If You Call Out Bad Code, Make Sure It's Bad First - <AUTHOR> http://www.naildrivin5.com/blog/2013/01/24/if-you-call-out-bad-code.html <comment><USER3> > Now, I'm all for bad projects and bad code being called out.

Bullshit, sorry.

Questions to ask yourself before "calling out bad code".

1\. Does this code belong to someone on your team?

2\. Does your code rely on this code?

3\. Does the code represent a risk to you or your business in some way?

4\. Do you have the direct contact info for the developer so you can appropriately, discretely and professionally inform them about their code?

Github == "Developer Playground/Experimentation Lab".

Why in the hell should I have to feel that every piece of code I put up there 'must' adhere to 'your' standards or anyone else's?

How can we as a development community rationally expect to grow the open source ecosystem and encourage people with this type of snobbery?

<comment><USER4> _How can we as a development community rationally expect to grow the open source ecosystem and encourage people with this type of snobbery?_

There's one lesson that I'm personally taking from this, after unsolicited ridicule, one sincere apology, one bullshit non-apology, and one arrogant _I have nothing to apologize for!_ If I build a small thing to scratch my own itch (which I often do) I'm going to think twice about sharing it with the world at large. Or, more succinctly, I've become yet more of a misanthrope.

Thanks guys!

<comment><USER5> Missing option: grow a thicker skin and don't take everything personally.

<comment><USER6> I've suffered pretty severe depression and anxiety for most of my adult life. While the idea that we should all just grow a thicker skin and 'just deal with it' is both understandable and practical given the nature of the internet - <USER2> just wont happen for me. I know myself well enough to have recognized that even a tiny drop of vitriol could have me questioning my every decision and shatter my self confidence for days or even weeks. So I simply write code and keep it to myself, and I'm sure there are plenty of others like me.

The idea of open sourcing our work is truly admirable however there are some of us out there who just can't stand the hate and Alpha-nerd jockeying, so we opt out. I don't think the world is missing out on much by my own lack of contribution but who knows how many truly brilliant yet fragile minds are self selecting out of the open source community because they just cannot cope?

<comment><USER7> please email tarballs to email@example.com if you have code you have no aspirations for but wouldn't mind kicking out into the wild. i will eliminate author headers from the code and seed over p2p and make available. thank you for any sympathy you might have towards this request to let us syndicate your work.

<comment><USER8> And annonhub an anonymous github clone in 3...2...1...

</comment></comment></comment></comment></comment></comment><comment><USER9> I see a lot of people saying you're going to keep personal projects to yourself (instead of putting them on GitHub or similar) because of this fracas.

Please don't. The Twitter snark isn't normal, it's an exceptional case. It wouldn't be on the front page of HN if that kind of behavior were the norm. And it's the jerks on Twitter who came out looking bad here, not the author of the code.

I really like how GitHub has encouraged people to err on the side of releasing their personal experiments. I was doing it myself in pre-GitHub days by publishing Darcs repo URLs on my website, but it didn't have the social aspect and Darcs never caught on like Git has. It's lovely to see the idea of "share all your code, by default" so validated as it is on GitHub.

Whether or not you release your code, assholes will still exist and they'll still find a way to be assholes. So don't let them ruin a good thing.

<comment><USER10> _The Twitter snark isn't normal, it's an exceptional case._

No, this isn't true. It's completely normal. It's been normal since long before Twitter. In exactly the same way high school bullying is normal, this is most definitely (a) prevalent, and (b) a problem. But it won't change, because people tolerate it.

You want me to open up my personal projects? It's not going to happen. It won't happen because we live in an ecosystem where the top dog is the one who barks the loudest, not the one who's most productive. People pay attention to what other people say. And there is nothing anyone could say about personal projects except "Pretty cool" or "Damn, what a steaming pile". The first is nice, but I'll get by without it. The second serves only to lower me and my ideas. I don't want my capabilities (ideas) to be constrained by others' lack of imagination.

<comment><USER11> Can you link to other examples of this happening?

<comment><USER12> You can visit Twitter periodically for a week and see this happening everywhere, programming and dev hash tags included (heck, a lot of the trending topics on Twitter are hugely racist or sexist).

</comment></comment></comment></comment><comment><USER13> This is getting way off topic of the original project, but as an older (40) programmer, I've learned that even if code is objectively bad you generally shouldn't call it out unless you have the full context of how it got that way.

I write code every day, some of it is great, most of it is good, some of it is shit ( _working_ shit, but shit nonetheless). The reason some of it is shit varies: time constraints don't allow for the proper solution, working around a crappy abstraction that I can't control, etc, but if you decide to focus on some snippit of the shitty code I wrote and extrapolate that to assess my skill as a programmer I reserve the right to extrapolate that your experience doing real world programming is pretty limited, because otherwise you wouldn't be so naive.

<comment><USER14> exactly. I am in the same era as you and unfortunately haven't managed to hook facebook or google to hire me so my day consists of making the most out of the shit I am served each and every day. You know that 3 line shell script that accounts only needed to run once a year ? Yes that migrated into an 20,000 line perl module that HAS TO run every night without fail but nooooo do they want to (pay to) re-engineer it ? No. Because the customer would not benefit.

The most fun I have at work now is "try to get the most audacious python module through the firewall and then get it approved by the project manager as they have absolutely no clue about what I do".

Sorry kids but unless you make it (and make it big)... that's you in ten years time.

If I am honest, I have got over the "OMG what's it written in?" stage. If it works and if the (time saving per run * the times I need to run it ) > time it would take to write it myself, then .. that's a success. Then.. move onto the next issue to get some project tasks done, contract renewed, kids fed, mortgage paid etc etc etc.

<comment><USER15> I stopped worrying much about so-called bad code a long time ago. Reading eye- watering, mind-numbing code is practically a pre-requisite for working on any non-trivial enterprise system at a business of any reasonable size. In many ways, you come to enjoy the challenge of it. I've had to read code written in an almost obfuscated manner in languages I'd never previously worked with before. You get used to it. You learn to read and grok just about anything.

On the topic of massive Perl scripts, I once worked on implementing a system that was an unholy maze of Perl, Pro-C, Pro-COBOL, Oracle Forms, Java, and PL/SQL. It was the first time I'd ever had to read and write Perl and Pro-C. I even remember reading Pro-COBOL at one point to debug a problem. Good times.

Since the above is somewhat tongue-in-cheek, I'll clarify that I certainly think we should strive to write excellent code and constructively help each other to that end. We should probably be very slow to dispense judgement but quick to share carefully considered, contextually relevant advice. You really do need to understand the context under which something was written to make any useful statements about goodness or badness (which is still probably not that helpful a measure). Something that looks bad at first may be fantastic work considering the circumstances under which it was written.

</comment></comment></comment><comment><USER16> I found this article helpful.

I was very surprised by the quality of the code in the replace.js repo given the vitriol that surrounded it. I'm not a big contributor to open source, but I've recently made some modifications (improvements?) to a Haskell library I use and was planning to make a pull request soon. This event gave me pause. As someone who couldn't tell what was so eye-bleedingly bad about the replace.js code, I was nervous that I would endure a similar fate.

<comment><USER17> Likewise, I've been meaning to convert my local projects at some point and post them to one of the newfangled online git repos. I was going to use GitHub or Bitbucket to avoid saddling my crap on the git hosting I have available from the open source project I develop for, but now I'm not so sure GitHub is the best place for that.

I don't mind the code being publically-accessible as the price for free hosting but I have no interest in being hounded about my personal scratch code either.

<comment><USER18> For what it's worth, I've been on Github for years and no one has even noticed that my code exists. Which I don't mind at all, given all of this.

</comment></comment></comment><comment><USER19> The way I see it, writing command-line utilities in Node is really no different than writing command-line utilities in Python. Both offer a nice scripting environment, and while Node is more web-oriented, there's still quite a bit of libraries out there to do stuff with, making it potentially perfectly suitable for writing an utility for doing _X_. Hell, I personally even consider it somewhat more attractive than Python in this regard because Node has no equivalent to the 2.X/3.X compatibility mess that Python has. (Python wins in having more "general purpose" libraries, though, making it potentially more suitable for not-directly-web-related-development in nature.)

And while this was mentioned a few times in the previous thread, it bears repeating again: There are quite a lot of people out there using Windows, _which includes developers_. Node is a first-class citizen on Windows, and grep, sed and friends won't be there out of the box for you. A properly done Node command-line utility is generally more cross-platform than a shell script using grep and sed would. And there's quite a bit of command-line utilities made with Node out there (most revolve around web development, such as build tools like grunt and things like CoffeeScript/TypeScript/etc compilers), so it's not like this one is unique in that regard either.

</comment><comment><USER20> I propose a solidarity movement:

Heather Arthur day: On this special day we post useful code that we might otherwise be unwilling to post because of what other people might think of it. Because some people have the courage to do this anyway and when they do, it makes the world a better place.

If just a few people do this, they might be considered crazy and laughed at, but if all of us do it, why then we'd have a movement.

<comment><USER17> We'd run out of calendar days if we had a "solidarity day" made up everytime something like this happened.

<comment><USER18> That's why you pick one particular incident and then use it as an anchor point for all the other bad incidents to refer to. This is how all other solidarity days work.

