PyCon 2010
Labels: Conventions, PyCon, Python
Labels: Conventions, PyCon, Python
Labels: Bad Design, Dynamic Languages, failed language implementation, Python, Ruby, Speed
Labels: Hacking, OOP, Pascal, Perl, Professionals, Python, Rexx, Ruby
Labels: Django, dvcs, Hg, Mercurial, Project Planning, Python, version control systems
Labels: Burlington Coat Factory, Django, Engineering, Ethics, H-1B Visas, principles, Python, software engineering
Labels: Alpha, Automation, Beta, Cartography, Coming Soon, Kaart, Maps, Metric, Python, SimulaE, Update
Labels: Algorithms, Design, Objects, OOP, Python, Refactoring, SimulaE
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.
-----
Labels: Code Evaluation, Django, Dynamic Languages, Post Compilation Dynamics, Python
Labels: Development, Dynamic Languages, Engineering, Guido van Rossum, Matz, Objects, OOP, Python, Ruby, Smalltalk, Static Typing
Labels: Arc, failed language implementation, Lisp, Paul Graham, Perl, Python, Robert Morris, Ruby, Scheme
Labels: Django, Inked Magazine, Joomla, PHP, Python, Rails, Ruby
Labels: Cheetah, Django, Engineering, Engines, GANTT Charts, Project Planning, Python, Rapid Application Development, Ruby, Scheduling, Team Projects, Website Design
Labels: BAMP, BSD, Design, human interfaces, Javascript, LAMP, MySQL, Python, Rapid Application Development, Templates, usability, user friendliness, Website Design
Labels: Agile, Cheetah, Perl, Python, Rapid Application Development, Team Projects, Templates
As was mentioned in a previous entry, I stated that I was willing to try being an independent contractor again sometime. That time is now. As such, my new corporate overlords are a media publishing group and I’ve been called in to do a ground up architecture and engineering job, along with continued long term maintenance. Unlike before this situation appeals to me because it lacks on of the most common issues in the realm of development in general, legacy upkeep. Sure, there is the little issue pertaining to a php application which needs to be put on a website short term, but after that we’ll be trying to limit php to specific applications on a limited (only as-needed) basis.
Ultimately we’re looking at starting with a fresh new remote server and that being said, my own experience brings me down to a quasi LAMP setup. Traditionally I’ve found that when I want a rock solid remote host, one which I know can go years on end in a reliable manner, I chose FreeBSD. Nothing against Linux other than I find it fine for a Desktop or a Server, but more so the desktop than the server. I find that there still is no substitue for Apache when it comes to matters related in pushing out pages to the web.
Next is a point of contention, the database. I’ve been using MySQL since version 3.23.24a (or something around that revision number), and have found that it met my needs about half of the time. Much of it (at the time) revolved around the issues pertaining to MySQL’s myisam faults and weaknesses regarding concurrence in high insert/update environments. I know some people out there (many actually) will start arguing this point right away, and I still say unto you that this is a known weakness. The myisam database storage engine is designed for speed, not high-concurrecy, nor transaction safety. When paird with the InnoDB engine, and the removal of the auto-commit flag (as it negates the whole point of using a transaction safe engine), most of those issues disappear. The other issues pertain to foreign keys, store procedures, etc., which have been slowly addressed in versions since the 3.xx base. Now we’re at the 5.xx family and much has improved.
However, all of these points still cause MySQL to pale in comparison compared to PostgreSQL. True, MySQL has proven to be very capable and very popular, especially among the Linux crowd and cheap hosting crowd. I will be installing MySQL on the new machine to handle support of third party web applications, though when it comes to hosting any important data, there can be only one choice, and it isn’t MySQL. PostgreSQL is the clear winner here, the closest db engine we have to Oracle without being Oracle.
Finally, we approach the last letter in our acronym. The ‘P’, which can stand for a multitude of langauges scripting, web and otherwise. We have PHP which is wonderful for quick and simple (an a handful of not so quick and simple) web based applications. It is an easy language for the novice to learn, and in the hands of an expert, even more so capable, though it has its faults, and among those security being the top. Much effort has been made (especially post 4.2.3 and 5.x versions/trees, and I hope to see this evolution continue, though I still don’t see myself using it much as I don’t feel compelled by the language as a whole.
Next we move to another ‘P’, which in actuality is a ‘p’, perl. The oldest of the languages we’re discussing here, but not by that much of a time frame. Perl grew out of the personal needs of a C programmer, Larry Wall as a combination replacement of both sed and awk (amongst other Unix utilities). I’ve been paid to code in Perl for the better part of the past 11 or so years, and I can say after all of that time several things. On the good side, perl is found everywhere, has a large code base, and is fast. On the bad side, I’ll have to limit my dislikes and faults found within perl so that this entry doesn’t go on for thousands of words. Limiting my issues with perl we will see that it allows, almost seduces people into writing ugly, cryptic code. Yes, yes, yes, the code some perl monks/mongers write may be very crafty. Crafty does not equate with great, let alone good quality.
All too often we see people referring to the TIMTOWDI (There Is More Than One Way to Do It) mindset of perl as being a benefit, though I see it (time and time against, countless of codebases later, even the CPAN library) as being a flaw and weakness. If you don’t enforce a certain level of clean design into the language itself, you end up with a mess, or as many others have stated, a write-only language, one which even the author(s) of programs cannot read/decipher down the line. My suggestion is for perl coders to follow Java coding guidelines. I mean, we’re talking about a language that doesn’t has several decent levels of rules and coding enforcement (such as the ‘use strict’ pragma), but is so foolish as to allow people to code in a manner contrary to that pragma when it already exists in the core language. How about a proper exception handling system? Eval blocks or non-core/second-class libraries do not make a proper first class handling system. This is asinine in a language that has been around for over 20 years as of this writing. I could go on, but I’d rather not.
This brings us to a non-p ‘P’ in LAMP, Ruby. Ruby to me is an evolution of perl in many regards, especially its object based design and proper exception handling system, however it still fails miserably in the sense of massive overuse of tokens and pascal-esque verbatim block terminators. Rails has made Ruby a mainstream language, and I do feel that it has considerable potential ever more so than Rails alone, but it still has a ways to go when it comes to speed and cleanliness. Matz has be working hard on it, and I’d like to think there are great things ahead for the language from the land of the rising sun, but at the current moment, I still find it lacking as non-web specific development platform.
Finally we come to where I’m heading, and I’m sure others have already figured that one out. Python rounds out the last ‘P’ in the equation. Python is almost as old as Perl, and is rooted in development languages as opposed to the shell and various utilities. In this language we see a very capable, 100% object-based development language which is capable of handling coding projects of any size which espouses clean design, human readability, code re-use, distributable byte-code compiled classes/applications and proper exception handling as a first class citizen.
So as we can see where, the solution i find most reliable and long-term maintainable with minimal development time, maximum return for design/coding efforts, security and platform flexibility is simple. So it isn’t technically a “LAMP” solutions, more as it is a BAMPP solution encompassing BSD for the OS, Apache for the web serving, MySQL and PostgreSQL for the database(s), and Python for application development.
I came to the above choices after years of experimenting and experiencing and I do suggest others experiment on their own if they have that luxury/time frame available to them, but I do offer the above as a recommendation as I would (and have, and will) bet my own future livelihood on the flexibility and reliability of the aforementioned combination of technologies.
Labels: BAMP, FreeBSD, InnoDB, LAMP, MySQL, OS, Perl, PHP, Python, Ruby
I’m not sure as to whom to attribute the following statistic, but i believe it was something along the lines of this; Code is read vs. written on at a 10:1 ratio, meaning that the is far more reviewing of any specific codebase than there is writing to said code. Furthermore, the majority of software positions involve maintaining and modifying existing code as opposed to creation of new code from the ground up.
To what does all of this allude? The importance of writing clean code. Knowing full well that other developers are going to have to read, understand and most likely modify your code in question at some point(s) in the future. This is where our responsibility as software professionals (even in the case of hobbyists) comes into play.
Several languages have tried to address this problem by intrinsic design decisions. Most notably among those in recent times are Java and Python. Java does so by its explicitness by design, and Python by its forced formatted a la the whitespace requirement. Both are effective in what they do, however there are still a multitude of ways in which both can be written in a harder to read format. Obviously choice of variable, function, class and object reference names is a very large point of readability (or not) which really cannot be enforced by a language specification. Let us take a look at this very issue and while we’re at it, i’ll be clear that this is not a Python vs. Java issue discussion.
All too easily so many coders (I know this from having had to look at, understanding and refactor their code) overlook one of the best sources for building readable code, and that is their naming convention. There have been several best practices and coding style specifications documents produced that one might think me as flogging a dead horse, but I assure you this is not the case.
In the following examples we see a variation of languages and how we might commonly see the same variable name referenced (and initialised as it were):
Smalltalk:
num_of_doors = 4 ;
Python:
numberOfDoors = 4 OR numDoors = 4 OR number_of_doors = 4
Ruby:
numberOfDoors = 4; OR numDoors = 4; OR number_of_doors = 4;
Java, C#:
int numberOfDoors = 4; OR int numDoors = 4; OR int number_of_doors = 4;
Lisp:
number-of-doors := 4;
C, C++:
int intNumDrs = 4; OR int num_drs = 4; OR int int_drs = 4;
Perl:
my $vzoiuwriozufsd = 0x04;
The point here is that there are many varied ways in which the same variable can be referenced. I am of the opinion that much along the lines of Guido van Rossum of Python (and to a lesser extent ABC) fame, that there really should be one and only one obvious way to do it. This isn’t to say that I think everyone should code in the same language, and speak the same tongue, etc. What it does mean though, is that to be understood by others (and sometimes by ourselves), we need consistency, and unless we have a set of strict guidelines set out for us as software engineers, developers, etc., we might as well code in our own made up dialects.
I am of the opinion that a proper interpreter, compiler, virtual machine, etc., should be more than capable of quickly turning long variable, class, function and method names into concise tokens with small internal footprints. So much to the point that there is no excuse for not being verbose. At one point in time, every single byte of allocated memory for names of the aforementioned items was a crucial issue which required extreme concise naming conventions to be followed. Those times are gone in this day and age, allowing us to be clearer and more expressive.
I can see using single letter counter variable names, but never could I imagine naming a class, method or function in such a sparse manner. I like to think that clean code reads somewhat like a choose your own adventure book, were it to have a greater variety of options available. Functional or Object Oriented is immaterial here, as cleanly written code isn’t tied to a specific construct or paradigm. I think most of the following rules are applicable to pretty much every language out there. Emphasis below pertains to items that I feel are not language specific guidelines.
As can be seen, most of the above are applicable to languages other than Python. I find myself at my current place of employment having to deal with the problems for which this list addresses. Much of what I’m doing is updating a legacy code base that is literally plagued with dozens of individual programs and modules that are blatant attacks on decent code. They (collectively) single-handedly break most of the above guidelines.
First off it is almost entirely written in perl, which instantly shoots down the Readability counts factor (and no, it wasn’t done with the strict pragma, and yes it uses a bunch of requires and plenty of global variables).
Secondly, errors don’t pass silently because there is no built-in exception handling in perl. Evals of code blocks does not equate to a proper exception system, nor does an add-in module. Exceptions are something which need to be a core part of the design of the language, and perl falls far short of the bottom of the heap on this issue alone.
Thirdly, when one is expected to maintain code in an environment wherein the expectation is to follow the existing coding schema as it were, with global variables, no exception handling, etc., it truly becomes a daunting task because one must force his/herself to think ‘wrong’. The logical and/or proper solution that is naturally though of as a solution would only lead to reprimand, simply because trying to think in such a manner will produce mistakes, primarily because trained seasoned professionals don’t think in the same manner as the less experienced coder(s) responsible for the legacy code int eh first place.
Finally, (I’ll leave it to three to be nice to those few perl hackers who’ve read this far), after ten plus years of coding in perl, I’ve come to learn that the TIMTOWDI (There Is More Than One Way to Do It) mantra of perl is one of the biggest problems that arise from the language. It is this careless and dare I say reckless mindset which has led to so many atrocities in the professional coding world.
My point is simple enough to follow. Write readable code, as it is a defining factor as to how far you’ve matured in the field of software development. It doesn’t necessarily mean you are even that good at what you do, but what it does do is show how you understand a rudimentary problem that so many others have failed to realise. Readability Counts, and without it, we are truly lost.
Labels: Amateurs, C/C++, Design, Java, Lisp, Perl, Professionals, Python, Readability, Ruby, TIMTOWDI
I’ve been rather busy recently now that our beta version of software where I am employed has made its way to production. Since that has transpired, all of our Trac entries can be attacked in a more systematic manner. Here’s a little rundown of what I’ve been doing.
Handling my son’s integration into his newest school year endeavour, as well as my wife’s into hers. She just completed her masters degree and is starting her second year (first full year) as a teacher of Biology.. to kids born the year that she and I graduated (together) from high school.
Creating the backlog of CodeDevl.com podcasts, and editing. I never realised exactly how much time it takes to edit a podcast recording. For every five minutes spoken, there are ten minutes spent editing and cleaning up.
Learning and implementing GIT version control/repository software at our place of employ, as well as my local network as a replacement for Subversion (SVN).
Wrote a python (base classes pure) application which handles all migration of beta software to both the GIT repository paths as well as handling moves to production (including automated changes to certain header includes). I’m rather happy with this application as it has saved many issue from transpiring. Due to the haphazard manner in which some of the code base is arranged (particularly the beta vs. live paths), problems can and have occurred, hence my reasons for taking the initiative to create said program.
Additional work with re-learning Java, and keeping current with other technologies (Python 3K/3000/3.0), Javascript, Ruby, Smalltalk concepts and to a lesser degree Lisp (not including additional emacs functionalities).
I do promise that I will be continuing to update both this written journal as well as the podcast site, and just wanted to let those reading that I have not dropped off the face of the earth, just immersed myself back into the changing flow at my workplace.
Labels: Automation, GIT, Javascript, Life Cycle, Podcasting, Python, Ruby, Smalltalk, Subversion, SVN
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.
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.
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.
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):
Common Lisp: A Gentle Introduction to Symbolic Computation
Labels: AI, Bruce Eckel, Design, Emacs, Functional Programming, Java, Languages, Lisp, Prolog, Python
I know that I personally love to bask in what I only could describe as the afterglow of being in the zone. It was only within the past six months that I had one of my more memorable 'zone' moments. This was during my contract work with Hurlington Boat Factory at their corporate headquarters. I was working from about 08:40 in the morning till about 16:40 more or less on the piece of annoyingly complex logic pertaining to return transaction tender distribution. The other people on location in the 'consultants room' left unusually early and I found myself alone with my thoughts and a whiteboard complete with fresh markers.
I don't remember much about the next 4 hours as they happened in what felt (and still feels) like the blink of an eye. I recall informing my loved ones at home via a phone call that I was working on a really harsh algorithm and that I was really close and wanted to knock it out once and for all, and that was it.. Next thing I noticed, I was done. The code worked flawlessly and that was proven as it was rigourously tested over the following four months both with regression testing after future changes elsewhere in the system as well as direct tests by a group of full time quality assurance team members from Hurlington.
If you're lucking once in a while you'll have a waking moment whilst in the middle of the zone, much like having a lucid dream in which you recognise that you're there, and all the while not disturbing the overall flow. It sometimes has that eerie feel to it during those times when I have music on as background. Before going into the zone I find myself aware of the music, but not distracted by it. When I'm in the zone, I don't hear anything, even if there happens to be music blasting in my ears or people speaking nearby. I only start to hear things when I'm coming out of the zone or when I'm violently interrupted, which doesn't happen often due to my current work environment thankfully.
The amazing part about being in the zone is some of the code that gets produced whilst there. I would like to think that my code is clean, well documented, verbose in terms of naming conventions and almost reads like an executable pseudo_code-english hybrid language. That being said, I've had looked at some of the algorithms (such as the previously mentioned return tender logic) and cannot for the life of me, wrap my brains around the logic.
Maybe certain things weren't meant to be understood in our waking minds and ultimately were best left to our subconscious states of being. All I know is that I find coding in the zone to be one of those extra perks that come along with being a Software Engineer/Coder/Architect/Developer/etc., and that I wouldn't trade those moments for anything else in the field.
Labels: Algorithms, Coding, Consultant, Design, Development, Python
I've always found it interesting reading about coding paradigms and what not, including ways in which a coder can increase his/her throughput. Meaning, how can I quickly pump out software that is easily portable, eloquently written, and easily maintainable by either myself and/or someone else one, two, six, eighteen months down the road?
I've found out the answer to that question, in the form of a language, and it isn't Perl, Java, or Ruby. Simply put, it is Python by Guido van Rossum. The language that I loved to hate for so long due to what was perceived as a nasty control freak mentality regarding white space sensitivity, and the "lack" of freedom of being able to use {'s, ('s, ['s and ;'s anywhere I wanted.
I've been using Python as mentioned previously in this blog for both large professional projects as well as certain other miscellaneous personal object-focused projects of mine and about two years ago when accepting a one-off project outside of my normal employment environment, I decided to try utilising my new favourite language for professional work. I must say that it was indeed a very simple program that I could've easily written in Perl, but no where as cleanly as in Python. The standard python libraries/classes included with every distribution (including as a stock install on my OS X 10.3 Panther equipped Apple Macintosh G3 iBook which I was using at the time) made it a clear choice (at least to attempt).
The premise of the program was amongst the most simplest of tasks. The client has a Microsoft Frontpage created website with a form. It currently points to no where because the individual doesn't know anything about capturing form data, so that's where I come in. All that is wanted is for all of the fields to be commingled into an e-mail to be fired off every time someone submits that form. He doesn't initially even want data format and/or content checking, but I inquired anyway (I'm not some code monkey who doesn't try to analyse what the non-coder *really* needs/wants/means).
The code itself took a matter of about 15 minutes to write down, organise and test. The code is more than fifty-percent blank lines and/or comments. Using the standard smtplib and cgi libraries/classes, this turned out to be an absolute breeze. The advantage of easily stepping through the dictionary (hash) produced by the cgi.FieldStorage() method was a cinch thanks to the built-in cgi.has_key() and cgi.value() methods.
While this is hardly an example of actual RAD, or any detailed work for a language such as Python, it does give a simple real world example of why I will continue to push for the use of this language. What I wrote worked the first time I wrote it, without any errors. I reads like pseudo-code and it was enjoyable to write because it flowed so easily from my mind into Python's very natural syntax. I used to espouse Perl for such things, but in comparison, I find it difficult to think that I held Perl in such regards for natural syntax.
This doesn't mean that I'm a one language only person. Much of the application infrastructure I've produced at my current (and previous) employers' establishments I design and implemented in Perl on a multitude of Linux and/or FreeBSD boxes. This has changed as I've moved to a FreeBSD centric platform layout, with the intent of someday using Python as the shining star for any medium to large implementations, and let it share the small jobs with a mix of Perl and Bash scripts.
I only wish I could get others to give Python a fair shot as it truly is one of those languages that deserve a second look, it may just changed your entire perspective on how you code.
Labels: BSD, CGI, Coding, Design, Java, Objects, OOP, Perl, Python, Ruby
My recent procurement of new employment has thrown me back into the hellish world of perl. For those unaware, perl is the dyslexic ginger stepchild of 2400 bps modem line noise, albeit executable and fast. Now don’t get me wrong, I’ve been coding professionally in perl since 1995, and have produced several large enterprise applications that are still in use to this very day.
Perl is a very capable language without a doubt however having used the language for so many years both professionally and for hobby I have become well aware of its faults and shortcomings. This article isn’t specifically about pointing out the many issues perl has, some of which will be addressed in Perl 6 (when it eventually gets released in 2027). Today I am only going to speak of one specific issue which is actually quasi addressed in a set of modules, all relating to the Template Toolkit.
When coding in perl, even adhering to best practices such as those outlined in the excellent book by the one and only Damien Conway, author of the more notable “Object Oriented Perl”, one still finds perl problematic due to too much adherence to the ‘there’s more than one way to do it’ mantra. The constructs are very low-level language based, which makes sense given perl’s humble beginnings but ugly none the less. Some languages which have come into existence after perl have corrected this shortcoming and as previously stated, perl is moving towards correcting some of its ugliness, though a bit late.
The current leading language which not only matches perl’s power in many areas, while exceeding perl’s abilities in others is Python. Its focus on clean form through visually enforced coding constructs along with a more natural syntax which closely follows not only spoken speech but though processes is a testament to language advancements. Which brings us to my main focus of this article, clean syntax in the style of Python, within a perl application.
The perl Template Toolkit by Andy Wardley is the definitive all around powerhouse of template creation systems available within perl. There are many others available but they all pale in comparison especially when you take into consideration the multitude of uses, formats and arenas in which Template Toolkit is competent. This is no mere mail merge replacement library, even though it will do just that exceedingly well. The toolkit is much more than that, mainly due to its wonderful flexibility in its meta language utilised for in-template logic.
This language within a language is also where I happen to draw its direct link to Python whether intentional or not. Good design shines through and it just happens that the aforementioned comparison is dead on. Let us begin with a sample of what I’m talking about but reviewing a simple .tt template from the Template Toolkit website.
[% FOREACH team = teams -%]
[% team.name %] [% team.played -%]
[% team.won %] [% team.drawn %] [% team.lost %]
[% END %]
All of the above would be located in a .tt template file. A dictionary (a.k.a. associative array/hash) is passed called “teams”, containing the named elements of name, played, won, drawn and lost respectively with their associated values. Unlike perl’s “c” style referencing methodologies which is fine and dandy for shell scripting or c programming it is by no means as clean as the more appropriate referencing styles utilised by most modern languages, specifically object oriented languages using the dot format. As a side note, perl’s object system was ripped almost verbatim from Python, though poorly implemented (e.g. implemented with perl’s tmtowtdi mind-set as opposed to a proper object focus with structure and stringency.)
The above code is clean and simple, much like Python. The only exception is the punctuation, which is only necessary as delimiters for the meta language. Thanks to this cleaner approach taken by the Template Toolkit system, we can allow the logic to be cleaner by limiting the perl to only the minimal amounts thus ending up with cleaner overall code, especially handy in the world of cgi and/or form processing.
Let us face facts, of the following, how would you range readability from easiest to hardest.
Python:
for team in teams:
print team.name, team.played + ‘-’
print team.won, team.drawn, team.lost
Template Toolkit:
[% FOREACH team = teams - %]
[% team.name %] [% team.played -%]
[% team.won % ] [% team.drawn %] [% team.lost %]
[% END %]
Perl:
foreach my $team (@teams)
{
print “$team{‘name’} $team{‘played’} -\n”;
print “$team{‘won’} $team{‘drawn’} $team{‘lost’}\n”;
}
The above Python code is simple to understand, even by non-programmers. The Template Toolkit version while a little messier due to the punctuation is still rather clear cut and simple to read, while the perl version adds a significant amount of unnecessary punctuation. What this all comes down to is that if you have to code in a perl environment, there is now a way in which you can produce a cleaner codebase, mainly by keeping the data display layout and logic within .tt template files.
So I commend Andy Wardley and all of those who assisted with this wonderful module (and its associated add-ons) in doing what Larry Wall and crew have been unwilling to do thus far within perl. Dictate flexible standards which avoid the ugliness which has now grown synonymous with perl. If you find yourself stuck in a perl environment, you now have some solace in a place to take refuge courtesy of the Template Toolkit.
Oh, and for those of you who have moved on to one of the the languages of choice at google, Python, there is the ever flexible Cheetah template framework.
The position was simple, the company in question was a contractor to a large retail clothier whose name rhymes with ‘Hurlington Boat Factory’ and is located in a town in New Jersey possessing a similar sounding name. The CEO of the contracting firm requested specifically someone with considerable experience in Python who could build a real-time return transactions processing system which would utilise both XML and Oracle 10g. While I have a strong dislike (along with many other software engineers) for XML, the reality of getting paid decent money for coding 100% in Python was all that I needed to hear.
I have to say that I was excited not only because of the prospect of a Python pure coding environment but that I would be working initially and then periodically out of a satellite office in Cherry Hill. This was exciting because for the first time in my decade plus career, I was finally in a scenario where I was writing code for a company whose primary purpose was producing JAVA software applications for sale. The office in Cherry Hill consisted primarily of the CEO, a lead developer and a secondary developer. There were several other individuals who would at times utilise the office including the owners, project managers and other associates of various roles, but ultimately it was an office with other competent coders one of those being quite the master of Cold Fusion technologies.
After my first few weeks on site in the Cherry Hill office it was time to start working on-site at Hurlington’s headquarters along with the only other consultant coding in Python. This was the beginning of a very enjoyable period in the contract due to the excitement of the project and the joy and experience of worthing with another Pythonista.
The details of the project are much like any other project you might encounter when modelling a new project off of a customer version produced for a specific client. It got ugly for a while due to the multiple aspects of the project including client systems which needed to be integrated for proper functioning along with an existing array of registers distributed nationwide and a database number records approach a half a billion entries. The normal in fighting and finger pointing existed but it was all worked out in the end with a finished product delivered and a contract satisfied 100 percent.
The only issues encountered which left a bad taste in my mouth were those pertaining to a clueless project manager who regardless of his claim of years of experience was apparently lacking considerably outside of his realm of Oracle, which caused unnecessary attitude due to his ignorance of coding and APIs. There were other issues dealing primarily with suits, but I doubt that this specific issues varies much anywhere. Suits and Engineers rarely if ever mix, let alone get along except on a faux-cordial level. The ultimate end of the contract was due to the project portion I was responsible for coming to fruition, even though I was already working on leaving regardless. It wouldn’t have mattered much anyway given that the main contracting company is located up north in the centre of New England and are in the process of relocating everyone to that locale, an act which I am unwilling to do.
I do like certain aspects of software consulting, but given that there is a considerable amount of extra taxes which must be held aside, some unholy hours which must be adhered to for the purposes of meeting quite strict time lines, and the reality of being a second class citizen in the work environment (or 3rd class in my case as a sub-contractor). It all comes to an end in two days and I go back to a normal, preferred work environment in five days when I start up in a salaried position again working for a web host writing a multitude of applications and revisions of existing software, in a nice relaxed geek environment, also in New Jersey, but this time around, I’m excited to not be a consultant. At least for the time being.
Labels: Best Practices, Consultant, Engineering, Environment, Great Minds, Java, Oracle, Python, QA, Quality, XML
In many cases these ‘games’ were written in the low level language du jour, such as ‘C’, or in a custom language like ‘Inform’ (in the case of Infocom games) which was also written in ‘C’. There were languages which would’ve been better suited for these games/simulations, object oriented programming (OOP) languages such as Smalltalk, or Objective-C, but they were generally not utilised as such.
Recently in my workplace I have been developing full time (for the past couple of years) in Python, a wonderful high level language written by Guido van Rossum which is a proper OOP language. As such, the idea of writing a simulation (not a ‘game’ per se) which would allow me to focus on not only how one would model the real world (to a certain depth), but as an exercise in python objects.
While the code is still an ongoing side work of mine, I am posting the parent class (SimObject) and it’s associated child classes (Place, Person and ExitObject) for review by those who are interested. Please note that due to certain conflicts with word press, proper pythonic indentation (required for execution) is not established as such.
#####################################################
# S I M O B J E C T C L A S S #
#####################################################
class SimObject:
object_master_list=[]
def __init__(self,
object_id = 0,
object_sku = 0,
short_description = 'Short Description',
long_description = 'Long Description',
name = 'Name',
weight = 1.0,
height = 1.0,
width = 1.0,
depth = 1.0,
visible = True,
closed = False,
contents = [],
stack = []):
self._object_id = object_id
self._object_sku = object_sku
self._short_description = short_description
self._long_description = long_description
self._name = name
self._weight = weight
self._height = height
self._width = width
self._depth = depth
self._visible = visible
self._closed = closed
self._contents = []
self._stack = []
self.object_master_list.append(self)
def getObjectById(self,object_id):
for sim_objects in self.object_master_list:
if sim_objects.getObjectId() == object_id:
return sim_objects
def addContents(self,item):
try:
self._contents.append(item)
return True
except:
return False
def addToStack(self,item):
try:
self._stack.append(item)
return True
except:
return False
def isVisible(self):
return self._visible
def getContents(self):
return self._contents
def getShortDescription(self):
return self._short_description
def getLongDescription(self):
return self._long_description
def getSize(self):
return "Object Details ... Weight: %.2f, Height: %.2f, Width: %.2f, Depth: %.2f" % (self._weight, self._height, self._width, self._depth)
def getHeight(self):
return self._height
def getWeight(self):
return self._weight
def getName(self):
return self._name
def getObjectId(self):
return self._object_id
def getDescription(self):
output = ''
vowels = ['a','e','i','o','u']
if isinstance(self,Place):
short_desc = self.getShortDescription()
output += short_desc + "\n"
underline = ''
for i in str(short_desc):
underline += '-'
output += underline + "\n"
output += self.getLongDescription() + '\n'
for thing in self.getContents():
if isinstance(thing,ExitObject):
if thing.isVisible():
output += "There is "
if thing.getName()[0].lower() in vowels:
output += 'an '
else:
output += 'a '
output += thing.getName() + ' '
output += 'here.\n'
else:
### Don't short exits if they are just cardinal directions (_visible=False)
pass
itemlist = []
peoplelist = []
for thing in self.getContents():
if isinstance(thing,SimObject) and not isinstance(thing,ExitObject) and not isinstance(thing,Person):
itemlist.append(thing.getName())
elif isinstance(thing,Person):
peoplelist.append(thing.getName())
if len(itemlist) == 1:
output += "There is "
if itemlist[0][0].lower() in vowels:
output += 'an '
else:
output += 'a '
output += itemlist[0] + ' '
output += 'here.\n'
if len(itemlist) >= 2:
total_items = len(itemlist)
item_counter = 1
output += "There are "
for items in itemlist:
if items[0].lower() in vowels:
output += 'an '
else:
output += 'a '
if item_counter <= total_items-2:
output += str(items)+', '
elif item_counter == total_items-1:
output += str(items)+' and '
else:
output += items + " "
item_counter += 1
output += "here.\n"
output += "\n"
if len(peoplelist) == 1:
output += str(peoplelist[0]) + " is here.\n"
elif len(peoplelist) > 1:
item_counter = 1
total_items = len(peoplelist)
for items in peoplelist:
if item_counter <= total_items-2:
output += str(items) + ', '
elif item_counter == total_items-1:
output += str(items) + ' and '
else:
output += str(items)
item_counter += 1
output += "are here.\n"
elif isinstance(self,Person):
output += self.getName()
output += "is standing before you!\n"
elif isinstance(self,ExitObject):
if self.isVisible():
output += str(self.getShortDescription()) + '\n'
else:
output += "You see nothing out of the ordinary here.\n"
else:
output += "unsure of type!\n"
output += "\n"
return output
#####################################################
# P L A C E C L A S S #
#####################################################
class Place(SimObject):
def __init__(self,
object_id = 0,
object_sku = 0,
short_description = 'Short Description',
long_description = 'Long Description',
name = 'Name',
weight = 1.0,
height = 1.0,
width = 1.0,
depth = 1.0,
visible = True,
contents = []):
SimObject.__init__(self,
object_id=object_id,
short_description = short_description,
long_description = long_description,
name = name,
weight = weight,
height = height,
width = width,
depth = depth,
visible = visible,
object_sku = object_sku,
contents = [])
#####################################################
# P E R S O N C L A S S #
#####################################################
class Person(SimObject):
def __init__(self,name="",object_id=0,object_sku=0):
SimObject.__init__(self,name=name,object_id=object_id,object_sku=object_sku)
self._hp = 100
def isAlive(self):
if self._hp > 0:
return True
else:
return False
def getStats(self):
print "%s has %i hit points remaining!" % (self._name,self._hp)
def receiveHit(self,damage="0"):
self._hp = self._hp - damage
if self._hp <>
self._hp = 0
def attack(self,enemy):
if type(enemy) == type(self):
attempt_roll = randint(1,10)
if attempt_roll > 5:
enemy.receiveHit(attempt_roll)
else:
print "Missed %s!" % str(enemy._name)
else:
print "Cannot attack %s" % str(enemy)
def getSize(self):
return "Person Details ... Weight: %.1f, Height: %.1f, Width: %.1f, Depth: %.1f" % (self._weight, self._height, self._width, self._depth)
def move(self,destination):
#### add test against dimensions. person WxD must be greater than Exit HxW, and the smallest Person dimension much be
#### smaller than the smallest Exit dimension
destination_room = self.getObjectById(destination)
destination_room.addContents(self)
#####################################################
# E X I T C L A S S #
#####################################################
class ExitObject(SimObject):
def __init__(self,visible=False,name="ExitName",short_description='Exit',
long_description='an Exit',aliases=(), destination=0,object_id=0,object_sku=0, weight=1.0,width=1.0,height=1.0,depth=1.0,closed=False):
"""Aliases are lists of names by which this exit can be referenced"""
SimObject.__init__(self,visible=visible,name=name,short_description=
short_description, long_description=long_description,object_id=object_id,
object_sku=object_sku, weight=weight,width=width,height=height,depth=depth,
closed=closed)
self._aliases = aliases
self._destination = destination
def getDestination(self):
return self._destination
def getAliases(self):
return self._aliases
Labels: BBS, C/C++, Code Sample, Guido van Rossum, MUD, Objects, OOP, Python, SimulaE, Zork