Working on Haskell code in vim

I decided to get a fresh vim install properly set up for some Haskell development, and went down the road of using hdevtools, vim-hdevtools and Syntastic. Below are notes on some issues I encountered setting up vim-hdevtools.

The instructions on the GitHub page for hdevtools & vim-hdevtools linked above are simple enough, but I ran into a couple of issues. I’m using the sandbox feature added in Cabal 1.18, and by default hdevtools doesn’t know to look for a .cabal-sandbox folder. So, when I tried to use any of the hdevtools commands, I received an error message similar to the following:

Error loading targets
 Could not find module `(module)'
 Use -v to see a list of the files searched for.

This is an issue that a few people have run into, and I found a link to this solution in the archives of the #Haskell IRC channel. Adding it to my .vimrc seems to have fixed this error, and I can now use all the hdevtool commands in vim. I’m still having issues with *.cabal files that  specify default-extensions (vim-hdevtools doesn’t seem to pick these up).

Also, if you get an error message similar to the following:

E492: Not an editor command: ...

make sure that hdevtools is on your path and that you have plugin files for specific file types enabled by adding

filetype plugin on

to your  .vimrc.

Installing self signed certificates on Android (Jelly Bean)

I was pretty happy when I found out Android now supports installing self signed certificates, but had some trouble getting the certificate I use for administering this blog installed.

So, a quick note for anyone who is attempting to install a self signed SSL certificate on Jelly Bean Android devices: you can only install a root CA certificate (i.e. a certificate with “Subject Type=CA”).

Trying to install a certificate for a single site (i.e. a certificate with “Subject Type=End Entity”) isn’t possible as far as I can tell. I don’t have any references for this, it’s just based from my experience, so let me know if you’ve experienced otherwise.

Two-factor authentication and ‘trusted’ devices

This is an interesting article – it’s the story of a couple who challenged a hacking team to pen-test their digital lives. To give some context to the following quote, their laptop has been compromised and user ID and password for their on-line banking account at Chase has been stolen by the ethical hacking team: uses a two-step verification system, which momentarily stymied SpiderLabs’ hackers. Every time she or I logs on from an IP address that Chase doesn’t recognize, it offers to send us an activation code via text to our mobile phones. But a search of Charlotte’s hard drive revealed Chase cookies, which the team copied and used to convince Chase that she was logging in from home.

You could argue that if your PC has been this thoroughly compromised then you have bigger problems, but it still points out how limited some two-factor authentication systems can be if you allow devices to be remembered/trusted.

Part of the job of a BA, as explained by Cathie Hagen and Jiangmei Kang at ThoughtWorks LevelUp EXP (Brisbane)

ThoughtWorks LevelUp EXP Brisbane

On Saturday I was lucky enough to attend ThoughtWorks LevelUp EXP at the ThoughtWorks Brisbane office.

As well as plenty of opportunities to chat with the ThoughtWorkers (and Chad!) who kindly gave up their Saturday, there were six presentations throughout the day:

Opening Keynote: Design Thinking

Ben Melbourne (@benmelb) set out to teach us about design thinking, and how it’s important for any project. The main points that I took away from his talk were:

  • Visual design is only a small part of design.
  • UX research is not strictly academic or scientific – iterate quickly and rely on feedback to get the best results in the shortest time.
  • Embrace constraints to get the most out of a situation. Design is harder when you have a green field to work in – if you have constraints, don’t fight against them, use them for inspiration.
  • Everyone is a designer – if you’ve ever been on a project without a designer, it was you.
  • Always ask if the current approach is the best use of business capability.

Functional Programming for Fun and Profit

Next up was James Ottoway (@jms_) with a good intro to functional programming. He started out by explaining declarative languages and reactive programming, as well as DSLs and closures and how they can be used to cut complexity.

Declarative languages focus on expressing the logic of a computation, not how to carry out that computation. Regular expressions, Chef/Puppet configuration files, and SQL were all used as examples of declarative languages. In James’s words:

We’re expressing what, not how. And that’s a good thing.

Expressing what you want to do (and not how it must be done) frees up the compiler/interpreter to make decisions about implementation at runtime, and eases the burden on you as a programmer.

When talking about reactive programming, James used Excel (everyone’s favourite spreadsheet application) as an example of a reactive program. This is a really simple analogy which I think helped everyone grasp the idea of reactive programming quickly. He also pointed out that the windows GitHub client is built using reactive programming (using ReactiveUI from what I can see).

As someone who’s trying to learn Haskell at the moment, this section about of this talk about closures was interesting to me. Closures aren’t something that I was seeing in Haskell, perhaps because I’m still battling with unfamiliar syntax (turns out they’re pretty much everywhere). A closure is just a function together with a referencing environment, and they’re pretty essential for functional programming.

Business Analysis

After lunch we heard about the life of a BA from Cathie Hagen (@catherist) and Jiangmei Kang. BAs are an integral part of every stage of a project, and use their place as a bridge between the client and the developers to ensure that value is delivered to the client. The following is a photo I took of the board used to explain the many aspects of work as a BA, I think it says more than I can:

TW LevelUp – Business Analysis

(Sorry about the poor quality – the projector turned on for the next talk just as I was taking this picture)

User Testing

Why build something that people don’t want to use? It’s 2013, doing that is a waste of humanities potential.

Pete Chemsripong gave a great talk about the importance of user testing. Speed is important for user testing and ideally should be a daily thing. Every feature that you’re working on in a project should be validated by a user (this agrees with what Ben said in the design talk).

Helping you get your first job

The last presentation before the keynote was by Jean D’amore (@jeandamore) with an entertaining on how to land your first job in IT. The talk introduced job hunting as a game where you can’t control everything, but what you can control can make all the difference. He split the journey into seven steps, each accompanied by a great movie reference & quote. Hopefully the slides will be made available as I didn’t get everything down, but what follows is my summary:

  1. Yourself (The Last Samurai)
    • Improve the environment by working on yourself.
    • Do: know your boundaries, be versatile, stretch yourself, maintain balance, listen, commit to projects, be willing to sacrifice, learn/do new things
    • Don’t: underestimate yourself, thing you’re alone, deny the challenge, limit the horizon
  2. The Search (An Unexpected Journey)
    • The search will change you
    • Do: know what you seek, choose a domain, know the employer, ask about graduate programs/training, keep your LinkedIn (and internet presence in general) up to date, favour simple job ads (i.e. not ads that list every skill under then sun – you often need to be a specialist before you can generalise)
    • Don’t: dismiss too quickly, use recruitment agencies, work on projects you don’t agree with (everything you do has an impact and will impact you), waste too much time searching on-line (do spend more time talking to people)
  3. Your CV (The Colour of Money)
    • Do: PDF it!, make it unique, know what’s on it, web design it (use web design principles – e.g. readability, don’t cram everything in), make it one page, get friends to read it, start with skills over education
    • Don’t: lie/exaggerate, rush it, use ‘bullshit bingo‘ words (except in a few cases where it’s in the ad – in this case, always explain and give examples)
  4. Applying (Close Encounters of the Third Kind)
    • You need to understand and be understood
    • Do: strike with precision, add a cover letter, apply to people (not computers), customise your CV, wait, follow-up, be organised
    • Don’t: bulk apply (do apply to at most 5 organisations at once – it becomes too hard to keep track of what you’re doing otherwise)
  5. Interviews (Gattaca)
    • Little things are often the most important. For example, be good to everyone at the company.
    • Do: look clean and tidy, research the company & their interview process, arrive early, know who you are and why you’re there, know what you’ll be asked, listen, ask relevant questions, be humble and curious, know your stuff (especially your résumé)
    • Don’t: be afraid to ask for clarification, lower your guard until you’re clear of the building (i.e. do treat every moment you’re in/near their offices as part of the interview), ask how you did at the interview, ask about time/money when you’re after your first job, leave your phone on, have alcohol (even if offered), go if you’re sick (you need to be 100%, and the interviewers will understand)
  6. Hearing Yes/No (The Hurricane)
    • Don’t be afraid of failing and keep bouncing back
    • Do: take your chance to explore/re-evaluate, take risks, trust your instinct, understand that this is one step is a career
    • Don’t: burn bridges, take it personally, rush to accept, say you’re waiting on another offer
  7. First Day (City Hall)
    • Make a difference and work where you’re satisfied. Focus on employers that give you the upper parts of Maslow’s hierarchy of needs
    • Do: learn names, go to social events, pair, do what you’re told, be helpful, learn the ropes step by step, leave if you don’t like it after a month of so
    • Don’t: panic, try to change things quickly, cold shoulder anyone

Closing Keynote: Who are you, where are you going, and how will you get there?

The closing keynote by Chad Renando (@ChadRenando) followed on nicely from the presentation from Jean, and was really a step back, focussing on making the most of who you are, being clear about where you are going, and being intentional about how you can get there.

Every man invents a story for himself – which he often, and with great cost to himself – takes to be his life.

Chad used this quote from Max Frisch as a way of explaining that you create your own story, but you should never think that it can’t be changed or even completely rewritten.

You need to understand yourself to understand how you will work with others – are you more practical or creative? Do you approach things in an analytical way or listen to your beliefs? Are you structured or flexible? Learn what your signature strengths are and use those to create a mission statement, as your strengths are the things that make you feel alive. At the same time, look out for the strengths that you rank poorly in.

Create goals (what is your 9-day plan? your 120-day plan?) that align with your strengths, but don’t think that these goals are set in stone. Use goals as a way to direct yourself, not as measures of success. This allows you to iterate on your goals and improve them as you learn more about yourself.

Chad finished the main part of his talk with his axioms from life in a digital studio:

  • Ask questions
  • Focus on resolving process conflict, not relationship conflict
  • There are things that are understandable, but not acceptable – don’t get the two confused
  • Everyone is generally doing the best they can
  • There is no fault, only cause
  • Every conversation we have is with ourselves, and sometimes they involve others
  • If you want to lead others, lead yourself

The day covered a range of topics and gave me a lot to think about. One point that appeared a couple of times throughout the day (and which Chad reiterated at the end of his keynote) is how important it is to get involved with your community. It allows you to grow your network, get references and learn. I can’t agree more, I have learnt so much and met lots of interesting people by attending the YOW! conferenceYOW! nights, and the BFPG & Brisbane GPU Users meetups (there are tons of similar user groups in Brisbane – I guarantee you won’t regret attending one of their meetups!). Another way to get involved in the broader community while sharpening your skills is volunteering – there are plenty of non-profits that could use help with IT. Or, if you have an idea/are working on a start-up, River City Labs is building an amazing community of like-minded people.

Thanks again to ThoughtWorks for running this mini-conference – you’ve done a great job of inspiring this IT undergrad! More about ThoughtWorks LevelUp can be found on Twitter (@TW_LevelUp) and Facebook.

A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments.

Kevlin Henney (original tweet here).

There are some interesting responses, pointing out that comments are great for references and in-line diagrams, and sometimes necessary for code that has been restructured to improve performance (although creating difficult to read code solely for performance reasons is a separate issue).

It’s just amazing how many mistakes [are made] and how bad programmers can be. Everything that is syntactically legal, that the compiler will accept, will eventually wind up in your code base . And that is why I think static typing is so valuable.

John Carmack (full talk here - note this link jumps to this quote – part one of the keynote is here).

Pretty much sums up how I feel about the static v. dynamic debate for anything other than very short-lived prototypes.

Don’t fear the Monad

I recently watched Brian Beckman’s Don’t fear the Monad talk (YouTube version here) and thought it was a really good explanation of functions, monoids & monads and why they’re a useful way to master complexity.

I recommend it to anyone who’s starting to look at functional programming. Here are some of the key points I took away from the talk:

  • Functions are data
    • A function takes an argument(/s) and returns a value, and always returns the same result for the same inputs
    • Think of a function as a table lookup – the table is the data
  • Functional programming is a style that can be used in almost any language
    • But some languages make it easier than others
    • First class functions (or at least lamdbas) are a must have
  • Complexity is killing software developers – we need to control it
    • The best way to control complexity is to put functions into groups where things are disciplined, and where they can be composed in arbitrary ways
    • Build complexity out of simplicity by composing things
  • A monad adds some data to a value, and the implementation of the bind operator defines how that data interacts
  • If you want to add a feature, you shouldn’t even have to know what you’re going to interact with
    • Using monads means the interaction is already built into the structure
  • You don’t need to know what a monad does
    • So long as it follows the rules, it can have arbitrary side effects

Another interesting part was Brian’s reasoning about why functional programming is a ‘hard sell’:

Immediately upon the foundation of computing, the world split into two camps – the bottom up camp and the top down camp.

The bottom up camp is typified by Turing machines – “let’s start with the hardware and add abstraction as we need it to get close to the mathematics, but never at the expense of performance”. That gave rise to FORTRAN, C, C++, Pascal, Java, C# … all of those languages are in that tradition.

The top down crowd says “let’s start with the mathematics and subtract abstractions to get down to the machine, sometimes at the expense of performance”. That tradition starts with lambda calculus … and only subtracts abstraction when it is convenient to do so. That’s the tradition that gave rise to ALGOL, Lisp, Smalltalk, ML, Haskell and all these languages that have reputations of being slow.

As most programmers are familiar with the bottom up way of doing things and the two approaches come from very different origins, it can be hard to convince a bottom up programmer of the benefits of the ‘top down’ approach. It can be even harder to pick up functional programming once you’ve resigned to giving it a try.

[The top-down crowd] are saying “don’t go to the hardware so early, you’ll lock yourself into irreversible design choices”. [The bottom-up crowd] are saying “don’t give me all this math, I can’t handle garbage collection, or function calls or whatever it is that’s getting in the way of my performance, I need every ounce of performance the hardware can give me. And I’m willing to write software into the wee hours of the morning to get it”.

The last sentence here is what stands out to me – as software gets more complex, it seems that bottom up programming is going to require more and more time working in the wee hours of the morning to get the desired performance and functionality.

Maybe Haskell …

After reading Learn You a Haskell on and off over the past fortnight and watching a couple of Erik Meijer’s Functional Programming Fundamentals, I finally got around to installing the Haskell platform and firing up GHCi.

After a couple of hours of implementing the simple functions scattered throughout LYAH, I was up to implementing quick sort. Given the number of times I’ve seen this example, I’m not going to reproduce it here, but it’s pretty amazing [1].

One of the main things I noticed was that after two hours of writing code in a language I’d never used, I’d produced zero run time errors. There were plenty of compile errors, but that’s to be expected – especially given I was using an editor that was inserting tabs in a language with significant white space (which, by the way, makes for fun times when unfamiliar with Haskell compiler errors). I know what kind of error I would prefer to deal with.

So far I’m liking Haskell, and I think it’s a huge shame that there is only one functional programming course at my university (COMP1024), which isn’t available to most dual degree students.

1. I know this isn’t ‘true’, in-place, high performance quick sort, but in how many other languages can you write a readable, generic sorting algorithm in 6 lines of code?

VirtualBox + Dell laptop VT-x issues

I recently had to use a VM for a uni project, and needed to have access on my laptop & desktop. I haven’t used a VM on my laptop in a while, but didn’t expect to see the following error message from VirtualBox (4.2.16):

VT-x features locked or unavailable in MSR.

I’ve used x64 hosts before with no problems, but I guess my BIOS settings were reverted for some reason (using a Dell laptop with Intel PM45 chipset).

So thinking to myself that this should be an easy fix, I rebooted, enabled VT-x and restarted, but I received the same error message. No amount of changing BIOS/VirtualBox settings, rebooting or otherwise reconfiguring would make this message go away.

I eventually read that it’s sometimes necessary to power down and physically disconnect the machine from power to properly enable VT-x. This solved my problem – I decided to make a note of it here to hopefully help someone else in the same situation.

Ubuntu 12.10 – Transmission fails to connect to HTTPS trackers

Transmission, the BitTorrent client installed by default in Ubuntu seems to have an issue with connecting to trackers using HTTPS at the moment.

After Transmission failed to connect to a tracker using HTTPS, I went searching and found this bug report.

The steps there are pretty simple and worked well for me:

  1. Close Transmission
  2. Download the .deb for updated libgnutls26 from here (bottom of page – choose your architecture then mirror)
  3. Install using
    dpkg -i (package name).deb
  4. Restart Transmission

UPDATE: It looks like this is now fixed, so running

sudo apt-get update
sudo apt-get upgrade

should get it working again for you.