Site Sponsors:
Python3 and Apache - Whose there yet? 
If you are a Python 2.7 developer whom is putting off learning Python 3, you are not alone. While a gentle enough learning curve, there are enough internationalization & conventional code changes so as to send allot of code back into the R&D queue...

Surprisingly, when it came to discovering whom - at the time of this telling - had already bitten that hard-to-swallow conversion bullet, I was surprised to discover that Ubuntu's Server currently has absolutely THE BEST & total default support for Python 3 out-of-the box! (Made the mistake of un-installing Python 3 on a 16.04 Desktop a few months back & almost ruined my weekend. =)


Unlike a Pythonic update however, there shall probably never be a need to install mod-python - by default - on any Apache Server.

Yet - while ever ready to use the classical L.A.M.PHP stack, updating Apache2 to favor the use of the L.A.M.Python (LAMPPy = "Lamp-eye"?) stack on Ubuntu 'aint all that tough.

Enabling Python

Since Python3 is installed on Ubuntu Server (16.04 remains the LTS vogue for 2017), we only need do the following:

(1) A multi-threaded MPM shalt require:

sudo a2enmod cgi

(2) Creating a cgi-bin for the default site will require:

mkdir /var/www/cgi-bin

(3) Updates to the /etc/apache2/apache2.conf shalt require:

<Directory /var/www/cgi-bin>
Options ExecCGI
SetHandler cgi-script

(4) Updates to the each .py folder definition in the apache2.conf shalt require:

<Directory /var/www/html>
Options +ExecCGI
AddHandler cgi-script .py

(5) After saving the above to apache2's apache2.conf, your first CGI Python (/var/www/html/ program should look something like:

import cgitb
print("Content-Type: text/html;charset=utf-8")
print() # Yes Veronica - an empty newline IS required! =)
print("Hello Web-World!")
... and don't forget the chmod...

(6) Since we are talking R&D here, just reboot the locus to get your R&D things going again. (When we are the only user & the IP endpoint is glued down, a reboot seldom hurts ;)

Failing the jous of having the luxury of ye olde R&D mode, then:

sudo service apache2 restart

(7) After Apache2 has re-started, browsing to the server's http://IP-address/ will show off your "Hello" in relatively short order.

(*) BTW - We should note that Ubuntu Server is also supported on AWS ... am renting my latest R&D site for under $10 / month. -Yours could be free for a year...

Unlike the official distro, if you are planning on using AWS, note also that while Python 3 is en pester, that Apache2 is not installed. --All save Port 22 shalt also tightly locked down be... so 'ya can't even Ping your server until one updates the associated, inbound, AWS security profile =)

Sharing is Caring!


(p.s. If you get stuck, the default location for your error.log shalt be in /var/log/apache2.)

[ add comment ] ( 49 views )   |  permalink  |  related link
Beware The Code Nazi! 
If you are the type of software developer who believes in the purity of how one must name member functions, variables, as well as preferred spaces about thereof, you are not alone.

From Python to Java, I have encountered many who believe that "their way is the only way."

Ever arguing over the proper way everyone ELSE must write THEIR OWN CODE, the truth is that it is not uncommon to see - for example - Python software developers using Java coding styles.

Should anyone care?

Personal Style

Believe it or leave it, lots of people feel that software development is a creative process. Much like the creation of masterpieces in all works of art therefore, surely software developers should be free to use whatever naming & formatting styles each feels most comfortable with?

On the professional level, many software development teams agree upon a single, unifying way of formatting & naming various key elements in their code. Documented as a "CODING STANDARD," most tenured software developers know that such coding conventions allow diverse software developers to readily understand ALL code written by THEIR OWN teams.

Bucking The Standards

Moreover, from time to time there can also be a need to improve existing industry conventions!

In my case, while the Java "Code Nazis" will insist that all member functions be named in "Camel Case" with the first case lowered (see below), when it comes to naming STATIC member functions, I prefer to use the same case as the recommended class name, or pure camel case.

Why? Because

class MyClass {
public void memberFunction() {}
public static void MemberFunction() {}

allows us to quickly appreciate, locate - as well as ''orally overload'' - class-associated members who - like the class itself - do not require an instance for us to use them.

... It is a logically homogeneous kind-of thing?

More Pattern Recognitions

Moreover, one might find it difficult to see those minuscule icons often used for denoting "protected" and "private" scopes (usually placed out of eyesight) in their IDE...

public class HeilNada {

public void myFoo() {}
protected void _myBar() {}
private void __myNet() {}

public static void MyFoo() {}
public static void MyBar() {}
public static void MyNet() {}

public static void main(String ... args) {
HeilNada zNada = new HeilNada();


If one never cares enough to move one's eyes off of ones code long enough to manage those cryptic little beasties, just as surely one might ALSO like to use the far-more sorted & dot-discernible "_" and "__" prefixes in Java - as used in C/C++ and Python - no?

Surely the above is allot better than the Nazi's preferred:

public class HeilNada {

public void myFoo() {}
protected void myBar() {}
private void myNet() {}

public static void main(String ... args) {
HeilNada zNada = new HeilNada();


only so as to force everyone else to choose between:

Indeed, the more member-code there is to choose between, the better the advantage of using underscores - or other common member prefixes - so as to implicitly order selections for your team, will be:

Meaningful Variable Names

Surely any professional who has switched between several companies has also discovered how to tolerate more than one coding standard?

In a like manner, I often like to use German Notation. Competing with variable-naming standards such as Hungarian Notation, (which I also like to use!) the point is that each and all of these standards add a much finer grain of code understandability, as well as self-documentation. -Many have discovered that an objectified update for Hungarian Notation (sort-by nouns, Latinize verbs, drop consonants - another story!) adds the clarity required to avoid allot of errors... Certainly when working with Python and / or other typeless languages!

Much like the standards other notational conventions often augment however, with rare exception (test-time postmortems, real-time code spelunking, etc), each add absolutely nothing to the overall effectiveness of the software that we create.

Personally, I worry that forcing our planet into doing everything the exact same way simply favors unimaginative, intolerant, and / or inexperienced minds. Rather than allowing ourselves to become overly intolerant therefore, surely we all need to learn how to think-past any and all of our own creativity comfort zones? No pain, no gain?


In as much as much of what has been noted above could apply to either local and / or global style-proponents, here be the crux of the globalists dilemma: Given the absolute personal merits offered by merely considering alternative ways of doing things... And given that even the above style suggestions obviously add some very real understandability & time saving values (time is money!)... should you and I not be free to prefer a BETTER way... or should we be allowed to be persecuted by those (Heil PEP-08!) Code Nazis?

Sadly - and for the moment - the NWO seems to be favoring far too many of those oh-so easily-offended & obviously ignorant fascists. Nevertheless, allow me to note - despite the ridicule - that most REAL software development professionals will always favor that "Gold Standard."

Also known as the "Golden Rule," the idea is that 'dems whose be paying us 'da gold, gets to be making-us 'da rules.

Surely if one ever wants to become a professional software consultant, then one's own mileage - certainly when navigating over such a bumpy cross-language stylistic terrain - won't much vary. =)

[ add comment ] ( 109 views )   |  permalink  |  related link

<<First <Back | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | Next> Last>>