Locke

I don't know that I particularly disagree with you. The one advantage that a language scoped packaging system has over a system-wide system is developer adoption.

Debian, Gentoo, Redhat, FreeBSD, etc all depend on heavily on volunteers to create the packages, manage dependencies, issue security announcements, feed bug reports and patches upstream to developers, etc. I've used Gentoo for a long time and I've watched it struggle in recent years as it loses volunteers. New releases take longer to reach portage, some software never finds its way to portage at all, and I find more and more broken packages. The only Ruby package I install from portage is Ruby itself.

The thing is, every Ruby developer uses RubyGems. There are no volunteers because the developers themselves create the packages for each release. I think this is more sustainable, even if I don't think RubyGems is as good as the packaging tools used by the major distributions.

Wow. I'm not going to claim that rubygems is the best package management system, or that it's better than debian's packaging system. But, some of your frustration comes from the fact that you know apt very well and you don't seem to know rubygems very well.

For example, you can setup your own local gem server. You can load it with only the gems you want to install on your fleet of machines and use 'gem install --source your-local-server fastthread', for example. You might even get around your "pick the right gem" problem by installing only the fastthread gem you need on your local server.

But, I think the real problem you have with rubygems is that you don't want to learn another package management system. I really don't think the rubygems devs can do anything to remedy that problem.

Yes, it's clear that Rails blazed the path for Merb. At the same time, the Rails people really shouldn't be surprised (or feel badly) that their "opinionated software" has created a market for flexible, agnostic software.

Both projects are great, and will probably appeal to different sets of developers. In a lot of ways I think of it like the dynamic between Python and Ruby. Both are excellent languages with very similar capabilities, yet they appeal to different developers. It's like there's an element of personality in there, and there's nothing wrong with that.

Not that I follow it too closely, but I think Ruby was in the top 10 until it slipped a few spots recently.

In what way do you feel like rails support for postgresql is an afterthought?

I've noticed some books / documentation assume mysql, but that's usually limited to the "and now setup your database" section.

I've been using rails + postgresql for a long time now (almost 2 years in production) and I can't think of a single problem that was due to not using mysql. Of course, I don't use every plugin or feature, so there may be something out there...

In my case the effort was minimal. I certainly wouldn't measure the effort in "man-months". Here's how it went for me:

0. Research. This is one small part of why I read HN, and other assorted "news" sites. I like to stay current with the tools I use. I don't jump at every new tool just because it's new, but I understand that my current set of tools is not perfect. Sooner or later, I'm going to replace every tool in my toolbox with an even better tool. I may like my current set of tools today, but I understand that it's important not to get so attached to them that I stagnate as a developer. I think it's critically important for good developers to stay "intellectually curious".

1. I decided that git was worth trying. So, I started using it with my next new project. This allowed me to establish a new work flow without interrupting active projects. Yes, you'll need to read man pages, cheat sheets, etc. There's no point to adopting a new tool if it behaves exactly like the old one. So, it shouldn't be a surprise when you actually have to commit to learning the new tool. That said, I found git to be more user friendly than I'd expected based on the negative comments I'd read online.

2. I decided I liked the new work flow and that git was worth switching to. I moved my old projects over to git in less than a day and used git for all my work moving forward.

I'm sure this transition is different for everyone. I'm also sure that git is not yet (and may never be) a good fit for some people. But, I really don't see the point in disparaging those who think the switch is worthwhile for them.

He's so prolific that for a while I wondered if _why wasn't really a collection of people. But, he's just so consistently odd and unique (in a good way) that it's hard to imagine that there could be more than one _why.

(Although, I wonder how hard it would be to use markov chains to generate _why-like rambling rants)

Yes. How do people buy cars? On credit. Harder to get credit means fewer people capable of buying cars. A bad economy means fewer people buying cars. GM et al, did not create the credit crisis. They did not create the bad economic conditions.

But we want them, and more importantly, all the people working in that industry to suffer? Honestly, I can't imagine how letting them fail won't cause more than 25 billion in economic damage.

It baffles me that we'd blow 700 billion bailing out financial institutions that caused our economic problems. Money that's now going towards bonuses and acquisitions instead of buying "toxic assets" as originally intended. Toxic assets that were created by these same wall street companies.

