Hちょびよみ勉強ノート(3回目)

Haskell 勉強会

型クラス

(図内の分類は適当)

  • 型
    • 値の集合
  • 型クラス
    • 型の集合

型をある何かしらの特徴で分類したものを型クラスと言う。「足し算できる型」とか「表示できる型」とか。
「型クラス」と言う名称はHaskellとHaskellにインスピレーションを得た言語固有の語彙。言語によってはKindとか呼ばれたりもする。
型クラスに属する型はHaskellとかだと静的に決まるがJavaとかだと決まりきらない(継承とかがあるので)。
ある型に対する処理や演算が可能かどうかというのを静的に保証したい。目的としてはJavaとかで言う「インタフェースに対する実装」と同じだけどより型による制約が強い。

Eq型クラスは同型比較しか出来ないが異型比較はどうするの？

そもそも異なる型同士の比較とかはHaskellでは起こらない。
継承がないので何型が来るか分からないとか言うのはそもそも起こりえないし、全ての型は静的に決まる。
(equals(Object obj){...}で、実際の型は何型が来るんだろうみたいな状況がそもそも無い)

letとwhere

letは式、whereはただのキーワード。
whereは「どこ」ではなく関係副詞。

数学ではお馴染みの表現とのこと。

I was born in this house.
　↓

This is the house which I was born in.

　↓*1

This is the house in which I was born.

　↓*2

This is the house where I was born.

let A in B と B where A は似たような機能を持つ構文だけど、英文として見ても割と似たような変換を出来るということっぽい。

何故asパターンのところだけ「あず」とひらがなでルビが振ってあるのか問題

翻訳者が関係あるのでは説

*1:前置詞inは名詞に惹かれ合うらしい。whichは関係代"名詞"

*2:in which = where

Twitterで「最近開発でDocker使ってて便利だよ」って呟いた話

Docker

概要としてはこんな感じ。
少し前、いわゆるLAMPのプロジェクトをやっていてそれにDockerを導入しました。ついっとした通り、本番投入はまだ怖かったので個々人の開発環境とJenkinsのテスト用止まり。デプロイはAnsibleを使ってDockerコンテナにsshという感じで行いました。*1

Ansibleを採用したのは

という経緯から。*2


上記のような環境で開発してみて分かったのは、ついっとにもありますが

  • クリーンな環境をコマンド一発で高速で構築してデプロイするの快適すぎる
  • 同じDockerfileを使うので「俺の環境では動くんだけど」が無い。Jenkins上でのテストもしかり。
  • PRベース開発でレビューする時、他人の成果を自分のマシン上で動かせるの完全に良い
  • Jenkinsマシンが汚れないしJenkinsマシン自体にいろんなライブラリやツールをセットアップしなくて良い
  • Dockerだろうが実マシンだろうが常に同じ仕組みでデプロイしているので安心感が半端ない
    • デプロイの頻度自体も上記のようにローカルでかなりの回数やるので安心感が更にプラス
  • DockerコンテナにMySQLも入れたので、本物のMySQLをテストに使える
    • sqliteやh2みたいな「テスト用の使い捨てDB」を使わず本物のMySQLを使い捨てられる
    • MySQL固有の機能や方言も使えるしわざわざDBアクセス部分をモック化しなくていい


Ansible自体も、使い方覚えればFabricより快適という状況でした。Fabric自体は単なるPythonであるという圧倒的学習コストの低さが魅力なんですが、逆にただのPythonであるというのがデメリットにもなるなと言う感じ。
結局のところただの手続きなので、デプロイスクリプト自体にバグがない事を保証したり安心したりするのはなかなか難しくて、手順自体が複雑だと高確率でデプロイスクリプトにバグを作りこむ結果になるという感じがしていました。
その点Ansibleはymlを使って宣言的に書けるのでFabricに比べるとかなりシンプルになった感じがあります。ただ、その分柔軟さと言うところではFabricより手間がかかるっぽいので、そこはトレードオフと言う感じかなーと思いました。*3

冪等性とかもAnsibleはある程度はやってくれるっぽいです。*4 *5

Chefは使ってないのでChefとの比較は出来ません…。

問題点

方式自体の問題点というよりは、やはり、共用開発環境や本番環境ではDockerが使えなかったという点。
Dockerfileに対して加えた変更をちゃんと実マシンにも反映しましょうというのが結局のところ「人間が気をつける」に帰結してしまうので、うっかりすると「ローカルやJenkinsでは動くのに共用開発環境では動かない」ってなるのがイケてないなーと思いました。

