DevFi

Hey, look, another episode!

This time around I’m talking smack about comments. To go with this episode, take a look at this article by Mark Easterbrook.

During the podcast I give a few tips for writing better in-line comments. The most common reason used to justify in-line comments is to document complex code. Here are some tips for writing better code, so it doesn’t need comments:

• Ask a coworker or a friend for help
• Use Google Code Search to find similar implementations
• Write out the algorithm using pseudo-code
• Write a test as a way to become a user of your code
• Talk it out with a non-technical person

I also talk about block-level comments, those are the comments you put before a function for API documentation. Here are some tips to keep them in good shape:

• Don’t write them if you don’t have to (e.g. private methods)
• Don’t go into unnecessary detail
• Try to make them invariable
• After changing code, read the comments and make sure they match

Files for this show:

• AAC
• MP3

Feedback:

Please leave a comment, or send us an email. Motivate us to do more shows!

So, this time, Chris is the slacker. But here’s the newest episode just a week late. Chris puts forth the importance of reading other people’s code, and has suggestions of where to start if you don’t know where to go.

Next week, Peter will release his episode on time… Probably.

Please post any comments or suggestions right here on this blog.

Files:

• AAC
• MP3

Peter gets to rant all by himself, while Chris has to listen just like everyone else. This time Peter talks about software maintenance and refactoring, maintaing source code style, and adding features without just bolting them on.

Please post any comments or suggests as a blog comment, or email Peter directly.

Files:

• AAC
• MP3

This week’s podcast is a little tour through the mind of someone, me, writing scripts to handle a certain part of my workday. I’m a pretty lazy guy, so if something can do some work for me, I’m all for it.

This is also the debut of the new DevFi podcast format: a shorter, solo show, with the next one to follow closely.

More tips and encouragement on automating your work can be found in two Pragmatic Programmer titles: The Pragmatic Programmer and My Job Went To India.

Star Wars was way better than the prequels, and I think Peter and I are in a similar situation. We’ve arrived at Episode IV, A New Hope... I mean Being Agile in a Waterfall. We haven’t quite got our sound issues totally out of the way, but I wouldn’t be surprised if we get that all figured out next time.

Until then, enjoy us giving a brief rundown of various development methodologies, and then how to sneak in Agile practices into a non-Agile team. We give some pointers on estimating, especially on getting better at it, and getting your team to incorporate some agile practices into their workflow.

Peter recently wrote about his project planning process, which I recommend if you’d like to see how someone with OCD does it.

Thanks for listening. Leave comments or suggestions below. And get ready for the next episode: The Empire Strikes Back...err, Project Management for Developers.

Files

• AAC
• MP3

Now that Peter and I got our remote recording situation settled, we can get back into the business of producing episodes. And, hopefully not too late, here’s number three. This episode’s about letting people know about your software project and getting them involved.

We hit on a few things, from mailing lists to twitter to helping developers create patches.

If you’re as excited about git as we are, and you’re looking for somewhere to host your project’s repository, you’ll want to check these sites out:

• repo.or.cz
• Github
• Gitorious

Questions? Comments? Manifestos?

Links for direct download:

• AAC
• MP3

As you’d expect, Chris has been a PITA. He took a vacation, and when he returned he took a new job. We have the content for the next episode, but Chris and I need to figure out how to get together to record the show.

Rest assured, the next episode is coming, it’s just a tad bit delayed.

In the meantime, if you have any show ideas, encouraging words, or more likely, criticisms, please post a comment.

Oh, if you get the chance, sign Chris up for a few mailing lists, he loves spam.

In our sophomore effort we talk about some of the considerations needed when releasing a project under an open source license. We briefly discuss license choice, hosting your project, and why you might do so at all. We also touch on the expectations that users have once you’ve released your code, when to release, and how to let people know that you did.

In the show, we promise an interview with Ara Howard. When we actually get his answers, we’ll post them here.

If you’re looking for a comparison of licenses, check some of these links:

• Licenses at opensource.org
• Steven Fishman’s overview
• A simple chart by Zack Rusin

We’ll go back to both using one good microphone next time, when we talk about version control options and encouraging participation in your open source project.

---

Downloads:

• Audio – M4A
• Audio – MP3

In our inaugural podcast, we discuss reinventing the wheel vs. buying a wheel vs. customizing an open-source wheel. When is one a better choice over the others? We tackle that and more.

We also have an interview with Dan Berger, long-time Ruby developer, who recently forked the Ruby interpreter, creating the Sapphire programming language. His full answers are below:

---

Is Sapphire good or bad for the Ruby community?

It’s good for the Ruby community the same way that Perl or Python or any other language is good for the Ruby community. Many languages have ideas that language designers can (and do) borrow. If the features I add to Sapphire prove to be useful and popular, there’s at least a chance that those features will be merged back into Ruby.

