HN user
This is a decent article and (in some sense), I agree with Page's argument - though the H1N1 reference is a bit over the top.
I'm not sure where the rather sensationalist headline comes from, though; would you consider offering a nuanced argument as to why user data retention makes the company "evil" to back it up?
"What ultimately matters most in life is how much money you make..."
Interesting value judgment there.
This is great to see. I've been curious about trying Passenger, but am addicted to Nginx. Looking forward to playing around, and if the fit is right, deploying with it.
Free software is great. But it's okay to charge for things, too.
Call it me-too if you like, Matt, but there's some great stuff coming out of Techstars. I don't care where innovative companies come from - just that they get off the ground.
Sorry to hear you're not into that.
I straddle the line between these worlds. My day job is frontend development with some Ruby here and there, while I've been designing and building out a Rails app on the side.
I think my response would be similar to your 'developer-side' response - if at any point in working on a project I find myself confronted with something I do not understand, I have this compulsive urge to figure it out. In the process, I've saved myself thousands of dollars by investing a few days to learn what I need to at the time to get around the problem.
It sounds like you're a great Ruby developer with a leg up on all of the new "ZOMG RAILS!" converts. Don't be too concerned about the "jack of all trades, master of none" category. If you're working on building a company from scratch, product guys/gals are key - people who may not be experts in everything, but can get the job done for rev1 no matter what. If you can play that role yourself, you'll have far fewer people to depend on.
If you decide to work on the frontend yourself, start with raw HTML and forget that CSS exists entirely. This might help you to think of HTML/CSS as a backend developer.
HTML is just XML with a fixed set of elements that are named according to their purpose and have specific functions in a document - and you'll probably only need a small subset of them. So, look at your comp and think of the elements in it; paragraphs, lists, images, buttons, links, etc. Then, start writing what seems like an XML document describing it. Again, don't even think about styling it at this point. Just build the best web page that 1994 ever saw:
<html>
<head>
<title>My Application</title>
</head>
<body>
<div id="header">
<div id="branding">(Name, logo, etc. here)</div>
<div id="nav">(Navigation)</div>
</div>
<div id="content" class="column">(Main app content)</div>
<div id="sidebar" class="column">(Sidebar content, if you have one)</div>
<div id="footer"></div>
</body>
</html>
Good luck building your application; whichever route you choose, let us know when it launches!
And if you'd like any recommendations for either a designer or just someone who can slice and dice a comp, let me know; I've got a few solid friends who charge reasonable rates and have some availability coming up.
I seriously find it difficult to believe that this is still a debate on YC. Once you attempt to build a site of a reasonably level of complexity and/or learn how to build a site using clean, valid, semantic markup, you'll never go back - unless horribly messy code and hack piled upon hack are your thing.
This isn't about being a web standards zealot. It's about learning to do your job. Look to any of the industry leaders in frontend development - it is simply no longer an issue. Table-based implementations of layouts (and all non-tabular data) are the GOTOs of modern markup.
Cutting up a comp isn't "design," it's implementation.
I have never seen a frontend web development position where slicing comps wasn't a core component of the job description. If the primary languages they listed in the description are HTML, CSS, and JS, then this is probably what they imagined you'd be doing from the beginning.
On the other hand, if you a "programmer" proper and the primary languages listed are Ruby, Python, PHP, Java, etc., then I could understand a little frustration. But keep in mind - if you're working in web and doing any frontend work at all, most employers will (rightly) expect that you have these skills.
I hope the position you've found works out for you, or that you're able to find something better that you'd prefer.
Good luck!