./appademic.rb

daily log of my experience at app academy

[appademic]

Sep. 29 - Week 9, Day 1

Over the weekend and today I made a lot of ground on my project, and it's coming together really nicely. As of now, a lot of core functionality is in place. You can search for users, follow them, favorite their submissions, and comment on submissions. Users all have a feed of people they follow, which displays an overview of images (a couple of people who have liked it, and a preview of the latest comments).

I'm really excited with the way my search bar turned out, as it supports keyboard shortcuts to navigate through the results. The shortcuts are: Ctrl+N or DOWN to navigate down the results, Ctrl+P or UP to navigate up the results, Ctrl+O or ENTER to go to the selected result, or Ctrl+C to clear the results.

Overall, I'm really happy with what I'm writing, and I've been trying to keep code clean and concise. I hope to have a basic image editor up and working by the end of tonight, and at the latest tomorrow.

A live version of the site is available at http://any-gram.com and the code is available here on github.

[appademic]

Sep. 24 - Week 8, Day 3

With authorization finished, the next thing on my list to tackle was user profiles. I decided to keep the login credentials separated from the profile information in my database design to keep tables small and logical.

I ran into a few annoying bugs that took a lot of time to figure out, but after I did it was nice to have a website that was starting to take shape.

I began my research into image processing and storage after profiles were finished, and I believe I’m most excited to implement some cool image editing features.

This will be my goal for the next few days, and I feel will be the highlight of my project.

[appademic]

Sep. 23 - Week 8, Day 2

Today marks the first day of working on my final project. The goal is to create an Instagram inspired website that uses backbone, and has an online editor that will support multiple media types.

Today was spent mostly setting up the structure, getting Heroku setup, and a simple authorization system along with beginning user profiles. Nothing too out of the ordinary or crazy today, but I’m excited with what I’ve created today and what lies ahead.

The code is over on GitHub and the current life version lives at http://any-gram.com

[appademic]

Sep. 22 - Week 8, Day 1

Wee 8. Day 1. This day marks the final day of pair programming at App Academy, and the eve of the first day of the beginning of our final projects. 

Today, we got to do some server-client interactions by making a Node application. Specifically, a realtime chat application. It was fairly simple to get up and running, and most of the time was spent implementing a feature and polishing the CSS. It was a nice little peek into what Node has to offer, and what kind of programs you can make using it. 

However, with today behind me, I am ready to tackle my final project to test myself and see what I've learned thus far.

[appademic]

Sep. 19 - Week 7, Day 5

Today I learned a very important lesson, and I learned it the hard way.

Frequent git commits when features are implemented and working are essential for allowing a developer to safely and confidently manipulate their codebase and file structure. Before doing any git operations that modify your codebase, always make sure you're latest working codebase is committed and readily available to fallback one.

