Home > コンピュータ関連 > プログラミング Archive

プログラミング Archive

「予告.in」に不正コード埋め込み

  • Posted by:
  • 2008年8月 4日 23:21

「2時間で作った」が売りだったんですが、多少時間が掛かってもテストしないと...
と思ったニュース。

サイトの趣旨は素晴らしいと思っていただけに、驚きを隠せません。

「予告.in」に不正コード埋め込み 閲覧すると2chに犯行予告投稿

 犯行予告収集サイト「予告.in」に8月3日、不正なコードが埋め込まれ、アクセスと同時に「警視庁爆破する」という犯行予告文を「2ちゃんねる」に強制的に投稿させる問題が起きた。約1時間半後に修正されたが、運営者の矢野さとるさんは「利用者に迷惑をかけて申し訳ない」と謝罪している。

 問題が発生したのは、3日の午前2時18分から3時55分。PCで予告inにアクセスすると、2ちゃんねるのVIP板に、タイトル「警視庁爆破する」、本文「嘘です」、名前欄にアクセス元リモートホストを書いたスレッドを、強制的に投稿させる状態になっていた。

 クロスサイトスクリプティング(XSS)の脆弱性をつき、予告投稿欄に不正なコードが埋め込まれていたことが原因。投稿欄のURL部分にエスケープ処理(不正な文字列を無効化する処理)を行っていなかったため、悪意あるコードを投稿欄のURL部分に埋め込んだ場合、コードを実行させる危険性があったという。

 矢野さんはユーザーからの連絡で状況を確認。不正コードを排除し、不正コードを送信・表示できないような対策を講じた。犯行予告を投稿後、すぐに反映する形式から、いったん内容を確認してから反映させる方式に一時的に変更した。

 警視庁には、これらの投稿が不正なコードによって行われ、投稿者本人の意志ではないことを連絡。必要があれば被害届を出したいという意思を伝えた。警視庁は事実関係を把握し、調査を行っているという。

 矢野さんは「利用者の皆様にご迷惑をおかけして大変申し訳ございませんでした」と謝罪。プログラムの整備やセキュリティー対策強化を行っていくとしている。


こちらでは、厳しい意見も。

予告inセキュリティ脆弱性を狙ったコード!? 「予告in開発者は素人」

犯行予告サイト『予告in』にセキュリティ脆弱性があるとしてクロスサイトスクリプティング (Cross Site Scripting) を利用したコードが『予告in』に貼られるという騒動が起きた。
8月2日の深夜の出来事で『Internet Exploler』(その他互換ブラウザ)でアクセスすると不正なコードが送信されるというもの。

そのコードを踏むと『2ちゃんねるニュース速報VIP』に「警視庁○○する」犯行予告として書き込まれるのだ。
それだけではなく名前欄は“fusianasan”(IP、もしくはリモートホストが表示される)、本文は「嘘です」というもの。

クロスサイトスクリプティングとはいわゆるサイトを横断したコードである。
今回は『予告in』にあるスクリプトを踏むと『2ちゃんねる』に投稿するように仕組まれたようだが、もちろん『2ちゃんねる』以外にも投稿させようと思えば出来る。

『予告in』運営側は「一時的な対応策として犯行予告の投稿時、すぐに反映するリアルタイム形式から、一旦内容を確認してから反映させる確認方式に一時的に変更」としている。

現在この不正コードは対策されているという。

今回の件について某IT企業に勤めるエンジニア(匿名)に聞いてみると、
「これは初歩中の初歩。XSSコード書いた方も10分も掛かってないよ。それを事前に対策してなかった予告inにはもっとビックリだけど、、、素人なの?」
と語る。

『予告in』側は「コードを踏んで『警視庁○○する』と投稿した人は本人の意志ではない、すべての要因はコードを開発&埋め込んだ犯人に原因がある事」としている。

このようなスクリプトのおかげで一時的に“犯行予告を予告”するサイトになってしまった『予告in』だが、今後は今まで通り“収集・通報サイト”として頑張って欲しい。

クロスサイトスクリプティングというのは、セキュアプログラミングの基本中の基本。
WEB系エンジニアなら、知らないってことはないと思うんですけどね...

