SOLID principles

As a software developer, there is always something new to learn.  There's always a new hot language to learn, framework to apply or tool to try.

For anyone who doesn't have a formal education in computer science, like myself, there's also a lot of old concepts to learn.  Importantly, you should prioritize learning these old gems before filling your head with the newest trend.

The old stuff has stood the test of time, so it's probably been useful somewhere.  And if it's been used, it's also been criticized; so you can learn from that too.

Even if the old concept is fatally flawed, they are part of the lexicon and of the computer science knowledge base.  Someone might refer to these concepts in describing a new concept.  So, being unaware of the past may make it harder to keep up with the future. 

The last few days I have been reading about SOLID.  This qualifies as an 'old' concept (or concepts).  It's an acronym for the "first five principles" of object oriented design.  Basically, when you are writing code, it should follow these principles, and if you don't, you better have a good reason why you are not. 

There isn't much I could add to the discussion that hasn't been discussed thoroughly.  But for my own sake, I thought I'd define each of them again in my words.

S - Single responsibility.

Make sure your classes are responsible for one thing and only one thing.  You want modular components, not a single "God" object that can do everything.  The primary benefit of this is encapsulation.

O - Open / Closed Principle

Write code that is open for extension, but closed from modification.  When you are adding features, you want to write new code, and not have to modify old stuff.

L - Liskov Substitution Principle

I don't like the name of this principle.  'Liskov' doesn't mean anything to me.  It really should be called the 'Substitution principle'.  Anyway ...

Wherever you using a base class, you should be able to substitute a derived class.  Make sure your derived class D "IS-A" subtype of base class B.  Because your public interface will depend on virtual methods, make sure your derived class D behaves like a base class B, except

I - Interface segregation Principle

It's better to set up lots of client specific interfaces than just a few general interfaces.  Fat interfaces will have lots of unintended dependencies.

D - Dependency Inversion Principle

The name of this principle is confusing too.  It sounds like I should should invert or reverse the direction in which modules depend on one another.  But what if I had the dependency relationships correct in the first place?

In any case, I think the point of this principle is that all concrete classes should depend on abstract ones.  Say you have some object and you want to save its data to a database.  You should have the object depend on some abstract database writer.  When you want to change the way you write to a database, you can modify the database writer and not have to modify the object.

SOLID

So, those are the solid principles.  You can get by as a programmer without actually knowing of these principles.  But it makes a lot of sense for any programmer to spend some time becoming familiar with these concepts and terms.  It helps when you are designing your classes and it helps when you want to communicate with fellow programmers.  

Osprey Talon 44

For Christmas 2013, I got a new backpack, the Osprey Talon 44 Backpack.

I've always wanted a backpacking backpack; so I'm pretty happy with the gift.

I got it because it is light. I plan on using it for hiking, bike riding, and any other travel in general.

It should be durable enough for me. It has a lifetime guarantee, but unless it falls apart soon, I'll probably never ask Osprey to live up to the guarantee. It would be cool to pass this along to a kid or nephew one day. I could tell them about all the cool places I've gone to with this bag.

My wife and I have our next trip planned. We'll be doing some hiking on the Inca Trail to Machu Picchu. I'll report on how it holds up.

Update 1

Pro: It is a great size for the Machu Picchu hike. It very comfortably holds your rain gear, liquids, snacks, cameras, sun-screen, etc ...

Update 2

Con: It is not water-proof. You should invest in a cover to make it water proof.

Update 3

Con: When it is full, the upper compartment works great and everything is secure. When the bag is partially full, things sag in odd ways, and it feels like the bag is partially exposed and open on top.

Update 4

The top of the bag is opened and closed with a cordlock. I find it very difficult to use. I accidentally pulled the drawstring out of the lock and it was extremely difficult to reinsert. I found a pen cap to be the best tool for shoving it back in.

Rating my reading

I got an email from Pocket today.  Pocket is an app that I use to read articles.  Today, they sent me a report of how many words I read in the last year.  My stats are here.  So far, in 2013, which isn't over yet, I have read 748,610 words.

I don't know how this number is calculated.  Do they know if I opened an article and closed it before finishing?  What if I opened an article more than once?  In the end it doesn't matter.  .75 million words is my new benchmark.

More than the absolute number, the more interesting part of the given statistics was that I was in the 95% percentile of users.  This means, I read more than what 95% other users read.  So this tells me something interesting.

Over time, I'd like to see how much I've been reading versus myself.  Maybe after some life events, like if I have kids, I will see a huge drop off in reading.  Maybe nothing will change over time.

It felt good to get this report.  I think reading is worthwhile (so does this guy), and it's encouraging to hear that I've done a lot of it.  Maybe I'm vain, but statistics about oneself are interesting.  It's one of the reasons I started building the app usage monitor.

Hardware is hard

The wife and I started working on a robot.  We are trying to follow the tutorial at Let's make Robots.  I have found that working with hardware is hard.

As with many things, the hardest part is that I don't have the basic skills or knowledge.  For example, soldering looks like the basic building block of putting electronic components together.  For a regular software developer, it is akin to editing text.  If you can't solder, then you can't build any electronics, and I didn't know how to solder.  When you don't know what to do, how to do it, or why it should be done, making progress is hard.

In the hardware world, everything costs something.  In the software world, once you have a computer and an internet connection, there are tons of free languages and tools to build real world applications.  If you have been building robots for a while, you may have a collection of unused supplies.  But for me, a beginner, I had to buy a lot of stuff, from wires to soldering tips and of course batteries.

It is not easy to undo a change.  If you break something, you might need to buy a new one.  This makes tinkering a little bit scary.  For now, I don't have a good means of debugging a problem or testing a change.  It will take a combination of increased knowledge and maybe some new tools (like a volt or current meter) to really be able to debug problems.

This experience reminds me of being a physics student.  In class, we solved problems and the math worked out perfectly.  Then, we tried to measure things in lab, and all the answers were just a bit off.  The hardware world is much less forgiving, but I hope that going through the trouble of working with hardware will have some benefits.  I hope to have a greater appreciation for all hardware, and I hope it helps me be a better software developer.

Motivation

I experienced a few things yesterday and they all led me to the same thought.  I'll note them here, and you can try to guess what feeling I had after each one.

1. I played in a basketball game where my team was completely annihilated.  It was like the NBA vs the pee wee league.  We were totally outclassed.
2. I was looking over some old code that fumbled through a few actions: unzip files, delete a subset of them, re-zip remaining files and then move them to another directory.
   After some thought, and reading through 'man zip' and 'man find', I replaced garbled nested code with a few clean unix one-liners.    
3. I found out that an old buddy of mine had started his own company in a field that he has loved since we were kids.  

If it wasn't apparent to you, I'll tell you now. The feeling I had after each of these events was motivation (or maybe ambition).

After losing my basketball game, I felt that I had to get back into shape and practicing regularly.  After finding out a cool solution to a coding problem, I had a revitalized feeling to continue studying and reading to uncover cool solutions.  Finally, after hearing about my friend, along with being very happy for him, I also felt motivated to do more with my life.  

Yesterday, no matter what happened, I felt motivated.  It is similar to that old Tootsie roll commercial, "Whatever it is I think I see, becomes a Tootsie Roll to me".  I was drawing motivational fuel from whatever I was seeing or experiencing.  Let's hope I can keep putting it into action.