“It’s our turn to decide what that means” really is a wonderful way of explaining to someone what it means to embrace that which you love but that most people see as frivolous. I have a new yard stick;
Despite everything, Chris Hadfield is a man. He is someone who has worked hard to have the opportunity to experience something truly astonishing but most importantly, to me at least, he has shown that despite the fact he worked his way into orbit it didn’t stop him from playing up to it. In the six months he was commander of the ISS he showed us what it is to be a grown up, insofar as you make the most of whatever situation you find yourself in.
The Space Oddity video, and the many others he posted, are truly the ultimate proof that we decide what it is to be a grown up. For that, he forever has my thanks, admiration and envy.
After a two week hiatus from work and blogging, spent mostly at the ever excellent Reading Beer Festival, I’m back at work and doing something so simple I’ve utterly forgotten how to do it. As this blog started as a way for me to keep track of random things I learn over the years, it’s time to write this one down.
Here’s the issue; I’ve created an XML file and want to create a C# class library to work with it in code. It’s really easy once you remember how, through the use of xsd.exe.
- Create xml file
- Run “xsd.exe filename.xml” to create an XSD file
- Run “xsd.exe /classes /language:CS filename.xsd” to generate a .CS file
One thing that always makes me chuckle is this line that is included at the top of each CS file;
“This code was generated by a tool.”
In this case, a forgetful one at that.
Today’s post relates to my experience installing Atlassian Stash on a headless Ubuntu box. My first attempt ended with me trying all sorts of nonsense which left the server messy as hell, including an accidental installation of Unity…
The trickiest part for me was the installation of Java as the version available via the package manager, OpenJDK, didn’t seem to play ball with Stash. No idea why but one of the helpful fellows from Atlassian, Stefan Saasen, pointed me in the right direction with this article which I’ve used as basis for the steps below, the browser plugin steps were omitted for obvious reasons.
First of all you need to grab the tar file for Java from here then get it onto your server, the easiest way I found was to use an FTP application in SSH file transfer mode. Then connect to the terminal and run through these commands;
- Decompress the tar file noting that the file name will reflect the version you download and may differ from mine;
tar -xvf jdk-7u2-linux-x64.tar.gx
- Move the JDK directory to /usr/lib;
sudo mkdir -p /usr/lib/jvm
sudo mv ./jdk126.96.36.199_17 /usr/lib/jvm/jdk1.7.0
- Now run these lines, no idea why, explanation in the comments please!
sudo update-alternatives –install “/usr/bin/java” “java” “/usr/lib/jvm/jdk1.7.0/bin/java” 1
sudo update-alternatives –install “/usr/bin/javac” “javac” “/usr/lib/jvm/jdk1.7.0/bin/javac” 1
sudo update-alternatives –install “/usr/bin/javaws” “javaws” “/usr/lib/jvm/jdk1.7.0/bin/javaws” 1
- Correct the permissions for the executables;
sudo chmod a+x /usr/bin/java
sudo chmod a+x /usr/bin/javac
sudo chmod a+x /usr/bin/javaws
If you are installing on a fresh server, that should be all you need for Java to work. If you’ve a few JVMs present on your machine, see the original article for steps to configure the default. For Stash, you can now follow the instructions here. One thing I found quite useful was the wget command that a colleague showed me, it makes downloading via the terminal quite easy, getting the Stash installer for example can be done like so;
Note, the version I’ve listed there may not be the latest so you should grab it via here;
For editing the setenv.sh file, and text files in general, I’ve found nano really useful. I’ve not ventured into the murky depths of the text editor holy war yet but this does the trick for now. I had to run the same chmod against the Stash home directory I created but after that I was good to go. Open a browser to the path listed in the console and use the wizard to continue setup.
I’ve always been a fan of grid computing and at the start of the year I donated my gaming rig to the World Community Grid project, 24×7 for January, which was a bit of fun and a nice stress test. I’ve since been given permission to install on some spare machines at work and found a bit of a gap in the documentation for a headless installation which I thought I’d bridge. Installing it headless is easy, managing it headless proved a little trickier but only due to my rookie status with Linux. These steps are all you need for a quick installation and remote management;
sudo apt-get install boinc-client
sudo nano /var/lib/boinc-client/remote_hosts.cfg
Add your client machine IP to the list then connect remotely using Boinc Manager. Job done.
For anyone interested in joining the fun, I’ve set up a jedbowler.com team;
This weeks thing was built for a friend for the Iron Man inspired dress she has made for Iron Fest. The ARC reactor is made using 11 superbright 3mm LEDs connected to a pair of AAs. It is then sewn onto a scrap of denim from an old pair of jeans for a bit of structure and covered in white fabric from an old t-shirt. The dress was made by Miss Jones herself, including the repulsor glove, the latter using an EL panel left over from one of her Tron routines. I don’t have a pic of the reactor completed but it works best as part of the outfit after all;
The actual structure of the reactor is really simple, I set out the LEDs in the required pattern using blutak then bent the pins so when soldered together the pins themselves form the structure. This makes for a far lower profile and easier to integrate into the outfit.
As I’m implementing Git at work, I’ve decided to start using it at home too and for the site. As such I’ve dusted off an old account I’d forgotten I’d created and you’ll find me on github as jedibowler. The first of my projects to be posted is the code for the network enabled temperature/humidity logger from a few weeks back which can be found here.
My wallet has taken a beating, is showing its age and my tablet is still away for repair so I’ve taken to carrying a notebook with me. About time I hacked my Moleskine really…
It already had a pocket in the back so all I needed to add was slots for my cards. To that end I removed a couple of pages at the back to keep the bulk down and used one of the pages for the slot. I’ve added a crude ruler on the back page and I’m going to add reference notes on the blank bit too as I discover useful things I’ve a habit of forgetting.
You can also make your own pages to print out and stick in using the MSK tool, there are quite a few already available too. Likely will add a Tube map in there somewhere as I can never remember which line is which when travelling through London.
If you’ve been following this series of articles, I’ve been attempting to migrate from Subversion to TFS 2012 over the last six months or so and have given up on the idea. It seems as though we are using a non-standard repository pattern which means the odds are stacked against us.
I’m not a newbie when it comes to troubleshooting TFS, I used to work in Microsoft Developer Support and it was my specialisation, but it shouldn’t be this hard to move from one platform to another. I know that the Subversion adapter is Alpha but I also attempted to use SVNtoTFS and the trial version of Timely Migration’s tool too without luck. I’m not sure if the way we’ve used Subversion makes it difficult to move history (update: likely yes) or if the tools just aren’t up to scratch with TFS 2012 but we need our version history and as we can’t get it into TFS, that’s that.
After a lot of effort, we’ve given up on migrating to TFS and instead we are going to use GIT and Stash, we’ve already licences for Jira and Bamboo too so will be investigating these as they are new products to me. We’ll be self hosting on Linux which should be an experience too and as I’m a Linux newbie I’ll be blogging my experience as I go in order to help other Windows veterans get to grips with things, as well as a reference for myself.
We hit more problems, as per my last article that means another post! This post will detail the steps to troubleshoot a merge issue but the techniques I learned are good examples for generic troubleshooting of the TFS Integration Platform. Our issue;
A set of files aren’t being checked in after a merge in SVN.
Looking at the Subversion log I can see that the files should be checked in during a merge at a specific changeset. Looking at the TFSIP log you should see entries similar to “Processing ChangeGroup”, searching the solution for this string takes us to the MigrationEngine.cs file. I added an IF statement after the processing trace is added such that a break point can be hit when a certain changeset is reached;
Adding a breakpoint at line 347 means that you’ll be able to step into the code when a problematic changeset is reached and troubleshooting can begin.
During troubleshooting this issue I randomly hit the following error on build from the Interop.Subversion project, I resolved by cleaning only that project then rebuilding the solution;
error C1859: ‘Debug\Interop.Subversion.pch’ unexpected precompiled header error, simply rerunning the compiler might fix this problem D:\tfsip\IntegrationPlatform\Adapters\Subversion\Interop.Subversion\AprPool.cpp
I ended up hitting the same issue as mentioned in part 1 where a manual merge was required and for the life of me I couldn’t remember how I fixed it the first time around. Follows are my notes from each attempt;
“1039″ issue – Manual rename of folder in TFS and check in;
Source = SVN version 1039
Target = TFS checkin 942
Undo pending change
Delete empty folder from folder B and checkin -> 942
Move from folder A to B and checkin -> 943
Get latest, undo pending change then open in Windows Explorer. Manually copy the files from source folder to target then within Source Explorer delete the source folder and add new items to target. Check in an cross fingers.
1039 -> 942
Rename B/WebSite to Website2 then checkin
Move A to B and check in
Manually map 1039 to 944
Hit start, map all conflicts to 944
Resolve Conflict in TE, Rename Server and check in
Map 1039 to 943 in TFS IP.
The simple step I should have taken, and wasn’t aware of, was to open Team Explorer and have a look at the list of pending changes. This helps a lot and was the troubleshooting step that worked around this issue. Migration continued
Around a thousand SVN revisions later we hit another issue, this time a runtime conflict; “Checkin failed for unknown reason”. I opened VS to check pending changes and found missing files, for some reason the Subversion adapter wasn’t getting a few thousand of the files for this revision from the repository. I manually got that revision from SVN and pasted into the TfsIpData folder and checked in to attempt a manual merge as before. I managed to check it in but when I kicked off the migration again it threw a few hundred conflicts.
It failed, and I’m sorry to say this is where the story ends as we are cutting our losses with the migration and moving to GIT and Stash. More on that in the next post.
Stuff and Things!.NET Gadgeteer 3d Printer C# CAN Bus Desk Project Dev Stuff Electronics Git Grid Computing HelloWorld Home Brew Home Server Kitchen Tricks Lifehacks Linux Make Media Centre Netduino Office365 Personal PowerShell Project Hugo Random Musings Recipes Robotics Site News TFS Thing a Week Tools Uncategorized Windows 7 Workspace XML