DEV Community: Steve Kim

Customizing radio buttons and checkboxes with CSS

Steve Kim — Wed, 06 Apr 2022 18:30:39 +0000

Disclaimer: There's an unnecessarily long introduction that I couldn't stop myself from writing. I had no intention of baiting so feel free to skip to the TL;DR section below if you're just here for the examples.

How much CSS do front-end developers have to know? I've heard arguments for both sides, ranging anywhere from "it's an absolute must since CSS is directly related to what the user sees and interacts with which is ultimately all things front-end" to "I've been a front-end developer for over 18 years and I've never had to write a single line of CSS during my entire career." But despite which end of the spectrum your opinion aligns with, I think most of us can agree that having an additional skill under your belt never hurt anyone and, if not anything, it will add to your list of developer traits than take away from it.

Having said that, it's also probably worth mentioning that CSS unfortunately seems to be one of those things that are often neglected and end up being self-taught. It was covered very briefly in my bootcamp curriculum and the little amount that was introduced was kept to the basics. It is also rarely included in any of the project requirements nor is it held to a high standard during an assessment. For a newbie programmer like myself, I'd say the primary motivation behind learning and practicing more CSS usually stems from self-fulfillment and the desire to make your final product look as "professional-grade" as possible.

Furthermore, I think the technical side of CSS can sometimes feel disjointed from the ability to make a web application look aesthetic because it shares close boundaries with the creative/artistic realm of web design which requires a different skillset like knowing which shades of colors to use and how to make something look visually appealing to the user.

TL;DR

So if you're at all interested in this post it must mean you're looking to customize your input type radios and checkboxes purely using CSS. Let's start with radio buttons because they're slightly simpler.

Radio Buttons

The first step is to change the radio buttons to our desired size.



input[type="radio"] {
  width: 220px;
  height: 160px;
}

BOOM. Big radio buttons. Next we set the appearance property, which controls the native appearance of UI controls, to none. Then we set a border (or a background color, or an image, or a combination of all three), just anything to help us actually see something appear on the page. I also got rid of the Yes and No text because we want these to show up inside the button and not beside it. Then I added a border-radius to round the edges and a cursor: pointer to bring back the pointer effect when we hover.



input[type="radio"] {
  width: 220px;
  height: 160px;
  appearance: none;
  border: solid 1px #72978d;
  background-color: #f1f5f5;
  border-radius: 6px;
  cursor: pointer;
}

Finally, I had a decision to make about how I wanted to handle the inner text as well as the checkmark graphic when the button is selected. For this particular example, it felt easy enough to simply use CSS pseudo-classes and different images to achieve the desired effect.

I concluded that there were essentially four different states that I needed to account for and thus four different images:

Yes [unselected]
Yes [selected]
No [unselected]
No [selected]



input[type="radio"]:first-of-type {
  background-image: url('./images/yes-unselected.svg');
}
input[type="radio"]:first-of-type:checked {
  background-image: url('./images/yes-selected.svg');
  background-color: #d8e2e0;
}
input[type="radio"]:last-of-type {
  background-image: url('./images/no-unselected.svg');
}
input[type="radio"]:last-of-type:checked {
  background-image: url('./images/no-selected.svg');
  background-color: #d8e2e0;
}

You can also use different pseudo selectors or any other way that's appropriate to your code as long as you are able to grab the correct elements in applying these styles. The key is to make the images the exact size you need so that they are a perfect fit, but even if they weren't, you'd be able to add properties like background-size, background-repeat: no-repeat, and background-position: center to ensure they show up nicely. And lastly, since I use a different background-color for the 'checked' state, I also added the same color to the hover effect for a better UX.



input[type="radio"]:hover {
  background-color: #d8e2e0;
}

Checkboxes

So what about checkboxes then? Can we just do the same thing?
Almost, but not quite. The gist of it is the same but checkboxes behave differently in that you're unable to add a background image. This means you lose a lot of flexibility and it creates a challenge in designing the checkbox to your desired look. What you can do, however, is hide its display, give it an id, and point to that id from a label tag which can set background images. Take the following example:

I've got several checkboxes that each have an image, text, and an additional input field that appears in the same "box" once clicked. The HTML for one of these checkboxes looks like this:



