DEV Community: MikeDudolevitch

Recursion Post Recursion Post

MikeDudolevitch — Thu, 27 Jan 2022 15:24:26 +0000

In the time since graduating from Flatiron School's software engineering program, I've been looking for ways to shore up my knowledge and expand on the concepts taught in the course. Free Code Camp's curriculum has been awesome for that- little bite sized mini-Labs that you have to solve before moving onward. In going through those tests as a study review, I did run into a concept in Javascript programming that I wasn't familiar enough with: recursion.

I mostly knew recursion as being a pitfall for beginner developers that forgot to close a loop, or set a condition going the wrong direction so as to continue forever. Ctrl-C was my way to escape her siren clutches before melting my computer's processor from the inside out. But it turns out it can be harnessed to solve Javascript problems with some clean and easily readable code.

const recursiveFunction = (n) => {
    if (n == 0) {
       console.log("This is the base case")
    } else {
       console.log(n)
       recursiveFunction(n - 1)
    }
}

Above is a fairly basic function using recursion to countdown from whatever number is provided as an argument when invoked. Programmatically, it works similarly to a for loop, going through each case, operating on it (in this case console logging the present number) and then decrementing it and doing likewise until the loop is done. But the setup is a little different in recursion: you're gonna start with a 'if' statement, that will represent your base case- ie. the condition that will stop it from calling itself endlessly. In our case that's the passed in number reaching 0, and it console logs and never calls again. Boom, our function did what we wanted it to do, and we don't have so smash Ctrl-C.

The 'else' statement is where we operate, calling the very same function within our defined function, only with the passed in number being decremented by 1 in our case- or otherwise operating on that argument so we call it again and again until we hit that base case.

Free Code Camp has a very in-depth look at the concept in terms of using them in your algorithms- I highly recommend taking a deeper dive than my primer on the subject if you're like me and would like to add this to your problem solving arsenal: https://www.freecodecamp.org/news/understanding-recursion-in-programming/

Big, Long, Sappy Graduation Post

MikeDudolevitch — Mon, 13 Dec 2021 23:41:12 +0000

I wanted to write an extremely non-technical post, processing 2021 as it rolls to a close, and focusing primarily on my recent graduation from Flatiron School's software engineering part-time (and full-time for a bit) bootcamp. There's a TON of gratitude I want to express that I don't think would fit particularly well on a Linked-In post. I also wanted to examine the point in which I bottomed out and let myself get to a pretty dark place, in hopes that it may help someone reading this to relate. And some of it will just be processing a wild year personally- so fair warning, if it seems like a self-indulgent life story, just smash that 'X' button in the top right corner!

I applied for Flatiron School's program late in 2020- a time that obviously affected everyone's life in ways that couldn't have been predicted. For me, as someone who dedicates a lot of energy to music and performing, it was a double-edged sword- I got a break from some of the burnout from playing out/touring a lot, and I got to take a rest and reset I never would've afforded myself on my own. However I naturally felt a bit lost and that I was lacking something critical to my identity. Professionally, I had been working in the same industry (glass tile manufacturing, operations) since I was a teenager, and I felt more and more compelled to escape my comfort zone. I also recently got engaged in October 2020, so suddenly the future didn't seem like such a distant, abstract thing to think about and plan for. I had the tremendous privilege of learning that baby bonds my extended family got me back in the day for birthdays, christenings, etc. had matured, and it would be just enough to live off of while I went back to school- so that was it: I would invest in myself and put the wheels in motion to make a career change into a field that I already had a growing interest. I can't thank the friends of mine that work in software engineering enough for encouraging me and telling me I was capable, that boost made an enormous difference to this (at the time) total beginner.

I had this great, neat, tidy plan for how I would succeed in the Flatiron course- it was January '21, it was the freezing cold months of the year here in NY, and so much was still closed with no clear end in sight. It made for an ideal situation to bury myself in the material for a relatively short amount of time, and be graduated and certified by early Summer. Even after the prep work, once the course started going I found it extremely fast paced and I wasn't looking like I was going to make the First Mile deadlines to continue in the class. I hadn't quite come out of my shell to ask for help and collaborate until it was too late- I had this self-damaging feeling of not belonging, and the idea that everyone knew all the answers while I was grasping at straws. But I felt motivated to succeed in a new cohort with the experience I gained in that short time. Once I started with my new classmates I had a much better handle on how to get through the course work, and was part of an unbelievable community. My cohort leads Laura Berge and Eri Guzman were amazing teachers that effortlessly curated a positive learning experience, and I gained fantastic friendships from many of the talented students going through the course with me.

During the week of my first module final project, my fiancee Kassidy and I got some unfortunate news that would punch a hole in my simple plan to hunker down during the full-time course. The brownstone we were renting an apartment in had been sold, and the new owners were going to renovate. That meant entering the sane, logical world of New York City real estate (<- pure, refined sarcasm). Not ideal, but I had classmates in the same boat. The challenges crept up from keeping up with the course (Sinatra at the time) and keeping up on listings, keeping appointments with real estate agents, and having to weigh pros and cons of prospective apartments at lightning speed so as to not miss out (we missed out on a few places by a matter of minutes). Well we found a nice place it seemed, and it offered us even more amenities- why not upgrade if we gotta go through the hassle? So then it was juggling lessons and lectures with packing up our things and coordinating the move, which I would do myself with the help of our respective families (lockdown had them a little stir crazy and they insisted). It was exhausting as hell, but we started settling in. There was a week delay for setting up our new internet, so I would commute every day then to our gutted old apartment to have wifi to work with. It did not make for a great environment to concentrate and my work suffered, but I grinded through the best I could.