As we save the companies that crippled the credit markets, we have no interest in spending a fraction of that same amount of money helping the companies most negatively effected by the condition of those same credit markets.

I'm sorry, but I don't see anyone buying a car from a manufacturer in bankruptcy. I think bankruptcy will be the end of the American auto manufacturers. The resulting damage will dwarf the 25 billion a bailout would cost.

I'm not sure your post deserves to be downmodded -- it seems honest and on topic. I can see how one bit in particular could come off as slightly offensive:

'Speaking only for myself, any candidate who starts going down the road of "I won't fill out employment application until we are interested in each other", "I won't discuss previous salary", "I won't provide references until there is an offer letter", etc... - just screams "Prima Donna"'

This is a matter of trust. Salary history, a detailed employment history, and references are private. In the case of references it would be down right rude, to repay the people who are willing to vouch for you by spamming their contact info to anyone who asks. There is nothing unreasonable about withholding that info until both sides clearly serious about moving forward. If anything, I wonder what your cavalier attitude screams about you?

On a related note, if you find this line of thought interesting, you'd probably enjoy Steve Martin's Born Standing Up.

It's a beautifully written memoir in which he tells the story of how he became one of the most successful stand-up comedians ever. I'm not much of a reader, but for what it's worth, it's probably the best thing I've read this year. And, yes, it reinforces the idea that "genius" is often the result of years of hard work and trial and error.

I think our opinions are informed by very different "real world" experiences. I've worked mainly at small companies where HR had very little power over staffing or other important decisions. When I have had hiring responsibilities, I worked very hard to balance the interests of the company with the interests of the future employee. I care deeply about the happiness of both parties, because I think happy, successful employees are the foundation of a healthy, successful company.

It sounds like you've worked often (mostly?) with larger companies. Companies staffed with people who think life / business is somehow a game. That in order to win, someone else must lose.

I don't doubt that such companies exist. They may even represent a majority. But, not every company is run that way, and I hope you are fortunate enough to work for a better sort of company someday.

You're first point strikes me as incredibly jaded. That may be the case at poorly run companies, but hasn't been my experience. As in most business relationships, the goal is not to screw the other party. The goal is to arrive at a win-win, where both sides can be happy.

Let's look at what I can expect if I screw someone over with the lowest possible salary:

* An employee who can justify doing the bare minimum it takes to get the job done, because after all, he's being paid the bare minimum

* Low morale. Can I not expect the individual to bitch about how poorly the company treats its employees?

* High turnover / no loyalty. How much money am I going to waste bringing people up to speed, only to see them hop to the next job as soon as possible? How can I expect to retain valuable employees when I don't treat them as valuable from the start?

It's a poorly run business that screws over it's employees, customers, and / or partners just because it can. I like to think most good business people recognize that that sort of approach does not yield the best results over the long term.

Frankly, I have no concerns about revealing salary requirements or providing salary history. If a company doesn't treat me fairly during negotiations that's a huge signal that it's not the sort of company I want to work for.

In short, yes there are other advantages. If you just want a list, the release announcement is full of goodies. I was really just listing the things I noticed when working on one small app. As to features I haven't used, yet... I'm probably most excited about Merb's slices. Slices are potentially a huge win for code organization and re-use across webapps.

Okay, here's a situation I've run into: I want to create a web frontend to an existing library. Naturally, the existing library already has some nice model-like classes that I'll be working with.

What I'd like to do is take those model-like classes and persist them to the database. It should just be a simple matter of mapping a few instance variables / attributes to database columns right? Well, it turns out this is fairly difficult with ActiveRecord. Firstly, ActiveRecord wants all your models to extend ActiveRecord::Base. But, I already have an existing class and the chances are I don't want to, or can't, change the existing class to extend AR::Base.

So maybe I'll to create an ActiveRecord model that will wrap and delegate to the existing class. Ah, but AR::Base has a huge footprint and uses so much magic that it's downright painful to do delegation. You can't safely use method_missing because AR::Base does, and you're almost guaranteed to have a conflict where AR::Base and your existing class define the same methods anyway.

