Friday, September 28, 2012

Learning Ruby

This week I've been reading through "Code Complete" by Steve McConnell. He discusses the importance of choosing the right programming language for the task at hand. Now, there are many languages available for use today. How do we choose which language to use? Do we just stick with what we know or do we branch out and try to learn a new language? Every language has its strengths and weaknesses, if you limit yourself to only a few languages you may possibly be limiting your knowledge and capabilities.

Working in the IT field over the past 10 years, I've learned many programming languages over the years ranging from C to SQL. However, Steve McConnell brings up the interesting topic of utilizing high-level languages that allow you to be more productive and allows you to produce higher quality results. A study shows that 1 line of C++ is as efficient as 2.5 lines of C code and 1 line of Perl or PYTHON is as efficient as 6 lines of C code. This means that you can do more with less when utilizing high level programming languages! 

One specific language brought up was Perl. I've heard all about this language and have several co-workers who go on and on about how great it is. However, I never really took to even look into it, much less learn it. A few weeks ago my boss suggested I learn Perl and I brushed it off not thinking much about it. This week, I learned what it is capable of through Steve McConnell's book.

On a daily basis, I utilize the Linux command line and write SQL queries to retrieve data from databases. I do most of this manually with some shell scripting for administrative tasks in Linux. Today I learned that I can make my job 10 times easier by learning and using Perl! If that's not incentive enough to learn it, I don't know what is.

First stop, Google and YouTube! Here is some good links that I found for anyone who may be interested in learning Perl as well. Click here for a free online book and here for some tutorials.

Have fun!

The Pragmatic Programmer - Chapter 2: Here's What I Thought Was Good

In chapter 2 of The Pragmatic Programmer, we read about "tips and tricks that apply at all levels of software development". According to the text, these are virtually universal methods. Here is my opinion on what was good and informative about this chapter:

  • Tracer Bullets
    • Aside from the awesome analogy between software development and guns, this method of development makes a lot of sense to me. Why spend valuable time calculating all the variables before taking a shot at the target when you can fire off "tracer rounds" along side your "real ammunition" in a live environment? When operating in an unknown environment with the high likely-hood of changes occurring, rather than spending lots of time specifying and calculating in order to create something we hope will work we, instead, code a basic structure with minimal functionality to establish a starting point for further improvements. 
    • I, especially, like this because it's a technique which you can use to take that first step in coding a project. Sometimes when you take a high-level view of your project, it can seem like a daunting task. By starting with basic functionality first, then making incremental improvements to increase it's functionality, it allows you to get to work quicker and to make progress. For someone like me who likes to get into a project quickly and make immediate progress, this seems like a great technique. This all assumes that you have planned the project well in advance.
  • Orthogonality
    • The concept of Orthogonality resonated strongly with me. This describes the concept where two or more things are said to be orthogonal when changes in one do not affect any of the others. 
    • I've been a part of many projects where software modules are highly dependent upon others. Having been only a part of the "rebuilding" team, making changes to  one part of the non-orthogonal code required me to make changes in several other modules as well. Understandably, some code may need to be dependent upon other modules for functionality. However, if you can isolate modules so that they are not dependent upon others it makes changing and updating the code much easier and development time is reduced dramatically. In addition, changes to the code reduces risk.
    • I like this concept and will try to apply it in all future projects. While I have always had it in my mind that your code should incorporate independent modules, I have never been able to pen those thoughts as well as it was written in the text.