At the same time, the world was starting to open up from lockdown. My musical obligations weren't the slow build I had in mind, but more like a dam bursting. The band I had played in since high school, toured extensively in, and poured myself into, had finished a record over the pandemic and now had no choice but to play shows to push it, before we decided to call it quits. I had started my own project to stay productive in quarantine, and that was starting to become active. Plus, a more established band had been trying to acquire my abilities for a little while prior, and had doubled down- pay guarantees, international touring, dates as tour support for Joan Jett...aka the type of thing that you work towards as a musician. They were recording a full-length at Little Steven's (Springsteen, the Sopranos, Underground Garage, etc) and requested that I be the featured guitarist. So these 3 music projects were competing for my nights and weekends, and the move had already knocked me back a little bit in my studies. I had picked up some work because expenses were piling up and I was getting concerned about my modest nest-egg getting me through. And in settling in to our new home, we had the unfortunate realization that the place was a mistake- an awful, hateful building management company that reneged on parts of their agreement, plus insufferable neighbors to have to share our (poorly insulated) building with.

At this point, I was eating poorly, sleeping terribly from stress, falling behind in the daily assignment pace, and struggling to balance my music workload, while knowing that just giving them up was not an option without major repercussions. That scrappy mentality to work through coding problems and frustrations I'd had early on had started eroding. I struggled all through the Rails module, had not yet passed a review for my project, and the following course unit was already well in progress. I was exhausted from our 2-front war against a negligent building management and entitled, inconsiderate neighbors. That sick, self-destructive voice inside me had become louder and louder, telling myself how inevitable it was that I'd crash and burn. Something absolutely had to give.

I had an intense meeting with my cohort lead, Laura, and she once again proved to be an excellent educator with my best interests in mind- she recommended initiating a move to the part-time program. It was like both a kick in the teeth and a weight lifting off of me at once. I still had to prove my abilities in a Rails review, but I felt energized. I would have more time to internalize the information, and could pick up some more work concurrently- my original idea of a nice, convenient bubble to study in turned out to be an absurd pipedream, so I may as well adapt. I passed my Rails review and was subsequently placed in my part-time cohort, where I reunited with some friends I had made from the school making the same switch. Still, it felt disappointing to be so close to the finish line and get the clock turned back so significantly.

Kassidy and I decided to be proactive, since our living situation had turned out to be a bust. Our environment was terrible, it was a laughable mockery of a 'home', and it was negatively affecting both of us. We asked out of the lease. The landlord miraculously agreed (he could rent it at a higher rate with less pandemic nervousness than earlier, likely the only driving force behind their agreeing). It was a risk, because we had to go BACK into the rental market, just a few short months later and with sharply rising costs. We'd passed the point of no return and needed a new place ASAP- we aggressively pursued a listing and got the place- this time we emptied the piggybank for movers to do it for us and let us keep a little shred of sanity. I was re-settling into a new place for the 2nd time in a few months while getting through the final module, and thankfully the (slightly) more forgiving pace of the course in part-time let me keep up and nail the final project.

Barely a week after passing my final review, I'd be on a plane to Sweden. The band I was hired to play in had a run of dates from Malmo to Stockholm, with some recording dates in Stockholm's Old Town district. There I met friends for life and made incredible memories doing what I love. It was a whirlwind and felt life-affirming after overcoming the challenges of the Flatiron course.

Now I'm entering a new job market into the new year, and I feel armed with confidence from overcoming a challenging bootcamp- so much code that I've written would have made my earlier self cross-eyed and I overcame problems I previously wouldn't have known where to even begin. My biggest takeaway isn't that now I magically know everything, but that I have the ability to absorb the information and continue learning in a vast field. And I'm armed with an amazing network of people that each did their part and helped steer this rickety, metaphorical vessel along to its destination.

Next blog post will be 100% technical, but until then I'd like to thank the talented, awesome people that helped me by name.

My dev friends outside of school who each took a look at my code and each helped me along tremendously: Conor Leeds, Rob Notwicz, Maggie Curtis, Joe Giralt, Justin Michaliga

My teachers and support staff at Flatiron, y'all made an amazing learning environment for someone who hadn't been in a formal class setting in a decade and a half: Laura Berge, Eri Guzman, DJ Ritchey, Gretchen Stamp, and Mark Strozik

