feed.xml

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mina Slater</title>
    <description>Javascriptress | Rubyist | Nacho Monster</description>
    <link>https://minaslater.blog/</link>
    <atom:link href="https://minaslater.blog/feed.xml" rel="self" type="application/rss+xml" />
    <pubDate>Fri, 10 Jan 2020 23:31:26 -0600</pubDate>
    <lastBuildDate>Fri, 10 Jan 2020 23:31:26 -0600</lastBuildDate>
    <generator>Jekyll v3.8.5</generator>
    
      <item>
        <title>Too Beginner to be a Conference Speaker? NEVER!</title>
        <description>&lt;p&gt;When I changed careers into tech, I had a mental retro about what I could’ve done better in my past career, coming to the conclusion that:&lt;/p&gt;
&lt;ol&gt;
  &lt;li&gt;I didn’t stay connected enough to the community and…&lt;/li&gt;
  &lt;li&gt;I found situations that were comfortable and held onto them, avoiding opportunities that challenged me.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;So, I made a conscious decision to do the opposite of both of those. I looked for leadership and organizing opportunities in the local tech community and identified things that I was scared of doing, and actively sought out chances to do them.&lt;/p&gt;

&lt;p&gt;Public speaking topped that list. 😱&lt;/p&gt;

&lt;p&gt;Fast-forward to 2019, after sending out CFPs (calls for paper, or talk proposals) here and there for a year, I got my first acceptance to a major conference, RailsConf. 🎉 It was a conference that I had wanted to go to for a couple years, where some of my Coding Heroes will be presenting, as well. Naturally, I was at the same time excited, honored and of course, terrified!&lt;/p&gt;

&lt;p&gt;Spoiler alert: I survived.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/eYG8hAr.gif&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Since RailsConf in May I have given that same talk two more times, at THAT Conference in WI and RubyConf, getting less and less terrified each time. Some folks (mostly other Code Newbies) have expressed shock that at less than 2 years in tech, I was “already” speaking at conferences. I always told them that they can too, and should.&lt;/p&gt;

&lt;p&gt;Here are the reasons why.&lt;/p&gt;

&lt;h2 id=&quot;fresh-perspective&quot;&gt;Fresh Perspective&lt;/h2&gt;

&lt;p&gt;We bring a set of new perspective with us when we come into the tech industry. Our experiences before entering tech might inform a simpler approach to completing the task or we might ask different questions than a Senior Engineer would. While our experience might be limited, we are also not weighed down by the same indoctrination and baggage as someone who’d spent decades in the industry. CodeNewbies are inventive. We don’t have the notion of “we’ve always done it this way”; All these tools are new to us and in our attempt to manipulate computers to do complicated things, we sometimes discover new ways to use these tools that folks might not have thought of.&lt;/p&gt;

&lt;p&gt;And what better place to share these discoveries than on a conference stage?!&lt;/p&gt;

&lt;h2 id=&quot;motivation-to-learn&quot;&gt;Motivation to Learn&lt;/h2&gt;

&lt;p&gt;When I first decided to submit a proposal for a conference talk titled “Bridging the Knowledge Gap: Debugging”, I was not good at it. Whenever I had to track down a bug, I froze. I had no idea when to use what tool.&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;Should I put a &lt;code class=&quot;highlighter-rouge&quot;&gt;binding.pry&lt;/code&gt; somewhere? If yes, where?&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I always forgot to look for information in error messages or server logs. My pair, if I was pair programming, always had to make suggestions and point out the next steps to me. I constantly wished that my bootcamp had taught me more about debugging.&lt;/p&gt;

&lt;p&gt;The purpose of the talk, other than to get into speaking, was to pick a topic that I want to get better at or know more about. This gave me a reason and accountability to do a deep dive that I otherwise might keep putting off. I learned so much during the research phase of preparing the presentation. Now that I’ve given the talk a few times, I’m feeling more comfortable applying those tools in my daily workflow.&lt;/p&gt;

&lt;h2 id=&quot;professional-advancement&quot;&gt;Professional Advancement&lt;/h2&gt;

&lt;p&gt;Long before my first trip as a speaker to RailsConf, I’ve wanted to go as an attendee. I streamed the talks from the main room from afar the two years prior to 2019. I watched videos of presentations by really smart folks like &lt;a href=&quot;https://twitter.com/tenderlove&quot;&gt;Aaron Patterson&lt;/a&gt;, &lt;a href=&quot;https://twitter.com/eileencodes&quot;&gt;Eileen Uchitelle&lt;/a&gt; and &lt;a href=&quot;https://twitter.com/searls&quot;&gt;Justin Searls&lt;/a&gt;. I always learned a lot from their talks and regarded them as “coding celebrities”.&lt;/p&gt;

&lt;p&gt;Attending conferences, it’s pretty much a given that you’ll meet new people and create professional connections. Attending as a speaker takes this to a whole new level.&lt;/p&gt;

&lt;p&gt;A lot of conferences host a reception or dinner for speakers at some point. The ones that I had been a part of took place the night before the first day. At these events, I was able to meet some of the people I looked up to in the Ruby community. I can say, with 100% truthfulness, that I “had dinner with DHH”, the creator of Ruby on Rails. We don’t have to talk about the fact that it was in a room of about 100 people.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/Md6erde.gif&quot; /&gt;&lt;/p&gt;

&lt;p&gt;My favorite interaction with one of the “coding celebrities” mentioned above was when Justin Searls tweeted about being nervous before a talk after 10 years of speaking, I replied that it was a relief to hear him say that as a first-time speaker. Then, &lt;em&gt;he came to my talk and complimented me afterwards&lt;/em&gt;! 😮&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/owHDvmu.png&quot; width=&quot;350px&quot; /&gt;
&lt;img src=&quot;https://i.imgur.com/Xrh1giH.png&quot; /&gt;&lt;/p&gt;