『予告in』に行ってみると、「犯行予告通報フォームのURL部分のエスケープ処理(不正な文字列を無効化する処理)を行っていませんでした。」とありますので、コードの不具合というより、対策コードそのものが実装されていなかったということのようです。
不正コードを投稿した人も当然悪いのですが、このレベルになると開発者にも問題があるように思います。

プログラムっておいしいんだか、まずいんだか

  • Posted by:
  • 2008年5月 2日 23:22

いろいろと懐かしい気分になる、良エントリです。
完全に乗り遅れたんだが...気にしないこととする。

プログラムっておいしいの? - iGirl

ってゆうスイーツ(笑)が少しでもプログラムを理解するには何をしたらいいのでしょうか。何を読んだらいいのでしょうか。ググればググるほど分からなくなってきました。

「初心者のための・・」系を読んでも、サンプルコードというものを見ても、何のこっちゃ分からずで、perlにしようかPythonにしようかjavaにしようかC++にしようかとか言ってる場合じゃありません。C++とC#は別クチなんすかね?ですよね。ギャー!

どんなふうに始めればいいか分からないしたぶん「私には無理!生まれたときから文系だもん!むしろ文系から生まれたもん!」とか言い訳垂れて諦めるかもしれないんだけど、とりあえず何となく話だけでも分かる風になりたいなーとか思ってー。諦めるまでに達せない自分が歯がゆい><

ギークに「プログラム始めたきっかけって何ですか?」みたいに聞くと(あと記事とか読むと)「自分でゲームを作ったのがはじめかな」って答えが多いようなのだけど、そもそもゲームが自分で作れるとかゆう発想がどこからきたの!と思うスイーツな私。えへ。

私にとってのプログラミングって、何なのかよく分からないんですよね。

小学4年生の時、友人の兄ちゃんが、X1-CSというパソコンを持っており、マイコンBASICマガジンなる雑誌を見ながらプログラムを入力したとかで、すごく自慢されたんですよね。
なんかもう、スネ夫なみに。

もう20年も昔の話なんですが、当時のパソコンはデータをカセットテープに保存していたのですが、日曜朝10時にパソコンサンデーなる番組があって、その最後の方にプログラムを副音声で放送してたんですよ。
その副音声をカセットテープに録音し、パソコンでロードすると、なんとゲームが楽しめる!ってことで、その一部始終を見せ付けられ、相当ショッキングだったことを記憶してます。
あの時代に地上波でプログラムを流してたってのは、今から考えても凄いことでした。

でも、そのとき、羨ましいみたいな感情の前に、「将来はパソコンを使いこなせる人が強い時代が来る」という確信があって、親にパソコンをねだったのでした。

で、中学に入学したときに、パソコンを買ってもらい、早速ポーカーを作ってみたのですが、こいつは結局まともに遊べなかった。
何しろ、同じカードが何枚も配られてしまうので、スペードのAのスリーカード?とか、イカれた状態のまま、カセットテープはどこかに消えていったのでした。


再び、プログラミングに触れたのは、大学時代のこと。

高校時代は化学が得意で、将来は薬学関連に進みたいと思っていたのに受験に失敗し、なんとか第4志望の学校に滑り込んだものの、そこが情報学部。
しかも、情報システム学科なもんで、毎日プログラミング三昧でした。

学校で出される課題もえげつなくて、「掛け算、割り算を使わずに、1/xを求めるプログラムを作りなさい」とか、ノーヒントで出されてました。
そのおかげもあって、ある程度組めるようになったんですが、楽しくてやってた訳じゃないんですよね。

パソコン買ったときも、「パソコンを知らないと将来困る」と思ったからだし、状況に脅迫されてた気がします。
就職したらしたで、バブル崩壊後で会社がえらいことになってるしで、とても楽しんでプログラミングできる状況じゃなかった。

オープンソースやったりしてると、プログラミングが好きなんだと思われがちなんですが、正直全然好きじゃない。
でも、嫌いかというとそうでもない感じ。
なんか良くわかんないまま20年間親友になってしまった、腐れ縁の仲間みたいなもんか。


でも、本当は楽しくてプログラミングしてるっていうのが、最高なんだと思う。
私はもう無理だと思うけど、そういう気持ちを持っている人には、心からエールを贈りたいと思います。



