Static or Bustby jeff
A few weeks ago, a Carrot dev team consisting of Kyle, Tom, Josh, and myself participated in a hackathon called Static Showdown. We were particularly drawn to this hackathon since we are particularly invested in Static, which you might have known if you've had a chance to check out our code journal. We already build most of our products on a heavily static stack, so we were feeling good about the toolset going into the event.
We hung out at the office all weekend, Friday through Sunday, to put in work on a little app that we were excited about because we wanted it and wanted everyone else to be able to use it. We called our app "Rainbows," thanks to a random rainbow doodle that Kyle put up while we were wireframing, and built the design heavily around the concept of iridescence. The actual site provides an alternate and controllable interface to github, a tool for developers to collaborate on code that we use for all of our work here. It also provides a set of linters -- small utilities that check for the presence of best practices -- to check through your public projects so that you can be sure that they are up to scratch.
While we totally understand that this is a developer-y tool appealing only to developers, if you are still interested, let's dive into some of the details. First, our stack. We used a set of tools that we are fairly comfortable with. Notably:
- Roots with Jade, Stylus, and Coffeescript for the front-end
- Parse for persistence, caching, and managing users
- UserApp for handling login
- Divshot.io for hosting
In addition, we found a little vulnerability in the hackathon entry site's code that allowed us to add custom styling to the page. We took this opportunity to build out a custom entry page that fixed a couple design details we didn't like, and was themed to fit our app.
...and here's an example of a normal entry page without our custom styles.
You can read our summary on this page for more details on the app as well. Make sure not to miss the human-readable descriptions of each repo, the colors that are decided by dominant language and match loosely with those on github, our homestar-inspired error page, and the slowly changing rainbow colors throughout the site.
We also made sure to craft the linter API such that it is nice and clean, and easily extensible. So, in the future, we should be able to add in new linters quickly, and even accept linters contributed by the community.
While of course we are quite busy with work, we know that since this app was built in 48 hours, there is certainly a bit of cleaning and improvement to be made before we are ready to start publicizing it more heavily. We have all agreed that this is a tool we would like to invest in and are going to make an effort to find time to get together and work on finishing it out. Look forward to another update here once we are ready for the real launch of rainbows.io!
The team, after the 48 hours of building