How serious is Google about Dart? - <AUTHOR> http://yakovfain.com/2013/08/02/how-serious-is-google-about-dart/ <comment><USER2> Never rely on Google for anything - always have alternatives. In the case of Dart, the alternative is that it is open source, which means if (read: when) Google drops Dart, other developers can continue to support it.

However, Dart is a 'full stack' solution. This means that any developer taking over Dart would have to support the IDE, the VM, the javascript transcoder, the language, integration with new browser features, cross browser compatibility, etc. This is practically impossible for hobbyists to do properly.

Why would Google drop Dart? Google is almost guaranteed to drop any project that does not have high traction and/or high income within a few years of release. Dart has neither income nor traction. If Google does not drop it, I will be very surprised and impressed.

I highly recommend avoiding Dart, but obviously the choice is yours. You've been warned.

EDIT: Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. If Google does this it would be a pretty evil thing to do and go against the spirit of the web.

If your ethics are a bit lacking, you may want to try betting on this effect which would create a demand for Dart dev houses in the future, and could make you some cash.

<comment><USER3> Standard disclaimer, I work on Dart. And normally I'd avoid engaging a borderline troll, but this is such a terrible comment, in so many ways, that I have to speak up.

> Never rely on Google for anything

First, you're expectation that Google will drop Dart is based on what exactly? A few SaaS product cancelations? The "never rely on Google" meme is getting so old, mainly because it's overly applied to Google when all SaaS providers have this issue, and it's been a known downside for years: when product support ends for an installed app, you still have the old installed app to use, when support is ended for SaaS users have a problem. I hope this can be mitigated one day, but that's a whole other topic. The differences with Google is that we have a ton of users even for our "small" products, and there's a single name to attach attention to, rather than the numerous shutdowns that have happened in other companies, or the startups that have bee bought and killed.

The important bit for the discussion at hand is that Dart is not even _anything_ as a service. It's a set of installed, open source compilers and libraries. They will continue to work in the (unlikely, IMO) event that Google drops support.

> This means that any developer taking over Dart would have to support the > IDE, the VM, the javascript transcoder, the language, integration with new > browser features, cross browser compatibility, etc.

Dart's more of a collection of independent pieces. If Google ever did completely drop Dart I'm pretty sure that the parts could be maintained by the community (assuming the community hits critical mass). The dart2js compiler is the most important part and it's well structured, easy to understand code. The IDE could be abandoned in favor of plugins for WebStorm (already maintained by IDEA), Sublime, vim, etc.

> Dart has neither income nor traction.

Dart will never have income, that's not its purpose. Dart's purpose is to make web development easier, more productive and more scalable, and web apps themselves faster. This goal is both for internal development, for which we badly need something like Dart, and for everyone else because we want to see more and better web apps.

As for traction, if Dart doesn't get any traction (after it's actually released, and had a good chance to succeed of course!), inside Google or outside, then it probably _should_ be abandoned, right? In that case, who exactly is there to care that it's not developed anymore?

I've heard some people point to GWT as an example of what might happen to Dart. I don't agree, but for the sake of argument, let's look at where GWT is: 1) There's an official community maintaining GWT, 2) Google still has a team working on GWT, and large projects using it. 3) GWT will still get better as Java gets better. There are other factors that apply to GWT and it's language that don't apply to Dart. If Dart's fate was ever the same as GWT, I'd say it'd be a pretty soft landing for everyone.

> Just to add, Google can artificially increase traction of Dart by putting > the Dart runtime inside Chrome and using that as a weapon to increase Chrome > adoption, similar to Microsoft's ActiveX strategy.

This is still a ridiculous comparison. ActiveX was a plug-in architecture. Dart compiles to JavaScript. We support all "modern" browsers, IE9 and up.

Look, we've made no bones about wanting to get the VM into browsers some day. And obviously, being part of the Chrome team, we'd like to see it in Chrome. Lars pointed out at Google I/O that there's work already being done to pave the way for this on the memory management side. The Dart VM does enable faster and quicker to startup applications, no doubt.

But we all understand that Dart will be distributed as JavaScript for the foreseeable future, and we do considerable work to ensure that programs behave the same in dart2js and the VM, and that the JS output is very fast. The Dart and Chrome teams firmly believe that the adoption of Dart will entirely depend on it's success as a compile-to-JS language. How Dart helps developers will be its main draw, and hopefully there's organic demand for the VM as an accelerator for apps that already work well across the web.

This will not be "evil" in anyway, but one of many ways that the browser vendors have pushed the web forward. There are so many examples of a vendor pushing something that's initially totally or somewhat proprietary but end up being a great thing for the web, that only comparing Dart to ActiveX is just juvenile and annoying. Consider JavaScript itself, XHR, <canvas>, CSS, SVG, WebGL, setImmediate() and so many other DOM APIs, CSS extensions like rounded corners, shadows, transforms, etc. Some of these have actually been much more backwards-incompatible than Dart which primarily _compiles_to_JS_.

The FUD around Dart is just incredible. No matter though. We see the benefit every day that we luckily get to code in Dart, and so does our community. Those who wish to reap the benefits Dart can opt-in and those who don't can ignore it.

<comment><USER4> >As for traction, if Dart doesn't get any traction (after it's actually released, and had a good chance to succeed of course!), inside Google or outside, then it probably _should_ be abandoned, right?

Yep. So goes the argument. When/how is it going to be released in a meaningful way, such that it can 'actually' gain traction?

People are using CoffeeScript and Typescript in production _right now_. Dart has been a theoretical project for far too long.

>The Dart and Chrome teams firmly believe that the adoption of Dart will entirely depend on it's success as a compile-to-JS language.

Yep. It's not doing so well.

>The FUD around Dart is just incredible.

Maybe it's not FUD, maybe it's legitimate criticism.

In any case, I wish you good luck.

<comment><USER3> Dart 1.0 will be released pretty soon, as Lars & co, have said. It takes a long time to create a new language and core libraries from scratch.

But I can't believe you complain that it's not released yet, and that it doesn't have much traction in the same post...

I think Dart adoption is going along just fine, considering it's pre-release state for the last two years. If too many people had already starting using it, they might have had unmeetable expectations about it's stability and readiness. Better that there are fewer early adopters who are aware of and willing to take the pain of the evolving platform.

<comment><USER5> > _But I can 't believe you complain that it's not released yet, and that it > doesn't have much traction in the same post..._

Where's the contradiction?

For one, other projects have gotten traction LONG before the stable release. Mongo and Node.js come to mind.

Second, the complaint can be stated as: "If you want it to gain traction, why do you keep tinkering on it for such a long time without a stable release"?

<comment><USER6> Damned if you do and damned if you don't. If they release it and iterate on it for years in the public before official release, you complain about adoption or lack of users.

If they were to bake it internally first until it is stable and then release it "done", then everyone complains about a closed process.

And do you have any numbers to compare Dart vs Typescript vs CoffeeScript adoption?

<comment><USER5> > _If they were to bake it internally first until it is stable and then > release it "done", then everyone complains about a closed process_

Well, Go did just that, and I didn't see anyone complaining.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> > How serious is Google about Dart?

It depends. I spent a lot of time looking at Dart in the first part of this year. My impression is that the team developing Dart is very serious and enthusiastic about it. Dart makes web development fun again. It's easy to try things and throw them away if you get a better idea in the process. Building large apps is easy. The success of Dart doesn't only depend on success in the browser, because a lot of effort is being put into Dart on the server, where it hopes to compete with Nodejs and replace Java for some uses. Another motivation for Dart is that it is not influenced in any way by Oracle, who has sued Google over Java. Dart may shine on mobile devices where old browsers are not an issue, that remains to be seen.

Who is not enthusiastic about Dart at Google? I would say the Chrome team and the Closure team, based on a lot of reading and watching videos, are not enthusiastic. This is just my impression. I have no inside information. As far as I know, Dart is not being used internally.

The Chrome Frame issue caused me to switch to TypeScript, which I also really like. It's not as much fun as Dart, but it certainly makes JavaScript a lot more verifiably correct, with type annotations making code refactoring and type checking possible. TypeScript is an ok alternative to Dart. They feel similar, they each have their uses.