スタートラインに立てないスイーツを助けてくれる本とかありませんか?もしくはこの言葉でググれ!みたいな。

どうやったらスタートラインに立てるんだー!教えてのび太くん!

のび太かあ、敷居低いなあ。

最初に始める言語は、その人の好みなので、いろんな意見が出てきて混乱しちゃうんだけど、どれを選んでもある程度やってみると、他の言語にもすぐ移行できちゃうものなので、いっそのことサイコロとかで決めてみるといいかもしれない。
きっと、神様がベストな選択をしてくれる気がする。

でも、COBOLだけは、他の言語に応用がきかないので除外すべし。

ちなみに、私は未経験者の人にプログラムを教えるという仕事をしていたことがあるんですが、言語は好きなものを選ばせました。
「決められないなら、サイコロで決めろ」とか、本当に言っていて、実際にサイコロで決めた人もいました。



最速の人は「例えばホームページつくりたいとかゆうふうに、何かを作りたいと思ってスタートして、カウンターをつけるにはどうすればいいとか新しいコレをつけるにはどうしたらいいかとか勉強するうちにできてくるよ」みたいなことを黒糖梅酒のみながら言ってた。たしか3杯目くらいのとき。

ホームページは良いですね。

私も、プログラミングは好きではないけど、WEBページを作るのは好きですね。
仕事以外で、こういうことを始めたいという人には、WEB作成だとか、Flash作成だとかを強く薦めたいです。
いろんなところで役に立つので。

SEOの世界も熱くて楽しそうなんで、徐々にこっちに移行しつつあったり。

数学的なセンス

  • Posted by:
  • 2008年4月28日 18:31

CodeZineに興味深い記事がありました。

エンジニアは数字・計算力の高い人が多い?:CodeZine

 Tech総研の報告によれば、エンジニアは他の一般職と比較して数字に強い傾向にあるようだ。これは「エンジニア150人VS一般職150人 数字・計算力チェック」というテーマで行われた調査結果によるもの。無作為に抽出したエンジニア150人と非エンジニア150人に対して、以下の3つのポイントについてのアンケートを行った。

  • 「数字&計算」が得意or不得手?
  • あなたの仕事において「数字&計算力」はどれだけ必要とされる?
  • エンジニアはほかの職種に比べて「数字&計算力」が高い人が多くいると思う?

 アンケートの結果では、エンジニアはほかの一般職に比べて数字・計算力が高い人が多いと判明した。報告ではエンジニアは職業柄、論理的思考を求められる機会が多いため、結果として数字に強い人も多くなるのではないかと分析している。

 また、これを受けて「数字・計算力が強いエンジニアの方が活躍のチャンスは多い。苦手な人ほどキャリアを見据えてこれらの力を高める必要がありそう」と提言している。

だそうです。

私は理科系なので、このアンケートでは「得意」に入れる人なんですが、計算力の捉えかたがちょっと曖昧な気がします。
計算速度であったり、公式を覚えるというのは、実はそれほど重要では無いと思います。
実際、数学に馴染みの薄い文系エンジニアだって、十分に活躍していますから。

私は、数字で遊べるかどうかというのを大事にしています。
例えば、25×24なんて、いちいち筆算しなくてもいいし、頭の中で暗算しなくてもいい。
25×20+25×4=500+100=600 と柔軟に計算できる方が大事。
消費税なんかも、20円ごとに1円、100円ごとに5円なんて計算した方が簡単だし、面白いでしょ。

数学的なもので、エンジニアにとって大事なものを挙げるとすれば、「集合に対する理解」ではないかと思います。
クラス構造を考えるにしても、SQLを書くにしても、その基本は集合の捉えかたですから、理解できないと厳しいでしょう。

下手なプログラムを見ると、SQLは正規化されていないは、オブジェクトが全部配列に入っているはで、集合的な捉えかたが全くできていない場合が多い。

アンドロイド

ちょっと前のエントリですが、taraさんとこの
[Resident of Virtual World]最近考えていること
を見て。


人工知能とかは今も盛んに研究されていると思うが、自分のためのソフトとして補助的な知能が構築できたらすごくいいなという単純な発想だ。そもそも人はどんな風にとらえて展開していくのかなぁという素朴な疑問から脳について、もう少し知りたいと思ったんだ。