<div>
   <input type="checkbox" name="beer" id="beer" checked={checked.beer} onChange={handleCheckbox} />
   <label htmlFor="beer">
      <span>Beer</span>
   </label>
   {checked.beer ? <input type="number" ... /> : null}
</div>

(It's actually JSX, but you get the idea.)

I'm using some local state in React to keep the form controlled and using a ternary statement to render the number field conditionally, but that's a whole another topic so we'll dial that back and stick to just the CSS portion. Just note that the htmlFor property above is the JSX equivalent to using the for attribute in HTML labels.

So the div here is representing our "checkbox" so-to-speak and inside I've got the actual checkbox input which we will use CSS to hide, the label (which wraps a span of the text), and then the <input type="number"> field which, again, will render depending on whether the checkbox is checked.

Then I apply the following CSS:



div {
  width: 220px;
  min-height: 160px;
  border: solid 1px #72978d;
  border-radius: 6px;
}
div:hover {
  background-color: rgb(216, 226, 224);
}
input[type="checkbox"] {
  display: none;
}
label {
  width: 220px;
  height: 160px;
  display: inline-block;
  background-repeat: no-repeat;
  background-position: 50% 25%;
  cursor: pointer;
}
label > span {
  display: inline-block;
  margin-top: 100px;
}
label[for="beer"] {
  background-image: url('./images/icon-beer.svg');
}
input[type="checkbox"]:checked + label {
  background-image: url('./images/icon-checkmark.svg');
}

Okay, so let's break this down.

We set the width and height on the div that will act as our container, but only use min-height so that it can expand if we need to display the number field below it.
We then set a different color on hover to give the user some feedback like we did with the radio buttons (this part's not so important).
Then we hide the actual checkbox using display: none and instead fill the entire div with the label by using the same width and height.
We also set its display to inline-block in order to use a block element box but without the line breaks so that it flows with surrounding content.
Then we make sure to prevent the image from its default behavior, which is to repeat in both directions, and use background-position to define the X and Y values (using 50% for the X value to center the image but 25% for the Y value to leave some space underneath for the span).
And of course we mustn't forget to bring back the mouse pointer with the cursor property.
Then for the span of text, we use display: inline-block again and set a top margin to properly position it under the image.
And finally we set two background images on the label: the default image we want to display and a different image when the checkbox is checked. (Pro-tip: Placing the label right after the hidden checkbox in the HTML makes it easy to use the adjacent sibling combinator CSS selector to target the label when the checkbox is in its checked state.)

Again, as with most things in the land of programming, there's likely more than one approach to produce the same results (sometimes with subtle differences between them). So I'm certain that my examples are not the only way to customize these fields; they are merely one implementation that has worked for me and I share them here hoping someone might find them useful.

Final Thoughts

To be fair, I tend to put off CSS until the very end in all of my personal projects and I would argue that a significant amount of people probably do as well (or maybe it's just me). But one thing I noticed is that the more familiar I become with styling in CSS and utilizing certain patterns, determining how I should structure the application does become slightly more instinctive. In other words, it becomes much easier to code for the future knowing that I will probably want certain containers in certain places to hold certain class names and so forth. Next I think I'll explore with some of the popular CSS frameworks that we might encounter in the industry and see how they compare. Feel free to leave me comments or suggestions!

The Chronicles of a Rookie Developer: My 'React'ion Blog

Steve Kim — Tue, 29 Mar 2022 21:19:03 +0000

It's finally here. The long awaited 2nd edition of The Chronicles of a Rookie Developer. (And yes, I just shamelessly upsold my self-made blog series. 😏)

Today's piece is about none other than the most popular front-end library out there, ReactJS. My one-liner opinion? Let's just say I can understand where its popularity stems from. But my affection won't make much of a blog post, so let's just dive right in, shall we?

As with the JS post, I thought I'd start by simply sharing my first impressions, some things I've learned along the way, then maybe leave you at the end with a few thoughts going forward.

One. Hooked on hooks.

I'm just going to come right out and say it. What the hook would we do without hooks? Okay that was corny. But seriously, everything is so much easier with hooks. I felt so cheated when I first encountered hook examples after spending a lot of time learning about functional vs. class components, using lifecycle methods, and this. Granted, not all of these things completely "go away" with hooks, and I don't regret covering all the bases because 1) I think it makes me a stronger developer and 2) I'm told there are still plenty of professional environments that use legacy code while the industry tries to catch-up. So for anyone who's just starting out on this path as I am, I still recommend you take the time to understand the old and the new. Also, I imagine that there's still a niche for class components since you could very well run into situations where it's just more sensible to use traditional methods -- whether it's to follow certain design patterns or something more subtle. (And I encourage you to comment below if you have any good examples.) But the point I want to make is that hooks are... well... they're wonderful.

Two. When unsure, useState.

One thing I noticed whenever I wanted to add a new feature or improve upon an existing one, is that I'm constantly setting and using state. Even with Redux in my application, I quickly realized that the need for local state is almost completely separate of what Redux is designed to solve. Redux deals with maintaining a single source of truth and helps prevent prop drilling, but it's more closely tied to the actual data you might need throughout your application as opposed to other non-critical or UI state. For instance, when I'm dealing with how my application behaves or how it should render a component, it usually means I just need to keep track of values that represent a certain state of my application.

Take this example. I was building out a quiz-like feature on my application and needed to incorporate a stepper to visibly show the user which question they were on because how annoying would a quiz or survey be if you had no idea how many more times you can expect to press "Next" before you're finished. So I've got a "parent" component that renders a separate component for each question in the quiz. (FYI, I am also using React Router to take the user to a new route for each of these renders.)



import { Routes, Route } from 'react-router-dom';
import QuestionOne from './quiz/QuestionOne';
import QuestionTwo from './quiz/QuestionTwo';
...

function Quiz() {
   return (
      <div>
         <Routes>
            <Route path="1" element={<QuestionOne />} />
            <Route path="2" element={<QuestionTwo />} />
            ...
         </Routes>
      </div>
   );
}

Here's the part you stop to think what information is changing and therefore should belong in state (the current question in the quiz) and which component stays mounted and which ones come and go (the Quiz component is the parent that stays mounted while the Question components render on and off the page depending on the route). So then where should my stepper live and which component should keep track of which step the user is on? The answer is obviously the parent component, in this case, Quiz. Great, so we add that in.



...

function Quiz() {
   return (
      <div>
         <Routes>
            <Route path="1" element={<QuestionOne />} />
            <Route path="2" element={<QuestionTwo />} />
            ...
         </Routes>
         <Stepper steps={10}
            nextButton={<button onClick={handleNext}> Next </button>}
            backButton={<button onClick={handleBack}> Back </button>} />
      </div>
   );
}

(For the actual Stepper component, I used Material UI but have simplified its properties for the purpose of this example.)

The props that are being passed are pretty self-explanatory but steps obviously refers to the total number of steps we want our stepper to have, whereas nextButton and backButton represent our two buttons that each take an onClick event that will handle navigating forward and back through our quiz. So now, how can we get the stepper to actually display which step we're currently on? Enter the useState hook.



//Quiz.js
...
import { useState } from 'react';

function Quiz() {
   const [activeStep, setActiveStep] = useState(0);
   return (
      <div>
         <Routes>
            <Route path="1" element={<QuestionOne setActiveStep={setActiveStep} />} />
            <Route path="2" element={<QuestionTwo setActiveStep={setActiveStep} />} />
            ...
         </Routes>
         <Stepper steps={10}
            activeStep={activeStep}
            nextButton={<button onClick={handleNext}> Next </button>}
            backButton={<button onClick={handleBack} disabled={activeStep === 0}> Back </button>} />
      </div>
   );
}



//QuestionOne.js
import { useEffect } from 'react';

function QuestionOne({setActiveStep}) {
   useEffect(() => {
      setActiveStep(0);
   }, []);

   return ...
}

export default QuestionOne;



//QuestionTwo.js
...

function QuestionTwo({setActiveStep}) {
   useEffect(() => {
      setActiveStep(1);
   }, []);

   return ...
}

export default QuestionTwo;

Couple of things are happening here but first I set up some local state in my Quiz component with an initial value of 0 and name it activeStep. I then pass this as a prop to my Stepper component in order to tell it what step we're on (and also use it to disable the "Back" button when we're on the first step/question). Then I pass the setActiveStep method to the children components so that they may use it in their useEffect which I have set up to basically mimic the componentDidMount lifecycle.

