2007年09月02日(日)

非可逆圧縮に注意

テーマ:ブログ

データ圧縮形式の分類方法として、可逆圧縮・非可逆圧縮という分け方がある。可逆圧縮されたデータは、復元(解凍)すると、圧縮前と 100% 同じものに戻すことができるが、非可逆圧縮だとそうはいかない。一般に、非可逆圧縮とは、人間がデータを利用する際に不都合がない程度に、情報を割愛することだからだ。


非可逆圧縮は、通常は画像や音声、動画の圧縮形式について使われる言葉だが、他の種類のデータも同様の考え方で圧縮できることがある。


例えば、シフトJIS などの文字コードでは、半角の数字やアルファベットは1バイトで表現できるが、全角だと2バイトが必要となる。人間が単に文章として読むだけなら半角でも全角でもよいので、全角の数字やアルファベットを半角に変換することで、データを非可逆圧縮することができる。


このように、用途によっては便利な非可逆圧縮だが、元のデータが欠落することの弊害については、よく考えておかなければならない。



2000年問題(Y2K問題)といっても、若い読者にはもう分からないだろうか。1900年代に作成されたシステムは、日付データを扱う際に「年」の部分を下2桁しか持たないものも多かった。そういったシステムで2000年以降の日付を扱うと、期待しない動作をしてしまう。例えば、1995年を "95"、2001年を "01" と下2桁だけで持っていると、経過年数の計算(引き算)や大小比較の結果がおかしくなる。


これは、「このシステムが2000年まで使われることはない」という前提で、日付データを「非可逆圧縮」してしまった結果であるともいえるだろう。



Web を見ていると、時々、生きているのか死んでいるのか(更新が続いているのか止まっているのか)分からないサイトに出会うことがある。通常は、サイトの更新情報やページの掲載日付などを見れば分かるのだが、そうした日付に、年が記載されていないのだ。「8/1 更新」などと書いてあっても、今年の 8/1 なのか、去年の 8/1 なのか、あるいはもっと前なのか分からない。「1年以上更新が止まることはないだろう」という前提で年の表記を除いたのだろうが、実際には更新が止まっているのだ。


実害は小さいものの、これも2000年問題と同様、日付データを省略しすぎたことによる問題である。インターネットでの情報公開というと、空間的な広がり(グローバル性)ばかりに目が行くが、時間的にも長く残っていくという意識を持っておいたほうがいい。



システム開発では、データ量の削減が求められることは多く、非可逆圧縮的なデータの省略が有効なこともあるだろう。しかし、データの一部が失われることによる影響についてよく考えておかないと、システム稼動後に困ったことになることもあるので、注意したい。







■関連記事
省略してはいけないものもある




JPEG―概念からC++での実装まで
橋本 晋之介 アズウィ
ソフトバンククリエイティブ (2004/12)
売り上げランキング: 52645
おすすめ度の平均: 5.0
5 待ってました!


暦と数の話―グールド教授の2000年問題
スティーヴン・ジェイ グールド Stephen Jay Gould 渡辺 政隆
早川書房 (1998/10)
売り上げランキング: 228563

AD
いいね!した人  |  コメント(7)  |  リブログ(0)
2007年08月19日(日)

ちょっとしたプログラム

テーマ:専門用語

「ちょんプロ」という言葉がある。プログラマが自分自身の作業を楽にするために作る簡単なプログラムのことである。私がこの言葉を初めて聞いたのは、おそらく職場だったろう。ネットで検索しても出てくるが、それほど頻繁に使われているわけでもなさそうである。語源は不明だが、おそらく「ちょっとしたプログラム」の略だろう。


「ちょっとした」というのは面白い言葉である。大辞林(goo辞書 )によると、ひとつには、「わずかな」「ささいな」といった意味がある。「ちょっとした風邪」、「ちょっとした感情の行き違い」といった使い方だ。一方で、「大層立派とはいえないまでも相当の」「かなりの」という意味もある。「ちょっとした会社の経営者」だとか「どうだ、ちょっとしたアイデアだろう」といった使い方である。