でも、やはり人が機械と違うのは、認識力と連想+想像ができることなんだろうな・・・これが今のコンピュータにはできないことなんだろう。それ、まったく同じにできなくてもいいから何か近づけ無いかなってここ数日考えていることだったりする。

実は、私も似たようなことを考えていたりします。
大学時代にファジイ理論を使ったプログラムを作ったことがあって、そのときに「アンドロイド作りてえなあ」と思って(痛い)から、ずっと考え続けてきたことでもあります。
最近、やたらと「オンメモリ・データベース」にこだわっていたのも、実はこれが理由なのです。

ということで、今の段階で私が考えていることをまとめてみます。


自律学習

機械学習を使った人工知能も面白いのですが、人の作ったアルゴリズム上では、どこまで進化しても感情を持つことはできません。
よく漫画などで、機械が感情を持ち始めるというストーリーがあるのだが、感情を考慮していなかったシステムで感情が自然発生することは不可能です。
機械が自律的に学習を行い、勝手に成長していくようにするためには、得られた情報の良し悪しを判断する機構が必要であり、それを構成するのが、感情・本能・性格の3つと私は考えています。


本能

娘が生まれてから気付いたことなのですが、人は生まれたときにゼロの知識で生まれてくるのではありません。
実はいろいろなことを知っている状態で生まれてきています。
例えば、状況によって泣き方を変えたり、母親という存在を知っていたり、母乳を飲む方法を知っていたり。
これは、誰かが教えなくても絶対に知っていることであって、いわゆる本能というものです。


性格

性格は度が過ぎると、本能と異なる行動を取る場合があります。
例えば、人間は危険なときに本能でストレスを感じるようになっていますが、危ないことをすることが好きな人はストレスを超えた興奮を覚えるなど。
生きていく上で必須でない事柄に関しては、本能より性格が及ぼす影響の比重が高いように思います。


感情

楽しいことはどんどんやりたい、嫌なことはしたくないといった行動の指標。
自律的に学習させるためには、知識を得ることが楽しいと感じるようにしなければならないと思う。
が、この感情がとても難しい。
例えば、人の笑い顔はその人に対して一種類しか無い訳ではありません。楽しさの度合いによって、顔面のくしゃくしゃ具合が違うだろうし、他のリアクションが加わったり、涙が出てくるかもしれない。
アンドロイドを作るためには、微妙な感情表現がなにより重要だと思う。


本能の実装

危険から逃れる行動が取れるような初期データをあらかじめ設定しておく。
変更不可能。


性格

これも初期設定なのだが、ランダムデータとした方が、面白みがあるし、教育次第では想像以上の天才が生まれるかもしれません。
感情と連動して、徐々に修正される。


感情の実装

人間は、セロトニン、ノルアドレナリン、アドレナリン、ヒスタミン、ドーパミンなどのモノアミン神経伝達物質が分泌されることにより、感情が制御されているらしい。
ということで、インプットされた情報によって、これらの分泌量を示すパラメータ値を変化させる仕組みを作る。
こういう難しい仕組みは、深く考えずに、人間の仕組みをそのまま実装するイメージで作った方が良いのではないだろうか。

また、パラメータ値制御とは別に、笑いを制御するコントローラ、悲しみを制御するコントローラなどの複数のコントローラをマルチスレッドで起動する。
これらのコントローラは、共有メモリにあるパラメータ値を監視し、しきい値を超えると体本体の動きを制御するようになっている。
例えば、笑い泣きを例にすれば、笑いに関する数値に比例して顔がほころび、泣きに関する数値がしきい値を超えることで涙が出るようにすると、笑いと涙にタイムラグが生じるので、より人間らしい感情表現となる。

このモデルは、Blackboardアーキテクチャとほぼ同じである。


記憶

最大の難関がコレだ。
当たり前のことだが、二次元表を使ったリレーショナルデータベースなど論外である。
有向グラフでデータ表現をするのが良いのではないかと思っているのだが、概念のようなデータをどう扱うか、逆向きのリンクをどうするか、などの問題が今のところ解決できないでいる。
また、相当なデータ容量となるので、これをどうバックアップするのか、どう復元するのかも想定しておく必要がありそうだ。


検索

