Book Review - The Art of Readable Code by Dustin Boswell and Trevor Foucher; O'Reilly Media

Programmers Dustin Boswell and Trevor Foucher present The Art of Readable Code: Simple and Practical Techniques for Writing Better Code with the underlying premise that, "code should be easy to understand." This practical and clearly-articulated text provides sound advice to assist the reader with both fundamental and advanced techniques to write code which is easy to read and understand. With chapters organized into four progressively complex sections, Boswell and Foucher focus first on basic improvements to code, offering tips about naming, commenting, and aesthetics which are applicable to almost any code, both simple and advanced. Progressing to variables, loops, and logic and then to code reorganization into functions, the authors lead the reader through important lessons and a wealth of examples. The book culminates in a study of code testing and a case study analysis of code development, applying the principles offered in the preceding chapters.

This collection of solid programming advice is bolstered by numerous code examples in several mainstream programming languages, yet is presented at a level which is accessible to a broad audience. Whether a student needing guidance, a novice programmer, or a more experienced programmer who could use a reminder about good practices the reader is certain to glean valuable tips which will help him or her write better code. The authors are successful in creating an easy and fun read which can either be traversed cover to cover or selectively, with the help of the contents pages and index. Supplemented with expressive cartoons and quotations (including Yoda!), each chapter concludes with concise summaries which embody the key principles presented. A further reading list is also provided.

As a self-taught intermediate programmer, reading this book has helped me identify some areas in which I could make my existing code better. The authors draw attention to warning signs that code is not as easy to understand as it could be. I only wish that I had encountered this sage advice several years earlier before developing coding habits which need correcting. The success of Boswell and Foucher in their endeavor to educate programmers in the oft-overlooked area of creating code which is intuitive to the reader is evident to me because reading this book has caused me to reflect, learn, and resolve to write better code.

Practical, enjoyable, and very readable. Recommended for students in computer programming and any programmer, of any level of experience, who has looked back at his/her code of several months ago and thought, "What does this part do?"

O'Reilly Media provided me with a free electronic copy of this book. Learn more about The Art of Readable Code at http://oreilly.com

O'Reilly Blogger Review Program

Recently, I joined the O'Reilly Blogger Review Program. This innovative program allows ordinary people access to new texts and videos for the purpose of writing honest reviews and publishing them on personal blogs and consumer sites where the books are sold. I'm about to publish my first review. Interested? Learn more!

Account for Every Possible Eventuality

I spent a day this week working on a project which needed some serious housekeeping doing to it. While working adequately for the end user, it was filling our PHP error log with volumes of warnings, primarily associated with referencing unset indexes or variables. In my earlier programming days I was good about accounting for events which I expected to happen in the logical flow through my code, but I often neglected to account for the unexpected. Some of my housekeeping included:

• Always check that a variable is set if any possibility exists that it might not be, before trying to use it.
• Declare the default  timezone when using server date/time variables. While it may assume correctly, it creates warnings to remind you to do so.
• Don't pass empty variables to be processed by methods when it is unnecessary to do so.
• Consider testing for NULL values and create procedures or breaks in loops for handling that.

It's common sense really, with hindsight, but when you don't know, you don't know. It's a case of live and learn. My appreciation of the usefulness of error logs has grown notably over the past year and that has caused me to lament all of the unnecessary warnings that I was causing. This is what spurred me into action and now my future projects will be all the more watertight.

Database Abstraction Switcharoo (2)

So I was continuing with my transition to PDO and I did encounter a rather annoying problem. When using MySQL Boolean or Natural Language searches, I couldn't get placeholders to work. Period. I tried everything I could think of and consulted numerous forums. Even put a question out there on stackoverflow.com but no answers in a week. I don't know if I'm overlooking something obvious, but I've been pretty thorough. I make sure my array has the exact amount of correctly-named variables and I reference each in the query only once. I get no useful error messages to give me even the first clue about what's giving it the grump. Grrrrrrrr.

Database Abstraction Switcharoo

A database abstraction layer is a piece of software which helps to manage the interaction between a script, such as PHP, and a database, like MySQL. One of the advantages of such a tool is that it can help boost the security of interactions with the database, particularly when using user input from a web form to populate the database query. This introduces the danger of SQL injection, where a user tries to interact with the database inappropriately by writing SQL code in the form fields instead of the information the form is soliciting.

Another advantage of abstraction layers is that it is usually relatively easy to change the database back end on a project without having to substantially overhaul the code responsible for interacting with the database. Examples of abstraction layers include PEAR MDB2 and PDO. I was introduced to abstraction layers through MDB2, although recently I was forced to switch from MDB2 to PDO on a project when I changed the back end database to SQLite3. MDB2 couldn't interact with this iteration of SQLite.

This week I switched another project over to PDO even though the backend was remaining in MySQL. I was improving the security of my code by no longer passing completed SQL statements but instead assembling them using the abstraction layer and a technique using placeholders. However, I just couldn't get it to work in MDB2. It took offense when I used placeholders, named or unnamed. The error reporting pretty much told me nothing but it seemed as though the MDB2 connection was being lost or something like that. So in a short space of time I did the switcharoo to PDO and it worked like a charm.

Securely handling interactions between a script and a database, especially when user input is included, is an essential skill. It's well worth investing time in learning to utilize such a tool before you need to use it in a hurry.

