The Rails Doctrine - <AUTHOR> http://rubyonrails.org/doctrine <comment><USER2> Funny, everything in this post is exactly why i prefer Python(+Django/Flask) over Ruby(+Rails). Too much magic happening everywhere, a gazillion of built- in methods, weird shit happening all over the place, all that combined with all the syntactic sugar Ruby offers.

Granted, it might look "beautiful" in the eyes of a experienced RoR developer, but personally i find it just makes code very hard to read. Just my 2 cents.

<comment><USER3> Similarly, Python turned me off immediately when I tried to exit the REPL with "exit" and it goes "The way you exit is with control-D." _It fucking knew I wanted to exit, and instead lectured me._ WTF, Python? Seeya, dick.

<comment><USER4> That's because there's no magic in the REPL. You're typing nothing but regular Python code.

'exit' is an object. Expressions typed at the REPL are stringified. Thus, when you type 'exit', it gets stringified, and thus you get that message.

'exit' is also a callable, so if you type 'exit()', the REPL will exit.

The same goes for 'help', 'copyright', 'credits', and 'license': they're just objects that get stringified.

Having the REPL work the way you want would mean building magic into it, and magic avoidance is part of the language's culture, so that's not going to happen. Having it print that message is a compromise between keeping things friendly and building magic into the REPL, if you consider printing the result of expressions automatically to be magic.

The Python REPL isn't being a dick, it's being parsimonious and predictable in its behaviour.

<comment><USER5> Yet the code behind the REPL knows exactly what I was attempting to do and tells me that.

This is what Ruby developers mean when they say they optimize for developer happiness over bowing to the will of the computer.

/uses Python regularly and enjoys it.

<comment><USER6> Those assumptions that "optimize for developer happiness" 95% of the time make the developer's life hell the other 5% of the time. It happens often enough that "explicit is better than implicit", within reasonable constraints like dynamic typing, is one of Python's core values, and experienced developers usually come to appreciate it.

It's best to design an API that makes what's happening clear without being overly verbose or esoteric, and without making assumptions, especially not dangerous assumptions that may cause you to lose data (exit may close the REPL and cause you to lose your session when you forget that exit is a special word in REPL mode). My personal feelings are that Python has done a better job at this than any other major language. I have major projects in both Ruby and Python and I enjoy the Python ones 100x more because of this.

This document partially explains why; DHH is normalizing shortcuts because it helps him gain new users, even though working around those same shortcuts becomes a major PITA when you need to go a little bit off the beaten path, which happens in one way or another in most real software. There is a way to make these things explicit with only marginally more typing/"effort" (for example, requiring parens to call functions with no arguments, making it explicit and obvious when someone is referencing a variable vs. when they're calling a function), thus avoiding the complexity down the road.

<comment><USER5> > and experienced developers usually come to appreciate it.

I find statements like this a bit condescending. It's like when Java developers say 'Oh, that's nice, but I work on _big_ applications." "Obviously you don't get it because you're not experienced. _Experienced_ developers get it."

I'm sure that wasn't your intent. But it still irks me a bit.

I've been writing software for a very long time, in many languages and paradigms over the years. I believe that qualifies me as an experienced developer. My years of experience tell me that if I only experience pain 5% of the time, then the 95% of the time I _don 't_ experience the tools I use making me do extra work more than makes up for it. :)

<comment><USER6> >I'm sure that wasn't your intent. But it still irks me a bit.

Correct. I meant it inclusively, like most of the Python community is either experienced developers who've worked in a lot of languages and have sought refuge in the sanity of Python or the apprentices of such developers. Python doesn't have a figure like DHH to give it sex appeal, so not many new people use it.

There are definitely experienced developers who have not yet had occasion to seriously enjoy and appreciate Python.

>My years of experience tell me that if I only experience pain 5% of the time, then the 95% of the time I don't experience the tools I use making me do extra work more than makes up for it. :)

I meant this as a count of the number of issues, not the amount of time it takes to resolve them. That 5% of problems caused by non-obvious implicit magical behavior usually take an inordinate amount of time to debug and solve, and then the workarounds are usually disgustingly ugly because the framework had never conceived that someone might have a valid reason to circumvent their magic. Even worse, this locked-down, "looking inside will void your warranty" attitude (which Rails often calls "convention over configuration") frequently means that the workaround must be somewhat pervasive and ugly up your code not just in one place, but in several places to really resolve the problem.

Experienced developers may not encounter this often if they don't use a lot of magical APIs that promote the systemic ambiguity of "do what I mean".

<comment><USER5> > Even worse, this locked-down, "looking inside will void your warranty" > attitude (which Rails often calls "convention over configuration") > frequently means that the workaround must be somewhat pervasive and ugly up > your code not just in one place, but in several places to really resolve the > problem.

In 2005, when nobody used Rails, as a complete beginner to Ruby, I was able to write a patch to improve the Oracle database adapter. Somehow, despite all the magic, it took me very little time to find what to change and submit a patch. As a complete newbie to the language and platform.

