Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment Re:can you NYC people answer this for me? (Score 1) 37

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.

Comment Re:can you NYC people answer this for me? (Score 1) 37

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.

Comment Re:can you NYC people answer this for me? (Score 4, Insightful) 37

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.

Comment Re:Developers hate Agile too (Score 1) 597

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.

And yet, somehow, projects like, oh, the Linux kernel, the Apache HTTPD server, and just about every other open-source project out there seem to be able to muddle along without face-to-face communication.

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.

That's your job as project lead.

... and no need to put added pressure on any dev by suddenly making daily inquiries about their progress.

Then you explain to them why you are making such inquiries and, if they'd like them to stop, what they should do about it.

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.

Comment Re:Developers hate Agile too (Score 1) 597

If they've spent 2 days on something that should have taken a few hours, you as the project lead know there's trouble.

Then why can't people instead send a daily e-mail to you alone as the project manager. Why force everybody together and hear about stuff about which they couldn't care less?

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...

In other words, it's a way to keep people from slacking off. Surely as a project lead, you know who your good, self-motivated developers are and who your slackers (or potential slackers) are. If that's the case, then simply fire the slackers or, slightly less drastic, require daily e-mails from only the slackers and leave the better developers alone.

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.

Comment Re:Developers hate Agile too (Score 1, Interesting) 597

You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.

As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.

If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.

Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.

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.

Comment Re:Conservation of Energy (Score 1) 266

The only thing that makes it not a sailing boat is that I happened to use land to make the engineering easier to describe. We can trivially change it back into a sailing boat by saying "it's a really really wide catamaran, and the mast is attached to a travelling base.

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.

Comment Re:Conservation of Energy (Score 1) 266

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.

Comment Re:Conservation of Energy (Score 2) 266

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.

Comment Re:I'm going to assume that was hipster irony. (Score 1) 91

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.

Comment Re:I'm going to assume that was hipster irony. (Score 1) 91

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.

Slashdot Top Deals

Logic is a pretty flower that smells bad.

Working...