Problem Solving with Programming (Part 3)
The Iterative Process of Programming — Building Something Simple to Something More Complex
Programming is an iterative process. Trying to write your whole program in one fell swoop often leads to something unusable. Instead, you write something simple, test it out and make changes until it works. And then you move on to a more complex version of it.
Solving Problems — Taking Something Complex and Breaking It Down into Simpler Pieces
I started the mentorship wanting to learn how to use programming to solve problems, real practical problems. I've learned that solving the big problem has been an exercise in breaking it down into a series of small problems, and further breaking those small problems into even smaller ones. The resulting problems have become so small that they show up as an error message on the screen, one that can be looked up by googling it. Occasionally there is no precedence for your problem. In that case, your thinking skills have to kick into gear, and trial and error come into play.A Demo of the Iterative Process
In this post, I will be demonstrating the iterative process of programming. I've developed the map portion of my app in an iterative manner. In the previous post, I had shown some pseudocode regarding the map portion. Below, I've updated the pseudocode, which tells you how to get GPS coordinates from user's browser and displays them on a map:
Version 1 of Maps Code: Get One Set of Coordinates in Browser
The first iteration of my code called "maps.html" gets one set of coordinates from the browser. This is the simplest scenario in geolocation coding. The HTML and JavaScript code below shows how to do that.
Version 2 of Maps Code: Get Multiple Sets of Coordinates in Browser
The second iteration to this code is now that we've figured out to get one set of coordinates, let's get multiple coordinates as the user moves around. I do that in the code below.
I've replaced the function getCurrentPosition() with watchPosition(), a geolocation function that will give a user's location every time they move. The watchPosition() function returns an id, which you can use if you want to stop watching a user's position. In this code, I add a "Start Tracking" and "Stop Tracking” button. In the initial state, you can only press the "Start Tracking" button since I've disabled the "Stop Tracking” button. And once you press the start button, the start button becomes disabled and the stop button is enabled. This is done so that any given point in time the user can not press anything they're not supposed to press. The coordinates are stored in a list. They are printed out as a list in the area where it says "You are nowhere!". Below is what the web page looks like when you first load it.
Version 3 of Maps Code: Incorporate the Real-Time Aspect by Using WebSockets
At this point, having achieved the first step of my pseudocode (which is to get user's coordinates), we can move on to the second step of the pseudocode (which is to send the coordinates to the server). To achieve the real-time aspect of the geolocation tracking, I used a communication protocol called WebSockets. Usually, a web browser communicates to the server with an HTTP request-response protocol. Your web browser sends a request to the server, asking for data. The server sends a response, and then the connection is closed between the browser and server. WebSockets allows one to keep a connection between the browser and server open constantly. It's bi-directional. The browser can initiate an interaction, or the server can initiate an interaction.Long Polling vs WebSockets
Real-time tracking for my app could be implemented with HTTP with something called long polling. That is, the browser can send a request to the server asking, "Do you have new data for me?" The server holds the request open until it has new data. When it has new data, the server sends it to the browser. The browser is said to have pulled the data from the server. After the browser gets the new data, it immediately sends out another request to the server, "Do you have new data for me?" And this interaction repeats.
With WebSockets, the browser doesn't have to keep asking the server if there's new data. When the server gets any new data, the server can push that new data to the browser. In other words, when a server gets new data, it can just say to the browser, "I have new data. Here it is." This is a more elegant and efficient way of implementing real-time.
Why Do We Need WebSockets?
Why is this important for us? When a user moves, we want to be able to send the new set of coordinates to the server. After the server stores this new set of coordinates, we then get the list of coordinates from the database. And then we want to push this data to the browsers of all of the members in the search party.Django Channels Implements WebSockets
Django has a library called Channels that will give us access to WebSockets. I worked through the tutorial for Channels.https://channels.readthedocs.io/en/latest/tutorial/part_1.html
https://channels.readthedocs.io/en/latest/tutorial/part_2.html
The tutorial creates a basic chat server. After having done this tutorial, I needed to incorporate what I'd learned about WebSockets to my existng maps code.
WebSocket in the Maps Code
This is what it looks like with WebSockets implemented in the maps code. The code below is on the front-end in the form of HTML and JavaScript.Below is what the web page for my maps code looks like. My web page has two areas.
The first area is where the coordinates are gotten from the browser and displayed to the browser. This was originally in the second version of our maps code. The second area, which is new, is the text area. When coordinates are gotten from the browser, the coordinates (which is basically in the form of text) is sent to the server. When the server gets those coordinates, it then pushes it to everyone that is subscribed to a group. Because we are in this group, the coordinates comes back to our browser and it then shows up on the screen.
Contrast this the first area. In the first area, the coordinates are not sent anywhere and are just updated in our screen by using JavaScript. The reason why I coded both of these areas on the same page was make sure that the coordinates in the second area matched the coordinates in the first area. That is, I wanted to make sure that WebSockets was working correctly.
The Modularity of Programming Gives Us Freedom
So that concludes the WebSocket portion of the app. Because of the modularity of programming, the next task I can choose to work on can be storing the coordinates in the database (which is on the back-end). Or I can just as easily work on the front-end by trying to display the coordinates on a map in the browser. I don't necessarily have to work on the things in my pseudocode in order. As long as I make sure each part works correctly, each part can be worked on separately.Summary
I hope it was helpful to see the iterative process of the maps code. First I started out with displaying just one set of coordinates. And these coordinates shows up immediately after the user gives us permission to use geolocation. In the second interation, I got multiple sets of coordinates. I could control when I started tracking with start and stop buttons. The third iteration of the maps code was incorporating WebSockets. This allowed me to implement the real-time tracking aspect of the app. I started out with a simple version of the maps code and progressively made it more complex with more features. At each step, I had to test and make sure things were working before I moved on to coding something more complex. Coding it this way cuts down on bugs and ensures that you have a working version at any point in time.Closing Thoughts
Photo Caption: Life as a Web Developer
Participating in the ChiPy Mentorship program has been really great. I’ve learned so many things from deployment to tooling and software design. It's shown me areas in which I want to further develop such as Bash scripting and database design. I've learned to take an idea and bring it to life. What's really been helpful is when I've been murky on a concept, my mentor has been able to draw a diagram and explain it to me.
Words in a novel are not just a bunch of texts. There are stories and plot lines and arcs. Code isn't just a bunch of texts. It's data flying back and forth between browsers and servers, and it allows you to ask questions that can sometimes be answered. Will I find my missing pet? Where do I look next?
Thanks to my mentor Austin for making learning to code fun. His enthusiasm and love of coding really made it a fantastic experience. And thanks to the ChiPy Mentorship team Zax and Ray for all of their help and wonderful support. Thanks to software engineer Robert Heaton for his savvy advice and guidance. And finally thanks to the ChiPy community who gave advice in my survey and to Richard, for giving me advice on how to improve on my blog writing. It's been really great to find a community where I can learn programming with.