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!

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.