感想文「プログラマが知るべき９７のこと」
この本を読んで思ったことをツラツラと徒然なるままに。
読んで思ったこと。
この本はいろいろなプログラマの考え方を知るきっかけ。
設計してる人から、研究分野の人、ツールを促進する人、批判する人などなど。
読んだ後に、得られるメリットは
いろいろなエンジニアと軽くおしゃべりした後に受ける刺激みたいなもの。
経験を積んだ人と話すと、この人の考えは同調できるって人と、自分とは全然捉え方が違うなって瞬間があると思うんすけど、９７人＋αの視点で書かれてるので、中身のほとんどが、後者の内容。
なので、そういうことを
「面白いな、自分とは違うなー盗めないかなー」
ッて思う人には面白いし。
「おれはこういう考えだ。これは違うと思う！」
って、人には、退屈な本かなって思った。（僕の周りのこれを読んだ人の雰囲気だと）
中でも刺激を受けて、現場で実践してるもの
- コードレビュー
- 単一責任性原理
コードレビューで取り入れたこと
前のブログでも触れたけど、
プログラマが知るべき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です
みたいな、よーさんのセリフはかなり、印象的でした。
DevLove甲子園で使った野次機能を公開しました！
お疲れ様です！まだまだ、暑い夏が続きますね。
野次機能をgithubに上げました
DevLove甲子園西日本大会2014で使用した野次機能をGithubにあげました。
需要があるかは知らないけど。
TDD（テキトー駆動開発）だったので、ソースコードの良し悪しは気にしないでくださいｗ
ちなみに、こちらです。
https://github.com/daigorowhite/gayagya_cli
(ちなみにCliってついてるのは、もともとホストを建てて、データを集めようと考えてたので。ただ、クライアントだけで解決できるじゃんってなってしまって、クライアントのみになった。)
なにができるの
- ディスプレイ上に、twitterから拾ってきた文字を野次として表示できます
- プレゼンの際に、観客の意見を入れたいとき
- 画面にtwitterから文章を拾って表示したいとき
- 発表にちょっとした遊び心を入れたいとき
- 寂しくてディスプレイ上にだれかのつぶやきを出したいとき
-
ちなみに、こんなかんじに表示される↓ （「おはよう」で引っ掛けてます
必要なもの
- Java7以上でビルド出来る環境
- twitterのアクセストークン(developerに登録すれば発行できるはず
- gitとjavaとyamlに対する、微妙な理解
- 過度の期待を寄せないこと
- うまく起動しなくても、イライラしないスマートな心
- なにかあったら、ここのコメントに書くほんの少しの行動力
詳細は、Readme読んだらいいかなと。
あと、ニコニ◯動画風に文字を横に流す機能も実は実装してありますｗ
以上っす。
もし使ってみたら、一言ここにコメントを残していただけると嬉しいです。
追記：実行方法
コンソール編
- git cloneでソースを落とす
- mavenとjavaをインストール
- 設定ファイル(app.yaml)にtwitterのアクセストークン（詳細はgithub）を埋める
- 下記のコマンドをコンソールから実行
$ mvn clean package
$ java -cp target/gayagaya-1.0-SNAPSHOT-jar-with-dependencies.jar YajiYaji/YajiYajiApplet
実家で休みながら考えたこと
これなに？
熊本に、４日間帰省したときに、プログラマとして、熊本人として考えたこと。
1、仕事の力加減
仕事をしているときは、8割くらいの力でやると良い。10割いくとだいたい、自分の受け皿が小さくなって、人の意見を聞けなくなる。なんで、「こんぐらいでまぁ行けるやろ」くらいの気持ちの方がチームも自分も、気持ちよくプロダクトに集中できて良い。
2、休息のバランス
どうしても、未知に挑戦するときは10割の力で行ってしまい成功失敗にかかわらず、脳が常に戦闘状態になってしまいがち。そうなったら、自分のため以上に周りのために、仕事のことを忘れる環境に身を置く。
3、母は偉大
おかんの作る飯は美味い。
4、温泉は1人で入る。
1時間くらい、ボケーっとすると意外と頭の中整理される。
5、失敗しよう
意外と周りは寛大。そんで、自分も人に寛大になる。
6、熊本城に行くときは宇土櫓に登れ
熊本城で唯一、復元ではなく、現存。
歴史を感じる。
さて。9月からも仕事頑張るばい！( ´ ▽ ` )ﾉ
プログラマが知るべき97のこと 「14.コードレビュー」
14.コードレビュー
読んだ感想をちまちまと書きます
チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立すること
ここにはかなり同意だなー。個人的にはコードレビューの意味はいくつかあって
- バグを見つける
- 読みやすさに対する客観性
- コード設計レベルを上げる
- ビジネスロジックに合ってるか（コーディングしてるうちにロジックの勘違いが起きてないか）
かなと。
友好的な態度を取るべき
辛辣な批判は絶対に避けましょう
も同意。
結局、人だからお互いのモチベーション維持が必要不可欠。楽しくコーディングしたいしね。
個々のレビー担当者の役割、権限はあらかじめ明確に決めておきます
ここら辺はやったことないなー。全員が全部見るって感じでやってるなー。意外と面白いかも。良いタイミングあれば、やろう。
コードレビューを成功させるために最も有効な方法は、レビューを楽しいものにすること
間違いなくそうやな。まぁ、コードレビューだけじゃなくて、設計からリリースまで、モチベーションのためにも楽しいってことはソースコードに、大きな影響を与えるよね。
