const app = {
lines: document.getElementById('lines'),
textbox: createTextbox(),
lineTemplate: createLineTemplate(),
}

const socket = connect(
`ws://${location.host}/app`,
{

initial({ lines, uuid, charLimit }) {
app.uuid = uuid
app.charLimit = charLimit
lines.forEach(addLine)
},

added(line) {
addLine(line)
},

removed(i) {
app.lines.children[i].remove()
},

server.onclose = (ws) => {
if (ws.line) {
const i = lines.indexOf(ws.line)
lines.splice(i, 1)
server.sendToAll({ removed: i })
}
}

server.commands = {

begin(ws) {
const line = {
hash: ws.hash,
uuid: ws.uuid,
text: '',
}

ws.line = line
lines.push(line)
server.sendToAll({ added: line })
},

run() {
console.log(`Running on port ${this.port}`)

this.wss = new WebSocket.Server({
port: this.port,
verifyClient: this.verify.bind(this)
})

setInterval(
this.prune.bind(this),
this.pruneInterval * 1000
)

this.wss.on(
'connection',
this.connection.bind(this)
)
}

Steven Degutis

Full-stack software developer for hire

Tictactoe on Rails

October 26, 2010 — 7 years ago
Note: This article was written 7 years ago. It may refer to files or websites lost to the ages. It may advocate outdated practices. Take it with a grain of salt.

Yesterday I was tasked with implementing a Rails front-end onto my Tic-Tac-Toe library. At first I thought it would be trivial, considering how much effort I put into making sure my classes adhered to all the good coding principles and best practices I knew. But obviously things weren't that simple.

For starters, I wasn't sure exactly how to reuse my Game class. As it turned out, it wasn't really a general Game class at all, but rather a ConsoleGame class with only one appropriate environment. Trying to tack a Rails front-end onto it proved impossible, so I either had to generalize it out into a subclass, or pull it apart piece by piece until it was no longer a class at all.

It's kind of funny how, even though I tried very diligently to make sure my original code could have different front-ends or different back-ends, there were some obvious rough-spots that I only found after actually trying to add a different, non-console-based front-end to it.

This was the first time that I successfully "spiked" a solution too. I wasn't sure how the Rails controller would look. So I wrote just enough code to show me how the controller would basically function, moved the code to pseudo-code in a temporary file, and deleted the actual code. Then, I was able to tweak the pseudo-code until it appeared to make logical sense, at which point I began to actually implement the controller.

At first I was worried that writing a spike would feel like a waste of time/energy, but it actually felt right. I used it just enough to work out the details of the solution and resolve any unknowns, and once I knew what details would be used, I felt confident in my ability to test-drive the pseudo-implemented API into existence.

Finally by the end of yesterday, I had spec'd and written out my whole GameController in Rails, and all tests passed!

So this morning, I began to work on spec'ing the views and test-driving them into fruition as well. At one point early on, I thought that was done too! And then there were a few surprises.

For one thing, I was surprised that, after all my seemingly-thorough testing, my Rails app completely lacked an AI. I simply forgot to specify it in any of my tests or pseudo-code.

As Eric had suggested, had I written acceptance tests via a cucumber feature set, this probably would have been caught much earlier on, as writing such tests would have forced me to think of the app "from the outside-in." But alas, it was still my responsibility to have caught such a glaring omission, and thus it was kind of embarrassing.

Secondly, I realized that, because my classes were so coupled together, the controller's move action was awkward to write, and thus some of its corresponding tests were near-impossible to implement in a way that would drive my functionality in the right direction but also not be fragile.

Thirdly, when I tried to instantiate a Player object with the AI class inside the game#move Rails action, it became apparent that I would be forced to drop down to using the Minimax class. This is because the Player and Game classes are coupled in such a way that, when you instantiate a Game with two players, it will set each one's opponent variable to the other player instance. In reality, this "hack" was only needed so the "next-move algorithm" of the Minimax strategy-module would function properly. (It needed to know who itself was and who the opponent was.)

Even though I could (and did) work around the problem, this coupling honestly just needs to be worked out entirely. Otherwise I'll run into even further problems down the road if I ever want to put a different front-end or back-end onto the game. One problem that this is going to pose, though, is that, if I change the various APIs to work in a different (albeit better) way, not only do I need to write the new API code, but I also need to rewrite every client code that uses them, as well as every test that uses them directly. And considering this might involve a non-trivial change, it could mean up to a day just spent rewriting tests and controllers. Not pretty. I only just began the process this afternoon and already my head is starting to spin. This is good motivation to do it right the first time!

Also, my "clever" solution to keeping "player string representations" completely separate from the player and all encapsulated within the Board object may not be holding up too well. I've noticed that if you choose the 2nd position, you will be x, but if the other player (AI) chooses the 1st position next, you will be o and the AI will be x. This is a big I thought I had squashed earlier, but I think I may have inadvertently resurrected it due to my assumption when writing the Board class that a single given Board instance will continue to exist throughout the life of the game. However, in my Rails front-end, a new Board instance is created with each request. Yet another way that I had not full planned for alternative front-ends and back-ends.

As for testing views, that's still taking me a bit of getting used to. Eric's guidelines are, test only what has programming in it, ie. code inside a view that is likely to produce variable output. To me, that seems to be missing half the picture. Technically, the form tag which allows making a move in my game, is never going to change. It has no variable code. But we need to make sure it exists, so that the player can actually make a move. Otherwise the game is basically just not playable.

On the other hand, testing the view at all seems pretty fragile. Views are tricky in the sense that they have a tendency to change the most often and with the biggest changes, from my experience. That's the beauty and purpose of the view: it is user-facing, it only presents an interface to the user. Thus, it is subject to constant scrutiny from a much larger array of team members; a manager may want the page to contain an ad on the bottom, the designer may want the sidebar placed on the left of the body instead of the right, the coder may realize that the div with inner divs should actually be a ul with inner lis. These constant changes by themselves can be a large burden, but adding the fact that for every change, the tests must also be changed, well, to me that indicates a potential nightmare may be on the horizon. Honestly, I'm just not sure I feel entirely comfortable with this aspect of TDD + MVC just yet.

On an unrelated note, this project has so far also been good practice in experimenting with Haml within a Rails app; it's surprisingly straightforward: ERb is just translated to Haml, the files renamed to .haml, and then you'reall done. Granted it has a slight less flexibility than ERb does, but it's awesomely more succinct, and the few times you need that flexibility, you can just drop down to ERb and problem solved. Overall, I think using Haml has been and will from now on be a huge win.

By the way, the most up-to-date version of the live app is usually hosted on Heroku specifically for your personal entertainment.

About me

My name is Steven Degutis, and I've been writing software professionally for almost a decade. During that time, I've written many apps and websites, quite a few techical articles, and kept up-to-date with the rapidly evolving software industry.

If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at sbdegutis@gmail.com to set up a phone call.

Work Experience

  • Self-employed – present
  • Clean Coders – 5 years
  • 8th Light – 2 years
  • Big Nerd Ranch – 1 year
  • Self-employed - 1 year

Platforms

  • Web: full-stack
  • iOS (UIKit)
  • macOS (Cocoa)
  • REST APIs
  • AWS / EC2 / ELB

Languages

  • JavaScript
  • HTML5 / CSS
  • Swift
  • Objective-C
  • Clojure

Frameworks

  • Node.js
  • Express.js
  • React
  • Vue.js
  • Electron

Technical articles

Over the past decade, I've written a total of 169 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.

Subscribe via RSS / Atom.

Chronological

Portfolio

Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.

CleanCoders.com

Website - Online Video Store

I wrote this web store for Robert "Uncle Bob" Martin, using Clojure for the back-end, and JavaScript for the front-end. Over the course of 5 years, I took the site from a simple three-page website to a full enterprise-ready business solution, with nearly 100% test coverage.

  • Clojure
  • Datomic
  • jQuery / D3.js
  • JavaScript
  • ClojureScript

Docks

macOS app - Dock Utility

I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.

  • Apple.com Staff Pick
  • MacWorld 4/5 Rating
  • MacWorld Gem of the Year
  • Featured on Engadget.com

Leviathan

macOS app - Clojure IDE

Source Code

While working on CleanCoders.com, a website written completely in Clojure, I increased my productivity by building a custom IDE for macOS designed specifically for Clojure projects.

  • Objective-C
  • Clojure
  • C / C++
  • Cocoa
  • Themeable

Zephyros

macOS app - Hackable Automation

Source Code

This began as an experiment to see how many languages I could use to script a custom macOS window manager using our custom TCP protocol. Eventually it had bindings for Clojure, Ruby, Python, Go, JavaScript, CoffeeScript, Node.js, Chicken Sceme, and Racket, as well as other community additions.

  • TCP / Unix sockets
  • Custom protocol
  • Highly Scriptable
  • 10+ language bindings
  • Open source community

Bubble Maker

iOS app - Bubble simulator

This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.

  • SpirteKit
  • Custom art
  • Physics simulation
  • iOS
  • tvOS

Quick List

iOS app - Todo list app

When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.

  • In-app purchases
  • Custom UI / UX
  • Social media
  • App Store artwork
  • Spring animations

sdegutis.com

Website - Personal Portfolio

Source Code

This very site itself was written from scratch in about a day. It uses best practices for modern responsive web design, and a custom build phase to compile the sources into a single HTML file.

  • Node.js
  • Pug / Jade
  • LessCSS
  • HTML5
  • WebSockets

2048

Java app - Game

Source Code

The game 2048 (created by Gabriele Cirulli) is so fun that my kids wanted their own copy. So I wrote this version in Java 8, using JavaFx for attractive graphics and silky smooth animations.

  • Java 8
  • JavaFx
  • Modular code
  • Customizable
  • Animations

Mjolnir

macOS app - Window Manager

Source Code

I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.

  • Objective-C
  • Embedded Lua
  • Plugin system
  • Fully documented
  • 5,000 GitHub stars

AffluentConfidante.com

Website - Social Network

Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via Stripe.com) seamlessly into web apps, for a frictionless and pain-free payment experience.

  • Clojure
  • Elastic Beanstalk
  • PostgreSQL
  • Stripe.com
  • Apple Pay

HyperChat

Website - Live Chatroom

Source Code

This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.

  • JavaScript
  • WebSockets
  • Node.js
  • Vue.js
  • CSS

Bahamut

macOS app - Music Player

Source Code

As iTunes went through many user interface changes, I wanted an app that was consistent, intuitive, and easy to use. So I created Bahamut, a minimal music player for macOS with a custom user interface.

  • Objective-C
  • Custom UI
  • Cocoa
  • Core Data
  • AVFoundation

Chatter

macOS app - Chat (IRC) Client

Source Code

This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.

  • Async networking
  • Core Animation
  • Core Text
  • IRC Protocol
  • UI Design

AppGrid

macOS app - Window Manager

Source Code

This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.

  • Minimalist UI
  • Simple UI
  • Vim-like Hotkeys
  • Global Hotkeys
  • Zero-configuration

Hydra

macOS app - Lua window manager

Source Code

As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • Embedded Lua
  • Generated docs
  • Lightweight
  • Memory efficient
  • CPU efficient

Phoenix

macOS app - JavaScript window manager

Source Code

As an evolution of Zephyros, Phoenix was my attempt to use Cocoa's native JavaScript bindings to make a more lightweight and efficient window manager, that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.

  • JavaScriptCore
  • JavaScript API
  • Lightweight
  • Memory efficient
  • CPU efficient

Smaller projects

These may be tiny, but they're interesting technical feats.

Lua4SwiftSwift framework for embedding Lua with a native Swift API.
chooseCommand line fuzzy-matching tool for macOS that uses a GUI
musicCommand line music daemon for macOS that only speaks JSON
hectoCommand line text editor with an embedded Lua plugin system
ZephSharpWindow manager for Windows using Clojure for scripting
managementMinimalist EC2 configuration & deployment tool in Ruby.
go.assertAssertion helper package for writing tests in Go.
go.shattrGo library for printing shell-attributed strings to stdout.
OCDSpec2Objective-C based testing framework with Xcode integration.