30億のデバイスで走るHonMarkHunt

JavaとJavaScriptと恐竜の絶滅について書いていきます。

Rakus Meetup Tokyo #1 終わらないスクラム 行って来た

こちら行って来た

rakus.connpass.com

テックブログもあるよとのこと

tech-blog.rakus.co.jp

アジェンダ

  1. 終わらないスクラム ~楽楽精算のサービス拡大を支えるスクラム開発の取り組み
  2. テックリード(自称)としてのやっていき! ~iOSアプリ開発チームを率いて
  3. 流行の開発手法ChatOpsとは ~楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化~

終わらないスクラム

概要

ラクスでは、まだ多くの開発チームがウオーターフォール型の開発プロセスを採用していますが、 一部のチームでスクラムによるアジャイル開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。

登壇者

twitter.com

資料

speakerdeck.com

背景

  • 過去プロジェクトや勉強会を通してスクラムを学んだ
  • 今回のプロジェクトからスクラムを導入

フォーターフォールからスクラム

Problem

  • バーンダウンしない
    • めっちゃわかる
  • とにかく会議隊が終わらない

Try

  • タスクをなるべく細分化
  • リファインメントの徹底
  • デイリースクラムの見直し
  • カンバン
    • 物理カンバン
    • キャパシティーを表す写真を貼って、4枚以上はキャパオーバーとか測る
  • インペディメントの除去

知見

  • 与えられた役割を全うする
  • スクラムチームの役割
    1. プロダクトオーナー
    2. 開発チーム
    3. スクラムマスター
  • 役割を全うするのはどのような開発手法でも同じ
  • 短期的なスプリントを何度も繰り返すので従来の開発より振り返り・導入の機会が多い

これからのスプリントでの挑戦

感想

  • スクラムに向かって行ってる感じがしていいなって思った
  • チーム多いなって思った(10人)
  • 1年後くらいに振り返ったら全然違うチームになってそう
  • 物理カンバンのだんだん汚くなるのと付箋の粘着力問題と立ち向かっててすごいなって思った
  • バーンダウンしないのめっちゃわかる。
    • 見積もりにくそ時間かけないと正しく測れない、正しく測れないから後からタスクが湧いて来てバーンダウンがなんなら右肩上がりになる
    • 正しく見積もろうとするとそれだけで数日経つのでコードが書けない。みたいなトレードオフになる気がする

テックリード(自称)としてのやっていき!

概要

若手エースエンジニアが初めてのiOSアプリ開発でテックリードとして奮闘したお話しです。 iOSアプリ開発は、自身も初、メンバーも初、しかも短納期(3ヵ月...)。 このデスマーチを予感させる不利な条件下で、テックリードとしてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。

登壇者

twitter.com

背景

スクラムチーム

  • バックエンド開発チーム 3人
  • iOSチーム 3人 ← ここ
  • スクラムマスター

やっていった

  • 仕組み化
  • コード品質
  • バランスをとる

仕組み化

  • DDD
  • 詳しい人がいないのでそこまでがんばんない

コード品質

  • あえて属人化させて開発速度をあげる
  • スタイルガイドなど導入
  • CIとか外部のやつ
    • なんか聞いたことないやつだった
  • コードレビュー
    • 細かいところまでは見れないので要点を絞ってレビュー

バランスをとる

  • hubになる
  • このへん仕事のSlackきてあんま聞けなかッタ...

振り返り

  • 技術的な課題感
    • 未着手の言語だとさすがに大変そう
  • エンジニアリング頑張りたい

感想

  • チャレンジする感じいいなって思った
  • 「3ヶ月くらいで一気に作ったけどtoilで死んだ」みたいな話をいつか聞きたい
  • php/java -> swiftってどうなんだろ
    • 大変そう(小並感)
  • 挑戦して成果出してアウトプットまで繋げるの偉いなって思った(こなみ)

流行の開発手法ChatOpsとは

概要

Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用したbotツール、システム構成、Hubotスクリプトの実例など、ノウハウを余すことなくご紹介します。

登壇者

twitter.com

資料

speakerdeck.com

背景

  • 少人数で開発~リリースまでを支える自動化の紹介

環境

  • 開発者がすきなScript書いたり
    • やばそう
  • CI/CDはJenkinsに

問題点

  • Jenkinsだるい
    • だよね

ChatOps

  1. IncomingWebHooks
  2. SlackCommands
  3. OutgoingWebhooks