「ちょんプロ」という言葉には、その両方の意味が込められているように思う。ソースコードの量が少ないプログラム、あるいは、短い時間で作ったプログラムであるのは確かだが、それだけではない。何かしら実用的な機能を持っていたり、それ自体が技術調査を目的としたものであったりと、ちゃんと役立つものでなければ、ちょんプロとは呼ばれないのである(つまり、"Hello World!" と表示するだけでは駄目だ)。


つまり、ちょんプロを作るには、それなりの力が必要である。有用なプログラムをいかに短く、短時間で書けるかということだからだ。綿密なテストを行うわけでもないので、コーディングの品質も高くなければならない。


必要なのはプログラミングの技術力だけではない。そこには、企画から、要件定義、設計、実装といったソフトウェア開発工程の縮図がある。その全てをプログラマ自身で行うのだ。例えば、単純作業を自動化するためのプログラムが欲しいと思っても、それを作るのに時間がかかり過ぎるのなら、作るべきではない。そういったことを正しく判断するには、プログラミングに必要な時間を正確に見積もる力が必要だ。そしてそのためには、事前にある程度の実装方法までイメージできていなければならないだろう。


たかが「ちょんプロ」。されど、それを作る過程には、ソフトウェア開発者として学ぶところは多くありそうだ。







■関連記事
面倒くさいこと




Short Coding ~職人達の技法~
Ozy やねうらお
毎日コミュニケーションズ (2007/08/09)
売り上げランキング: 1057


業務システムのための上流工程入門―要件定義から分析・設計まで
渡辺 幸三
日本実業出版社 (2003/10)
売り上げランキング: 11335
おすすめ度の平均: 4.5
4 上流工程のル―ル化促進を期待します
5 システム屋にとって感動を呼ぶ本でした
3 上流工程の入門書

AD
いいね!した人  |  コメント(4)  |  リブログ(0)
2007年08月05日(日)

この文書は誰が読むのか

テーマ:ブログ

自称職業プログラマの私だが、最近はプログラミングをしている時間はどんどん少なくなってきた。遂には顧客向けにシステム導入の提案書を書いている始末である。


技術者が提案書を作ると、システムの機能面を強調しがちだ。特に、事前に客先の担当者と打合せをし、システムの要件がある程度決まっているような場合には、いわゆる「能書き」の部分は「当り前のこと」として省略してしまう。「能書き」とは「そもそもそのシステムを導入することによるメリットは何であるか」といった、根本的なところの説明である。


確かに、顧客の担当者が読むだけなら「能書き」は必要ないだろう。しかし、彼がその提案書を上司に読ませたらどうか。決裁権を持つようなレベルの上司の多くにとっては、システムの細かい機能や実装技術などはどうでもよいことだろう。むしろ、そのシステムを導入することによって会社にどんなメリットがあるのか、ということこそが彼らの関心事なのだ。



この「当り前のことを省略してしまう」という行為は、実は色々なところで問題になりうる。例えば、社内の報告書。直属の上司が読んだ時には問題なかったのに、更にその上の上司が読んで、「意味が分からない」と言われたことはないだろうか。


システムの設計書でも同じだ。設計書の内容は、とりあえずはその開発プロジェクトの関係者に伝わればよいので、関係者にとって「当り前のこと」は省略されがちだ。しかし、プロジェクトに遅れて参加する人や、後から保守をするような人がその設計書を読んだ時に、「当り前の知識」がないために誤読し、不具合を生むようなことだってある。



文書を書く際には、読者層を想定する必要がある。それは書く内容(焦点)を絞り込むということでもある。しかし、あまりに読者を限定しすぎると上記のような問題が起こってしまう。最初に頭に浮かんだ読者の他に、第二、第三の読者がいないか、よく考えた方がよさそうだ。







