Horribly Underqualified

Graphql APIs

I’ve been using GraphQL for almost a year now. I’ve used it in a few small hackathon projects, along with the Stuyvesant Spectator site. I like using GraphQL because it’s rather easy to query complicated relations, especially for React components. On StuySpec it allowed us to split the fetching logic into smaller, more granular queries, which got rid of the large up front fetch that we previously had (not that you need GraphQL to solve that, you can easily use query params).

Boring Ass Classes

Let’s imagine you’re a first year physics student. You’ve never taken a physics class in your life. You’ve never even conducted a simple physics experiment in your life. The only thing you know about physics is that it’s used to make bridges and it has something to do with electricity, motion, and gravity. You like the idea of making bridges, so you decided to become a physics major. So you take your first class and you realize that your professor doesn’t know the first thing about bridges.

C Is Cool

I’ve been using C for my classes and I can’t help but be really really happy about that. I’ve played with C before. Actually C was my first language. I tried learning it as a stepping stone to Objective C and iOS development, but I quickly gave it up after getting to pointers and arrays. Granted I was like 11. After that, I played with C in various places. First I had to use C++ in an internship, where I got to play around with performance optimization and profiling.

Using Rails in 2018

I’m a huge fan of Ruby on Rails. I’ve used it for numerous hackathons and various other projects. The Stuyvesant Spectator website is built with a Rails back end and the previous iteration of this blog was my first Rails project. However, as a shameless advocate of Rails, I get to hear a lot of inaccurate ideas about Rails, such as: Isn’t Rails dead? I don’t know anybody who uses it Rails is too confusing Why should I use Rails when I can use Node?

Explaining Redux

Redux is one of those concepts that is so damn hard to explain, and even harder to understand. For me at least, React was a lot easier to understand at a high level. I mean, React at a high level is basically just objects minus inheritance plus one way data flow. Or function composition with some enclosed state if you’re into functional programming. Sure, there’s a lot more to it once you get into the nitty gritty, but really that’s all you need to know to start writing React code.

Rules of Engagement

I’ve gotten approached by a fair amount of “entrepreneurs” recently. Granted this is completely my fault; I put my name up on the NYU Entreprenurship Lab’s wall under developers. And putting all the jokes and snarky remarks aside, there’s a lot of genuine misunderstanding between these entrepreneurs and developers. I want to clear some of them up with some “rules of engagement” for developers. So let’s say you are the founder of a startup called Breakr, Tinder for break dancers.

Speed and Iteration

I’ve become interested in programming languages recently. This interest stemmed from Bob Nystrom’s wonderful book Crafting Interpreters. Reading the book, with all the wonderful diagrams and simple code snippets, has given me the idea of writing my own language. However, what kind of language should I make? Right now it feels like the programming world is bursting at the seams with new languages. Golang, Kotlin, Swift, and Rust have all appeared within the past few years.

First Post

Hi! This is my first post on the new Horribly Underqualified. I created the original version of this blog last year. However, it quickly fell out of use, partially because I found a job and partially because I couldn’t be bothered to maintain the Rails app it was built upon. For this blog I’ve decided to take another route. I’m using Hugo, a static site generator. That way I can have a blog with minimal effort, while also having it look (significantly) nicer than the previous iteration.