hubotを使う

  • Slackコマンドのリクエストを受け取るAppサーバー立てるの怠い
  • coffeeじゃなくていい
  • npmのパッケージも作って公開した
    • すごい

gyoza.beer

  • 活用事例は若干コンプラっぽそうだったので割愛

感想

  • サービス外のコーディングは楽しい
    • わかる
  • hubotどこで動いてるんだろ
  • digdag入れたい
  • 今はhubto以外も結構あるぽい
  • Q.意識高い人が作ったものってその人がいなくなるとわからんちん問題はどうしてるのだろう
  • A.まだ引き継いだりとかっていう段階じゃない。でも最高のコードを書いてるから大丈夫!

最後に

  • 次回は来年(2020年)2月ごろだそうです。

Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました

株式会社サイバーエージェント AdTechStudio オペレーションテクノロジー事業部 iXamDrive(イグザムドライブ) でサーバーサイド・フロントエンドの開発をしている @HonMarkHunt です。

先日、 @konifar さんの記事 『B1グランプリ(Bug Bash)』を2時間やって細かいIssueを洗い出しました を拝見し素晴らしいこころみだと思ったのでiXamDriveでも挑戦して見ました!

blog.kyash.co

* iXam Driveとは?

インフィード広告の運用自動化ツール

www.cyberagent.co.jp

TL;DR

  • チーム内で触ってバグを見つけるのでは無く他チームのエンジニアにプロダクトを触ってもらいバグや分かりづらい点(UI指摘)を見つけてもらった。
  • 1時間でバグ・UI改善点が27個見つかった

Bug Bash!!

このような流れで行いました!

  1. 事前説明
  2. バグ報告
  3. 採点
  4. 景品授与

それぞれ解説していきます!

事前説明

f:id:HonMarkHunt:20180323192532j:plain:w450

まず、当日のレギュレーションを発表しました。大きく分けるとレギュレーションは以下の3つです!

  1. フロント(画面)サーバーサイドのコード(GitHubリポジトリ)フロントエンドのコード(GitHubリポジトリ)から自由にbag(と思わしきもの)UI/UX的な指摘その他なんでものを見つけて欲しい。
  2. フロント(画面) はStaging環境を使う。
    • 本番環境だと実データに影響を及ぼす危険操作ができてしまうため
  3. フロント(画面) は全機能を自由に触わるのではなく、こちらで指定した機能のみ触ってもらう。
    • 一部昨日はStaging環境でも実データに影響を及ぼす危険操作ができてしまうため

どの機能を触って貰うかミーティングで 危険操作だらけだった ことが判明したのも収穫でした。

バグ報告

  • バグと思わしきものを見つけた方は前に出てプロジェクターに繋いでバグ内容を発表してもらいました。

f:id:HonMarkHunt:20180323230637j:plain:w450

  • 想定の10倍くらいバグだらけだったのでバグ報告の行列もできてしまいました。

f:id:HonMarkHunt:20180323192728j:plain:w450

採点

  • 報告されたバグはその都度iXamDriveのメンバーで採点しました。
  • 4人のジャッジがそれぞれ1~5点までの札を持っていて、ジャッジの合計点数でもらえる景品が変わるという評価基準にしました。
  • 0点の場合は「仕様」という札をあげる。

f:id:HonMarkHunt:20180323193750p:plain:w450

(札は前日にiXamDriveメンバーで割り箸と段ボールで手作り)

f:id:HonMarkHunt:20180323192535j:plain:w350

景品授与

f:id:HonMarkHunt:20180323195056p:plain:w300

  • 報告のたびに採点してその都度点数に応じた景品を持って行って貰いました!
  • 景品用に大量の駄菓子と 机にあったいらない本 技術書を用意しました!
  • ちなみに フォームにHTMLタグをそのまま入力できる という痛恨の初歩的バグ を発見していただいた方が満点20点を叩き出しシークレット商品の iXamDriveの飲み会1回無料参加券 を獲得しました。

f:id:HonMarkHunt:20180323194847j:plain:w450

f:id:HonMarkHunt:20180323195043p:plain:w450

景品交換の様子

終了後

  • Bugは随時記録。
  • 27個ものバグが出ました!!!

f:id:HonMarkHunt:20180326121639p:plain:w400

振り返り

Bug Bashをやってみて良かったこと改善点などを書いていきます。

