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

book sqlap

SQLアンチパターン

SQLアンチパターン

impression

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

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

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

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

misc

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

goos_ja book

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

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

開催理由とか目的

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

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

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

結果

  • makopi さんが来てくださった！
  • それ以上増えることもなかったので、もくもく会になった
    • まことに申し訳ない…
  • 自分は自分で、第1章から第9章くらいまでちゃんと読み返した
    • 原著は2部から5部くらいまでをみっちりと読んで頭使ったつもりだったんですが、あらためて読むといいこと書いてあるな〜と思いました。
    • 第5章とか。繰り返しをするためのスケルトンが大事とか、あっさり書いてあるけど一番ときめいた

今後

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

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

scrumdo

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

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

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

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

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

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

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

ruby

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

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

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

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

bundle じゃなくて b とか。

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

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

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

とてか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 のデモ
    • 見てるだけ
  • 今回は、仕様変更を入れながらプログラム (メイヤーズの三角形判定) を書くので、楽しみましょう。
    • 「こういうテストケースがいるんじゃない？」というのをみなさんにお願いします
  1. 入力された整数が、三角形かどうかを判定する
    • 0 を入れる
    • 負数を入れる
    • 少数を入れる
    • "07" を入れる
  2. 入力された整数を計算して、三角形かどうかを判定する
    • "\t2" を入れる
    • "8 " を入れる
    • " 8" を入れる
    • "三角形でない"の例 (1,2,3)
    • なんかすっごい大きい数
  3. 辺の長さを調べて、「二等辺三角形」「正三角形」「三角形」を判定する
    • ちょっとかっこいい実装をお見せします
    • 「三角形判定アプリを誰がどう使うのか分からないのがもやっとする」
    • 2.0 は 2 とみなすのか、とか
    • 漢数字ェ
    • Integer と同じパースをするものになってるけど、カスタマイズするべきかもね

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

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

レシピ

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

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

なかうちさん。

  • ソフトウェア通信簿
    • コードがどのくらい使えるかを自己評価したもの
    • 試作ソフトの出来栄えを数値化
      • 技術リスク、ソフトウェア検査結果、パフォーマンス評価とか
  • 知らないものにはコミットできない
    • 自分で書いたコードじゃないと…評価って何？
  • 通信簿パターン
    • 「通信簿」も「ソフトウェアを使ってもらう」も同じ形をしていることに気付いた
    • 前者は後者を解消するものではなかった
  • QA
    • 今の通信簿の 3 つの項目 (品質レベル) はどんなもの？
      • 開発サイドと同意してるもの
      • どんな当たり前バグがあるとか、どんな機能を諦めてるとか

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

ワンプレートテスト

ゆりてぃさん。

  • TEF 道ワークショップの課題「スーパーマリオの状態遷移」
    • みなさんが書いてるもの→難しい
    • 会社の研修で書いてもらったもの…→難しい
  • ワンプレートテスト
    • テストの関心ごとを 1 枚の紙に入れる
    • 階層ごとの状態遷移図にいろいろ盛り込んでいく
    • UML の状態遷移図と同じ?
    • 入力から考えていくと困りそう
  • 1 枚に全部書く
    • 俯瞰できる、スコープを明らかに
    • CFD よりもシンプル
  • メリット
    • 全部でどれくらい、が見える
    • 書くときに何をテストするかを意識しやすい

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

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

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

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

恋愛系テストエンジニア

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

  • 用語としての探索的テスト
    • あるテストを実施し、その結果をベースにして次のどのようなテストを行えばよいか考える
    • 非常にレベルの高いテスト
  • テスト活動と探索的テスト
    • W 字モデルっぽいプロセス
    • テストは、チームの皆で考える
      • 全体像は徐々に出来上がる
  • わたしの探索的テスト
    • 序盤 (+もや)
      • テストケースはなし
      • チームの心配事などを重点的に
    • 中盤 (+もや)
      • 設計したテストケースを使う
      • テストケースに無いこともやる
      • テストケースの設計にフィードバックするサイクル
    • 終盤 (+もや)
      • ユーザ観点のテスト
      • 開発中に発生した問題についてもテスト
  • もやもやが無くならない…
    • 受けいれる (スピリチュアル系)
    • 認めてもらう (依存系)
    • テストケース設計と同じサイクルを回す
      • テストケースがある場合もやもやしない
      • →自分で考えてるからもやもやが残る？
      • 言葉の定義にないけど、一人でやらないといけないと考えていた
    • ペア探索的テスト

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

