DEV Community: Ivy Chen

AppWorks School - CloudMile Feedback Loop Project

Ivy Chen — Wed, 11 Dec 2024 22:32:38 +0000

As a part of the bootcamp program, I had the chance to work closely with the developer mentors at CloudMile for a project called Feedback Loop. It is a event feedback management tool that helps organizers keep track of participants’ feedback via form submissions. I collaborated with another classmate on this 2-week project and received guidance from our 5 mentors (Juri, Liang, Shan, Welly, Jack), which was super cool! The mentors took turns in reviewing our pull requests, gave recommendations for code quality/best practices, and encouraged me a lot throughout the collaboration!

Learnings

Here are some of the things I learned.

Database Schema

I got more familiar with working with Firebase Firestore to come up with a database schema through this first phase of the process. Through some back-and-forth discussions with our teacher and mentors, we finally got a structure down that we could work off of.

Git Flow

We used a simplified approach to git flow. The steps were as followed:

Make a develop branch from main
Pull remote develop to local develop, then make a feature branch from develop
When done, push local feature branch to remote feature branch
From remote feature branch, open a pull request to develop
PR review time!

Best Practices

Also, we got some advice on best practices for developing collaboratively.

300-500 lines for a PR
1 branch: 1 PR, 1 branch: 1 feature
Pull develop every day

I think the ratio 1: 1 makes a lot of sense. It’s focused, modular, and more maintainable. Similar to how a food stall should only sell one thing if they want to be specialized in a dish.

Reflection

Due to the time crunch (2 weeks was a little tight for this), I relied on AI a lot to debug and break down manageable tasks for me, which resulted me in having less control in the code I was writing. If I had more time on this project, I would spend more time on refactoring so then other features could be built on top of our work in the future.

Crocheting x Programming

Ivy Chen — Mon, 21 Oct 2024 05:09:34 +0000

Crocheting is a lot like programming. It requires locked-in focus when you’re first learning a pattern. Sometimes the pattern repeats, sometimes they don’t. It’s stressful when you’re first trying to decipher and replicate a pattern, but then once you get into the groove of it, it becomes like flow.

Crocheting is also precise. Every round should have a certain number of stitches, no more or less. I often found myself counting and recounting again to make sure the number is exact so it doesn’t affect the outer rounds later. Sometimes if something doesn’t seemed right when you finish a round, you have to go back to check your stitches to see where the mistake happened, which is a form of debugging in itself. Then you either untangle all the stitches up to that point and redo them, or you try to see if there’s a way you can still build on top of the mistake without it being too noticeable. But like programming, if a mistake remains unattended, it usually will end up making later steps harder to implement, though there are still workarounds. But unlike programming, everything is manual and there are no AI-assisted anything to help you speed up the process or get unstuck. Everything is analog, which is such a good breather from screen time.

Like code reviews in programming, it is a good skill to know how to read other people’s crochet patterns so you can try them yourselves or help them discover what went wrong. To para-quote what the store owner said at the workshop the other day, “once you become literate in reading crochet patterns, it becomes a whole lot easier”. Like how empowering it was to learn to code, learning to read / create crochet patterns itself was also really encouraging. It’s like gaining access to another sphere that you previously had no access to before.

AppWorks School - Week 3

Ivy Chen — Wed, 14 Aug 2024 05:23:57 +0000

As we’re about done wrapping up the e-commerce shopping website, our teacher gave us his sample code and had us study it as an examplar of how it could be done differently. I think what helped the most was seeing how he structured his folders and files, especially with the way components are broken up and how logic is seperated in index.js seperate from the JSX. He also doesn’t set unnecessary states or use useEffects when he doesn’t need to. He then gave us a set of review questions, mostly foundational JS and React concepts, and we had to use snippets of sample code to back up our answers to these review questions.

What was really hard about this last week on the project was that we had to do all the functionalities like selecting product (color, size, quantity) and adding to cart / adjusting cart items in this week. For me, it felt like a lot of functionalities squeezed into the span of 1.5 weeks, so it’s taking me a bit longer to fully complete than scheduled. Our teacher always give us feedback comments on our PRs so that takes time to fix too.

AppWorks School - Week 2

Ivy Chen — Sat, 03 Aug 2024 22:09:52 +0000

This week’s progress is definitely a bit more stalled than last week. We had to integrate react into our existing vanilla JS project and I spent some time early in the week figuring out how to do that. Then, it was diving straight into styled components and figuring out how that works that took some more getting used to. Refactoring the header and footer to styled components took some time but then once it was time to build the rest of the product details page’s layout, I got more comfortable. I think I still don’t know how to fully utilize the benefits of styled components to appreciate its design. In theory, it’s supposed to help with modularity (easier tracking of CSS with it being component-based) and dynamic styling.