記憶ときたら検索がセットですね。
最大の課題が巨大なデータ容量でしょう。
検索は一瞬で完了し、思い出せなかったら何度かトライしてみるだとか、ひょっとしてコレかな?といった推測ができるようにしないといけない。
常に検索結果が同一というのは、アンドロイドでは全く意味を成さない。
何度も試行錯誤しながら、その中から最適解を決定していくという仕組みが必要である。

実はこれ、私の頭の中では、最適解を決定するアルゴリズム以外は大体できています。
どんなに巨大なデータ容量であっても、瞬時になんらかの答えを返すことができる画期的な方法ですが、具体的な方法はまだ内緒にしておきます。


ということで、弁慶フレームワークの次は、「脳モデルデータベース」プロジェクトになる予定。

高橋メソッド・コンバータ 1.0.1

  • Posted by:
  • 2007年12月16日 01:04

11/7にアップロードした高橋メソッド・コンバータをバージョンアップしました。

設定情報を保存できる機能とか、目次ページの追加とか、いろいろやってみました。
良かったら使ってみてください。

ダウンロードページ

ソフトウェアメトリックス

ソフトウェアメトリックスについて調べていたところ、面白い記事を見つけました。

最適な工期は「投入人月の立方根の2.4倍」、JUASが調査


 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短縮率が)30%以上の短い期間での開発は無謀である」(JUAS)としている。

 調査したプロジェクトのうち、事前の予定通りの工期で開発を終えられたのは70%以上で、工期に関しての失敗はそれほど多くないことが分かる。遅延する理由で最も多いのは「要件仕様の決定遅れ」。3位は「要件分析作業が不十分」で、ユーザー企業が行うべき上位工程での不具合が工期全体に影響を与えているようだ。

 工数(人月)の設定ではシステムの画面数やファイル数も使える。調査から導き出されたのは「必要工数=0.1×ファイル数+1.3×画面数+0.3×バッチ数」という数式。その中でも工数と最も高い相関を示すのは画面数で、「必要工数=画面数×1.55」との数式も示された。

 完成したシステムの品質の計算では、ユーザーが発見した欠陥数をプロジェクトの全体工数、または発注金額で除した欠陥率を使用。調査したプロジェクトの欠陥率は、平均値で0.81個、中央値で0.33個との値になった。1人月を100万円と計算すると、欠陥が5人月(500万円)当たり1件に収まっているプロジェクトは全体の約40%。JUSAは「5人月(500万円)当たり1件以下」を目標にすべきと提言している。

要約すると、

・標準開発工期 = 投入人月^(1/3) × 2.4
・必要工数 = 0.1 × ファイル数 + 1.3 × 画面数 + 0.3 × バッチ数
・必要工数 = 画面数 × 1.55

ちなみに、立方根を計算するときは、1/3乗すると求めることができます。

FizzBuzz問題

使えないプログラマーさんのところで、面白い記事を見つけました。

使えないプログラマー: FizzBuzz問題

元ネタはこちら
どうしてプログラマに・・・プログラムが書けないのか?

以下、引用


かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。

それで、そういった類の開発者を見分けるための質問を作り始め、私が「Fizz-Buzz問題」と呼んでいる問題のクラスを考え出した。これはイギリスの学校の子供たちがよくやっている遊び(というかやらされている遊び)にちなんで名付けた。Fizz-Buzz問題の例はこんな感じだ。

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。自称上級プログラマが答えを書くのに10-15分もかかっているのを見たこともある。

すぐ思いついたので、C#で書いてみた。


using System;
using System.Collections.Generic;
using System.Text;

namespace FizzBuzz
{
class Program
{
static void Main(string[] args)
{
// 3の倍数のときのメッセージ
const string MultipleOfThree = "Fizz";

// 5の倍数のときのメッセージ
const string MultipleOfFive = "Buzz";

StringBuilder message = new StringBuilder();
for (int i = 1; i <= 100; i++)
{
if (i % 3 == 0)
{
message.Append(MultipleOfThree);
}
if (i % 5 == 0)
{
message.Append(MultipleOfFive);
}
if (i % 3 != 0 && i % 5 != 0)
{
message.Append(i);
}
message.AppendLine("");
}

Console.Write(message.ToString());
}
}
}