And my classmates- I cannot stress enough how valuable great classmates were for me: Jazo, Lupita, Elias, Jill, Zack, Connor, Zoe, Anthony, Edward, Nicoll, Kyle, Lydia, Maxine, Sav, Luis, Richard, Erick (probably more that I'm rudely forgetting)- thanks for an awesome experience. It was a blast becoming friends with all of you and I look forward to all our your inevitable success stories in coding!

New To Hooks

MikeDudolevitch — Wed, 03 Nov 2021 23:21:21 +0000

In this post will explore hooks from the perspective of somebody new to implementing them in my React.js code. So what exactly are hooks? From my music background, I associate them with that part of a song that compels you to listen again, and might get stuck in your head, or you wake up humming without noticing, 'til your partner asks you to "please shut up"- chorus of "Don't Stop 'til You Get Enough", bass line to "Under Pressure" by Queen/Bowie, etc. In React it's not writing a bit of flashy code, but the parallel concept exists that the code you write can be a bit more reusable and concise (ie a catchy repeating chorus).

The issue that exists, and hence why the folks at the React library developed a new structure for components, is that in the standard object-oriented class components, passing its state around an app can get cumbersome. Though in my own application, the Longwinded-Chef, my file structure was simple compared to an average web application, I saw firsthand how counter-intuitive it can be to store a component's state- it involved setting up a high level store at the top level of the app, connecting each component to that store, mapping the props that were inherited by parent elements or any conditional user-input related change to state, and sending that updated state to the store to be used and referenced throughout the app. I can only infer how that might get tangled quickly in a more complicated, real-world site.

Those same class components can just be rewritten as a functional component. Make sure to pass down the props as an argument to the function. Instead of writing:

state = {
attribute: initialValue
}

we set state as a const variable, and pass ONLY the initial value in as an argument to the setState hook:

const [anInitialState, aFunctionThatUpdatesThisState] = useState(passInAnInitialStateHere)

Here's a way to pass in a local state in a functional component to preserve it for future use, and a callback function that we will take that initial state and update it as we want (ie in onClick or onSubmit).

I am getting ahead of myself (as sometimes happens when I code)- these hooks we are using are inherited from 'react', so make sure to import it to avoid errors of course!!

import { useState } from 'react'

Also, make sure all of your references to 'this' are taken away, as they won't work in functional components- that gets left in class/object oriented world.

So now that you have a useState hook- a function inside your component can grab that state you've set and use that callback function to update it:

<button onChange={() => aFunctionThatUpdatesThisState(anInitialState * whatever)}>

That's the basic rundown on how hooks work: they are functions from React that let a functional component "hook" into state features- set values locally, set ways to update that state, all convenient within the component and without having to awkwardly store elsewhere to reference later- they are an intuitive way to manage components, and though I am new to them, and that there is way more to it than this basic layman's overview, they are the present and future convention on writing React code!

Don't Fear the Redux

MikeDudolevitch — Sun, 10 Oct 2021 23:44:08 +0000

I am thrilled to say I am at the end of the Flatiron School's Software Development Bootcamp, and just completed the Phase 5 project which required a web app made with React.js and Redux. In this blog post I will walk through some of my challenges, and how I was able to reach the solutions to get my application working, complete with some code snippet examples.

I've mined my passions for music/guitars, reading, and hockey (both professional and amateur) as the subjects of my previous project assignments. I also love to cook so making a recipe site seemed like a natural next step. Once again it started with making a Rails API for my backend, at this point as comfortable as a warm blanket. The :recipe is the model to which :ingredients and :comments belong, and it has native attributes like name, blog post, and instructions (the latter two being text areas- this site is going to spoof cooking websites with obnoxiously long anecdotes by the author so I need some running room to write long blogs for each recipe.)

My next step was to create a new project repository and start my frontend with 'npx create-react-app' which auto-populates the directories for a React project. App.js is my highest level, so that seemed like a fine starting place. 'react-router-dom' has the built in components , , and , to let the client-side web app have the same routing capabilities that we've gotten used to in backend development. encompasses any of the routes that are user chosen; that being the case my NavBar (copied and pasted from 'react-bootstrap' and then customized to my specifics) would sit outside the switch and render to the screen to the user at all times. The specific inside of the switch accept a path/exact path="/to correspond to a url" and a component={to correspond to which component this url path with take a user to}.

Time to make up some components! They really are the basic lego building block of a React web app. There's an extension for VS Code called 'ES7 React/Redux/GraphQL/React-Native snippets' that is fantastic, and I can't recommend enough (it may be available in other text editors as well but I can't speak to that). Using this extension, to create a new class component, I just 1) create a new file in a '/components' folder, 'Recipe.js' say 2) type in rce, hit enter, and 3) watch the component magically appear- importing {Component} from react, creating a new class with the same name as the file, exporting default of the class name, putting in your render() function which returns an empty div- all stuff that at this point we had gotten used to hard coding ourselves but is unnecessarily repetitive to do for every component- hooray for software engineering laziness!

rce [ENTER]:

import React, { Component } from 'react'

export class Test extends Component {
    render() {
        return (
            <div>

            </div>
        )
    }
}

export default Test

This took me to the stage where I could start bringing some backend data in and showing it through my frontend. This meant fetching the recipes I seeded in Rails- and this is where Redux came in to figure into my app- I set up a store at the top level, App.js, and used the inherited from 'react-redux'- I created a store and passed it into the Provider as a prop, which allows me to store a shared global state of my components, and configured that store with the 'thunk' middleware, which gives me the dispatch() functionality, and the ability to pass the dispatch function other functions that I write as parameters. To set up the store, I pass in a reducer as a parameter to createStore- this serves as a central location to update state based on the action that occurs- in the case of my fetch request for recipes, I supplied that with a type of "GET_RECIPES"- just some descriptive string that I can match in my reducer, so when an action with a type of "GET_RECIPES" gets sent, it will update state accordingly (ie storing a bunch of recipe objects as state, that I can use throughout my app!). I call that fetch action on componentDidMount() in my App.js, so as soon as someone opens up my web application, boom, it populates with the relevant data.

My recipes get fetched on a componentDidMount() call when my app gets opened, and then I mapStateToProps() to connect that state change in my store. I wanted the recipes themselves to show up on a Home page, and link to an individual 'show' page of each recipe. This was a matter of iterating over my whole list of recipes and passing each one to a component as props, like so:

const recipesOnDom = this.props.recipe.map(r => <Recipe
recipe={r} key={r.id} />)
        return (
            <div className="content-div">
                <ul id="recipe-list">
                    {recipesOnDom}
                </ul>
            </div>
    )

Each recipe would render a link to that associated show page, by interpolating its ID in the url route:

const { name, id } = this.props.recipe
        return(
            <li key={id} id="recipe">
                <Link to={`/recipes/${id}`}>
                    {name}
                </Link>
            </li>

My show page would be my recipes, the payoff, where a user can, ya know, read a bunch of vaguely associated blather, fight through ads, and then after X-ing out a bunch of spammy offers to subscribe to something, read instructions on how to cook something! Some of that anyway. Here it was just a matter of showing, in JSX elements, the name, ingredients (a nested resource of Recipe in my backend), instructions, and blog post, and style it up on the page. One minor issue I came across: each recipe had a random amount of instruction information. When it rendered to the page, it was ugly, and just a paragraph with step 1) and step 2) etc. all in the same blog text field. It took a minor bit of creativity to format that correctly:

const instArray = recipeObj.instructions && recipeObj.instructions.split("|")

I split it be the seldom used '|' character, popped one of those between each instruction that I seeded, and put all of the split up instructions in a list. The && operator was a bit of error handling, in case no instructions were available upon loa

And now we're on to comments. A user ought to be able to post a comment on the specific recipe, so I styled up a couple of input fields. The onChange= in each element updates the state with the user's input, and then hitting the 'Post Comment' button triggers a handleSubmit() function that I wrote:

 handleSubmit = (e) => {
        console.log("in HS", this.state)
        e.preventDefault()
        this.props.addComment(this.state)
        this.setState({
            name: "",
            content: "",
            recipe_id: `${this.props.recipeObj.id}`
        }) 
    }

It updates the state, and we mapDispatchToProps() and connect to our store to fire it off to my Redux action- ie "POST_COMMENT" to make a fetch request as a "POST" action. The action sends it to the reducer, that sees the "POST_COMMENT" and updates state accordingly- taking the new comment a user posted, and popping it into the array of comments for that recipe. Great. These comments persisted in my backend, were set in the Redux store, and now should show up on the DOM immediately. There weren't showing up in the DOM (well, they only did when they didn't persist to my store and backend) Above, when I call this.props.addComment with the updated state as a parameter, it was with the intention of using the addComment function inherited from my recipe 'show' page, and plunking that user updated state right there on the page! But it wasn't showing on the page!

