kenjiro_nのブックマーク - はてなブックマーク

Apache TomcatとHTTPクッキーにまつわる騒動 - GeekFactory

Apache Tomcat 5.5.26（6.0.16も同じ）で、HTTPクッキーの取り扱いについて大きな仕様変更が行われました。ここでは仕様変更の内容と影響範囲を考察します。 HTTPクッキー簡単に復習しましょう。WebブラウザがWebサーバから以下のHTTPヘッダを受信したとき、Webブラウザは test というクッキーを記憶します。 Set-Cookie: test=nullpo; Expires=Wed, 08-Oct-2008 14:03:16 GMT; Path=/クッキーは NAME=VALUE という形で表現されます。連想配列と同じ。 NAME VALUE test nullpo 一度クッキーを受信すると、ブラウザは当該URLにアクセスする度に、以下のHTTPヘッダを送信するようになります。 Cookie: test=nullpoこのように、クッキーはWebサーバがブラウ

kenjiro_n 2013/07/10

リンク

How to install Apache Tomcat 7.0 on Linux - GeekFactory

公式ドキュメントに従って Apache Tomcat 7.0 をインストールしてみました。前提条件 Scientific Linux 6.3 x86_64 Oracle JDK 7u7 x86_64 Apache Tomcat 7.0.30 gcc, make などのビルドツールが必要です。実行ユーザ実行ユーザを作成します。ここでは tomcat:tomcat とします。 sudo useradd -d /var/lib/tomcat -s /sbin/nologin -r tomcat id tomcat sudo mkdir -p /var/lib/tomcat sudo chown -R tomcat:tomcat /var/lib/tomcat ls -l /var/lib/tomcat Directory structure アーカイブを展開します。ここでは /opt/to

kenjiro_n 2013/07/04

Tomcat
Linux

リンク

SSHとHTTPSでアクセスできるGitサーバの設計と構築 - GeekFactory

(追記) この記事は公開から時間が経っており、内容が古くなっています。本稿では、すでにプライベートなWebサーバを運用している人向けにGitサーバの構築方法を説明します。ひと手間をかけるだけでGitサーバを構成できます。Webサーバがない人はGitHubでプライベートリポジトリを作った方が早くて安くて旨いかもしれません。要件以下の要件を考えてみます。 SSHでGitリポジトリにアクセスしたい。 HTTPSでGitリポジトリにアクセスしたい。 Webブラウザでリポジトリを閲覧したい。 Gitリポジトリには機密性の高い情報を格納する可能性がある。具体的には、 git clone git@git.example.com:/something.git とか、 git clone https://myname@git.example.com/something.git とかしたいです。 Gi

kenjiro_n 2013/07/04

SSH
git

リンク

もしSIerのマネージャがFizzBuzz問題を解いたら - GeekFactory

SIerのピーエム*1と呼ばれる人たちはパワーポイントを武器に日々闘っている。そんなパワーポインターがFizzBuzz問題を解いたらどうなるだろうか？作ってみた。作成手順書 PowerPointを起動する。スライドマスタを表示し、ページ番号を大きなフォントにして中央に配置する。空白のページを15ページほど用意する。 3、6、9、12、15ページ目に、Fizzと書いたテキストボックスを配置する。 5、10、15ページ目に、Buzzと書いたテキストボックスを配置する。 1〜15ページをコピーして必要な分だけ貼り付ける。レビュー指摘管理簿レビュー出席者：部長、課長、次長、ヒラ（記）レビュー時間：120分ページ数：60ページ社内標準のスタイルを使っていない。会社のコピーライトがない。プロジェクト関係者の秘密資料であることの表示が入っていない。フォントがMSゴシックでない。

kenjiro_n 2013/07/04

リンク

受託開発が抱える本質的な非効率性に関する考察 - GeekFactory

受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。外注のオーバーヘッド契約に係るコスト。限られた場所や時間で質疑応答を行うことによる損失情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。決定に要する時間が長くなる。開発者が業務プロセスを学習するコスト前提として、どんな要件でも学習コストは必ず発生する。過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。

kenjiro_n 2010/09/19

リンク

90年代と21世紀の越えられない壁 - GeekFactory

実質的な仕様承認者となることが多いであろう30代後半の人は、1990年代のクライアントサーバの経験で生きている。業務トランザクションやGUIの考え方は、VBに代表されるクライアントプログラムがベースになっている。業務データが入力されてからコミットされるまでプログラムは動いているし、画面の操作はイベントでやってくる。これに対して、Webを当たり前のように使っている人たちはステートレスな世界に慣れているし、画面の操作はページ遷移を伴うことを前提にしている。HTMLで書かれたページに対してMouseOverだの再描画だの言っても噛み合わない。両者の間には越えられない壁が存在する。まとめると、世代の違う人がレビューすると前提が違いすぎて話が噛み合わないケースがある。そんなことを感じた今日この頃。企業内システムはまるで時計が止まった世界にあるようだ。