Why I’m Doing a PhD and Why You Might Want to Think About Doing One Too.

I’m getting my PhD. Right now I am about a year into it and I’m not looking back. I started straight after getting my previous degree (BE Electrical) because for me now is the best time to be doing it. The following are some thoughts about why I am working towards a PhD and why I did it as soon as I could. To avoid sounding self absorbed I have put this here with the hope that someone like me who needs that final push will come along and convince themselves to enrol in a PhD, my particulars are not overly important here.

What my PhD is/will be about

For some context my PhD revolves around the design and optimisation of gradient coils for MRI. I have a background in electrical and software engineering so for me this was perfect. There are a lot of simulations and coding which I love and also enough experimentation to keep me grounded. A lot of what I do revolves around the mitigation of eddy currents in conductive surfaces. Eventually I plan to write a post outlining these concepts in a simplified way but that will have to wait for another day.

I should clarify that where I am (Brisbane, Australia) a PhD is usually 3 years of continuous research. I have talked to others who have course work and other combinations of study in their PhD. Some are longer, I haven’t heard of any much shorter but who knows. As such individual milage may vary here.

Reason 1 – I love what I do

First and foremost I’m here because I love it. I am extremely lucky to be able to take the time to keep studying, I know there are many others who are not so lucky and sometimes the ‘do what you love’ mantra ignores that fact. Believe me I realise that I’m in a great position. I enjoy the work, even when it’s a grind. The idea that, maybe one day, I will discover or design something brand new is quite an exciting prospect. I have a great amount of freedom in my work (which is probably why I’m in a startup too). As well as that I feel that medical technology is a great use of my skill set. Knowing that I might pay a part in making the lives of others better is very rewarding. I’ve met some of the smartest people in the world in a whole range of fields related to what I’m doing and having the chance to pick their brains is a reward in and of itself.

If you finish university and find yourself thinking ‘finally’ then a PhD probably isn’t for you. If you hated study and research then, as it should be obvious, you may want to consider other options. If, however, you left thinking ‘Over already, it was just getting interesting!’ or you’ve been away a while and have maybe changed your mind you may want to talk to your local graduate school.

Reason 2 – The tip of the iceberg

Bachelor’s degrees are, as they should be, more about exposing you to concepts and building a foundation than becoming an expert. As an electrical engineer there are dozens of possible pathways you could follow. There is no way you could become an expert in all of them in a four year period. A PhD (or any post graduate study for that matter) gives you the chance to tunnel deeper into some facet of this knowledge. It’s true that you come to know more and more about less and less but it’s only when you break through the outer crust that you start to see the vast amount of wonder out there.

There is also an interesting opportunity to apply skills from other areas in your life to your research. Some of the algorithms and software ‘tricks’ I have picked up over the years have boosted the performance of simulations significantly. In a way a PhD becomes a lot like an apprenticeship, you are mentored by some of the best in your field as you grow into your own.

Reason 3 – I have few barriers right now

As I mentioned I went straight from my bachelor’s degree to a PhD, this is in part due to the system we have at my university. I thought about it for a long time and I realised that the longer I waited to do it the harder it would be to come back. If I had a family to support, a mortgage, and a well paying job it would be difficult to drop everything and go back to study. I’m not saying it can’t be done but for me I figured now was the time. There are some things that I think a little bit of real world experience can make all the difference but I had aligned myself with some of the best people in my field and I didn’t want to pass up the opportunity.

In summary (or tl;dr)

So there is my story, or at least the introduction to it. I love what I do and I’m extrememly lucky to be doing it. I would recommend a PhD to anyone who wants to experience more in their field. I’m not saying you can’t get the experience elsewhere but a PhD is a great place to find it.

As always I would love to discuss with other PhD’s or those considering it about their thoughts on the matter. Feel free to tell me I’m wrong, as long as you provide some reasoning. If you want to get in touch with me jump onto twitter or leave a comment wherever you found this article. Also if you are interested you can leave your email address below and I will, from time to time, send you an email about a new post (not all of them though thats what RSS is for).

- Elliot

A .vimrc for Beginners

I love vim. I use it for code, notes and blogging (meaning I’m using it right now). It is a great tool with a tonne of smart, powerful features that I have barely started to get my head around. There was a time when my vimrc file was hundreds of lines long filled with all the cool bindings and snippets I found online. Truth is though, I never used any of them.

I know what they did but the sheer number of them made it hard to remember and made me frustrated with vim. I knew vim was good and I knew the features were enabled so it must be me thats doing something wrong. So I stopped using it. I got fed up and put it away for another day. When that day finally came I was on a new laptop without my old vimrc. Probably in the best place I could have been. A fresh start.