It turns out I was so focused on getting comments to render correctly on my backend that neglected a logical fix on my front end- just fetch the data all over again! On my recipe's show page, I mapStateToProps()- so anytime state gets an update it connects and communicates with my store- and then I just call another fetch of the now updated data (passing that fetch function in as a connect parameter), and presto- all new data is rendered to a user, including their comment that just got posted!

The Free Jazz of Computer Languages

MikeDudolevitch — Thu, 05 Aug 2021 16:53:03 +0000

For Flatiron School's Phase 4 Final Project, we created a project using Javascript to handle the views to a client, without ever refreshing a page. I'll use this blog post to detail some of the challenges I encountered and how I overcame them, in case it resonates with someone else who is learning frontend development.
I'll make the music analogy, especially in contrast to making a full-stack site entirely on Rails: Javascript is really the free jazz of coding, whereas Ruby on Rails is the hardcore punk. Rails is rigid and has a pretty strict set of conventions that it makes you follow, and if you deviate, you've got to explicitly hard code it to do so- ie in punk, it's a rigid set of rules: predominantly power chords on guitar, root notes on the bass, fast 4/4 time on the drums. If you buck that convention too much in another direction, well, it no longer sounds like punk rock (the Clash notwithstanding- they are often labeled punk but covered so much sonic ground. Anyway...). Not to mention your aggro lead "singer" will start getting annoyed, ie Rails throwing you an error anytime your code falls out of line. In Javascript, there are very few guidelines! Declare your global variables and functions wherever! Invoking a function with an argument, when you didn't declare any parameters? Great! JS will try to run it. Declare a function to a variable name to pass it into another function as a callback to handle the data? Yeah! Anything goes! It's like improvisational jazz- it can be easy for a novice to get lost in the lack of form and inherent organization. What chord was I supposed to improvise over? A Cadd7dim9? So I can use the flatted 5th of the root note is "in scope"? (as a musician I'm not even entirely sure that's a real chord- power chords and root notes for me!).
Well this project was a fusion of both styles- with a Rails API handling my backend, and Javascript taking that data and displaying it client-side. Making a Rails API was nice review of Mod 3, plus it underscored why it is such a useful framework- I created my project in the command line and "scaffolded" my resources with each of their attributes (Team and Player in my case). Player would be a nested resource to Team, as a Player belongs_to a Team- rendering only the data I wanted in the teams_controller was the only major challenge here:

render json: teams, only: [:name, :logo_img, :players, :id], include: {players: {except: [:created_at, :updated_at]}}

I went on to make an entirely separate repo and file directory my project's frontend, where I would be coding my Javascript. Starting was simple enough- I put an event listener on the document, and when the DOM is loaded, I invoke a yet-to-written function called getTeam() (logical enough, I wanted the browser to display the available teams that I seeded into my backend).
getTeam() makes a fetch request to the API, and once the data is formatted correctly, runs a forEach(), taking in each Team object, and creating a new Team (using the ES6 object-oriented syntactic sugar) to display in the DOM.

function getTeam(){
    fetch('http://localhost:3000/api/teams')
    .then(r => r.json())
    .then(resp => {
        resp.forEach(team => {
            const t = new Team(team, modal)
            t.addToDom()
        })
    })

This is where getting into Object Orientation made sense. All the concerns of Team could be under one big class, so when 'new Team' is called from the fetch request, each one could be initialized with the constructor method that would correctly set each attribute. The addToDom() method of the Team class posed my next significant challenge: its purpose was actually access the appropriate HTML node and show the application user the data correctly. However I found that the function I was writing was starting to take up 30 lines of code and going supernova! I had it showing each team with it's logo on a div. Then when that logo gets clicked, an event listener would fire, making a fetch request to show the players associated to that particular team. Having an entirely separate fetch request in the same function seemed like it was in dire need of a refactor, since now this one function was responsible for two completely separate concerns.

    addToDom() {
        const teamOnDom = document.querySelector('#team-container')
        const teamDiv = document.createElement("div")
        teamDiv.classList.add("team")
        teamDiv.innerHTML += this.renderTeam()
        teamOnDom.appendChild(teamDiv)
        teamDiv.addEventListener('click', () => {
            this.modal.classList.remove("hide")
            this.renderPlayers()
        })
    }

I refactored that call to the API into its own function, renderPlayers(), after displaying the modal that would pop up and show the roster.
Players were a nested resource of Team, should they have their own class handling their concerns? I opted against it, because I could call 'Team.players' in the Team class and have all of the info about each player easily accessible.
In order to hit the project requirements, I needed an additional fetch request to my backend with another CRUD functionality- I already had the 'read', and as my app is for managing player rosters, it made sense to be able to update information about each player. A PATCH request would do the trick. First I needed to figure out my endpoint, which would be each player by their ID in the URL. I had to pass the configuration object as a second argument, which would designate this fetch call as a PATCH request to update information about the targeted resource.

updatePlayer(form, id) {
            fetch(`http://localhost:3000/api/teams/${this.id}/players/${id}`, {
                method: "PATCH",
                headers: {
                    "Content-Type": "application/json",
                    "accept": "application/json"},
                body: JSON.stringify( 
                    {
                        first_name: form[0].value,
                        last_name: form[1].value,
                        jersey_number: form[2].value,
                        primary_position: form[3].value,
                        handedness: form[4].value,
                        injured: form[5].value
                    }
                )
            })
                .then(r => r.json())
                .then(data => this.renderPlayers(data))
    }

The existing information about each player was already present in the Edit Form rendered to a user, but any information edited in that form was passed into the body of the configuration object to persist to the database. As an aside, I found that accounting for all the closed parentheses and curly brackets to be a huge headache in this! An object passed as an argument, with it's own embedded objects, and passing an object as the argument to a .stringify() serializer function. It took AT LEAST triple checking to understand why VS Code was still telling me there was a syntax error baked into my code!
Javascript overall is a more free-form language that challenges a developer to plan and structure their code before writing it, as otherwise it can quickly get confusing to keep track of. The key I think is to go into a project with an idea of the functionality in mind, and split those concerns into their own functions, and pass those functions to each other to handle the appropriate data.

Off the Rails!

MikeDudolevitch — Fri, 14 May 2021 01:46:37 +0000

For Flatiron School's Phase 3 final project, we were tasked with creating a web application using the Ruby on Rails framework. I had the idea to make a Book Club app, as it sounded like an idea that I as a user would be into. It would be easy to meet the requirements of a many-to-many relationships, since users would logically be able to belong to many different individual clubs, and clubs are going to have any number of users. Once I dove into the project creation, I had plenty of issues harnessing Rails' "magic" (ie. the convenient assumptions and built-in helper methods that Rails offers that save lots of explicit coding- IF you are comfortable with them.)
My models were my first course of action. I had a straight line from Users => Clubs <= Books in which they would associate. I created join tables to properly associate them: Users => Club_Users <=> Clubs <=> Club_Users <=> Books. These would store the foreign keys of their joining clubs. Additionally, the Club_Users would have a boolean value in the table for that user's role as an admin to the associated club. I implemented the with some aforementioned Rails "magic":

rails g resource users username email password

The above command line creates the model, controller, and database migration for Users- with the attributes starting with 'username' assumed as strings, unless specified otherwise. It would have been tedious to created each file for each of my models, so this is a prime example of the Rails "magic" at work.
Once I migrated all of these to the database, it was time to think about my app's routes. In the 'config/routes' file that's provided upon starting a new Rails project, I waved the magic wand another time:

resources :clubs do resources :books, :only => [:new, :index, :show] end

With the 'resources' keyword, the framework sets up every RESTful route associated with that model, with corresponding helper method for each one- ie. now '/clubs', an index of all clubs was now available to be implemented, and could be called with 'clubs_path' throughout my app. The above code demonstrates my nested resource of 'books', in which I specify which of the RESTful routes I am opting to use.
I set up my log in functionality similarly to the Sinatra project of the previous phase- setting up validations for email, username and checking for presence and uniqueness, and the has_secure_password ActiveRecord method that works in the .authenticate function on a given user to check that their password matches. Then I set the session_id equal to the ID of the user that just logged in, and delete the session on clicking the logout button in my navbar. Additionally, a requirement for this project was to allow a sign in via a 3rd party such as Facebook, Google, or Github- I installed the Omniauth gem and set about following the documentation for registering an app on Google, and taking the client_id and client_secret it provided, setting it in a .env file as it directed, and hiding that information from pushing to Github via .gitignore in my project (as this is sensitive information that could compromise the security of an actual app that gets regular use.) I understand that my app needed to use this stored information to communicate and verify with Google, then once it gets verified a user is able to use their account to log in.

scope :newest_books, -> { order(created_at: :desc).limit(5) }

I used this scope method in my Books model, essentially as a class method that uses ActiveRecord's database querying directly to select the 5 most recent books that had been created across the app. I created a custom route outside of RESTful conventions called 'recent_books' and was able to directly display those 5 most recent books- using the Rails helper method 'link_to' to generate an HTML link to each book's show page. Another custom route my app called for was for a page that showed every book club a user belonged to in order to make a user's experience navigating easier.

get "/your_clubs", to: "clubs#your_clubs"

This took every club in which the current user had joined and iterated over each and displayed it for easy access.
I wanted to find a way to leverage the 'admin' boolean value of my club_users join table- naturally I only wanted users with the admin value set to true to be able to implement the create, edit, and delete actions in each club. So anytime a user created their own brand new club, that would set their admin value to true, giving them control over that club- in the 'show' view for each club, I put some conditional value to if the current user is in fact that admin, display the buttons for choosing the new book to read, ability to update the group, and ability to delete it altogether. Otherwise, simply by joining an existing group, the functionality that is unlocked is access to the virtual meeting link that is provided by the club's admin (again through a conditional 'if' statement in my .erb show page.)
It took fighting through plenty of Rails server error messages to get all of these application features up and running, but each one taught me more about how to wield the logic of this powerful framework, and why it is extremely popular in modern day web applications.

A Guitar Collector App From Scratch

MikeDudolevitch — Thu, 01 Apr 2021 21:53:30 +0000

For Flatiron School's Mod 2 final project, the challenge was to create a full site from the ground up using the Sinatra framework- complete with user log-in/log-out functionality, the ability to post and edit their posts, and enough security to protect each user's posts. My two major hobbies are hockey and music, and I had already done a hockey related app for phase 1's CLI app, so my brainstorming instantly went to music. I wanted to make a site dealing with guitars specifically, since the ability to create, save, and edit seemed to lend itself to a guitar collection (I have a modest collection of guitars myself. I've always seemed to just luck into them!)
To sink my teeth into the app's creation, I installed and used the Corneal gem in my terminal- this was invaluable to setting up the various directories needed to handle the files from my database to my user's views. I had heard mixed things about this gem, and it gave me pause to hear about some additional troubleshooting needed for version compatibility with some other gems, but overall I found it to be excellent- I had to manually adjust the version of ActiveRecord but once I did that, I had my site template up and running. It gives a very basic layout but it was simple to customize the existing code that Corneal loads up instead of starting it from scratch.
My philosophy going into this was to opt for simplicity- using very neat code and keeping my object relationships minimal. My models inherited the 'has-many' (in this case, my user) and 'belongs to' (their guitars) so all I had to do was set those macros in each respective model and I knew that a user ID would associate to each guitar when persisted to my database. I elected not to seed dummy data to my database table or pull data from an API. Instead I went with the idea that each user can fill out a form to create and save their own guitars. Each form would instantiate a new guitar, and persist it to the database by matching up each attribute from the form to each column of my table. It was important to me to be able to display a photo of each guitar, and this posed my first significant challenge. To enact this, I gave the site user a form item to supply an image url in the creation form. In the pertinent views routes, I was able to use an HTML anchor tag and dynamically pass in that url to display each guitar photo.

