「プレースホルダ」を含む日記 RSS

はてなキーワード: プレースホルダとは

2019-02-01

anond:20190201215349

価格が高いから興味を持っている人が多い」なんてことは一言も言っていない上に、欲しい人間がその価格を出しても欲しいというのだから、それを欲しくない人間が適正だとかいうのはおかしいのですよね。仮に、今欲しがっている人が高すぎると感じるような金額になったらそれはそれで高いですし。そもそも物の価値もその金額に対する評価相対的ものしか無く、需要供給曲線の均衡点に乗っかっているのであれば、それは適正な価格なんですよ。

アイドルコンサートチケットに関して話題限定してしまうと確かに全体を見るには局所的すぎるが、その例はあくまで一例でありアイドルコンサートプレースホルダーとして見ればどの物に対しても同じ議論が行えると思うのですが。

2016-05-25

http://anond.hatelabo.jp/20160525101430

反撃方法

1. 「おちんちんびろーん」とかなんでもいいので適当プレースホルダーを増田投稿する。

2. ターゲットブログウォッチし、伸びそうな記事が出るまで待つ。

3. 伸びそうな記事に5ブクマくらいついた時点で内容をまるまるコピペし、1.を編集して差し替える。

4. コピペを載せた1.の増田ブクマして互助会で伸ばす。

5. オリジナルの方を増田パクリとして糾弾する。

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2010-05-27

ウェブサイトでよく使われるデザインや機能の呼称のまとめ

「あちこちでよく見かける『あの機能』を実装するためにCSSのテクニックとかJSライブラリとか探したいんだけど、どういうキーワードで探したらいいのかわからない…」という人向け。

注意

※この呼称が正しいとは限りません

※この呼称に統一されているわけではありません

ブロック要素等の角を丸め

角丸

複数の画像を一枚にまとめてCSSbackground-positionで制御する(メニューのマウスオーバーなどでよく使われる)

CSSスプライト

フォームにうっすらと説明文が表示される & フォームにフォーカスすると消える

プレースホルダ

フォームに入力された文字にあわせて入力候補を表示する

サジェスト

ページ内リンク等をクリックした際に滑らかにスクロールさせる

スムーズスクロール

他のメニューを押しのけるようなアニメとともにサブメニューが表示される & 開いているメニューは常にひとつだけ

アコーディオンメニュー

メニューの横にある+マークなどをクリックするとその下にサブメニューが表示される & 複数のメニューを開くことができる

→ ツリーメニュー

水平メニューから垂れ下がるようにサブメニューが表示される

→ プルダウンメニュー

横一列に並んだアイテムスクロールバーでスライド表示 & アイテムが床面に反射したようなエフェクト

カバーフロー

水滴のように光沢のあるデザインボタン

→ アクアボタン

画像サムネイルクリックするとオリジナルサイズの画像が画面中央に表示される

ライトボックス

警告ウィンドウ等が画面中央に表示される & その他の操作を受け付けない(※指摘を受けて追記しました)

→ モーダルボックス

説明文等が書かれた小さな吹き出しをマウスカーソルの隣に表示させる

ツールチップ

タグアルファベット順に並べる & その使用頻度等に応じてフォントサイズや色を変えて表示する

タグクラウド

ひとつの記事を分割してページ番号を振る

ページャー、ページネーション

フッター部分が常に最下部に固定されている

→ フッタースティック

2008-02-27

Joel On Software私訳

訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。

注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。

なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)

Tuesday, February 19, 2008

先週、MicrosoftOfficeバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。

それぞれのExcelワークブックは1つのcompound fileに収められている

つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。

もしあなたが週末を、Wordドキュメントブログインポートしたり、あなたの個人的な財務データからExcelフォーマットスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通プログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:

この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。

理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。

これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:

これはライブラリを使うことを想定して設計されている。もしあなたがバイナリインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリサポート存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。

オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートWord文書に埋め込んだりできる。完璧Wordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。

それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。

それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧Wordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。

それはアプリケーション歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordExcelには費やされてきたのであり、これらのアプリケーション完璧クローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションサポートする全てのフィーチャーの簡潔なサマリーなのだ。

手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。

Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンMac版であり、それは単に簡単だったという理由でOSエポックを使っていて、しかしWindows版のExcel1-2-3ファイルインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。

1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルWindowsMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。

実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙ディティール発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙ビットを全て完全に記述することはできない。

そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。

唯一導き得る結論はこれだ。

MicrosoftMicrosoftOfficeファイルフォーマットリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。

オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。

ヘビーな仕事Officeにやらせよう。WordExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。

  1. Webベースアプリケーションがあって、それが既存のWordファイルPDFフォーマットに出力するようにする必要がある場合、それを実装するにはこうする: ファイルを読み込んでからWord 2007のビルトインのPDFエクスポーターを使ってそれをPDFとして保存する、数行のWord VBAコードだ。あなたはこのコードIISで動作しているASPASP.NETコードから直接呼び出す。これでうまくいく。最初にWordを立ち上げるときは数秒かかる。2回目はCOMサブシステムによりWordはまたあなたがそれを必要としたときのためにメモリ中にキープされている。それは通常のWebベースアプリケーションにとっては十分に速い。
  2. 上と同じ。ただしあなたのWebホスティング環境Linuxだった場合。フルライセンスWordインストールされたWindows 2003サーバを買う。そしてその仕事をする小さなWebサービスを構築する。C#ASP.NETでの半日の作業だ。
  3. 上と同じ、ただしあなたがよりスケールさせたいと望む場合。ステップ2で構築した全部のボックスの前にロードバランサーを置きなさい。コードは必要ない。

この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:

これらのケースの全てにおいて、Officeオブジェクトインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザ入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。

書き込むファイルにはもっとシンプルフォーマットを使いなさい。単にOfficeドキュメントプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマットWordExcelでも問題なく開くことができるようなフォーマット存在する。

いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん