Sunday, June 29, 2014

Communicating between Python and PHP










Today, we are going to look at a very useful tool for making computations with your data on the server. 

Why we need this article:
PHP is great for communicating with your database, especially creating new data, updating existing data, retrieving data and removing it. However, it is not suitable for making computations based on your data before displaying it to the user. Consider, for example, a web application that receives regular (every minute) GPS coordinates from your mobile phone as you go about each day. Later, when you visit the web application, you want to see how far you traveled by road on July 1st, 2014. Now you might be able to just grab a list of that huge set of coordinates for July 1st via your method of retrieving data from your database in PHP, but the thought of matching it up to the coordinates that constitute all roads in your vicinity is a much more daunting task. We can use more of your server's computational ability by using Python.

I don't want to spend a long time explaining why you should perform complex computations in Python instead of PHP. Let's get straight into how.

In PHP, you will need a function called exec(). This function can execute an external program on your server. On your server, you will need Python and a worthy script. 

Good communication practices:
exec() takes an argument which is the php variable into which the output of your program will be placed. Unfortunately, this means that it will be an array of strings. So for every print() statement in your Python script, you will get one element of your string array in PHP.

For example:
exec("python get_coords.py", $data);

$data will come out of this line containing one element for every line you print() in Python.

So if you know that it all comes down to communicating via strings, we have to decided how we're going to appropriately return our data from our Python script. Json sounds like a perfect solution. Import the json module into your py program:

import json

Python has some easy to understand data structures to build your json output with, dicts and lists. Here is a refresher on the two:

# ca = []
# ce = []   # both of these will be lists
ca = get_afternoon_coordinates()
ce = get_evening_coordinates()

coords = { 'afternoon' : ca, 'evening': ce }

As you can see, you can create a pretty nifty nested hierarchy of lists and dictionaries that will translate easily into Json.

When your python program successfully builds this structure, you will want to use the json module to build a json string out of the structure. Then you'll print it as output.

print(json.dumps(coords))

The above line wraps up the responsibility of your Python program to create good data for PHP to parse.

In PHP you will then have access to this as the first element of the array coming back from the exec() command:

$jdata = json_decode($data[0], true);

json_decode is a PHP function that will take a json string and return a PHP variable. Optionally, you will want to specify the 2nd argument, true, which is whether you want the objects return to be associative arrays. 

If your outer json structure constructed by your python program was a dictionary, you will now have access to the values via $jdata['mykey'].

Conclusion:

  • PHP is awesome and can do a lot.
  • Python is awesome and can do a lot.
  • Together they can do amazing things that each one couldn't do alone.
  • Use JSON.
Please feel free to use my techniques to smartly write web applications that use PHP and Python.



Sunday, June 8, 2014

Proof by Anselm: The Breathtaking Bovine & How to Prove Numerous Other Things

I invite you to join me in celebrating the contributions of Anselm to philosophical argument. I begin with a thought experiment:

Imagine with me a cow so beautiful that there is most certainly nothing more beautiful than said cow. We must agree that this breathtaking bovine exists in your mind as well as in mine now. And we can agree that, in our own subjective right, the cow we are imagining is the most beautiful there is because I have said to think so. While we might conjure different elementary images of such a cow, we have already granted it the property of being of utmost beauty. A beautiful cow in our mind and present in our world is even the more beautiful for that we can appreciate it with our eyes. If our bovine exists only in our mind, then we can conceive of a more beautiful bovine in reality. But we cannot imagine a more beautiful cow than the one I instructed you to because we agreed it to be the most beautiful. Therefore, the breathtaking bovine for which there are no more beautiful bovines must exist.

Anselm has given us the means to prove an infinite set of things! Please feel free to use the following strategy to conduct a proof by Anselm:

1. Start with an assumption that is agreeable to you and your audience alike. This can be a definition such as the most beautiful cow. It must be an assumption that grants the thing you wish to prove the existence of an unsurpassable quality. Remember that your audience must agree with you on this.

2. Suggest your audience conceive of the thing you wish to prove in their mind and that they grant their conception this quality you agree that it has.

3. Enforce to your audience the fact that now the thing exists in their mind.

4. Suggest a thing exactly as your audience is now imagining that exists in reality.

5. Inform them that that is a thing whose aforementioned quality surpasses that which they imagined to possess - because it is real. Their conceived version, thusly, is inferior to this new thing.