<img src=<%= @guitar.image_url %> alt="Guitar Image">

In the event no url gets passed in, I was able to set a default image url to a variable, and then set a conditional that if no custom guitar picture is passed in, just display the default. I then had to pop into my CSS stylesheet and set image size parameters, to avoid having enormous pictures of guitars displaying on the page. Also- I wanted SOME fields to be required, and some (like the image url of course) to be optional- in my guitar model I had to set validations for each attribute that I wanted to be mandatory. Phew! That was a lot of steps and trial and error to get this basic functionality!

photo_url = !params[:image_url].empty? ? params[:image_url] : "https://i.pinimg.com/originals/0b/0d/bc/0b0dbce265be5db9bf7061b4e8dc83f4.png"

I had a basic sketch of what routes I wanted, but I found it to be a challenge enacting those RESTful conventions at first. How do I get to my /index page? That would start with no data, so what would I display to a new user? How do I click one specific guitar from their index, and just display that? I knew I would need to take the individual ID and pass it into the route, but how do is that possible for every single guitar? After some missteps and improper routing, I followed the correct convention to show the index after login, render the form to create guitars, and a cool feature to click on the photo of each created guitar to pull up a page just showing that one's attributes. String interpolating the .id method call on that instance of a guitar in the route solved my issue of being able to single out an individual guitar to display on my '/shows' view. Then I refactored my creation form to be an edit form, and set up the proper routes, including a 'patch' request in my guitar controller file.
This was all well and good, and was able to display properly when I ran the Shotgun gem to spin up a local host. But what about getting users to log in and out? How do I protect each user's items they created from being manipulated by another unrelated user? At this point, anyone could type in a random ID number of a guitar in the browser and edit it all they want. This wouldn't do for an actual functional site! It was time to enable 'sessions' in my main controller, and a sessions controller (for handling each user session) and a users controller (for handling creating a new user properly).

