builderscon tokyo 2017に参加してきた[day 2]

buildersconに参加してきました。

builderscon.io

前身のYAPC 2015から2年ぶりの参加になります。

以下気になった部分のメモを残しておきます。 ただし聞き間違い等も多くあると思うので、スライドや後日公開される(はずの)ビデオ等を見るほうがよいと思います。

OSS開発を仕事にする技術

builderscon.io

• 成長が見込めるOSS
  • テーマが明確であること
  • コミュニティが強いこと
    • 具体的にはstackoverflow, reddit, github, 等のコミュニティ
• ビジョンと基礎があればエンジニアは集まる
• 複数社からエンジニアが参加していることが重用

• OSSの開発プロセスに決まった型がない

  • 見つかったものの一つがXDSD
  • XDSD(eXtremely Distributed Software Development)

• Kubernetes on AWSを採用している企業

  • https://github.com/hjacobs/kubernetes-on-aws-users
• 自社にあったOSSの選定の仕方
  • ニッチでよい(一番有名なものがよいわけではない)
  • 開発が活発なプロジェクトを選ぶ
    • PRを投げてもmergeされなきゃ意味がない
• OSS開発のアンチパターン
  • OSS自体で一儲けしようと考えてしまう

ランチセッション A 株式会社VOYAGE GROUP

• Ajito.fmの公開収録？的な
• お弁当ごちそうさまでした。 ajito.fm

ランチセッションB Momentum株式会社

• 広告詐欺や不適切な場所に広告が表示されるのをいかに防ぐかの話

真のコンポーネント粒度を求めて

真のコンポーネント粒度を求めて - builderscon tokyo 2017

• Atomic Design
  • デザインシステムを作り、ページを作るという流れ
  • 細部から始めて全体を考え、細部を見直せ
• Enduring CSS(ECSS)
  • コンポーネントの抽象化を避ける
    • 抽象化: OOCSS的なアプローチ
  • いつでも捨てられることを意識する
• 抽象化を避ける
  • 似たようなUIパーツが登場しても、別の機能の中で使われるのであればそれは別物
  • 同じような見栄えでもそれぞれのコンポーネントであれば
  • コピペで作っておけば、該当部分のコードをすぐに消すことができる
  • コードの捨てやすさが長期運用では実は一番重要
• 実際の事例の紹介
  • CSS設計はデザインカンプとコードだけ眺めていても解決はしない
  • 前工程、後工程などを考慮し、ワークフローに応じて考える
• 質疑
  • ECSSを採用してもレスポンシブのためのGridなどは共通になると思う、他に共通化を行ってもいい部分はあるだろうか？
    • Gridは発表者も共通化すると思うとのこと。共通度と変更の可能性を考慮して決める

Goで実装する軽量マークアップ言語パーサー

builderscon.io

• 軽量マークアップ言語

  • Markdown, Textile, はてな記法
  • HTMLやXMLとプレーンテキストの中間にある

• はてな記法

  • org-modeとちょっと似た文法
  • 実装が色々ある
    • 実装の数だけ仕様が存在する
    • 仕様を知るにはPerlと正規表現を読み解く必要がある

• 手頃な実装がない

  • Perl以外で書かれたアプリケーションでも使いたい

• 軽量マークアップ言語は難しい

  • 人間にとっての読み書きしやすさと、機械にとっての読み書きしやすさは異なる
  • 厳格な文法規則に従わせるパーサーより誤り訂正してくれる方が実用的なのでは？

• 軽量マークアップ言語のパーサーは個人プロジェクトで取り組むにちょうどいい難度

  • 小さい機能を積み上げられる
  • 使用が厳格
  • 例えば： JSONのパーサーを書いてみる
  • 次に字句解析、構文解析を自作

RDBアンチパターン リファクタリング

builderscon.io

• DB設計はは積み木のようなもので三角錐の上に球をのせるようなマジカルな設計にしてしまうとニッチもサッチもいかなくなる
• チーズなのか腐った牛乳なのかを見極める
  • 本当に改修が必要かどうか
  • 腐った牛乳は生死に関わる
  • 時間とともに腐っていく

DBリファクタリングの準備を整える

• 抽象化: 永続化層を整える
• モニタリング
  • テストコードではパフォーマンスが監視できない
  • 負荷テストでは人間が想定したテストしか書けない
• テスト: 品質を担保する
  • テストコードはコード品質の見える化
• 覚悟
  • サービス停止の壁
  • 0に近づけることはできるが、0には出来ない
  • 政治的な力が必要
  • 自分を守るために自動化（人がアサインされづらいので、だからこそ自動化)
• これらの大変な作業をする価値があるのか？
  • 腐った牛乳なのか、チーズなのかの判断
• memo1, memo2がダサい
  • ときには我慢して使ってもらうのでもいいかも
• 対象を選定し、移行期間を決める
  • 移行期間が必要
  • 移行前と移行後で両方正しく動く必要がある
• 移行期間についてはコメントに入れておくとエンジニアが気付ける
  • /* 2018/04に削除します */ とか
• 移行期の戦略
  • Triggerを使う
  • その後Triggerと旧カラムを消す
• 変更前、変更中、変更後のテストを行う
  • DB変更の手順は多くの手数が必要になる
• 現場で働くあなたへ
  • 施行前に戻せる事
  • 以降中は過去の状態を保持すること
  • 小さい変更を長いスパンで繰り返す
    • 影響範囲が広いので切り分けをしやすくすることが重用
    • 似た事例Model層
  • 兎にも角にもテストとリファクタリングが必要
  • DBの機能をうまく活用する
    • MySQL: 仮想列
  • コミュニティを上手く使用する