■関連記事
どこまで書くか設計書
書かずに伝える
読者指向プログラミング




SEのための提案書のつくり方―お客さまにわかりやすく伝える
小野 泰稔 神野 憲昭
日本能率協会マネジメントセンター (2004/02)
売り上げランキング: 158483
おすすめ度の平均: 5.0
5 SEでなくても役に立ちそうです。


知らずに身につく企画書・提案書の書き方―すぐに使えるだれでも書ける72文例付き
斉藤 誠
日本実業出版社 (2002/03)
売り上げランキング: 38645
おすすめ度の平均: 4.5
4 なかなか
5 ビジネスマンの必読書

AD
いいね!した人  |  コメント(1)  |  リブログ(0)
2007年07月22日(日)

エンドユーザーとは

テーマ:専門用語
コンピュータ業界では「エンドユーザー」という言葉がよく使われる。直訳すれば「末端の利用者」だが、文脈によって微妙に意味が変わるようだ。

例えば、ユーザーを管理者とその他に分けた場合に、後者のことを指す場合がある。あるいは、システムを使ってサービスを提供する者と区別して、そのサービスを利用する者を指すことがある(例えば、ショッピングサイトで言えば、ショップの運営者と区別してショップの顧客を指す)。


他にも、パッケージソフト等では「最終消費者」のような意味で使うこともあるし、受託システム等を孫受けする場合に直接の(つまり二次の)発注者と区別して一次の受発注者を指すようなこともある。


あるいは、単に漠然と「コンピュータに詳しくない人」を意味する場合もある。



ほとんどの場合、文脈から意味が理解できるので困ることもないのだが、ちょっと気になったので、一般的な定義がどうなっているのか調べてみた。


まず、@ITの Insider's Computer Dictionary では、


 広義には、製品やサービスなどを末端で消費する利用者のこと。コンピュータ関連では、コンピュータ自身をビジネスにしたり、第3者のコンピュータ環境を管理したりするのではなく、あくまでもコンピュータを道具として利用するユーザーのことを指す。

 エンドユーザーのハードウェア/ソフトウェア環境やネットワーク環境などを管理する「管理者」と対比させ、「管理される側」という意味を込めて、エンドユーザーという言葉が使用されることもある。


となっている。あえて「第3者の」としているところをみると、自分(達)用のシステムを管理する人はエンドユーザーと呼ぶのだろう。実際、「@IT情報マネジメント用語事典」の「エンドユーザー・コンピューティング」の説明 では、システムアドミニストレータ(システム管理者)がエンドユーザーの代表として位置づけられている(上記の引用の最後が「こともある」となっているのは、そういう例をふまえてのことだろう)。


次に、日経パソコン用語事典2007(日経パソコンオンライン) をみると、


自分の業務を処理することを目的に、コンピューターを道具として使っているユーザーのこと。情報システム部門の担当者のように、社内の各部門の人々の要求に応えてコンピューターシステムを構築するユーザーと対比する場合に使う。


とある。@IT の記述に似ているが、「管理」ではなく「構築」という言葉が使われている。システムを「管理する人」は「構築する人」よりも「エンドユーザー寄り」だと思う(※1)が、そういう意味では、「管理者」の位置はもっと曖昧になってしまっている。


これらと全く毛色の違う説明をしているのは、三省堂「デイリー 新語辞典」(goo 辞書) だ。


末端の利用者。一般使用者。コンピューターでは自分ではプログラムは組まず,アプリケーション-プログラムだけを利用するユーザーをさす。


なんとも乱暴な説明である。プログラミングをする人でも、他者が作ったアプリケーションを使うだけなら、他のユーザーと同じだと思うのだが、この定義だとそうはならない。また、コンパイラのようなプログラマ向けのソフトウェアは、エンドユーザーを持たないということにもなってしまうだろう。更に、「エンドユーザープログラミング」、「エンドユーザー言語」といった言葉と矛盾してしまう。