Coming into today, I realized I was committing some files into my project that should have been ignored (vim's .un~ files) and I wanted to remove them. I was trying to figure out how to recursively `git rm` all files of a certain type, and was messing around with various flags and match patterns. However, I carelessly entered `git checkout -- app/assets' for whatever reason. If you are unaware of what that does, it basically resets that entire folder to the last committed version, meaning any local changes that weren't committed would be undone.

Git doesn't track local changes unless they're committed, meaning whatever I had worked on after my last commit was for naught. I quickly realized my mistake, and saw that almost all of my work had been reset to a very primitive state. This was incredibly discouraging, frustrating, and made it hard to continue working on the project. However, I decided that it could be a good thing. It would allow me to re-write parts I had planned on refactoring with a cleaner, better implementation. By the end of the day, I was caught up and then some.

Lesson learned.

[appademic]

Sep. 18 - Week 7, Day 4

Solo day today, and we got to work on a Trello clone. Our main focus was on continuing our practice of Backbone. There were two sets of instructions, terse and step-by-step. I decided to go with the terse instructions. The gist of them was essentially: "make a Trello clone."

I was surprised with how much I retained, as I have had zero Backbone experience prior to this week. I found it relatively easy to get an almost-complete Trello up the first day. The only things left were some minor refactors (more subviews!) and drag/drop ability to sort lists and cards, which was to be finished by tomorrow.

[appademic]

Sep. 17 - Week 7, Day 3

Today we put Backbone on the back-burner, so we can spend a day working with Bootstrap.

It was pretty cool to see how easy it was to turn regular, boring HTML into an interactive and responsive page by adding a few divs with special classes here and there. Bootstrap makes it easy to lay your page out quickly and precisely, too.

One thing that I found really cool with Bootstrap was modals, Modals are essentially dialogs that can popup and overlay themselves on the current page. We used this to allow a user to sign in on any page by clicking a link, which would prompt a user for their credentials.

At the end, we got to see how easy it was to change the entire look of the website. All you have to do is download a CSS file, and place it in the assets folder in your rails project. That's it!

[appademic]

Sep. 15 - Week 7, Day 1

Today was one of the first days where I felt like I didn't have a clue at the beginning of the project. BackboneJS proved to be a tougher task than I had originaly thought, but by the end of the day, I feel like I have a decent grasp of how it works. I'm pretty happy with the results of today's work, and me and my partner ended up finishing the entire task.

The project today was to create a pretty simple 'Journal App'. A user can create posts with a title and body. The first then we did was create a RESTful API using Rails to allow our BackboneJS app to communicate with our server. Once that was done, we create the standard views that listed posts, allowed us to make new ones, edit them, and even delete them. All of this was presented as a single page application using Backbone, which was pretty neat.

One of the cool things that we added towards the end was the ability to inline edit a field, simply by double clicking the element. This would cause an input element to replace the field, focus on it, and allow a user to type the new value into it. Once finished, the simply click outside of it and it's updatead, replacing the input box with the original element with the new value.

A pretty cool trick I came up with to implement this feature was to serialize the original element into the new input boxes data attributes, allowing me to deserialize and recreate the element when the time came to finish editing.

All in all, today was pretty cool, and I'm excited to learn more about Backbone.

[appademic]

Sep. 12 - Week 6, Day 5

What's a web developer's favorite cleaning product? AJAX

Bad jokes aside, AJAX is what we were learning today. We were tasked with refactoring an existing Twitter clone project to make it update the page's elements asynchronously.

The first task was to create a button to follow and unfollow a user. The goal was to create a button that would: 1) follow or unfollow a user depending on the initial follow; 2) update its text to display what it will do (or is doing). This proved to be pretty easy, and in no time we had self-updating, non-page redirecting buttons that could follow and unfollow users. All it took was a little hooking into the button's 'click' event, and sending an AJAX request and handling the response.

With a cool, new button it was time to move on to bigger and better things. It was time to take update the user search page and remove the need to click a submit button, and make it update the search results on every key-stroke. To achieve this effect, the following steps needed to be made. First, the 'input' event needed to be handled by the plugin. In side of the callback to handle the event, the value of the text field must be extracted. With the value extracted, it was time to send a request using AJAX, with the value of the text as the payload. On a successful response, a list of users would be updated to contain the search results. AJAX searching: done.

After the search and follow button were done, the feed page needed to be modified. We had to paginate the list of tweets visible, that way a user could load as many (or as little) as they wanted. This was accomplished by hooking into the click event on an anchor tag, and then sending a request to get a certain number of tweets. Then, before requesting more tweets, the last tweet had to be tracked to ensure we don't retreive duplicates.

Finally, making it so we could post a tweet from the page without having a redirect. This was fairly simple, as all you had to do was hook the form button event, and then create a new tweet, and add it to the existing feed.

This was definitely a fun exercise and a lot was learned about how to make a webpage more user-friendly by taking advatnage of jQuery and it's ability to enhance HTML tags.

[appademic]

Sep. 11 - Week 6, Day 4

Ever wondered how a website allows you to hover over an image and display a zoomed in box beside it? Or how websites allow for smooth slideshows? Well, that's what we learned how to do today, and it was pretty cool to see ways to transform our HTML.

