4. Imagine a client...
...who has the idea of an online version of
Jeopardy.
“Participants should be able to join the game
with their smartphones, using their own devices
to ring in to score points.”
5. Ultra brief Rules of Jeopardy
●
●
●
●
●
●
3 Players, 1 Master
30 Clues: 6 Categories x 5 Levels
Player selects category & level
Master reads clue, Players ring in
Correct answers score points
Wrong or no answers cost points
● The twist: Players phrase questions
6. But, there is always a ‘but’
The client needs the App in about an hour.
Luckily, the client has a UI design team that is
capable of producing markup…
20. Our Jeopardy (some exceptions)
•
•
•
Teams (instead of single contestants)
After a wrong answer you can ring in again
No Timeout (timeout is handled by the host)
21. CoffeeScript’s Basics
•
•
•
•
translates to JavaScript
borrows syntax from Ruby & Python
semantic white space
implicit return
CoffeeScript is basically an
implementation of the best
practices desribed in the book
“JavaScript: The Good Parts”.
24. Reactor Pattern
“An Object Behavioral Pattern for
Demultiplexing and Dispatching Handles for
Synchronous Events”
Implementation in Ruby: eventmachine
•
single threaded (in our case a good thing)
32. Next Steps
•
•
•
•
Code the State Machine
Explain the State Machine
Some CoffeeScript Details
Demo the whole game
33. Jeopardy in Single Steps
•
•
•
•
•
•
A clue is selected
The clue is read
No buzz is received
Buzz is received
Answer is correct
Answer is wrong
These are all events.
35. State Machine in JavaScript
An event is a transition from one state to another.
events: [
{ name:
{ name:
{ name:
{ name:
{ name:
{ name:
{ name:
]
'start',
'clue_selected',
'clue_read',
'buzz_received',
'answer_wrong',
'answer_correct',
'no_buzz',
from: 'initialize',
to: 'select_clue' },
from: 'select_clue',
to: 'read_clue' },
from: 'read_clue',
to: 'receive_buzz' },
from: 'receive_buzz',
to: 'receive_answer' },
from: 'receive_answer', to: 'receive_buzz' },
from: 'receive_answer', to: 'select_clue' },
from: 'receive_buzz',
to: 'select_clue' }
https://github.com/jakesgordon/javascript-state-machine
37. (Ask Alain how the
coding is going.)
Next up: CoffeeScript details
38. Function Definition & String
Interpol.
faye.subscribe "/pong", (data) ->
util.log "pong received with Team #{data.team}"
faye.subscribe("/pong", function(data) {
return util.log("pong received with Team " + data.team);
});
40. List Comprehensions
team_counts = ->
counts = {a:0,b:0,c:0}
counts[v]++ for k, v of
players
counts
var team_counts;
team_counts = function() {
var counts, k, v;
counts = {a:0,b:0,c:0};
for (k in players) {
v = players[k];
counts[v]++;
}
return counts;
};
{"38":"First up: Function definitions & String Interpolation\nFunction definitions, especcially for annonymouns functions is something you need fairly often in JavaScript.\nThat is why CoffeeScript provides a handy shortcut: the arrow with paramater definition prepended.\nWhat JavaScript is entirely missing is a handy String interplation.\nThe Syntax is obviously stolen from Ruby.\n","27":"This is the chapter where I get to say anything I want. We just need the time to code.\n","16":"There are multiple patterns to make use of Rack.\nuse, map & run are important keywords.\nIf you run an app thats an endpoint, of which you can have only one.\nBut you can use multiple middlewares.\nA middleware can modify the any incoming request\nas well as outgoing response.\nIt even can short curcuit any request,\nreturning an immediate response.\nBut you can also use map to map URLs or URL patterns to multiple endpoints.\n","5":"1 game master\n3 contestants\n30 clues\ndivided in 6 categories\nand 5 levels of expertise\na contestant gets to pick a clue\nthe master reads the clue\nthe contestants ring in\nthe first contetsant to ring in gets to answer the question\ncorrect answes score points\nwrong or no answers cost points\nThe twist: The answer has to be phrased as a question.\n","33":"If try to split the game into single steps\nwe might end up with something like this.\nA clue is selected\nThe clue is read\nNo buzz is received\nBuzz is received\nThese are all events\nand events usually make good transitions in a state machine.\nWho has used a State Machine before?\nWho has never used a State Machine before?\nSo if I’d draw a diagram for the jeopardy state machine it will look like this.\n","22":"- for the communication between master and player we chose the pubsub pattern\n- the pubsub pattern is a messaging pattern where messages are send via an event bus\n- to which the publisher can send messages\n- and from which the subscriber can recieve messages\n- you can see a very simple example in this diagram\n- but usually real world applications are not that simple\n- and that’s why in our case the diagram will look more like this\n","11":"So we will need 2 components\nthe master with the game board and the clues\nand a buzzer to ring in\nSo what are we going to use for the tiny backend.\nYou saw the big Ruby in the tag cloud on the 2nd slide.\nSo naturally we’ll reach for one of Ruby’s web frame works.\n","39":"Next up: Named Fields.\nThat’s also something you come across fairly often when writing JavaScript.\nWhen your variable is identically named as the field in an object you want to create\nyou get this somewhat awkward redundancy.\nCoffeeScript again provides a handy shortcut.\n","28":"jQuery is the closest to a stdlib that JavaScript has.\njQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.\n$.getScript loads Faye client lib \nHonestly I assume we could have saved a couple of lines of code by using AngularJS.\nAngularJS has bidirectional data bindings as an alternative to direct manipulation of DOM.\nWe simply didn’t wanted to pack more magic into this presentation.\n","17":"We will be using a micture of both.\nWhat you see here is the scematics of our tiny backend.\nThis is basically a diagrammatic version of the code in the config.ru file.\n","6":"But the client needs the App in about an hour.\nLuckily the client has a UI design team\nthat is capable of producing markup\nAs you might have experienced yourselves\nthis is not allways the case.\nSo how are we going to commence this.\nThe title in the conference’s program kind of gave it away: We’ll do pair programming.\n","34":"4 states and 6 transitions\nthe plus 1 is for the state initialize, which isn’t really part of the game.\nOk, a State Machine - but why? \nwiring the logic for the game without a state machine, will simply be futile.\nIt will inevitably lead do lots of horrible, unmaintainable code.\nWe’ve all been there, don’t feel bad.\nBy thinking of it as a state machine\nyou gain a better structure.\nYou’ll easily discover edge conditions.\nAnd if you use a state machine library\nyou can make use of guards, which prevent invalid transitions,\nand you can define callbacks on transitions.\nPutting this diagram into code will probably look like this.\n","23":"- As you can see the master as well as the clients\n- act as both publishers and subscribers.\n- That’s because both need to send and recieve messages.\n- I will illustrate that by explaining how the ping/pong mechanism works in the pubsub pattern.\n- The player will ping the master by publishing a message with it’s generated unique id to the event bus.\n- The master will have subscribed to these events to receive the ping.\n- The master will then respond to the player by publishing a pong message.\n- The player will have subscribed to the events of the server to receive the pong.\n- In our case the master will use the pong to inform the player about the team he has been assigned to.\n- the implementation of the pubsub pattern we use is called faye.\n- faye is actually two implementations one in ruby and one in JavaScript for use with nodejs.\n- it makes use of the bayeux protocoll for formatting messages in JSON.\n- one nice thing about faye is that it ships its own JavaScript client library\n- which we’ll load in the browser to be able to publish and subscribe with only a couple of lines of code\n- for those who are curious: faye builds on eventmachine, which is a ruby implementation of the reactor pattern.\n","12":"I’m not much of a designer. But I made this graphic for you.\nYes we could go with Rails.\nWho knows Rails? Yes, almost everybody does.\nBut Rails is a little heavy weight on our tiny backend.\nSo we could go with something more light weight like Sinatra.\nWho knows Sinatra? Ok, some.\nBut still, we are looking for the minimal setup.\n","1":"Welcome to our talk “The Making of Geek Jeopardy”.\nMy name is Phil Hofmann\nthis my colleague Alain Lafon\nWe are working with Panter AG\na 20 heads counting consultancy based here in Zurich.\nHow do we introduce ourselves best to a tech audience like you?\n","40":"And last but not least: List Comprehension.\nSo many fine languages have list comprehensions.\nCoffeeScript brings those finally to the JavaScript eco system.\nThe suffix notation, you see in this example, is a matter of taste.\nYou can also use it in a more common prefix notation.\nBut if used carefully\nyour code gets so much more succinct.\nAnd if you get used to it,\nit’s definitly one of the things you will ask yourself\nhow programming without was even possible.\nThese were actually my finishing words.\nLet’s see if I’ve to buy us some time.\n","29":"- For those of you who know their RFCs well:\n- Yes, this is a rfc4122 version 4 compliant solution to implement generation of UUIDs.\n- Honestly this was the only opportunity we found to bring a RFC into this talk.\n- It’s not really needed.\n- We could simply replace it with a long enough random number.\n- But the code is so nice, don’t you think?\nMention Stackoverflow\n?= Existential Assignment (more or less unique to Coffee)\n? Existential Operator\n","18":"Thank you Phil and hello everyone.\nNow that we have part of the backend in place, let’s start with the frontend and something for the real time communication.\nBtw, you are seeing Phil switch workspaces right now. This is because he’s an Emacs wizzard while I prefer VIM. \nBut, we still like each other. That is actually possible^^\nSo to anyone out there who likes to engage in editor wars or any other kind of flame war: Be nice to each other. You all deserve it.\n","7":"Not like these guys.\nThey are doing it wrong, obviously.\nWe will also be doing it wrong.\nBut that’s because we’re standing in front of couple of hundred people.\nOur presentation will be held by the navigator (that’s currently me)\nwhile the code will be written by the driver (that’s currently Alain).\nSince we’re short on time, we’ve to speed things up.\nWe won’t have time to get into too much detail.\nNevertheless, this talk will require your full attention.\nI did not just have a coffee or are feeling otherwise not well prepared\nplease leave the room now.\nJust kidding, please stay. (Pretty please stay.)\nLike any good project we’ll have a lot of talking in the beginning\nand a lot of coding towards the end.\nSo I’ll rush through the first chapter and I promise we’ll slow down afterwards.\n","35":"If it looks like this you’re lucky\nsince this is the format\nthe JavaScript State Machine library by Jake Gordon expects.\nThis basically defines the transitions from one state to another.\nThe state machine will only be able to perform transitions defined here.\nAnd it will do so by calling methods on the State Machine Instance\nnamed after the names of the events.\nSo the only thing left...\n","24":"- the reactor pattern is a pattern for demultiplexing synchronous events\n- and way to complicated to explain it here in detail.\n- but rest assured there is a white paper about it\n- (for those of you who like white papers)\n- one interesting aspect of the reactor pattern is\n- that its explicitly a single threaded solution\n- which in our case is a good thing, right?\n- that way we let this beast answer the question\n- “who was the first to ring in?”\n","13":"We really only need the basics.\nSo we will directly built on Rack.\n","8":"Chapter I: Basic Setup\n","36":"…is to define the side effects of the state transitions\nas callbacks to these events.\nThese are just 2 examples.\nThe 1st one “onanswer_correct” will send a signal to the active player\nto go back into state “inactive”.\nThen it will add score points for the player’s team.\nAnd finally it will trigger to update the scores on the view.\nThe 2nd example is fired when a buzz is received.\nThis of course as its own side effects.\nThis event makes the state machine\ntranscend from the state ‘receive_buzz’ to ‘receive_answer’.\nWhenever a player hits the buzzer\nthey faye client on the master’s side\nwhich subscribed to these events\nwill trigger this transitions.\nBut the transition will only take place if\nthe state machine is in state ‘receive_buzz’.\nAnd thats when the state machine acts a guard.\n","14":"Rack is the common basis of 99% of Ruby web frameworks.\nIt’s no much more than an abstraction layer on top of HTTP request & response.\n","3":"Of course with a tag cloud\npresenting the technologies we frequently work with.\nAs you can see there is a lot of Ruby going on,\nbut also some other technologies.\nAt Panter we have awsome customers,\nbut not quite as awesome as the one I’ll introduce you to right now.\n","31":"First of all congratulations you all made it to chapter 4\n- our final chapter.\nThe title gives it away\nto implement the rest of the application\nwe go with a state machine.\n","20":"- Some noteworthy exceptions to the original game\n- adapted to a big crowd which will be separated in 3 teams\n","9":"While my colleage will get right to it, I’ll give you an overview:\nunzip markup provided\nstart revision control\nspecify and install dependencies\nhack the backend\nRemember this will be mostly a frontend app,\nso the backend will be tiny.\n","37":"That’s more like a note to self.\nAlain how is the coding going?\nOk to give Alain a couple more minutes\nI would like to focus your attention to some CoffeeScript details.\n","26":"Finally, now that most of the tech stack is in place, we get to the point where we actually implement some business logic. \n","15":"Rack reduces the inner workings of a web app to very simple data structures:\nA request is represented as a list of key value pairs.\nA response is respresented as an array with three elements.\nThe 1st element is a status code.\nThe 2nd element are the headers which itself is a list of key value pairs.\nAnd the 3rd element is the content, which of course is optional.\n","4":"Imagine a client who has the idea\nof an online version of Jeopardy.\nParticipants should be able\nto join the game with their smartphones\nusing ther own devices to ring in to score points.\nOk, who knows the rules of Jeopardy?\n","32":"So naturally the next steps are\nleading to the State Machine\nand walking you through the details of it.\nSecondly I would like to highlight some noteworthy parts of the CoffeeScript.\nAnd if everything goes smoothly\nwe’ll use the time when you usually get to ask any question\nto demo the app.\n","21":"- In other talks you have seen ST-JS (Strongly Typed JS) and Typescript\n- More on CoffeeScript we will show you later heads on with code\n","10":"We’ll unpack the markup and find three folders\nviews is where the html files are\npublic is the directory where all the assets, mainly css, js, and images are located\nwhile assets is a special folder which also holds assets\nbut these are not meant to be served directly to the client\nthese files need processing\nlike converting scss or sass into css\nor translating coffeescript into javascript\nSubsequently we’ll start with the revision control. Here we use Git. If you haven’t done so you should check out Git.\nThis might seem a little too nitty gritty, but we really to join us from the beginning.\nMoving on.\n"}