Interviews are Broken - <AUTHOR> http://erniemiller.org/2013/09/19/interviews-are-broken/ <comment><USER2> I've been in this game for a while now and the breakdown is pretty simple. If you are an employer, I implore you to trust me on these two simple points:

1\. Finding decent people that are both technically competent and a good culture fit is bloody tough and can take a lot longer than you'd ever expect.

2\. Interviewing/screening these people is simple. Don't make it more difficult than it needs to be.

You've done the hard part and you're confident the person/people you've found are worth at least a couple of hours of your time for an interview so why waste that time by applying a boilerplate interview process that every other company uses?

Give the candidate a realistic technical challenge to complete in a realistic timeframe, in an environment that will be indicative of the environment they would expect to work in should they succeed in getting the job.

If you're happy with the technical results, spend at least an hour with them having an actual conversation. Don't sit there throwing stock interview questions at them, don't try and nitpick on their CV. Just talk to them. Get a feel for their personality, the things that motivate them, the things that annoy them, the things that inspire them, etc.

<comment><USER3> I long for an interview like that. I first left the tech industry due to having to deal with HR and the hiring process.

I became a chef, where the interview could be moved to having them watch me make a dish or show knife skills. Then out of interest, I went through a biomedical engineering degree and am back into the tech field.

Still, due to my negative experiences with the filtering process, I have stayed in the realm of freelance and contracting. I would jump back into a tech job if interviews, like the above, were more common.

Thanks.

<comment><USER4> I've always thought the simple coding interview questions was like asking a chef to prepare a very simple meal; they should be able to do it without any problem. Though it's apparent that coders, like chefs, can choke on even these simple tasks. You only need to watch the "skills tests" on "Masterchef: The Professionals" to see a dozen professional cooks fail to fry schnitzel or fillet a fish. The same chefs go on the create some fantastic dishes in less stressful challenges.

<comment><USER5> One additional difference is that interview coding questions don't have a realistic working environment. Programmers utilize tools like search engines, IDEs and documentation, but these may be not available in a coding interview question, which might mandate a programmer to work on a whiteboard or using unfamiliar software.

</comment></comment></comment></comment><comment><USER6> Peroni writes in his top-level comment, "Give the candidate a realistic technical challenge to complete in a realistic timeframe, in an environment that will be indicative of the environment they would expect to work in should they succeed in getting the job." And of course that is saying "Give the candidate a work-sample test." That's a very well validated hiring procedure,[1] one that every company ought to use for essentially every job. In most parts of the world, you can add incremental validity to the hiring process by also testing the job candidate's general cognitive ability (a.k.a. IQ). In the United States, you have to take careful legal steps to be able to add a general cognitive ability test to your hiring process, but you would have to take the SAME legal steps to make a diploma or degree a requirement for hiring (a little known fact about the key Supreme Court case on the issue). Anything else you do in hiring has less impact on gaining successful workers than work-sample tests and general cognitive ability tests.