良かったこと

  • @konifar さんの記事を拝見してから、チームのKPT meetingでBugBash 1週間後の開催が決まりました。開催までの期間が短く、2度のmeetingを経て、他チームの方々への周知用チラシ作成、採点用札作成、景品準備など... ドタバタしながら進めていくのが文化祭みたいで楽しかったです。心なしかチーム力も向上した気がします!!
  • 参加していただいた方々にも楽しんでいただけた。参加者にはアンケートをお願いしたのですが結果がとてもよかったです!!「他チームでも開催したい。」という声があったのは嬉しかったです! f:id:HonMarkHunt:20180323201808p:plain:w400
  • issueがいっぱいできた。 ユーザーテストや単体テストと違い、自身のプロダクトを他チームのエンジニアに触ってもらう機会は中々ないと思います。エンジニアは景品欲しさに能動的攻撃を仕掛けてくるので普段は気づかないバグを発見することができました。

改善点

  • できたissueいつ消化する?問題。 issueはたくさんできたものの開発スケジュールにそんなに空きがあるはずもなく... とりあえず取り組めそうなものはバックログに追加しておいたので、一瞬手が空いた時にサッと着手できるといいかもしれないです。BugBashででたバグは当月中に解消するなどのルールを事前に決めておいてもよかったかもしれないです。
  • Bugの捜索対象をフロント(画面)サーバーサイドのコード(GitHubリポジトリ)フロントエンドのコード(GitHubリポジトリ)と3つ選出しましたが、ほとんどがフロント(画面)の指摘でした。アンケートでも「コードの指摘はそもそも仕様がわからないからハードルが高かった」とありました。機能を絞ったりしてコードも見やすいように手配すれば良かったです。

Tips

  • 発言しやすい空気を作るように心がけました。どんな報告が来てもとりあえず大声を出しました
  • 得点のフダ余ってるんで使いたい人がいたら言ってください。
  • お祭り感を出すためにわざわざチラシを作って他チームに配りました。

f:id:HonMarkHunt:20180323165458p:plain:w450

Shinjuku.LT 第18回 レポ

ShinjukuLT

www.shinjukult.tk

目次

  1. DI with Reader Monad
  2. Search Suiteのシステム構成
  3. 引っ越しを支えるかもしれない技術
  4. ツリー構造のデータをRDBで扱う
  5. 第一回 デザインクイズ
  6. Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました
  7. カイゼンジャーニー読んだよ

DI with Reader Monad

f:id:HonMarkHunt:20180324142220j:plain

登壇者

twitter.com

TL;DR

  • 関数単位の細かなDIができる
  • 評価されるまで、DIを遅延させることができる

DI

メリット

  • 疎結合

    • テストしやすい
  • 種類

    • 動的DI
    • 静的DI

SwiftでDI

  • Swinject
  • DIKit

Reader Monad

  • コードがたくさんです! f:id:HonMarkHunt:20180324142217j:plain

感想

  • 心の片隅に覚えておこう。

Search Suiteのシステム構成

f:id:HonMarkHunt:20180324143217j:plain * 全面コンプラ

http://qqqmeisi.com/wp-content/uploads/2018/02/que-1343525833.jpeg

引っ越しを支えるかもしれない技術

f:id:HonMarkHunt:20180324164826j:plain

登壇者

twitter.com

TL;DL

  • 引っ越しで支えるかもしれないいろんな情報

引っ越しにかかるコスト

  • とにかく捨てるものが多い
    • 紙の本をたくさん持ってる
  • ダンボールを送りつけると買い取ってくれるサービス

発送買取によるメリデメ

メリット * 重いものを運ばなくていい

デメリット * 引っ越しで住所が変わるとだるい

家電や粗大ゴミの破棄

  • 家電は捨てれない -> 高い
  • 粗大ゴミは低コストで捨てれるが、予約が必要
  • 地元の引っ越し屋さんの有料回収した
  • ネットのリサイクルショップは反応が遅くて微妙
  • ミニクラ 等で預かってもらっても良かった

物件探し

  • レインズ見れない(見たい)

感想

  • レインズ見たい

ツリー構造のデータをRDBで扱う

f:id:HonMarkHunt:20180324164008j:plain

登壇者

twitter.com

ツリー構造のデータで考慮すること

  • 全体参照
  • 一部参照
  • 挿入
  • 更新
  • 削除

ツリー構造をRDBでどう表現するか

  • 隣接リスト