&lt;p&gt;More than that, I have met folks who inspired and encouraged me to write more (&lt;a href=&quot;https://dev.to/molly_struve&quot;&gt;Molly Struve&lt;/a&gt;), speak more (&lt;a href=&quot;https://twitter.com/leenyburger&quot;&gt;Colleen Schnettler&lt;/a&gt;), take better care of myself (&lt;a href=&quot;https://twitter.com/avdi&quot;&gt;Avdi Grimm&lt;/a&gt;), among others. Many of whom I also now consider friends.&lt;/p&gt;

&lt;h2 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h2&gt;

&lt;p&gt;All that said, the best reason I have found for me to keep speaking (even though imposter syndrome runs amok) is this:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;There’s always someone working to be where you are.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Even though I started speaking as a major stretch goal in a new career and to face my fears of public speaking, I keep doing it because I want to inspire other early-career developers to get up and speak about their learnings and experiences. Experts shouldn’t be the only voices we hear on conference stages. &lt;strong&gt;Representation matters.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Now I’m going to shamelessly include a video of my first conference talk (click to play):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://www.youtube.com/embed/g1PxL1T4Z4s&quot;&gt;&lt;img src=&quot;https://i.imgur.com/RT4apqT.jpg&quot; /&gt;&lt;/a&gt;&lt;/p&gt;

&lt;h2 id=&quot;resources&quot;&gt;Resources&lt;/h2&gt;

&lt;p&gt;Articles on writing proposals:&lt;br /&gt;
&lt;a href=&quot;http://www.noelrappin.com/railsrx/2014/3/17/what-i-learned-from-reading-429-conference-proposals&quot;&gt;What I learned from reading 429 conference proposals&lt;/a&gt; by Noel Rappin&lt;br /&gt;
&lt;a href=&quot;http://www.noelrappin.com/railsrx/2014/1/18/conference-prompts-or-how-to-submit-proposals-and-influence-people&quot;&gt;Conference Prompts: Or How to Submit Proposals and Influence People&lt;/a&gt; by Noel Rappin&lt;br /&gt;
&lt;a href=&quot;http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/&quot;&gt;What Your Conference Proposal Is Missing&lt;/a&gt; by Sarah Mei&lt;/p&gt;

&lt;p&gt;I would also recommend checking out your local &lt;a href=&quot;https://www.writespeakcode.com/&quot;&gt;Write/Speak/Code&lt;/a&gt; meetups. They do a great program called Own Your Expertise that I highly recommend.&lt;/p&gt;
</description>
        <pubDate>Fri, 10 Jan 2020 00:00:00 -0600</pubDate>
        <link>https://minaslater.blog/2020/01/10/conference-speaking-as-a-codenewbie/</link>
        <guid isPermaLink="true">https://minaslater.blog/2020/01/10/conference-speaking-as-a-codenewbie/</guid>
        
        <category>CodeNewbie</category>
        
        <category>Speaking</category>
        
        <category>Conferences</category>
        
        <category>Twitter Thread</category>
        
        
      </item>
    
      <item>
        <title>Bridge the Knowledge Gap, Debugging 3 - Print &amp; Interactive Debugging</title>
        <description>&lt;p&gt;&lt;em&gt;Part Three of the &lt;strong&gt;Bridging the Knowledge Gap&lt;/strong&gt; Series on Debugging&lt;/em&gt;&lt;br /&gt;
&lt;em&gt;Check out Part One &lt;a href=&quot;/2019/11/24/debugging-part-one/&quot;&gt;here&lt;/a&gt;&lt;/em&gt;
&lt;em&gt;and Part Two &lt;a href=&quot;/2019/12/09/debugging-part-two/&quot;&gt;here&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Learning syntax is only a small part of being a developer. The transition from coding bootcamp or online tutorials to the Real World can be a struggle. The objective of this series of blog posts is to summarize the knowledge that I gained during my own transition period (and beyond), and pay it forward to those that find themselves in a similar position.&lt;/p&gt;

&lt;h3 id=&quot;debugging&quot;&gt;Debugging&lt;/h3&gt;

&lt;p&gt;A reminder of the debugging topics that we will be covering:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;
    &lt;p&gt;&lt;a href=&quot;/2019/11/24/debugging-part-one/}&quot;&gt;“Look under the hood” - Print &amp;amp; interactive debugging&lt;/a&gt;&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;&lt;a href=&quot;/2019/12/09/debugging-part-two/}&quot;&gt;“Tap the phone line” - Network monitoring &amp;amp; server logs&lt;/a&gt;&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;General tips&lt;/p&gt;
  &lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&quot;part-three-general-tips&quot;&gt;Part Three: General Tips&lt;/h2&gt;

&lt;p&gt;Bugs and errors are normal parts of software development, because developers are only human. We have already covered some tools that will help us debug our program. In this post, we will have a look at some approaches that have worked for me. They’re not “best practices” (what does that mean, anyway?!), just some mindsets I have picked up from my mentors and peers along the way.&lt;/p&gt;

&lt;h3 id=&quot;scenario&quot;&gt;Scenario&lt;/h3&gt;

&lt;p&gt;Recently, my pair Shamyle and I wrote a method to sort some ActiveRecord objects returned from a couple of queries into one list. We had one database query that returned an ActiveRecord Relation, a list of Evaluations, and another query that returned one single Evaluation. The purpose of our method was to sort these results into one list based on certain attributes, so that the frontend will display them in the proper order.&lt;/p&gt;

&lt;p&gt;Something like this (shortened for reasons):&lt;/p&gt;
&lt;div class=&quot;language-ruby highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;&lt;span class=&quot;k&quot;&gt;def&lt;/span&gt; &lt;span class=&quot;nf&quot;&gt;display_evaluations&lt;/span&gt;
  &lt;span class=&quot;n&quot;&gt;list_query&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;no&quot;&gt;Evaluations&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;nf&quot;&gt;where&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;(&lt;/span&gt;&lt;span class=&quot;o&quot;&gt;...&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;attributes&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;)&lt;/span&gt;
  &lt;span class=&quot;n&quot;&gt;single_query&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; &lt;span class=&quot;no&quot;&gt;Evaluations&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;nf&quot;&gt;find_by&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;(&lt;/span&gt;&lt;span class=&quot;o&quot;&gt;...&lt;/span&gt;&lt;span class=&quot;n&quot;&gt;other&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;attributes&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;)&lt;/span&gt;
  &lt;span class=&quot;n&quot;&gt;list_query&lt;/span&gt; &lt;span class=&quot;o&quot;&gt;&amp;lt;&amp;lt;&lt;/span&gt; &lt;span class=&quot;n&quot;&gt;single_query&lt;/span&gt;
  &lt;span class=&quot;n&quot;&gt;list_query&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;.&lt;/span&gt;&lt;span class=&quot;nf&quot;&gt;sort&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;(&lt;/span&gt;&lt;span class=&quot;ss&quot;&gt;date: :desc&lt;/span&gt;&lt;span class=&quot;p&quot;&gt;)&lt;/span&gt;
&lt;span class=&quot;k&quot;&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With a fully green test suite and the UI revealing no unexpected behaviors, after the team reviewed it, we merged it into the codebase.&lt;/p&gt;

&lt;p&gt;A couple hours later, when Sasha was working in the QA environment, she found that the page we worked on was broken. After a little bit of investigating, she concluded that the page couldn’t render because one of those queries to the database returned nothing. Our method was adding a &lt;code class=&quot;highlighter-rouge&quot;&gt;nil&lt;/code&gt; into the list of objects we pass to our frontend, but when it tried to display something that was undefined, everything fell apart.&lt;/p&gt;

&lt;h3 id=&quot;tip-1---write-tests&quot;&gt;Tip #1 - Write Tests&lt;/h3&gt;

&lt;p&gt;One of the first things I do when I find a bug now is write tests because we want to make sure that any future changes to the code won’t result in the same bugs again. Tests to cover the conditions under which our bugs show up will prevent that code regression and let us know when the bug has been fixed.&lt;/p&gt;

&lt;p&gt;For the case above, I ended up working with her to find a solution for the bug and the first thing she suggested we do was write tests to cover this particular state of the program. Our test basically said, “hey, if one of the queries came back with no result, exclude it from the list of objects to render by not pushing it to the array we return!”&lt;/p&gt;

