The Trap You Set For Yourself - <AUTHOR> http://blog.codinghorror.com/the-trap-you-set-for-yourself/ <comment><USER3> _> The way Lancelot motivates himself to get past self-doubt in combat is not to care whether he lives or dies.

As Ariely says: Lancelot fights better than anyone else because he found a way to bring the stress of the situation to zero. If he doesn't care whether he lives or dies, nothing rides on his performance. He doesn't worry about living past the end of the fight, so nothing clouds his mind and affects his abilities — he is pure concentration and skill._

This is "somewhat" similar to what Steve Jobs said in his commencement speech at Stanford:

 _> Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart._

Atwood closes with: "concentrate on the daily routine of doing what you enjoy, what you believe in, what you find intrinsically satisfying." What this fails to take into take into consideration is that unless you are focusing on the "right" things, this pattern can be more harmful. On most days I just want to meditate, catch up with family, exercise and perhaps hang out on the beach or travel to exotic places. I don't currently find work intrinsically satisfying (a majority of the working population don't find their work intrinsically motivating).

This is also bad advice if you are depressed. It just doesn't work then. Most days you want to sleep in, stay within your space, and think about darker stuff. Completely unrelated but the reason many people fail to quit smoking or quit eating unhealthy things is not because they don't know that these habits are bad for them but because in that moment, they are unable separate their desire from what they should be doing for the long term betterment of themselves.

I'm assuming that the author is primarily writing this post for programmers/computer scientists and how they can focus on increasing their skills in their chose field, but this post is generic enough that I though my comment may be relevant enough to add to the discussion.

<comment><USER4> It's also similar to what one of the older budo teachers said (the text is at home, I'm paraphrasing what I understood):

Mindsets for going into battle/duels can be:

1) Believe you are stronger and will win. It's weak because if it turns out you are not you will lose heart easily.

2) Convince yourself you are stronger without taking data into account. (As in, be positive.) Weak for the same reason.

3) Believe you are doing the right thing, and you want to do it regardless of outcome. According to this teacher, here lies true strength because you will not lose heart even against a stronger opponent.

<comment><USER5> Outside competing contexts, I tend to think you should give 100% regardless of outcome, but not dismissing it since it's also the greatest data to learn from.

</comment></comment></comment><comment><USER6> How about we start paying attention to how we describe men? That quote was really unnecessary:

"They (women) aren't just bad at behaving like arrogant self-aggrandizing jerks. They are bad at behaving like self-promoting narcissists, anti-social obsessives, or pompous blowhards"

which suggests men are mainly successful because they are those things.

I recently heard (in a finance lecture, but still) that 3% of men are psychopaths, and 1% of women. So yes, more men are psychopaths, but neither gender is off the hook, and the majority of people actually aren't psychopaths.

<comment><USER7> Throwing your gender under a bus is a primitive way of signalling that you're an enlightened bro. I find it rather sleazy.

</comment></comment><comment><USER8> I've realised that I have a tendency to fall into this trap when I find I'm working _for_ someone, rather than _with_ someone. It seems that distinction is important to me (subconsciously). It seems to come about when I start thinking 'just keep them happy and off my back' vs 'just do the right thing'. Thankfully, I've only been pulled into this thinking twice in my career.

<comment><USER9> My usual solution is 'just do the right thing even if it gets you fired' to that problem.

I don't mind working for someone but i can't do it without doing it properly if he wanted an obedient servant he probably shouldn't have hired me to begin with.

</comment></comment><comment><USER10> With all due respect to women, the notion that

"They aren't just bad at behaving like arrogant self-aggrandizing jerks. They are bad at behaving like self-promoting narcissists, anti-social obsessives, or pompous blowhards, even a little bit, even temporarily, even when it would be in their best interests to do so."

suggests either a very limited acquaintance with women, or an unduly extensive experience with bad male behavior.

<comment><USER11> No, it's a "let's say this in a way that won't look too sexist" thing.

I don't know if it's sexist to make generalisations about women if it's clearly just a generalisation. And it might even be true, on average - <USER2> it's probably a result of nurture not nature.

But I think he didn't want to pour any more fuel on the fire than necessary.

</comment></comment><comment><USER6> Side note: Ariely's Coursera course has just started for the second time - [https://www.coursera.org/course/behavioralecon](https://www.coursera.org/course/behavioralecon)

There is still time to jump in.

I highly recommend it.

<comment><USER12> Thanks, just letting you know that you've inspired at least one person to join!

</comment></comment><comment><USER13> > They [women] aren't just bad at behaving like arrogant self-aggrandizing > jerks. They are bad at behaving like self-promoting narcissists, anti-social > obsessives, or pompous blowhards, even a little bit, even temporarily, even > when it would be in their best interests to do so. Whatever bad things you > can say about those behaviors, you can't say they are underrepresented among > people who have changed the world.

Why not, instead of selectively adopting this behavior when convenient, instead work to create systemic disincentives for it, if not across the business world, then at least in one's own little corner of it?

<comment><USER6> Is there proof that that kind of behavior actually brings about good results? I think it might just be a myth. The quote is from a rant about some written application where the applicant sounded too full of himself. But I think such things can also backfire. It isn't at all obvious to me that who boasts the most is the most likely to get the job.

Although I admit there are studies that show in groups people tend to trust the people who claim they know the most.

</comment></comment><comment><USER14> Anyone interested in learning about human perseverance would do well to spend a couple hours reading Viktor Frankl's Man's Search for Meaning.

It's short. It's accessible. There is also a noticeable absence of Richard Gere.

"In psychiatry there is a certain condition known as delusion of reprieve. The condemned man, immediately before his execution, gets the illusion that he might be reprieved at the very last minute. No one could yet grasp the fact that everything would be taken away. all we possessed, literally, was our naked existence."

The trick is that our naked existence is all we ever have. Learning to deal with this fact, to accept and and even rely on this fundamental truth, is the first step towards developing a real purpose in life. This is the kind of thing that will get you out of bed each day.

