OPW – Project update, aka “tenaciousness is key”

The last few weeks have presented a series of extremely trying RL (real-life) challenges to deal with outside of my coding life.  There were a few rounds of very upsetting news, on a personal level.  I had to make a move on short notice, to a remote area where (believe it or not) internet and cell reception are hard to come by.  It took a week and a half to get internet, due to various hold-ups… and since I had no cell reception either, it was very hard to get much done as there was no easy way to look up syntax or examples when I got stuck.  Other obligations are suddenly making increased demands on my time and energy, while a number of things have simultaneously gone awry which have been or will be very time-consuming to sort out.  Staying focused through the trials and upsets has taken a monumental effort at times.

In short, it’s been pretty horrendous.

I’m a determined soul, though, when I have a goal in mind, so I refuse to quit.  It’s just going to take some serious tenacity (and sleep deprivation) to see things through.  I love what I’m doing, I’m enthusiastic about this project, and I want this experience, so I’m going to give it all I’ve got.

An in-depth understanding of Git has been slow in coming, I’m afraid.  I used Subversion, once upon a time in a class far far away, so the concepts of branching and checking out code and merging aren’t new.  Much of the time, technology just kind of innately makes sense to me, and new concepts fall into place with relative ease (considering the complexity of the topic at hand, anyway).  I’ve found it inexplicably difficult, however, to wrap my head around Git.  I know what I want to do in a given situation, but figuring out how to make Git actually do it has taken an inordinately long time.  Recently, some relatively minor fixes were made, but stored on a different repository, and I couldn’t figure out how to pull the changes to my local machine.  I ultimately ended up waiting until the changes were merged into the origin.  By then, unfortunately, I was half-configured for the other repository… so it took time and some fancy dancing to get everything back to normal.  Ick.  Well, mistakes lead to more learning, even if the resulting predicaments can be frustrating at times.  This evening’s learning, however out of place it may be in the middle of this post, was how to pull the latest changes from the remote of a branch you’ve been working on. I want to post it here, now, because I may not remember to do it later:

git fetch upstream yourworkingbranch

I remember a lot more PHP than I thought I would, thankfully, and the things I’ve forgotten have come back pretty quickly.  I was about to say, “Not so for JavaScript,” but now that I think about it, I suspect that has less to do with how much I’ve forgotten and more to do with how much it has changed over the years since I first learned it.  For reference, I remember my annoyance at the time because — go ahead and laugh, this will date it for sure — it was in the midst of the Great Browser Wars, and there was an incompatible DOM for each browser.  Cross-compatibility required ugly, nasty hacks to (1) sense which browser you were dealing with, and then (2) jump through the appropriate hoops to work with that one while not breaking your script’s functionality with other browsers.  Eeeyuck.  IIRC, there were 3 main DOMs to juggle; one for the newest version of Internet Explorer, one for the next newest (because it was that different under the hood, and still in popular use), and one for Netscape.  In the end, JavaScript seemed like far more effort than it was worth for a little dynamic content, and I finally abandoned the whole thing.

Since that time, however, it seems that many new permutations/uses of JavaScript have developed.  There’s jQuery, JSON, AJAX, and node.js, to name a few.  Jonathan, the project lead and one of my internship mentors, tells me that things have improved by leaps and bounds since the days of yore.  He feels it’s important that I (re?-)learn JavaScript, and I agree.  This has now come to the forefront, as the search engine I wrote during my application process must now be integrated into the UI… and that means I’m trying to learn jQuery.

Next up on the agenda is JSON.  I’ll be working on developing a configurable Application Programming Interface (API).  Basically, what that means for this project is creating a way to pull live data feeds from a variety of sources… things like bus schedules, weather forecasts, tweets… whatever a given community may deem useful.  Since different feeds come so many different types and formats (and probably many thousands of sources), it doesn’t make sense to write a new interface (API) for each feed.  The most practical, and yet the most challenging, way to do this is to create a single API that users can configure to work with the feeds they want.  This is a task of sufficient complexity so that I don’t think anyone expects it to be complete by the end of my internship, and that’s okay.  It’s an exciting challenge, and I’ll continue to work on it as much as I can.  When you’re developing software to be released for public use, it’s really intriguing to think about.  There’s no way to know who will use it, where it will turn up, what kinds of clever uses people will come up with, or the positive impact it will have on people’s lives.  This was made abundantly clear when TidePools was used to coordinate emergency services after Superstorm Sandy.  It’s an amazing project, and I’m proud to be a part of it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s