Monthly Archives: February 2014

switching to linux (sort of)

i’m trying to find a faster way to cross-compile raspberry pi binaries and it’s come to this: i’m installing linux on a spare laptop to see if i can get chroot cross-compiling to work.

it’s been a while since i’ve installed linux as a primary OS, but i use it all the time for servers. when your expectation of linux is a command-line interface, you have a pretty low bar to hit in terms of user experience. but when it is the main OS that is running your apps, there’s a far higher bar of expectation and that bar is nowhere near close to being met on a default install of linux.

to be fair, i am using ubuntu 12.04 LTS, so there’s a good chance that things may have improved in ubuntu 13.x, but i’m not quite ready to make the plunge into that release.

my first impression was the UI was actually quite pleasant. the window manager was relatively slick, there’s a Mac Spotlight/Windows Start search experience to quickly launch apps from the keyboard. the default background was clean and attractive and my first impression was pretty good.

but then things took a turn for the worse. wifi didn’t work and it took additional installs of drivers and setup to get wifi to work. even then, i still have to manually connect it to the access point. i’ll have to figure out how to get that connected at boot time instead.

the most striking and painful realization of how far linux needs to go, though, is opening up a browser. the internet looks broken. it looks broken because the, what i thought was standard, microsoft web safe fonts are not installed on ubuntu by default. instead, fonts fell back to system defaults and everything about the internet felt foreign.

installing infinality and the microsoft web safe fonts (tf-mscorefonts-installer) made looking at the screen bearable again.

to mimic the os x workflow that i’m accustomed to, i installed Do as a quicksilver replacement and cairo dock as a dock replacement. Just the addition of these two apps have made my transition to linux more seamless.

there are weird quirks though. google chrome requires a plugin to make the backspace key perform a browser back.

luckily, there’s a native dropbox client. there’s an evernote clone called everypad which works, but is still pretty rough around the edges, i think i might prefer the web page over everypad.

sublime text editor seems to work as well, though i’m not sure how much i’ll be coding on this machine.

that being said, i think i can get this linux install to be working the way i want it to enough so that i would prefer this linux distro over windows. i still prefer mac os x over linux, but the gap between the two is certainly closing for routine tasks like web browsing.

jenkins job dependencies

out of the box jenkins provides a mechanism where you can kick off one job once the current job has been completed. you can chain several up and downstream jobs so that a build pipeline can be created. this is ideal if you have a workflow where you have a build job and then want to run a test job immediately after the build. this functionality is great, but a little limiting.

for example, let’s say that you have a workflow like this:
workflow

if you want to deploy your code, you want to ensure that your code:

  • has passed all of its unit tests and have passed static code analysis (job 1)
  • build the project (job 2)
  • run your test automation (job 3)
  • and then finally deploy your code (job 4)

    • in jenkins, you can set all of these upstream jobs so that once you run job 1, it’ll trigger job 2, 3, and 4. but what if you want a different workflow? what if you want to run job 1 on every commit but not do anything else? what if you want some of your jobs to depend on others, but not necessarily always be triggered from some job all the time?

    the jenkins parameterized trigger plugin comes to the rescue. with this plugin, you can tell jenkins that the current job has a prerequisite that another job needs to be successful and you can block the current job’s execution until its dependencies are met.

    build_workflow

    now when we trigger the build code job, we’ll make sure that the static code analysis passes, then build, the project, and then run test automation. if any of the jobs fail, the pipeline won’t continue.

    additionally, we can now have job 1 trigger on every commit and not have to worry about wasting resources and kicking off builds just because someone committed some code to the repository.