ひらっちです。 Webプログラミングではどのようなデータが送られてきても正常に動作するよう、入力データの検証が欠かせません。一方で、ユーザがフォームに入力したデータを、JavaScriptを使ってその場で検証して表示できれば、ユーザビリティの向上につながります。 この二つの機能は、データの検証についてはほんんど同じ機能です。しかし、多くの場合、サーバサイドではJavaScriptとは違う言語でプログラミングされているので、共通のコードにすることはできませんでした。 今回私が作成したものは、プログラミング言語に依存しないかたちで検証方法を書くためのライブラリです。まだ機能が絞り込まれていなかったり、足りなかったりしますが、一応動く形になりましたので公開します。 この機能を実現するため、最初はJSONを使っていました。しかし、JSONはある程度を超えた複雑な表現をしようとすると、見た目に煩雑に

こんにちは satoです。 障害の多くの場合はハードディスク障害ですが、実際障害が起きた際に、どのように復旧するかをケース別に書いてみようと思います。 hdd のセクタが壊れた /var/log/message等に kernel: hda: dma_intr: status=0x51などど表示されているとハードディスク障害の可能性が高いです。 badblocks -vs -o hda1.sector /dev/hda1 (かなり時間がかかる)とやると 不良セクタが書き出されたファイル hda1.sector ができます。 fsck -l hda1.sector /dev/hda1 とやると不良セクタを使用しないようになります。いずれにしても早めの交換をお勧めします。 memoryが壊れた http://blog.miraclelinux.com/mita/cat218683/index.

尾藤正人です。 最近僕のアメリカ人の友達がオフィスに来たときに英語で会話をしてたのですが、ようやく僕が本当に英語が話せることが証明できて存在価値を認めてもらえるようになりました。 昔は理科数学しかできない典型的な理系人間で、高専に進学したため受験戦争の荒波から逃れ、英語レベルは中学生止まり。海外に一度も行ったことがない(パスポート持ってない)状態で外国人と普通に会話ができるまでに成長することができました。 英語は読めるんだけど喋るのは苦手という方は多いと思います。なので、僕がどうやって英会話力を見につけたかを紹介したいと思います。 日本語を使わない これが一番大事です。英和辞典は捨ててもいいぐらいです。日本人は日本語を勉強するときには日本語を使います。英語を勉強するときには英語を使えばいいのです。そもそも言語っていうのは一対一で対応するものではないので、外国語を使うことに無理があります。英

hideです。 僕がMac OS Xを使うようになって1ヶ月と少しが経ちました。最初は戸惑うこともあったのですが、だいぶ手に馴染むようになってきました。最近、オープンソース関係のイベントに行くとMacユーザがかなりの割合でいる理由が分かったような気がします。感想としては、 UNIXの良い文化を取り入れている DockやDashbordの動きがいちいちカッコいい VMwareやcoLinuxを使わなくてもローカルに開発環境を作れる 今更ながら、BSDベースにしてMicrosoft製のOSとの違いを出していくというAppleの戦略には関心してしまいました。Web系エンジニアの方は、Macを次に購入するPCの候補に入れてみてはいかがでしょうか。 というわけで、あなたがいつかMacユーザになった際に便利なように、最初にインストールするべき10のアプリケーションを紹介します。 1.Firef

Sashaです。 MicrosoftがIE7 RC1（Internet Explorer 7 Release Candidate 1）を公開しましたね。タブ・ブラウジング? RSS? 今ドキ当たり前。タブに出ているサイトのサムネイルが一括して見れるとか、印刷するときに用紙の大きさに合わせて印刷してくれるぴったり機能とかも、「あったらいいな」的機能であったことは確かですが、ウェブデザイナーたちの興味の中心は、今まで私たちの忍耐力をギリギリまで試してきた、IEの CSSへのサポートが、どのように変化するのか、ですよね。せっかくなので、今まで長年にわたって多くの人を悩ませてきたバグたちと照らし合わせながら見ていきましょう。ちなみに、私はまだ一つ一つ検証してませんので、その解決宣言に関する信憑性には責任は負いかねます。悪しからず。 positioniseverything.net では数年前から

