davidanthonycolucci
David++
David learns to code
45 posts
Don't wanna be here? Send us removal request.
Last Seen Blogs
ask-maleficent1959
Mistress of Evil
katybudgetbooks
Katy Reads
hwjsjsjsj-blog
Untitled
losmalqueridosdelahumanidad
Haz el chingado favor
Text
w9d5 - this is the end, my only friend tumblr, the end
And so it came to pass that the App Academy curriculum reached its conclusion (kind of). I spent the majority of the last day cleaning up some of the bandcamp-clone CSS and getting the thing working on Heroku (I hadn't pushed up for a couple days...............). I started working on a welcome page (currently the front page is just the sign-in page), but didn't have time to get it functional by the time we were to present.
There are about a million more things I want to improve with my app, and mine definitely pales in comparison to some of the incredibly impressive output of a few of my classmates, but I'm happy and proud of what I built. I really enjoyed the challenges and rewards of designing one's own application from the ground up.
http://bandcamp-clone.herokuapp.com
While there is so much I still want to improve on and add to the app, I've already gotten overwhelmingly excited with some ideas for brand new applications to build. It will be interesting to see how much time I'll actually have to devote to all of these ambitions, especially considering that the next three weeks (after which we reach the true conclusion of the App Academy curriculum) will be dominated by the job search. Regardless, the need to create cannot be suppressed.
And anyway -- think of all the time I'll have on my hands now that I won't be doing a tumblr post every day!
0 notes
Text
w9d4 - not that there's much of a divide between one day and the next these days
Todesterday (today + yesterday, used to describe when they fuse into being the same day) was spent doing some heavy view refactoring in the bandcamp-clone app, a BUNCH of CSS, and a nifty rewrite of my site header.
In the app, there are several views in which an "index" of albums is displayed. Within each list item a link is displayed (on hover) that allows the user to add or remove the album from their collection. Whether the link says "add" or "remove" is based on conditional logic in the rendering of the view that checks whether that list item album is part of the user's collection. If the contents of the collection change, the view re-renders so that the links update dynamically.
The problem with this is that EVERY list element was listening for the collection change. So, for instance, if you are looking at an index of 12 albums, and click "add" for one of them, the ENTIRE view re-renders, since it is listening for changes to the collection. This is inefficient -- there is no need to re-render any list items besides the one whose add/remove link was clicked.
I fixed this by implementing each list item as its own sub-view that listens directly to its add/remove link being clicked (instead of changes to the collection). This way, when the add/remove link is clicked, only the parent subview is rerendered, and the link text flips accordingly.
So by then it was like 1 AM.
After that, I did a bunch of CSS improvements. The site looks pretty slick now.
Somewhere in there I did a rewrite of my site header. Previously, menus of options (e.g., browse albums, browse artists) had displayed on hovering above their corresponding menu titles in the header. This has the undesirable side-effect of having the menu stay visible when a link is clicked (and only disappear when the cursor is moved outside of it). I wanted to have the menus only appear on click of the menu header, and disappear when clicking elsewhere OR if the mouse leaves. To achieve this I implemented a backbone view for the header which listens to click events and mouseleave events.
I have a long ways to go still until the application is where I originally envisioned the final product. Although the site is very basic, I am proud that a lot of attention was paid to the details in the features it does have. Although todesterday is presentation day, when the project is technically due, I plan to continue improving it.
But first I might take a day off from code. And maybe take a nap.
0 notes
Text
w9d3 - picture yourself in a boat on a river in an amazon web services S3 cloud
The majority of the day was spent getting picture uploads working for user/artist profiles and album cover art in the bandcamp-clone app. There were a few things that went into this. I leverage Amazon Web Services cloud storage to host the images, and the Paperclip ruby gem to save uploaded images to the cloud location and serve them back down when necessary. Images uploaded as user profile or artist pictures are handled entirely through rails (simple), since all of my profile-editing is handled directly through rails; ones that are uploaded for album cover-art are passed through backbone up to the server. This is a little complicated, but it's working smoothly now. I have images served down rendering at different sizes depending on the context (images displayed as part of an "index" of albums are scaled down). I'm hoping to leverage a lot of this infrastructure to support actual music file uploads.
Tomorrow the focus will be tightening up a few input validations, and then back to CSS, to polish everything up before presentation day on Friday. I'm quite a ways from what I envision as the final product, but I'm proud of what I've built so far and will continue to refine it after Friday.
0 notes
Text
w9d2 - introducing advanced technology to ADD TRACKS to ALBUMS!!
Tuesday was spent focusing on expanding the backbone components within the bandcamp clone app. As mentioned in the previous post, I decided to revamp how album indexes (i.e., lists of albums) were displayed -- these are now instated as subviews referencing the same backbone View object. Part of this undertaking also involved moving a lot of the functionality specific to artists that had previously been patched into the user model to the actual artist model within backbone.
The next major project of the day was moving album adding/modifying/releasing into backbone. The workflow is such: a user (who is an artist) creates a new album. Within this screen, there are options to add tracks to the album, save the album, release the album, or delete the album. The user may add (and remove) tracks (via a form in a backbone "new track" subview) and then save the album -- this keeps the album as unreleased, and can be edited later (change title, add more tracks). Unreleased albums are not viewable to other users/artists. Once released, an album cannot be edited.
I spent a bit of time grooming the album create/edit/release functionality to meet the user experience specifications I desired. I wanted the feature to be flexible -- the user should be able to create a new album, add tracks, and immediately release it, or create an album and come back to it later. The only outstanding issue here is the removal of tracks -- this is complicated slightly by the fact that the tracks are not actually saved to the database until the album is saved, and therefore may not yet have an ID. I am looking into finding some other way of identifying which track should be removed when the "remove" event is triggered, since this is typically achieved by adding the item's ID as a data tag on its parent HTML element. Without a unique ID generated by saving to the DB, there is no guaranteed-unique attribute available.
Once I get that working, there will be a few more backbone pieces to polish up, and then I'll resume the CSS grooming.
0 notes
Text
w9d1 - And on the seventh day, we added style
I spent the majority of the project's seventh day implementing CSS. Although CSS isn't nearly as complicated as other components (namely, backbone), it takes awhile to work through translating the desired layout to well-organized style specifications. Achieving the best and most efficient organization of cascading styles is a challenge in itself -- and one that will clearly invite refactoring as more stylized pages are integrating into the app.
Towards the end of the day I transitioned back to backbone. Since there are multiple places in the app where an "index" of albums can be viewed, it makes the most sense to implement these as albums index subviews. Connecting the dots, I realized this would require a bit of refactoring on the user and artist model sides as well. Insiders agree those efforts will turn out to be a major story of w9d2.
0 notes
Text
w8d5 - Look ma, no server requests
Friday (as well as Saturday) were devoted exclusively to the backbone buildout of my bandcamp clone app (which has yet to adopt a catchy, concise name). On Friday, I achieved backbone-based "show" pages/functionality -- all pages displaying static content have been ported to backbone. It's still pretty fascinating to me how the different pieces of the system (the server-side components and the browser-side components) fit together to minimize requests to the server.
On Saturday I set up backbone-based adding and removing of albums from a user's collection. This implementation did not turn out to be as smooth as I'd hoped. On the server side, user album collections are represented by a "join" table between users and albums. This table's records simply consist of a user id and an album id, indicating the album belongs to the user's collection. There is a rails model and controller for this as well. However, on the backbone side, I did not implement a model for a user album collection; a user's album collection is simply represented as a backbone collection of Album models (i.e. an Albums collection). This complicates the communication of additions and removals of albums from a user's collection, since the Albums collection communicates to the Albums controller on the server side, not the User Album Collections controller. To work around this without implementing a User Album Collection model on the backbone side, a bespoken ajax request is made when a user adds or removes an album. Two custom routes within rails listen for requests of these patterns and route to the User Album Collections controller appropriately. This doesn't seem overwhelmingly conventional; on the other hand, creating a User Album Collection model on the backbone side will introduce a lot of code for comparatively little functionality. I'll probably seek some second opinions.
The earlier part of the upcoming week will focus on the presentation layer (CSS/HTML) and implementing image upload functionality.
0 notes
Text
w8d4 - Still spineless after 12 hours of backbone
I spent most of Thursday trying to implement backbone in the bandcamp clone. A lot of the time was spent trying to figure out which parts of the site to "inject" backbone into. I'm trying to leave all of the authentication components (sign in / sign up) strictly to rails, but would ideally like to have nonsensitive user data handled by backbone.
One of the challenges is to have the first page that appears after login not be the backbone root page but be the user's home page. When backbone history is started, by default it "navigates" to its root route. I'd like it to navigate instead to "users/:id" (the "user show" URL). I'm working on streamlining this behavior.
0 notes
Text
w8d3 - Spineless code complete(-ish)
Today I finished up the core bandcamp-clone rails application. The application now supports artist and fan signup, album creation, track creation (both standalone and as part of an unreleased album), editing and releasing albums, profile editing, browsing albums and artists, and adding albums to one's collection. I've not yet implemented the track collection functionality, because it does not really make sense to do without backbone.
A also spent a fair amount of time putting together some unit tests for my rails models using rspec. It was a bit of a challenge getting back in the mindset of rspec syntax and ideology, but once you are, it starts flowing relatively intuitively. I left all of the associations tests as pending since I'm still undecided on the best approach for certain "has many through" associations.
I also spent a bit of time putting together a solid db seeds file so that any environments from which I pull a branch down from github can be easily brought up to speed with robust development/testing data. The seeds file needs some improving, but it was definitely a relieving "to-do" to get behind me.
Tomorrow I'm going to begin implementing backbone functionality to replace some of the clunky "redirect"-based rails usage patterns. I'll also probably be integrating the app to allow for authentication using facebook credentials.
0 notes
Text
w8d2 - this one time, I cloned bandcamp
Week 8, day 2 marked the official beginning of the class's final projects. I've chosen to clone bandcamp, a platform through which music artists can distribute music to fans, digitally or otherwise. Fans and artists can also follow one another's activity on the site. My version will include what I feel to be the core functionalities of bandcamp: fans and artists may create accounts and profiles, artists may upload releases (albums and standalone tracks), and fans may add albums and tracks to their own "collections" with their accounts. Time permitting, I'll also incorporate "follow" functionality.
The first few days of the project will be focused on setting up the rails components. Today I worked on setting up the authentication components as well as the artist and album models. On an instructor's recommendation, I've implemented a setup in which there is a single user authentication mechanism for both artists and fans -- selecting to create an artist account at signup simply populates an extra flag on the user model (indicating the user is an artist) and creates an associated artist model. This allows for DRYness of authentication components and for artist accounts to include all the features of a basic fan account.
Tomorrow I plan to finish up the core models with the track model buildout, and then move onto the "join" tables (fan album collection and fan track collection).
0 notes
Text
w8d1 - a/s/l?
Week 8 began with an introduction to node.js, a powerful, popular tool for enabling realtime two-way communication between server and client. Our task was to build a chat app through which users can log into chat rooms and post messages.
First, an HTTP server was instantiated, and then a socket.io server was overlaid upon it. the socket.io library allows for the creation of sockets on the server that can listen for events back and forth between server and client. A user navigating to the HTML front-end would enter a message in a text field and click submit; this action "emits" a message from that user's socket connection to all the other sockets. All sockets, listening for such message events, would add the message text to the HTML of the page (via jQuery) upon receipt of a message.
The next phase was to build screennames for users. This involved creating a server-side hash of socket id / screenname key-value pairs. Finally, separate chat rooms were created, so that users visiting the site could pick which room they'd like to enter.
0 notes
Text
w7d5 - I'll refactor when I'm dead
The second day of the Trello clone project was a challenging one, but as with many challenging things, it came packaged with a few valuable learning opportunities.
Perhaps the most crucial takeaway for me was the challenge of handling a large project. This project involved the most components of any we've done yet: the rails components, including models, associations, controllers, and views; the backbone components, including models, collections, the router, views, and templates; and the presentation components, which include the backbone templates and CSS files. The fact that the backbone templates overlap between two of those categories actually serves to complicate things rather than simplify.
Having so many components demands conciseness, modularity, and organization. You can always build things stream-of-conscience style in the initial build-out and plan to refactor later -- but I'm realizing that (a) refactoring disorganized code requires mental effort several orders of magnitude higher than that required to write it in an organized manner in the first place, and (b) refactoring is, generally, a loathsome pain in the ass. As such, it's critical to keep a level head while writing code in large-scale projects, and avoid "tunnelvision" when trying to solve individual problems within the overall objective. All aspects of the architecture and execution must be addressed with some degree of a macro perspective.
By the end of the day my project did not look exactly like Trello to the naked eye, and felt far from complete, but I was happy with the coherence of the back-end design. I'll probably spend some more time polishing up the front end (I have not yet implemented the drag-and-drop functionality of Trello's app but I'd like to explore that), and -- yes -- maybe even do some refactoring.
0 notes
Text
w7d4 - Trello, Goodbye
On Thursday we began our last non-final project: a clone of Trello. It's a two-day solo project. After this, we begin our final projects, which will consume the upcoming two weeks. Which is daunting and exciting and hard-to-believe and awesome.
But back to the Trello clone. At its most basic level, the site can be organized into several layers of collections of things (a user has a collection of boards, a board is a collection of lists, lists are collections of cards). This structure lends itself well to the application architecture we've learnt throughout the curriculum. In this particular project, the back-end rails API has already been provided, so our task is strictly to the build up the front-end backbone and presentation components. The project framework was also handed to us with bootstrap implemented.
Working through the build-up of backbone, a lot of things that had previously seemed foggy or magical to me became clear. For instance, I was finally forced to confront and conquer my fear of HTTP and server handling of requests/responses. One thing I've built thus far that I was pretty happy to get working is a sub-view for adding new boards/lists that dynamically adds and removes itself from the current view without completely replacing it.
Progress comes at a vacillating pace. At times I'm blowing through stuff; other times I'm banging my head on the keyboard. But overall it's great to see what's almost the final culmination of everything we've learned put to work.
0 notes
Text
w7d3 - Make your site look like every other site
Hump day project was an introduction to Bootstrap, which is essentially a set of libraries that can be plugged in to a web app project to facilitate quick setup and standardized front-end formatting. Bootstrap is also focused on accommodating screens of various sizes (i.e., different-sized devices) -- its "row and column" organization allows for smooth reorganizing of components on the page depending on the size of the window.
We built a simple site leveraging several of bootstrap's features. I found the collapsing navigation bar particularly cool -- A number of navigation options are displayed horizontally across the top nav bar, but when the width of the screen goes below a certain size, the menu options are replaced with a button that shows the options in a dropdown menu, vertically, when clicked.
Another snazzy feature was the "fixed scrollspy" nav menu. On another page containing several sections (marked off as resource locations by # fragment markers) we had a sidebar nav menu displaying each of the section titles as links to those section fragments. The links had some hover highlighting effect. If the user does not click one of the links, and instead just scrolls down the page, the link in the nav bar to the section closest to the top of their page will be highlighted as if hovered upon. The nav bar's position is also fixed, so as the user scrolls down, it appears to remain in the same corner of their browser window, effectively detached from the rest of the page content scrolling by.
Bootstrap is clearly very useful for getting sites up and running quickly and for standardizing site design. I feel personally disinclined from using it, since I like the challenges and freedom of making one's own design decisions. That's easy to say now, of course....
0 notes
Text
w7d2 - Intermittently updated news is good news
Our second backbone project was to build a simple RSS client. The user can view all subscribed feeds on the home screen of the client, and can click on a feed to view its news entries (as links to the news stories).
The project was largely similar to the prior day's -- the purpose being primarily to get backbone reps in -- with a few notable differences. In our RSS reader, we took advantage of the technique of overriding a backbone model's parse function to attach to it an associated collection (replacing the simple JSON representation of the "has many" association that's passed down from rails). In our case, we wanted a feed being requested from the server to have its child news stories ("entries") included in the response. To accomplish this, in the rails feed router, we had our show method include a feed's associated entries when it is rendered to JSON. The backbone feed model then creates a new collection (as in, an extension of Backbone.Collection) for the entries and saves it as an instance variable.
Another "trick" we implemented (tricks, to us, at this point) was to have the list of feeds on the home screen, as well as the list of entries in the view of an individual feed, dynamically rendered within the parent view and appended to the parent view's root jQuery element, rather than passing a collection to a template and having the list rendered within there. So, for example, within the feed index view's initialize function (i.e., the view responsible for generating the list of feeds on the home screen), we iterate directly through the top-level collection of feeds, instantiating a view for each item, rendering it, and appending its jQuery element (an <li>) to the feed index's own root jQuery element (a <ul>).
I applaud anyone who understands the two paragraphs I just wrote.
Anyway, it was fun to build this RSS reader, albeit a challenge. Backbone is beginning to sink in, though, and I'm hoping to be able to build backbone setups intuitively from memory ANY DAY NOW (at worst, by Monday, since that's when we'll be tested on it).
0 notes
Text
w7d1 - Javascript, meet Backbone, your new home
The second half of the App Academy curriculum kicked off with our first Backbone project. Backbone appears to serve two key purposes: first, it adds "MVC"-style organization to what otherwise might become highly disorganized code in the browser layer; second, it provides a wrapper framework for easily incorporating ajax into an application and thereby facilitating smoother user experience.
While Backbone seems like a powerful tool, learning it will clearly be a matter of repeated practice. It differs from Rails just enough that its setup can't quite yet be induced from intuition. Perhaps more so than Rails, there's a lot of "magic" that occurs under the hood in Backbone, and piecing together how a set of code produces a certain end result takes a lot of time and -- the horror -- thinking. Later that evening, I found myself drawing flowcharts modeling the stack my coding partner and I had built during the day, in effort to better grasp exactly how all the components of the application were working together.
With more practice, Backbone will surely become more intuitive, such as all that's come before it has. Until then, I see a lot of flowcharts in my future.
0 notes
Text
w6d4 - Plug Me In
Thursday was more jQuery -- this time, we were investigating the wide world of jQuery plugins, and building a few of our own.
We started out building a plugin that can be used to organize content in tabs, hiding content in all other tabs besides the active one. This one was fairly straightforward to build -- I'm sure plenty of plugins offering the same sort of functionality are already out there -- but it was a good exercise to see how such a concept is broken down into its different components (HTML, CSS, javascript, jQuery). We were also introduced to the CSS transition property, which enables basic animation of elements on the page (though should not be confused with the actual animation property).
Next we built an image "carousel" effect: the user can scroll back and forth between images in a single viewing pane in which only the active image is viewed. When moving to a new image, the one currently in the viewing pane slides out to the right or left, and the next one slides in from the right or left (right and left correspond to "previous" and "next" anchors). This leveraged transitions as well, though was a little more complicated; my partner and I got a bit hung up trying to get the sliding in/out effect working correctly.
The last plugin was another image gallery, but this time arranged as a "gutter" of thumbnails with a single active full-sized image in the viewing pane. This also implemented a mouseover effect, so that mousing over an image temporarily moves it into the viewing pane, but does not permanently replace the image in there (only a full mouse click will permanently replace the image in the viewing pane).
Though rudimentary, these plugins could be pretty useful for image-hosting applications. I'm going to touch up the CSS and keep these on hand for potential future projects!
0 notes
Text
w6d3 - Towers of Hanoi, for the nth time
Today we built what I daresay might be our best version of Towers of Hanoi yet. And that's saying something.
The goal of the exercises today was to leverage jQuery (in conjunction with our existing toolkit of javascript, HTML, and CSS) to build interactive games accessible through a browser. Instead of using an HTML canvas, as we'd done in our Asteroids game, we would be directly manipulating HTML elements via jQuery.
jQuery is a pretty fascinating and powerful tool. I found it very intuitive to work with, though granted we've only yet scratched the surface. It reminds me of ActiveRecord in that you need to abstract your mental logic to the level of the "proprietary" objects in which it deals. First, my partner and I built a tic-tac-toe game, wherein the cells of a 3x3 grid are marked with an X or an O on mouseclick depending on whose turn it is (actually, we replaced the X/O nomenclature with our two headshots, so that cells, when clicked, flip to display either my partner's or my headshot).
The next exercise was to build our friend Towers of Hanoi. Though this is maybe the third or fourth time we've built the game, this iteration did not feel at all repetitive -- it was fun solving the challenges within the jQuery and CSS components to make the game render and behave as desired. I'm especially enjoying the graphic design aspect of stuff we're building in class, thanks to CSS recently entering the picture.
The last game to build was Snake -- you know, the one where a chain of segments moves around the screen and you try to guide it to "eating" everything except its own body. We did not finish this game but we felt good about the direction it was going, so I'll be finishing that one up independently.
Hopefully we get to build Towers of Hanoi again soon.
0 notes