Rails 2 and below revolved around a lot of hacks. Rails 3 removed many of those. Rails 4 even more so. Check out the book "Crafting Rails 4 Applications" to see how easy it is to hook into places in the framework to get what you need. (Disclosure: I'm the editor of that book.)

The argument you make about "voiding the warranty" is an argument I hear from people who have touched Rails for a project and hated it for one reason or another. It's not a sensible argument.

Remember, for centuries, people used "magic" to explain away something they didn't understand. :)

<comment><USER6> >In 2005, when nobody used Rails, as a complete beginner to Ruby, I was able to write a patch to improve the Oracle database adapter. Somehow, despite all the magic, it took me very little time to find what to change and submit a patch. As a complete newbie to the language and platform.

One part of the system not being obfuscated doesn't mean that many other important parts aren't.

>Rails 2 and below revolved around a lot of hacks. Rails 3 removed many of those. Rails 4 even more so. Check out the book "Crafting Rails 4 Applications" to see how easy it is to hook into places in the framework to get what you need. (Disclosure: I'm the editor of that book.)

I currently maintain both Rail 2.3 and Rails 4 applications. I totally agree that Rails 4 is a much smoother experience. There are still hacks around the magic that I've had to implement. The one most immediately on the top of my head is one of the form generators ignoring the method argument in some circumstances because it _knows better_ and forcing me to jury rig them into obeying the command anyway (with a bit of JavaScript that alters the method on-page IIRC).

>The argument you make about "voiding the warranty" is an argument I hear from people who have touched Rails for a project and hated it for one reason or another. It's not a sensible argument.

Of course it's a sensible argument. Frameworks shouldn't be causing those feelings in people -- the magic isn't magical if it's getting in the way. If people are coming away with the impression that the system will blow up or otherwise misbehave when they try to peel back the covers, it's ignorance to just blame them for feeling wrong. One should try to at least understand the problem; then, you can decide if it's a problem that needs correction or if you're just OK with people who want some flexibility and cooperation from the framework not using your stuff and be honest about that so that they don't have to waste their time.

>Remember, for centuries, people used "magic" to explain away something they didn't understand. :)

And, also for centuries, people used "magic" to hoodwink gullible people.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I submit that anyone who takes the time to really learn Rails and how it works and the problems it solves will never want to use another web framework except for toy projects. It really is that good, and just keeps getting better every year.

It does one thing, web applications, and does it really, really well for the type of coder / team it was designed for.

People that belittle it by saying it has too much magic or whatever have never seriously tried to maintain a huge web application all by themselves. Web apps are ridiculously, mind-bogglingly complex, Rails conventions have been baking for well over a decade now.

If you're Twitter, maybe you have the resources to maintain a serious web presence without Rails. Everyone else is just handicapping themselves.

<comment><USER8> Having used Rails seriously since it was originally made available as an open source project, I find myself agreeing with you less and less. It has really failed to stand the test of time, in my opinion.

I agree that it nailed the needs of web applications in 2004. If you are still building web applications like they did then, perhaps it is still the best tool. In the circles I find myself in, there is a push for much more Javascript heavy applications and Rails starts to become a large hinderance more than a help in that environment, when compared to other tools.

We've built a log of great software together over the years, but I can honestly say that I'm not going to rush into using it in future projects.

<comment><USER9> This is a bizarre comment. Rails failed to stand the test of time because it doesn't play very nicely with monolithic JavaScript frameworks? Are you asserting that such frameworks are the future?

<comment><USER10> I think they are referring to most UI logic being on the client, not on server. That architecture does not require a monolithic JS framework, nor does Rails offer anything special in that case.

<comment><USER9> "Doesn't offer anything special" is quite different than "starts to become a large hindrance."

</comment></comment></comment></comment></comment><comment><USER11> I've been a Rails developer for 10 years now and I have to say it is still my favourite tool of choice (yes even in 2016). There are other interesting tools and frameworks out there (I'd love to put my hands on Phoenix and Elixir if I had the time) but for now I have to be honest: When I start a new client project I have to consider a few things:

* Using a well-known framework is favourable over new shiny toys in a commercial system

* An ecosystem that has good 'defaults' is essential. A single web framework won't do everything for you. You need stuff around that for testing, deployments, etc.

For mainly the reasons above Rails is still my primary tool of choice. Yes, it has pinpoints but the reasons above far outweigh the new and shiny.

</comment><comment><USER12> Couldn't agree with DHH more.

I found Rails during the 0.9 releases. Coming from the horrific world of Java web frameworks like Spring and Tapestry, it was a revelation to see how fun and productive web programming could be again.

When I saw things like 2.times, 1.day.ago, and ActiveRecord, I knew I was done with Java web development. This isn't a knock against Java per se, but I just spent so much time in the trenches having to do busywork and configuration that isn't necessary if authors of those frameworks put programmer productivity and enjoyment first.

Thank you DHH!

<comment><USER13> > 1.day.ago

So apparently .day multiplies the number of seconds in a day by the receiver, then .ago subtracts that from the current date[0].

However, not all days contain the same number of seconds. This is where "friendly" APIs like this lose me - they're vague and sometimes incorrect.

In Foundation, which I consider to have a decently designed date API, "dates" are doubles of seconds all since a reference date, and "date components" are used to express the concept of days, months, and years - which also require a time zone and a calendar to even make sense.

[0] [https://stackoverflow.com/questions/21392065/how-do-you- impl...](https://stackoverflow.com/questions/21392065/how-do-you- implement-1-day-ago-in-ruby)

<comment><USER14> That StackOverflow answer is wrong.

Rails does correctly handle `1.day.ago`, taking into account the number of seconds in a day.

`1.day.ago` is a perfect example of what DHH was saying, in that it looks beautiful, but requires a bit of work under the hood. `1.day` creates a duration. This isn't just a number of seconds, but is represented by hash, more like `{:days=>1}`. When it's time to do the actual math, Rails looks at the :days number, and actually moves the day part of the date forwards and backwards.

Source here: [https://github.com/rails/rails/blob/master/activesupport/lib...](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/date/calculations.rb#L113)

</comment></comment></comment><comment><USER15> I recently wrestled with the idea of using NodeJS for any side projects. I touched Ruby/Rails in the past for a few times (on-off between small works) and never really felt excited or see it as something "beautiful" because at the end of the day, we, developer, still have to debug our own buggy code.

After a few strings of drama in the NodeJS land, a few chat with friends who used NodeJS in production, and seeing the pattern of BigCo who use NodeJS only for glue/front-end/gateway appserver, I'm pretty close to settle with Rails.

I admire DHH for his dedication to the framework for so long (since 2004). You don't see that type of dedication in the NodeJS land. Yes, NodeJS is still new, but a few BDFL/leaders of important NodeJS projects had left the boat already. One of the premier NodeJS vendors, StrongLoop, always mired with controversy (I happened to know a few people who worked for a company that was acquired by StrongLoop).

Building long-term side-project requires a stable platform because of the time limit (outside office hour + other responsibilities). Dealing with unstable but "sexy" technology is not a good choice.

</comment><comment><USER16> I think DHH has realized that Rails has a bit of an "image" problem when it comes to new web app development, and this is a way to lay out why Rails remains relevant and even desirable. No doubt some will take exception to some or most of his points, but that's OK. For the rest of us who thrive in continuing to build with and evolve the Rails ecosystem, it feels good to see a renewed focus on communicating just what makes Rails (and Ruby) special and vital.

</comment><comment><USER17> For those that are interested in a more performant and scalable Rails-like experience I encourage you to check out Phoenix: [http://phoenixframework.org](http://phoenixframework.org)

We have been working with Elixir (the language Phoenix is built on) for over a year. It is an incredibly satisfying language and its toolset is surprising advanced for its age. Phoenix has been a very easy mental jump for our developers who were already trained on Rails.

<comment><USER18> To add another side to this coin, having recently used Phoenix to write an api after hearing good things, I found Elixir clunky, and Phoenix poorly documented. It tries to be too much like Rails (I realise this is the point, though), and is currently failing spectacularly in my opinion. YMMV obviously.

<comment><USER19> In the spirit of making our docs better, what did you find poorly documented? We go to great lengths to have extensive, comprehensive docs. Pick any module in our source, and you'll find extensive documentation on usage, APIs, etc. All docs are extracted to hexdocs.com as well [http://hexdocs.pm/phoenix/Phoenix.html](http://hexdocs.pm/phoenix/Phoenix.html)

This is in addition to our separate online guides focused more on getting up and running through the basics. Where did we lose you?

<comment><USER20> I think the Phoenix/Elixir docs in general are quite good, it's just the lack of years of blogs and stackoverflow q&a that makes it harder to jump in. Switching from Ruby's OO/functional to Elixir's purely functional/immutable/actor-based would be easier with more of other people's code to read and learn from.

I'm a complete n00b and was just trying to get a pool of TCP client workers to monitor servers and update a DB and display the results in a Phoenix app, and I kept coming across the same 4-6 blog posts and docs, maybe 60% of which were for pre-1.0 Elixir and no longer quite worked.

I see a huge amount of promise with Elixir/Phoenix as well; currently it makes some hard things easy but also many easy things hard. With a few years of library/community growth I could see it wiping the floor with Rails for a lot of projects.

<comment><USER21> An Elixir/Phoenix "Railscasts" would be great too

<comment><USER22> [http://elixirsips.com/](http://elixirsips.com/)

</comment></comment></comment></comment></comment></comment><comment><USER23> Now that Rails isn't the cool new thing anymore, is it still a good choice for new projects?

For the new year, I'm thinking about the programming landscape and contemplating what I want to learn next. I've tinkered with Ruby on Rails in the past and think DHH is on to something with the doctrine he has laid out. I've only scratched the surface of Rails, but it still seems pretty neat to me. A deeper dive would be fun.

On the other end of the spectrum, Dart + Angular is appealing in part because I'm a fan of some of the Google developers working on Dart. While Rails feels like it is entering a comfortable middle age (or at least adulthood), Dart feels a little like a car being assembled as it cruises down the interstate. It's new and maybe a bit dangerous.

Both projects are super-appealing to me. Unfortunately time constraints prohibit me from chasing both and I'm interested in opinions especially of Rails people. Are you still excited about it?

<comment><USER24> > Now that Rails isn't the cool new thing anymore

But why does that have an impact on what tech you use?

<comment><USER23> It's a good question and it's really what I'm asking about.

The only web-stuff I've worked on in a commercial settings was a long time ago using Java and Tomcat. At the time, it was the cool new thing. I think that some of the pain points of languages and frameworks from that era are what prompted DHH to develop Rails (I'm specifically thinking about convention- over-configuration and admit I could be totally wrong here).

So today, I probably wouldn't pick Java and Tomcat for a personal project just because I know it won't be as fun and I won't be as productive as I would be with different technology. Has Rails been eclipsed in a similar way?

<comment><USER15> I'll pick Java, SpringMVC, Maven, JUnit+DBUnit, and FlyWay (DB migration) and any appserver (jetty, tomcat, TomEE, glassfish) thrown at me except from the BigCos (WebLogic, WebSphere).

Those tools are pretty close to what Rails give you (notice the View/UI is open for anything... Rails View is slightly nicer as it has better templating capabilities but ... not a deal breaker for me).

It's not sexy, it gets the job done, and I know it'll run for at least 5-7 years with minimum hassle.

Plus it's easy to be productive on Java project...

<comment><USER25> Upvoted. I am tired of getting the "uncool old fart" looks every time I propose similar stack. You CAN do cool stuff with established tech plus have a peace of mind that you will not run into any "surprises".

<comment><USER23> It makes total sense to mitigate risk on a commercial project by going with established (well supported, well understood) technology. No argument. But for a personal toy project where you _want_ to be surprised, would you choose something like Ruby on Rails?

</comment></comment></comment></comment></comment></comment><comment><USER26> About picking the "Best" tool for the job. One annoying thing about Stack Overflow is that they aggressively stop those types of questions with their mod system. Just understanding the Pros and Cons of the major options is very valuable, but not allowed.

<comment><USER27> About SO, it's just that this isn't the goal of SO. The goal of SO is asking a precise question and getting a specific result, it's not a place for debate or opinion.

Quora could have been that place, for some reason and because of some odd UX choices ( mandatory signup to browser the site ) , it isn't , which is too bad.

<comment><USER28> So it would destroy SO if, in the context of programming, there was a best of question? Are they really that tight-assed? Do they not have the bandwidth? Really, I'm curious how those questions would hurt the site. And Quora? Why would SO prefer users to actually go somewhere else? Debate and opinion, despite what the moderators think, is a valuable part of coding. It isn't all "solve for x."

Because the interesting thing about the 'ask a specific question' concept is that some questions are closed because they're too specific. I pretty much abandoned SO. The anal retentive pendants moderating things have turned me off to spending any time contributing.

<comment><USER29> It's just subjective and unproductive noise.

The strict moderation and categorization is what makes stack exchange useful in general. Why not use a free-form forum like Reddit for that kind of question? Because you know the answers are going to bullshit opinions and holy wars, mostly by people that are trying to solve different problems than you, or are actually less knowledgeable than you.

Given the fact that Reddit and similar forums suck for finding solutions to specific problems, why should a Q/A site that is good for finding solutions for specific problems try to emulate it?

Quora and Yahoo answers also suck because the questions are almost entirely anecdote and opinion based, and it seems to be acceptable to cite "experience" as a source for bullshit opinions. "Being a pilot with 10 years of experience" is not an adequate reference for a response to a question about the safety of using a cellphone radio on a commercial flight, nor does "being a veteran" count as original research into Iraqi popular support for the 2003 invasion.

Of the good "answers" from Quora that I've seen shared, all are basically long form blog posts that have found a "close enough" question to answer, rather than been motivated by the question, and I would have actually preferred to read them on medium or some other blog site. However interesting they are, they aren't answers.

I think projects like Rosetta code are useful for comparisons of programming languages, because they keep it concrete. You can also look at big high- quality projects on github or whatever and directly judge the subjective qualities of a language for yourself, based on how readable the code looks to you.

</comment></comment></comment></comment><comment><USER30> I was just singing praises to Rails last night for these reasons.

At my corporate job, we use Java with Spring, and a hellish mess of node packages/libraries/whatever we're calling them now. It's not good.

So when I do side projects or consulting gigs, I always run to Rails which is what got me into development. It's very refreshing.

Reminds me of the jQuery post the other day. Rails is just a little older than jQuery. Rails with some jQuery sprinkled in is as close to development perfection as I've ever seen.

Also re: "too much magic" \- Why is magic a bad thing? Creating layers of abstraction to ease building is what programming is really about, right? Why would we want to go backwards to configure everything under the claim of "I need to know how EVERYTHING works!"?

<comment><USER31> Sometimes (performant) SPAs provide a better user experience than regular views strung together with Ajax/jQuery. But otherwise, I agree. Rails and jQuery were probably the first truly "nice" APIs I've used in programming, and I still get quite a bit of enjoyment from using them, to this day.

<comment><USER30> I've seen a few examples of performant SPAs providing a better user experience, but I can only think of a couple. One example would be the Timbuk2 bag customizer: [http://www.timbuk2.com/customizer#/product/15-custom- commute...](http://www.timbuk2.com/customizer#/product/15-custom-commute- laptop-messenger-bag/size/4/customize)

But even this seems possible without committing to an SPA architecture. If I recall correctly they are using Ember for this.

But yeah, you're right.

<comment><USER31> Check out [http://ask.fm](http://ask.fm)

This is actually a SPA _and_ a bunch of strung together jQuery. But things subjectively feel "faster" compared to what the site was like before they upgraded to this model.

</comment></comment></comment></comment><comment><USER32> There is great stuff to say Ruby and RoR. But I have yet not experienced the "smile" that DHH is describing. Especially when I have to read and understand the code written by colleagues (or myself mind you). To do my job I had first to become a master in grep to find where stuff come from and deciphering half assed documentation. Mostly because exploring objects with hundreds of methods is not my cup of tea. I also enjoy understanding my tools, and RoR is, in my experience, not particularly easy to understand. This doesn't put a smile on my face.

<comment><USER33> batiste, I think what you are describing is that the culture around Ruby doesn't put a smile on your face, rather than just Rails.

Ruby's philosophy is quite a bit different from Python, Smalltalk, Perl, Java, and PHP. Ruby is roughly described as "batteries included." Some people don't prefer this, as it encourages meta-programming and introspection rather than explicit instructions.

A lot of libraries and tools around Ruby use meta-magic; some libraries have been attempting to strike a middle ground with meta magic, such as Datamapper (explicit) vs ActiveRecord (implicit). But the bias is definitely towards implicit; or as what DHH calls "omakase."

</comment></comment><comment><USER13> > Where Java championed forcefully protecting programmers from themselves, > Ruby included a hanging rope in the welcome kit.

I don't think this is something to be admired in a language. Java is a bad language to work in because it's not expressive, not because it protects programmers (which it _doesn 't_).

Thankfully, we are seeing this shift the other way with the growing popularity of languages like Rust and Swift.

<comment><USER34> _Java is a bad language to work in because it 's not expressive, not because it protects programmers (which it doesn't)._

Compared to C/C++, yes it does. Java protects you from out-of-bounds array access, uninitialized access, buffer overflows, use-after-free, double-free, etc etc.

<comment><USER35> Memory safety is a protective feature as much as sending texts is a smartphone feature. Sure, it is nice and very useful, but almost all languages provide it, so it does not count for much these days.

<comment><USER36> Thats how it should be, but the frequency of C/C++ threads on HN and the discussions about memory safety that will inevitably follow unfortunately paint a different picture.

God I hope Rust will shoot C++ in the backyard and put it out of its misery.

</comment></comment></comment></comment><comment><USER37> >Optimize for programmer happiness

I've never been more unhappy programming than when I touch Rails. I'll take python or Java any day of the week.

>Convention over Configuration

Discoverability is totally gone. Walking into a brand new RoR app and it's next to impossible to figure out what's going on. Not having a good IDE doesn't help.

>Exalt beautiful code

Write simple easy to read code. Don't be clever.

<comment><USER38> >I've never been more unhappy programming than when I touch Rails. I'll take python or Java any day of the week.

Try PHP

</comment></comment><comment><USER39> My background is Python, C#, and SQL, and it shows because those languages have affected the way I think about programming.

I strongly disagree with DHH's points 2,3,4, and 6. But I think I'm going to learn the language anyway and use it for some projects because I think it's important to not get in a rut. Using different languages changes the way you think about code, and if you are not constantly updating the way you think about code, you are falling behind.

Besides, I really like the way DHH writes. His language is persuasive even when I quite certainly disagree with him.

Still going to learn a functional language first probably. But then Ruby/Rails.

<comment><USER40> A tad bit off topic, but for your functional language I'd recommend Haskell. It's given my mind the most trouble out of any of the other functional languages I've tried (which is a good thing). I find it's syntax reasonable, and resources plentiful.

Excellent lecture series on functional programming (language used is Haskell):

[https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer- Fun...](https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional- Programming-Fundamentals/)

When you get to trying to understand monads, DON'T look up monad tutorials, look for functor -> applicative functor -> monad tutorials, like this one:

[http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html)

<comment><USER39> Thank you for this. Much appreciated. I have a copy of learn you a Haskell for great good and have been slowly working my way through it in my occasional spare time.

Also interested in F# these days now that Microsoft seems to be open-sourcing . . . pretty much everything.

<comment><USER41> There's only one way to learn Haskell: you have to use it!

Both links below show how friendly the Haskell community is for people willing to learn:

[https://github.com/NICTA/course/blob/master/README.markdown](https://github.com/NICTA/course/blob/master/README.markdown)

[https://github.com/bitemyapp/learnhaskell/blob/master/README...](https://github.com/bitemyapp/learnhaskell/blob/master/README.md)

Good luck on your journey!

</comment></comment></comment></comment><comment><USER42> I transcribed an interview with DHH [0] in which he also explains his motivations for choosing Ruby (instead of PHP or Java, for example), and where he explains some design principles for Rails.

[0] [http://www.transcribed-interview.com/dhh-rails-david- heineme...](http://www.transcribed-interview.com/dhh-rails-david-heinemeier- hansson-interview-randal-schwartz-floss.html)

 _" One example I always pull out is "what you gonna call the primary key in your tables?" When I was working with PHP and Java, every single shop, almost every single application, would have its own naming scheme. Some would say they have the 'Products' table and then they'd have 'productid', others would have 'product_id', some people would have 'prod_id' or 'p_id' or 'P_id', and every time somebody made a new design decision it meant configuration. You now have to tell your models, your objects, how they're going to talk to this database table. Because it needs to know what the hell you called the freaking primary key column, and it just doesn't matter! Who cares what the primary key column is called? It just doesn't matter. It's going to have zero impact on the usefulness of your application."_

and

 _" 'Dont repeat yourself' is all about not having the same intentions spread out in multiple places. Don't have one configuration. If you're calling something, let's again take the example of the primary key. If you're calling that for 'id' you shouldn't have to configure that in three different places that all have to work together and all have to be changed together. You should just pick one authoritative place to have that information stored. And then you can make changes from there. It also goes with the the whole Ruby idiom: we don't want those Java boilerplate ten line things: that's repeating yourself. If you have the same idiom, if you have the same intentions, that should really be exceedingly a short expression. And that goes up throughout the entire framework. Just keep one place to change those things, and keep the idioms very short."_

<comment><USER15> That sounds like the pre-ORM days.

These days ORM would map member variable id to database table id.

<comment><USER42> The interview is from July 2009. I think Rails already had its ORM then. DHH says:

 _" The model part in an MVC application is where all the business logic is kept. Those are all the classes like 'Post' and 'Category' and 'Author' and all those things –say if you're making a weblog– you'd keep all that stuff in the Model. And you'd have all the logic about whether the author is allowed to make a post and how the relationship between posts and comments work together. Those are all sitting in the model, so that's all the business logic, very often backed by a database in some sense, not always, but most of the time. And that's where in Rails we're using something called 'ActiveRecord'. Which is this way of mapping database tables to objects, and then decorating those objects with logic."_

<comment><USER15> I was referring to:

> When I was working with PHP and Java, every single shop, almost every single > application, ...

</comment></comment></comment></comment><comment><USER43> It is funny how small things affect your future. I did a lot of stuff with rails back in 2007 or so. However I really got fed up with it because some things were so slow. So for the next project I decided to pick up django, and I've been using django since then.

Would it have made much difference if I had staid with ruby/rails instead of python/django? I dunno. Many of my friends have careers with rails, and they have nice careers. I have nice career as well, as do many other friends with django. In the end they are not that different, I guess.

</comment><comment><USER44> If you like the Rails Doctrine, check out Phoenix Framework and Elixir language by the former Rails Core Developer Jose Valim. You'll get hooked as you did with Rails 10 years ago.

</comment><comment><USER45> I like ruby and rails, not just for the framework itself, but for what it was and it is for many developers.

I want to say thanks to DHH for his way to maintain the framework simple, despite to many PRs that try to make rails more complex.

Thanks to this document, I'd like to read also some document about the standard in big rails app.

</comment><comment><USER46> Sigh, it's hard to take any of these comments seriously without first understanding how much real-world experience they actually have in the industry.

<comment><USER47> You could probably post that comment verbatim on half the threads in HN and get upvoted.

</comment></comment><comment><USER48> Mature Ruby projects are very difficult for a new Ruby programmer to parse and understand. In contrast, Go projects are quite easy to understand.

DSLs are part of the reason for this.

Naturally there is a tradeoff. People that have been working with a particular DSL in Ruby for a long time can achieve amazing things in a short amount of time. Equivalent productivity is not really possible in Go (at least not yet, in my experience).

Having said that, I think it is easier to onboard new (and newbie) programmers onto a Go project than a mature Ruby project.

</comment><comment><USER49> Having been working with Rails for a long time, now I wonder what could be the next cool thing looks like. The only improvement I'd like to see is about performances, and Elixir and Crystal are a good candidates to replace ruby in this direction. But until now, I don't see any other framework equaling the elegance of Rails, great job David and all the community, let's continue to keep Rails weird.

</comment><comment> ryan-allen I personally prefer ASP.NET MVC, it has all the core parts of early Rails (back when it was nice and simple), and it's statically typed to boot.

The most magic thing in .NET MVC is Entity Framework, and all it's magic is either a bunch of strongly typed convention classes (of which you can create your own), or LINQ queries, which work pretty well.

If I'm building stuff for Adults with Money I'll choose static typing any day.

</comment><comment><USER50>
      This is easily described with a contrast to Python. [...] Ruby accepts both exit and quit to accommodate the programmer's obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what's requested, even though it obviously know what is meant (since it's displaying the error message).

When you're trying to convince me that your programming language is great because another one is so much shitter in comparison, you're on the defensive and basically telling me you don't trust your own stuff. Especially when this is at the top of your article.

By the way, python handles your example very gracefully in comparison to other REPLs (for instance, node spits out a cryptic, but expected traceback on exit/quit)

<comment><USER51> He didn't say Python was bad in comparison. He just highlighted a simple example of coding to spoken language expectation even if it means aliasing. It's a minor example of trying to make the development experience more enjoyable, nothing more.

<comment><USER50> Did you read the quote? He very exactly says that python is bad in comparison - by using a concrete python vs ruby example.

If this was a passing mention on some blog post, I'd be inclined to believe you, but this post is not like any other. It's a descriptive update of the current rails "doctrine". When I ask you "why is your X so great" and you tell me immediately "look at how bad Y does", I'm inclined to think you're not feeling very secure about X.

<comment><USER51> Here is the exact quote from the article:

> Anyway, what did this mean for Rails and how does this principle continue to > guide its evolution? To answer that, I think it's instructive to look at > another principle that was often used to describe Ruby in the early days: > The Principle of Least Surprise. Ruby should behave how you'd expect it to. > This is easily described with a contrast to Python:

> _code snippet_

> Ruby accepts both exit and quit to accommodate the programmer's obvious > desire to quit its interactive console. Python, on the other hand, > pedantically instructs the programmer how to properly do what's requested, > even though it obviously know what is meant (since it's displaying the error > message). That's a pretty clear-cut, albeit small, example of PoLS.

Nowhere in the above is he calling Python bad. He's using an example of how Python handles a thing to illustrate how Ruby handles that exact situation differently inline with his philosophy "Principle of Least Surprise". I'm not trying to get into a semantic argument here, just pointing out that he's making an illustration with a minor detail.

Calling Python "bad" would make no sense, because Python is wonderful. This is just a way to highlight how Ruby does things differently than others have chosen to do them.

<comment><USER50> Unfortunately it seems like the argument is mainly semantic then - I find it reasonable to think that "pedantically instructs the programmer how to properly do what's requested, even though it obviously know what is meant" is pretty much a detour to say it's not good, it's _implied_.

I just don't see why DHH needs to do this - ruby has so many things that make it stand on its own.

<comment><USER51> That's fair. Sometimes to put decisions in context you need to be able to compare it to something else, but I do understand where you're coming from.

</comment></comment></comment></comment></comment></comment><comment><USER52> 9\. Monkey patching instead of good design 10\. Don't worry about data integrity

</comment><comment><USER53> I know PHP-bashing is oldschool, and I love what I've been able to do with PHP.

After a decade of me in PHP, his love for Ruby is a lovely selling point for trying out that language.

</comment><comment><USER54> Bit off-topic here:

How is the Rails market these days? It seems (personal perception of outsider) that it has been replaced by Python/JS work.

<comment><USER55> There is still enough work and projects being built using Rails. Of course NodeJS stole a lot of thunder from Ruby/Rails, but everyone who has been smart either went back to Ruby/Rails or moved on to Go (if performance was an issue). I don't think Python is an issue, it's always have been that people went from Ruby -> Python and vice versa.

<comment><USER54> The change from Rails to Go must be quite shocking. Going from such a completely framework to a barebones language is a huge step. I write Go and went from Python -> Go and it still was a bit of a jump. :)

</comment></comment></comment><comment><USER56> DHH is amazing.... Thank you for creating RAILS.

</comment><comment><USER57> I was hit hard by the cognitive dissonance at the start of section 2.

Just after waxing in section 1 on how Rails is designed to his own happiness (including adding quirky methods like 'fifth'), he says "One of the early productivity mottos of Rails went: "You're not a beautiful and unique snowflake""

</comment><comment><USER58> I think this should be post here: [https://dockyard.com/blog/2015/11/18/phoenix-is-not- rails](https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails)

It's very interesting to see such different philosophies.

</comment><comment><USER59> > Progress over stability

> We have to dare occasionally break and change how things are to evolve and > grow.

> ...harder to swallow in practice. Especially when it's your application that > breaks from a backwards-incompatible change in a major version of Rails. > It's at those times we need to remember this value, that we cherish progress > over stability...

I encountered this doctrine first hand. A division of a company I worked at had its division's website rewritten in RoR by some outside consultants. Even brand new, it was a mess of Ruby gems of conflicting dependencies which was undeployable. The build system was a train wreck as well. Some of the main web pages of their web sites like rubygems.org were not available - the web site had "progressed" and when you clicked on a link, the page explaining anything had disappeared. I mean hell, go to rubyforge.org this minute (1:15 PM EST) - it is down, of course. The blog of the author of the Ruby gem that then was the main gem that handled web serving did not inspire confidence.

As I would have to maintain it (as a sysadmin, not programmer), I refused to deploy the system, since it was an unreproducable mess of conflicting gems and gem versions and kludges. They decided to pay the RoR consultants additional money, despite them having never delivered a working system. By the time I left, it still was never deployed. The division closed dozens of offices soon after, and then the division shut down - perhaps not completely related, but probably somewhat related to this project.

Meanwhile, the company's other divisions had decent programmers programming for Java application servers, and that code and those servers were much more solid. Builds rolled out easily (and could easily be rolled back if need be). It was really night and day. It makes sense this contempt for stability is explicitly part of their doctrine.

<comment><USER60> DHH's is talking about the doctrine of the framework, not random apps built atop the framework.

rubyforge.org has been offline for over a year and a half, as announced over 2 years ago.

You describe a Rails application written by outside consultants that was undeployable, and compare it to apps written by internal Java developers. I believe the quality of the developers had more to do with the deployability than the languages of choice. You could just as easily have a Java application written by consultants, with undocumented JARs, magical PATHs, mystical server.xml's to make things work just right, and crazy ant scripts.

<comment><USER59> > rubyforge.org has been offline for over a year and a half, as announced over > 2 years ago.

To those not drinking the RoR kool aid, this is toward my point. Two years ago rubyforge.org was a central repository of Ruby gems. Now it is a web page that says "RubyForge Could Not Connect to Database:". Of course, in the minds of some, this does not reflect poorly on _RoR_ but me - I am supposed to know that two years ago they decided to transform this central hub of Ruby gems to a web page that says "RubyForge Could Not Connect to Database:".

This kind of thing is par for the course with Ruby. I know that the [http://perl.org/cpan](http://perl.org/cpan) page I used twenty years ago is still redirecting somewhere sane, but rubyforge.org ? "RubyForge Could Not Connect to Database:" \- and the fool is _me_ for not knowing why. This is typical of the kind of thing you deal with in RoR world.

Insofar as projects - a Java project can be junk just like an RoR project can, yes. The thing though is that relatively, the core Java infrastructure, community, API etc. has been much more stable over the past twenty years.

Hearing that rubyforge.org disappeared eighteen months ago to be replaced by this cryptic message makes me more down on RoR-world than if it was just their website being down for a few hours. It's the kind of thing you deal with in RoR-world all the time.

<comment><USER61> Rubyforge.org was a 'central repository of gems' in name only. The transition to gemcutter, which turned into today's rubygems, happened in 2009: [http://www.rubyinside.com/gemcutter-is-the-new-official- defa...](http://www.rubyinside.com/gemcutter-is-the-new-official-default- rubygem-host-2659.html)

</comment></comment></comment></comment><comment><USER62> I like the philosophy of optimizing for programer happiness even if it's imperfectly implemented. I think those kind of ideas have more power than they are commonly credited with.

</comment><comment><USER63> Can someone describe their experience with using rails as a back-end JSON API for javascript apps (flux/react or with angular/ember)?

<comment><USER64> We've been happily doing Rails/Ember for about a year now. When we started Ember Data wasn't as stable or as customizable as it is now, so I don't have experience working with that.

In general, we've been happy with it. We ended up writing our own serializer system (similar to ActiveModel::Serializers) to provide legacy clients with the option to use XML without losing our minds. Rails has a lot of view-level niceties that we're not using under this scheme, but the rest of the framework is still very useful for this task.

</comment></comment><comment><USER65> My tool of choice today is Clojure, but I have to thank RoR for teaching me a lot of sensible conventions that I use in Clojure nowadays.

</comment><comment><USER66> I think I can boil down all the debates in the comments:

Some people prefer the Rails way of doing things. Others prefer something else. Nobody is wrong.

</comment><comment><USER27> > 7.Progress over stability

No real ecosystem can be built on rails since its apis keep on breaking.

That's why in my experience, most people give up on rails.

Stop breaking apis, introduce stability and maybe the framework will be successful again. People don't give up on rails because of ruby, or because it's bloated or slow, but because it became an unmaintainable, non upgradable mess as time passed.

<comment><USER67> Show me an integrated framework that is easier to upgrade than Rails.

</comment></comment><comment><USER68> one thing i hate about rails is writing the database migrations. (i thought: "why not just define what the schema should be, and let a diff-like tool figure out update statements?") so that's what i wrote:

[https://github.com/keredson/ruby-db-evolve](https://github.com/keredson/ruby- db-evolve)

been using it in production for ~1y now.

<comment><USER69> I may be wrong but it looks that you just misunderstood what migrations offer and their usage patterns. What if you have to remove one column and split its data into two new ones? I can provide dozens of similar examples from my production code. In short, migrations are not only about schema metadata.

It would make more sense if your gem would generate migrations from schema.rb changes.

Also, that rant at the end of README kinda shows that you're hating the tool you're trying to use. Why not use another? You are not tied to ActiveRecord.

I'm not trying to say that migrations are flawless as a tool. I've faced at least one major problem with them. But still.

<comment><USER68> True, this doesn't do data migrations, and we still write the occasional(1) data migration when needed. But those are no more difficult to write, and the much more common non-data migrations are an order of magnitude easier. So net win.

(1) If your data migrations are not "occasional" (and I mean very occasional) that's a sign you're doing a poor job at modeling your data. Splitting one column into two is almost always an example of someone really f-ing up the original schema.

Think of it this way: how do you switch branches? Do you look up the most recent ancestor, check it out, migrate down to it, then back up the new branch? It's so hard I don't know any rails devs who actually do it. But with a my tool it's a one-line command. PRs w/ schema changes actually get tested now, not just eyeballed.

Also, did you even read the "rant"? Do you seriously like the proposed version control tool modeled after rail's migrations? ;)

<comment><USER69> I was under impression that you suggest not to use migrations at all. That "hybrid" approach you just described seems to make sense :) Still not sure if I'm going to try it in production.

As of occasional (or not) data migrations, it depends on project and its history. If project is live, rapidly developed and has faced couple of pivots, migration history will reflect it.

<comment><USER68> Just to clarify, to me "data migration" is just a fancy name for a one-off script that you run during (or after) a deployment. We don't actually use the rails migration for it. (Mostly because it would overwrite our schema.rb IIRC.) But in general, yep.

<comment><USER69> So how do you manage these scripts? When deployment is multistaged and automated you won't just run them by hand. You need system that runs them automatically and exactly one time at each stage. I can't see why you have to create a system to manage these scripts if there is good enough built-in system for that purpose?

If automated deployment is not your case I strongly recommend it. Since I first time managed autodeploy to work properly I've never looked back. It is SO convenient.

I may be wrong again about your processes and configuration :)

<comment><USER68> we do auto-deploy, but they aren't required to be run during the deploy process, so we just run them sometime after the deploy. but honestly i can count on one hand the number of these we do a year - i haven't put much effort into streamlining the process. whereas schema changes are quite regular. just had one tonight in fact. output from the deploy log a few mins ago:

      Executing in 3...2...1...

      BEGIN TRANSACTION

      -- column changes for table products
      ALTER TABLE "products" ADD COLUMN "dont_email_on_purchase" boolean

      -- column changes for table searches
      ALTER TABLE "searches" ADD COLUMN "tag_only" boolean DEFAULT 'f'

      COMMIT

      --==[ COMPLETED ]==--

from the one line code change that triggered it:

      1  db/schema.rb
       @@ -543,6 +543,7 @@

          create_table "searches", :force => true do |t|
            t.text     "query"
       +    t.boolean  "tag_only",         :default => false
            t.datetime "searched_at"
            t.integer  "user_id"
            t.integer  "page_id"

(well, there were two commits obviously)

</comment></comment></comment></comment></comment></comment></comment><comment><USER70> whoa what the hell is ApplicationRecord?

<comment><USER71> The replacement for ActiveRecord::Base in Rails 5. All your models will inherit from ApplicationRecord. See [http://nithinbekal.com/posts/rails-5-features/](http://nithinbekal.com/posts/rails-5-features/)

</comment></comment><comment><USER72> s/so its only fitting/so it's only fitting/

</comment><comment><USER72> Push up a big tent? David Oscarmeyer Heineken is gross! :P

</comment><comment><USER73> The main problem with Rails is that other developers you work with have strong opinions about coding style, and they hammer you on code reviews if you don't code their way.

<comment><USER74> I'm not sure I agree that makes it a Rails problem, more of a developers who happen to use this tool problem.

<comment><USER73> It's partly a Rails problem because there's a ton of different ways to implement something, so people will always find reasons to disagree with what you did. And the Rails community seems particularly over-opinionated about these things. There's a lot of cargo cult thinking going on when your stuff gets code reviewed.

<comment><USER75> …which is not a Rails problem, but an inexperienced developer problem.

</comment></comment></comment></comment><comment><USER76> The worst thing about rails these days is ruby itself. If I'm going to use a non type-safe language, I may as well use the one that's on the client side as well (and has first class functions).

<comment><USER77> Ruby procs are first class.

<comment><USER78> very functional

</comment></comment></comment><comment><USER79> Everyone who has created their own open source framework which supports a multi-million-dollar business that now supports your hobby of driving million dollar race cars, please feel free to cast stones at what rails is and has become.

<comment><USER80> This is a terrible form of argument. Success does not mean you're correct. Many successful people and things deserve criticism. I don't think DHH or Rails is among them, but that isn't _because_ they're successful.

<comment><USER7> > Success does not mean you're correct.

Err, yes, it does. That's precisely what success means. If you are successful at something, that means you did something right. What that something is is certainly up for debate, but you can't ignore success as an argument.

<comment><USER81> Right; for example if you're a successful pharma CEO you might be able to afford the one and only copy of a Wu-Tang Clan album.

Unless you define "success" as "being rich", no, I'm sorry, it's not true. It's actually quite easy to become rich by being a complete scumbag with no consideration for other people.

<comment><USER80> I think a much better, more relatable, and currently very striking example of this fallacious "rich and famous people must know what they're talking about" line of reasoning is the current U.S. Republican presidential primary front- runner.</comment></comment></comment></comment></comment>


Ask HN: Where is the best place to find a co-founder? - <AUTHOR>

I'm currently working on a startup and would like to bring in a co-founder. The general consensus seems to be the following: first find someone and then work together on a pet project for some time to find out if the vibe is good.
The problem is that most people in my social circle aren't tech savvy, let alone entrepreneur minded. Of course I could cold message everyone on HN but that would take some time and annoy a bunch of people!
So, where can I find a hacker type co-founder on the web (due to my current location, attending meetups is not an option)? <comment><USER2> What happens if you frame the question thusly: "How do I foster relationships with people so I can trust them with my well being?"

Going on the internet to look for a start-up co-founder is putting the cart before the horse. Its backwards really. I know HN is a great place to connect with like-minded people and if a start-up has come out of this online-co- founder-dating model I'd love to hear about it.

Don't worry about obtaining what is considered "success" in some communities. Screw co-founders, funding, cool new web stacks, etc. If you're even relatively close to being able to handle these sorts of things, opportunities will come and you will recognize them.

Simply my $0.02. I hope your search goes well.

</comment><comment><USER3> Another 'co-founder wanted' post here a couple of days ago garnered 150 responses, you'd think that amongst the 149 that won't be 'the one' for that particular person there might be one that is right for you.

The posting that led to the 150 responses should be part of a textbook on how to approach potential co-founders, have a look at it here:

<http://news.ycombinator.com/item?id=1553095>

</comment><comment><USER4> Ideally they would be interested in whatever area your startup is in. You meet them while interacting in the community around that interest. If your startup is something that doesn't necessarily have a community around it(say bingo cards) then I would try to draw on a community, like HN, where people are more likely to be business minded.

</comment><comment><USER5> You can try places like HNHackers, techcofounder.com

Feel free to add me on IM too.</comment>


Post-Mortem of AWS Outage - <AUTHOR>

[Self-post because it's not easily linkable]
We would like to share some detail about the Amazon Elastic Compute Cloud (EC2) service event last night when power was lost to some EC2 instances and Amazon Elastic Block Store (EBS) volumes in a single Availability Zone in the US East Region.
At approximately 8:44PM PDT, there was a cable fault in the high voltage Utility power distribution system.  Two Utility substations that feed the impacted Availability Zone went offline, causing the entire Availability Zone to fail over to generator power. All EC2 instances and EBS volumes successfully transferred to back-up generator power.   At 8:53PM PDT, one of the generators overheated and powered off because of a defective cooling fan.  At this point, the EC2 instances and EBS volumes supported by this generator failed over to their secondary back-up power (which is provided by a completely separate power distribution circuit complete with additional generator capacity).  Unfortunately, one of the breakers on this particular back-up power distribution circuit was incorrectly configured to open at too low a power threshold and opened when the load transferred to this circuit.  After this circuit breaker opened at 8:57PM PDT, the affected instances and volumes were left without primary, back-up, or secondary back-up power.  Those customers with affected instances or volumes that were running in multi-Availability Zone configurations avoided meaningful disruption to their applications; however, those affected who were only running in this Availability Zone, had to wait until the power was restored to be fully functional.
The generator fan was fixed and the generator was restarted at 10:19PM PDT.  Once power was restored, affected instances and volumes began to recover, with the majority of instances recovering by 10:50PM PDT.  For EBS volumes (including boot volumes) that had inflight writes at the time of the power loss, those volumes had the potential to be in an inconsistent state.  Rather than return those volumes in a potentially inconsistent state, EBS brings them back online in an impaired state where all I/O on the volume is paused.  Customers can then verify the volume is consistent and resume using it.  By 1:05AM PDT, over 99% of affected volumes had been returned to customers with a state 'impaired' and paused I/O to the instance.
Separate from the impact to the instances and volumes, the EBS-related EC2 API calls were impaired from 8:57PM PDT until 10:40PM PDT.  Specifically, during this time period, mutable EBS calls (e.g. create, delete) were failing.  This also affected the ability for customers to launch new EBS-backed EC2 instances.  The EC2 and EBS APIs are implemented on multi-Availability Zone replicated datastores. The EBS datastore is used to store metadata for resources such as volumes and snapshots.  One of the primary EBS datastores lost power because of the event.  The datastore that lost power did not fail cleanly, leaving the system unable to flip the datastore to its replicas in another Availability Zone.  To protect against datastore corruption, the system automatically flipped to read-only mode until power was restored to the affected Availability Zone.  Once power was restored, we were able to get back into a consistent state and returned the datastore to read-write mode, which enabled the mutable EBS calls to succeed.  We will be implementing changes to our replication to ensure that our datastores are not able to get into the state that prevented rapid failover.
Utility power has since been restored and all instances and volumes are now running with full power redundancy.  We have also completed an audit of all our back-up power distribution circuits.  We found one additional breaker that needed corrective action.  We've now validated that all breakers worldwide are properly configured, and are incorporating these configuration checks into our regular testing and audit processes.
We sincerely apologize for the inconvenience to those who were impacted by the event. <comment><AUTHOR> What I found most remarkable was how in-depth their backup systems were and how many things had to go wrong for this to become an event.

This happened because they lost primary power AND had a generator fail AND had a distribution breaker fail. I wonder how often any two of those happen without us ever knowing about it...

<comment><USER2> The likelihood of these occurring in parallel is probably higher than you would expect. Backup systems are difficult to test fully since you can only do it via a full failover. Without running 100% of your systems via the backup distribution breaker, for example, you cannot verify that it can handle the load. You can only design for it. The full system was probably tested at initial install, but obviously more power was being consumed by live systems than by the original test. Entropy doesn't leave backup systems alone either, so over time they can fail even without use, and it is a surprise to everyone when the "working" backup systems fall over.

</comment></comment><comment><USER3> Wow! A proper outage post-mortem that isn't babbling on about control rods. I love it.

<comment><USER4> I don't get the reference -- what was the infamously control-rod-centric post- mortem?

<comment><USER5> That would be Heroku's response a couple weeks ago: <https://status.heroku.com/incidents/372>

</comment></comment></comment><comment><USER6> Well that's suck. Reading between the lines a little.

0) Wire faults happen, stuff breaks, that isn't fixable. No problem.

0.5) A cable fault that can take out your redundant pair of substations... means you do not have a redundant pair of substations. (sometimes you have to go to war with the army you have, not the army you'd want).

1) Faulty generator fan? a) Was this generator periodically run with a dummy load? { okay maybe a chicken fell in the fan or a weasel ate some control wires or something... }

2) The power circuits were never tested after a breaker got installed/reconfigured, and manual validation of configuration failed to find a discrepancy between plan and as build.

3) some back end parts of the EBS are probably A/B pairs and subject to split brain issues.

This is why you always need to test what you run, and run what you test...

Kudos for the write up. I see lots of electrician overtime in the near future.

</comment><comment><USER7> If you haven't learned your lessen yet then you deserve what you get. If you need 100% availability the only way you can get close is multiple servers, in multiple data centres, from multiple companies.

 __You cannot count on somebody else to make sure your web site is up. It's your job. __</comment>


Instagram is hiring extraordinary engineers and designers - <AUTHOR> We are currently hiring extraordinary engineers and designers who want to build and scale one of the fastest growing companies in the social web. We're in the business of building a new way for people to communicate and share their lives via media on the go. We're looking to grow our team into a world-class group of engineers that want to focus on big, meaningful technical challenges.
In a handful of months, Instagram has amassed well over 2.5 million users on the iPhone platform alone. As an Instagram Engineer, you have the unique opportunity to face many different kinds of challenges and touch many different kinds of technologies that allow the service to continue to grow at an increasing rate.
We're looking for people who want to face interesting infrastructure challenges. You should be constantly excited by questions like: How do you tackle increasingly vast amounts of data? You should get excited about exploring and implementing sharding and partitioning schemes. You should get a thrill out of processing gigabytes of data to inform product decisions. You should be able to design and implement systems that scale seamlessly with the vast numbers of users that decide to share their lives through images every day.
We also face product challenges like how to prioritize, design, and build a compelling product while maintaining simplicity and usability. Our product challenges span different platforms (mobile & web) and you should be comfortable moving between different parts of the system whether that be learning objective-c to contribute to our iPhone client, or writing solid JavaScript to make a web experience immersive and interactive.
Instagram is also an incredibly important part of everyone's life that works here. We pull many late nights and weekends, and you should be excited to jump in and make Instagram the primary focus of your life. We put in extra effort because we love Instagram and love to see it flourish and you should want to as well.
The bottom line is: we want smart, extremely motivated people who are willing and able to contribute quickly to all parts of Instagram, and who are excited by the challenges we face.
Here's a list of characteristics that we're looking for in an engineering candidate:
- A college degree in Computer Science or equivalent.
- A scrappy, entrepreneurial attitude that gets high-quality projects done quickly.
- Deep understanding, familiarity and skill with programming for the web.
- Experience in Objective-C and Python is a plus, but not required.
- Ability to touch many different parts of our system such as: deploying a new set of boxes on EC2, debugging network inefficiencies, implementing optimized graphics algorithms in C or OpenGL, writing optimized SQL queries, writing full python classes, or writing NodeJS applications. Point is: you should be able to pick up new things very quickly.
- A demonstrated history of intellectual and entrepreneurial exploration.
- Be able to write elegant, readable, and well-documented code.
We're a small team, and we're looking for people to make a big impact. This means you should want to take on lots of responsibility and be able to manage projects independently. You should be able to think critically about a problem, evaluate the solution set, and be able to pick the right course of development given the set of constraints. Of course we're looking for great engineering talent, but it's extremely important to us that everyone our team has a solid product design sense.
We truly believe in Instagram's potential to change the world for the better, and we're looking for a select group of individuals up for challenge to see that vision through.
Send your resume to firstname.lastname@example.com and let us know why you think you're a great fit. We're looking forward to hearing from you!
Instagram is in San Francisco <comment><USER2> It's off-topic, I know, and feel free to downvote me into oblivion both for being offtopic and getting meta in this post... but, I'd be remiss if I didn't mention:

<http://iwannaworkatinstagram.com/></comment>


Haskell Game Server – Part 1 - <AUTHOR> http://mojobojo.com/posts/2015-12-26-haskell-game-server-part-1.html <comment><USER2> I don't want to sound mean, I really appreciate the article, but the choice of colours (the blue background and the colour of links) is making it quite difficult to follow the post, for me at least.

Maybe you could take a look at some of the web palettes at [http://www.colourlovers.com/web/palettes](http://www.colourlovers.com/web/palettes) ?

Thanks for the nice blog post!

<comment><USER3> Got to agree, but, despite the (kinda horrible) colours, the article itself is great!

fyi: adding:

body { background-color: #FFFFFF; }

makes everything a lot better (I use style-bot extension to quickly fix things like this, just shared the styling: [http://stylebot.me/styles/12386](http://stylebot.me/styles/12386))

<comment><USER4> Or hit F12 to access the developer console and type:

      document.body.style.backgroundColor = "white";

<comment><USER5> Bookmarklets still have their place. Quickly tweaking page colors is one of them.

Here's a classic bookmarklet quick reference. (Though I have a few of my own; don't be afraid to modify to suit your taste/need.)

[https://www.squarefree.com/bookmarklets/](https://www.squarefree.com/bookmarklets/)

<comment><USER5> Downvoted... whatever. One click to obtain a readable page continues to serve me well.</comment></comment></comment></comment></comment>


Ask HN: How does a RDBMS developer migrate to noSQL ? - <AUTHOR>

I am used to seeing data in tables and their relationship via foreign keys. I would like to move on to noSQL (key-value) store. A challenge to me is how to stop thinking about foreign keys and tables and think everything in a single key-value store. Does anyone point to guide/links how to move away from RDBMS mindset to key-value store mindset. Real life examples of moving rdbms schemas to noSQL would be great. <comment><USER2> I dont understand the constant desire to replace the relational model. It works great to store most types of data in it, and its very flexible to do ad hoc reports if you have a good understanding of SQL.

I ❤ ORDER BY, GROUP BY, DISTINCT, SUM(), COUNT(1) etc _ducks_

</comment><comment><USER3> You may check this presentation from MIX10 "Using Storage in the Windows Azure Platform" <http://live.visitmix.com/MIX10/Sessions/EX11>

</comment><comment><USER4> You know that table where you just have an id and a blob or text field? Start with that.

</comment><comment><USER5> Why do you want to move to a KV store? Don't just move for the sake of it. If you have a real problem that requires a KV store then sure, but it sounds like you're just doing it cause everyone else is. Don't optimise for a problem you don't have (yet).</comment>


The New Gatekeepers: Private Firms as Public Enforcers - <AUTHOR> https://www.virginialawreview.org/volumes/content/new-gatekeepers-private-firms-public-enforcers <comment><USER3> Apart from the brief period from mid nineties until 2005 there were always gatekeepers who owned the presses and distribution chains. What changed?

<comment><USER4> This 50+ page document states many things, among which the claim "suddenly there are gatekeepers who own presses and distribution chains" is nowhere to be found.

<comment><USER5> Well the title explicitly says " _New_ Gatekeepers".

<comment><USER6> Which is not mutually exclusive with there having been Old Gatekeepers.

<comment><USER5> Strictly yes, but the title implies that something changed which is exactly what upthread commenter asked about.

<comment><USER7> Well, I would say - having grown up in the early days of the internet - <USER2> before the 'monopoly model' of internet companies, consumers simply didn't tolerate gatekeeping by private companies. It used to be easier to find the dissenting voices online than it is today, and keeping out minority opinions was seen as delivering an inferior product.

Essentially, big tech had been in a Moloch trap to the benefit of consumers, and now they've managed to co-ordinate their way out of it.

<comment><USER8> I see plenty of "dissenting voices" online, they're just not very worthwhile. I assume that a lot of what used to stand out as "correct" contrarianism has since become mainstream, or close enough.

<comment><USER9> Dissenting voices are only worthwhile if they agree with my worldview. My contrarian opinion is the correct one and has since won out.</comment></comment></comment></comment></comment></comment></comment></comment>


D4 Project – Open and collaborative network monitoring [pdf] - <AUTHOR> https://www.d4-project.org/assets/slides/20190522-IHAP-D4.pdf <comment><USER2> This looks awesome. Great to see a project like this in a space dominated by commercial offerings. I sincerely hope thus grows and thrives as it's desperately needed in this world of persistent attacks against our infrastructure.</comment>


Ask HN: I'm a bored front end developer. What should I learn next? - <AUTHOR> I've been doing web development for the past 4 years and I've had enough of pushing pixels around for clients. I have a degree in Physics and I'd like to do something more numerically demanding. There are a <i>ton</i> of amazing resources out there on things like Coursera, Udacity, iTunesU etc for teaching yourself new things, but that's my problem - I don't know how to narrow it down, and I don't want to waste time learning things that won't be worthwhile. Here are some of my initial thoughts: teach myself Machine Learning, Data Science, GIS, computational fluid dynamics. I have a good knowledge of Javascript, so I'm thinking it's possibly a good idea to learn another language like Python/C/R etc. Do any of you have any good suggestions that would lead to promising career paths? Thanks <comment><USER3> I have a path to avoid: embedded programming. Its low level c and being increasingly marginalized due to moores law. Its a field dominated by accidental complexity and wheel reinvention on its path to irrelevance.

<comment> Sean-Der I could see C replaced with something like Rust, but I don't see it disappearing just because hardware gets faster. Companies will just make devices smaller, and it makes sense to write things in C once if that means everyone gets a faster experience. However, I sure don't want to maintain all that code!

I am paid to work at a higher level (Go, PHP and JS) I take any opportunity to write a little C, in fact I would say that I romanticize the chance, the challenge is great.

Are you currently in the embedded field, is it your experience that it is getting phased out?

<comment><USER3> Yes, I am. I made the mistake of equivocating hard, complex == valuable. Classic engineering mistake. Higher level languages, in the end, will always be in more demand than lower level ones because those levels of abstraction allow for newer possibilities. New possibilities lead to new money lead to better career paths. There will always be a need to set up registers and clocks, but once that's done by 1 or 2 programmers, the real work begins. The intentions/vision of the application come into focus, and, in the end, reap the rewards. In short, embedded is an increasingly automated dead-end; the smart skill investment is moving up the stack.

<comment><USER4> > _embedded is an increasingly automated dead-end_

as someone who's new in the industry and interested in embedded, what do you mean exactly? who is automating it and making it a dead-end?

<comment><USER3> I mean that a lot of low-level setup for embedded is done by tools now; for instance, Freescale has a set of design tools that let you design peripheral drivers by picking options from a pull-down list rather than writing code directly. Embedded is bottom-of-the-stack coding that is very repetitive. By all means, if you are interested, study low level programming. It's good for any developer to know those things, but in terms of career growth its probably better to develop higher level programming skills to rest on. Buy a beaglebone board to hack embedded stuff but don't invest your core skills there.

</comment></comment></comment></comment></comment><comment><USER5> Learn C, and do something with machine learning. Once you master C everything else will seem easy. This will help you by mastering another language and give you something to focus on that should use some of the math skills you probably gained from your physics degree. The nice thing about learning C is you'll never have to wonder how the other languages work because most are implemented in C/C++.

</comment><comment><USER6> Don't know about career paths, but maybe you'd enjoy playing with [http://d3js.org/](http://d3js.org/) to visualize data in all sorts of interesting ways.

<comment><AUTHOR> Thanks for the suggestion, I did a bit of dabbling with D3 a while back. I wonder what doors it could open if one became an expert in it.

<comment><USER7> I talked with the guy who originally created nvd3 a little while back - <USER2> apparently makes quite a lot contracting due to his d3 expertise (no hard numbers unfortunately).

<comment><USER8> Do you know what kind of projects he works on, that use d3?

</comment></comment></comment></comment><comment><USER9> machine learning + go|java|scala</comment>


Show HN: Upload a photo of food and get calorie info in real time - <AUTHOR> http://www.foodsnap.mobi/

<comment><AUTHOR> As you can imagine, the problem of getting nutrition information from food is a really difficult problem, so we are breaking it into chunks.

For our first phase, we are using user input to provide a baseline of nutrition information. Some people don't want to use the existing apps which require you to select an item from an auto dropdown, then select the quantity.

For our second phase however, we are doing what you said. With the image and input data, we are training our artificial intelligence system to see if it can fix user entries, or at least provide a 'guess' of ingredients for the user.

Some interesting solutions we have seen from Harvard research papers is to get an image, then generate vector image shapes. With the image shapes, we can access portion size + the caption and fix that.

</comment><comment><USER2> At first I thought that there is some kind of "food recognition" going on but after watching the video I was a little bit disappointed... It seems to me that you are not doing anything interesting with the image... or are you using the image + input from the user to train some kind of artificial intelligence that can recognise food?</comment>


A Horrifying Example of Government Handouts and Perverse Incentives - <AUTHOR> https://danieljmitchell.wordpress.com/2017/07/05/a-horrifying-example-of-government-handouts-and-perverse-incentives/ <comment><USER2> Takeaway from this Libertarian website article is: Government handouts are bad because people in India (reportedly) feed granny to tigers in nature preserve and then move body to field just to claim compensation from government for tiger attack.</comment>


Network Outage in EU affecting AMS1 and AMS2 - <AUTHOR> http://www.digitaloceanstatus.com/ From Digital Ocean:
At this time we're experience a network outage in our AMS1 and AMS2 datacenters. With secondary impact affecting customers in Europe. As a result, you may experience latency, connectivity issues, or slow pings.
Preliminary investigation indicates that Telias Transatlantic cable are down. We are working to resolve the issue and apologize for any interruption this causes for you. Mon May 19 20:29:32 2014 <comment><USER2> A bit of tracerouting and some twitter searching[0] suggests that the issue likes with Telia.net. There are some unconfirmed suggestions that a cable was severed[1], which I'm not sure I believe yet but certainly any packet going via telia.net is having a bad time.

Edit: Even CloudFlare are reporting the cable cut[2] so... gosh.

[0] [https://twitter.com/search?q=telia&src=typd](https://twitter.com/search?q=telia&src=typd)

[1] [https://twitter.com/CurseNetworkSys/status/46849347754249420...](https://twitter.com/CurseNetworkSys/status/468493477542494208)

[2] [https://twitter.com/CloudFlare/status/468493714134822912](https://twitter.com/CloudFlare/status/468493714134822912)

</comment><comment><USER3> Related discussion:

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

From the UK everything seems to be working normal now, including access to my instance in AMS1.

</comment><comment><USER4> Akamai has a nice visualization map. Look at all that red in Europe.

[http://www.akamai.com/html/technology/dataviz1.html](http://www.akamai.com/html/technology/dataviz1.html)

</comment><comment><USER5> It looks like from our end that there was a large trans-atlantic issue which affected a lot of the connectivity between the US and EU and other providers were affected.

In our case we had to route around Telia which seemed to be the link that was having the most issues and we're getting more info from them to see what happened and when it will be safe to add them back into the mix.

Thanks, Moisey Cofounder DigitalOcean

</comment><comment><USER4> As a side effect, anybody else getting intermittent false alarms from Pingdom?

<comment><USER6> You're not the only one.

<comment><USER7> I had this issue on the new beeper system, I switched back to the old system and have had no issues since.

</comment></comment></comment><comment><USER8> In Germany we felt it for about 15mins, now the routing is adjusted and we are back to normal.

This is a nice reminder that the Internet was designed to resist to such disturbances.

</comment><comment><USER9> Transatlantic cable has been cut, lots of sites affected.

</comment><comment><USER10> It's not Digital Ocean's fault. It seems like CloudFlare, Twitter and Facebook's EU servers are down too..

<comment><USER11> I am in Europe, and I can reach Facebook's EU servers just all right :-).

</comment></comment><comment><USER12> At PagerDuty we saw our alerting volume double between 19:50 and 20:00 UTC (about 90 minutes ago).</comment>


Samsung Moves to Compel Apple to Reveal When It Learned Foreman Was "Untruthful" - <AUTHOR> http://www.groklaw.net/article.php?story=20121031200136965

<comment><AUTHOR> Disclosure: long-time Apple fanboi here.

But they are destroying the brand with their take-no-prisoners IP battle with Samsung.

From the posting:

 _I hate to watch it, and the paralegal side loves watching it at the same time, in that I've never seen anything quite like this, and it's professionally fascinating. But I wish Apple would see reason, and pull back on the extremism. I've always liked Apple, and I can't admire this, and it makes me sad to know that Apple's brand is being ruined. The US got drunk on the idea of IP maximalism, thinking it would solve some economic problems. They think that, though, because Hollywood told them so, and how does the world view Hollywood's IP legal work? If you want people to buy what you are selling, they have to like you enough to want to buy from you. And now it's Apple imitating Hollywood's extremism. Does it make you want to reward the company with your hard-earned money? Are their products as "cool" in your eyes, now that you are watching its legal behavior toward Samsung, a partner of Apple's? 26 devices Apple wants to block. 26. I mean. It's trying to put Samsung out of business in the US. For what? Rounded corners on a tablet? Are they listening to the wrong lawyers?_

Sad, and there will be blowback.</comment>


Ask HN: Are there any alive and active TELNET BBS systems? - <AUTHOR>

Are there any alive and active TELNET BBS systems that are still being used? <comment><USER2> PTT is still heavily used in Taiwan by university students. The numbers today might not be quite as high as the quote from Wikipedia below (due to the rise of Facebook), but the system is definitely still extremely active.

 _" PTT is arguably the largest BBS in the world with more than 1.5 million registered users. During peak hours, there are over 150,000 users online. It has over 20,000 boards with a multitude of topics, and more than 20000 articles and 500000 comments are posted every day."_

[http://en.wikipedia.org/wiki/PTT_Bulletin_Board_System](http://en.wikipedia.org/wiki/PTT_Bulletin_Board_System)

<comment><AUTHOR> Wow, thanks! And do you know about any english-languaged bbs?

</comment></comment><comment><USER3> Yes.

[http://www.google.com/q=telnet+bbs](http://www.google.com/q=telnet+bbs)

<comment><USER4> That link returns a 404.

</comment></comment><comment><USER5> There's at least about 20 Commodore 8-bit BBSs up currently, [http://cbbsoutpost.servebbs.com/](http://cbbsoutpost.servebbs.com/) and I'm sure more are out there as there have been recently developments in creating Hayes compatible internet devices.

</comment><comment><USER6> If ssh is fine (and I can't think why you'd want to use telnet over ssh), then try Monochrome (ssh email@example.com, though I haven't used it myself in years). (They might not even have switched off telnet access yet, you never know.)

</comment><comment><USER7> telnet matrixreturns.dyndns.org 6401

It's running on an Apple IIe, so only one user at a time. [http://www.youtube.com/watch?v=AfJtD5OeR_k](http://www.youtube.com/watch?v=AfJtD5OeR_k)

</comment><comment><USER8> Oh yeah. Even better, there are still active GOPHER servers out there. Fire up Links and try hitting gopher://gopherproject.org. You won't be disappointed...

</comment><comment><USER9> check it out [http://cloudwalk.io](http://cloudwalk.io)</comment>


Recent Events and Future Changes - <AUTHOR> https://blog.freenode.net/2016/02/recent-events-and-future-changes <comment><USER2> For those of us blissfully unaware of any drama, could someone fill us in? What was the "Dear GitHub"-style list of issues that they're talking about?

<comment><USER3> I wondered the same thing. I use freenode every day and wasn't aware of any drama at all.

</comment></comment><comment><USER4> I'm ex-staff (left long ago, still a chanop and regular user). Roughly, it seems like what happened was there was a disagreement over what freenode was supposed to be, a bunch of people resigned in frustration, there were a bunch of discussions, and everybody unresigned again on the principle that the future plans in the blog post were worth trying to bring about.

About the only reason it was worth mentioning the drama part in the blog post was that we'd been inundated with people asking about the resignations (since they were visible due to cloak changes), and now we're getting a fraction a many people asking about "what else aren't you telling us?", which is overall still a lot less annoying.

For anybody not directly involved in running the network, what'll be more interesting will be the changes made over time, which I'm not able to predict but am looking forward to watching.

</comment><comment><USER5> Freenode is the place I go to once googling has failed but before raising a question on stackoverflow.

Often you'll be able to speak directly to a dev or a knowledgeable user of an opensource project.

IRC/freenode - an important arrow in your problem solving quiver.

</comment><comment><USER6> Thanks for the vague announcement that you had some internal drama? Even as a user of freenode I have no idea what anything in this post is referring to. Maybe something happened that I might need to know about? Apparently there's going to be some sort of changes in the future, but to what?

</comment><comment><USER7> I'm not able to locate any information on the "rash of high-profile staff resignations." Is anyone able to fill in some context here?

</comment><comment><USER8> This is an example of an inside view "I see drama everywhere!" swamping an outside view "Freenode is up, ok."

One of the early lessons I needed to learn as a manager, is that my inside view is just one view. Getting the view of others is much more valuable.

</comment><comment><USER9> Editorial: there's a typo in the submission's title, an 'r' has been made into an 'e'. The name is of course Freenode, not Feeenode.

Makes it sound like it has something to do with [http://www.seeedstudio.com/depot/](http://www.seeedstudio.com/depot/). :)

</comment><comment><USER10> I worked with Rob Levin at Linuxcare. It's nice to see his creation continues. It has a lot of good open source comunities.

[https://en.wikipedia.org/wiki/Freenode#Rob_Levin](https://en.wikipedia.org/wiki/Freenode#Rob_Levin)

</comment><comment><USER11> Is it really that hard to run an IRC network?

(I say this with experience running infrastructure for an IRC network, albeit orders of magnitude smaller)</comment>