post '/login' do redirect_if_already_logged_in user = User.find_by(email: params[:email]) if user && user.authenticate(params[:password]) session[:user_id] = user.id redirect '/guitars' else redirect '/login' end end

Much of the curriculum in Mod 2 involved using methods that were inherited from elsewhere, which is logical in development- it only makes sense to have frameworks and gems write the common lower level methods, while as the builder of an app we are responsible for the higher level functions and specifics. This accounted for some of my learning gaps as well. Remembering and properly identifying which inherited methods came from where proved to trip me up. In order to log a user in, I had to call .authenticate on that user in a post request on my sessions controller to make sure the email passed in matched the password they set. The .authenticate method is one that I can call only because in my user model I included the has_secure_password method (which in itself is inherited from ActiveModel::SecurePassword module of ActiveRecord::Base). Once has_secure_password is loaded, this opens up the ability to a) work in conjunction with the bcrypt gem, which salts a passed in password for security (I don't want to be sued for my Guitar Wishlist passwords getting leaked!), b) writes a reader method to the model for their password, and c) .authenticate, which verifies that the password of that instance of user matches the email they signed up with.

class User < ActiveRecord::Base has_many :guitars has_secure_password validates :email, uniqueness: true validates :email, presence: true end

This log-in feature didn't quite protect my routes- I had to create some helper methods in my main controller for that. These helper methods were little catch-all methods I would call in other methods throughout my app, just to make sure what the user was trying to do was kosher- they compared the user's ID to the session's user ID, and if the two didn't match up, it's back to the login page. Ditto if a user is logged in, we bypass the login page, or if not logged in at any point redirect them to do so, etc.
Now I had my users, their ability to login and logout (a delete request that clears the current session), their CRUD ability to each guitar in their profile, and protection to that CRUD functionality to unauthorized users. Each step of the way to get there broke my code and threw error messages to my browser, causing plenty of frustration when I thought my logic was sound and implemented flawlessly. Through the guidance of my cohort leads and classmates, I was able to knock down each barrier and get my site fully functioning, once again reinforcing how much of software engineering is about collaborating effectively. And I have new respect for just how many factors even the simplest website has to handle!

NHL Command Line App

MikeDudolevitch — Mon, 01 Mar 2021 14:12:54 +0000

I was able to finish the Flatiron School's Phase 1 Final Project, which calls for creating a command line interface app in Ruby that pulls data from a remote source uses that data in an object oriented program. I eventually opted to create a program that gives the user information about any NHL franchise's first year in the league. With a week to complete it start to finish, I hit a few challenges and some breakthroughs until I was ready to call it complete and have my parents display it on their refrigerator. I'll give the play-by-play, and color commentary, on how I was able to get to the final buzzer.

The first order of business was to brainstorm concepts for my app. I toyed with the idea of randomly generating and displaying a year to the user, and they have multiple choices to select which team won the Stanley Cup. As a fallback option, I came up with the idea to have the user type in their birth date and the app would display what the number 1 song in the charts (which specific chart depended on which chart API I was able to pull from). With 2 strong contenders in my back pocket I started researching APIs. RapidAPI.com seemed like a great resource, as it has a clean and simple search function to browse categories. I found a Billboard Chart API, which pushed me in the direction to create my Chart Topper birthday app (The hockey ones had a dizzying amount of statistical data to parse through, which I found discouraging). I started coding my model, when I realized I had not properly researched the API's endpoints (these are new concepts that though I understand in theory, it wasn't intuitive to me yet). The data being displayed was limited strictly to the current charts! Back to the drawing board it was- that was not enough depth of information to pass project requirements no matter what I did with it.