So now, whenever the user renders a Question component, the parent will know which one the user is looking at since it holds the activeStep state and shares the corresponding value to the Stepper as well.

Some other great examples of places I utilized local state are with my Login/Signup drawers, controlled forms, various snackbars, dialogs, toggles and many more. When building with React, you will never be short of places to use and manage state since literally any value that needs to change will mean that it needs to be stored in either local or global state.

But it's important to bear in mind that there is no right answer when it comes to which of the two you should use to store your information. Even the Redux documentation will tell you that it's often a choice developers have to make and that it's important to find a good balance. Some developers are more comfortable with storing absolutely everything in a global state management tool (like Redux) whereas I personally find it an anti-pattern to include every bit of information in the global state when we can utilize local state.

So next time you're wanting to develop a feature but feel stuck or clueless on where to begin, try setting up some values in state and focus on what and how those values need to change in order to implement your desired behavior.

Three. Keep a mental note of the component tree.

Lastly, I would like to end with this. I learned that taking sufficient time to plan and having a solid grasp of how you will build out your component tree before you get started on a project can help tremendously with your application control flow. Once a user starts freely navigating around in your app, it quickly becomes apparent that you need to be somewhat conscious of which components are constantly mounting and unmounting. This is particularly because the lifecycle of a component is crucial in determining where certain state values should reside and if you're not making a mental note of it as you code, it can lead to some very unexpected behavior down the road (especially as your application grows bigger in both size and functionality).