Here's how DataMapper is different: You're not required to extend any sort of base class. Instead, you mixin a module with a tiny footprint. So, in your web frontend, you can open the existing model-like class, mixin DataMapper::Resource, and map your properties to columns. Because the footprint for DataMapper::Resource is so light, and it doesn't use any magic, it's unlikely we'll break the existing class. Even if we do break it with this approach, we're far more likely to succeed with delegation that we are under ActiveRecord.

So, to bring it back to Merb and Rails, here's the key difference: ActiveRecord might be just fine for most projects. But, maybe DataMapper is sometimes better. Or, maybe another ORM is. In any case, Merb will let me work with whatever library I think is best for my project. Rails give you no choice. You either take the whole stack as is or you don't.

And, that doesn't just apply to the ORM layer. The same can be said for template engines and javascript libraries.

This is great if you happen to love every design decision the Rails crew has made for you. If not...

I don't think Merb will replace Rails. I think, ultimately, the two appeal to different crowds. Too some extent, I hope people who are happy with Rails stay with Rails. Merb feels like it's more aligned with the Ruby community than the Rails community. If that makes any sense.

I made one small demo app in Merb about a month ago -- so, slightly pre-1.0. Overall, it was a good experience and I intend to continue exploring Merb.

A few points:

* Not as much documentation... sometimes it takes a while to find the Merb equivalent of some Railsism. The interfaces for Merb are very similar to Rails, though, so usually just trying the equivalent is enough. The differences I encountered were usually improvements over the Rails approach, IMHO.

* Smaller community. So, fewer plugins, fewer examples, fewer HOWTOs, etc. Hopefully this will change. But if you're uncomfortable developing something without a ton of resources to leverage...

* More flexible. I used Datamapper instead of ActiveRecord, and was very happy to have a choice. I was also very happy with Datamapper itself. I'm not sure Datamapper is mature enough, yet, for large scale projects, but the future is bright.

Overall, I think Merb benefits strongly from the "hindsight is 20/20" adage. It takes the best of Rails and rethinks its shortcomings. Where Rails was more revolutionarly, Merb is evolutionary. I think the improvements are worth the trouble of learning another web framework. I intend to use Merb for any new projects I start.

My demo app is http://ifrotz.org -- not that it's at all enlightening in a Merb vs Rails debate.

The long list of skills is a symptom of a much larger problem. Too many companies are just clueless about hiring technical staff.

These things don't work: using HR, resume databases, keyword searches, creating an overlong and too detailed list of requirements and then treating them as a checklist.

Yet, this is the approach taken by far too many companies. The result, of course, is a stack of resumes a mile high that each contain a list of as many buzzwords and skills as possible. How do companies expect to find a good match in all that?

The way out is simple. Create a simple resume, with a small focused set of "skills". Leave out anything that's irrelevant to what you actually want to do. Then send it to a small handful of companies that run reasonable adverts. There may be fewer such opportunities, but I think a focused approach works better in the long run.

Very nice. It'd be nice to see a little better relevance. For example, I searched for "game" then drilled down to one of my projects which was listed in the side bar. Towards the bottom of the results was a hit from "game.rb"... it seems like a hit from a file who's name includes the search term might be more relevant than that.

Or, perhaps a hit like "class Game" should be considered more relevant than "attr_reader :game". Perhaps.

Overall, very nice though.

It seems to me that the big disconnect here is this:

When you're the game developer you know exactly what the user wants to do. They want to advance through the game and have fun. You can make early levels where the player learns one new skill at a time, so as not to overload them. And then when they're ready you can hit them with more complex challenges.

When you're developing some kind of productivity app, a word processor for example, you don't know specifically what your user wants to do. Maybe I want to write a novel? Maybe I want to create a brochure? Maybe I want to insert tables and graphs into a business document? How do you guide me through when you don't know where I'm coming from or where I'm going?

I agree. At least he's upfront about his ridiculous standards in his blog.

The amount of code and then the use of the code strikes me as unethical. I don't see where the company would own any of that code whether or not the coder is hired. If you want a contractor for a short project you should pay for the work, file proper tax documents, etc.

