1,293 karma · joined March 24, 2011
You can get in touch with me at nicholas@lyssna.com.
Not that I disagree with your premise - if you need to write highly performant code, lower level languages will pretty much always be faster. But abstraction is extremely beneficial in many other circumstances.
Sounds like it's not stored in plaintext.
He found serious flaws in DNS and SSL. Of course one code review is not authoritative, but he is pretty credible.
It very rarely works out.
If it's something that nobody on your team can tackle you can easily end up with completely disparate development environments (with devs running different ruby versions, app servers, even databases!) when there's no well documented system for setting up environments.
Heroku makes it dead simple to deploy and add services, but if your team can't manage to do that for local development anyway, things can end up in a really bad state.
For me, I'm held back more by the UI rather than the features. I find the different, independent panels very confusing, and the popups (for eg. XHR request info) drive me nuts. I'm sure there's a strong rationale for how it is, but it doesn't quite click for me.
I've tried going back to Firebug where the UI is more my style, but for me, it's too slow (on my not new, but not old laptop). It often takes several seconds to launch the select element tool, and can lock up for a couple of seconds at a time.
The built-in tools are much faster, which is great. I'm just not accustomed to the UI, and have reservations about whether I can get into it or not.
The number of people in my CS degree that couldn't program - at all - was astounding. I did a final year subject on databases, and ended up in an end of semester group project with two students that didn't know the difference between a table, and a database.
If you're about to start a startup, I'd strongly encourage you to come up with some hypothetical figures for these metrics:
* Number of monthly uniques
* Percentage that will convert to trial
* Percentage that will convert to paid
* Average monthly subscription cost
* Churn rate
* Cost of acquisition
You'll be way off, but run the numbers you've made up past as many experienced founders as you can, and you might be able to come up with a model that's semi-realistic. Of course it will evolve over time as you get some real data and more experience, but the main point of the exercise is to then ask yourself questions like: "How can I get X0,000 uniques to my marketing site on a $0 marketing budget?", and "What can I change about my product/positioning/target market so I can triple my average monthly subscription cost?".
Were these kinds of exploits noted when writing the 1394 spec and ignored in favour of the DMA feature?