dkubb

IMHO if you have even the smallest doubt I would remove the child from the daycare and either move them to another, or bring them home.

With my first son we ignored some of the doubt, thinking we were being overprotective first-time parents. Once we made the decision to move him to a new daycare, the changes in my son were immediate. He was socializing with kids, and learning much more rapidly than before, and in general much of the behavioural problems we were having disappeared.

Even more perl-awk-ish would be to use the -F and -a switch and move the regexp onto the command line, eg: https://gist.github.com/942975

It's nice to see people thinking about processing input as a stream rather than waiting for the entire message to be received before doing anything.

If you start to think about input and output in web app as streams rather than buffered data, alot of neat possibilities arise for reducing latency.

No. I don't believe there ever can be. For a specific technology choice to become useful -- and more importantly to remain useful -- I think it needs strong competition.

To expand on this, I'm not saying that I think alot of programmers are idiots. (I realize now it could be taken that way)

What I mean is that as an industry, we're in the stone ages. What we're doing will be looked back upon the same way that look back at bloodletting that was practiced by doctors a few hundred years ago.

Just when I think I'm beginning to get a grip on things, a whole new layer opens up, and I start over as a beginner again. I've heard anecdotal evidence that programmers who have been around 30 or 40 years still experience this.

Funny, I always like it when people have strong opinions.

Maybe that's not the same thing as "too many" opinions; like when people have opinions on something they have no experience with.

I've always preferred it when people have strong, but weakly held opinions. [1]

[1] http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...

That almost no one really knows what they're doing.

I know you were asking about design, but the first thing I usually do with a new project (usually commit #2) is to make sure the deployment process works.

Then I usually setup a CI service that runs the specs on each commit, and deploys to a staging/demo server automatically if they pass.

The reason I do this first is that deployment becomes more difficult the further into the project you get. It's easier to work through deployment issues incrementally rather than just before launch, or when you want to demo the app to someone outside.

Maybe it's not the norm, but I've read about new findings in the past, mentioned them to my family doctor and found that he's familiar with the same studies.

Like developers, I'm sure there are doctors who just do their 9-5 and go home, while others continue to study, attend conferences and discuss new techniques with other doctors. Also similarly it's hard for the people who hire them ("us") to differentiate between them unless we have domain specific knowledge or someone who does and we trust to recommend a good doctor.

I believe it's a good thing when I see code I wrote 6 months ago and think it sucks. If I thought it was perfect then that would be a sign that I hadn't learned much since I wrote it.

This works predates Rails 3 by about 2 or 3 years. I would bet it indirectly influenced AR3, and I know it has influenced DataMapper (which I maintain).

One major difference with Ambition is that you're writing the queries in the same code you would when using the normal Enumerable API. IMHO from an interface pov, it's better than any Ruby ORM has provided (or would ever be able to). However, the (big) downside is that it requires ParseTree, which only works on Ruby 1.8. It's also a bit fragile, since if you use code the underlying parser doesn't understand you'll get weird runtime errors.

I created an Ambition-like interface to DataMapper early last year, which uses a similar approach:

  http://github.com/dkubb/dm-ambition/

The main difference (aside from working with DataMapper) is that when the underlying collection is already lazy loaded the block provided is evaluated for each record using the normal Enumerable methods. I believe the Ambition project has a few constructs that make this impossible, but in dm-ambition I set this as a requirement from the start.

How do you set this by default? I looked through git-config, and elsewhere, but I couldn't find any way to do it, short of using a shell wrapper.

When I was more a user of open source software I would've agreed with you, but as I've become more involved as a developer I've come to understand Brett's point of view.

Now, I don't think the correct approach is to tell users to shut up. That's just dumb. I do think it's important to try to convey that there are real people working on this software, with real life pressures, and unconstructive criticism is not going to have any kind of positive result. At best it will have no effect, and at worst it will cause developers to lose motivation and move on.

One of the myths of open source software is that the whole community is pitching in, and developing software in tandem with a "core team" who is setting the direction for the project. The truth is that most of the work is being done by one or two developers, and the cumulative contributions by others in the community does not come close to what they're doing.

There are few open source projects that can survive if one of those core contributors becomes demotivated or loses interest.

Most people who work on open source software do so for the love of programming, and the joy in helping other people. When you read stuff like "This sucks!", or "I wasted so much time fighting with your project today", you start to question if you're really helping people. You think that maybe you should move onto something else that would help people, focus on a startup for yourself, take on contract work, learn something new or whatever. If you're like me, there's a dozen projects you could start on today if you weren't focused on an open source project.

You don't have to treat core contributors like rockstars, but it does help to treat them with respect and remember that there are real people behind those keyboards.

We're just getting started with DataMapper too. Lots of things planned in the future as we refine the API and internals.

For example, we're looking towards allowing normal ruby objects to be persisted, not just objects that include DataMapper::Resource. I'm also working on a query/adapter layer that will allow more complex queries to be constructed similar to ARel called Veritas (http://github.com/dkubb/veritas/), except it will include alot of the things we've learned about working with 40+ datastores, some vastly different from RDBMS.

This reminds me a bit of Edge Side Includes (ESI), although I realize this is done on the client side more than the server side.

ESI got alot of attention about 10 years ago, but then sort of fell out of favor in the tech media/blogs. Some big companies are still using them like Akamai, and the Varnish HTTP accelerator has some basic support for it.

I always liked the idea of breaking up my page into smaller segments, and then caching each part independently, and assembling the page from the cache. The cache could request only the parts of the page that aren't in cache/expired/uncachable, but otherwise pull everything from a super-fast cache.

Whenever I've tried to reuse the same controller for two URLs, I usually end up with some conditional logic within the controller to handle difference in parameters available from the URL.

I think a better approach would've been for me to subclass one from the other, or have a common parent class, and then handle the parameter differences within each subclass. At that point you'd end up with a 1:1 mapping between controller class and URL anyway.

Agreed. I always thought that Rails controllers violated the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle) by mixing collection and member concerns into a single class.

I've often wondered why we don't have any standardized test cases for email validation. A simple list of known good, and known bad addresses to use as test cases would really help.

You could almost make a game out of finding valid addresses that are not matched, or invalid addresses that are false positives, or optimizing candidate regexps. The list could be continuously growing as new variations are discovered, and tested against previously submitted candidate regexps.

From here maybe? http://tfletcher.com/lib/rfc822.rb

FWIW, I just visited your link and with a cold cache it took ~5 seconds the status bar to report every asset was downloaded. Definitely not a scientific measurement by any means, but I thought you might like to know.

I also ran the site through http://www.webpageanalyzer.com/ (one of many such services), and it said on a T1 it would take approximately 6.5 seconds to load. It also provides a number of improvements to cut down the page size, and improve rendering speed.

You are correct that SEO people would latch onto the idea and start producing faster sites. But so will many legitimate sites that want to provide a good user experience. Is that really so bad?

I think that site speed does correlate with a better user experience. A site that loads quickly shows that the person who made it cares about my experience more than a bloated site that takes forever to load.

I will admit that it's certainly not as as strong an indicator as the content, inbound links and other factors that are rumored to be part of PageRank but speed does matter. All other things being equal, I would much rather visit a site that loads in 2 seconds than one that loads in 20 seconds.

That was my thinking too. With PageRank Google is trying to find a way to measure the perceived quality of the user experience for each page. Except there's no way to do that directly, so they look at indirect methods, like counting the number of inbound links. This is just another indirect measurement to add to (what I'm sure is) hundreds of other factors they use to rank a site.