As always, thank you for taking the time to read and, once again, stay tuned for the next edition of The Chronicles of a Rookie Developer!

The Chronicles of a Rookie Developer: JavaScript Insights

Steve Kim — Wed, 22 Dec 2021 15:52:42 +0000

Pretext

After building out my first-ever vanilla JS + Rails API application, I thought back on the experience and skimmed through my code to gather ideas on what I could blog about. The truth is, there were many bits and pieces that I learned but I didn't feel like I knew nearly enough about each topic to solely dedicate an entire blog post. (Not to mention I also suffer from chronic indecisiveness.) So I apologize in advance but I decided to just list them all. Here are 4 things I learned, attempted, or simply found interesting about JavaScript.

One. To function, or not to function, that is the question.

In JavaScript, and particularly vanilla JS, you're most likely going to declare and use these so-called node getters where you grab elements from the DOM using a method such as (but not limited to) querySelector() in combination with one or more valid CSS selector strings (like classes or ids). And when you find yourself querying for the same node multiple times at difference places in your code, it makes sense to assign it to a variable and extract it to a more global scope, right?
Now, I know that when we first start learning to code, this notion of declaring variables in the global scope is a big no-no and it gets reiterated over and over as we're often told that it can lead to some unexpected behaviors down the road and should therefore -- when possible -- be avoided. But for now, let's just assume that our application is extremely small and there is very little to no reason to sound the alarm. The question, then, is whether to wrap these node getters into a function or to just have it point directly to the node.
For instance, you might've seen someone do something like
const mainContainer = () => document.querySelector('div.main')
versus something like
const header = document.querySelector('#header').
So which way is better? The answer, I've found, is that it really depends.

There's this subtle yet sweet balance between what you are trying to accomplish with the node and whether the node exists or doesn't exist inside a particular execution context.

The benefit of using a function to grab your node is that you can always ensure you are selecting the most recent version of it since you are calling the query at the exact moment you need it. This is particularly useful when perhaps you need to grab a node that doesn't exist immediately on initial load but is something that gets created later in your code (as a result of a callback, for instance). I'd say 9 times out of 10, this is probably going to be your preferred method.

However, the opposite can also be true. I ran into an occasion where it made more sense to point directly to the node, and it was something as simple as wanting to remove() a header from the page and later re-attach that same exact node back on the DOM. In this case, if we were to use a function, we would not be able to find the node since it would no longer exist on the document and we would instead have to re-create the element. But luckily for us, JavaScript has garbage collection, meaning it will store it in memory and give us access to it even after it's been removed from the DOM as long as we point it to a variable. It then goes without saying that this would probably merit some thought in all future applications in order to ensure that we are always effectively preventing unnecessary memory leaks.