こんにちは satoです。 インデントが浅いと、コードが見やすいです。 インデントが浅くなりそうなテクニックを紹介します。 時と場合にもよりますし、賛否両論もあると思いますが、寛大な目でみてやってください。 1)処理の判定は正常じゃない場合を書く //before $data = getdata(); if ($data) { なんか複雑な処理; } else { return false; } //after $data = getdata(); if (!$data) { return false; } なんか複雑な処理; 2) array か どうかを判断する場合は array にして処理をする //before if (is_array($args)) { foreach() ... } else { .... } //after if (!is_array($args)) {

こんにちは！　やまもと＠テスト番長です。 先日マサトさんに教えてもらったのですが、 こんなウェブアプリケーション用のチェックシートがあるそうです。 SECGURU: Web Application Testing cheatsheet なかなか面白いので、軽く日本語にしてみました。（Special thanks to: ジュンヤさん） ※間違ってたらごめんなさい。　 1. アプリケーション名とバージョン 2. コンポーネント名 3. 通信プロトコル　SSLならばバージョンと暗号方式 4. パラメーターのチェックリスト URLリクエスト URLエンコーディング クエリストリング ヘッダー クッキー フォーム フォーム（Hidden） クライアントサイドのヴァリデーションチェック 使用していない余計なパラメータの存在 文字列長の最大/最小値 連結したコマンド（Concatenate

sashaです。 naoya君が前回のエントリーで振ってくれたように、ジョエルテストの話から、ユーザビリティ・テストをどこまで行うかという話になりました。 私が今まで見たユーザビリティ系の記事の中には、追求したら悟りが開けそうな、限りなく奥深いものもありましたが、適度に深く、満遍なくカバーしているユーザビリティ・ガイドライン（原文）を見つけ、以降これを参考にしています。少し前に翻訳しましたので、今日はそれをご紹介いたします。 一般ユーザー向けのWebサービスでは、全部のチェック項目が該当するわけではありません。個人的には、各項目のスコアより、「スコアの説明」という欄を重視しています。現状では何が問題であり、どう解決するべきなのか、そういった思考のプロセスが、「ユーザーのことを思うこと」だと思うのです。 いま、ウノウではフォト蔵のデザイン見直しを行っております。私たちのデザインを省み、

尾藤正人です ラボブログではウノウのエンジニアで1日1人1エントリ(早く書くのはあり)で書いてます。おかげさまでウノウも順調にエンジニアの数が増えて、僕の順番に回ってくるのが少しずつ遅くなってきました。でもまだまだウノウではエンジニアを大募集中です!!我こそはと思う方はぜひご連絡ください。 前回のベンチャー流サーバ構築のススメ(ネットワーク編)ではネットワーク周りについて書きました。前回のエントリで言ったように、今回はソフトウェア周りのことについて書きたいと思います。 ソフトウェア周りで重要なのは、同じ構成にする、これにつきます。web サーバにだけ apache をインストールしたりとか、DB サーバにだけ MySQL をインストールしたりだとかいうことはしません。全てのサーバに同じパッケージ、同じプログラムをインストールします。それによる管理コストの軽減ははかりしれないものがあります。

尾藤正人です。 ウノウでは最近新オフィスに引越ししたのですが、新オフィスにサーバルームを設置してフォト蔵のサーバをホスティング業者から自社サーバに移行しました。 自社サーバに移行のは下記のような理由からです。 フォト蔵のようなストレージ系のサービスの場合、十分な帯域を確保する必要があるが、広帯域を確保するにはコストがかかる フォト蔵のようなストレージ系サービスの場合、大容量のHDDが必要になるが、大容量のHDDを搭載したマシンはハイエンドマシンになり、増設コストがかかる マシンの増設に時間がかかりフレキシブルに対応できない というわけで自社サーバに移行したわけですが、自社サーバに移行するにあたって様々なノウハウがたまってきました。 サーバ構築にはいろいろトピックスがありますが、今回はハードウェア的な部分について書きたいと思います。 ・マシンは全て同じ構成にする 数多くのサーバを運用するに