We also had some government people come to visit to listen to our presentations and attended a workshop on sharing learning tips. Our company mentors came for the government event as well and we spent some time chatting afterwards, which was so nice. They’re very friendly as usual and made us feel comfortable askig questions. I’m very excited for the 2-week project Gwen and I will be doing with them.

How this past week went

What was working?

Having your own ideas for how to implement something and why is very important. Being able to explain my code to someone else (not just what but why) is a skill I want to improve on.
Writing “robust” code is important, e.g. you shouldn’t have to drastically refactor in the future if more data is pulled in.
Also learned that naming stuff like functions and variable should be self-descriptive as much as possible. This will reduce the needs for comments. But at this stage, I still prefer using comments everywhere to remind myself of what I’m doing.

Reminders to self

Rebasing is a tiresome process, even more so than programming the logic itself because mistakes are deadly. But still, you should rebase often! And, you could always make a backup branch before the rebase process in case something goes horribly wrong.
Done over perfection. Especially if you’re under a time crunch.

AppWorks School - Week 1

Ivy Chen — Fri, 26 Jul 2024 06:30:00 +0000

Top learnings 🔄 recap sessions

From design file, pay close attention to which containers are dynamic and which ones are fixed with viewport changes
An HTML structure is considered good if it can allow adding/changing elements in the future
Git merge vs rebase
- Merge shows all commit history of both branches and is ideal for collaboration
- Rebase integrate changes from the main branch into feature branch
- Don’t use rebase if you’re collaborating with other people, because you’ll accidentally change other people’s work

Git commands ⌨️

git checkout feature-branch -> git fetch origin? -> git rebase main
git checkout main -> git merge feature-branch (to see feature-branch work in main)

How this past week went 🗓️

✅ What was working? Why?

Taking the time to visualize how you want to tackle the task and break into smaller to-do’s before actually diving into code.
Console logging a lot! Especially in and outside of code blocks to see what’s actually being run. Indicate what you’re logging out too, not just the item itself.
Giving ChatGPT very specific git branching scenarios to know with confidence which git commands to give and in what order to keep things up-to-date.

🙅🏻‍♀️ What didn’t work? Why?

Just throwing your blocks of code at ChatGPT to debug without thinking about what exactly you want it to check before
Being too fixated on a bug for more than 2 hours. Stand up and go take a breath of air. It’ll help reframe your perspective once you come back.
Don’t code when you’re too tired because you’ll make stupid mistakes.

Top learnings 🔄 project

Try to think ahead early on and plan for future implementations so you won’t have to refactor your logic drastically later to make it work
Edge cases like error messages matter for a smooth user experience
Make there aren’t redundant (don’t repeat yourself) or unnecessary code
Your commits should be concise and descriptive as to what you changed/added/refactored/deleted
Learned that PR’s should have test cases for what you want the reviewer to test out on their end manually!

Reminders to self 💅🏼

Habits lead to consistency. Consistency leads to growth.

If you want to grow, then develop good habits 💪🏼
You’re here at the bootcamp for only 4 more months. Prioritize what’s important and what you want to get out of it

Links:
What’s my viewport
Postman
GitLens Chrome Extension

AppWorks School - Week 0

Ivy Chen — Sat, 20 Jul 2024 05:46:09 +0000

I’m a month into the bootcamp at Appworks School and just wrapped up my first week on a class project. I’m learning a lot and liking it so far! Our frontend instructor is really thorough with checking our work and patient with my questions.

Every morning, we start off with a 1-hour recap of what we worked on yesterday and next steps. Usually, there are guided discussion questions based around our approaches to the task the day before and we break into small groups to share. Sometimes, we’re given some things to research on our own in our free time, such as what is/how to rebase in git. Then, we’re off to work on our task for the day.

Last week, our recap sessions have primarily been focused on github workflow for collaboration and CSS approaches to unconventional design (I finally can understand why it’s empathetic to not set random pixel numbers and have wacky UI). I’m really glad that we get to experience what it’s like to “collab” using git and github so early on in the bootcamp and learn about best practices. For this class project, we’re not actually collabing with others but rather mimicking the process of collabing by making a pull request, getting our work reviewed (merging), and pulling the latest updates (including all the other students’ work) into our local repo.

A pull request is a request made to the upstream repo (original repo where you forked from) to see if you could “merge” your work into it. Merging is usually done by the person who owns and maintains the upstream repo and an action that cannot (?) be reversed.

I also learned a bit more about branches. It’s best to use branches that stem from your main and make one every time you want to work on a new feature (or experiment with something). Usually, one branch is used for one PR (?), and after the PR has been merged, you can dispose that branch. There are naming conventions for these branches, usually something like feature/what-you-work-on (eg: feature/w0-p2). From what I understand, a branch contains all the content you have in main and is like a copy, or a “snapshot” to work from. It is a good idea to frequently check which branch you’re on to make sure you’re working in the right one (git branch).

