At work, I’m gradually moving our CI server from Hudson to TeamCity.
Nothing against Hudson really, but I feel that TeamCity is a much more robust CI Server when it comes to integrating with .Net. It allows you to publish artifacts from your builds, and has a killer integration between developers IDE’s and itself, which is amazingly helpful to help developrs make sure they’re not going to break the build… well before they break it.
But anyway, one thing that was slightly annoying me with TeamCity, is the fact that the build agents would often get disconnect, and all my builds would stay in a queue until I went and manually restarted the agents.
The “Build Agent Disconnected” quickly became very annoying, and by quickly looking up on Google, I found lots of people had the same issue, and while there were lots of responses or people claiming they found a solution to it, I never actually found anything of much use other than the screenshot this guy posted.
When you add build agents on TeamCity, you get the option of adding them as a windows service, or simply as an agent that runs with TeamCity. I had tried to add multiple build agents as windows services before, but for a very strange reason, I would always end up with only one agent no matter what I did. TeamCity’s documentation wasn’t much help to be honest, and I ended up figuring this out after a couple of hours of trial and error. So here’s how you do it properly.
I’ve created a new website over the last weekend and would like to share it here with you.
I’ve spent an entire day without checking my emails on Saturday, and when I finally got around to do it, there was a ton of useless crap in it. My spam filters are pretty good, but won’t pickup on things I (un)intentionally subscribed for.
The very act of purchasing something online will sometimes auto-subscribe you to the store’s monthly, weekly and daily newsletter until the end of era.
By osmosis, I will normally delete all the email from my inbox and just get on with my life.
This time though, I decided I’d also unsubscribe from some of them. Some were easy enough, as every good citizen knows to add an unsubscribe link to the bottom of the email.
Some others though, will make the assumption you love to get their newsletters about their huge selection of garden hoses.
While unsubscribing, I though maybe some other people may want to make use of the unsubscription links, so I decided to collate them all, and put them together on a collaborative website.
The idea is very simple, find what you would like to unsubscribe from, and the link will take you straight to their unsubscription page.
What if my link isn’t there?
You can just add it. Simply go ahead to the GitHub page, fork the project, make your changes, and send me a pull request.
Adding a new URL is as simple as:
And you can also collaborate with the project itself, but changing any of the files, adding new functionalities or making the layout look a bit prettier.
So I had this idea for a little application and wanted to get the UK’s Top40 singles to use in it. I started by writing something that would scrape Radio 1′s Top 40 chart and return me a list of songs since I couldn’t find any feeds that would give me that.
I then thought this could be of use to somebody else, so turned it into a little service (built using Ruby and Sinatra) that returns a JSON object with all the singles and some useful information about the number of weeks it’s been there, how much has it moved, and which direction (up or down) it’s gone.
On the root of it, it returns the chart date as the current date and time, and the retrieval date to indicate which date it’s been last retrieved. I am caching the feed to play nice with Radio 1, so I’m only making one HTTP request a day to their website.
It’s no secret that on the UNIX world, dotfiles play a very important part when it comes to making your terminal look good. Be it on Linux, be it on a Mac. Dotfiles are there so you can configure your favourite software to look just the way you like it.
I especially use dotfiles to customize the look on my terminal, and to manage bundles I use with Vim. One thing that normally annoys me, is the fact that whenever I rebuild my machine (or build a new one) I need to copy over my dotfiles, and obviously make sure they are kept up-to-date on all my devices when I change something.
I’ve heard about people adding their dotfiles to GitHub, and even noticed GitHub themselves encourage you to do the same. I decided to give it a go, and will describe here what you need to do in order to have your dotfiles stored there, and most importantly, how to quickly load them up on any other computers boxes you may have.
Start by creating a folder called “dotfiles” on your home directory, and move all your dotfiles into it.
In the example above, I’m only covering my vim and bash dotfiles. You can cover as many as you like by simply moving your files into the dotfiles directory.
Now it’s time to create your install script also under our ~/dotfiles directory. You should use this script every time you want to install your dotfiles on a given machine. So let’s open vim (or your favourite text editor) and create the following file:
The file is pretty simple, as it contains a list of files which you want to have copied, and a loop to put them on the right location and create symlinks on your home directory.
Now, it’s really important that you name this file correctly, as you want to be able to execute it. And after having created it, we need to give it execute permissions, as we want to be able to run it
If you run this file now, you should see the following happening on your screen:
Good. We’re ready to push this to GitHub, so we never have to go through this process again.
Go ahead and create a new repository on GitHub called dotfiles.
Now, back to your terminal and run the following commands:
From top to bottom we’ve done the following:
navigated to our newly created directory
turned it into a local git repository
added all the files it contained into our local Git repository
committed all the added files into the new local repository
hooked up our local git repository with the GitHub repository
pushed our files to the remote (GitHub) repository
If everything went OK, you should now be able to browse your remote repository (mine is https://github.com/mplacona/dotfiles) and see all your dotfiles (as well as your installer) listed there.
Now, the beauty of it, is the fact that whenever you want your dotfiles in any other box, you can simply do the following:
At work, we use Apache JMeter for load testing applications or API’s we build.
JMeter is an amazing open source tool with an even more amazing community behind it, so if you’ve never used it, you surely are missing on a great piece of software.
Anyway, one thing that used to annoy me a bit, was the fact that when creating tests for API’s, I’d sometimes need to pass in dates.
So imagine the following case:
You’re testing that your API can create a new book in your bookstore for a specified date, but the business rules imply that you can only create a new book with a release date in the future.
If I had hard coded this to a date in the near future, I would then need to update it at some point as to always make sure my dates really were in the future.
I could also put a date very far in the future, but my business rules again dictate that I can only pass in dates up to 60 days in advance, so I’d end up having to update my tests in about two months or so.
Come the user defined variables:
The code for your user defined variable would look like this:
What it does is simply create a new date, add 60 days to it, and then format it as “yyyy-mm-dd”. You could change the number of days and format easily by moving things around.
A sample request would then look something like this: