タグ別アーカイブ: アジャイル

情熱プログラマーを改めて読み返してみました


3年前に購入した情熱プログラマーを今日改めて読み返してみました!やっぱりこの本は僕の原点となる本です!!
自分の考えていることであったり、大事にしていることが全て網羅されている用な感じです。

プログラマだけにとどまらず、非プログラマの人もとても参考になるところはあると思います。単純なHowTo本ではなく、プログラマとして、社会人として、仕事への取り組み方をとても分かりやすく語り口調で書かれています。監訳者の方が素晴らしいのかもしれないですが。。。

また、最後の項が「楽しもう」というタイトルとなっている所が粋ですねー。
単純にモチベーションが上がったなーー!! 作ること、プログラミングすることをこれからも楽しんでやっていきたい!!

DevLOVE関西2012Drive へ参加した


ちょっと遅くなったのですが、DevLOVE関西2012Driveに参加してきたので、メモったことやその都度思ったことをまとめてみたいと思います。

「開発現場を、駆動せよ。」
というサブタイトルに引きつけられて、DevLoveに初めて参加しました。
基本的には、今興味のあることとして技術部門のセッションを聞いてきました!
開催日:2012年11月10日(土)


乙女ゲーを支える技術 – play2.0 + Scala の開発事例 –

粕谷さん(@daiksy)
利用技術:scala、Play2.0、Squery、MySQL、Git

基本的にはScalaでソーシャルゲームを開発したという内容で、Scalaは個人的に興味深々の分野で内容はとてもおもしろかった。
ScalaでWebアプリを作成する時のWebフレームワークはPlayフレームワークの1択とのことでした。

・始業前勉強会を行った
コップ本論読(Scalaの本) 
scala,Gitなど初めて使用する技術だらけだったので、朝の始業前にメンバーで勉強会をやっていたとのことです。

・一部scalaの書き方
「var」 再代入OK
「val」 再代入NG(再代入NGってのが関数型っぽい)

if文も関数なので値を返す。
以下のようにしてif文の条件でマッチしたらtest_valueという文字列を返す。

val huga :String = if (hoge>0) { "test_value" }

保守はしやすい
コード量が減り、見通しが良い(少ないコードのほうが保守しやすくなる)

【感想】
朝にチームで勉強会していたっていうところがいいなーと思った。
自分の現場でもこういう部分は取り入れていけたらいいなーと思う。


CIの何か

@kiy0taka さん

JenkinsのJobが遅くなってきた時の対処法

−パイプラインを使う
Build Pipeline Plugin
・一連で動作させていたjobを分割する (チェックアウト・コンパイル、テスト、チェックスタイル、findbugs)
チェックアウト・コンパイルのjob、テストのjob、チェックスタイルのjob、findbugsのjobそれらを
Linuxのパイプラインでつなぐようにjenkinsを実行する
・(重要)1個目のチェックアウトでビルドしたリビジョンをその他のjobでも使用するようにする。
取ってきたリビジョンをアーカイブする。Clone Workspace SCM Plugin

Promoted Builds Plugin
・buildのチェックを可視化する。各ビルドを総合して成功している場合はスターを付ける。
(ビルド、テストに依存関係をもたせられるってことかな?! 依存する全てが成功していたらジョブの成功(チェックOK)とする)

【感想】
Jenkinsは個人的にまだ使っているわけではないけど、今のプロジェクトで一部使用しているので、いろんなプラグインがあってとても参考になったー!導入できるものとかを精査してちゃんと使っていこう。


なぜ私はソニックガーデンのプログラマに転身できたのか?

@JunichiIto77 さん
プログラマーを一生の仕事にしたかった。

【それまでにやっていたこと】
ブログを書いていた
継続的に勉強していた
特定の技術に偏らないようにしていた
どの職場でもそれなりに認められていた
美しいコードが一番と考えていた

【ソニックガーデン採用方針】
半年くらいかける・コードを見る・一緒に働く

【選考期間中にやったことを振り返る】
素早く行動に移した
毎週必ず進捗報告した(出来たという報告だけでなく、全てにおいて報告した)
「郷に入れば郷に従え」を意識した。(ソニックガーデンの流儀に合わせるように努力した)

【感想】
プログラマとしての考え方はとても近いものがあったなー
共感出来る所がとても多かった。そして、これまでに300冊以上の本を読んできたっていうのはすごい尊敬できるー


まとめ

最後のセッションは別の予定があって参加できなかったのですが、こういうアジャイル開発の大きなイベントは初めての参加だったので、とても刺激的だった。
もっと自分も本を読んだり、コード書いたりしていこうと思う。

もっと、もっと、!!!

[読んだ−]リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)


読みました−

読みやすいコード! ほんとこれが理想。。
サンプルやコードの目的を持ってコードを書くことの意味など。
純粋に参考になったー!

詳細な設計書もないようなスタートアップのプロジェクトなど、
わかりやすいコードを書くことが一番の設計書になると思う。

コードを読めば何をしているか一発でわかるような、属人化しないようなプログラマになろう!!
レビュー by ブクログ

[読んだー]ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵


 

ピープルウエア第2版、読みました。


http://booklog.jp/item/1/4822281108

 

  • レビュー