Two. Two is always better than one, or is it...?

The thing I'm talking about here is none other than the DRY principle of programming and my humble attempt to combine two functions into one. I've learned by now that refactoring code is just a regular part of any programmer's life and should become second nature sooner rather than later. So as I examined for areas to abstract, I noticed that my fetch functions were carrying a lot of code and particularly noticed similarities between my POST and PATCH requests. The data being sent was identical, the fetch url was identical except for the presence of an id (thanks to RESTful routing), and the init object was identical except for the HTTP method. It seemed to check everything off the list for a potential refactor.

First I should start by mentioning that I've built my application in an object-oriented pattern using ES6 class syntax and therefore have a separate Adapter class that handles all fetches.
Sticking to conventions of CRUD, I've got a static createRecord() and updateRecord() method within the Adapter class, each responsible for sending the appropriate fetch request. I also have one other static property, baseURL, and two other static methods defined, setDataObj() and setInitObj(). baseURL (as the name suggests) simply stores the base URL to which we will be sending our fetch requests while setDataObj() is responsible for constructing the object that we will be sending off to the backend and contains all of the input values from a form. It looks something like this:



static setDataObj = () => {
    const name = form().querySelector('#name').value;
    const description = form().querySelector('#description').value;

    const data = {
        name,
        description
    };

    return data;
};

Notice that it returns the data object, as this will be useful to us in the next step.
Then in my setInitObj() method, I take in a string argument for the type of request -- POST, PATCH, or PUT -- then use it to build out an options object.



static setInitObj = (method) => {
    const options = {
        method: method,
        headers: {
            "Content-Type": "application/json",
            Accept: "application/json"
        },
        body: JSON.stringify(Adapter.setDataObj())
    };

    return options;
};

Notice that I am now able to simply pass in Adapter.setDataObj() to JSON.stringify() since we made it return the object we need.
setInitObj() then returns yet another object, which we can use in our fetch method both in createRecord() or updateRecord(), passing in the proper HTTP verb with it:



static createRecord = () => {
    fetch(Adapter.baseURL, Adapter.setInitObj('POST'))
        ...
};



static updateRecord = (id) => {
    fetch(Adapter.baseURL + id, Adapter.setInitObj('PATCH'))
        ...
};

Now in my event handlers, or anywhere in my code where I need to send off the form data, I can simply call Adapter.createRecord() or Adapter.updateRecord(id).

Three. Being conscious of how often we fetch.

Personally, this was more of a food for thought than anything else because I'm guilty of not following my own advice but I did realize the importance of code design, particularly how I wish to maintain the data on the front-end after a fetch. Because this was my first experience with JavaScript, and especially because I was using functional vanilla JS instead of object-oriented JS or some other library, I chose the easy way out and saved myself a few headaches by re-fetching at times. Not ALL the time, but in certain situations. At least now I definitely see how I could have done things and it will come in handy as I think about incorporating more features on my app like sorting and filtering.
(Note: This was something I wanted to share at the time of originally writing this post but have since rebuilt my entire project into object-oriented JavaScript and am now dealing with my front-end data in a much different manner.)

Four. Default behavior of an HTML5 button is submit.

Last but not least, I was enlightened during one of my debugging sessions that, apparently, the default behavior of a button is submit unless specified otherwise. Maybe this was just me but for some reason I always thought <button> tags did not have a default behavior as opposed to <input type="submit">. This would matter less if the button isn't enclosed in a <form> but if you're ever trying to use buttons inside a form for something other than submitting the form, you have to either specify the button's type attribute as type="button" or, alternatively, use preventDefault() in its event handler. Again, this might've been obvious to most but I hope someone else out there might find it useful to know!

If you've made it this far, thank you for reading. Stay tuned for the next edition of The Chronicles of a Rookie Developer as I continue my journey! Until next time!

Rails: The Quick-and-Dirty to February 31

Steve Kim — Thu, 04 Nov 2021 16:18:27 +0000