*1:本来はアプリごとDockerイメージに焼きこんでしまいたかったのですが、上述のように開発と本番で環境が違うので、本番環境でDockerfileによるデプロイは出来ないという状況で、とは言え開発と本番でデプロイ先環境が違うからといってデプロイ方法を変えたくなかったのでこのような方法を取りました。

*2:Chefはなんとなく苦手イメージがある

*3:モジュール書けば何でもできるしモジュール自体の作成難度も高くないのでそんなに手間という感じでは無いっぽいですが、言うてやっぱりFabricの手軽さには勝てない感

*4:モジュールによる？

*5:今回あまり複雑なマシン設定も無かったしアプリのデプロイ自体もバージョンごとにディレクトリ作ってシンボリックリンクで切り替える方式にしたのであまり気にしてなかったというのもある

Hちょびよみ勉強ノート(1回目〜2回目)

Haskell 勉強会

型とか関数とかを集合論の観点からとらえた基礎的な話

型


関数

そもそもこの知識すら無かった。
今までまるで理解できなかったWikipediaみたいな事言ってくる人達の言ってる内容、理解できそうな部分が増えそう。

多相

f :: Int -> Int

みたいな固定の型を受け取るような関数じゃなく

f ::  a -> b

みたいに複数の型を受け取れる関数を多相な関数というらしい。*1
多相にもいくつか分類があって、HaskellやJavaはJavaのジェネリクスはその中でもパラメトリック多相*2というものらしい。

との指摘を頂いたので修正しました

*1:a, bは型変数

*2:ある範囲の型を型変数と言う形で表現するからパラメトリックとか言うとのこと

ミニ四駆を走らせる会を開催しました

misc

6/7(土)に ミニ四駆を走らせる会 - connpass を開催しました。

とは言え主催者が何も書かないわけにもいかないので書いてみます。

開催の経緯

にも記載した通り、何故か周辺でにわかにミニ四駆が流行りだしたのが発端でした。
いざ買って走らせてみたら、やっぱり大きなコースで走らせたいよねー欲が湧いてきて、そのうち誰かイベントでも立ててくれるに違いないと思ってたら立たなかったので勢いでconnpassに立てたという流れです。

当日の様子

既にVさんが書いてくれてるミニ四駆走らせたいに参加してきた · GitHubに詳しいですが、ガチ勢が鬼気迫る勢いでしのぎを削るというサツバツな感じにはしたくなくて、みんなでワイワイやりたいなぁと思っていたんですが、実際ワイワイした感じになって良かったです。
コースの設計段階から「ちょｗｗｗLC多すぎｗｗｗ」とか「二連続ジャンプｗｗｗｗ」とか「ジャンプの直後ヘアピンとか物理的に無理ではｗｗｗ」みたいに草が生い茂り、非常に楽しかったですね。
タミヤの作例にJCJC4セット相当のものがなかったのでとりあえず3セットの作例で適当なやつを組んで、そこから残り1セット分適当に拡張しましょうみたいなことをやったんですが、やっぱり実際に走らせてみて初めて塩梅が見えるみたいなのが多かったという感じでした。


第一回ミニ四駆を走らせる会のレギュレーションとかまとめるやつ - Qiitaの方に当日のコンテンツ案について色々書いたんですが結局当日の流れと言う感じになりました。
持ってきたマシンを走らせる→吹っ飛ぶ→完走を目指す→タイム測る→「速くなったｗｗｗ」ってドヤるみたいな感じで、吹っ飛ぶとみんなで「あーっ！」と残念がり、速く完走できると「おーｗｗｗすげーｗｗｗ！！」とみんなで喜ぶ感じ。
最後の方になってタイム上位者で競争してみる？みたいな流れになってレースしたんですが、みなさんが吹っ飛んでいく中トロトロ走ってた僕が完走して優勝するみたいな感じで幕を閉じました。

何人かの方は高円寺のミニ四駆バーへミニ四駆二次会に行ったみたいです。コースがガチすぎて阿鼻叫喚だったっぽいですが。

まとめ

舞台裏

