タグ

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

  • 第4回 UTF-8の冗長なエンコード | gihyo.jp

    今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1~4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U+0000からU+007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C(\⁠)⁠、0x2F(/)などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン

    第4回 UTF-8の冗長なエンコード | gihyo.jp
  • 連載:オープンソースなシステム自動管理ツール Puppet|gihyo.jp … 技術評論社

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    連載:オープンソースなシステム自動管理ツール Puppet|gihyo.jp … 技術評論社
  • 特集:jquery.jsを読み解く|gihyo.jp … 技術評論社

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    特集:jquery.jsを読み解く|gihyo.jp … 技術評論社
  • モバゲータウンのノウハウ満載! フレームワークMobaSiFを使おう! 記事一覧 | gihyo.jp

    第4回MobaSiF に含まれるケータイ向け処理モジュール 能登信晴,川崎修平 2008-09-12

    モバゲータウンのノウハウ満載! フレームワークMobaSiFを使おう! 記事一覧 | gihyo.jp
  • 第39回 RVM(Ruby Version Manager)による環境構築 | gihyo.jp

    はじめに Rubyの普及にともない、Rubyの生みの親である、まつもとゆきひろ氏がC言語で作成したRubyインタプリタ(CRuby)以外にも、JVMで実行されるJRuby、Objective-Cで実装されMacアプリケーションのプログラミングのできるMacRuby、CRubyベースにメモリ管理に改良を加えているRuby Enterprise Edition等、プログラミング言語Rubyを実行できる環境が増えてきました。またCRubyに関しても、現在最も使われているバージョンである1.8系以外にも、最新の安定版である1.9系も普及期にはいってきました。 今回は、複数のRuby実行環境の管理を簡単にするRVM(Ruby Version Magager)を紹介します。 RVMとは RVMはUNIX系の環境で、複数のRuby処理系をインストール、共存させることができるツールです。 ひとつの環境に対

    第39回 RVM(Ruby Version Manager)による環境構築 | gihyo.jp
  • 2011年のPerl | gihyo.jp

    あけましておめでとうございます。今回は新春特別企画ということで、2010年のPerl界を振り返りつつ、2011年のPerl界がどうなっていくかを、予定と期待を織りまぜながら見ていきましょう。 Perl 5.14 2010年のYAPC::Asiaでジェシー・ヴィンセント(Jesse Vincent)氏が紹介されていたように、Perl 5は現在、2011年4月に予定されているPerl 5.14のリリースに向けて最後の仕上げをしているところです。Perl 5.14は2010年の開発成果をまとめた定期リリースなのでPerlの根幹をゆるがす大きな仕様変更はありませんが、Perl体、コアモジュールともに細かなバグがいくつも修正されているほか、内部的にはさまざまな最適化が行われています。 一例を紹介しますと、Perl 5.14ではkeysやeach、あるいはpushやshiftのような、配列やハッシュ

    2011年のPerl | gihyo.jp
  • 第43回 Rails 3を支える名脇役たち その1 - Arel - | gihyo.jp

    はじめに Ruby on Railsの2年半ぶりのメジャーバージョンアップである3.0の正式リリースがいよいよ間近に迫ってきました。 Rails 3は、アプリケーション・レベルではRails 2.3との互換性をなるべく保ちながらも、メジャーバージョンアップだけあってフレームワーク自体は隅々にまで徹底的なリファクタリングが施されて更なる洗練を遂げています。結果として、Rails 3では融通の効かないフルスタック構造を捨ててすっきりとしたモジュール独立性が実現されているのですが、この際に、Merbとの合併の影響もあってか、いくつかの新たな外部ライブラリに依存する形になっているのも興味深いところです。 そこで稿では、あえてRails 3そのものではなく、このRails 3の大改造の舞台裏を支える裏方さんにスポットライトを当ててみたいと思います。 Arelによってパラダイムが大きく変わったAct

    第43回 Rails 3を支える名脇役たち その1 - Arel - | gihyo.jp
  • 第21回 Railsアプリの受け入れテストをCucumberで書こう | gihyo.jp

    はじめに Cucumberとは受け入れテストのためのテスティングフレームワークです。CucumberはRuby on Railsに依存しているライブラリではないため、例えば同じRuby制のフレームワークであるSinatraはもちろん、PHPなどで書かれたアプリケーションでも使用することができます。 Sinatraやフレームワークを使用していない素のRubyスクリプトなどをベースにCucumberの解説をすることも可能ですが、今回は仕事で使っている人が多く、また筆者自身もRailsを使って開発をしていることもあって、Railsをベースに解説させていただきます。 なぜCucumberなのか 筆者が勤めている株式会社RAWHIDE.では、Railsアプリを作成する場合、原則的にCucumberでテストを書くようにしています。Cucumber採用当時は、社内にナレッジが少ない、不慣れなど、なかなか

    第21回 Railsアプリの受け入れテストをCucumberで書こう | gihyo.jp
  • 第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp

    日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日には毎年数回仕事で帰国しているし、日語でブログや記事を書いてもいて、ある意味で「日のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の

    第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
  • 第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp

    「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニア仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「⁠常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス

    第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
  • 第1回 memcachedの起動オプションを把握しよう | gihyo.jp

    1.4系で新しく追加された主な機能しては バイナリプロトコルの導入 マルチスレッドの標準化 統計の強化 などが上げられます。この1.4系の機能の詳細については前坂徹氏の連載「memcached 1.4の到来」が参考となります。ここではバージョン1.2.5と最新の1.4.5の起動オプションを比較しながら、新しく追加された機能や実際の運用で用いられる起動オプションについて説明します。 1.2系と1.4系の起動オプションの違い まず、memcachedの起動オプションの一覧(ヘルプ)を確認しましょう。memcachedのヘルプを出力するには、「⁠-h」オプションを使います。 $ memcached -h memcached 1.x.x -p <num> TCP port number to listen on (default: 11211) -U <num> UDP port number t

    第1回 memcachedの起動オプションを把握しよう | gihyo.jp
  • 第42回 実世界のSinatra | gihyo.jp

    前回は、Sinatraバージョン1.0の概要を公式ドキュメントを手がかりとして、Sinatraを紹介しました。そして最後に、「⁠Sinatraの先には、まだ地図がない」と言及しました。 今回は、「⁠実世界のSinatra」と題して、実際にSinatraを利用して開発していくうえでの、筆者自身のロードマップを示していきます。 Sinatraとはいったい何か いきなりですが、Sinatraとはいったい何なのでしょう。 これは根的な問いになりますが、Sinatraで開発を進める前に、ここをしっかり考えることが重要であると筆者は考えます。 素直に考えるならば、Sinatraはもちろん、広義のWebアプリケーションフレームワークの一つである、と答えられるでしょう。アプリケーションフレームワークのそもそもの定義が、「⁠共通部分を再利用可能にし、開発を助けるもの」であるならば、Sinatraもこの例に

    第42回 実世界のSinatra | gihyo.jp
  • 第9回 SinatraとSequel・Hamlで掲示板アプリを作る | gihyo.jp

    はじめに 第7回はRails以外のWebフレームワークの簡単な紹介と、SinatraでHello Worldアプリケーションを動かすところまでを解説しました。今回はSinatraで実際のアプリケーションを作り、SequelとHamlという2つのライブラリを紹介します。 Sinatraの特徴は、CGIスクリプトのようにファイル一つからアプリケーションが書ける気軽さです。CGIスクリプトといえば、代表的なものは何と言っても掲示板(BBS)です。そこで、今回はSinatraで掲示板アプリを作ってみました。ソースコードが少し長めなので、githubにて全文を公開しています。適宜参照しながら読み進めて下さい。ファイル構成は以下のようになっています。 start.rb アプリケーションの体。 model/comment.rb 掲示板の書き込みを表すモデルの定義。 view/index.haml トッ

    第9回 SinatraとSequel・Hamlで掲示板アプリを作る | gihyo.jp
  • 第2回 Firebugによるデバッグの基本、Console APIとその活用 | gihyo.jp

    さて、前回はインストールからFirebugのタブの基的な部分について紹介をしてきました。今回は、Firebugに実装されているConsole APIの紹介と、Console APIを利用したデバッグ手法について解説していきます。 Firebugで利用できるAPI Firebugには、デバッグに活用できる2つのAPIが実装されています。今回は、その2つあるAPIのうちConsole APIについて解説していきます。 Console API Console APIはFirebugのタブだけでなく、コンテンツ側のJavaScriptから呼び出すことのできるAPIです。デバッグのために便利な関数があらかじめたくさん用意されています。これらの関数を以下に列挙しますので、目を通してください。 console.log(object[, object, ...]) 渡された全てのオブジェクトをconso

    第2回 Firebugによるデバッグの基本、Console APIとその活用 | gihyo.jp
  • 特集:Firefox 3とFirebugで始めるJavaScript開発|gihyo.jp … 技術評論社

    第3回Command Line APIとその活用、各タブからのデバッグ方法 堀邦明 2008-05-21

    特集:Firefox 3とFirebugで始めるJavaScript開発|gihyo.jp … 技術評論社
  • 2010年のJavaScript:「これまで」と「これから」 | gihyo.jp

    2010年のJavaScriptと題しまして、JavaScript周辺の「これまで」と「これから」についてまとめてみたいと思います。 2009年までのJavaScript JavaScriptは各ブラウザベンダなどが個別に実装するという特殊性から、ブラウザ(実装)ごとの非互換性の問題に悩まされ続けてきた言語です。まず、そのJavaScript歴史を簡単に振り返ってみます。 ECMA-262 3rd editionとスピードコンテスト JavaScriptNetscape社によってLiveScriptという名前で誕生し、その後ECMAScriptとして標準化が進みました。1999年12月にECMA-262 3rd editionが策定されてから、Internet ExplorerのJScript、MozillaのSpiderMonkey(TraceMonkey⁠)⁠、SafariのJav

    2010年のJavaScript:「これまで」と「これから」 | gihyo.jp
  • 第19回 Who&#039;s Who on IRC:Perl界の紳士録(IRC編) | gihyo.jp

    あの人はだれ? Perlの世界でいちばんホットな話はIRCでかわされている、ということを知っていくつかのIRCチャンネルに入ってみたはいいものの、そこで話をしているのがいったいだれかわからない、という経験はだれしも一度はするもの。なかにはIRC上でのニックネームとCPAN/PAUSE ID(と名)が同じ、という人もいますが、さまざまな事情からIRCとCPANでは似ても似つかぬ名前を使っているという人も(筆者を含めて)少なくありません。 今回はそんな「だれがだれだかわからない」「⁠業界の勢力図を知りたい」という悩みや希望にお応えして、おもにIRC上のPerl関連チャンネルでよく見かける人をPAUSE IDつきで簡単に紹介してみます。人選については、筆者が入っているいくつかの英語チャンネルの過去ログから、今年特に活発に発言していた人を機械的に抽出してみました。 マップにするとこんな感じ 単純

    第19回 Who&#039;s Who on IRC:Perl界の紳士録(IRC編) | gihyo.jp
  • 第36回 SQL::Abstract:簡単なSQLはより簡単に | gihyo.jp

    DBIの泣き所 いわゆるLAMPないしそれに似た環境でウェブサービスばかり書いている方にはあまり実感がないかもしれませんが、あちらの現場ではOracleを、こちらの現場ではMicrosoft SQL Serverを、はたまた別の現場では組み込みのSQLiteを、といった受託系の仕事をしている人にとって、SQLの方言問題は避けては通れないもののひとつです。 典型的なところでは、たとえばSELECTで取得するデータの件数を制限したい場合、PostgreSQLなどでは「LIMIT ... OFFSET ...」のように書きますが、OracleではROWNUMを使いますし、MS SQL serverならSET ROWCOUNTやTOPを使います。また、いまでこそPostgreSQLとの互換性を確保するため「LIMIT ... OFFSET ...」と書けるようになっているMySQLにしたところで、

    第36回 SQL::Abstract:簡単なSQLはより簡単に | gihyo.jp
  • 第2回 AnyEventでイベント駆動プログラミング (2) | gihyo.jp

    ウォッチャー AnyEventでプログラムを作成する場合「ウォッチャー」を作成、管理することが基的な作業となります。ウォッチャーとはI/Oやタイマーなどの何かしらのイベントが発生したことを通知してもらうためのオブジェクトです(図2のコールバックの指定および実行の部分を担当します⁠)⁠。 現在から5秒後にコールバック関数を呼び出してもらうにはリスト1のようなコードを書きます。 リスト1 ウォッチャー use strict; use AnyEvent; my $cv = AnyEvent->condvar; ……(1) # タイマーウォッチャーを作成 my $w; $w = AnyEvent->timer( after => 5, # 今から5秒経ったらイベント発生 cb => sub { # イベント発生時にこの関数が呼ばれる warn "5秒経ちました!"; undef $w; ……(2

    第2回 AnyEventでイベント駆動プログラミング (2) | gihyo.jp
  • 第2回 AnyEventでイベント駆動プログラミング (1) | gihyo.jp

    連載では第一線のPerlハッカーが回替わりで執筆していきます。第2回は、Japan Perl Association代表理事の牧大輔さんで、テーマはAnyEventです。 はじめに 昨今のPerl界で最も熱い話題がイベント駆動プログラミングです。イベント駆動プログラミングはいわゆる「リアルタイムWeb」などと呼ばれる、大量のデータや接続をさばきつつも更新通知の速さが重要となるアプリケーションでは必須技術で、今後のエンジニアにとって最も重要な知識の一つと言えるでしょう。 イベント駆動プログラミング自体はPerlでも以前からさまざまな用途に使われてきましたが、それがまた見直されているのは、従来のイベント駆動プログラミング用ツールキットの使いやすさをはるかに凌駕するAnyEventというモジュールが成熟期を迎えたためです。 イベント駆動プログラミングとは AnyEventの解説に入る前に、簡単

    第2回 AnyEventでイベント駆動プログラミング (1) | gihyo.jp