型、ついてますか？ - 型の本質を振り返る - に参加してきた #AIAL
2016/7/8に開催された「型、ついてますか？ - 型の本質を振り返る」に行ってきました。
会場は品川のマイクロソフトさんです。
大変内容が濃く興味深い話でしたが、時間が短かったこともあって大半は理解できなかった気がします。以下レポート。
型、ついてますか？ 高野光弘さん(@takano32)
今日は(古代|近代|現代|原始) * (動的|静的)型付けで分類していく
静的型付け
動的型付け
- 事前に型の精査をしない
- いきなり実行できる
- 実行時にはじめて型がわかる
古代静的型付け
- C言語を代表とする
- システムと密接な型付け
- 型が不明だとデータの扱い方がわからない
古代動的型付け
処理の記述へとフォーカスしていく
BASIC
- 初心者向け
- 裏ワザ使ってシステムにアクセス出来る(DATE, PEEK,POKE)
シェル
- システムと対話するための機構を応用
近代動的型付け
古代動的型付けで解決が面倒だった分野の改善
パール(真珠)はシェル(貝)からできているという逸話
近代静的型付け
おみやげ話: C++のstructはclassと同じ動きをする
現代動的型付け
現代静的型付け
システム記述レイヤーからの解脱
- VM
- マルチプラットフォーム
- Java
- Haskel
- AltJS
原子動的型付け
レジスタ 即値 アドレス
機械語の型付け
- 実行時に即値かアドレスか判断
- この時点からは事前処理がない
- つまり動的型付けといえる
原始静的型付け
- 起源はラムダ計算
- 型なしラムダ計算
- 型ありラムダ計算
- 原始動的型付け ... ノイマン型
- 原始静的型付け ... 思考実験
なぜ歴史は繰り返すのか
- 静的型付けと見せかけて動的なのは邪悪
- TypeScriptは実行時にJavaScript)
- C言語やC++はデバッガを強化して延命された
これからのパラダイム
抽象化がさらに進む
個人的に欲しいパラダイム
副作用を考慮したシェル
- ここでいう「副作用」とは操作がマシンに影響するか
- ls → 副作用なし
- mkdir → 副作用あり
「俺が聞きたい話はこんなんじゃなかった」→ イベントやるから来てね
Linear Types niryuuさん
資料待ち
Linear Typesとは
- 1度しか取り出せない値を表す型
- Uniqueness types(Clean)
- Ownership(Rust)
「英単語イメージハンドブック」が良本だったので書く
良本だったので書く。
- 作者: 大西泰斗,ポール・マクベイ
- 出版社/メーカー: 青灯社
- 発売日: 2008/10/04
- メディア: 単行本
- 購入: 10人 クリック: 89回
- この商品を含むブログ (24件) を見る
なお同著者の「一億人の英文法」の方が有名だと思う。こっちはまだ読んでいない。
一億人の英文法 ――すべての日本人に贈る「話すため」の英文法（東進ブックス）
- 作者: 大西泰斗,ポール・マクベイ
- 出版社/メーカー: ナガセ
- 発売日: 2011/09/09
- メディア: 単行本
- 購入: 12人 クリック: 68回
- この商品を含むブログ (49件) を見る
どんな本か
この本は「英文で使える英単語に日本語の意味を添えて大量に覚える!」系の本ではなく、「英文で特に頻出する単語を"ネイティブが持っているのイメージ"を添えて理解する」本でした。なので単語数で言えばおよそ100程度しかありません。 ですが、それぞれの単語の解説は非常に濃く、例えば "it" の解説などは5ページにも渡って行われています。
ネイティブのイメージとは
例えば「過去形」とは単に過去を表すもの、という形でならったと思われますが、 本書では、過去形はネイティブにとって「離れている」というイメージがあると解説しています。*1
本書では特徴的な使い方として
I hope you can advice me.
と
I hoped you could advice me.
では後者の方がよりへりくだった言い方になると解説しています。英語での敬語として "Would you ~" や "Could you ~" を使うと習った方が多いと思われますがこれと同じで、理由としてはネイティブは過去形のイメージとして「離れている」というものを持っているから、一歩下がった立場の表現を使うことで丁寧な言葉になるということだそうです。このように、英語を定型として説明せずにネイティブが持っているイメージから理由立てて説明がなされています。他にも、助動詞(MUST, MAY, CAN...)、前置詞(AT, IN, ON...)、接続詞(AND, OR, BUT, SO...)といった単語も逐一イメージをベースとした深い解説があります。
どんな人が読めばいいか
あくまで自分を基準としますが、英語を学び始めで、英語の定型文をただひたすら覚えるのが苦手という人が読めばいいと思います。特に自分は前置詞の使い分けが苦手で、どんな時にAT/IN/ONを使い分ければ良いのかが上達しなかったので、本書のように根拠を持って解説してくれるのは非常に理解の助けになりました。*2
さいごに
この本は手元に置いておいて英文で困った時に何度か引き直す本になると思います。*3
英語初学者の方はまず本書を一通り読んでおけばその後の学習に非常に役に立つと思うのでオススメです。
Railsでバッチ処理を書く場合、rakeタスクとrails runnerのどちらにすべきか
Railsでバッチ処理を書く仕事があって、どちらにするべきか迷った。 迷ったのでググったら以下の記事を見つけた。
要約すると
script/runnerは実行時にRailsアプリを起動する。これはrakeの:environmentと似ている- Railsの起動は時間が掛かるので避けられるならrakeにして避けるべき
- それ以外はほぼ同等
ということなので、Railsのモデルを使うバッチはrunnerで、それ以外はrakeにする方が良さそう。
個人的には、
-eで環境を指定できる- クラスのメソッドを直接呼べるのでテストが書きやすい(rakeだと結局処理を別のクラスに起こさなければいけない)
という点からrails runnerを使うことにした。
adtech x scala meetupに参加してきた #adtech_scala
2016/5/16に開催された「adtech x scala meetup」に参加してきました。
「頑張らないでScala 〜VOYAGE GROUPにおけるアドネットワーク開発の戦略〜」 VOYAGE GROUP 岩永 賢明
スタートアップらしく技術はサービス開発を加速できる必要最低限で抑え、しっかり前に進むための地に足を付けた戦略だと思った。 「頑張らないこと」を主眼においているが、いずれ来る困難を先読みし退路を確保しておく、ということはとても重要だと説いていた。
「Dynamic Movie Ad x Scala」 adtech studio 大野 裕太
※資料待ち
広告の配信と同時に動的に広告動画を生成するアーキテクチャについて紹介された。 使用しているミドルウェアはSplay/Kafka/Spark/Go/Aerospike/Mysql/S3あたり。 動画生成部分にGoを使っているのは書いている人が得意だった、クロスコンパイルしてLinux/Windows両方動かせるようにしたかった、などから。
Aerospikeを初めて知ったので調べてみたところ、データモデルも指定でき集計もできる高機能なKVSといったものだった。
「CyberZにおけるScalaの立ち位置」 CyberZ 鈴木 雄登
F.O.Xを支える技術 from Yuto Suzuki
PHPで構築された管理画面部分をリプレースしたい、かつ共有DBから引き剥がしデータストアAPIを作りたい、というところをScalaで実装したお話。 Scalaを選定したのはそもそもJava開発者が多く、アンケート結果からScalaやりたい人が多かったからとのこと。 Scalaの複数可能な記述法、ノウハウの不足、読めない記号などに苦しめられたそうだが、「アドテクは連携が多く、統一的な規約がなく汎用的に作る必要がある。言語レベルで抽象化できるScalaは理想的」という言葉が印象的だった。
読めない記号問題は、この発表の最中にTLで流れてきたscala-search.orgが記号にも対応していて便利そうだった。
(なおfoldLeftを意味する /: は ドミノの畳込みをイメージしたものらしい)
LT
Scala.jsの話かと思ったら違った。JVM上でJavascriptを動かすランタイムらしい。Scala.jsより幸せになるんだろうか。
Scalaの歴史振り返り。Scalaコミニュティは徐々に拡大傾向にあるとのこと。ちょこちょこ入るxuwei氏情報が面白かった。
さいごに
登壇された皆様、会場提供のサイバーエージェント様ありがとうございました! お寿司おいしかったです🍣
Atomでファイルを生成せずに素早くRubyコードを実行する
スクリプト書いて連番の文字列を大量に出したい時とか、Rails書いててRubyの挙動を確かめたい時にさっとRubyのコードが実行できたら嬉しいと思います。
で、大抵の場合irbかpryを使って書くわけですが、コードを何度か書き直しながら実行したり、複数行にまたいだりするとこれらのツールだと結構面倒くさくなってくるんですね。
そんな時、僕はメインエディタにAtomを使用しているのでatom-runnerでRubyコードを走らせています。
というわけで、とっととatom-runnerをインストールします。
$ apm install atom-runner
atom-runnerが無事インストールできたら、atomを立ち上げて
Control + Shift + L で Select Grammar からruby とEnterを打ち
お好みのRubyコードを書いて
Control + Rで実行できます。
GrammarでRubyを選ばずとも#! /usr/bin/env ruby とシバンを書いてあげても実行できますがこの方法が速いのでこれでやっています。
なお、atom-runnerが対応している言語であればRubyに限らず実行が可能です。(画像はJavascriptを選択しnode.jsを実行している)
JAWS-UGコンテナ支部 #4 に参加してきました #jawsug_ct
2016年2月5日に開催されたJAWS-UGコンテナ支部 #4 に参加してきました。
「好きです ECR (仮)」 @orih_y さん
ECRの特徴としては
ということだという。
気になる料金だが、DockerHubと比べてもかなり安いとのこと。(詳細忘れた)
「お前のDockerイメージはまだ重い〜体脂肪一桁のDockerイメージを目指して〜」 株式会社サイバーエージェント @stormcat24 さん
ちょうどDockerイメージの軽量化に取り組んでいて、一番聞きたかったセッション。RUNをチェーンしたり、ビルドのためにインストールしたパッケージやファイル(産業廃棄物)を消すという地道な作業が重要ということだった。
このイベントに参加する前にこの記事をちょうど読んでいて自分もAlpine Linuxを触っていた。後から質問したところ、とくにネックになっていることもなくいつでも本番に投入したいと言っていたので、十分に採用することはできそうだった。
「実践ECS-CLI（デモ）」 @pottavaさん
ECS-CLIを使って実際にEC2上にコンテナを立てるデモ。ECS-CLIを使えば、docker-composeを使っているかのようにEC2上にコンテナを立てることができるとのこと。実際にECS-CLIを本番環境で使うには難しく、aws-cliやシェルのサポートが必要とのこと。
「ECSを使ったAutoScalingの実装Tips」 クラスメソッド株式会社 千葉 淳さん
ECSのAutoScalingはコンテナごとのスケールにはまだ対応しておらず、EC2ごとのスケールをしなければならない。それをCloudwatchEventのトリガーを使って頑張った話。
CloudwatchEventのトリガーはほとんどのサービス網羅してそうで、なんでもできそうなイメージだった。
はじめましてJAWS-UGコンテナ支部
＿人人人人人人人人人人人＿
＞ 突然のトニーモリス ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
HANDSLABさんでもDockerを本番環境に投入しており、十分に安定しているとのこと。
Docker で Deep Learning
さいごに
JAWS-UGの方々、会場提供のサイバーエージェントさん、ありがとうございました!
「DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門」に参加してきた #DDDAlliance
2015年1月21日に開催された、「DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門」に参加してきました。
以下から現地で書いたメモ
ドメインモデルとは
ドメインモデル = 関心事を集めたもの。サブセットと呼んでもいい
ドメイン駆動設計
ドメインを分析する人がコードを書く コードを書く人がドメインを分析する 毎日分析し、毎日コードを書く
コードを書くためにはクラスを見つけなければいけない 問題領域を分析することでクラスが見つかる 分析者 = 実装者 とならなければならない
モデルを見つけることとクラスを見つけることは一緒。人を別にしてはいけない。
ソフトウェアを立ち上げる時はフェーズと人を分けるけど、 保守フェーズでは分析と実装者が一緒。立ち上げ時もそれをやればいい。
ドキュメントを書いてからコードを書くという方法は大概無駄になる。
ドメインを学び学んだことをコードで表現することが大前提
ドメイン層
ドメイン層はどこにも依存しない(プレゼン、アプリケーション、データベース) Springで実装
ドメイン層のオブジェクト ドメインにGetter/Setterは使わない 業務の関心事の表現 知りたいこと 誰が、いつ、なぜ。。。 業務ルール 制約、閾値、手順。。。 業務ルールが破られた時の業務ルール
業務サービスの実行役 判断の結果 計算の結果 加工の結果 (基本データ型は返さない)
独自の型を作ることがドメイン指向設計
オブジェクト指向のメリット: コードの整理
クラス単位に関連するコードを整理する どこに何が書いてあるか特定しやすくなる 変更が飛び火しない - データと機能を分けると飛び火しやすい 変更した箇所のテストがOKなら全体もOK
アンチパターン：変更コストが高くなる設計
ふるまいを持たない、いわゆるデータクラス
データクラスがレイヤーを跨いで使われている
どこで使われているか特定しにくくなる
変更コストが下がる設計
役に立つクラスを作る(判断・加工・計算ロジックを持たせる) クライアントは使うだけ
主要な関心事をアグリゲートに組む
オブジェクト指向：アーキテクチャ
構造
オブジェクトの集合体
強く関連する部品は集約する
アグリゲート同士は分散性を高め必要最小限につなげる
「変更」を前提にしたネットワーク構造
メタファ：LANアグリゲートとインターネット(全体)
工法
「変更」を前提にする
インクリメンタルに開発
少しずつ成長する全体
毎日変化させていく
オブジェクトの設計
独自の型を設計
オブジェクトのコラボレーションを設計
実現手段の隠蔽
独自の型を設計する
ドメイン層は独自の型だらけにする
独自の方＝利用者の関心事
基本データ型＝コンピュータの関心事
オブジェクトのコラボレーションの設計
契約による設計、責任駆動設計、擬人化。。。
結局は「オブジェクト」と「オブジェクト」が協力して設計することが大事
コラボレーションの設計原則
オブジェクト同士の契約(顧客と供給者の関係)を意識する
相手のことを深く知りすぎてはいけない
書籍：契約による設計
「契約による設計」
契約ってなんだ?技術者にはいいメタファじゃないよね
契約はビジネスルールの関心事。業務ルールの基本。
業務知識を学べば業務ロジックも契約による設計も学べて美味しい
オブジェクト指向：実現手段の隠蔽
業務の関心事の表現手段として「不適切」
int string LocalDate => 値オブジェクトで包む
for while List => ファーストコレクションで包む
列挙型でswitchを減らす
事例の研究
「転職支援サービス」を例に
転職アドバイザ
求職者
求人
応募
スカウト
職務依頼
ドメイン層の隔離
初級
中級
ドメインロジックを(プレゼン層、アプリケーション層などから)ドメイン層に移動する
浅いリファクタリング
上級
知識豊富になったドメイン層の見通しを良くする
深いリファクタリング
主要な関心事(コア)の隠蔽
主要な関心事(コア)の抽象化
各層の実装
プレゼンテーション層
標準的なSplingの機能を使う
サービスをインジェクションする
サービス層
渡されたIDに対してデータをリポジトリから取得する
データソース層
SQL Mapperのインジェクション
ドメインの型を返す
メトリクス
ざっくり20ヶ月、100人月くらい
アグリゲートに対して10くらいのドメイン(平均なのであくまでイメージ)
ドメイン層のクラスの行数はだいたい100行くらいで収まっている
30行〜60行がほとんど
クラス数が1000~2000あっても、関心事が集約されているのでたいして困らない
ドメインオブジェクト「善い部品」
ドメイン駆動設計のEntityパターン：参照オブジェクト
Entityと呼ぶのではなく参照オブジェクトと呼んだ方がいい
主要な関心事への参照点
顧客との会話の語彙の起点となる
JPAの@Entity
ただのデータの入れ物クラス
テーブルと対応する
ドメイン駆動のEntityとは無関係(むしろ逆に位置する)
値オブジェクト
業務の関心事と基本語彙(日付、期間、数量、金額、単位...)
目的に特化して制約をかける
暗黙の業務ルールをコードで表現する
コードを読んで業務ルールがわかるようにする
ロジックを集約する
コードの重複がなくなり変更が楽になる
値オブジェクトの実装パターン
完全コンストラクタ
不変なオブジェクト
何もしないgetterはNG
例えば、求人者の転職回数というのは今後関心事となることが予想される。そういったものを値オブジェクト化するのは有効。
値オブジェクトの効果
コードにドメインの言葉が増える => コードが仕様を語れる
一覧オブジェクト（ファースクラストコレクション）
ListやSetをラップ
コレクションの操作はコードがごちゃごちゃしやすく、変更の副作用が多い
クラスとして独立させ、そのクラスに閉じ込める
一覧オブジェクト vs SQL問い合わせ
SQLの抽出条件を単純にし、微妙な抽出を一覧オブジェクトにやらせる選択肢もある
どちらのやり方が関心事をうまく表せられるか
メモリとトレードオフ
区分オブジェクト
場合ごとのルールを理解し表現する道具
列挙を有効活用しifやswitchを削減する(ポリモフィズム)
区分オブジェクトの効果
関心事の明示的なコード表現
複雑なif文の削除
どこに何があるかわかりやすくなる
区分の追加や削除時の変更の副作用が少ない
How より What でコードを記述する
業務の関心事を明示的に表現する
より業務に寄せたメソッド名にする
深い洞察に向かうリファクタリング
お客さんの要望からやりたいこと、関心事を洞察し、コードに反映させるようにリファクタリングをしていく
関心事をより強調されるようにドメインオブジェクトを捻出していく
オブジェクト指向設計の学び方
本やスライドで用語を学ぶ
実際にコードを書く
元の本やスライドを読みなおす
変更作業が学びの絶好のチャンス
既存コードを変更しながらコードを読んだ範囲、変更箇所の数、テストの範囲を意識
オブジェクト指向設計に書き換えてから変更してみる
変更の際にリファクタリング
既存のコードの設計と比較して成功を実感する
ドメイン駆動設計とは
ドメインを学び、学んだことをコードで表現すること
QA
Q: リポジトリでトランザクションやロックするの難しくない?
A: 最近はトランザクションなしでの開発にチャレンジしている(現場はトランザクション使う)
Q: リポジトリから特定の値オブジェクトだけを取るのはあり?
A: 業務として必要であるのであれば全然あり。(ただし業務として成立している場合)
Q: コンストラクタは隠した方が良いか?
A: 隠したほうが良い。ファクトリメソッドで生成する考え方は推奨。
Q: DDDによって開発スピードが落ちないか?
A: ビジネスががらっと変わることはなく、既存のサービスをどんどん成長させていくケースがほとんどで、
ビジネスと開発に大きなスピードのギャップは生まれない。
開発スピードがでないのであれば、それを判断材料にオブジェクト指向を習得していくべき。
Q: ドメインエキスパートが不在、もしくはまだビジネス未成熟の場合どうすれば?
A: ドメインエキスパートなんてものは存在しない!ビジネスの全てを知っている人はいないので、技術者が積極的にキャッチしにいくべき。ドメインの知識をためていく。