&lt;p&gt;We didn’t know when we started debugging what specific lines of code we needed to change or what that change looked like. But backed up by the tests, we would know right away when it’s been fixed. Having comprehensive tests can also help with our next tip.&lt;/p&gt;

&lt;h3 id=&quot;tip-2---make-small-incremental-changes&quot;&gt;Tip #2 - Make Small, Incremental Changes&lt;/h3&gt;

&lt;p&gt;When I first started coding, I had the tendency to make (what I know now to be) wild guesses about the cause of my bugs. I would encounter something that’s broken and immediately try to fix it in the code, glossing over the error messages. In my random attempt at a solution, I might touch multiple files and methods. At the end of the flailing, the bug would either still be there or something else altogether was broken, and I would have no idea where to begin backtracking the many changes I just made. 😱&lt;/p&gt;

&lt;p&gt;Tech folks like to talk about TDD (Test Driven Development) as a Best Practice. I would also define TDD as Test Driven Debugging. Regardless whether our task is to create a new feature or fix a buggy old feature, having tests gives us a roadmap to our goal.&lt;/p&gt;

&lt;p&gt;Sasha and I wrote our tests, and much like with the TDDev approach, each change in code only addressed the specific way the tests were failing or a specific error we saw &lt;em&gt;at that moment&lt;/em&gt;. So each time we tried a solution, we would run the tests, hoping that they would fail in new and exciting ways, informing our next step(s).&lt;/p&gt;

&lt;h3 id=&quot;tip-3---challenge-assumptions&quot;&gt;Tip #3 - Challenge Assumptions&lt;/h3&gt;

&lt;p&gt;Bugs exist because we think our codes works one way when it really works another way. There are things about our program that we take for granted to be true. How many times have you said something like this:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;This method returns an array of objects, so when we call it here, the other method can iterate through it.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;…only to find that the first method returns a different data structure sometimes?&lt;/p&gt;

&lt;p&gt;They say that the first step to recovery is admitting that you have a problem. In order to debug efficiently, we have to admit that what we think we know about our code isn’t always true. We can begin by asking ourselves these questions:&lt;/p&gt;

&lt;p&gt;🚨What do I &lt;em&gt;think&lt;/em&gt; my code is doing?&lt;br /&gt;
🚨What is my code &lt;em&gt;actually&lt;/em&gt; doing? (by using some tools from Parts 1 and 2, maybe)&lt;br /&gt;
🚨How does this disconnect cause problems in the program?&lt;/p&gt;

&lt;p&gt;In the case of our example:&lt;br /&gt;
💡I thought both of my queries would return &lt;em&gt;something&lt;/em&gt;.&lt;br /&gt;
💡…but in actuality, those queries could return nothing from the database.&lt;br /&gt;
💡When the frontend tries to iterate through and display components for each item in the list, it doesn’t know what to do with an &lt;code class=&quot;highlighter-rouge&quot;&gt;undefined&lt;/code&gt; or &lt;code class=&quot;highlighter-rouge&quot;&gt;null&lt;/code&gt;.&lt;/p&gt;

&lt;h2 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h2&gt;

&lt;p&gt;Sometimes in our jobs as developers, it feels likes we’re just putting out fire after fire.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/QvlRjA6.gif&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;So, good debugging habits are almost as important as writing clean code.&lt;/p&gt;

&lt;p&gt;In a perfect world, bootcamps would put more emphasis on teaching the techniques and practice of debugging; it would prevent their graduates from learning bad habits and prepare us better for our first jobs.&lt;/p&gt;

&lt;p&gt;I’d like to go back to Aaron Patterson again here to close this talk. I found a tweet the other day, that he had pinned from back in January.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/i7GVEHs.png&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Knowing Tenderlove, he was probably making a joke, but this actually made me feel more at ease about debugging. Because when we frame it in this way, errors and bugs are just edge cases that we haven’t considered yet. So we shouldn’t be intimidated by them.&lt;/p&gt;

&lt;p&gt;And, I hope after these three posts, you are now empowered to debug with confidence!&lt;/p&gt;
</description>
        <pubDate>Fri, 27 Dec 2019 00:00:00 -0600</pubDate>
        <link>https://minaslater.blog/2019/12/27/debugging-part-three/</link>
        <guid isPermaLink="true">https://minaslater.blog/2019/12/27/debugging-part-three/</guid>
        
        <category>CodeNewbie</category>
        
        <category>Debugging</category>
        
        <category>Ruby On Rails</category>
        
        <category>Basics</category>
        
        
      </item>
    
      <item>
        <title>Bridge the Knowledge Gap, Debugging 2 - Network Monitoring and Server Logs</title>
        <description>&lt;p&gt;&lt;em&gt;Part Two of the &lt;strong&gt;Bridge the Knowledge Gap&lt;/strong&gt; Series on Debugging&lt;/em&gt;&lt;br /&gt;
&lt;em&gt;Check out Part One &lt;a href=&quot;/2019/11/24/debugging-part-one/&quot;&gt;here&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Learning syntax is only a small part of being a developer. The transition from coding bootcamp or online tutorials to the Real World can be a struggle. The objective of this series of blog posts is to summarize the knowledge that I gained during my own transition period (and beyond), and pay it forward to those that find themselves in a similar position.&lt;/p&gt;

&lt;h3 id=&quot;debugging&quot;&gt;Debugging&lt;/h3&gt;

&lt;p&gt;A reminder of the debugging topics that we will be covering:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;
    &lt;p&gt;&lt;a href=&quot;/2019/11/24/debugging-part-one/}&quot;&gt;“Look under the hood” - Print &amp;amp; interactive debugging&lt;/a&gt;&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;“Tap the phone line” - Network monitoring &amp;amp; server logs&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;General tips&lt;/p&gt;
  &lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&quot;part-two-tap-the-phone-line&quot;&gt;Part Two: Tap the phone line&lt;/h2&gt;

&lt;h3 id=&quot;browser-developer-tools&quot;&gt;Browser Developer Tools&lt;/h3&gt;

&lt;p&gt;As web developers, testing features in the browser as we write code is a fairly standard practice in our typical development flow. Usually, when things aren’t working properly, we would expect to see some kind of error in the browser or Javascript console. However, oftentimes, we would be faced with an unresponsive UI or a blank screen.&lt;/p&gt;

&lt;p&gt;Something that’s really useful in these cases is built right into the browser. If we open up the developer tools, we can see all these tabs. The most useful ones, from left to right, are Elements (HTML &amp;amp; styling), Console (Javascript) and Network (server activities).&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/Ab5tqGE.png&quot; alt=&quot;Screencap of puppy app with the developer tools open and Elements, Console and Network highlighted&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;In the Network tab, lives a log of our network activities. It shows us whether our app’s resources are being downloaded or uploaded correctly, and the status of our application’s trips to and from the server.&lt;/p&gt;

&lt;p&gt;When we first open up the dev tools, we won’t see anything in the logs yet. But once the tab is open, we can reload the page or repeat the action that was problematic and watch the logs populate with all the network activities.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/50cTDFH.png&quot; alt=&quot;Network tab with a 500 status request&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Each row in the table at the bottom represents an HTTP request and the column gives you more information about each of the requests. The ones that I look at most often are the name of the resources, the status, which is the HTTP response code, and the resource type.&lt;/p&gt;