IMHO a site that cares about the user experience would have been optimized to load quickly.

Heck, even if Google told people speed was important, and didn't incorporate any speed measurements into PageRank, I think it would have a positive effect.

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web:

Update their PageRank algorithm to take into account website speed, and then publish this as a fact.

The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and slow sites lower.

One of the problems with PageRank is that most of how they measure site quality is a mystery, but making it plain that speed is used in ranking would bring website performance to the front of everyone's minds. They could use similar metrics as YSlow and PageSpeed use, and tell everyone to optimize their sites using those tools as a starting point.

Regardless of what anyone says here, you have to test several approaches and pick the best performing one.

One company I worked for was famous in it's niche for running tests. We'd run 30/45/60 day free trials, bundle offers, one-time offers, and so on. I mean we ran literally hundreds of split tests every year. The funny thing is that we went a few years before trying a low $1 trial (for a $100+ item) on a whim, and you know what? It out-pulled almost every free trial test we'd ever run. Then we bumped it up to $2.95, and that out-pulled $1 even more.

All this time we'd been running free trials because common sense said that's what would pull best. Not testing this earlier was literally a multi-million dollar mistake.

This taught me a valuable lesson: never make any assumptions about what will or will not work, and test all time.

$2500 for 50 hours of work works out to $50 p/hour. I don't know what the fair market rate is for freelance client side app dev, but that sounds a bit low. Most web designers I know bill higher than that. For $50 an hour I'd either expect the developer to be really junior, or experienced but totally unaware of their own value.

Also, I agree that providing a percentage of the possible profits is not a very good motivator. Unless you're some master marketer with proven businesses experience behind you, it's a bad gamble for the programmer.

As a freelancer myself I think it's really important to finish what you start, and keep your promises.

Sure, there are times when you have to walk away from a project, such as when there are personality conflicts, or unreasonable expectations. It doesn't sound like that's the case here.

Keep in mind that most software isn't actually done when you deliver on the initial specs. Companies will usually expect you to be available for some sort of maintenance phase where bugs fixes and small feature additions are done by you. They'll likely expect you to work at your original rate unless otherwise specified. Even though you think it's only going to be 200 hours I suspect you will likely be involved with them longer than that.

What I would do is finish the contract, but start to set the company's expectations now so there are no surprises at the end. Tell them honestly that you set your rate lower than your costs, and that after you deliver the project you will need to charge $35/hr or whatever the going rate is for further work.

On a side note, while $35 sounds like a great full-time wage when freelancing you'll be lucky if you can get 8 billable hours a day. Sure, while deep in code it's easy to meet that, but there's the downtime between projects that you have to account for. Also as a freelancer you're expected to be an expert, so learning everything on the job is normally frowned upon -- you don't get paid when you take time off to learn how to use a new tool or technique.

I once heard the rule of thumb is that if you'd like to earn the same as you would working full time, but as a freelancer, that your hourly rate should at least be twice your full time wage. Depending on where you live $35 might be good, but I don't know any experienced freelance developers in North America who charge that.

YSlow's primary purpose is to help you make sure the browser renders each page in the minimum amount of time. However YSlow does not only apply to browser rendering, following 6 of the 13 YSlow rules will result in a reduction of the total work the server must perform for each request.

DataMapper is about 60% faster overall than ActiveRecord, and as much as 20x faster in a few key benchmarks at the moment: http://is.gd/3xwR

In fact we, the core DM contributors, have spent very little time optimizing the library. Up until now we've been mostly focused on creating a clean API, and keeping the internals simplified. I would expect the gap to widen much further once the API stabilizes, and the spec coverage gets nearer 100% (it was in the low 90's last I checked).