If you’ve worked on text parsing projects – or an app that needed it – then you know what regular expressions are. It truly has been a lifesaver for me on many, many occassions. If, however, you haven’t dealt with it before, here’s some background on it:
According to Wikipedia, in computing, a regular expression is a string that is used to describe or match a set of strings, according to certain syntax rules.
For example, to capture the word Perl in the text below, you would use the following expression: .*(Perl).
Regular expressions are used by many text editors and utilities to search and manipulate bodies of text based on certain patterns. Many programming languages support regular expressions for string manipulation. For example, Perl and Tcl have a powerful regular expression engine built directly into their syntax.
How does it work?
- . (dot) means match anything
- * (asterisk) means match the previous character 0 or more times
- (Perl) (open & close parenthesis) mean capture whatever’s in it
A tool that I personally use to learn, construct, and test regular expressions is called: The Regex Coach. This tool offers many views to show how the regex engine parses text, which garners you knowledge on how it works internally, so you can write more advanced expressions.
Here’s what the tool looks like:
To end this post, I highly recommend reading Master Regular Expressions by Jeffrey E. F. Freidl to learn how/when to use it and the text-processing power it offers. This book, in my opinion, reads like a novel and is the best book on regular expressions.Take care! =0)
If you develop software or web apps, you’ve most likely experienced working off of an incomplete spec. I have, and it’s tremendously frustrating when all the work you’ve developed so far needs to be changed all of sudden because you followed the spec!
So here are some points to keep in my mind and push for before you start any kind of development:
- Make it clear to your client, whether it be an internal department or actual client, that you won’t be able to work on the project unless a finalized spec is delivered to you. If they can’t give you one, wear the project manager hat and obtain it yourself by way of interviewing, document gathering, etc.
- If you have a spec and see any TBDs in the spec, write down questions that will assist your client help you finalize that portion of the spec.
- If the TBDs in the spec can’t be finalized or answered, i.e., the client doesn’t know what he/she wants, build a mock up or shell to show him/her, as it might help the client envision what he/she needs and most likely give you the answer you need.
- Give and allocate yourself enough development time for you to complete the project. I personally add at least a week, on top of the time I believe I can complete it. This way I have time to resolve bugs or unforseen issues, and…if I complete it earlier, then I look good. =0)
- Most importantly, set the expectations of your customer – especially with regard to item #4. Let them know what the end product will look like, functions it will provide, etc. This is why building a mock up or showing the client a reference early in the development process is important.
There will be times where some – or maybe all – of these points may not apply, but try to push for them anyway.
Thanks to a good friend of mine, Dave Mercer, for making this weigh heavily in my mind!