問題点

  1. 階層が深くなると一度に引くのが大変になる
  2. 分けてクエリを発行してもクエリの発行回数が増える
  3. 挿入・更新は容易だが、削除は(末端以外だと)大変
  4. 隣接リストを用いたツリー構造は ナイーブツリー と呼ばれるアンチパターン

解決策

代わりのツリーモデルを使用する

  • ただしやや複雑になるので注意

1 . 経路列挙

経路列挙

閉包テーブル

  • メモが追いつかなかった

まとめ

  • ツリー構造の隣接リストはアンチパターンになることがある
  • 経路列挙は参照整合性が維持できない
  • 万能っぽいが、構造の難しさとデータが増える

感想

  • 全然知らなかった

第一回 デザインクイズ

f:id:HonMarkHunt:20180324164830j:plain

登壇者

twitter.com

デザインクイズ

クイズで学ぶデザイン・レイアウトの基本

クイズで学ぶデザイン・レイアウトの基本

こちらの本から抜粋してAとBのどちらのデザインが直感的に優れているのかのクイズ大会

大事なこと

  • 誰のためのデザインなのか
  • 何のためのデザインなのか

感想

  • 楽しかった!

Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました

登壇者

twitter.com

  • 僕です

資料

honmarkhunt.hatenablog.com

カイゼンジャーニー読んだよ

f:id:HonMarkHunt:20180324173756j:plain

登壇者

twitter.com

  • 小説 + 解説という面白い構成
  • リアルな状況に即したベストプラクティスに即している

感想

  • 「あなたは何をしている人なんですか?」

Shinjuku.LT 第17回 レポ

ShinjukuLT

www.shinjukult.tk

目次

  1. Shinjuku.fitness
  2. SQL Format1
  3. ブランチとCLRを組み合わせて、論理の繋がりを見える化してみる
  4. Lensとは?
  5. NGINX Blogから考えるマイクロサービスのProxy設定
  6. 危機的状況から脱出した話

Shinjuku.fitness

登壇者

twitter.com twitter.com

TL;DR

  • 正しい肉体改造方法

資料

docs.google.com

感想

  • 1時間40分も喋ってしまった。LTとは?

SQL Format1

登壇者

twitter.com

TL;DR

  • SQLフォーマッター作ってみた

様々なSQL文のフォーマット

  • フォーマットが人それぞれ
select
  a
  , b
  , c 
from
  hoge
select
  a,
  b,
  c
from
  hoge
select
  a,b,
  c
from
  hoge
  • 公式フォーマットは存在しない
  • サイモンホリウェルのフォーマットなど

www.sqlstyle.guide

合意をとる

  • 意外と色々めんどくさい...

自動でフォーマットしてくれたら楽!!

  • 作ってみた
1. ファイルパスを引数に指定された`.go`ファイルを書き換える
2. `sql`という変数に格納されている文字列を修正する
  • 手順
  1. astで抽象構文木を抽出
  2. 変数取得
  3. パーサーで解析、フォーマット
  4. 抽象構文木に入れる

抽象構文木 - Wikipedia

デモ

  • ターミナルで見せてくれた

感想

  • ファイル保存時にフォーマット直接書き換えて欲しいナ

ブランチとCLRを組み合わせて、論理の繋がりを見える化してみる

f:id:HonMarkHunt:20180218174722p:plain

登壇者

twitter.com

TL;DR

  • CLRの順番に質問してブランチで図に起こすと発言の意図をぶれずに伝えることができる

宣伝

  • 電車のお悩みを解決するオンラインハッカソンに挑戦して豪華賞品をゲットしよう!

hackathon.val.jp

前置き

  • 複数人での会話/会議はファシリテーションが大変(話が噛み合わない, 突拍子も無いことを言う, etc...)
  • ブランチ」と「CLR」が役に立つのでは

ブランチ

https://www.slideshare.net/NoriyukiMizuno/vol1-66046068/30

  • 原因と結果をはっきりさせる
  • AだからB
  • AでBだからC

CLR

  • 論理性を検証する4つの視点
  • 4つの視点を正しい順番で質問する
1. 明瞭性の懸念
2. 存在の懸念
3. 因果関係の懸念
4. 十分性の懸念

資料

hiiiiiiihikaru.hatenadiary.com

感想

  • 身につけたら一生モノのスキルになりそう

Lens