&lt;p&gt;Some lines will appear in red if there are bad requests, maybe a 500 internal server error or a 403 forbidden.&lt;/p&gt;

&lt;p&gt;When we click into one of these lines, we have access to more details like the request and response headers, and the response body. These sections will let us look at the requests more closely. I typically check to make sure the requests are going out to server with all the information that the backend needs to properly process the request.&lt;/p&gt;

&lt;p&gt;In the Headers tab under an individual request line, there’s a request payload section that will tell us what information went out to the server, and we can see whether it’s behaving as expected or identify where it’s not.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/KGTwIaX.png&quot; alt=&quot;Response tab in Network that shows a 500 returned from the server&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;On the flipside, there’s a Response tab that will show us what came back from the server as a result of our request.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/wC9X9s7.png&quot; alt=&quot;Response tab in Network that shows a 500 returned from the server&quot; width=&quot;550px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;In this case, it looks like our request resulted in a 500 internal server error, because it raised an ArgumentError on the backend because we gave some method the wrong number of arguments.&lt;/p&gt;

&lt;h3 id=&quot;server-logs&quot;&gt;Server Logs&lt;/h3&gt;

&lt;p&gt;We can also look for similar information from the server-side by peeking into the server logs.&lt;/p&gt;

&lt;p&gt;This is the place our backend will log information about each request coming in, how the server resolves the requests and the result. This is where exception and warnings will show up and where the Pry session will open if the program hits a breakpoint.&lt;/p&gt;

&lt;p&gt;We have here the Rails server for Puppygotchi, the example app from &lt;a href=&quot;/2019/11/24/debugging-part-one/}&quot;&gt;Part One: Look Under the Hood&lt;/a&gt;. This is all the information the server logged during for the same action from when we saw the network logs in the browser.&lt;/p&gt;

&lt;p&gt;Like with the network tab, we can see the HTTP request and which route it hits (Box 1), the response status code (Box 2), and the exception that was raised (Box 3), which we saw in the browser returns as part of the response body.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/DdDAFTM.png&quot; alt=&quot;Rails server that logs the route a request hits, the response code and any exception or error raised&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;takeaway&quot;&gt;Takeaway&lt;/h3&gt;

&lt;p&gt;There are a lot of more advanced ways to read both the Network tab and the server logs, and get them to even better clues on how to approach our bugs. When I was first getting started, I had a hard time even remembering to look in these places; let alone knowing what it was telling me. This is only meant to point out something that’s easy to overlook:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;Even though a bug manifests itself on the frontend doesn’t necessarily mean it’s something wrong with the frontend code.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I wasted a lot of time looking in all the wrong places only to realize that it was actually a backend issue disguising itself as a frontend error.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/A3ypjb2.gif&quot; alt=&quot;Captain Marvel drops through the ceiling of a bus to beat up an old lady&quot; width=&quot;500px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;I also recommend keep an eye on the Network tab and the server logs as a matter of practice, because it is really beneficial to be familiar with how our programs. As we can saw, the logs don’t always tell us when something is misbehaving; they mostly just tell us what is happening. The output definitely are not always color-coded, so if we know what the logs look like when it’s correct, we will be able to spot when it’s not.&lt;/p&gt;

&lt;p&gt;Be patient. The more we read these logs and error messages, the easier it would be next time to spot the important things.&lt;/p&gt;
</description>
        <pubDate>Mon, 09 Dec 2019 00:00:00 -0600</pubDate>
        <link>https://minaslater.blog/2019/12/09/debugging-part-two/</link>
        <guid isPermaLink="true">https://minaslater.blog/2019/12/09/debugging-part-two/</guid>
        
        <category>CodeNewbie</category>
        
        <category>Debugging</category>
        
        <category>Ruby On Rails</category>
        
        <category>Early career</category>
        
        
      </item>
    
      <item>
        <title>Bridge the Knowledge Gap, Debugging 1 - Print &amp; Interactive Debugging</title>
        <description>&lt;p&gt;&lt;strong&gt;Part One of the &lt;em&gt;Bridge The Knowledge Gap&lt;/em&gt; series on Debugging&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;As a Career Changer, like many others, I went through a coding bootcamp, where they taught me the very basics of building a web app. Since there is a limit to how much you can teach someone over the course of three months, compromises have to be made. Things like refactoring, testing and debugging don’t get the same attention.&lt;/p&gt;

&lt;p&gt;Because of this, when I started working, I instantly discovered that there is so much I still had to learn; syntax is only a small part of it. I’m sure my experience was not that unique and a lot of bootcamp grads struggle at our first jobs because of it.&lt;/p&gt;

&lt;p&gt;From that revelation the “Bridging the Knowledge Gap” series was born.&lt;/p&gt;

&lt;p&gt;The objective here is to pay it forward. Even as a Beginner, I realize that there’s always someone that’s working hard to get to where I am. I can’t travel back in time and give Past Me the knowledge and skills that I have now, but hopefully I can help others narrow the gap between Bootcamp and the Real World.&lt;/p&gt;

&lt;h2 id=&quot;debugging&quot;&gt;Debugging&lt;/h2&gt;

&lt;p&gt;The first topic I want to cover is debugging. As developers, we spend a lot of our time navigating code that doesn’t work, and when I first started learning to code, I thought errors were telling me that I did something wrong and since we’ve all been conditioned to avoid mistakes, they felt like failures. As an attempt to avoid error messages, I just didn’t run my code as often.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/P0mGT1s.jpg&quot; alt=&quot;you can't get error messages if you don't run the code meme&quot; width=&quot;300px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Since then, I’ve learned that errors are actually my friends and picked up a few tactics for handling bugs. I’ve organized the things I learned about debugging into three main parts, each the focus for a post of their own:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;
    &lt;p&gt;“Look under the hood” - Print &amp;amp; interactive debugging&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;“Tap the phone line” - Network monitoring &amp;amp; server logs&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;
    &lt;p&gt;General tips&lt;/p&gt;
  &lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;These are not meant to be step by step instructions, but rather starting points where debugging can begin. Depending on the issue at hand, we can use one of the three, mix and match them, or go another route altogether.&lt;/p&gt;

&lt;p&gt;This is Part 1: “Look under the hood”, covering print &amp;amp; interactive debugging&lt;/p&gt;

&lt;h3 id=&quot;print-debugging&quot;&gt;Print Debugging&lt;/h3&gt;

&lt;p&gt;In Javascript, print debugging is achieved by using &lt;code class=&quot;highlighter-rouge&quot;&gt;console.log&lt;/code&gt;. In Ruby, we use &lt;code class=&quot;highlighter-rouge&quot;&gt;print&lt;/code&gt;, &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; or &lt;code class=&quot;highlighter-rouge&quot;&gt;p&lt;/code&gt;. Most of the time, we use this strategy to get a look at values of variables at runtime, compare these printouts to expectations to figure out where our code needed changing.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/6ypWDpK.png&quot; alt=&quot;Ruby print methods&quot; width=&quot;350px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;All three of these do similar things: output information from our program into the console.&lt;/p&gt;

