www.codedevl.com

SimulaE Cartography Program - simulae-kaart.py

2008-06-26T21:37:00.004-04:00

As a quick follow up to the previous entry regarding rooms being a void and not an object, I can happily announce that the first working alpha of simulae-kaart has been committed to code this evening.

The function of this bit of code is simple: Produce the necessary wall/barrier objects needed to create the voidspaces we call rooms.

The current working codebase does the following already:

* Allow graphical design in a 2d environment utilising unicode representative tokens.

* Returns Multidimensional Lists designating literal start & end points of wall objects

* Allows for walls in traditional cardinal orientation (north-south, east-west, nw-se & ne-sw)

* Also allows for arbitrary wall/barrier positioning at any angle (true 360 degrees).

* Default scale based on cubic decimetres, variable scaling coming soon.

Upcoming functionality to be added:

- Auto population of a given map grid

- Auto insertion of portal objects inside any giveen barrier/wall object.

- Automatic map scaling down to the smallest micro and largest macro levels

Stay tuned for further information. If anyone else is interested in signing up for future beta

testing, I can be reached at this domain, under the email account of eric.

-e

Simulae3 Update: Room Object? What ever do you mean?

2008-06-05T22:50:00.003-04:00

This is just a simple, quick update to let it be known that the issue pertaining to how to accurately represent a room in Simulae3 has been resolved. I spent about an hour with a blank book of graph paper and pen poised in my hand and thought about the problem till the following realisation hit me:

Rooms are an abstract, a void. They only exist as a concept without substance to us. They are the empty space created by barriers, some of those barriers contain portal objects (e.g. windows, doors, openings). It is using this logic that the next piece of Simulae3 can be designed.

SimulaeKaart.py

A simple cartography-based program (kaart) being the word for map in Nederlands (Dutch). Physical space will be represented in 10 centimeter square grids (though variable map design may be possible). The whole point of this is that in the real world, we use GPS and surveying to accurately place physical locations, Simulae3 will be no different.

The other quick note is that the concept of rooms are also knocked out in that a room knows not of its purpose, it is only by human reasoning and deduction that a particular enclosure/void/"room"'s purpose can be ascertained. If you take an empty house with two rooms near the room with the stove and dishwasher, how does one know which is the dining room (if either). One doesn't, one chooses to assign that role by the placement of the appropriate objects (appropriate to a dining room that is) within said void.

Simply put, this conundrum has been resolved and the next phase of design and coding can continue.

Migraines: A common misunderstanding

2008-05-28T00:22:00.004-04:00

Mi - graine: (n)
A headache characterized by throbbing head pain, often greater on one side; may be preceded by a warning (aura) and accompanied by nausea, vomiting, and sensitivity to light and sound; in rare cases, weakness, language problems, or other neurologic disorders are associated with migraine.

Over my years of coding I've endured what I thought were migraine headaches, not uncommon to those of us who spend waking moment after waking moment staring at multiple screens as part of both work and hobby. I say "thought" because up until this past weekend, I was sure that the harsher headaches I had endured qualified as the infamous 'migraine' variety. I was wrong.

On this past Saturday, I had the pleasure of seeing one of my best friends (and also my best man at my wedding) tie the knot with his sweetheart (both are coders by trade as a sidenote). The day was perfect, the weather was wonderful (as it was an outdoor ceremony) and all was well in general. I on the other hand aside from coping with sciatica down both sides of my body (a relapse of a previous L4/L5 left disc rotation), awoke with what I thought, was one of my annoying 'migraine' headaches. I took Excedrin Migraine along with Vicodin for my other-pain and proceeded onto the wedding with my wife. The headache didn't subside, regardless of a second round of 'migraine' strength medication.

