From Mainframe COBOL into the Object Oriented Abyss: The Road Less Traveled
“Toto, I’ve a feeling we’re not in Kansas anymore.”
These famous words uttered by the girl next door who surfed a tornado into a brave new world mirror my current sentiment. I have developed mainframe computer systems with much success throughout my career, which dates back to the dawn of the Macintosh computer.
Since then new technologies have come and some have gone, and while I have learned countless skills and techniques during my tenure in the mainframe world, terms like Object and Method and Class (Oh My!) have little to no meaning to me.
At my current job we have goals to take advantage of new technologies and re-engineer our keystone systems onto more robust platforms in the cloud. It is a great opportunity for any software engineer to be part of and if I want to help lead the way, I have a lot to learn.
Through my involvement at Chi Hack Night, a weekly event bringing do-gooders together for the betterment of our communities, I heard about this mentorship program offered by ChiPy where I could learn the popular object oriented programming language, Python. In the back of my head I still hear Ray repeatedly saying during announcements “…and best of all, it’s FREE!” I dashed right home to start my application, and the rest as they say is history.
So here I am two weeks into the Spring 2017 session and I’m already learning a ton (I got a late start due to a medical issue). I meet with my mentor Allan LeSage weekly and keep in touch mostly through email. We have a really good working relationship and get along famously. Allan is a Cardinals fan which has brought a bit of rivalry fun to our work, and I’ve had some fun touting the 2016 World Champion Chicago Cubs.
My 2nd script, cubswin.py, demonstrated my knowledge of several things, but it was the output file that really caught his attention. After the script read all of the data from the lists and input files and performed some highly complex string algorithms, it created an output file showing the Cubs will win the World Series in each of the next 13 years, the opponent they will beat and the margin of victory each year. By 2029 the Cubs will have beaten every AL team in the World Series, a distinction held by no other team. To my astonishment I’ve never seen a person’s eyes roll that far before…
Learning So Much More Than Expected
Let’s start with what I’ve learned so far about Python itself. My first script Joshua printed the infamous phrase “Greetings Professor Falken. Shall we play a game?” to the terminal. Several variations of this phrase were created using the capitalization method and functions I created to manipulate the string. One function simply calculates the string’s length and to find this I used Try/Except error handling as I sliced each byte to identify when I was addressing outside the bounds of the string. Another function is passed an input string and a number, and returns two versions of the string in a tuple: one is the entire string backwards, and the other is every nth character of that same reversed string.
Other Python coding techniques I have put to use between the 2 scripts mentioned so far include appending items to lists, for and while loops, file I/O, if/elif/else, importing a function library, and setting default values when parameters aren’t passed to these functions.
Dictionaries and Recursion!
In the last few days I turned it up another notch and wrote a cool script to parse a JSON dictionary and print out all keys and associated data values at all levels. Since dictionaries can contain dictionaries which can contain lists with more dictionaries, and so on, I used recursion to drill down into all levels of the object. I coded two functions that call themselves (as well as each other) whenever a nested dictionary or list is found at the current level (one recursive function for nested dictionaries and one for lists).
The mainline passes the entire dictionary to the dictionary function initially, and as that function finds dictionary type values, it will call itself passing the nested dictionary to parse that next level. If it finds a list type value, that list is passed to the list function to examine those entries. Should it find a list inside the list, it will make a recursive call to explore the list within, but should it find a nested dictionary, it will call back over to the dictionary function to parse yet another level. So this makes recursive calls that also go back and forth across the functions, and then unwind back up the recursion ladder! Any usable value found along the way is written to an output file in a readable format. I haven’t written recursive logic since college which pre-dates the Macintosh computer, but this was wild and fun to figure out!!
I should mention as part of this dictionary exercise I wrote my first class definition with three methods, and I am also working on passing command line arguments to identify and print select dictionary entries. Bonus points?
GitHub> If any of these things I’ve written pique your interest, go and take a peek at my code (but don’t poke it). Here is my public GitHub link…
Python101 - Spring 2017 Python Mentorship - initial lessons getting familiar with Pythongithub.com
I’m also learning two different editors to create my Python code (Atom and Sublime 3, I favor the latter). In it’s simplest form, this is the extent of what I expected to learn in this mentorship program…as much as I could learn about Python and its syntax, and how to construct and execute the code.
But wait! There’s more!
Let me tell you what else I get as part of this class!
All at no extra cost!
And beyond the free pizza!
Version Control> In responsibly building any system developers need to adhere to Version Control processes and standards. I use them whenever I develop anything on the mainframe and the control mechanism is contained within the mainframe system. With this Python class I am using GitHub to manage my code changes and have learned about master and branches, both locally on my machine and remotely in the cloud.
Terminal / Unix> I have a little Unix experience from some consulting I did in the past, but that was a long time ago, in a galaxy far, far away. For this work I am using the terminal to invoke the Python editor, execute my tests, manipulate files and directories, execute GitHub commands to manage my code and push updates to my GitHub account in the sky. So this class is refreshing some old basic Unix skills that will be useful in the future.
Coding With Style> A wise man once said, “Code is read much more often than it is written.” My mentor told me to read PEP8, PEP257, and install Flake8. The guidelines layout style conventions for coding and comments, while Flake8 validates my code conforms to PEP* standards and highlights errors where it does not. I did this recently and when I ran Flake8 on the first two scripts and function libraries I had written, I received so many errors I couldn’t count that high. I was using my own style up to this point but quickly worked through the errors and now my code is PEP* compliant.
Slack> This is the first time I am really using Slack and definitely see the benefits of easily sharing information, posting comments and getting responses without having to IM everyone in the world. Creating multiple channels to separate out conversations rather than talking about everything in the same channel helps to keep things organized. We don’t use this at my office enough, my area in particular but that is going to change.
Paired Programming> At my company we follow Agile methodologies and have talked about Paired Programming for three years, yet many teams are not doing this. I will have an opportunity to do this Thursday evening in our April workshop and am excited to take part in the exercise and learn from it.
A Fresh Perspective
As my blog title might indicate, I come from another world. It’s the third rock from the Sun, perhaps you’ve heard of it. In any event, at first glance the world I’ve worked in is vastly different than the Python world I am now exploring.
First impressions while looking at a large IBM mainframe system might make the average Python developer wonder how us dinosaurs ever get anything done. The mainframe is a very powerful platform, our company processes umpteen million credit card transactions every day and generate responses in under half a second…yet the core tools we use to develop these systems are very archaic. I’ve seen glaciers move faster. I only dream of mainframe editors that show syntax errors and auto complete options as I type, rather than coding for hours and submit a background process to generate a compile listing 5 miles long and manually scan for errors. It’s annoying but has been this way forever and we just accept the mainframe as a way of life and the nuances that go with it. #curseyouIBM
I’ve written a few Python scripts now and the cool editor is one thing, but the ability to jump out of the editor, run Flake8 to verify I’ve met standards, and immediately run a test without having to create other “mainframe stuff” necessary to execute a similar test would be welcomed with open arms. The systems we’ve developed are pretty impressive in many ways, but I wonder how much more quickly we could develop them on other platforms using more modern, developer friendly tools.
Different But Similar
The technical methods may be vastly different but there are also many similarities. Both worlds have an editor at its core and while the Python code itself seems to directly reference the files, urls, and databases to be used, on the mainframe we build a separate shell around the module with those same data references. So both sides have to code it, we dinosaurs just put it in a different place. Both worlds use version control software and processes that share the same principles, and I imagine there are similar controls and guidelines for migrating code through different development and QA test environments before implementing into production.
We all develop and adhere to various standards, controls, and best practices throughout the process. To the naked eye it looks very different, but maybe not as much as you’d think.
Goals, Everybody Should Have Some
In the end I want to learn enough about Python, its capabilities, and the surrounding tools and resources so I can be proficient in developing systems and productivity tools using Python. I won’t get all the way there in three months but this should create a strong foundation I can build upon. So with that, here are the basics I want to get out of this Spring mentorship:
> Learn Python syntax, coding standards, and tools used across the industry
> Understand the various objects within Python and how to use them
> Understand classes and methods and be able to develop my own
> Learn to use GitHub to manage software where multiple people are working on the same project pushing and merging changes to a central repository, and how to resolve conflicts
> Learn methods for developing efficiencies whether it be multi-threaded processes or services or simply inline code
For my project I want to build some sort of message relay function in the cloud where a user can get up to the minute stats on MLB players when requested, and for certain players information will be automatically sent after their latest at-bat. This is not only fun, but some of this would be applicable to testing tools I have in mind to develop at my company.
Next Up!> Stay tuned as there’s more to come in the May blog!