[1] [https://news.ycombinator.com/item?id=5227923](https://news.ycombinator.com/item?id=5227923) (this earlier Hacker News comment gives full references for the statements in this comment)

<comment><USER7> The challenge here, in my experience on both sides of this, is that a developer's deep domain knowledge of a large or large-ish app is essential to a 'work-sample' environment. And that's virtually impossible to duplicate even in the longest interview time frame.

Making decisions about managing technical debt, adding architecturally- significant changes, balancing good OOP with responsiveness, knowing the difference between future-proofing and conscientious coding -- all of those are both crucial (in many cases the most crucial) to day-to-day work, and also so highly context-specific that those decision-making traits are nearly impossible to identify during a technical exercise.

So for coding challenges, that leaves short-term tactical/analytic/algorithmic exercises, which in (anecdotally) 95% percent of cases cannot begin to approach a 'work-sample' environment. I've yet to encounter a technical challenge that would tell me much more about a candidate than basically how fluent they are with their tools, how well they know syntax and some general design principles, and what, for instance, their TDD (or lack of) workflow is like. Probably some insight into line-level analytic and algorithmic ability.

All of that is helpful, but -- Trust Me Here!! -- can also be very deceiving. The same coders that can knock those challenges out of the park can also be highly-proficient _Debt Machines_ , all the more destructive because of their special genius for cranking out architecturally suspect code at a breathtaking rate.

To get into a real 'work-context' flow of a large app requires weeks, sometimes months, and only _then_ can you get full perspective on how a given coder is going to contribute to your team on an ongoing basis. To get a feel for what that will look like in an interview, I've found I have to pretty much rely on the candidate's past projects, and informal conversations around larger architectural and OO principles.

<comment><USER6> I think your point is well made that what you can sample in a work-sample test is not the full set of long-term skills that benefit a for-profit company. That's why the predictive validity of work-sample tests is only about .50 across a wide range of industries. But the key point is that EVERY other hiring procedure, except for general cognitive ability tests, has lower validity, so a company is throwing away a lot of opportunity to hire good workers if it doesn't use a combination of work-sample testing and cognitive ability testing for all of its hiring. Your sound analysis can be turned around to using interviews as a hiring procedure--which is much more commonplace than using work-sample testing as a hiring procedure--to make the correct point that an applicant who looks good in an interview may not be a "team player" once hired. Any hiring procedure is a sample of applicant behavior, not fully representative of how the worker will behave on the job after being hired. But work-sample tests get much closer to what the worker will do on the job long-term than any other procedure besides general cognitive ability tests. Because work-sample tests and cognitive ability tests each have incremental validity when added to the other, it's best to use both in combination to get a hiring procedure with somewhat more than .50 validity in finding good workers.

</comment></comment></comment><comment><USER8> Yes. I have a new rule with recruiters. If you are trying to recruit me, make me an offer. Otherwise, go away. You called me, not the other way around. I'm not going to jump through a bunch of your hoops to prove to you for free that I can do what you already know that I can do just by looking at my resume, looking at some of my public projects, and asking me questions in an informal, short interview. And I'm certainly not going to do that knowing that, even after the end of an extremely long and taxing process, you can _still_ refuse to offer me a job.

What I've done should be proof enough. I don't want to jump through a bunch of arbitrary hoops so that I can get an incrementally higher paying job (maybe) and devote my life to working on someone else's vision. Gee, can I?

I already have a job, and it might be different if I didn't. But maybe not.

<comment><USER2> _What I 've done should be proof enough._

It really isn't. It may be indicative of your technical ability however your past experience doesn't give me any indication if you'd be a good culture fit.

<comment><USER9> Isn't "cultural fit" another way to hide sexism, racism, and prejudice in the hiring process? I've seen it happen and it's a very good excuse to give to HR.

Just like in social situations you can judge anyone pretty well in the first 5 minutes of a phone conversation, see if they will "click" with your team - hell you can almost do that just by looking at their open source (how they think/design). I don't need a high school coding exam and a 2 hour panel interview to see if someone is a "cultural fit".

<comment><USER10> > Isn't "cultural fit" another way to hide sexism, racism, and prejudice in > the hiring process?

While that may be, it doesn't mean cultural fit is only used in those cases.

There is a vast difference between someone who cares about doing their job well and someone who does their job. And 'cultural fit' will be used to describe that. Are you the type of person to put in your own time to advance your knowledge, or do you require the company to pay to keep you up to speed on the latest advances. I've seen both types of people.

And the former is more valuable than the latter. And the former generally won't want to work with the latter, either. Granted, the former will cost more than the latter, as he brings more value to the table.

You can argue the merits of 'cultural fit', but it's not just a word used to hide sexism, racism, and prejudice in the hiring process. And, personally, I think it's important because I want to enjoy the people I work with.

<comment><USER11> > There is a vast difference between someone who cares about doing their job > well and someone who does their job.

I like this as a definition of cultural fit. I have worked a place where I felt like the only guy who cared about his job, and it was suffocating, similarly, I have seen the one guy who is just doing his job in a team of those to love to do their job well, and he was like a ball and chain.

Perhaps we need to stop using "cultural fit", as a replacement for "professionalism". When I think about "cultural fit", I think, "what do I like, and does this person like it too?" When I ask myself and others, "is this person a professional", I think, "do they exhibit: passion, discipline, dedication, drive, and care in their work, skills, and interactions with everyone?" I would rather tell HR, "not as professional about his craft as we like to see", than a wishy-washy, "not a good cultural fit". The first sounds like we are professionals who treat ourselves, our craft, and others with respect, the second like a frat house blackballing a pledge because he doesn't like the same beer we all do.

<comment><USER12> This definition (caring about doing your job) is a bit annoying, because it means it's sort of impossible to work at any company that looks for this, while also trying to start your _own_ company. All my _passion_ is reserved for my start-up; you get my _professionalism_ , but nothing more. Why is that not enough? (This is assuming salary and no equity.)

<comment><USER11> In my opinion, someone who does their job well and professionally is just fine to work on side-projects. Ideally, your productivity and focus stays the same as they did before your side-project.

I truly do not think it makes sense to demand every person on a job is passionate about the job they are doing. There have been many times I have had to (even at a job I normally loved) do long, boring, and fruitless work. I did not do them out of my passion for the "Mission to Save the World of Enterprise Banking", but because I am a professional who does what needs to be done and who does it to the best of my abilities.

When I said passion before, I was trying to express two things.

First, I was intending to express the attitudes that cause someone to stay abreast of their field, keeps their own saws sharp, (and ideally helps teach/inspire others to do the same), comes in and works hard, and pushes themselves and those around them to be better. Perhaps the best word for that is just professionalism.

The second concept is that I would rather be around someone who, while acting like a consummate professional, also enjoys at least some part of it. I love the fact that software development has more than I could probably ever learn, and it is a worthy challenge to seek to master its different forms. I have worked with several professionals who really do enjoy parts of the craft that I only barely tolerate, and I enjoy that about them immensely. They open to me a new worlds of appreciation for the craft. Just recently, I had to work on a few hundred legacy bugs for a few weeks in a row. They were unexpected, not caused by me, and deeply tedious. Some took hours to locate the cause. One of my coworkers really came alive doing that. He just loved the hunt and chase, like a detective working out a mystery. While I was mentally moaning and groaning after week two, he was just getting started. We talked about it for a few minutes one day, and I decided to try and see things his way. While it didn't cause me to love bugs like a fine wine, I was able to bring my attitude around from a silent scream up to mildly interested. Maybe the best word for that is having a good attitude? Enjoys some parts more than others, and keeps quiet when they don't enjoy it? I am not sure, but that whole concept I find to be important. The person who reads books about development and enjoys reading them is going to bring a wonderful attitude to the team, and can motivate others to pursue their own interests.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I think there's a lot of general recognition that the interview process is suboptimal, but it'll probably be slow to change at larger companies mostly out of inertia. Part of the problem is that developers tend to do most of the interviewing/phone-screening, and a lot of us don't like it and/or aren't very good at it. Thus, it's unlikely that we'll be willing to put much thought into improving the process (note, I have _never_ had a performance goal related to interviewing). Usually, we just go with what we know, which is the standard white-boarding style interview.

That, and I wonder if there's a certain fraternity-like hazing element. One of our HR people recently brought up the possibility of removing one of our hiring steps (a take home programming assignment), and I found myself irrationally against the idea. I even joked that I wanted new candidates to suffer just like I did. On reflection, that might not have been a joke... Not particularly proud of it, but part of me resists changing the process because _I_ did really well at it.

</comment><comment><USER14> This person sounds completely insufferable. He basically is declaring himself too good for interviews (except for C-level execs, whom he apparently tolerates). Heaven forbid you don't just assume Ernie Miller is god's gift to your job position, because he is Ernie Miller and he is a special unique snowflake who is not to be insulted with petty questions pertaining to his ability to do the job.

Anyway, good luck with that.

<comment><AUTHOR> Did you actually read the article, or just the big, bold letters? The point wasn't that I am special. It's that each person is an individual, and a company that doesn't recognize that situations differ and make reasonable accommodations is unlikely to be a company at which I (or many like me, if the comments are any indicator) would enjoy working.

<comment><USER15> Because nothing makes a hiring process more fair and accurate than changing the rules for each candidate.

<comment><USER16> I'm not sure that same == fair.

If a worker is going to work remotely, is it a better evaluation of her skill to have her do her coding test remotely or have her do it in the office? Likewise, is it fair to ask a potential remote worker to take on an endeavor that's much more cumbersome than it would be for an in-office worker.

The other part of the argument is that the hiring company may be affecting its ability to evaluate a candidate by subjecting him to a situation that's pretty different from the job's reality. Ostensibly, the point of having someone work out of the office is to see how well he'll do if he gets the job, but in the case of a remote worker, this may not be a good indicator.

I think all of this is highly debatable, and there's probably no right answer, but there is lots of food for thought!

</comment></comment></comment></comment><comment><USER17> It's interesting to note how many people that actually work at a place had to jump through all of the pre job offer hoops. I think you'll usually find a lot of people who were able to avoid much of that stuff because:

1) they were hired before the company started doing it

2) they new someone going in so they got hired without as much rigmarole.

3) they started as a contractor/freelancer and were converted to employee without interviewing

4) they came to the company through an acquisition

It seems like if you're not good at these annoying pre-offer activities that you're better off taking one of the above routes into a new job rather than trying to play these games.

[edit formatting]

<comment><USER18> This is a good point, and sort of supports the Author's thesis. Perhaps better than the submitted Article. The way to test if interviews are 'fit for purpose' is to see how effective they are in real use. If everybody is going around the formal process, by hiring friends/previous project-teamates/warm- referrals only...then that is pretty important observational data.

</comment></comment><comment><USER19> I think that we can simply say "no one has been fired for traditional interview". Yes, it is broken, ineffective, interviewees mostly hate it, some egos get hurt while solving fizzbuzz on the whiteboard, etc. But for an interviewer, it's a safe choice. It's something he has done hundreds of times, something the interviewee expects. He might miss some really good potential employees but at the end of the day, everyone will be ok. Trying something totally new requires some courage and stepping out of comfort zone, probably a lot, and that explains it.

And if we are talking about major corps, it would require lots of investment in terms of internal training, would take a while, in other words - it's expensive. And they still get a lot of top quality candidates, so why bother?

<comment><USER11> >Trying something totally new requires some courage and stepping out of comfort zone, probably a lot, and that explains it

I think you are on to something here. People want to do the safe, easy, and known thing. I cannot imagine most people, when finding out a poor employee was hired would blame the interviewer or the interview system. They assume that those are fine, because "Joel, Yegge, Google... everybody does them" and so they become a mental blind spot. The focus falls on the bad employee, "wow, he seemed so good, he must be a con artist or something".

>And they still get a lot of top quality candidates, so why bother?

This, I do not believe. By definition, most developers are not "top quality", rather just fit in just well enough to stay out of the "fire zone". From what I have seen, unless by "top quality" you mean "best development value for your buck", most developers at most shops are far below "top quality". Most are either overly conservative or overly aggressive, and have skills just barely good enough to do their job, which is good, because if they were truly the "top quality" they would tire quickly of your work and leave. The only way someone gets to be even close to "top quality" is by constantly doing new things, constantly pushing themselves, constantly getting better. Those traits _sound_ good till you consider what then will happen when they master the job you want them to do and get bored. That is what I mean by "best development value for your buck". Chances are, most development shops want most developers to be just barely good enough to get the work done in an arbitrary time with an arbitrary level of quality. Like the old joke goes, anyone coding slower/poorer/less than me is "a lazy idiot!", and anyone coding faster/better than me is "an architecture astronaut stuck up jerk!". Hiring becomes, "are you within an acceptably narrow band of skill that will all share?"

