Steven R. Baker - Latest Comments

Re: Do Your Damned Job

synapticmishap — Sun, 20 Jan 2013 16:14:04 -0000

Yup, totally agree. As Uncle Bob says "QA should find nothing".

Re: A Folder Full of Middles

Steven R. Baker — Wed, 28 Mar 2012 23:14:10 -0000

Ah, thanks. I couldn't remember the {} special characters. I originally tried with xargs, but it complained about some quoting, and so I just ghettoed it.

Re: A Folder Full of Middles

daniel — Wed, 28 Mar 2012 22:58:58 -0000

find . -type f -exec cat {} \; | wc -w

Re: Optimizing Stand Up

Jonan Scheffler — Wed, 04 Jan 2012 14:10:18 -0000

Great article. I second Avdi on the Google+ Hangouts option; we use one everyday with our remote team and I am always impressed by the audio/video quality.

Re: Optimizing Stand Up

SteveB — Tue, 03 Jan 2012 17:38:59 -0000

agree! lots of standups denigrate into a meaningless chatter of people coming up with random stuff to defend their value to the company. I content that you should answer what you're working on & connect to a story in your agile planning tool. And if you need help, ask for it.

I do find it interesting the differences in what motivates the in-office team and remote workers. It's important for remoters to have some respect for those that arent as lucky to be at home, w/ their kids, in their underwear, working. if it's a "nana-nana" look at me...you wont win over the in-office folks.

Re: Optimizing Stand Up

Avdi Grimm — Tue, 03 Jan 2012 13:25:26 -0000

Good stuff. Just a quick note: I frickin' love Google+ Hangouts for remote standups. I participate in at least one G+ standup every workday.

Re: Optimizing Stand Up

jwo — Tue, 03 Jan 2012 12:17:54 -0000

Enjoyed the post -- stand ups can indeed be awful ... Experimented with google hangouts for standups with decent success. Technically, it worked well, but didn't win over the in-office-team. For remote-only teams, I highly recommend.

Re: Isolating Rails 3

Steven R. Baker — Wed, 05 Oct 2011 17:35:06 -0000

Graham! It would have been October/November of 2004, if I remember correctly.

Bundler has been a complete pain, and it was left to its current maintainers in an awful state. They're doing the best they can, but they have a lot of compatibility concerns to deal with.

Personally, I use Isolate, but I recommend you fixing your Bundler problem and sticking with it for the time being. The documentation, the community, and Rails itself depend pretty heavily on it. Of course, I'm happy to help you with it if you drop me an email.

Great to hear from you!

Re: Isolating Rails 3

Graham — Tue, 04 Oct 2011 14:40:29 -0000

Ironic that Bundler failed me, so when I went looking for a fix, I found an article by Steven about Bundler fails. That's the same Steven who had recommended Rails to me 8-9 years ago, but I was focused elsewhere and didn't have the time. Now I have the time, but am stuck with Bundler fails ... . Will this Bundler fail be my learning cliff??? Can a newbie figure out Isolate???

Re: From Bundler to Open and Inclusive Software Communities

Mark Wilden — Sun, 11 Sep 2011 02:23:43 -0000

Steven, your post did not make it sound like the patch would've been rejected. You said "I don’t want to write it if you’re just going to throw it away later". The operative word (as far as my comment is concerned) being "later".

As for who was reinventing the wheel, I accept your statement that Isolate is older than Bundler. I can't help but feel, though, that the project turned out to be aptly named. Regardless of your project's priority - regardless of its superiority - the fact is that Bundler is the market leader. You can go your own way, or you can suck it up and stay with the mainstream. Pluses and minuses on both sides.

Another way to look at it is this: Why do you suppose Bundler has been a success, in spite of the deficiencies in its authors that you note?

Re: From Bundler to Open and Inclusive Software Communities

Steven R. Baker — Sun, 11 Sep 2011 02:09:14 -0000

Mark, I was told that my patches would be rejected; why would I waste my time? And I did not reinvent the wheel; I switched to a project which was older than Bundler itself. If anything, Bundler was re-inventing the wheel (which is pretty typical of its authors.)

Re: From Bundler to Open and Inclusive Software Communities

Mark Wilden — Sun, 04 Sep 2011 01:28:46 -0000

I can sympathize with your experience. However, I do think there's an important lesson here:

Don't be "generous". Write code because it fulfills a need you have. Don't worry if it will be "thrown away" later. If it's good, then it won't be thrown away. But even if it is, you would've saved time just by patching Bundler and contributing your patch back to the community than reinventing the wheel.

I think some decisions were made here based on personal irritation rather than logic.

Re: From Bundler to Open and Inclusive Software Communities

Alex Sharp — Mon, 08 Nov 2010 11:16:50 -0000

I suppose it's a bit late to comment on this post, but what the hell ;) We experienced very similar issues with bundler, though not specifically the build options issue. My beef with bundler was two-fold, and in the following order. First, release management was, to put it lightly, a complete and utter joke. Somewhere in the 0.8 branch, it was highly encouraged by one of the bundler developers that we all start upgrading our apps to use bundler, so we could be ready for Rails 3, or something. In my opinion, bundler 0.8.x seemed somewhat stable, and worked pretty well for our purposes.