[http://www.amazon.com/Mans-Search-Meaning-Viktor- Frankl/dp/0...](http://www.amazon.com/Mans-Search-Meaning-Viktor- Frankl/dp/080701429X)

<comment><USER15> The book itself is amazing, yet I found it had the same effect as other books that hold similar messages - it just doesn't translate well into my day to day thoughts. After reading it I felt the sort of profound enlightenment one might expect when discovering what was written in the book, but woke up the next morning feeling the same as before I had read the book.

"Learning to deal with this fact, to accept and and even rely on this fundamental truth, is the first step towards developing a real purpose in life."

Perhaps I'll get there at some point, but I just haven't figured this out yet. I see the fact there, I understand it, but incorporating it into my daily thinking is just something I can't seem to grasp.

<comment><USER16> Integrating changes into your being is a slow process. Reading these kinds of books help plant the seed of change, but the seed grows at its own pace. Patience and self-forgiveness

"Step by step walk the thousand-mile road" \- Musashi Miyamoto

<comment><USER14> I agree. It takes time and the reading of other books. Eventually, when you're ready, it just sort of clicks and you're there.

</comment></comment></comment></comment><comment><USER17> [http://www.slate.com/articles/technology/technology/2014/01/...](http://www.slate.com/articles/technology/technology/2014/01/do_what_you_love_love_what_you_do_an_omnipresent_mantra_that_s_bad_for_work.html)

</comment><comment><USER18> I honestly want to hope this article is an intentional bait, because otherwise choosing this moment to drop a blatantly sexist article seems strange, and based on my past experience out of character for Atwood.

<comment><USER19> I am genuinely curious how this qualifies as sexist. My understanding, based upon my own experience as well as some of the research I have read, is that there is something to the distinction Atwood brings up in this article. Whether or not such a distinction is fact though, I would like to think there is a way to discuss such possibilities without offending reasonable people.

Is the issue that he claims a distinction? The way he values the qualities he ascribes to either sex? Something else?

More importantly, is he wrong? Without a doubt utterly wrong, or is there room for debate? At the end of the day that is what strikes me as most important.

<comment><USER18> The sexist part would be where he states that men as a whole behave one way, and women as a whole behave another way.

<comment><USER19> Thank you for the clarification. Would it be legitimate for me to rephrase your position as "stating generalizations about peoples' behavior, based upon sex, is sexist"? For example, if I were to say "men, in general (though not in all cases) are more risk-seeking than women", would that be sexist?

I am not sure that I can accept your definition of sexism. What if that generalization is true? I can concede that the specific generalization I made above is debatable, but I don't think it can be argued that it is without a doubt false. The connotation of the term "sexist" is that the thing being labeled so is morally wrong. I cannot accept a stance that labels certain beliefs as blatantly immoral which are (at least debatably) true.

To propose a different definition of sexism, I would like suggest that making such statements is only sexist if one refuses to acknowledge that there are exceptions, or if one refuses to acknowledge such exceptions as morally acceptable. For instance, refusing to fund a startup founded by a woman because one assumes no woman is capable or because one thinks it is wrong for any woman to do so.

There are a few things I would like to note about my definition. First of all, it does not state what sort of legislation should be passed to prevent sexism. Indeed, I consider it quite probable that there could be instances of sexist behavior that, while immoral, would also be immoral or at impractical to legally prevent. Second, it does not require a person to be 100% accurate when applying generalizations. Third, you do not need to be all things to all people; you can choose to market to only those people who fit the generalization. Just be aware that, especially with the advent of the internet, it is quite easy to market to only those people who are the exception.

I could go on, but I hope that is a sufficient explanation of my position. If you are still following this thread I would like to hear your critique.

</comment></comment></comment></comment><comment><USER20> There are at least a quintillion ways to fail at different levels of strategic mistakes, with a few paths out by getting the big things right and making the best of change and uncertainty.

</comment><comment><USER21> I've heard this alternately described as "Fake it until you have it"

</comment><comment><USER22> Zen :

Jeff and Jobs .

</comment><comment><USER23> First Knight is not a terrible movie.

<comment><USER24> You're right of course. It is a _really really_ terrible movie!</comment></comment>


How to ensure your startup will fail - <AUTHOR> http://howtosplitanatom.com/news/how-to-ensure-your-startup-will-fail/#comment-14119 <comment><USER2> "Take a look around the net and make certain that you don't have another huge player operating in the space that you want to move into." BS, That is how you end up selling hats for iguanas, dont be afraid of competition just make sure to do something better.

<comment><USER3> True, and yet if you literally don't know about the huge player there's a good chance that you will forget to do something better. Or, if you accidentally do have some distinctive features, you will neglect to market them properly.

Another way to phrase your point is: "look around the market and make sure there's a huge player whose customers you can siphon off".

</comment></comment><comment><USER4> Why is the link to the last comment, not to the beginning of the article? Took me a while to read the linked comment, and to figure out why it was so important. It wasn't. :)

</comment><comment><USER5> As someone who hasn't gotten too deep into hackerdom yet, this thought goes through my mind often when viewing a newly launched startup:

"What you need to understand, right now if you have not already, is that early adopters are not real people. The geeks, techies, friends and family that initially use your product are not representative of the public at large. Their opinions on your product are not representative of what the mainstream will think."

I suppose most people want to use their hacking skills to make something useful in their domain of expertise. Unfortunately, for most hackers their domain of expertise is hacking, which limits the userspace.

<comment><USER6> Unless, as we do, hackers build things for parts of their lives other than hacking.

<comment><USER7> Hackers are still not representative of the mass userbase that startups are looking for if they want to be big. This matters because hackers will value different things than normal users. RSS springs to mind as an example. If, for instance, you do a webbased tool to keep track of your tasks one of the first things a hacker might look for is a rss feed so that he can put it on his feedreader along with all of his other feeds. Normal people won't even know what RSS is.

So even though you do a non-hacker product, hackers will still value features that are of littel importance to a normal crowd.

</comment></comment></comment><comment><USER8> Man, I've got to make sure I check Hacker News all the time so I don't miss this kind of info that'll keep me from failing.</comment>


Avoiding Event Chains in Single Page Applications - <AUTHOR> http://www.code-experience.com/avoiding-event-chains-in-single-page-applications/

<comment><USER3> I've read this 3 times and I still can't see what the advantage of this dispatcher is.

In the event model, Events that deal with model A also have to be dealt with in models B,C, and D. Wouldn't this lead to exponential explosion?

The fact that B has to explicitly wait for A in the code also seems prone for errors. If A changes to no longer deal with that event, will B block forever?

And this still builds an event chain, because B is blocking on A. I don't see how this is different from an event chain, execpt that the dependency is non- obvious (whereas a callback chain/future chain will at least show what data is being passed into B from A)

This is maybe OT as well, but this article could really do for some concrete examples in the explanations. "Model A" and "Model B" are not examples.

<comment><USER4> > If A changes to no longer deal with that event, will B block forever?

No, A would just no-op, and control will return to B. This is all written in the context of JavaScript, with a synchronous dispatcher and no threads which can block.

</comment></comment><comment><USER5> It took me a while to come round to it but this kind of madness is something that Ember's event/render loop and implicit property dependency graph makes really, really easy to solve.

People knock Ember for its complexity but in reality it's simply a complete/coherent solution for the kind of problems people like this are iterating towards - and watching their code get more complex as they do.

<comment><USER6> Having built large Ember and Flux apps, Ember seems a big opaque mess.

Computed properties which depend upon other computed properties never seem to update quite right. The object system is tightly coupled to the template system. It's a monolithic framework that depends upon hidden magic to bind the pieces together.

</comment></comment><comment><USER7> It looks to me like the case where this is required is actually screaming out for a new event type, not fixed dependency order. B shouldn't be listening for the same event as A is if B depends on A getting something done. A should be firing a new event which B can listen for.

Is there some subtlety I've missed here?

<comment><USER8> The flaw with such a strategy is that it does not scale. (We used to do exactly what you described). In a big "eventful" app, you will have way too many events to keep track, and you will constantly be browsing trough different modules to understand the chain.

Lets assume the user clicks somewhere, so an event is fired "user-clicked-x" that model A listens to.

So you know that model B needs to change as well and you fire a new event type from model A, say "model-a-changed-because-of-user-clicked-x" or a more generic event, say "model-a-changed".

Both will cause headaches, because they require a quite high cognitive load. With the generic one, you have the issue that sometimes you want A to change but not B, which leads to lots of conditionals (all of which you need to remember).

With the specific one, you have two events that mean almost the same, but are different. With every model C and D you need to carefully evaluate which event you listen to.

In isolation, this is perfectly fine.But if you have 10+ of those things interacting with eachother, it will be a big mess. You will have 30-40 different events, that map out a hierarchical order that you need to track down through multiple modules every time you change something.

If you do not abstract the chain away, the complexity is simply too high. You'd have to keep roughly 15-20 links in your head, which is too much. With Flux or similar patterns, you just have to keep one pattern in your head.

In the end it's a simple story of abstraction. Your mind can only deal with a couple of different things. If you reach the threshold, you need to abstract. Flux shows one way to do this (and it is only useful if you've reached the need for abstraction threshold).

Having one or two short event chains is perfectly fine. If you have 5 different user interactions that have a complex ripple effect through the state of your app, you need to do something, or development speed slows.

<comment><USER7> This I can well believe, but I'm interested in this bit:

> you fire a new event type from model A, say "model-a-changed-because-of- > user-clicked-x" or a more generic event, say "model-a-changed".

These two seem to be on opposite ends of a spectrum where I'd try to pick a middle point. I wouldn't want the semantics of "this is a reaction to a UI event" anywhere past the first event, it's way too detailed. I'd try to pick something like "model A's date field changed ", or ideally something more meaningful like "The User updated their address".

<comment><USER8> This still introduces a new link, which will overload your brain if you have too many of those.

To give you some context:

In the app I'm developing now, we've got roughtly 25 global user interactions (meaning an event that will be triggered with a DOM event).Most of these events affect more than one model. Quite a lot of those also trigger complex event chains.

Multiple models have complex dependencies that would form branched dependency chains with conditionals.

It's just impossible to have everything in your mind at all times, which you need to if you want to extend a chain without bugs.

Now you might not have this issue in your projects, because they don't require that kind of interactivity. If thats the case don't bother, keep doing what you are doing.

But if you ever realize that things get pretty complex in one of your projects, then you know where to start :).

</comment></comment></comment></comment><comment><USER9> Isn't this simply trading one level of complexity for another?

Maybe the OP is just giving a bad example, or maybe I'm missing something - but one thing I really don't like in his example is that model B's 'waitFor' call needs to know about Model A, and that model A has an appDispatch. This kind of tightly coupled code isn't going to do anything useful for your codebase if you have a large application. It might make debugging easier right now because things are more explicit, but it will make you less flexible in the long term. It also doesn't solve the problem that you still need to understand that A has to finish before B can start - which I suppose most people would simply solve with an additional event. The OP does mention this in the article, but I'm not convinced that the trade off is worth it here. If I'm to explicitly state dependencies within the event handling code, then that means that any time I want to change how things handle events, I've got to remember exactly which of my dependents reference me. This isn't helpful - <USER2> in fact it may be more painful than the current situation.

I guess my main problem here is that the benefits this brings just aren't enough (in my view) to offset the potential pain. To me, it kinda just feels like cutting off your nose to spite your face. You might make one area a bit easier to debug, but you lose out in other areas too.

On the surface the code may look more sensible and easier to think about, but in practicality I'm not convinced that this won't introduce additional pain later on.

</comment><comment><USER10> it's amazing how JavaScript is becoming the new java.

everyone thinks that adding a ton of extra complexity in the guise of a simpler api will make it more maintainable.

in this example you now have 4 events under the hood and two event dispatchers. but it seem simpler because you only "see" two and one dispatcher.

while it may make things just a little bit simpler to maintain you may enter debug hell when there's bugs on that added under the hood complexity... which will often be a code you're unfamiliar. making the article main argument (helping on debugging edge case bugs) kind of two edged

<comment><USER8> writer of the article here:

I simply cannot follow the argument about "added complexity"

The use case defines the minimum amount of links you have to make, in this case 4.

Now you have two options: You just roll with it (we used to do that), or you try to abstract away a few steps (we do this now with the dispatcher).

The dispatcher here is roughly 100 lines of fairly simple, unittestable code, so I really cannot see where the elusive bugs come from. 100 lines that you will easily save if your app is complex enough by the way.

With the dispatcher, you can abstract away a couple of steps consistenly over your app. Now I fully agree that you need a certain threshold of complexity to make it worthwile.

But you cannot avoid the original complexity of your usercase.

There is no alternative to decent abstraction if you reach a certain level of complexity, because it is given externally.

Other concepts like two-way databinding do exactly the same.

<comment><USER11> It seems all you've done is inverted and hidden the sequence dependency in a series of waitFor chains instead of event chains, which in some ways is worse; compare

        A:
         update;
         notify B;
        B:
         update;
         notify C;
        C:
         update;
         notify D;
        D:
         update;

with

        D:
         wait for C;
         update;
        C:
         wait for B;
         update;
        B:
         wait for A;
         update;
        A:
         update;

The former is a clear sequential path, the latter builds up and then unwinds in a stack-like fashion. It's like the difference been non-tail and tail- calls.

 _It 's only a technical nuisance that one model needs to wait for the other to update._

I would certainly not view a sequence dependency that's critical to correct operation as a "technical nuisance" to be hidden away; it's an important fact.

<comment><USER8> yep, that's all it does. It just inverted the sequence dependency. You call it "worse". But I argue that it is a much better mental model in the specific use case of updating state given an external disruption from the user.