&lt;p&gt;But where &lt;code class=&quot;highlighter-rouge&quot;&gt;print&lt;/code&gt; and &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; internally calls &lt;code class=&quot;highlighter-rouge&quot;&gt;to_s&lt;/code&gt; to turn the thing we want to output into a human-readable String, &lt;code class=&quot;highlighter-rouge&quot;&gt;p&lt;/code&gt; calls &lt;code class=&quot;highlighter-rouge&quot;&gt;inspect&lt;/code&gt; internally, giving us more useful information.&lt;/p&gt;

&lt;p&gt;For instance, let’s say we have an ActiveRecord object, a puppy named Dottie.&lt;/p&gt;

&lt;div class=&quot;language-shell highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;irb&lt;span class=&quot;o&quot;&gt;(&lt;/span&gt;main&lt;span class=&quot;o&quot;&gt;)&lt;/span&gt;:001:0&amp;gt; puppy &lt;span class=&quot;o&quot;&gt;=&lt;/span&gt; Puppy.first
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/nhQGFXi.jpg&quot; alt=&quot;puppy in a gift bag&quot; width=&quot;200px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Inside the Rails console here, we can see the difference between using &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; to output our Puppy object (top) and using &lt;code class=&quot;highlighter-rouge&quot;&gt;p&lt;/code&gt; (bottom).&lt;/p&gt;

&lt;div class=&quot;language-bash highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;irb&lt;span class=&quot;o&quot;&gt;(&lt;/span&gt;main&lt;span class=&quot;o&quot;&gt;)&lt;/span&gt;:002:0&amp;gt; puts puppy
&lt;span class=&quot;c&quot;&gt;#&amp;lt;Puppy:0x00007ff2a2449930&amp;gt;&lt;/span&gt;

&lt;span class=&quot;o&quot;&gt;=&amp;gt;&lt;/span&gt; nil
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;div class=&quot;language-bash highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;irb&lt;span class=&quot;o&quot;&gt;(&lt;/span&gt;main&lt;span class=&quot;o&quot;&gt;)&lt;/span&gt;:003:0&amp;gt; p puppy

&lt;span class=&quot;o&quot;&gt;=&amp;gt;&lt;/span&gt; &lt;span class=&quot;c&quot;&gt;#&amp;lt;Puppy &lt;/span&gt;
    &lt;span class=&quot;nb&quot;&gt;id&lt;/span&gt;: 1, 
    name: &lt;span class=&quot;s2&quot;&gt;&quot;Dottie&quot;&lt;/span&gt;, 
    stomach: &lt;span class=&quot;nt&quot;&gt;-19&lt;/span&gt;, 
    bladder: 24, 
    bowel: 24, 
    bored: &lt;span class=&quot;nb&quot;&gt;true&lt;/span&gt;, 
    created_at: &lt;span class=&quot;s2&quot;&gt;&quot;2019-04-21 19:37:34&quot;&lt;/span&gt;, 
    updated_at: &lt;span class=&quot;s2&quot;&gt;&quot;2019-04-28 01:06:28&quot;&lt;/span&gt;, 
    user_id: 1&amp;gt;
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Depending on what problems we are trying to debug at the time, we might choose one over the other.&lt;/p&gt;

&lt;p&gt;Print debugging lets us leave breadcrumbs, in the form of these print statements, around our code and visually track the path of our program and look at actual pieces of data. We can watch and make sure that all the data is as expected and if an output we expected didn’t show up, it’s safe to say that our program never hit that section of code at all.&lt;/p&gt;

&lt;h4 id=&quot;to-summarize&quot;&gt;To summarize:&lt;/h4&gt;
&lt;p&gt;🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; - Outputs a human-readable string of the object, with a new line.&lt;br /&gt;
🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;print&lt;/code&gt; - Outputs a human-readable string of the object, without a new line.&lt;br /&gt;
🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;p&lt;/code&gt; - Outputs information about that specific instance of the object.&lt;/p&gt;

&lt;p&gt;Aaron Patterson is a maintainer of both Ruby and Rails, and a famously self-proclaimed puts debuggerer (&lt;a href=&quot;https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html&quot;&gt;link to his blog post&lt;/a&gt;). In that post, he talks about a lot of very advanced uses for these print methods. Most of the things that he covers in the post feel very much over my head, and honestly, &lt;code class=&quot;highlighter-rouge&quot;&gt;p&lt;/code&gt; and &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; aren’t my favorite tools for digging into the inner-workings of my Rails application. I generally prefer interactive debugging, using a Gem called &lt;a href=&quot;https://github.com/pry/pry&quot;&gt;Pry&lt;/a&gt;.&lt;/p&gt;

&lt;h3 id=&quot;interactive-debugging&quot;&gt;Interactive Debugging&lt;/h3&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/Eid2Ij2.png&quot; alt=&quot;Pry logo&quot; width=&quot;200px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Pry allows us to open up a console session at any given point of our program, just by dropping the line &lt;code class=&quot;highlighter-rouge&quot;&gt;binding.pry&lt;/code&gt; into the parts of the code we want a closer look at. Now when we run the program again, it would pause there and give us an interactive console in the terminal. It serves largely the same purpose as using the print methods, but Pry, gives us more freedom.&lt;/p&gt;

&lt;p&gt;Here is an app I built years ago to teach myself Rails, called &lt;a href=&quot;https://github.com/minaslater/Puppygotchi&quot;&gt;Puppygotchi&lt;/a&gt;. The puppies get hungry or bored over time so Users can log in to feed or play with them.&lt;/p&gt;

&lt;p&gt;I have put a couple of breakpoints in the service object that ages the puppies and reset their hunger and boredom level. We also have a few private methods that are folded at the bottom.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/Vh1T9gK.png&quot; alt=&quot;code snippet with binding.pry&quot; width=&quot;200px&quot; /&gt;&lt;/p&gt;

&lt;p&gt;If we run the program by reloading the page in the browser, the load would catch and appear to be unresponsive. But, over in our server, we can see the request from the reload hit the server and stop at our first &lt;code class=&quot;highlighter-rouge&quot;&gt;binding.pry&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/1VWVCsF.png&quot; alt=&quot;pry session at breakpoint&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Most things we can do in the Rails console are available in a Pry session, such as &lt;code class=&quot;highlighter-rouge&quot;&gt;ls&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Using &lt;code class=&quot;highlighter-rouge&quot;&gt;ls&lt;/code&gt;, we can get an overview of everything that is available to us within the current context, &lt;code class=&quot;highlighter-rouge&quot;&gt;PuppyAgingService&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/VWrMVsG.png&quot; alt=&quot;pry context output for puppy aging service object&quot; /&gt;&lt;/p&gt;

&lt;p&gt;We can see from the output of our this command that the PuppyAgingService has a public instance method, &lt;code class=&quot;highlighter-rouge&quot;&gt;process&lt;/code&gt;, but it doesn’t show me the private methods, because I don’t have access to them from within Pry.&lt;/p&gt;

