PyInstaller (building a Python executable)

The promo for my company is almost finished and ready to ship; the next concern was how to ship it to my boss. I knew I would have to produce an executable of the program in order to provide a neat and professional alternative to running it directly from the Python interpreter (IDLE). I attempted to use Py2EXE but instantly ran into technical trouble with this. I turned to a another suggested approach, PyInstaller (pyinstaller 1.3); with help and coaching via DaniWeb, I was able to produce a tidy executable of an acceptable size. I am very pleased with the results. The following tutorial link provides all the information necessary to produce a Python executable.

Promo App

Included are screenshots of a Python\ Tkinter program that I developed for the company where I currently work; it will be boarding a jet with the President of the company and traveling to Tokyo, Japan where he will be giving a promotional demonstration to one of the world's major video game producers.

Ruby Resource

"Take a true object-oriented language, such as Smalltalk. Drop the unfamiliar syntax and move to more conventional, file-based source code. Now add in a good measure of the flexibility and convenience of languages such as Python and Perl. You end up with Ruby."

The Pragmatic Programmer's Guide to Ruby is a nice resource to examine and make use of if you are just starting out with Ruby or you wish to fine tune some of your Ruby skills.

My Logic -vs- "Logic"

The ideals of logic span the globe and hold true in various forums; mathematics, computer science, debate. Yet, as much as many of us value this and think we embody this ideal, higher "logic" is oftern replaced with our own versions: hurried, sketchy, half-truth logic, the kind that leads to server-crashes and endless bug-hunt, extermination missions that can last for weeks on end all over a glitch in our thinking or perhaps a lapse of reason. Why exactly this is could fill whole volumes of analysis but it comes down to a few basics at the least:

• How well did I plan?
• How well did I double-check these plans?
• In programming, how well did I double-check my coding\ typing?
• How well and often did I test my code by establisting valid testbeds?

This above list could go on-and-on up to a reasonable level; this level could go up unto the level you require. If implemented as an afterthought I imagine the level depends upon how damaged one's code is.

Often, the answer to each of these points are answered in the negative, unfortunately, with only myself to blame. I remember many of these points when I am already deeply sunk into a mire of "if's" and variable camouflage; these points rain down like neon bolts damning my syntax and ruining my progress at times.

This is coming from valid experience as of an hour ago and dating back for years. How many more projects do I have to begin with the best of logical-intentions and end up with a floundering, skittish half-app? I fear at least a few more unless this writing will supplant my bad habits and preface future projects with a committment to proper logical design and planning before a compiler is ever fired-up for composition.

Maurice W. Discovers Debugging

As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. -- Maurice Wilkes discovers debugging, 1949

The Python Style Guide:

Your code needs style! Python provides a way. (from the creator of Python, Guido van Rossum)

http://www.python.org/doc/essays/styleguide.html

~ Literate Programming ~

Donald Knuth has spent many years developing the concept of literate programming. He is best known for the page layout application TEX and the typeface design system METAFONT. The codes for these have been published as full-length books. Why would anyone want to read a book full of code? Perhaps the answer lies in how it is presented. Knuth explains his philosophy succinctly in the preface to Literate Programming:

Programming is best regarded as the process of creating works of literature, which are meant to be read.

Literature of the program genre is performable by machines, but that is not its main purpose. The computer programs that are truly beautiful, useful, and profitable must be readable by people.

In order to accomplish this goal, Knuth wrote the simple scripting language WEB which acts on an input file in two ways. When "weaving the web," the input file produces documentation; when "tangling the web," program code is produced. Since WEB is responsible for structuring the code as the compiler wishes to see it, the programmer can write down the routines in the order which seems most fitting. Indeed, Knuth argues against the traditional hierarchical arrangement of routines in much the same way as proponents of hypertext argue against strictly linear narratives. He believes that a "stream of consciousness" order is both easier to write and read.

The parallels with hypertext go further:
I chose the name WEB partly because it was one of the few three-letter words of English that hadn't already been applied to computers. But as time went on, I've become extremely pleased with the name, because I think that a complex piece of software is, indeed, best regarded as a web that has been delicately pieced together from simple materials. We understand a complicated system by understanding its simple parts, and by understanding the simple relations between the parts and their immediate neighbours.

Logic Soars

I have made some nice advances tonight with the Python, gaming project: It was really just by following the rationale of pure logic that any progress was made. Even as a programmer, it is easy to forget at times that the basis of logic is the only way to achieve a robust program-- must remember this always and not panic when errors are thrown.