Getting from my CLI project to here has been quite the adventure! I knew this course was going to be a lot of work, but even keeping within the hours I assigned myself, keeping up with the schedule I worked out with my student adviser at the beginning has been a real challenge, with my day job becoming more and more challenging all the time, the amount of travel required increasing, and life in general. But I’m here, finally submitting my second project.
I do want to say off the bat that I wish Flatiron provided more support at the beginning of this section. After I got past my first project review I felt very alone - I know it’s an online, self paced program, but it was the first time I’d had that feeling since starting Flatiron. The level of support, technical and non technical, dropped dramatically. There were literally zero study groups related to what I was working on for about a month. A bright spot was when we got a study group hosted by Avi about how the internet works - that was really interesting and a big boost to my studies. And as time went on and the holidays passed, the number of study groups related to my section did increase and I did get the support I needed to make it through this project. But it was touch and go for a while and I do hope Flatiron can consider supporting this section of the curriculum (particularly the bits right after the CLI project is submitted) a little bit more strongly for other students in the future.
Now on to the work itself. I find that I’m much more inclined to want to spend time working on a project if the subject matter is something that I find interesting. I’m a science nerd. Although my day job is in the field of food science / chemistry, I’m interested in all shapes and sizes of science. And I never got over some of my little kid obsessions like dinosaurs and space. I still read about both when I have spare time and I’m just as fascinated with new discoveries as I ever was. My CLI project was a dinosaur scraper (just saw a Learn magazine article from someone else who did a dino CLI – for the record I was first! :). I really enjoyed building the program and even more so seeing it spew out accurate and interesting data about the subject once it was complete. For Sinatra I decided to continue the trend of ‘fun’ projects and opened it up to that other childhood love, space. I was reading an article about exoplanets – planets discovered outside of our own solar system – and started thinking of the ‘belongs to’ ‘has many’ nature of solar systems. A planet belongs to a star. A star typically has many planets. A planet can even have many moons which in turn belong to a planet. A Sinatra project is born!
Of course a CRUD MVC app by its nature must be interactive and serve some sort of function. My Dinosaur CLI app just spewed out fun facts based on what number you push, but this project would have to serve some higher purpose. So, I designed Exoplanet Indexer. It’s a tool that amateur astronomers / professional nerds could use to keep a basic inventory of new discoveries in exoplanetary science. The focus of the app is exoplanets, so although it would have the functionality to create, view, edit and delete stars, the focus would be on planets and the landing page upon login would be a list of all exoplanets in the database, sorted by system. This view makes the “star” landing page, which just shows a list of all stars, slightly redundant, but is the core of the app. The stars view can allow for a more focused approach when modifying just a star.
Getting the planets to show up on the index page per their parent star was one of my greater challenges in the development of this app. The first problem I ecountered here was having starless planets showing up on the list, unsorted, below all of the neatly organized systems. To resolve this I added a line of code that would prevent starless planets from showing on the page:
planet.name if planet.star_id!=nil
Only show a planet’s name if the planet’s star’s ID isn’t nil. That worked. But led me to another train of thought – why am I allowing starless planets to exist at all in this system when it’s not realistic for a planet to exist without a star (it CAN happen, but it’s not common, and it’s another discussion). So I had to tweak the new planet form to make sure this could not happen. There are many ways to do that but I took the easy out here and simply made the “star” field “required.” No new stars without planets. I also wanted to make sure that creating a new planet via a star’s page (link says “add to this system”) didn’t come out the other end with an accidentally different star or no star at all. To do this, I needed the new planet form, when accessed via an existing star and only when accessed via an existing star, to default to that planet’s star. That would eliminate human error from this equation. Linking to the new planet form from that star’s view page wouldn’t be enough. This led me to perhaps my most challenging part of this project, how can I get that data to persist from one page to another? I know the ‘params’ hash can do that for me, but what about when the origin page is NOT a form and therefore has no inherent params hash? For example, you start at a planet’s view page and click edit. How can you be sure the new planet form opens up with the correct star name already in that field, so the user doesnt have to type it again or ever worse, leave it blank – either of which would end that planet object’s relationship with the correct star object? I had a feeling my solution here was in params and in the end, it was. I didn’t need a form on the star view page so how am I going to get params on the following page? Hidden forms! We’d been using the ‘hidden’ form type for patching and deleting, why not use it here? So that’s what I did – a hidden form with the name of ‘star_name’ and a value of ‘@star.name’. The hidden form’s ‘submit’ button would be a link to the new planet form. The form method was ‘get’ because honestly, it’s a hidden form, why not. I tested this out with pry and to my amazement, it worked beautifully – from that page and that page only, I could access a params hash within the new planet view which would allow me to pre-populate the star field with the correct star name. Nice!
With this in place and my basic MVC and CRUD in place I thought it was downhill from there, almost ready to submit the project! I just wanted to add some CSS to make it look decent (decent, not great – I’m still learning!) and I also had to incorporate “slugs” that I’d learned about a few labs back, because a URL of “planets/23” is pretty useless compares to “planets/mars”. I’d done this before so should’t be a problem, right? Wrong! This ended up taking me a few more days (working a couple hours a day) to incorporate and since I was doing it after the fact instead of during development, it led to innumerable bugs which I had to sort out, both in the views and controllers. However, it too got done and now the app has nice URLs like “planet/methuselah” and “star/PSR-B1620.”
And then I really was in the home stretch. As a bonus, Sinatra-focused study groups had geared up again in earnest so I really was getting a great deal of support at this important stage of the curriculum. I still wanted some decent CSS and felt that CSS was one of my weaknesses in the curriculum so far. I heard “bootstrap” mentioned at a couple of study groups and decided to see if that could make my life easier. Watched a one hour tutorial on YouTube and it gave me the info I needed to get some basic bootstrap CSS into this app. I’d like to refine this as time goes on and I will do so, but for now I think it looks presentable enough to be submitted, so that’s what I’m about to do.
One other t hing I wanted to mention was that this was the section that led me to totally transform my local environment. I was working from Windows 10 throughout the first part of the course. I did install WSL but for the most part I was using pure Windows and the in-browser IDE for my coding, only dipping into WSL to play around once in a while. As I moved through Sinatra I noticed the in browser IDE crashing more than usual and disconnecting more than I was OK with and realized I needed a better solution. The disconnections may have been partly on my end as my coding area is quite far from my router, but either way, I saw the complexity of some of these labs and realized that I needed something more stable. I tried VisualStudio in Windows and honestly didn’t love it. Of course, I don’t really know how to use it. But it wasn’t the simple solution I needed at the time. I wanted something like the IDE, or even better, the terminal plus Atom I keep seeing in the videos. Not having the $2500 on hand for a Macbook Pro I started to consider my options. Pretty quickly I realized that converting my Lenovo gaming laptop with Windows 10 into a dual boot, Ubuntu / Windows machine, with a dedicated partition for each OS, would be the cheap, easy and practical solution. I got this done pretty quickly (thanks again YouTube) and have been running on Linux for a couple of months now and I absolutely love it. I learn so much more on this OS than I ever would have on Windows. I’m keeping Windows on here mainly for gaming, but as far as coding goes, I’m sold on Linux.
So that’s all I’ve got to say about my Sinatra project. Give it a shot sometime if you want to learn a bit about exoplanets or see the structure of my very basic MVC app. It’s certainly not the most practical Sinatra app out there but it sure is fun.