So, companies get what they hire for. Chances are, they get mediocre programmers, because that is what they actually _need_. They don't need language-writing, development world colossi striding about their office, designing new paradigms for their slightly altered CRUD app. Most companies wouldn't know what to do with such developers if they had them. Heck, even Google apparently didn't know what to do with Guido. Instead most companies need someone happy sitting down to add a new field to this page, or make this checkbox work on this popup, or fix this bug that only shows up in IE7. Someone for whom that is just challenging enough to be interesting, but not impossible. Apparently, programmer quizzo is the cheapest/safest way to ascertain that.

</comment></comment><comment><USER20> "If a company isn't making efforts to recognize you as an individual during the interview process, an accepted offer letter isn't going to promote you to personhood."

This is a great point. I've noticed that culture tends to be pervasive. The good experiences I've had with companies started from first contact. So have the bad experiences.

<comment><USER21> Also applies as a consultant. Bad clients have noticeable red flags right from the start.

</comment></comment><comment><USER22> I'd say asking a candidate to implement levenshtein distance in an interview (probably not the best question to ask I'd say) is more about creating a level playing field for candidates who might not have "attended and spoken at relevant conferences" or have "a bunch of apps doing mission-critical work in production", but might be thoroughly productive and successful at XCorp nonetheless.

In fact, a candidate might have experience in something completely different but maybe just as impressive - publishing a paper on an optimization for an algorithm, creating a programming language, submitting Linux kernel patches, etc. How would one differentiate a candidate like that with someone with "a list of public repositories on GitHub as long as your arm"?

<comment><AUTHOR> I wouldn't differentiate them.

In fact, that's kinda the point. Each candidate should be evaluated on the unique experience they bring to the table. Trying to create the illusion of a level playing field by standardizing on generic code challenges in interview exercises is just that, an illusion.

</comment></comment><comment><USER23> I have a simple rule of thumb when interviewing other people... I don't care so much what you know how to do, as much as I care how you handle what you _don 't_ know how to do. Technical skill can be discovered quickly enough in the interview process. Ways of thinking, that takes work.

As for the original article... if a company puts you through a long interview process, you should take advantage of it to learn about them as well, and see if it's where you want to work. Don't just be a replaceable part.

</comment><comment><USER24> My personal opinion. If you are hiring for a fulltime role where you hope to have that person on the team for a long time , then it is a heck of a lot more than just technical ability that matters. I learned this from an ex-boss who taught me the value of skills that matter in the long run. Hint: technical skill is just one aspect and not enough. It matters what the attitude is, what encourages/discourages them etc. Why do these matter ? Because we are humans and we use our experiences/emotions/values in practice a lot more than just technical skills.

The game changes however if you need an expert consultant/contractor/freelancer who can solve a _very specific_ problem with a _very short_ period of time. For those, go hard on the _specific_ tech. questions.

</comment><comment><USER25> You know, there's a lot of these interview articles. Where whiteboarding doesn't work. Or whiteboarding works but filters out a vast majority of applicants. Give homework problems instead. No, applicants can easily cheat or resort to copy pasting code when given time away from the interviewer. The future is GitHub repos to see candidates' prior work. No, open-source code is not verifiable and easily falsifiable. What about determining if an applicant has solid fundamentals, not overthinking it, and having him or her learn on the job? Whatever happened to providing training? Is there really no room for apprentices or novices in modern tech companies?

<comment><USER11> Plenty of places do this, I have run training programs and helped with co-op training for new developers now in three different companies, and I can say, yes, there is room.

And, yet, our demand for developers with experience surpassing the average co- op or college grad doesn't change. It can be hard to make much progress with a team of mostly younger developers when every technical discussion someone is asking, "what is FTP", or "I read that GET is the only safe way to pass values", etc. Sometimes, it _really_ pays off to just hire someone who has already figured out a certain level of the fundamentals and can hit the ground running into more advanced walls like lack of business domain knowledge.

</comment></comment><comment><USER26> I've done very few interviews (on either side of the table) but I wish I would come across one that had two main questions in the technical interview:

1\. Write some piece of code that you think is cool. It doesn't have to originally be yours, and if it would take too long to recreate exactly, write it out in pseudo code and explain how it works and why you chose it.

