Across The Stack in a Boiling Forest
It really sets in just how proficient you have become when you are coding in two(html/CSS do not count) languages, working on the Font-end Browser and Back-end Terminal simultaneity, and can get through errors all by yourself.
I had this thought when I was halfway through a Global Warming App I built. It tracks temperatures in major cities and actually puts a little science behind the code. This application is full stack with a JavaScript Front-End and a Rails JSON Back-End. There are a few ways to make this type of app. One way is make two distinct directories with a sole HTML/JavaScript Front-End app and a backend directory; essentially building two apps. This has a lot of merit and there are pros and cons to this design strategy. One benefit is there is a better SOC(separation of concerns). Another is if you build this out it will be cheaper and and easier in terms of hosting. When you go into production your JS Front-End app will be easier and cheaper on a CDN . I chose a different software architecture and opted to put the Front-End and Back-End housed together in one directory. That way I could use the power of rails to provide me the ability to build a Back-End JSON server that uses it’s conventional MVC architecture and even have the HTML Embedded Ruby JavaScript Front-End view all in one place. I deployed this app on Heroku with a PostgreSQL database and a name I rather enjoy “boiling-forest”; Here is the GitHub repo and here is how I went into production.
Before we move on I want to point out if you look at the GitHub repo you might notice I actually used both ways to make this application. One way which is live on Heroku where everything is housed in one directory. This allowed me to host it fully packaged in one Heroku app. Otherwise I would need a Heroku Backend rails server app giving data and a Front-End to display it. I actually have this coding and you can find the directory here. The benefit is as you can see smaller JavaScript files and better SOC. However I chose to utilize the javascript_pack_tag to essentially import my JavaScript into my Rails application. One downside is you can only use one pack_tag and needed a giant JavaScript file. I digress lets get back to the app.
This being a Global warming app I needed data on Global warming. I chose OpenWeatherMap which is a free API with paid options that look amazing. I have been using this API since the early days of my programming back in 2018. I can fully be proud of how far I have come. My idea stems from my days of being a student in the College of Medicine where I earned a Bachelor’s of Science. I have a sold understanding of Science and Math and used that knowledge in combo with programming. There are a few ways to track Global Warming. One is simply recording the temperature and showing it is getting hotter over time. My idea acts as a proof to the leading theory that carbon emissions are creating a greenhouse effect. This means that heat will be trapped longer with more CO2 in the air. When the Sun sets the earth starts to cool. If this greenhouse effect is real then we can most definitely prove it. We can demonstrate that the earth takes longer to cool at night once the Sun has set. This will take time but with enough data it will be proven.
There came some decisions that really gave an understanding of MVP. For example I could have set up this app to take in a city from a user and have it added to “their” list of cities to track. That would have required users to create profiles. That requires gems like devise or bcrypt or some gem that authenticates users and keeps passwords secrete. Here The idea was to keep this simple and working. I could go back and add anything I want but I chose to determine what cities will be tracked and what options the app will have.
For MVP I chose to have two options; display the high and low temperatures of today and an option to chose the temperature decrease from night to day. This was the most crucial part of the application and also the most effort to get working. Rails comes with Active Record which is an amazing gem connecting the database and the application models/tables. Under the hood Active Record uses AREL which actually turns your helper method quires into SQL. For example for this App you can do Temp.last which will give you the last temperature record stored in the db. However I needed something a surgeon with a scalpel would be doing opposed to a big knife. I needed the records created at specifically at midnight (beginning_of_day) and maybe 4 am. These would be the coolest recorded temperatures of the day. Moreover the hypothesis is that if global warming is caused by greenhouse gasses(leaving other factors out such as the ocean acting as a Carbon sink) The earth will take longer to cool after the sun set. At this point I am doing real valid science. I would need to work on my PostgreSQL queries which rails will let me use in place of the helper methods powered by AREL. Here POSGRESQL is a cool little page that gives you tips on how to do this.
Beyond using AREL and the built in Active Record methods you can use raw SQL in your queries. They are actually faster and getting data out of the database. For this application I used this method to get the data I wanted to get it giving the correct response. I actually used stackoverflow to aid my problem as This was a more complex query. As you can see in my post I started off with their code. However that wasn’t exactly what I needed. I then busted out an essential skill of a developer; googling how to do something. I ended up finding this great little post that seems like it wouldn’t really help. I then went to a technique I came up with a colleague that also does software. We call it the “Brute Force” technique. Brute Force is just bluntly trying things until they start to work. Below in the picture you can the the @afternoon and @overnight instance variables that point to postgresql queries. I ended up discovering that these where the ones that work. This was after a few hours of typing things that did not work.
Lastly I used logic in the Temp model to determine which records were saved overnight vs afternoon, sort them and then display their decrease in degree per hour. I discovered that you can use a nested sort method in ruby.
Sort in ruby works with a comparison and under the hood used -1 0 and 1. If it evaluated to -1 the element is moved left, 1 is moved right and 0 does not need to move. So in my sort is x is zero this indicates the records have the same city attribute. Then we drop into the nested sort and then do the same for the time the records were created at.
I added some user submittable functionality such that a person could add their own city to track. This was not a challenge but took effort and needed checks because a user would be uploading to my database. Safety is always important and while all the data is opensource It’s good practice to practice best practices for safety. There are the big picture concerns covered here and the move specific things I’m concerned about discussed in this hackernoon post. As mentioned in the above post I have two checks in my app. The first check is at the entry point of the app where the use inputs a string into the from. As soon as a user submits the form, JavaScript does a simple sanitation. Pulling out any common SQL characters and removing them. After all SQL should not be in this input and can only be nefarious. The second is a rails convention of using safe_params to ensure only specific things are permitted to get into the db.
Now my app was fully function with the initial db being seeded with a few cities. These cities would be used to make calls to the third party API openweathermap that would return weather data. This weather data would calculate the rate of global cooling once the sun set. The hypotheses is if greenhouse gas is a factor in global warming it follows the earth should say hot longer after the sun sets over a given period of time. There are other factors to consider such as the ocean absorbing some of this gas. Overall this was a science experiment in global warming with global data taken from reputable sources.
