Announcing the CodeDevl.com Podcast

I’ve been writing on matters of a computer centric theme on and off for roughly 18 years, I figured it was time to compliment my ramblings via a different medium.  First and foremost, I do this knowing full well that I post these words more so as an act for myself as a personal journal pertaining to my primary field of interest.  Secondly, I post with the hope that a few others may find humour, warnings and/or lessons to learn in what I have experienced.  

That being said, I’ll give a basic rundown of what a listener to the codedevl.com podcast can expect.  The first dozen or so podcasts will be slightly more verbose variations of the existing codedevl.com journal entries, with the eventual hopes that I will have guest software engineers whom i’ve come to know over the years.  I am also making it known that while this site doesn’t currently allow for interactive comments, audio responses are welcome via email addressed simply to eric at codedevl.com. 

I appreciate those of you who continue to follow the various happenings and writings (and lack thereof) at codedevl.com, and just want to let everyone know that I do have several things waiting for future release dates.

  

Future Aspirations.

I recently had dinner with a previous pseudo-co-worker from my previous contract to catch up on things since parting ways.  I say "pseudo-co-worker" because ultimately when one is a contractor, he/she has no co-workers with only the exception of other contractors on the same project for which they were contracted.  He works for a software production firm primarily in Java, and that little tidbit of information started me thinking.  What I have wanted for all of these years in the profession was to work for a software house.  

I know that some of the open source crowd are going to say "why not contribute to new and/or existing open source project?" to which I simply point out that is isn't the same.  I have written and distributed code under both the artistic license as well as the BSD license, but ultimately it isn't solely about the code, it is about the environment.  Right now, I work in an environment in which there is really one person with whom I can speak and joke regarding code and geekdom in general, and I enjoy that.  I do know however, that much like my previous work associate, I want the whole environment, surrounded by other coders of varying capabilities and disciplines.  

I'm sure some might imply that I have a sort of fantasy view of these environments, but I beg to differ based upon the opinions of others that I know personally.  There is a certain camaraderie in highly skilled engineering/creative homogeneous work place environments which just isn't found elsewhere.  If anyone reading this has ever had the opportunity to read any blogs from the original coding group at Netscape or Apple, you'll know full well as to what I'm referring.

I know full well that there are high stress time periods at those companies and that more so those environments are more conducive to non-family-life encumbered employees, but there are definitely exceptions as such.  

Either way, back to my friend.  I think he pointed out something to me that I feel would me help with my, dare I say, professional environmental depression, that being -- attending programming/tech conferences.  Back in 2000, I attended Linux World in New York at the Jacob Javits Center, and then again in 2001.  It was a blast, by and far.  I do have to say that 2000 was a much better event than 2001 not only because of the IBM sponsored rave, BattleBots, and free (as-in "beer") bar, but because of the people there.  It seemed to go quite a bit more corporate in one single year.  I met many interesting people during those conventions, and even received several job offerings as well, though I didn't take any, as much as I should've since a few were at software houses.   Either way, I've lost my focus of this post, but I can say that I've made it a personal resolution to start heading to more developer related cons, now the questions are, which ones?  PyCon?  JavaOne?  LUG Radio Live (US or UK)?   I guess time will tell.  

Python's 'Pickle' Module

Recent changes to the SimulaeObject class have proven to be a big leap forwards in regards to flexible object manipulation for both testing and live environments.  The issue at hand was in regards to how to load and/or save object 'types' as it were.  Initial thoughts were to go with a simple configuration file which contained each and every object a la something akin to the httpd.conf file from Apache 1.3 (& 2.x?) for handling virtual hosts.  Then it dawned on me that this was a mistake which I personally made once before, and was almost about to fall victim to once more.  