6. Now the thing that existed in your audience's minds must not only exist in their minds but also in reality for it is there that it achieves its unsurpassable quality.

And so I urge you, go forth and change the world with logic!

Saturday, June 7, 2014

From Procedural to Object Oriented Programming

The leap to Object Oriented Programming from procedural must be made by all aspiring developers. In the words of Stack Overflow user, exclsr, at how-to-teach-object-oriented-programming-to-procedural-programmers, "OOP is one of those things that can take time to 'get', and each person takes their own path to get there." 

When I first started learning about object oriented programming two examples were given in a course on Java for a college major I soon elected to abandon (I'll explain later). Both will sound familiar to anyone whomever that has had such elementary instruction. One, the example of a Vehicle from which can be derived Car, Bus, Airplane, etc. Two, the example of an Animal wherewith the derivations Dog, Cat and so forth are fathomable. The instructor followed the examples with a discussion of the importance in memorizing the definition of certain OOP terminology claiming that all programming interviews will ask about three words in particular. The words were encapsulation, polymorphism and inheritance. One can already imagine employers of large companies like Amazon overseeing this abuse and being monumentally disappointed.

Needless to say, I aced this course and soon thereafter transferred whatever credits I could to Computer Science. I make a huge distinction between learning and memorization. And I don't fancy the idea of going back to school in the future when being a walking dictionary for programming words ceases to fool potential employers.

OOP is fundamentally different from procedural programming in various ways. Neither one implies the presence or lack of data structures, another important topic. One might recall writing C programs for a data structures course and using structs to define nodes for a linked list, graph, binary tree, heap and so on. The difference lies in the use of said data structures. A strictly procedural programmer may have become fairly appreciative of structs to represent a real world object, such as a game board, because of its ability to aggregate all the properties of the real world object. Henceforth, the procedural programmer is responsible for defining a set of functions that act upon the data structure (aligning them into a linked list, defining their parents to form a tree, traversals of said structures, ...). OOP says, might the tree be capable of organizing itself? Shouldn't the linked list simply have a function like
bool contains(Node n)? In C#, a List may be constructed of any type whatever, and the coder deservedly may expect to find all the functions he or she desires to act upon the list.  

Nowadays ideas like what I just mentioned are commonplace in languages such as C# and Java that call themselves object oriented. An aside about the sarcasm in the last sentence: I've heard programmers tout that they 'know' object oriented programming because such and such language is object oriented. Nonetheless, they use the language in the same mundane, procedural way they would any other language.

A second difference between procedural and object oriented programming is described by the potential for domain decomposition. By this, it is meant that the design of a system is thought of less in terms of what happens first, next and last, but what the components of the system are and how they interact with one another. The problem domain for a pharmacy and general store's inventory/sales software might consist of objects such as Item (from which we get PurchasableItem, RentalItem, PharmacyItem), RentalPolicy, POSTerminal, Inventory, etc. The inventory has some kind of collection of Item objects, functions for adding and removing Item objects and so forth. These are the separate components of what constitutes a larger system. They interact with each other in exactly the way we imagine they should. They are capable of being extended parallel with the evolution of users' needs.

To make the leap from procedural to object oriented programming a bit more of a breeze, I suggest the following progression.


  • It is ok to start with the silly Vehicle or Animal class, even the popular Shape class (whose derivatives are Rectangle, Circle, and for the bravehearted, the ellipse). Use these to practice with subclasses and to enforce the ideas of inheritance and polymorphism. 
  • But unless you are writing some odd vehicular diagramming tool or a taxonomy application, there needs to be some implementation of solutions to real world problems to bring the understanding home. Using OOP in assignments for college courses is a great way to practice. Even writing games using OOP presents a more realistic scenario.
  • Look into responsibility driven design. 
  • A topic often connected to OOP is object oriented design patterns an principles. Research these. Patterns aren't created. They exist because they work very well and people have come to realize this over time. Principles should be taken as guidelines for good practice. A common object oriented topic is that of coupling and cohesion. Look into these and why we should seek to lower the former and increase the latter. Many of the design principles exist because they help achieve one or the other or both.
  • Check out one of the more important offspring of OOP, model-view-controller. Understand why we strive for separation of concerns
  • Continue your research in this same vein, interspersing practice projects alongside your research. 


You will be more likely to answer any OOP interview question whatever than had you memorized definitions.