The first lesson to be learned here is that Excedrin Migraine (I'm pretty sure any over the counter "migraine" medication as well) , while great for 'bad' headaches, is lightweight against 'textbook' migraines (more on this later).

After the wedding was over and we made the drive home (hellish for me as my headache seems to have grown from annoyance to throbbing), I started to feel dizzy with a bit of nausea, yet did not succumb to an involuntary protein spill thankfully. I ended up retiring fairly early figuring that my 'migraine' was just particularly bad and was exacerbated by the fact that our table at the reception was next to the live band.

Sunday morning arrived and that horrible headache was still present. I took two vicodin and several aspirin in the hopes that it would finally kill the beast within but it was all for naught as much to my dismay, the headache only soldiered on. I spent much of the day in a narcotic (vicodin) induced stopor in an attempt to mask the pain which was at this point pressing heavily on my head, and would remain this way the rest of the day into the evening when I retired early in an attempt to once again let tomorrow come without the now 36 hour headache. Little did I know that this was about to get worse, much worse.

Memorial Day arrived, complete with plans to go to my in-laws for a barbeque and family goodness. 04:00 on the clock and I arose from my sleep to the udder shock that the pain was not only existant, but worse. I quickly (well, as quickly as I could) went downstairs to take three Advil (I was now out of Excedrin Migraine), and then return to bed, hoping this was finally the end. The time was 08:00 according to the clock and I was expected to rise. Problems. The headache was still there, and it was rather angry with me. Outside of glancing to see that it indeed was 08:00, I had to keep my eyes shut, the dizzy feelings, nausea and pain from the light (through the blinds, mind you) was unbearable. It felt as if my head had been mounted between the the grips on a vise. I at this point, took the decidedly un-male action and asked my lovely wife (and child) to get me to the Doylestown Hospital Emergency Room. Something was obviously wrong and I was quite worried, not to mention blinded by the pain.

After what seemed like an hour (when in reality it was half of that), I entered the ER and was promptly thrown in a wheelchair, tagged and admitted to ER room #5. At this point the pain caused me to writhe in pain in my open-backed hospital gown in my new metal bed. Another 10 minutes came and went, along with an increase in the pain until one of the nice ER nurses (and a doctor I believe) tapped my arm to place an IV line, which was utilised shortly thereafter to inject a medication (a narcotic of which I'd never heard) that immediately overpowered the pain with a feeling of numbness. This enabled me to speak somewhat lucidly to several nurses as well as a doctor about all of the aforementioned backstory leading up to this point.

First comes the catscan at this point to check for abnormalities. None found. Then the blood tests, no oddities either. ER Doctor then comes to the conclusion that a LP (Lumbar Puncture) was the next logical step. I consented, though it was not to be, after a considerable number of jabs and sharp pains, said doctor gave up and contacted a Neurologist who would come in later to do said LP.

The pain started to return and I was given another dose of said magic narcotic. All remained well for another 90 minutes or so (at this point, I've been in ER room #5 for approximately 6 hours). During this time the Neurologist arrived and I spoke with him and allow him to have a crack at a lumbar puncture. Needless to say he was an expert at this procedure and was able to withdrawal 4 vials of the clear cerebrospinal fluid from my spinal column. He then surreptitiously disappeared for what seemed like hours.

It was at this point, my pain surprisingly started to return, first on the right side of my head, but then started to migrate over to my left side as well. The pain became so severe that I could tell that the lights were on in the next room over (separated by a curtain), even though I had a folded over pillow case upon my eyes, with my hand over that. The lights in my room had been out since my arrival as they were painful, even with my eyes shut. I felt as if I were going to tear the metal sides of my bed clear off. I suffered like this for another 60 or so minutes as we were awaiting the results of the spinal fluid from the lumbar puncture, and it was already stated that I was given an extraordinarily large amount of narcotics already and they worried about providing anymore until they knew more about the cause of my pain.

After all was said and done, I was told that this whole episode of the worst head pain in my life, was a 'real' migraine. I was told that they would provide me some additional medication intravenously before being discharged which would 'kill the headache' this time. I was also being given more subscriptions, one for vicodin (as if I didn't have enough for my back pain, which I already try to avoid using), but a medication which i had never heard of before, specifically meant to stop migraines at their onset. That final migraine killing injection came, along with a complimentary spewing of my stomach contents shortly thereafter and I was on my way to being released. I was informed by the doctors that there were a few things I could do to keep migraines at bay aside from the medication provided.

"Caffeine, Caffeine, Lots of Fluids, and of course, more Caffeine."

I'm thankful to all of the wonderful nurses, doctors and specialists who provided help to me after suffering what ultimately will be remembered and hereafter referenced by me as the 60-hour migraine. I will never use the term "migraine" mistakenly to mean a "severe" or "bad" headache as they not only aren't in the same ballpark, they're not in the same league, region or country.

I decided to share this with everyone in the coding community because I'm sadly sure that this will happen (if it hasn't already happened to some of you) again, and to others. I hope that having read this, those who find themselves suffering one of these 16 tonne behemoths will not wait an exorbitante amount of time before doing exactly that which I did, contact professional medical help as quickly as possible. No one should have to suffer that kind of pain any longer than it takes to realise what said pain was; that being a 'real' migraine.

Wishing everyone good health.

Eric

Simulae3: A Testament to Socratic Design.

2008-05-21T00:34:00.004-04:00

Socratic Method: the pedagogical technique of asking leading questions to stimulate rational thinking and illuminate ideas.

When I first started working on SimulaE (long before it was even referred to by the aforementioned name), it was a solo project. This isn't to say that I haven't written all of the code from day one to this very moment, because I have. I can however say that the design portion of its various incarnations wouldn't have evolved in the manner which they did were it not for the diligent use of the Socratic Method.

My earliest versions of designing the Simulae virtual world simulation suite of libraries and what not were designed and written by me in response to the original interactive fiction/text adventure engines, then consequentially MUDs (Multi User Dungeons). The proof of concept of building a better designed mousetrap was simple enough to bring to fruition. This took place over years, dependent upon my free time and interest in furthering what was simply a flight of fancy for me from my programming youth and Zork playing escapades.

What really became apparent was when I worked for another company and had the pleasure to work with a very intelligent individual by the name of Tim. He is a systems/network administrator as well as a capable coder though the latter is not his primary goal, nor role professionally.

Tim was interested in my Simulae project and as such I found a kindred spirit through whom I could interact by applying the aforementioned Socratic Method. Through a constant back and forth barrage of theories and examples along with postulates about the hows and why virtual components modeled after reality need to be viewed in a certain light, we would come up with a whole new understanding about the direction of the project.

It was during this time initially working together that the present tense English Parser component (parser.py) came to be realised and produced. It took a total of seven point-releases to go from simple noun verb understanding to parsing complex compound sentences with a massive understanding of 45,000 adjectives, 9,500 verbs and multitudes on various parts of English speech. This series of productive success if anything re-enforced the validity of this methodology in the realm of software design.

It is now though, with this in mind that I have taken utilising this method to the next level and enacting it with completely uninvolved individuals (uninvolved in the sense of the projects topic and internals). In the past several days Simulae3 has emerged from the bowels of my TextMate application. The code is simple, shorter and far more capable than any previous incarnation and things are moving forward at a great clip.

This brings me to the current point of interest and a call for assistance for anyone willing to get into sometimes heated dialogue about object models. The object model system is based around the three basic SimulaeObject types. The only piece of the puzzle still causing an issue is the matter of Portal Objects (entranceways between other container type objects.)

For the sake of argument, just look at it this way: A room is a container, that leads from one room to other rooms of 'greater' building enclosure. A set of lips in a Mobile Object (hereafter MOB) (e.g. 'actor' in OO/UML terminology) is simply a Portal Object to the mouth of said MOB. A window is simply a portal between the outside 'container' object (in this case a root SimulaeObject), and the room in which our Actor/MOB would be in (to see said POB destination from said perspective).

I need others with whom I would be able to work out ideas so that this conundrum can be resolved and the next phase of Simulae can come about for code release and testing. If anyone is interested, contact me at this domain via my email address: eric

I am going to finish on that note being that due to medical reasons dealing with my sciatica, I ingested a full dosage of two Vicodin tablets (as per my primary physician), and as such I'm getting ready to crash hard. I hope to hear from some of you in the hopes of moving forward, but I'd like for Tim to give me a call in any case so that I we can bounce some ideas back and forth on these issues.

SimulaE - Model Update

2008-04-27T22:10:00.003-04:00

I've made mention of my virtual world simulation project on multiple blog entries, most recently related to Ruby and making a rewrite of the existing engine in said language to test out its applicability (the language not the simulation), which by the way I found to be the lesser language for this kind of application, but I'm not saying anything about the language as a whole. Either way, onto SimulaE, which after all is what this post is about today.

I have been rattling my brains (and occasionally those of my friends) regarding the basic SimulaE Object model, which up to this point has served its purpose. Though the time has come for it to evolve. It can implemented in a simpler manner and I have known this in my mind all along though it hasn't been an issue in the process of designing the parser which has for the most part been satisfactorily completed. Now that my focus has returned to the object model, I feel it a fine time to share that update thus far. Comments are always welcome and most are appreciated.

The fault before was that I broke the objects into the wrong sub classes. Originally I had the parent Object class, and subclasses for Room objects, Exist Objects and Person Objects. This is a horrible idea and leads to unnecessary complexity.

The newest model:

Object (super class)

MovableObject (isa Object)

PortalObject (isa Object, isnota MovableObject)

PortalObjects, hereafter POB are a much more dynamic version of the previous "room" objects. A POB behaves in the following manner(s):

1. Object(s) enter into the object containing said portal.

2. Exits an object when contained therein.

3. Can exit (when specified) to a specific object, though by default exists to the parent container object.

If a MovableObject, hereafter MOB, is not contained within the same container as the POB, POB leads into the container.

If the MOB is contained within the same container as the POB, POB leads out of the container.

By working in this manner, we ensure that the simulation object model more closely mimics the real world, whilst still allowing for exceptions to transpire for non-real world based applications of this group of models as well as anything they may be working on at CERN in Switzerland which breaks our current understanding of physics.

I haven't had time to implement this new set of models yet, but as I write that code, I will be posting the revised Python source.

Quick Django Tip: Dynamic Application Object Retrieval

2008-02-24T23:44:00.004-05:00

In my recent django adventures I needed to introduce site-wide search functionality and in the process of doing so, encountered a small roadblock towards doing so. Apparently due to the nature of Django's API for db interaction (as of the last stable release version), there is a limitation as to the use of python variables in API calls. I found this to be a hinderance, but only for so long.

The follow code snippet was something I whipped together which by utilising Python's 'eval' built-in, overcame the aforementioned limitation regarding the API's ability to interpolate native Python (e.g. non-django explicit) varaibles.

Things to know to understand the following example:

search_input is a list of cleaned and pre-processed user-driven terms, split into separate expressions, (e.g. ["dynamic langauge", "agile", "programming", "paradigm"]).

search_schema is a dictionary in which the key is the django model/class through whose objects we are attempting to search, and the value is a list of specific model attributes to attempt said search. (e.g. User_Profile : ['firstname' , 'lastname', 'address_1', 'bio_info', 'favourite_books'])

container_xref is a simple alias mapping for the actual django application names to our internal references inside this search code base. Obviously this whole bit could be written without said setup, but for readability given the scope of the actual application involved, and the fact that I was not searching simply a few static fields in one django application, but several dozen fields through about two dozen separate applications, this container_xref dict was appropriate. It is through this mapping dict which we place any matched object results (so as to not waste any additional space via unnecessary list initialisations.) for eventual results generation.

Note: the key "total_results" in the container_xref was a simple means of keeping track of overall search matches, rather than relying upon the Django templating engine (view) from doing work responsible from the processing (controller) perspective. In retrospect, there are better ways this could have been handled, and in future point revisions, this will be addressed.

------



for search_string in search_input:
  for application in search_schema.keys():
    for attribute in search_schema[application]:

      code_to_eval = "%s.objects.filter( %s__icontains='%s' ).order_by('-id')" %       
                     (str(application), str(attribute), str(search_string))
        try:

          eval_results = eval(code_to_eval)
          for eval_result in eval_results:

            if eval_result not in container_xref[application]:
              container_xref[application].append(eval_result)
              container_xref['total_results'] += 1
        except Exception:
          ### Case specific exception handler types, assignments and resultant actions 
          ### specific to each application in which the above is implemented, go here.



-----

As can be seen from the above, simple inline substitution proceeded by evaluation of said string results in post-compilation dynamic search functionalities within django, addressing simple problems one might run into with the existing API which will most likely be addressed in future versions.

Your results may vary.

Eric

Ruby: Somehow I overlooked this Gem of a Language

2008-02-19T13:51:00.006-05:00

About 5 years ago I started looking into a language that prior to it's "Rails" fame, was lesser known and even lesser utilised. I tried it a bit and found it leaving me wanting more. I've kept tabs on it over the years, reading the tutorials and writing several quasi-AI experimental applications for my SimulaE research, but I ended up being enticed by Python, a language which I stand by, including the wonderful (but until recently unused by me) framework Django (Python's Rail's equivalent, focused on Publishing).

I've programmed professionally using Python for several contracts/years now and find it quite enjoyable. In fact, I'm currently coding specifically in Python for Inkedmagonline.com, but that doesn't mean that I don't continue my personal exploration and education for both personal and professional reasons. I decided to re-experience Ruby by picking up the hallowed PickAxe book and giving it another honest chance. I'm glad I did.

I believe that Python, and the values espoused in Tim Peter's "De Zen van Python" (The Zen of Python) (my copy just happens to be in Dutch, otherwise I'd post it for others) have helped me to look at Ruby in a different light. There are some key differences in the two languages, but I can see now the inherent power in Ruby that I was overlooking before. In fact, some of those key pieces, syntactically as they were which make Ruby so enticing this time around are the very same 'features' I feel are missing in Python. It only took me working in an environment with situations where said language features would prove the best solution to the problem(s) on hand for me to realise it.

I am not going to spend time detailing all of the specifics, though I may mention one or two nonetheless. I'm more so bringing this point up so that others might be reminded that giving something new a single chance might be to your own disadvantage. After all, I didn't like Python the first time I tried it either. I think it is partially a matter of how we grow as developers that allow us to know what we're missing, that same spark of realisation that gives us the "a ha" of relief when we find it hiding in a new language, programming methodology, etc.

What brought me back to looking into Ruby a second time is of all things, Smalltalk. The whole "everything is an object" concept is nothing new to me, or to programming languages. However in dynamic strongly typed languages, it is. More importantly is manner of how even rudimentary objects such as integers, floats and strings are treated in Ruby. They have methods which can be both called using the standard instance.methodname call format, and have their standard methods overridden. The second being something far more wonky and kludgy in Python (and a non-option in perl).

The fact that key methods are instance based such as "len" or "length" for example makes a world of difference for consistency. It speaks to the overall design that "Matz" (Yukihiro Matsumoto creator of Ruby) had in mind during the planning phase. In Python, a language in which everything is truly an object as well, this starts to get rather confusing. While Python does treat every integer and string as an object, it mixes the traditional functional paradigm for calling items such as 'len' so that to find the value of 'a', one would type len(a), as opposed to the more object based a.len .. This seems counter-intuitive and quite frankly a real surprise when you look at the overall design of Python.

I'm not ripping on Python as I do wholeheartedly enjoy the language, I'm just starting to feel aches and pains over decisions which are ingrained into the language, as well as not being seen as an issue or being addressed in py3k (or Python 3000/Python v3.0) as it were. I just think that my eyes have been opened to Ruby again and I like what I'm seeing. I am actively looking to find a future professionally as it were utilising it as nothing beats having fun while accomplishing what one would hope accounts to 'great' things. We'll see what the future holds.

Next Step: Migrate my SimulaE virtual world/real model object simulation from Python into Ruby as a test run. Lather, rinse, repeat and then see what the side-by-side comparison's look like.

Until next time...

The Importance of Being Challenged

2008-02-05T21:02:00.000-05:00

In this most recent engineering, architecting and development endeavour which I simply refer to as my "job" or "contract", I have come to some conclusions which I feel require sharing. I'll be very straightforward so as to not waste certain readers' time. Many of the more seasoned lifetime coders will know (and have experienced many times over) that which I am writing about, which can be summed up as such: If you are not being constantly challenged, you are atrophying as a developer.

I often write about my own experiences as I know them better than any single other developers experience(s). This is not because I feel that I'm the end all be all of coders. Far from it, I do feel that I'm good at what I do, however I prefer to look at my writings as a form of navel gazing, a self-reflective ascertaining how I can better grow in my art and profession. It is exactly the same manner in which I'm going to proceed regarding today's message.

As I have mentioned, I have most recently jumped into a contract situation at the personal request of a rather successful life-long entrepreneur and given that the opportunity sounded rather interesting, I turned down a salaried position worth almost double because the challenge that was proposed. Please don't get me wrong, I took a position fixing a half-assed php open-source hot or not style rating system because the employee responsible by no fault of his own necessarily, and due to a lack of a sense of urgency was unable to get a system such as that prescribed, in place by a contractual client deadline. This was not the reason I took the contract, whilst simultaneously being precisely why I took the contract.

I'm not a fan of php, and most definitely not a fan of a vast majority of already written php applications open source or otherwise. What I am referring to more so is that I was brough into an environment where it wasn't the same old same old. Now I wouldn't have stayed were the job going to continually require php specifically just out of my distaste of said language. I did know that while I don't consider myself a web developer, I would be required on more than one occasion to work on web applications.

These weren't to all be simple ones either, any moderately proficient web developer and non-web developer alike could figure a good many of these solutions out. What really did it for me was that I would be required to not only work under a fairly frequent set of short deadlines due to the nature of the publishing industry as well as the time frame required to keep the site and features current.

The importance of all off these ramblings is this simple point. Being experienced and disciplined as a Software Engineer/Developer/Architect, etc. ad nauseam helps me to know 'what' I need to do, and gives me insight as to how I might go about solving an issue. It is however, the actual specifics which put those tidbits of understanding and knowledge into play which go outside a given comfort zone. It is only then, when we find ourselves in unfamiliar territory, under threat of tight deadlines coupled with our own personal desires to do our best and produce code to which we are proud to associate our name.

I know that earlier in my career there were times (albeit very few, which I can honestly say) that I too fell into this 'comfort zone'. I found out though, that this comfort zone is boring and causes one to stagnate. We code because we love it. Coding and problem solving is in our blood, and in our hearts. It is how we look at the world and as such isn't something from which we can remove ourselves.

If you only know low-level languages, learn a high level language. If you only work in functional programming paradigms, learn object or aspect oriented ones. If you only work with interpreted languages, learn compiled langauges, etc. I'm not saying give up your current lingua franca, I'm simply saying expand your horizons. The more ways you have of looking at, describing and ultimately understanding a given problem, the more ways you have to solve said problem. This doesn't solely benefit you, it benefits everyone for whom your code will be written and utilised.

You knowledge needs to be a living, dynamic pool of information, not a static, never changing one and the way to ensure that is to aggressively fight off the status quo. Be aggressive, absorb all that you can. The best way to do this isn't by dipping your toes into the shallow end of the kiddie pool, it is accomplished by putting on your goggles and climbing that high dive, plunging in head first.

Take a chance for once, you might just learn something.

Till next time..

Arc: An evolution of Lisp/Scheme, or a outdated implementation at launch.

2008-01-29T22:55:00.001-05:00

So the day has finally come in which prolific geek & insightful essayist Paul Graham along with Robert Morris released Arc, their evolutionary love child of Lisp & Scheme. I think it is safe to say that many of us have (and will continue to) read Paul's wonderful essays on a multitude of geek and coder centric topics, and generally with much joy and agreement. Many of us have been following the work that Graham and Morris have been undertaking with the new baby "Arc".

Now that this day has arrived, we can see that it wasn't as deserving of all the pomp and circumstance to which we were planning for it to be attributed. Seems that there are a considerable amount of deficiencies and intentional short comings to the language. Normally this wouldn't be seen as anything out of the ordinary for a 'new' language, and would be generally a non-issue.

The problem is that this is the year 2008 and people have come to expect more from their languages. Ignoring established standards along with ignoring the need for designing to meet the needs of developers globally all the while using the cop-out of it being purely for exploratory programming is just bad form.

The world doesn't need another Lisp, the original is wonderful just as it is, that's part of its beauty. I don't see anything in Arc that couldn't be done as functions and/or macros in Lisp that required the entire 'creation' of a new language. The way I see it is this; for prototyping as well as production usage we already have several languages that excel in those domains, specifically Lisp and Python.

Generally the idea of rewriting existing languages with little difference from their predecessor(s) is a waste of time and effort which could've been better spent elsewhere. There are exceptions to this scenario such as that of Ruby. It is a language that in the past I used to dislike because of certain key flexibilities much akin to the reasons for spaghetti perl, but it successfully fixes many of perl's wrongs, and corrects some of Pythons short comings as well. It serves serves enough of a purpose as that of supplanting perl with a better thought out design, and thanks to Rails, its future looks solid.

Arc on the other hand is like a still born fetus. Much was expected and there was potential to be just like its parent(s), but death was announced during a delayed delivery and upon further examination, it was discovered that it wasn't a proper offspring, but a clone in fetal form. My advice to Paul and Robert is the following: recall the release, and make it truly something worthy of release, with proper compatibility and compliance with modern norms. Make it usable to others as opposed to just a few tinkerers interested more in lisp and scheme basics.

An on a more pleasant note to Paul; Please keep on writing your essays and providing your viewpoints as they are appreciated, I just wish that your judgement call in the case of 'Arc' was as well thought out as your writings have proven to be over time.

The New Django Powered Inked Magazine Website is Up!

2008-01-04T14:13:00.001-05:00

This will be rather brief as it is more of an announcement than one of my more traditional journal entries.

After a short two or so months from start to finish, I have successfully setup my first Django powered website. Inked Magazine has been relaunched effective January 2nd, 2008. This replaces the Joomla powered site which existed prior to both myself and the current ownership of the magazine were involved in the project.

Phase one has been completed, with extras. The customer photo galleries, the cover photo application, the user profile system as well as the main magazine feature areas have been established and are active. As of today, I will have available for all registered users the ability to host a blog on our site (using our software which I wrote in a few days), mind you it is still early in the feature process, though it without doubt serves most blog authors needs.

I will be adding features as time progresses, but until mid-January 2008, I'm on a tight schedule to build the entire forum application so that the beginning of the "New and Improved" Inked Network can go live.

I don't think one needs Ruby on Rails when you have Django. Much of the same great functionality and without having to use Ruby all the while using Python. [Update: After having revisited Ruby as a language on its own, sans Rails notoriety, I've found that my previous assertions regarding Rails specifically was unwarranted. It simply took my experiences with Django and Python to make Ruby and Rails far clearer to me.]

