タグ

ブックマーク / gihyo.jp (12)

  • 2011年の技術系Advent Calendarを電子出版で提供しませんか? | Gihyo Digital Publishing … 技術評論社の電子書籍

    技術評論社の電子出版サービス「Gihyo Digital Publishing」では,2011年の技術系Advent Calendar(終了後のもの)を,無料で電子出版コンテンツとして制作し,配信サポートをいたします。 ご自身あるいは団体で公開しているAdvent Calendarコンテンツについて,電子出版コンテンツでの発行をご希望される方は,以下宛先までご連絡ください。 応募は締め切りました。 応募期間:2011年11月28日~2011年12月16日 配信予定:2012年1月中旬 Advent Calendarの終了後に,各ブログ,サイトで公開した記事を取りまとめてWeb/EPUB型の電子書籍の形にしまして,当サイトよりダウンロードできるようにいたします。 なお,1次コンテンツの著作権については著作者に帰属するものとします。 補足情報(2011年11月28日16時15分) 今回配信する

    Seacolor
    Seacolor 2011/11/30
    [
  • 第41回 PHP 5.3.4におけるセキュリティ上重要な仕様変更 | gihyo.jp

    PHP 5.3.4のリリースは2010年12月にリリースされました。このリリースにはセキュリティ上重要な変更が追加されています。 Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus) パスに“⁠foo\0bar.txt⁠”などのようにNULLが含まれる場合は無効として処理される、とPHP 5.3.4のリリースノートには記載されています。PHP開発者の間でもあまり大きなニュースとして取り上げられていないので、この仕様変更をご存知でない方も多いと思います。2011年4月現在でもこの仕様変更はマニュアルには記載されていません。しかし、この修正はセキュリティ上非常に重要な意味を持っているので解説します。 仕様変更の必要性 PHP体はC言語で記述されているため、ファイルを開く場合、最終的にはC言

    第41回 PHP 5.3.4におけるセキュリティ上重要な仕様変更 | gihyo.jp
  • 酷い英語をもっとお願いします | gihyo.jp

    メーリングリストでもっとたくさん酷い英語を見かけたい。ネイティブじゃない人が英語が上手くなくてと謝る場面がもっと減ってくれたらとも思う。母語ではない第二、第三、あるいは第四の言語を、たとえ熟達していない状態でも、とにかく使ってコミュケーションを図ろうとするのは全く恥じるようなことなんかじゃない。もし、外国語だというのを理由に不安や気後れを感じて重要な貢献を果たさなかったり、FLOSSツールへ貢献する方法やその使い方について質問を控えたりしたのなら、そういうことが恥になるんだ。 訳注 FLOSSは Free/Libre and Open Source Software の略。フリーソフトウェアとオープンソースソフトウェアとをまとめた言葉 オープンソースの美点の一つは多国籍ということ。それも“⁠るつぼ⁠”と見なしうる物事のうち最も真に“⁠るつぼ⁠”らしい多国籍なんだ。数百万もの人たちが英語で運

    酷い英語をもっとお願いします | gihyo.jp
  • 第1回 WebSocket登場までの歴史 | gihyo.jp

    はじめに 初めまして。NTTアドバンステクノロジの金城と申します。幸運にも記事を執筆させていただけることになりました。WebSocketという新しいウェブの規格についての連載を、全4回の予定でお届けします。 用語統一について WebSocketは「WebSocket」「⁠WebSockets⁠」⁠、単語を切り離した「Web Socket」等、表記に揺れがあります。2009年12月22日のワーキングドラフトのタイトルは「The Web Sockets API」となっていますが、2010年4月26日のエディターズドラフトでは「The WebSocket API」となっています。この連載では、最新の仕様書に則り、用語を「WebSocket」で統一します。 HTML5とWebSocketの関係 WebSocketは、もともとHTML5の一機能として仕様の策定が進められていました。しかし、Web S

    第1回 WebSocket登場までの歴史 | gihyo.jp
  • 第10回 動的な索引構築 | gihyo.jp

    はじめに 今回からは、近年の話題や少し発展した話題について触れていく予定です。 第7回では、転置索引の静的な構築方法について触れました。今回は、索引に対して文書のインクリメンタルに追加していく方法について触れていきます。 動的な索引構築の必要性 第7回の復習になりますが、索引の構築方法には"静的"な方法と"動的"な方法が存在します。英語ではそれぞれ、Offline Index Construction、Online Index Constructionと呼ばれています[1]⁠。 文書が頻繁に追加される場合や索引が大規模な場合、文書の追加の度に索引を作り直すことは非常に高コストとなり現実的ではありません。このような場合は、動的な構築方法により索引をインクリメンタルに更新していくことで対応することができます。情報が絶えず追加されている近年のWeb上では、とても重要な構築方法となります。 メモリ

    第10回 動的な索引構築 | gihyo.jp
  • 米Yahoo!、社内で使われているWebプロキシキャッシュ「Traffic Server」をオープンソース化 | gihyo.jp

    濃縮還元オレンジニュース 米Yahoo!、社内で使われているWebプロキシキャッシュ「Traffic Server」をオープンソース化 2009年11月4日、米Yahoo!はWebプロキシキャッシュ「Traffic Server」をオープンソースとして公開しました。プロキシキャッシュとは、よくアクセスされるコンテンツをキャッシュして高負荷なHTTPトラフィックを効率良くさばくための技術です。ほかに有名なものでは「Squid」があります。 Traffic ServerはC++で書かれており、コード量は数十万行にも及びます。またマルチスレッドで動作し、一般的なクアッドコアマシンで秒間リクエスト数が3万を超えるなど、非常に高速に動作します。実績も申し分 なく、米Yahoo!のトップページやメール、スポーツ、ニュースなど多くのサービスで使われています。 元をたどると、2002年に米Yahoo!によ

    米Yahoo!、社内で使われているWebプロキシキャッシュ「Traffic Server」をオープンソース化 | gihyo.jp
  • 第5回 不正なバイト列の埋め込み | gihyo.jp

    今回は、「⁠不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて (1) 処理A = 文字列中に特定の文字(あるいは文字列)が含まれていないか検査 (2) 処理B = 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil

    第5回 不正なバイト列の埋め込み | gihyo.jp
  • 第1回 UTF-7によるクロスサイトスクリプティング攻撃[前編] | gihyo.jp

    みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「⁠危険な文字列の検出」「⁠安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか(このルールを符号化方式あるいは文字エンコーディングと言います)に注意しなければならないこともあるでしょう。攻撃者は巧みに文字

    第1回 UTF-7によるクロスサイトスクリプティング攻撃[前編] | gihyo.jp
  • 第1回 Wassr(ワッサー)ってどんなサービス? | gihyo.jp

    こんにちは。株式会社モバイルファクトリーの木村と申します。 これから、数回にわけて弊社で6月6日にオープンしましたWassr(ワッサー)がどのように開発が進められていったかを、開発者(含むデザイナー)の視点から紹介していきたいと思っています。 第1回目の今回は、Wassr(ワッサー)の特徴を簡単に紹介できればとおりますので、より技術的な話は次回以降をお待ちください。 Wassr(ワッサー)ってどんなサービス? Wassr(ワッサー)は、いわゆるTwitterライクな、今何をしているのかを共有する、シンプルなサービスです。 PC、携帯電話からの更新はもちろんですが、インスタントメッセンジャー、さらには、最近なにかと話題のSecondLifeからの更新も公式にサポートしており、いつでもどこでも家族、友達とリアルタイムにコミュニケーションをとれることを目的としたサービスです。 SecondLif

    第1回 Wassr(ワッサー)ってどんなサービス? | gihyo.jp
  • 第2回 知っておきたいスケールアウトの基礎知識 その1 | gihyo.jp

    サービスを初めてから高負荷になるまで さて、今回からは具体的に、個人でサービスを初めてからシステムを増強していくまでの課程を説明していきたいと思います。 まずサービスを始める際は、手っ取り早さやコストの問題などから、複数のユーザと共有のレンタルサーバから始めるケースが多いですが、ある程度の人気が出てくるとアクセスに耐えきれなくなり専用サーバを借りるというパターンになると思います。 ここまではわかりやすくシステムを増強することができるのですが、専用サーバで耐えきれなくなってきた際はそれ以降はどのようにすればよいのでしょうか? その負荷はホンモノか? まず、サーバの負荷が高いといっても現象はさまざまです。負荷が高いといった現象は具体的に発見されるのは、「⁠ユーザから見たレスポンス」から発見されることが多いはずです。 ここで単純に「サーバを増強しなければ!」と判断はせずに、何が原因でパフォーマン

    第2回 知っておきたいスケールアウトの基礎知識 その1 | gihyo.jp
  • 第1回 memcachedの基本 | gihyo.jp

    株式会社ミクシィ 開発部 システム運用グループの長野です。普段はミクシィのアプリケーション運用を担当しております。今回から数回にわたり、最近Webアプリケーションのスケーラビリティの分野で話題になっているmemcachedについて、弊社開発部 研究開発グループの前坂とともに、使い方や内部構造、運用について解説させて頂きます。 memcachedとは memcachedは、LiveJournalを運営していたDanga Interactive社で、Brad Fitzpatrick氏が中心となって開発されたソフトウェアです。現在ではmixiやはてな、Facebook、Vox、LiveJournalなど、さまざまなサービスでWebアプリケーションのスケーラビリティを向上させる重要な要素になっています。 多くのWebアプリケーションは、RDBMSにデータを格納し、アプリケーションサーバでそのデータ

    第1回 memcachedの基本 | gihyo.jp
  • #5 (株)ライブドア 池邉智洋/谷口公一/ma.la(前編) 「そろそろライブドア事件について一言いっておくか」の「(中略)」にあったこと|gihyo.jp

    小飼弾のアルファギークに逢いたい♥ #5(⁠株⁠)ライブドア 池邉智洋/谷口公一/ma.la(前編) 「そろそろライブドア事件について一言いっておくか」の「(中略)」にあったこと 今回、弾さんが逢いに行ったのは、(⁠株)ライブドアでRSSリーダー「livedoor Reader⁠」⁠、ソーシャルネットワーキングサービス(SNS)「⁠livedoor フレパ」をはじめさまざまなコンテンツを持つlivedoorのポータルを開発している、池邉智洋さん、谷口公一さん、ma.laさん。弾さんがライブドアの前身、オン・ザ・エッヂ時代にCTOを務めた古巣は、すでに面影もなく新しい時代を築いているのかそれとも…。 編集部注) 対談は2007年1月に行われたものです。 撮影:武田康宏 開発体制 弾:まずは自己紹介から。 池邉(以下、池⁠)⁠:ポータルを展開しているメディア事業部に、エンジニア

    #5 (株)ライブドア 池邉智洋/谷口公一/ma.la(前編) 「そろそろライブドア事件について一言いっておくか」の「(中略)」にあったこと|gihyo.jp
  • 1