改めて見てみると、3と5両方の倍数の場合の表示方法はちょっとまずいのかもしれないと思えてきた。
このケースでは結果的に問題は無いのだが、仕様変更して「HogeMoge」にしろと言われたらロジックが変わってしまうからです。
使えないプログラマーさんのところで書かれているように、「FizzBuzz」と素直に書く(さらに言えば定数にするのがベターかと)のが正解かと思います。

みなさんの作ったコードはいかがでしょうか。

プログラマになる方法

  • Posted by:
  • 2007年8月23日 23:38

プログラマになる方法

思わず、吹き出してしまいました...

【オープンソース】クラス図、階層図

クラス図
階層図

現在作成中のオープンソース・フレームワークの設計図をちょっと公開。
特に階層図は重要ですよね。アプリは思想が大事です。

オープンソースがなぜビジネスになるのか

  • Posted by:
  • 2006年12月23日 23:03

オープンソースがなぜビジネスになるのか
オープンソースがなぜビジネスになるのか

2週間前に図書館で借りた本なのですが、明日返却日なので慌てて読みました(汗)
内容はタイトルとは微妙に違う気がしますが、ためになる部分も多少ありました。
特にIBMのオープンソースへの方向転換の話はある程度知ってはいたものの、その背景までは知ることができたのは価値があったと思う。

現在構想中の会社像がまだ完全に定まっていないこともあって、オープンソースをどうやって取り入れていくかという知識がもっとほしいんですよね。
今までの経験上、オープンソースに関わったのはJavaで開発した一部だけだったため、まだまだこれからだなあと痛感しました。
それと同時に、まだ見ぬ世界に可能性も感じています。
以前からなんですが、システム開発の世界に大きな流れが来そうな予感があるんですよね。
もしそういう流れに乗り遅れないような体制を作り上げていかないといけないなあ。

ニコニコカレンダー

  • Posted by:
  • 2006年9月20日 07:12

発想が斬新だと思います。
プロジェクト管理と言うと、ガントチャートとかそういうものを想像しちゃいますけど、もっとメンタルな部分で視覚的に見ていこうというもののようです。
システム開発はとにかく気力を削っていく仕事のため燃え尽きる人も多いので、結構使えると思います。

ニコニコカレンダー
[IT-pro]ニコニコ・カレンダでチームの士気を見える化する

改行を変換する設定時のpreタグの扱い

  • Posted by:
  • 2006年9月17日 07:11

MovableTypeユーザーの悩みの種は3.3でもダメっぽいです。
私はというと、もう諦めました。
自動改行をオフにすればなんとかあるわけですが、pre以外の行が面倒になるのでいやん。
読みにくいかもしれませんが我慢してください。m(_ _)m

[Matatabi.ws]改行を変換する設定時のpreタグの扱い

PREでの改行

  • Posted by:
  • 2006年9月16日 07:10

preタグをソースコード表示用に使うとスクロールバーが出てしまうので調べてみました。
cssで解決するんですね...φ(.. )メモメモっと。

[Bowz::Weblog]preでも改行を生かしたまま折り返す
[ip-network.org]css/pre>グカスタマイズ

Index of all entries

Home > コンピュータ関連 > プログラミング Archive

Search
Feeds
Tag Cloud
Recommend

SQLパズル 第2版 プログラミングが変わる書き方/考え方
SQLパズル 第2版 プログラミングが変わる書き方/考え方

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ITアーキテクト vol.1
ITアーキテクト vol.1

オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向における再利用のためのデザインパターン

アンチパターン―ソフトウェア危篤患者の救出
アンチパターン―ソフトウェア危篤患者の救出

おら!オラ!オラクル
おら!オラ!オラクル

プログラマの数学
プログラマの数学

スタイルシート スタンダード・デザインガイド―SEO/ユーザビリティ/アクセシビリティを考慮した実践的HTML&CSSデザイン術
スタイルシート スタンダード・デザインガイド―SEO/ユーザビリティ/アクセシビリティを考慮した実践的HTML&CSSデザイン術

セオリー・オブ・スタイルシート
セオリー・オブ・スタイルシート

テクニカルセキュリティ技術
テクニカルセキュリティ技術

まってる。
まってる。

Return to page top