The goal of a resume / cover letter are to land an interview. It's not an autobiography.

I can say from personal experience that one does not completely read hundreds of resumes. When I was hiring I would get just as much info from a short resume as I would from a long resume. The key difference is that with a shorter more focused resume you have more control over what I actually take away from your resume.

So for that reason I use a one page resume that's tightly focused on what I want to do, not everything I've ever been capable of doing.

But I don't want my resume in some HR or recruiter database, either. A long resume make work better if you prefer the shotgun approach to finding work...

It's still a fairly decent reference if you need to update your software for 1.9. Several incompatibilities I ran into were listed there. For others problems, I did have to search the mailing lists, though.

The plan has been for 1.9 to be a stable series for a long (at least over a year) time now. I'm not sure there are any concrete plans for 2.0 at this time. If you use Ruby, now would be a good time to start getting comfortable with 1.9, though there doesn't seem to be much rush.

I updated one of my projects to work with 1.8.6 and 1.9 a couple months ago and it was mostly painless. I'm looking forward to the nice performance improvement and some of the api changes when it becomes production ready.

Okay, so there's a large number of people here who have opinions on, or an interest in, the hiring of hackers. This seems natural -- this is after all "Hacker News" and a large number of hackers will at some point or another participate in the hiring process. This is a recurring discussion here, so we should not be surprised to see the topic come up again.

Curiously enough, there's also a large number of people who have an interest in YC and companies that have received funding from YC. Bizarre, I know.

So, is it really a surprise that people would want to discuss a controversial job advert posted by a YC funded company?

The only disappointment is that these comments couldn't have been added to the advert posting itself.

As to your karma, I think people get tired of meta-discussions / whining about why one item gets more points than another. At the very least it's off topic here.

Despite how hard you try, you can't get this 100% right. This is how I approached hiring:

1. Weed out the truly incompetent. A very simple programming exercise is sufficient. Keep in mind that the goal of the exercise is not to identify a great programmer, but rather to identify those who can't program at all.

2. Set expectations. During the interviewing process, try your best to work out what you would expect from the individual if hired. Would you expect them to churn out a ton of quality code? Do you expect them to be great at determining business needs and writing less code, but code with a high impact? Is this going to be your go to guy for technology X? Do you expect your junior person to learn Y and Z so they can start contributing after N months?

3. Communicate your expectations clearly. Make sure the candidate knows what's expected of him or her. Towards the end of the interview discuss how they feel about those expectations. Ask how they plan on going about meeting them.

4. After hiring: If you get it right great, if not, let the person go sooner than later. You do yourself and the individual a great disservice if you try to turn them into something they are not. Don't try to turn a lump of coal into a diamond. It's a trap. It doesn't work. They will be unhappy and resentful if you try. Nobody likes to be fired (or do the firing) but you have to tell yourself it's best that they get back out there and find the job that they can be happy and successful at.

You're reading it wrong. He used 10 requests to illustrate that they would be handled in parallel (vs sequentially as in stock rails). His actual benchmarks show many thousands of requests being processed.

* This was originally in response to a comment asking if the benchmark only consisted of 10 requests.

How do you know what questions to ask your lawyer? How do you know what info might be pertinent to helping your lawyer to give sound advice?

Let's say I were to ask for advice about X. Someone posts, "Oh, when I went through X, my lawyer advised me to do Y and I think it really helped." So, then when I talk to a lawyer I can ask about Y. I don't see how opening a dialog hurt anything?

How does a little extra knowledge lead to disaster? Note: I'm not talking about forgoing a lawyer's advice in favor of listening to an internet nutjob.

You seem to be advocating ignorance and/or blind faith lawyers. How do you recognize a bad lawyer if you don't make any effort to educate yourself?

It occurs to me that I've strayed from the point I wanted to make. I'm not arguing that advice from non-lawyers can or should be used as a replacement for a lawyer's advice. I'm arguing against the idea that advice from non-lawyers is worthless and should be avoided at all costs.

You mean to say that every legal issue is life and death?

There's no variability? There are no minor legal issues? I should consult a lawyer about, say, a parking ticket?