2013-04-07

転職エントリ

memo

他意は無い。無いったら無いんですが、日頃の感謝を込めて。

from SI

昨年の4月末日、6年ほど在籍していた会社を退職しました。
良かったこと、良くなかったこと、色んなことがありました。

{ここにいろいろな出来事を書く}

今の私を形成している要素の半分くらいはそこで得られたものです。
いや言い過ぎか、でもいいや、それくらいはもらってるんじゃないかと思っています。
人間的に危機的な場面もありましたが見守ってもらいましたし。おかげで今は元気です。
本当にありがとうございました。

to SI

~~とある会社~~GxPと呼ばれるグロースエクスパートナーズ株式会社に応募（apply っていうとなんかかっこいいですね）して採用されました。現職です。
日々驚きの連続（もう10ヶ月も経つのに）ですが、楽しく仕事をしております。
具体的には、門番を自称する id:digitalsoul と共にアーキテクトチームのような立ち位置で生きています。もっと彼の荷物を引き受けられればいいなぁ。

ベンチャーみたいな雰囲気と統制された雰囲気が混ざり合っているかのような感じです。
理由も無く無駄なことをやることは許さん！みたいなところが過ごしやすくて素敵です。
- 思考停止は容赦なく叱られます。
（今は）人はそんなに若くないけど組織は若くてどんどん変わろうとしています。

自分を変える

自分の経験も棚卸しして、いらないものはどんどん捨てて新しいものを取り入れていかないといけないなと思っております。
まずはたまに出てしまう下請け根性を葬り去らないといけない。
これは必須（10ヶ月何してたんだっていうのは置いといて。結構根深い）。

それと面倒くさいと評判になりつつある点は訂正してきたいと思います。
具体的にはもっと提案するということを考えていきますよ。

補足

軽微なネタがあったので追記。

java-ja が始まった場所だった

すっかり覚えてなかったんですが第一回チキチキ Java-ja 勉強会ミーティングに参加しており
10ヶ月経ってから一度来社（オフィスが西新宿にある頃に）していたことが判明
java-ja が始まった？場所なのかと思うと感慨深い
- 今となっては誰も SI やってないのが面白い

向こう側の世界

名だたる面々が顔をそろえて暗躍活躍しております。
自分には届かない世界（セレブっぽいイメージ）だと思ってた人達を身近に感じられて楽しいです。
- DDD 翻訳で知られている id:digitalsoul
- アーキテクト97本で有名な ~~@yusuke_arklanp~~@yusuke_arclamp
- プラクティス本を読んだことのある人なら間違いなくお世話になっている @a_konno
- POStudy主催の @fullvirture
- マインドマッパーな @dproject21
総じて皆笑顔である

飲み会がカオス

Why たこ焼き、おでん
油性ペンで顔面ペイント…

2013-03-02

第n回GOOS（日本語版）読書会を開催しました

goos 読書会

はじめに

実践テスト駆動開発の読書会でした。
5人くらいだったので話題とか時間とかいろいろと調整しやすかったです。

何をしたのか？

皆ひと通り読んでいる、ということだったので次のように進めてました。
1時間くらいで休憩を挟みつつ。

1部、2部
- 若干の思い出し時間を設ける
- ざっくばらんに気になるテーマを出して話す
3部
- オブジェクトの図を中心に育つ様子をトレース
4部、5部
- 超高速チラ見ガイド

感想