My current workflow look like this:

switch into main git checkout main, sync fork (sync your main to the newest updates from upstream), switch into main, git pull origin main (so your local main have the latest update from remote main), create and checkout new branch git checkout -b <branch-name>, start making progress, git add/git commit, git push origin <branch name>, make a PR (then back to the start).

This workflow also means that I can only start working on another PR after the last one is merged. But apparently there are some workarounds because reviewing PRs can take some time and you don’t want that to be a blocker for moving on to the next task. It is possible to make a new branch from the previous branch, but I don’t really understand how it works after that. Maybe I should look into what rebase it but I feel like it gets more complicated from there. The last thing I want it making irreversible changes.

CS50 Week 4 - Memory

Ivy Chen — Sun, 10 Mar 2024 00:54:15 +0000

To be fairly honest, this week's lecture went a little over my head. It was about bytes, pointers (which store the address of a value), and storing/freeing memory. It is good to free up memory that you're done using. The content this week felt more archaic and even after practice with the psets, I still feel uncomfortable doing it on my own.

The psets were interesting though and really practical! The first one was Volume and the task was to change the volume of a melody by 2x the speed. The second one was Filter and the goal was to make 4 different filters that you could use on images. The final one was Recover and I had to write a program to find and "recover" the JPEGS in a memory card. For this one, I practiced opening, reading, and writing to files.

I'm entering my halfway point in the course and I feel good! Excited to dive into the more modern languages and see how they approach teaching it.

Also I feel like I should start thinking what I'd want to do for my final project.

CS50 Week 3 - Algorithms and runoff

Ivy Chen — Sun, 28 Jan 2024 22:54:59 +0000

