Book Review – Regular Expressions Cookbook 2nd Ed.by Jan Goyvaerts and Steven Levithan; O'Reilly Media

Software developers and programmers alike, Goyvaerts and Levithan present the second edition of Regular Expressions Cookbook having worked extensively with regular expressions and having equipped regular expression practitioners with handy tools such as RegexPal and RegexBuddy. I encountered this book as I first became aware both of the power of regular expressions and of the necessity of my using them in several projects at work.

This circa 600 page book is by no means a “sit down and read it” text. The first two chapters, however, provide an excellent overview of regular expressions as a concept and numerous introductory walkthrough examples of basic regular expression problems to solve. Chapter 3 focuses on utilizing regular expressions within the nuances of eight programming languages. The remainder of the book delves into specific features/applications of regular expressions in depth. For example, chapters are provided on using regular expressions with Source Code and Log Files; URLs, Paths, and Internet Addresses; and Markup and Data Formats as well as within the broader contexts of numbers and text.

The recipe format of this text is like reading case studies where a problem is outlined and one or more solutions are offered, along with a discussion for clarification. Specific programming languages are also addressed to demonstrate the development of the appropriate regular expression in that particular context. This consistent format makes each recipe that much easier to understand. This book is well cross-referenced, with the added bonus of hyperlinked cross-references in the PDF version.

Regular Expressions Cookbook 2nd ed. has undoubtedly assisted me in learning and utilizing regular expressions at work. It has proven useful both as an initial introduction to regular expressions but also as an ongoing go-to reference. I would like to see the third edition of this book include appendices with language-specific cheat sheets or summary tables for quick reference. An appendix summarizing ASCII characters and Unicode categories (already included as a table within the text) would also be appreciated. All in all, this cookbook is one of few books in my programming collection that I consider to be essential. I recommend it both for beginners (who shouldn’t allow themselves to be intimidated by its depth) and for experienced programmers who need something to which they can refer when necessary.

O'Reilly Media provided me with a free electronic copy of this book. Learn more about Regular Expressions Cookbook 2nd ed. at http://oreilly.com

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

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.