&lt;p&gt;My projects generally couple a gem called &lt;a href=&quot;https://github.com/deivid-rodriguez/pry-byebug&quot;&gt;pry-byebug&lt;/a&gt; with Pry, which gives us commands to navigate through the codebase. The ones I most commonly use are &lt;code class=&quot;highlighter-rouge&quot;&gt;next&lt;/code&gt;, &lt;code class=&quot;highlighter-rouge&quot;&gt;step&lt;/code&gt; and &lt;code class=&quot;highlighter-rouge&quot;&gt;continue&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;So, we’re still pry’d into the &lt;code class=&quot;highlighter-rouge&quot;&gt;initialize&lt;/code&gt; method in PuppyAgingService here. We are stopped on line 4, and we can tell because of the arrow on the left of the line number. That line of code is telling our &lt;code class=&quot;highlighter-rouge&quot;&gt;@puppy&lt;/code&gt; instance variable to point to the puppy object we passed in when initializing the PuppyAgingService and right now, it  hasn’t been executed yet. If we look at our instance variable &lt;code class=&quot;highlighter-rouge&quot;&gt;puppy&lt;/code&gt;, it has no value right now; it’s &lt;code class=&quot;highlighter-rouge&quot;&gt;nil&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/VOHsvtB.png&quot; alt=&quot;@puppy with nil output&quot; /&gt;&lt;/p&gt;

&lt;p&gt;But if we use the &lt;code class=&quot;highlighter-rouge&quot;&gt;next&lt;/code&gt; command, the program will run the next line, assign the value of &lt;code class=&quot;highlighter-rouge&quot;&gt;@puppy&lt;/code&gt; variable and stop at line 5.&lt;/p&gt;

&lt;p&gt;We can then see &lt;code class=&quot;highlighter-rouge&quot;&gt;@puppy&lt;/code&gt; has a value now.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/nKCvdHj.png&quot; alt=&quot;output of next command in console&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Then, let’s say we want to know how the method &lt;code class=&quot;highlighter-rouge&quot;&gt;change_time&lt;/code&gt; works, we can use the &lt;code class=&quot;highlighter-rouge&quot;&gt;step&lt;/code&gt; command to step into this next method call. This will land us inside the declaration of a private method defined on the PuppyAgingService class.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/5ZakyKF.png&quot; alt=&quot;step command steps into next method call, change_time&quot; /&gt;&lt;/p&gt;

&lt;p&gt;The last navigation command I want to demonstrate is &lt;code class=&quot;highlighter-rouge&quot;&gt;continue&lt;/code&gt;, which will tell Pry to continue running the program until it hits the next breakpoint, which remember we have in the instance method, &lt;code class=&quot;highlighter-rouge&quot;&gt;process&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/ZnQG1E8.png&quot; alt=&quot;continue command gets to next breakpointinto private method&quot; /&gt;&lt;/p&gt;

&lt;p&gt;And when we’re done with the session and want our program to carry out the rest of the actions, we can use &lt;code class=&quot;highlighter-rouge&quot;&gt;exit&lt;/code&gt; to get out of the Pry session.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://i.imgur.com/sF8fWzL.png&quot; alt=&quot;exit command exits pry session&quot; /&gt;&lt;/p&gt;

&lt;h4 id=&quot;to-summarize-1&quot;&gt;To summarize:&lt;/h4&gt;
&lt;p&gt;🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;next&lt;/code&gt; - runs the next line in the program.&lt;br /&gt;
🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;step&lt;/code&gt; - steps into the declaration of the next method called.&lt;br /&gt;
🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;continue&lt;/code&gt; - runs the program until the next breakpoint.&lt;br /&gt;
🚨 &lt;code class=&quot;highlighter-rouge&quot;&gt;exit&lt;/code&gt; - gets out of the Pry session.&lt;br /&gt;
🎁 Bonus! 🚨 !BONUS!&lt;code class=&quot;highlighter-rouge&quot;&gt;whereami&lt;/code&gt; - tells us where the Pry session is currently.&lt;/p&gt;

&lt;h3 id=&quot;use-case&quot;&gt;Use Case&lt;/h3&gt;

&lt;p&gt;If you’ve ever built a Rails project, you’ve seen this error before:&lt;/p&gt;

&lt;div class=&quot;language-ruby highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;&lt;span class=&quot;n&quot;&gt;undefined&lt;/span&gt; &lt;span class=&quot;nb&quot;&gt;method&lt;/span&gt; &lt;span class=&quot;s1&quot;&gt;'select'&lt;/span&gt; &lt;span class=&quot;k&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;kp&quot;&gt;nil&lt;/span&gt;&lt;span class=&quot;ss&quot;&gt;:NilClass&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This message is telling us that the code wants to invoke a method, &lt;code class=&quot;highlighter-rouge&quot;&gt;select&lt;/code&gt;, on something whose value is &lt;code class=&quot;highlighter-rouge&quot;&gt;nil&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;In this example, &lt;code class=&quot;highlighter-rouge&quot;&gt;select&lt;/code&gt; is a Ruby built-in method on the Array and Enumerable classes, so if the object it’s being called on is anything but an instance of either class, the method call results in this error. It’s the message we’ll see every time we try to use a method on something has the incorrect data type. Since there are many answers for where, how and why the data is unexpectedly &lt;code class=&quot;highlighter-rouge&quot;&gt;nil&lt;/code&gt;, opening up the program using &lt;code class=&quot;highlighter-rouge&quot;&gt;puts&lt;/code&gt; or Pry is a decent place to start this debugging process. We can use these tools to identify the problem spots and follow the clues from there to the solution.&lt;/p&gt;

&lt;p&gt;Being able to peek under the hood of my program was a game-changer! For me, the hardest part of learning to code was overcoming the disconnect between the text in the files and what shows up in the browser. It’s especially hard to conceptualize when working with a dynamically typed language like Ruby, where we can assign data of any type to the same variable without any warning about potential problems.&lt;/p&gt;

&lt;h3 id=&quot;resources&quot;&gt;Resources&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html&quot;&gt;I am a puts debuggerer&lt;/a&gt; by Tenderlove&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/deivid-rodriguez/pry-byebug&quot;&gt;pry-byebug docs&lt;/a&gt;&lt;/p&gt;
</description>
        <pubDate>Sun, 24 Nov 2019 00:00:00 -0600</pubDate>
        <link>https://minaslater.blog/2019/11/24/debugging-part-one/</link>
        <guid isPermaLink="true">https://minaslater.blog/2019/11/24/debugging-part-one/</guid>
        
        <category>CodeNewbie</category>
        
        <category>Debugging</category>
        
        <category>Ruby On Rails</category>
        
        <category>Rails Basics</category>
        
        
      </item>
    
      <item>
        <title>Imposter Syndrome - Feels Not Reals</title>
        <description>&lt;p&gt;Originally published on the &lt;a href=&quot;https://www.devmynd.com/blog/imposter-syndrome-feels-not-reals/&quot;&gt;DevMynd Software Blog&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://minaslater.blog/images/post-3/doctor-pointing-at-computer.jpeg&quot; alt=&quot;Doctor pointing at