Then started the tinkering. And the breaking. And the crazy backwards incompatible API changes. And the inability to have different versions of bundler on the same *system*. What!? Oh, it's fine, it's a rubygems bug. The solution was always something to effect of, oh you should upgrade to the latest version. Or, oh, that's fixed in master. Or, just use rvm.

Admittedly, I like bundler 1.0, a lot. It's stable. Finally. But the road to 1.0 was, well, painful to say the least. And not, "life on the bleeding edge" painful, this was more, "we promise, it's stable (except we're going to make major changes that will break everything)" painful.

And secondly, I always got the "this is a *very hard problem* and therefore only the bundler core team is qualified to work on it" vibe. Give me a break.

Don't get me wrong. I like bundler. I like the guys on the core team. I think they've improved immensely since you wrote this post on all the things that I've bitched about in this comment. But I think it was a very hard lesson learned for the ruby community. Hopefully we can avoid this type of thing in the future.

Re: From Bundler to Open and Inclusive Software Communities

railsjedi — Fri, 16 Apr 2010 16:32:47 -0000

I don't think it makes sense to always force people to write patches beforehand if you get prior confirmation from the core team that they are not going to merge it. Time is valuable, and if you know something has a slight chance of getting merged, its often completely wasted effort.

Before writing patches for something that needs to be a shared community asset like Bundler (I deploy to heroku), I do believe its better to bounce ideas of the core team, and only code something if they agree with the approach. Even with github, maintaining a separate fork of a project is still a huge duplication of work.

Re: From Bundler to Open and Inclusive Software Communities

railsjedi — Fri, 16 Apr 2010 16:28:53 -0000

I know exactly how you feel based on experiences on some other open source projects. All I can say is the Bundler team (indirect, wycats, carl lerche) has been super helpful with my direct experiences with them. I don't think they were trying to antagonize, but if it seemed that way, please give them another chance. They'll help make things right with this issue.

Re: From Bundler to Open and Inclusive Software Communities

Zach Moazeni — Fri, 16 Apr 2010 13:18:33 -0000

Hey Steven,

One thing that strikes me is that you said you had two opportunities to write patches but didn't.

I'm not in favor of wasting time, but as an outsider to the conflict, I would think that having concrete code would make the conversation a lot easier.

I've only talked with Pat at Goldstar briefly, and I haven't met the Bundler guys, but reading these posts/articles/tweets back-and-forth feels like more a battle of egos than a cooperative effort to solve the problem(s) at hand.

Can't you guys hug it out? :)

Re: From Bundler to Open and Inclusive Software Communities

Guest — Fri, 16 Apr 2010 12:25:30 -0000

That does sound frustrating.

Thanks for sharing and sharing isolate. Can't wait to check it out.

Re: From Bundler to Open and Inclusive Software Communities

Steven R. Baker — Fri, 16 Apr 2010 12:11:12 -0000

Our app worked with 0.8, but as I stated, there was a bug that prevented us from upgrading gem versions, which we found ourselves doing two or three times in a row.

Re: From Bundler to Open and Inclusive Software Communities

Steven R. Baker — Fri, 16 Apr 2010 12:10:25 -0000

The conversation was paraphrased, but was pretty accurate. I believe the exact quotation was "You can't do it." (I do have the logs, and I was referencing them when I wrote that, but there's a lot of private stuff that would need to be stripped for me to post them.)

Re: From Bundler to Open and Inclusive Software Communities

geetarista — Fri, 16 Apr 2010 12:00:01 -0000

If your app worked with 0.8, why didn't you just leave it alone when it didn't work with 0.9?

Re: From Bundler to Open and Inclusive Software Communities

joegrossberg — Fri, 16 Apr 2010 11:47:02 -0000

Yeah, I assume you're paraphrasing, but given the use of quotation marks, you might want to explicitly say so.

Would also be interesting to hear Developer's version of the conversations.

Regardless, it does sound like a really frustrating experience. :/

Re: From Bundler to Open and Inclusive Software Communities

Guest — Fri, 16 Apr 2010 11:31:12 -0000

Did they really say "You’re not smart enough", or is that dialog a summary of how you felt after the conversation?

Re: Do Your Damned Job

Liz Keogh — Sat, 09 Jan 2010 05:40:33 -0000

I'd go further. I prefer developers to get the browser up and click on it anyway, even with full acceptance tests. There's a difference between "working", "usable" and "intuitive", and bringing the browser up - even for small typos - can show us other things we missed, as well as getting the domain ingrained in our brains.

Re: Do Your Damned Job

terry_brown_uk — Sat, 09 Jan 2010 05:37:58 -0000

Utterly agree with this, and with the comments from kbaribeau. Quality is everyones job, at every step of the process. Any developer who delivers code that they aren't 100% confident has been personally tested (using whatever means are appropriate) isn't a software developer I ever want to work with.

Brilliant post Steven.

Re: Do Your Damned Job

kbaribeau — Mon, 16 Nov 2009 18:40:33 -0000

Quality is *everyone's* job. The best QAs can write code, and the best developers can test (although there is still a lot of value in specialization; the best QAs are better testers than the best developers and vice versa).

I think though we should be steering our teams in a direction where everyone collaborates frequently. When done well, roles start to blur. QAs pair with developer's frequently enough that we forget who's who.