f:id:HonMarkHunt:20180218181020p:plain

登壇者

twitter.com

TL;DR

  • Lensとは何か?

宣伝

2018.tokyo.builderscon.io

Lensとは?

  • なんかすごいGetter/Setter

普通のGetter/Setterとなにが違うの?

  • ネストしたオブジェクトのある一部の値だけ操作したい

関連Link

資料

speakerdeck.com

感想

  • composeの実装、全然わからなかった

NGINX Blogから考えるマイクロサービスのProxy設定

f:id:HonMarkHunt:20180218174538p:plain

登壇者

twitter.com

TL;DR

  • マイクロサービス化 => プロキシのやること増えた => アプリ/ミドルウェアで解決するの辛い =>

よくある構成

  • リバースプロキシ

    • セキュリティ
    • SSL
    • ロードバランシング
    • キャッシュ
    • etc...
  • マイクロサービスのプロキシはどうあるべき?

  • 従来のアプローチ

  • 3 Models in the NGINX

1. Proxy Model
2. Router Mesh Model
3. Fabric Model

Proxy Model

  • 従来のリバースプロキシの設定 + マイクロサービス特有の機能

Router Mesh Model

  • 1台目のNIGNXで従来のリバースプロキシのような動き
  • 2台目のNGINX(ルーターメッシュハブ)
    • エンドポイントの統合
    • 内部キャッシュ
    • サーキットブレイカー
    • etc...

Fabric Model

  • マイクロサービスコンテナごとにプロキシを配置
  • 全ての通信IOがプロキシ経由

で、具体的にどうすればいいの?

SidecarとService Mesh

  • Sidecar

    • 各サービスとセットでデプロイ
    • 全ての通信がプロキシを経由
  • Service Mesh

    • ≠Fabric Model
  • 新しめのツールがたくさんあるぞ!

f:id:HonMarkHunt:20180218173826p:plain

資料

speakerdeck.com

感想

  • Proxy ModelからService Meshへ移行するぞ!!

危機的状況から脱出した話

f:id:HonMarkHunt:20180218175444p:plain

登壇者

twitter.com

TL;DR

Shinjuku.LT 第16回 レポ

ShinjukuLT

www.shinjukult.tk

目次

  1. キャラクターマーケテティングを考えてみる
  2. Physical Computing2 現実(リアル)を支配ハックする
  3. Elastic Cloudを1年ばかし使ってみたレビュー的な
  4. 入社までにやっておきたい事, 入社してすぐにしたい事
  5. ~歴史から学ぶ~ スニーカー基礎講座Ⅰ

キャラクターマーケテティングを考えてみる

f:id:HonMarkHunt:20180120145035j:plain

登壇者

twitter.com

TL;DR

  • キャラクターマーケティングには多くのメリットがあるが、浸透させてメリットを享受するにはそれなりの準備が必要。キャラクターをどう育てていくかが大事。

動機

  • 業務でキャラクターを作成したのでキャラクターマーケテティングについて考察してみた

キャラクターを作るということ

  • 差別化や認知度UP
  • たくさんのメリット
  • 定着させていくためには...
    • 一定の予算と時間が必要
    • PR
    • 作り込み
    • が必要

成功例

くまモン

http://www.kumamotoiccard.jp/wp-content/themes/kumamonic/images/kumamon.png

  • 新幹線開通にあわせて登場
  • 熊本外の人に向けてSNSなどで拡散
  • ターゲットと時期が明確

人気キャラを作るため

  1. 世界観
  2. 背景
  3. 差別化
  4. 使いやすい

実際に作ったキャラクター紹介

  • コンプラのためお見せできない
  • とても可愛かった

https://iwiz-chie.c.yimg.jp/im_sigghSFFFkARLdX2nNahutOZHw---x320-y320-exp5m-n1/d/iwiz-chie/que-1343525833

所感

デザインできるのっていいナー

Physical Computing2 現実(リアル)を支配ハックする

f:id:HonMarkHunt:20180120145314j:plain

登壇者

twitter.com

TL;DR

  • ブラーバを作る

方向転換する

  • モータードライバ
  • 前進と後進ができるようになった

f:id:HonMarkHunt:20180120150454g:plain

壁に近づいたら後進する

f:id:HonMarkHunt:20180120152056g:plain

所感

自分で掃除した方が早そう

Elastic Cloudを1年ばかし使ってみたレビュー的な