I will return to my normal posting after the Forum application is up and running.

Till then, keep on coding.

Reflections on 2007, Looking forward to 2008

2007-12-31T21:43:00.000-05:00

Given that it is nary a few minutes past 22:00 on the east coast of North America, I figure it is time for one of 'those' looking back and looking forward type posts, but with a codedevl slant. This past year has been a rather bizarre one as it marks the first year of my professional career (over 13 years) in which I've been employed by more than two firms/companies. I mean technically I've only been employed by one firm, the time prior and currently I've been self-employed, so does it count?

While this isn't necessarily an issue for many others out there, it was a point of concern for me as I have been traditionally conservative in my career moves and choices. It isn't as if I'd suddenly threw caution to the wind and job hopped. I will say that it was all thanks to the federal government for starting the ball rolling over a year ago when they raided the offices of a previous employer due to nefarious actions of several of their customers (unbeknownst to any of us at the time). The government claims it wasn't a raid but a search and seizure. As far as I know, that is classified as a raid, more so because the agents were wearing bullet proof vests with guns drawn.. all three dozen of them.

I've started to obvious stray from the where I was going. Simply put I found myself working with a skeleton crew at a company for an additional five months while legally being unable to process our normal transactions, hence no hope of future work. The warnings started coming and as such, the few of us which remained knew the end was near so we all started prepping for the day when it would all come crashing to an end, an end to a wonderful half decade as a working family as it were. It took less than a week for me to land a new gig working on a project for Burlington Coat Factory and previously mentioned in a previous entry. I do have to say that I grew more as a software engineer during that first jump into contracting than I had in many of the prior years, including my time as team lead, department lead and CTO.