computer&quot; /&gt;
Image source: &lt;a href=&quot;https://www.pexels.com&quot;&gt;pexels.com&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Imposter Syndrome (also known as Doubtia Debilitus) is a wide-spread neurological disorder caused by the disconnect between perception and reality of one’s abilities. It commonly affects newborn Software Developers from a non-traditional background, but has been observed amongst individuals of all dev-ages and backgrounds. It is generally triggered by comparing oneself to a false ideal, and conditions can worsen if symptoms are left untreated.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;symptoms&quot;&gt;Symptoms&lt;/h2&gt;
&lt;p&gt;Some common symptoms include, but are not limited to:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Tunnel Vision&lt;/strong&gt; – Usually imperceptible at an early stage, you might find yourself hyper-focused on minuscule areas of imperfection in largely successful endeavors. Despite overwhelming evidence to the contrary, you see the venture as a failure as a result.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Paranoid Delusions&lt;/strong&gt; – The intense focus on small mistakes/areas for improvement can increase in severity and cause you to create inaccurate analysis of your self-worth. The perceived “failure” becomes the defining characteristic of yourself and you become convinced that this unknowledgeable true-self will one day be exposed.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Paralysis&lt;/strong&gt; – The virus attacks the brain and body with such severity that it can sometimes cause productivity to come to a halt. This is a response to your extremely high perceived rate of failure, and they have concluded that “if I don’t start, I can’t fail.”&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;treatments&quot;&gt;Treatments&lt;/h2&gt;
&lt;p&gt;Doctors recommend the following techniques to treat Imposter Syndrome. These are found to be the most effective treatments by the Researcher; your mileage may vary.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Change it up&lt;/strong&gt; – Identify and remove yourself from environmental triggers, if only briefly, that could exacerbate symptoms. For instance, if you have consistently been working closely with someone much more experienced, it is suggested that you seek out opportunities to work alone or with someone who is more comparable in experience. While pairing with a senior developer is an excellent learning opportunity, it could sometimes lead to unrealistic expectations and self-assessment of yourself. This could occur no matter how supportive from the team. It is important to remember that though it may feel like you don’t know as much, even experienced developers sometimes Google simple things and you still have skills that are valuable and can contribute to the project.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Celebrate wins&lt;/strong&gt; – The virus takes hold in your brain by exponentially multiplying negative thoughts. Fight it by celebrating any and all achievements, no matter how minuscule they might seem: “I took on a feature independently.”, “I demonstrated something for the Client.”, or “I gave my first lightning talk in front of a group.” Acknowledge these wins without qualifying it, then find a friend to give you a high-five or, if alone, give yourself a mental one. Consistency with treatment is a challenge, especially as the virus fights back. Keep at it. Maybe once or twice a day to start, and work up the frequency. Pretty soon, it will become second nature.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;External affirmation&lt;/strong&gt; – Taking the previous treatment a step further: when you are given a compliment, be sure to allow yourself to accept it. Strike words like “just”, “only”, “well…”, and “lucky” from your vocabulary. No more responding to compliments with: “It was just lightning talk.”, “Well… So-and-so had done it better.” or “I was lucky I got that job offer.”; a simple “Thank you” will do. Take pride in that someone else have noticed your achievement. Downplaying the significance of what you have done will only create fuel for the virus and feed into the negativity that it craves.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;long-termeffects&quot;&gt;Long Term Effects&lt;/h2&gt;
&lt;p&gt;Whatever methods of treatment work for you, embrace it. But remember: we are all human. When you lapse and the virus is filling you with negative thoughts, don’t fret. Acknowledge what is happening and remember the achievements that got you to where you are. We are all learning to live with various degrees of imposter syndrome, and clinical trials conducted have uncovered that while the condition is serious, it is not chronic or terminal.&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;&lt;em&gt;The research cited was from personal experience, no official clinical trials were conducted. No medical personnel were involved in the writing of this article.&lt;/em&gt;&lt;/p&gt;
</description>
        <pubDate>Thu, 13 Sep 2018 00:00:00 -0500</pubDate>
        <link>https://minaslater.blog/2018/09/13/imposter-syndrome/</link>
        <guid isPermaLink="true">https://minaslater.blog/2018/09/13/imposter-syndrome/</guid>
        
        <category>soft skills</category>
        
        <category>imposter syndrome</category>
        
        <category>CodeNewbie</category>
        
        
      </item>
    
      <item>
        <title>What is ReST - An Interview Survival Guide</title>
        <description>&lt;p&gt;I was recently caught off-guard at a job interview by this question: &lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;What is ReST?&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;While my bootcamp instructors drilled us with algorithmic problems as found on Codewars, we did not allocate as much attention to the talk-about-coding type interview questions. Thinking back, it was negligent of me to assume that just because I understand something enough to use it, I could talk about it eloquently too.&lt;/p&gt;

&lt;p&gt;WRONG!&lt;/p&gt;

&lt;p&gt;I think I mumbled something about using HTTP verbs and URLs. I don’t really remember; I may have blacked out.&lt;/p&gt;

&lt;p&gt;The paragraphs and images that follow barely skim the surface of understanding ReST, but should be sufficient knowledge to get you through your interview. &lt;/p&gt;

&lt;p&gt;This is also what I wish I had given as my answer.&lt;/p&gt;

&lt;h3 id=&quot;rest-stands-for-representational-statetransfer&quot;&gt;ReST stands for Representational State Transfer&lt;/h3&gt;

&lt;p&gt;So, now that that’s out of the way, we can get down to what it actually means.&lt;/p&gt;

&lt;p&gt;Assuming that you, the Reader, are familiar with the Client-Server-Database structure of most web applications, the short answer is that ReST is a set of guidelines that describes how your client communicates with your server.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;https://minaslater.blog/images/post-2/rest_cartoon.jpg&quot; alt=&quot;ReSTful cartoon&quot; /&gt;
Image by: &lt;a href=&quot;http://http://doodlingdev.com/&quot;&gt;DoodlingDev&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;A “ReSTful” design is complex; way more complex than an Interviewer is looking for in a short interview answer. Here, we will cover the following:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Endpoints named after resources&lt;/li&gt;
  &lt;li&gt;Actions performed on those endpoints&lt;/li&gt;
  &lt;li&gt;Stateless communications&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;SIDEBAR: If you are interested in diving into the nitty-gritty of ReSt, here is Chapter 5 of Roy Fielding’s dissertation.&lt;/p&gt;

&lt;h2 id=&quot;hockey&quot;&gt;HOCKEY!&lt;/h2&gt;

&lt;p&gt;Let’s say I have a very simple CRUD web application for a hockey league, where I keep track of all the teams in the league. Upon surveying the Users, I have condensed the user stories down to the following:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;As a User, I want to be able to create a team, so that I can add a new team when they join the league.&lt;/li&gt;
  &lt;li&gt;As a User, I want to see (read) all the teams, so that I can get an overview of the league.&lt;/li&gt;
  &lt;li&gt;As a User, I want to be able to update a team’s information, so that I can track wins and losses.&lt;/li&gt;
  &lt;li&gt;As a User, I want to be able to delete a team, so that I can remove a team when they leave the league.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Knowing that a route consists of two parts: the path / URL and an HTTP action verb, let’s get started.&lt;/p&gt;