f:id:HonMarkHunt:20180120145040j:plain

登壇者

twitter.com

宣伝

hackathon.val.jp

TL;DR

経緯

  • 障害対応、顧客サポートでELBログを可視化したい
  • ElastiSearchとKibanaよさそう
  • ElastiSearchは管理が大変...
  • Amazon ESとElastic Cloudとの比較

状況

  • 要求: 管理に時間がかからないこと
  • ほぼAWSの構成

比較

f:id:HonMarkHunt:20180120145531j:plain

Amazon ESのメリット

  • 他のAWS製品との親和性が高い
  • IAMでのアクセス制限
  • VPCの対応
  • Kinesisとの連携

Elastic Cloudのメリット

  • ESと同社が作成しているので対応がきめ細やか
  • X-Pack標準搭載
  • クラスタのバージョンアップが容易 違いはそんなになかったがバージョンアップやESの使い勝手からElastic Cloudを採用

結果

  • 安定している
  • version up対応もスムーズ
  • 不満な点は特になし

所感

  • うちはlogentriesです

入社までにやっておきたい事, 入社してすぐにしたい事

f:id:HonMarkHunt:20180120152031j:plain

TL;DR

  • 入社初日から活躍するためにやっておきたいこと

準備しておきたいこと

  1. ビジョン・行動指針の把握
  2. 技術面のキャッチアップ
    • 公開されている記事や動画には目を通す
    • 使用しているライブラリ使ってみる 
  3. ビジネス視点でサービスさわってみる
  4. 中の人とご飯に行く 
    • 事前に親睦を深めておく
  5. お引越し
    • オフィス側に引っ越せるなら是非
  6. ビットコイン買っておく
    • みんなやってるから

最初は...

  • 最初の一ヶ月は「なんでも聞いていい魔法の時間」

入ったあとやりたいこと

  1. ひたすらストーキング
    • Slackの過去ログ
    • ドキュメント, PR
    • 闇雲でなく脳内にインデックスをつくっていく感覚
  2. 内容じゃなくて背景を知る
    • How Why
    • なぜこうなっているのかを意識する
  3. ビジネスドメインの理解

まとめ

  1. ストーキングしよう
  2. Whyを理解しよう
  3. ドメインを理解しよう

~歴史から学ぶ~ スニーカー基礎講座Ⅰ

登壇者

twitter.com

僕です

スライド

docs.google.com

【読書メモ】Scala関数型デザイン&プログラミング 1章 関数型プログラムの基礎

概要

Scala関数型プログラミングを学ぶ本。 関数型と聞くと「ウ"ッ」っとなるプログラマーだが、会社で輪読会のお誘いがあったのと、対象読者が「Javaばっかしやってた人」だったのでなんかできそうだなと思い読んでみことにした。継続的にkotlinをやっているのでScalaで関数型を学べるならこれ幸い。という気持ちもあった。

今回は、1章:関数型プログラムの基礎 のまとめ。

隔週で輪読会をやっているので(可能であれば)毎回ブログにまとめていく

TL;DR

式eがあり、すべてのプログラムpにおいて、pの意味に影響を与えることなく、p内のすべてのeをeの評価結果と置き換えることができるとしたら、eは参照透過です。関数fがあり、式f(x)が参照透過なすべてのxに対して参照透過であるとしたら、fは純粋関数です。

1. 副作用とは

  • 関数型プログラミング -> 純粋関数だけを使ってプログラムを構築すること
  • 純粋関数 -> 副作用のない関数のこと
  • 副作用 -> 単に結果を返すこと意外に何かする関数

副作用の例

  • 変数を変更する
  • データ構造を直接変更する
  • オブジェクトのフィールドを設定する
  • 例外をスローする、またはエラーで停止する
  • コンソールに出力する、またはユーザー入力を読み取る
  • ファイルを読み取る、またはファイルに書き込む
  • 画面上ここに脚注を書きます))描画する

副作用を持つコードの例

副作用

2. 副作用の排除

  • buyCoffeeの際にトランザクションを発生させたくない
    • テスタビリティー
    • 再利用性
  • Chargeを返すように修正
  • n杯のCoffeeの購入に対応したbuyCoffeesを作成
  • ワンライナーでまとめられるよ!

副作用排除