2\. (Slightly more common, and I've asked this before) We are having Problem A, and it would be within the scope of your responsibilities. How would you approach it?

the interviewer asks follow up questions to both and hopefully learns something in the process.

<comment><USER27> Ugh, coming up with something "cool" under time constraints, while someone is sitting there and watching my every move, is not exactly a realistic gauge of anything. One of the reasons the hiring process is so broken for so many is that they fail to take in to account the nervousness and pressure the candidate will invariably be feeling. Speaking as someone who has done _many_ interviews, questions like this always make me cringe. Sitting there in a suit, sweating and angling for a job, isn't really the best time for me to come up with something "cool."

<comment><USER26> i meant this more in the sense of "what's a piece of code you've seen(or written) that made you excited and made you think 'wow that's really clever!'" It shouldn't necessarily be something earth shattering, could be very simple, just something you genuinely liked. I personally believe enthusiasm (including intellectual curiosity) is the most important quality somebody can have in the workplace.

If your problem with the question is trying to think of a response that the interviewer would want to hear, then you aren't approaching the question correctly and/or neither is the interviewer.

</comment></comment></comment><comment><USER28> I am attending interviews these days and can echo a lot of what I read. Sometimes the interviewers just keep forcing you to the answers they have or they ask the same question to everyone - it's new to the first one but anyone coming in later already has the perfect answer. Your past doesn't matter - only the 30 min demo of you will sell. Only if in real world products got sold by their demo and not final functionality.

</comment><comment><USER29> I never got to interview for a startup. Is it common to have a 1:n interview? At every single big company I've interviewed with, interviews were always 1:1.

He threw out 1:n interviews being bad as if it were the norm.

I also have no idea what he meant by this:

"All of this for a position that will involve working remotely (you are working remotely, aren't you?)."

Stopped reading after that because it didn't sound like he and I were in the same industry at all.

</comment><comment><USER30> I recently failed a tech interview. I was asked to pair program on a calculator.

Something so simple became more difficult under the pressure of someone watching you the entire time.

It's also nothing I've ever even thought of building nor something I would ever be asked to build in a real work environment.

I have stellar reviews from my former employers. I know I don't suck, but hell if that didn't shake me to the core.

Maybe I'm just venting.

<comment><USER31> Similar experience recently, writing some trivial awk while being watched, on a keyboard with an unfamiliar mapping too. Probably took me 5x as long as normal, which was unfortunate as this was a timed test!

</comment></comment><comment><USER32> > Once I started to apply this simple filter to the incoming opportunities, > things got much easier

What filter? I didn't see him mention the filter he's using. Maybe he means he rejects a company unless it has an adaptive interview. But, how can you do that unless you take the interview?

</comment><comment><USER33> Ive been doing interviews for a few months now, and I try to make it as casual as possible. Why? Because I don't want to ask the candidate about who they think they are, I want to know who they _actually_ are.

</comment><comment><USER34> __________ is broken.

</comment><comment><USER35> Hired.com can help this guy.</comment>


Rails is 100% magic with 0% design  - <AUTHOR> http://groups.google.com/group/comp.lang.lisp/msg/f2c33661b80ba302

<comment><USER2> This is mostly bullshit. The guy is trying to do things in Rails the _wrong way_ and complaining about it failing. He does have a few legitimate points, but I guess I'll go at it point by point, because it is fucking long:

-AR find works fine for me, in most cases, in those cases you can always fall back directly to SQL (has happened a total of two times for me). The guy very incorrectly states that the :group stuff will choke in Postgres. It does not. There is a separate driver for each database that will make the queries compliant with the specific DB.

-When using joins, you're supposed to use :include, or has_and_belongs_to_many. These are NOT read only, and work very very well. He's complaining that something he is doing the wrong way does not work. That is because he is doing it wrong, and it isn't SUPPOSED to work.

-I agree with his point about understanding Rails and the options hashes. At this point, I really wish that Ruby had named arguments, as the options workaround gets really annoying.

-I don't understand what he means by quality assurance. Rails has an incredibly large automated testing suite. I've been using Rails for two years and I've found _one_ bug. I really just have no idea what he's trying to get at.

-On the last point, about the "big-picture", he is provably false. If you've written a Rails app and there is even ONE XSS injection opportunity, you've done it wrong. Spend two seconds in the API docs and you will find this function called "sanitize":: [http://api.rubyonrails.org/classes/ActionView/Helpers/Saniti...](http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#M000936)

It helps if you read the fucking documentation before you criticize something.

<comment><USER3> the parent post is dead on. the guy who wrote the article does not know rails well enough to find accurate criticisms.

the complaint he makes about the options hashes would be solved if someone took the time to document all of the private methods, etc. I like a mix of code + documentations to figure out how something works. Most of the rails contributers prefer to just read the code, which is why no docs exist.

<comment><USER4> I'll throw my 2pesos in as well and concur here. Though I do feel the pain of traversing down the call stack to dig up where the magic is. Ruby for Rails has a great chapter on digging into Rails core code which helped me a lot.

</comment></comment></comment><comment><USER5> A lot of this is really a rant, but I do agree with some of it:

"- Reading and, in general, understanding Rails is horribly difficult, since it's no design and layers upon layers of magic. Very often you will find 5-7 layers of functions delegating the work deeper and deeper in, until you arrive to a completely undocumented internal function that in turn splits the work to three other, unrelated internal functions. Given that each of those 10 functions takes a hash called "options", each layer altering it subtly, but none having the complete picture, and that 9 times out of 10 that hash is not documented on any level, figuring out what your choices are is pure hell. It's made even more fun by the fact that different parts of Rails are accessible at various points of handling the request, and you can't just jump in and poke things from the console, since it won't have 99% of the things that only magically spring to life once a request is live. "

Methods do really nest pretty deeply sometimes. And since all of ruby's classes are open, people just add stuff by hacking things together. It's pretty much impossible sometimes knowing where a particular method is in the codebase.

<comment><USER6> amen, if you are coming at it with no other coding experience then I would think its a breaze. my main problem is when you start to dig you feel like alice in wonderland going down the rabit hole.

</comment></comment><comment><USER7> It's easy to piss on things after the fact. It is pretty common behavior in our field to try and make yourself look good by criticizing others' work. It's usually pretty easy to find things to pick on with the benefit of hindsight, but much harder to create something new.

<comment><USER8> Well, imagine this rant where "RoR" would be replaced by "java", wouldn't you imagine being the author of the pamphlet ?

I'm frightened by such an uniform behavior in the YC community. By dismissing any dissenting point of view you kill diversity. I remind you that the next fad you (and I) will be trying to catch will be created by a guy bothered by the current state of things. Bothered enough to act (and reunite the "Tipping point" conditions).

This guy attack RoR, he's attacked personally as trying to sound smart. Have you ever criticized anything ?

(my karma will follow the Dow Jones today I think ....)

<comment><USER7> Uhm... I actually wrote my programming language, Hecl, in Java. While there is a lot I don't like about Java, I still don't like the tone of these kinds of articles. I think after a while you can sniff them out - when they're really trying to point out some deficiencies, and when they're just going for a boost by putting stuff down.

At least that's my take on it. Slinging numbers like 100 and 0 is generally a sign of hyperbole.

<comment><USER9> I agree instead of bitching about Rails, the guy should be writing about why Weblocks is so great - with more detail than: "because they actually stopped and thought about the whole thing for a moment, and try things that will address the problem as a whole"

</comment></comment></comment></comment><comment><USER10> This guy is trying to apply rails as a solution to the wrong problem space. No wonder he finds it wanting. Typical.

Rails is not a solution for: "create the most well engineered product possible."

Rails is a solution for: "solve this business problem with these limited resourced in this limited time frame as inexpensively as possible. Oh and we're not sure exactly what the business problem is, we'll need to see a few prototypes before we are able to figure it out."

The amazing thing about rails is not how good it is. The amazing thing is how much better it is than most solutions in spite of how bad it is.

Rails is a success because it was created by someone who has a real understanding of economics, business value, and resource limitations. Not because it's a brilliant piece of engineering.

</comment><comment><USER11> _"There's no overarching design or scheme of things, it's just a bucket of tools with some glue poured in."_

This premise is wrong, so I almost TLDR'd the post immediately. I decided to skim further, though:

 _"And to stress the first point again, Rails never concerns itself with the big-picture problem of 'writing webapps.' It only thinks as big as 'outputting HTML strings' and 'querying the DB for a list of things.'"_

This is provably false. The average reader of the intro chapter of most Rails books could tell you that, for example, Rails enforces high-level application design patterns like Model-View-Controller, thus exposing his statement as factually untrue. The guy seems to have _languages_ like PHP (or, charitably, Ruby) confused with the Rails _framework_. Nice try by the OP, but ultimately an unconvincing troll.

<comment><USER12> MVC, while a valuable application design principle, is not really tied to 'writing webapps.' The article mentions things like the stateless nature of HTTP requests, which are very much bound up in the idea of writing software accessible over the web. Something like Seaside (a Smalltalk framework for developing web apps) is much more aligned with the request-response cycle that is the web. It uses the continuations feature of Smalltalk to map that cycle into a natural language idiom. Neat.

Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way.

Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside.

Until then, go forth and write great software!

<comment><USER13> The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architecture described in O'Reilly "RESTful Web Services" book). Seaside (and Weblocks) seem to focus on continuations, but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients.

Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.

<comment><USER12> Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy.

One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP.

Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end.

Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back.

Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.

<comment><USER14> Lua has been on my "todo" list for a while. Looks like there's already a framework out there:

<http://www.keplerproject.org>

</comment></comment></comment></comment></comment><comment><USER15> Even if every point the author makes is true - there are still plenty of reasons why you _should_ use rails in many cases. The first of which I'd argue is you can get shit done fast! For startup founders, this is essential. Make something. Put it in front of users as fast as possible. See what they like and dislike. Fix it. Repeat. Rails makes this super fast and easy. Once you get to the point where you really care about any of the things this guy mentions, hire a team to rewrite it. You'll need to at some point anyway...

</comment><comment><USER16> Huh... that's harsh, and is coming from more knowledgeable Rails hacker than I am, I wasn't aware of this mess with :union and :group in AR, while I don't mind Rails' habit of passing around hashes of options.

The point I agree with him the most is that "different parts of Rails are accessible at different stages of processing the request". This one annoyed the hell out of me, it took me forever to solve the problem of adding your own custom configuration options and accessing them from anywhere in the app.

<comment><USER17> Have you tried some of the other ruby frameworks, like merb? Merb is not that different from rails, but seems to perform better and can be used with other ORM's than ActiveRecord as well.

<comment><USER16> When we started nearly two years ago, we had to quickly drop Windows and simultaneously learn Linux/bash, vim, Ruby, Rails, Apache, SVN plus million other things in a hostile and unknown land of old :-))) No, I have not heard of Merb back then, we compared RoR against PHP and went with Rails and so far it wasn't a bad ride. The key to NOT be disappointed is to do everything "Rails-way", i.e. treat DB as a dumb swamp where you keep your models. So far so good.

<comment><USER18> I'm pretty sure Merb didn't exist two years ago, so I wouldn't be too ashamed that you didn't hear of it back then. :)

</comment></comment></comment></comment><comment><USER19> He is right in most of his critics.But, worse is better.

We computer science guys, and especially those with background in maths, always want to have frameworks reduced to orthogonal concepts that recombine in all possible ways to create very diverse outcome. This leads to algebraic- type formal systems that are very beautiful and powerful in their domains.

You can rarely model a real-world domain in such a minimalistic and mathematical way. Think about it: if it was easy and useful, the natural languages we used would benefit a lot from being unambiguous, minimalistic and mathematical. We have neither evolved to use such languages nor successfully created ones outside narrow artificial domains This, I think, is an important lesson for computer science.

Recently we have seen the rise of Perl, and later RoR. Why are they successful, despite having fuzzy concepts and leaking abstractions? I think this is because they try to mimic natural languages, and put the mathematical clarity aside.