移り気な客のためのリスクベースドな下準備

goyokiさん

熊とワルツを とか。

SEI の資料だとこういうやつのことなのかな。
http://www.sei.cmu.edu/reports/93tr006.pdf

Class として Program Constraints というのが該当しそう。

  • 子供のマネジメント:職歴の庇護の元で狭い世界と向きあう
    • 「単純バグ多すぎ」「仕様変更多すぎ」

ワールドカフェ

「月曜日から変わること、変わらないこと」というテーマでした。今日の振り返り的な位置付けでしょうか。

ごく雑多なことをいろいろと話してましたがあまり覚えておらず…

懇親会

会場は ダイニングバー ウニコ - ホーム | Facebookダイニングバーウニコ でした。

リジェクトレシピ+飛び入り LT、面白い発表がいろいろあったので、これだけでも懇親会参加してよかったと思います。

なんとなく自分も話したくなったので、テスト設計とフィードバックについて、なんか疑問提示してました。

初めてお会いしたのですが、@koyaman2 さんからテスト設計の目的とするところや、TABOK 面白いよみたいなことを教えていただきました。

JavaEE勉強会にも参加されていたという id:vestige さんに伺った「ふつうの開発」について、、、
設計して実装してテストする、それを繰り返すだけ、、、普通ですよね orz

以上

今回はインフラエンジニアやプログラマー、テストエンジニア、テストコンサルタントといった色々な日常を聞くことができて楽しいものでした。

Linux のパッケージ管理システムの例

linux

社内勉強会で Dependency hell - Wikipedia を読んでいます。
Linux のパッケージ管理システムの例として挙がっているものに知っているものも知らないものもあったのでメモ。

apt

Chapter 2. Debian package management
Debian のパッケージ管理システム。
dpkg の上のレイヤで、aptitude の下のレイヤだと思います。

YUM

Chapter 14. YUM (Yellowdog Updater Modified) - Red Hat Customer Portal
Redhat のパッケージ管理システム。
RPM の上のレイヤ。

Urpmi

mandriva.com
Mandrivia Linux のパッケージ管理システム。
RPM の上のレイヤ。

ZYpp

Portal:Zypper - openSUSE
OpenSUSE のパッケージ管理システム。
RPM の上のレイヤ。

Portage

http://www.gentoo.org/doc/ja/portage-user.xml
Gentoo Linux のパッケージ管理システム。
ひたすらにビルドする系。

Packman

pacman - ArchWiki
Arch Linux のパッケージ管理システム。

自分用のお題的な何か

memo

自分用。
これだけならn分以内に作れる、ということにしたい。
ネットワーク使うしDB使うしでいいかなって思ったので。

  • 種類
    • Webアプリケーション
  • 内容
    • 個人用オンラインブックマーク
  • 機能
    • ログインできる
      • ログインすると、公開可否を問わず登録済のブックマークを閲覧できる
      • ログインしなくても、公開可として登録済のブックマークを閲覧できる
      • ログインすると、oauth 認証可能な外部サービスを登録できる
      • ログインすると、外部サービスへの投稿履歴を見ることが出来る
    • 外部サービスへの投稿ができる
      • 外部サービスへの投稿はサーバサイドで行う
      • 非同期に行なってもよい
      • 投稿時は、投稿先のサービスと、投稿日時を記録する
    • ブックマークを登録できる
      • URL、タイトル、コメント、イメージ、タグ、公開可否を指定できる
    • ブックマークを編集できる
      • URL、タイトル、コメント、イメージ、タグ、公開可否を編集できる