betwixt code and music


Hackathon Retrospective

Real-world kinda stuff right here

Our introduction to working in teams was rooted in Agile. On Wednesday, our guest speaker to introduce our students to the concept of Waterfall versus Agile/Scrum was Sabina Winters from here in Austin, TX. We learned all about user stories and sprints and always talking to your scrum master and how Waterfall doesn't make sense for software development. Scrum is a funny word, but it makes a lot of sense.

Then on Thursday we were divided into groups, told to head to lunch and come back to campus to pitch the staff on a project of our choice. Most groups were like mine: two front-end developers, a back-end developer, and a designer. My group had Ryan Y in the back, Mory F. and me in the front, and Liz S. in the design seat. Our front-end requirements mandated that we use the Backbone.js library, but only the models, collections, and a router, though we also needed to use Views for our particular functionality.

After a delicious lunch at Freebirds World Burrito on South Congress in ATX (
WHAT! You have NEVER been to FREEBIRDS?!!?!), we had settled on two different ideas that we all thought had enough features to cover our bases and still push us to make something cool and (hopefully) useful. The main idea was to design a web application that could help Austinites reserve a parking spot for their favorite local restaurants. Austin has some terrific food, and parking can be fairly difficult. This is a useful idea that would be used by many.

Turns out, git and GitHub can be a challenge. We had different repositories for back-end (Ryan all by his lonely) and front-end + design. This meant that Liz, Mory, and I had to stay on top of "who is doing what" for much of our time together. Thankfully, our campus director
Travis Swicegood literally wrote two books about using GitHub, so we leaned mightily on his knowledge and experience on Friday when getting started on repository work. (He also helped me set up some bash-it themes on my machine which always show me the current git repository and its status!)

A portion of the challenge of working with two front-end developers was how to divvy up the work between us. I started to work on our main.js file while Mory started getting the models and collections put together. As we began to focus on one file at a time, we found it much easier to do
pair programming, with one of us helping talk the other one through coding. This has many benefits, but we found that the major ones were fewer errors (since someone was helping catch misspelled words and punctuation) and we could push our files to GitHub on one computer at a time. An added, non-obvious benefit was watching and learning from someone else's workflow, especially the myriad keyboard shortcuts.

We could not quite cross the finish line with the features that we expected to "ship," but we learned a lot and incorporated a good deal of functionality in populating our webpage with data from the custom-built API (thanks, Ryan!). The design that Liz created and built worked like a charm. Mory and I had Liz imbed templates in the HTML, which means that she alone could work on the HTML and Sass files to her liking. That left us front-end fellas to determine how to look into the server and put that data on the webpage. We used our JavaScript, jQuery, AJAX, and Backbone skills to dig around and eventually we learned enough about Views in Backbone to make things happen.

I am exhausted, and it was a tough push to get to the finish line. However, it was worth it. Today we started using React.js (built by Facebook), and it is making a TON of sense to me. This is certainly a combination of Aaron Larner's brilliant teaching (I have worked with a lot of those...I know one when I see one!) and a natural outgrowth of working so intimately with Backbone for the last seven days.

Things are looking good for the future as these concepts being hammered into me are starting to turn into a sensical set of instructions to make these computers do what is expected. Being in Austin is GREAT...except my family is back in Dallas, where I will be looking for a job not long from now. Off to finish more React.js learning....
(do we ever finish learning, though???)

Backbone Basics

Backbone makes it easier

Our front end engineering class has brought us to the point where we know enough book information to make a desirable number of features on a website. We have learned a good deal of HTML and CSS for basic, good-looking website content. To increase the power and ease of using CSS, we learned Sass which is a pre-compiler for CSS. All of this knowledge brings us to the point where we can talk to designers and get a basic page built fairly well.

From near the beginning, we learned vanilla JavaScript in node in the terminal (or in Sublime Text, if you are fancy). Next we learned how to link the HTML/CSS into the JavaScript to provide functionality to our websites. We then learned some jQuery, a JavaScript library, to quickly target areas of a webpage for interaction. Just as soon as we were getting comfortable with mixing JavaScript and jQuery we discovered that AJAX lets us deal with a server to store information in a place other than the client's computer. This allows us to work arm-in-arm with our back-end brethren and opens us up to the world of Backbone.js.

Backbone is a library that is written in JavaScript and also incorporates jQuery and Underscore. This particular library uses the MVC architectural pattern that stands for Model-View-Controller, some of the main ingredients that make this approach attractive to many. I certainly have a freshman-level view of these concepts, but I can already see the appeal of having the page updated in a dynamic way. The main basic idea of the Backbone (or another MVC framework) approach is to have the internal use of data separated from the user's computer. Backbone code will be set up to listen for changes to the website and then will interact with the server behind the scenes to initiate and carry out those changes.

While somewhat easy to explain in those terms, the code is already sometimes becoming rather large. When the lines of code begin to pile up, it is best to step back and remember the bigger picture. We will set up a
model that will exist between the user's page and the server. This model will be our "single source of truth," as our instructor Aaron likes to say. When a change is made, the model is consulted and then it interacts with the server behind the scenes to make changes. Backbone is also smart enough to carry out changes that are needed. In other words, it will not refresh your entire profile on your social media site if you only change your picture. Backbone will just change your picture and be done.

Without a doubt, there is a long road ahead to grasp all of these concepts. Thankfully we have our
hackathon this weekend where we pair up with the design and back-end cohorts to create and implement a project of our choosing. This will be a great way to learn how to work with these other two elements of web development to realize a project. I am really excited to work with these folks!

To infinity and beyond,