flint>flint blog
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 »

A Good Example of Bad Interface Design

ノートだけで仕事をするのは少々きついので、デスクトップPCを一台、新規に購入しました。 OSは Windows 7 (64ビット版) を搭載。 さっそく環境設定や各種ソフトウェアのインストールを行います。

これまで XP を使い続けていたのは、Vista 以降、Windows (に限らず Microsoft 製品全般) のユーザインターフェイスのレベルが無残なほどに低下していたからに他なりません。 (参考: Windows Vista) 7 になってもインターフェイスの改良の気配は見られず、各種の挙動にイライラしながら設定作業を行っているのが現状です。 各種プログラムの中でも特にひどいのが、Windows Live Messenger 2011." 「わざと使いづらいように作っているのか?」と疑念を抱かずにはいられないレベルです。

というわけで今回は、UI設計の反面教師とすべく、この最悪のインターフェイスについて詳しく解説をしていきたいと思います。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Ruby でも型チェック

動的型付け (スクリプト) 言語では、データ型のチェックが実行時にしか行われないため、プログラムの妥当性検証・デバッグといった作業が困難になります。 例えば、Ruby でプログラムを書いていて、次のようなバグに悩まされたことのある人は多いのではないでしょうか。

  • Integer オブジェクトを参照しているべき変数が、他の型のオブジェクトを参照している。
  • そのオブジェクトが「いつ」「どこで」代入されたものなのか分からない。

この手のバグは、問題の発生 (不正な型の代入) と発覚 (エラーの発生) の位置が離れてしまうので、非常に厄介。 発生箇所を絞り込むのが難しいため、プログラムを広範囲に渡って見直すハメになります。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

ウェブサービス開発について

ウェブサービスを構築するために使用できるソフトウェア, ツールには様々な選択肢がありますが、これまでに私が手掛けてきたもの (→参照) は概ね、以下のような構成になっています。 (このサイトが置かれているサーバもこの構成です。)

OS FreeBSD
Web サーバ Apache
CGI スクリプト Ruby
データベース PostgreSQL
その他 ImageMagick (Convert コマンドによる画像変換用)

諸事情により、OSが Red Hat Linux になったり、データベースが OracleMySQL, SQLite などになったこともありますが、基本的な構成は変りません。 (というか、移植性を意識して、そうなるようにプログラムを組んでいます。)

こうしたプラットフォームに依存しないシステム設計が「売り」でもあります。 予め環境に制約などがある場合であっても、最小の手間で構築を致しますので、そうした案件がございましたら、是非ともご用命ください。

成田
このエントリーをはてなブックマークに追加

営業資料作成中

名刺

来週月曜日から、市内のソフトウェア開発を行っている会社を訪問して回る予定ですが、その際に必要となる営業資料を作成中です。

とりあえず、名刺 (左図) は100枚ほど用意しましたが、もちろんこれだけでは足りません。

「何ができるの?」「今までどんなことしてきたの?」など、発注を考える側が知りたいと思う情報を過不足なく載せた資料を作らなければならないのですが、これが難しいもの。 あまり技術的なことを長々と書いても読む気が失せるだけですし、かと言って、プロを相手にあまりに端折った説明をしても信用を損ねてしまいます。

まだまだやるべきコト・考えるべきコトはいっぱいあるようです。

成田
このエントリーをはてなブックマークに追加

サーバと奮闘中

新しく仕事を始めるにあたっては、どうしてもサーバが必要となります。 そんなわけで、さくらインターネットのVPSを借りることにしました。

OSは、業務でもプライベートでも使い慣れている FreeBSD を選択。 ここに、Apache, Postfix, Dovecot, PostgeSQL 等々のソフトウェアをインストールし、これらを適切に設定しなければならないのですが、これが想像していたよりも大変な作業です。 前の職場にいたときは専門のスタッフが管理するサーバを何気なく利用していましたが、自分でその作業を全部やるとなると、これがいかに大変なことかが分かりますね。

かく言う現在も、Postfix のSMTPまわりの設定に不備があるらしく、メールが上手く送信できないので、目下調査中です。 サーバの設定にばかり時間をかけているわけにもいかないので、さっさと片付けてしまいたいところなのですが...。

成田 (がんばれ!アドミンくん)
このエントリーをはてなブックマークに追加

ごあいさつ!

はじめまして。 今月より、ここ山梨県甲府市でフリーランスで活動を始めた 成田 祥 と申します。

五月末までは、福島県は会津若松市のとあるIT企業で働いていましたが、諸事情により独立することとなりました。

業務としては主に、Microsoft Visual C++ を用いた Windows アプリケーション (サーバ/クライアント型含む) の開発や、Ruby を試用したウェブ (CGI) サービスなどを手掛けてきました。 珍しいところでは、SensAble Technologies 社が提供する触覚デバイス PHANToM の制御プログラムなども書けたりします。 Omni (GHOST: General Haptic Open Software Toolkit) と Desktop (Open Haptic SDK) 両方の開発経験があります。

知人のツテなどの一切ない状態でのスタートですので、これから積極的に営業活動を行っていく予定です。 ソフトウェアの設計・構築の案件がございましたら、是非お声掛けください。 電話番号, メールアドレス等は、こちらに掲載しております。

成田
このエントリーをはてなブックマークに追加

チョークのマークひとつ

これが問題の個所だ。

私たちが普段行っているソフトウェア・システム開発には、他の製造業と大きく違う点があります。 それは、モノができあがるまでに掛かるコストの殆どが人件費であるということ。 他の製造業において、原材料, 加工に使われる電気, 洗浄のための水など費用が占める割合を考えれば、これはかなり特殊な形態です。 (厳密に考えるならば、そうした費用も最終的には人件費に行き着くわけですが、ここでは措いてください。)