&lt;h3 id=&quot;resources-as-endpoints&quot;&gt;Resources as Endpoints&lt;/h3&gt;

&lt;p&gt;In a ReSTful architecture, the path is  a noun describing a resource that is being accessed. It is generally named after database models (tables). These paths are the endpoints our client requests will hit.&lt;/p&gt;

&lt;p&gt;In the hockey app above, our requests should all hit the path representing the Team resource. So let’s start the routes there:&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;1. /team
2. /teams
3. /team
4. /team
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;h3 id=&quot;actions-on-endpoints&quot;&gt;Actions on Endpoints&lt;/h3&gt;

&lt;blockquote&gt;
  &lt;p&gt;If all these User Stories hit the same endpoint, how does the server know which of the actions to perform?&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;In order to differentiate  between each of the CRUD activities, our request from the client will also send an HTTP action verb to the server, along with the path of the endpoint the app wants to hit. &lt;/p&gt;

&lt;p&gt;Let’s update our routes for the hockey app:&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;1. POST /team
2. GET /teams
3. PUT or PATCH /team
4. DELETE /team
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;h3 id=&quot;stateless-communication&quot;&gt;Stateless Communication&lt;/h3&gt;

&lt;p&gt;Another big part of ReSTful design is that the “communications must be stateless in nature” (Roy Fielding). That simply boils down to the fact that all the information needed to understand each request is sent along as part of the request itself.&lt;/p&gt;

&lt;p&gt;For our hockey app, we will need to add something to the PUT/PATCH and DELETE routes so that our server knows which team we want to apply the action to.&lt;/p&gt;

&lt;p&gt;Like so, where 1 will be the id of a specific team:&lt;/p&gt;

&lt;div class=&quot;highlighter-rouge&quot;&gt;&lt;div class=&quot;highlight&quot;&gt;&lt;pre class=&quot;highlight&quot;&gt;&lt;code&gt;1. POST /team
2. GET /teams
3. PUT or PATCH /team/1
4. DELETE /team/1
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;

&lt;h2 id=&quot;tldr&quot;&gt;TL;DR&lt;/h2&gt;

&lt;p&gt;To sum up the above points into a concise answer to the question, “What is ReST?”:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;ReST is a structure for the communication between client and server, where each path is a noun, named after the resource being accessed. The requests contain an HTTP verb to define the action to be performed on the endpoint, as well as everything necessary to understand the request.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;There you have it. It is two weeks late for that interview, but here is my answer.&lt;/p&gt;
</description>
        <pubDate>Sat, 28 Apr 2018 00:00:00 -0500</pubDate>
        <link>https://minaslater.blog/2018/04/28/what-is-rest/</link>
        <guid isPermaLink="true">https://minaslater.blog/2018/04/28/what-is-rest/</guid>
        
        <category>interview</category>
        
        <category>api</category>
        
        <category>CodeNewbie</category>
        
        
      </item>
    
      <item>
        <title>Why I Started Coding</title>
        <description>&lt;p&gt;Have you ever gone to a magic show or seen a magic trick and immediately feel the need to know every little secret about how it was performed?&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;That is me.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I discovered this about myself early on, as a small child watching David Copperfield move a helicopter through the Great Wall on television and as a teenager hanging on to every secret the Masked Magician gave away. Later, as my entertainment career took me down the path toward variety and circus, I watched closely as magicians I worked with prepared for their shows. I wanted to know where every rabbit and chick came from, when that red ball went from the cup on the left to the cup on the right, and how on EARTH he knew the word in her head was “mug”.&lt;/p&gt;

&lt;p&gt;Maybe unsurprisingly then, I married a variety performer. I. HIT. THE. JACKPOT. I bombarded him with questions after every magic show we saw and asked him to teach me card trick maneuvers that my hands were too small to perform.&lt;/p&gt;

&lt;p&gt;It was with this level of curiosity and drive for information I first approached web development. My clown-husband had already veered left on his own career path, went to a coding bootcamp and started working as a web developer. All I knew about it at the start was that he would sit at a computer screen (with a dark background, WEIRD) for hours, typing out these colorful texts and VOILA! websites happen!&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;Just like a magic trick.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;After watching this digital wizardry happen under my roof for about a year, I finally asked him to show me what he was doing and how these text files turn into websites and applications. This is where my programming journey began.&lt;/p&gt;

&lt;p&gt;I learned the basics of the command line, went through a short tutorial about HTML/CSS, and he introduced me to Ruby. It felt very powerful, the way that I made things happen by doing something seemingly unrelated. I was the magician and my hands were not too small for these tricks.&lt;/p&gt;

&lt;p&gt;…and now, for my first trick!
&lt;img src=&quot;/images/post-1/first-program.png&quot; alt=&quot;my first program!&quot; /&gt;&lt;/p&gt;

&lt;p&gt;I also always had an aptitude for thinking outside of the box, and was rarely stumped by a riddle or logic puzzle. In school, I was great at math (I essentially taught myself trigonometry), but hated the rigid repetition of math classes. Writing code gave me the creative outlet I craved, but it was objective. There are countless different ways to solve a problem in coding, but every problem still has a very clear correct answer. I can’t talk my way out of code that doesn’t work and to me, that’s liberating. There is no ifs or buts about it: either code works or it doesn’t. You can make code cleaner, DRYer, and more concise, but it always has to work, otherwise it’s wrong.&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/images/post-1/hipster-ariel.jpg&quot; alt=&quot;hipster Ariel&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Admittedly, the process has been filled with lots of bumps in the road. I struggled to master the Art of Google. When I started to learn Rails, I had the hardest time understanding how the internet works, and couldn’t wrap my brain around HTTP requests/responses.&lt;/p&gt;

&lt;p&gt;Predictably, in hindsight, the biggest pushback I gave was to the concept of “Rails Magic”; I had a really hard time accepting that the Rails source code was just too much for a beginner and that I needed to move on for now, let it help me and get back to uncovering the secrets later. The turning point that saved me from quitting came in the form of a talk at RailsConf 2017. Thanks to Alex Kitchens and his &lt;a href=&quot;https://www.youtube.com/watch?v=Q_MpGRfnY5s&quot;&gt;Perusing the Rails Source Code - A Beginner’s Guide&lt;/a&gt; in which he said that “…there is no magic [in Rails].”&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/images/post-1/mind-blown.png&quot; alt=&quot;mind. blown.&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Learning to code is the most challenging thing I have ever taken on and, from what I hear, the journey never really ends. There are countless magic tricks still for me to discover and pick apart, and I’m excited for the opportunities to discover all the “secrets” the tech world has to offer.&lt;/p&gt;
</description>
        <pubDate>Mon, 09 Oct 2017 00:00:00 -0500</pubDate>
        <link>https://minaslater.blog/2017/10/09/why-i-started-coding/</link>
        <guid isPermaLink="true">https://minaslater.blog/2017/10/09/why-i-started-coding/</guid>
        
        <category>personal</category>
        
        <category>CodeNewbie</category>
        
        
      </item>
    
  </channel>
</rss>