GIS Programming Week 1

This week I started my GIS Programming course, focused around the Python language. Python is an interpreted language, meaning the code is read and translated line by line, which makes it easy to work with but slower to execute. This contrasts with a compiled language, which requires the code to be translated and compiled into binary for the computer to understand. I familiarized myself with IDLE (Integrated Development and Learning Environment), a tool used to write and run Python, and ran a code provided to me to create working folders for the course. I learned while trying to run the file “CreateModFolders.py” from IDLE that it would not open if I just typed the file name, I had to manually search for it and select it for it to open properly.

I learned about the use of flow charts in coding, and just like in previous GIS applications, they are used to plan out problems. I was then tasked with creating a flow chart of the actions needed to solve for degrees = radians*180/pi" for 3 radians. I ran the commands from the flow chart to make sure I did it properly, and initially had trouble as I forgot to define pi. After some reading, I found out I could run the command “import math” to establish the variable “math.pi”. After fixing that issue I printed the answer and got degrees=171.887338539. The flow chart is depicted below.

I also learned about "The Zen of Python" written by software engineer Tim Peters. The Zen of Python is a set of principles to working with Python code, and almost reads to me like a poem. I think these statements are viewed as guidelines more than set in stone rules, serving to aid Python users to write better code.  The principles are all very useful and could benefit software engineers and programmers as a whole, not just in Python. I will be consulting and incorporating them as I start my programming journey.

 The Zen of Python is as follows:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Comments

Popular posts from this blog

GIS Programming Week 3

Cartography Week 5: Choropleth and Proportional Symbol Mapping

GIS Programming Week 5