We started out writing a simple tab system. There were multiple links, and when you click one, it would change the content of the tab, fading between the previous content and the new content. Pretty simple to accomplish, but still cool.

After that, we create an image carousel--click an arrow to the left or right to browse through images, kind of like Facebook or a slideshow. This proved to be a little harder than the previous, with some cleverness required to make sure the images transistioned smoothly, and looked nice.

The next thing to do today ws a plugin for a thumbnail system. The idea was that there were 5 visible thumbnails, and 1 visible actual sized image. Clicking a thumbnail would change the active image, and you could navigate the thumbnail display to different thumbnails. This part proved to be a little trickier than thought, and took some debugging to solve. The core concept that was used to solve the problem was that we needed to store the current thumbnail and active image index, along with the offset to the thumbnail position. The end result was a nice looking image carousel, which we tested using album covers.

Finally, the last task was the zoomable image plugin. This one proved to be a difficult with various things interferring With displaying the focus target box, for example. A lot of time was spent trying to debug it, but at the end of the day, it was finished.

Overall, I'm pretty impressed with the power of jQuery and the relative ease of adding functionality to objects through plugins.

[appademic]

Sep. 10 - Week 6, Day 3

Yesterday's CSS practice proved to be very useful for today's projects. Today we were using jQuery to create games that we've already made in Ruby for the command line.

We started with Tic Tac Toe, and the CSS and HTML structure was obvious. 3 rows, with 3 cells a piece. Once we had that up, we just had to connect the game core logic and model with our game widget, and add a few CSS classes. This is what the end result looked like:

One cool feature that I was proud of was the 'ghost' placement to highlight where your mark would be placed.

The next game we worked on was Towers of Hanoi. I spent most of my time making sure that the number of discs and their sizes weren't static. This allowed for me to set up games with anywhere from 3 to 1,000 discs. This is what it ended up looking like:

Here you can see that the selected disc to be moved is highlighted red.

Overall, I'm happy with the code and progress I made today.

[appademic]

Sep. 9 - Week 6, Day 2

Today reminded me of SQL day, just a little lighter in material. We were tasked with writing CSS all day.

We began by looking at an image of a website, and then recreating it in HTML/CSS. It proved to be a great way to learn more about CSS. As the day progressed, my HTML was becoming cleaner and my CSS followed suit.

By the end of the day I felt my knowledge of CSS was much improved, and I can’t wait to apply it to future (and perhaps previous) projects.

[appademic]

Sep. 8 - Week 6, Day 1

Today was probably the most rewarding day, as we were making yet another game. This time, however, we were using HTML5's <canvas> element and JavaScript to do our rendering. It's much more satisfying working on something that you can see results for quickly and at the end of it, actually play and use.

We learned a lot about implementing inheritance in JavaScript and name spacing our classes. Whenever learning inheritance, games are a great way to get the hang of it, because the classes in a game are fairly obvious (for the most part.)

Me and my partner finished pretty quickly today, leaving us some free time to do any changes we wanted to it. We decided to implement game states to allow an easy way to create a Menu and Game Over screen. Once we finished. We worked on cleaning up the actual code (proper spacing, minor refactors) and ended up with a really nice code base I feel.

A few things I wish I had time to implement today are better movement, asteroids splitting into smaller asteroids, particle effects, and mouse input.

[appademic]

Sep. 5 - Week 5, Day 5

Today we focused a lot on learning about callbacks and bindings. I've worked and implemented them before in C++ and C#, so I had a fairly easy time picking up the syntax for them in JavaScript.

The basic gist is that you have a function that takes in another function as an arguement, and will call it when it needs to. It's helpful when programming things that need to be asynchronous, as you can tell a functon to do something, and then whenever it finishes it, it can call some other function to work with the results of that function.

One easy, basic example of this usage was using 'readline' in our game projects today. If you don't close a readline interface when you're done, your program will enter a state where it's constantly reading in input. How do you ensure that you close it at the end of your game? There's a few ways you can do this, but this is how it's done with callbacks:

