Regexes and Sizers

 As I mentioned a few weeks ago, I've been learning Perl using the infamous llama book.  My first introduction to Perl was by a friend of mine when I was working on a class project using MATLAB (which was a mistake, but that's a story for another time).  I didn't try picking it up at that time, but it's been on my list of languages to learn since then.  

There are few things I've learned that Perl is good for: it's really good at processing text and it's goal is to allow for quick and dirty programming.  This means it doesn't take a lot of time or typing to write short little snippets of code that are pretty powerful.  Even though I'm a tad more than half-way through the llama book, I still feel like a noob because some of the syntax feels so obtuse, particularly when it comes to regular expressions.

Several of the more recent chapters I've gone though give an intro to regular expressions and it's the first time I've really had any exposure to said concept.  So what are regular expressions (or regexes) anyway and why are they useful?  They are a way of matching parts of text (in geek-speak: matching patterns in strings) and their existence and robustness in Perl is why it's a great language for text processing. Anytime you have to do some sort of searching there's probably some regexes (although maybe not in Perl) being utilized in the background.

Regexes are going to be useful for me in one of the later coding projects I have planned, but they may also come in handy in my current project.  The llama book alluded to the fact that Perl supports some Python-style regexes, so I know such objects (because everything in Python is an object) exist in Python.  In the coming weeks I'll need to look into their syntax and usage in Python as I look to adding search functionality into my catalog application.

And speaking of my music catalog app, I'm in the middle of prototyping, but I'm no where near as finished with this step as I had hoped to be.  I definitely underestimated how long it would take me to implement the layouts I had sketched in my design step.  This is mainly because I start doing something I think is simple and then quickly run into problems because it's a bit more complex than I anticipated. One of the coding issues I've had is using sizers to create the layout of buttons, text fields, and other visual elements in windows.  I now understand that if you're using horizontal sizers, their inputs (flags) determine how the elements are placed vertically and vice versa.  And sizers embedded inside other sizers also influence how elements are placed, so you've got to be extra careful with the flags you've used on various levels of sizers.  I've only completed two, simple layouts as of yet, but it took me the better part of a day to figure out enough to successfully do even that.  So instead of focusing on building one dialog window or panel at the time, I started by just making skeletons of many of these elements so when it comes time to coding the layouts, I can focus more on playing with the sizers themselves.

The other issue that roadblocked me earlier in the week was figuring out how to break up my code so it wasn't all in one long, hard-to-read file.  I was operating under the assumption that this should be part of the design phase, but a friend of mine advised me otherwise.  He said that at least initially (especially when you don't have very many projects under your belt), you don't always have a good feel for the architecture of your code. As such, it may change several times in the early phases as you figure out the best place for classes and methods in the structure of your code.  He recommended writing it all in one file at first and make clear section breaks to group pieces of code together.  This has a few advantages.  First, as you work, you can rearrange things as many times as you'd like as you begin to figure out where stuff should go.  Second, because everything is still in one file, it's easier to test your code and not accidentally break it since you don't have to worry about dependencies. Then, once you've gotten several hundred lines of code written, you can break it up into different files and make sure all the dependencies work before continuing along your merry way.  I imagine I'll get to this point before the end of next week, but we'll see how well the layouts go.

Now that I've actually begun coding for my project, I've started practicing using Git. I read several threads this week trying learn how often I should be committing changes to my repository (repo).  Different people have slightly different suggestions, but I've settled on doing a commit anytime I've added a thing that works.  So this week, that's been any time I've added code for a new dialog window and successfully tied its opening to a button or menu item click (in code-speak, that's binding a method to open said window once an event is triggered by the user clicking on something).  I do all these commits locally and then when I'm finished for the day, I push everything to the remote repo on my GitHub.  Right now this repo is private, but I will probably make it public once I release my app (which will hopefully be later this year).  I should also mention I'm doing this all on a different branch than the master.  I figured this is probably a good habit to get into for two reasons.  In the event I work on projects with other people, it's good to work on your own independent branch so as to minimize conflicts in code several people may be working on.  Working on a separate branch is also a good thing to do once an application is released into the wild, as it will mean changes only get made to the code once a new version is ready to be released to users, and that is something I may need to contend with in the future.