Do you see Sapphire as a long-term commitment, and if so, will it be a side- or full-time project?

It’s definitely a long term commitment, and one that I’ve put off for a long time precisely because I know how much work will be involved. For now it’s a part time project, because I have a full time job, and that limits how much time I can put into it. I’d love to work on it full time, though.

What specific changes have made [will make] Sapphire more Windows-friendly than Ruby?

Several core classes will be refactored, either to take advantage of native system calls or to fix incorrect behavior. This primarily affects the Kernel, IO, File, File::Stat and Process core classes. For example, IO.readlines will use scattered IO for improved performance on large files. File.basename and File.dirname will be fixed to work properly with UNC and root path names. Several methods in File::Stat that don’t work or aren’t supported will be made to work including, shockingly, the fact that File.size breaks on file sizes over 2gb on Windows. The Process.kill method will be improved to use a less brutal termination method. The list goes on.

The standard library will see improvements by replacing Unix-only libraries with cross platform solutions or by refactoring existing libraries to become cross platform. For example, the etc library has been replaced by sys-admin, the dbm/gdbm/sdbm group of libraries will be replaced with kirbybase, and open3 will be made cross platform.

What sort of projects/developers would benefit switching to Sapphire from Ruby?

The sort that would like to have features integrated into the core language that Matz hasn’t expressed any interest in. I think Ruby is already falling behind languages like Python or Scala. Those languages, and others, have useful features that could be integrated into Ruby.

I also suspect that Sapphire will appeal to developers who are unhappy with the way Ruby is being managed and some of the features that are being shoveled into the 1.8.x branch.

Are any of your concerns about Ruby being addressed by the 1.9 effort? Or Rubinius? Or JRuby?

When it comes to MRI, other than Unicode support, not really. The primary issues are management and evolution.

There is still no real test suite in MRI. The Rubinius/JRuby spec, while a vast improvement, is still an afterthought among the core Ruby team. Plus, the spec itself is a moving target, especially with some of the major changes that 1.8.7 just incorporated. Mostly it’s still a case of Matz using the end users as beta testers. There’s no attention to compiler warnings, which can be significant, and virtually no effort goes into refactoring. That trend isn’t going to magically stop with 1.9/2.0. The upshot is that the end users are left to find the bugs, usually the hard way.

There’s also the issue of dealing with bug reports and patches in a timely way. They’re often ignored for months or even years at a time. The same thing has happened with patches. Eric Mahurin’s array.c patch was the most notable example, which some people may remember from the Zed Shaw rant.

When it comes to evolution Matz is moving Ruby in the wrong direction in my opinion. I see a lot of obsession over proc/block/lambda notation and semantics and a bunch of marginal methods being shoveled into the core language. Instead, I’d love to see some of the evolutionary changes that languages like Scala, Python 3000 and Fortress have implemented, along with some other fundamental changes, but Matz doesn’t seem interested. We’ve seen two iterations of the RCRchive fail because Matz ultimately demanded too much of the proposers and eventually lost interest. When he lost interest, so did the community.

JRuby and Rubinius (and any other implementatinos out there) necessarily cannot address my issues either, since they are more or less bound by whatever Matz does with Ruby. That’s a terrible shame really, because I think both the JRuby and Rubinius core members could incorporate some fantastic ideas into the language, such as type inferencing (as Charles O. Nutter did with Duby) or Behaviors from the old Sydney project. But, unless Matz gives the thumbs up, they’ll have to be side projects. That puts them in a serious dilemma.

If Ruby core were to ask to merge your changes into MRI, would you be willing and would you give up Sapphire?

No. It would never happen anyway because my changes require as much ripping out as they do adding in. Furthermore, we have seriously differing opinions about where the language should go and how it should be managed as I discussed previously.

---

We’d like to thank Dan for taking the time to answer our questions, and for open source in general for making project forking a possibility.

Join us next week when we talk about releasing an open source project and all it entails.

---

Downloads:

• Audio – M4A
• Audio – MP3

No matter how you say Hello World:

printf("Hello, World!\n");
std::cout << "Hello World!" << std::endl;
print "Hello World!\n" 
puts "Hello World!" 
write("Hello, world!\n")
echo "Hello World!" 
putStrLn "Hello World!" 
io:format("Hello World! ~n").
alert("Hello World!");
(message "Hello World!")

We’ll have something interesting for you on the DevFi podcast.

Chris and I are working on the first episode, with a planned release date of May 5th.

Our first topic is going to be on using existing software vs. writing your own. We’re also going to touch on forking open source projects, and close with an interview with Dan Berger, a long time Ruby contributor who recently forked the language.