最初はピクシブさんにはスペースを貸して頂くだけで、ピクシブさんとは関わりなく、あくまで僕らの会としてやろうとしていました。
で、タミヤのコースレンタルを依頼するために、タミヤのフォームに僕の名前と、開催場所としてピクシブさんを指定して送信したんですが、タミヤさんが僕をピクシブの中の人と勘違いし、更にその後タミヤさんからピクシブさんへ「コースレンタルの依頼来てるけどピクシブさんコース持ってませんでしたっけ？何かの間違いでは？」と言う直電が走ったらしく、会の開催とは関係ないピクシブさんの中の人へ話が波及する事態に。
すったもんだあった末ピクシブさんのコースを借りることになり、ピクシブコースを出動させるための社内承認フローを発動させてしまう事になり、コースの搬入も前日とかにやって頂いたそうで、全体的にピクシブさんにお手数をかける結果となってしまいました…。

とても楽しかったので第二回もやりたいなぁと思ってはいるんですが、やはりコースどうするの？辺りに色々コストがかかる感じで、これを解消しないと大変だなぁという感じです。*1
ミニ四駆を大きなコースで走らせたいなぁというだけの事でも、色々大変だなぁという学びを得ました。

*1:今後もピクシブコース借り続けるのはピクシブさん側に迷惑かけ過ぎでつらい

きょんくんの結婚祝いLT大会で人生初LTしてきた

勉強会 misc


2014年の抱負というか目標は社内だけでなく人前でLTすることでした。
そんなようなことを夜中何の気なしにつぶやいていたらきょんくんに狩られ、死ぬ思いしながら資料作って、昨日のkyon_mm * kaori_t_spica 結婚祝いLT大会 in Tokyo #kyon_kao_wedding | Peatixで発表してきました。


参加メンバー見て頂いたらだいたい分かるかと思いますが、あのメンツの前でScala初心者でjs全く分からないマンが人生初のLTをやったというのだいぶ無謀っぽいししばらくこのネタで戦っていける感ありますね。


資料作っている間も発表している間も死にそうになっていましたが、僕のような性根がアレしている人間は何やかんやでやらない理由をでっち上げては逃げるので、ある種の強制力のようなもので引っ張ってくれたきょんくんには感謝してます。


発表資料はこちらになります。


きょんくん、かおりさん、ご結婚おめでとうございます

Java8でPlay2(Java)を動かす

Playframework java

Java8がリリースされたのでPlay2をJava8で動かしたいと思うのは人類の自然な発想だと思います。
Play2ではPromise周りとかでFunctionalInterface使う場面ちょこちょこありますし、別に使わなくても便利な機能ガン増えなのでPlay2をJava8で使えたらQOL上がること間違い無しだと思います。

そのままでは動かない

Play2.2.2現在、Java8インストールして普通に動かそうとしても動きません。

とのことなのでbuild.sbtに

scalaVersion := "2.10.2"

を足しましょう。これだけで動きます。

http://i.gyazo.com/bd9b1385929dea482d96c86159590212.png

コードはこんな感じ

package controllers;

import play.*;
import play.mvc.*;

import views.html.*;

import java.util.function.Supplier;

public class Application extends Controller {

    public static Result index() {
        return getOk(() -> "Java8");
    }

    private static Result getOk(Supplier<String> sup) {
        return ok(index.render(sup.get()));
    }
}

まとめ

あなたとJava、今すぐダウンロード

git-labにマージリクエスト作成機能つけた

Python GitLab

gitlabにアクセスするgitのサブコマンド作った - 新しいフォルダ (2)のやつに機能追加して0.2.0としてリリースしました。
こんな感じ

# このプロジェクト(リポジトリ)のカレントブランチからmasterへ
# カレントブランチ名をタイトルとしてマージリクエストを作成する
$ git lab requests create

# カレントブランチから"namespace/upstream"プロジェクト(リポジトリ)のmasterへ
# カレントブランチ名をタイトルとしてマージリクエストを作成する
$ git lab requests create -d namespace/upstream

# カレントブランチから"namespace/upstream"プロジェクト(リポジトリ)のsome_branchブランチへ
# カレントブランチ名をタイトルとしてマージリクエストを作成する
$ git lab requests create -d namespace/upstream:some_branch

# foo_branchブランチから"namespace/upstream"プロジェクト(リポジトリ)のsome_branchブランチへ
# "foo_branch"をタイトルとしてマージリクエストを作成する
$ git lab requests create -d namespace/upstream:some_branch -s foo_branch

# foo_branchブランチから"namespace/upstream"プロジェクト(リポジトリ)のsome_branchブランチへ
# "some_title"をタイトルとしてマージリクエストを作成する
$ git lab requests create -d namespace/upstream:some_branch -s foo_branch -t some_title

マージリクエストを作成元のブランチはあらかじめpushしておく必要があります。