ohanhi

Learning FP the hard way: Experiences on the Elm language

by Ossi Hanhinen, @ohanhi

with the support of Futurice 💚.

Licensed under CC BY 4.0.

Editorial note

IanWhitney

class Bob
  def reply_to(statement)
    public_send("reply_to_#{statement.class}".downcase.to_sym)
  rescue NoMethodError
    default_reply
  end

  def reply_to_silence
    "Fine. Be that way!"
  end

vcunat

import Data.List
import Data.Maybe (fromMaybe)
import qualified Data.Map as M

import XMonad
import XMonad.Config.Xfce (xfceConfig)
--import XMonad.Config.Gnome
--import XMonad.Config.Kde
import XMonad.Config.Desktop (desktopLayoutModifiers)

mwlang

     Failure/Error: response = post_xml(:stock_update, "single_item")
     Faraday::ConnectionFailed:
       getaddrinfo: nodename nor servname provided, or not known
     # /Users/mwlang/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/adapter/net_http.rb:80:in `perform_request'
     # /Users/mwlang/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/adapter/net_http.rb:39:in `call'
     # /Users/mwlang/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/rack_builder.rb:139:in `build_response'
     # /Users/mwlang/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/connection.rb:377:in `run_request'
     # /Users/mwlang/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/connection.rb:177:in `post'

varyonic

module ActiveAdmin
  module Views
    class ActiveAdminForm
      class DeprecatedFormBufferSubstitute
        def initialize(form)
          @form = form
        end
        def << (value)
          @form.text_node value.html_safe
        end

rkjha

upstream myapp_puma {
  server unix:/tmp/myapp_puma.sock fail_timeout=0;
}

# for redirecting to https version of the site
server {
       listen 80;
       rewrite ^(.*) https://$host$1 permanent;
 }
 

evancz

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

davidcelis

upstream puma {
  server unix:///var/www/app/shared/tmp/sockets/puma.sock fail_timeout=0;
}

server {
  listen 80 default deferred;
  server_name example.com;
  rewrite ^/(.+) https://example.com/$1 permanent;
}

jhjguxin

In this article, I'll walk through a basic Rails (3.2.x) setup for creating a nested resource for two models. Nested resources work well when you want to build out URL structure between two related models, and still maintain a RESTful convention. This code assumes you are running RVM to manage Ruby/Gem versions, and Git for version control.

Creating a new Rails project

$ mkdir family # create rvm gemset 
$ echo "rvm use --create ruby-1.9.2@family" > family/.rvmrc 
$ cd family # install rails 
$ gem install rails # create new rails project 
$ rails new . # version control