View app.cr
require "crappy"
class AppHandler
include HTTP::Handler
include Crappy::Routing
include Crappy::Rendering
def call(context)
crappy do
within "api" do
View application.html.slim
doctype html
html
head
title My Rails 5.2 App
= csrf_meta_tags
meta name="viewport" content="width=device-width, initial-scale=1.0"
= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload'
= javascript_include_tag 'application', 'data-turbolinks-track': 'reload'
View application.html.slim
doctype html
html
head
title My Rails 5.2 App
meta name="viewport" content="width=device-width, initial-scale=1.0"
= csrf_meta_tags
= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload'
= javascript_include_tag 'application', 'data-turbolinks-track': 'reload'
body
View main.coffee
memoize = require './memoize'
# By using memoize, the following functional component will only update
# when the props passed into it have changed. Please note that this assumes
# that the actual prop values are immutable objects, since we don't perform
# any deep equality checks.
logPanel = memoize ({log}) ->
h '#log-panel', [
for line in log
View about.md

Here's a tiny, but fully functional (ha) incremental game framework. Some notes:

  • Built with CoffeeScript. I like CoffeeScript very much.
  • Inspired by Elm, minus the types, obviously.
  • Uses Inferno.js as its rendering layer. It's extremely fast.
  • main.coffee dispatches to a state object, because games typically employ finite state machines. With a single state, this is unneccessary, of course.

-- Hendrik Mans, hendrik@mans.de

View info.md

This is a RESTful Rails controller, implementing all 7 RESTful actions. In my Rails apps, 9 out of 10 controllers will end up looking like this.

class PostsController < ApplicationController
  load_and_authorize_resource

  def create
    @post.save and redirect_to(@post) or render(:new)
  end
View Clicker.elm
module Clicker exposing (..)
import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (onClick)
import Time exposing (Time, second)
-- MODEL
View elixir_phoenix_notes.md

Notes on learning Elixir and Phoenix

Just some assorted notes I've made while digging into Phoenix, Elixir and friends. I'm coming from a strong Rails background, so many of these will refer to features from that framework.

Views / Templates

Biggest difference from Rails?

Unlike Rails, where rendering is almost always performed by a template file, the responsibility of rendering a response in Phoenix lies with a view module (that typically corresponds to the current controller module.) This view module will typically offer a whole bunch of render functions (matching different parameters, first and foremost the template name.) Templates (found in web/templates/) will directly compile into such functions.

View application.html.slim
doctype html
html
head
title My App
meta name="viewport" content="width=device-width, initial-scale=1.0"
= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload'
= javascript_include_tag 'application', 'data-turbolinks-track': 'reload'
= csrf_meta_tags
body
View Disabling Rails generators you don't need.md

Disable some Rails generators you don't need to run all the time

Reasoning: the Rails default is to generate a separate .coffee (or .js) and .scss file for each controller you add to your application. This may not be what you need. Adding the following lines to your development environment's configuration file will prevent this from happening:

# In config/environments/development.rb
config.generators.stylesheets = false
config.generators.javascripts = false
config.generators.helper      = false