Perl's author is a linguist and had consciously borrowed natural language characteristics: <http://www.wall.org/~larry/natural.html> DHH has emphasized a lot that he wants his DSLs to look like natural languages (don't have a reference right now). Perhaps this means something.

</comment><comment><USER20> Come on, it has a pretty obvious design. So obvious in fact that Microsoft is copying it for "asp.net" v-next. There is a lot of magic to rails, but let's call it "configurable magic" since __it seems__ most of the magic can be overridden (i'm not a pro). But to say it doesn't have a design? Come on...

<http://www.asp.net/downloads/3.5-extensions/>

<comment><USER6> I am looking forward to the next release, this one ain't great. MS MVC should go further than rails and will no doubt scale without much hassle. I wish they would just do a standard release of ruby.net in visual studio. yeah there is Ironruby but not the same as a fully supported release like C sharp, vb.net and J sharp.</comment></comment>


Understanding Understanding: Essays on Cybernetics and Cognition [pdf] - <AUTHOR> http://www.alice.id.tue.nl/references/foerster-2003.pdf <comment><AUTHOR> This is a full book. I expect discussion to be limited.

Very interesting topic (cybernetics) and concepts. Author is Heinz von Foerster, mentioned in my earlier Ted Nelson submission.</comment>


Online startup weekends. Attend from anywhere, every week - <AUTHOR> https://www.foundler.com <comment><USER2> Welcome to HN. Don't bother with the sockpuppet accounts next time. This sort of thing is quite likely to get upvoted organically; there's no need to cheat.

<comment><USER3> I could understand (but in no way respect) their decision for doing that if they had a decent product or good idea.

This looks like someone is having a punt on an idea after spending 30 minutes hacking together a website. I can't understand the idea though - we pay them for us to do work? I couldn't see any mention of what actually happens to the 'startup' or IP afterwards.

</comment></comment><comment><AUTHOR> Hope you all like this idea! Get tickets for our first discounted weekend at www.foundler.com/welcome

<comment><USER4> Ok, so this is not a hackathon. There are no prizes. We pay you to work on an idea, and then after the weekend that is it?

<comment><USER5> Was wondering the same thing? If he's not willing to offer a prize, I'm willing to post one with $50k prize with the assumption that 1000 signups of $100 per person.

Also, really needs to be coaching during the weekend.</comment></comment></comment>


Several types of types in programming languages - <AUTHOR> http://arxiv.org/abs/1510.03726 <comment><USER2> Over many years of reading various essays on " _types_ ", this is the list of synonyms I've accumulated:

 _= "constraints"

="rules"

="policies"

="contracts"

="semantics" (separate concept of MEANING from underlying DATA BIT representations)

="compatible semantics"

="capabilities"

="propositions" (and functions can be "theorem proofs")

="facts" about code that compiler attempts to "prove"

="tags" or "metatags" for compiler checking

="documentation" that's enforced by compiler specify what is NOT ALLOWED e.g. "you can't do that"

="substitution", "compatibility"

="A set of rules for how to semantically treat a region of memory."_

Because the list is synonyms, many concepts overlap. In my mind, the highest level of unification about "types" is the concept of " _constraints_ ". Related topics such as polymorphism is a practical syntax pattern that arises from data types' constraints.

Personal anecdote: I initially learned an _incomplete and misleading_ idea about "types" from K&R's "The C Programming Language". From that book, I thought of "types" as different data widths (or magnitudes). An "int" held 16bits and a "long" held 32 bits, etc.

It was later exposure to more sophisticated programming languages that a much richer expressiveness of "types" is possible that the C Language "typedef" cannot accomplish. For instance, if want a "type" called "month", I could encode a "rule" or "constraint" that valid values are 0 through 11 (or 1 to 12). A plain "int" is -32768..+32767 and having " _typedef int month;_ " provides a _synonym_ but not a new _policy_ enforceable by the compiler.

<comment><USER3> Urbit actually wound up with three different concepts which all want the word "type," and can't all have it. Worse, none of these quite matches the PL- theory meaning. So none of them wound up with the word.

One easy way to state a type is to state it as the range of a function. The function accepts all values, and produces some subset of all values; ideally, all values in its range are fixpoints, f(x) == f(f(x)). This is kind of nice because you've defined both a constraint and a validation function. We often want to validate untyped data and make it typed.

On the other hand, this range (Urbit's "span") is not the same concept as the function itself (Urbit's "mold"). Moreover, when you send data over the network, you don't want to send the range or even the function; you want to send the _name_ of the function, which hopefully is bound to something compatible on the other side.

