うさみみが2016年に読んだオススメ書籍と振り返り - うさぎ組
仕事 社内他チームをマネジメントしたり、Breaking Scrumしたりと挑戦しました。たのしかったです。 セミナーや新卒研修などにも携わり。ヴァル研究所様とお仕事できたのは素晴しい経験になりました。 また、 enPiT という文科省と各大学の連携でやっている「（僕から見ると）イケてるITエンジニアの卵つくろうぜプロジェクト」に関わらせていただきました。大学院生の教育に関われる日が来てよかった。これからも積極的にかかわりたいです。 株式会社オンザロードというか、僕へのお仕事の依頼はいつでもWelcomeなので kyon.mm あっとまーく gmail.com まで。 講演 1月に「15分単位でメトリクスとってるスクラムチームあるんだけど、質問ある？」っていう発表をしてから、ちょこちょこ発表をしました。 2016/1 Regional Scrum Gathering Tokyo 2016
知識ゼロから学ぶソフトウェアテスト 【改訂版】 - @kyanny's blog
ソフトウェアテストについて体系的に学んだことがないので、とりあえず何冊か本を読んで、概念や用語、手法などを知ろうと思い、最も易しそうで Amazon のレビューも良かったこの本から読んだ。文章が堅くなく、文量も少ないようで、一日で読めてしまった。内容は確かに易しくわかりやすい。そこに価値を認めるからには、詳細で網羅的・包括的とはいえない点は仕方ないというべきだろう。文体から受ける印象だけでいえば、筆者のキャラクターは好みではない。 テストをする上での考え方について、なるほどそう考えるのかと初めて知ったこともいくつかあり、読んでよかった。いくつか「それはどうかなぁ」と思うところもあった。どのみちこの本だけ読んで済ますわけにはいかなそうだし、そのつもりでもない。自動化テストについては懐疑的な立場で書かれていたが、自分の目下のゴールはそこなので、先人の見解を踏まえて「勘所はどこか？」を考えていき
Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
