Which is fine if the two slots for bikes aren't already taken and if you don't forget to grab your bike off the front of the bus when you get off. ;)

And of course in between the time of riding some where and getting on the bus you have keep your bike someplace. With the bike share system, that's a non issue. You slide it into a stall at the station and then you're done with it.

Though this doesn't always apply, I got a coupon book with my subscription that I had a bunch of coupons I could actually use. I got my first subscription cheap because I signed up at the end of the season. Since a lot of the coupons were set to expire, they gave me another book at the start of the next season. The net cost for me was less than $0 when all was said and done.

I don't live in NYC but we do have a bike share system in Minneapolis. I ride my own bike every day to work and felt much the same way as you did but I've since realized there are some significant advantages to using a bike share system.

The biggest for me is that I can get around town without having to lock up my own bike somewhere and risk getting it stolen or damaged.

Another is cost. An annual subscription to the bike share system is $60 or so but if you're savvy you can get them for $45 or less. My subscription this year cost me $20. That's far less than what an annual bike tuneup would cost IF you don't need any parts.

Then there is the space saving thing you alluded to. Though you may be fine with a bike taking up space on a wall in your apartment, not everyone is. Depending on what floor you live on, getting the bike into your apartment may not be at all convenient even if you have the space. And while yes, you could lock it up outside, again it is at greater risk of getting stolen or damaged.

Open source projects are a different beast that don't operate under the same constraints that a commercial project does. You lose some efficiencies in terms of communication but for projects like the Linux kernel or Apache you have potentially an unlimited pool of developers and much more flexibility as to what gets delivered when. It should also be pointed out that for every open source success story like Apache or Linux there's lots of stuff that dies on the vine or never gets off the ground.

Look, it's clear that you're not happy with an Agile approach and some people just don't work well in that environment. It seems to me though that people who only give a crap about their part of the project and resist any face to face communication in favor of email are limited in the sorts of projects they can work on successfully.

Agile places a high value communication, especially face to face communication. You can pick up things face to face that you can't in an email. Besides projects are supposed to be a team effort and as a member of the team you should care what other people are doing and what issues they may be running into. You may be able to help or learn from them. That won't happen if all you're doing is staying holed up in your cube sending a daily status email.

As a project lead I'm not just concerned about keeping the slackers honest. Sometimes very dedicated, very good, but also very prideful developers can be reluctant to volunteer that they're struggling with something. Sometimes the road blocks aren't technical but political. If the meetings are regular, then there's no need to single anybody out (which can have bad consequences) and no need to put added pressure on any dev by suddenly making daily inquiries about their progress.

I should also stress that in my view, agile works best in fairly small teams. I'd never have a standup meeting with 15 or 20 people. It's going to be detrimental rather than helpful if they are anything but brief.

As a project lead I found a lot of value in stand up meetings. Not all devs like them, that is for sure. The thing to remember though is just because an individual developer may find little value in it for them personally, that doesn't mean it doesn't have value for the success of the project as a whole.

If you encounter a road block at 2:00 by all means, try to resolve it, but the truth is not all developers will and often they don't have to, it can wait and they move on to something else. Then there are developers who will naturally put things off anyway (sometimes too long) or will bang away at a problem forever when they could simply ask someone else. The beauty of the stand up meeting is that problems are quickly identified even if the dev doesn't specifically mention them. If they've spent 2 days on something that should have taken a few hours, you as the project lead know there's trouble.

Just the fact that a developer on a daily basis has to stand up in front of their peers identify what they did and what they are currently working on helps them stay on task and helps you as the project lead nip problems in the bud. It also keeps everyone involved informed as to who is doing what and the current state of things as a whole. All by holding one short meeting. And if you're really doing agile, the developers are located in the same area and assembling them shouldn't take anytime at all.

Other than a startup, I think it's rare for any innovation to come from the executives.

Even if you could build such a thing that would actually strong enough and flexible enough to deal with all the forces involved while still being able to float and steer, it would no longer be fast enough to accomplish the goal. Imagine what it would take just to have a mast mounted to a moveable base which would have to have a keel whose angle could be set independently of the direction of the boat.

What you're describing is not a sailboat, and I think you'd have some serious engineering problems to tackle in order to make a working example. ;-)

I'd argue that you can't call it a sailboat unless it uses sails. ;-)

I still think the blackbird is unique because it's not using a wind turbine to drive the wheels. It's using the wheels to spin the propeller, - which spin the wheels.

This machine can head straight downwind and exceed the speed of the wind itself. A sailboat can't do that unless it's using some method other than a sail for propulsion.

A sailboat can reach a point downwind faster than the wind speed by traveling at angles to the wind but that is different.The blackbird is doing something else.

Sailboats only go faster than the wind on a reach, not directly downwind. Eventually the apparent wind goes down to zero so there's no more (forward pushing) force acting on the sail. When sailing across the wind on a reach, the force on the sail remains even as the boat accelerates.

That's what makes this thing unique, it can go downwind faster than the wind itself is going.

We use jQuery because it allows us to deliver what our users want in a significantly shorter period of time. Not only they get it sooner, it costs the company less and we can focus on doing things that jQuery doesn't do. Especially in our case since we have a limited set of hardware and browsers to support. Wringing the most speed out of a site that we possibly can isn't necessary.

And just because you're using jQuery for some stuff doesn't mean you have to forget how to write native javascript or use css for those things that make the most sense to use it for.

Then you don't know enough people using jQuery. Just because I'm quite capable of writing straight javascript or creating my own library doesn't mean that jQuery doesn't have benefits for programmers. Smart programmers don't reinvent the wheel just because they can.

We use jQuery for actual in house web applications rather than a site that gets infrequent visits from random users. The difference being that we can use an application cache to store things like a minified version jQuery library on the client so it doesn't need to be downloaded every time you visit the site.

The website seems to work fine on my smartphone which is almost 3 years old.