Possible Mod 4 short projects

flack.markdown

Flack

Unfortunately, slack just isn't cutting it anymore as a chat service. This week we'd like you to build us an alternative. This first iteration of the application will be a simple browser-based chat application.

When accessing the application, a user should have the option to:

• Oauth with github (or maybe even no auth, just sign up with a name?)
• select from a list of existing "rooms" to enter
• Or optionally create a new room

Once inside a chat room, a user should see a standard chat interface, including:

• A list of current members in the room
• Last X messages that have been sent in this room
• A text box for typing a new message and a button to send the message

Room updating

Chat isn't very useful if it's not real time, so the rooms need to update with new messages sent from other users semi-instantly. You have some leeway about how you accomplish this, but the 2 most realistic options are:

• Long-polling from the client side
• Persistent websocket connections between client and browser

Extensions

• @-mentions
• emoji
• text/email notifs
• File uploads
• room invites

Themes??

hacker.markdown

Pivotal Hacker

Managing projects is hard. Let's see if we can make a tool to help with the process. This week we'll be building a simple project management application a là Pivotal Tracker/Trello/etc.

Upon accessing the application, a user should see a list of existing boards that have been created (maybe skip any board auth/inviting?), and have an option to create a new board. Upon selecting or creating a board, they should be taken to the familiar 4-column interface of Agile ticket states ("backlog", "current sprint", "in progress", and "done").

Users should have the option to create new tickets by providing a Title and Description. Optionally a user can assign a ticket to themself or another user.

Board UI

Users should be able to interact with the board by dragging/dropping tickets between state columns. When dropped, a ticket should have its state updated in the appropriate DB, and be moved into the appropriate column on the UI.

Backend Implementation

A tracker app like this one is a perfect example of a software pattern called a "State Machine". Simply put, state machines are a way of modeling behavior as a series of distinct application "states", through which data can move in a linear flow. This is useful because we often want certain behaviors to take place when a certain state boundary is traversed (e.g. moving from "in progress" to "done"), and state machines give us a convenient way to model this.

There are plenty of libraries in ruby that implement state-machines, but where's the fun in that? Let's build our own. For this project your server application will need to include a state machine implementation. For models that use the state machine, you should:

• Include a "state" column on the approprate table
• Define possible states, in order, using a simple "DSL", e.g. has_states [:backlog, :ready, :in_progress, :done]
• Be able to define transition events using a similar DSL, e.g. on_transition_from :in_progress, :done, :notify_requester

hyde.markdown

Hyde

Seems like everyone and their mother is writing a static-blog/site generator these days. Let's join the party! This week we'll be writing a simple static-site generator for outputting content to the web.

If you've used SSG's like Jekyll or Middleman, this application will feel familiar to you. Ultimately its purpose is to take input files in a more editable format (we'll use markdown) and turn them into rendered HTML files that can be shipped to github pages or heroku.

Functionality

The "application" will be run as an executable from a user's machine (gem or npm module). It needs to include several features:

• a "generator" to scaffold out a new site (eg hyde new my-blog)
• a "build" step which processes provided markdown files into rendered HTML templates. You'll likely want to use an existing Markdown processor for this, although if you ask nicely a module 1 student might let you use their Chisel.
• a "serve" command which boots a simple HTTP server to allow viewing the site in development.

File Locations and Path Conventions

Remember that by convention, the "root" file for a static HTML site is its index.html. This is what will be served by, for example, github pages if you ship your site to it. We'd like to also allow arbitrary path nesting based on whatever structure a user provides with their site.

So, for example, a file located in the source at:

articles/my_article.markdown

should get built as:

articles/my_article.html

and be retrievable on the server at:

my_url.com/articles/my_article.html

Serving static assets

We'd like our users to be able to include static assets like Javascripts, Stylesheets, and Images.

Extensions

• Rails-style "layouts" for extracting standard template functionality
• Partials
• CSS preprocessor (using sass or less)

kad.markdown

KAD

A good diagramming tool is useful for a variety of purposes, from wireframing apps to taking notes. Let's build a simple diagramming tool using ASCII.

This will be chiefly a client-side application for drawing simple shapes and taking notes using ASCII characters. Upon accessing the application, the user should see a "canvas" consisting of a blank grid sized for monospace characters and a "palette" of shape tools.

Drawing

Initial drawing interactions should include:

• squares
• lines
• arrows (lines with an ending < or >)
• text (choose the text tool and click a place on the canvas to start typing)

Extensions

• export to gist
• additional shapes

rebodoku.markdown

Revenge of Robodoku

Building an algorithm to solve Sudokus was a pain. So let's build a web-app that offloads that responsibility on our users! This week we'll be building a simple web UI which allows users to play Sudoku puzzles.

Upon accessing the site, the user should see a list of links to available puzzles to play (these puzzles can be hardcoded to start). When the user selects a puzzle, they should be taken to a standard 9x9 sudoku grid interface where the starting cells have already been filled in.

Playing sudoku

• The puzzle should keep track of which cell a user is currently working on by highlighting it
• A user should be able to select a new cell by clicking it
• A user should be able to fill in a cell by typing a number; non-numeric entries should be ignored
• Additionally, a user should be able to move their current focus around the board using the arrow keys
• The puzzle should include a button to "Check Puzzle". Clicking this should look at all the cells a user has filled in and highlight any incorrect ansers in red
• If a user completes a puzzle and the answers are all correct, the puzzle should flash a victory message on the screen

SQLengine.markdown

SQL Engine

Remember our old buddy Sales Engine? It just won't die. The original clients from the sales engine project have returned, this time requesting more Business Intelligence features. Our original SalesEngine was starting to push the bounds of what we could do efficiently in pure ruby, so our new implementation is going to require some updated tech.

This time around we'll implement sales engine using a database with ActiveRecord. This will allow us to offload some of that complicated business logic where it belongs -- in a relational databse. But steel yourselves, since this new implementation will require writing some SQL.

• Library/CLI only (no web ui?)
• Spec harness?
• New BI reqs?

timber-js.markdown

Timber.js

This week you'll be building a simple rich-client application using the Timber.js framework. Unfortunately, Timber.js does not exist yet, so you'll have to build that as well. The focus of this project is to start to understand some of the components that go into a front-end framework and get some practice building better abstractions using Javascript.

Components

Templating

Manual DOM manipulations with Jquery are getting old, so for Timber we'll want to use a real client-side templating framework. (Mustache/Handlebars)

-- templates stored in files? or script tags?

Repositories/DataStores

Our framework will be built on top of a server-side API, so we'll need ways of sending data back and forth between the server and client. You'll likely need one of these for each "model" your application deals with.

Repositories will need to be able to:

• fetch individual records from the server (by id)
• fetch collections of records from the server
• create new records both by persisting them locally and sending them to the server

Models

Once we fetch data from the server, we'll probaby want to layer client-side behavior on top of it beyond what is contained in the raw data itself. For this we'll want objects to represent our "models". When the repositories fetch data from the server, they should return it as a new model object, rather than a simple JS data hash.

Data Schema

For this project we'll be revisiting an old friend -- the SalesEngine schema. We'll use a simplified version of the schema containing Customers, Merchants, Invoices, InvoiceItems, and Items. (maybe we provide the API?)