I found the situation a lot like teaching my mum how to send emails. At first I would bombard her with keyboard shortcuts and tricks to save her seconds here and there. In the end I would find myself showing here again and again because I was trying to introduce far too much at once when all she really wanted to do was send an email. Once I noticed this it became much easier to show her new things. I would pick the trick or shortcut that would have the biggest effect and showed it to her. For example cut and paste went down a treat when it wasn’t paired with archiving emails, reply all and how to organise an inbox. Anyway, back to vim.

This time was different. I enabled the bare minimum like syntax highlighting and disabled the arrow keys. From there I committed to really learning what vim was all about. I had a post on my old blog about a post by Yan Pritzker (here) which I still maintain is the tipping point for my understanding of vim. I really started to ‘get’ vim and most importantly some of the design ideas behind it.

The more I understood the less I needed. I turned on some indenting features for code, a colour scheme and search highlighting but that was it. Sure there are some useful add ons and sure they may increase productivity by 100% but the question I ask is whoes? At this point the gains of adding all the extra modifiers would probably be minimal. My current approach is to just write, when I find myself doing something multiple times I stop and check if there is a better way do to it. Usually there is, without needing to add a new plugin.

So that’s my recommendation, Start with an empty .vimrc and only add things as you find yourself needing them. As always your milage may vary but for me this has worked wonders. For anyone interested here is my .vimrc:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
" filetypes
filetype plugin on
filetype indent on

set hlsearch

set showmatch

syntax enable

colorscheme desert
set background=dark

set expandtab
set smarttab
set shiftwidth=4
set tabstop=4

- Elliot

Vim

Blog Reboot

The new year often brings in changes. At least that sounds like a fine excuse. Truth is I was a bit sick of wordpress bloat and 99% of the posts on my blog get about 4 views a month. With all this at hand I decided it was a good time to move my blog onto a new platform (Octopress for those curious) and start things anew.

When I started the blog oh so long ago I wasn’t really sure what I was starting one for, honestly it just sounded like something I should be doing. Since then I’ve tried many thing to keep me posting regularly only to find that at the end of the day I don’t really know why I have a blog in the first place. That’s the first thing I am going to change.

I’m writing a blog to share my thoughts, stories and adventures in programming, electrical engineering, my PhD, my Startup and all the other passions in my life

Well there it is. A reason. Even if it isn’t a very good one it is a reason none the less. At least now there will hopefully be some focus. Chances are pages will still only get a few reads a month but thats something I can work towards. Secretly (or not so secretly) I’m using this as a way to try and improve my writing as well. I spend a lot of my time writing in acedemia and PR but I never really take the time to practice so thats a bonus goal I suppose of this blog.

I’m going to port over some of my old posts just so existing links don’t break but there may be missing formatting or images so I apologise about that. Also I likely wont be having comments on the blog because I’ve had something like 10/10,000 comments to spam on wordpress. If you want to comment or get in touch twitter is a good place to do it (@smitec)

None the less here is to a new year full of exciting things to share.

- Elliot

My Stuggle With Vim

For a long time I had read and listened to people telling me how excellent Vim was and why it was better then X, Y and Z. Honestly though it has taken my a really long time (say 2 years) to become what I would call average at Vim and understand why it is actually a useful tool.

TL;DR

How to improve your vim skills (for those starting from the beginning)

  • Learn to touch type (probably the most important step)
  • Write your own vimrc
  • Read This
  • Disable the arrow keys (See Below)
  • Practice often
  • Take small steps (one command at a time)

Hello Vim

My vim journey began 2 years ago when one of my subjects at university required us to ssh into a remote machine to do all our coding. I’d been coding for a while and I could work my way around the command line if I needed to but I was still very much in the comfortable world of the IDE. I’d traversed from Visual Studio on Windows to XCode on OSX and honestly I was happy. I could compile run debug and do all sorts of tricks with the press of a few buttons and for what I was doing it was more than enough.

My first vim experience probably like many others was the built in vim tutorial. I worked through it pretty slowly laughing at the concept of using letters to navigate the screen and wondering why anything needed such a complicated set of seemingly random commands. I printed my vim cheat sheet stuck it on the wall and got to work.

Progress was slow to say the least. I would never remember which commands performed which action and I had to set line numbers and a indenting rules every time I opened vim. I thought to myself, ‘There must be a better way’. Then I discovered the .vimrc

Baby Steps

As I didn’t really know much about vim I figured I would find a .vimrc online that would solve all of my issues and use that. I read the description and it seemed to fit the bill with features above what I’d hoped for (you can use a mouse!) honestly looking back this was probably the biggest mistake I made, but an important one.

