Principled GraphQL - <AUTHOR> http://www.principledgraphql.com <comment><USER2> The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world.

At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for things like dispute dashboards was considerably more complicated compared to an abstraction that made sense for the clients (apps and website).

If we only had one graph, all the clients developers would have to develop around a data model that was far more unwieldy than they needed. But with two graphs, the world was a lot simpler (at the cost of having to maintain two graphs).

<comment><USER3> The RDF world has conclusively proven that there is more than "One Graph". (e.g. people try to make "One Graph" and their projects die; try to make as many graphs as there are points of view and the sailing is smooth)

<comment><USER2> In the case of GraphQL, I'd be interested in seeing strategies for multiple graphs within a single codebase. Essentially being able to produce different schemas based on config. I know that superficially it's as simple as some "if" statements, but I'm curious about the maintenance/scalability side of it.

<comment><USER3> How about having N base graphs and the ability to make unions of the graphs, as well as other kinds of algebra.

It is relatively easy to do this in the RDF world since the graph is composed of individual facts which may or may not be in a particular graph.

<comment><USER4> Which triplestore are you using that gives great front-end performance at load?

<comment><USER3> None of them are really "great". I get acceptable results with OpenLink Virtuoso if I give it a lot of RAM, tweak the configuration, and baby it when needed.

</comment></comment></comment></comment></comment></comment><comment><USER5> I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected.

I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing some enormous value by naively just using GraphGL without involving Apollo?

That is a sincere question. What is the deal here?

<comment><USER6> It's called marketing and they're pretty good at it. They do provide some useful tools however if you want to use them and don't just blindly follow the docs (which are selling you on things you may/may not need).

<comment><USER7> Apollo's marketing game has been ridiculously on point. They are the only GraphQL client in the ecosystem that is fully compatible with any GraphQL compliant server [0]. And since it is pretty good, whenever one has to talk/market/propose anything about GraphQL in the community, they end up cross-marketing for Apollo.

[0] Relay has its own spec and can be used only if the server supports it. Other GraphQL clients are either not well maintained or do not support as many features as Apollo does (caching, subscriptions are two features that come to mind)

<comment><USER2> FWIW: You don't have to follow any of the Relay spec to use Relay. Though you'll lose many of the benefits if you don't at least use globally unique 'id' fields on each major type. Connections are optional, the node interface is optional.

</comment></comment></comment></comment><comment><USER8> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.

I see it's advantages of having auto-documentation for each API. Thumbs up here.

Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and- server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn is not worth it.

<comment><USER9> > Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to > REST.

I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations.

If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.

<comment><USER10> "If you just want JSON over HTTP with some status codes"

yes this

Qualifier: have not been able to use graphql yet, and I'd still like to try it out at least before making and judgements

<comment><USER9> GraphQL costs a lot more to do, but also gives you a lot more.

Just some benefits we've seen:

\- Automatic codegen in the client removes a lot of boilerplate.

\- Verification of schemas in CI makes sure we don't "go backwards" on the API inadvertently.

\- Documentation tooling that makes it easy to show API structure.

\- Easy to generate schemas automatically from underlying data models in the backend service (database tables, ORM models, enums, etc).

\- Great type safety compared to JSON over HTTP.

</comment></comment></comment></comment><comment><USER11> I disagree with the notion of `One Graph`.

We have multiple "gateways" for multiple backend services.

We have our main application that has one graph and we have multiple internal applications each owns its own graph.

I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).

<comment><USER12> They advocate one graph, because it's too hard to merge graphs in parent-child (many-to-one, many-to-many) relationships (recursively) in a flexible way. This is purely because of technical limitation of GraphQL IMO.

<comment><USER13> An alternative architecture (following the BFF idea):

* Non-GraphQL services (speaking REST, gRPC, whatever) * GraphQL gateways, owned by frontend teams/applications.

E.g. each frontend team/application owns its own schema owned by these teams. They can compose the backend services however they wish—and whatever is the most natural representation for their domain.

<comment><AUTHOR> [author here]

Yup, we see this pattern a lot. You get the benefits of fewer bytes on the wire, typed APIs, elimination of data fetching code, etc.

But it leaves a lot on the table. The bigger wins come when new features can draw from all your data (in unanticipated combinations) without new API or services development, when you can make new data available for every team's use just by plugging it into the central graph, and when you have a birds-eye view of exactly how all your data is being used so you know where to make further investments.

<comment><USER13> Yeah, I'd also add that it is a huge help in ramping up new devs when understanding your schema.

</comment></comment></comment></comment></comment><comment><USER14> One question I have is with the "One Graph" idea. I get the principle, and it does seem like it would be nice. However, it's hard for me to imagine what this looks like in practice.

