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
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.
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:
Chase.com 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.
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.
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:
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 talk 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:
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
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)
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)
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)
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)
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
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:
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! conference, YOW! 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.
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).