Static IP On Raspberry Pi (2016)

Like all things Linux, when it comes to assigning a static IP address to your Raspeberry Pi, there are hundreds of blog posts documenting dozens of ways… and none of them seem to work.  These all contain plenty of jargon for the Linux initiated but seem to be short on actual answers for guys that spend all day on Windows and just want a quick fix.


1.  Get your Pi up and running and connected to the network.

2.  SSH into your Pi.   Don’t know what that is?  No big deal!  Download PuTTY (zip or installer version) and run it.



3.  You’ll be greeted with a screen like this.


The default user name is “pi” and the password is “raspberry

4.  Find out your current network information by typing “sudo ifconfig”.*  


Make a note of what this address is and your network connection name (wlan0 for my wireless connection eth0 if it was plugged in) are as we will be using them later.

You’ll also need your router’s address which you can find by (you guessed it) another command called route.  Type in “sudo route –n


5.  Armed with this information, you need to edit a config file.  Enter “sudo nano /etc/dhcpcd.conf”


This will be an odd experience if you haven’t done much with Linux.


Yes.  An editor that looks like it’s from 1992.  It’s lightweight and does the job across a network connection though.

You’re a hacker now.

6.  Scroll all the way down to the bottom and add the lines that are highlighted above, replace the information from above to match what I have.

I haven’t truly embraced the Linux ethos yet, so instead of skippng over the obvious question because I’m an asshole, I’ll go ahead and tell you what that is:  Google’s DNS servers.

7.  You’d probably like to save this.  Hit “ctrl + O”, and then “enter” to accept the file name.  Then hit “ctrl + x” to quit.

8sudo reboot

9.  When your Pi comes back up, you should be able to connect to it again via PuTTY using the IP address you just entered.

*“sudo” stands for “super-user do”, which makes you feel like you’re kicking ass instead of screaming at a borderline awful way of configuring a computer.

Secrets Of the SQL Server Ninja*–System Stored Procedures

Like me, you’ve probably hummed along happily enough just using SQL Server as a place to store data.  You’ve no doubt noticed, but never really dug into the all the folders that appear when you create a database.

Secrets Of the SQL Server Ninja*

I spend more of my day than I’d prefer inside of SQL Server Management Studio trying to piece together fragmented business logic.   However, this does have it’s upside as I’m learning a whole new skill set that I had been ignoring for most of my career. 

One of the major things I’m learning is how to leave the mouse alone.  In Visual Studio, with your trusty Resharper side kick you can fly along, rarely touching the mouse.  I don’t have any of the cool add-in’s available for the SQL Server tools, but I’m starting to get pretty proficient with the basics that are available.

The first and most basic lesson is that just like Visual Studio, F5 means run.  By default, every SQL statement in your current window will execute, but you can short circuit this by highlighting just the block you want to run. 


A lot of times, you’re going to want that value you just looked up so you can copy/paste it somewhere else.  Hands off the mouse!  F6 will toggle between the SQL pane and the Results and Messages tabs:


By default query results are shown in a grid with column headers.


But occasionally, you need your results as plain text.  To toggle this, you can use ctrl+T


And every once in a while you want to save the results to a file.  The shortcut here is ctrl+shift+F.   When you run the query in this mode, you will get a File Dialog asking you where to save the data which will be saved as a .rpt file which you can view in any text editor.


To switch back to the grid view use ctrl+d .  An easy mnemonic here is gridtext and file.


*fat toddler in a Power Rangers costume.

Living Happily with Legacy Code

In 2008 or so, I was working primarily on a mid-sized enterprise application written using Visual Basic on the ASP.Net Web Forms platform.   The application had been written by a team of people with recent experience primarily in the soupy morasses of classic ASP and desktop based VB, and to put it gently, that was very obvious when you dug into the code.  

I say this not to criticize that team.  I was one of the original members, and while I was away from the project for a couple of years after it launched, I was close to enough to the primary developer to know the kinds of restraints he was under as he worked to add a ton of functionality in in the impossible time frames you’d generally expect at a large company with a small IT department.

Long story short, he eventually left the team and maintenance fell to me.  My immediate (and mid-term) reaction was to feel completely overwhelmed.  There were a lot of 2AM calls saying that our users were reporting outages.   There was a lot of code to wade through.  There was a lot of duplicate code.  There was a lot of commented out code.  There were a lot of things that made me twist my head like a dog trying to figure out exactly what that high pitched whistle means.  And there were a lot of things that made me update my resume and spend a lot of my employer’s time on  However, I had a young child and the company provided a solid paycheck, stability and a very relaxed attitude towards work/life balance so I wasn’t thrilled about the prospect of leaving.

A few years prior to this (as the garbage can full of spaghetti code was being created),  Michael Feathers penned the classic Working Effectively With Legacy Code in which he defined legacy code as being code that lacked unit tests.   Because of this lack of tests, he reasoned, it is difficult or impossible to make code changes without knowing what the side effects might be. 

My primary take-away from this book was the concept of “seams”.  While legacy code doesn’t have tests and generally isn’t written in a testable manner,  “seams” are those places in the code where you can pull things apart just enough to make a tiny change that allows for testing.  For example,  you can move the creation of a service object out from a method and require it as a constructor argument, which will allow you to pass in a mock/fake/stub  and start adding tests.  As you start to develop a knack for what these “seams” look and feel like, you can add tests and gradually get even the most unwieldy pieces of code under control.

I stuck with that job and applied the lessons learned from this book and beat a lot of the more complicated code into submission.  I went from zero tests to around 2500 and was able to refactor, reorganize and rewrite things in ways that both made sense and were maintainable, all the while having confidence that my changes, backed by tests, were not going to cause any issues.   I put an end to calls in the middle of the night, and the late evenings and weekend work tapered off to nothing.  (It wasn’t all rainbows and unicorns – there were still areas of that code base that terrified me and I’m not ashamed to admit that I added plenty of extra nonsense in the name of keeping my skills current).

I  am reminded of this now because I have found myself in a similar situation:  I have ended up as the “lead” on a suite of legacy Web Forms applications with seven to eight years’ history of hacks, enhancements, changes of ownership and acquisitions, pure laziness and attempts to alleviate the boredom by factoring in several technologies du jour  over the lifetime of the applications. 

It appears the previous developers never met a situation where they couldn’t use a  convoluted stored procedure instead of a few lines of code.   They seem to have had no problem with databases being shared between multiple applications.  4500 line classes?  So what?  Code duplicated dozens of times in the same  file?  What of it?

And this is no big deal.   Theses developers were subject to the same temporal, fiduciary (and often, mental) restraints that we all are.  That these applications are still around after nearly a decade is testament to the fact that these developers played to their strengths to meet deadlines and provide business value.   They moved on to bigger and better things, and the bigger and better things that I moved on to include their legacy code.

Feathers’ book is back on my desk (along with Fowler’s Refactoring,  Kent Beck’s Implementation Patterns and a Costco-sized jar of Excedrin) and I’m relearning how to walk blindly into those dark hallways, feeling for those seams where tests can be introduced and refactoring can take place.

And so it begins!