I love CruiseControl.rb, but one of the things I’ve found is that it exposes via the web interface a lot of what is potentially confidential data. From the cruise_config.rb containing accounts on our SVN server, to being able to browse source files, which would include database.yml, again, exposing usernames and passwords.
(more…)
One of the things we take pride in here at OpenSource Connections is what we like to call the OpenApproach. The OpenApproach is our implementation of best practices for software development and project management, and is largely based on the concepts of Agile and Scrum. In addition to providing development services to our clients, we often coach our clients on OpenApproach techniques so that they can improve their own development environment and learn from our success on other projects.
Most recently, I participated in a Scrum team on our own internal software development project: AeroWebOnline.com. This was a very time sensitive project with various OSC developers going in and out of the project, geared towards a product launch at the AAAE conference in New Orleans. That project was a definite success, although one Scrum lesson we re-learned was that 1 week sprints really are too short, and 2-4 week sprints are much more effective. As both a developer and a project manager, I really find Scrum rewarding because it keeps me aware of what’s going on in the project as a whole, as well as very focused on my own development tasks.
Currently I’m with a new client of OSC, and we’re on another time sensitive project with up to 8 developers (though most also have other project obligations), an architect, a project manager, a business lead, and 2 QA/build staff. It’s a big project with a tight deadline and for several reasons I felt Scrum was the perfect approach for this project:
1) The team needs to have improved communication and a real time sense of how the project is going and what everyone is doing on it, without introducing a heavy process.
2) The business needs strong insight into the project, because the deadline is very important to them. If the timeline doesn’t go well because developers are on too many other projects, they need to be able to see that effect directly.
3) Developers need to be encouraged to trade tasks and to cross train, because since many of them will be called on for other projects or production support, it’s essential that the project not be too dependent on any one developer.
So I pitched the idea of Scrum to the team leadership, and we’re going forward with it. I’ll record here some of our experiences so far, how Scrum is helping us, what we can improve on, and the team’s reaction to a different process.
We have essentially a one month timeline for the project, so we decided to split it into two sprints of two weeks each. Last Friday we had our planning meeting for Sprint 1. Since this was the first introduction of Scrum to the whole team, I started by giving a talk about Scrum and showing examples of past burndown charts and task lists in other OSC projects, and talking about the responsibilities of each Scrum role (developer, scrummaster, and product owner). I used this “Scrum in 5 minutes” document as a set of talking points for the presentation. But no, it didn’t take me 5 minutes. It actually took about an hour of me talking and the team asking questions.
But after that, we went right into planning for Sprint 1. I setup the sprint planning spreadsheet in Google Docs as we do with most of our OSC projects, and I served as Scrummaster in the planning meeting. However, my goal is not to be the Scrummaster myself, but to train the client’s project manager on how to be a Scrummaster so that they can continue this process on other projects. So while I served as the Scrummaster for the first planning meeting, she is now leading the daily stand ups, and I expect she will lead the planning on the next sprint with my guidance.
The architect for the project had already prepared his own set of goals for the sprint, and so we used those as a starting point with the team, which the rest of the development staff added to. The team as a whole came up with their own list of sprint tasks for those goals, which took us another hour and a half probably. There was of course much discussion about the tasks, but it was my job to make sure that discussion did not go into “implementation details” so that we did not get into too technical or indepth of a discussion. That was a real challenge, but for the most part we did it.
After all the tasks had been laid out, we moved into task estimation. To do this, Eric Pugh strongly suggested that we try Scrum poker. I was a little skeptical how well that part might work, but I was really pleased with the results. We didn’t have time to order the official Scrum poker cards from Sweden, so I cut a stack of index cards in half and everybody got cards with these values on them:
?,2,3,5,8,13,16,20+,donut.
Some of the developers also had fun adding their own cards to the mix. Chris added a pizza card when it got close to lunchtime.
So how does it work? As the Scrummaster, I would read the next task off the list, and ask everyone to pick a card from their deck. When everybody had set a card face-down on the table, I would say “flip” and then I would read off the estimates given around the table. The 20+ card was used to indicate you think the task will take longer than 2 days and it probably should be subdivided into other tasks. The donut card was used to say “my brain hurts, pass the donuts.” And the question mark card was used to indicate you didn’t know enough about the task to make a reasonable guess.
Those who gave the lowest and highest estimates would be asked to make a quick case as to why they made that estimate. Sometimes those defenses would lead one or the other to realize they had made an incorrect assumption about the task, and the team would quickly be able to agree on a reasonable estimate. Other times, it brought out important points about the task that we then used to make a better estimate with.
Scrum poker addresses a real problem in task estimation, and I was really pleased with the results. Normally, if you have a group of developers and ask them how long it will take to do a task, someone will speak up first and throw out a number. No matter whether that estimate is really high or low, the fact is that most other developers are now going to give estimates somewhat similar. Even if they would have guessed a much higher estimate, they will now downgrade theirs because they don’t want to sound like a slacker compared to the initial low estimate.
I think that would have definitely happened with this team, because I observed that the developer who was probably the most confident in his estimates was also the most optimistic in his estimates. Without Scrum poker, I think we would have had a much lower set of estimates and we would be less likely to hit them.
Estimating the tasks took about 2 and ½ hours, and was the longest part of the process, though I think the end result was good.
The final thing we did was to assign the tasks. In Scrum, the best way to do this is to go “round robin” around the room and each developer picks one task at a time, until no tasks are left.
However, we had been meeting for a long time at this point and people were fading. The project manager asked if we could just print out the task list and pass it around our desks to assign the tasks. I acquiesced, but in retrospect I should not have given in. At that point, I essentially lost control to enforce the process, and instead of people signing up for one task at a time as they were supposed to, developers signed up for multiple at once.
The end result of this Scrum “faux pas” was that developers stayed in their comfort zones too much, and that there is not enough cross-training among members in my opinion. The architect took all the tasks around a rules engine, and a senior developer took most of the tasks regarding how the workflow would be implemented.
This was a definite downside of the process in my evaluation, and one that could have been avoided had I not allowed meeting fatigue to get the best of us. However, I think this will fix itself to some degree because some of these tasks will have to be traded around over the course of the sprint in order for everything to be done. It’s nearly a week into the sprint and that is exactly what’s happening.
All in all though, introduction of Scrum into this team has gone very well so far. The developers have responded well despite the fact that I introduced Scrum to them in something of a top down fashion (Ideally a movement to adopt Scrum would start with the developers, not with management, although I felt in this particular case it was critical that I get buy-in from the management of the team first). The project manager seems to really like the process, and commented to me that “this lets me manage projects the way I want to anyways.” And the business seems excited about it because they get to keep their finger on the pulse of the project without being too intrusive on the developers.
Two days ago one of the senior managers in the company came up to me and was talking positively about Scrum and what we are doing on this team. Although he had not been in our Scrum meetings, word about the process is getting around the company.
Finally, since we’re nearly halfway through the first week of sprint 1, I’ll show the burndown chart as it stands right now. You can see that the first few days very little apparent progress was being made. This did not surprise me, because at this point all the team’s developers except one are still being assigned small tasks or even large tasks on other projects, and so they keep having to divert attention away from this project. Just in the last day that is starting to change and more work is getting done, so now we are starting to see a steeper drop in the burndown chart. I think having that chart is helping to communicate the effects of side projects and reinforce the deadline of this sprint.
Ultimate success of a process is determined primarily by the end result of a project, and so it will continue to be interesting to see how this sprint and subsequent sprints will go. But so far, Scrum is working quite well!
For an agile web developer two frameworks are available for quick and easy deployment of a new website: Ruby on Rails for the Ruby fans and Django for the Python fans. These two tools should provide the same functionality and as someone who’s been working on two projects for the last month, each using one the frameworks, I have had the experience of starting from scratch on both of them and trying to learn both in parallel (or at least one right after the other without acquiring more experience in one and becoming biased for one over the other). 
So what has this experience taught me?
Deployment
It is very easy to start an application using both Rails or Django:
rails myapp vs. django-admin.py startproject mysite
even though one is wordier than the other it is pretty simple to start the project with all the directories and files needed automatically generated.
Starting the Server
This task is as simple as the previous one:
ruby script/server vs. python manage.py runserver
in both cases there is a call to the language in use, then passing a command. In Rails’ case the command is an executable found in the “script” directory whereas in Django’s case the command is an argument passed to the Python manager.
Configuration
Both frameworks provide a place to configure the application. Rails provide an entire directory to configure the database setup and the Rails environment whereas Django provides a settings.py file where all the configurations can be present but also provides the option of having a config directory for multiple personalized configurations.
Updating the Database
Yet another simple task:
rake db:migrate vs. python manage.py syncdb
In this case we notice that with Rails the call is actually to “rake” whereas for Django it is still consistent with the previous format. But we’ll see that Rails is also consistent where “rake” is called for everything relating to the database.
Creating Models
Where some of the differences begin:
With Rails you create one application that can have multiple controllers, models and models and link to each other using ruby script/generate * (where the * differs depending on what needs to be generated).
Whereas in Django you create multiple applications which each has its own models and views using python manage.py startapp myapp
Documentation
It seems that Rails is more widely used which results in more available resources online for documentation and help. None the less, the Django documentation site is very extended and provides sufficient help.
The Dirt
In the case of Rails I started the project from scratch by first following with the example in the book Agile Web Development with Rails, Third Edition and then applying what I learned to the project I was working on. Whereas in the case of the Django project, I was put on it late in the development process and tried to learn the language and at the same time understand what was already done on the project. My experience with both has been limited and what I have found is that the Rails magic seems to be the difference maker for most people. The majority are not comfortable with that “unknown” but I have seen some magic done with other languages like Java, although it is not the same type but in either case there is something in the background that is doing some sort of work for the programmer. And I have become comfortable with such a setting and because I have seen a bit of how programming languages interpreters work I understand and appreciate the Rails magic.
Even though I was more productive using Rails than I was using Django, which may have influenced my opinion about them, I am still willing to give Django a chance. Both are great tools for developing web applications in an agile manner. My recommendation though, if I have to make one, will go for Ruby on Rails, just because I was more comfortable with it.
This Thursday, July 17th 2008, the Charlottesville .NET User Group will meet from 6:30-8:30PM. Kevin Hazzard will present “Accessing Web Services from Silverlight 2 Beta 2″. The meeting will be held at the SNL Galactic Headquarters: 1 SNL Plaza, Charlottesville, VA 22902 (map).
We’ve been using RimuHosting.com’s VPS servers for a couple of small prototype style RoR applications that don’t warrent the “full” treatment of their own dedicated servers in a clustered, redundent, scalable, etc environment. An example is my side project learning about the Semantic Web and Microformats: HighTechCville.
One of the parts that I really like about RimuHosting is there very complete use of the Webmin administrative console. The more I work with it, the more I like it. While the GUI isn’t anything incredible, it is very serviceable. And you can pretty much do most SysAd tasks from it, from installing packages, which really surprised me, to setting up log file rotation.
So here, in no specific order are some tips for folks doing a fairly plain jane RoR deployment on a RimuHosting VPS:
/opt/apps/hightechcville/shared/log/mongrel.800*.log. By gzipping them you get much smaller files, and they will be pruned after 4 rotations. I did have an issue with BackgroundRB not being happy with the log file being moved under it, however I get so little output from that that when BackgroundRB restarts it resets the file.wget localhost:3000/recurring_job/run call! Sure, your mongrel will block, but if you have a cluster, who cares. You can also schedule this via a HTTP Remote Process check 
local_recipient_maps setting to get email to be sent out, otherwise you get a 550 server error. Just go to Servers -> Postfix and choose edit config files. You want to edit the main.cf and set local_recipient_maps= so it is blank.
Got your own tips for easily setting up a reliable RoR app on a VPS, please let me know in the comments!
I recently was tasked with creating a Firefox add-on or extension for a client and here are some of the things I wish I had known before I began. XML User Interface Language (XUL) pronounced “zool” is the programming language created by Mozilla used to create Firefox extensions and cross platform applications. It is a language similar to DHTML allowing someone with DHTML experience to quickly learn XUL. So far my experience with XUL has been a pleasant one. Please support the XUL community and leave comments with your experience with XUL.
Tips for development
XUL files can be opened in Firefox making it much easier to quickly view the changes you make to your code. Use the Error Console in Firefox to view error messages your XUL code may produce which can be found under the Firefox Tools menu. The Extension Developer has a nice “reload all chrome” option, but it closes all the web sites you currently have open and crashed Firefox on my computer if I had Gmail open.
XUL tools
Spket IDE is the best IDE for editing XUL I was able to find and is based on the Eclipse IDE.
Extension Developer is a Firefox add-on for building extensions.
Firebug is an awesome Firefox add-on for debugging web pages.
XUL Explorer is a nice little application to help you get started with XUL development
Resources
Mozilla Developer Center is the official web site for XUL with documentation.
Born Geek contains several great tutorials.
XUL Periodic Table has a nice web page containing most of the user interface components with source code.
XUL Planet is the unofficial web site for XUL with documentation.
PHP was one of the first languages that I learned when web design was my primary focus as a career. It seemed to be simple with plenty of examples on how to use it as well as plenty of code to grab to use on the fly in order to get the job done so that I could concentrate on what I loved the most, doing design. However along the way, I somehow got sucked into the programmer paradigm and ended up being a professional code monkey.
As such, my exposure to quite a few other languages, features, and coding paradigms have drastically increased as I’m a sucker for new technology and things of the geekified nature minus star trek, dungeons & dragons, and obsessions with super models. Now PHP seems to be more of a thorn in my side as a programmer than anything. Since I do have working knowledge of the language, especially its Object Oriented Features, magic methods, its various editors, extensions, and its limitations and quirks, I tend to get drawn into PHP projects. Working on a PHP project makes me long for a good rails or asp.net project because PHP just makes me feel dirty as a programmer.
PHP has gone the way of PERL: somewhat usable, a few good features and scripts, but stagnating with its ability to push the language itself to compete with other modern languages.
So what makes PHP so bad to work with? (more…)
Recently, I completed my first Ruby on Rails application, which you can see here. It’s not a complex application, basically it’s a survey of political candidates with three data models: candidate, question, and answer. Pretty straightforward.
I built the Ruby app using Scaffolding, which was very easy and I liked alot. Scaffolding gives you the nice pre-configured classes and pages for adding, editing, and deleting records, but my survey doesn’t line up exactly to that model (ie, I don’t want anyone to go edit or create the questions on the survey, and I wanted to create a flow from creating your candidate record to then answering each question in the proper order). With some help from Eric, I soon got into the REST mindset and got the application working properly. That was cool.
I didn’t consider deployment too much until I had the app completed and working on my local instance. My plan was to just deploy it to my DreamHost account, which I assumed would be easy. I’m used to deploying .NET applications, which is extraordinarily simple, and it didn’t occur to me at first that Ruby might not be as easy. After copying my files out to DreamHost, I found this wiki page of theirs. I was a little bit annoyed at first after reading that, because I realized I would have to run a bunch of commands to get rails running and the permissions correct.
Fortunately, as Eric pointed out to me, DreamHost already has a solution. Now they use mod_rails, and all you need to do is copy out your code, check the box for mod_rails, and then use their configuration panel for that domain to point to the public directory used by ruby on rails. After doing that, everything worked great and I have to say that I am now pretty sold on Ruby on Rails. One thing I’ve always liked about .NET is that it’s pretty easy to deploy. Now that I’ve seen Ruby on Rails can be easy to develop and also easy to deploy (at least with DreamHost), it’s a much more attractive language to me.