Haseeb Writes Code.

I decided to table GivingSmart. After about a week of trudging through Catarse’s massive, sprawling codebase and its 100+ libraries, I decided that I just wasn’t getting enough done quick enough. Catarse is a production app that was developed by a team of 7+ developers. It’s the kind of thing that I’d be working on if I actually joined a company and had to be inculcated into a novel codebase.

Integrating whole new dimensions of presentation and functionality with Catarse’s massive back-end would be so onerous that this project would not take not weeks, but months to complete. Over the week, this slowly dawned on me. It was Saturday when I finally made the call and got in touch with the guys who asked me to do this.

It was tough, but they agreed with my evaluation. I decided it was time to pivot. I put GivingSmart on the shelf and set to attacking another project that I thought would be more tenable in the time I had left: making an EA charity gift cards app. The app is going to be tentatively be called “A Better Present.”

A Better Present

It’s going to be a couple of orders of magnitude simpler than GivingSmart, but that’s good. It allows me to really polish what I have and build on what I know. Catarse was an overwhelmingly involved codebase. Studying it taught me about a lot of libraries and ways to structure an app. I want to put some of that into practice with A Better Present.

The flow of the app will basically work like this:

You decide you want to purchase a charity gift card

You select a design, who you’re sending it to, and how much the card will be worth. You also choose 3 (among a list of 10-15) high-impact charities you want your recipient to select from.

You write them a message. Then you pay for the card.

You can decide whether to send them an automated e-mail at a certain time, or send/tell them the link yourself.