The solution was sitting right in front of me all along, the standard library's 'pickle' module (or alternatively the 'cpickle' variation for speed's sake).  Due to the issues presented in a virtual world simulation the topic of object blueprints and simulation population ease come to mind rather quickly.  The best environment for manipulating these new objects will ultimately be via the methods provided by both the the SimulaE package (SimulaE.loadObject(filename_to_load, [optional_load_path]) as well as at the code level in the parent class in SimulaE.SimulaeObject.saveObject(filename_to_save_as, [optional_save_path]).

By going this route it has been realised that a simple loop and/or script-like routine could be used to create all the generic object templates needed for design platforms, and for customisation all one need do is use the loadObject routine, make the necessary alterations and re-save said item as a more concrete, concise and specialised object, named appropriately of course.  

Let us take an example of a room type object (more simply put, a larger container object).  We'll use simple constructor information here for the sake of staying on focus.  We're going to make a 4 metre x 5.5 metre dining room, with a 2.75 metre ceiling, simple called "Dining Room".  It will be empty sans an already pickled to storage butler object we've created for the sake of this example (whose filename is simply "butler_jeeves"), though future discussions on SimulaE's container and stack loading methods are forthcoming.

import SimulaE

generic_dr = SimulaE.SimulaeObject(name='Dining Room', width=4.0, length=5.5, height=2.75)

generic_butler = SimulaE.loadObject('butler_jeeves')

generic_dr.addToContents(generic_butler)

generic_dr.saveObject('diningroom4x5.5x2.75wButler')

We now have a pickled version of this generic dining room of the aforementioned dimensions, sporting its own copy of Jeeves the butler, saved to a physical file on whatever storage device we're set to utilise.  We can overwrite said object by simply saving the item with the filename as it exists on whatever storage device is in use.  There is also the flexibility of specifying alternative file save and load paths with allow for multiple parallel simulations and/or individuals to work in safe separate but equal spaces, very much along the lines of a Unix mentality.  Another advantage by working in this manner is being able to create a path full of simulation objects and copy said path en masse for alternative and/or backup purposes.

Either way you slice the pickle (module), it proves to be quite (ful)filling, making one feel quite (programmatically) satisfied.

Java Redux. Redux.

I was perusing the internet last evening to pass the time before getting into a vicious round of Champions of Norrath : Return to Arms with my lovely wife.  I had Java on my mind for a bit of the commute home and as such decided to do a bit of googling.  For whatever reason, I decided to lookup “Java for Python Programmers" much along the lines of a great "Perl to Python Migration" book I'd acquired years back.  To my utter shock, results were actually returned.  

This whole 'ordeal' with Java has been going on with me for something over 7 years.  I started teaching myself Java way back when, but found it to be utterly too verbose for productivity, opting for perl in its place.  Then perl very quickly proved to be lacking when it came to large projects, and code cleanliness (by design mind you, I have written production code which after 7 years upon seeing it again, was very easy to follow in spite of its 7,000+ line codebase), and utter hackishness about it, regardless of the raw power.  I moved to Python both personally and then shortly thereafter, professionally where I enjoy myself most.  

However, there are certain things I've come to realise over the past many years, more so over the past few specifically.  One is that I should force myself to code in one of the behemoth languages to the point of solid fluency regardless of how dreadfully painful it can be.  Two is that most jobs are hybrid these days and require a wider set of disciplines in terms of technologies, languages and toolsets than in the past, and whilst I don't have any need for Java in my current work endeavours, it doesn't negate said need in the future.  Three is that Java makes the most sense being that C/C++ are for all purposes outside of hardware tied code (such as operating systems, device drivers, compilers), dead for application creation, period.

And so it is that I venture forth again into the wonderful realm of re-re-learning the evil behemoth formerly known as oak.  May she not be as cruel a mistress as in the past as my understandings of her workings have been greatly enhanced thanks to python sharing so many of those conceptual designs and paradigms coupled with my adoration for the latter language.  

Wish me luck.

Check External Data/Configurations First.

I was recently on holiday with my family visiting other members of my family as well as friends.  It was at this time I pulled out my trusty MacBook Pro, fired up TextMate, pulled down the newest subversion repository of my simulation software 'SimulaE' and attempted to show my friend the crafty english parser component I wrote.  I showed him the test suite with all of its various scenarios and then suggested he throw an attempt at it so that he may be amazed at its crafty logic.  

He did, and it failed, and I was surprised to say the last.  So given that I was on vacation, I wasn't going to focus must time on this issue other than updating the subversion repository so that I could look into the issue at a later time.  Well, two days ago I finally did so, and found out after careful checking that one of the datafiles utilised for cross checking and sub classifications of parts of speech of english lacked the necessary word (also the culprit of the mis-parse).  After making a quick addition to the aforementioned lookup file, the test ran just fine, and passed with flying colours.  

Lesson learned (for what feels like the millionth time);  check your support configuration and/or data files, because your code isn't broken, just doing what it is supposed to, based upon the information it has available (data files) to it.

Present Tense English Parser : Part I

As part of an ongoing project during which I have been designing, building and testing in one way or another over the past decade and a half, I have arrived as the parser phase.  Well, I will correct that statement.  I have tinkered with creating parsers before, but thanks to the expressive nature of the Python language, I was finally ready to make a serious attempt at writing an English present tense command based parser.  I'm not going to make a massive post about this, though I am going to post the test results.

Note, all the tests pass.  What a passing result actually means is this; The parsers job as of version 0.5.4 is to break apart the sentence(s) properly into their components via identification of verbs, conjunctions, prepositions, articles, conjunctions, pronouns and punctuation.  

Creating Parser Instance:                                                                                  : Passed

Loading Configuration for Instance:                                                                 : Passed

Testing for version: 0.5.0 

  paint the gold bucket black                                                                             : Passed

  get the big , heavy hammer and kill Bob with it !                                           : Passed

  get hammer and squirrel from Bob and then hammer squirrel into the wall .  : Passed

  get the gold gold                                                                                             : Passed

  kill elf and get gold                                                                                         : Passed

  paint the bucket gold                                                                                       : Passed

  paint the gold bucket black !                                                                           : Passed

  get gold                                                                                                            : Passed

  kill elf , get gold                                                                                              : Passed

  get the large gold brick .                                                                                  : Passed

  paint the bucket gold .                                                                                     : Passed

  get the large , gold brick .                                                                                : Passed

Testing for version: 0.5.1 

  get rock , pliers , hammer and squirrel and hammer squirrel into the wall .     : Passed

Testing for version: 0.5.2 

  kill the trite little elf with my sword , then wipe the blood off of it !                : Passed

  destroy the cantankerous creature before you eat your dessert                        : Passed

  kill the trite little elf with my sword , then wipe the blood off of my sword !  : Passed

  kill the trite little elf with my sword .                                                               : Passed

Testing for version: 0.5.3 

  hammer the hammer into the big hammer                                                       : Passed

  hammer the hammer into the hammer                                                             : Passed

Testing for version: 0.5.4 

  kill the trite little elf with my lavacious sword , then wipe the blood off it !   : Passed

  go to the store and buy a new cellphone                                                        : Passed

  slit Fred's throat and capture the warm , red blood in a cup !                         : Passed

  play with my toys and listen to my music .                                                    : Passed

  play with my toys and listen to music .                                                          : Passed

As can be seen, the variety of possible inputs for the parser vary from simple to complex, from grammatically perfect to questionable fragments.  Being that the purpose of this parse is first and foremost for use in a command environment in which interaction is needed, thus the present tense only requirement.  This is a massive relief on the demands of the parser, but even still, it can be see from the above that the system can differentiate key words which can be used in both noun and adjective forms.  The system also handle post adjective usage.  

The system currently most notably recognises over 9,000 verbs (regular and irregular), 50 prepositions, and a whopping 46,000+ adjectives.  A call for test case phrases is hereby announced.  I am satisfied enough with the stage one parse process that I hereby am moving on to the second parse stage, that is the creation and order of individual statements (as dictated by their prepositions), in preparation for the third and final stage, in which the parser sends the results from stage two to the action engine.  Both those phases will be the subjects of new posts, accordingly.

Thinking in Lisp (with respect to Bruce Eckel)

It isn't what you might think based solely on the title of this post.  Bruce Eckel of www.mindview.net isn't coming out with yet another book prefixed with "Thinking in"...  or maybe he is.  As far as I know though, he has yet to, nor is he expected to write one on Lisp.   

On a quasi-regular basis I make the effort to learn something new in the realm of computing whether a concept, paradigm, and/or language.  I decided that given my past experience and interest (since I was considerably younger) in artificial intelligence programming concepts coupled to early leanings towards Prolog, a French born AI/logic language created around the same time as I was back in the early seventies, that it was time to return to my roots.  This time around I decided that after being an emacs junkie for so long, that the obviously choice for me this time around would be the Lisp functional programming language.  

Now the point of this post is not to go into the semantics of the Lisp language but to stress a more important point which I feel would be of greater value to any and all who might stumble across these pages.  Learning to think in Lisp changes the way you think about code logic.  I'm a fairly big proponent of OO design and programming, though I ultimately believe in using the right tool for any given job/project.  Lisp has a wonderful simplicity about it, a simplicity with a considerable amount of power behind it.  

The concept is not unlike Unix methodologies.  Simple, small programs which do one thing, but do it exceedingly well, which can then be piped to one another to do larger tasks.  Mind you this is slightly different but not by much.  Lisp works dealing with functions (and lots of parentheses).  You string together multiple simplistic functions together to produce more complex functionality.  A simple example might be finding the average of two numbers.

(defun AVERAGE (x y) (/ (+ x y) 2.0))

defun is used to define the function with the given name "AVERAGE", followed by its parameter requirements.  The actual body of said function consists of doing a division operation (/) by 2, against the results of an addition function (+) of the two provided parameter.

I feel that this example while a little simplistic does at least point out the basic mindset of Lisp programming, which still hold consistent with my above statement on its likeness to Unix shell mannerisms.  While I don't see myself coding entire systems (on a regular basis at least) in Lisp, I do have admit that I'm going to continue my studies on this language as I have been finding that my perspective has shifted thanks to learning this new and different programming paradigm, which ironically isn't new when it comes down to it.  It was just pushed aside to make way for the 'next great thing™.'

I heavily recommend some of the freely available books and information on learning Lisp and its concepts as listed below (Note: All items are PDF formatted for convenience):

Practical Common Lisp

Common Lisp: The Language

Common Lisp: A Gentle Introduction to Symbolic Computation