150 karma · joined August 24, 2010
NCCN Clinical Practice Guidelines in Oncology (NCCN Guidelines®): The NCCN Guidelines® document evidence-based, consensus-driven management to ensure that all patients receive preventive, diagnostic, treatment, and supportive services that are most likely to lead to optimal outcomes.
Format(s) Available for Licensing: PDF API not available
As pg brings it up, writing is one of the many ways to shape ideas and even change them. But I wouldn’t go so far to say it’s the stricter test.
Each way of expressing and sharing ideas will test it in different ways. Writing may look for conciseness, flow and completeness while talking about it can validate ideas for collaborative building.
Going a step forward, I’d suggest that putting Ideas into Action IS the stricter test.
[1] https://www.linkedin.com/pulse/truth-market-fit-unbundling-t...
Which leads to more-than-once-a-week situations of "Hi - full question or comment notification that probably shouldn't be seen by co-worker/boss/client" popping up during the share.
A simple "hello" --wait for answer-- protocol makes it a quick way of checking if it's a good time.
This Capitalism 2.0 would also need to be a system of things that enables a new direction - whatever that may be - based on the fragile regression to the mean of what an expected aggregated view of that looks like.
UBI can or cannot be part of that system, but by itself it can quickly become irrelevant.
Most economic theories of capitalism are based on (mostly) rational behaviors of the majority of market participants. Social studies will show that in topics related to finances/money, behaviors are all over the place.
Want to drive towards Capitalism 2.0? Start with financial education, support systems, relevant incentives (maybe UBI is one of them) and a good shared vision of what that 2.0 is.
The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.
You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.
Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.
It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.
If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.
Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.
https://htmx.org/extensions/client-side-templates/
any element below it in the DOM can use one of three attributes named <template-engine>-temlpate
-- The other day I was talking with a friend about structured editing and literate programming came up. LP was one of Donald Knuth's ideas, to structure programs as readable documents instead of just machine docs. He was interested in it, I was cautiously skeptical. We both knew the famous story about it: https://en.wikipedia.org/wiki/Literate_programming
"In 1986, Jon Bentley asked Knuth to demonstrate the concept of literate programming by writing a program in WEB. Knuth came up with an 8-pages long monolithic listing that was published together with a critique by Douglas McIlroy of Bell Labs. McIlroy praised intricacy of Knuth's solution, his choice of a data structure (Frank M. Liang's hash trie), but noted that more practical, much faster to implement, debug and modify solution of the problem takes only six lines of shell script by reusing standard Unix utilities. McIlroy concluded: >>Knuth has shown us here how to program intelligibly, but not wisely. I buy the discipline. I do not buy the result. He has fashioned a sort of industrial-strength Faberge egg—intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start."
The program was print out the top K most-used words in a text. (and so it goes on...) ---
Just a word of caution here. It would be important for you and the client to already be aligned on financial terms / paid pilot when based on feature development. When dealing with larger organizations, it’s not unusual do see B2B postmortems caused by ‘death by a thousand features’ where the deal never happens. Until the organization has to pay anything you may not have a deal at all (didn’t go through procurement, legal, etc).
security tools = 10 opsec = 0
So if this is a $5M potential market, probably there is a clear winner. If this is a $100M potential market, things are just starting.