Copying the vimrc allowed me to code but the entire time I kind of felt like it was using vim for the sake of using vim. I got slightly faster by the end of the subject and I could use vim if I had to but my command set was entirely made up of the letter i, :wq and the arrow keys to move around the screen. The subject ended and with it my vim usage.

Back from the Dead

during the following 12 months I put an ssd in my laptop and decided rather than copy across all the seemingly useless stuff I would start from scratch and only install what I really needed. With that wipe (unbeknown to me) my seemingly precious copy of the same vimrc I used on the server was washed away into oblivion. Some time later I was perusing Hacker News and saw an article about vim. ‘Hell, why not’ I thought and decided to give the article and vim a chance.

I read that article on December 19 2011 (I know because my comment is on the article) and it was like the dirt was washed from my eyes. The article was Learn To Speak Vim by Yan Pritzker and after reading it I finally started to understand the value of the vim editor.

Text Do My Bidding (please)

Another thing I should probably mention is until about half way through 2012 I could not touch type. Everyone I knew seemed to learn at school but some how I managed to miss out. I could type fast enough for anything I needed to do but Vim without touch typing is about as useful as coding via Morse code. If you cannot touch type and want to use vim, stop right now and learn. I subjected myself to many online children’s touch typing games and whilst I’m still pretty average in terms of accuracy and speed I feel there is a definite improvement.

When I first reopened vim I noticed all my syntax highlighting and tab options had disappeared so I decided to remake a vimrc before I started getting seriously back into vim. I thankfully couldn’t find my old vimrc so I decided to write one from scratch. I looked online and saw that the :Set commands i was used to running fit easily into the vimrc and created a basic vimrc that highlighted syntax and used 4 space tabs.

Now honestly I didn’t use vim all that much for some time, I had textmate and XCode and never thought to open vim when I decided to code. Every now and then I would be working from the terminal for other reasons and it was most convenient. For one reason or another TextMate became somewhat of a pain for me to use (mainly because I could never remember any of the shortcuts) and I decided to get rid of it.

I told myself I would try and use vim whenever I could and the next big step forward came from adding four lines to my vimrc.

1
2
3
4
:noremap <Up> <nop>
:noremap <Down> <nop>
:noremap <Right> <nop>
:noremap <Left> <nop>

If you can do this and stick by it your vim productivity will increase significantly. It will be a pain to begin with I promise you that, make sure you know A appends after the end of the current line. You will be tempted to quit or use a mouse but it is worth it in the end.

From there it was just a matter of practice and slowly building up my command portfolio. If you can keep this up and learn a command every now and then you should be comfortable in vim in no time. In terms of commands if you find yourself doing something mundane over and over there is probably a command that can help you. Which commands you use often and in what order you learn them is defined by how you use vim don’t be afraid to experiment and go at your own pace.

Summary

To keep myself from rambling I’ll call it quits here. I’m no vim guru and I still type rather slowly but I’ve come to be comfortable working in vim and can see myself using it (perhaps not exclusively) in the future. If you know any great vim articles I should have a look at please let me know in a comment or an email.

:wq

  • Elliot :)
Vim

Setting Up a Git Server on OSX

This is the moved copy of my old post. Hopefully it all looks the same in Octoproess. If you have issues let me know on twitter. Pictures will be back ASAP.

So I’m a pretty big fan of GitHub but sometimes it just isn’t what I’m after. I have some projects that I want to keep hidden away (at least for the time being) and don’t really want to pay for the private hosting features.

Sound familiar? Well then you probably want to set up your own Git repository on a machine at home and push to that. If that does sound like something you’d want to do continue reading below.

This post is mainly a OSX port of This Article which is a great article, and while a lot of it is the same I hope to cover some of the OSX specifics that I personally found a little hidden when following that article.

What You Need

  • A spare computer running osx (these steps will work with some small tweaking on and unix system but as I couldn’t find a complete osx tutorial I’ve decided to stick to that, also I had a spare mac mini.)
  • Thats it apart from an internet connection which I can assume you have. Just as a note I’m currently running OSX Lion but these steps shouldn’t be too different for Snow Leopard (anything else I can’t guarantee)

Step 1: SSH access

In order to push and pull from your repositories you need some way to connect to the computer they are stored on. SSH (or secure shell) is the way to do just that. The following steps will help you set up your spare computer for ssh access using certificates only (more on that below).

1.1 Settings

Turning on ssh access in osx is pretty simple all you need to do is open up “System Preferences” and click on the “Sharing” icon.

Click the check box for remote log in and give your computer a name (something easy to type is probably not  bad idea). Now at this point you have two options, you can allow any user on your computer to sign in or you can create a new user that will just be used for git (perhaps even call them git). I would advise creating the git user anyway as this will make your repository URL much nicer. To create your new git user go back to “System Preferences” and click the “Users & Groups” icon.

