26 Jan 2015
Joining the Project

TOS Chapter 3

Overall this chapter conveyed the aspects of Open Source communities pretty clearly. However I noticed there is a large emphasis on wikis. In my experience the popularity and use of wikis is only present in very large projects. Smaller to semi-popular projects often forgo or have limited use of wikis. This can be especially true in python-based projects (such as Mopidy!) where the use of documentation tools such as readthedocs is fairly standard.

This is also true for planets and blogs. I’ve never encountered planets, or the terminology, and have never seen them for smaller projects. I can see their use in large projects such as Mozilla and Fedora, but for smaller projects there is usually not a huge blogging community behind them. So planets would likely be rather stagnant.

The section on IRC was a good introduction to the basics. I’m glad that they talked a bit about IRC etiquette and the importance of sometimes staying quiet and just listening (lurking).

I’ve been using IRC for several years already and am constantly on a CS channel for CofC. I’ve used a variety of clients. On Windows and Ubuntu I’ve used Hexchat a client based off of XChat. On Mac I’ve used Komanda, a beta client written with node-webkit. Lastly, on my laptop (Ubuntu) I’ve recently switched away from GUI clients to a terminal based client called Weechat.

Joining the Project

I started with IRC, since I was most familiar with it. The channel seems fairly quiet, the topic is set to “Welcome to #mopidy! Feel free to ask questions, but be prepared to hang around for an answer. Otherwise consider asking on http://discuss.mopidy.com :-)”. It’s common for community channels like this to be quiet until someone needs a question answered. They’re generally not used for chatting. One person had a Travis-ci bot posting updates and build statistics, but it was nicely requested that they take it down.

An individual also joined and asked a question. Someone answered him right away, and was promptly thanked. The exchange was very friendly, thus my first impression is that the community is kind and happy to help.

I later discovered that Mopidy posts its IRC logs, this is unusual as IRC was initially intended to be an anonymous chat client.

I’ve already followed the issue tracker on github. I’m keeping an eye on the mailing list which seems like it’s just used for announcements. The discussion forum looks like it’s used for questions, similar to IRC. Lastly I also followed their twitter.

SD 2 and 3

Chapter 2

Chapter 2 states that developers have recently adopted the practice of agile development, which is true. But not true for all developers. A lot of books have emphasized how some developers adopt one practice or another, but I believe there should be more of an emphasis on flexibility. It’s not necessary to follow only one method. I would say it’s better to take what works for you or your team from each method. Being too strict on development practices can be potentially damaging.

Design patterns can be very helpful in project development, and I think those should be followed fairly closely. They keep code organized, and it becomes much easier for people who are new to a project to follow it. I feel that there is not the required amount of emphasis on the importance of design patterns at CofC. Developing with one, even once, is immensely helpful for keeping organized development practices in the future.

Reading code is an especially important skill. The code you read in published programming textbooks is, unfortunately, not typical of the code you find in most software applications.

I agree with this 100%, which is why the lack of “real” code presence in classes is disappointing. It’s also important to be able to adapt to different coding styles and be able to pick apart what’s what. We’re taught, for the most part, the importance of documentation/commenting in code. But in the “real world” code isn’t always well commented. There’s generally documentation for higher level concepts, but each method doesn’t have a detailed description. So reading comprehension is definitely an important skill to have.

Everyone has their own coding style, so it can be difficult to adapt that style to another. This is why it’s important to follow the contribution guidelines for a project. Code can become much more difficult to read and comprehend if there’s a mishmash of styles.

Chapter 3

The beginning of this chapter is largely a re-iteration of TOS Chapter 3. It goes into a bit more detail about synchronous and asynchronous communication.

After some IDE coverage the book starts to talk about software stacks. I’m so glad this is discussed, I think it’s an often overlooked concept. LAMP and WAMP are some very popular stacks I’ve seen utilized a lot. I’m surprised that MEAN stack wasn’t mentioned though.

Version Control is mentioned, but they don’t talk about GIT at all. It’s at this point that I remembered this book is now 4 years old. It really goes to show how quickly technological trends develop.