You see, what you call a clear sequential path is what I call evil :). We had tons of those in our app, and it was so hard to keep track of them, and everytime I didn't look at it for a while, I had to invest 10 minutes to track down the event chain.

There is one simple reason for this: If you have a sequential path, you loose the context after the first link. A updates because "user-clicked-x", and B updates because A updates. But if you're working on B, you ask yourself why the heck did A update in the first place?

You might argue that you are always aware of this, but we found that when our app grew more complex, we actually didn't always know.

I'm sure you could find a solution where you keep the sequence and don't lose context, but then you have to state the dependency in the wrong place: In model A you have to say that model B should update. But that's all wrong because A shouldn't care about models that depend on it. The models that depend on A should care!

So by inverting the whole sequence dependency, you gain the following:

1\. in every model you are aware of the context, i.e. the original event that triggered the state change in the first place

2\. you are also aware on what other models this model depends on (it is explicitly stated and not hidden like you said).

This means that you can work on model B and extend it without ever looking at other models, while knowing exactly the origin of your state change. In my opinion, this is decoupling at its best. It also helps unittesting greatly.

While I agree that inverting the dependency is a drawback, I've gained things that, at least in my opinion, heavily dominate that drawback.

<comment><USER3> > A updates because "user-clicked-x", and B updates because A updates. But if > you're working on B, you ask yourself why the heck did A update in the first > place?

Stack traces are a thing. Chrome even has asynchronous stack-traces.

A updates because "user-clicked-x", but it might also update because "user- clicked-y". Or because "user-clicked-z". So now I have 3 things to add to A and to B, because B needs to refresh everytime A does. So if you forget about one of these, then suddenly B is out of sync.

A "solution" to this problem already exists in terms of event listeners. If B listens to any change on A, then A doesn't have to deal with B, but B updates properly and doesn't have to deal with all event types A has to deal with.

<comment><USER12> > _Stack traces are a thing. Chrome even has asynchronous stack-traces._

Now this argument line has dissolved into plain sillyness.

He showed how he made the congnitive load less and the dependencies more explicit and locally evident IN THE CODE, and you tell him to use "stack traces" for that?

<comment><USER3> From what I understand, this methodology increases code duplication, which leads to higher risks of bugs later on.

I'm trying to understand whether this is truly the case, or if I'm missing something.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> A model listening to other models? Yuck, that's just wrong. In an MVC application, only controllers should update models. Just because Backbone lets you listen to model events from anywhere doesn't mean it's a good idea.

IMHO Application events should simply bubble up through the DOM, and get caught by appropriate controllers (Backbone.View class in backbone parlance) that then modify the appropriate models. If need be it's the top-level controller for the app, eg:

document.body.addEventListener(function(e) { modelA.doSomething(e.data) modelB.doSomethingElse(e.data) });

I'd take a simple approach like that over an event bus/dispatcher/coolest-new- pattern-since-sliced-bread - any day, and sleep at night knowing if something happens to me, any employee will be able to parse and debug my code.

PS And no, I don't use Backbone, but my own 500 LOC MVC framework that's got zero dependencies and is about 100x faster.

<comment><USER14> Backbone is considered a high-quality javascript project, written by a very talented and experienced developer.

Could you explain what you do differently in your MVC framework to achieve those gains?

<comment><USER9> Easy - he doesn't support anybody else's requirements, app designs, or coding practices.

</comment></comment></comment><comment><USER15> OT but I'm looking for a comparison between Angular and React/Flux, preferably with a real case study. Working with templates that update themselves without having to bother with anything else just seems to much easier...

<comment><USER8> I do not have much experience with Angular, however, I feel the arguments over different frameworks depend a lot on the specific nature of your app.

two-way databinding is perfectly fine and really helpful for a lot of apps. However, it will screw you for certain use cases.

In my opinion, it really boils down to how much global interaction you have in your app. If you simply render a lot of models that can only be changed trough the view, then I don't really see a reason for a Flux like architecture. Two- way databinding is perfectly fine there. (React vs whatever then boils down to performance vs toolset)

If you do a lot of graphical stuff that allows for heavy interaction, filtering and other kinds of stuff, I believe that two-way databinding will be your downfall. You need to clearly and explicitly map out on how data flows through your app. That is the time where an architecture like Flux shines.

So ask yourself this question:

"How often can a user do something in your app, and a lot of Views need to rerender?"

If the answer is "often", then you should consider something like Flux. If not, Angluar might be a better fit, especially if you already know it.

</comment></comment><comment><USER16> If ModelB needs to wait for ModelA, and it already is aware of ModelA (which your code requires) - why not make ModelA into an eventDispatcher, have ModelB listen to ModelA, and have ModelA dispatch an event when it's done (Or write a small onX function in ModelA).

It's also clearer, easier to implement, already implemented in tons of frameworks and easier to unit test (since you no longer need to mock the appDispatcher).

You should probably try to avoid using a global eventDispatcher (as any other global), whether you can specify order of execution or not.

</comment><comment><USER17> Coming from Backbone.js so this post was extremely helpful to me. Thank you. I do recognize the exploding complexity of event chains.