</comment></comment></comment><comment><USER21> I see many comments from people saying that they are more hesitant about participating in open source after this. That they have been working on some code and will now think twice before they put it out in the open. It makes me sad.

Please don't let this deter you! I know how it feels. I was literally shaking when I put my first project on GitHub. Literally. The second time too. And the third. Still am. Still scared of making a fool of myself, but I know what a great learning experience it is and that it benefits my career, so I force myself to do it. Add to that the fact that it is a ton of fun, and every single star a project of mine gets (and the stars are few) makes me proud.

<comment><USER22> I write software because I enjoy it, not to advance my career. I enjoy interacting with real users of my software, solving their real problems. Contributing to open source is not enjoyable because many of the people you have to interact with are so obnoxious, so I rarely do it. Not everybody is trying to pimp their CV.

For example today I found a memory leak in a popular open source library. There's a good chance it is installed on the computer you are using right now. It never even occurred to me to submit a bug report or patch because when I have submitted patches to this project before one was completely ignored (somebody else fixed the issue 6 months later) and the second time I got flamed (that crash causing bug still exists as far as I know).

I have about half a dozen local copies of projects related to things I'm interested in that have various improvements or fixes that will probably never be submitted back to the project, and I don't think I'm unusual in that. Most of the issues are fairly obvious and tend to get fixed eventually anyway.

</comment></comment><comment><USER23> The endless conversation tennis using HN as a traffic-driving net is getting really tiresome

<comment><USER24> The ultimate traffic driver "PHP is terrible! No PHP is Great!" now gets automatically downvoted so something has to fill the void.

</comment></comment><comment> at-fates-hands I experienced when I first started out as a developer, my co-workers were just like this. They'd rip apart sites left and right, people's apps and anything else they could set their sites on. I was hazed on a regular basis for the code I was writing, simply because I was considered a "junior" developer.

It wasn't until after I left there I realized how incredibly myopic and arrogant these people really were. This was one of many lessons I had to learn. There is no one way to do anything in development. Sure there are certain things you should and shouldn't do - but one way to do everything? Hardly.

After I left said company I really gained more respect for how people write and maintain code. As such, I now just keep my eyes and ears open for best practices. Unless it's going to be constructive, I never hack on anybody else's code. I know the feeling of thinking you've done something wrong. When in fact, it might just be a different approach to reach the same conclusion.

