Creating my first app: Goodbye abstract labs, hello the real deal!

Mary
7 min readMar 5, 2021

--

Image source: Original artwork by author.

I am sitting in my kitchen with my laptop. I need a change of scenery from my home-office, where I have spent enumerable hours finishing my first project as a software engineering student. After six weeks of learning Ruby, I built my first Ruby Gem, a Command Line Interface (CLI) that accesses an external data source and uses Object Oriented Ruby. Learning to code and creating my first project has been a journey. I know I have further to travel, but moving past completing abstract labs and successfully building my very own app, made me feel like I was on top of the world. As I look over my code for my project, I think about:

  • The value of planning.
  • The art of persistence.
  • The opportunity to feel proud.

The value of planning:

Planning my app flow, having a clear picture of what I wanted my app to do, and knowing what I wanted my user to experience were three major pieces of the puzzle. I had a few ideas for the project that I tossed around before I settled on my app, which is called Remotely. The idea from my app stemmed from the pandemic and the benefits of being able to work from home. I decided I wanted to make an app that allowed users to search for remote jobs. I knew I wanted to use an Application Programming Interface (API) to get my data rather than scrape a website. Taking the time to search for a good API, that had the data I needed and didn’t require any authorization (which for my first project added unnecessary complication and more opportunities for my app to break), was well worth the time. My app still broke throughout the coding process and I still ran into complications that made me stuck.

Image source: http://www.quickmeme.com/meme/35dnnt

It was when I went back to review my planning notes, and spent some time adding to my notes about what I had coded, as well as what I wanted my code to do, that I was able to push forward and escape my stuck place. When I refreshed the picture of my end goal, something shifted and I was able to make progress on connecting my classes and making my app run. So for anyone starting out, I would say: plan well, continuously re-read your plan/app flow notes, be patient, be persistent, and enjoy the proud moments.

Image source: Original artwork by author.

The art of persistence:

Getting stuck was part of the process. It happened several times throughout the course of creating my app. I was reminded so many times that coding is like existing in a world where everything is broken. What helped me get unstuck was taking breaks when I needed to, pushing past the frustration, and believing I would get it to work eventually. There were times when I thought I was almost finished, but would find one more step that was needed to help make the code more dynamic and help prevent potential breakage. It was the persistence to make my app more dynamic and more interesting for my user that led to learning opportunities. This project forced me, in a wonderful way, to learn more about Ruby, writing code, making code creative, and debugging. For example, when I used the gem HTTParty to get my data from my selected API, even though the gem is intended to parse the data into a JSON hash that makes it easy to turn into objects, the job description portion was still in HTML format.

It took A LOT of searching and experimenting to change the description element of my hash into normal text for my user to read. Nokogiri allowed me to parse the HTML snippet, I did not need to use OpenURI because I was not parsing directly from a URL, but from my @@all array of created objects. I found that xpath(“//text()”).to_s allowed to find and match the text elements similar to how someone would use CSS and return a string. I wasn’t done with description yet though…

After I got my description element to text, I found that some of the job descriptions were insanely long. I did not want the entire terminal to be filled with a wall of text, so after some experimenting, I found I could use .split[0..100] to select part of the definition, meaning a certain number of words to display for each definition. My understanding is that .split turns a string into an array of strings and then I could access how many words, or elements, of the array I wanted using square brackets like I would for accessing elements based on indexes from any array. Then .join(‘ ‘) to turn back into a readable string with appropriate spacing. Then I wanted to add ellipses so that I could show my user that the description kept going. After getting that to work beautifully, I felt very pleased and accomplished, but I had one more step. I did not like how the description lines went to the edge of the terminal and did not have a clean word wrap to the next line. I found a great gem called WordWrap, which took a bit of playing with to use correctly within my Ruby code. This worked great, but added a line break after my description, before my URL, which I didn’t want. So I had to chain on one more method, a .chomp to take care of the white space.

How job description looked after I created a job object and before using the above mentioned methods.
Job description after Rainbow(WordWrap.ww “Description:” + ‘ ‘ + info.xpath(“//text()”).to_s.split[0..100].join(‘ ‘) + “…”, 100).chomp.green

The opportunity to feel proud:

I could have just ditched including the description in my project, and to be honest I thought about it. A part of my brain said, just give the user the job title, company name, job-type, and job URL. Why not? That’s enough information (this is the conversation that was happening in my brain). But there was a louder voice that said no, I want to work through this. I want to figure it out. Being persistent and determined to make my project fit what I had planned, gave me the opportunity to learn so much more than I would have. And it gave me an opportunity to feel proud of my accomplishments.

Some other successes, which I owe a big thanks to my tech lead for pointing me in the right direction on the first two, were the following:

  • Making my code dynamic enough to allow the user to continually select the next ten job postings. One method and a few dynamic lines in my CLI class allowed for a manageable amount of output to the terminal so my user did not have 300 jobs in one output to scroll through.
  • Using a checker to display a message when the user reached the end of all the job postings for a certain category and then allowing my code to continue running, by giving the user the opportunity to loop back to the beginning of the search.
  • Finding gems that enhanced my app and user’s experience. Three additional fantastic gems I must mention are TTY:Link, Rainbow, and WordWrap. TTY:Link, allowed for me to make a clickable link for each job posting that my user could navigate to and open in a new browser window for more information or to apply. Rainbow allowed me to make my output colorful and fun. Who doesn’t need a little cheer when job searching? WordWrap allowed for the words to fit nicely in the terminal and break between words, instead of going to the edge of the terminal and breaking in the middle of words.

This project would not have succeeded without the support of my tech lead and fellow students. I also want to give a special thank you to REMOTIVE (https://remotive.io/) for providing an array of remote job listings in various categories and creating an API where someone like myself could easily get data. Check out what the information in the API looks like (https://remotive.io/api/remote-jobs?category) as compared to the information in my project below:

In conclusion, the above successes I mentioned are why I fell in love with coding and continuously fall in love with it over and over again. It can be so frustrating at times and it can test you patience, but when you are persistent and continue to test, experiment, debug, search, ask for help, and work towards your goals you will have many opportunities to feel accomplished. When you have a plan, or a goal in mind, and you persevere, you will achieve outcomes that you might not have felt possible. You may say, “it’s broken” 57 times, but when you get to say: “It works!” the feeling is incredible.

Image source: https://www.reddit.com/r/ProgrammerHumor/comments/1lehzz/found_how_i_feel_when_my_code_works/

--

--

Mary

Software Engineer, mother, and former therapist. I am a runner, reader, chai tea drinker, nature lover, and information nerd.