Hatena::ブログ(Diary)

日々量産 このページをアンテナに追加 RSSフィード Twitter

2016-09-30

[] プロジェクトを進める上での「要望・要求・要件」と愚痴

感情的になっちゃったので先に反省しておくと、自分がもっと要求分析をしたりして具体的に何をしたいかを聞き出したりしなかったのが悪いとは思っている。(客との距離間があって話しにくい。)

しかし、客はもっと自分がやること・自分が関わるプロジェクトに関心を持ってもらいたい。自分みたいなのと仕事するのは不安でしょう。


話は少し変わりますが、プロジェクトの進め方について勉強したわけではないけど、要望・要求・要件という言葉の使い分けをどこかできいて、プロジェクトでは必須では、と思ってる。

自分の頭の中ではこんな感じ。

  • (要望)これやりたい、何かをしたい
  • (要求)実現するにはこういうのが必要
  • (要件)こういうのを実現するには、こうしたらどうでしょうか

客側は「要望」と「要求」は固めるべき。要望は複数の要求からなりえるし、要求は要望にもなりえる。開発に伝わるまで小さくしていきましょう。

開発側は「要望」と「要求」を聞いて「要件」に落とし込む。場合によっては「要求」が足りなかったり、「要求」が見当違いなことになっているかもしれないから、こういう「要求」ではないですか?と提案する。(あと、客側に「フワフワさせてないで要求をはっきり言えや」と言える気概も必要かも。)

客は要求までをしっかり言えれば良くて、開発は要求から要件を固めればよい。

要望と要求について、客と開発の間で合意を取っていたら、巻き戻ることもない。

あとは、時間はかかっても焼きあがるはず。あとは正直に行きましょう。未知のソフトウェアについて知ったかぶってはいけない(戒め)

でも、この「要望・要求・要件」がちゃんと出来てないと、辛くなるのではないでしょうか。僕はそう思いました。

ポエム終了。

以下も頭の悪そうな愚痴。

続きを読む

2016-05-26

[]Domain別にCookieを送る条件を調べた

Perl5のWWW::Mechanizeの挙動がなんか怪しかった。で、HTTP::Cookiesがどうも怪しそうだった。

送るべきCookieを送れてなかったりとか。

で、何が正しいのかわかんなくなってしまったので、Chromeと動作を比べた。

RFCとか見ればわかる事なんだろうけど、見てわかるような表がほしかった。文字読むの苦手なんだ。

確認方法

  1. Set-Cookieを受け取るためのアクセスを行う(「A」)
  2. Cookieを送るためのアクセスを行う(「B」)
  3. 「B」のときに送られたCookieの内容を確認する。(「A」でSet-Cookieした内容が送られたら○、そうでないなら×)

対象domain

  • ryozi.net
  • main.ryozi.net
  • sub.ryozi.net

Set-Cookie時のdomainの値

  • domain指定なし(none)
  • domain=ryozi.net
  • domain=.ryozi.net
  • domain=main.ryozi.net
Chrome
「A」のドメイン「B」のドメイン(none)ryozi.net.ryozi.netmain.ryozi.net
ryozi.netryozi.net×
main.ryozi.net××
sub.ryozi.net××
main.ryozi.netryozi.net××
main.ryozi.net
sub.ryozi.net××
sub.ryozi.netryozi.net××
main.ryozi.net××
sub.ryozi.net×

WWW::Mechanize
「A」のドメイン「B」のドメイン(none)ryozi.net.ryozi.netmain.ryozi.net
ryozi.netryozi.net×
main.ryozi.net×
sub.ryozi.net×
main.ryozi.netryozi.net××××
main.ryozi.net
sub.ryozi.net××
sub.ryozi.netryozi.net××××
main.ryozi.net××
sub.ryozi.net×
  • サブドメインでアクセスした際、親(ryozi.net)のSet-Cookieは受け付けない?
  • noneでもサブドメインで送っている?

確認時に使ったコード

https://gist.github.com/ryozi-tn/f2be9b397cf9b2402c352b27a21a75bb


後はクッキーの上書きを登録時のdomainとは異なるdomainからでも出来るのか、domain値が似てるようで違う(「.ryozi.net」と「ryozi.net」)場合も上書きできるかなども調べたほうがよさそうだけど、面倒になったので諦めてPhantomJSでやることにしました。

PhantomJSもこれはこれで辛い・・・

2016-05-22

[][]WWW::Mechanize(LWP::UserAgent)でHTTPリクエストの前後に処理をはさみたい

WWW::Mechanizeを使うとリダイレクト処理とかよしなにやってくれて便利。

しかし、うまくクエリパラメータが渡されてないとかになってくると、やっぱり間の状況もしっかり見たくなる。

つまり、curl -Lv URL みたいに、リダイレクトを含めたリクエストログを出したかった。

my $m = WWW::Mechanize->new();

$m->add_handler("request_send", sub {
  my $req = shift;
  say "--- REQ -----------------------------------------------";
  say $req->as_string;
  undef; # 自前でHTTP::Responseを返すと実際のリクエストが飛ばなくなる。なのでundefを返しておく。
});

$m->add_handler("response_done" => sub {
  my $res = shift;
  say "--- RES -----------------------------------------------";
  say $res->message;
  say $res->headers->as_string;
  undef;
});

$m->get('http://wwwwwwwwwwwwwwwwwwwwww')

LWP::UserAgentはhandlerをいくつか持ってるので、その処理に合わせてコールバックを設定することができる。

これを利用して、リクエストの前後に処理を仕込むことができる。


・・・2016年らしからぬ記事を書いてる気がする。

2016-03-07

[]contenteditableの領域に項番を出したいけど編集できないようにしたい

contenteditableにしておいてお前は何を言ってるんだと思われるかもしれないけど、同じことしようとすると絶対こう思うから。まじで。

https://gist.github.com/ryozi-tn/5496e56e9141a5559f5b

(ol|ul)とliで頑張るか、CSSdomのattributeを参照して表示するかの2択かなーと思います。後者は項番に限らず任意の文字列を動的に出せるのが良い点かも。

JavaScriptで頑張って制御を入れてもいいんだけど、自分は辛かったのでやりたくなかったです。

contenteditableを(input|textarea)みたいなものだと思ってしまうと闇が待ってるぞ・・・


全く関係ないメモ

  • CSSで使える":before"にかかる要素のことを疑似要素(Pseudo-Elements)と呼ぶんだって。

他にも言えることだけども検索するとき、css selector beforeみたいなよくある単語だとノイズが多すぎるので、pseudo-elementとかより具体的なものを加えてさらに絞ると良い。



また使い捨てタグを作ってしまった・・・

2016-02-29

[]仕事辛い

まだ作業途中だけど、仕事で必要になったので書いてる。

Wordpressの記事を作るとき、ある程度決まったフォーマット上を与えて特定の箇所だけ、自由にかけたりするようなものがほしくて、それを結構な数用意しないといけない。(現状は4つだが・・・)

jQueryのゴリ押しで出来なくもないんだけど、ちょっとした改修が面倒だと嫌だし、他のデータをもとにして動的に画面が作られる部分も多い。例えばタイトルを変えるとパンくずの末端にあるタイトル部分も変わるとか。

それに、特定の項目は可変長で増えるので、そのテンプレートをどこかで保持しないといけない。jQuery一本でやるとなると、JavaScriptに持たせるかしないといけない。(WebComponentsはまだ未来の技術みたいだ。)

続きを読む