サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
セキュリティ
itoasuka.hatenadiary.org
Cubby でちょっとした Web アプリケーションを作ったのですが、意外と分かっていないところがあったのでロガーを差し込みまくっていろいろ調べました。 アクションクラスの各メソッドの実行順序 アクションメソッド(戻り値の型が org.seasar.cubby.action.ActionResult のメソッド)、initialize、prerender、postrender、そして JSP(View 層)、それぞれどのような順番で実行されているかといいますと、以下の順番です。 initialize アクションメソッド prerender JSP postrender バリデータがあれば、以下のようになります。 initialize バリデータ アクションメソッド prerender JSP postrender では、バリデータでエラーとなった場合はどうなるかというと以下のようになります
P(Plan=計画)、D(Do=実行)、C(Check=評価)、A(Act=改善) もうすっかりおなじみの言葉になっていると思います。 この間、面白いものを見たのです。 あるプロジェクトで、単体テストの不具合の原因の集計を行っていたんですね。 それ自体はいいんですけど、そのプロジェクト、ウォーターフォール型の開発プロセスをとっているんですよ。なら、その集計した結果は何に反映させるのでしょうか? 他のプロジェクトにでも使うのでしょうか? まさか! だって、このプロジェクトも他のプロジェクトからのインプットなんてなかったですもの。 つまり、意味のない集計ってことですね。自己満足止まり。集計の分、余計に工数を取るだけです。 PDCA を上手くまわしたいのならば、勇気をもってウォーターフォールと決別しましょう。そう、勇気をもってです。
ITは「理系」なのか? - モジログ この記事の内容は理解できます。しかし、ぐだぐだな IT(というかコンピュータシステム開発)の現場には圧倒的に理系(というより工学かな)的な発想が欠落していると思います。 とにかくシステマテックではない。理にかなっていない。 「設計」という名の決め事で走り始め、「規約」という名の束縛のもとに造り、「試験」という名の泥沼にはまる。 「仕様書」と「設計書」を混同している現場があるのがそもそもいけないのか、「設計する」とは言っても「仕様する」とは言わないように、仕様は決め事ですが、設計は方法論に基づいて「すること」なのです。 「コーディング規約」などに代表される「規約」ももちろん一種の「縛り」ではあります。縛りはできればないほうが楽です。なければないほうがいい。なのになぜあるのか? これをちゃんと考えていないところも多いですね。たいていはこういう返事が返ってき
あるプラットフォーム(たとえば汎用機)から、別のプラットフォーム(たとえばUNIX)に移植、移行作業をする場合、こういうことを考える人ってあんまり経験がないんだろうなぁと私は思いますね。 それは、ついでにいままでのシステムでいけてないところも直しちゃおうということです。 これ、絶対失敗します。たとえば、電文で、なくてもよさそうな項目を削ってしまうとか、ファイルレイアウトで非効率的な部分を直そうとか、さらにいうなれば、移行前のプラットフォームなら効率的でも移行後のプラットフォームでは非効率的な部分をなんとかしようとか、そういうのを一緒にやると絶対失敗します。ここでいう失敗とは、見積もり工数を大幅にオーバーするとか、そもそも工数を見積もれないとか、そういう事態になるということです。 最初は、愚直なまでに可能な限り移植前と同じ姿、同じロジックで移植すべきです。手続き型言語からオブジェクト指向言語
DB のテーブルの項目に「更新日時」なんてあるくせにブラウザキャッシュをうまく使わせていない Web アプリケーションをよく見かけます。もったいない! ブラウザキャッシュを考慮した Cubby の Action クラスの例 // S2Containerの機能でリクエストがインジェクションされる。 public HttpServletRequest request; // 同じくレスポンスがインジェクションされる。 public HttpServletResponse response; public ActionResult index() { // ブラウザが送ってよこすキャッシュの時刻を取得 long cacheTime = request.getDateHeader("If-Modified-Since"); // ここでテーブルの更新日時を取得 // java.sql.Timest
いまさら日本のIT産業の構造をどうこういうつもりはないですが、たいていこの業界の人ならどこかの大手SIerの文化に触れたことがあると思います。あるいは、どっぷり下請けなんてやってることでしょう。 私は今、富士通文化に浸ってます。以前は以前でまた別な文化に浸ったわけですが。 ということで、富士通文化目線で話します。これは富士通さんを攻撃するための記事ではないので、そこのところお間違いなく。また、富士通文化がわからない方が読んでもさっぱりわからないと思います。 富士通さんにはSDEMという開発標準があります。いつ制定されたかは私にはわかりません。ですが、少なくとも5年以上前であることはたしかで、前身も含めれば、10年より新しいことはないでしょう。 それでですね、富士通さん自身と、そのグループ会社、関係会社は、ほとんどのプロジェクトにこのSDEMを持ち込むのです。Webなんてなかった時代に策定さ
某大手 SIer の人が、自社の Web フレームワーク(Java 用)を指してこう言ったんです。 これは一般に公開しないし、単独での販売もしません。これは我が社のアドバンテージとして我が社の受注開発のためだけに使用します。 おいおいおいおい。うぬぼれなさんなよ。と思っちゃいましたね。 こんな、使用するのに専任技術者のレクチャーがないと Hello, world! もままならないものを誰が好き好んで使いますかって。 いや、こういうの、よくありますよね。「これを公開したらうちのアドバンテージが損なわれる」みたいな。でも、実際はそうでもないんですよね。そんなにすごいものなら、特許でもとってパテントで食ってるほうがよっぽどいいですよ。でかいこといっても大手 SIer だってプロジェクトこかすことなんてざらですからね。そんなリスク背負うぐらいなら、そのものすごいツールのパテントで食べましょう。 た
とてもよくできた(無償で利用可能な)オープンソースソフトウェア(以下 OSS)を指して「よくこれを無償で出すもんだ」「なんでただでできるのか」と言う人がいます。その気持ちはわからなくないです。お金にからむ疑問は、生活の基盤がお金である以上、誰しもが持つものでしょう。 ですが、その次というのがあってもいいと思うのです。つまり、技術者ならではの疑問です。 ところが、「このソフトは何行ぐらいのソースコードでできているのか」を気にする人は技術者であっても意外に少ないように思えます。中には、自分たちが「ダイキボ」プロジェクトと呼んでいるもののコード量をはるかに凌いでいるのさえ気がついていない人もいます。 そして、そのようなものが「世界中にちらばっている技術者たちでどうやって作ったのか(マネジメントも含めて)」を気にする人もとっても少ないです。 ボランティアベースというのは、逆に見れば意欲が続く限り無
エンジニアがエンジニアを説得するなら、 より良いコードを見せるほうが早いと思うんだけどねぇ。 確かにそう思います。でも、ですね。いないんですよ、その「エンジニア」が。 エンジニアとコーダを混同してないかというようなコメントがついていますが、そういうレベルじゃないです。 たとえば、SE は「エスイー」なんです。「システム・エンジニア」でなんか決してない。というのも、ほとんどの現場では、彼らがやってることは「決め事」だけだからです。合理性といいますか、設計手法といいますか、そういった方法論に基づいて仕事をしているわけじゃなくて、過去の成功体験を反芻しているだけなんですね。 しかも、この成功体験ってのもあやふやで、彼らの多くはプロジェクトがいくら火を噴こうが、納品が済んでしまえば、このプロジェクトは成功したと思い込んでしまいます。でなくとも、火を噴いた理由をコーディングにかかった工数にしか求めま
Excel って何ソフトですか? 表計算ソフトですよ。それで文書作ってくるっておかしいでしょ。 言ってしまえば Adobe Illustrator でラスタ画像を作ったり、Adobe Photoshop でベクタ画像作るみたいなもの。自分たちの中での「ノウハウ」なら使うのも手かもしれないけど、外出しにすべきものじゃないですよ。 もっと簡単に言ってしまえば、ルーズリーフに履歴書書いてくるようなものですよ。それで、それをやった理由が「書きやすかったから」。相手のことを考えてません。なぜ履歴書用紙が販売されているのか考えてません。 いくら叩かれ続けている Microsoft といっても Excel よりは Word のほうがはるかに文書作成ソフトとして完成度が高いものとしてリリースしていますよ。いくら叩かれ続ける Microsoft といっても、その財力にものを言わせて雇った人材は、そこいらのぼ
私は、ホームページ・ビルダーを10年ぐらい(つまり、出た当初から)使っているのですが、未だにホームページ・ビルダーが不当に低く評価されていると思います。特にWebアプリケーション開発の現場で。 そこで、不当に低く評価する彼らの言い分に反論してみたいと思います。 ホームページ・ビルダーは変なタグを入れる 入れません。独自タグはもちろん、独自属性も入れません。ビルトインの JavaScript を使ってどうこうするとかでない限り、勝手にコメントすら入れることもありません。 PageMill とかと混同してませんか? それにしても PageMill はひどかったな。と言っても10年ぐらい前の記憶だけど。 ホームページ・ビルダーは HTML を崩す 崩しません。といいたいところですが、崩すこともあります。それは、ホームページ・ビルダーの「自動修正」機能が働くからです。しかしこの自動修正機能が働く条
初心者が考えがちな「Linuxの普及しない理由」 - 狐の王国 私も考えてみました。サーバ OS としてはもう十分に普及していると思うので、デスクトップ OS としての Linux について考えます。 なお、この記事で言う Linux とは、厳密な意味での Linux、つまり Linux カーネルのことではなく、Linux ディストリビューションおよび Linux をとりまく状況のことです。 IE が動かない 私が肌で感じている最大の理由がこれです。うちの奥さんの PC の使う様を見ているとこれさえ動けば問題なさそう。うちの奥さんが使ってる PC は IE の動きがいまいち不安定なので、Firefox ユーザの私はうちの奥さんにも Firefox を使わせていたのですが Yahoo! 動画が見れないということで IE を捨てきれずにいるのです。うちの奥さんは、ネット以外ほとんど PC を使
「自分のやりたいことがわからない」といって、自分のやりたいことが見つかるまでフリーターで食いつなぐという人がいます。 私は、こういう問題の専門家でもなんでもないので想像の域をでませんが、たぶん、そういう人は一生自分のやりたいことなんて見つからないと思います。 自分のやりたいことはこれだ!と言って仕事に励んでるいる人は、それまでの生き方にその根拠があることがほとんどだと思います。たとえば、エンジニアこそが自分のやりたい仕事と思っている人は、小さいときからものづくりが好きだった等です。 逆にこのように小さいときからものづくりが好きだったわけでもない「自分のやりたいことがわからない」人がエンジニアという仕事が「自分のやりたい仕事かもしれない」と思ったとしましょう。この人にある苦難が訪れたとき少なくない割合で「やっぱり自分はこの仕事はやりたい仕事ではない」と簡単に言ってしまいます。 しかし、小さい
ミラクル・リナックスで業務システムを動かしている顧客を持ってる人〜? (´・ω・`)ノ ハイ 3年ぐらい前ですかねぇ〜。中国に工場を作った地元の製造業の会社のオーダーで、日本と中国をまたにかける社内システムの開発をしたんですよ。 今でこそ、それなりにそのへんでは顔が売れている私ですが、当時は「だれ、この人?」みたいな感じで、元受もうちじゃなかったし、最初は蚊帳の外っぽかったんですね。 で、ですね。 DB は、Oracle ってことになったんですよ。で、当時はまだ、Redhat のカーネルのパラメタいじらないと Oracle 動かないよとかまことしやかに言われててですね、そこに「すんなり Oracle のインストールができて、すんなり Oracle が動きますよ!」的なことを売り文句にミラクル・リナックスが話題になりかけてたんですね。 それとともにちょうど Asianux とかいいはじめてで
最近、IT業界に従事していながら、素人臭いことを平気でする連中が増えてきました。IT業界にいるからこそできる「IT気遣い」をしない連中です。もう少し具体的にいうと「IT気遣い」とはコンピュータシステムにおいて「大抵大丈夫な(問題にならない)んだけど、場合によってはうまくいかない場合がある」ことを回避する心です。そういう心がない人は↓こんなことを平気でします。 メールに半角カナを使う。 一度にたくさんの人にメールを送るとき、To に送り先を並べる。 メールのサブジェクトがいつも同じ。 アドレス帳を使っていないのか、関係のないメールの返信としてメールを作成しはじめ、サブジェクトと本文をまるっと変えてまったく関係のないメールを送る。 メールに機種依存文字(まる1とか)を使う。 添付ファイル名が日本語(マルチバイト文字)。 メガバイトオーダーの添付ファイルを平気でつける。 Webページのコンテンツ
会社によっては業務に関係のないことでインターネットを閲覧することを厳しく制限していることがありますね。そういった観点で、たとえば昼休みでのインターネットの使用を禁止しているところもあります。 うん。経営側としてはその気持ち、わからなくもない。 では逆に被雇用者がこれと同じぐらいドライだったらどうでしょう。 家にパソコンなんて持たない。 もちろん、家で勉強なんてしない。 つまり、業務上知りえたこと以上の技術の習得をしない。 日が変わっても、週が変わっても、連休が明けても、そのまえとは一切変わることのない能力。 経営側からしたら、すごく使えなさそうに見えます。でも、経営者側は業務時間中に業務に関係ないことをするなと言った以上、これを批判してはいけないのではないでしょうか? 業務時間中に業務に関係ないことをしてはならないのなら、業務時間外に業務に関係あることをする必要はないでしょう。 しかし、実
偏見的な見方ですけど 技術者 1.0 昔かたぎの技術者みたいな。ただし非汎用機系(笑 車輪の再発明を厭わない。フルスクラッチして何ぼ。 というか人の車輪を信じない。人の車輪はパンクしてるとか思ってる。 VB でも Windows API を叩きまくる。 C ならポインタのポインタのポインタとかにキュンキュンくる。関数型引数とか大好き。 スクリプト言語ならワンライナーとして命をかける。 バグはコンピュータが気を利かせてくれないから出ると思ってる。けど、本当に悪いのは自分だと自覚してる。 技術者 2.0 Web 2.0(死語)時代の技術者 他人のふんどしで相撲どころか日常生活も送っちゃう。 思いつたと同時にプログラムができてる。 車輪の再発明はしない。100輪駆動車とか乗っちゃう。 C でできたものは外国の「偉い人」がいつの間にか作ってくれるのでそれを使っちゃう。ポインタとかわかる人は変態だと
メモ。ハードウェアのモニタ等はホストOSに任せるという観点から、最小構成でインストールしても以下のデーモンは消したり止めたりすると良さげ。 rpm -e microcode_ctl rpm -e dhcpv6_client rpm -e ppp rp-pppoe rpm -e irda-utils rpm -e NetworkManager rpm -e bluez-gnome bluez-libs bluez-utils rpm -e ipsec-tools wpa_supplicant rpm -e ypbind yp-tools rpm -e apmd acpid rpm -e smartmontools rpm -e pcmciautils chkconfig cups off chkconfig gpm off chkconfig ip6tables off chkconfig
「ドキュメントはソースコードです」というのはよく聞く話です。しかし、実際の現場ではそれが通用することはあまりないでしょう。しかしながら、「そんな動きはソースを読まなきゃわからんよ!」なんてことが必ずあるはず。 では、なぜソースコードがドキュメントというのが通用しないのでしょうか? それは、ドキュメントは日本語さえわかれば読める(気がする)のに対して、ソースコードはプログラミング言語がわからなければ読めないということもあるでしょう。 ですが私はこうも考えます。 プログラム言語さえわかれば、ソースコードも立派なドキュメントといいたくなるようなソースコードを書く人もいるのです。 それは、かなりベテランのプログラマです。歳は関係ありません。如何にソースコードをわかり易く書くかを常に考え、コーディングしてコーディングしてコーディングしまくったようなプログラマこそがそのようなプログラマになれるのです。
Maven + Continuum で快適な開発ライフを過ごそうかとお考えの諸氏の中に、Continuum は日本語が使えないのか!(日本語が全部 ? になっちゃう)とお嘆きの方もいるかと思います。そこで、その解決方法を今回はご紹介します。 Cntinuum は Webwork という Java の Web アプリケーションフレームワークでできています。ということで、[CONTINUUM_HOME]/apps/continuum/webapp/WEB-INF/classes の下にある webwork.properties 29 行目の #webwork.locale=en_ENこの行を以下のように修正します。 webwork.locale=ja_JPちなみにこのディレクトリとファイルは、1度でも continuum を起動しておかないと出てきません(continuum-plexus-ap
自社の社員だったら、教育すればいいだけなんだけど、他社の人だったらきっついわーって人。大規模プロジェクトでかき集められた人員がこんなんだったらげんなりします。 javac でコンパイルできない IDE に頼りすぎ。いざというときに使い物にならない。こういう人は「そもそも論」がなってないことが多い。 IDE を知らない 上の逆。テキストエディタでこつこつ作る。そのほうがいいものができると確信してやってるわけでもないやつが多い。そういうやつはもちろん生産性が低い。 Entity クラスでもないのに public フィールドを使う カプセル化がわかってないことが多い。Entity クラスだけに限定して public フィールドを使ってたりするのは確信犯(?)だったりするので、別にいいけど。 static メソッドと static フィールドがやたら多い そもそも OOP がわかってないことが多い
未だに Java は生産性が低いと思っている人を見かけます(人によっては「この人、まだ Java の生産性は悪くないって言ってるよ」って言うでしょうけど)。私の周りのそういう人に見受けられるパターンを書いてみたいと思います。 Java をちゃんと身に着けていない 「簡単に身に着かないなら、学習コストの分、生産性が悪いじゃないか」と言われるかもしれません。確かにそうです。ですが、Java がエンタープライズ用途に使われるようになってからいったい何年経ったでしょうか? それは、COBOL に比べたら赤ちゃんみたいなものですが、学習コスト云々というほど新進気鋭の言語ではすでにないはずです。 以前、「C++ が難しいのはなぜか?」という話があって、「それは、Microsoft Visual C++ で学習するからだよ。そういう人は、C++ の文法と MFC と Windows API を同時に覚え
http://osd.jp/itoasuka/ に移転しました。 Wicket 1.5-rc2 がリリースされました。なぜか今回は「RC2」ではなく「rc2」です。お間違えのないようご注意ください(笑)。 これは私にとってとても嬉しいリリースなのです! このリリースにあわせて wicketstuff の 1.5-rc2 がリリースされました。そしてこの中に Wicket の Scala 拡張があるのですが、この度はじめて Scala 2.8.1 対応となりました!(これまでは 2.7.5)。これでシコシコ SNAPSHOT をビルドする必要がなくなります。やったね! 面白みがないので JPA はとりあえずおいときます。Doma がお気に入りなので、Doma が念頭にあったりします。それを踏まえて Scala + Wicket にあう ORM を探しています。文中でいう「エンティティ」とはレ
傍目から見て「ああ、こりゃ炎上するな」と思うプロジェクト。思いつくままに書いたので視点があっちこっちだけど。 ベンダー・ロックインしたいのかどうか知らないが誰も知らないような(シェアのかなり少ない)ツールを使おうとしている。 なので「Java 要員が欲しい」とか言いながら本当に欲しいのはそのツールの要員。 いるわけないので人員不足にあえぐ。 困ったとき Google 先生に聞いても答えてもらえない。 そのくせ開発元に問い合わせない/問い合わせても有用な回答が得られない。 結局ツールの「選定」がおろそか。 おろそかどころか選定すらしていない。 脊髄反射的に関係ベンダーの製品を使う。 脊髄反射的に過去のプロジェクトで使った製品を使う。 しかもそのプロジェクトも炎上しており、その製品を使用したことも原因のひとつだったことを忘れている。 「セキュリティのため」の一点張りでインターネットすらまともに
Click Framework が最近お気に入りです。それで、Seasar 党の私ではありますが、Guice のシンプルさも気になっている今日この頃なのです。 ということで、Click Framework の Page クラスに Guice でインジェクションを施したいんだけどどうしたらいんだろう? ということになりました。それで S2Click のソースなどをそぞろ見ていたのですが、ぜんぜん見当違い(というか私のやりたいことと微妙にずれている)でした。 ということで、自分なりに考えてみたやり方。とても簡単です。まず前準備として、guice-1.0.jar に加えて guice-servliet-1.0.jar もデプロイします。次に ClickServlet を継承して Guice によるインジェクションを行うサーブレットを作成します。↓こんな感じです。 package example;
gem を新しくしたら、この間紹介した方法では、警告が出るようになってしまいました。相変わらずのドキュメント不足(あるのかもしれないが見つけにくい)で多少戸惑いましたが、次のようにすれば OK でした。 require 'rubygems' gem 'sqlite3-ruby' require 'sqlite3'
長年メンテナンスしてきた幾多の掲示板 CGI がスパムに犯されているのを目の当たりにしているので、最近は CAPTHCA に大注目の私なのですが、今日は、Ruby on Rails による Web アプリケーションに割と簡単に CAPTCHA を導入する方法を紹介します。 使うのは Ruby/CAPTCHA というライブラリです。個人的には、それほど洗練されたライブラリだとは思っていないのですが、「とりあえず CAPTCHA をつけたい」と言った場合には必要十分です。 まず、Ruby/GD をインストールします。どこぞの Blog で Ruby/CAPTHCA は RMagick に依存すると書いてありましたが、Ruby/GD が正解です。インストールの仕方は以下を参照してください。「もう Ruby/GD は入ってるぜ!」という方は、freetype をサポートするビルドオプションをつけて
私は試してみて、そして身体で覚えるタイプなので、たまに理解できないものが現れる。今悩んでいるのは Teeda Extension での開発において action はいるのか。 私は page に全部書いているので使ってない。 service はどういうときに使うのか。何に使うのか。 以前、id:higayasuo さんの blog 記事で action が呼び出すと書いてあったような……。 logic はどういうときに使うのか。 結局私は action と service と logic が上手くすみわけできていない。 helper はどういうときに使うのか。何に使うのか。 Rails だと、HTML タグを生成する関数が helper だったような……。しかし、Teeda ではそのような振る舞いが必要なことは皆無だし……。 何かいい資料はないものだろうかと彷徨う今日この頃です。
故あって CAPTCHA に挑戦してみました。CAPTCHA とは何かということははてなキーワードに任せるとして、私は JCAPTCHA を使って実装してみました。しかし Google 等で検索してみて見つかるサンプルで生成される画像は人間すら読むのが困難なものばかり。それどころか Windows でなければ動かなかったり、とても実用に耐えません。 そこで JCAPTHCA の少ない情報をなんとかほじくり返して見ると、どうやら DI と相性がよいとのこと。そして、カスタマイズするのに Spring がどうたらこうたらというくだりを発見したのですが、無駄に Spring に対抗心を燃やしている Seasar ファンの私としては、Seasar でやったるわい! と奮起したわけであります。 ということで、題して S2Captcha ができました(以降のアーカイブにはソースも含まれていますので参考
次のページ
このページを最初にブックマークしてみませんか?
『イトウ アスカ blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く