とはいえ、「コンピュータに詳しくない人」といった曖昧になりがちな分類に対して、明確な基準を与えていることには潔さを感じる。例えば、同じシステム管理者の中でも、プログラムを組まない人はエンドユーザーだし、プログラムを組む人はエンドユーザーではないということになる。



他にもいくつか用語解説の類を調べてみたが、多様に使われている「エンドユーザー」という言葉を包括的に説明する記述は見つけられなかった。


考えてみれば、「ユーザー」という言葉自体が広い意味で使われるものである。ユーザーというのは、何かを「使う人」であり、その「何か」によって意味が変わるのは当然である。先に書いたように、ほとんどの場合、文脈から意味を判断できるので、特に難しく考えることもないのだろう。


ただ、「カスタマー(顧客)」とか「コンシューマー(消費者)」と表現した方が分かりやすいような場面では、あえて「ユーザー」という言葉を使う必要もないだろう。自分が使う場合には、注意したいと思う。








※1
というよりも、システムを「構築する人」はシステムの「ユーザー」ですらないような・・・。コンピュータ=ハードウェアのユーザーとしての話なのかも。




■関連記事
 ・曖昧言葉




1週間で分かる初級シスアド集中ゼミ「午後編」〈2007春秋〉
栢木 厚
日本経済新聞社 (2006/11)
売り上げランキング: 1362
おすすめ度の平均: 5.0
5 基本をおさえることが合格の秘訣
5 午後は○○!?


エンドユーザコンピューティング
佐藤 修 佐々木 憲一 松尾 道明 山田谷 勝善 大塚 修彬 沢田 博光 山川 隆義
日科技連出版社 (1996/07)
売り上げランキング: 768402


いいね!した人  |  コメント(3)  |  リブログ(0)
2007年07月08日(日)

もどかしい話

テーマ:喜怒哀楽

既存の Flash 製のプログラムを改造する仕事をした。Macromedia Flash 8 を使って、ソースコード(というか .fla ファイル)を変更するのである。しかし、私はこのツールを使った経験が全くなかった。


本来、Flash はアニメーションを作るためのツールであり、VB や Eclipse などのプログラマ向けの IDE とは全く勝手が違う(直感的に編集できたのはスクリプトエディタの部分だけだった。Flex ならよかったのに!)。周囲に詳しい人もおらず、ネットの情報を頼りになんとかやってみたが、思うように仕事が進まず、もどかしい思いをした。


仕事でこんな状況に陥ったのは久しぶりだった。プログラミング初心者の気分というのは、こういうものだったかもしれない。



・・・などと考えていたところ、FPN に「何かを始めようとするとき、必ず陥る罠 」という記事が。「好転の前兆」として、いくつかの例が挙げられているが、なるほど、誰しも思い当たるものがあるのではないだろうか。


何か新しいことを始めれば、最初は効率が悪いのは当然である。それを必要以上にネガティブに捕らえてしまうと、成果が出る前にくじけてしまったり、苦手意識を持ってしまったりする。最初の効率が悪いなら、悪いなりのスケジュールを引いておけばよい。あとは気持ちをどう持つかという問題だろう。


もちろん、新しいことを始める時には、進む方向を間違ってしまうことがあるので、必要以上にポジティブに考えるのも危険ではあるのだが・・・。








■関連記事
プログラミングは体で覚えろ
プログラミングを始めようとして何度も挫折した人へ



Flash Hacks―プロが教えるテクニック&ツール100選
シャム バンガル Sham Bhangal クイープ
オライリージャパン (2005/07)
売り上げランキング: 5516
おすすめ度の平均: 5.0
5 楽しい
5 他にはないテクニック満載


すごい「実行力」
すごい「実行力」
posted with amazlet on 07.07.08
石田 淳
三笠書房 (2007/06/20)
売り上げランキング: 2

いいね!した人  |  コメント(0)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。