3. 参照透過性

  • どのようなプログラムにおいても、プログラムの意味を書き換えることなく式をその結果に置き換えることができる
  • intToString(5) の結果を呼び出し元において"5"と置き換えても正しく動作する。てきな

  • これは参照透過なのだろうか?

  • chargeはUnit

    • buyCoffeeの戻りはnew Coffee()と同等
    • つまり、buyCoffeeの呼び出し元を全てnew Coffee()と置き換えても、正しく動作(影響を与えない)しなければならない
    • この条件が満たされないので上記buyCoffeeには参照透過性がない。といえる

置換モデル

  • 参照透過性では、関数が実行する全てのことが戻り値によって表される <= 普遍条件!
  • 関数を全て結果に置き換えても同じように計算が進められる。
    • 等価による置換
    • プログラムの等式推論がなりたつ(意味不明)

純粋性

  • 参照透過性が担保されるとめっちゃモジュール性高い
    • 合成可能

4. まとめ

  • 関数型プログラミングとは副作用のない純粋関数だけを用いてプログラミングすること
  • メリット
    • モジュール性向上
    • 推論の容易可

builderscon 2017 でLTしてきたぞ!の感想とか

はじめに

2017/08/03~05で開催されたbuilderscon 2017で、LTをさせて頂いたのでそちらの感想と来年にやる方への向けて何か残せればと思い記事を書きました。

builderscon.io

決してコアスタッフの方々に圧力をかけられたからではありません。

f:id:HonMarkHunt:20170807104224p:plain

f:id:HonMarkHunt:20170807104058p:plain

登壇までの流れ

  1. 7/20 申し込み(締め切りは7/30迄)
  2. 8/3 採用発表
  3. 8/4 登壇

登壇した感想

  • 当日はメインホール400人会場😥で5分LTをやらせていただきました f:id:HonMarkHunt:20170807122128j:plain
  • ステージ下に順番に並んで前の人が終わったらすぐ次の人はい次!という感じで完全5分切り替え制でした。割とカンファレンスのLTってそういう形式が多いですね。
  • 自分は5番目くらいでしたが、前の人達が全員信じられないほど大爆笑をかっさらっていたので、首を掻っ切って命を断とうかと思いましたが、なんとか発表できました
  • 発表中は緊張しすぎてなぜか会場を見ず、空条承太郎を彷彿とさせるポーズでスクリーンを見ながら発表し、マイクが遠くなって声が小さくなってしまいました。後で言われて首を掻っ切って命を断とうかと思いました。

ちょっと困ったこと

  • 実際申し込みから登壇してみて少し困ったことを書いておきます。

LTの採用・不採用がいつなのかわからなかった。

  • 上記の通り採用連絡が運営のツイッターから行われたのが前日でした。
  • 私みたいな無能エンジニアはスライド作るだけでも数日かかってしまうので、そもそもいつ採択が発表されるのかがわからない状況は少しキツかったです。
  • 前日発表するにしても、「LTの採択は前日に発表します。」と一言アナウンスがあるととても助かるなと思いました。

LTのプロポーザルが運営向けか一般向けかわからなかった

f:id:HonMarkHunt:20170807123907p:plain

  • LTの申し込み時に専用のページからLTの概要を記入するのですが、これが一般公開されるものなのか、運営が審査のために読むものなのかわからず少し書きづらかったです。
  • 書いた後に分かったのは、LT終了後に一般公開されるものということでした。ですが、登壇前にカンファレンスアプリから普通に見えたような気がします。
  • こちらは「そもそもプロポーザルってそういうものだから」とかそもそも私の勘違いなどでしたら喉を掻っ切りますので教えてください。

やってよかったこと

勇気がついた

  • あの大人数の前で登壇するのは私のような底辺エンジニアには中々ない機会でしたのでなんか色々すごいよかったです。

自分のダメなことがわかった

  • 本番は練習以上のものはでない。とよく言いますが、まさにそんな感じでした。
  • スライドの作り, 声の出し方などダメなところがよくわかりました。

最後に

  • 私は以前HTML5 Conferenceのスタッフをやらせていただいたことがありますが、buildersconは3日間開催、スポンサー用のアメニティー、カンファレンスアプリなど考えて、準備と当日運営が死ぬほど大変だったんじゃないかと思いまいした。
  • このような貴重な機会をいただきスタッフの皆さん本当にありがとうございました!!&お疲れ様でした!!
  • また来年も楽しみにしています。

発表資料はこちら

www.slideshare.net

Twitterもフォロー待ってるぜ!

twitter.com