The Halfway Mark!

Last week marked the halfway point for completing Flatiron’s Online Software Engineering program. The program moves so quickly that it’s hard to stop myself and think, wow, I can build entire web applications when two and a half months ago I was learning the elementary basics of Ruby. The minimal coding experience I had coming into the program (I have taken some courses on HTML, CSS and began teaching myself Javascript) as well as previously working on the tech team of a startup gave me sufficient context as to what I was getting myself into. However, the program’s curriculum is so curated that what I’ve learned in the past 2.5 months probably would have taken me years to learn on my own. Since I’m at the halfway mark, I thought I would share the obstacles I faced and my method of overcoming them.

When to Stop Working

I love the flexibility of learning on my own terms. However, with this comes an undefined start and stop time. You can never be finished with learning how to code. This concept of limitless knowledge is what attracted me to the subject, but as a human being who has relationships, other responsibilities, and a desire for a hefty self-care practice, I had to draw a line with when to stop coding. I make sure to stop learning by 8 p.m. each night. I drew this line because I am unable to sleep well if I have screen time late into the night. I have found that when I cross this boundary, I wake up several times throughout the night and I don’t feel as well rested for the next day. I also set boundaries for when I start in the morning as well. I don’t start coding until 9 a.m. after I have my morning routine of activities that sustain my coding practice— like meditation, yoga, and journaling.

Getting into a Routine and Schedule

This is related to my learnings above, but it’s important to identify when and where you get your most work done. When I first started the program, I stuck with the 9-5 routine I was familiar with. This was problematic because I was rushing to get to my computer by 9 a.m. to begin learning for the day (note: a racy mindset is not good for learning…) and some lectures were getting scheduled post 5 p.m. I learned I had to be less rigid with my schedule. I learn best during the day, so I made sure to do schoolwork for 11 a.m.-4 p.m., and threw in learning time at other parts of the evening depending upon when the live lectures were or how I was feeling.

Also, I learned to be less rigid with where I decided to do my schoolwork. As part of the program, Flatiron gives you access to a WeWork space. I take full advantage, I spend 30 hours a week there. However, if I have an hour and a half lecture to watch or am feeling unwell, it doesn’t make sense to force myself to remain in an environment that isn’t supportive to my learning. Also, on weekends I got to coffeeshops to work as a change of environment and to be around different people.

Meeting with Others to Talk About Code

Flatrion gives you great resources to meet with others. 1:1’s with your cohort lead, pair programming sessions, and organized Study Groups. However, it’s up to you, as the student, to take advantage of these resources. I was on top of creating agendas for my cohort 1:1’s to best make use of the time and was meeting with my partner for pair programming. However, in the beginning of the program, I wasn’t attending Study Groups live. Since the Study Groups were recorded, I figured I could learn just as much at a time that was more convenient for me. But as I was watching the recorded versions I realized I wasn’t experiencing the ‘magic’ of a live lecture. The possibility of getting called on to answer a question, or having an opportunity to ask questions you have are components of what makes a Study Group truly special. This type of interaction helps cement concepts. I stopped perceiving Study Groups as optional and started fitting them into my daily schedule. To enhance my communication with code, I also began meeting with a classmate outside of who I was paired with for Pair Programming. Having additional practice with sharing what I was learning has been super helpful since this program is primarily self-driven.

I’m motivated to take on the second half of this rigorous program. I’d like to think that I’m a bit wiser about my plan of attack to finish up the program strong. Whenever I feel stuck and like I’m going nowhere (I feel this AT LEAST several times a week…) I watch this video by Flatiron’s CEO and founder Avi Flombaum:

I love this video because he doesn’t believe his bootcamp is an easy quick fix to learn how to code (wouldn’t that be nice if that actually existed??) but he does believe that continuous small steps will lead to progress and success.

Hip Opener Sequence

“The morning wind spreads its fresh smell. We must get up and take that in, that wind that lets us live. Breathe before it’s gone.

Sorrow prepares you for joy.

It violently sweeps everything out of your house, so that new joy can find space to enter. It shakes the yellow leaves from the bough of your heart, so that fresh, green leaves can grow in their place. It pulls up the rotten roots, so that new roots hidden beneath have room to grow. Whatever sorrow shakes from your heart, far better things will take their place.”

― Rumi

Ah, hip openers. They’re grounding, sweet, infinite but also uncomfortable and jarring. We come up against unexamined parts of ourselves. Often times in my classes I queue that we store unsaid words or unexpressed emotions in our hips. Where did I get this from? I truly believe that we hold memories and experiences in our bodies. Hip openers may bring up feelings of grief. The grief doesn’t have to be linked to its source, but after a yoga class or a personal practice if grief comes up move through it. Journal about it. Talk to a friend. Often times after the grief passes through, a raw and peaceful feeling may arrive, similar to the dessert of a good cry.

