The Project

This week in class all ten groups presented their browser extensions. I was pretty impressed by the creativity and technical complexity of all thr groups that presented. In the process of working on my own project my ideas of what was possible in an extension and what I was capable of with my current level of expertise expanded a lot, but seeing all the projects my classmates made expanded them yet again!

Some Specific Projects

Two projects that stood out to me were Team 5’s Quick Notes and Team 4’s Meowtivation. Quick Notes is pretty self-explanatory- it’s a lightweight notetaking extension that creates a popout window in the tab you’re in. It was impressive to me in how useful it felt- it was something that I’m actually considering downloading and using myself. Meowtivation creates a popup that displays a random cat GIF to brighten your day. How cute! I really liked the custom art they included to give their extension a bit of extra personality.

What really caught my attention about both these projects, though, is the way they integrated technology and workfrom other people. QuickNotes relied on a third-party package to render its combination of markdown and LaTeX, and Meowtivation relied on Giphy’s API to provide its GIFs. I’ve always been a bit hesitant to include packages or use APIs in my projects- I think that’s because I feel like using someone else’s complex work like that undermines the value of my creation. That is, if my project relies on another person’s work to function, then how impressive or interesting can my project really be? These projects showed me that this is not really a logical way of thinking at all. Both these groups used advanced tools developed by other people in their projects while still creating a cool, interesting, and unique final project. (Indeed, any project I make relies on a programming language- something I didn’t make. It sounds pretty silly to say that anything made in Python isn’t impressive because the creator didn’t make Python.)

This project, and especially seeing all the presentations, has inspired to explore what I’m capable of and try to contribute to more projects, and not be afraid to incorporate the work of others in my work.

The Git Exercise

In class on Monday we explored some of the basics of Git. The very basics I already knew (I had to figure them out to get this blog off the ground, actually)- making changes in the working directory, staging files, commiting, and pushing. Branches, merging, and reverting commit history, though, were pretty new to me. This is, of course, not a revolutionary thing to say, but I found branches to be a pretty powerful tool. The ability to work on new features independent of the main branch- and then seamlessly (hopefully) merge them into the main branch when done feels like it must revolutionize workflows, especially collaborative ones.

That parenthetical “hopefully” I included above is carrying a lot of weight, though. Like all complicated systems, there’s a lot that can go wrong in Git, especially when you don’t know what you’re doing. Even just in my time working on our group’s browser extension project, I ran into a lot of issues trying to get Git to do the thing I wanted, including reverting to old commits and merging branches. Luckily, though, this project is a relatively low-stakes environment for me to get my Git footing, and I learned a lot experimenting with different commands. I certainly have a ways to go until I’m a Git expert, but I have found that the best way to understand all the features Git has and their best use cases is to just dive right in and experiment with them.