Prologue

If you're a newbie programmer like I am and just starting to build your very first Ruby on Rails application, there's a good chance you'll attempt to incorporate some dates in your data using good ole HTML5 forms.

Whether it's inputting a user's birthdate or adding some sort of calendar feature, your instinct will be to use something like date_select, which is just one of many Action View Helpers built into Rails for us to use at our disposal. And it'll work quite nicely, allowing you to include options like start_year, end_year, order, and prompt. And in your controller, you'll just add the attribute name to your strong params, pass it along to an object and rely on mass assignment to take care of the rest. Rails will perform its standard "rails-y magic" and everything will function the way you expect it to. The world is a joyful place.

The Conflict

"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths."
-Walt Disney

You often discover issues when you get curious -- not only because you're new to coding and there's just so much that you don't know, but also because you're a programmer and programmers are usually... well... curious (and for good reasons too). So as Disney suggested, curiosity is what led me to test how Rails might handle the input of an invalid date like February 30 or 31. Because without using any JavaScript, plugins, gems or other external code, there's obviously no way to manipulate the DOM, which means no way to dynamically set the range or hide the few extra option tags based on an event (like the user selecting a month, for example). The best we can hope for is for our application to spit back an error which Rails is quite equipped to deal with.

...
...
...

Fingers crossed... and Submit!

...
...
...

...what???

No error and Disney's date of birth is now March 3rd.

The Rationale

So it appears that when Rails is given an invalid date such as February 31, it takes the additional days and just rolls it over to the next month. I couldn't figure out for the life of me why Rails would believe this is more useful than just throwing an invalid date error, which I'm sure wouldn't be too difficult to implement under the hood with a bit of sanitizing and/or validating. Perhaps once I've grown as a developer and one day decide to take a deep dive into the Rails library and source code, I'll have a better understanding and when I do I will be sure to come edit this blog. I reckon there must be circumstances where this is the desired behavior but for the time being, I'm not convinced.

The Fix

There's a number of things you could do. The way date_select works is that you get three separate key-value pairs coming through your params.



{"user"=> {
    "first_name"=>"Walt",
    "last_name"=>"Disney",
    "gender"=>"male",
    "birthdate(1i)"=>"1901",
    "birthdate(2i)"=>"2",
    "birthdate(3i)"=>"31"},
 "commit"=>"Submit",
 "controller"=>"users",
 "action"=>"create"}

But inside Rails' Active Model library is a module called Multiparameter Attribute Assignment and it's responsible for doing just that.

Instantiates objects for all attribute classes that needs more than one constructor parameter. This is done by calling new on the column type or aggregation type (through composed_of) object with these parameters. So having the pairs written_on(1) = "2004", written_on(2) = "6", written_on(3) = "24", will instantiate written_on (a date type) with Date.new("2004", "6", "24"). You can also specify a typecast character in the parentheses to have the parameters typecasted before they're used in the constructor. Use i for Integer and f for Float. If all the values for a given attribute are empty, the attribute will be set to nil.

Rails will take the three values (year, month, day) and reconstruct it into a Date object before persisting it to the database. This is once again Rails at its best, making our lives convenient so that we don't have to concern ourselves with correctly assigning multiparameters to an attribute. But what this also means is that, if we wanted, we could probably monkey patch the code to prevent it from carrying the extra days over. But monkey patching is often a frowned upon practice and should be avoided when possible.

Other common solutions I came across on the web mostly involved using some type of external library (various plugins and gems) or JavaScript. All very valid and possibly the obvious choice, but that's not what this blog is about. As the title suggests, I'm going to show you how I did it, the quick-and-dirty way. No gems and no JavaScript.

The answer is a simple rescue. Here's what I did:



def create
   begin
      @user = User.new(user_params)
      @user.valid?
      Date.new(user_params["birthdate(1i)"].to_i, user_params["birthdate(2i)"].to_i, user_params["birthdate(3i)"].to_i)
      if @user.save
         redirect_to @user, notice: "New user created!"
      else
         render :new
      end
   rescue ArgumentError
      @user.errors.add(:birthdate, "must be a valid date")
      @user.birthdate = nil
      render :new
   end
