When I was a kid one of my favorite things to do was play with Legos. I loved the feeling of taking the tiny, insignificant pieces and putting them together in a meaningful way in order to create something that didn’t previously exist. Of course I didn’t think of it in those terms at the time. I was more interested in building space stations, but the feeling was the same. I suppose it’s only fitting that years later I’d stumble upon the React JS framework. One of the benefits of using React is that it allows you to create small “components” — or compact pieces — and put them together in a meaningful way in order to create a feature-rich application. I’m not sure if I was taking this idea a little too far, but my original plan was to imagine the application I was hoping to create, and then jot down every single little piece of it and create those pieces individually. The idea was to create SubmitButton, FavoriteButton, Button3, FormInput, ItemInput, Checkbox1, Checkbox2, Header1, etc… By doing this I would learn about each React core component one at a time and ease the overwhelmed feeling I get when it comes to front-end design. One thing to know about me; when it comes to coding I have no issues writing, say, a useful bash tool, a small server, or something that facilitates a task. However, when it comes to creating a front-end user interface I suddenly become a tiny, panicky, prehistoric mammal; scurrying about Google like it’s the floor of an ancient forest, frantically searching for small code morsels that might sustain me for the next twelve to fifteen seconds or otherwise die of some perceived threat. So it’s no surprise that this is more or less exactly how my first days of the challenge played out.
Fortunately, it was exactly this scurrying that led me to another framework that instantaneously altered the course of my journey. Enter Material UI. Material UI is a design framework created by Google in 2014. The purpose of Material UI is to empower developers to create beautiful, responsive applications, and to give them flexibility to create whatever style, theme, or application they want. For my own purposes, it is incredibly beneficial and has allowed me to go from scratch on day one of the 100DaysOfCode challenge, to having a responsive, modern looking user interface in just weeks. Finally, the days of melting like the witch in Wizard of Oz at the thought of having to design a web page are over. More importantly, it changed my mind extremely quickly about creating tons of super tiny components that I could put together like Legos, and allowed me to just start creating without worrying too much.
One thing I don’t love when it comes to searching the internet for answers is finding countless blog posts all sharing the same solutions, and leaving out minor details that end up snagging you when you try the solution. I find myself wishing people were more apt to sharing their silly mistakes, instead of only showcasing their wins. Don’t get me wrong, I’m aware that Stack Overflow is out there, but its difficult not to start feeling inadequate when the only Youtube videos you see are people hammering out an entire working application in mere minutes. I want to see the process. How long did you google before you found your solution? Did you really type all that out for yourself or did you find a component you liked and then pasted it into your application, adding the appropriate edits to integrate it into your code? Is that even okay to do or does it make you an imposter? Do you, like me, occasionally find yourself staring blankly at your code editor like it’s in the way of the grass you’re trying to watch grow? I get it, it’s hard to admit to the world that you are imperfect. So, in the spirit of admitting mistakes I’d like to share one that I made early on. My plan when I started this journey was to record my screen as I’m coding so I could share all my live coding videos with the world, raw and unedited. Doing this would serve multiple purposes. First, by knowing that the entire internet would be able to watch me fumble around Sublime I would be forced to keep on track and not wander over to Discord or some other time-wasting task. Second, it would allow me to be able to review everything I’ve coded in case I forget how I did something. Third, and this one is important, it allows me to watch my inefficiencies play out right in front of me so I can figure out how to better improve my time usage. Not a bad idea if you ask me. What wasn’t a good idea was saving all of these 1–3 hour videos in the same git repository as my code. Now, before you go laughing at my hopeless ignorance let me explain myself. I understood that Github doesn’t like it when you try to push files larger then 100mb, and repositories allow no more then 1GB of storage, but I figured if I just added the directory to .gitignore then all would be fine. It wasn’t. Initially I had pushed the first video in my live-coding directory to Github, so it was already in the cache. Even though I had later added this directory to .gitignore, git was still tracking it. The end result was not being able to push anything to the main branch of the repository.
WARNING: git-filter-branch has a glut of gotchas generating mangled history
rewrites. Hit Ctrl-C before proceeding to abort, then use an
alternative filtering tool such as ‘git filter-repo’
(https://github.com/newren/git-filter-repo/) instead. See the
filter-branch manual page for more details; to squelch this warning,
set FILTER_BRANCH_SQUELCH_WARNING=1
Oops. This is about the time that I start frantically foraging for solutions to my issues in hope that I gather something to sustain me before the winter comes. This tasty morsel ended up saving my skin. With the guidance of Stack Overflow I ended up beating the second solution into submission by squashing the repo:
git reset — soft HEAD~7
There were a total of 8 commits on that branch so I figured I didn’t do much of anything on main (since I’m using individual day branches) and I’d just reset to the first commit.
git add .
git commit -m “fixed stuff maybe???”
git push origin main
Problem solved. I’m sure most of you aren’t clumsy enough to make this mistake, but if you are, I hope this may help you fix it.
I want to revisit this idea of copying code you’ve found on the internet and shaping it to fit your application. Don’t get me wrong, I’m not advocating for ripping off other people’s code and pasting it into your project without having an understanding of what the code is doing. In fact, one of my favorite things about writing code is that euphoric feeling you get when you finally understand something that previously seemed like an alien language to you. However, if I’m being honest, when it comes to creating a web application, sometimes I just want things to work. So when I find, say, a really great looking example of a Sign Up page that I’d like my own project to have, I don’t necessarily see anything wrong with copying the code and adding it into your own application. At least as long as you understand what you are copying. In fact, this is exactly how I learned React. I found a template that I wanted to emulate and I began researching each of the components until I knew what each of them were doing, and now if I wanted to create a component from scratch I have the ability to do that. Years ago when I first began teaching myself the PHP language I did the same thing. To be honest, I was never the best student; sitting and listening to someone give a lecture, or reading some dry textbook chapter by chapter just wasn’t the way I learned. So when it came to coding, all I wanted to do was find something to take apart and then rebuild to see if it works. So, if you’ve created a beautiful sign up page, or a really sleek looking four-step form… or perhaps a PHP web shell of some sort, I’m inclined to borrow your code and tear it to pieces.
At the time of writing this, I’m exactly at the halfway point of the 100DaysOfCode challenge. Fifty days left in the journey. When I was on the Pacific Crest Trail everyone talked about how amazing, and terrible, it felt to get to the halfway point. “Damn, I have to do that all over again?” It’s easy to feel that way. One thing I’ve learned about very long journeys is that the second half never feels the same as the first. So as easy as it is to feel overwhelmed by what lies ahead, just know that it will always be different, and better, than you can imagine.