I made this video for my friend Alison, but wanted to share it with you all as well! Enjoy this sweet 30 minute hip opener sequence, perfect for decompressing after a long day.

My First Sinatra Application

I built my first web application! That other people can log into and use! Our project’s requirement was to build a web application using Sinatra as our Framework. I felt like a baby taking their first steps on their own. I was slow and wobbly, but with my earnest attitude I persisted.

My application is named My Book Collection. With My Book Collection you can view all of your books in one application. If you’re anything like me, you have books in different places. I have books in my living room, in my bedroom, and even at my friends’ houses. It can be tough to keep track of where all my books are, especially if I loaned them to a friend. You can view all of your books on a single page with My Book Collection and click on a book to review the book’s status (if it’s on loan, read, unread etc), as well as the book’s author and genre.

My Process:

Before I started coding, I wrote out user stories in my journal. How I expected the app to function, what I wanted the app to accomplish etc. This gave me a clear vision and limited the decision making I had to make while coding. Specifically, I only wanted users to interact with the app if they were logged in. Similarly, I knew I wanted users to have the capability to edit their own book collection.

Main Takeaways:

How to deploy an app on Heroku.

Heroku is a platform where users can deploy their web applications on the web so other people can use it. It took some time to successfully connect my GithHub account with Heroku. When I use a new platform I tend to take the process very slowly to ensure I’m not just mimicking steps but rather understand the process. I envision myself using Heroku for many projects in the future, so understanding how to upload a web application this time around is helped out my future self.

Taste of Ux/UI.

Although my main focus with this project was to understand the backend and how my objects interacted with each other, I had some moments of considering the user experience of my application which was new for me. When I am working on my labs, I’m not as focused on the Ux because my name isn’t tied to the project. However, My Book Collection is completely my own! For example, initially, I had a delete button too close to the edit button. I imagine users will want to edit their books often, it would be frustrating to delete a book when all you wanted to do was update its status! Therefore, I increased the white space between the edit and delete button.

ActiveRecord CRUD.

ActiveRecord comes with many helpful methods to call on objects in order to create, read, update, and destroy objects. This documentation here https://guides.rubyonrails.org/active_record_basics.html was a great reference. I ran the rubygem Tux so I could create and play around with objects in my terminal to test my application’s onjects to make sure they were interacting with one another correctly. Alternatively, I could have created seed data to have for my app, but I wanted to play around with ActiveRecord’s CRUD methods to get more comfortable with them since I was planning to include them in my code. The method that was the most fun to use was the .where method. Calling .where on an object is the SQL equivalent to saying:

Select * from table where column_name = 'condition'

This was helpful because I only wanted users only see their own books. I then added the .each method in order to iterate over each book so it could be listed separately on the user’s page.

<h1>Here are all of your books:</h1>
<%Book.where(user_id: current_user.id).each do |book|%> 
<ul>
  <li>Title: <a href="books/<%=book.id%>"><%=book.title%></a>
    <p>Author: <%=book.author%><br>
    Genre: <%=book.genre%></p>
  </li>
</ul>
<%end%>

Don’t be intimidated by errors.

The instructors at Flatiron try to reinforce the fact that most of the time code is going to be broken. For the most part, I’ve embraced this and this mentality helps when other things besides code aren’t working projects. For example, I ran into an error with Shotgun, which is a RubyGem that let’s you run your application on your local server and updates changes you make in your code in real time, so you don’t have to stop, code, save, and run the application.

The error caused my browser to look like this:

This was in my terminal:

Set SINATRA_ACTIVESUPPORT_WARNING=false in the environment to hide this warning.
objc[1464]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called.
objc[1464]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

Luckily, I googled my error and found that other people had the same issue and there was a Issue thread on Shotgun’s GitHub repository, link here: https://github.com/rtomayko/shotgun/issues/69. I ran through all of the suggested resolutions, and ultimately I had to update my Mac’s software to Mojave and then install macOs’ Xcode which added components to get Shotgun up and running. It probably took me 3 hours to resolve this issue, between the software updates, trying out different resolutions, and talking to my fellow cohorts to see if they had any ideas. However, this experience taught me that I’m not alone with the issues I experience. There are very generous people out there who have run into the same error and decided to write about it! Also, I was proud of myself for remaining level headed and persisting in order to solve my problem.

As always, I learned a TON about ActiveRecord and Sinatra by building my app. It reinforced my foundation which is important for our next section… Rails!

P.S. here’s a walkthrough of the app!