Wow, it's been a while since the last post. The reason this took so long was because the Pomodoro Clock project itself took so long to complete! See here for the code in all its glory.
I did the set up so that it can eventually be refactored to submit to the freeCodeCamp's version of their project. Yes, I do like my twofers.
Overall, this thing took about 19 hrs and 35 minutes to complete. Why? Because I had to do it over and I added some options that did not work out.
The project started with the styling which was my favorite part because it was so straight forward to me. That didn't take too long, probably just a handful of hours.
Then coding up the functionality began.
I started by tracking the actual time with use of the Date() object and some help from w3schools. I went this route because it is supposed to be more accurate than just using setInterval by itself. But it was really freaking hard to get a pause and resume type functionality working with the setIntervals and clearIntervals. I was able to get it paused, but not resumed, or resumed incorrectly, or there would be some bug that affected it. It was a mess.
Eventually, I decided to just straight up use setInterval() by itself without relying on Date() to track the time. So that was about 5-6 hours wasted. It was actually so much simpler this way and I was able to get the pausing and resuming up and running very quickly!
By then, it was pretty much working as intended, but I planned from the start of the project that I wanted to use a progress bar.. or rather, a progress circle. I found a neat library aptly named ProgressBar.js which seemed to fit the bill. I got it working!... but only if you do not use the pause functionality. If you do use pause, bugs start presenting itself with the progress bar by either doubling in time or some other weird stuff. So then we have another 5-6 hours spent on trying to get it working. After some searching around, it appears that others who also wanted to use a pause functionality encountered the same problems.
To fix it was to edit the library itself and I am not quite there in terms of ability yet (especially since it also uses SVG which I only just started reading about). That and I was ready to be done with the project and move on already! So I called it a close, with a promise that I will build my own built-in progress bar.
After fiddling with the project for so long, I reasoned that it would be very simple to implement my own progress bar using JS to change the styles in CSS based on the % completed. And it was! While it is not the slickest thing in the world, it does and (generally) looks like how I envisioned it.
Sometimes, you just got to Keep it Simple, Stupid. (KISS)
And lastly, I am really pleased to finally finish the Web Development 101 section in the Odin Project!
Gee, I wonder where I got that idea for the progress circle from?
Showing posts with label DOM. Show all posts
Showing posts with label DOM. Show all posts
Thursday, August 22, 2019
Wednesday, July 31, 2019
Day 115: Etch-a-Sketch Project
So I finished my etch-a-sketch project for the Odin Project a few days ago. I meant to blog about this sooner but needed a few days away from it for a bit. More on this later...
The requirements for the project are the following:
But it wasn't quite working as intended.
When you clicked the shader button, it worked as it should, but the bug was that it became persistent and continued the shader functionality (decreasing in opacity) when you switched to any other mode as well. Clearing the grid or resizing it did not help. Nothing short of ctrl+r made it go away.
Not working as intended at all!
So I spent the next THREE days trying to figure this damn thing out. I almost got it working close to intended when I switched from using opacity to straight up changing the color values themselves (i.e. hex value of #999999 => #111111). However! There were other bugs related to the shader, where when you clicked the shader (it worked), but when you clicked it again it still worked, but now instead of going through 10 passes to get to black, it was 5 passes. If clicked shader again, it was now just 2 passes to get to black. Then 1. Other bits and bobs I tried was using the removeEventListener, forcing refresh (no, no, no), and tons of refactoring.
So with my frustrated grouchy face at home, cue the husband noticing and asking to look at my code. I grumpily told him what was wrong and after a ton of console logs, we figured it out.
I was calling the mouseover eventlistener inside a function. This function was later called from the click eventlistener.
Yeah, you're not supposed to do that! Why? Because once you call that function, it's going to have that mouseover eventListener hanging around forever (until refresh). And when you call the function again by clicking on the button again, that evenListener is going to duplicate itself! And so on and so forth.
So this is just another case of my wanting to cram in as many things at once instead of focusing on one functionality at a time.
For something like mouseover that is persistent, that function should only be called once. And you have to work around creating something that manages the various modes.
In the end, I created an actual "mode" value that defines what the mode should be based on the user click. And the drawMode() function, being called only once and is persistent changes the mode based on the user click.
Here's the old code when I thought I was nearly done. Compare that sucker to how different it is from the final code. There was a lot of refactoring done!
But I started it (after procrastinating a bit), I got the grid creator to work within minutes using CSS grid, fixed up the CSS to look the way I want it to (I am really pleased with it!). I got most of the functionality to work with ease and pretty minimal googling. Huzzah! I was on cloud 9.
Then that bug reared it's ugly head. Like I said, I suffered through it for 3 days. For comparison, the project took a total of 17 hours... 10 of which was bug fixing. Yeah... And this was the time where I'm thinking "This is the second, the SECOND project on the Odin Project. If I can't do this right, how the heck do I expect to do the rest of the projects which are harder!?" SO. DAMN. FRUSTRATING.
When I understood why it was bugging out and fixed it... it was like those 3 days were erased. Total euphoria and relief. And exhaustion. Hence why I had to take a few days away from it to decompress and let it sink in a bit.
But this is how you learn and become a better developer right? Through hours and hours of frustration and when its solved, you feel like a million bucks. I am OK with that.
![]() |
| I'm happy with how it turned out! It was a bumpy ride though... |
The requirements for the project are the following:
- Generate a grid and allow users to choose the number of cells in the grid while conforming to the original grid size.
- Allow users to clear the grid so they can draw something new.
- When the user hovers over the grid, allows them to change the colors of the cells.
- Optional: Allow users the option to select a random mode where each pass through a cell changes to a random RGB valu.
- Optional: Allow users the option to select a shader mode where each pass through a cell adds another 10% of black to it so that after 10 passes is the square completely black.
- My Extra: Allow users to have an eraser tool
- My Extra: Allow users the option to pick their own color using a color picker.
But it wasn't quite working as intended.
When you clicked the shader button, it worked as it should, but the bug was that it became persistent and continued the shader functionality (decreasing in opacity) when you switched to any other mode as well. Clearing the grid or resizing it did not help. Nothing short of ctrl+r made it go away.
Not working as intended at all!
So I spent the next THREE days trying to figure this damn thing out. I almost got it working close to intended when I switched from using opacity to straight up changing the color values themselves (i.e. hex value of #999999 => #111111). However! There were other bugs related to the shader, where when you clicked the shader (it worked), but when you clicked it again it still worked, but now instead of going through 10 passes to get to black, it was 5 passes. If clicked shader again, it was now just 2 passes to get to black. Then 1. Other bits and bobs I tried was using the removeEventListener, forcing refresh (no, no, no), and tons of refactoring.
So with my frustrated grouchy face at home, cue the husband noticing and asking to look at my code. I grumpily told him what was wrong and after a ton of console logs, we figured it out.
I was calling the mouseover eventlistener inside a function. This function was later called from the click eventlistener.
const drawShade = () => {
sketchPad.addEventListener("mouseover", e => {
e.target.style.backgroundColor = "black";
let opacity = Number(e.target.style.opacity);
if (e.target.style.opacity <= 1) {
opacity += 0.1;
e.target.style.opacity = opacity.toFixed(1);
}
});
};
const shade = document.querySelector("#shade");
shade.addEventListener("click", e => drawShade());
Yeah, you're not supposed to do that! Why? Because once you call that function, it's going to have that mouseover eventListener hanging around forever (until refresh). And when you call the function again by clicking on the button again, that evenListener is going to duplicate itself! And so on and so forth.
So this is just another case of my wanting to cram in as many things at once instead of focusing on one functionality at a time.
For something like mouseover that is persistent, that function should only be called once. And you have to work around creating something that manages the various modes.
In the end, I created an actual "mode" value that defines what the mode should be based on the user click. And the drawMode() function, being called only once and is persistent changes the mode based on the user click.
Here's the old code when I thought I was nearly done. Compare that sucker to how different it is from the final code. There was a lot of refactoring done!
Touchy Feely Stuff
Oh boy, was this project a roller coaster ride. Before I started, I was super nervous. You know the whole thing about "if I try, I might fail. If I don't try at all, I can't fail... right?" Yeah, that's why I am always nervous before starting any project. The fear of failure.But I started it (after procrastinating a bit), I got the grid creator to work within minutes using CSS grid, fixed up the CSS to look the way I want it to (I am really pleased with it!). I got most of the functionality to work with ease and pretty minimal googling. Huzzah! I was on cloud 9.
Then that bug reared it's ugly head. Like I said, I suffered through it for 3 days. For comparison, the project took a total of 17 hours... 10 of which was bug fixing. Yeah... And this was the time where I'm thinking "This is the second, the SECOND project on the Odin Project. If I can't do this right, how the heck do I expect to do the rest of the projects which are harder!?" SO. DAMN. FRUSTRATING.
When I understood why it was bugging out and fixed it... it was like those 3 days were erased. Total euphoria and relief. And exhaustion. Hence why I had to take a few days away from it to decompress and let it sink in a bit.
But this is how you learn and become a better developer right? Through hours and hours of frustration and when its solved, you feel like a million bucks. I am OK with that.
Thursday, May 23, 2019
Day 046: BUILD THE DAMN THING - A Simple MadLibs
I'm pleased to present my first project from (mostly) scratch: a simple and silly madLibs app!
It's "mostly" from scratch because I had to look up the DOM syntax and later encountered some issues with the HTML5 form inputs, namely using <input type="button"> vs <button>. I need more practice in understanding the DOM. While I understand that part of being a good coder is getting good at asking the right questions to look up stuff, but I can't wait until the day I actually know the syntax well enough to not need to reference documentation!
Here's the user story for the app:
- Allow user to input various words
- Generate random madLibs sentence
- Allow user to clear the madLibs sentence
- Allow user to clear input values
- If any input is empty, prompt user input
- Pretty up UI with some bootstrap practice
In all I spent about 2 hours on it including the Bootstrap bits. I am not including the time I spent at the end of April trying to create this. This was right after I finished up the Practical JS course and was attempting to create the madLibs in the console first (like the course) and then move it to the DOM. I set up my workspace in VSCode and got to work on the JS file. Unfortunately, I ended up just confusing myself and making it more complicating than it should be and got frustrated and gave up. You know the old adage of putting the cart before the horse? Yep.
But after watching all those videos during crunch time at work, I got a bit more confident to give it another go. Since it was simple enough, I figured starting it in Codepen was enough and it was!
I have to admit, even getting to the point where I knew I had to start building stuff scared me. I couldn't put into words why I felt the fear of starting the project, but in retrospect I think it's the sentiment of "I can't fail if I don't start!"
Once I decided to restart the project, it took a whole day to get over the fear. I was procrastinating by doing chores or watching more videos. Once I realized what I was doing, I took to repeating to myself to:
BUILD THE DAMN THING!
JUST BUILD THE DAMN THING!
And then I did and it wasn't terrible! Sure, I needed to reference some materials and some parts didn't work at first, but it in the end, it was resolved and it works more or less as I envisioned it. It even took less time than I thought it would (I had estimated 6 hours lol). I also reminded myself to take it one step at a time and that helped a lot.
Knowing how I am, I am probably going to keep having the same fear as my ideas for projects get more complex. But I just have to BUILD THE DAMN THING and just keep chugging along.
The next projects to work on is a tip calculator, day counter (so I can correctly get my #100dayofcode number), a Tabata timer, and an actual calculator. Baby steps!
The next projects to work on is a tip calculator, day counter (so I can correctly get my #100dayofcode number), a Tabata timer, and an actual calculator. Baby steps!
Labels:
100DaysOfCode,
Bootstrap,
BTDT,
Build the Damn Thing,
Codepen,
DOM,
HTML,
Javascript,
Learn in Public,
NoZeroDays,
User Story
Subscribe to:
Posts (Atom)