I wouldn't bet the company on Dart, but I would on TypeScript, which could go away and you'd still have perfectly readable and sensible JavaScript files to work with. As Anders Hejlsberg (designer of C# and TypeScript) says, "we don't obfuscate your code."

It's easy enough to learn Dart. There are places even now where it makes sense to use Dart. If JavaScript is an old internal combustion engine car, then TypeScript is one with automatic transmission and power steering, while Dart is a new electric car. I'll drive all three as long as they get me where I'm going.

<comment><USER3> FYI, Dart is starting to be used internally, on multiple projects, and some pretty large ones.

And Dart's part of the Chrome team, if Chrome wasn't enthusiastic about Dart, Dart wouldn't exist.

<comment><USER7> I get my impression from this video

[https://www.youtube.com/watch?v=TlJob8K_OwE](https://www.youtube.com/watch?v=TlJob8K_OwE)

Skip to &t=17m26s and you can hear them talk about it. Judge for yourself.

</comment></comment></comment><comment><USER8> Developers. Developers. Developers...

I'd love to know if there's an internal debate inside Google and if they are aware of how much recent decisions have damaged their reputation amongst a critical demographic.

I could not understand the decision to drop Chrome Frame. It seemed like a good strategic product but even more so - a lot of people had staked their reputation on a technology choice because of it's existence. These people were the thin end of a wedge inside enterprise cultures that were historically dominated by Microsoft evangelists. Google has now pissed off these people and made them look bad.

<comment><USER9> Conversely I never saw the point of Chrome Frame. Most enterprises that lock their users into IE certainly also forbid them from installing arbitrary browser plugins.

<comment><USER8> Chrome Frame doesn't need admin rights to install so I presume it bypassed a lot of IT lockdown?

<comment><USER9> Chrome itself doesn't need admin rights to install either.

</comment></comment></comment></comment><comment><USER10> Greetings, I'm someone who is using Dart in production I can tell you that is promising and the community is growing.

The only problem I see is that Dart developers are focusing to much in the newer stuff w/o ironing the basics first, for example, the DateTime datatype can't parse this: "2013-08-03 12:00" but can parse this: "20130742", and to me is more important to work in those basics than all the fancy Canvas stuff or polymer.

We don't know the level of compromise Google has with Dart, I'm taking the risk cause I think is worth it.

<comment><USER11> It's somewhat disconcerting for Dart to merely be seen as "promising", especially given its competition.

It would take a lot of effort to do worse than JavaScript.

CoffeeScript is basically just JavaScript with a Ruby-inspired syntax.

TypeScript is only a very minimal set of improvements to JavaScript.

If it's doing things right, it should be blowing all three of those away with ease, especially given its origin. The fact that its uptake is so slow suggests that it isn't competing against them very well, which I take to be a bad sign going forward.

<comment><USER3> Dart's uptake is slow because it hasn't really been released yet. It's pre-1.0 and has been evolving pretty rapidly until recently. I'm not worried.

</comment></comment></comment><comment><USER12> I am puzzled by low-quality, hyperbolic, panicky articles like this. And I'm even more surprised by the reaction they cause on HN.

[http://blog.chromium.org/2013/06/retiring-chrome- frame.html](http://blog.chromium.org/2013/06/retiring-chrome-frame.html) seems like a pretty good reasoning w.r.t stopping updating Chrome Frame and lists alternatives. What's all this noise about? And what the hell does this have to do with Dart?

<comment><USER13> Yakov Fain is a world-class whiner and master of hyperbole. He was always the "squeaky wheel" in the Flash/Flex community, and it doesn't surprise me that he's still whining.

Why it's being picked up by HN is beyond me... maybe because Google is the favorite scapegoat recently? Certainly few people bothered reading what he wrote and just started commenting/complaining.

It's astonishing to me that Google is getting flak for dropping (in 5 months) what amounts to a 3rd-party-patch for a browser that'll be turning 5 years old. They already dropped support for IE8 in Google Apps, and jQuery dropped support several months ago.

If Fain wants to play with fancy new technologies, he should find clients who want to use new technologies.

</comment></comment><comment><USER9> _I hope Google will provide some iron clad guarantees that their Dart project will be around for the next 5 years_

5 years is a lifetime in web technology. 5 years ago nobody was using coffeescript, angular, ember, or any of that. They didn't exist, or if they did they were crude ancestors of what they are today.

I just don't think you can have this expectation of any guarantees like that in web development. Things move too fast. If you want that kind of guarantee, use open source stuff and acknowledge that you'll have to support it yourself when the rest of the world moves on.

<comment><USER14> Here's my problem with this line of thinking: Dart is supposed to replace one third of the triad of core technologies web developers use: HTML, JS, and CSS. It doesn't appear that in the long term it's intended to be transcompiled to JavaScript. CoffeeScript is only intended to be an alternative that transcompiles to JS. There's no effort to build a CoffeeScript VM. (C8? CoffeeMonkey?)

Angular, Ember, etc are just frameworks. They're not likely to be as long- lived as the triad of front-end web development technologies because the creation of such a framework has a significantly lower barrier to entry and adoption. There's no W3C committee overseeing development and there will be no W3C draft or standard for any of these somewhat ephemeral frameworks.

Core web development technologies are very stable and their development, deployment, and adoption happens quite slowly; on the order of decades. If Dart does become widely adopted (and with the support of browser markers) it'll likely remain in place for a long, long time, far longer than the latest JavaScript framework or veneer language de jure.

Even if Dart does become widely adopted, Dart hasn't got a hope of truly replacing JavaScript, at least for the foreseeable future (>10 years), as both a Dart VM and a JS VM would have to coexist in all browsers for reasons of backward compatibility. Yay, browser codebase bloat!

</comment></comment><comment><USER15> Before Google Reader was cancelled I don't remember people worrying this much online about each new Google service and its longevity.

Seems like a non-issue to me. When we run out of real criticism against Google we just make some up because they're big and.. you know.. playa hatin'. ;)

Try to remember that it's first and foremost a search engine with ad-revenue. Anything else is a product of a liberal work environment and driven employees.

<comment><USER16> _> Try to remember that it's first and foremost a search engine with ad- revenue. Anything else is a product of a liberal work environment and driven employees._

But that's actually a _really good reason_ to hesitate a bit before betting your own project's success on anything they put out that isn't directly related to the search engine or the ad products. It's not "playa hatin'" to recognize that things from Google that aren't strategic to them may get dropped some day, it's just being pragmatic.

</comment></comment><comment><USER6> This article isn't about Dart, it's about IE6 and ChromeFrame. Microsoft itself is discontinuing support for IE6 next April. Period. It's dead.

You're blaming Google for not supporting a dead platform that not even Microsoft is going to support any longer.

It's time to upgrade your internal systems. Don't blame Google for not wasting resources on a shitty broken browser that causes developers to waste time supporting.

IE6 needs to die, die, die.

<comment><USER8> Chrome Frame is also useful for later IE versions. IE8 is becoming the thorn that IE6 once was.

</comment></comment><comment><USER17> FWIW, Haxe is a solid alternative if you're looking into alt-js or cross platform (mobile) development: [http://haxe.org/](http://haxe.org/)

It doesn't have the money of Google, but it has been around for 8 years, and is backed by its own non-profit foundation. It just recently hit version 3.0: [http://haxe.org/manual/haxe3/features](http://haxe.org/manual/haxe3/features)

It continues to make steps forward with new cross-platform development frameworks like openfl. [http://www.openfl.org/](http://www.openfl.org/)

</comment><comment><USER5> > _During the meeting one person said that about 15% of our users are still > working with older browsers and we don't want to lose them if Dart-generated > JavaScript won't work in Internet Explorer 7 or 8. I immediately answered > that this wouldn't be an issue, because several years ago Google created a > smart way to automatically download Chrome's JavaScript VM if the > application runs inside IE. The name of this smart solution is Google > Frame._

Err, Google Frame is not a "solution" for Dart not running on older IE browsers and it doesn't just download "Chrome's Javascript VM". It's (was) a way to install a different web engine for IE altogether, based on Chrome.

Second, it's not "automatically downloading" (which might give the impression that it's transparent to the user) -- you have to install it.

</comment><comment><USER18> It is loosing to TypeScript already.

</comment><comment><USER19> I was playing with Dart and found it really nice for both server and client side development. However, I ended up setting Dart aside (as I did for ClojureScript) and worked on my JavaScript skills.

<comment><USER3> I hope you check it out again as we reach 1.0. We're going to be able to give server-side some more attention after 1.0 too.

</comment></comment><comment><USER20> Didn't Larry Page say "we're putting more wood behind fewer darts" when he took over?

<comment><USER21> fewer arrows

</comment></comment><comment><USER22> Google didn't have a choice about Chrome Frame. The new Internet Explorer 10 doesn't support plugins that are as invasive as Chrome Frame. See [http://msdn.microsoft.com/en- us/library/ie/hh968248%28v=vs.8...](http://msdn.microsoft.com/en- us/library/ie/hh968248%28v=vs.85%29.aspx)

Chrome Frame on older Internet Explorer versions shouldn't really need to be updated that much, since those browsers aren't changing that much. Also, I find it really hard to believe that the kind of IT department that decrees that everyone has to use IE6 (or whatever) would ever allow such an invasive third-party plugin as Chrome Frame in the first place.

The limited browser compatibility of dart.js is a real issue and probably is a dealbreaker for some enterprise situations. But there's no need to bring Google Reader into this-- it has literally nothing to do with it.

The other thing which everyone seems to be missing here is that even if Google does "become bored with Dart," there will still be an open source community to support it. Coffeescript has been around forever without any sugar daddy. A big part of the reason for using open source technologies is to avoid vendor lock-in and other similar questions about the future.

<comment><USER23> It is very difficult to move a non-trivial product from corporate developed with source code available to community developed even if both are technically open source.

If things like design docs & decisions, the main bug tracker, commit rights, and so on are all internal you end up with no one with the institutional knowledge to take over if the company decides to drop it. The most famous example of this is probably the open sourcing of Netscape Navigator which lead to a four year gap before the next release, due to a ground up rewrite.

</comment></comment><comment><USER24> Dart is part of Google's strategy to replace open-standards with its own proprietary walled-garden. Let's hope it doesn't work. Stay away from Dart.

<comment><USER6> Stay away from Kool Aid. ;-) Really, this is unfounded and unjustified speculation.

<comment><USER2> Hi Ray

I respect your work a lot, but are you sure your view is not biased a bit by working for Google? It's sometimes hard to disconnect from that kind of working environment to see the kind of issues into the future certain practices can have.

Dart turning into something bad for the web is really not all that unfounded or unjustified. You don't have to agree, but you shouldn't dismiss that argument so quickly.

Dismissing this kind of thing is what leads to 'impossible' scenarios happening. The point needs to be raised, repeatedly, and hopefully within Google as well. As long as a possibility exists for Google to misuse Dart, there needs to be voices speaking out against that possible misuses _before_ it occurs, not after.

<comment><USER6> Dart is no more an attempt to replace the web with a walled garden than GWT is (which is what I work on). It is a tool, like Typescript, like CoffeeScript, like ClojureScript, like Emscripten. There's no "plan" to create a lock-in walled garden based around programming language.

Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native.

Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance.

There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript.

The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower)

The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.

<comment><USER25> The asm.js comparison is a false equivalence. It is not possible (without explicit effort, e.g. checking the UA string) for Web authors to ship asm.js that does not work in Chrome, because asm.js is just JavaScript. With Dart, Web authors may end up not shipping the JS fallback, or not testing it, thus locking the Web into Chrome. That is why turning on the Dart VM for Web content would be a problem.

<comment><USER6> It's a false equivalence in theory, but in practice, I don't think so. Realistically, how many developers are not going to ship something that doesn't work on Firefox and Safari, especially, Mobile Safari? Especially when the tools to do this are trivial and automatic.

It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort?

Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.

<comment><USER25> Of course people won't ship something that doesn't work cross-browser today. But by that logic, no proprietary feature is worth worrying about. Consider a hypothetical future in which Chrome had 90% market share: as a Web dev, would you bother shipping or testing the JS fallback?

History tells us what will happen.

<comment><USER6> If Chrome gets 90% marketshare, there'll be other problems besides Dart. History also tells us that even if all vendors adhere to standard specs, there will be implementation differences and bugs that still require developers to write browser specific code and fixups.

Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen _because of Dart_ , but because of other forces. The criticism over the DartVM is being blown way out of proportion.

The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> > Still forced to support IE 7/8

I want people who use this shit to die already.</comment>


Inside The Netflix/Comcast Deal and What The Media Is Getting Very Wrong - <AUTHOR> http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal-getting-basics-wrong.html <comment><USER2> "Given that Netflix has many options to buy transit from many different transit providers, why would they pay more? They wouldn't."

Spot on. This is why most reporting about the issue has been wrong. Granted this article isn't perfect, its shows much more insight than others.

<comment><AUTHOR> What I appreciated was they he calls himself out for not being a true expert, but did his best to understand the situation.

<comment><USER2> No kidding. His take was much more accurate than others AFAIK.

</comment></comment></comment><comment><USER3> I love how this was pushed to the bottom.</comment>


Who Killed Lard? (2012) - <AUTHOR> http://www.npr.org/blogs/money/2012/02/03/146356117/who-killed-lard <comment><USER2> The lipid hypothesis did it. The idea that fat and dietary cholesterol cause obesity and heart disease.

Here in Poland there are still many dishes that require lard as a cooking oil - "chrust" or angel wings, a friend pastry known all over the Slavic world is one that comes to mind.

Heavily salted lard, often with bits of bacon, apples and onion is used as a spread on dark bread. It's amazingly delicious, especially in the winter with some sour pickles. These are traditional winter foods here - salted lard would hold forever and sour pickles are a seasonal delight.

<comment><USER3> _The lipid hypothesis did it. The idea that fat and dietary cholesterol cause obesity and heart disease._

That's only half the story though. The factually wrong part (fat in == fat deposited). The other part, that is still factually correct and hence a good reason to avoid lard, is that saturated fats absolutely and unequivocally lead to atherosclerosis and coronary artery disease.

I'm surprised how easily the 'bad' fats are getting a free pass in the name of decriminalizing 'fats', in the bleeding-edge of dietary pantheon.

<comment><USER4> > saturated fats absolutely and unequivocally lead to atherosclerosis and > coronary artery disease

This isn't true at all. Too much saturated fat, perhaps, does, but this idea that if a drop of saturated fat crosses one's lips, you'll die a horrible death in 5 year is just plain silly.

<comment><USER5> That idea is just plain silly. And who exactly advocates it? It's just a plain, silly straw man.

<comment><USER6> Advocate that no, but I know people (ok a person, vegan),who I consider sane in all other bits of their lives, who believe the first half of that straw man (if not the timeline bit). Diet and health make people act completely nuts - and things you think are straw men are sometimes things people actually believe.

</comment></comment></comment></comment></comment><comment><USER7> Interesting article, but perpetuates the misunderstanding of that Sinclair's "The Jungle" was intended to be all about food hygiene, rather than an indictment of the awful labor conditions in the meat industry.

<comment><USER8> Quite. That point cannot be iterated frequently enough.

</comment></comment><comment><USER9> Lard does make better pie crust than vegetable shortening -- no joke.

Near DC, we had some friends with a farm on the water near Annapolis. They had some cherry trees, sour, red cherries, that they had cared for properly and, then, a lot of fresh cherries. So I offered to make a cherry pie.

They had no vegetable shortening but did have some lard; so I used lard. I cleaned, pitted, and cooked the cherries with sugar and corn starch, partly guessing on quantities from a poor cookbook. Then for the pie crust, I just did what I'd done a few times with shortening. The lard based pie crust was much more delicate -- the raw crust tore during handling!

But the resulting pie was terrific, especially the crust!

If can get some fresh cherries and lard, go for it! Or just make little cherry tarts!

</comment><comment><USER10> I grew up in North East Scotland and therefore must have consumed a vast amount of lard in the form of "rollies" (AKA rowies/butteries/Aberdeen-rolls).

[http://www.stronach.co.uk/2013-02-04/how-to-make-the- classic...](http://www.stronach.co.uk/2013-02-04/how-to-make-the-classic- buttery)

I have fond memories of consuming rollies that were completed soaked in melted butter on a trawler somewhere in the North Sea - about the only pleasant memory I have of that particular trip...

<comment><USER11> I never put any thought in to what butteries were made from but the salted taste and texture was absolutely delicious and plenty a lunch-money coin was spent on them! Ironically the reason I wouldn't eat them now that I do think about ingredients is all the flour.

Another favourite from that era was a scotch beef pie that contained a layer of mashed potato and a small clump of baked beans on top of that.

<comment><USER10> I had a traumatic incident with scotch beef pies in my teens - never touched one since.

<comment><USER12> You mean just a Scotch Pie? I've never been clear on what was inside them, I just remember eating them at Pittodrie as a kid and then being dubious about them as I grew up.

Plain old Steak Pie (i.e. what those who didn't grow up in Scotland would probably interpret "scotch beef pie" as) though are fine and I miss them dearly - as do my fellow expats who are from NZ, they've got a bit of a pie culture too as I understand.

<comment><USER13> That description makes them sound like they were sold by Cut-Me-Own-Throat Dibbler :) (sorry for the OT).

[http://discworld.wikia.com/wiki/Cut-Me-Own- Throat_Dibbler](http://discworld.wikia.com/wiki/Cut-Me-Own-Throat_Dibbler)

</comment></comment></comment></comment></comment><comment><USER14> I wonder if many of you have ever actually cooked with lard? The stuff stinks when heated up to the point it makes me retch. It's not fun stuff, and its more widespread use would make life even more difficult for vegetarians.

<comment><USER15> Growing up in the 70s in the UK, we used it for all frying, etc. Everyone did, but switched away at the start of the 80s because the new message was "sunflower oil is healthier".

Lard also makes me retch if I smell or taste it nowadays. The only reason I buy it is to make food for birds (lard + sunflower and other seeds).

</comment></comment><comment><USER16> My preferred fat for cooking is my own home rendered beef dripping. I can get a huge bag of it from my local butchers for dirt cheap. Chop it up, stick it in the oven for a couple of hours (normally while I have a roast dinner cooking) and then filter it.

The flavor is incredible and I can guarantee that the fat is from free range animals with zero additives.

<comment><USER17> I find beef dripping far superior to lard for roast potatoes.

<comment><USER18> But surely not better than goose fat?

<comment><USER17> Roughly even, actually!

I've also had quite a lot of success with a half-butter, half-olive oil mix.

</comment></comment></comment></comment><comment><USER19> Health is only part of the issue. The growth of ethnic minorities worldwide whose dietary restrictions keep them away from lard is probably very significant.

Devout Hindus, Muslims, and Jews won't consume products containing lard derived from pigs. I'm surprised that factor wasn't covered at all in this article.

<comment><USER20> Very true. I'll often ask when I'm dining out whether something was cooked with lard, especially at Mexican restaurants. Nearly everything in Mexican restaurants is cooked with lard.

<comment><USER8> Having seen large-scale preparation of Carnitas, I can attest to the amount of fat and grease produced in the process. It gets over _everything_.

</comment></comment></comment><comment><USER21> You can buy lard in every UK supermarket.

<comment><USER22> For those of us who don't buy into the £5 jars of duck/goose fat, lard makes for exceptional roast potatoes :)

<comment><USER23> I've never bought a jar of goose or duck fat. We will just cook a goose or duck and collect the fat afterwards. The product isn't as pure, but you're getting a whole, tasty meal out of it, so it's much more economical that way.

I have been cooking with lard for about 20 years. It's just something that my family never stopped using. I learned to cook from my father and his grandmother, and she always asserted the superiority of lard over Crisco, even going so far as to setup blind taste tests (that 85 year old woman was more of a scientist than most of the scientists I know today). Growing up in a rural area, it was readily available in all of the grocery stores. Even though most of the stores here in Alexandria carry it, they usually only have it in small tubs, about the size of a large tub of sour cream. The stores back home had it in bulk-sized canisters of all the same sizes that Crisco came in.

I'm also quite a fan of collecting bacon fat. Filter it through a paper towel first and it makes a wonderful oil for cooking eggs and sauteing vegetables. I've been known to cook an entire pack of bacon in the morning just to have the oil available for making dinner. Having cold, cooked bacon available in the fridge for the next week is a nice bonus.

</comment></comment></comment><comment><USER24> I remember just a few years ago everybody being afraid to eat meals made with coconut oil as well, but, thank god, it's omnipresent now and red palm oil is quickly catching up (which is not necessarily good for the natural habitat affected, so, be selectively when you buy it). Ansel Keys is to be blamed, he fake evidence to shape the Lipid hypothesis and he himself didn't abstain from saturated fats and meat.

</comment><comment><USER25> Note that most lard you can buy in the grocery store contains trans-fat and should be avoided. Pure unprocessed lard must be refrigerated or frozen.

</comment><comment><USER26> Ah damn. I saw Robert Smith and LARD and thought the singer of The Cure wrote an article about the death of Jello Biafra's side project.

<comment><USER27> Haha, I had the exact same initial thought!

The original LARD release ("The Power of Lard") was completely awesome (as with most things Jello Biafra does)... is their other stuff good?

<comment><USER28> Probably not... otherwise it'd be much more "well-known"

</comment></comment></comment><comment><USER29> I'm not sure how applicable this is to the US. But here in the UK the decline of Lard, (which was everywhere when I was growing up as a child) could be also attributed to the fact that there has been an increase in the number of vegetarians and ethnic minorities. These groups dietary demands would have a strong influence on restaurants and takeaways that are looking to cater to the largest audience size as possible.

<comment><USER30> I agree. I think in some places in North America, a growing population of, for example, Muslims, may have had some influence into the move away from lard in certain restaurants.

The omnipresent Canadian chain, Tim Hortons, for example, stopped using lard in it's baked goods in 1997 and I seem to remember at the time this was partially due to a lobby from Muslim community groups.

</comment></comment><comment><USER31> In Germany Lard is generally not used for cooking anymore. Instead plant based oils are used or concentrated butter (called Butterschmalz, similar to Ghee).

But at least in the south it's available in every supermarket in several kinds. Some pure, some spiced. It's most commonly used as spread. But it's a matter of taste. Some fancy restaurants serve the bread they serve in advance not only with butter but also with lard.

</comment><comment><USER32> Similar: popcorn used to primarily be cooked in coconut oil. Then we had the campaign against saturated fat and theatres switched to vegetable oils. Decades later we discover that the MCTs in coconut oil are awesome for cardiovascular risk.

<comment><USER33> I'm not saying that you're wrong (because I don't know) but the 2nd paragraph on wiki seems to suggest different: [http://en.wikipedia.org/wiki/Coconut_oil](http://en.wikipedia.org/wiki/Coconut_oil)

<comment><USER34> I am not sure if it is good are bad but i know a state(Kerala) in India where entire food is cooked in Coconut oil and it is awesome and i have not seen their heart or other health point well in comparison to other states.

I think the matter is that eat what is naturally available in the environment you live and it should be ok. Also with food act always like dont have money to spend more than what you really really need then we should be ok.

<comment><USER35> > I think the matter is that eat what is naturally available in the > environment you live and it should be ok.

Because we all live on the African savannah, where humans evolved?

<comment><USER18> Significant evolution has occurred since homosapiens left the savannah.

</comment></comment></comment></comment></comment><comment><USER36> I see it in every supermarket and some people still have it as a spread on a toast for breakfast.

But it's true most restaurants switched to those [s]cheap ass[/s] healthy vegetable oils.

</comment><comment><USER37> Eskimos still eat large amounts of blubber without issue.

</comment><comment><USER38> ["It seems funny," Silver says, "but for thousands of years this was the thing that people cooked with.]

Not true. Olive oil use go as far as 5000BC. Lots of other animal fat were used too.

Germanic countries used Lard a lot, they needed enormous amount of fat to survive the winter. By the way, in my opinion Germanic food is one of the worst in the world, and I had traveled a lot.

They also used a lot of butter.

Going to the north people used seals, whales and even bears.

In North America they ate Buffalos, in Ecuador they ate llamas. In China they used lots of different fats.

Only a small amount of people in the ancient world ate big amounts of lard in their food.

<comment><USER39> Wait - lard can come from all of those animals. Render any fat - its lard.

<comment><USER38> In Spanish we use different words for lard of different animals.</comment></comment></comment>


Adding the accessibility in your React Apps [video] - <AUTHOR> https://www.youtube.com/watch?v=E4Di8Xi9LUA <comment><USER2> Egghead recently made this React Accessibility course free: [https://egghead.io/courses/develop-accessible-web-apps- with-...](https://egghead.io/courses/develop-accessible-web-apps-with-react)</comment>


My Year in Review: 2019 - <AUTHOR> https://www.susanjfowler.com/blog/2019/12/10/my-year-in-review-2019 <comment><USER2> Not really related to tech, but I find it interesting that she went from software engineering to being an editor for the New York Times and writing books.

That being said once you've been a whistleblower, even for good reasons, sadly, it is probably harder to find another job in your previous area of expertise...

<comment><USER3> Her whistleblowing doesn't seem to me the kind that should create distrust. It's not as if she taped conversations relating to financial practices. She stood up to a company culture that a lot of qualified observers thought toxic.

Anyway, it's well that she sounds cheerful. She seems to have been quite good at what she did in tech, and I hope that she will consider going back to it.

[edit: corrected spelling of "observers"]

<comment><USER4> I find it weird that on her main page [0], she has put a large photo of hers with the title "Whistleblower". I mean, since when did whistleblowing become a profession/job?! And for someone who's supposedly working in the tech industry, does it really reflect good on the person to identify herself mainly as a whistleblower?

[0] [https://www.susanjfowler.com/](https://www.susanjfowler.com/)

<comment><USER5> Whistleblower is the title of her book.

</comment></comment></comment></comment><comment><USER6> Writing was one of my goals for 2019. Couldn't write a single piece. A mix of impostor syndrome and lack of discipline I guess. Sometimes I get nice ideas about something to write and then when I start typing I think, 'this is just bad' or 'no one is going to like this'.

To the people who write: how do you decide what to write about? Do you play and research with tools and thoughts, and write about that? Or mostly about things you actually do at work?

<comment><USER7> In order to be able to write, you need to have something you _actually_ want to say on something you are actually interested in. Writing, is about expressing ideas, so you need some sort of idea, and then you need strong convictions and opinions surrounding that idea. What you DON'T need, is to be unique, smart or good at the technical aspects of writing. If you believe this to sound wrong, just read an Op-Ed in NYT.

You also have to face the idea, that maybe you actually don't want to write. HN is obsessed with writing for the sole reason that it ostensibly builds clout and ultimately makes you more money and validates you as "an important person".

If after all of this, you still want to write, but you really don't have a strong opinion or idea, choose a topic, research it, and share it.

Also, again maybe you need to expand your interests and try and pick an ideology so that you have opinions on things. Listen to a lot of people/podcasts/books with strong opinions, form friend groups with people with strong opinions, fight them on their ideas by researching counters to their opinions. Take stances and argue from a position that you don't believe, etc. This could be anything from gender in tech, to free markets vs regulated markets, to TDD is good vs TDD is bad, to Remote is good vs Remote is bad, etc, etc.

<comment><USER8> Agree with this. I felt the same about writing, but eventually found that having strong feelings about my chosen topic helps a lot.

I've never been able to write for the sake of writing, so I only author posts when I feel strongly about the topic. There are days or weeks when I don't care to write anything and that's ok. Eventually you run across something interesting and BAM, you can barely type fast enough to keep up with your thoughts.

</comment></comment></comment><comment><USER9> There was a blog post by her that I happen to read, called "Life Without a Destiny"

[https://www.susanjfowler.com/blog/2017/5/21/life-without- a-d...](https://www.susanjfowler.com/blog/2017/5/21/life-without-a-destiny)

What she wrote there totally resonated with me and stayed with me from the day that I read. It was as if she managed to put what I have been wondering into words.

</comment><comment><USER10> As an aside, what a great 2019 reading list!

[https://www.susanjfowler.com/reading- list](https://www.susanjfowler.com/reading-list)

<comment><USER11> Wow. Thats more than book/week. Is it really possible to absorb that amount of information. Won't you simply forget what you read in a very short time after, like almost immediately.

<comment><USER12> A lot of it is fiction, so I would assume it is for enjoyment. No need to remember all of it.

</comment></comment></comment><comment><USER11> > she was denied a formal education–yet went on to obtain an Ivy League degree

Now an editor at NYTimes. Amazing resolve.</comment>


Show HN: Quma – Plain SQL in Python - <AUTHOR> https://github.com/ebenefuenf/quma <comment><AUTHOR> Co-Author here. We wanted to have full control over our db/sql and think it's also easier to read this way (instead of using an ORM). Similar libs got posted recently, quma will provide you with namespaces, supports dynamic SQL (conditional WHERE), has a connection pool and generally makes it nice to work with.

It's also battle tested, we're using quma since 2 years in production (pyramid app) with ~350 sql files and are quite happy.

Would be cool if someone plays around with it. Questions welcome.</comment>


Mozilla Seabird Phone Concept - <AUTHOR> http://www.youtube.com/watch?v=jGPxDCTIBX8&feature=related

<comment><USER2> Looks awesome, but they are going to have to contend with battery life issues (for the projectors mainly), and visibility issues (the projector/keyboard etc would be nearly invisible in any kind of lighted situation).

<comment><USER3> Those are the least of this concept's issues. Who would take the time to design, QA and build this phone, not to mention put it into production, all the while not co-opting or diluting the vision put forth by Mozilla?

There's a lot of hating on business-people who "just need a technical founder" to take 500 bucks and actually _build_ the app. This concept just needs an entire business to re-vamp it's R&D division to implement Mozilla's idea. Physical production's a ton more coordination and effort than most apps, and it doesn't seem fair for HTC or whoever to take complete stake to do Mozilla's bidding.</comment></comment>


Good Overview of Modern Visual Application Builders? - <AUTHOR> I'm looking for good pointers on visual application builder tools.
It's been a long while since I needed to build relatively simple apps, and much has since changed (cloud computing, webapps etc).
In the past, things like Borland Delphi were a good starting point. Recently, I played with Google App maker, which seems almost 100% perfectly suited to build simple, SQL backed applications. It's reasonably expandable with server side and client side snippets, has a decent number of widgets and a decent deployment framework too. The fly in the ointment is that AppMaker only works for users in the same Google GSuite domain, so I cannot use it for general app building.
I'm loathe to start dealing with UI details in code and really like a visual tool that helps me focus on application logic.
I appreciate any pointers to such application builders. Ideally, they are free/open source, work on a Mac or linux or don't have heavy license handicaps.
Thanks! <comment><USER2> Since you're coming from Delphi, I've heard Lazarus IDE [1] is a decent open source replacement.

[1]: [https://www.lazarus-ide.org/](https://www.lazarus-ide.org/)

 _Disclaimer: I have no experience in either._

</comment><comment><AUTHOR> In addition to the comments below, I quickly looked at

* Bubble.is – UI looks great, but this is a full stack solution that requires hosting by them. * Lightning app builder – only runs on salesforce platform * Bobile – confused about this one, but it seems to focus on a special kind of sales mobile apps, and analytics.

* I _thought_ there were some UI building tools (ala balsamiq) that exported the UX into code.

Maybe I should just give up and deal with the FE UI directly in code. Even in GoogleAppMaker, code maintenance of larger deployments is not so easy. At least, it's easy to accidentally duplicate code, and hard to search and replace over all code snippets spread across all events and triggers.

</comment><comment><USER3> Retool tryretool.com seems like it'd do the job

<comment><AUTHOR> Looks great. Maybe a bit more rough than I'd love (e.g. tables look too much like spreadsheets), but seems pretty easy to get started with. I love the integration with Google Sheets as data sources ;)

<comment><USER4> If you're building internal facing apps, you can't go wrong with retool.

We've used it in production since before it became public and its served us well.

</comment></comment></comment><comment><USER5> Don't forget [https://stacker.app](https://stacker.app)

[Disclaimer: I built it!]

</comment><comment><USER6> Search for anvil.works. I never actually used it but the demo looked pretty cool, and it seemed pretty affordable.

</comment><comment><USER7> You could try looking at Microsoft PowerApps

<comment><AUTHOR> Thanks, that looks worth checking out. But look at at the pricing chart, it looks like it's again limited to a business domain, not create apps that can then be launched at the world. Maybe I overlooked something. Any general app framework would require a robust and extensible auth framework.

</comment></comment><comment><USER8> NativeScript I haven't used it btw.</comment>


Ask HN: Where to find remote tutoring jobs? - <AUTHOR> Preferably part time. <comment><USER2> Find the services and apply directly. These positions are contracted so they're almost always hiring.

<comment><AUTHOR> Thank you.

</comment></comment><comment> cljs-js-eval wyzant.com is a good start

<comment><AUTHOR> You have to be in the US to apply. It looks nice though. Thanks.</comment></comment>


Inventor or Innovator - Are Both True Entrepreneurs? - <AUTHOR> http://www.infochachkie.com/inventors-vs-innovators/#more-261 This article is a nice continuation of the questions first discussed in "Are You An Entrepreneur?"<p>I like the clear definitions of each person's role at a venture. <comment><USER2> For those of us who dream about bringing a life changing product to the world, this article brings great hope in the form of understanding why most inventors need innovators.

</comment><comment><USER3> Agreed. There really is no debate here, as both parties need each other. However, I do agree with the distinction that Inventors are like "parents who enjoy 'making babies' but abandon their children once they begin to cry."

Great line!

<comment><USER4> It's a ridiculous characterization of inventors: it sounds like the definition of a dilettante not an inventor.

For the most part it's difficult for inventors to appreciate where their inventions will find their first market. Peter Drucker details this in an interview in Inc. magazine [http://www.inc.com/magazine/19960515/2083_Printer_Friendly.h...](http://www.inc.com/magazine/19960515/2083_Printer_Friendly.html) which builds on his work in "Innovation and Entrepreneurship" [http://www.amazon.com/Innovation-Entrepreneurship-Peter-F- Dr...](http://www.amazon.com/Innovation-Entrepreneurship-Peter-F- Drucker/dp/0060851139/)

Drucker: The first entrepreneurial pitfall comes when the entrepreneur has to face the fact that the new product or service is not successful where he or she thought it would be but is successful in a totally different market. Many businesses disappear because the founder-entrepreneur insists that he or she knows better than the market.

Inc.: So, often the entrepreneur is actually succeeding but doesn't realize it?

Drucker: No, it's worse than that. He or she rejects success. You want examples? There are thousands of them, but one of the best is over 100 years old.

A man by the name of John Wesley Hyatt had invented the roller bearing. He made up his mind that it was just right for the axles of railroad freight cars. Railroads traditionally stuffed the wheels of their cars with rags soaked in oil to handle the friction. The railroads, however, were not ready for radical change; they liked their rags. And Mr. Hyatt went bankrupt trying to persuade them otherwise.

When Alfred Sloan, the man who later built GM, graduated from MIT at the head of his class in the mid-1890s, he asked his father to buy him Hyatt's small bankrupt business. Unlike Hyatt, Sloan was willing to broaden his vision of the product. It turned out that the roller bearing was ideal for the automobile, which was just coming to market. In two years Sloan had a flourishing business; for 20 years Henry Ford was his biggest customer.

</comment></comment><comment><USER5> I've never even heard of Philo before reading this. Did anyone else know that he was responsible for inventing the modern television? (He definitely wasn't the innovator who profited from it)</comment>


One-time Passwords in FreeBSD - <AUTHOR> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/one-time-passwords.html

<comment><USER2> Why md5 and not something more solid?

<comment><AUTHOR> OpenBSD skey and friends support MD5, RIPEMD-160, or SHA1 algorithms.</comment></comment>


Show HN: LegraJS – Draw using Lego-like brick shapes on Canvas - <AUTHOR> https://legrajs.com/ <comment><USER2> Love these types of projects! Very neat. Does the API use actual LEGO pieces? If so, could you render something and output a count of the pieces necessary so as to actually build it IRL? That'd be slick.

<comment><USER3> +1 for this feature! It would be pretty neat to combine this with a service that prints a 2D image using physical lego bricks. This is nerdy and silly, but I could imagine "printing" a successful fortress in DF this way (or another sliced 3D view.

</comment></comment><comment><AUTHOR> Here's a clock made with LegraJS: [https://legra- click.glitch.me/](https://legra-click.glitch.me/)

Source: [https://glitch.com/edit/#!/legra- click](https://glitch.com/edit/#!/legra-click)

</comment><comment><USER4> I've done something like this in Go: [https://github.com/esimov/legoizer](https://github.com/esimov/legoizer)

<comment><USER5> I also did something like this in JS with video support [https://github.com/kirkegaard/legofy](https://github.com/kirkegaard/legofy)

<comment><AUTHOR> These are really cool! The goal of legra was to provide primitives though and not just for images so one can draw dynamic, charts, shapes, animations.

</comment></comment></comment><comment><USER6> I'm reminded of one of my favorite music videos: [https://youtu.be/fTH71AAxXmM](https://youtu.be/fTH71AAxXmM)

</comment><comment><USER7> Looks very similar to legofy

[https://github.com/JuanPotato/Legofy](https://github.com/JuanPotato/Legofy)

<comment><AUTHOR> You're right. The goal of Legra is to provide all basic drawing primitives not just image rendering. So one can create dynamic charts, animations etc.

</comment></comment><comment><USER8> How do you create something like this? I.e. what are the keywords I'd look for if I wanted to create my own graphics library from scratch like this?

Very cool btw

<comment><USER9> Rasterization + whichever shape you want to draw.

E.g. "rasterization line" leads you to [https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm](https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm)

</comment></comment><comment><USER10> For paths and polygons you should just implement the 2d Path API

[https://developer.mozilla.org/en- US/docs/Web/API/CanvasRende...](https://developer.mozilla.org/en- US/docs/Web/API/CanvasRenderingContext2D#Paths)

      context.moveTo(x,y);
      context.lineTo(x,y);
      context.closePath();

<comment><AUTHOR> Thanks for the input. Next on my list :)

</comment></comment><comment><USER11> I wonder why no one, who implements some kind of JavaScript graphics library like this one, just mimics the Canvas 2D context API, so you could just drop this into your current application.

<comment><AUTHOR> That's the goal. Missing the 2d path api mainly. There are some interesting technical limitation for fill vs stroke. But for a fun hobby project, only limited time. :)

<comment><USER12> Can't you just replicate the entire 2d context api and pass through to an appropriately scaled (1px per block) offscreen canvas? Then pull the image from that and legoify it up to the display scale. That seems like a lot of unfun boilerplate to write, but ultimately an easier way to implement this, which would give all the gnarly parts of canvas without having to pull in external libraries ¯\\_(ツ)_/¯

<comment><AUTHOR> True but having raw parts would give it more flexibility when animating or changing sections of the image. Especially when the canvas size is large, it won't be as optimal

<comment><USER12> Optimality may be a function of effort, but your approach definitely seems like a more engaging approach. It's a cool project, thank you.

</comment></comment></comment></comment></comment><comment><USER13> Cool! For the image rendering, could you have a setting to constrain the colours used to currently-available Lego bricks? You might also offer dithering for better image matching.

</comment><comment><USER14> What would the optimizations be for a larger canvas?

Does it redraw the whole canvas when an update is made* to a single line when there are several other lines on the canvas?

*edit for spelling mistakes

<comment><AUTHOR> It doesn't redraw the whole canvas. The optimizations are really needed when 'filling' a shape. If you draw a large polygon, it may take a little longer to fill it with bricks. Optimizations can be made by using WebGL instead.

</comment></comment><comment><USER15> Great stuff. It would be awesome if you could select a brick type for a rectangle. You could make a 6x6 square and choose to fill it with 2x6 or 1x6 bricks.</comment>


Twitter's Tips for Making Software Engineers More Efficient - <AUTHOR> http://spectrum.ieee.org/view-from-the-valley/computing/software/twitters-tips-for-making-software-engineers-more-efficient <comment><USER3> Seems odd to take this advice from a company like Twitter when you compare them to companies like Instagram and WhatsApp. How to keep a lot of engineers busy and burn a lot of money, they could offer lots of good tips there.

<comment><USER4> Why? Because Twitter as a company hasn't produced effective revenue? Twitter (or their employees personal projects) has brought us Bower, Bootstrap, Typeahead, Flight and many other fantastic open source tools to make devs more productive. I think they are a great company to take advice from in this specific area.

<comment><USER5> > _Why? Because Twitter as a company hasn 't produced effective revenue?_

Because they're lecturing about engineering efficiency, yet they require 2,000 engineers to support their product. By comparison, WhatsApp scaled to 3X as many active users with a engineering team 1/40th the size. Instagram also runs circles around them in this respect.

For a team so huge and so productive, where is the output? More productivity tools? Maybe Twitter should pivot into that space.

<comment><USER6> Just the number of active users is a really bad metric in this case. WhatsApps product is much, much simpler than twitters products.

<comment><USER5> > _WhatsApps product is much, much simpler than twitters products._

Can you enumerate Twitter's products?

Perhaps Instagram is a closer comparison -- broadcast photos instead of broadcast 140 characters. And you have a much smaller engineering team, much faster growth, twice as many active users, and far fewer fail whales.

Regardless of the comparisons, 2,000 engineers seems excessive in proportion to Twitter's product, which suggests engineering inefficiency.

<comment><USER7> Don't forget that Twitter has a comprehensive advertising platform. The partnerships, sales, tooling, and ad auction system themselves are likely just as complicated (or more so) than the basic Twitter product.

Instagram has only recently started to monetize the product -- it's almost unfair to compare the size of the engineering teams supporting the systems.

<comment><USER8> It still seems bizarre to need two thousand software engineers for something whose functionality is as simple as twitter.

<comment><USER9> I believe the primary difference can be summarized in two words - <USER2> analytics. Twitter has a ton more analytics options for its users than WhatsApp appears to have mostly because, like Google, Twitter is more of an advertising platform than a utility platform as far as its actual business model goes. WhatsApp is potentially b2c as a business while I'd argue Twitter is really b2b. My experience with enterprise businesses makes it hard for me to believe that going b2b is actually efficient as much as it is about revenue assurance and scaling for sales / marketing culture organizations.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> To me, this is obvious. I find it extremely valuable to spend time making things more efficient and clear. Even if the time spent doesn't save that much time, but makes things less frustrating, it's a big win to me. There's a lot to be said for having processes that are predictable, that don't randomly have issues that require taking time out of your day to resolve before you get to your actual problem. I'd be surprised if there was a significant percentage of companies that don't spend at least some time solving these types of problems. I think the question that this article brings up, is what that ratio should be to actually gain.

</comment><comment><USER11> Here's the problem with tools and process:

They're a cost center and not a revenue generator.

When you've got a group that provides no measurable revenue they will _always_ be at a disadvantage to the group that provides the money train. This is why you see a systematic de-valuing of tools and iteration improvement despite the massive gains they provide.

<comment><USER12> What if the tools support the money train to generate 100x more money?

<comment><USER13> Regardless of the coefficient, it comes down to whether or not everyone else in the company realizes that the tools expertise is the secret sauce driving the money train. I think that's what the person you were replying to was getting at.

It is unfortunate, but the reality of our profession is that tools/infrastructure work always has an uphill battle when it comes to justifying engineering time. It's something we all have to fight for when appropriate, and discussing why and how to do that can be super useful.

Working on tools and infrastructure is by definition time spent making things that will help us make things to make money. The people paying us usually would much rather have us spend time making things to make money, rather than making things to make things to make money. If there's not enough trust between the engineer and the nontechnical manager/investor/whatever, it can be hard to get buy-in for time and money spent making something which is essentially an IOU for hypothetical returns later on. Build that trust and have great ideas and hopefully resources can be directed towards indirect (tools/infrastructure/whatever) engineering expenses.

It is always an uphill battle though, I think it's just the nature of the industry, or at least most companies. :( I'm not bitter though, because it really is totally rational if you look at it from the perspective of the stakeholder who would have to approve it. Just part of the professional landscape to be aware of.

</comment></comment></comment><comment><USER14> I didn't realize that _that_ Peter Seibel (author of _Practical Common Lisp_ ) worked at Twitter. Neat.

The article is pretty hand wavey, although the point made feels to be along the right lines; I'm left wondering what data supports the claims.

<comment><USER15> [https://www.youtube.com/watch?v=sYsHK81MTHI](https://www.youtube.com/watch?v=sYsHK81MTHI)

</comment></comment><comment><USER16> Sometimes(read: most of the times) the tech debt and other code issues arise from the last min requirements although as dev. we try make sure the code is robust enough to absorb these changes seldom this happens.

What I have seen is effective for me is to sit down with pen and paper and describe the problem at hand and then think about the solution write up.

</comment><comment><USER17> Did they pull the scaling out of their hair? I'd like to read about the rationale.

</comment><comment><USER18> Looking at Whatsapp and Instagram's engineering teams' sizes, could twitter do with less than 100 engineers?

If yes than what justifies having thousands when 50 would do? How does an organization get to that point?

<comment><USER19> > _How does an organization get to that point?_

Raise $1B in private capital and another $2.1B in an IPO. Now you have billions to burn and sky-high expectations and no path to profit. Hire lot of people and hope for the best.

But in their defense, Whatsapp and Instagram hadn't demonstrated an viable alternative yet.

</comment></comment><comment><USER20> I wonder how much of this additional engineering workforce is working on things like Bootstrap, FlockDB, Bower, etc, vs internal tools?</comment>


Working at Facebook Inspired Me to Write Lean Out - <AUTHOR> https://medium.com/@MarissaG/why-working-at-facebook-inspired-me-to-write-lean-out-5849eb48af21 <comment><USER2> I wrote something long and deleted it as I don't think I have the emotional bandwidth to pretend that I don't care about the assured avalanche of downvotes that would follow. And linger.

Short version: women will never be taken seriously if they keep talking about their 'feelings' instead of carrying on being kickass at work. It's a job. Not a hobby. Or a club membership.</comment>


Quarterly: Get physical mail from influential contributors - <AUTHOR> http://quarterly.co/contributors/alexis-ohanian

<comment><AUTHOR> I'm curious to know what you think, Hacker News.</comment>


Charlie Sheen – Craziest Marketer Of All Time? - <AUTHOR> http://www.fredsexton.com/charlie-sheen-craziest-marketer-of-all-time

<comment><AUTHOR> Charlie is no doubt doing his hardest to out craze all celebrities but how fruitful will his efforts become?

With this said, how do you quantify each celebrities efficiency in turning craziness into cash? Well, thank you for asking. May I present the Hollywood Craziness Marketing Index (HCMI).

</comment><comment><USER2> "I'm guessing he'll bank $380M from this excessive batch of craze, assuming he converts to Scientology like Tom." Nice.</comment>


Boring Systems Build Badass Businesses - <AUTHOR> https://devopsu.com/blog/boring-systems-build-badass-businesses/ <comment><USER2> In the stated examples there's are no benefits to the additional complexity. No one would argue that complexity _for the sake of it_ is a good idea. That'd be insane. If Alice's restaurant could handle 5,000,000 covers a night with only 1 member of staff while Zola's restaurant could only handle 10,000 then you'd have a more realistic scenario to compare with the SaaS industry. The benefit of "complexity" is that you are able to do more things with less work.

The ideal is to build powerful systems from small, simple processes - if any single stage is trivial then anyone can understand it, fix it, modify it, and so on. With many little processes working together you can do amazing things. A good example in software is a build process - a good system can lint code, test it, uglify it, minify it, push it to version control, watch for changes, reload an output mechanism, clean up a distribution, and push it to a live server if it's working all from a single command. That's very 'complex', but really it's just a set of very simple linked processes.

<comment><USER3> I think the restaurants were a poor analogy. Much better for me was the rule right at the end:

> Innovate on your _core product_ , not on your _plumbing_ (this rule is > extremely tempting for developers to break - see next rule)

I was first exposed to this during my final year university project in 2004. We had a sponsor who wanted to build a marketplace for tourism operators and B&Bs. I was the only real developer on the team of 4. I worked really hard with little sleep, producing a really great caching layer and a very impressive WYSIWYG editor. But when the project deadline arrived you couldn't even book a room on the site.

I still struggle with staying focused; the best technique I've discovered to deal with this is to log ALL work around a project, prioritise the tasks and stick to only working on logged tasks with the highest priorities assigned rather than do whatever I feel like.

(It took me even longer to realise what a business opportunity I had lost.)

<comment><USER4> He should have used the analogy of Alice making an automated wait staff (e.g. waiter drones) for the restaurant. Not an amazing electrical system. I wonder how that kind of story would fair in his scenario.

</comment></comment></comment><comment><USER5> I can easily see how this post could be mis interpreted, so i'll add my personnal experience :

I had the occasion of building the same system in two different companies : one was a start up, the other a huge company.

For the start up i could choose the tech i wanted, and decided to go for python + app engine + backbone ( new at that time ). Those tech were "hype" yet not absolutely brand new. I took some risks by choosing them but thought it could be worth it.

For the big company i had to go with java spring mvc + sencha, they didn't want to hear of any new tech that would be different from what they were used to. They deployed it in their own infra.

Now, the start up project took 3 man month, the big company took more than 7, and a year total before being deployed. The startup only paid an intern to maintain the software,and almost nothing in infrastructure fees. The big company outsourced maintenance to a software service company that proved unable to do even the most basic troubleshooting.

I designed and coded the two systems, and i wasn't a guru of any specific tech, so it's not an issue with the people. Sometimes, under the right circumstance new technologies _are_ way better.

<comment><USER6> The arguments of most of these types of posts can be hand-waved with "use the right tool for the job."

But honestly, plumbing and electrical infrastructure is a terrible metaphor for a development framework. There is no situation in which a handyman would be praised for advocating complex systems. They complicate every single layer of the build.

A sizable chunk of the "hype" tech facilitates faster, more efficient development at fairly low cost (maybe sacrificing some scalability or stability).

It would be reticent of me not to mention how much the deluge of JavaScript frameworks pisses me off. It is overwhelming trying to keep up.

<comment><USER7> You can always ignore them - trying to keep up with every new javascript framework (where 80% wont be around in 2 years) is gonna piss anyone off : )

</comment></comment></comment><comment><USER8> Well said. I can't tell you how nice it is to have software in production on a boring stack. It gives you freedom to _do other things_.

I can (and often do) go entire months without touching the codebase of my main rent-paying products. It means I can, among other things, pick up a full-time development gig to sock away some extra runway, take off and go backpacking around the world, or better still, _build yet another rent-paying product_ without having to spend a significant amount of time keeping the old stuff alive.

It seems like on a lot of stacks, keeping the server alive, patched and serving webpages is a part-time job in itself. In my world, that's Windows Update's job. Big New Releases come and go, but they're all 100% backwards compatible, so when you get around to upgrading it's just a few minutes of point and clicking with nothing broken.

I see it as analogous to Compound Interest, but to productivity. The less effort you need to spend on maintenance, the more pace you can keep going forward.

<comment><USER9> What is your to-go boring stack, if I may ask?

</comment></comment><comment><USER10> This is why Java is used widely. It _works_. It works _well_. And this is also why Java is great for huge systems (not in terms of users, disk space or bandwith, but in terms of code size). The same can be said about a lot of "old" technologies, and certainly about almost every industry standard out there.

On the other hand, once in a while the Alice/Albert bet happens to win; be it because the new system is really better (as in: easy to maintain, or really being capable of managing higher amounts of workload), for non-technological reasons (Alice/Albert just happen to have a great idea), or just because of luck. Over time their technology may even become the new industry standard. The problem here is that it's the Alices/Alberts from the world who make it progress by trying new things (and failing often), but we're afraid of failure.

So, yes, it's completely natural that corps resort to Java or C#, while startups use Scala or Ruby.

For all of you doing startups in shiny new technologies: this means that even failure has a bright side, since even in that case you've put your grain of sand to make the technology more mature.

<comment><USER11> It's not just a question of language or platform but also culture.

Java is probably the #1 culprit for building huge systems to solve simple problems. The goal is small, simple, fast, cheap, and 'enterprise' solutions are rarely a good fit for new companies. Now, if your United Airlines and you have complex problems involving hundreds of systems yea your in a world of pain and Java is a great option for dealing with complexity.

That said, their are plenty of rock solid Java programs that avoid the bloat there just rarely websites.

<comment><USER12> > Java is probably the #1 culprit for building huge systems to solve simple > problems.

Don't blame the language for the enterprise culture.

Before Java existed I have seen similar complex systems done in C, C++, Clipper, VB and quite a few other languages.

Just to cite a concrete example, before J2EE existed, we had CORBA and DCOM systems, plugged with distributed transactions across multiple OS systems. Great debugging experiences.

<comment><USER11> The culture, tools, and language evolve together.

How else do you explain things like:

InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter

JDBC is perhaps a better example. It's short and simple but designed around raw SQL which ends up creating a huge mess vs something like LINQ. Sure, there are hundreds of 3rd party solutions to this problem just pick one except external library's might pick something else...

<comment><USER12> Easy. As they have on a few CERN offices "You can write FORTRAN in any language".

I have seen InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter written in multiple enterprise languages.

</comment></comment></comment></comment></comment><comment><USER13> The fun part is that you can be either Alice or Zola with nothing but perl.

The moral of the story might just be "stop trying to be clever and start trying to be done", with all of the usual yaddayadda about preoptimized yak razors.

<comment><USER14> This is pretty much my point of view. How new or buzz-wordy a bit of technology is, isn't really the issue. It's whether or not the thing in question will allow you to end up with a simpler solution.

Simplicity and supportability come hand in hand for me. I'd much rather debug/fix a really simple app in a language I don't know, than a really complex one in a language I do.

</comment></comment><comment><USER15> A simple rule - you should always remove complexity from a project and never adding it. It builds on its own so any tech you add must remove some complexity from the current project.

Warning sings for tech that brings more complexity than it is usually worth - extensive xml configs, hiding of executable code, stack traces more than 240 levels deep.

Current favorite offender - GWT - I just love when something blows up in the javascript and it just tells you - well signature object object object is not what I expect in javascript apply. And you have no idea where exactly it was generated.

So it is a KISS - the project must be of the least possible complexity to solve the problem.

</comment><comment><USER16> Boring system themselves do not ALWAYS build badass businesses. It's knowing when to stick to boring systems vs taking the chance on something new. A lot of systems start off as someone's side-project. It's a calculated risk when you pick something that brings different things to the table.

</comment><comment><USER17> This post highlights something that can be a problem with the contracting of workers. Namely, that Albert will be more in demand than Zip, despite having built an inferior system. The failure of the business, in real life, is probably not attributable to him - there are many other variables that one could point the finger at (low demand, location, infrastructure, sourcing prices, etc..). And, the manager will often not understand what truly constitutes a "best-practice", maintainable solution. So, by default, he probably ends up being paid more, and is seen to be more important and accomplished as well.

So, where is the incentive for the handyman to act like Albert? And how do you identify these people?

<comment><USER18> Reminds me of Fred and Jane:

[http://groups.csail.mit.edu/mac/ftpdir/users/mrb/Hacks/Plans...](http://groups.csail.mit.edu/mac/ftpdir/users/mrb/Hacks/Plans/plan.brilliance- v-brute-force)

 _Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn 't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple._

</comment></comment><comment><USER19> The maintenance aspect is huge. I've been able to observe how fancy, complex systems fare over a long period of time (as opposed to simple systems): in almost every case the "cool" complex system required way more maintenance. There are just more things that can break.

Unfortunately, we don't normally record the "long tail" cost of a feature. We build and deploy, but don't keep an eye on how much time it takes to maintain that feature.

</comment><comment><USER20> Unproven innovative technologies are not necessary bad. They can give you edge over competition. The real problem is to restrain yourself when applying them, and have a fallback plan.

<comment><USER21> I liked the usage of the word restrain. I try to introduce one or two new things on projects. Too many new technologies and it you will increase the risk of the project, and you will spend more time learning than doing.

</comment></comment><comment><USER22> "There are many ways to achieve developer happiness, but making your core business products a playground for developers seeking novelty is the path to hell."

Excellent point. This also applies to programmers who'd like write everything themselves so that they can learn more in the process. My current job involves maintaining an application that has everything written in-house - logging, html templating, url mapping, validation, form bean binding, scheduling and what not! - all this is possible with just using slf4j, Freemarker, Spring and a bunch of other lightweight libs. Some of the stuff is good and so it makes me think the only reason would have been to become more proficient in OOPs and Java.

</comment><comment><USER23> The problem is, simplicity is not an objective measure. Take monads, for example. To most developers these are a foreign and possibly scary concept. Once you understand them, however, they seem ridiculously simple. This is one of the problems with monad tutorials -- they are so simple there is almost nothing there. I know I spent a long time trying to find a "deep" concept when learning monads, before I realised there isn't one.

Building a system with monads, if you understand them, is simple. You can write together components easily, and have concurrency, logging, error handling and more all nicely abstracted away. But is this a simple system? It depends entirely on your background.

</comment><comment><USER24> This is an argument for buy vs build. As others have stated, the question is whether complexity is worth it. My bias is we tend to underestimate the complexity of small additions, and overestimate the benefit of having control over a system. The implication is too much complexity in things we build ourselves. Sometimes the industry standard solutions aren't appropriate, but it all depends on what a company wants to focus on.

And I'm not sure of the reference for Zola's restaurant, but I like the Guthrie inspired complexity of Alice's restaurant.

</comment><comment><USER25> Of course if you are working on a boring problem it is a mistake to try to make it more interesting by incorporating interesting tools. This is a common problem in web development for a lot of people. On the other hand if the problem you want to solve is interesting and hard then probably you will not go far with the boring standard solutions. (see: Oculus Rift).

Summary: if you don't want to be bored, choose interesting problems, not just interesting tools.

</comment><comment><USER26> Even though it's still hip, this is why Go works in capable hands. As a new programming language / platform, it's academically quite boring. In fact, that's the number one criticism of its detractors.

<comment><USER27> That's what I love about it. No surprises and rather straightforward. Plus it's the first language I feel comfortable using a plain text editor to work with. I use Sublime Text.

<comment><USER28> I wouldn't call sublime text a plain editor.

<comment><USER29> Plain text[1] editor, not a plain[2] editor.

[1]: [http://en.wikipedia.org/wiki/Plain_text](http://en.wikipedia.org/wiki/Plain_text) [2]: "not decorated or elaborate; simple or ordinary in character" [https://www.google.com/search?q=plain](https://www.google.com/search?q=plain)

</comment></comment></comment></comment><comment><USER30> The sad thing about our industry is that the boring systems with the greatest support are also often the most complicated and hardest to deal with.

So the choice ends up being,

* Go with the system you can get some kind of possibly useless support for, but your people will have a hard time dealing with on a daily basis.

or

* Go with something your people can understand that might not have wide external support.

</comment><comment><USER31> The cases presented in this article are contrived.

1) There are room for both boring and cutting edge technology in any business. Albert didn't drop the ball by choosing cutting edge tech. Albert exhibited poor risk management skills. Alice wouldn't be complaining if Albert took a controlled risk and installed a next generation flash fryer that gave a clear competitive advantage over Zola in terms of personnel and order-to-delivery time.

2) Good ideas require both Albert and Zip. Zip keeps the lights on and the costs down for all the mundane BS required to run a business. Albert is the disrupter. He is the reason starting the business was a good idea. He is an iconoclast that looks at the state of the world and said "I can do this better".

The title of this article should be Boring Systems Build Benign Businesses

<comment><USER32> Albert doesn't start the business. He is the plumber on payroll and should behave as such. Alice and Zola start the business and innovate in the realm of cooking, not plumbing.

<comment><USER31> I didn't say Albert started the business. I said that Albert was the reason starting the business was a good idea. What I did say is that either Alice or Zola would be better served by having elements of both Albert and Zip.

I would consider hard to find a decent software engineer that would introduce 20 unproven tools to for something allegorically related to "plumbing" like say your web server.

Additionally, a lot of this is based on perspective. If I suggested standing up a web infrastructure on "nginx" am I an Albert or a Zip. I mean "Apache" has a much longer track record...right? By this article's logic we should write everything in FORTRAN and use single-tasking operating systems. Those have been around since the 50's ... rock solid.

Net out is "proven track records" and "best practices" are convenient stop gaps for ignorance. They are a way for people that don't know any better to manage risk. "I don't get it ... but it worked for her". Being competent and knowledgable, having good risk management skills, and understanding the problem will serve an organization much better than being conservative in your choice of tools.

</comment></comment></comment><comment><USER33> "Boring is where the money is". ~ some HN dude.

</comment><comment><USER34> Why add the complexity of a car when you can simply walk?! The car will break down, you will have to waste days taking it to the service station, you will have to get a driver's license, you will get tickets, you may kill someone and get in trouble, you can't drink if you will be driving. Why add so much complexity to your life?

The idea that complexity in itself is bad is flawed. Sometimes innovation does require complexity. Complexity for the sake of complexity is bad.

>"But [some new unproven system] is really cool! Even [some big company] uses it!"

A company I know uses a big/buggy oil pipeline leak detection software. It is very complex and very buggy. Tech support has to be called in every few months. But they still use it. Why? Because it will detect oil leaks much faster. Potentially saving them millions in case of something bad. Should we stop innovation because we are scared of 'complexity'? I wouldn't suggest using a system because it is 'really cool' and a 'big company uses it'. But why do they use it and why is it 'cool'? Can it make you more money? Those are the questions worth asking.

>"Innovate on your core product, not on your plumbing "

Every bit of complexity deployed to make more money is good. Can you tell and prove how it will make money?

Every bit of complexity added because it is 'cool' is flawed! If plumbing can make me more money, then hell yeh it requires some investment. Every situation is different.

</comment><comment><USER35> I wouldn't say that boring solutions are always the best, unless they satisfied the conditions below.

Here's what is REALLY important:

A) How fast can you get your first product in front of customers?

B) How often can you measure and iterate on that and get the new version in front of customers.

You should pick the best solution that optimizes for A & B. Both are really important because they will help you discover the actual thing you need to be building.

<comment><USER36> I am involved in an ongoing discussion at work. The guys implementing the project want to go with a NoSQL / Angular / Node solution. I see a relational database as being a better fit.

"Its so fast, even running on my laptop" "you only have 3Gb of data just now" "Its so quick to develop, just plug Angular straight into elsaticsearch, no schema,..."

The thing is, I just see lots of problems stored up for the future. Sure you have to define a schema up front if you go for a relational database, but changing it isn't such a big deal, not until you are in production with live data. Sure you might save time up front, but you are essentially cutting corners to achieve this, and storing work for the future.

</comment></comment><comment><USER37> I run/work in a small shop supporting a real estate brokerage with custom software. For every new core project, I ask if the problem can be solved in java. Not because it is the best language, or the one I am most familiar with, but because it is the language that almost all the other systems are run in. Ditto for databases--projects should use mysql unless there is a very compelling reason not to. And we use one data processing tool--pentaho kettle.

Now, we've actually had some other languages 'sneak in'\--perl, bash, python, javascript. But they were for closely scoped projects and, in a couple of cases, I asked for a prototype in java and the other language first.

It is hard to do this, because I read hacker news and am interested in keeping my skills up to date with the latest and greatest interesting technologies. I and my team have other alternatives to explore (hackfests, not-work side projects), which makes it easier. I'm doing the right thing for this company, and that's the right thing to do.

</comment><comment><USER38> I was planning to architect a new system using SOA (or the newly-hyped microservices), then realised the complexity it'd bring.

Each individual system is easy to debug, test etc. Debugging what's wrong when the output isn't what you expect - much harder.

Not sure what's the boring (vs familiar) option here, but the old adage "All that gleams isn't gold" is true...

</comment><comment><USER39> I get the rather bluntly hammered home moral to use safe reliable tech but that misses a lot of subtlety.

I think the moral of the story is to load test before you dump a bunch of customers onto your system. Regardless of the tech you use you can easily fail in this regard. And secondly not to value people for the effort they put in but the results they achieve.

</comment><comment><USER40> This post spoke to me because I'm in the middle of an interesting decision - for our public/marketing website, should we go with Wordpress (something a lot of people know, etc) or a static site generator (fill in your favorite - Harp, Docpad, etc.)? The argument for going with the static site is that we'll have a much faster site (it will be static) that will likely be easier to customize (we don't need a lot of what Wordpress offers) but the potential downside is that most developers don't know the static tools so if I hire someone new, I'm likely training them. Now, I don't think training will be that hard if you get someone with a decent background, but you get the idea.

What would you choose? Safe and stable Wordpress with more customization effort, or the static site generator idea with less installed based of developers?

<comment><USER41> Wordpress, safe, and stable. Wow. Never heard this together.

<comment><USER42> You can have safe and stable Wordpress, you just can't have it cheap:

[http://wpengine.com/](http://wpengine.com/)

( patio11 post about WPEngine - [http://www.kalzumeus.com/2012/02/09/why-i- dont-host-my-own-b...](http://www.kalzumeus.com/2012/02/09/why-i-dont-host-my- own-blog-anymore/) )

</comment></comment></comment><comment><USER43> Well, I mean, it's all about understanding both the tools and the needs and selecting the tool that fits the need. Some "restaurants" have exotic needs that good ol' Zip might not be able to satisfy using his system. Or Albert might have ways to do things that are way cheaper -- require fewer resources, less time, etc -- but have the drawback of using newer tools that might become abandoned, have low developer numbers, etc.

But, as a developer, this is why you have a conversation with your client and understand what their needs are. So you can understand these trade-offs and make the best possible recommendation. Neither Alice's way nor Zola's way is the Way Things Should Work 100% of the Time.

</comment><comment><USER44> I think this is the precise reason why every industry and function has a process framework. Working around processes/functions and its value maps while creating a solution is the best way to not just meet customer expectations but also ensure that your products play well with other products a buyer might have.

Processes and sub process maps like Procure 2 Pay, Order 2 Cash, etc, are there for a reason. They tend to make life simpler for buyers making a choice and also help ensure that your product doesn't have process blind spots that will kill it.

The big guys in the ERP space have perfected this approach and it's something a lot of business oriented startups don't seem to consider.

</comment><comment><USER45> A better analogy would be Alice doing a bunch of research up-front to think that she needs all kinds of cool features before opening and then hires the plumber to enable them, rather than just hiring him because he knows how to build complex systems. The latter really isn't too realistic while the former happens every day in many, many companies.

This overbuilding is usually borne from a lack of understanding of what is really needed and in lieu of learning through doing and reacting, people try to build up-front in anticipation, putting a lot of importance on things that ultimately turn out to be completely trivial.

</comment><comment><USER46> Couldn't agree more. The pre-optimization of cool might be a good name for it.

</comment><comment><USER47> And then there is outsourcing to the cheapest bidder overseas...

<comment><USER12> With guaranteed quality delivery on time. :)

</comment></comment><comment><USER48> Great analogy, this can't be said enough.

Although there has to be a distinction made between using the latest technology and how you choose to architect and design a product with that technology.

I've seen super complicated web architectures with something as widely used as PHP. So it's not so much about what tools you use but rather how you use them. Choose the right tool for the job while keeping the business constraints in mind.

</comment><comment><USER49> From the title I was expecting this to be about the area of the businesses, perhaps suggesting to solve boring and real problems for real people who pay real money instead of, as is fashionable today, building "buisnesses" for sharing your crap to another crap and liking and commenting and following this and that whilst being fed with advertisements.

</comment><comment><USER50> There might be another way to look at it in terms of overall risk appetite:

\- when maintaining a traditional venture, innovate more on tech to attract more talent and interest. (Microsoft Azure folks, Basecamp (formerly 37signals))

\- when innovating in something game changing, don't take huge risks on plumbing. (Facebook, Craigslist)

</comment><comment><USER51> Simply put: Choose your battles wisely, and the ground you do it on even more so.

Though one can gain serious competitive advantage by using something new to compete against established players or use something well tested in an innovative and new way.

</comment><comment><USER52> Boring stack: PHP+MySQL ?

<comment><USER53> I've always wondered how to scale this once you have thousands of active users?

<comment><USER54> [http://hhvm.com/](http://hhvm.com/) seems to work pretty well for Facebook.

</comment></comment></comment><comment><USER55> what was up with the Github and 37signals references? They both use Ruby on Rails which could be considered a niche technology, 37signals even admits to use the most bleeding edge version live in production before they even put out a beta of the version to the public so if anything referencing them is actually hurting the article

</comment><comment><USER56> Bad biscuits make the baker broke, bro.</comment>