• まとめ
  • DBの寿命はAppより長い
  • 一度使ったDBは消せない
    • 定期的なメンテナンスが必要
    • DBの肥大化と共に問題も大きくなる
    • Alterが終わらない、小さいときはカラム名変えるのも簡単だったけど、レコード数が大きくなると容易にはできなくなる
  • DBを守ることはサービスやチームを守ることに繋がる
    • 周囲の経験談を学ぶ
    • 積極的にコミュニティを利用する
  • RDBについては、知識が長期的に生きてくる
  • 手を動かした人だけが世界を変える

Haskellで英語学習用のコマンドラインツールを実装しました

昨日のHaskellハンズオン でIOモナドを学びました。 アイデアがあったものの、イベント中に実装が間に合わなかったので改めて時間を取って実装をしてみました。

改良点すべき点は多いのですが、とりあえず動くようになったので公開してみます。

作ったもの

英語学習用のCLIツール。

日本語に対応する英語を入力すると正解か不正解か、不正解の場合はそのDiffが表示される。

GitHub - kuranari/ring-note

最近、瞬間英作文の書籍を使って英語の勉強をしているのですが、音読だと時制や単数・複数の扱いが曖昧なまま流してしまうので、コンソールで入力して正確な作文が出来ているのかチェックしてみることにしました。

紙に書くと時間がかかるので、キーボード入力がちょうどいいのではと思った次第です。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

コード

import Control.Monad (forM_)
import Data.Maybe
import System.IO (hFlush, stdout)
import System.Console.ANSI
import System.Console.Readline (readline)
import Data.Algorithm.Diff (getGroupedDiff, Diff(First, Second, Both))

sentences :: [(String, String)]
sentences = [("これはリンゴです。", "This is an apple.")
            ,("彼は東京に住んでいます。", "He lives in Tokyo.")
            ,("これらの本はとても高い", "These books are very expensive.")
            ]

main :: IO ()
main = examination

examination :: IO ()
examination = forM_ sentences $ \(question, answer) -> do
  putStrLn question
  hFlush stdout

  maybeLine <- readline "> "
  case maybeLine of
    Nothing -> return ()
    Just line -> putResult answer line

putResult :: String -> String -> IO ()
putResult expected actual = do
  if expected == actual then
    putStrLn "✅"
  else do
    putStrLn "====="
    putStrLn expected
    mapM_ showDiff $ getGroupedDiff actual expected
    putStrLn ""
  putStrLn ""

showDiff :: Diff String -> IO ()
showDiff (First x) = do
  setSGR [SetUnderlining SingleUnderline]
  setSGR [SetColor Foreground Dull Red]
  putStr x
  setSGR [Reset]
showDiff (Second x) = do
  setSGR [SetUnderlining SingleUnderline]
  setSGR [SetColor Foreground Dull Green]
  putStr x
  setSGR [Reset]
showDiff (Both x _) = do

要素技術など

Readline

System.Console.Readline

Ctrl-aやCtrl-hなどを使うために、readlineのライブラリを使いました。 OSXのインストールに手間取ったのですが、下記の方法で解決しました。

Can't pass extra cabal parameters for readline on Mac OS X · Issue #2237 · commercialhaskell/stack · GitHub

ansi-terminal

System.Console.ANSI

文字色を設定するために使用

diff

O(ND) diffアルゴリズムを使用するために使用

Diff: O(ND) diff algorithm in haskell.

エディットグラフを使用したdiffアルゴリズムとO(ND)法による実装は以下が詳しかったです。

http://hp.vector.co.jp/authors/VA007799/viviProg/doc5.htm

今回はライブラリを使ったのですが、このアルゴリズムを独自実装するのもまた楽しそうです。

感想

これまでHaskellを勉強していても、IOが必要となるアプリを作っていなかったのでいい機会となりました。

Haskellでも手続き的な記述をすることができ、これなら自分もHaskellでも意外と実用的なコード書けそうな感覚を持ちました。 引き続き実装進めていきます。

今後のTODO

• 単語レベルでdiffを取るようにする
• 外部ファイルから学習用データを読み込めるようにする
• 正答数を出力する
• 回答までの時間を計測する
• ランダムな順番で出題できるようにする
• 結果を保存し、間違えた問題のみ再度テスト出来るようにする
• Ctrl-Dで終了できるようにする

Github

github.com

Haskell入門ハンズオンに参加しました

毎月開催しているShinjuku.hsのスピンオフの「Haskell入門ハンズオン」に参加してきました。 shinjukuhs.connpass.com

講師は『Haskell 教養としての関数型プログラミング』の著者の重城さん@yoshikunijujoさん。 普段のShinjuku.hsでは勉強会の進行等を行っているのですが、今回は @afroscript10 さんと@n0bisukeさんが勉強会の取りまとめをしてくれたので、参加者の一人として参加しました

勉強会の内容

「Haskell入門ハンズオン!」事前資料 - 1/3 - Qiita

上の事前資料を復讐した後、多相関数とリスト処理、IOモナドの講義を行い、各自作りたいものを作り始めるというような流れでした。

告知

次回は8.28にLT会を開催します。 shinjukuhs.connpass.com

Shinjuku.hsでは引き続き月に1回ペースで勉強会を開催予定です。Haskellが好き、Haskellを勉強したいというエンジニアの方、ぜひご参加下さい。 shinjukuhs.connpass.com

本イベントはSchooさんで配信が行われたので、もしかしたら後日視聴ができるようになるかもしれません。 schoo.jp