I decided to come back to CS50 after taking a break from this core course last August (I started doing CS50's Web course instead). I remembered stopping because I got stuck on this problem set problem called runoff, which was pretty difficult at the time. Coming around in 2024, I decided to give this problem another try and familiarize myself with coding in C again.

In week 3's lecture, the professor used various demonstrations to show us the difference between a couple of algorithms, like merge sort (fast), selection sort (slow), and bubble sort. I still don't remember when you would use them but I did note down which ones are fast or slow. David also went over the concept of recursion, which I interpreted as reusing a small part of a problem that we know the answer to in other similar problems. It is an "elegant" way, but not necessarily "faster".

Then comes the pset problem runoff, which I remembered I had a hard time understanding the prompt the last time around so I could barely even get started. This time, there was an accompanying walkthrough video, which broke down the different functions we needed to finish writing for us. At a glance, a runoff election is a way of deciding who the election winner is by counting the votes of first-preference candidates while eliminating the candidate with the fewest votes. I struggled with the tabular function the most because I kept on entering an infinite loop. Then the other functions were pretty quick and self-explanatory. I finally got rid of the infinite loop with the Duck's help, among other bugs as well.

I finished the runoff problem in a little under 4 hours, which was a lot of time considering people could run a marathon with this amount of time.

If you're hesitating whether or not to take CS50, I'd say that it is a bit harder than most introductory programming courses but the quality of the lectures/problem sets is spectacular.

I'll be continuing this series and updating each week's reflection as it goes.

CS50 Web - Project 2

Ivy Chen — Thu, 07 Dec 2023 02:27:30 +0000

Second project with Django down ✅ This time around, I was tasked with building an auctions site where users could create listings, close listings, add to watchlist, bid on listings, and add comments, which was definitely a handful. I was initially pretty doubtful whether or not I'd be able to complete this since I've never done a full stack project with so many functionalities before, but I did it so yay.

Working with views.py in Django has taught me the importance of separating functionalities, the more distinct the better. For example, originally I had the bidding functionality and the displaying bids both in the same function, but then after I separated them, Django got more clear on what each of them is supposed to do. One thing for one function at a time.

I also learned more about databases from Django models and what foreign key, one-to-one relationship, and many-to-many relationship means.

I'm really liking how hands-off these CS50 projects are so far. They don't tell you how to do something but give you what you need to do, which almost mimics real life.

You can check out the demo of the working app here

🚊 How to make a terminal-based metro game

Ivy Chen — Fri, 24 Nov 2023 03:40:54 +0000

I got this idea from an Instagram reel that I've seen recently where these people play a game to see which metro stop it'll take them to! I thought it'd be good practice to digitize this and make it into a terminal game. If you're not familiar with the Taipei metro system, don't worry. You can easily replicate the steps here to suit your city's metro system and make a unique one for the metro system of your choice!

🚊 Let's get into the code

First, you want to create dictionaries for each of the stations in selected metro lines. My city's MRT stations come with an associated number, but if your metro doesn't, then just assign a number to each from one direction to another. Create a dictionary for each metro line.

brown = {1: 'taipei zoo', 2: 'muhza', 3: 'wanfang community', 4: 'wanfang hospital', 5: 'xinhai', 6: 'linguang', 7: 'liuzangli', 
         8: 'technology building', 9: 'daan', 10: 'zhongxiao fuxing', 11: 'nanjing fuxing', 12: 'zhongshan junior high', 
         13: 'songshan airport', 14: 'dahzi', 15: 'jiannan road', 16: 'xihu', 17: 'gangqian', 18: 'wende', 19: 'neihu', 20: 'dahu park', 
         21: 'huzhou', 22: 'donghu', 23: 'nangang software park', 24: 'nangang exhibtion center'}

Next, it's time for getting the user's inputs. You want to get which station they're starting from and what line that station is on.

starting_station = input("Which station are you starting from? ")
color_line = input("Which color is your station on? ")

You want to convert the color_line input to a dictionary to easier access later. So...

color_dict = eval(color_line)

Then, we want to emulate a coin toss to see if it's heads or tails. If it's heads, you will go north/east from where you are. If it's tails, you will go south/west. Don't forget to import random at the beginning of the file.

coin_flip = ['heads','tails'] 
coin_flip_result = random.choice(coin_flip)

You want to do the same thing for rolling a dice too. In which you can go like this.

dice = [1, 2, 3, 4, 5, 6]
randomize_number = random.choice(dice)

Then comes the fun part, implementing the logic! I used a nested if/else conditional to make it work.


for station in color_dict: 
    if starting_station == color_dict.get(station):
        # station is the key aka number
        if coin_flip_result == 'heads':
        # increase station number 
            destination = station + randomize_number
            print(f"🪙 Your coin flip turned out to be {coin_flip_result}")
            print(f"🎲 You are going {randomize_number} stops in {heads} direction on the {color_line} line")
        elif coin_flip_result == 'tails':
        # decrease station number 
            destination = station - randomize_number
            print(f"🪙 Your coin flip turned out to be {coin_flip_result}")
            print(f"🎲 You are going {randomize_number} stops in {tails} direction on the {color_line} line")

I also used a try/exception to catch an index out of bounds error just in case you're starting at a station that's towards the end of the lines and you number from the dice exceeds what is possible.

try: 
    print(f"🥁 Your destination is {color_dict[destination]}!")

except:
    print("☹️ Try again, index out of bound")

💭 Conclusion

And that's it! Make sure to run python3 filename to run it while you're working on it! Here's the Github repo if you need a fuller look at it.

CS50 Web - Project 1

Ivy Chen — Tue, 21 Nov 2023 07:55:10 +0000

Hi from 2 months later! I finally got around to wrapping this project up, which is a clone of a simplified Wikipedia. I had loads of fun designing the baby blue-themed UI from scratch and implementing it using Django. Django was introduced in week 3's lecture and it wasn't nearly enough to make me feel comfortable building this project, which I did what I could with Googling.

There were 7 main features of this website, my favorites included creating/editing a page, randomly displaying a page, and the search functionality. I struggled the most with the search feature to make it work just right because you also had to account for if a user just typed in a substring of the actual entry page name and showed them the search results regardless of the spelling typo.

The overall features of this project reminded me of the structure you would have for a blog, which includes the usual CRUD (create, read, update, delete), except this project's criteria didn't need to have the delete function.

Overall, this project was a good challenge as it took over 15 hours (roughly) for me to complete!

Here's a demo of the finished project with timestamps.

CS50 Web - Project 0

Ivy Chen — Fri, 22 Sep 2023 07:19:01 +0000

Hello!! It has truly been a hot minute since I've written on here but I'm glad to be back. This time around, I'm taking a course called CS50 Web and I want to document my journey through it, especially the projects part. In total, there are 5 projects + a final project to be completed for this course.

I really like the format of the CS50 series because of the automatic grading system for assignments, but I was pleasantly surprised that not only is this web dev course of CS50 graded automatically, but it is also simultaneously looked over by human graders! In this first project (and probably in the upcoming projects as well), students have to record a screencast of their finished demo and give a verbal explanations with it. I thought this was really nice that they made this mandatory because it could help me with my presentation skills :)

This project was to build a clone of Google Search, Google Image Search, and Advanced Search. At first, I thought I had to use some sort of API or build a backend but it turned out that you could just rely on HTML to grab the queries of your inputs. How fascinating!

For example, to implement the "I'm feeling lucky" button, which takes you directly to the first result of your search, you just have to use this name="btnI" thing.



<input class="input" name="btnI" type="submit" value="I'm Feeling Lucky">

This project was a good way to make sure you can implement pixel-perfect HTML/CSS by inspecting the original designs using the developer tool.

Here's my demo video with timestamps.