var game = new Game(); game.play(function (winner) { console.log(winner + " wins!"); reader.close(); });

As you can see, it's pretty basic and easy to grasp. The game's 'play' method takes in a callback that will get executed when the win condition has been met, and it will call it while passing the winner.

A cool piece of code that I wrote today (in my opinion) was a method to render the Towers of Hanoi game board using console output.

HanoiGame.prototype.print = function() { var buffer = "\n"; var maxHeight = 3; for (var height = maxHeight; height > 0; --height) { var lineBuffer = []; for (var stack = 0; stack < 3; ++stack) { var stackHeight = this.stacks[stack].length; var disc = 0; if (stackHeight >= height) { var disc = this.stacks[stack][height - 1]; } lineBuffer.push(this.formattedDiscString(disc, 3)); } buffer += lineBuffer.join(' | '); buffer += '\n'; } console.log(buffer); }; HanoiGame.prototype.formattedDiscString = function (disc, max) { var padAmount = max - disc; var padString = new Array(padAmount + 1).join(' '); var discString = new Array(disc + 1).join('##'); return padString + discString + padString; };

[appademic]

Sep. 3 - Week 5, Day 3

Today was a continuation from yesterday. Another solo day to finish up RailsLite, except I had already finished it yesterday. I hadn't finished the bonuses yesterday, and today I wasn't inspired to do them either. 

After reflecting on the structure of this project a few things come to mind:

The way it's set up doesn't actually make me feel like I'm writing RailsLite on my own, but rather filling in the missing pieces.

I don't feel like I'm learning or making any important decisions with regards to the structure of the code, and it doesn't challenge me to figure out how to solve the problem.

Splitting up the classes (e.g. Controller) into 6 different files that each inherit from the previous phase's controller doesn't allow me to picture what my Controller class looks like and does. It makes it harder to go back and finish the later phases.

In addition to having classes split into multiple files, it makes it really difficult to go back and implement bonus features. Having the the 'main' task use tests to verify correctness conditioned me to just try and make it go green, rather than think about the big picture. Then, going to bonus problems with no tests to verify them makes it really difficult to think about--to the point where I'd rather just skip them. 

[appademic]

Sep. 2 - Week 5, Day 2

Today was a pretty cool day, partly because it was a solo day (which means I can use my own environment!) and partly because we wrote our own version of Rails. A Lite(TM) version, to be clear.

I think the main reason this is a great project to do is so you can truly get a grasp on what is going on under the hood of Rails, allowing you to know what you're doing. This seems to be a common theme at AppAcademy--teach the fundamentals, without abstractions, so you can deeply understand what you're doing. I love this approach, because I love knowing the inner-workings of what I'm dealing with.

I finished the project around 4 today, and tomorrow is another full day of working on it, so I wonder what that means for me.

Anyways, one little piece of code I found neat today was just a simple way to create a Hash from two arrays. I'm a big fan of Ruby's array methods, such as 'zip'. As such, I enjoy finding cases where it's appropriate to use them. On to the code!

def run(req, res)   md = req.path.match(pattern)   params = Hash[md.names.zip(md.captures)]   controller = controller_class.new(req, res, params)   controller.invoke_action(action_name) end

A few interesting things are happening here:

By using RegExp captures, we can create a 2D array simply by zipping the MatchData.names to MatchData.captures,

We can then pass this array to Hash[] and it will create a new hash, interpreting the 2D array as key-value pairs

[appademic]

Sep. 1 - Week 5, Day 1

With a full month behind us, we’re fully into Rails. Today’s task was to begin using Capybara to create a Goals App using TDD.

Going into today, I wasn’t looking forward to it—the last time we wrote tests was long and tedious. Today however I found that using Capybara was much more enjoyable. Testing the behavior rather than unit makes more sense and provides a nice outline of what the program should do. Perhaps TDD isn’t so bad after all.