<comment><USER18> You may also be interested in an open source library I wrote called EventAPI [https://github.com/benaston/event-api](https://github.com/benaston/event-api)

</comment></comment><comment><USER19> Does anyone know how this dispatcher is different from WPF dispatcher? Maybe that's the way to sell it.

<comment> rational-future IMHO WPF doesn't have so much of a good reputation, to be used to market other products.

<comment><USER19> not for marketing per se, but to sell to understand what is it and why is it good. A lot of people know WPF and you could use the analogy.

</comment></comment></comment><comment><USER14> " _But when somebody uses his mouse to click somewhere and expects something to change, things might get tough. If you 're lucky, it's just a local action, like a dropdown menu that needs to open. If you're unlucky, it's some complex filter action on your data heavy app that causes three ajax requests and changes to seven models._"

Reading this I start to think if isolated javascript components and a jquery pubsub system publishing the 'newclick' event from the server isn't simpler and more modular..

</comment><comment> rational-future So Flux is poor man's BizTalk.

<comment><USER12> Yes -- but only if you half-understood Flux, didn't read the article, and just wanted to make a snark comment.

<comment> rational-future Now that's a reassuring yes :)

What I meant is it seems (I've never used or seen it before) to be closer to a message broker than a bus - [http://www.udidahan.com/2011/03/24/bus-and- broker-pubsub-dif...](http://www.udidahan.com/2011/03/24/bus-and-broker- pubsub-differences/)

</comment></comment></comment><comment><USER20> Complex.

<comment><USER21> How? Everything about this seems incredibly straightforward

<comment><USER20> Call me old fashioned, but function calls are pretty nice events.

Rather than heaps of code, and weird concepts, you can just implement firing the event into the A, and B models by calling a method on each. Simple!

      A.getFilteredDays(payload);
      B.getFilteredDays(payload);

That's only two lines of code compared to 30 or so. This scales up because with more models, you have less code.

In practice these are easier to debug, because the debugger supports function calls with stack traces, and easier to read, because people understand function calls. They are also faster.

This is why I think that long article is complex. Remember that OO uses messages and objects. Method calls are events. Also remember that there is an M in Document Object Model (DOM). So you see we already have a Model, and events?

Please also consider how much less code there is in the jQuery version of the todomvc app compared to the react one. [http://todomvc.com/](http://todomvc.com/)

<comment><USER12> Hmm, this answer seems to have missed 7-8 years of the web's development, and shows a preference for convoluted, messy codebases with huge conginitive overload...

<comment><USER20> Explain how smaller, simpler and faster code is worse.

<comment><USER12> Smaller: Not really. You just avoid some K of helper code already build (by the React team). Your code will end up being more than the one you'd have written on top of React -- because it will also have to reimplement and handle all common cases (either poorly, or time-consumingly).

Faster: could be, could be not. Without profiling this is an empty statement. Besides, "premature optimization is the root of all evil".

Simpler: Noope. You have to manually track all the interactions, and you strongly couple things together with your "OO and functions" idea. It might be simpler to just churn out code initially (instead of understanding an architecture), but it becomes an ad-hoc mess soon.

Let me put it this way: it's not like you have discovered a novel way of building stuff compared to these coders that overcomplicate things. What you propose is what these engineers have already tried, used for a decade or so, and found unscalable and wanting.

It can work for small and not complicated pages, but it's not a solution to modern single page web apps.

You might think that you are proposing a clear and simple way of coding as opposed to something like overengineered J2EE patterns mess.

But what you describe is more like the "Why use procedural code etc, GOTOs for flow are simpler and faster", or "why use functional programming, imperative is simpler and faster".

<comment><USER20> The code I mentioned is definitely _smaller_ than in the article.

It is _faster_ , because it is just a function call. It doesn't create any event objects, or have to go through six layers of other function calls.

It's _simpler_ because there is less code, and there are less concepts.

No, it's not novel or new. Messages as function calls, and MVC comes from 70s smalltalk.

It's not strongly coupled because of a few reasons. Firstly because in JavaScript it is simple to dynamically reassign objects and functions. The receiving object does not care where it got the function called from. Only the sending object knows where it is sending to. However, from Coupling theory in Software Engineering, we know that if there are a small amount of outputs then the strength of the coupling is still low. Luckily in many apps there are often only a few places where you want to send a message. [http://en.wikipedia.org/wiki/Coupling_%28computer_programmin...](http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29#Module_coupling)

Yes, if there are lots of outputs it may be useful to reduce the coupling. In my experience, even with large apps (100 person teams), this is often not the case.

It is often useful to know what your app is doing by looking at where the events are going. Just using function calls makes this very easy, both in source code and in the debugger. So this also needs to also be weighed up in the decision of how you are passing events around.

<comment><USER12> > _The code I mentioned is definitely smaller than in the article._

Yeah, so this is a first sign of misreading the dangers.

Of course the code you mentioned is "smaller than in the article". The code in the article is a toy example to illustrate a specific point.

It's when you start to build a full app, with all the (necessary for the requirements) complexity that it's gonna get much more and more unyieldy that the code one would write on top of React.

> _It is faster, because it is just a function call. It doesn 't create any > event objects, or have to go through six layers of other function calls._

Again: premature optimization. After you build your colossal temple of function calls in a NON TOY example, it will either be slow (because you'll have re-introduced abstractions and layers by yourself) or it would a complex spaghetti of cross-calls.

> _It 's simpler because there is less code, and there are less concepts._

Less concepts != simpler. Assembly has less concepts too.

And it's only "less code" because you're comparing a "toy example + framework" with a "toy example without framework". It's after that level that it gets hairy.

> _No, it 's not novel or new. Messages as function calls, and MVC comes from > 70s smalltalk._

Yeah, and it's what all these coders going to React etc have tried already for a decade and found out that it doesn't cut it with modern apps, because the environment they run in is nothing like a Smalltalk MVC application.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> disappointing...thought you meant F.lux</comment>


My Second Phone Is in the Cloud - <AUTHOR> https://lucassimpson.com/blog/2020-01-23/my-second-phone-is-in-the-cloud/ <comment><USER2> There are already multiple implementations of this:

\- nextcloud ([https://nextcloud.com/](https://nextcloud.com/)), more like a "dropbox-like" with added applications \- sandstorm ([https://sandstorm.io/](https://sandstorm.io/)), with a high focus on security \- yunohost ([https://yunohost.org/#/](https://yunohost.org/#/)), a full-on debian distribution with all the scaffolding to one-click install known applications (mail server, file storage, IM server and client, ...). All linux software can be used as an "app". The process to make it into an app is the same as creating a package for a distribution, except specifically for this one. The good thing is that installation is way easier than using a package manager and configuring the database for the user, etc... It seems to be the most in line with the author's vision.

<comment><USER3> There's also FreedomBox ([https://freedombox.org/](https://freedombox.org/)), which is part of / released with Debian.

</comment></comment><comment><USER4> Hugged to death.

"If you were using federated Kuberenetes with node auto-scaling and the latest cloud-native AI-enabled service discovery OSS tools for geographically aware traffic distribution your static site wouldn't have gone down."

<comment><USER5> I wonder how a personal website can't be made to handle HN traffic? Is there are some kind of excessive back end that cause stuff like this?

<comment><USER6> You can read about his tech stack here[1]. Curiously, his "About" page loads fine. He is using a Django REST API with DynamoDB and the "whole site is hosted serverlessly on AWS Lambda."

1\. lucassimpson.com/about/

<comment><USER7> Something is wrong with the stack where Dynamodb and Lambda are advertised for autoscaling automatically for your needs.

<comment><USER8> Dynamo DB can be expected to adjust capacity every 5 minutes when set up with an auto scaling configuration or on pay-per-request model.

Lambda will scale up in seconds.

Dynamo, however, can be set not to (if you wish to stay within free tier limits). Dynamo DB free tier allows 5 4KB/key reads/second, with a buffer for about 5 minutes worth of "tokens" at this rate.

If poorly designed (e.g. using Dynamo like a relational database) you chew through this with app-side joins very quickly. Even if well designed, looking up related articles, or re-loading records on page transition will eat up DB time

As someone else mentioned, caching is critical for this setup to survive this load, especially if you want to stay in free tier... And CloudFront costs pennies compared to Dynamo and Lambda... Though both can easily be cheaper than $5/month

<comment><USER9> > And CloudFront costs pennies compared to Dynamo and Lambda...

The website actually is fronted by CloudFront.

</comment></comment></comment></comment></comment></comment><comment><USER10> I was hoping this as someone else who, like me, has ported their primary phone number to twilio and runs their own personal telco, in the cloud.

That is not what this article was about.

<comment><USER11> I'd love to see a write up on this

<comment><USER12> I'm sure everyone's setup is different but I did this for about 8 years and had to stop recently due to a variety of problems. The first being the lack of support for group messaging. I couldn't send group messages at all but what was even worse was that when I was part of group messages I would receive the messages individually as if the person was texting me directly. My system could mark them as being group messages but I couldn't see the other recipients so there was no way of knowing who else was in a thread until other people started texting and then could piece together the group from context.

Also some services straight up refuse to send SMS to cloud phone providers meaning you can't sign up for certain services that needed a verified phone number (unless they had an option to receive a call with the verification code which worked like 25% of the time).

Dialing was another huge issue, you can somewhat intercept outbound calls on Android but the system is buggy so I had to find other methods. Since I had integrated my SMS/MMS messaging with Slack (one slack channel per phone number) I created a /dial command that would call my phone and then when I answered it would transfer me to the person I wanted to call.

Happy to answer more questions about it but I highly recommend people think about all the consequences before moving their main number over.

<comment><USER13> > Also some services straight up refuse to send SMS to cloud phone providers > meaning you can't sign up for certain services that needed a verified phone > number (unless they had an option to receive a call with the verification > code which worked like 25% of the time).

I've ran into the same issue with this on Google Voice. Though sometimes I wonder if I could have gotten the best of both worlds by just porting a number from a traditional carrier to Google Voice/Twilio.

Are these kinds of checks only against the number itself? Or is there some kind of dynamic registry?

<comment><USER10> "Are these kinds of checks only against the number itself? Or is there some kind of dynamic registry?"

In general it is much simpler than that. These companies are sending you these SMS messages not from a "normal" phone number (xxx-yyy-zzzz) but from a shortcode (xxxxx). The "from" is a shortcode and _only_ mobile numbers can receive SMS from shortcodes.

So if your number is not a "mobile" number, you might still receive SMS from other real phone numbers, but you cannot receive SMS from shortcodes.

Twilio, for instance, _does not provide mobile numbers_. Period. So even if you port a mobile number to twilio, as soon as it is theirs, you cannot receive SMS from shortcodes.

<comment> _-___________-_ Your assertion that only mobile phones can receive SMS from shortcodes is not true in general, and additionally many verification SMS are not sent from shortcodes.

<comment><USER10> Only _true mobile phone numbers_ can receive SMS from shortcodes.

Here is a list of carriers that are properly registered to receive SMS from shortcodes:

[https://usshortcodedirectory.com/faq/what-wireless- carriers-...](https://usshortcodedirectory.com/faq/what-wireless-carriers- support-short-codes/)

"... short code carriers have arrangements to exchange messages with mobile phone numbers only ..."[1]

[1] [https://support.twilio.com/hc/en- us/articles/223133447-Not-R...](https://support.twilio.com/hc/en- us/articles/223133447-Not-Receiving-Incoming-SMS-and-MMS-Messages-on-Twilio- Phone-Number)

<comment> _-___________-_ I guess this is a US thing, then. It's definitely not true in general, as I said.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Cached copy by Google:

[https://webcache.googleusercontent.com/search?q=cache:lIMDg7...](https://webcache.googleusercontent.com/search?q=cache:lIMDg7RKZRwJ:https://lucassimpson.com/blog/2020-01-23/my- second-phone-is-in-the-cloud/+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-b-1-d)

<comment><USER15> You can type "cache:" before any URLs in the browser, works in Firefox and Chrome.

</comment></comment><comment><USER16> This is a really cool idea. In fact, I was thinking about it but in the form of a PC [1].

Most desktop computers today are a magnitude more powerful then the small VMs we rent on the cloud. While you go on with your day, your desktop computer can be put to work in Your service.

[1]: [https://idiallo.com/blog/bringing-back-the- pc](https://idiallo.com/blog/bringing-back-the-pc)

</comment><comment><USER17> Sounds like a similar idea as the (failed) sandstorm.io.

<comment><USER18> Failed? Website looks open for business, and latest commit 6d ago: [https://github.com/sandstorm-io/sandstorm](https://github.com/sandstorm- io/sandstorm)

Agree that it sounds exactly like what OP is imagining, website even has the copy 'installing apps is as easy as on your phone'.

I also think Urbit is similar, but frankly I've always been too confused by the space analogies that project uses to be sure.

<comment><USER19> The website is a bit misleading since I haven't had the energy to really revamp it to reflect the current state of the project. A lot of the marketing material is still accurate in the details (e.g. features), but the overall presentation makes it look like a product for sale rather than an open source community...

The current state is that it's "just" an open source project, not a business. There are a few people working on it in our spare time. The paid hosting service has shut down.

<comment><USER18> Oh I see, thanks. I had heard of it before but wasn't familiar enough to know it had previously been paid-for/hosted option.

I actually thought my 'open for business' turn of phrase was going to draw comments like 'its open source what are you talking about', when I only meant that it existed.

\---

That's a shame it didn't work out, but I think for now the vast majority of people that want 'personal clouds' are so technically minded that they will favour at least running it themselves, if not ensuring that everything is OSS.

Perhaps a critical point can be surpassed after which privacy but not technically minded folks are interested in the by then popular concept, and will pay for the cloud device and then further for apps on its store app.

I think it's a solid idea, but that the money at the moment is in commodity infrastructure or hardware that happens to be used for it, and to a lesser extent software licences .

Did you consider selling Sandstorm licences, as a sort of iOS for a BYO phone, in the analogy?

<comment><USER19> > Did you consider selling Sandstorm licences, as a sort of iOS for a BYO > phone, in the analogy?

We tried for a while. But the kinds of "enterprise" customers who would pay for an on-prem/private-cloud version of Sandstorm are also the kind that don't just wander onto your web site and plug in their credit card... you have to do the enterprise sales dance, which we never had any clue how to do. :/

</comment></comment></comment></comment></comment><comment><USER20> The problem is in the details.

When openssl has a bug, who notices, decides, installs the new package and restarts all the dependent services?

That person or group has the actual control over your personal cloud server. And it's more efficient, and thus cheaper, if they are a large scale organization. Once again it will be more attractive to most people to centralize.

</comment><comment><USER21> I like the sentiment (and run my own Synology NAS to sort of achieve this), but I'm trying to understand the difference between saying "my second phone is in the cloud" and "I want my phone to be a thin client for a server that I run using open standards".

Is there any meaningful difference? I feel like the second idea has been around for a while.

Incidentally, because I've read so many articles recently bemoaning the state of the iPad, I think if Apple really embraced the "thin client" model for the iPad, they would have a much better shot at product market fit. For example, if the iPad could seamlessly view and edit files from, say, any SMB server as easily as it can from iCloud, I think that would get people excited. It would be decoupling the interface from the underlying standard, but also make sure that they work well together. Who knows, it also might lead to having a standard file format where we're missing them today, e.g., for handwritten notes?

<comment><USER22> > if iPad could view and edit files from, say, SMB server....

Try 'add server' in iPad's "Files" app?

[http://osxdaily.com/2019/11/04/how-connect-smb-share- iphone-...](http://osxdaily.com/2019/11/04/how-connect-smb-share-iphone-ipad- files-app/)

<comment><USER21> This is a great point, and I should clarify: I do this and it works. However, it feels like a second class feature, and there are many rough edges.

For example, some apps don't seem to be aware of this possibility and throw errors if you try to open a file on this way. You also can't add directories as favorites like you can for other sources. It's just annoying enough in some cases that it feels like Apple doesn't really want you to do it.

</comment></comment></comment><comment><USER23> This is great to see and is pretty much the same reason why we have initially started with Cloudron [1]. There are not many technical reasons why running your own apps on the server has to be harder than using a phone. There are tons of great apps already out there and from my perspective the biggest issue, as mentioned in the blog post, is the onboarding and ease of installation/maintenance of those apps including the server itself. The building blocks are all available but as a complete solution hard to use, unless one is a kind of a sysamdmin. This makes it just very exclusive. If you ever tried to setup your own email server there is so much crud work to be done and things to be learned. Learning about this is as such a great opportunity to understand the underlying technology and how things work together, but it is also a huge barrier.

1\. [https://cloudron.io](https://cloudron.io)

<comment><USER24> I tried cloudron recently and the experience was pretty smooth. However the 30$/month price tag put me off. Yunohost offers the same (please correct me, if cloudron has features yunohost doesn't have) for free, and it's hard to compete with free.

<comment><USER25> Agreed the price is steep but it's probably good they're focusing on profitablity. IMO what killed sandstorm.io is the lack of resources to keep apps integrated and updated. It's awesome tech but just didn't hit critical mass.

</comment></comment></comment><comment><USER26> Very cool idea. I do however have some comments:

\- The "appstore"-like experience already exists in the ecosystem, in a sense. You have package managers with post-install and configuration scripts (Installing slapd for example yields a perfectly functioning instance within 2 minutes), or maybe Ansible playbooks that run the instance with a simple file configuration and one command. For package managers, it all depends on the packaging.

\- Again the ecosystem somewhat already exists in a way if you consider Docker for example. All the dependencies are neatly packaged, and if you think kubernetes, then you you have helm as the appstore. It even solves the possible problems with ports and schenanigans that the user mentions. (But again, post-install triggers in debconf for ufw on ubuntu for example already do this. It all depends on the packaging.)

But as the author points out, not everyone is keen on hitting the terminal, but that has been a problem (or rather a business opportunity) for long enough that there are solid, uncomplicated and perhaps way more convenient (and eco- friendly) ways to achieve what the author is thinking of accomplishing.

One thing that comes to mind is the amazing Synology products. In fact, they implement the exact vision of the author: Run your software on your NAS, and have a dynamic DNS graciously provided by synology to access it. E-mail server, file sharing, photos app, even photo recognition, and a plethora of other stuff. You can even run VMs or Docker on it ! And all within the synology appstore (with some magic nat traversal I presume because it does not need any port forwarding)

And that is just one example of something I've seen and witnessed to work very well and reliably too.

I guess what I'm saying is, the author's vision is shared amongst a lot of people and there may even be commercial solutions out there that implement it. But I would for sure love to see an open-source attempt. In fact, I think there's already one that I'm just not aware of.

</comment><comment><USER27> I'm trying to create EXACTLY this with my latest project ([https://www.aspen.cloud](https://www.aspen.cloud)) and it is challenging to find the right balance between ease of use and decentralization. The path we're taking is a service that you can pay for and we provide everything you need or you host it yourself. Because sometimes letting experts manage your system is more reliable and you can avoid getting the hug of death like this site!

The idea of owning your personal computer in the cloud with instant, always updating apps completely in your control seems inevitable but making something easy for anyone to use will take time. That's why we're focusing on the developer experience to make it simple and cheap to make apps in this new paradigm while shaping the experience for the end user so it does ultimately feel as simple as using the App Store.

<comment><USER28> Would you consider open sourcing it in the future? If not the hosted option not only competes with products such as GSuite but it 'll be hard to get adoption from the self hosted crowd.

<comment><USER27> That's the plan! We are building it in a way that you also means you don't have to decide to do just self-host or pay for the service. You could use both and have one as the failover. I.e. primarily use the hosted version but if you're internet goes out you are now working on your LAN to a computer you have in the other room.

</comment></comment></comment><comment><USER29> This seems more like the Urbit "personal server" idea than the cloud replacement for a phone I expected tbh

</comment><comment><USER30> So... VDI, but for Phones? VPI? Seems like a cool idea worth some effort to streamline.

These days, it's fairly inexpensive to get a home server, set up a VPN server, and run stuff like a web browser through RDP. Guacamole ([https://guacamole.apache.org/](https://guacamole.apache.org/)) makes desktop apps through a web browser even simpler.

Again, setting all this up is more than trivial, but I believe it's something that could be a "one-click app" for a VPS. See [https://marketplace.digitalocean.com/](https://marketplace.digitalocean.com/)

</comment><comment><USER31> Isn't this (pcc) urbit.org?

</comment><comment><USER28> I 've been using nextcloudpi on an rpi for 3 years to achieve most of what the author describes. It's been awesome and I d suggest people give it a try.

</comment><comment><USER32> I've been thinking about and working on the same problem for a while. My conclusion is that this has to be done with a physical device of some kind over which the user has physical control. Otherwise whoever provides the personal cloud servers ends up being the centralized lock-in element in the system.

</comment><comment><USER33> This is a neat idea.

Am I right in the inking that even if a big tech company did this it could still be good. Because they are just providing the 'device' like Apple do now. I guess they would still have power over what you could / could not install though.

</comment><comment><USER34> I get wanting to be serverless, but hosting the static parts using S3 and doing clever database things using Lambda and DynamoDB also achieves that goal, while surviving the hug of death.

<comment><USER8> Dynamo DB does not survive the hug of death unless configured to do so and can be very expensive if you don't design the data access pattern will.

The author is trying to stick to free tier, so if it's set to the max (5 records/sec), and no caching, it probably can only handle 1 visitor every 2 seconds after the bucket of 1500 read tokens is used up.

If it's doing scans at all, the DB will be shot in seconds.

Really need CloudFront in front of something like this to survive and lighten the DB access

</comment></comment><comment><USER35> Thought this was going to be more literally. A phone-virtual-machine, for stuff like your robot vacuum cleaner to keep it from infesting your real phone and spy on you.

</comment><comment><USER36> If apps on personal servers can't collect data, then they will need to charge money in order to have an economic incentive to support the app, ship updates, upgrade UI, etc. If there is a competing "free" option then from a centralized monolith, then it's going to be very difficult for the PCC app to deal with.

Paid apps are also inherently less viral and can't tap into network effects as well due to the friction resulting from payments. In order to overcome this, PCC apps need to develop a viable revenue model without putting a paywall.

I see the PCC model work for applications where neither the consumer and the business want to store sensitive data because the security overhead is too high.

E.g. trading bot that doesn't want to store user's API keys. In fact, running private servers is something that is pretty common in that world.

<comment><USER37> I'm not sure it's so limited.

First this is a great space for open source apps.

Second I think people in general are becoming more aware that free online stuff usually comes with a hidden cost to privacy.

Third there is a whole swath of online services that can't thrive in current situation: services that are too uninteresting (from a data harvesting pov or no tie-in to larger offering) to run for free, and not valuable enough for the user to pay $7/month for, and not worth running as a SaaS at a lower price. Yet if a user had a cloud OS with metered resources, they could run such an app for a few bucks a year (plus a few bucks donation/paid to the app dev). And they'd never have to worry about it shutting down because the dev wants to do something else with their lives.

</comment></comment><comment><USER38> But is there an alternative to iCloud backup or to photostream/photos? Even Dropbox does not backup my photos unless I run it and wait.

</comment><comment><USER39> Isn't [https://solidproject.org](https://solidproject.org) going in that direction?

<comment><USER40> Solid worries me because the apps don't run on your server. That means Solid apps can do all kinds of bad things and your only recourse is to stop using it (if you even know about the badness). For the same reason, Solid's privacy expectations aren't really enforceable; apps could mine your data and you'd have no way of knowing and they could cache your data even after you withdraw permission.

<comment><USER39> That's indeed a worst case scenario, but you know (an grant permission to) which data the apps have access to

</comment></comment></comment><comment><USER41> Demand for this article is outstripping server.

</comment><comment><USER42> Wouldn't my server have to run on ARM in this case.

</comment><comment><USER43> welp ddos'd by apparent popularity!

</comment><comment><USER44> So, a virtual desktop in the cloud? That's new

<comment><USER45> Check the Hacker News Guidelines, particularly "please don't post shallow dismissals". I definitely think the blog author is onto something. This is not just a virtual desktop, this is a VPS but "administered" like any regular smartphone. Such a thing doesn't exist yet, while all the parts are there.</comment></comment>


Acunote (YC W11) Takes On Project Management With A Gmail-Like Interface - <AUTHOR> http://techcrunch.com/2012/07/02/acunote-yc-alum-takes-on-project-management-with-a-real-time-gmail-like-interface/ <comment><USER2> I'm playing around with it, and it seems similar to our current solution, <http://www.liquidplanner.com/>

I wonder if there's a compare/contrast between the features/capabilities of LiquidPlanner, Acunote, and others.

EDIT after downvotes: I was being diplomatic, out of respect for anybody who ships in general, and any YC company in particular. However, since I'm now feeling less charitable, let me be less diplomatic. The features of this app are a subset of LiquidPlanner. I see no features that it does not have, and considerably less polish. I would say this is a good start, but they have a long way to go.

<comment><AUTHOR> I haven't done a serious competitive evaluation of Liquid Planner so I would hesitate to offer an opinion about them. Much like with a new source control system it take 1-2 solid day to get a feel for a system like this, and your understanding stays primitive until you talk to real customers.

I can tell you that talking to our customers, some of whom evaluated 50 alternatives (no joke) at the end it all comes to:

      * being fast
      * easy to use
      * scalable

I know it sound undifferentiated, but the reality is that while everybody claims all of these, few products do any of this well.

I'll give you one example. We have keyboard shortcuts for just about every operation in Acunote. For many power users this is really important, as lets them do a lot of stuff rapidly. It's a qualitative difference when you can work at the speed of though.

From the engineering and feature point of view that's like 5% of the product, but that's what matters to customers, so that's what makes sense to talk about. Having said that, Acunote does offer a ton more, but we do it based on a few powerful orthogonal primitives, so we don't have to come up with a new button for every kind of need as it leads to unusable interfaces. This lets us serve large customers with complex needs while remaining highly usable and approachable for smaller groups.

One thing we should offer is better training, screencasts, tutorial on getting started. That's definitely something we are working on.

Please shoot an email to our support. We'd love to discuss this further with you.

</comment></comment><comment><USER3> We've been using Acunote for almost a year, and love it. I highly recommend checking it out if you haven't done so already. Congrats!

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER4> I've been a big big Acunote enthusiast for a long time. I recommend it to everyone -- they're an incredibly sharp and responsive team.

It's essentially a hacker-friendly task management system. I have trained all my engineers to use it pretty efficiently -- if people are interested in seeing how I use it, I will think about putting up some videos of how efficiently I use it.

<comment><AUTHOR> Thanks! It would be awesome to see the videos, we've had customers ask for this actually.

</comment></comment><comment><USER5> Wonder where they got their pricing page design from:

<http://www.acunote.com/plans-and-prices>

<http://highrisehq.com/signup>

<comment><USER6> Also like every other site out there. It's the most generic way to showcase pricing and plans.

<comment><USER7> while it might seem like a reasonable response, it's just not true. I don't see anything wrong with making the pricing page similar to 37signals, but it's not the case that this is "like every other site out there"

<comment><USER6> Tons and tons of sites use the 3-4 column approach to showcasing plans and pricing Here are just a few: <http://patterntap.com/search/pricing>

In terms of styling, you're right, it's very close to 37signals.

</comment></comment></comment></comment><comment><USER8> Wow, this looks awesome -- I was actually looking for something exactly like this recently, and was worried I'd be stuck using mac-only software.

Would be interesting to learn about your security.

<comment><AUTHOR> We should chat about that. We take it super seriously. Would love your feedback.

</comment></comment><comment><USER9> We've been using Acunote for almost three years. How is this a "launch"?

</comment><comment><USER10> I came here to comment about the how the proj. mgmt. problem has been solved in numerous ways by several companies. How could there by anything left to do?! And yet there are raving fans of this product right here. I guess there's a hundred different niches within the project management domain.

<comment><AUTHOR> Right, project management software has a ton of niches, and it is also much harder than it seems. It hasn't happened yet, but much expectation is that somebody will be able to consolidate a big chunk of this space. We count on that being us :-)

</comment></comment><comment><USER11> Been using it for a long time. Great product. Going to be using it to manage contractors building my house too

<comment><USER12> Would be curious how contractors respond to using Acunote. You may need to explain to them that tasks are like a punchlist.

</comment></comment><comment><USER13> Just signed up, since I was looking around for a Basecamp alternative. First impression is that Acunote is more user friendly and faster. Also, thank you for creating a plan for Indie developers. Are you going to keep it free or will you start charging in the future? If you do, will you accept Paypal?

<comment><AUTHOR> If anybody says they can predict the future, they are lying. So I can only that we've never charged small teams and right now we have no plans to start. We accept VISA/MC/AMEX (and standard enterprise billing terms for large customers).

</comment></comment><comment><USER14> how is this different/better than asana?

<comment><AUTHOR> I think Asana is a solid product. Their long-term vision seems similar to ours - new category of business software covering all employees who do project/task-oriented work (developers, operations, marketing, product management, legal, etc..), that individual contributors actually enjoy using.

Our strategy on how to get there is completely different. Unlike them we provide the vertical functionality individual groups (like software developers, product managers, IT, etc.) need in addition to common horizontal task management. And we expect to be best-of-breed in the verticals we cover.

One vertical they do cover much better than Acunote is personal productivity using GTD. We focus on groups.

For larger companies we also have a really strong focus on data-driven management - letting you manage the whole company using data not politics. I haven't seen Asana offer analytics, but that's probably just a question of time. It's a smart play to focus on getting basics just right first.

</comment></comment><comment><USER15> From <http://www.acunote.com/how-it-works>:

>Acunote integrates with your source control. We support Subversion, Perforce and __GitHub __.

That wording is rather poor as it makes it sound like github is a source control system rather than a hosting service.

"and git (via GitHub)" would be better.

</comment><comment><USER16> Are there any good free alternatives? I'm a student with a semester long group project on the horizon.

<comment><USER17> Try trello.com. Highly recommended.

</comment></comment><comment><USER18> What's interesting is that the R&D team is based on Ukraine. Atypical of YC companies that heavily based on SV.

</comment><comment><USER19> Just curious - are there any open source systems that are just as agile as this one?

<comment><USER15> Redmine is pretty nice and for small projects you can host it for free on an AWS micro instance (pretty easy to setup with something like bitnami). For open source projects JIRA is also free.

<comment><USER19> Interesting! Anything that uses .NET technologies? I'm only looking for something that is extremely simple.

<comment><USER15> I'm not familiar with anything .NET based that has similar functionality. Redmine was pretty easy to setup and configure. If you just want issues/roadmap/repo, that's probably what I would go with. If you're just looking for a fancy todo list you could try something like trello or workflowy (not open source, but free).

</comment></comment></comment></comment><comment><USER20> Any plans to add Bitbucket (git or hg) support?

<comment><AUTHOR> Yes!

</comment></comment><comment><USER21> _We have intentionally made the user interface similar to Gmail's_

Be ready for a flurry of patent lawsuits from google.</comment>


Code to 'stalkdaily' xss attack - <AUTHOR> http://gist.github.com/93782

<comment><USER2> This is as trivial as XSS attacks get. Third on the XSS cheat sheet: <http://ha.ckers.org/xss.html>

</comment><comment><USER3> That was the original (afaik) code. It was changed a few more times with randomUpdate containing different strings. The latest I saw before the url of the script changed was <http://mikeyylolz.uuuq.com/x.js> (404'd now)

</comment><comment><USER4> Goes to show how few attacks are currently performed on sites nowdays. Twitter survived all the fame, competition, and development without this happening until now</comment>


After New York Attack, Congress Wants TSA to Secure Amtrak, Buses - <AUTHOR> http://www.bloomberg.com/news/articles/2016-09-26/congress-wants-the-tsa-to-help-secure-amtrak-and-buses <comment><USER2> Oh, hell no. The last thing we need is more dumbshits, who couldn't hack it at McDonalds, groping people and clogging up the transportation networks. We need to shut the TSA down, not expand its scope.

<comment><USER3> I take the train a lot despite it taking longer and not being a good deal specifically to avoid dealing with the TSA. This would just keep me from traveling in general

<comment><USER4> Consider switching to a better country.

<comment><USER5> Consider the economic burden and complete lifestyle change to necessitate that.

<comment><USER6> Sneak, which country did you move to?

<comment><USER4> I have lived in Berlin since 2008.

Regardless of what laws are on the books of the respective countries, the state interferes in my day-to-day life vastly less in Germany than in the United States, and the interactions I do encounter are generally way, way less brain damaged than the idiocy perpetrated continuously by the TSA, idiot American cops, et al.

</comment></comment></comment></comment></comment></comment><comment><USER7> I don't understand how a TSA-like organization is going to secure ground transportation. To get total safety, you'd have to secure every grade crossing, bridge, bike-path-near-the-tracks, and so on. Any idiot can be texting and stall their car at a grade crossing and kill way more people than most terrorists dream of. Happens quite often. What are some security guards looking for drugs in your luggage going to do about it?

Air travel is nice because there is basically one area that needs to be secured; once the plane is in the air, there's not much you can do to it. (Modulo 9/11!) I don't think the TSA does much (any airport employee can smuggle whatever they want into the secure area), but at least the task is theoretically possible. And, with air travel, the risks are higher; you can hijack the plane and use it as a missile. Trains run on tracks, so there is really no way the thing can take out the World Trade Center.

Anyway, this pattern of money grabs after botched terrorist attacks is depressing and distracts us from the real problems in New York City. Kids die every week walking to school because of people not driving carefully. Actual deaths. Kids. How do we react? By not filing charges, and by removing traffic calming devices because they interfere with parades. ([http://gothamist.com/2016/08/29/nypd_safety_west_indian_para...](http://gothamist.com/2016/08/29/nypd_safety_west_indian_parade.php)) Are we going to address real problems, or are we going to waste our limited money on things that simply don't happen because the possibility scares us?

<comment><USER8> > Any idiot can be texting and stall their car at a grade crossing and kill > way more people than most terrorists dream of

how? other than the vehicle instantly exploding on impact, the only thing that's happening to the passengers is a small bump.

<comment><USER9> [https://en.wikipedia.org/wiki/Valhalla_train_crash](https://en.wikipedia.org/wiki/Valhalla_train_crash)

<comment><USER10> Note that this was quite unusual:

> Since grade-crossing accidents typically do not lead to fatalities on board > the train, investigators from the National Transportation Safety Board > (NTSB) were particularly interested in determining why the fatalities > occurred.

</comment></comment></comment></comment><comment><USER11> I think this story buries the lede - it is pretty clear that this is not about creating TSA checkpoints at train stations and bus depots:

 _" A bipartisan bill introduced Thursday by Senator John Thune (R-S.D.) would require the TSA to use a risk-based security model for these transport modes and to budget money based on those risks. It would require a wider use of the agency's terrorist watch list by train operators and more detailed passenger manifests along with tighter screening of marine employees. The legislation also would increase the TSA's canine use by as many as 70 dog-handler teams for surface transportation."_

 _" Lest you begin hyperventilating, it's virtually impossible to envision airport-style screening detectors or security queues snaked around America's train and bus passenger depots. "This is very much not creating for bus or rail transportation the [security] model that exists for aviation," said Frederick Hill, a spokesman for the Senate Committee on Commerce, Science, and Transportation, which Thune chairs."_

<comment><USER12> But there already are security queues snaking around train stations?!

EDIT: Philadelphia: [http://travelswithtarc.com/wp- content/uploads/2016/05/DSC013...](http://travelswithtarc.com/wp- content/uploads/2016/05/DSC01363-1024x576.jpg)

<comment><USER13> That's not a security checkpoint though, they're just waiting to board the train when it arrives.

</comment></comment></comment><comment><USER14> Protip:

If you want to "opt out" without opting out, simply tell the TSA that you can't lift your arms above your head. They'll let you bypass the scanner - sometimes even the metal detector - and swab your hands.. and you're done. I've done it 20+ times in the last year. If they ever ask why, I say "it's a college basketball injury." I'm a 5'8" (1.72m).

And if you get really brave, you can try my thing "I can't lift my arms like this" while lifting my arms.

I have yet to be called on it.

<comment><USER15> I have been Opting Out since the backscatter machines were used and they were "safe". What a boondoggle, wasted $800mm on those. The only downside is traveling with friends & family you get a few jokes cracked at your expense, but that never bothers me. Most agents I talk with acknowledge that its security theatre, only once is a while do you get an agent who thinks they will be the next rambo and having that extra .5oz of liquid over the limit in your bag is a threat to national security and treats you as such.

<comment><USER14> When I travel with friends of family, I encourage them to not acknowledge me for a few minutes and then turn opting out into a fun experience for everyone! Except the TSA. ;)

</comment></comment></comment><comment><USER16> Money money money moooooney... MONEY. There's nothing else that could inspire the sheer balls for an organization with such a crushing track record of failure (95% last tested, right?) to imagine that this is a good idea.

</comment><comment><USER17> If congress and their staff were forced to go through the same process as everyone else (and not through a VIP precheck line) they might realize what a clusterfuck it has become.

Last flight I had some water left in my bag which I realized just before going through the security scanner. So instead of letting it go to waste, I thought it'd be best to quickly drink it. But I was stopped by a TSA agent saying it's a security risk and I'd need to either leave or give him the bottle clear bottle of water.

He had nonchalantly took it, he had no doubt it was plain water and threw it in a trash container full of other bottles. Kind of ridiculous, if they really thought a clear liquid was a liquid bomb or something, why would they give me the option of leaving it with it? And how could it possible be a bigger security risk for me to ingest it, than give it to them to put in the open

While it's not like it ruined my day, it's certainly enough to convince me the whole thing is a joke.

<comment><USER18> Well, if TSA checks through diapers of babies just in case - you know - you as a parent might have put a bomb there, why not swallowing some sort of magical liquid that let you live for next 45 minutes, and explode/destroy aircraft once you get aboard and in the air?

/s

[https://www.youtube.com/watch?v=h-uKemWVFeY](https://www.youtube.com/watch?v=h-uKemWVFeY)

</comment></comment><comment><USER19> The thing to remember here is that we gave up some of our liberties at the airport because airplanes were demonstrated to be credible weapons for attacking any location in the nation.

Trains and buses (to a lesser degree) do not share that attack vector. Trains ride on externally-controlled rails, and often depend on externally-provided power. Buses are slow, depend on roadways to reach any targets, and don't really offer any novel attack vectors vs. trucks.

<comment><USER20> Not only that, but the TSA was created because there was a threat, and not because the TSA provided any actual defense against that threat.

Major difference between intent and outcome.

</comment></comment><comment><USER21> Federal money is a gravy train for contractors. They lobby congress to get it. The New York attack is a benefit for them, sadly.

<comment><USER22> (become a contractor)

</comment></comment><comment><USER23> Can we just have martial law with curfew, checkpoints, and papers already? I don't know about you but having no rights would make me feel so much safer.

<comment><USER24> People are easier to control when they think they have rights to begin with and imagine the government is legally subordinate to their power.

</comment></comment><comment><USER25> It boggles my mind how certain countries are becoming safer day by day, yet people feel compelled to vote for pervasive surveillance and control. I think it is a mental disorder, a complete disconnect from reality, bordering on schizophrenia.

<comment><USER26> I call them scared little bunny rabbits. People freaked out over a statistical 0.0% increase in the _local_ population let alone nationally, for refugees coming into the country. And these people are all, "no they're dangerous, they're not vetted, we're being stupid..." And when I say, "no we're being generous, because we can be and should be." And these types just cock their heads and frown. Yep, scared little bunny rabbits. Life contains dangers, there is no life guarantee, but so many people are scared of bullshit. Go put some sunblock on, or stop smoking, or something useful.

</comment></comment><comment><USER27> The country is simply too large to physically secure everything.

We'd have to become a police state to even begin to protect every potentially sensitive area. You can kill people with almost everything and it is infeasible to prevent it altogether by force of arms.

</comment><comment><USER28> Why does anything need to change? This is another in a long line of ineffective terrorist attacks, and if anything strengthens the case for keeping on as usual (if you want to argue that security at the best targets is already so good that people are resorting to random dumpsters). No one died and as far as I can tell no one even has serious injuries.

</comment><comment><USER29> Next up, TSA at your local interstate Toll booth. If you have EZ-Pass or similar, then you will automatically be enrolled into TSA - Precheck.

This is needs to stop. Contact your representatives and tell them hell no.

</comment><comment><USER30> I remember when they wanted TSA to grope children at high school proms.

</comment><comment><USER31> Next up - TSA securing entrances to your own buildings.

</comment><comment><USER32> Meanwhile I accidentally left a switchblade in my bag and still managed to get through airport security twice.

<comment><USER33> As in an automatic knife? If so, you might be lucky. Those aren't just forbidden on airplanes, they're illegal in many jurisdictions.

<comment><USER34> Holy crap, you're right.

The US Switchblade Knife Act of 1958 prohibits the import or interstate commerce of switchblades. Plus a bunch of state laws about possession and carry.

Add a button to a knife, and _now_ it's dangerous.

<comment><USER35> Note that almost all knives people consider to be switchblades are actually "assisted open" knives instead.

The law very specifically requires a switchblade be opened by pressing a button on the handle. (They're generally implemented by a spring pushing on the blade and a catch released by the button). An assisted open knife has you start opening the knife by applying pressure to a stud on the /blade/ which causes a spring which had been holding it closed to continue opening it instead. These do not meet the definition of "switchblade" and are not illegal in most jurisdictions.

</comment></comment></comment></comment><comment><USER36> Bullshit that doesn't help anyone but the govt and terrorists ruining society

</comment><comment><USER37> Uggghhhh

</comment><comment><USER38> Because they're doing such a good job at the airports ...

</comment><comment><USER39> Explanation: only a few congressional districts have airports, but a lot more have bus stops & train stations. TSA are the kind of shitty patronage jobs that appeal to them.

<comment><USER40> It's not really a "patronage" job. Nobody gets their TSA gig because they know a member of Congress.

<comment><USER41> It's the opposite way around. People that have cushy government jobs support members of Congress that maintain those jobs.

</comment></comment></comment><comment><USER42> Who is this "congress" I keep hearing about? It sounds like they have a lot of power.

</comment><comment><USER43> One more reason never to take public transport.

</comment><comment><USER44> Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon.

<comment><USER45> Further expansion of the TSA seems a pretty universal nightmare to me. Maybe it's a bit out of place here, I'm not sure - their presence at train and bus stations wouldn't be a "new phenomenon" though[1]. I do think the TSA/DHS et al encourage unhealthy forms of paranoia[2], and my own experience with them warrants loathing. They've also hard-earned a pretty bad reputation, which doesn't exactly merit additional responsibilities.

1\. [http://www.nytimes.com/2013/08/06/us/tsa-expands-duties- beyo...](http://www.nytimes.com/2013/08/06/us/tsa-expands-duties-beyond- airport-security.html?_r=0) 2\. [https://www.washingtonpost.com/news/rampage/wp/2016/05/07/iv...](https://www.washingtonpost.com/news/rampage/wp/2016/05/07/ivy- league-economist-interrogated-for-doing-math-on-american-airlines-flight/)</comment></comment>


Fuck Off As A Service - <AUTHOR> http://foaas.herokuapp.com/

<comment><USER2> _Roadmap: Internationalization based on Accept-Language._

Ironically, if this could be done for certian languages for which there is no simple analogue for "fuck off" (ex: Japanese, where you need an arsenal of slang to suit the various occasions), it would be of great service to mankind.

</comment><comment><USER3> /linus/:name/:from

Will return content of the form ':name, there aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap. - :from'

<comment><USER4> It appears to do this now, albeit brokenly.

<comment><USER3> Sweet!

> albeit brokenly

WE DO NOT BREAK USERSPACE!

</comment></comment></comment><comment><USER5> And for extra effect, you can also include your own blink tag or javascript : [http://foaas.herokuapp.com/donut/bob%3Cscript%3EsetTimeout%2...](http://foaas.herokuapp.com/donut/bob%3Cscript%3EsetTimeout%28function%28%29%7Balert%28%22no,%20really%22%29;%7D,2000%29;%3C%2Fscript%3E/zumth)

<comment><USER6> Doesn't this mean you can do any kind of cross-site scripting? Like redirect to goatse.cx?

</comment></comment><comment><USER7> That's not the first service of such kind: see [http://natribu.org/en/](http://natribu.org/en/) (lacks an API however :-)

</comment><comment><USER8> I wonder if there will be as many comments as usual complaining about any type of profanity.

<comment><USER9> Well, if there are, you will now have a service to tell them. I think it's the /off/:name/:from method.

</comment></comment><comment><USER10> Nice one! creative use of technology and gives a vent to instant frustrations..bravo!

</comment><comment><USER11> Very useful, I think I'll implement this inside of an exception handler :)

</comment><comment><USER12> how good is the enterprise tech support for this api?

</comment><comment><USER13> Technology serves people! Nice joke :)

</comment><comment><USER14> Solid documentation.

</comment><comment><USER15> is this on github ?</comment>


Kevin Rose on the future of Milk - <AUTHOR> http://tech.fortune.cnn.com/2011/04/12/the-ruthless-digg-milk-founder-kevin-rose/

<comment><USER2> The following made me chuckle:

In techspeak, "pivot" is really a euphemism for "Our idea failed, but we have way too much venture and emotional capital invested in this thing to bail in a heap of embarrassment, so instead let's totally reinvent what we thought would be our life's work."

<comment><USER3> And the article's footer is pretty good too. "This is the second installment of Fortune's new column on startups and the tech bubble that may or may not exist."

</comment></comment><comment><USER4> So, Milk Inc. won't be doing any A/B testing? Sounds like from the example of "Peeka" that they just decided to kill it because of some early negative reaction.

The whole thing seems odd to me. Why would a productless company be doing this much press, which has centered around the strategy of killing projects early? It must be helping to attract investors. I can't think of a worse message to send to potential users though.

</comment><comment><USER5> I thought it interesting that the KIIP founders were from digg... I wonder what their thoughts are about Kevin. There were some not-so-nice things said about him previously from some of the net eng team at digg.

What I am interested in, is these guys that founded KIIP and raised ~$4MM, would they work with kevin again, would he/did he in any way advise them? Do they respect him?

This article is BS, it would seem to me given what this article states is that MILK is a PR firm. A Kevin Rose Promotion company.

MILK may stand for MANY IDEAS LIKELY KILLED -- as he seems to be fond of the idea of killing ideas, rather than making them.

Further, everything I read in that article was yesterday and reactionary. To ponder badging and IRL couponing when the market is littered with companies doing that suggests that there is no profound technovisionary there.

A me too with money, a little lab used to promote a bunch of experiments much the way a trust fund kids dabbles in various professions before realizing the only thing hes really good at is partying, womanizing and spending money.</comment>


Microsoft Open Sources .NET, Saying It Will Run on Linux and Mac - <AUTHOR> http://www.wired.com/2014/11/microsoft-open-sources-net-says-will-run-linux-mac/?mbid=social_twitter

<comment><USER2> never thought I would see this happening...

</comment><comment><USER3> 218 points and just 1 comment?</comment>


Ordinary Skill in the Art (2001) - <AUTHOR> http://infolab.stanford.edu/~ullman/pub/focs00.html <comment><USER2> Slightly off topic - can anyone explain why a patent, which often involves a great deal of research expenditure and is vetted through a long and expensive process, is granted for 20 years, but copyright, which covers almost any form of creative expression and is granted automatically with virtually no minimum standard, lasts for the lifetime of the author plus 70 years?

<comment><USER3> From my intro-college-course understanding...

The problems they're solving are different. Patents exist to incentivize people to create new technology. If there were no patents, it's hard to justify spending lots of time and energy on new technology -- it'll just get stolen. So, the deal is that if you invent something, you get solid industrial use out of it (20 years sounds look enough to build a career), and in return, you publish comprehensive documentation about it. Contributing your knowledge to society is part of the deal.

Copyright is different. Copyrights are granted to unique, creative works -- art, that holds no value other than the value in the thing itself. There, there's nothing that would otherwise need to be hidden and protected to get use of the art. So, no need to publish docs, since you're exposing the whole thing when you disseminate anyway. But, it may be your life work, or something like that. So, you get protection from people ripping you off for your lifetime, plus long enough for people to forget about your person, leaving only the work.

Long story short, they're different processes with different societal impacts, so they get fundamentally different protections.

<comment><USER4> A very reasonable argument.

However, pragmatically, the real reason is that the driving force behind copyright law in the United States (and therefore in much of the world) is the Walt Disney Corporation, which has decided that it will use the full force of its political weight to ensure that no work featuring Mickey Mouse ever enters the public domain. This currently requires that the length of copyright be 70 years. However, since Steamboat Willy would under these terms become public domain in 2023, I would be willing to bet that we'll see some changes to copyright law around 2022.

Disney has no such interest in patents and, as a result, no reason to lobby for the extension of their terms.

</comment></comment></comment><comment><USER5> > _is the question of what happens if the 100 people come up with 10 or 100 > different solutions, all or most of which are at least as good as the > patented idea, and yet few if any are exactly that idea_ //

If none of them were exactly the idea, and the skilled practitioners were tasked to present solutions that required no novel development only that which constituted the state of the art at the time, then the solution would be non- obvious.

Indeed the presence of many other possible solutions makes any one solution less obvious as _the_ choice. There's a secondary effect that if the many solutions are equally good then they'll all be of little value whilst if the patent covers the one solution of the many that turns out to be greatly superior then it will have a much higher value.

Moreover on the subject of obviousness I always felt that should a patentee or their agent push the argument to it's logical end that "if it's obvious then why has no one already done it" appears to be an almost watertight argument.

To recapitulate, if it were obvious then others would have done it, if it were obvious and valuable it would be recorded (or patented) - in such case then a novelty citation should be available. If the subject of the application were obvious but of little value, ergo no patent had been applied for, then there would be little reason to continue to grant and little reason for a patent office to refuse and moreover little reason for a patentee to pay renewal costs. The result then is that if there is no novelty citation the patent office has no case [to push obviousness] or reason to practically pursue such a case. YMMV.

I just skimmed the second half but:

> _I'd love to see public review of patents before they are granted._ //

This is why there is early publication. Practitioners have chance to file observations before USPTO or UKIPO or who ever before grant that the examiner can take in to account. In short there already is public review. Many many times there's been a story on Slashdot with commenters aghast at what the USPTO are granting now the kerfuffle has been over an A-publication and then usually the scope has been assumed to be only limited to the title (rather than the claims).</comment>


Here Is Why You Probably Paid Too Much on Your Last Flight - <AUTHOR> http://www.buzzfeed.com/maximiliani/here-is-why-you-probably-paid-too-much-on-your-las-1pn2k <comment><USER2> Good lord, please don't share Buzzfeed tripe here. This is blatant advertising barely disguised as content.</comment>


Screen Dependency Disorder Is Real, and It Damages Your Child's Brain - <AUTHOR> https://www.momjunction.com/articles/screen-dependency-disorder-is-real-and-it-damages-your-childs-brain_00442190 <comment><USER2> For most values of "real", no, it's not.</comment>


There is no longer any such thing as Computer Security - <AUTHOR> https://blog.codinghorror.com/there-is-no-longer-any-such-thing-as-computer-security/ <comment><USER2> Working in this space, I'm convinced that email will eventually evolve from a default "blacklist" model to "whitelist" in the next 3-5 years.

There's simply too many bad actors and too many uneducated or uninterested end-users.

Microsoft is developing an interim step for this now ('Composite Auth') as part of Office 365 ATP: [https://docs.microsoft.com/en- us/office365/securitycomplianc...](https://docs.microsoft.com/en- us/office365/securitycompliance/anti-spoofing-protection)

I hope it helps, at least in the Enterprise space, because I'm tired of playing 'Whack-A-Mole' with business communications.</comment>


How to Create JDBC Driver over Rest APIs - <AUTHOR> https://firstname.lastname@example.com/how-to-create-a-jdbc-driver-over-rest-apis-1571ab156e6a <comment><USER2> Currently, I would use a FDW (Foreign Data Wrapper) [1][2] to do represent a REST API as database tables (Multicorn [3] is awesome). That is, of course, Postgres-specific.

I'm bookmarking this in case I want to do something similar, but Java- specific.

As a note, if you find writing FDWs in C or Python easier than writing Java, you could use the FDW and then access it via a generic Postgres JDBC driver. It's great to have choices!

[1] [https://www.postgresql.org/docs/11/postgres- fdw.html](https://www.postgresql.org/docs/11/postgres-fdw.html)

[2] [https://wiki.postgresql.org/wiki/Foreign_data_wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers)

[3] [https://multicorn.org](https://multicorn.org)

</comment><comment><USER3> [https://www.transposit.com/](https://www.transposit.com/) is a pretty interesting company making it possible to define SQL on top of REST APIs</comment>