Simple Made Complex

What a crash course my learning experience has been over the past few months.  I must admit, my original intentions with this blog were to post frequently but I have been lacking in that to say the least.  I imagine this patterns is consistent with others who have thought. “Hey, I’m going to start a blog about that!” but became much more engulfed in what they were learning or experiencing than the desire to blog about what they were experiencing.  That said, I do have quite a few interesting things that I think are worth sharing, and I hope to start posting about these topics.

Out of everything that has been in a state of flux the absolute biggest change has been… *drum roll please* working primarily in a terminal based environment.  Prior to this job, I'd guess I'd spend less than 5% of my time in some kind of terminal..mainly Windows PoweShell when I needed it.   Now, I'd say that I spend over 80% of my time inside a terminal window.  My team uses VIM as their primary IDE, and tmux for switching between several programs in on terminal .  VIM is a text editor that is built into most UNIX systems.  It’s notorious for having a step learning curve but after you've overcome the learning curve many swear by it.  Here's an example of me hitting the learning curve pretty hard with VIM.

Simple made complex

1. Now in VIM.. say you want to copy and paste 2 lines of code.  Here’s how you go about doing it.
2. Ensure that you aren't in insert mode 
3. Ensure your cursor is on the spot where you'd like to begin selecting the text you'd like to copy.
4. Hit V to begin character based visual selection.
5. Move your cursor to the end of the text to be copy.
6. Hit Y to copy the text.
7. Move your cursor to where you’d like to paste text
8. Hit P to paste.

Blamo! Copy paste via vim.  That’s not so hard, right?  Well.. I guess not.  Seemed a bit laborious to learn another way to copy paste.  But in all fairness, VI has been around longer than I have.  Now I need to remember CTRL + C /CTRL +V for windows, Command C/Command V for OSX, and the dance listed above for VIM.

Now let’s say that I need to take the code that i just copied and put it into a bug report.  Unfortunately, by default, VIM doesn't share the the operating system’s buffer… so you need to figure out a way to get that text into a buffer that’s accessible outside that VIM session. You can do things like using the * register to reference the system clipboard, but that doesn't work in every Unix OS.  You can set clipboard=unnamedplus in your .vimrc file but it requires at least vim-7.3.74.  If you are on OSX you can use the command line tool PBCopy.   And...there seems to be 10 more ways to solve this problem.  There are times when I’m really impressed with the things I can do with VIM, and there are other times when it comes to things like this where I grow frustrated that things as simple as copy/paste can be this complicated.  It seems very silly that I actually need to go to google and search for "how to copy paste VIM OSX"  ... but I digress.

You can get by in VIM by using the most basic commands, but it’s real power comes from learning all of the tricks in and tips, installing custom plug-ins, shelling out to the command line within VIM.  Here’s a link to the "best” VIM tips.  I've found reading these to be very helpful, and I've tried to teach myself at least one new trick in VIM everyday.  Once you get beyond these initial learning/growing pains there are some really wonderful things that you can do with VIM.  There are countless tricks in here that i know I couldn't do with my last few IDEs.  The trick is continuing to learn a new thing or two everyday to make that initial learning curve worth it.

Whew. I survived the first week!

I’m afraid to say that I won’t be able to share much of anything that is insightful about the nuances of the Ruby language.  I’m experiencing the learning curve of the development environment so much that the learning curve for the Ruby language isn’t as much of an issue.  Truthfully, it’s much more difficult to get a hang of the environment than the language.  VIM, tmux & Bash have a steeper learning curve than I would have expected.  As far as using OSX is concerned, I feel like I’m struggling at just about the appropriate amount.  I’m very curious how much different my experience would be if I were using UI based IDEs & source control.  I think the tools my team uses are the tools I’d probably end up using anyway, but if I had my druthers, I’d prefer to be learning one new thing at a time rather than an entirely new paradigm.  Regardless, I’m thankful to have the opportunity to be experiencing a developing is such a different environment than what I’m used to in the .NET world.  I know I’ll quickly get the hang of this.

Here are a few of my initial impressions:

OSX:

• The keyboard shortcuts are compatible enough with how they work in Windows to be dangerous.  Seeing as how I usually use the mouse as little as possible, my shortcuts being gone really makes me feel like a novice.  Goodbye start key.. hello command and (option/alt?) keys.  Often times you can replace whatever shortcut you know in windows with the command key.   It’s going to take some practice to get the muscle memories down for the new shortcuts.

Terminal / Bash:

• Getting used to terminal style development is steepest part of learning curve for me.  
• Command + W is the command that kills a chrome tab.  Useful to know, eh?  It also a dangerous shortcut when you are in a terminal. It hard kills the entire terminal window.  Ouch.  Buyer beware.

Ruby:

• Any class variables you want to set a default value to, needs to be set in an initialize method.  The initialize method gets called on instantiation of the class.  If you initialize the variables outside of that method, their initial values will not be set.  I imagine there is more to this than I’ve discovered thus far.
• Have your entry point for the application at the end of the file.  This forces Ruby to scan the entire file for all of your method definitions before getting started.  

Git:

• I’ve used Git for Windows as a crutch for a while.  I’ve just been more comfortable with UI based source control.  I will be leaving this is the dust.. command line source control from now on.  Pinky swear.
• My team uses Git Duet.  Cool way to share the credit/blame when pairing.
• Try Github is a fun way to get proficient at git via the command line.  