ところで、この「人件費」とはいったい何でしょうか? 辞書的な定義を引くならば、人を雇用することによって発生する費用のことですが、そうした言い換えはあまり実用的とは言えません。 その性質に着目した理解の仕方をするならば、それぞれの被雇用者が有しているエネルギーや知識・技術といった所謂「労働力」を調達するためのコストである、と言えるでしょう。

この労働力のうち、使われたエネルギーあるいは、為された (物理的な) 仕事については、定量的な評価が可能であるため、支払われた賃金に見合っているかどうかということは比較的容易に判断することができます。 その一方で、知識あるいは技術と呼ばれるものについては、それを定量的に計測することは極めて難しく、実際問題としては不可能と言わざるをえないでしょう。 例えば、二人の技術者がいたとき、その知識の差を数値で表すことは可能でしょうか? あるプログラミング言語を習得することによって、どの程度の技術向上が見込めるかについての客観的な評価法は存在するでしょうか? そのような方法論の確立を目指して、これまでも標準化や規格化, 資格・認定制度の導入などが数多く試みられてきましたが、私の見るところでは、そのどれもが技術者の力量あるいは価値を定量的に示す基準として機能しているとは言い難いのが現状です。 また、あるノウハウを手に入れるために必要となる投資 (金額, 時間) はどれほどか、という問題についても、未だ実用に耐える精度を備えた計算方法はありません。

そうした、知識・技術を獲得・評価することの難しさについては、これまでも何度かこの日記で書いてきました。

それ故、私には今や、このテーマについて新しく語るべきことはあまりなかったりします。 その替わりといっては何ですが、個人的に気に入っている、ある古いジョークを紹介したいと思います。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Tractor

固定翼の飛行機は、揚力を得たり、舵を利かせるために、その翼に当たる風を必要とします。 この風が得られなくなり、パイロットが機の状態を制御できなくなってしまうのが、いわゆる失速 (ストール) と呼ばれる現象。 このような、コントロールを喪失した状態の発生をいかにして防ぐか、あるいは、そこからどれだけ早く復帰するか、ということは、工学において非常に重要な課題です。

「結局のところ、ストールから抜け出す時間だ」ティーチャは答えた。

散香のようなプッシャ・タイプはプロペラが後ろにある。 一方の翠芽はプロペラが前にあるトラクタ・タイプだ。 プロペラが作った風を、機体で受け止めているトラクタは、メカニズムとしては効率が悪い。 ところが、機体が失速して、頭を下げて落ち始めたときには、速度がある程度まで達しないと舵が利かないけれど、そのとき、トラクタはプロペラが作り出す風を翼の舵に当てることができるから、舵が早く利き始める。 極端な場合、速度がまったくゼロのときだって、プロペラを高速に回して舵を大きく切れば、姿勢を制御できる。

自動車に搭載されているABSもその一例。 フルブレーキをかけても、タイヤをロックせず、ハンドルを切ることで進行方向を制御できる (つまり、舵が利く) ように設計された機構です。

あくまで私の個人的な意見ですが、自動車や飛行機だけでなく、私たち人間の心理・行動の制御についても、この工学の理論を適用することで、見えてくるものがあるのではないでしょうか。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

求められているもの

東日本大地震発生から5日が経ちました。 各被災地では未だ混乱が続いており、今このときも、被災者の安否情報を求め、いたたまれない思いをしている人々が全国にどれだけいることでしょう。

昨日まで、私もその一人でした。 津波によって壊滅的被害を受けた宮城県気仙沼市に住む弟と、地震発生から4日が経っても、一向に連絡が取れず、現地の被害状況に鑑みて、半ば諦めてもいました。 幸いにして、昨日本人から実家に連絡があり、その無事を確認できたのですが、それまでの4日間は、本当に気が気ではありません。 何でもよいから彼の消息に関する情報が得られないものかと、寸暇を惜しんで情報収集を試みていました。

その際、速報性に優れるメディアとしてテレビに大きく頼っていたのですが、時間が経つにつれて、私はその災害情報の報道の在り方に大きな苛立ちを感じ始めました。 というのも、テレビがそれを観ている多くの人が真に求めているであろう情報、即ち冒頭でも述べた、被災者の安否情報を伝えることについて、とても消極的だからです。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

抜け落ちるもの

ソフトウェア開発の工程は大きく分けて、要件定義, 設計, コーディングの三段階からなります。 (実際には、その後にテスト, デバッグなどの段階が続きますし、これらも明確に区別されるわけではなく、互いに絡み合っている部分もありますが、「作る過程」の説明としては大きく外してはいないはず。) これらの段階においては、「何を」「どのように」作るかということが順次決定されていきます。 そこで決められた事項は、仕様書設計図として文書化され、開発に携わるメンバの間で共有されることになるわけですが、この共有の際に零れ落ちてしまう、あるいは、作る過程では確かにあったのに、完成品からは抜け落ちてしまうものがあります。

例えば、データベースの仕様書には、各テーブルに属するカラムの名前, データ型や、それらが満たすべき制約については、逐一正確に書き込まれます。 しかし、それらの事項がどのような理由・経緯によって決定されたのかということについては、ドキュメントは何も教えてはくれません。 書きあがったプログラムを眺めても、例えば関数名や引数の並びについて、何故そのようになったのか、ということは分からないようになっているのが一般的です。 それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

けれども、ソフトウェア開発の知識・技術の本質とは、こうした「作る過程」における「瑣末なもの」の中にこそある、と私は考えています。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 »