I brought all of this us because it lead to how I started out the year of 2007. I was finishing up my contract having successfully deployed the new point of sale returned goods system for Burlington's stores nationally. I knew when my last day would be and started to look for interesting jobs, but preferably salaried ones, which I found without trouble, so much to the point that I finished my contract on a Friday and started my next job with Blue Gravity Communications, Inc. the following Monday. As that saga has also come and gone (by my own choice), many things have changed, primarily my outlook on contracting vs. salaried employment, my work environment and my work ethic.

I found that there really isn't a major difference between salaried employment and contract employment, other than the 'false sense' of security in a salaried job. The reality of it is that one can be let-go from a salaried position very easliy, unless you're in Nederland, France, Denmark, Sweden or Norway (and a few others I'm sure I forgot). The overall benefits of being self-employed become clear rather quickly once the newness of contracting fades away. You have more responsibility, and more freedom.

You work harder to prove and build and/or strengthen your reputation, and don't mind it. You have flexible hours (at least in my case and/or other cases where on-site 9-5 is not required, which is a pretty common flexibility. You don't have to deal with as many managers or supervisors. You don't have to stress over working with a certain group of people forever. You are able to work multiple clients simultaneously (as much as you can personally handle), and finally, you truly have more control over yourself and your future than ever afforded in a salaried position.

My environment was always a sticking point throughout my various locales of employment, ranging from a room full of others in a different department, a room full of peers, a room full of subordinates (though I hate the term, being very much an egalitarian), and of course, in a room all by my lonesome. I worked many of my years in a solitary environment, for a full time employer and as such had plenty of human interaction. Yet during those years I yearned for more interaction, a room in which I could openly be around others. I finally got my chance when I became CTO and Development Lead at one company. I was able to secure an open office with no partitions and a relaxed layout.

This proved to be an enjoyable environment, but I found later on that it didn't allow me to produce my best work. Separating myself from the others didn't do much to help either. It was only when I worked as a contractor for my first time that I started to realise what my environmental needs are. I returned into the salaried world and worked side by side with some great people, even entering into the halls of foosball with one of my aforementioned peers. It was only after I re-entered the realm of self-employment contracting for Pinchazo Publishing Group, Inc. (owners of Nylon and Inked magazines most notably), that I setup my home office an came to terms with a new reality.

I work best, in my home office, alone with minimal contact from others with the exception being my request to speak with others over designs or processes changes in order to meet project/structural demands. I do enjoy the company of others but know that I work more diligently, more exacting and am ultimately more focused when in my own space. I did find however that this new environment does have its perks, one of those being flexible time to meet up with peers and past co-workers for quality time.

This leads me to my final point of realisation. My work ethic has changed dramatically for the best. To be honest I found that I was too easily distracted in other environments when a salaried employee. I had far less "in-the-zone" moments when in a workplace, and on someone else's payroll. Again I think this is due to distraction and a certain level of security (a false one at that). I'm not particularly fond of making this public admission, but at least I've recognised it and willingly state it for the record. I know what I need to be the best that I can, producing the best work of which I'm capable. Now that my reputation and future prospects rely mostly upon my current projects and the manner in which they are complete, it makes me stay more focused and on task.

I also must say that due to the lowered stress in my career at this juncture in time, I am able to enjoy my art/trade for more than ever before. When one couples that feeling of relief along with my combined experiences, gained knowledge and wisdom (or lack thereof at times), caring becomes a top priority. I care about my work, and I strive to produce the best that I can. I own the process, the engineering, the schedule and the maintenance and as such demand of myself nothing but my best, and I love every moment of it now. I know what I'm worth now, and I know what my code and expertise are worth and what it takes to ensure that I'm operating at my best.

Finally, this brings me onto my outlook for the upcoming year. Hopefully, much of the same and barring any catastrophes, I see a very promising future ahead with the current outfit for which I'm contracting. The work is exciting, doing things the right way and engineering a whole system is something upon which I thrive. I look forward to learning new technologies, I'm excited about the prospect of new advances and of course, I'm happy that I love coding and truly feel as if I've found my ultimate environment to do what I feel that I do best: Engineer great software.

Happy New Year to all, here's looking forward to a great 2008!

Eric

Django and Gant Charts

2007-11-26T23:03:00.001-05:00

It has now been almost a full week since I started the complete inkedmag.com site and infrastructure redesign in Python using the Django web publishing framework on FreeBSD, and I am happy to report that it is awesome. Mind you we're talking version .96 of the product, yet it truly is a dream with which to work.

I only recently started working with (and writing about) Cheetah, a wonderful python template engine, and had to very quickly learn yet another (Django's own template system). I must admit that Cheetah is easier to ready and learn quickly, but Django's system is considerably more agile in terms of conditionals and modifiers inside the template itself. There even happens to be a simple mechanism for cycling through a list continually changing on each iteration of the loop within which the cycle conditional resides. Simply put, it is wonderful for automatically changing the background colour of a row in a list.

For those unfamiliar with Django, it is simply one of the better web frameworks for content publishing on the web these days. While learning curve can be a little steep for some pieces of the framework, as a whole the speed at which once can produce working pages and applications is staggering. The ease and elegance of the system truly makes one enjoying creating new applications within the framework.

The first application I chose to migrate from native python into the framework was a simple store locator. The new version not only is considerably less lines of code, the database management was done for me at application creation/initialisation. I then simply exported the data from my existing application and imported it into the new table(s) Django created.

I could go on waxing poetic about every little bell and whistle, but I'd just be paraphrasing what many others have already pointed out online and otherwise. Don't think of it as Ruby on Rails because it isn't, though that isn't to be taken as an insult to Ruby. It is much more focused, cleaner and far simpler to setup and get running, including all of its own admin interfaces for the applications you create, as well as its own standalone development web server. Check it out, you won't be disappointed. This is going to save me a considerable amount of time.

Which brings me to my second point; Gant charts. They are simply not something I find myself utilising on any regular basis, though I think that is going to change. I'm my own boss and have found that gant charts produce the easiest visual way to show people the various pieces necessary for a project, when each portion can be expected to start and finish, all in parallel with the other projects for which I'm responsible (and/or coordinating).

I feel that the use of this tool more than others really gives a great method by which to see which projects will take the bulk of the time, and what projects overlap, etc. We have a system rewrite to produce and a whole server to replace, not to mention migrating certain custom software into the framework all before the new year. This is doable, but only because we've clearly set realistic (though tight nonetheless) goals and time frames. Consider using a gant chart if you have more than one project or component of a project which needs to be done in a given time frame. Use one if you need to share with one or more people your schedule and need them to understand as quickly and clearly as possible that with which you are juggling or dealing. You find yourself quickly addicted to its usability.

Where Javascript Helps the User Experience.

2007-11-12T16:52:00.001-05:00

As is well known by a good deal of the regular readers of this blog, I have moved back into the world of being an independent Software Engineer, in an open ended contract with Pinchazo Publishing Group, Inc. Their best known publications are Nylon (featured recently in the newest iPhone commercials from Apple), and the recently re-launched Inked, a tattoo-culture centric magazine, both of which are distributed globally.

I bring up all of these specifics because it marks a decidedly big shift in my own coding career. I have traditionally worked on back-end and middle-ware systems, making incompatible systems play nicely together, hardly have I ever had to deal with front ends and end user interactivity. Sure, I did the web page for Thelesis, a non-profit group, including the framework and almost all graphics, and continue to maintain that site to this very day. As a whole though, I never felt a desire to deal with the front end, I like the logic behind the interface point of view. Well, now I'm in a situation where I'm needed to make tools with which end users will interact primarily. Odd change eh?

It was at my previous employer, Blue Gravity Communications, a wonderful FreeBSD centric (with some Linux) hosting company that I found myself needing to really start to learn Javascript in order to convenience the end users in the selection processes. It was here that I started to learn more about a language with which I never thought I would have a need. I couple this to mention from a good friend about a post from a wonderful developer (my aforementioned friend's previous co-worker), regarding how wonderful javascript can be in one's toolbox.

With all of this in mind, I needed to jump into the world of user friendly interfaces. I know from my own experiences perusing the web that I know what a non-intrusive interface is like, but it really isn't best to ask developers what a good interface is all about. By nature, we are far simpler in our needs and all too willing to overlook certain practises that we don't see as a problem. Keep in mind, many developers, myself included, still prefer command line interfaces because of how much quicker they generally are.

I've already called upon javascript for certain pre-submit form checking, which is ultimately a convenience to the end user because it saves them having to reload the page, or worse off, play hit and miss with multiple loops of the process of submitting and seeing what was wrong with their form submission. This is a very unfriendly approach in 2007 which is sadly still utilised by many large web based corporations.

This time was different as I was coding the first version (what I would normally tag as a beta) of Inked magazine's online tattoo gallery. The concept is simple, allow users (and store owners) to upload tattoo photos for general viewing on the website, and if a specific photo is from a tattoo shop/parlour in our tattoo shop database (covering 4 out of every 5 shops in the United States), make a link to that shop so that browsers of the gallery can associate certain quality work with a given producer of body art. Very simple, great use for your standard LAMP (in this case BAMP [BSD, Apache, MySQL and Python]) configuration.

However, end users could care less about the underlying technology, they care about ease of use. It was with this mentality in mind that I approached the gallery's first incarnation. Limit the amount of non-photo graphics (for speed), limit the amount of time a page actually needs to be refreshed and/or requested, and make the controls relevant and simple to understand.

This was (I believe successfully) achieved by use of a strong reliable template engine for the purpose of controlling what user control elements were presented for navigation on any given screen. Ultimately, if a person is browsing paginated libraries of content, we only wish to have he navigation controls relevant to where said individual is in their browsing activities, visible. Meaning that if a person is on the first page of a five page gallery, don't render the button that links to the first page, and don't render the button which links to the previous page (as it is non-existant). Likewise, we don't want have buttons for the "next" page, or the "final page" when we're actually on it. This may seem logical, which I'd like to think it is, yet so many seem to overlook these kinds of details. These are details which can cause frustration from users who unintentionally click on a button which goes to the same page they are already browsing, or in the case of a "ghosted" button, make them wonder why it isn't working at all. Only present that which is needed, and nothing else if at all possible.

More importantly, and even less obstructive, javascript for auto-zooming the photo gallery images themselves without having to pop-up a window, or even worse, replace the current viewing page with a simple image link or dedicated page with headers and footers in addition to the image. These elements are time killers, and javascript is one wonderful way in which to resolve the problem. Not only does this kind of visual add an interactive feel to the page(s), far more similar to the way a user would experience their own operating system (especially these days with candy like OSes), but it means they aren't hindered by unnecessary delays and can focus clearly on that for which they came to the page in the first place. To view photos of tattoos that interest them, or share theirs with the world.

Cheetah, Python's Powerful Template Engine

2007-11-07T20:46:00.000-05:00

About six months ago I wrote an entry about using the Template Toolkit for perl, and how I found that it was almost as if giving perl a little taste of Python. Now, fast forward to present time and I find myself as my own boss once again and in a dedicated open-ended contract with Pinchazo Publishing Group for Nylon Magazine and more recently, Inked Magazine. This opportunity has also proved to be beneficial for me in that I get to choose the technologies with which to arm these businesses moving forward for their presence on the internet.

This brings me to some realisations to which i came today. Python's template engine "Cheetah" is considerably better than aforementioned Template Toolkit for perl. I'm currently writing a new online gallery application using Python, MySQL, Javascript, CSS and of course HTML on a BSD server running Apache 2.2. Today was the first actual coding day for implementing my design, and while there were certain changes of some underlying routines, I have to say that it is moving along much quicker and smoother than alloted/anticipated. I attribute this heavily to the ease of use found within the Cheetah library.

Some template engines add a quasi familiar set of language constructs which make using such a system doable but with that kludgey feeling. That is not that case with Cheetah and in true Python fashion, it integrates using constructs that closely parallel the standard Python syntax, as well as offering several additional alternatives to help adapt in various situations and code bases.

The beauty of using template system (as has been said before) is that you add an additional layer of separation of code from display to the point that in team/diverse environments, the coders and artists don't interfere with one another. A simple protocol of self-discipline for each individual to stick to their roles ensures that both content and display functionalities can be developed, and changed simultaneously without concern over coordinating the end result. The busier the schedule, the crazier the deadline, the quicker (and with a much higher level of confidence and lower level of stress) that a project can be implemented/modified/redesigned.

Once the gallery is fully operational, I will be updating this post to add a working link to the site. It should only be a few days from the committal of this blog entry, so keep up to date by subscribing via the codedevl rss feed (courtesy of atom).

The Importance of Developers' Social Circles

2007-10-31T22:40:00.000-04:00

I just received a phone call this evening from Philip F., a previous quasi-co-worker (an employee at a software shop for whom I used to contract) and we took some time to catch up on how things have been in both of our personal/professional worlds. I took the time to explain that I was no longer working as an employee for a New Jersey based internet hosting provider, and he informed me that he was now teaching some of the same classes on web based coder that he himself had just completed as a student. Just for the record, he's been coding for almost two decades, it was more of a catchup on certain technologies with which he didn't focus on professionally.

This eventually led into the topic of getting plans together for grabbing dinner together, as our previous plans to do so were disrupted at the last minute and we'd not had the opportunity to reschedule. We're going to do so this time and it made me think of how important it is for developer/engineers and architects to spend time face to face, even over something as ubiquitous as dinner. We need this kind of camaraderie as a means of acquiring new information that while not directly affecting each of us in the same manner, it does provide us expanded horizons.

Getting together over some nice Indian, Thai or Moroccan food while chatting away aimless on topics as innocuous petty work incidents to full blown coding feats is a means by which we as a community of software professionals bond. It is this circle of connections which proves to be the most rewarding in terms of contacts for future work, but more so importantly, for our own social well being, knowing that others share some of the same pains prevalent in the coding environment through which we endure to produce wonderful products.

This reminds me of many, *many* years back when from 1987 through 1996 I owned and operated an electronic bulletin board system (BBS) called Somerton Telecomm International BBS (also known as Somerton Telecomm as well as Somerton BBS). We had 6,000+ verified users in 39 countries and 42 US states, 12 phone lines and a very active user base, but ultimately it was the weekly dining get-togethers at 01:00 in the morning at locale eating establishments (the great Northeastern United States collections of diners as it were) to munch on food whilst blabbering away, in person to others on various topics of interest to all those involved. We would spend hours, sometimes longer just go off verbally on anything and everything online related or otherwise.

It is exactly this kind of face to face interaction that helps to grown the world view of a given coder, as well as assist in the act of interacting with others in a more relaxed environment. So I suggest to everyone out there, contact previous coders, architects and/or engineers with whom you've worked and arrange to get together over a glass of wine, or a formal meal, and simply enjoy the company of a peer with whom you can speak openly, about so many varied topics. I'm sure that there are more than a few topics via which you can converse happily.

Don't wait, take action today, your mental stability will thank you.

Apple OS X 10.5 Leopard Upgrade Experiences

2007-10-28T17:55:00.000-04:00

Just a few days ago, on 26 October, 2007, I received my 5 license copy of OS X 10.5 "Leopard" via FedEx. I quickly wanted to share my upgrade experiences to this, the newest incarnation of Apple's Unix operating system. I say Unix with a capital U because as of this newest version, Apple joins the ranks of HP, IBM and Sun as having a fully certified (Unix 2003 Standard) Unix operating system. No longer is it simply "Unix based" or "Unix Like", huzzah to Apple for this endeavour.

The upgrade was simple enough on my primary machine, a Core Duo MacBook Pro with 2 GB of ram. Inserted the Dual Layer DVD and walked away. Everything was updated when I came back, and after all of that, only two simple plugins didn't work 100%, Growl, and SizzleKeys for iTunes. Either way, the Growl team is working on this, so no worries.
Before I go into my experiences, I will state that when I went to upgrade my son's Quicksilver (PowerMac G4 933), I found that the DVD drive (being a previous generation) was rejecting the DVD so, being thankful that this was a Macintosh, I didn't panic. I pulled out a firewire cable, plugged on end into the PowerMac and the other into my MacBook Pro. Held the T key down on the MBP, Powered on, and the PowerMac now booted into Leopard from the MBP's DVD Drive. I decided to do a full install from scratch for this computer and it proved to be almost as quick as the install on the MBP.

The first thing I noticed upon booting was the finder, and how it auto mounted all the computers in the network that it could find. This was all done in the background, via separate threads in the OS, so no locking up like previous editions. It even found and mounted window shares (I have to say that the icon for a windows share (a BSOD or Blue Screen of Death)) is rather an amusing jab at MS. As juvenile as it is, it made me laugh. In our house, serious machines for Software Development, Art, Music, Work, et al, are all Macs and the game machine (for Civilization 4) is a windows box. Accessing any of those machines was simple and quick. And since I had setup my son's machine with Parental Controls on, I was even able to click a button to share his screen via a VNC connection. Very smooth Apple, VERY smooth.
Time Machine is as simple as it gets. There happens to be, connected to the PowerMac, a 160 GB firewire external drive hooked up which Time Machine instantly saw and after accepting its choice, everything was done in regarding to backing up the machine on a regular basis. I've yet to restore any documents, but I don't doubt that it will work exactly as advertised by Apple, as so many other things do (if they didn't, I wouldn't be working on Apples, but back on a FreeBSD machine).

Coverflow and Quickview are options that I can already see as coming in handy. While graphic intesive and eye-candyish, they are nonetheless very useful.
The multiple desktop features which has been around in KDE and Gnome amongst other window managers for ages is finally available on the mac, though now that I work on a multi-display setup most of the time, I don't see myself as using this. My 1440x900 & 1600x1200 displays provide sufficient real estate.
There are many more features which I could discuss in great depth, but I'll leave that after I've utilised them more.

In Buildings and Software, a Poorly Designed Foundation More Oft than Not Leads to Disaster.

2007-10-13T20:05:00.000-04:00

Recently I’ve had the misfortune of being exposed to a multitude of software packages constructed in PHP and I have to say that I am very disappointed. I’m not talking about the language specifically as it is capable, even though I don’t particularly care for it. I’m talking about code that unless run in absolutely perfect conditions (a.k.a. the developer’s box), the code fails to work as described by said developer. This point alone stresses the importance of proper testing and the benefit of peer-based code review.

I have noticed this issue as being more common in what I refer to as the ‘lazy languages’. These are your weakly typed dynamic languages, specifically those lacking any real enforcement of data constructs, and lacking proper exception handling. The lack of these two key language features don’t necessarily cause bad coding to transpire, but what they do is allow poor programmers (and non-programmers alike) to continue on with poor practices because nothing (on the compiler/interpreter end of the code) will dare to call said programmer(s) on his/her problems. Careless coders will naturally gravitate to these languages as it lets them continue to live in their own little make believe world, the world in which they are competent coders and/or designers.

This isn’t to say that there aren’t good or even great coders that didn’t start out in the same manner as mentioned previously. It is all part of the learning process through which we grow. This isn’t exclusive to coding obviously, but it most definitely is applicable. The most important point which I need to stress is that recognising poor habits and working to eradicate said habits is paramount to becoming a better coder. Don’t wait, act now. The code you save may be your own.