The link that’s generated for them will be three random normal English words (much like what http://what3words.com or http://gfycat.com do). With a 2000 word dictionary, that amounts to 8 billion unique slugs. They’ll have to enter in the first name of the sender as an extra layer of security.

The recipient then gets to play a giving game. Basically, they read about each of the charities, see pictures and stuff, and then decide how much of the money they’ll allot to each charity.

And that’s basically it! It’s essentially a giving game wrapped in a gift card. Giving games are known to be one of the most effective ways to get people to thinking deeply about the relative tradeoffs of charities, so I think it’s a really awesome way to both do some good, and be engaging tothe recipient.

I think if this thing gets some traction, it could be a very effective twist on traditional gift-giving. Getting someone a charity gift card for their birthday and letting them pick where the money goes would be, in my opinion, an awesome and unique present. It’s a beautiful gesture of affection, and at the same time it demonstrates the ideas behind effective giving.

This might be a smaller scale project than GivingSmart, but the possibility for behavioral change could be bigger if we can convince effective altruists to start doing this as a baseline behavior in their lives instead of default gift-giving. I don’t know, maybe I should be more skeptical. But I’m excited at the possibilities.

Anyway, I’m something like halfway done now, I think. Tomorrow is technically my last day at App Academy before I start teaching for the upcoming cohort. So I’ll likely continue working on this on my own for a while. But I’m okay with that. I’ll also start talking to some potential users over the next week or two and see what changes this thing might warrant. It’s exciting!

http://haseebq.com/my-first-job-job-instructor-at-app-academy/

Today we began our final projects. My final project is to build a p2p charity fundraising platform, tentatively named GivingSmart (link to my proposal & wireframes).

The site is going to be oriented toward fundraising for highly effective charities. Based on what I’ve heard from effective altruists working in this space, the current solution don’t provide the right kinds of customizability, and charge too high fees.

I was approached by a couple of EAs to try to build this for my final project. At first I wasn’t sure; it seemed like a massive undertaking, especially for someone with a dearth of experience. But I mulled it over and decided that this would provide way more value than cloning Twitter or Quora, like most final projects end up being.

That is, I could make something that people actually use. That’s pretty awesome.

Catarse

As I was planning out this project, I realized that if I wanted to build something with industry-quality security and payment-processing that could realistically be used in production, I’d need to use a framework that already had these problems solved. This led me to Catarse, an open-source crowdfunding platform that came out of Brazil, upon which catarse.me was built.

Apparently, nobody’s ever built their final project upon a framework of this magnitude before, so this will be a first in a/A history. But my project proposal was (after some back and forth) ultimately given the green light. So I’m in this now--I’m going to build this on top of Catarse.

Catarse is a sprawling platform. I mean, it shouldn’t be surprising, it’s a very successful platform in Brazil. It has a massive amount of dependencies and libraries that it uses, and a huge codebase that I’m going to need to first digest and understand before I can start building on top of it.

Day One

So day one, my only goal was really just to get Catarse running. That sounds simple, but it’s a fairly involved task given the complexity of the project. I spent most of the day messing around with Cheffiles, Vagrant, Ruby gems and versions, and a lot of wheel-spinning. But finally, to some surprise, I was able to get it both running locally and on Heroku, which you can see here.

(Holy crap that was a mess. About 6 hours of work to get just to get it deployed.)

I was also able to submit a pull request with improvements to the documentation, so the hope is that I’ll be able to substantially contribute to Catarse over the course of this project. We’ll see how it goes.

Tomorrow I’m going to begin really delving into the project and trying to translate some of the views and really understand the layouts. Just the process of familiarization with the project I expect to take several days. But I’ll keep you all updated.

Today we wrapped up our Trello projects. I got a pretty good amount done over the two days. I was able to make robust CompositeViews and get a lot of the functionality and styling that resembled Trello. The only thing that I was really missing by the end of the day was persisting reordered cards (reordered lists persist, and cards can be created, destroyed, and dragged between lists, but I hadn’t cracked persisting the card re-ordering by the time 6PM rolled around).

All-in-all though, I got a good amount of experience with jQuery UI and a lot more familiarity with Backbone. It was a good experience, and a good lead-in to my final project. I’m going to write about it tomorrow in some detail, especially since I’ll know more about my plans then.

Today we hit our last big website before final projects: a Trello clone. It was the first time we were really thrown into a massive project with little direction. In a way, that made it quite analogous to our final projects--for the first time, we were totally on our own.

It was tough debugging a lot of the issues I was facing with Trello. Backbone (and JS in general) is so finicky, and little errors bubble up into weird places like the Underscore or Backbone source code. It’s hard to always know what exactly is going wrong. Working solo and not having another pair of eyes to catch syntax errors and the like made it surprisingly tough.

I don’t know if I’m going to be able to totally finish all of the functionality by Monday (our last day of Trello), but I want to at least delve into the jQuery UI library to implement drag-and-drop functionality. Getting acquainted with jQuery’s popular libraries is going to be valuable in my final project, so I’m going to prioritize that if it comes down to a time race.

Today we covered the final and perhaps most relevant design pattern for client-side views: the Composite View. A Composite View is a view that contains different classes of subviews. By using a robust composite view design pattern, you can make--well, you can make anything, really.

Today we made a RSS-feed newsreader app called NewsReader++. We designed it as a three-pane app that has the feeds on the left side, the feed content in the middle, and an iFrame which loads any item you select on the right side, in its own window.

Once we got through the initial challenge of getting all of the views and everything set up, we set about to implementing Auth purely through a JSON API, and managed through Backbone. Turns out, this is quite difficult (and is the reason why the standard advice at AppAcademy is to implement Auth purely on the backend), But we got most of the way there and just had left to implement views, so I think once I get to my final project, it’s a pattern that I’ll come to understand fairly well.

We finally properly integrated Backbone with a fully-fledged Rails app. That means obeying the entire client-side pattern: routers, models, and views, all from scratch. We made a journaling app (which is a kind of functionality I may end up implementing in my own final project), having everything take place on a single-page through AJAX requests.

We implemented what’s known as the CollectionView pattern, which is basically having a one big view that’s a collection of subviews, which all behave similarly (or model the same type of object). It’s a way to manage your views without accidentally creating a bunch of zombie views that drain away memory 

Today we hit day 2 of Backbone, delving into views and routers. Views are the layer that directly determine what the user sees on the page, whereas the router is the mechanism that helps you navigate through the pages/filetree of a web app. 

That said, in this project we were guided through a labyrinth of anti-patterns, juggling around callbacks between views and writing spaghetti code all over the place. It was something of a mess. We did end up cleaning it up a good bit toward the end (which we promptly undid by writing out our own custom regex-based router for the hell of it), but it all helped me get a better feel for how Backbone works.

Most interestingly, today we finally started talking about final projects. Basically, starting next week, I’m going to be working on a full-fledged Rails + Backbone web app, building it from top to bottom and showing off everything I’ve learned. Chances are, I’m going to end up putting in upwards of 150 hours into this thing, so it’s going to be a beast.

I’m still working through my proposal and figuring out what the site is going to look like and what features it’ll eventually have. I’ll talk about it more soon as I hash out the details. But you’ll be hearing a lot more about it soon.

Final projects begin proper next Tuesday. Man, oh man! I’m excited.

Today we took a swipe at some Backbone.js, a client-side JavaScript framework for developing one-page-apps. The power of Backbone comes in abstracting away a lot of the work with having to bind and manage listeners on your objects, and so it lets you manipulate the DOM in an object-oriented way. There are, strictly speaking, more elegant solutions to client-side presentation (I’ve heard React described as the client-side Rails), but Backbone is kind of the grand-daddy of them all. So it’s probably a good thing that we’re starting here, as it’ll develop a deep understanding of how to build a view layer on the client-side.

Our first project to get acquainted with Backbone was to develop a Pokedex app with a simple Rails API in the backend. As of now there wasn’t anything too complex, mostly just managing models and AJAX requests, putting info in the right place, stuff like that. After finishing early I did do some cool stuff with turning fields into forms so you can dynamically edit attributes at any time (think like Facebook’s forms for editing your profile information).

So you guys didn’t actually see the first phase of my Asteroids game, but rest assured, it was fairly sneeze-at-able. This second phase, not so much.

Check it out live here: http://haseeb-qureshi.github.io/Asteroids/

It’s still very basic--not really a game, more the engine of a game. Just getting the physics and shapes right took a lot of time and debugging, especially since this was my first time doing anything involving vectors or computer graphics. A lot of rusty trigonometry: sins, arctangents, rotation matrices? Boy, oh boy.

Still to-do (hopefully sometime this week if I can sneak in the time, but unlikely):

Implement points and a proper level system (with increasing difficulty)

Lives system

Title screen

Bind keyup listeners upon keydown (that way I can set concurrent timers to fire events, which allows you to hold down multiple buttons simultaneously)

Add a powerup? Extra lives?

Add particles for ship thrusters

Add explosions upon asteroid impact

Okay, finally as promised, was able to get my (super basic) games live on GitHub. I added a little flair and fixed a couple of bugs I was able to find, but everything is pretty basic. It’s all done in (mostly) jQuery and JS. 

Here are all my reindeer games. <==

Today we built some jQuery plugins! You can actually see them! Look at this Thumbnail plugin! I made that! It was harder than it looks!

Now look at this zooming plugin! This one was even harder! Isn’t that cool?!

Don’t look at the other ones! They are not very good! You will not be impressed! 

jQuery plugins are hard because you need perfect orchestration between the HTML, CSS, and JavaScript for everything to work right! It’s often tough to figure out what’s screwing you up!

The other thing about jQuery is that it’s just so exciting! You can’t help but exclaim it from the rooftops!

I’m so tired! 

I’m going to sleep now!

Today was our first day getting into jQuery. $ never looked so good, am I right?

We spent the day working on getting three games up and running, dynamically interacting with the DOM: Tic-Tac-Toe, Towers of Hanoi, and Snake. Unfortunately with Snake we were only able to get an ASCII version up and didn’t have time to convert it into a colorful visual display, but we did get all three running and bug-free by the end of the day!

I’m going to try to get these live on Github pages by this weekend so you guys can take a look for yourself, but they’re all totally playable.

The games themselves weren’t too bad to implement. It was Snake that was the toughest, I think because we made a few mistakes in architecture, specifically in separation of concerns. I think we would’ve benefited from a central structure that kept track of the apples, the snake, and the overall grid, but by the time we’d implemented the game logic, we had that knowledge distributed over two objects. That made our code a lot more unwieldy.

Today we dove into CSS, Cascading Style Sheets. CSS was invented around 1996, back in the cowboy days of the Internet when browsers did whatever they wanted to and every website was broken by default. In an attempt to standardize this mess, some very smart people decided to try to standardize the way browsers interpreted styling. Hence, CSS was born, and countless AngelFire fan-art pages were saved.

CSS is a finicky and fragile medium. It’s not quite as solid and straightforward as a conventional programming language; things will often break or work for seemingly no reason at all. But it’s ultimately a product of experience; the more time I spend with it, the more I come to understand its capriciousness. 

CSS is indispensable for any kind of front-end magic, and so I hope I’ll gain more mastery over it. Little things like relative vs absolute positioning, or the clearfix hack do make me a little queasy, but like anything else, I’m sure I’ll get used to it.

Today we worked on Asteroids (note: distinct from ass-steroids), using a combination of JavaScript and the HTML5 Canvas. It was an interesting project, and our first real integration of browser graphics with a back-end.

Today we tackled another day of JavaScript. We implemented TicTacToe, the Towers of Hanoi, and a generalized Towers of Hanoi solver. A few key insights about JavaScript:

This and That

You have to be careful about the this keyword inside of an anonymous function. This usually refers to the object you’re inside, but if you’re in an anonymous function within that object, this refers to the global namespace (in the browser, it would default to window). Basically the original object you were trying to do stuff to will be inaccessible and, to put it in technical terms, your program will asplode. 

To avoid asplosion (note: distinct from ass-plosion), you must assign (note: distinct from ass-sign)—assign a local variable to refer to the current object so it can be accessed within the closure of the anonymous function. The most common convention to have a line before your anonymous function: “that = this;” which tends to read a little funny. Then inside of the anonymous function, whatever you wanted to do to this, you do to that. 

Simple, right? 

(Fun fact: JavaScript was the first language invented by a high-functioning sadist.)

Arrays, enumeration, and sorting

Two fun facts I learned about arrays:

1. The array#sort method does not sort the way you’d expect it to. If you give it an array of [1, 13, 2, 26] and ask it to sort it, it will return [1, 13, 2, 26]. That is, the exact same thing. This is because it sorts by coercing each number to a string, and then comparing Unicode code point values. In other words, it sorts the way your filesystem sorts. That is, idiotically.

To get it to sort like any other programming language in the world would think to sort an array of numbers, you have to pass the method a callback that does number comparisons for you. This is a beyond stupid default behavior.

2. The built in methods for array enumeration (forEach, map, reduce, etc.) will not execute the callback you provide if the element its enumerating over is null or undefined. It will just skip that element, assuming that you weren’t smart enough to be able to handle those cases in your own goddamn data. 

Because JavaScript is, clearly, much smarter than you are.

Today was our first day of JavaScript. Holy crap. Now I understand why JavaScript is the butt of so many jokes in the developer world. 

Imagine meeting an imbecilic, drooling fool over dinner, and then coming to learn that his name is Nero and he’s the emperor of Rome. Well, learning JavaScript is a little bit like that. It’s a haplessly designed programming language; compared to Ruby it’s clunky, hysterical, verbose. And it’s also the single high-level language that can be run in every single web browser in the modern world.

Alas.

But honestly, I can’t go into it with this kind of mindset. If I want to take advantage of its tools (and wow, the JS tooling and support is amazing compared to Ruby), I have no choice to make peace with this language. And who knows, maybe I’ll come to appreciate it.

Come on. Don’t we all have that idiot friend who we keep around, but makes us look terrible at parties, whom we secretly can’t stand the sight of and barely understand anything he freaking says?

No?