I haven't done anything with GraphQL in a few years. But when I did, we basically had several teams in a part of our organization (one of many in a huge giant megacorp) which built an API with GraphQL. We shared that code base and did the changes in it we needed for different parts of the graph. Sometimes it was fine, and sometimes it didn't go so well (unexpected issues, unexpected deployments when a team didn't prepare properly, etc). So it was an OK idea, but it caused some friction.

A decent of the problems were communication between teams of course. But even if communication was as good as one could imagine, it seems like this model would cumbersome at some point. And I can't imagine it spanning our entire organization, much less our entire megacorp across the board.

So assuming what we did wasn't good, what is a way you might make this work? Do you have a single code base like we did and just be more disciplined? Do you have a project whose job is to stitch together other schemas and pull in submodules? A monorepo for the entire company? Do you actually limit what the idea of the company is at some point to limit what the scope is that this should cover?

This turned out to be more of a ramble than anything. Oops.

<comment><AUTHOR> [author here]

> So assuming what we did wasn't good, what is a way you might make this work? > Do you have a single code base like we did and just be more disciplined? Do > you have a project whose job is to stitch together other schemas and pull in > submodules? A monorepo for the entire company? Do you actually limit what > the idea of the company is at some point to limit what the scope is that > this should cover?

I think these are great questions. One approach that looks promising is the idea of modular schemas that can be stitched together into a larger graph. Quite a few large organizations are doing this now. I recommend watching a recent talk by Martijn Walraven for more on this idea: [https://www.youtube.com/watch?v=OFT9bSv3aYA](https://www.youtube.com/watch?v=OFT9bSv3aYA)

<comment><USER15> We do this at Artsy in production too, here's an overview of how it works for us: [http://artsy.github.io/blog/2018/12/11/GraphQL- Stitching/](http://artsy.github.io/blog/2018/12/11/GraphQL-Stitching/)

</comment></comment></comment><comment><USER16> Summary: have one company graph, implemented as federated implementations from different teams, with a registry for tracking the (iteratively evolving) schema. Use per-client access permissions and structured logging, incrementally improving performance as usage grows. Data graph functionality should be a separate tier rather than baked into every service.

</comment><comment><USER17> We should probably add another point which is "you probably don't need Apollo tools".

I'm using GraphQL in production since 2015 and I feel like the only Apollo contribution to the ecosystem was pushing lot of marketing content around their hacky tools and "best practices", leading teams to poorly designed backends.

<comment><USER9> Yeah, I haven't seen a lot that has been particularly useful from Apollo so far.

They supposedly have a slightly different recommended way of doing the things Relay tries to do, but it's poorly documented and only compatible with Apollo, whereas the Relay spec is relatively clear (just the spec, I haven't used the Relay library).

Also they seem entirely JS focused. Our backend is Python and our frontend so far is Swift. They have no Python tooling, and their Swift codegen has a lot of issues, our iOS devs use it pretty reluctantly and replace a lot of parts of it, and even that tooling is all in JS, not Swift, which means our iOS builds suddenly need Node, Yarn, NPM, etc, a whole load more complexity, caching, and so on.

<comment><USER18> I'm currently working on building an open source library for building backend GraphQL APIs in Python. I'd love to hear your use cases! My email is in my profile, if you're interested.

</comment></comment></comment><comment><USER19> We've been working on doing something similar to create "one graph" at my job (though using our own library instead of graphql [1]).

There are definite difficulties to doing this, you need some strong cohesion between teams. If you try to do it in an agile manner, you're going to end up with a lot of duplication with minor differences. You'd need a way to flag existing similar data when trying to add new branches and nodes.

Our hope is to make our graph explorable and interactive so teams we don't have direct contact with, often in other countries, are able to find the data they would be interested in and see immediately how to read it out.

[1] [https://dwstech.github.io/muster/](https://dwstech.github.io/muster/)

</comment><comment><USER20> I think the single graph idea is impractical in any large organization. Every centralized model deteriorates over time due to many reasons: time pressure, carelessness and bigly varying competence levels in federated teams. A couple of years down the line everyone will hate it, and it'll be too big to discard.

Independent team structures and microservices based architectures are acknowledging that such monoliths are impossible to build and maintain.

<comment><USER21> The point of federating your schemas across different services is that you can achieve the single graph that represents the organization without having the separate parts step on teach other. It doesn't discard microservices, it embraces them.

</comment></comment><comment><USER22> There's nothing that says "we're really good at making front end development easier" like a website where even after I click into the main frame it completely fails to respond to up/down/pgup/pgdown ... I understand the whole "should work on mobile" thing but it should also bloody well work on a desktop too :(

<comment><AUTHOR> Thanks, looking into it. I agree and I hope we're able fix this. We're moving all of the Apollo docs to the same system. It's built on Gatsby, which uses GraphQL under the hood.

<comment><USER22> Cheers. I get really cranky about my keyboard not working (twitter's web UI manages to break it under a bunch of circumstances, which aggravates me at least once a week) but I'm well aware that there's always a billion things that need doing :)

</comment></comment></comment><comment><USER23> Single graph: Large companies often do not have a single graph. Different experiences and use cases require necessary variation in how teams surface data and do experimentation independently from other teams.

Federated implementation. Implementation being spread across many teams is important, but if that is through federated services being reused by multiple teams, it can create brittle dependencies.

Track schema in the registry: It's difficult to have a single source of truth when it is unable to display the variation based on #1 comment. I don't think anyone has solved this well for really large systems. Good principle but hard in practice!

I think it is really hard for a VC backed company selling a product to describe principles without being biased. This feels very biased toward selling their product.

</comment><comment><USER24> Principle 8 mentions "demand control", including "estimating the cost of a query before performing it". This is very much in line with GraphQL API Management work we are doing at IBM Research. I recently wrote about this: [https://www.ibm.com/blogs/research/2019/02/graphql-api- manag...](https://www.ibm.com/blogs/research/2019/02/graphql-api-management/)

I wonder about the other proposal for demand control, namely that untrusted users "should only send queries that have been preregistered by the authenticated developer of the app". To me, that seems to somewhat negate a great advantage of GraphQL, namely giving clients more flexibility in deciding (on the fly) what data to fetch/mutate.

</comment><comment><USER25> is graphql something anyone really needs unless they're facebook

<comment><USER26> While using GraphQL does have some benefits when dealing with a massive amount of users, that's not the reason most people choose to use it. GraphQL is simply a drastically different (and IMO better than REST) model for clients to talk to servers.

<comment><USER27> I don't think it is - mutations (and state management) are the biggest issue. It's ok for reads though, although even there tooling for rest is better.

<comment><USER18> > I don't think it is - mutations (and state management) are the biggest > issue.

How so? I don't think GraphQL mutations are any worse than their REST equivalents, especially once you get more complex than "update these fields on this entity".

</comment></comment></comment></comment><comment><USER28> Just wanted to throw out that this is cool amongst the critical feedback. Thanks Apollo and GraphQL for pushing the boundaries. It was fun using it when it was needed. Recently moved onto other pastures but solid progress!

</comment><comment><USER29> Anyone else's job have Cisco Umbrella flagging this page as possibly a malware distributor?

</comment><comment><USER30> I think the author doesn't understand what "principled" means.</comment>


Behind the scenes with the neuroscience of game design - <AUTHOR> https://www.polygon.com/2017/9/8/16263050/game-design-magic-tricks <comment><USER2> > Mechanics that straight-up give you the illusion of their existence are some > of my very favorites because they reveal, more than anything else, how much > we want to be fooled, and how little it matters what is real and what simply > feels real.

There is a quite different take on the same subject matter:

> Zizek suggests [...] that we neither believe nor disbelieve, but rather, > that we conditionally believe and allow ourselves to be emotionally affected > in the meantime. Far from mere escapism, this is in fact a highly > utilitarian method of self-realization. "We need the truth of a fiction," > Zizek concludes, "to enact that which we really are."

</comment><comment><USER3> The problem I see with this is that if the illusion is _ever_ shattered (because you make a jump you know you shouldn't have or vice versa), then not only is the effect lost, but likely the player will distrust the game and the satisfaction of accomplishment in the game is gone forever.

I like some games (eg Dark Souls) because I know that I can overcome challenges through my own perseverence and skill. If I ever feel that it wasn't my doing, then the game suddenly becomes completely worthless to me. The first time I battled the final boss in Dark Souls 3 DLC 2, I was playing on NG+2 and it took about a week of after work play to finally take him down. It was exillerating because I knew that I was a better player (at that fight, at least) at the end of the week than I was at the beginning. For example, I was able to dodge attacks with ease that at first I felt like they were un- dodgeable. What do you think will happen if I ever found out that the game became subtly easier over time and let me win, instead of my own skill improving? I'd feel cheated...

</comment><comment><USER4> I will say that the _Doom_ example -- where the last bit of health is counted as more as the rest of your health bar combined -- doesn't come as a surprise for me as I did feel that I could get away with just charging into the fray and dancing around all the enemies and my health bar would drop super quick but then somehow I was able to not lose that last bit of health as I'm charging through everything or running away from everything to find some brief cover before coming back in.

The game really wants you to charge and meleeing the weakened enemies to death (as a melee kill is the only way you will get health or ammo back, as it springs out of them), so they pretty much have to do something to help you make that otherwise suicidal charge.

Even knowing this, I don't care, I still think it gives you an awesome feeling. In fact now that I know this for a fact, I will probably get even more reckless in the game.

</comment><comment><USER5> I'm so happy not all games are like this, I abhor hidden or unfair mechanics. Even if you sometimes get one-shotted "out of the blue" in, say, Path of Exile, you can be sure game didn't "help" you, there is a crystal clear explanation of every mechanic in Wiki and your 90 lvl hardcore char IS your and your skill achievement.

<comment><USER6> Every game _mist_ do this, of course. Hitboxes are not (and can't be, and shouldn't be) perfectly accurate reflections of the target. Firing arcs are compressed down to the resolution of the game. Random chances aren't really random. Etc. what game designers realized long ago is that tuning these necessary approximations makes for a better game if 'more fun' is a stronger criteria than 'more accurate simulation of a usually-imaginary situation'. My usual example of this is critical hits in multiplayer games (I usually use WoW and D&D as examples, because they're well known). In D&D there is a chance that each attack is a critical success - an extra good hit. In the simplest versions, this is the 20 result on the 20-sided die, which means that roughly 5% of the time, on average, you get a critical. In WoW, crits do the same thing, but the rule is 'every so often', rather than '1 in 20 chance each try'. The designers of WoW understand that humans like these things to be "unpredictable but fair", so they have effectively a timer for crits; if you don't get a critical hit in a certain elapsed time, your chance goes up, until eventually it reaches certainty. This makes critical hits regular but. It predictable.

</comment></comment><comment><USER7> Just adding the word "neruoscience" does not make an article about neuroscience. This is deceptive use of the term.

<comment><USER8> One could almost say that it is a form of bait, that is trying to get someone to click on it.

</comment></comment><comment><USER9> You can exploit this in for example poker games that is rigged so that first time players will win.

<comment><USER10> Yes though I'd probably recommend exploiting this in games that are slightly less regulated if you enjoy being free from prison...</comment></comment>


Managing Styles with Sass on Heroku - <AUTHOR> http://avandamiri.com/2010/09/15/managing-styles-with-sass-on-heroku.html

<comment><USER2> Avand, your blog is really hard to read in Chrome, thanks to the shadow on all the regular text, which ends up appearing blurry. Firefox is actually significantly easier to read, though I'm still thinking you should drop the text shadow. Nice post otherwise, though!

</comment><comment><USER3> avand, one file in your code reads:

Dir.glob("#{Rails.root}/app/stylesheets/#{params[:package]}/ __/ _.css_ ") do |filename|

Don't you want to compile all SCSS files? Why ' _.css_ ' then? Also, wouldn't you have to exclude partials (_foo.scss)?

I had to add ':load_paths => %w(. ./app/stylesheets)' to the sass_options to get the @imports working. Did it work for you without that?</comment>


Show HN: Manage all your online profiles from one place - <AUTHOR> https://www.mypresences.com/ <comment><USER2> It's a landing page. Why does it need the loading animation? Even though it takes less then 2 seconds, it instantly put me off.

<comment><AUTHOR> Hi .. It is mainly there for slow connections and mobile devices. Will look at potentially not displaying it for a few seconds so fast loads will not see it.

<comment><USER3> Very nice. This is what I see [http://imgur.com/PypgE2q](http://imgur.com/PypgE2q)

Welcome to the Web 3.0

<comment><AUTHOR> Sorry to see that you got a blank page .. did it remain that way after a refresh? I have tried the page in many different browsers and never received a blank white page. I wonder if it could be related to the GNU browser you are using.

<comment><USER3> Sorry for the negative comment :). I think it's due to the addons IceCat ships with.

<comment><AUTHOR> no problem.</comment></comment></comment></comment></comment></comment>


Wayland anti-FUD - <AUTHOR> http://ppaalanen.blogspot.de/2012/05/wayland-anti-fud.html

<comment><USER2> I like the way he says "possible network layer".

It's the lack of network transparency which is the problem. No one's complaining about the overhead of it, because Wayland lacks this crucial feature.

Edit: Other features lacking in Wayland: A close button which works, consistent decoration across apps, efficient cut and paste, ... And things which Wayland has that are basically bugs: windows which are rotated at non-90 degree angles.

<comment> Tuna-Fish Remember the Unix philosophy? Something about small, well defined components doing a single thing well?

X violates it in every way possible. It has probably found a few ways of violating it that are _not_ possible, and done it anyway. Wayland is a part of moving back to the roots. It will lack at least 95% of all the features X has, because they really, really shouldn't be implemented as a part of a huge, monolithic system that has to run as root. Instead, all those features should be their own libraries/daemons.

As such, Wayland will never understand networks the way X does. Which is good, because it shouldn't. Wayland will never do anything put pass OGL handles between processes, and do the last few stages of compositing, and forward input. It actually has a well defined scope, unlike the amorphous blob that is X.

Nothing stops you from implementing a network transport layer _above_ Wayland. And somebody will. And since there is room for competing implementations, in less than two years, there will be _better_ network display protocols than what X does. When you split huge, monolithic things into smaller parts with clearly defined interfaces between them, the parts themselves become easier to make.

 _> Other features lacking in Wayland:_

 _\- A close button which works_

This is trivial. Just don't draw the close button with the application. Personally, I want my "close program" in a static place on the screen, so that's not a problem at all. If you want close buttons above windows, make the window manager put a small box it owns in the upper corner.

 _\- consistent decoration across apps_

When is the last time you tried to run apps from different toolkits on the same desktop? Notice that they look the same _because it's implemented in the toolkit_? X doesn't have consistent decorations across apps, and hasn't had them for a decade.

 _\- efficient cut and paste_

Why, oh why should that be part of the display server? Just why? Do you just want to pile all the features in the system into one big ball? And as for efficient, just how often do you cut and paste anyway?

Wayland lacks feature X is not a valid criticism against Wayland. Because that does not mean that a system using Wayland lacks feature X. And the primary feature of Wayland is that it implements as few features as possible.

<comment><USER3> Have there ever been any successful cases of a UNIX philosophy window system which could be used to back up the _"really shouldn't be implemented as a part of a huge, monolithic system"_ thing?

In most circumstances I'm totally cool with accepting the superiority of the UNIX philosophy as an axiom, but I don't think I am in this particular case.

<comment><USER4> plan9's rio is very unixy, and quite "successful" at what it does.

<comment><USER3> I was thinking more along the lines of: do Windows or Mac OSX do it in a more unix-y way than X?

When it comes to "GUI stuff" I am a consumer. I don't care about better software engineering practices in my windowing system unless that means the experience will be better for me. So far I am not seeing that offered by Wayland, _nor_ am I seeing any real evidence that better engineering _would or could_ offer me a better experience. If this were still 1995 and battling X was still something I did then I'd be less inclined to ask for evidence, but these days X is simply something I only know that I use because it _used to be_ a hassle. I haven't had to know about it for years, which I think is the way Windows and OSX work for their users.

<comment> Tuna-Fish The advantages of a more unixy display system are all indirect. Right now, working on that side is pretty arcane. Wayland will make it much simpler, so that cool ideas and new innovations will get turned into reality faster.

The only direct advantage Wayland will bring is a flicker-free and tear-free desktop.

<comment><USER3> I'm under the impression that flicker-free/tear-free are features that KVM brings to Wayland and that X already has if you use KVM drivers. Is that not the case?

<comment><USER5> Do you really mean Kernel Virtual Machine or did you mean Kernel Mode Setting?

<comment><USER3> Ah sorry, KMS. Been working with KVM too much recently ;)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Whoa wait, we are really supposed to replace X with something that only works on Linux? Way to give BSD guys the middle finger.

<comment><USER7> Or the BSD guys can implement the required infrastructure and bring their kernels to the modern era, instead of requiring userspace programs to hack around their lack of features. The only people giving the BSD guys the finger is themselves.

<comment><USER8> The problem is that the only documentation for the "required infrastructure" is the Linux source itself which is constantly changing.

<comment><USER9> I doubt that the BSD infrastructure has to match the Linux infrastructure exactly for the Wayland protocol to work on it. Mostly what it has to do is mode-setting in the kernel, enable sharing of graphics buffers between processes, and allowing libkms and mesa to work on top of it. The exact kernel api shouldn't matter for most applications.</comment></comment></comment></comment>


Anti-patterns and malpractices in modern software development (2015) - barry-cotter https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877 <comment><AUTHOR> The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don't complain about business constraints and they put out stellar work.

"business people" most often do understand what makes the money flow through their company (and into engineers' bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don't understand the technical details of an engineer's work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It's not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.

(fwiw I'm a director-level engineer so I'm technical but bordering on being a "business person")

<comment><USER2> In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.

<comment><USER3> I have worked in team where programmers constantly questioned business requirement - without having any understanding of business.

Eventually customer got tired of having to defend how many statuses he wanted in combobox or what process their company want to use.

By that I want to say, there is definitely such a thing as programmer not willing to consider business point of view for a second and thus being impossible to work with.

<comment><USER4> Sometimes it's hard to understand the business. I see this happen when developers are considered fungible resources to implement a spec. If their only visibility into the business problem is through a proposed solution, then yeah, questions about how many statuses are supposed to be in the combobox are to be expected.

<comment><USER3> It was not issue of ambiguity. Specification was clear. It was issue of programmer assuming that customer is wrong all the time and basically wanting the customer wrong. The statuses were right, but the programmer fought to merge few of them into one, because it looked "simpler" to him.

By questioning in don't mean having honest questions nor trying to understand, but being convinced that there must be mistake and forcing customer to defend every tiny choice.

And sometimes the customer wants radiobox instead of combobox are just wants to have it without having to spend 20min on meting to defend the choice.

<comment><USER5> On the other side I've had customers ask for things that _are_ impossible or against best practices and their own interests.

For example, password requirements. Many companies are not aware of the latest best practices and guidelines and request that we block browsers from generating or remembering passwords in password fields. Or they give us a list of draconian password requirements that are clearly debunked by the latest guidelines.

Or they ask us to basically break the HTML spec.

Like I tell my four year old son, _I 'd love to get a million dollars but I'm not going to get it because I stamp my feet and demand it._

Trade-offs need to be made on both sides. I agree that an engineer that doesn't provide alternatives when a customer demand is not technically feasible should be corrected. However the customer should be prepared to choose from those alternatives or change their demands as well. The first step to success is shipping and the most common reason for software projects shipping late is a failure to start. I'm not against firing bad customers.

It's much easier to ship without a contentious feature and figure out how to add it later than to delay shipping (for certain features within reason, of course -- please don't ship half-baked security libraries or aviation control software).

<comment><USER3> Yes, but that is different situation.

I was specifically talking about situation where requirements are possible and not ambiguos. And where engineers starts "knowing" customer is wrong and keep knowing it despite it regularly turns out it was enginers lack of domain knowledge.

There is no trade off between these two situations.

I don't know what you mean by breaking html spec. Browsers keep it and we work either with it or around it?

<comment><USER5> Ah okay, that makes sense.

re: HTML -- I've had strange requirements come in that required us to work around the HTML spec in order to get the UI to work they way they wanted. We eventually found a better solution...

but the point was that not all requirements are golden; sometimes the customer is plain wrong, ignorant, and stubborn.

<comment><USER3> Yes, I agree with that. It is not that customer is always right. But it is not that customer is always wrong either. We have to look at requirements, give them benefit of doubt, ask and listen to answers to figure out which are wrong.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I think as a profession we've been bad at quantifying and communicating the value of clean infrastructure and good development practices to the business. Why should they pay you to make things "nicer"? One of your big customers is threatening to churn if you don't deliver this new feature! To them, it sounds like you are asking them for a ton of money for better feng shui - pseudoscience with unclear benefits - when they can directly see the benefit of delivering features to the customers.

Instead, I think we need to learn how to measure and quantify the value of a good codebase and good practices, and communicate that to the business. Google's error budgets are a step in the right direction here, but I think there's a lot more that can be done.

<comment><USER7> I've been brainstorming this with colleagues at my job and tossed out the idea of including both an immediate development cost as well as a "long term cost multiplier" for every requested feature. So far, no one has the like the idea or phrase. I can't really blame them.

But there must be some quantity or term, with a nice memorable ring to it, that could get this across and at least let business people make decisions with full information at hand. Granted, any such numbers delivered in that guise would be wild guesses. But still, better than nothing.

Edit: However, I've since realized that the notion of "story points" and "velocity" already sort of provides a way to get this across if used carefully.

<comment><USER8> How can story points be used for that? To me that's only relevant in the short term. Can management be made to understand that velocity can be too high?

Edit: Expanding with my previous thoughts on this - as a software architect I've explained my role to management by saying it's like I work in an agile team, but the waterfall is in my head - someone needs to keep the architecture together and drive it towards green pastures where it keeps great flexibility for developing future anticipated features without giving up stability.

<comment><USER7> My thought was that story points can be used once they are turned into velocity by dividing by time. And you can say that adding this feature half baked _now_ in short time, will inevitably drop our velocity by 10% in the future.

<comment><USER8> Like a huge afterburner that is a dead weight after 3 seconds...

</comment></comment></comment></comment></comment><comment><USER9> "I suspect that most discrimination that happens against older programmers is not, in fact, age discrimination, but is, in fact, 'wisdom discrimination'."

<comment><USER10> As long as hiring and technology decisions remain largely hype-driven, having someone around who says "we don't need k8s, hadoop, machine learning, and AWS with some big-ass Terraform-driven constellation of supporting serices for our expected data, workload, and use case; look, give me one middle-weight server, or one heavyish VM somewhere, and I can show you how to do all this with awk, sed, cron, and maybe a few lines of Perl or Python. We can have it up fast and anyone who can read man pages and a README can admin it, and anyway it's so simple and the workload static enough that once some initial kinks are worked out it'd probably run in a closet without issue for so long you'd forget it was in there—so, longer than this project is likely to be alive, anyway" isn't really something you want unless you plan to ignore them. For their fellow developers, that's résumé poison, you _need_ "real world" experience with all this crap for the next job hunt. For the product manager, owner, and sales, you can't baffle stakeholders or investors or prospects with fancy bullshit when there isn't any fancy bullshit.

<comment><USER11> It's always fascinating to me how people can get to this point where they eschew new technologies just because there is an older way that works fine. Yes, having a tried and true pipeline is important, but it shouldn't be surprising that companies are made of people who want their company to push the envelope to further evolve the systems. _Someone_ was the first person to use Python for a production project, and that evolution has to happen somewhere, with real applications to test them.

<comment><USER12> It's always fascinating to me how some people churn from tech to tech, burning most of their time reading docs and fighting with configurations, just because a new technology might be a bit better than the existing, perfectly adequate system.

It's not that things can't be improved, just that there is so very much low- hanging fruit that has never been implemented at all in a usable manner. We should focus on the huge gains to be made there before the tiny incremental gains to be made by endlessly iterating.

<comment><USER13> There was a blog posted on HN or reddit (I forget) talking abou how they were moving the tech behind their blog yet again. And went through how they did static when it was popular, reactJS, node, and a few others.

I read thinking to myself "my god, it's just a fucking blog engine, why are you spending so much time rewriting it in shit, realizing what you wrote it in has downsides, and thinking the new shiny wouldn't?".

It's like someone actually believe there's a tech silver bullet just around the horizon, rather than a new way of doing things that eases some burdens and creates others.

</comment></comment></comment></comment></comment><comment><USER14> Is it just me or does this article read as basically "everyone else is an idiot, executives (1), managers (2, 8), architects (3) and other developers (5, 6, 7) and only I can see the future and know what needs to be done."

<comment><USER15> The article reads to me as "I didn't get my way and our code isn't perfect, therefore it's everyone's fault but mine and if only we'd embraced X, this would have all been avoided."

</comment></comment><comment><USER16> History of computer programming:

\- Having an accumulator (abacus)

\- Accumulator with operations (calculator)

\- Multiple registers with more complex operations (early computers with plugboards)

\- Stored program computer (abstraction over the plugboards)

\- Imperative programming (simple abstraction over operations + registers)

\- Procedures, Functions, Structures

\- OOP, functional programming, and beyond.

Why do we keep making layers of abstraction? reusability.

We want abstractions that reduce effort by making code reusable.

But abstractions are only a tool, using the tool correctly is on the programmer.

Code is written once, read many times. Languages that focus on "easy to write" are a trap. Languages that focus on "easy to reuse" are what you want.

<comment><USER17> Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well- defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.

<comment><USER18> I highly agree with this. It's almost a necessity these days with a major push to hire "junior" developers at a discounted rate. By doing those lower abstraction layers, you allow them to write the necessary high-volume business code while reducing their ability to do something subtly stupid for the business/data. Usually this involves abstracting away a lot of the database transaction-type stuff.

And on a side note: Never let juniors anywhere near the database design without supervision by the team/seniors. They won't learn anything that way, and they will inevitably make a mess.

<comment><USER16> In genetic algorithms, you select the best from each generation to breed the next generation.

I think this holds true in software development teams as well.

When you indoctrinate new developers, you should delegate mentorship to the best* performing teams, so new developers can assimilate good practices and develop an intuition for how thing should work.

I think this is much more valuable than giving them grunt work.

*: just like with genetic algorithms, picking the right fitness function is everything. Good performance is about steady, consistent, sustainable development... rather than trading today's problem with tomorrow's problem.

</comment></comment></comment></comment><comment><USER19> What a bunch of huey. I've consulted on government programs with massive amounts of money and easy to meet deadlines, and the resulting software systems were still crap. Why? Because yagni (you aint gonna need it) went right out the window and they ended up creating the most resume padding, shiny rock encrusted POS ever.

</comment><comment><USER20> >Some propose that the phenomenon of easy credit and low-interest rates make it economically nonviable for a company to act in its longer-term interests.

Wouldn't it be the other way around? High interest rates would increase the discount rate for future value?

<comment><USER21> I think the idea is that low-interest rates cause investors to push companies to adopt riskier behavior and that easy credit enables said riskier behavior.

</comment></comment><comment><USER5> I don't recall ever having worked on a large code base with a team of developers where everyone was 100% happy with it. Developers complain about _everything_. It's never good enough and never will be.

I believe this is related to our brains being hard-wired to prioritize negative phenomenon and stimuli. Most of those projects shipped and were successful. Users _did_ like using them. However the developers often only saw the bug reports and the endless requests for new features. They never got a chance to talk to users and see how the software was being used and improving the lives of real people. They only see the barb-wire and duct tape.

I had a young developer ask me once about _refactoring_ : how do you get time to refactor your code?

 _Never_. You will never find a person willing to hand you a paycheck to take a month to change absolutely nothing. It gives the business no advantage. _But the bugs!_ the young developer says. To which I say, dear summer child, _risk tolerance_. The business is willing to take the chance that 1-2% of the time a user may get frustrated, encounter a bug, and file a report or complaint. If the company has to pay you to fix it later that's fine. They can tolerate the cost.

You refactor your code as you go. After you write the code and your tests pass and you think you're done -- refactor first. Abstract away superfluous variables with function application, remove duplicated code, break up long branches with decision tables, etc. Fix that code up before you check it in.

As you get better your refactor steps will be much shorter as you internalize the data structures and patterns that lead you to clean, concise code to begin with.

When you write software commercially you need management that understands how to balance capital, people, and technology. And you need engineers who are pragmatic about their work and the real outcomes: the systems and the people who use them.

<comment><USER22> > _You refactor your code as you go._

That's one of my most valuable self-taught truths! I fought with management and colleagues for _years_ until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains _both_ the desired feature (or fix) _and_ the refactoring that slightly improves the status quo of the code.

This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.

<comment><USER23> The word "refactoring" to software managers has the same ring as "prostate exam" or "speculum" to the rest of us. It might be necessary sometimes but Preferably Not Today and please stop talking about it all of the time.

<comment><USER22> Yeah, agreed. I stopped using it altogether when I am not talking with programmers. I usually just say "when adding this new thing you have to re-fit everything else so all parts play nice with each other", or "you know how you have to pull the engine out so you can fix the frontal suspension? that's what I have to do sometimes". Both of these are accepted pretty well by non- technical people.

</comment></comment></comment></comment><comment><USER24> My two bosses keep asking me how the code I write for myself is so stable (it's Elm), and yet we're always fixing bullshit bugs in our company's codebases (they're JS and TS -- sorry guys, TS isn't good enough).

But when I try to sell them on the stuff I use personally, the response I get is "it will be too expensive if we have to hire someone for that," yet no thought to the cost-effectiveness of needing to calling a dev on a weekend with overtime pay to fix a null reference that snuck into the codebase during the week somewhere. Or months ago. I'd say another developer is more valuable than clinging to classes of bugs that don't need to exist any longer.

We do what we can but can only do _so much_ to make and keep our code stable, we're a small company with a small dev team and one of the two managers like to meddle in the code. We get by well enough, but despite all the evidence directly in front of them, I am simply not allowed to take the leap into something that would be better in the long run. It just doesn't matter to them.

Another one I get is "that language is too weird," but I've taken to just directly telling them that isn't a criticism and that I need a better reason. Of course it just goes right back to the hiring excuse from above. We aren't hiring and have no plans to hire anytime soon. We're small enough to move quickly, there's no giant organization to migrate into new tooling, none of that, I'm just basically being told that I'm planning too far in advance.

</comment><comment><USER25> Discussed at the time: [https://news.ycombinator.com/item?id=12778824](https://news.ycombinator.com/item?id=12778824)

a bit more: [https://news.ycombinator.com/item?id=13270271](https://news.ycombinator.com/item?id=13270271)

</comment><comment><USER26> this problem is about as intractable to me as why I don't eat healthier. Maybe one day I will achieve one or both.

</comment><comment><USER27> There is so much truth in this article I nearly fell off my chair. Especially #2 and #3.

<comment><USER10> > Oh sure, you can solve the endless little meaningless problems that plague > the day-to-day life of programmers everywhere, but the source of these > problems — defects at the engineering level — are effectively untouchable. > Also untouchable are the systemic issues that cause each of these should-be- > trivial-to-fix problems into 5–8 hour tasks.

That part of #4 is so true it hurts. Most of the software I use is full of brokenness and "WTF"s.

About a year ago: AWS Lamba supports Java. Sweet, should be easy. Oh but the command line tools are broken in several ways you won't discover until you try, find they're broken, google around for a while trying to figure out what's wrong, then realize it's not your fault when you find the relevant unfixed issues.

About three years ago: Well I'm writing an Android app so this Google Maps feature should be a piece of cake, I mean, Google makes the OS so surely Maps is amazing on here. Except. Wait. No. That cannot be right. It can't. The Android maps SDK is missing features that the Javascript version has? No. That doesn't make any sense. Oh. Here's a GH repo someone already made to provide a convenient interface from Android Java to the Javascript maps SDK for this exact reason. I mean I guess I don't have to write it myself now but seriously, this was a fucking waste of half my day for no good reason.

A few days ago: Debian installer is flat-out incapable of writing Grub correctly. Several tries, every reasonable combo possible, boot fails with missing OS every time. This ain't my first damn rodeo—something's wrong. Think it's maybe a UEFI issue. Force UEFI. Now my video card doesn't work. Because it's not UEFI compatible? Why dafuq is that even a thing? Open case, reset bios so I have a display again, install again just to be safe, boot to installer's recovery mode, mount, chroot, install grub manually and in _precisely_ the way I'd told the installer to do it the first time, and without changing a damn thing about the config the installer had just written, and it's fine.

This is basically how everything goes every time I try to do anything with software at all. Which is my job. So this is my life.

Software is terrible.

[EDIT] in fact I can think of one area where my tools are consistently as shitty, broken, and unsuitable for their intended purpose as software usually is: it's when I cheap out on power or (especially) hand tools to try to save a buck.

<comment><USER28> There is a related Jonathan Blow talk titled "Preventing the Collapse of Civilization" [0] that I came across recently from a HN post. You might be interested in watching it. Also, Casey Muratori's talk titled "The Thirty Million Line Problem" [1].

[0]: [https://youtube.com/watch?v=pW-SOdj4Kkk](https://youtube.com/watch?v=pW- SOdj4Kkk)

[1]: [https://youtube.com/watch?v=kZRE7HIO3vk](https://youtube.com/watch?v=kZRE7HIO3vk)

</comment></comment></comment><comment><USER29> 5sts

</comment><comment><USER30> *of

:D

</comment><comment><USER31> This feels borderline sociopathic.. working in team is hard and demand compromise, and yes, although necessary no political system is perfect. But the work conditions of a software engineer are way better than any other job I have done.

</comment><comment><USER32> The so-called "Business People" are people who's main goal is to make money. And if you think about it that really means their main goal is is to make money for themselves.

Techies' in contrast are more concerned about building great products. This naturally creates some tension between techies and the business-people. What should be the division of labor, and rewards?</comment>


Is anyone using VR to collaborate remotely with colleagues? - <AUTHOR> My engineering team is entirely distributed. We write software and build architecture to process data.
We joke about using VR all the time to whiteboard projects. There's probably a lot of other collaborative stuff we could be doing in there as well. The problem is, only one person has an HTC Vive, so we can't test if this is useful.
I'm curious if anyone is using VR in this capacity for real work.
Do you use it often? Is it beneficial? Are there any benefits that surprised you? Anything you thought would work that doesn't?
Does anyone get enough benefit to justify business expenses to buy VR for your teams? <comment><USER2> in plan</comment>


Show HN: Open-Source Starter for SaaS Products - <AUTHOR> For the past few months, I've been thinking about building a few different SaaS products.
The problem is that there's a lot of work to do before you even start building your product — adding support for recurring subscriptions, billing, GDPR compliance, authentication, . . . maybe your SaaS needs support for teams, scoped memberships, API key pairs, etc. etc., the list goes on.
Introducing Staart — the starter template for SaaS products. Written in Node.js/TypeScript with a beautiful Vue.js/Nuxt.js Progressive Web App (PWA), Staart takes care of all the boilerplate required when building a SaaS product, so you can focus on what really matter — your core product.
I'd love to hear what the community thinks!
Check it out on Product Hunt: https://www.producthunt.com/posts/staart
GitHub: Staart (backend) and Staart UI (frontend) https://github.com/o15y
Live demo: https://staart-demo.o15y.com <comment><USER2> I love starter templates like this. But I have yet to use them in real products, because they are inherently opinionated. And I like my tech choices to be driven by product needs, not the ease of launch. I'm not philosophically opposed to using something like this, but my process is more along the lines of:

1) Define the product

2) Determine what features and functions are needed, and how it will influence architecture decisions.

3) Pick a stack to start with.

Normally, from node up to the front-end, I'm flexible, but these kits typically also are tied to specific databases, with specific auth solutions, and assumptions about the type of dev environment and flow that people want to see. If you are adding in billing and subscriptions, there are even more places we might end up on different pages.

Now, if the stack I choose ends up matching a solution like yours, terrific. I'll use it and be happy. But the more complete the solution, the less likely it is to be a match.

<comment><AUTHOR> I understand and this makes a lot of sense. For me, Staart was a way to streamline my own build-and-launch process and I designed the Stack to fit my personal needs. Based on other comments, I do want to make it as context- agnostic as possible while keeping the basics, like authentication, authorization, etc.

Perhaps a "Staart builder" is an interesting idea where you pick and choose what features you want for your starter and build from there.

</comment></comment><comment><USER3> Great idea, but I agree with codingdave. Too opinionated and only makes things more difficult.

The more important things to a SaaS is the actual product and not the authentication / backend / DB.

99.99999% of all early stage SaaS have absolutely no need for even 2FA, let alone multitudes of authentication.

It's just a lot of clutter and cruft for an MVP, which is what should be built.

I think a better framework would be focusing on the essentials, a very simple username + pwd, drop-in DB with a generic schema (Put it in JSON and export it from a file, rather than wrapping in an ODM / ORM object).

Finally you could wrap it up with a nice landing page template.

I would pay money for someone to give me a light, nice-looking landing page that is easily templated and it focuses on being light.

\---

One issue with this kind of project is that it is difficult to adopt and build on to. It might be a great starting place, but it presents a fork of either total rebuild or stumbling through unfamiliar, cluttered code.

<comment><AUTHOR> Thanks, madamelic. Like I said to codingdave, Staart was built as a tool for me, and I published it to see if others might want to use it too.

I agree with you that 2FA, auth rules for teams, etc., may be overkill, but the projects I'm working on (primarily focused as enterprise software alternates) all needed them, which is how Staart was born.

I am more and more pushed in the direction of a "check the features you want to keep and build your Staart package".

Perhaps that last part can be solved with thorough documentation about how to build on top of it. I am currently doing this by only working on project- specific files ("core product") and letting Staart handle auth/etc., but the second these need to be updated to be project-specific too, it will result in merge errors when updating Staart and so on. You're right, it's a problem I need to look into.

</comment></comment><comment><USER4> Why didn't you use a querybuilder (like knex) that is db agnostic? Here users are stuck with MySQL.

<comment><AUTHOR> That sounds like a great idea! I found a few ORMs and decided to go that route first (for strong TypeScript support), but later dropped that idea to my current interface-MySQL implementation. Now that I see it, this is the perfect use case for Knex and I'll give it a shot. Thanks again!</comment></comment>


Company plans to beam free Wi-fi to every person on Earth from space - <AUTHOR> http://www.dailymail.co.uk/sciencetech/article-2552177/Forget-Internet-soon-OUTERNET-Company-plans-beam-free-wi-fi-person-Earth-space.html

<comment><USER2> No idea of the validity of this, but for non UK readers, the Daily Mail is a very poor source of information on anything scientific.</comment>


Ask HN: Keeping busy during a commute - <AUTHOR>

I've started a new project that will have me commuting 60km a day. The distance is not too bad, but with traffic as it is I'm in the car for a solid hour.<p>There are a few podcasts I enjoy, but they are relatively infrequent. I'd also like something a little more engaging.<p>- anyone have experience with audiobooks? Do you need to speed them up? - any other ideas would be most welcome <comment><USER2> Hyperion Cantos by Dan Simmons for a great audiobook experience. I do mean experience, the word epic is thrown around a lot but Hyperion is worlds above any Sci Fi I have read. The narration is excellent in all 4.

<http://www.audible.com/pd?asin=B002V5BLIW>

You will find yourself trying to find a longer way home</comment>


Online Accounting: The Next Killer App For Google Apps - <AUTHOR> http://www.readwriteweb.com/archives/online_accounting_google_apps.php <comment><USER2> Replace "Google" everywhere with "YourCleverDomainNameForAnAccountingApp", and this becomes the elevator pitch for a YC application.</comment>


React Server - <AUTHOR> https://react-server.io/ <comment><USER2> This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is cost-prohibitive for most people, I'm sure. At the same time, I'm hesitant to go "all in" on a stack that I haven't heavily researched myself. If the developers are reading, can you go into some details about how you handle routing and data stores? Are you using off the shelf libraries or have you rolled your own?

<comment><USER3> > I just spent the last two weeks setting up a boilerplate

Two weeks for setting up boilerplate? Is that normal for react?

<comment><USER2> No, two weeks to take a deep dive into all the associated dependencies for doing a universal SPA. Learning the details of webpack (which requires more googling than reading the documentation), auditioning several flux implementations (and there's relay if you want to go down the graphql rabbit hole), routing libraries, and server page rendering configurations. There's no single way to do this and everybody has their own boilerplate set up on github. You can just get started with one of those, but if you don't understand what's going on under the hood, you'll be up the creek when something breaks and you're on the clock. I'm extremely uncomfortable working with something professionally until I have a good understanding of the source at least at the highest level of abstraction. Unfortunately this seems to be the only way to survive in the NPM ecosystem, pulling down and spending an hour reading the source of every variation of large dependency you might need. Hence the two weeks. Not that it's such a bad way to do things, reading the source. It's just a lot slower than people generally expect web development to take these days.

</comment></comment></comment><comment><USER4> It doesn't seem like it is for beginners. Docs look at the author assumes everything is self-obvious. Need better tutorials.

<comment><USER5> Yes, definitely agree! We need better tutorials!

We need better docs in general. Contributions welcome! :D

<comment><USER6> I'm totally on board with the "contributions welcome" response from open source maintainers, but when it's the only response to questions about documentation it's pretty off-putting. This is your project, how could you expect a new contributor to add docs without your input? I get that good documentation is hard, and takes time, but if you want your project to succeed I think it's almost mandatory for you to write these docs (at least the initial version!) yourself.

<comment><USER7> I have to agree here. There's nobody better to explain how something really works than the person who wrote it. The rest of us are just fumbling around guessing.

As a dev and a creative person, I understand the desire to get something out there. But documentation and tutorials aren't just something that's nice to have. They are your marketing tool, your adoption driver, and the way to create educated advocates for your project. They are as valuable to your project's success as a splashy "getting started" web site is.

<comment><USER8> That process of you fumbling around and guessing is actually really extraordinarily helpful. The things a contributor might think to do or to try, and the things that a newcomer might think to do or to try, are completely different. No documentation survives its first encounter with a real newcomer. We can, and will, continue working on the onboarding experience, but we'll need real users to roll up their sleeves and wade into it, and the first few of them will have questions we didn't anticipate, and make assumptions we've never considered, and try use cases we've never thought of. Creating good documentation is something that newcomers and contributors need to collaborate on.

<comment><USER7> That process is the second part of the process, once clear, basic documentation exists.

</comment></comment></comment></comment></comment></comment><comment><USER9> How does it handle fetching data from a path on the same origin? For instance, I only need to fetch('/api/users.json') on a certain page (/users). This means that it can either be hydrated in the initial state when performing a full page load of /users or needs to be fetched (using xhr/fetch) when navigating to that page from another page on the site (which shouldn't require a full page load).

So how exactly does the server perform that same fetch when attempting to hydrate the full page without actually making an HTTP request against itself?

<comment><USER10> The other responses seem to be answering how this would work once the hydration is occurring on the client side. I understood the question to be `Does the http request layer support doing API requests to routes which are on the same webserver as react-server`.

There doesn't appear to be special handling for this use case. However, they use SuperAgent ([https://github.com/visionmedia/superagent](https://github.com/visionmedia/superagent)) for http requests and I expect implementing the behavior that you're describing is relatively easy with their plugin system. Specifically I'd bet that plugins previously designed for testing could be used to accomplish your goal (superagent-mock or superagent-mocker).

<comment><USER9> What I'd like to be able to do is not incur an additional HTTP request against my own server. Does SuperAgent have a way to avoid opening a new socket when making a request against yourself?

<comment><USER10> Yeah, I understood what you wanted. I may not have been clear in my line of thinking. My understanding is that react-server does not support this. However, I do not believe that it would be difficult to add support using the testing plugins built for SuperAgent.

Imagine writing tests with mocked requests. Now apply that same logic to all calls to fetch() on the server. Does that make sense?

So to the front end when fetch() is called, it actually makes the request. On the server, when fetch() is called it hits a mock plugin which fetches "mocked" data which is just fetching data from whatever local store you normally would on your backend be it a JSON blob on the file system, a database or an in memory cache.

editing to say that @exogen gave what may be a better explanation below: [https://news.ycombinator.com/item?id=12273029](https://news.ycombinator.com/item?id=12273029)

<comment><USER11> Another universal http option is : [https://github.com/matthew- andrews/isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch)

<comment><USER10> That's the opposite of what the question is asking for. They want to call fetch('/api/foo/bar') but on the client it does an HTTP call while on the server it recognizes that /api* is on the local system and therefore invoke that _local_ route instead of doing an unnecessary http call.

That's what I'm apparently failing to describe how to accomplish :).

<comment><USER11> Oh i see, I actually accomplished that a while back by monkey patching superagent to use Hapi.js, and inject.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> If this works as advertised, this may prove to be a very useful project, that can replace numerous homegrown, half-complete implementations strewn about the internet.

</comment><comment><USER13> I've been banging my head in this boilerplate for the last few weeks and it's been very interesting.

[https://github.com/erikras/react-redux-universal-hot- example](https://github.com/erikras/react-redux-universal-hot-example)

How does this compare to that?

<comment><USER14> This boilerplate served as a base for a project I worked on, which I then extracted out into an npm module for easier maintenance. You might find it helpful: [https://github.com/bdefore/universal- redux](https://github.com/bdefore/universal-redux)

That said, react-server attempts to solve the problem in more of a framework fashion. I hope to look further into it.

</comment></comment><comment><USER15> I see a bunch of failed attempts in console to connect to slack websocket. Is everything looking ok for you?

After blocking 2 iframes with adblocker I could finally inspect what was going on :)

Anyway, I can definitely feel that is fast and seamless and worth to give a deeper look! In the meantime, prefetching all the content in docs or source views upon load generates quite a few requests and might explain your scaling issues. Would you mind sharing statistics for number of users and hardware behind ?

<comment><USER16> That's a result of the Slack badge at the bottom of the page trying to use a WebSocket to update its counts. We discovered getting WebSockets working through ELB was not trivial and have decided instead to disable the real-time updates to the badge. The changes have been made for that, but sadly, not deployed in time for your visit.

Anyway, the errors in the console aren't impacting the behavior of the site (the badge is falling back to polling to get updates, for instance). They are ugly, though, and will be gone in a future deployment.

<comment><USER17> > getting WebSockets working through ELB was not trivial

Amazon announced the Application Load Balancer today which supports Websockets:

[https://aws.amazon.com/blogs/aws/new-aws-application-load- ba...](https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/)

<comment><USER16> Oh, that's timely! I will check that out.

Thanks for the heads up!

</comment></comment></comment></comment><comment><USER18> Based on the documentation and the design principles this seems like a really promising framework.

The data hydration, incremental HTML delivery and incremental code loading are really, really important for creating web apps that aren't load time hogs. Great to see that they were unopinionated about data fetching, too. That's one of the things that has made it difficult to drop Relay into existing applications.

Is this used in production? Are there any performance numbers that you can share.

<comment><USER19> Redfin uses it in production. [https://www.redfin.com/blog/2016/05/announcing- react-server....](https://www.redfin.com/blog/2016/05/announcing-react- server.html)

"We've been using it here at Redfin in production for over a year and it serves the three highest traffic pages on the site. We're serving 1 billion requests a month from our React Server instance; hundreds of requests per second during peak hours."

</comment></comment><comment><USER20> Would be useful if this project explained the difference between React and ReactServer. It seems they are as similar as Java and Javascript.

Instead of the render() method in React to output JSX, it appears that ReactServer uses getElements() for a similar purpose. So the entire model and object lifecycle is probably different as well?

<comment><USER21> React Server uses React; the page that has getElements is sort of a meta- React-component that has other specified behavior, as well as returning a React component to be mounted. So it renders the first page you visit on the server (for fast loading), then all subsequent pages are rendered on the client.

<comment><USER20> Thanks. That should be the very first line in the documentation.

<comment><USER22> Also should probably mention it's not worth the trouble.

</comment></comment></comment></comment><comment><USER23> Humorously this looks a bit like Apache Wicket, a Java-based client/server UI framework which has been around for about 10 years: [https://wicket.apache.org](https://wicket.apache.org)

<comment><USER24> I was thinking about the same thing + JSF.

This might be the evolution of it, where the page routing is residing on client with server side state ?

</comment></comment><comment><USER25> there is a wealth of information in their documentation about making performant rendering on the server and client [https://react- server.io/docs/intro/why-react-server](https://react-server.io/docs/intro/why- react-server) I found it super interesting.

</comment><comment><USER26> I just recently made the switch into the Web Dev world (coming from C++/Python, desktop world). Since I knew of Django, I've started using it as the 'Backend/Server' part of my Web app dev stack. Basically using Django to render minimal React/HTML/JS/CSS to bootstrap my single page Web app. Wondering, what advantage would I have would I get from using react-server instead of Django (aside from using JS across the board)?

Would appreciate feedback!

<comment><USER27> I have not looked at how this framework does it, but I have built a nodejs server that does similar things myself. Some advantages:

\- The server can render the full page in html for the client, which means the website is viewable even without js (or before js has loaded, for example on slow network)

\- The server can preload all data the client needs. The webapp might need to fetch data from 3 API endpoints. Having a server do this and pass the results to the client on load is much more efficient. If the client (browser) loads it, the following happens: html loaded -> js loaded -> start calling APIs. If the server does it, the client instantly has access to this data.

Rendering all the html can be a bit heavy on a weak server though, but you get the advantage that you quickly notice bottlenecks in your rendering. You can also implement some caching on your server to make it faster.

<comment><USER26> I appreciate your answer, which seems to apply to the general concept of server rendering. But Django can also do all what you mention. My question was: what can React-Server do that Django could not? I hope this clarifies my original interrogation.

<comment><USER27> The difference is that a "react server" can actually render the dynamic react content. I don't know of a way to do this in django, unless you are able to run javascript code somehow. If you do this, you are kind of making your django app a "react server" though, since it renders all of your react components.

What usually happens in a react app is that the server delivers static content (html, js, css). When everything is loaded, react starts working on the browser and renders / fetches data.

If the server that delivers the html doesn't just deliver a static page, but actually fetches data and renders it first, the browser can instantly display the data and react is smart enough to know that it doesn't even need to do a new render, because the components are already rendered to html.

</comment></comment></comment></comment><comment><USER28> Mad props to a crew from the real estate industry who just pumped out cool tech for universal utility! Kudos to the folks from Redfin!

</comment><comment><USER29> The company that I was consulting for tried to get Spring and React to play nice via Nashorn, but ended up scraping the idea 6 weeks in because of performance issues and not enough developers knowing the stack. Nashorn was missing a lot of essentials to make this easy out of the box. So looking at this is a breath of fresh air.

</comment><comment><USER30> _One of the great things about React is its support for server-side rendering_

Cool, I never knew that.

</comment><comment><USER24> A simple model/flow of rendering pipeline would be helpful here based upon routing logic.

As I understand, Pages are composed of Components, Components provide HTML sections. HTML sections are loaded incrementally.

</comment><comment><USER31> An alternative here is Hypernova by Airbnb.

<comment><USER32> Correct me if I'm mistaken, but Hypernova has the javascript rendering siloed as a separate service. Which can be really useful in some cases (especially if you want to render React components from a Rails app).

But if you want it all in one place (reduced complexity and overhead), React Server looks pretty promising.

<comment><USER10> React-server seems to roll in additional opinions (sane default) about how to go about creating a high performance server-side rendered universal application.

My evaluation is that react-server looks promising for prototyping and first versions of an application where being monolith is a reasonable approach. Hypernova seems like a good fit for organizations that are already building microservices and want to eek some additional performance out of the initial render of their SPAs.

</comment></comment></comment><comment><USER33> React Server looks fantastic!

For some reason this week I stumbled over many great React.js articles, so I started a collection here [http://deepreact.com](http://deepreact.com) mostly to save&share things with friends, since a lot of us are getting deeper into React now.

</comment><comment><USER34> I'd really love to see a demo of what they mean by "seamless transitions."

<comment><USER5> The website itself is meant to serve as a demo. :)

When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".

<comment><USER35> "seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely- unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising this may lead to some unwarranted excitement and subsequent disappointment, since the website doesn't really have transitions at all of this sort.

<comment><USER5> Oh, hadn't considered that interpretation. Our full project description on GitHub is "React framework with server render for blazing fast page load and seamless transitions between pages in the browser". The tag line on the website is shortened from that. I think the full version is a little less ambiguous, but it's a little too wordy in the context of the site.

Will have to think about a better tag line... Thanks!

<comment><USER34> I share nostrademons's interpretation. I'd expect the first page rendered on the server and the rest rendered on the client in any isomorphic framework. When I hear "transitions", I expect elements morphing between assets, ala neon-animated-pages:

[https://elements.polymer-project.org/elements/neon- animation...](https://elements.polymer-project.org/elements/neon- animation?view=demo:demo/index.html&active=neon-animated-pages)

I think your value proposition is something like: "Renders on the server or the client - whichever's fastest for that request"

</comment></comment></comment></comment></comment><comment><USER36> Are there any numbers comparing pre-rendered React versus React communicating with a JSON Api? It seems to put a lot more stress on the server which can neglect the (theoritical) speed improvements

<comment><USER37> Not sure, but the time cost is the latency of loading an almost-empty index.html, loading and parsing your app, _then_ it starts running and hopefully fast doing some API requests and then it's off and good to go. Subsequent JSON-API-requests-and-then-rerenders should be pretty fast indeed, but those aren't the point :)

You want to server-side render React apps so that while all that happens, the app already works.

</comment></comment><comment><USER38> Looks fascinating, I will definitely be watching this project in the coming year.

Just curious, if it's been successfully running in production for over a year, why is it only being used to serve three pages?

<comment><USER19> That statistic is out of date; Redfin has built dozens of pages on React- Server by this point.

(Also, just to be clear, we treat _all_ home details pages as a single logical page.)

</comment></comment><comment><USER39> Looks very interesting, will give this a spin. I've been skimming the docs, but I assume you'll still have to install redux to handle state etc.

</comment><comment><USER40> Could react-server build in support for AMP? [https://www.ampproject.org/](https://www.ampproject.org/)

</comment><comment><USER41> You have a misspelling in your homepage: née not neé.

<comment><USER42> Merged at [https://github.com/redfin/react- server/pull/527](https://github.com/redfin/react-server/pull/527)

<comment><USER8> thanks again!

</comment></comment></comment><comment><USER43> It even includes a Dockerfile and a docker-compose.yml file to get quickly started, that's cool :)

</comment><comment><USER44> This looks cool. Any way to make it easily work with Relay?

<comment><USER8> This is something that we're thinking about ([https://github.com/redfin/react- server/issues/190](https://github.com/redfin/react-server/issues/190)), but that we just don't have an answer for right now. React Server was built with running two servers in mind, one for your api and React Server as your front- end. I haven't used Relay much, but I think you could run your Relay server as the api server, then make the request from React Server with ReactServerAgent and it should work?

</comment></comment><comment><USER45> > "Blazing fast page load and seamless transitions."

Click on Get Started and no seamless transition, but rather a very abrupt page load.

</comment><comment><USER46> every time somebody makes a new react / angular derivative a unicorn loses it's horn.

</comment><comment><USER47> wtf is neé?

<comment><USER8> Its the French word for "born." Its often used for maiden names. In this case, we mean "we called it Triton before we called it React Server," which was more important to understand before [https://github.com/redfin/react- server/pull/40](https://github.com/redfin/react-server/pull/40) merged

</comment></comment><comment><USER48> Getting random 504 timeout errors on this site. Is this hosted using react- server?

<comment><USER49> It's a curious project but maybe not "Blazing fast page load and seamless transitions."

<comment><USER50> Well page loads are fast, and clicking links within the docs section does feel super fast, but I agree use of the word 'transitions' is confusing (which the author has now addressed elsewhere).

</comment></comment></comment><comment><USER51> Getting some weird issues, can only get to the docs by clicking on the link to the docs and then refreshing the page a couple of times...

<comment><USER8> We had some scaling issues, and have added a couple more hosts to the pool. The errors should be resolved now</comment></comment>


Digital Exile: How I Got Banned for Life from AirBnB - <AUTHOR> https://medium.com/@jacksoncunningham/digital-exile-how-i-got-banned-for-life-from-airbnb-615434c6eeba?curator=NODESK <comment><USER2> Dupe of [https://news.ycombinator.com/item?id=17523056](https://news.ycombinator.com/item?id=17523056)</comment>


Clojure and Logic: Lojic Part Two - <AUTHOR> http://clojure.com/blog/2011/12/08/lojic-part-two.html <comment><USER2> If anyone knows about it, I'm curious about any of the history and evolution of Kanren/miniKanren (the original Scheme versions) not found in standard reference papers, and wonder if any of the authors frequent HN.

There seem to be three distinct implementations in the Kanren family at:

<http://kanren.sourceforge.net/>

1) Kanren (v4.50) - the full-blown logic system by Dan Friedman and Oleg.

2) "minikanren.scm" (v4.50) - this isn't the miniKanren that's used in The Reasoned Schemer (RS) - it appears to be a trimmed-down version of Kanren that may have been used in Univ. of Indiana classes, e.g:

<http://www.cs.indiana.edu/l/www/classes/c311/minilop.pdf>

It's an interesting version in its own right, and I've used it for some Datalog-like experiments. I wonder if this was an early attempt to adapt Kanren for teaching, or if anything else drove its implementation.

3) "mk.scm" (v1.3) - the RS' miniKanren by Friedman, Oleg Kiselyov, William Byrd, and Chung-chieh Shan...also described in Byrd's dissertation:

[https://scholarworks.iu.edu/dspace/bitstream/handle/2022/877...](https://scholarworks.iu.edu/dspace/bitstream/handle/2022/8777/Byrd_indiana_0093A_10344.pdf?sequence=1)

There are other versions as well - a microKanren, a couple of implementations by the U. of Indiana folks for things like nominal logic programming (alphaKanren) and constraint logic programming (cKanren), and of course the Clojure version discussed in the link.

These are all fascinating projects, and the full-blown Kanren implementation (in Scheme) is quite fast for things I've used it for. Much of the work you see recently on the web discusses the core.logic (miniKanren/Clojure) implementation. I'd be interested in hearing from others who've used any of these systems.

<comment><USER3> I would email Prof. Friedman, I've spoke with him in the past and he was very friendly and extremely eager to discuss his work (of course keep in mind he is very busy). As far as I could tell chatting with him the whole Kanren system is a continually evolving project to make a better and better logic programming system in scheme. He's an amazing hacker and extremely dedicated to pushing Scheme to it's absolute limits, I remember him showing me all the places where him and his co-author were able to reduce 6 loc to 4 here and 10 to 8 there etc. You could tell that he's continually reviewing code saying "I know this can be more abstract, more simple but how?" I think they've reduced the implementation used in the reasoned schemer from 2 to 1 1/2 pages at this point (edit: originally said 6 to 4 pages but reviewing some notes from the meeting, after seeing keithflower's reply, I've adjusted it accordingly ). If you can't get in touch with Friedman definitely try some of the other co- authors, Friedman gives them a ton of credit for making the system as awesome as it is today.

<comment><USER2> Thanks, good idea. I've got he and Mitchell Wand's well-known Essentials of Programming Languages and it taught me a ton.

You're right about the conciseness of RS miniKanren - it's just two pages in the "Connecting the Wires" part of the text.

<comment><USER3> Ah yes it is 2 pages, I've edited my comment above, believe it or not they actually have reduced it even further to roughly a page and a half. I was really inspired by the extreme dedication and passion it takes to look at a full logic programming implementation in 2 pages of code and say "nope, we can do better". Dan is definitely one of my all time heroes.

</comment></comment></comment></comment><comment><USER4> I bought "The Reasoned Schemer" several years ago, but did not work all the way through it. I am using Clojure a lot now on customer and personal projects so I'll give Lojic a good look.</comment>


The power of ignoring - <AUTHOR> https://www.washingtonpost.com/news/wonk/wp/2016/03/03/the-incredible-power-of-ignoring-everything/ <comment><USER2> It's very easy not to think of a polar bear; it's hard to enter into a state of mind whereby you can _guarantee_ that you will not think of a polar bear for the next N minutes. If you drop the guarantee part, and make it a soft requirement, then it's easy: just think of something else and forget about polar bears. Chances are you won't accidentally think of a polar bear within N minutes.

"Worse is better" makes it possible: relax the requirements, get the job done.

If you try to guarantee that you don't think of a polar bear, that is oxymoronic, because to concentrate on not thinking of a polar bear, you have to continuously hold a polar bear symbol in your consciousness, which means you're doing nothing but thinking of a polar bear.

</comment><comment><USER2> This just seems completely wrongheaded.

There is no difference between looking for items which match some criteria, and looking for items which do not.

The classification type looks like a big red herring.

It is a problem of exhaustively partitioning a set of items into two classes. "Retain" and "reject" are just arbitrary labels for these classes, which might as well be "A" and "B" or whatever else.

Whether it is easier to calculate class A or B depends entirely on the statistical properties of the specific input relative to the complexity of the criteria for determining class membership in A versus B.

For instance, suppose membership in A means satisfying the correct attribute values in fifty different properties. Now suppose that most of the objects in the input set satisfy the test in 49 properties, failing only in one. Only a few objects satisfy all 50 properties with the correct attributes. Then the task will be hard, and it will be equally hard whether the focus is to identify B's or A's, because either way it is a _separation_ of A's from B's.

If you give me a jar of beans, where all are white, but about six or seven are black, I can easily give you all the white ones, or all the black ones. Either way I pick out the black ones. Then I have them separated and I just give you whichever set you asked for. If the mix is 50/50, it's a lot more work, whether you ask for black or white.

</comment><comment><USER3>
      The study suggests that the ability to pay attention to
      something is driven by inhibition.

This is controversial.

Inhibition sounds like the opposite of openness, and openness is considered vitally important to being a good programmer according to [http://arstechnica.com/science/2015/11/programmers-are-a- tin...](http://arstechnica.com/science/2015/11/programmers-are-a-tiny-bit- introverted-but-otherwise-agreeable/)

<comment><USER4> Nope. Inhibition is about attention. Openness is about judgement.

<comment><USER5> Yeah, seems like it's one of those words that psychologists use differently than the rest of us? At least feels like I'd use "Inhibition" differently... "the brain's ability to suppress distractions -- what psychologists call "inhibition" "

<comment><USER4> Neuroscientists use the word "inhibition" for the situation when an excited/activated neuron suppresses the excitation of another neuron. An inhibitory connection is like a negatively weighted connection in an ANN. That seems similar in spirit to the psychological use. Yeah, context is important.</comment></comment></comment></comment>


Ask HN: Dark Mode for HN? - <AUTHOR> Does anyone know if HN will natively support a dark mode and if not, where can I find an implementation of it? <comment><USER2> I use Stylus [1] with the Hacker News Gray style [2].

[1] [https://add0n.com/stylus.html](https://add0n.com/stylus.html)

[2] [https://userstyles.org/styles/151862/hacker-news- gray](https://userstyles.org/styles/151862/hacker-news-gray)

</comment><comment><USER3> Here's a simple user style I wrote:

body { background-color: black !important; filter: invert(90%) hue- rotate(180deg) !important; }

</comment><comment><USER4> A couple of months ago I created a dark theme for HN: [https://chrome.google.com/webstore/detail/hn- enhance/dmnbgmc...](https://chrome.google.com/webstore/detail/hn- enhance/dmnbgmcilgmcmlhgjkociikeihbkbcdp)

</comment><comment><USER5> You could do it yourself using this extension if you use Chrome:

[https://chrome.google.com/webstore/detail/user- css/okpjlejfh...](https://chrome.google.com/webstore/detail/user- css/okpjlejfhacmgjkmknjhadmkdbcldfcb?hl=en)

</comment><comment><USER6> Stylus (browser extension) + Hacker News Dark - [https://userstyles.org/styles/113994/hacker-news- dark](https://userstyles.org/styles/113994/hacker-news-dark)

</comment><comment><USER7> I use tampermonkey (works in all browsers IIRC) with this little hacky script: [https://pastebin.com/USzMCtSz](https://pastebin.com/USzMCtSz)

</comment><comment><USER8> The Chrome extension Dark Reader works very well on Hacker News. It's hit or miss on other sites and can create some disturbing SVGs.

</comment><comment><USER9> There exists extensions that can do it, tho be careful about them some have been known to spy on people, by reporting back data</comment>


Ask HN: What if there was a software for 'starting a business" - <AUTHOR>

Been playing around with this idea and would love to have feedback/thoughts from the community.
There is Word for writing text. There is powerpoint for creating a presentation. There is Photoshop for making graphics. What if there was an App for Starting a business?
How would it work? You'd fill in an idea, the app would take you through steps to validate, build, market your business. And if the idea doesn't make you money, you can simply start over again and select 'Launch New Business'.
It's not an app that does the work for you. It just motivates/inspires you + provides daily micro challenges to take you one step further.
Problem of writing a business plan = You write it and thats it. You have to motivate yourself to stick to the plan and go for it.
This app will challenge you everyday to get one step further.
Is this something you would use? Pay for even? <comment><USER2> It sounds like what you are describing is a "guide". Which, rather than an app, could start out as a "information production". That might be interesting and valuable if you've done it before and can do it. Even a blog post linking to other people's posts on each of those steps would be valuable.

<comment><AUTHOR> True yeah. Thing is I've consulted on this topic, but the problem is that people get very inspired by reading an ebook or what ever on this topic. But what they really want is actionable daily challenges. Like 'Do X today' If you fail, go back to step 2. So software in this case is the only minimum option I think. But evolving the idea right now

<comment><USER2> So you can make an info product that is an app? You can make it "email first" (as some people are calling it these days). Basically email me the steps for today, and if I do them email you back "okay", then you can send me the next step tomorrow. If I don't email you, or email you "help please", then you can send me further instructions or provide more details.

<comment><AUTHOR> great idea!

</comment></comment></comment></comment><comment><USER3> Back in the day, I tried a program called something like Biz Plan Writer. It helped to organize ideas around the new business (e.g. revenue projections) and put together a business plan which could be presented to potential investors. It left the validation and marketing to the humans, though.

<comment><AUTHOR> What if Biz Plan would have given you daily challenges to kickstart your business and make money (or to quickly find that it doesn't work and you need to pivot)

</comment></comment><comment><USER4> > What if there was an App for Starting a business?

Wow. What a great idea. You download a $1.00 app and before you know it you have a billion dollar company. Love it!!!

<comment><USER5> my sentiments exactly. however there is a legacy app that's been floating around for a few years... some use it, most don't. it's called a business plan.

<comment><AUTHOR> a business plan is one of those 'feel good for a moment' things. A business plan doesn't send you daily reminders and challenges of 'what to do now'</comment></comment></comment>