TDDの一歩目って何
- まだ無いクラスは IDE が赤字下線で教えてくれるのになんでその段階を踏まなきゃならないの、という疑問
- 「やりたいようにやればー」派と、「テストコードがやりたいことを確認する作法ですよ」派といろいろありそう
- たぶん TMTOWTDI
会話しやすい
- 少人数だから誰かを妨げることはあんまりない
素通りしてたところを拾えた
- 値型の分解、発芽、Bundling Up (忘れた）とかのあたりで「そもそもドメインって何を指してるの？」みたいなやつを回収できた
図の間違いを見つけた
- 3部でオブジェクトの図を流して見ていて「これ説明と合って無くね？」となり、調べたら翻訳原稿での誤りだったという。原著は合ってた
俺、設計やってない
- 3部でシステムが育っていくところを改めて見なおした結果、普段の仕事では全然やれてないことを思い知らされてしまったので猛省する
3部を納得しながら読んでいくために
- コードだけでも図だけでも片手落ちになるので、それぞれをくっつけながら読むとよさそう
4部5部は動かしてこそ理解も深まるし面白いのでは
- 「あるあるー」で済ましておくのではなく、書いた方が分かりそう
6部の話おもしろい
- 読んで無かったという orz

おわりに

「企画が下手」とかいろいろありますが前回の二倍を越える方々に来ていただいて嬉しいです。
これからも下手の横好きで続けていきたいと思います。

が、3部をうまく読む方法は今のところ思いつかないので、次回は4部5部をじっくり読むことにしようかなと思います。

参加いただいた皆様、本当にありがとうございました。

2013-01-26

SQL アンチパターン、落とし穴と転ばぬ先の杖

book sqlap

SQLアンチパターン

作者: Bill Karwin,和田卓人,和田省二,児島修
出版社/メーカー: オライリージャパン
発売日: 2013/01/26
メディア: 大型本
購入: 9人クリック: 698回
この商品を含むブログ (46件) を見る

impression

攻撃力高いですね。
普段の仕事ではそんなに複雑な SQL を書くことはほとんど無くなってしまっているのです。
ですが、過去にやってきたことを振り返ると胃が痛くなるような、そんな内容が節々に転がっており、読んでて楽しいです。

「インデックスショットガン」とか「リーダブルパスワード」とか、そんなの自分の目の届く範囲では絶対ないわ―という内容も
あったりするんですが、きっと自分は恵まれている。

テクニカルな内容が多いのですけど、これは逆にシステムのほうで都合を悪くしてしまっている例なんだとも思えます。
業務のドメインを正しく表現するのが第一で、それをいびつにしてしまったり、制約になってしまってはいけないなとしみじみ思いました。

データベース・リファクタリングと合わせて読みたい。（積んであるんだよなぁ）

misc

ひょんなことからレビューアの一端に加えていただくことになりありがとうございました。とても面白い体験でした。
DBリファクタリング読書会第四回には参加しようとしてます（え、2/5 から 2/12 に変わったの…危ういかも）
O'Reilly Japan - SQLアンチパターン
書籍:SQLアンチパターンのご紹介 (コーソル DatabaseエンジニアのBlog)

2013-01-16

第1回：GOOS（日本語版）読書会を開催しました

goos_ja book

第1回：GOOS（日本語版）読書会 - connpass

第一回だけど、次もきっと第一回。

開催理由とか目的

ボトムアップにユニットテストを書き連ねたところで、なんとなくこれじゃない感を覚えるようになり、方向性を模索していた
そもそもがオレオレ TDD なのであって、設計成分をどこに按配すればいいのか途方にくれた
そんな時にふと振り返ると、そこにはこの本があった

実践テスト駆動開発 (Object Oriented SELECTION)

作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘
出版社/メーカー: 翔泳社
発売日: 2012/09/14
メディア: 大型本
購入: 4人クリック: 262回
この商品を含むブログ (31件) を見る

Growing Object-Oriented Software, Guided by Tests(goos_jp)読書会 - FrontPage の番外編の気持ちです。
お仕事で一緒になった方が読んだことはないけど興味はある、ということだったので勢いで。（まぁ、その方は来なかったのですが…というか連絡取れん）

結果

makopi さんが来てくださった！
- オンライン実(戦|践)テスト駆動開発写経会の方からいらした
- http://devtesting.jp/dbrr の方も入っておられるとか
- （実戦って、、、もしや本当に実戦なのか!?）
それ以上増えることもなかったので、もくもく会になった
- まことに申し訳ない…
自分は自分で、第1章から第9章くらいまでちゃんと読み返した
- 原著は2部から5部くらいまでをみっちりと読んで頭使ったつもりだったんですが、あらためて読むといいこと書いてあるな〜と思いました。
- 第5章とか。繰り返しをするためのスケルトンが大事とか、あっさり書いてあるけど一番ときめいた

今後

続ける
エクストリムなやり方は続ける
ツッコミどころは多々ありそうではあるので議論のためにも開催のための最低人数(5人)を定める。
- 皆さま都合もあるので流局の判断は早めに…
ゲストを見つける（http://devtesting.jp/dbrr 方式）
付加価値として、第3部の導入で切り捨てられている環境構築スクリプトを仕立てる
- ダメなら環境構築ガイドとかを（すでに公開されている方がおられるのは知っている）

2012-10-28

当たり前のことを当たり前にやる人の集まる空間

scrumdo

スクラム道 EXPO 2012 - スクラム道 | Doorkeeperに参加してみました。

仕事で近々に求められているやり方ではないものの、隣の芝生は青く見えるのです。

id:yach さんと id:nawoto さんによる "no bull know how"（お悩み相談室）のあたりに座っていたおかげ(?)で、多くの人が自分自身と周囲の関係についての悩みを持っているのだなぁとしみじみしたりしました。

考え方に変化があったのは、無理して導入してもいいことは無いし、導入することが目的になってもしようがないのだなぁということでした。
じゃあ何時までたっても始めるきっかけはこないんじゃないか、とも思うのですが。
「なぜ」を突き詰めて、それが最善の方策であるということが確信できたなら、「どうやって」を考えればいいのかな。

なので、「どうやって」についてはしばらく考えることを止める。
「どうやって」にまつわる、あれはどうするのこれはどうするの的な疑問もとりあえず脇に置いておく。
やってる人にとっては特別な課題ではないようですし、徒手空拳で議論しても得るものは無さそうなので。

2週間先に出荷可能とするべき物事に思いを馳せつつ、後悔のないように考えられる人になる努力をしていこうと思います。

2012-10-25

Shinjuku.rb #10 に顔を出してきました

ruby

クレジットカード現金化詐欺【業界人が教える口コミ情報】

新宿で働いているのに一度も出たことがなかったので…

コードフィッシュボールで、LRU キャッシュを実装してました。

Rails 使ってる人の普段の仕事を垣間見れたのは面白いものでした。

bundle じゃなくて b とか。

spec を仕様書として大事にしてる感じ、とか。

いちおう手元で書いてたやつをメモしてました。

Shinjuku.rb #10 で LRUCache をフィッシュボール

2012-10-22

とてか02 に来たのでメモ

toteka development

とてか02 に来たのでメモ。

とちぎテストの会議とは

「日常、いつもの、ふつう盛りx2、小盛りx1」 - とちぎテストの会議

2010年に行われた「とちぎテストの会議（連番なし）」（通称とてか）は、
id:yoshioriのデブサミでの講演を発端としたTDD周辺の一連の炎上を受けて開
催されました。とてかはTDDとはなにか？について議論しあう、重い場と強いメッ
セージを提供しました。那須から流行のお祭りに参加する、ハレの日。
2012年、とちぎテストの会議02のコンセプトは「日常、いつもの、ふつう盛り
x2、小盛りx1」です。

ということだそうです。

お題目はすっきりしてますね。

基調講演「テストコンサルの日常」秋山浩一 (富士ゼロックス (株) SS開発本部)
ソフトウエア開発ライブ
テストのレシピ
ワールド・カフェ
クロージング

場所

東那須塩原公民館でした。

東北新幹線で那須塩原へ、さくっと。
結構多数の人が乗り降りしていた感。

駅前に結構何もなくて、、、地元感がありますね。

オープニング

Tweet 禁止などの諸注意。
日常の様子を発表される方がおられるから、という配慮だそうです。
(ということは blog もダメなのでは…)

プロジェクタは 2 台構成でした。準備いいなぁ。

基調講演

@akiyama924 さん。
ソフトウェアテスト技法ドリルの著者の方。

「ソフトウェアテスト技法ドリルを読んでいない人挙手」→じゃあこれあげる、という驚きの導入。

SQiP研究会 (http://juse-sqip.jp) で縁あって咳さんから呼ばれました、と。

「コンサルタントは事実を元に語らなければならない」ということで、ご自身の時間別ツイート数を分析w

なんでもかんでも HAYST 法、という時期の経験から得られた、コンサルティングの NG/OK といった話をされていました。

いろんな分野の会社から呼ばれるし、都度異なる課題があるので面白い。

QA

コンサルティングとして呼ばれる契機？
- 経営課題レベルで切迫したプロジェクトで呼ばれることもあります
- どのフェーズで入ってもあんまり変わらないですね

解決できない問題はどうするものなのか？
- 解決できる人を連れてくる。ハードの人、ソフトの人。

ソフトウエア開発ライブ

咳さん、佐々木さんによる

JaSST のテスティングライブ
- 正直めんどくさい。
TDDBC のデモ
- 見てるだけ

今回は、仕様変更を入れながらプログラム (メイヤーズの三角形判定) を書くので、楽しみましょう。
- 「こういうテストケースがいるんじゃない？」というのをみなさんにお願いします

入力された整数が、三角形かどうかを判定する
- 0 を入れる
- 負数を入れる
- 少数を入れる
- "07" を入れる
入力された整数を計算して、三角形かどうかを判定する
- "\t2" を入れる
- "8 " を入れる
- " 8" を入れる
- "三角形でない"の例 (1,2,3)
- なんかすっごい大きい数
  - Ruby/Smalltalk といった Bignum を実装してるプログラミング言語であれば、普通テストしない (よね ?)
  - だけどそれを格納するストレージは ?
辺の長さを調べて、「二等辺三角形」「正三角形」「三角形」を判定する
- ちょっとかっこいい実装をお見せします
- 「三角形判定アプリを誰がどう使うのか分からないのがもやっとする」
- 2.0 は 2 とみなすのか、とか
- 漢数字ェ
- Integer と同じパースをするものになってるけど、カスタマイズするべきかもね

プログラムを書いてるときにテストも書いてることが多い。
実装が分かってるので、ブラックボックスでやるときは気にするような観点をばっさり捨てたりする。
最初の頃からテスターが一緒にやってるので、前半の段階で外部仕様として制限するとか、そんなことをしています。

QA

TDD だとどうなのよ
- (id:t-wada) すぐに実装するので、ホワイトボックスに近いものになる。咳さんの考えとだいたい同じ

レシピ

発表者皆が咳さんと同じスタイル (中間チェックポイント入れるやつ) でした。
toRuby の特徴 ?

おいしくなかったレシピ (ソフトウェア通信簿)

なかうちさん。

前振り
- toRuby 所属、実行委員長係
- システムの科学
和田卓人のテスト駆動開発講座
- フラクタルな図が好き
- 若干コンフィデンシャル

ソフトウェア通信簿
- コードがどのくらい使えるかを自己評価したもの
- 試作ソフトの出来栄えを数値化
  - 技術リスク、ソフトウェア検査結果、パフォーマンス評価とか

知らないものにはコミットできない
- 自分で書いたコードじゃないと…評価って何？

通信簿パターン
- 「通信簿」も「ソフトウェアを使ってもらう」も同じ形をしていることに気付いた
- 前者は後者を解消するものではなかった

QA
- 今の通信簿の 3 つの項目 (品質レベル) はどんなもの？
  - 開発サイドと同意してるもの
  - どんな当たり前バグがあるとか、どんな機能を諦めてるとか

研究開発だけを目的にするチームを作るのは駄目だ、というような議論をしたなぁ。

ワンプレートテスト

ゆりてぃさん。

TEF 道ワークショップの課題「スーパーマリオの状態遷移」
- みなさんが書いてるもの→難しい
- 会社の研修で書いてもらったもの…→難しい

ワンプレートテスト
- テストの関心ごとを 1 枚の紙に入れる
- 階層ごとの状態遷移図にいろいろ盛り込んでいく
- UML の状態遷移図と同じ?
- 入力から考えていくと困りそう

1 枚に全部書く
- 俯瞰できる、スコープを明らかに
- CFD よりもシンプル

メリット
- 全部でどれくらい、が見える
- 書くときに何をテストするかを意識しやすい

普通にオブジェクトの状態遷移として考えてることだなって思った。

ふつう、というか、ポケモン

ネットワークインフラエンジニアとして、サイトマップ網羅テストが必要になった話。

サイトマップ網羅テスト
- サイトマップのリンクを全て開く
- ちゃんと表示されるかを確認するというテストを作ってみた

おいしくなかった
- インフラ観点で他に見るべきものが
  - メール送受信、ログ、セキュリティ診断、監視、、、

探索的テスト

恋愛系テストエンジニア

持ってない人挙手→買ってください

用語としての探索的テスト
- あるテストを実施し、その結果をベースにして次のどのようなテストを行えばよいか考える
- 非常にレベルの高いテスト

テスト活動と探索的テスト
- W 字モデルっぽいプロセス
- テストは、チームの皆で考える
  - 全体像は徐々に出来上がる

わたしの探索的テスト
- 序盤 (+もや)
  - テストケースはなし
  - チームの心配事などを重点的に
- 中盤 (+もや)
  - 設計したテストケースを使う
  - テストケースに無いこともやる
  - テストケースの設計にフィードバックするサイクル
- 終盤 (+もや)
  - ユーザ観点のテスト
  - 開発中に発生した問題についてもテスト

もやもやが無くならない…
- 受けいれる (スピリチュアル系)
- 認めてもらう (依存系)
- テストケース設計と同じサイクルを回す
  - テストケースがある場合もやもやしない
  - →自分で考えてるからもやもやが残る？
  - 言葉の定義にないけど、一人でやらないといけないと考えていた
- ペア探索的テスト

経験の不足を補う工夫を！