TRANS [hatena] - Hkon Wium Lie氏「CSSの10年とこれからの大きな動き」（日本語訳）
タイトルは誇張ではありません。僕も読み始めたときは何のことなのか分かりませんでしたが、途中で出てくるコードを読んで、やっと分かりました。「本当に、これは今のWebデザインやCSSを変えるかもしれない」と。元記事は、A List Apart: Articles: CSS @ Ten: The Next Big Thingより。著者はCSSそのものの草案者であり、今はOperaのCTOを務めるHåkon Wium Lie氏です。 追記 id:iwaimさんのはてブコメントに対する返答を文末に書きました。（2007年9月11日19時ごろ） CSS @ Ten: The Next Big Thing CSS は去年10年の節目を迎えた。このような節目は、過去に立ち返り、未来の計画を立てるための機会である。CSSは構造から見た目を分離することによって、根本的にWebデザインを変えた。CSSはデザイナ
![TRANS [hatena] - Hkon Wium Lie氏「CSSの10年とこれからの大きな動き」（日本語訳）](https://cdn-ak-scissors.b.st-hatena.com/image/square/6fda62be67b9643fff20af55f2e8c202f42f8b2d/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F2b8bb80cb2cb4b085ca671c9a7f57e090f4ae90e%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fa%252Faratako0%252F20070909%252F20070909015823.png)
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
FrontPage - Web APIまとめサイト
FrontPage † このページはWeb系のAPIを勝手にまとめようとするサイトです。 何か情報などがありましたら教えてくださいね。 API/ぐるなびWebサービス API/じゃらん API/はてな API/カーセンサー・ラボ API API/4travel API/Bloglines API/box.net API/Bulkfeeds API/castella Podcast API API/Google API/HTML2PDF.BIZ API/Last.fm API/MaidcafeAPI API/mooom.jp API/reflexa Web API API/RSSナビ API/SAGOOL API API/Technorati API/Yahoo API/YouTube
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
FrontPage - HackingWiki
ハッキング Wiki † ハッキングの関連のあれこれについてまとめてみようと思っているwikiです。悪いことには使わないでください（たぶん使えないと思いますが）。 内容は少しずつ充実させていきたいと思っていますが、wikiの使い方はあまりわかっていないので事故で消えるかもしれません。 硬いので文体を「ですます」にしようと思います。 誰も編集しないので編集できないように戻しました。編集したい人はyamamoto at bogus.jp宛にメールするか、blogにでも書き込むか、電話でもしてください。。 ↑
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
＠IT：Webアプリケーションに潜むセキュリティホール（1）
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング（XSS）」と呼ばれる脆弱性が有名で、「特集 クロスサイトスクリプティング対策の基本」という記事で詳細に解説した。しかし、Webアプリケーションに潜む脆弱性はXSSだけではなく、XSSよりもはるかに危険性の高いセキュリティーホールが存在する。 本稿では、Webアプリケーシ
適切なエスケープ処理でクロスサイトスクリプティングに備える ― ＠IT
Webアプリケーションのセキュリティホールが注目を浴びたことから、セキュリティを意識した開発の必要性が高まってきている。今後の流れとして、セキュリティ上満たすべき項目が要件定義の段階から組み込まれるケースが増えていくことが予想されるが、実際の開発現場においてはセキュリティホールをふさぐための実装方法が分からないという声も多いのではないだろうか。 そういった開発者の負担を少しでも軽くすることができるように、本連載ではJavaにおけるWebアプリケーション開発時に最もよく利用されているStrutsフレームワークの実装に踏み込んで、セキュリティ上注意すべきポイントを解説していきたい。なお、本連載ではStruts 1.2.8を対象として解説を行っていくが、すでにStrutsを利用したWebアプリケーション開発を行っている開発者をターゲットとしているため、Strutsの使用方法、各機能の詳細な説明な
[戯] target="_blank" を使わないで新しいウィンドウでリンクを開く方法
target="_blank" を使わないで新しいウィンドウでリンクを開く方法 2006-03-14-5: [JavaScript] <a href="foo.html" target="_blank">foo</a> を使えば新しいウィンドウでリンクが開きますが，これは XHTML 1.1 や XHTML Basic では採用されていません． ではどうするかというと，スクリプトを使うわけですが， <a href="javascript:void(0)" onclick="window.open('foo.html');">foo</a> こうすると，一見解決したようですが，JavaScript が off の場合はリンク先に飛べません． しかも，ステータスバーにリンク先が出ないので不安になります．これを <a href="foo.html" onclick="window.open('f
＠IT：Webアプリケーションのユーザーインターフェイス［1］-1
Webアプリケーションのユーザーインターフェイス[1] ユーザーにとっては “ユーザーインターフェイス”こそが製品そのもの ソシオメディア 上野 学 2005/6/2 ■はじめに Webクライアントの技術が進歩し、多様化するに従って、Webベースのシステムにはデスクトップアプリケーションと同等の品質を持つユーザーインターフェイスが必要となってきています。 しかし開発の現場では、ユーザーインターフェイス（特にGUI）デザインについての専門的なスキルを持った技術者が圧倒的に不足しています。その理由は、ソフトウェア製品におけるユーザーインターフェイスの重要性が正当に理解されていないためと、ユーザーインターフェイス・デザインに関する教育機会がほとんどないためです。 利用者の視点に立てば、ユーザーインターフェイスとは製品そのものです。いくら高度に洗練された仕組みがバックエンドにあったとしても、それが
WebプログラマはRailsに乗るべきか？
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部） Ruby on Railsとは？ Ruby on Rails（ルビーオンレイルズ：RoRと略されることもある）は圧倒的な開発効率を誇るWebアプリケーション開発のためのWebフレームワークです。Railsの用意した道のりに沿って開発することで、短時間で高機能なWebアプリケーションを構築することができます。 Javaのサーバサイドアプリケーション開発に慣れた人であれば、MVC（Model-View-Controller）フレームワークであるStrutsとO/RマッピングフレームワークのHibernate、Dependency Injection（DI）フレームワークであるSpringの
The Web KANZAKI -- Japan, music and computer
こんにちは。音楽に関するいくつかのメモや、ウェブ上での情報の共有や活用に関する参考情報があります。 The English only TOC page also available. 音楽の話 ロジャー・ノリントンの話 交響曲に関するいくつかの情報 歌詞／テキストと音楽（レクイエム、ミサ曲、第九、大地の歌、ツァラトゥストラなど） NMLで聴いてメモした曲リスト 古いもの ... show 音楽雑記帖 コントラバスの話 インターネットやコンピュータの話 セマンティック・ウェブ (ジャパンサーチ非公式サポート、グラフ視覚化、画像注釈とIIIF、LD Browser) いくつかの講演スライドそして専門誌/論文誌記事など アクセシビリティおよびごく簡単なHTMLの説明 OWL語彙の実験・提案、その他いろんな試みの記録 古いもの ... show ちょっとしたメモ（主に2003～2008） ハイパー
ブログサービスの設計思想とユーザ側の制約
はてなではサービス全体で共通のログイン cookie を発行し、各種サービスの設定・編集やプライベートモードの閲覧、ログインコメントなどをパスワード入力なしで利用できるよう設計されています。そのため、*.hatena.ne.jp 内で任意の JavaScript が利用可能な場合、悪意あるユーザは他ユーザの cookie を取得してなりすまし、パスワードの入力が必要な退会・個人情報管理・ポイント操作を除く全ての操作を実行できます。 はてなダイアリーで JavaScript の自由な利用が制限されているのは、この危険に対処するためです。各種 SNS でユーザの自由なスクリプト利用が認められない理由も同様です。ログイン情報をユーザが保持していることを前提に設計されたサービスでは、避けられない問題なのです。 こうした事情は一般のユーザには理解されにくい（私も satoshii さんのご教示を受け
脆弱なWebアプリケーションから脱却する5つのコツ
ショッピングサイトのように多くの個人情報を扱うWebサイトを運営しているのであれば、Webアプリケーションの脆弱性について早急に対策を取るべきだ。Webアプリケーションの安全性を高めるために考えられる対策として5つの方法を提案したい。 Webアプリケーションと個人情報 多くの個人情報を扱うWebアプリケーションの1つに、ショッピングサイトがある。ショッピングサイト上には、利用者の名前や住所、電話番号などの個人情報が蓄積されている。それだけではなく、購入履歴やアンケートといった、他人には知られたくないような情報が登録されていることも多い。通常これらの情報は、データベース（DB）で管理されていることがほとんどだと思うが、WebアプリケーションにSQLインジェクションの脆弱性が存在すると、DB内の個人情報を一気に抜き取られてしまう。Webアプリケーションの脆弱性にはさまざまなものがあるが、個人情
情報処理推進機構：セキュリティセンター：脆弱性関連情報取扱い：安全なウェブサイトの作り方
IPAでは、ウェブサイト運営者が、ウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として、『安全なウェブサイトの作り方』を取りまとめ、公開いたしました。 この資料は、昨年（2005年3月4日）にショッピングサイト運営者がウェブサイト上で発生しうる問題に対し、適切な対策ができるようにするための注意事項として発行した『消費者向け電子商取引サイトの運用における注意点』を、より広いウェブサイトの運営者に利用いただくことを目的に、内容の全面改訂を行ったものです。 『安全なウェブサイトの作り方』では、「ウェブアプリケーションのセキュリティ実装」として、IPAが届出を受けたソフトウエア製品およびウェブアプリケーションの脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、脆弱性の原因そのものをなくす根本的な解決策と、攻撃による影響の低減
携帯電話用のサイト構築に関する質問です。コンテンツを作成する際、キャリア別・機種別にファイルを用意しなければならない...との話を聞いたことがあります。…
携帯電話用のサイト構築に関する質問です。コンテンツを作成する際、キャリア別・機種別にファイルを用意しなければならない...との話を聞いたことがあります。キャリアによって使う表現言語や画像フォーマットが異なるためだそうです。 そこで質問です。みんなに見てもらえるコンテンツを作成する場合には、これらの違いを反映したファイルをその数だけ準備しなければならないのでしょうか？ ひな形を用意すれば、自動変換してくれるようなソフトはあるのでしょうか？ サーバ側のソフトとして、機種等を認識すれば自動でファイルを動的に生成するようなモジュールはないのでしょうか？ 全くの未経験者なので、素人質問ですみません。ズバリの回答のみ求めています。ズバリ度が高ければ、50pt以上、お送りいたします。「ここで探せば」などのポインタのみ的な情報は不要です。 以上、よろしくお願いいたします。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ＰＤ
http://c-moon.jp/robots.shtml
IBM リダイレクト - Japan
