A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.
O’Reilly Radar runs the blog post comparing performance of several cloud services. While everyone should run their own tests and benchmarks before deciding which one is better, the article provides a nice summary. Here is the graph based on their results.
As I have mentioned a few times before, I am a big fan of using BestPractical RT3 for all sorts of things, including, but not limited to, bug tracking during project development. I see a great benefit in having a single system for both technical support and development departments. Bugs can be reported by customers, investigated by technical support department, passed on to developers, fixed and tested, and then passed back to technical support department to verify with the customer and resolve.
Needless to say, integrating RT3 with Subversion can be of great benefit. In this case, not only you will have full history of bug reports, but you’ll also see which code changes were made for each bug report. Learning from previous bug fixes and having a quick way to see why something was changed is priceless.
Read more to see how RT3 can be integrated with Subversion. You can also easily adopt the same approach to other version control systems.
Continue reading Integrating RT3 with Subversion
I came across an interesting problem at work a couple of days ago. One of our CakePHP-based applications has a scheduled task (cronjob) that runs every minute and imports mail from a number of IMAP mailboxes into the database. All of a sudden the script broke. In a very particular way. Not a single line of code was change in the script itself, and there were no significant changes in the rest of the application that the script is using. But one day, for some reason, it started to import emails from only half of the mailboxes, completely ignoring the rest.
A lengthy midnight drunk debugging session helped to realize the problem. Apparently, in the list of mailboxes to check there were a few old mailboxes, which were not used anymore for any email. The script was checking them but they were always empty. Server administrator removed those mailboxes during a scheduled maintenance window. Now, the script couldn’t connect to the mailbox anymore. No problem, there was error handling for this case. But was error handling didn’t take into account is the combination of time it takes timeout on the non-existing mailbox check and the database connection timeout.
It so happened, that these few old mailboxes were right in the middle of the list of all mailboxes. The script was importing mail from the first few mailboxes just fine. But then while it was taking a long time to timeout on a few non-existing mailboxes, the database connection got closed due to the inactivity timeout. This wasn’t handled properly. The script was only checking for the existing database connection at the beginning, when it was opening the connection – not later on. As the result, nothing could have been imported from the rest of the mailboxes.
As always, once you know the problem, you also know how to fix it or work around it. But troubleshooting a problem like this is tricky. Seeing the queries working for one mailbox and not working for another is disorienting at least. Having no recent changes to the application doesn’t help either. And the problem being not in the code itself, but in the resources is also not very obvious.
So, here you go. If you ever have a weird problem like that – check that your resources (database connection, network connection, file handler) are still available to you.
I’ve been praising Best Pratical’s RT3 (aka Request Tracker) for a long time. So at my new job, given a new start, I thought that I maybe need to explore other options and widen my horizons. After all, the needs were much less and much simpler. We just needed a bug tracking application for three people or so and for a single project. There was a possibility of more people joining the team later and more projects starting up, so I didn’t want to limit ourselves too much. But immediate needs were quite simple.
After a good look around, I decided to give Mantis Bug Tracker another try. I remember using it for a bit back when the project just started. I even remember patching it to fit my needs back then.
During those few years that I haven’t looked at MantisBT it grew and developed quite a bit. It is a stable, feature-rich, yet simple to manage application. We’ve used it for the whole two month before our needs changed again and we started looking back at RT3. Never-the-less I am glad we used it and got experience with another tool. I got a few ideas out of it, which I will be implementing in our new RT3 installation. Below are the few things that I loved and hated about the MantisBT. Maybe you’ll find them useful.
Continue reading MantisBT vs. RT3
Several times a week I recommend to different people to actually go and read The Subversion Book. Obviously, not enough people do it. Including myself. So sometimes I have to fish out a tasty bit from that book to get people interested. Today is just such a day.
Have you heard about Subversion changelists? If you haven’t, chances are you aren’t utilizing your time properly. Here is a brief introduction.
Subversion 1.5 brings a new changelists feature that adds yet another method to the mix. Changelists are basically arbitrary labels (currently at most one per file) applied to working copy files for the express purpose of associating multiple files together. Users of many of Google’s software offerings are familiar with this concept already. For example, Gmail doesn’t provide the traditional folders-based email organization mechanism. In Gmail, you apply arbitrary labels to emails, and multiple emails can be said to be part of the same group if they happen to share a particular label. Viewing only a group of similarly labeled emails then becomes a simple user interface trick. Many other Web 2.0 sites have similar mechanisms—consider the “tags” used by sites such as YouTube and Flickr, “categories” applied to blog posts, and so on. Folks understand today that organization of data is critical, but that how that data is organized needs to be a flexible concept. The old files-and-folders paradigm is too rigid for some applications.
As wonderful as they are, changelists do have some limitations.
Subversion’s changelist feature is a handy tool for grouping working copy files, but it does have a few limitations. Changelists are artifacts of a particular working copy, which means that changelist assignments cannot be propagated to the repository or otherwise shared with other users. Changelists can be assigned only to files—Subversion doesn’t currently support the use of changelists with directories. Finally, you can have at most one changelist assignment on a given working copy file. Here is where the blog post category and photo service tag analogies break down—if you find yourself needing to assign a file to multiple changelists, you’re out of luck.
But even with this limitations, changelists are extremely handy. So I urge you once again to read the book. Or just the changelists section.