This namespace becomes a third level of type (Urbit's "mark"): like a MIME type, if a MIME type was an executable specification. One of the problems with most PL type systems is that they predate ubiquitous networking; so they're not designed to address the problem of describing external data, eg with MIME types, XML DTDs, protobuf schemas or whatever.

<comment><USER4> No offense, but this is exactly the sort of nonsense I associate with urbit.

>ideally, all values in its range are fixpoints, f(x) == f(f(x)).

This doesn't make any sense whatsoever. The _only_ function for which this is true is identity, and I assure you it takes more than just the identity function to make a useful program. This isn't even possible unless the function has the type "a -> a".

The only other thing I can see you trying to express here is some butchery of set notation, where by f(x) you actually mean {f(x) | forall x of the correct type}. Even then, what you're saying is still completely nonsensical.

I honestly cannot tell if urbit is some sort of coordinated trolling effort.

<comment><USER5> Identity is not the only function for which that holds. As an immediate example, constant functions have this property as well. More interesting examples exist as well.

Also what was stated was not an equation for any old fixed point but instead idempotence—a specific kind of fixed point. In particular, this describes precisely the shape of a "validation" function so long as it either succeeds on all inputs or has a notion of failure in either its computational context or it's range ("span" I guess).

<comment><USER6> _' a "validation" function'_

Or "normalization"

<comment><USER3> Yeah, that's exactly right. I usually say "normalization."

</comment></comment></comment></comment></comment></comment><comment><USER7> I have realized for quite some time now that there are at least three different uses of types in programming languages (with different goals), namely:

1\. Specification of constraints on data - the function arguments and return values. This corresponds to usage of types in logic. The goal here is the correctness of the program (and ease of reasoning about it).

2\. A way to define polymorphic functions, i.e. functions that do the same or similar operations with different kinds of data. Here we classify data as of some type so that we can define two functions with the same name, but different types, where the correct one is selected either during compilation or run time based on the parameter type. The goal is conciseness, to avoid explicit conditional statements everywhere or other ways of code duplication.

3\. Finally, to specify way how the computer is to store data, or generally how to model abstract concepts (such as integers) within the computer. This becomes less relevant with time (as languages increase in abstraction), but is important use historically. For example, integers that can be modeled with many different types in C. The goal here is to have type as a reference to concrete and efficient representation of the abstract concept.

I think this is pretty much what the paper is suggesting, although IMHO not so clearly.

<comment><USER8> I would split use #3 into two parts: 3a) disambiguation for builtin operators - e.g. a float local needs to go in a float register, adding 16-bit integers uses 16-bit addition, a struct local needs to go in an appropriately-sized memory location. This is basically the same as #2. 3b) schema-ed data storage. This allows laying out structured data in a compact way in memory (e.g. `struct x { int a; int b; }` consists of 2 integers one after the other). This functionality is useful even in unityped code.

<comment><USER7> While you are right that standard arithmetic operators are typically polymorphic, but that doesn't mean there is another use case. Another example I had in my head was little and big endian integers, or binary and decimal integers. A language where arithmetic operators are not polymorphic is for example assembler.

What I would say perhaps is that #2 and #3 are in a way complementary. In 2, we describe a common operation with a more abstract type, while in 3, we describe the specific representation with a more concrete type. So both #2 and #3 address issues of naming things on different levels of abstraction, which aren't directly related to the program specification or its correctness (use #1).

<comment><USER8> The arithmetic operators in x86/x86-64 are certainly polymorphic (over word- length, plus integer vs. x87 vs. SSE).

I think the distinction is that #3b-types, which denote the "encoding" of a value, mapping it to its meaning, are often used as a basis for a #2-types system (to parametrize operations).

<comment><USER7> > The arithmetic operators in x86/x86-64 are certainly polymorphic

I disagree - at least in machine code, the instruction code determines the type of the operands. If they were to be polymorphic, the type of operands would determine the specific instructions that are to be used (and so you could for example reuse the same code for different word lengths). Maybe modern assemblers can do that (and have a generic instruction name for addition, for example), it's been 20 years since I programmed in x86, I only recently used mainframe assembler where it is as I describe.

Polymorphism is all about names. You want the same name (and by extension, the same code) to refer to potentially different operations on data.

> I think the distinction is that #3b-types

I am still not sure how it is different from #3a in your definition. When I say 16-bit signed integer, I can also mean this as an encoding of abstract "integer number". The whole point of declaring type in sense of #3 is to be specific about encoding. In mathematics, you (typically) don't care about that; but you sometimes care about use case #2, which is typically dealt by mapping to more abstract concepts with some morphism.

</comment></comment></comment></comment></comment><comment><USER9> How does this compare with this paper? They are both discussing the meaning of the word "type".

[http://dl.acm.org/citation.cfm?id=2661154](http://dl.acm.org/citation.cfm?id=2661154)

There was a good blog post by Stephen Kell that I can't find now ([https://www.cl.cam.ac.uk/~srk31/blog/](https://www.cl.cam.ac.uk/~srk31/blog/))

"The concept of "type" has been used without a consistent, precise definition in discussions about programming languages for 60 years. In this essay I explore various concepts lurking behind distinct uses of this word, highlighting two traditions in which the word came into use largely independently: engineering traditions on the one hand, and those of symbolic logic on the other. These traditions are founded on differing attitudes to the nature and purpose of abstraction, but their distinct uses of "type" have never been explicitly unified. One result is that discourse across these traditions often finds itself at cross purposes, such as overapplying one sense of "type" where another is appropriate, and occasionally proceeding to draw wrong conclusions. I illustrate this with examples from well-known and justly well-regarded literature, and argue that ongoing developments in both the theory and practice of programming make now a good time to resolve these problems."

</comment><comment><USER10> Wow, apropos! I was just thinking about this in the shower.

For most of my life, I equated types with sets of values, but after learning Haskell and working with higher-kinded types, type classes, and existential types, I realized I don't know anymore what a type _is_. I know that type systems provide proof that certain classes of operations are impossible (like comparing a number to a string, or dereferencing an invalid reference).

It's pretty mindbending to use existentials or GADTs and pull two values of a record and not know anything about those values except that, for example, they can be compared for equality.

      data HasTwoEq = forall a. Eq a => HasTwoEq a a

      equalOrNot :: HasTwoEq -> Bool
      equalOrNot (HasTwoEq x y) = x == y

The example is contrived, but it illustrates the point that the types of x and y are not known, _except_ that they can be compared.

That's not the kind of thing you can express with, say, Java or Go interfaces, but it makes perfect sense once you start to break down the mental walls you've built in your head over the years.

I'm thrilled to see a growing body of accessible* PL and type theory literature, because these things are important to helping us develop software at increasingly large scales, and it's clear that very few people -- including myself! -- know enough about this topic.

* e.g. [https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-0...](https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/)

I tried to do my part here: [http://chadaustin.me/2015/07/sum- types/](http://chadaustin.me/2015/07/sum-types/) and [http://chadaustin.me/2015/09/haskell-is-not-a-purely- functio...](http://chadaustin.me/2015/09/haskell-is-not-a-purely-functional- language/)

<comment><USER11> Do these things actually help us develop software at increasingly large scales?

<comment><USER10> Absolutely. As a codebase grows and a larger and larger number of users depend on it, you want to be able to statically verify things like "I never compare an experiment ID to a customer ID" or "timeouts are always precisely specified with their units" or "I never issue a MySQL query from a retriable Redis transaction" or "this unit test is 100% deterministic" or "all code handles the case that this optional field is missing", just to pick a few specific examples that I've run into.

<comment> vezzy-fnord Those sound like jobs amenable to design by contract and information flow control, not necessarily type systems and type theory, per se (though there is some overlap).

<comment><USER12> How is "information flow control" different from a type system?

I've always considered the primary purpose of type systems to be restricting how data can flow through a program.

<comment> vezzy-fnord IFC is orthogonal to type systems, having also been modeled in terms of axiomatic semantics (Hoare logic) independent of a type system. It can also be practically implemented through runtime monitoring, partial evaluation and various hybrid approaches. Type systems are certainly _one_ way of providing foundations for IFC, but few languages have it as a first-class construct. Notable exceptions are SPARK (based on Ada) and Jif (based on Java).

See also "A Perspective on Information-Flow Control": [http://www.cse.chalmers.se/~andrei/mod11.pdf](http://www.cse.chalmers.se/~andrei/mod11.pdf)

<comment><USER13> Interesting, I'll definitely have to check this out. Any input on whether this has been applied and/or could be applied to actor paradigms of computation?

It seems like modeling data flow via messages would be pretty natural semantics for something like this. But first I need to dig into what Hoare logic is and how it applies.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I don't see why this has to be complicated. A type is just a (potentially infinite) set of values. Notice, then, that a (pure) function is just a way to map one set of values to another set of values.

<comment><USER15> It is really unfortunate that people down vote something that is wrong without actually saying what is wrong about it. I think it would help, though, to acknowledge that your opinion is unlikely to be shared with others and to append something like, "Can anyone explain where I'm going wrong?"

Now, I don't actually know much about type theory at all and came here to try to remove some of my ignorance. As such, I can't really help you much, but I will try my best. You might want to look at: [https://en.wikipedia.org/wiki/Type_theory](https://en.wikipedia.org/wiki/Type_theory)

If I read it correctly (and if it is written correctly), a "term" is essentially anything with a "type". So 1, 2 and 3 are terms and they have a type. A "function" is something that takes terms and "reduces" them to other terms. You can "apply" a function to some arguments in order to reduce them. So if we have a function, "myfunc x", we can apply that to 2 and have "myfunc 2". Both "myfunc x" and "myfunc 2" are terms, but they have different types.

Let's make a function that doubles an integer (let's call the type "int"). So "double x" is a term with a type of "int -> int": it maps an int onto an int. "double 2" is a term with a type of int. The term "double double 1" can be "reduced" to the term "double 2". "double 2" can be "reduced" to the term "4". 4 is known as a "normalized term". It can not be reduced any further.

Now, you may be saying "How is this different from what I said?" From what I can tell, the main difference is that a type is _not_ a set of "values" (or normalized terms). Functions applied to terms also have a type. Functions with free variables also have a type. Anything that is a term in an expression has a type. So 1, 2 and 4 are of type int. "double 1", "double 2", and "double double 1" are also all of type int. If we had a function called "fortytwo" that just returned 42, it would also be of type int.

It may seem like a small (possibly insignificant) difference, but it really depends on your point of view. We can completely ignore the type if we want to. Many programming languages make that very easy. We could also subscribe to the idea that a type is just a set of values, like you said. We can write many fine (and many not-so-fine) programs with that point of view.

These views limit the kind of analysis we can do on the code that is written, though. The point of using type theory in computer languages is to help us reason about the code analytically. So my answer to your (unasked) question is, it doesn't _have_ to be complicated. It proves useful to include all of the nuances that type theory gives us. Intentionally putting blinders on to make it seem simple, just deprives us of potentially useful capabilities.

Hopefully someone who actually knows something about this topic will chime in and correct whatever horrible mistakes I've made.

<comment><USER14> You're right - I am thinking "How is this different from what I said?".

> Functions applied to terms also have a type.

Yes, and those types are sets of values. For example, "int -> int" is the set of all functions that map integers to integers. (Remember that functions are also values, just like any other value, in functional programming.)

</comment></comment></comment><comment><USER16> The terminology we have around types is really messed up. What's most annoying is that 'static type system' and 'dynamic type system' are often seen as opposites of each other, but the 'type' in each of the names is a completely different concept.</comment>


Unheap - A tidy repository of jQuery plugins - <AUTHOR> http://www.unheap.com/# <comment><USER2> Apparently one of the projects listed, Packery, is licensed under the MIT license for open source projects, and under an expensive commercial license for commercial projects. This makes my brain hurt. Isn't the whole point of the MIT license that it can be sublicensed without restriction? Then what's to stop someone from sublicensing the free version to themselves for commercial use?

<http://packery.metafizzy.co/license.html>

<comment><USER3> I'm not sure about the MIT, but I believe nothing stops them from doing that. It's like WordPress themes or plugins licensed under the GPL. Most of the time, you pay for support and additional features.

<comment><USER4> If you license under MIT but restrict who can use the software, it's not really MIT. MIT explicitly states that you may use the software "without restriction".

The GPL is even more stringent in that it doesn't allow you to further restrict the usage of others.

It's less about the cost and more about the fact that they don't understand open source licensing.

</comment></comment></comment><comment><USER5> I _love_ this resource, but my only problem is that some of the [beautiful] thumbnails portray the plugin better than the actually are. I'm not complaining about that, but the timeline one in particular was super janky in production but looked lovely in the image.

Not sure how feasible this would be, but what I'd be overjoyed to see is a way to push the resource over to something like Codepen.io (or something on Unheap's end) so you could tinker with it and have all of these spin-offs of people actually customizing the resource that Unheap could also link to. It'd act as additional inspiration, give people more of a reason to use the site, get more designers into code without the setup hassle, and help the plugin author better sell his/her skills as a developer vs. as a designer and likewise, better sell the designer as someone capable of working with code.

<comment><USER6> Then you might like <http://jquer.in>

<comment><USER7> I think you missed his point.

He is asking to see the live demo link to be running on codepen.io. So there is more collaboration via forks, hacks.

Think: There can be more possibilities of using the same plugin via contributions and forks.

</comment></comment></comment><comment><USER8> This is absolutely incredible. Thanks for putting together such an amazing resource!

</comment><comment><USER9> I was just thinking about this...

Suppose you're writing a web page with AngularJS.

Then you find out that you need a component that is very self-contained and of general use - let's say it is a WYSIWYG editor and let's pretend this thing doesn't exist yet (you will have to write it). Now the question:

Do you write it depending on AngularJS, or just JQuery?

<comment><USER10> According to the AngularJS Developer Guide [1]:

«Angular was built for the CRUD application in mind. (...) Games, and GUI editors are examples of very intensive and tricky DOM manipulation. These kinds of apps are different from CRUD apps, and as a result are not a good fit for Angular. In these cases using something closer to bare metal such as jQuery may be a better fit.»

[1] <http://docs.angularjs.org/guide/overview#angularsweetspot>

<comment><USER11> I'd think Backbone plus jQuery makes more sense if you need close to the metal interaction, but still need some level of structure.

<comment><USER12> What is "close to the metal interaction" when you're talking about set of frameworks that run in an embedded interpreter that runs in a browser that runs on a GUI that runs on an OS that runs on.. oh wait.

</comment></comment></comment></comment><comment><USER13> Thanks for listing me, guys! [0]. I bet I've gotten a ton of watchers from it.

[0]: <http://www.unheap.com/?s=dynamo>

</comment><comment><USER14> It's really great that you draw a custom cover image for every single plugin.

Suggestion: make all navigation ajax-based and display the items right away (don't wait until all items are finished loading). This will make your site much-much more faster.

</comment><comment><USER15> Here are even more. There are tons of hidden gems here that surprise me every day :)

<http://pineapple.io/>

</comment><comment><USER16> This is awesome! Only thing that I would -love- to see on this page is a filter so you can select browsers. My company still requires IE6 +up ("just tell your boss to not supp... " Yea, I know, shut the fuck up) so it would be exceedingly useful to strip out everything that won't work in IE6.

</comment><comment><USER17> Great work. You just made my life so much easier. I have always wondered about _finding_ good jquery plugins and imagined if we could find a repo like this. Here it is!! Did I say awesome ?

If you add a donate button, I will happily donate :)

</comment><comment><USER18> Bad ass! Did you do all the "thumbnails" yourself?

<comment><USER19> All thumbnails were designed/made by one person, yep.

<comment><USER20> If they do freelance work, do you mind sharing?

</comment></comment></comment><comment><USER21> I must say, they do a great job at selecting plugins that goes into their repo.

</comment><comment><USER22> I was chuffed that they considered my plugin good enough to add to their list (<http://www.unheap.com/media/images/picstrips/>). They add really nice illustrations for each plugin, the one for PicStrips is way better than anything on the actual Picstrips landing page! Don't know who does the illustrations but I would definitely consider hiring them in the future if they were available.

</comment><comment><USER23> It's slightly weird having such a snappy menu and then when you click something having a second of blank white while it loads the page.

</comment><comment><USER24> Very nicely done! Love the UI. Bookmarked it in hopes that it will help me find plugins for current projects.

</comment><comment><USER25> another good one <http://iwantaneff.in/repo/>

</comment><comment><USER26> Looks great! What's the sort order?

Also, when clicking the tabs on the left the sub menu slides out and the page reloads shortly after. Perhaps it should only reload when you click the "All x" submenu item?

</comment><comment><USER27> Nice! Infinite scroll and sorting by github watchers would be useful too.

<comment><USER28> yep, plus one for infinite scroll, i don't know why people would implement pagination any longer.

also, the form field of the search bar looked confusing to me. I would make it a little less subtle to find it easier.

</comment></comment><comment><USER29> Very cool. One question... how do I actually get to the project page for each of these? I can't find any kind of link anywhere. (Am I just supposed to google the name?)

<comment><USER30> Hover the plugin and a "Launch" button shows up. Might not be compatible with touch devices.

<comment><USER29> Doesn't work on Chrome/Mac (does work on Firefox though). Might be because I have cookies disabled on Chrome... but why would a link require that cookies be enabled?

<comment><USER31> Works on Chrome/Mac for me. I don't have cookies disabled though. That does seem an odd thing to be the issue though.

</comment></comment></comment></comment><comment><USER32> Great stuff, love the design and the icons.

I'd consider making all of the hover animations snappier (side menu, tooltips, etc). They look neat, but feel sluggish.

</comment><comment><USER6> Another similar resource to unheap >> <http://jquer.in>

</comment><comment><USER33> This is great stuff but does it really need to render well on mobile?

</comment><comment><USER34> This is a great tool. +1

</comment><comment><USER35> This is one of the most useful posts I've seen on HN. Thanks!

</comment><comment><USER36> Very nice work. Whats your tech stack like?

</comment><comment><USER37> why this is so awesome!??? tell me! I suddenly found so many cool plugins.

</comment><comment><USER38> Gorgeous design!

</comment><comment><USER39> Another good one, though it hasn't been updated as much lately: <http://www.functionn.in/></comment>


Coronavirus Parties? - <AUTHOR> A large part of our population are children 0-14, who don't succumb to the coronavirus.  Is the government evaluating the option of purposefully quarantining those children at schools and infecting them, keeping them until they are no longer infectious, in order to immunize a large portion of our community?  Similar to pox parties? <comment><USER2> Yes, the government is working on exactly this. The president is planning to open the economy on Easter Sunday, which day he says there will be "packed churches."

Those are the pox parties.

</comment><comment><USER3> No, because it's absurdly stupid.

</comment><comment><USER4> What? No.</comment>


Show HN: PHP lib for Buffer - bufferapp-php - <AUTHOR> https://github.com/thewebguy/bufferapp-php

<comment><AUTHOR> Today I needed a Buffer library but there was none to be found.

It also served as a fun little way to get the hang of the basics of git & github :)</comment>


What Will Apple Release After The iPad? - <AUTHOR> http://www.geeky-gadgets.com/what-will-apple-release-after-the-ipad-01-03-2010/ <comment><USER2> 2020: iTimesSquare

</comment><comment><USER3> the iSlate</comment>


Show HN: A fast append-only data store for Java 8 - <AUTHOR> http://probablyfine.co.uk/2015/04/11/announcing-java-dirty/

<comment><USER2> An example of good idiomatic Java 8 source code.

Example:

[https://github.com/mrwilson/java- dirty/blob/master/src/main/...](https://github.com/mrwilson/java- dirty/blob/master/src/main/java/uk/co/probablyfine/dirty/Store.java)

<comment><USER3> What are the Java 8 features being used here, besides the obvious lambda expressions?

(genuine question, I haven't stayed current with Java)

<comment><USER4> Optional is also new to Java 8 although syntactically very similar that Guava.

</comment></comment></comment><comment><USER5> How would you compare and contrast this with [http://openhft.net/products/chronicle- queue/](http://openhft.net/products/chronicle-queue/)? (which I knows does a bunch more but seems like it could be used for this purpose too).

<comment><USER6> This is not comparable to chronicle, this is one of the mechanisms by which chronicle works (memory mapped files).

[http://stackoverflow.com/a/9268065](http://stackoverflow.com/a/9268065)

</comment></comment><comment><USER7> This reminds me of the log abstraction:

[http://engineering.linkedin.com/distributed-systems/log- what...](http://engineering.linkedin.com/distributed-systems/log-what-every- software-engineer-should-know-about-real-time-datas-unifying)

</comment><comment><USER8> > frequently find myself wanting a light append-only data store for pet > projects

As someone who is mystified by that statement: why?

<comment><USER9> Could be used as an event store. Rather than storing a list of mutable objects as in a normal database, you store the changes themselves as a list of facts. This makes things like replication a lot easier and can be optimized to be much faster than a traditional database.

<comment><USER10> There's Apache BookKeeper to fill some of those needs.

<comment><USER11> I've never seen BookKeeper in production. Where would you recommend its use over something like Kafka?

</comment></comment></comment></comment><comment><USER12> Really nice, I am just needing this ;) Super that it is MIT licensed as well. I was halfway on building something on top of XZ SeekableInput Streams but this is probably a lot saner to use ;)

</comment><comment><USER13> Great. I've been wanting something like this for a while. I've got a few questions:

1\. How large files are supported?

2\. It says that it will only persist primitive fields on objects - does that exclude persisting a byte array?

3\. What are the failure semantics? For example, what happens if my computer's power supply fails in the middle of a write? How will the program behave the next time it is started?

<comment><USER14> Good questions, but wouldn't it be fun to find out the answers using empirical tests? You might even be able to add tests and submit a PR, and be immortalized in the annals of github.

<comment><USER15> You don't get things done very fast, do you?

<comment><USER16> > You don't get things done very fast, do you?

Please don't make rude comments on Hacker News.

<comment><USER15> It is a legitimate response to a problem that plagues the hacker community. Focus on the task at hand. Trying to understand the intricacies of a system can be educational but the best lessons learned are from completing your current project.

I'm surrounded by intelligent people that can't get anything done.

<comment><USER16> Ok, but the problem with your previous comment wasn't your view, but the rudeness. It's possible to express your view without rudeness; you just did. That's what we're going for here.

</comment></comment></comment></comment></comment></comment><comment><USER17> \+ For chronicle

Have look at my profile. Also there is KVEngine from H2.

<comment><USER5> I tried googling for H2 KVEngine but didn't come up with anything, did you mean [http://www.h2database.com/html/mvstore.html](http://www.h2database.com/html/mvstore.html) perhaps?

<comment><USER17> yes

</comment></comment></comment><comment><USER18> This actually seems pretty useful. I'll be sure to check it out for my next Java project.</comment>


Minuteman: A Distributed HA Load Balancer - <AUTHOR> https://github.com/dcos/minuteman <comment><USER2> How is this different from bamboo - also an HAproxy based LB thats via the marathon framework?

[https://github.com/QubitProducts/bamboo](https://github.com/QubitProducts/bamboo)

<comment><USER3> Co-author here!

There are several differences: 1\. We're coupled with the kernel and operating at layer 4. Specifically, we play with the conntrack subsystem. This means, you may pay a little higher cost for the first packet of a connection (because we've got to program the flow), but once the flow is programmed, it's totally going through kernel space. The way Minuteman is meant to be used is to act as the underlying router of a connection pool, or some such.

2\. We expose the pools as "VIPs" or Virtual IPs. When you expose a service, you specify an IP-port pair (like 220.127.116.11:5000). In my opinion, that's a little bit nicer than Bamboo's routing.

3\. We work with all Mesos frameworks.

4\. We have an underlying distributed control plane ([https://github.com/dcos/lashup](https://github.com/dcos/lashup)), which lets us detect failures incredibly fast. We've evaluated its capabilities here: [https://github.com/dcos/minuteman#evaluation](https://github.com/dcos/minuteman#evaluation)

</comment></comment><comment><USER4> This should probably more prominently explain at the beginning of the README that it's for Linux. Nothing wrong with that, but being bound to Linux is an important detail.

<comment><USER3> Thanks! I'll be sure to add that note! Currently, minuteman targets Mesosphere's DC/OS (dcos.io), which is Linux only.

We've thought about what it would take to port it to Windows, and it's feasible. Just a matter of work. If you're interested, let me know.

</comment></comment><comment><USER2> Thanks for the response. Agree about the Bamboo routing. Lashup is interesting. Is the conntrack data replicated then to all Minuteman nodes so if you were to lose one minutemen a client wouldn't lose its "established" state when it has to connect to another minuteman node? Or am I failing to understand the design?

</comment><comment><USER5> This looks great.

Like the use of a in-kernel netfilter for data plane.

Clustering and failure recovery look solid as well.

</comment><comment><USER3> Co-Author here. If anyone has any questions, feel free to ask!

<comment><USER6> Is the naming on purpose to be identical to an ICBM?

<comment><USER3> I really enjoy naming things. The naming has a bit of a history. The first version used open flow. We wrote the flows on demand for the connections, and the project's name was 'Minuteman: flows at a moment's notice' as a reference to the soldiers during the revolutionary war that were prepared to fight at a moment's notice.

Although we changed the architecture, we decided to stick with Minuteman. Mesosphere's naming scheme has historically had to do with space. The road to the stars was originally paved by programs such as Minuteman -- Our mission is to orchestrate the data center. You can't do that without networking. Minuteman is our first networking component of many as one of the first components to help pave our way.

</comment></comment></comment><comment><USER7> Could you please comment on how this compares to Linux Virtual Server/ipvs that is also a Linux kernel-level layer 4 load balancing technology?</comment>


Git smart: How we're using Git to track our source code - <AUTHOR> http://www.37signals.com/svn/posts/1071-git-smart-how-were-using-git-to-track-our-source-code

<comment><USER2> Despite the 37s backlash, I think this was a good post. I had heard of lots of hackers using Git but not any companies. The fact that a well known company like 37s is using it gives it more credibility and exposure, which will help get more users, which will provide more contributors, documenters, etc.

</comment><comment><USER3> "Branching and merging in git, though, are wonderfully, blissfully straightforward."

That is a lie (or at best something like Stockholm Syndrome). Nothing in git is straightforward, let alone blissfully so.

<comment><USER3> Well, init and clone are straightforward -- the only porcelain that git actually has, as far as I can tell.

</comment></comment><comment><USER4> Is there some kind of karma-grabbing contest to post everything that comes out on a few key blogs before anyone else can?

<comment><USER4> Ew. Someone just posted a message about auto-scripting something like this. Now I feel dirty and ashamed for suggesting it, even if they didn't get the idea from me.

<comment><USER5> Don't worry, it's been suggested several times before. If someone is that "needy" for karma, let them. I prefer to earn mine the old fashioned way.</comment></comment></comment>