{"id":17929,"date":"2013-03-25T04:51:43","date_gmt":"2013-03-25T02:51:43","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=17929"},"modified":"2013-03-25T04:51:43","modified_gmt":"2013-03-25T02:51:43","slug":"best-practical-rt-training","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2013\/03\/25\/best-practical-rt-training\/","title":{"rendered":"Best Practical RT training"},"content":{"rendered":"\n

I’ve spent the better part of Wednesday and Thursday of last week in Amsterdam, at Best Practical’s RT training sessions<\/a>.<\/p>\n

\"Best<\/a><\/p>\n

I’ve been using Request Tracker<\/a> (RT) for many years now. \u00a0 The first version I saw was 2.x, and it wasn’t my own install, but I did participate in configuration and customization. \u00a0I also used it on a daily basis. \u00a0That was love from the first sight. \u00a0The user interface seemed simple and straightforward (yes, it’s built by techies for techies), internal architecture seemed transparent, it was Open Source Software, and it was written in Perl. \u00a0What’s not to love?<\/p>\n

Once I left that company, I think I’ve installed RT in pretty much every other company I worked for (there were a couple of exceptions, where the decision wasn’t my). \u00a0I’ve also done a couple of side projects, and I used it for my own needs too (going through all 3.x series and now jumping into 4.x). \u00a0And the more I used it, the more I loved it. \u00a0 I even mentioned it in this blog a few times. \u00a0Have a look, for example, at this post<\/a> from 2008, where I describe my toolbox and RT being one of the core tools in it.<\/p>\n

For the past year or so, however, I was involved in a slightly different kind of work, while at a slightly different kind of environment. \u00a0Long story short, there was no RT and I missed it a lot. \u00a0That, though, gave me an opportunity to once again look around. \u00a0I was part of the team that researched and evaluated a variety of tools, which, functionally, are similar to what RT can do. \u00a0And the more I looked, the more I wanted RT. \u00a0Alas, the choice once again wasn’t mine.<\/p>\n

That all made me a bit sad and nostalgic. \u00a0Why? Why<\/em> – I was asking myself – can’t I get back to The Golden Times of Perl programming and using capable tools such as RT?<\/em> \u00a0And I couldn’t find a good reason why not. \u00a0So, an idea seed was planted in my mind. \u00a0I thought about, and I thought more, and the idea grew. \u00a0And then I told a few people about it, and all of them seemed to like it, so I decided to\u00a0pursue\u00a0it. \u00a0Yet another side project, hopefully. \u00a0But the one which will be heavily based on RT.<\/p>\n

Once the direction was chosen, the stars started to align. \u00a0One of the friends, who’s the part of the project, pointed out to me that Best Practical Solutions LLC<\/a> – the company behind the Request Tracker – is doing a training session in Amsterdam. \u00a0Being a US-based company, their European training sessions are few and far apart, so I decided to go.<\/p>\n

On one hand, I have to say that it is a bit expensive, especially for a self-funded trip. \u00a0On the other hand, it’s an Open Source tool and people who develop it do need to make money somehow, and training is one of the legitimate ways to do so. \u00a0On the same hand, I’ve been using the tool to save me countless hours, pulled out hair, and earn me quite a bit of cash in the process. \u00a0So it’s all fair. \u00a0I guess, it’s not that it’s pricey. \u00a0It’s more of me having a bit of a short time to decide, plan, and make it happen. \u00a0Anyways. \u00a0Was it worth it?<\/p>\n

\"Learning<\/a><\/p>\n

It was! \u00a0Every bit so! \u00a0It was one of the best technical training sessions that I’ve been too, and I’ve been to a lot. \u00a0If I had to compare, I think it was the same level of quality I saw at Red Hat’s RHCE rapid track course.<\/p>\n

Kevin Falcone<\/strong>, one of the RT architects and Best Practical’s senior engineers was the presenter. \u00a0We only had two days to cover everything, but he came prepared. \u00a0In fact, it’s a huge understatement. \u00a0He was simply top notch! \u00a0He had everything with him that was needed for the sessions – books, slides, notes, you name it. \u00a0He is also extremely knowledgeable about the RT’s past, present, and future, about who and how is using it, about what the community is doing, and about all those tiny little details all over the RT universe – from people, concepts and ideas, to bugs, configuration options, and branch names, both merged and not. \u00a0Also, while being very serious about his work, \u00a0Kevin was easy to talk to, and, what is probably even more surprising, he was also a keen listener, interested in what kind of problems or issues people are having with RT, where they are coming from, and so on.<\/p>\n

As for the actual training sessions, I was a little bit worried to be bored out of my mind during the first day. \u00a0You see, the first day was mostly for RT users – new and seasoned. \u00a0While the second day was focused around more hardcore stuff like installation, configuration, customization, and development.<\/p>\n

I’m happy to report, that my worries were baseless. \u00a0It turned out that even though I’ve been using RT for so long, I still have huge gaps in knowledge and understanding. \u00a0There were quite a few things I had no idea about, and there were a few that I knew about, but where an easier way exists, or my understanding wasn’t totally correct.<\/p>\n

Here is an example of the knowledge bit that made quite a few people in the room go “Oh! Wow! Why didn’t I learn about it before?”. \u00a0In default (and many instances of non-default) configuration, RT would send an automatic email notification to the requester, upon the creation of a new ticket. \u00a0That’s a handy bit of functionality, served by a global scrip. \u00a0But, what happens if you have, say, 500 queues, and you don’t wan’t to sand such a notification for only two of those queues? \u00a0Until the training, I knew of two ways how to do it. \u00a0One involved removing the global scrip and re-creating a queue-level scrip only for those queues that needed to send the notification. \u00a0The other way would be to update the scrip code to check the current queue against a whitelist of queues. \u00a0Both would work, but neither one is elegant. \u00a0Well, apparently, there is a better, more elegant way, which also sheds some more light onto how RT “thinks”. \u00a0All you have to do is create a new queue-level AutoReply template with no body. \u00a0The same global scrip would execute, but would try to use the queue-level template, instead of the global one. \u00a0However, RT is being smart in a way, where there is nothing to send it won’t even try. \u00a0So an empty queue-level template would result in an email with no content, which RT simply won’t send out. \u00a0Brilliant, isn’t it?<\/p>\n

But, as much as the first day was useful, the second day was a total blast. \u00a0We’ve covered a lot of ground (and had to move through the slides pretty fast at times), but that was like … like … like Neo learning kung fu in the Matrix movie: huge amounts of knowledge and wisdom just being uploaded straight into the brain. \u00a0I think one of the reasons that we could move so fast was due to everyone in the room having plenty of prior RT experience. \u00a0Everyone knew what Kevin was talking about, and there was instant insight and understanding. \u00a0Or so I think.<\/p>\n

Some of the useful things that I’ve learned during the second day included:<\/p>\n