Structure and Forethought

A current project I'm working on, perhaps my biggest to date, is reminding me that it is very important to plan ahead for future scope when creating a code structure. In this case, I had big dreams but at the time didn't have the skills to put it all together. So I scaled down the project to the level at which I could cope. However, as time progressed and I developed new skills, I have been able to extend its scope to accomplish my original vision.

The consequence of scaling this project down was that the structure was scaled down also. Then, when I was able to add new elements to the project, I wound up overhauling the structure twice. This consumed a bit of time but served as an important lesson - If you anticipate a more complex structure than you might originally develop, design the project to be extensible so that it doesn't need a total restructure.

I'll spend a little more time in the future before diving in, to contemplate the potential complexity of a project rather than just the initial structure. This should result in more efficient code at the outset!

Learning to Write Code

Learning to write code was one of the most exciting, and yet intimidating, challenges that I've faced in library systems work. Not only are there many languages out there in which to write code, all with strong and weak points in specific contexts, but each language is a large entity to grasp. I think it is somewhat important to note that two separate challenges exist. One is the process of designing the logic, which is on the whole independent of the programming language and the other is the writing of the script - that is, embodying the logic in a specific programming language.

In addition, once one becomes familiar with one language, there are many concepts and practices which are transferable to other languages. There are subtle syntax nuances, however, that make each way of writing something unique. A very basic example is the "if....elseif.....else" structure of PHP. In JavaScript "elseif" becomes "else if" whereas in Python it becomes "elif". But once you remember that, you proceed in the same manner in each language.

I use a variety of resources to learn a language, typically using them as references. Most languages have a web site with a user guide/manual, like PHP's http://www.php.net/. This is the primary authority. Then tutorial-based web sites such as http://www.w3schools.com/ are very handy. Formal books are diverse. My favorites are usually published by O'Reilly, a publisher with which I became familiar during my MLIS studies, as some of my texts were their work. Lastly, on specific issues I frequently conduct internet searches and often end up reading discussion forums where practitioners help each other online. My preferred forum is http://stackoverflow.com

As I said before, knowing where to find the answers is key.

The MLIS and Preparation for a Systems Role

A few years ago when I earned that golden ticket, the Master of Library and Information Science degree, I knew next to nothing about programming, web design, and relational databases. These are the three areas into which I was thrown at the outset of my career. My MLIS program offered very little at all to prepare me. I took one mandatory and one elective course related to computer technology.

The mandatory course was an overview of computers in libraries, with a very basic web design component. This introduction to HTML got me drooling. I took the elective course which involved more advanced HTML projects and the use of CSS. I motored through that course and did just about all the assignments before the semester was half way through. I was hooked on web design then.

It's good to see that several MLIS programs are now introducing increased technology courses to prepare people for this dynamic area of librarianship. I wonder if such a specialization as a Systems Librarian track exists yet or whether we still rely on people with computing degrees to enter librarianship.

Competencies

I've been reading that oh-so-appropriate book, The Accidental Systems Librarian, by Rachel Singer Gordon. One area which the book addresses and which really peaked my interest, somewhat defines my challenge, and helps guide my learning, is that of competencies. There's so much to deal with.

• Hardware, software, and the sundry appendages to library computers - especially when the library is struggling to update them in a timely manner - seem to need continuous attention.
• The library web server and all services upon it need maintaining and keeping up to date. New services must be configured.
• The library proxy server must be maintained to facilitate remote access to subscription resources.
• Third party services must be maintained and configured, such as the ILS and other subscription tools like the Journal A-to-Z list, discovery service, and link resolver.
• Multiple programming languages must be learned to create original solutions or to customize existing services.
• Network and firewall issues, some of which are in the hands of the IT department, must be overcome.
• Collaboration with library colleagues who may understand little about systems and who only know what it is that they want to get done without knowing if/how it can be accomplished.

There's a lot to cover and none of it stands still. It's always changing. I think it's more important to know how/where to find answers rather than to try to have all the answers memorized. Solutions need to be as efficient and future-proof as possible.

Not the beginning!

This is not the beginning of my journey in systems librarianship. It began when I landed my first job as a librarian and one third of my role was to begin learning code to be able to assist the Systems Librarian with routine systems chores. Or did it? Perhaps it began when I was in my early teens with a Commodore 64 and, using Basic, I wrote short scripts to provide my younger sister with computer-based stories or math games. Little did I realize that when I volunteered in my high school library and spent free time writing short scripts to animate, multi-colorate, and nauseate a welcome message on a library computer, that I had sailed prophetically close to my future career! Either way, it was not part of a grand scheme of mine. Just as becoming a librarian was a quiet realization that the library career matched well with the logical mind with which I am equipped, moving into library systems was an equally logical step.

I love programming. I enjoy the learn-as-you-go self-education that comes with learning various programming languages. Much like learning a foreign language, I have experienced the plateaus where it seems hard to proceed upon the upward journey. I have enjoyed the revelations which open up new possibilities and applications of what I've learned. I love this creative outlet. I revel in developing coded solutions to library problems.

My goal is to achieve a Systems Librarian/Head of Library Systems role in which I can support the library's ever-increasing dependence on technology for the ongoing success of library functions. As my knowledge grows, I look forward to helping train those whom I supervise and to equipping them for success in their roles.