Click the plus beneath the list of existing users and fill out the details of your new user. Now if you only want to allow git to ssh into your machine go back and change the “Allow Access For:” settings in “Sharing”

1.2 A quick test

Just to make sure you have set everything up correctly thus far open up terminal and type the following line on another computer on your local network.

1
$ ssh git@yourOtherMachinesName

you should be asked to add this host to allowed addresses make sure you type yes here. Afterwards you should be prompted for a password, enter the password you assigned to the git user and press enter. If everything worked correctly you should now be connected to your other machine (exciting isn’t it).

1.3 Making things safer

Now as we stand anyone with your ssh address and password can log into your machine. That might seem okay but it allows people to sit all day attempting to log in until they finally crack your password. A better approach is to use RSA public keys. This method is a little more involved and once set up it means you cant log in from any old machine without adding a new key but it is by far the safest option, it also means on trusted machines you don’t have to type in your password when you ssh. It’s really up to you whether you do this or not, if it doesn’t sound like your cup of tea then you can just skip this step. First thing we need to do is open up terminal on our trusted machine (not the one used as a sever just yet). If you have used ssh before for github or anything like that you may already have a public key set up, for those that dont you’ll need to type the following into the terminal. (you can use -dsa or -rsa)

1
$ ssh-keygen -t rsa

You’ll then be prompted for a password, I cannot stress this enough PUT IN A PASSWORD. Once that’s done you should be prompted for a save location, just hit enter and it will go to ~/.ssh by default. You should then see your public key printed nicely and it will have been saved to

1
~/.ssh/id\_rsa.pub

(unless you gave it a file name). Now we need to copy this public key onto the other machine. Type the following commands into the terminal to do so. (If you already have an authorized_keys file you should use the cat command instead to append it to the existing file)

1
2
$ ssh git@yourOtherMachineName mkdir .ssh
$ scp ~/.ssh/id\_rsa.pub git@yourOtherMachineName:.ssh/authorized\_keys

Now we need to log into the server and tell it to stop accepting passwords. Type in the following commands into the terminal on your non server machine (or if your on the server machine just skip the ssh line).

1
$ ssh git@yourOtherMachineName

type your password.

1
2
3
$ cd /etc
$ chmod 666 sshd_config
$ vim sshd_config

So we are editing the sshd_config file (not ssh_config this is for logging into other machines not having people log into ours). now scroll through and make the following changes to the lines shows below (they’re shown as the default setting). If you don’t know how to use vim I suggest having a quick read on how to use it before doing the following. Change:

1
#PermitRootLogin yes

To (note no hash and changed from yes to no)

1
PermitRootLogin no

Remove the # from the following

1
2
3
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Also from

1
2
#PasswordAuthentication no
#PermitEmptyPasswords no

and finally change

1
#UsePAM yes

to

1
UsePAM no

Now save the file (:w) and log out of the machine (ctrl-D). Attempt to log back in and if it worked you shouldn’t have to enter your password. If you are able to try it on a different machine and you shouldn’t be allowed in at all (because you haven’t added that machine’s key).

2.0 Actually setting up git

Now there are a few ways to install git and I’ll let you choose your favourite the main thing is you have git installed on both machines.

2.1 Setting up an empty repository on your server machine

So now that git is set up on both machines we need to set up a repository that you can push to. Ssh into your remote machine and choose/make a directory to store your repositories. In that folder run the following command to create a new empty folder to store our repository in.

1
2
3
$ mkdir newrepo.git
$ cd newrepo.git
$ git init --bare

Thats all there is to it! By using the —bare flag we are saying this is a git repository but only use it to store pushes, in other words nobody will be using this as a local repository.

2.1 Setting up your local repository

Now head back to your local machine and find a folder to store the local copy of the repo. Run the following commands to setup the repository, add a readme file and push it to your server.

1
2
3
4
5
6
7
8
$ mkdir newrepo
$ cd newrepo
$ git init
$ touch README
$ git add README
$ git commit -m "initial commit"
$ git remote add origin git@yourOtherMachineName:/path/to/newrepo.git
$ git push origin master

And assuming everything was done correctly your repository should have been pushed to the server and you can now use it the same way as you would a github or bitbucket repository.

3.0 Summary

So hopefully this will help someone one day to set things up, if it does feel free to comment below or what not. also if you get stuck anywhere you can leave a comment as well as I may have mistyped a few things here and there. Another thing to note is this will only allow you to log in on your local network to allow external log in you will need to set up either a fixed IP for your router or configure a service like dyndns. These are both outside the scope of the article but there is a bunch of info around the web on doing both of these things.

Other than that happy coding.

Elliot :D