This is the last assessment of the Learn.co online developer program. I chose to build an app that will encourage people to be more involved in their state legislations by providing easy access to data and a way to share that information. The idea for this application came from a realization that many of my friends do not know much about what is happening in their state legislations or even who represents them. In this age of information, I wanted to provide them a format for accessing the relevent information for the next election.
The application is built with an AngularJS frontend and Ruby on Rails API backend. The RoR backend pulls most of its data from the OpenStates.org API, but also uses a SQLite database to provide additional functionality.
The first stage of this application is to provide basic information on all the legislators throughout the United States. Users can either explore legislators by state and chamber, or search for the legislators by their home address. This search feature will be particularly useful in the future as it returns the legislators in their district that they are directly able to vote for.
Future stages will provide access to bills and voting records and the ability to explore commitees. Additionally, I hope to eventually include data regarding campaign finance and possible correlations between voting records and donations. Hopefully, by next voting season, I will have an application that can easily provide information to voters so that they can make educated decisions in the next election.
For this assessment, I built an MVC to manage access to different machines that the Manchester Makerspace. The Makerspace has officers that manage each of the workshops. This app will allow them to set criteria for what a member needs to know before using the equipment and also sign off on those skills for different members. Also, it tracks the skill level so that members will know who to go to for help and relieve some of the burden on officers for signing everyone out on a skill.
Because this app had so many parts, I created a workflow of how the tables are related and what actions everyone is allowed to access/edit. Also, I had to add extra features to meet the assessment requirements. Since I wanted to actually use this for the Makerspace, I spent a lot of time working on the layout of the forms. One of the hardest ones was getting the nested checklists to display properly and then function properly. I actually ended up using a js script to dynamically add skills to a workshop to make it more convenient to mass asssign skills.
The hardest part about getting my app to work was setting up OmniAuth with Devise. I found several difference instructions but they were contridictory and apparently not up to date. I was able to get it working for gMail quickly enough but the Slack oauth functionality was not as easy. Even the documentation on their site was not correct. I eventually had to find clues from a recent update notice; for some reason, Slack didn't update the instructions that they direct you to.
As part of my second assessment with Learn.co, I was tasked with creating a simple web app using Sinatra and ActiveRecord. I wanted to make something usable in my day to day job, so I decided to create a loan management system to help track the different aspects of an SBA 504 loan.
One of the requirements was that users can only modify the content that they create. This doesn't really match the way that LMS systems work at my type of business, but I included it to pass the assessment. When I revise this project to put it into use, I will most likely replace this feature with one that simply updates a "last user" variable.
Putting the app together was quite straightforward since I had made several other Sinatra apps during the course of the program. The biggest issue I had was actually setting the initial program to run with the correct dependencies. I realzied that simply deleting the Gemfile.lock and created databases was the easiest approach to configuration. I am also a little unsure of where to insert Rack::Flash as it doesn't seem to work when I put it in config.ru. I put it in the ApplicationController class, which seems to work fine, but I'm not sure if this is convential.
I felt comfortable enough after creating the app to create a layout.erb with css styling. Adding the css styling was very difficult because I couldn't figure out how the app would read the css files. I did a bunch of research but most of it was very contradicting and didn't work for my application. Eventually, I got it working by putting the css files in a subfolder of public called styles. While this worked, I would have thought that putting it in a subfolder called css would work too, but it didnt.
I'm pretty happy with how the app came out, but I would like to add more features once I learn Javascript, such as being able to sort the lists of entities and loans.
This project was the first Assessment of the Learn.co program. The objective of the project was to create a CLI ruby gem that pulls data from an API or website to create list and detail views. I took a look through the examples that were provided and thought that they were essentially all the same concept of finding a service near you through a popular website. I wanted to learn more about APIs so I took a different approach.
Having studied climate change for my undergrad, I wanted to build something that I would find interesting, useful and expandable. I decided to build a gem that uses the NOAA Climate API to display and compare average temperatures for where I lived. I thought it would be interesting to be able to compare the average temperature of today to the year that I was born. At least, that is where my process on this gem began.
After searching through the NOAA Climate API for several hours, I realized that there were some limitations in getting the data that threatened the accuracy of my gem. The API is limited to return a maximum of 1000 values per request. I was at first going to compare yearly averages but because of this limit, I had to be more specific and compare average monthly temperatures. Once I had the API figured out, I created a blank ruby application to play around with different request variables and ways to access the values stored within the retrieved data. The API returns a JSON string, which I parsed into a hash. The first key of the hash, by default, is labeled "results" conveniently enough. The value of results is an array of data points. The data points are hashes themselves, the keys of which vary by request type.
Once I figured all of this out, it was time to start building the actual app. I used Bundler to set up the initial file and proceeded to work my way through the CLI class and then the NOAA Data class. When I first started the CLI class, I put almost everything into two methods: one to welcome the user and take inputs, and one to interact with the NOAA Data class. However, the more I built, the more I saw a need for more methods to try and stick with DRY principles. The NOAA Data class was fairly simple to build since I had done so much work prior in testing out the API. Knowing that I needed a list view and detail view to complete my assignment, I decided to expand the app to cover every state in the U.S.. Now, the user is able to select from a list of supported states, enter a date, and return the average monthly temperature for that date. Alternatively, users can decide to make a comparison between two data points, which is why I call it a tracker. Of note, users can choose to forgo the list of states and just enter one from memory. The option to view the list of states not only indicates what format the input expects, but also will update for any additions or deletions NOAA makes (i.e. adding Puerto Rico).
I'm quite satisfied with the end product having met my initial goals of creating something useful, interesting, and expandable. Future changes will add more functionality to how the user interacts with the NOAA API and save the results of queries to reduce having to query the same dataset twice.
I graudated college with a plan of working in the legal field for a few years and then applying to law school to study environmental law. After three years of working as a paralegal, I realized I no longer wanted to continue a career in the legal field and began looking for something else. I had a hard time finding something as all of the initial options required returning to school for 2-4 years. While I was not opposed to returning to school, the thought of giving up my income and accepting a lot of debt to try a new career made me nervous.
As I honed my search, I identified several criteria that my future career would have. First, I wanted a career that would allow me to move and travel as I saw fit. I moved almost every three years growing up and loved the experience of moving all over the country and would like to be able to do that once I had a family of my own. Next, I decided that I wanted to build things for a living rather than sell things. I don't remember where I heard it, but there is a phrase that has stuck with me: "In business, everyone is either building or selling." At first, I didn't think this applied while working in the legal field but upon further consideration, I saw that I was selling legal services. Having been a maker all of my life, I wanted a career that aligned with the love I have for building things. Lastly, I wanted a career that did not requrie a long lead tiem to start.
During my search for a new career, I became heavily involved with Manchester Makerspace. At the makerspace, I met several software engineers and had the opportunity to discuss their work-life and how they got to their current position. After looking into it further, I found that a career in software development met all of my above criteria. Also, I had already gotten my feet wet in the subject having done coding for 3D printing and microelectronics projects so I knew that I already liked it. I'm just starting out in my newly chosen field but am so far, incredibly pleased with my decision.