  |
はてなキーワード: ネストとは
http://tradenote.info/blog-entry-3.html
一般に、バッカスナウア記法は正規表現では処理できないネストの階層を記憶できるなどの根本的な差があります。
これは正規表現が有限決定性オートマトン（DFA）ないしε遷移と不特定の同種記号の遷移を用いる非決定性オートマトン（NFA）に基づいているのに対し、BNF記法での解析は必然的にスタックを内部状態に持つからです。
https://ja.wikipedia.org/wiki/LL%E6%B3%95
これは左からトークンを走査して、導出する非終端記号を左から決定していくアルゴリズムです。
例えばA→A Bという構文規則があった場合に、Aの還元内でAを還元できるかどうか判定し続けて無限ループに陥ってしまい、いつまで経ってもBの判定に辿り着けません。これを左再帰といい、LLでは左再帰を直接扱う事ができません。
非終端記号の間接的還元を考慮したはじめに現れる終端記号の集合（FIRST集合）を構築して上手く左再帰を回避しなければなりません。
マッチングに用いる規則をベタに関数内部に再帰させながら順番に書いていくだけなので実装は容易です。
https://ja.wikipedia.org/wiki/LR%E6%B3%95
https://ja.wikipedia.org/wiki/LALR%E6%B3%95
こちらは左からトークンを走査して、導出する非終端記号を右から構築するアルゴリズムです。
BNF構文規則から走査に相応するDFAを構築し、DFAの遷移を記憶しながらスタックに状態をpush/popし構文解析を行います。
なのでLL法にあるような左再帰を直接扱えないという欠点がなく、むしろスタックが簡潔になるため積極的に左再帰のBNF記述を行った方が効率よく処理を進められます。
LR法はDFAの大きさが巨大になるため、実用的ではないようです。
LALR法はLR法を改良したアルゴリズムで、扱える構文クラスの範囲はLRよりも少し小さくなりますが現実的な計算資源で構文解析を行う事ができます。
結構最先端めな東京のWeb業界から地方のSIer業界に転職して3年経ったのでそろそろ感じたカルチャーギャップをつらつらと書くよ。
転職の理由はまあ家庭の事情ってやつなので割愛。給料もやや減ぐらいで特筆することはないから割愛するよ。
上司を呼ぶときは正しい肩書きを後ろにつけないと嫌な顔をされるよ。
前の会社では社長までさん付けで普通に会話していたのでなかなか衝撃だった。
昇進や降格で肩書きが変わると呼び方も最新のものにちゃんと変えないといけないから大変。
昇進ならまだ訂正する方が嬉しそうに訂正してくれるからいいが、降格した人を前の役職で呼ぶと気まずさがハンパない。
当然メールの宛先にも肩書きを付けるので最初の宛先の羅列にすげー時間がかかるよ。
スーツで太っててやたら偉そうで、何の仕事をしてるのかよく分からないがゴルフの情報にはやたら詳しいみたいなのが割といるよ。
その人たちにとって下々の人間は石ころみたいな存在らしく、ほとんど注意は払われない。
これもテレビドラマで見た！って感じだよ。
なかなか新鮮だった。
見積もりの確認書からプロジェクトのリスクから反省点からレビュー表からテストのエビデンスから。
とにかくプログラムのコード以外に書かなければいけない書類が多いよ。
さらに一つ一つに上司やさらに上の人たちの印鑑が必要なので時間がかかる。
上の人たちは書類を見て印鑑を押す仕事だけで1日のほとんどを奪われているんじゃねーかとか思うよ。
実際にコーディングをする前に、そのままプログラムに変換できるんじゃねーかレベルの詳細設計書を作らないといけない。(当然作成ツールはExcelだよ！)
最初からコードで書く時間の5,6倍ぐらいの時間を使って、結局そのままコードに自動変換はできないロジックを日本語で書く。
当然簡単なテストも出来ないのでここでロジックの不備が見つかることはほとんどない。
ちなみに、実際のプログラミングは詳細設計書を写経するみたいなものなので全く面白くないよ。
一度上司にこの設計書の存在意義を聞いてみたら「誰でも実装や保守ができるように」などという答えが返ってきたけど、実装ならこの設計書を書いている間に終わるし、コードを読めない人が保守するようなプロダクトには、恐ろしくて関わりたくないと思ったよ。
割愛。
あまりにも文化が違う。300行ぐらいあるifブロックのネストとか余裕。
割愛。
割愛。
3年間で関わった案件で1度も実現できなかった。
割愛。
色々な切り口で問題点を伝えたが「規約ですから」で取り付く島もなかったよ。
結局、呼び出す度にどういう処理をするのか毎回コメントを書くことになっていたのには笑った。
ソースコードの複雑さを表す指数で、これが高いソースコードはバグが多いって言われてるの。
サイクロマチックの発案者に直接、科学的根拠あるのかって聞いたら「実際に役にたってるから(根拠は)いいだろ」みたいな返事らしいのな。
たしかにソースが複雑だったらバグは増えるだろうけど、それならツールを使わないと算出できないような複雑な指数をつかわなくても「ネストは○段まで」「サブルーチンは短く」「サブルーチンのローカル変数は○個まで」みたいな単純なやり方でもいいよな。
サイクロマチックでなくても、見た目が複雑なソースなら大きくなる指数を適当にでっち上げても「この指数とバグの発生件数は相関関係がある」って言えそうだよな。
http://weekly.ascii.jp/elem/000/000/306/306175/
「ニコニコ生放送」のコードに、循環的複雑度が600を超えるメソッドがたくさん入っていることが判明したことがあった。循環的複雑度が75を超えるとバグの混入確率は98％、「いかなる変更も誤修正を生む」状態になると言われていて、要はニコニコ生放送は動いてるのが不思議なくらいバグがめちゃくちゃ出やすい状態だった。
循環的複雑度って科学的なメトリックスだと思ってる人がいっぱいいるけど、あれ根拠ないからな。はっきり言ってオカルト。
サブルーチンのなかにif文は何個以下とかネストの深さは何個とか、もっと単純な基準で「循環的複雑度がxx以下」と同じ効果をだせるはず。
K＆Rと同じく、基本省略スタイル推奨。
ただ、ifがネストした場合には、elseのぶら下がりがわかりづらくなるから、必ず中括弧書け、とも言ってる。
? if (a) ? if (b) ? else ? ...;
あと、ブコメでも指摘してる人がいるけど、どのスタイルに従うかはどうでもいいけど、一貫して同じスタイルで書くことはとても重要だ、とも。
既存のプログラムが省略スタイルなら、追加コードも合わせるべきってことだねー。
既存のコードがぐちゃぐちゃだったら、、、スキルが低い集団ってことだから、カッコ付けるスタイルに修正してくほうがいいんじゃないかなー。
1. 括弧の省略
PHPにおいてはif文やwhile文において、１行であれば括弧を省略することができます。
<?php if (...) hoge(); while(...) hoge();
これは、保守性・管理性を上げたいのであればやってはいけません。括弧がつくことで視認性が下がることなどありません。むしろインデントに騙されてしまい、ミスが増えます。例えば下の例です。
<?php $a=0; $b=0; while ($a < 10) $a++; $b++;
さて、このとき $a はいくつですか？ $b はいくつですか？
答えは $a が 10、 $b は 1 です。$b は while のスコープにはないので、ループしません。
括弧でくくられていればこのようなミスを防げます。括弧はきちんと書きましょう。
2. 三項演算子
ネストしすぎると可読性が損なわれるため注意が必要ですが、うまく使うとスマートに書けます。うまく活用しましょう。
3. switch文
条件分岐が多い時にうまく使いましょう。
ただし if 文で素直に書いた方が速度は速いという噂もあります。
実用上の違いはほとんどありませんので、チームの方針に従いましょう。
4. ループ文
PHP にはループ制御構文が用意されています。主に下記の３つを用途にあわせてうまく使い分けましょう。他にもループに関する構文や関数はありますが、基本的には下記で事足りるでしょう。
主に回数でループさせたい場合は for 文を利用するといいでしょう。
<?php for ($i=0; $i<10; $i++) { //
横だけど、
switch-caseもどきのif elseが多段でネストしているロジックの時にcaseの中身を
private voidにしないと１０００行ぐらいあるケースの場合は
private void __whatdo();
という使い方になるのでは？ あまりあるケースではないけど、関数テーブル一発で飛べない場合には出てくるのでは？private void
if( a ){
if(b) {
__whatdo_A();
}else if(c){
__whatdo_B();
}else{
__whatdo_C();
}
}else if(d){
__whatdo_D();
}else{
__whatdo_E();
}
__whatdo_Eを直接呼ばれたくないけど、関数化しないと読めたもんじゃないという場合にはprivate void()になる。
中括弧は、プログラミングを覚えて1年くらいの段階で絶対に付けるようになって今に至ってる。
ブロック内がシングルステートメントなら無くてもいいんだが、後で処理を追加するのにいちいち中括弧を付け足すことが頻出して、だったら先に書いとけばいいや、と。
実際に中括弧を付け足すのを忘れたり、if行との間に一行空けてしまう(改行でステートメント区切りの言語)という事故も起こしたし。
中が一行であるという保証はどこにもないのに、一行しか書けない記法を使うということにナンセンスさも感じる。
今どきの言語はそもそも中括弧をなくすという方法をとっているが、合理性を感じる。ただ抵抗感はある。
「中括弧は省略しない」「ネストは深くしない」全く別の話だし両立するだろ。
#include＜stdio.h＞ int main() { int a = 1; int b = 0; if (a) if (b) printf("Hello"); else printf("Howdy"); }
昨年のテレビ録画を消化。
ライブとかフェスとか音楽関係のサイトの編集とか、ツイッターからの出会いとかそれで連絡つけて会うとか、三十路過ぎてママチャリ通勤とか、部屋の壁一面に生活に必要ないけどなんかないと死んでしまう気がするけど実際棄ててみるとなんともないCDとかマンガで埋め尽くされたネストとか、いい歳こいた年齢なのに仕事場の仲間とマンガにでてくる大学生のコンパみたいに盛り上がれるとか、あれどこの世界の日常なんだよマジでとか思いました。
背広組みがいないとよくわかんないよねー。
恋敵役がミュージシャンじゃなくて、エリートの商社マンとか、最年少で一部上場果たしたとこの若手社長とか、もう少しわかりやすいアイコンの方が肩入れできたかもしれんなー。
エミネムの自伝映画とされる8Mileみたいに、なんかすごいしなんに感動してるのかわからないんだけど胸がいっぱいにはなるが、一息いれてから思い返すとやっぱりよくわからない感じで終わるのがツラい。
告知されていたブックマークへの返信機能（コメント一覧ページで検討中の新規機能について、ご意見を募集します - はてなブックマーク開発ブログ）が実装されたが、いくつか気付いた点を書いてみる。
引用スターがしづらい、コメント内URLが一旦ブックマークコメントページに切り替えないと踏めない、という２つの欠陥がある。これはコメント文章をリンクにすることをやめて、従来の状態に戻せば解決できる。元に戻しても新設されたTwitterアイコン、Facebookアイコンの隣にあるリンクアイコンからブックマーク コメントページに飛べるので問題ない。
raimon49 はてなスターで引用箇所を選択しづらいのでコメント本文全体がクリッカブルな仕様はダメ。
（追記）
seiyuDB url貼っても１クリックで飛べなくなった。改悪でしかない。無条件で鳩とかfとか出して鬱陶しいったらありゃしない。聞く耳持たないご意見募集とか。
従来はメタブタワーが一系統だったが、これからは各ブコメにブックマークできるので、一つのブックマークページから何系統ものタワーが伸びることになる。これを見やすくするには、ブコメの横に赤いブックマークアイコンが付けば多少見やすくなる。
kha パーマリンク(鎖マーク)の隣に[XXusers]とメタブ数が表示されれば、手斧を投げ合う様子が視覚化されて良いと思います。
一つのブクマページから何系統ものタワーが伸びると、それを追うのも大変。
似たような構造としては、スラッシュドットのようなネストできる掲示板がある。スラドのようにボタン一つでメタブを開けるようにすれば非常に見やすい。
ボタンはOff,5users,3users,1userとなっていて、1userにすると全メタブが開く。
メタブというのはブックマークページをブックマークすることだが、 ブックマーク コメントページをブックマークすること何と呼べばいいのか。誰か早めに決めたほうがいい。例えばブックマコメントで、マコメというのはどうだろうか。
取り急ぎ、改善できそうな点を書いてみた。
奇麗なコードって何だろう？
15年近くコードを書いてきて未だに思う。
自分が書いたコードなんて3ヶ月後には陳腐化する。なんでこんなコード書いたんだろう？ってなる。
それでも実践している最小限のことはある。
桁数は78まで
省略はしないけど長い名前はつけない
引数は3つまで、仕方ない時は4つまで許す
関数の長さはそんなにはキニシナイ(100超えてたらマジキチだとは思うけど)
同じコードが散在していれば関数に切り出す(継承についても考える)
自分が書いた関数のドキュメントはWikiに書きなぐって俺の関数を使えー！！って叫ぶ
それでも3ヶ月もすればあれ？なんであの時？ってなる。
○朝食
水のみ
○昼食
○夕食
かきあげ丼（おごり）
○夜食
油麺のちに吐く
まずい、色々とまずい。
何がまずいってまず、一万円もポケモンカードに使ったことがまずい。
だってダーテング欲しかったんだもん！（一枚しか出なかったけど）
次の一週間も自炊をすれば余裕。
次の一週間も自炊をすれば余裕。
だって、残り月末まで16日だから、一日500円も使えるわけですよ、余裕ですよ余裕。
多分、月末には傷病手当金が振り込まれるから、何とかなるはず、はず。（もうこれが破綻すると、XboxOne貯金を崩さないといけなくなる）
最大の問題は、ポケカをシングル買いして大会に出たい欲を抑えれるかと、
「スターウォーズのキネクトゲーをやるために、スターウォーズ全巻見る為にピザとらないとピザ」みたいな欲求をちゃんと抑えられるかだ。
○ポケモン
ランダムフリーの、ダブルやトリプルでダークライを使って無双するの楽しいです。
エーフィに間違えて打って二人とも寝てからのボロ負け以外は、基本勝ててます。
ただ、フリーのダブルやトリプルは三値を理解していない人もいるからか、ほのおのからだファイアローなんてオドロキの型が来てビックリしました。
案外、フリーも楽しいので、イベルタルも厳選して、フリーダブル悪統一でも真面目にやろうかなあ。
とりあえず、レポを残して晒す遊びでもしようかなあ。
（※レポってのは将棋でいう棋譜みたいな奴ね、僕は第四世代の頃社大スレってところでポケモンをやってたので、そういうのを残すのが好きなんです）
○ハッピーウォーズ
魔法使いで協力を一セット。
やっぱ遠距離ファイヤーボールはいらないなあ、他のを模索しよう。
あと、エンジニア用の砲台命中3はあるんだけど、僧侶用のそれがないから、それも欲しいなあ。
そうだクレジットカードなら（危ない思考）
○マジック2013
黒デッキで数戦。
1マナソーサリーのお互いのクリーチャーを生け贄に捧げる奴が強いなあ。
僕はポケカでは悪タイプ専門、ポケモン本編でも悪統一なので、マジックでも黒なのです（実は今決めた）
アービターと協力かと思いきやそうでもない。
早くコルタナと再開したいです。
DLLやSO作るときに、シンプルなグローバル関数で逃げられるなら、別にシンプルなグローバル関数の追加は有り。
何でもかんでもIDLとかやってられない。
1度しかよばれない、汎用性の低い処理をわざわざAPI切って公開するな。他人が使わないものを公共の場に置かれても迷惑。
private
protected virtualも検討してくれ。他人が使うことがある。
その他よくある。goto 使うな
ネストの深い帯域脱出にgoto使わないとかありえないし、関数内の例外エラー処理にtry-catch使うほうがありえない。よってgotoの方が良いケースも有る。
基本的にコーディング規約は初心者を縛るもので、上級者になったら、コーディング規約の例外ケースを知らないとダメ。
想定外がない事ががないように、コーディング規約の例外・想定外の条件にコーディング規約に従っても仕方がない。逆に、そういうことを知らずにコーディング規約を語っても仕方がない。
もともとは、２ちゃんねる系のまとめサイトを巡回して、Yahoo!ニュースのようなサイトを作っていました。（現在も鋭意開発中です。）
コンテンツの内容を解釈して自動的にジャンル分けをして・・・などと、出来るかわからない壮大なアイデアを実装しているので、いまだに完成時期が見えて来ません。
画像収集処理を作っている時に「これでエロ画像を集めたら面白そう」と思いついてしまいました。思い立ったら、すぐにやりたくなるのが人間の性というやつです。基本的な処理はほとんどできていたので、割に短期間で作成できました。エロ画像をどうせ集めるのなら、目的をもって役に立つサイトにしようと思い立ち、おなぬーをするためのWEBサービスにました。
作成したもう一つの目的として、月間10万PV程度のサイトを自分で運営したいという思いもありました。安直ですがエロ系のサイトであれば、それが可能なのではと考えた次第です。
せっかくサイトを作ったのですが、エロ系のサイトは告知をするのが難しいとう事実を作り終わってから知りました。私自身もブログをやっているので、そこでお知らせをしても良いのですが、ブログの趣旨にあわないのと、PVがとてつもなく低いという理由で断念しました。
匿名ダイアリーは、かなりのPVがあるので、作ったサイトの告知ができるのではと思い匿名ダイアリーを書いています。
せっかく作ったサイトですから、皆さんに利用してもらいたいし、役に立つサイトにしたいと思っています。ですので、サイトを見たらご意見をいただけたら嬉しいです。
もう、15年以上PHP（PHP FIと言う名称の頃からのユーザーです）でプログラムを作ってきました。PHPが持っている気軽さや気楽さは大好きなのですが、誰もが好き勝手なコードが書けるというデメリットもあります。プログラム言語にはある程度の厳しいルールがないと将来にわたってメンテナスしていけるプログラムを作るのは困難です。
せっかく新しプログラムを作るのだから、新しいプログラム言語で作ることにしました。
ある程度、厳しいルールがあって、誰もが同じようなプログラムが作れる言語はなんだろうと考えていくとPythonとRubyが候補に上がりました。
Rubyはできるだけ手数を少なくプログラムを作ろうという基本思想があります。私の感覚では、熟練したプログラマが使う言語という印象が強いです。
Pythonは、プログラマのレベルを問わず、熟練プログラマも新人プログラマも同じようなプログラムが書けるプログラム言語という印象でした。
私自身も将来誰かに教えられるようにと、今回はPythonを使用言語として選択しました。また、裸のPythonで書くのも面倒そうですので、フレームワークとしてDjangoを選択しています。
「おなりん」は、そんな思いを乗せて以下の環境で構築しました。
| サーバー | さくらのVPS（1G） |
| プログラミング言語 | Pytyhon 2.7.5 / Django 1.5.1 |
| その他ツール | Bootstrap, jquery, wookmark, colorboxなど |
| Webサーバー | Apache 2.2 |
| データベース | MySQL 5.5 |
「おなりん」は、登録されたまとめサイトを定期的に巡回して、各エントリーから記事内の画像URLを抽出しています。取り出すのはURLだけで、画像の直接ダウンロードは行いません。ですので、リンク元の画像がなくなれば、「おなりん」からの表示もなくなります。
各サイトのエントリーはRSSから取得しています。各記事のHTMLをPythonライブラリurllib2を使って取り出し、HTMLから正規表現で画像URLを抽出しています。
サイトによっては記事画像のHTMLに決まった書き方がなされていないために、余計な画像を抽出してしまうこともあります。おかず画像の抽出精度は徐々に上げて行きたいと思ってます。
当初「おなりん」は、Amazon EC2（t1.micro）で構築する予定でした。構築までは完了したのですが、今ひとつ体感速度が上がらないのです。すでに利用しているさくらにVPSと比較したところ、3倍くらいの速度差（abコマンドの実行結果）があったので、Amazon EC2の利用を諦めました。
Amazon EC2は１年ほどの無料利用期間があります。これを過ぎると課金されていくのですが、Amazon EC2（t1.micro）を1ヶ月動かし続けると4000円近い料金が必要になります。さくらのVPS（1G）は1年で1万円程度です。3倍早くて価格は4分の1なら、チープな私はさくらのVPS以外選択余地がありません。
でも、拡張性を考えるとAmazon EC2も捨てがたいのです。
Pythonはインデントでプログラムブロックを表すます。他の言語のようにカッコを使いません。IFやFORを使ってインデントが深くなると、どんどん右寄りになってきて、全体的に斜めなプログラムが出来上がります。最初は見慣れずに違和感を感じましたが、慣れればそうでもありません。
ただ、ネストしたIFでインデントが深くなりすぎると、インデントの位置で意図しない結果が出るので注意が必要です。慣れてしまえば、使いやすい言語です。
Djangoは良いフレームワークだと思います。モデルを定義してしまえば、モデルのメンテナンスを行う、管理画面が一緒に生成されます。テンプレートタグなどを自作すれば、かなり深いところまで手を加えることが可能です。慣れれば扱いも楽なので個人的には気に入っています。
「おなりん」は、まだ作ったばっかりで、テストもまだ十分に行えていません。ですので皆様にも使っていただき、問題点があれば教えて頂きたいと思っています。開発しているマシンがmacなのでIE系のテストは皆無です。IEの方、ぜひともレポートをください。
レポートや感想などがありましたら、「おなりん」のサイトの下にある「お問い合わせ」リンクから送付をお願いします。また、巡回してほしいサイトも募集しています。ただし、日本国の法律に準拠したサイトに限らさせて頂きます。
機能的に今後は、画像の人気ランキング機能を組み込む予定です。また、サイト運営の足しにしたいのでひっそりと広告を入れます。
また、リクエストがあれば、ソースコードをGithubに公開したいと考えています。
長文を読んでいただき、ありがとうございました。
今日プロジェクトの打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQLの魔女と呼ばれていた。
今から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSEの仕事内容、特にWebのアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。
初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。
与えられた課題を終えるごとに、コードを提出するのだが、見たよ〜出来てると思う、頑張ったね〜と言われた後で、そのプロジェクトを下敷きに発展課題に足を進めたら、でっかいバグがあったり。
万事その調子で、今やってる課題放り出して、プロジェクトオイラーの問題でも解いてた方がよっぽど楽しいなぁと若干サボりたいと思い始めた頃、炎上プロジェクトへ先輩と二人テスターとして出向するよう、上司から命じられた。炎上プロジェクトのリーダーから手待ち要員いない？と声がお上に届き、降りて来た結果先輩と自分がいたわけだ。
前の事業部ではずっと同じ客先にいたわけで、頭では分かっていても鼻先三寸で飛ばされることには不安がつきまとった。
「これから行く先はどうなんでしょうね？」
先輩へ問うと、
「基盤にいたんでしょ。メインフレームが扱えるなら大丈夫だよ〜」
豆腐すらぷるぷる震えそうな声が返ってきた。
この時の私は、まだ事業部を転属して間もなかったし、プライドばかり高くて奢ってたように思う。事業部を変える→入社して以来の経験値がまた0に、と失うことに対する不満ばかりで、それが拗れて数少ない基盤系経験アプリ開発者、そんな肩書きばかりを強調する変人に成り果てていた。自己紹介で、どうも、基盤から参りましたと、そこだけは大きい声が、今思い出したけどマジで恥ずかしい。
だから、だろう。このゆるふわな先輩とドナドナされることに密かに感じていた屈辱には、出向いた先で押された駄目テスターという烙印によって罰があたることになった。
その理由は、私がSQLを全く使えなかったことにある。テスターとして行うことになったのは表示画面の統合テストで、UIの検索結果とデータベースに直接SQLを打ち込んで得たレスポンスを目で確認していく作業だった。UIは、境界値さえ気をつけて、仕様通りに実施すれば何とかなる。しかし、SQLで再現が出来ない。この仕様はどうやったらコマンドに落とし込めるんだよ。頭を抱える中で思い出したことがあった。
教育過程でJavaサーブレットを学んだが、その一つにJDBCも勿論習った。そこで私は何をしたか？mysqlに繋げればそれでいいやと、エグゼキュートで実行する際に渡す魔法の文字列……つまりSQLの中身は、すべてコピペで済ませていたのだ。社内教育資料を内部作成するにあたり参考にしたと思われるネットから……構文チェック効かないし、ここは手を抜いてもいいだろう、これが要領の良さというものさ……アホーアホー私のアホー。
三日目の午後二時、進捗を確認しに来たPMにすべてを告白すると、ちょっと来てとPMが連れ出したのがあの先輩の席だった。
「申し訳ないけど今やってるテストは止めて、これから定時いっぱい最低限テストが出来るように彼にSQLを教えてやってくれ。」
良いのですか？と顔をあげるとPMは何を勘違いしたのか、やにわに私の肩を叩くと、
「彼女はSQLの魔女と呼ばれている。半日でお前も即戦力だよ。」
と去っていった。顔を先輩へ戻すと、あのPMさんは嘘つきだから信じないほうがいいよといつものふわふわした声でにっこり。
宜しくお願いします。ノートパソコンを横に私は型通りの挨拶。四時間後、私は傲慢さを、尻の毛まで抜かれることになる。
私はSQLの深さを知った。SQLのQとは何だ？Queryであります、サー!!今も時々夢問答を繰り返す。そう、全ては問い合わせ次第なのだ。今思えば、あの時やったことはT2テストを使ったSQL文の作成と添削、しかもSELECTによる条件抽出のみだったが、そこに全てが詰まっていた。
DISTINCTとORDER BYの共存で詰まってわけがわからなくなったコードは、もっとシンプルにいけるよと副問い合わせに書き換えられて。ネストとワイルドカードを多用してスパゲティになったコードを、先輩はLEFT JOINとWHEREとORで全てをすませた。
なんということでしょう。マニキュアが塗ってある長い爪からは想像もつかない早さで直されていく構文に脳内で途中から匠の曲が流れ始めたのを覚えている。本当に、なんということでしょう。先輩はSQLの魔女だった。
翌日、先輩の教えはしっかり自分に身に付いていた。すらすら書けるSQL、サクサク進むT2テスト。条件設定に悩んで、エクセルに吐き出してからリストとコピペで逐一加工してた時間が馬鹿みたいだった。先輩のところへ、帰りしなに昨日のお礼と作業進捗に激震が走ったことを伝えると別にお礼なんていいよーといつものふわふわした顔で微笑んでくれた。
それから先、配属先が決まるまでの条件付きでテスターとして入っていたはずだったが、T2試験が終わり、T3試験が始まってもなぜか私はそのプロジェクトにいたままだった。DB担当者として。もともと基盤だったわけだし、バッチファイル処理でスクリプトがそこそこ書けたというのもあるけど、SQLが書けたというのはすごく大きい。昼休み、いつのまにか私はプロジェクトオイラーの問題に代わって、名著「SQLパズル」を解くのを日課としていた。
先輩は仲良くなる暇もなく、その後すぐにプロジェクトを移り、メーリングリストで寿退社を知った。炎上したプロジェクトは、なぜか横展開を経て今に至り、私は相変わらずここにいる。だが、あの時SQLの魔女がかけた呪いは今もしっかり私に根付いている。