VIM:

• Vim tutor is a good way to get started.  It’s built into VIM.  Kick off the tutorial from bash with the “VIM tutor” command.  It takes about 30-45 minutes, and every second is well spent.  Do this rather than learning via googling.   I’ll probably repeat this again exercise sometime soon.
• VIM adventures is video game approach to learning VIM.  I was recommended this by our intern, and I shied away from doing this at work because I didn’t want to get any funny looks while “learning”.  I decided to do this exercise on the weekend instead.  Unfortunately, only the first 3 chapters are available for free.  That’s just enough to get you hooked though.  I wish I could have kept going; maybe I’ll bite the bullet and pay the subscription fee in order to level up father with my VIM skills.  

Well, that's it for now.  More lessons from the Ruby Newbie to follow!

Ready, Set, Ruby!

TryRuby.org

TryRuby.org is a fun way to get started with experimenting with Ruby.  It's free and requires absolutely no setup on your development environment.  The website itself is your editor and guide.  It walks you through some basic ruby syntax via experimentation and exploration.  This guide is very entertaining and starts to get your ruby wheels turning. 

A Quick (and Hopefully Painless) Ride through Ruby (with Cartoon Foxes)

I perused my way through Chapter 3 of Why's (poignant) guide to Ruby.  After reading through all of the jokes, comic strips, and witty humor I'm again pleased with how fun the online Ruby community is making it to learn a new language. 

The metaphors they use to explain certain concepts are both entertaining and memorable.  For example - an array in ruby looks like this: [1, 2, 3]. The poignant guide's description: "Think of it as a caterpillar which has been stapled into your code. The two square brackets are staples which keep the caterpillar from moving, so you can keep track of which end is the head and which is the tail. The commas are the caterpillar’s legs, wiggling between each section of its body."  I'm looking forward to reading the rest of the material.

But enough with the reading.. and on with the doing.

I'm a "learn by doing" kind of guy.  Learning by reading is enough to prime the pump, but digging and actually slinging some code is what really does it for me. I decided that I'd start with a Kata that I never actually completed before, the bowling Kata.  Here are my initial impressions:

• I have a Windows 8 PC that's been pristinely only Microsoft development box.. up until now.  I've heard rumors of it being somewhat nasty to get ruby/rail/git running on a windows environment.  I used railsinstaller, RubyMine, and GitHub for Windows.   Setup was simple.  Myth Busted.
• I'm enjoying learning a new testing framework, IDE, and language all at the same time.  Although, when something breaks, it is very difficult to know where to point the finger (hint: mainly at myself!)
• I struggled a good bit getting the first test up and running.  Even following the example code on RSpec's website wasn't working for me.  I was snagged up with one of the requires.  My tests couldn't find my class under test, and I ended up using a require_relative.  I don't know if this is a best practice or not, but it fixed the issue.
• I also learned that the error messages that I was presented with mean almost nothing to me at this time.  I'm sure that I will get better at interpreting what each error means, but unfortunately it wasn't as intuitive as I had hoped. 
• RubyMine is pretty awesome.  It's seems to be an easy transition IDE from Visual Studio.  I'm still semi-terrified of using VIM.  RubyMine lets me debug code, have a watch window to check out variables during run time, set breakpoints..Etc.  This was key in helping me debug an issue when ruby was letting me combine a number with a range of an array.  Ruby, why'd you let me do that?  Oops!  
• The kata took me much much longer to complete that I would have imagined and I'm not necessarily  proud of the code I produced.  That said, I think I still get a notch on my belt for TDDing my way through the very first Ruby program I've ever wrote.  This code needs cleaned up, but I ran out of steam.

Comments & feedback are welcomed for the kata, tests, and blog!  Got any other cool things I can try out to learn Ruby and/or Go?  Post in the comments section below and we'll be BFFs.

Cannonball into the deep end

In 5 days, I start a new chapter of my career.  I don't simply start for a new employer on Monday, I'm making a complete 180° as far as the technology is concerned.  I've been in the Microsoft stack for 7 years now and have loved all of the things that C# and a compiler can offer.  I've enjoy using all of my ReSharper live templates to TDD out high quality code with minimal keystrokes.

But come Monday... I'll be entering the wild and wonderful world of using technologies like Ruby/Rails, the Go programming language, Vim, tmux, unix commands, and many more exciting technologies.  It is both exciting and terrifying to undertake a paradigm shift this drastic.  All of the keyboard shortcuts, tricks, and known gotchas will go the way of the Dinosaurs.  This is a going to be a whole new world for me.

I plan on blogging my way through this experience.  As the title of this blog implies, I don't claim to actually know my way around this technology stack... yet.  I'll probably be posting things that are flat out wrong or some practices that aren't the most ideal.  Odds are I'll probably be doing a lot of struggling to get to the point of competency.  This is going to be a fun adventure.  It's my belief that great developer needs to have depth and breadth.  Now that I have a lot of depth in the .NET world it's time to gain some breadth.  

I find it relieving that I'll be working in an environment where others have been through similar technology shifts.  Most of the development is done via paired programming and the environment seems extremely supportive of learning and growing.  The people seem very talented, and I know I have loads of learn from them.  

Well.. here we go.  It's time to do a cannonball into the deep end.  Wish me luck.