その名の通りシステム開発の現場を人に焦点を当てた管理や手法に関する内容だった。働く環境や働く人のメンタルなどとても参考になった。
良いチームを作るというところで、

「チーム編成の目的は目標の達成ではなく、目標に向かって一体

になることである。」という内容の一文があったが、これにはとても共感できた。

作業という一つのタスクは、基本的に一人でやるものだけど、
一人にはないチームで働く事の意味はこのことだと思う。

近くに同じモチベーションの人がいることで、いろんな意味で相乗効果が生まれると思う。 いいことばかりではないとも思うが。。。

 

 

 

IT業界に言われることを考察してみた(3Kなど)


いやいやー昨日はIT系の花見で飲み過ぎて頭痛に見舞われていました。IT系と言ってもWebやスマホの比較的中小企業が多くなっているので、普通におしゃれな人や女性もいました!!デザイナーやディレクターなどの立場の人も多いからいろんなジャンルの人が多く、楽しい花見でした。。

という前置きから、若干真面目なITに言われている3Kなどについて最近思うことをまとめてみます。

3K「きつい・きたない・帰れない」(注 この定義はその他にも色いろあるようですが「給料が安い」など)

とIT系の職業を象徴するように言われていますが、僕自身はそんなことないと思います。確かに急な不具合・障害で帰れないことやきついと思うこともよくあります。しかし、それってよくよく考えてみるとどこの業界でも同じではないでしょうか!?

ITにかぎらずどこの業界でもミスや失敗をしたらその責任を取らなければならないでしょうし、プロジェクトに問題が発生したらその間は残業も増え、帰りた打ても変えられないという状況が発生すると思います。

その中で、IT系だけ3Kと言われ続けるのはなぜなんでしょうか。僕自身が思うのは「程度の差」ではないかと思うんです。

ITの仕事は基本的に単価が高い。(特に基幹業務などSI系の請け負う仕事は億単位) 最近も行政機関のシステム開発事業が失敗し、開発を中止したというニュースもありました。それも数億円投資したのがすべてなくなったということです。このようにお金の単位が大きいからニュースでも取り上げられやすいし、デスマーチプロジェクトが多いと言われてしまうのではないかと思うんです。その他の業界でもデスマーチのようなプロジェクトはあるのに取り上げられていないということではないでしょうか。

それを決定的に感じたのが、自分が別業界でアルバイトしていた経験や、知人から聞いたIT以外の業界の話を聞いたことでおもいました。

最近聞いた話で貿易系の会社での出来事です。

その事業所ではある企業が元請けとしてメインで仕事をしており、他の数社に下請けとして仕事をお願いし回している職場環境です。その下請け企業の1社であるミスが発生したようでした。それはその下請け企業の責任者がしでかしたミスだったようです。しかしその責任者は自分のミスを部下に当たり散らし、部下も見覚えのないことをガーガーと言われて怒って仕事を放棄し帰ってしまいました。さらにその上司も当たるだけ当たり周りにガーガー行った挙句、やめると言って帰ってしまったようです。その責任をとるのが元請けの会社のリーダーの人が関係各所にお詫びの電話をしていたとのことです。

そこには責任のかけらもありません。。ITはよくプロジェクトが失敗して上司が次々にやめ破綻するということもよくあると聞きますが、別にIT系以外でも上記のことがあります。

最近ツイッターとかでも「ITはだめ」「ITは早く辞めたい」「ITのプロジェクトは失敗ばかり」とつぶやく人もいて、ITをやめたら全て解決できるように言っているように感じます。僕はそうじゃないと思っています!!

別の業界でも同じような問題は少なからず発生しているし、かつ別の業界はそれをこれからのプロジェクトで解決するということをあまり考えてないとおもいます。企業単位では失敗したことに対して改善策などを出しているところはあるとおもいますが、IT業界のようにアジャイルなどのようにプロジェクト管理の方法を最考察したり、色々なツールを実践したり積極的に業界としていろんな取り組みがされていることはすごいと思うし、それがITの魅力だとおもいます。

また、よくアジャイルを実践しただけではうまくいかないとか、ツールを入れるだけではうまくいかないとか言われることもあります。

しかし、新しい手法の勉強会や講演などを開いているのもIT系だけだと思うし、それを1年に1回の大きなイベントだけではなく小さな単位でそれぞれのコミュニティが実施しているのもIT系だけだとおもいます。失敗したことや悪いことを解決するための手段を常に新しい方向で前向きに考えていることは本当にIT企業しかないのではないでしょうか。

その意味でもITは最先端をいっていると感じます。

ということで文章力のない僕がこの中で言いたいことをまとめると、以下の4つです。

3KはITだけではない!

ITをやめたいとか、だめとかそれをいうだけ、やめてしまうだけでは何も解決しない。

ITは失敗していたことを良くしようと次の手段を次々と生み出している。

これからのプロジェクトは良くしようと考えている人が多くいる!

です。

実際の現場は全部上記のようにいいことばかりではありません。変な上司や何を考えているかわからない会社の上層部の人もやっぱりいますが、それはIT系だけじゃないし、どこの業界でもいるんだということです。

ITは3Kだーー

女性はいないーー

とかいうファーストインプレッションをなくしていけたらいいなーと思いましたーー。