人にモノを教えるときにしてる3ステップ
こんばんは、ウィスキーが美味しい季節ですね。
秋で美味しいものがたくさんでてきた季節だから思うこと。
人にモノを教えるときに
自然とやってることがあるな~って思って、ブログにまとめてみた!
自分で新しいことをする時、人にモノを教えるときにやっていること。仕事でも、プライベートでも。
ベースはこういうこと
「新しいことを経験する際に、ちゃんと知り、考える」
3ステップ
- 「なぜ」をちゃんと「知る」 (教える)
- 歴史、背景、過程、ストーリーとか
- その「なぜ」を「意識して」体感する (経験させる)
- 「なぜ」や「良さ」を自分でも考える (どうとらえたかを聞く)
これの例を料亭で同じことをしてるなって思ったので書いてみた。
(たぶん、同じような経験が皆さんあると思うっす)
料亭にて
料亭だと料理が出てくるときに、料理名とその料理の説明があったりすると思います。
鱧は梅雨の時期の雨をたっぷり吸ってると、無類の美味しさになるんですよ。
また、鱧の旨味と、梅肉や酢味噌の酸味が、絶妙に合いますので、お好みでつけてお召し上がりくださいね。
みたいなやつです。(昔聞いたことを思い出して書いてます)
1.なぜをちゃんと知る (教える)
これにより
- なぜ美味しいのかっていうのを、「梅雨明けシーズン」
- なぜ梅肉や酢味噌がついてるかというのを、「鱧の旨味と酸味が相性が良い」
っていうのを、知ることができます。コレにより、鱧を食べるときに「意識」することができます。
2.体感する (経験させる)
それから鱧は旨いのか、本当に梅肉や酢味噌が合うのか「意識」して、食べます。
3.良さを自分でも考える (どうとらえたかを聞く)
そして、食事の最後に
店「鱧はいかがだったでしょうか」
客「僕は、そのままよりなにかつけたほうが好きだね。梅肉が一番合うよ!」
なんて、会話があり、お客さんは鱧には梅肉が一番自分に合うという経験を意識します。
結果どうなる?
これらの流れにより、鱧の味や食べ合わせを意識することにより、ただただ食べるよりもよりも、美味しく楽しんで食事をすることができると思います。。
また、次に鱧に出会った時に、その時の話を思い出して、「この季節だから美味しい鱧だな!」「梅肉をつけて食べると旨いんだよな」っとか、その時の経験が次に活かされて、「より鱧を楽しめる人」になると思います。
仕事的にやってること
プログラマで、なにかを教えるときに気をつけていることは
- メンバーになぜこの「やり方」でこの「技術」で今やってるのかをちゃんと伝える。
- それを実践する機会を作る。
- 実際に、使ってみてどうだったかを、定期的に聞く。
なんてことです。メンバーも仕事をするときに意識することが増え、多様性のある仕事をできるようになっているのではないかと思います。
まとめ
普段から、自分が納得できなくて理由を調べる癖。そして、人に教えるときは理由や背景から教える癖があります。それをポジティブに使ってみると、こういう効果があるなーって思ったので、今日はまとめてみました。やはり、大事なのは「きちんと知り」「意識して行い」「自分の感想を持つ」ということを、教えられる側に経験させることなのかなと思います。でも、10年後とかに、この考えは甘かったなーって思うんだとは思うが、それはまた先の話じゃ( ・∀・)ノ
感想文「プログラマが知るべき97のこと」
この本を読んで思ったことをツラツラと徒然なるままに。
読んで思ったこと。
この本はいろいろなプログラマの考え方を知るきっかけ。
設計してる人から、研究分野の人、ツールを促進する人、批判する人などなど。
読んだ後に、得られるメリットは
いろいろなエンジニアと軽くおしゃべりした後に受ける刺激みたいなもの。
経験を積んだ人と話すと、この人の考えは同調できるって人と、自分とは全然捉え方が違うなって瞬間があると思うんすけど、97人+αの視点で書かれてるので、中身のほとんどが、後者の内容。
なので、そういうことを
「面白いな、自分とは違うなー盗めないかなー」
ッて思う人には面白いし。
「おれはこういう考えだ。これは違うと思う!」
って、人には、退屈な本かなって思った。(僕の周りのこれを読んだ人の雰囲気だと)
中でも刺激を受けて、現場で実践してるもの
- コードレビュー
- 単一責任性原理
コードレビューで取り入れたこと
前のブログでも触れたけど、
プログラマが知るべき97のこと 「14.コードレビュー」 - だいごろうのブログ
実践してるのは、各人のレビューの役割を与えるとどうなるかってこと。
今ん所、うまく機能していて、レビューに対して薄れがちな責任感が生まれるので、今まで、コメント全然しなかった人が、担当範囲は死守するみたいな流れが生まれている。で、付加価値としてその人がレビューにコメントをすることに対して抵当がなくなっている。
(とはいえ、不安なので、僕は担当範囲を超えてコメントしてるw)
単一責任性原理とはなにか
これはプログラミングのやり方、考え方の話ですね。SRPっていうらしいです。
1つのサブシステムやモジュール、クラス、
関数などに、変更する理由が2つ以上あってはいけないRobert C. Martin
この言葉の通り、すべてのコンポーネントは独立してデプロイ出来るということ。
まぁ、文学的に正しくは理解してはないんですが、大事な考え方かなと。
今、現場で、コーディングするときには、クラスとかモジュールにはひとつの機能しか載せないように、検討しながら進めています。
最後に思ったこと
みんなが本に期待するようなこと
- 求めている知識の深堀り
- 共感すること
は、この本には求めない方がいい
どっちかというと、
- 気付き
- 知らない世界を垣間見る
って感じで読んだら面白いかな。
一つでも面白そうだなって思える内容があればいいか、くらいの気持ちで読む本かなと。
ポーランド記法の電卓のパーサをHaskellで書いた
9月といえど、まだまだ外は暑いですね。
子どもたちが公園で遊んでる声で起きました。まだ夏な気がします。
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 -- プログラムの文法 1つ以上の式 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が自然数1を2つ持ってる。
後は、ロジックを実装すれば、立派な計算機として動きます。
時間あれば、+の部分を関数名にして、
ロジックで足し算とか分けていけたら、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 .企画 - 計画 - 開発 - ビルド - デプロイ~価値のパイプラインできてますか?
あとやりたいことメモ
- JiraからGitのBranchを作ること
- Cofluence QAを社内で流行らせること。(そもそも使えるかな?
A3.プロジェクトを成功させるための「期待マネジメント」
正しいことを正しくやる
やりたいことをやる
誰とするかが大事
インセプションデッキの自分事と捉えるための11個目
自分がお金を出すとしたら、同じやり方をしますか?
「正しいものを正しく作る」
を探していくことが自分のStor
このセッションではなかったけど、DevLoveの
現場を変えるまでがDevloveです
みたいな、よーさんのセリフはかなり、印象的でした。
DevLove甲子園で使った野次機能を公開しました!
お疲れ様です!まだまだ、暑い夏が続きますね。
野次機能をgithubに上げました
DevLove甲子園西日本大会2014で使用した野次機能をGithubにあげました。
需要があるかは知らないけど。
TDD(テキトー駆動開発)だったので、ソースコードの良し悪しは気にしないでくださいw
ちなみに、こちらです。
https://github.com/daigorowhite/gayagya_cli
(ちなみにCliってついてるのは、もともとホストを建てて、データを集めようと考えてたので。ただ、クライアントだけで解決できるじゃんってなってしまって、クライアントのみになった。)
なにができるの
- ディスプレイ上に、twitterから拾ってきた文字を野次として表示できます
- プレゼンの際に、観客の意見を入れたいとき
- 画面にtwitterから文章を拾って表示したいとき
- 発表にちょっとした遊び心を入れたいとき
- 寂しくてディスプレイ上にだれかのつぶやきを出したいとき
-
ちなみに、こんなかんじに表示される↓ (「おはよう」で引っ掛けてます
必要なもの
- Java7以上でビルド出来る環境
- twitterのアクセストークン(developerに登録すれば発行できるはず
- gitとjavaとyamlに対する、微妙な理解
- 過度の期待を寄せないこと
- うまく起動しなくても、イライラしないスマートな心
- なにかあったら、ここのコメントに書くほんの少しの行動力
詳細は、Readme読んだらいいかなと。
あと、ニコニ◯動画風に文字を横に流す機能も実は実装してありますw
以上っす。
もし使ってみたら、一言ここにコメントを残していただけると嬉しいです。
追記:実行方法
コンソール編
- git cloneでソースを落とす
- mavenとjavaをインストール
- 設定ファイル(app.yaml)にtwitterのアクセストークン(詳細はgithub)を埋める
- 下記のコマンドをコンソールから実行
$ mvn clean package
$ java -cp target/gayagaya-1.0-SNAPSHOT-jar-with-dependencies.jar YajiYaji/YajiYajiApplet