</comment><comment><USER25> I'd still like to know how these jerks even came across Heather's code in the first place. I suppose I should be grateful for obscurity. I even have a command-line utility written in C to count from 1 to 10. (Well it does a little more than that, but that's the general idea.) I'd hate to hear what they think of it. I'm not really a C coder so I'm sure it's fairly ugly, and I suppose they'd say it "shouldn't exist at all." In fact I've got all kinds of silly/pointless projects stashed up there--even a few that _I_ 'd say shouldn't exist. Heaven forbid I ever become famous enough for people to take a look! These guys seem to have all the maturity of kids egging someone's house. Who asked for their opinion anyway?

<comment><USER26> Well, now I'm curious for that CLI. Why do you need an utility to count from 1 to 10?

<comment><USER27> I use the standard Unix utility "seq" almost daily as part of shell one- liners. Lots of things are named with a sequential component. Sometimes iterating over those is easily done with a shell glob, but sometimes it's just simpler to do "for i in $(seq 1 8); do restart foo-$i; done".

It's very useful, but basically impossible to discover except by happening to see somebody else use it. So I really don't wonder that somebody would end up unknowingly reimplementing it.

</comment></comment></comment><comment><USER28> _should it exist at all?_

Quite an arrogant evaluation criterion IMHO.

<comment><USER29> You are just angry you didn't get picked to be on the secret GitHub Code Evaluation Committee.

</comment></comment><comment><USER30> I think this is a matter of poor critism. There is a strong suspicion that the code isn't all that useful. It ignores the tools that are available. Its great that the person wrote it, but there are certainly better options out there. Oh well.. good on them for releasing it. Its a learning experience.

On the otherhand I think this is stating to reveal the less than stellar aspect of open community based/social projects. Not everyone agrees with you, and/or has the same opinions as you. Also, its not all free love and drugs as it was promoted to be.

</comment><comment><USER31> > I won't claim to be great at this, but it's something I spend time on trying > to improve, even if it's at the cost of learning some new language or > framework. It's an ongoing process, and this blog post is part of that > process.

This basically means that he could have been one of the guys who called out the badness of the replace code and just took the opportunity to get some attention by posting about a hot topic.

</comment><comment><USER32> If you call out bad code, you call out bad people?

Half of you included, look at the ridiculous shit you say, and how __much __more offensive you are than anything anyone originally said.

Also this is great for a laugh: [http://dl.dropbox.com/u/116385/Slingshot/Pictures/Screen%20S...](http://dl.dropbox.com/u/116385/Slingshot/Pictures/Screen%20Shot%202013-01-24%20at%202.29.48%20PM.png)

<comment><USER33> I agree, the responses are much worse that was originally said. There's also the expectation that you'll suck it up and deal with it which betrays the purpose for reacting against what you said in the first place.

Oh, you missed the tweet, in the screenshot, where he wishes you get cancer and that he calls you a cunt :)

</comment></comment><comment><USER34> Yet some of the people singled out as the snarks in this article are people active in the community as teachers, participate to user groups, spend a lot of their free time on maintaining beginner-oriented software. Life is best seen in shades of grey and I'm sure they sincerely regret having reacted that way.

The more general issue is that Internet has become a place of competition and EXTREME negativity, just read any article on Hacker News if you need convincing. Some dude will spend months or years working on some shit, only to be greeted with cheers and claps like "wow, that sucks", "How is that useful?", "Your code is bad and you should feel bad", "LOL, you handled security like my 2-year old handles the TV remote". So no, it's not even a problem of calling out code when it's bad, it's just a simple matter of recognizing that those people you so hastily call out are in fact human beings. And NO ONE likes to be humiliated.

</comment><comment><USER35> A person who looks at a piece of art and says, "Eh. I could do that," isn't a critic. He's just another asshat with an opinion.

Criticism is the highest aspiration of non-fiction writers. Zinsser says so in _On Writing Well_ so it must be true. Even if it's not, what he says about most people sucking at it, certainly is. Negative criticism is easy, positive criticism isn't. Lead with an insult, and the internet pays attention. But it is hard work to criticize something productively - to point out the value and the areas for improvement. Writing a lead for that criticism is even harder.

Most people, including myself, are not in the habit of spending the time to do it right. The article takes the time to get it right. It does so by looking at why Heather did what she did. It compares what she did to the common alternatives. The author tells what he did when faced with similar situations. That's what makes it good criticism.

</comment><comment><USER36> I just gave the code a quick look and I find this `eval` usage not too cool:

[https://github.com/harthur/replace/blob/master/replace.js#L4...](https://github.com/harthur/replace/blob/master/replace.js#L41-43)

It relies on the fact that you can provide javascripts String#replace a "replace function" (1). The author just evals the contents of a command line provided file into a variable called `replaceFunc`.

Beside that, there's not a lot that can be pointed out as "bad", at least by just reading it lightly (5-10 mins).

[1] [https://developer.mozilla.org/en- US/docs/JavaScript/Referenc...](https://developer.mozilla.org/en- US/docs/JavaScript/Reference/Global_Objects/String/replace#Specifying_a_function_as_a_parameter)

<comment><USER37> It might not be optimal but the set goal couldn't be achieved differently without much overhead. It's a valid use of eval in my opinion.

</comment></comment><comment><USER38> I don't understand what has happened to people.

There is only 2 people who can call out said code.

They are: 1) Their Employer. Then you can ask them to refactor the code. 2) Them.

Additionally, your mother was right. If you don't have anything nice to say you shouldn't say anything at all.

Just because you were born on this planet and survived past birth; does not give you the right or the excuse to harm another person or cause harm to said person's "Value of Life".

</comment><comment><USER39> Man there sure are some sensitive sallies in the dev community lately over this whole debacle. Part of this industry is handling criticism. Not everyone is going to be a fan. That's part of being a developer. Devs were getting their pants torched long before me on the Internet and I don't see that ever ending. A lot of it is opinion. So treat it as such.

</comment><comment><USER40> Another issue in the "is Node right for this" is that it's very very portable, significantly more so that shell scripts (Mac uses BSD utilities, windows has nothing unless you have cygwin), and even slightly more portable than python.

<comment><USER41> Not sure I follow. OS X comes with the Bash shell and I have plenty of shell scripts (bash and perl) for automating my dev environment and numerous other tasks that run fine on both Ubuntu and OS X. OS X using FreeBSD as its Unix layer doesn't preclude it from interoperability with other *nix like systems.

<comment><USER42> If you've ever seriously written shell scripts you'll know that they're not 100% portable. You always have to go through hoops to make them work properly across operating systems systems. BSD and OS X come with the BSD userland tools, with the exception of bash being default on OS X. Linux comes with the GNU userland. A few differences from the top of my head:

\- BSD utilities do not accept any -options after filenames, GNU utilities do.

\- The situation is reversed for BSD find. It insists on accepting a directory name as the first parameter.

\- BSD sed doesn't support the -i option in the same way as GNU sed does.

\- Even different versions of GNU utilities are not necessarily compatible. A few years ago I ran into compatibility problems with 'head', 'tail' and even 'free' across different Linux distros. I can't remember the exact issues though.

So I agree with the grandparent, Node and Python are a lot more portable than shell scripts.

<comment><USER41> Ah I misunderstood the comment to mean the facility just wasn't available (being lumped in with Windows) which struck me as odd.

I generally just wrap things in checks for $OSTYPE and Perl when I'm not working with the system itself.

</comment></comment></comment></comment><comment><USER43> I pull people up for similar things on here, if you're going to call something out _explain_ why you think it's bad. You don't need to provide a rewrite to it, you just need to not drive by snark it.

</comment><comment><USER44> That's good advice in the same spirit here's another one. Don't trust in neat websites nor in pretty documentation; always read the code first.

</comment><comment><USER45> Breaking news, people on the internet have opinions and criticize things. Just don't take it too seriously and have your own opinions.

</comment><comment><USER46> I enjoyed reading David's post and only have one issue: Oxford Comma? Seriously? That's ridiculous, unnecessary and unparsable.

<comment><USER47> You pause there in speaking, so you should put a comma there.

<comment><USER46> Unless I increased my speaking rate to prevent the awkward situation of requiring the comma... or perhaps there never was a pause there (eg "eats shoots...")

</comment></comment></comment><comment><USER48> That was a very poorly written blog.

</comment><comment><USER49> I think that one of many problems with our industry is that even many good engineers can't really tell good code from bad. (Bad engineers are already hopeless.) That's why there are so many flamewars over cosmetic bullshit like tabs-vs.-spaces. Most code flamewars are over style, not substance. But it's substance (overuse of inheritance, lack of interface integrity, inappropriate technical choices) that kills projects.

</comment><comment><USER50> I was with him until he said he'd didn't know what YAML was :(.

<comment><USER51> .... at _the time_. Jesus..

</comment></comment><comment><USER52> who is Heather Arthur, and why they hell does she have 3 posts up on here about some people's opinion on her project. get over yourself, and move on, seriously.</comment>


Chinese BitcoinExchange Bter hacked,$1.75M worth of cryptocurrency stolen - <AUTHOR> http://thenextweb.com/insider/2015/02/16/chinese-bitcoin-exchange-bter-hacked-1-75-million-worth-cryptocurrency-stolen/

<comment><USER2> How many exchanges have been hacked at this point? We must be getting near double digits.

<comment><USER3> How many banks have been robbed now? We must be getting into near 4 or 5 digits by now. Anytime you store large amounts of money in a centralized location, people are going to go after it..

Time to be your own bank.

<comment><USER2> I don't understand why you would want to be your own bank at all? A proper bank will have some level of security as well as the scale to not fall over if a single branch is robbed. Surely being your own bank will not give you any of that security? You'll just doing extra work to make yourself a target?

<comment><USER3> what security does a bank offer that a hidden paper wallet can't? Bank security is a false sense of security.. Your money in a bank is not yours. Ever tried to withdraw more than 10k at once? You'll be given 50 questions you need to answer on why because of fractional reserve banking and other bankster tricks. FDIC is smoke and mirrors so don't even say you're insured against theft. It's far easier to steal money through identity theft with a pull payment system.

I want to be my own bank because I know how to use and protect my money better than some crooked bankster. I'm tired of the poor being prey'd on by fee's, and overdrafts. I'm tired of banksters creating money out of thin air backed by nothing but a gun. I'm tired of the wars, really i'm just tired of the entire fucked up system.

</comment></comment></comment></comment><comment><USER3> just 1.75m? That's nothing compared to the 300M banks lost the other day, and probably more when its all said and done.</comment>


Ask HN? is there anything like Pixel Winch for the PC - <AUTHOR>

<comment><USER2> [https://github.com/andrijac/ruler](https://github.com/andrijac/ruler) [http://www.bayden.com/mezer/](http://www.bayden.com/mezer/)</comment>


Chef 11 released - <AUTHOR> http://www.opscode.com/blog/2013/02/04/chef-11-released/ <comment><USER2> Can someone explain to me the benefits of moving to chef or puppet as opposed to say my current approach of writing deploy scripts in pythons fabric (basically ssh and file operations library)

I have even used Puppet but I could not get over the feeling that it is more complex than I would imagine for small end users (I have managed upto 40 servers with my libraries - it seemed quite feasible to double that. Maybe it's me but 100 servers sounds a lot and is manageable (deployment wise) with controlled scripts.

<comment><USER3> Configuration management is one of those things where you reap most of the benefit just by doing it, not by doing it with a particular tool.

That said, I prefer Puppet because its abstractions make more sense to me, and are pretty easily extended using Ruby.

Puppet is also trivial to bootstrap (at least on Debian). Unlike other Ruby stacks, I can install it using the package manager and be up and running in no time. With Chef you have to maintain additional services like CouchDB and RabbitMQ.

The real reason not to use ad hoc scripts or a tool you wrote yourself is that things like cfengine, Chef, and Puppet are maintained and used by communities -- your successor(s) will thank you.

<comment><USER4> > With Chef you have to maintain additional services like CouchDB and > RabbitMQ.

And care about a lot of dependencies. Installing chef-server on a fresh ubuntu quantal:

        0 upgraded, 444 newly installed, 0 to remove and 58 not upgraded.
        Need to get 280 MB of archives.
        After this operation, 775 MB of additional disk space will be used.

Of course a lot of that is due to how ubuntu packages java, but still... that's quite a lot of software to care about.

<comment><USER5> With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ is still there. Opscode provides a single package with _everything_ above libc required to run the server.

<http://www.opscode.com/chef/install> \- "Chef Server" tab.

If you'd like to build your own:

<https://github.com/opscode/omnibus-chef> <https://github.com/opscode/omnibus- software> <https://github.com/opscode/omnibus-ruby>

Cheers, Joshua Timberman, Technical Program Manager, Opscode, Inc.

</comment></comment></comment></comment><comment><USER6> Congratulations to the Chef crew! Here's one thing I still am wondering though, being a relatively heavy Puppet user now. What are the big benefits to using Chef, or would it be mostly just admin choice here? When I was originally deciding upon a CM system I looked at Puppet, Chef and Salt and decided that Salt was too new (even though I know Python), Chef declared everything in Ruby and I had no intention of learning Ruby just to generate server configurations and then finally Puppet, which I found (personally) to be simple to use/learn and didn't require me to directly learn Ruby unless I need to extend the 'language' of Puppet.

<comment><USER7> Theoretically you can use Chef without knowing Ruby, since if you're using pre-existing cookbooks you can just say what to install by listing the recipes in JSON format.

But practically speaking I'd say Ruby is essential. It'd be a disaster trying to use others' cookbooks without being able to read the recipes, and almost certainly you'll want to do something they don't cover.

On the other hand, perhaps Chef is an _opportunity_ to learn Ruby? Certainly you can be productive with a very superficial understanding of the language, so you could get started pretty quickly. And a Chef recipe is about the flattest, simplest code imaginable.

<comment><USER6> Well, if you're using Chef and just using pre-existing cookbooks I'd say you take away 90% of the power of a CM system. So yeah, probably using Chef you have to know Ruby, full-stop.

For admins whom have a history with Ruby that's not a huge request, but at the same time I question how useful it is to basically require an admin to code in a particular language to build system configurations (And that is the one thing that drew me to Puppet... that while it had a 'language' it wasn't REALLY a language, more a template syntax).

I can certain agree with the idea of using Chef as an opportunity to learn Ruby and when the day comes I have some spare time to start then it might be a good place to begin using it.

Really though beyond the language aspect, I was wondering what the feature-set that Chef offered over Puppet, things like structural decisions like how nodes are managed, node removal (kind of a sore spot in Puppet right now), etc.

<comment><USER7> I don't know enough about Puppet to compare them, but the impression I got from reading several comparisons a year or two ago was that Puppet had a more mature community and hence better cookbooks, while Chef was better suited to "dynamic" responses, like adding nodes in response to high load. So perhaps Chef has better removal abilities.

<comment><USER6> Well, the community for Puppet is good, but oddly there are many modules (what Puppet calls a 'cookbook') missing for some relatively trivial things. For instance, I have written about 10 modules now for various system utilities/resources/services now which didn't exist as of yet, or at least were very... ahem... not good. For example, I've basically re-written my own nginx module because the ability to add reverse-proxy caching to server entries didn't exist even in the Puppet Labs nginx module (really, this is a thing)!

</comment></comment></comment></comment></comment><comment><USER8> Impossible for me to join the opscode website. Maybe HN has crashed the web server due to the number of users? :)

<comment><USER9> What's even worse is that the install script at <https://www.opscode.com/chef/install.sh> is also unavailable, which is the default way of getting chef installed onto newly provisioned server.

<comment><USER10> Yeah. That's a fail. Pretty much killed my afternoon.

</comment></comment></comment><comment><USER11> My overall experience with Chef isn't that great, because seems to me their team didn't response to users'issue seriously.

E.g. I have reported a bug [1] half year ago that the chef-server failed to start automatically when your server restart, still mark as `Unresolved` and no official answer from chef.

I think when your server startup script failed to work on a major distribution like Ubuntu, it should be considered as critical, right?

[1] <http://tickets.opscode.com/browse/CHEF-3204>

<comment><USER12> I'm sorry you feel that you didn't have a good experience.

As one of the original Chef contributors before Opscode, and then becoming one of the lead people working with the open source community for Opscode, the vitality of the open source Chef project is very important to me. However, Opscode's support for all of our open source projects also hinges on the company being successful enough to continue to do so. Thus, a balance must be struck.

Opscode doesn't respond to every ticket on that open source tracker, just like we don't write all of the code in the open source project. I personally try to at least see every issue, but with over 1.8 million installs of the Chef gem alone, there are a lot of users out there. If you want a guaranteed response, we do have various paid support plans which will provide you with that, but it doesn't come for free because we have to pay the people who research and write those responses.

There are multiple ways to install the Chef 10 Server and many ways to start the processes. We have tried to support the most popular, and I think most people have found success. We're proud that we can do things like release our rewrite of the Chef Server in erlang back to open source. We want it to be easy for people to use Chef. We initially wrote it to make our lives easier, and we want your lives to be easier too. That's why the Chef 11 Server ships in our Omnibus packaging, which provides a running Chef Server in three commands or less.

<comment><USER11> Hi btmspox,

Firstly, thanks for your reply and your works on chef. I really appreciate it.

I think there is a difference between people who want free support & people who document a bug of a opensource project clearly in the hope of to improve the quality of that project - I hope I am in the latter case.

My reported issue can be easily fixed with some hacky workarounds, so I didn't bother with it and move on (As you can see I have never comment on that ticket). However, I still decided to create that ticket because I think the issue is easy to reproduce and will affect a lot of new comers to chef.

The issue is confirmed by others as well, one awesome commenter Florin Mihaila even provided a very detail analyse and solution to the issue.

For me, I would prefer if you can close the ticket if you think it is invalid, or mark as don't fix if resource is not allowed, rather than leaving as open and unanswered.

Of course, this is your project so I can't disagree with your preference, thanks anyway :)

<comment><USER12> Always appreciate bugs being filed. I did a little pondering on the ticket the other day. Since we're using update-rc.d, we're likely talking about debian package install, which means that we could probably set the defaults correctly with update-rc.d, someone just needs to do the research and patch the init scripts or the debian packaging. So it's best for the bug to be open.

[http://www.debian.org/doc/debian-policy/ch- opersys.html#s-sy...](http://www.debian.org/doc/debian-policy/ch- opersys.html#s-sysvinit) [https://github.com/opscode/opscode- packages/tree/master/debi...](https://github.com/opscode/opscode- packages/tree/master/debian/chef/debian) [https://github.com/opscode/chef/tree/10-stable/chef/distro/d...](https://github.com/opscode/chef/tree/10-stable/chef/distro/debian/etc)

</comment></comment></comment></comment><comment><USER13> the combination of erlang backbone + ruby nodes is a wonderful way to write distributed systems. i've put in my time rolling my own when a single-node system needed to go distributed, and today i'd pay the up-front cost of integrating either erlang or a message queue as soon as i added the second node; these things invariably have to scale up more than you'd expect, and your homegrown system will almost as invariably fall over and die when you can least afford it.

</comment><comment><USER14> Another thing I think helps to explain how beneficial a good configuration management system is, especially if you have a good deal of systems, is to think of the servers as part of a botnet, and chef as the command and control.

</comment><comment><USER15> I started with Chef around version 10.4. It's really amazing to see how far Chef and the community have come since then. Keep up the awesome work Opscode!

</comment><comment><USER16> I haven't try Chef yet, but it seems like it has some advantages, I should give it a try!</comment>


A Smooth Curve as a Fractal Under the Third Definition - <AUTHOR> https://arxiv.org/abs/1802.03698 <comment><USER2> It seems like this could be uncharitably summarized as follows. "The usual definitions of fractal are rather narrow. The second author of the present paper has proposed a broader definition of fractal. In this paper we show that according to this definition curves such as the semicircle and the logarithmic spiral are 'fractals', but rather than concluding that the definition was a bad one we choose to conclude instead that those curves really are fractals."

Which is, of course, absurd. Am I missing something?

<comment><USER3> I agree with you - I can't pick any sense out of this paper. Note that they have not given a single example of a curve that is _not_ a "fractal" by their definition. What would such a curve look like? A straight line is the obvious guess - but since all the "bends" are zero for a straight line it's not at all clear what their definition would even mean.

Intuitively, a fractal curve is something that has _larger_ bends than expected yet their definition is something has a disproportionately many _small_ bends. Why would we want to consider such a thing fractal? Frankly if I were to try to find a curve that was _not_ fractal (under their definition), I would search amongst curves that _are_ fractal (for the usual notion): how else would you get large bends even as you subdivide the problem?

</comment></comment><comment><USER4> outside of this there already exist smooth fractals

[https://www.emis.de/journals/em/images/pdf/em_24.pdf](https://www.emis.de/journals/em/images/pdf/em_24.pdf)

<comment><USER5> That's not exactly 'smooth' in the differential geometry sense.

<comment><USER4> what is 'smooth' in the diff geom sense?

<comment><USER5> In that context 'smooth' typically refers to things that are infinitely differentiable. The manifold described in the paper you linked only has derivatives of order 1.</comment></comment></comment></comment>


Ask HN: How to save files online and make it so that the files can't be deleted? - <AUTHOR> Like Amazon Glacier with Vault Lock. I really like this feature. I want to save some data valueable for me, and make them accessable for others. If someone get my password, it can delete all my files, with Vault Lock it must hack aws if I understand correctly. But AWS require a credit card. I have no credit card. And I don't want to have a credit card. Are there any other companys provide this feature? <comment><USER2> This sounds like the sort of thing [https://ipfs.io/](https://ipfs.io/) would be appropriate for.

<comment><AUTHOR> I can't evaluate if it is trustable, so I can't trust it. I know it maybe sounds stupid, but I trust big companys.</comment></comment>


Mouse options for accessibility - <AUTHOR>

My grandmother is getting to a point where using a computer is becoming very difficult.  Her hand tends to shake, and using a mouse or trackpad in particular doesn't seem to work very well.  She currently has Ubuntu on her desktop, and a chromebook as well.<p>Does anyone have any input suggestions for mouse replacements?  It's funny, but I think an old-school arcade style joystick moving the mouse slowly with a few buttons would do the trick, but am having trouble finding an out of the box solution for this.  Does anyone have any suggestions?  I know it should be possible to use a custom input controller for an actual arcade style joystick (8-way).  However, an existing solution would be preferred. <comment><USER2> The most frugal approach might be to consider a trackball, followed by a full computer drawing table (e.g., [http://goo.gl/qlHnlz](http://goo.gl/qlHnlz) or equivalent). Depends on the nature of her tremor or shake. Alternatively, get her a gaming mouse and turn the dpi sensitivity all the way up such that any movement is translated into minute screen movements.

There are dedicated hardware vendors, found on rehab sites such as [http://www.rehabmart.com/product/adapted-wireless- computer-m...](http://www.rehabmart.com/product/adapted-wireless-computer- mouse-interface-40391.html) that you might consider browsing. I had a link to a product that seems to have gone out of business - it was an adapter that autoaveraged input coordinates to tone down tremors.

Finally, keeping all the keyboard shortcuts handy - [http://community.linuxmint.com/tutorial/view/45](http://community.linuxmint.com/tutorial/view/45) or [https://support.google.com/chromebook/answer/183101?hl=en](https://support.google.com/chromebook/answer/183101?hl=en) might help her.

Best of luck!</comment>


Show HN: Broker-less simulation and mocking for Kafka - <AUTHOR> https://github.com/obsidiandynamics/jackdaw <comment><USER2> Do check out author's other project, Kafdrop[0], a web UI for Kafka.

[0] [https://github.com/obsidiandynamics/kafdrop](https://github.com/obsidiandynamics/kafdrop)

</comment><comment><USER3> > If only you could simulate the entire Kafka infrastructure in a JVM so that > messages can be published and consumed without relying on Kafka... After > all, you just want to know that your application components integrate > correctly; you aren't trying to test Kafka.

It depends on what one is trying to test. For simple connectivity, sure. If one wants to test more advanced features, this could be not enough.

By the way, it's possible to run entire cluster in tests. Here's an (older) example: [https://github.com/radekg/kafka-cluster- tools](https://github.com/radekg/kafka-cluster-tools).

</comment><comment><USER4> This is pretty cool, testing with kafka is a painpoint. We have been using a fat container from spotify that has kafka and zookeeper with basic configuration out of the box.

</comment><comment><USER5> I'm confused, does this have anything to do with the Clojure Kafka client also called Jackdaw by FundingCircle?

<comment><AUTHOR> No nothing to do with that. Just happen to have same names.

</comment></comment><comment><USER6> nice! related, we just added similar capability to librdkafka (the C client) to facilitate better integration testing. hopefully we will expose it in the bindings as well at some point.</comment>


Don't React - <AUTHOR> http://staltz.com/dont-react/ <comment><USER2> This is a repost from a few months ago. Relevant because the author commented on the original HN post [https://news.ycombinator.com/item?id=8819115](https://news.ycombinator.com/item?id=8819115)

</comment><comment><USER3> I recently finished building a small-ish web app for a major federal Government customer in react.js. They are very happy with responsiveness and quality of the product. I'm very happy with how easy and cost-effective it was to build.

To get an idea of the size of the app, it has about 20 components. However, some of the components could (and probably should) be broken down. My hunch is that with refactoring the final number would probably be around 30 to 40.

Other frameworks that I have used professionally include Backbone.js, Knockout.js, and Angular.js. My subjective (i.e. non-scientifically-measured) experience with React.js was that it took less time to build a comparatively sized application, and there were fewer bugs. All frameworks have a learning curve, but I felt React.js was pretty easy to get into. There are not a lot of "things" you have to learn about. In this project I didn't have to train anyone else to use React.js, but I believe it would have been relatively easier to do than training for other frameworks, which I have also done in the past.

The bottom line is that my experience was very positive and I will definitely use React.js again on future projects, should a suitable one come my way. I'm sure react.js could be better, but the authors recommendation not to use it based on not being pure enough is total bs.

<comment><USER4> As is covered ad naseum else where, ReactJS is just a way to do Views.

What did you use to manage state, data flow, communication to servers, etc?

<comment><USER5> You can actually do a lot of that stuff with JavaScript, it turns out.

<comment><USER4> So you end up with an unmaintainable pile of javascript?

Or are advocating reinventing the wheel and writing a bunch of boiler plate javascript to marshal data, update state, etc?

\----

One major reason to use a JS framework is to enforce good design and coding practices to allow for more maintainable code.

You can certainly implement these patterns yourself in Javascript, but you are reinventing the wheel, which is an antipattern in pretty much all but the edgiest cases.

<comment><USER5> React abstracts away the stuff that usually makes JS complicated, like DOM manipulation, or dealing with observables. What you're left with is view components that you can just stick a regular JSON tree into. For instance, updating state is something that you don't really need to do in React. Just update your JSON tree, and your interface will match. And JS is really good at monkeying around with JSON.

There is some stuff like routers etc. that you might not want to write yourself. Luckily there is a universe of components you can choose from, instead of one that some guy at google thought was good.

</comment></comment></comment></comment></comment><comment><USER6> Wow. This dude got really hung-up on the name 'React' (assuming that had to do with reactive programming). His summary of 'React sucks at reactive programming' is ... true? It also kind of misses the point.

The React team clearly states their design goals here: [https://facebook.github.io/react/](https://facebook.github.io/react/) ... and they have nothing to do with reactive programming.

<comment><AUTHOR> Apparently my submission of this was a repost -- the author commented on the original post saying:

"Presentation author here. I should have taken this down before it popped up on HN or elsewhere. The video of this presentation is worth watching, because it's tongue-in-cheek through-out. But the slides are not worth reading, otherwise people take it seriously like it's happening here now. Cycle isn't the solution to everything, it's just one guy's ongoing experiment."

[https://news.ycombinator.com/item?id=8819422](https://news.ycombinator.com/item?id=8819422)

Anyways, I found the ideas interesting because I think that its use of Reactive Extensions solves a variety of frontend problems elegantly (and Rx works on backend problems too, making it even more compelling). I made a jsfiddle that explains a bit about Rx to hopefully provide enough context for "why would you use this?" [http://jsfiddle.net/nmd88wum/](http://jsfiddle.net/nmd88wum/)

Anyways, sorry for the respost, and sorry to the author for dragging up something he apparently didn't want being dragged up again. :(

</comment></comment><comment><USER7> For anyone else who, like me, didn't realize it - there's a little triangle on the bottom right to let you go through the presentation.

<comment><USER8> What an awful UI decision. I wouldn't have even noticed it.

EDIT: This apparently wasn't intended to be navigated by the general public, as explained by a comment below.

<comment><USER9> Yeah, I had to read the source code of the page to understand it was actually a presentation.

</comment></comment></comment><comment><USER10> I actually look forward to the day when React is not engulfed in hype, so people will stop complaining that it's just going to go away when the hype dies.

Programmers love to make things. When you make something, you want to bash the thing that you are "better" at. This comes will all kinds of blindfolds though (you may be on the right track, but you need to be aware of these blindfolds). There are so many examples as to why his criticisms don't hold. If you don't like something about React, it's easy to make your own base component and add your own Observable semantics. Check out Om, a ClojureScript framework on top of React, which changes all sorts of stuff ([https://github.com/omcljs/om](https://github.com/omcljs/om)). React is a platform ([https://www.youtube.com/watch?v=5hGHdETNteE](https://www.youtube.com/watch?v=5hGHdETNteE)).

Why is it so important to reuse React? When you author a new framework, another blindfold is lack of community. You don't understand how important it is that authors of React can download tens to hundreds of incredibly advanced components ready to use (like [https://github.com/gaearon/react- dnd](https://github.com/gaearon/react-dnd)).

EDIT: Apparently, this presentation was tongue-in-cheek ([https://news.ycombinator.com/item?id=9316187](https://news.ycombinator.com/item?id=9316187)), which totally changes everything. I hate just seeing the slides!

<comment><USER11> Some of the criticisms the author points out still hold. For example, criticism that React doesn't give a place to plug in to do post-processing on nodes is valid, and is even a point that David Nolen makes in the video you linked to.

The author is probably wrong to dismiss React because of all the other benefits, and the community/platform aspects you brought up, but him complaining about these issues (the subset of his issues that are valid, that is) still provides a lot of value to the community.

<comment><USER10> That's definitely true, it's great to see parts where React doesn't allow people to play with something. It would be a lot more constructive though to build on top of React so we could more easily see the point. Additionally a lot of these problems are well known so before building your own framework, it's worth engaging the React community to see what we are thinking about them.

</comment></comment></comment><comment><USER12> I think that author is completely right about the part, that React has the only one reactive part — its render function. But I don't see why it makes React bad. I think it is great, fast and easy to use.

By the way, virtual-dom is a little bit early to use for production application. For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable. For example, it can duplicate some elements on the page.

I believe it happens because vdom depends on its internal index to traverse real dom nodes. It is still a remarkably good piece of software.

<comment><USER13> >For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable.

I can't think of a reason that someone would use react and still bypass it do their own dom modifications.

<comment><USER14> This usually happens when you want to use 3rd party libraries (e.g. jQuery draggables, Bootstrap tooltips, or anything that polyfills an unsupported DOM element)

</comment></comment></comment><comment><USER8> TL;DR: React sucks. React isn't "reactive". Oh, and check out this reactive framework he has been working on: [https://github.com/staltz/cycle](https://github.com/staltz/cycle)

<comment><USER15> Context, please? just a little? Figuring the top comment on HN might be relevant, I checked the comments (learned to do that before following main link), then started the presentation, it did nothing, came back, found a comment mentioning the near-hidden navigation, went back, read a dozen pages and still don't know what he's talking about.

<comment><USER16> The presentation from OP is difficult to use. Press the triangle in the lower right of the page, or the right arrow key.

</comment></comment></comment><comment><USER17> React really doesn't give you any way to handle communication between components besides going downwards, which is fine because that solves a lot of problems.

You can very easily implement his 'subscribe' scenario in React. In fact, in 0.14 they are planning on having observe[0] to help you do just this.

Now, for my little plug. I've been working on Reapp since launch building a couple real-world apps and I agree that React needs an observe/subscribe model. In fact, I fell onto it while exploring a number of different patterns, and it's stuck the best.

We launched reapp-kit[1] (in beta) a few days ago. It unifies a router, immutable data, and a simple action system that lets you implement flux as well as sideways data loading almost no time. And it's all run through React's awesome contexts[2].

Here's a video of me writing a sideways actions in React, in seconds, using reapp-kit: [https://www.youtube.com/watch?v=FALQU- pVKJo](https://www.youtube.com/watch?v=FALQU-pVKJo)

[0] [https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398) [1] [https://github.com/reapp/reapp-kit](https://github.com/reapp/reapp-kit) [2] [https://www.tildedave.com/2014/11/15/introduction-to- context...](https://www.tildedave.com/2014/11/15/introduction-to-contexts-in- react-js.html)

<comment><USER5> Reapp looked awesome, the issue is that the 'back-swipe' on my iPhone 5c was noticeably less smooth than the real thing... are you guys going to have to resort to some more exotic techniques to fix that?

<comment><USER17> At launch that hadn't been optimized, which it has been quite a bit since then.

We do need to optimize it further. It's actually React that is getting in the way here, but we don't want to cheat and break out of React because that would mean so pretty major disadvantages. We're thinking about building out either a separate animate() pipeline that works differently from render and just lets you use refs to animate things. Or, just optimizing further as there is some stuff we can do.

</comment></comment></comment><comment><USER18> Regarding the page's "poor UI usability" without obvious navigation buttons: I'm guessing the page is intended for the author's use in live presentations (like MS PowerPoint) and is not meant to be a general purpose landing page.

The author used it that way here: [https://www.youtube.com/watch?v=9QObt0SGriI](https://www.youtube.com/watch?v=9QObt0SGriI)

(I haven't seen the whole presentation so I can't comment if it's worthwhile to watch.)

<comment><USER19> The button was maybe created that way so people won't react.

</comment></comment><comment><USER20> First, the UI for that presentation is terrible. The arrow in the lower right is hard to notice, and on some slides it becomes invisible.

Second, the Cycle.js code on slide 18 is some of the nastiest, kludgey looking JS I've ever seen.

I get the ideas behind Reactive Programming the author is presenting, and they are interesting, but if that's the code his implementation is meant to produce, no thank you.

<comment><USER21> It looks a little like a combination of React and Angular. Which probably really isn't a good thing.

TodoMVC in Cycle is... intense: [https://github.com/staltz/todomvc- cycle](https://github.com/staltz/todomvc-cycle)

</comment></comment><comment><USER22> A few reasons to use React

\- it isn't a framework

\- thinking in terms of components can improve your code

\- very easy to prototype

\- react native

It's quite possible that React 1.0 or 2.0 will address all of the issues staltz points out. No harm in pointing out flaws but React does have a lot of good things going for it.

</comment><comment><USER23> To me it doesn't matter what React likes to think it is, to me as a front-end developer all that matters is the tool that I choose can do the job. React is just another tool, in a way it is like jQuery: it doesn't do everything and it shouldn't be used for things that need something else more full figured or suited for the task at hand.

I think Facebook do a great job explaining what React is and as far as I am aware, they don't go claiming that React.js is a 100% reactive library. There are no unclear intentions, Facebook saw a need to improve DOM performance and they achieved it in a great library that I think is a pleasure to use.

I have built two projects solely using React and the Flux architecture. I don't have exact figures, but it saved me a lot of time compared to using something like AngularJS which has too many conventions and opinionated ways of doing things. I was able to get a nice performant CRUD application running in the space of a few days, most of the time was spent creating the API and getting it to return the appropriate data.

How can you write off a library like React.js when it goes beyond just another open source project, and unlike Google with AngularJS, Facebook aren't dogfooding their own product and they are actually using it for parts of Facebook, the Instagram website and a few other places. React.js is a battle- tested library. Those who have used React.js on a proper project know that it is very easy to use and its performance is better than any other SPA framework by far. Unlike other frameworks and libraries, React.js can back up its claims and has proven benchmark after benchmark it can render UI components extremely fast and efficiently (with a concentrated effort to make it even faster).

Sure, React might do things differently and it might not be a pure form of reactive programming, but it works and it works very well. Coupled with Flux, you actually do get a nice and reactive development environment where events are emitted and things are updated throughout your application from your stores. I don't really see Flux being mentioned in the slideshow which is a shame because Flux is the missing piece of the reactive puzzle.

It's easy to say something sucks without really giving an adequate reason why it sucks. Seems like the author had a bad experience with React or perhaps just wanted to ruffle some feathers. I also got the impression the author was trying to pedal their own library Cycle.js which will no doubt be abandoned in 12 months time when it doesn't get as popular as he would have hoped. Nice try, but not a very well thought out argument in my opinion.

<comment><USER24> typo: Facebook ARE dogfooding

<comment><USER25> I prefer Facebook IS dogfooding. See [http://www.economist.com/style- guide/singular-or-plural](http://www.economist.com/style-guide/singular-or- plural)

</comment></comment></comment><comment><USER26> It seems the author's notion of Reactive programming is listening for event. While event handling is useful, it has been in Javascript for the longest time and it's nothing new. Event based updates can have very poor performance, MxN problem.

Also Reactive programming is more of having a declarative way to structure data flow so that changes can happen automatically, like a spreadsheet.

</comment><comment><USER27> Blanket statement: anyone that makes blanket statements like 'React sucks' or 'Ember sucks' should not be taken seriously.

<comment><USER28> OP backs up his statement with examples. 'React sucks' (because there are better ways to do this) was the conclusion of the presentation.

</comment></comment><comment><USER29> It's worth mentioning Elm, a (truly) functional-reactive language, based on virtual-DOM.

[http://elm-lang.org/](http://elm-lang.org/)

<comment><USER30> While mentioning other tech, I have found Scala.js with Scala.Rx [1], ScalaTags [2], and some glue [3] a great way to actually do reactive DOM updates based on state change. I find this way cleaner than building and diffing entire DOM trees (even if they are just AST's in JS). Mixed with ScalaCSS [4] you have a nice type safe solution.

1 - [https://github.com/lihaoyi/scala.rx](https://github.com/lihaoyi/scala.rx) 2 - [https://github.com/lihaoyi/scalatags](https://github.com/lihaoyi/scalatags) 3 - [https://github.com/rtimush/scalatags- rx](https://github.com/rtimush/scalatags-rx) 4 - [https://github.com/japgolly/scalacss/](https://github.com/japgolly/scalacss/)

</comment></comment><comment><USER31> Coming from a jQuery background, I'm intrigued by ReactJS (especially JSX and components). However, I've also been reading up on Meteor and find it very impressive (if you're willing to consider an end-to-end framework). I didn't notice any mention of Meteor as an example of a true reactive framework in his presentation.

<comment><USER32> Funny you should say that, there have been a lot of presentation/articles in the meteor community about using react with meteor instead of its native rendering engine. As it basically solves all of the authors problems with react.

</comment></comment><comment><USER33> With all the hype going around for React, I wouldn't mean getting the opinion of some other fellow front-end peers to see what their 2 cents are with this. I will say I honestly haven't looked into React enough to make a good call if this slideshow holds up or not. React does seem to be riding the hype train pretty fast, though.

<comment><USER34> My experience with React has been great. And my opinion of the slides is that, yes, someone can use react in an "interactive" style. But the one example is just that, an example. I have found that it is really simple to adopt a strictly reactive method.

To give some background, I started with virtual-dom when we were transitioning away from angular. I built a bunch of "proof of concepts" with it, and tried to build out a micro-framework around it for our company. Then we had a quick meeting where we presented quickly on react, mithril and my homebrew. The guy who did the react example had done it in like 20 minutes, and it was WAY more elegant.

So my point here is that, yes, virtual-dom is a great project, but it just doesn't have the "full package" like react. So we chose react and haven't looked back.

</comment></comment><comment><USER35> Also, lets not forget React Native. NO other framework can prove that compatibility with mobile. A React programmer can now cover both web and mobile development with relative ease. I'm not saying that React Native or React is perfect, but I would argue it is the best option for any company with limited developer resources.

<comment><USER36> Appcelerator Titanium says "Hi. Must be nice to just coast on hype without any product support investment or proven track record."

<comment><USER37> To be fair, Appcelerator used to be _awful_. My experiences with it a few years ago mean I haven't tried it again since though, so I'll admit my opinion is probably out of date.

</comment></comment></comment><comment><USER38> Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos.

Some important things I want to make clear:

1\. React is revolutionary. I really like the core idea inside it, which is basically just this [https://joshaber.github.io/2015/01/30/why-react-native- matte...](https://joshaber.github.io/2015/01/30/why-react-native-matters/)

2\. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for server-side rendering [https://github.com/andreypopp/react- async](https://github.com/andreypopp/react-async)), mutable API (setState) etc, and most of my presentation. I've spoken to others in the industry (would not like to mention names, but top experts anyway), and they both love React and agree it is contaminated with a bit of bad API.

3\. React probably doesn't have the perfect API for the "UIs as pure function of state" approach. It can be improved [https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398) and [https://twitter.com/sebmarkbage/status/543660526908088320](https://twitter.com/sebmarkbage/status/543660526908088320)

4\. This presentation was given at a small meetup and I made it provocative on purpose just to have some fun with friends. The type of stuff you talk about in a small circle, not meant to publish on HN for the whole world [https://www.youtube.com/watch?v=9QObt0SGriI](https://www.youtube.com/watch?v=9QObt0SGriI)

5\. Cycle.js is not _better_ than React, it is my personal ongoing exploration in how to make React (or React's ideas) better. It is work in progress, and I'm breaking it apart whenever I find a better way of doing stuff. E.g. [https://github.com/staltz/cycle/issues/99](https://github.com/staltz/cycle/issues/99)

6\. Cycle.js is not an antagonist to React. I am currently experimenting with Cycle.js + React Native. [https://github.com/staltz/cycle/issues/91](https://github.com/staltz/cycle/issues/91) If React's API would be a bit less restrictive, I would use it for the web too. But virtual-dom by MattEsch is lighter and less restrictive, so I use that.

7\. Don't be so harsh on HN as if I would be intentionally shouting to the whole world that React sucks.

<comment><USER39> Well, not sure about first point. We already have FlightJS ([https://flightjs.github.io/](https://flightjs.github.io/)) couple of years, which is event-driven also (even templates looks similar to React UI).

<comment><USER40> Flight is not like React at all. I see DOM manipulation all over the place in Flight examples.

<comment><USER39> Maybe that's the reason why it didn't take off the ground :) But their main idea is event-driven design, so I still think it's common idea for React and for Flight.

</comment></comment></comment></comment><comment><USER41> Do people really consider Grunt dead?

<comment><USER42> I'm also curious. I don't use grunt because my daily workflow is almost entirely in Visual Studio, but I though grunt was the go-to for automation tasks.

<comment><USER35> Maybe the author meant that there is a lean towards gulp over grunt? Not sure. but my company still uses grunt in production

</comment></comment></comment><comment><USER43> I'd be more worried about the unusual license.

React is under BSD, but includes additional terms in a PATENTS file. Very generous terms. And yet ...

I'm not a lawyer, I couldn't even play one on TV. But it is _profoundly bloody annoying_ that they didn't pick a well-understood, well-known license instead of baking up their own Frankenlicense.

I'm sure their lawyers have a reason for not just using the Apache 2 license. I'd love to know what it is.

In the meantime, every single company with fastidious lawyers is going to be dealing with Legal yanking the emergency brake when they see React, because it does not neatly fit into a known license.

</comment><comment><AUTHOR> After submitting this, I'm not sure that the author's slides alone really provide enough context about "reactive" in order to understand the criticisms he's making.

To understand his criticism requires some familiarity with the cross-platform Reactive Extensions library and its approach. I made a jsfiddle a while back that illustrates how this works in a way that I hope is very straightforward: [http://jsfiddle.net/nmd88wum/](http://jsfiddle.net/nmd88wum/)

</comment><comment><USER44> I've used Flux now on a few toy microprojects and I found that while Flux's unidirectional data flow is initially appealing (and I naturally tend to write unidirectional code for very complex UIs in past apps),it makes the simple cases much more tedious and error prone.

For example, given the simplest case of a Flux store handling events from a single ajax call, I find I have to write code like this:

      onLoad() {
        this.loading = true;
        this.errorMsg = null;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }

      onSuccess(data) {
        this.loading = false;
        this.errorMsg = null;
        this.data = data;
        this.condition1 = data.blah === 'Hello';
        this.condition2 = data.blah2 === 'World';
        this.something = data.something;
      }

      onFailure(errorMsg) {
        this.loading = false;
        this.errorMsg = errorMsg;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }

If for some reason I was feeling crazy and I wanted the store to handle a second Ajax call, the store code becomes much more cumbersome so I avoid this.

Even with some of the slicker Flux implementations, I still have tons more boilerplate than a traditional MVC app which for the simple UIs makes the code more difficult to reason about. For example, I find that in my store, I frequently forget to "reset" some property thus making the state "invalid". I've come up with this type of pattern, but it just feels... odd:

      resetInitialState() {
        this.loading = false;
        this.errorMsg = null;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }

      onFailure(errorMsg) {
        this.resetInitialState();
        this.errorMsg = errorMsg;
      }

<comment><USER4> > I still have tons more boilerplate than a traditional MVC app which for the > simple UIs makes the code more difficult to reason about.

I think this is just the relative immaturity of the ReactJS/Flux stack, and having to do this boilerplate is just part of the cost of being bleeding edge (much like struggling with understanding Transclusion/Directives/et-al when Angular was first released with crappy documentation).

</comment></comment><comment><USER45> "There are only two kinds of languages: the ones people complain about and the ones nobody uses" \- Stroustrup

Its kinda make sense in this context.

</comment><comment><USER46> The presentation has some really great points; it's a shame that it's wrapped up in so much FUD.

But from what I can tell, it _does_ seem like React is moving in a more reactive direction.

One example: [https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398) Another (not sure if this counts, but I think it does): [https://github.com/reactjs/react- future/blob/master/09%20-%2...](https://github.com/reactjs/react- future/blob/master/09%20-%20Reduce%20State/01%20-%20Declarative%20Component%20Module.js)

</comment><comment><USER47> I agree with others that the author seems to be missing the point of React. Whether or not it is "reactive" or doing things the way you're _supposed_ to do them is irrelevant. It's a tool, and it either helps you fix your problem, or it doesn't. IMHO React helps a lot.

I've built a few non-trivial apps with React this year (e.g., [https://github.com/robmclarty/barss](https://github.com/robmclarty/barss)), and after years spent building and maintaining apps made with backbone, angular, jquery, and other libraries (considering the domain of React => the view) I can easily say that React has saved oodles of time, allowed me to greatly understand my apps as a whole much more clearly, and enabled me to think less about propping up a structure for my app and focus on actually designing my app.

The point is, it's not about what's passive or reactive or [insert enlightened path to programming here]. It's about what works; what keeps the ball rolling; what gets your app online and in front of users.

When it's snowing outside and I'm making a decision about what I should cover my feet with, I'm concerned about "what will keep my feet dry?". When I'm moving across town into a new apartment, I'm concerned with "what will have enough volume to transport all my junk?". When I'm making an app, I'm concerned with "what will make this design in my head work in a browser?". Whether I wear boots or shoes, whether I use a diesel truck or a gasoline van, or whether I use React or Whatever; that's not what's important.

I _like_ that React doesn't drag me into event-listener hell where stuff is firing from somewhere that I don't know where. I _like_ that React compartmentalizes templates with the behaviours that manipulate them. I _like_ that React passively alters itself based on state changes.

When it comes down to it, an app is, simply, an interface for mutating and presenting data. It can be in one of many possible states at any given time. React just presents a view of the app that is based on its current state of data. With React, all I have to worry about, conceptually, is "what's the data?" and my app reconfigures its presentation accordingly.

TL;DR At the end of the day it doesn't matter what's right or wrong, it matters what realizes your intentions as a programmer (and as a human). The way React works makes my job easier, more productive, and faster. It doesn't suck at all.

</comment><comment><USER48> Does anyone else have real world examples of how you would actually build an application based on reactive programming? I've seen people from netflix give the same talk over and over, but they never really seem to go past handling drag or mouseover events. These account for maybe 1% of any of the applications I've ever built.

</comment><comment><USER39> I never understand people who claims "Don't use X" (about software). If you don't like X - don't use X and calm down, don't be a bigot crying "you all are doing it wrong" \- let people make mistakes. Maybe some of them will find right solution on the next step, just don't stay on their way.

</comment><comment><USER49> Andre's twitter feed has a link to a article on the same topic. (edit: I find it easier to read an article instead of slides.)

[http://futurice.com/blog/reactive-mvc-and-the-virtual- dom](http://futurice.com/blog/reactive-mvc-and-the-virtual-dom)

<comment><USER49> And the viedo of the presentation: [https://youtu.be/9QObt0SGriI](https://youtu.be/9QObt0SGriI)

</comment></comment><comment><USER50> Can we change the link to the video instead of the slide deck? [https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be](https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be)

Slide decks are (mostly) meaningless without context.

</comment><comment><USER51> I feel like this presentation kind of misses the point. React itself isn't reactive. It is a UI rendering library that is easy to use in a way that is reactive. When used in the way that React's authors recommend, your application will end up being written in a reactive style.

</comment><comment><USER52> It's becoming rather frustrating how often people are misinterpreting "reactive programming", the author included.

[https://en.wikipedia.org/wiki/Reactive_programming](https://en.wikipedia.org/wiki/Reactive_programming)

</comment><comment><USER53> I just want to say that this is the definition of "reactive" is amazing! Now I finally understand what "reactive" actually means.

</comment><comment><USER54> No delayed rendering? Isn't the programmer responsible for telling react when to render?</comment>


Kindergarten Has Become the New First Grade - <AUTHOR> http://www.theatlantic.com/magazine/archive/2016/01/the-new-preschool-is-crushing-kids/419139/?single_page=true <comment><USER2> This is one part of a much larger trend of dismantling all niceness in American life. EVERYONE now works much harder than they used to: workers work more than 10 hours a day with similar or lesser benefits, college students work much harder to get the same jobs, where we had one breadwinner supporting an entire family we now have two struggling to support families. Even kindergarten kids work harder than they ever have in history.

It does not take a genius to figure out that this is not a sustainable system. All benefits of the lower classes working really hard will keep accumulating to the top until society collapses on itself. Or maybe not; we could return to a stable feudalism.

In any case, the solution to this obviously is that kids should not have preschool, but their parents (particularly the mom) should stay home with the kids and play. That interaction with parents teaches kids far more than a lowly paid preschool teacher will. That's how it was done for centuries. That's what works.

<comment><USER3> >parents should stay home with the kids and play. That interaction with parents teaches kids far more than a lowly paid preschool teacher will.

Do you have kids? I have a 2.5 year who has been in a small day care setting (about 10 kids) for 2 years. The effect it has had on her social (and even academic) skills have been pretty amazing.

She is learning so much more about how to deal with other people, social interactions, ect than she ever could staying at home with me.

>[One parent staying at home with the kids] was done for centuries.

Not really. Preindustrial revolution life was much more communal and based around large, multi-generational family units.

<comment><USER4> Even a few generations ago, 4+ year olds wandered the neighborhood with the other 4+ year olds lightly supervised and played games in the woods. Today that never happens.

And in those large family units, all the kids played with each other constantly and barely bothered the parents to do anything.

<comment><USER5> That doesn't happen anymore? Man it's sad to think I was probably the last generation to wander around outside with my friends and play.

<comment><USER4> Well at least in Canada and the USA in many spots. I don't know about europe and other parts of the world.

It is pretty sad.

</comment></comment></comment></comment></comment><comment><USER6> It's weird to read an article like this today, dated January 2016, in light of Congress passing ESSA two weeks ago, eliminating most federal rules around national standardized tests. [http://edsource.org/2015/in-bipartisan-vote- congress-overwhe...](http://edsource.org/2015/in-bipartisan-vote-congress- overwhelmingly-approves-new-federal-education-law/91650)

<comment><USER7> Dismantling the federal rules doesn't dismantle the state rules which, whether or not they were in part designed to meet the federal requirements, exist independently. Nor does it, more to the point, rewrite the actual school curricula or transform classroom practices that were shaped by the system produced by the old federal rules and associated state rules.

This is largely an advocacy piece about how practices should be changed (focusing on what is viewed as negative about current practices); it makes as much sense to see it now -- when the federal rules allow practice to change -- as any other time.

Where is the weirdness?

</comment></comment><comment><USER8> This is a very US-centric article. Lots of other countries start out education with a fair degree of desk work, rote memorization (eg of the alphabet, basic addition and subtraction), expectations of being able to read by the end of the first year and so on...and they're doing fine. My education in Ireland would probably have seemed pretty Dickensian by the author's standards (although we also had unstructured time, physical play and so on), and yet Ireland consistently does well on measures of academic achievement and in terms of cultural capital.

My parents both liked reading (thanks Mm & Dad) so I was lucky enough to be able to read before I went to school at age 4, and the idea that it's bad for kids' brains to teach them to read before 5 or 6 just seems laughably delusional to me. I would have resented anyone trying to interfere with my reading at a young age and certainly plan on teaching my own kids to read should any come along. The article's suggestion that kids can't identify any similarity between the veins in a leaf and those in their hand because they're being subjected to too much book learning strikes me as bizarre.

Of course one shouldn't generalize from one's own experience, but given the highly standardized nature of the educational curriculum I grew up with, if it was so bad I'd expect that to have manifested in the form of intractable social problems or declining international rankings by now.

</comment><comment><USER9> This is a really disturbing trend to me. If you learn to read one year earlier then the last generation then.. what? What long term effect will that have on your life? Kids are learning so much at that young age already, even if they aren't sitting a desk learning from a certified teacher. It's cliche, but we need to let kids be kids for a while.

<comment><USER10> My daughter learned to "read" at 18 months. This was done by putting cards with words next to the things they described all around the house (a card written with "BUCKET" was put next to an actual bucket) for weeks, pointing them out and explaining them through the days. Then occasionally collecting them up and spreading them out on the floor to play a game "Emi, go bring me the bucket card". After six months she was reading billboards along the highway.

The key idea though was that it was always just a game, never a chore. We'd put the cards back BEFORE she got bored of them.

She could read a 400+ page novel in a day at age 11. I can't even come close to that.

<comment><USER11> This sounds like an interesting approach. What age did you start doing this?

<comment><USER12> it's an interesting approach if you like picking up bits of torn up and chewed up cards all day long. as for a reading 18 month old child, i call bullshit.

<comment><USER10> Notice the quotes. I said "read" not read. She was recognizing words on billboards by remembering the letterforms from cards. But it was a start.

</comment></comment></comment></comment></comment><comment><USER13> Two articles on the front page.

One lamenting that college graduates don't have any real skills and the other saying that Kindergarten is now harder than ever.

<comment><USER14> Maybe not unrelated

 _New research sounds a particularly disquieting note. A major evaluation of Tennessee's publicly funded preschool system, published in September, found that although children who had attended preschool initially exhibited more "school readiness" skills when they entered kindergarten than did their non- preschool-attending peers, by the time they were in first grade their attitudes toward school were deteriorating. And by second grade they performed worse on tests measuring literacy, language, and math skills. The researchers told New York magazine that overreliance on direct instruction and repetitive, poorly structured pedagogy were likely culprits; children who'd been subjected to the same insipid tasks year after year after year were understandably losing their enthusiasm for learning._

<comment><USER15> > ... children who'd been subjected to the same insipid tasks year after year > after year were understandably losing their enthusiasm for learning.

And yet we pretend this isn't by design! The US system is based on 18th-19th century's Prussian system which was used in their military to create more obedient soldiers. That's why school is soul crushing and so many children suffer in school. We are teaching them obedience above all else.

The system stinks.

<comment><USER16> I think that the Prussian bit is overdone. For one thing, the Prussian government was not trying to create more obedient soldiers--it had ample & brutal discipline for that--but literate ones. For another, it was the widespread literacy that US reformers were looking at.

</comment></comment></comment></comment><comment><USER17> What is Kindergarten for? What is school for?

Any approach is going to have consequences. For most Americans, the purpose of both is primarily daycare and also a bit of socialization.

</comment><comment><USER18> I found this article very frustrating. Everything the author is complaining about comes down to one issue: the ratio of Teachers to Students. And yet, she does not mention this once.

> A major evaluation of Tennessee's publicly funded preschool system, > published in September, found that although children who had attended > preschool initially exhibited more "school readiness" skills when they > entered kindergarten than did their non-preschool-attending peers, by the > time they were in first grade their attitudes toward school were > deteriorating... overreliance on direct instruction and repetitive, poorly > structured pedagogy were likely culprits; children who'd been subjected to > the same insipid tasks year after year after year were understandably losing > their enthusiasm for learning.

The problem here isn't that preschoolers were more "school ready," the problem is that the school system isn't prepared to handle "school ready" students. School ready kindergartners have just come from a preschool like that of my sons, where state regulations require a 1:10 teacher to student ratio [1], and they are now in a 1:20 or worse ratio public school [2]. When a teacher is going over material some students have already mastered, those students zone out.

> Unfortunately, much of the conversation in today's preschool classrooms is > one-directional and simplistic, as teachers steer students through a highly > structured schedule, herding them from one activity to another and signaling > approval with a quick "good job!"

The author claims that providing a conversational class room is "relatively cheap to provide." But this isn't something a teacher can just change their teaching strategy and accomplish. This kind of interaction requires focusing attention on a student at the expense of the other students--so it takes more teachers. It is laughably naive to claim a teacher can have personalized dialogue with 20 kindergartners at once.

> Pedagogy and curricula have changed too, most recently in response to the > Common Core State Standards Initiative's kindergarten guidelines... One > study, titled "Is Kindergarten the New First Grade?," compared kindergarten > teachers' attitudes nationwide in 1998 and 2010 and found that the > percentage of teachers expecting children to know how to read by the end of > the year had risen from 30 to 80 percent.

And yet, the Common Core only requires children know a number of sight-words, basic phonetics, and the concepts of reading (words are separated by spaces, we read left-to-right, etc.) [3]. The standards, which everyone loves to criticize but no one seems to know what they actually say, are quite easy to meet. One of my preschoolers has easily mastered the Kindergartner recommendations with nothing but teaching him that the alphabet, words, reading, and books are fun--but it takes personalized time to encourage that attitude.

[1] [http://dphhs.mt.gov/Portals/85/hcsd/documents/ChildCare/STAR...](http://dphhs.mt.gov/Portals/85/hcsd/documents/ChildCare/STARS/Kits/3to4centerteachertochildratiochart.pdf)

[2] [http://ecs.force.com/mbdata/mbquestRT?rep=Kq1411](http://ecs.force.com/mbdata/mbquestRT?rep=Kq1411)

[3] [http://www.corestandards.org/ELA- Literacy/RF/K/](http://www.corestandards.org/ELA-Literacy/RF/K/)

<comment><USER19> Heh, your comment makes me laugh. You are correct, but I was shocked to see 1:20 ratio. My elementary ratios were ~1:30

</comment></comment><comment><USER20> The biggest problem with modern formal education is that all of the incentives are screwed up. There's a race toward optimizing certain "metrics" and making progress on paper to the detriment of actual learning. Sometimes I wonder whether the educational system actually helps more than it hurts. So much of "education" is not about learning, and in fact turns students away from learning. It's amazing that the system works at all really.

</comment><comment><USER21> And has the Ph.D. become the new Master's?

<comment><USER22> If not now, then soon. The MS/MEng is for sure the new BS. I had a hiring manager from a local firm come in and say: "Yes, we are hiring entry level talent right now, masters students like you guys are in high demand and...."

The sentence betrayed his logic, that a MS is now entry level.

When asked if there were questions, one student said:"Wait, are masters now an entry level requirement or preference?"

He relied:"Yes, they are a requirement, and they are entry level not just in terms of comapny structure, but in terms of pay too"

This was bioengineering, by the way.

<comment><USER23> Bioengineering has rather high barriers to entry and an oversupply of highly qualified workers.

You see the same thing in any field that attracts more workers than it needs.

<comment><USER22> Wow, I did not know that! Do you know how much there is an oversupply of workers? I'd love to see the stats and whatnot, as I am in the field.

<comment><USER23> [https://www.asee.org/papers-and- publications/publications/co...](https://www.asee.org/papers-and- publications/publications/college-profiles/2011-profile-engineering- statistics.pdf)

4,066 undergrad in 2001 got a bio engenearing degree. +1,558 masters.

[http://www.bls.gov/ooh/architecture-and- engineering/biomedic...](http://www.bls.gov/ooh/architecture-and- engineering/biomedical-engineers.htm)

22,000 total jobs 2014 ([http://www.bls.gov/ooh/architecture-and- engineering/biomedic...](http://www.bls.gov/ooh/architecture-and- engineering/biomedical-engineers.htm))

There does seem to be steady growth in the field. But supply is definitely outstripping demand.

<comment><USER22> agreed, thank you!

</comment></comment></comment></comment></comment></comment><comment><USER24> This is the case almost everywhere else in South America. You start with pre- kinder if you wish, but most start at kinder.</comment>