With a little bit of guidance, I reverted back to my hockey-themed app idea, but from an API with very simple endpoints (https://github.com/dword4/nhlapi). It was getting to be mid-week, and I wanted to simplify my model. The endpoint I elected to pass into my project showed an array of every NHL team, with a hash containing roughly 20 key/value pairs showing information from the city they play in, the conference and division they're a part of, home arena, first year of play, etc. It was the latter data point that I decided on to be the focus of my app. This made for a much more simplified idea than my previous ones, but I leaned into the rule of MVP- no I'm not talking about the Hart Trophy winner- but Minimum Viable Product. My goal was focused mostly on creating crisp, clear code, and properly separating concerns among the classes I would be writing.

My API class was simple, and only called upon first running the program. Following the specs from my source API, I set my response to a variable, and parsed through it with the JSON gem to get nicely formatted data. I passed the array of individual teams through a .each iteration, where each element of the array would create a new instance of my 'Team' class.

My Team class would be responsible for storing my list of NHL Teams, that are created upon initialization. As previously mentioned, each team it's own hash of data- in my Team model I meta-programmed getter and setter methods only for the data that I wished to work with in my program- the team's name, their first year of play, and their official website. Additionally I set class methods to alphabetize each team by name, and to find each team by name as those would prove essential once I started writing my CLI class.

For my CLI class, I had the challenge to take that team data and find a way to display it appropriately for the user. My original plan was to display my alphabetically ordered and numbered list of teams, and take input via the gets.chomp method- then save that input to a variable, and pass it in as an index number to the full array of teams. The corresponding (adjusted for index value of course, as my list starts at 1) team would get displayed with their name, first year in the league, and website through my 'display' method that I wrote and formatted. This was not as clean as I would have liked though- for it to work, I'd have to have all 31 teams showing in the terminal, which looked unwieldy, and I'd have to code in all sorts of conditions to make sure the user input was valid. This made for unnecessarily messy, ugly code.

Coming in like a trade for a star player at the deadline, I discovered (through my excellent classmates) a gem plug-in called TTY::Prompt (https://www.rubydoc.info/gems/tty-prompt). Learning this amazing tool was a gamechanger in my application: it let me format and display menu data as I wanted, and gave all sorts of customizable scrolling options. Once the gem is installed, set a variable equal to a new instance of TTY-Prompt (in my case, I used a constant in my environment file). On that variable or constant, all I had to do was call whichever method detailed in the gem documentation worked for what I was going for. I used PROMPT.select(then it took an argument for a customized user prompt, how many choices to display, etc.). I saved whatever user input they chose into a variable, and passed that variable on to my corresponding Team class method, to display just that team's data. I coded in a prompt to either display the list of teams again to make another choice, or to exit the program.

My command line interface application reflected the subject that I made it about- hockey. In hockey, often times the best results come from simplifying the game and committing to fundamentals. I believe my project does just that.

Why I Decided to Learn Software Development

MikeDudolevitch — Sun, 14 Feb 2021 13:47:05 +0000

    I decided to take a leap of faith to learn a whole new, foreign set of skills in software engineering. There seemed to be the perfect storm of factors and influences that came along at a time in my life when I felt ready for a new challenge. 
There’s a philosophical factor above any of the personal circumstances or career goals. This is how the world works. This is a thing I benefit from every day of my life. Generations of people (including my Grandfather, who worked in the WWII/post-War field of computer development, from very simple code inputs to corresponding outputs) have problem-solved and innovated to a point where real world solutions are a regular part of life, and taken for granted. I have a desire to be a part of that- to understand these systems that are commonplace in everyday life, but to the layman (ie. me) can seem like voodoo magic.
    I have reached a point, at 32 years of age, where I pretty much know what I've gotten good at, and I primarily lean on those skills in my life. It can feel like I've stagnated recently because of that. Challenges have always helped me better myself, and I've felt hungry to add a new dimension to what I can accomplish.
There are plenty of practical aspects to why I want to master software development. I want to have a higher ceiling for career advancement. Performing music will always be my central passion, and I think software development compliments that lifestyle perfectly. There's opportunity to work remotely, which, through the pandemic, I've realized suits me well, and would suit my musical touring ambitions as well. On top of that, I've been fortunate to make all sorts of friends that have pursued software development mastery and succeeded. They've encouraged me to do it myself and their support has boosted my confidence that I can succeed in software engineering as well.
    My journey to learn this whole new set of skills in software engineering comes from a desire to be a part of building something, from a desire to better myself, and from plenty of encouragement from my support system. I look forward to each and every step of the way.