end

I utilize the fact that trying to instantiate a Date object with invalid dates will actually raise ArgumentError: invalid date. And when it does, I simply rescue the exception and attach an error to :birthdate before re-rendering the view.

You'll also notice that after I pass the params into a new User instance, I call @user.valid? first. This is to accumulate any other errors that the object might have after running validations on all of the other attributes like name and gender. Only then do I instantiate a Date "dummy" object and pass in the three values to check whether the date is valid.

Final Thoughts

So while what I did might not be the most elegant pattern or the most efficient method to validate dates, if you're project isn't regularly dealing with dates and you just need a quick workaround in a few places of your code, this could be the easiest (or at least a temporary) solution to reject invalid dates without breaking your code. I hope you've found this useful!

Using sessions in a stateless protocol

Steve Kim — Fri, 12 Mar 2021 22:36:37 +0000

So in building my first web application with Sinatra, I quickly realized that enabling sessions has many more use cases than just handing out cookies and signing users in and out. After all, the HTTP is a stateless protocol and that means sometimes you desperately need a way to pass arguments between different routes when it makes sense to do so. Enter, the session hash.

So you begin by enabling sessions and setting a session secret to keep our session data safe (although sessions will still work without a session secret, it's normally a good idea to use a randomly generated string of characters generally between 24 to 32 bytes long in order to help prevent malicious attacks).

Once you've done that, the most common practical use is for handling the login/logout process of a user. Once we've authenticated a user, we log that person in by creating a key inside the session hash and storing that user's ID as its value.

This is important because each time we need to check whether a person is logged in, we can simply see whether we can find that user in the database based on the user ID that's stored inside the session hash.

But just because that's what it's most commonly used for it doesn't -- or shouldn't -- limit how we use our session hash.

For instance, perhaps you need to store foreign keys and use that data when necessary to create associations where needed:

Or perhaps you need to store a message to show the user that an action was properly executed:

So you see, it doesn't really matter WHAT you store. Whatever information you need persisted between each request can be stored in the session hash and utilized accordingly. This opens up and provides numerous ways in which the application can function more flexibly even as we navigate through a stateless protocol.

Ruby CLI application: scraping, object relationships and single source of truth

Steve Kim — Mon, 26 Oct 2020 22:35:38 +0000

There’s an exciting aspect to building a CLI application, or rather the CLI in general. For the average user like myself who hasn’t a clue about the inner workings of a computer and has been confined to the comfort of GUIs, even just typing commands into the Terminal can give you the sensation of feeling like you’ve become some notorious hacker in a spy movie. And thus, to be able to successfully build an entire CLI-based application from scratch was truly a rewarding experience.

The Goal

I decided to build a very basic application for Premier League football (or soccer, in some countries) where it shows the current league standings, all the clubs in the league, and information for each individual club, and perhaps even stats for individual players (although I never got that far). It started off as a breeze. I thought I had a pretty good grasp of the concepts being dealt with, how I was going to obtain the data by scraping, and so on and so forth. To be fair, I had a great guide to follow, using a video demo that was done by my bootcamp instructor. All of it made so much sense when I was watching the demo, but as with most things in life, it’s one thing to watch someone do it and completely another to actually do it.

My first despair

Scraping consumed a bulk of my time. Not fully understanding and knowing how to effectively utilize Nokogiri methods was my downfall. I was fixated on chaining my .css selectors when later on I discovered that I could have much more easily grabbed the same data by joining ids and classes directly to tags. For instance, a line in my scraper class that grabs a piece of data like so:



.css('.tableBodyContainer.isPL').css('tr:not(.expandable)').css('.long').text

could have just as easily accomplished the same thing using:



.search('tbody.tableBodyContainer.isPL span.long').text

My second despair

I knew two important rules about building relationships when going into this project. One was that the objects will need to follow the principle of maintaining a ‘single source of truth’ when building relationships across classes and that this should be done by having the object which “belongs-to” another object be accountable for holding the relationship. And once I’ve done that, I knew I’d be expected to establish the remaining relationships only through methods. Simple enough, right? The only problem was that this seemed much easier in my head when the relationship was A -< B >- C as opposed to what I had to do which was A -< B -< C. So instead of B keeping track of both A and C, I needed to have B accountable for A and C accountable for B, then somehow build methods that will allow A to interact with C and vice versa. After building and re-building my classes over and over and hours of rubber duck debugging, I got it done.



league = League.find_or_create_by_name(league_name)
new_club = Club.new(name, league, position, matches_played, matches_won, matches_drawn, matches_lost, goals_for, goals_against, goal_diff, points)
Player.new(new_club, player_number, player_name, player_position)

My Club class was keeping track of my League class and my Player class was keeping track of my Club class.
Then I went on to build methods in my League class that could communicate with my Player class, like so:



def clubs
    Club.all.select {|club| club.league == self}
end

def players
    Player.all.select {|player| self.clubs.include?(player.club)}
End

And then finally an instance method inside my Player class to access my League class:



def league

    League.all.select {|league| league.players.include?(self)}

End

Final thoughts

There’s something I have yet to figure out and that’s a way to delay my deeper level scrapes until they're needed, instead of scraping all of my data in advance when the application first runs. The scraping simply takes way too long at the moment. Although I would ideally like to store the URL for my deeper scrapes as instance variables and then pass it into a scraper method as needed, this is proving to be a lot more difficult than I had anticipated primarily because of the way my second scrape is designed and the way my logic is currently built in the CLI class. Hopefully as I dive deeper into programming and become more skillful, I will be able to find a more elegant solution.

Taking advice from Gretzky

Steve Kim — Thu, 08 Oct 2020 18:46:58 +0000

"You miss 100% of the shots you don't take." -Wayne Gretzky

Why software engineering? Frankly, for me, the answer to that question dates back to 15 years ago. It’s 2005, I’m in my sophomore year of high school and I’ve just picked out Web Design as an elective. I choose it because it seems like an undemanding class that I can take advantage of to garner a "free A" so-to-speak. And although I don’t wish to generalize high schoolers, I would describe myself as having been a typical student. By typical I mean that I didn’t care much for studying or academics; I did those things because it was what I was supposed to do. I loved video games and basketball, I hated getting up in the morning, school was a place to hang out with friends more than for going to class, I’d grab any opportunity to be dismissed early from school, I much preferred extracurricular activities over homework, and, if anyone asked, my favorite subjects were PE and lunch. That was until I took Web Design.

It was the first time I experienced anything like it. I remember thinking, “Finally! A class that I don’t dread.” Or better yet, one that I actually found enjoyable and even looked forward to going. And while this was more than enough to pique my interest, I noticed as the year progressed that I was not only appreciating it, but I was also performing among the top of my class. And before I could even figure out why, my peers were starting to approach me for help. Granted it was only some very basic HTML and CSS, and while I’m getting very humbled at the start of my journey with Flatiron, at the time it was an encouraging moment for me. You see, I was a decent athlete and had decent grades across-the-board, but I had never been truly exceptional at anything. Yet what I was learning in that web design class just clicked with me. At times I simply couldn’t empathize with my peers who were struggling with concepts that seemed so obvious. I understood that it was like learning a new language, only difference being that this particular language made sense to me. I was comprehending it far better and more easily than most which brought me to the realization that I might have the right aptitude for code.

This was probably the beginning for me in giving programming any real thought. For the very first time I considered web development as a viable and realistic career path that I might be able pursue. The surest evidence I got was the countless hours I had willingly spent on that class. Unlike doing assignments and projects for other subjects, I was doing more than what was required of me and I was doing it while having fun. As painful and irritating as it is when your code doesn’t function how it should, I get an odd (or maybe not so odd) rush out of fixing it and getting it to work.

But somewhere along the road, life happened and I lost sight of it all. I lost sight of how much I had enjoyed coding, of how quickly time breezes by when I’m sitting in front of the computer to improve a website or figure out a bug. I lost sight of the potential I saw in myself and in a career that could have been right for me. And so here I am, many years later, using the pandemic as an excuse to finally take a stab at something I had always wondered about to see where it leads me. I’m nervous, excited, and, at times, still uncertain and doubtful, but I’m in high spirits and I’m optimistic that the industry will welcome me with open arms as long as I stay humble, positive, and dogged.