プレパタをDevLove甲子園日本シリーズの発表にどう取り入れようか考えてみた
１２月６日に東京でDevlove甲子園日本シリーズDevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜 - DevLOVE | Doorkeeperというところで、発表させてもらう機会を頂いきました。前回の再演を行うつもりで、全く同じ気持で発表しても自分は成長しないなと思ったので、今回プレゼンテーション・パターン（以下、プレパタ）を幾つか導入してみようかと思います。
プレパタとは、こういうものです。
プレゼンテーション・パターンは、「創造的プレゼンテーション」の秘訣を言語化したものです。創造的プレゼンテーションには、想いが凝縮されたメッセージがあり、聞き手の想像力をかきたて、新しい発見をもたらす工夫がなされています。そのようなプレゼンテーションのデザインにおける視点や方法をまとめたものが、プレゼンテーション・パターンです。
by プレゼンテーション・パターン (Presentation Patterns)
IT分野の人にかぎらず、なにか発表などをする機会があるすべての人におすすめの内容なので一度読んでみることをおすすめします。無料でPDFのダウンロードも出来ますし、本でも販売してます。
プレゼンテーション・パターン
プレゼンテーション・パターン (Presentation Patterns)
この中から、幾つかピックアップして、どう導入するかをjust ideaで書きなぐってみました。
そもそものDevLove2014日本シリーズの(おれの)発表のゴール
今回の
- 聴き手に新しい発見・発想を与えれるようなチップスを散りばめたい。（意識的に）
- 聴き手に再認識を起こさせ脳の活性化を起こすこと（すでにこのスライドを見たことある人もいると思うので、その人にスルメ本を読んだような２度目の発見を与える）
そもそものこのプレゼンのメインメッセージ
- 同じような現場で困ってる人への、解決への糸口を作る。
- コーディングの意識の知識と必要性を伝える（リーダブル）
- きれいなコードを書きましょう（って言いたい）
- そのコードはあなた一人のコードではないのですよ。（って言いたい）
という上記のゴールを掲げた上で、プレパタのいくつかのパターンを使おうと考えています。
プレパタ
「内容・表現」に関するパターン
メリハリ
今回は話し方においてメリハリを考え、伝えたい部分を強調する。
例えば、聴き手に聞いてほしいことを言う前に一言開ける。そして、小さめに低めに言う。もしくは、大袈裟に言う。など。
はてなの扉
謎が解決していく爽快感を味わってもらう。
何のためにリーダブルコードがあり、引き継ぎを意識してもらわないと行けないのかなどへの発見を言葉の端々に散りばめて常に、「なるほど」「たしかにそーだね」って言う、発見を連続させる。
「魅せ方」に関するパターン
リアリティの演出
この発表の味噌は俺の現場にリアリティを持ってもらうことで、より当事者意識で発表を聞いてもらうこと。あたかも、そのチームで聴き手が同じ悩みを持ってますと思ってもらえるような話し方をする。
「振る舞い」に関するパターン
キャスト魂
発表者であることを意識してTEDみたいに。間のとり方など、どうやったら伝わりやすい話し方になるか聴き手に発見を与えれるかを、考えながら話す。
ひとりひとりに
一人一人に発見を与える気持ちで。発表中に聴き手の顔を、見る。むっちゃ見る。
ドン引きされるくらい見る。
“ 世界 ” への導き
聴き手が一緒に発表を作っているということを無意識にさせる。（難易度たけー）
野次機能で、参加しやすいような雰囲気ができればいいな。
聴き手のtwitが話すことに影響を与えるということができれば、成功。
即興のデザイン
野次機能を使う予定なので、その場でどんなコメントが飛ぶかを大事にして、話す内容をフィットさせながら、聴き手を楽しませる。
以上の目標を意識して登壇する。せっかくの大舞台で話すんだから、ひとつくらい成長したいな。
人にモノを教えるときにしてる３ステップ
こんばんは、ウィスキーが美味しい季節ですね。
秋で美味しいものがたくさんでてきた季節だから思うこと。
人にモノを教えるときに
自然とやってることがあるな～って思って、ブログにまとめてみた！
自分で新しいことをする時、人にモノを教えるときにやっていること。仕事でも、プライベートでも。
ベースはこういうこと
「新しいことを経験する際に、ちゃんと知り、考える」
3ステップ
- 「なぜ」をちゃんと「知る」 (教える)
- 歴史、背景、過程、ストーリーとか
- その「なぜ」を「意識して」体感する (経験させる)
- 「なぜ」や「良さ」を自分でも考える (どうとらえたかを聞く)
これの例を料亭で同じことをしてるなって思ったので書いてみた。
（たぶん、同じような経験が皆さんあると思うっす）
料亭にて
料亭だと料理が出てくるときに、料理名とその料理の説明があったりすると思います。
鱧は梅雨の時期の雨をたっぷり吸ってると、無類の美味しさになるんですよ。
また、鱧の旨味と、梅肉や酢味噌の酸味が、絶妙に合いますので、お好みでつけてお召し上がりくださいね。
みたいなやつです。（昔聞いたことを思い出して書いてます）
1.なぜをちゃんと知る (教える)
これにより
- なぜ美味しいのかっていうのを、「梅雨明けシーズン」
- なぜ梅肉や酢味噌がついてるかというのを、「鱧の旨味と酸味が相性が良い」
っていうのを、知ることができます。コレにより、鱧を食べるときに「意識」することができます。
2.体感する (経験させる)
それから鱧は旨いのか、本当に梅肉や酢味噌が合うのか「意識」して、食べます。
3.良さを自分でも考える (どうとらえたかを聞く)
そして、食事の最後に
店「鱧はいかがだったでしょうか」
客「僕は、そのままよりなにかつけたほうが好きだね。梅肉が一番合うよ！」
なんて、会話があり、お客さんは鱧には梅肉が一番自分に合うという経験を意識します。
結果どうなる？
これらの流れにより、鱧の味や食べ合わせを意識することにより、ただただ食べるよりもよりも、美味しく楽しんで食事をすることができると思います。。
また、次に鱧に出会った時に、その時の話を思い出して、「この季節だから美味しい鱧だな！」「梅肉をつけて食べると旨いんだよな」っとか、その時の経験が次に活かされて、「より鱧を楽しめる人」になると思います。
仕事的にやってること
プログラマで、なにかを教えるときに気をつけていることは
- メンバーになぜこの「やり方」でこの「技術」で今やってるのかをちゃんと伝える。
- それを実践する機会を作る。
- 実際に、使ってみてどうだったかを、定期的に聞く。
なんてことです。メンバーも仕事をするときに意識することが増え、多様性のある仕事をできるようになっているのではないかと思います。
まとめ
普段から、自分が納得できなくて理由を調べる癖。そして、人に教えるときは理由や背景から教える癖があります。それをポジティブに使ってみると、こういう効果があるなーって思ったので、今日はまとめてみました。やはり、大事なのは「きちんと知り」「意識して行い」「自分の感想を持つ」ということを、教えられる側に経験させることなのかなと思います。でも、１０年後とかに、この考えは甘かったなーって思うんだとは思うが、それはまた先の話じゃ( ・∀・)ﾉ
感想文「プログラマが知るべき９７のこと」
この本を読んで思ったことをツラツラと徒然なるままに。
読んで思ったこと。
この本はいろいろなプログラマの考え方を知るきっかけ。
設計してる人から、研究分野の人、ツールを促進する人、批判する人などなど。
読んだ後に、得られるメリットは
いろいろなエンジニアと軽くおしゃべりした後に受ける刺激みたいなもの。
経験を積んだ人と話すと、この人の考えは同調できるって人と、自分とは全然捉え方が違うなって瞬間があると思うんすけど、９７人＋αの視点で書かれてるので、中身のほとんどが、後者の内容。
なので、そういうことを
「面白いな、自分とは違うなー盗めないかなー」
ッて思う人には面白いし。
「おれはこういう考えだ。これは違うと思う！」
って、人には、退屈な本かなって思った。（僕の周りのこれを読んだ人の雰囲気だと）
中でも刺激を受けて、現場で実践してるもの
- コードレビュー
- 単一責任性原理
コードレビューで取り入れたこと
前のブログでも触れたけど、
プログラマが知るべき97のこと 「14.コードレビュー」 - だいごろうのブログ
実践してるのは、各人のレビューの役割を与えるとどうなるかってこと。
今ん所、うまく機能していて、レビューに対して薄れがちな責任感が生まれるので、今まで、コメント全然しなかった人が、担当範囲は死守するみたいな流れが生まれている。で、付加価値としてその人がレビューにコメントをすることに対して抵当がなくなっている。
（とはいえ、不安なので、僕は担当範囲を超えてコメントしてるw）
単一責任性原理とはなにか
これはプログラミングのやり方、考え方の話ですね。SRPっていうらしいです。
１つのサブシステムやモジュール、クラス、
関数などに、変更する理由が２つ以上あってはいけないRobert C. Martin
この言葉の通り、すべてのコンポーネントは独立してデプロイ出来るということ。
まぁ、文学的に正しくは理解してはないんですが、大事な考え方かなと。
今、現場で、コーディングするときには、クラスとかモジュールにはひとつの機能しか載せないように、検討しながら進めています。
最後に思ったこと
みんなが本に期待するようなこと
- 求めている知識の深堀り
- 共感すること
は、この本には求めない方がいい
どっちかというと、
- 気付き
- 知らない世界を垣間見る
って感じで読んだら面白いかな。
一つでも面白そうだなって思える内容があればいいか、くらいの気持ちで読む本かなと。
ポーランド記法の電卓のパーサをHaskellで書いた
９月といえど、まだまだ外は暑いですね。
子どもたちが公園で遊んでる声で起きました。まだ夏な気がします。
Haskellを初めて触ってみました。
超初心者。関数型言語も。
詳細な書き方の理解は全くなく、
イロイロなものを組み合わせてだんだん動くようになったから
生意気にもブログを書いてる感じです(｀・∀・´)ｴｯﾍﾝ!!
なので、細かい技術の話は、参考文献の方々のモノを読んでくださいね( ・∀・)ﾉ
とりあえずソース
daigorowhite/PNDentaku · GitHub
{-# LANGUAGE OverloadedStrings #-} import Control.Applicative import Data.Text(pack) import Data.Char (ord) import Data.Attoparsec.Text import Data.Attoparsec.Number import System.Environment (getArgs) -- Exp型？の定義 data Exp = Add Exp Exp | Sub Exp Exp | Mul Exp Exp | Div Exp Exp | Nat Int deriving Show -- プログラムの文法 １つ以上の式 prog = many1 expr -- 式の文法 足し算、引き算、掛け算、割り算、数字のどれか expr :: Parser Exp expr = add <|> sub <|> mul <|> divi <|> num -- 足し算の文法 "(+ EXP EXP)" add :: Parser Exp add = Add <$> ("(" *> ("+" *> (spaces *> expr))) <* spaces <*> expr <* spaces <* ")" -- (中略) -- 同じように引き算、掛け算、割り算を書く -- 数字の文法 "Num" num :: Parser Exp num = Nat . read <$> many1 digit -- 複数のスペースの文法 spaces = many space -- 引数をパースして出力する main :: IO () main = do args <- getArgs; print $ parseOnly prog $ pack $ concat args
技術的に
- Attoparsecというものを使ってパーサを書いてる
- 記法を簡単にするために、Applicativeというものを使っている
じゃあ、やってみよう
とりあえずコンパイルする
% ghc dentaku.hs [1 of 1] Compiling Main ( dentaku.hs, dentaku.o ) Linking dentaku ...
実行ファイル( dentaku )ができるので
これを使ってパースしてみる
% ./dentaku "(+ 1 1)" Right [Add (Nat 1) (Nat 1)]
できたー。
Addが自然数１を２つ持ってる。
後は、ロジックを実装すれば、立派な計算機として動きます。
時間あれば、＋の部分を関数名にして、
ロジックで足し算とか分けていけたら、Lisp系の言語ができそう。
haskellの感想
- そもそもhaskellの文法を理解しないとだめだなー
- letとか、関数渡しとか、オブジェクト脳には、何がなんやら。
- 全体的に、なんか、動いた。。。ってことが多い（初心者すぐる）
- とはいえ、よく知ってる言語よりも動いたらうれしー。（よその猫が膝に乗ってきた感じ
次はちゃんと、haskellの書き方を理解しよう(ﾟдﾟ)！
インスピレーション受けたやつ
様々な、人とブログと勉強会から刺激を受けています。
スペシャルサンクス
- 発表をしていた@fujiyan18さん
https://gist.github.com/fujiyan/e1b58d3d447843509477
- その勉強会を企画した@kazuhito_mには特に感謝っす。
- プログラム中に僕を支えたハンモック
- 居心地がよく集中力を来れた。グランフロントのCafe.Lab.
メソッドの命名で主語を気にしていること
読み易いなーって思うメソッド名の付け方
最近、コード書くとき、どの視点からなのか、英語の文法的に読み易いのかってのを意識してメソッド名をつけてる。（オブジェクト指向で。関数型だと当てはまらないかも）
同じことをするメソッドを両方から見てみる
例 > オブジェクトを生成、変化、抽出
例えばcategoryって言うクラス(もしくはenum)があって、カテゴリは数字で分けられてる場合
# 前提:DB上で1はオモチャというカテゴリ # 生成> 1という値のカテゴリを取得する Category.of(1); Logic.pickupCategoryBy(1); # 変化> オモチャカテゴリをDBで表現する値を取得する toyCategory.toDBVal(); Logic.convertToDBValFrom(toyCategory); # 取得> オモチャの商品のリストを取得する toyCategory.getItemList(); Logic.getItemListFrom(japanCategory); # 抽出> 女の子向けの商品を抽出する toyCategory.forGirls(); Logic.extractForGirlsFrom(toyCategory);
こんなかんじでまとめることで、英語の文を書くようなプログラムを書いてる
（気になれる）
組み合わせてメソッドを作ってみるとこんな感じ。
# LogicClass /** * 指定の商品が、対象のカテゴリに含まれるか * @param categoryId 対象のカテゴリID * @param targetItem 指定の商品 * @return 含まれるならtrue **/ public boolean includeItemIn(int categoryId, Item targetItem){ Category targetCategory = Category.of(categoryId); List targetItemList = getItemListFrom(targetCategory) return targetItemList.has(targetItem); }
こんなかんじですかね。
読みやすいですかね？読みにくいですかね？
僕は、けっこう、読みやすいと思うます。
Developer Summit 2014にいってきました
聞いてきたのもの感想とか、簡単なまとめをする備忘録
印象に残ったものだけね。
S1.この『物語』は、ぼくが歩き出す物語だ。肉体が……という意味ではなく、エンジニアとしてという意味で……
僕の感想としては、自分の視野を大きく超えたストイックなエンジニア。
そんで、自分がこういうエンジニアっていいなって、業界に入る前に思ったモデルみたいな人でした。ほんとに、エンジニアとして仕事をしたい人すべてにこの資料を見て欲しい。
B1.Webデザインと開発の未来
世界のwebサービスとかがどんどん出来るようになってきた。
物事は、使い回しが出来るようになっていくんじゃないか。
- レスポンシブからリアクティブなものになっていく
- コンポーネントで使い回しできるものになっていくかもしれない
- 世界のサービス作成スピードやばい
betalist：betalist.com
producthunt：producthunt.com
なので、ムダに頑張らない。自動化出来るところはフレームワークに任せる。
デザイナーが、プログラマが。ってのがなくなってきている。
本当に、いい時代なんだになってきたんだなと思った。
エンジニアとして、技術は良いものとして、
別観点として、プロダクトに少人数で集中できる環境がどんどん整ってるんだな。
最後に、「やらないと変わらない」
A2 .企画 - 計画 - 開発 - ビルド - デプロイ～価値のパイプラインできてますか？
お話としては、企画からデプロイまで一貫したパイプラインが重要である。
ツールで企画-計画-開発-デプロイのすべてのフェーズでプロダクトへ同じ方向性で認識を持って、進めることが出来る状態にすることが大事って話だったかなと。
個人的にはAtlassianの製品はどれも好きで、
すべてが一貫していて、チケットに要件を書けば、すべてがそこから動き出す。
そこらへんを少しだけ知っていたので、かなり面白い話だった。
Confluence - Jira - Stash - Bamboo - Hipchat
の連携は、５０００円(一つ１０００円)で試せる割には強力かなと。
AtlassianTシャツももらった( ・∀・)ﾉ
あとやりたいことメモ
- JiraからGitのBranchを作ること
- Cofluence QAを社内で流行らせること。（そもそも使えるかな？
A3.プロジェクトを成功させるための「期待マネジメント」
我らが中村さんの発表。やっぱり面白かった。
チームで導入すれば、もっとお互いのことがわかり、開発が順調になるなーってほんとに思った。現場って大事。チームって大事。
以下、発表スライドから、響いた言葉をピックアップ
正しいことを正しくやる
やりたいことをやる
誰とするかが大事
インセプションデッキの自分事と捉えるための１１個目
自分がお金を出すとしたら、同じやり方をしますか？
「正しいものを正しく作る」
を探していくことが自分のStor
このセッションではなかったけど、DevLoveの
現場を変えるまでがDevloveです
みたいな、よーさんのセリフはかなり、印象的でした。
