Hatena::ブログ(Diary)

みぞやんの日記 RSSフィード Twitter

2013-05-23 [SQL]

ちょっと久しぶりに書く。hatena記法を忘れたけど

@naka_aki_spl

RDBカラムの初期値(default)って、「ほかのマスタテーブルの値を引っ張ってくる」みたいなこと、つまり式、を書けたっけ?書けたらいいなあ。

試してみた

適当にH2databaseを使用した

BBBB_CODEテーブルがマスターテーブル,AAAAが対象のテーブルとしたらこんな感じで定義


    • BBBB_CODEテーブルの定義

CREATE TABLE BBBB_CODE(

BBBB_ID INT NOT NULL

,BBBB_CODE VARCHAR(20) NOT NULL

,BBBB_CODE_NAME VARCHAR(50) NOT NULL

,DESCRIPTION VARCHAR(50) NULL

,PRIMARY KEY (BBBB_ID)

);

INSERT INTO BBBB_CODE(BBBB_ID , BBBB_CODE , BBBB_CODE_NAME )values(1,'0000','未入力');

CREATE TABLE AAAA(

AAAA_ID INT NOT NULL

,BBBB_ID INT NOT NULL DEFAULT (SELECT BBBB_ID FROM BBBB_CODE WHERE BBBB_CODE.BBBB_CODE_NAME = '未入力')

,DESCRIPTION VARCHAR(50) NULL

,PRIMARY KEY (AAAA_ID)

);


インサートしてみる

INSERT INTO AAAA (AAAA_ID)values(1);

で、中身を確認


select * FROM AAAA;

AAAA_ID BBBB_ID DESCRIPTION

1 1 null

(1 行, 2 ms)

入ってる

2012-07-26 [java][備忘録]javaのenumで継承ができない話

まず、enum継承できないんだよねって話

こんな感じで、ユースケースenumとして管理したいと・・・

public enum 発注 extends Abstractユースケース {

  仕入れ先を追加する, 仕入れる

}

public enum 経理 extends Abstractユースケース {

  お金を支払う, お金を受け取る

}

当然、enum継承できないから、コンパイルエラーになる。

で、インタフェイスは実装できる。

そこで、イロイロ調べていたら、インタフェイスは実装できることが分かったので実装してみた。

public enum 発注 implements Iユースケース {

  仕入れ先を追加する, 仕入れる

}

おー、コンパイルエラーが消えた。

そんな時にさ・・・

ユースケースを超えてセッション情報を破棄するような感じで処理を組みたいってことで、UsecaseGroupってアノテーションを作って指定させてみたの。それが、こんな感じ。

@UsecaseGroup(発注.仕入れ先を追加する)

public class 仕入れ先を追加するUsecase {

  public 登録Form 初期表示(){

    ・・・

  }

  public 登録済みForm 仕入れ先を追加する(){

    ・・・

  }

  ・・・

}

こんな風に書いていきたいのね

アノテーションはさ・・・

なので、アノテーション自体はこんな感じで定義

interface @UsecaseGroup{

  Iユースケース value();

}

そしたら、コンパイルエラーになるのね・・・

インタフェイスは、メンバ・アノテーションに設定できないから。

使えない・・・

いいアイデアないですかねぇ・・・

2012-05-22 久しぶり

日記タイトルを「ぐっちの日記から「みぞやんの日記」に変更しました。

また、よろしく、お願いします。

レビュー

自分の置かれている場所空気感最近変わってきているので、文章に残しておいてみようと考えて、久しぶりにblog更新してみます。それは自分を置いている場所のせいなのか、時代のせいなのかはわかりません。

おそらく、そのどちらもでしょう。

自信の無さ

ここ数年、自分に自信がありません。

自分のしている事に自信が持てないのです。ともかく、不安なのです。

何か自分ダメな点が分かれば不安も解消できるのかもしれませんが、どこがダメなのかも判りません。

これは、自分に対してだけではなく、他人に対しても同じです。すべての物が信用できないのです。

できるだけ多くのテストを早いタイミングでしたい。テストNGであれば、ジャッジをして、必要なら早い段階で対策をしたい。その様に考えるようになっています。

ともかく、早いフィードバックが欲しいのです。

問題点

多人数参加のレビューで見直すなんて効率的ではない。大量の人数が参加するレビューでの、意味のない日本語向上の指摘など、反吐が出る。レビュー後に、レビュアーの言う、「すこしぐらい日本語として読めるドキュメントを書いてほしい」とかいう、愚痴もイライラする。低レベルだと思う。

はっきり言って、ドキュメント記述者の中には日本語弱者の人もいる。そんなの、査読をできる人が事前に、推敲してもいいんじゃない?そんなアイデアも出ないってことだよね。原因はうっかりではなくて、体制的な問題だよね。レビューイ個人に責任押し付けて、瞬間的に楽をしているだけだよね。

レビューを楽に進めるのは、効率よくレビューして品質を上げること。日本語些末なことを高い技術力を持った人が行って、問題点として上げられない。レビューイがウッカリしてたっていう原因にすること自体が、問題。そもそも、「レビュー」は言葉意味は「見直し」だろ。

じゃあさ

レビューアーは、上段からレビューイを責めるんじゃなくて、もっとレビューによって品質をあげるのに邪魔になっていることに真剣に立ち向かってほしい。無責任だと思います。

レビューアーは、さぞかし経験を積んで、メカのようにミスをしない方々なのかもしれない。しかし、レビューイは人間的でミスをする人だと考える余裕をもって欲しい。日本語品質が悪くて、レビューアーが成果物効率的レビューできないなら、レビュー前に推敲を提案して欲しい。レビューという作業が、効率的に行われるように立ち向かってほしい。日本語弱いという記録は数字として現われてきていると思う。

一方でレビューイは、自分レビューしてもらいたい部分をレビューしてもらえないなら、程度が低いことを認識すべきだ。レビュー対象物の日本語レベルが低く、技術的なレビューを受けられないドキュメントであると理解すべきだ。日本語レベルが低いから見直してほしい。技術的なレベルが低いから見直してほしい。それぞれを効率的に行えるように提案するべきだ。それが、結果的に短い期間の最適化にはつながる。

ボトムアップからは、こういうアプローチしかないのかもしれない。

ビィジョンに向けた戦略戦術をみんなでとっていかないと、ダメなんじゃないかな。ダメビジョン戦略はあると思うけど、そんなレベルの問題を正攻法で攻めたり、責めても無駄で、正しいと思う方向にみんなが動かしていくために、どうしたらイイかを考えて動こうよという事。愚痴を言っていても、何も変わらない。

戦略ミスビジョンミスを正せる人は、正せばいいし、戦術ミスを正せる人は正せばいい。それすらできない人は、部分最適や、戦術ミスに気がつかせるにはどのように動くかを考えていったらいいと思う。