圧縮・解凍ソフト CubeICE をゼロから改修

気付けば数年ぶりの更新となってしまいました。私は、普段 キューブ・ソフト (CubeSoft) と言う会社で様々な Windows ソフトウェアを開発・公開していますが、その一つに CubeICE と言うファイルの圧縮・解凍(展開)を行うソフトウェアがあります。今回、この CubeICE に対して 6 月~ 8 月にかけてゼロから書き直す大改修を行ったので、その記録として何かを書きたいと思い、久々にブログを執筆しています。

なぜ CubeICE をゼロから書き直したのか?

CubeICE は、7-Zip と言う圧縮・解凍ソフトウェアのライブラリ部分を修正して日本語の文字コード推測・変換処理を追加し、そのライブラリを利用した GUI アプリケーションとともに公開しているソフトウェアです。

CubeICE メイン画面

2011 年に最初のバージョンを公開して以降、Zip ファイルを WindowsMac 間でやり取りするユーザを中心に、文字化けが発生しにくいと言う一定の評価を頂いていました。また、圧縮ファイルにマウスカーソルを合わせるとファイルの一覧を確認できるシェル拡張機能なども好評で、現在でも多くのユーザにご利用頂いています。この CubeICE ですが、公開からしばらく経った段階で私の方でもいくつかの問題点を把握しており、その中でも大きな問題は以下の 2 点でした。

  • ボタンのクリック等、GUI の反応に大きな問題が存在する
  • ファイル数の多い圧縮ファイルを解凍する際、非常に長い時間を要する

これらはともに GUI プログラミングや 7-Zip を利用する上での(初期開発当時の)私の知識不足が原因で発生したものですが、ソフトウェアの根幹部分に存在する問題であった事もあり改修に多くの時間を要する事が予想されたため、長らく保留事項となっていました。しかし、現在でも引き続き多くのユーザにご利用頂いており、何とかしたいと言う気持ちは強くありました。また、「7-Zip」v16.00には危険な脆弱性の修正も。「PeaZip」にもアップデートが提供される - 窓の杜 などを始めとして、ここ 1, 2 年、圧縮・解凍ソフトウェア(ライブラリ)に脆弱性が見つかり、修正バージョンがリリースされる頻度が高まっている傾向が伺えます。そうした緊急度の高い修正に対して素早く追随するための開発体制を整えると言う意味でも、改修の必要性を強く感じていました。そこで、今年の大きなテーマの一つとして、CubeICE にあるこれらの問題の根本的な解決を図るべく、ゼロから書き直す事を決定しました。

CubeICE 改修の概要

改修に際しての一番大きな決断はプログラミング言語C++ から C# に変更する事でした。

CubeICE は当初 C++ と Win32 API のみで開発されていました。これは、開発開始当時においては、一般ユーザの .NET Framework に対するネガティブな印象がまだ完全には払拭されたとは言えないのではないかと言う判断によるものでしたが、その後の保守作業の大変さを生んだ要因の一つともなりました。2017 年時点においては、さすがにもう .NET Framework も広く認知されたと見なして良いだろう事と、GUI の非同期処理をまともに実装するにあたり、他はともかく async/await と呼ばれる機能だけはどうしても利用したいと言う個人的な思いから、この決断に至りました。その甲斐もあって、GUI の反応の悪さに関しては問題ないレベルまで改善できたと思います。

もう一つの課題は 7-Zip との連携に関する部分で、具体的には COM インターフェースから 7-Zip ライブラリ (7z.dll) を利用する方法の改修となります。従来の CubeICE では 7-Zip との連携に不完全な部分があり、これが「多数のファイルを含む圧縮ファイル」を解凍する際に処理時間が異常に長くなってしまう現象の原因でした。7-Zip との連携に関しては、随分昔に @rofi に詳細を調べてもらっていたのですが、前述したような都合で実際には活用されないまま時間が過ぎてしまいました。今回、当時の調査結果等も参考にしながら、ようやく該当部分の実装を終える事ができたので、この場を借りて御礼申し上げます。

尚、修正効果については、CubeICE 0.8.0β のリリースノート でも触れましたが、サンプルケースとしてハードディスク上(not SSD)で「59,763 個のファイルを持つ 135MB の Zip ファイル (boost_1_64_0.zip)」を解凍したところ、CubeICE 0.7.3β では約 35 分かかっていたのが、0.8.0βでは約 7 分まで改善しましたWindows 標準の展開機能を含めていくつか比較してみましたが、少なくとも CubeICE だけが特別遅いと言う現象は解決できたのではないかと思います。

まともな開発および保守環境の構築

今回ゼロから書き直すに当たり、ソフトウェアのバージョンアップと言う最終目的とは別に、開発中に設定したテーマとしてまともな開発および保守環境を構築すると言うものがありました。具体的には、以下のような項目となります。

まず、バージョン管理は、自ソフトウェアの開発プロジェクトは 2010 年の頃から git によるバージョン管理を続けているので大きな変化はないのですが、既存の OSS プロジェクトをカスタマイズする際におざなりになる傾向がありました。このせいで、前述した 7-Zip脆弱性に対する修正をカスタマイズ版に反映する時に苦労した経験から、何とかしたいと感じた課題です。7-Zip に関しては、フォークしたリポジトリ (cube-soft/7z) に対していくつかのブランチを用意し、オリジナル版の修正を反映しやすくする事で改善を試みました。改修後に発生した 7-Zip 側のアップデートは 1 度しかないのですが、この時は git の自動 merge のみで完了できたので、従来に比べて随分と楽になった事を実感できました。

ユニットテストに関しては、ライブラリ部分に関しては当初からそれなりにテストケースを作成していましたが、View 側に近づくにつれて不十分になっていくと言う実感がありました。また、旧 CubeICE では、ユーザ設定に応じて圧縮・解凍結果が正常に変化しているかどうかの確認を人力テストに依存している部分が残っていたため、これを自動化する必要性も感じていました。今回は、改修当初からアプリケーション部分のユニットテストも後回しにしないように注意しながら進めた結果、コマンドラインとユーザ設定を指定して圧縮・解凍処理を実行すると言う実アプリケーションとほぼ同様の流れをユニットテスト上で再現できる形まで持っていく事ができました(ArchiveTest.cs, ExtractTest.cs)。また、解凍処理で対応している圧縮形式に関しても、可能な限りサンプルファイル (Examples) を用意する事で、特定の圧縮形式の解凍処理にのみ発生する問題も早期に検知できる体制となってきました。

最後に、CI 環境の構築については、ごく少数で開発している事でローカル環境で十分と思っていた所もあり、ずっと後回しになっていました。しかし、1 年位前に AppVeyor と言う Windows アプリケーションの CI に特化したような Web サービスが存在する事を知り、github との連携で比較的簡単に導入できる事もあって基本的なライブラリ用プロジェクトから少しずつ導入を進めていました。そこで、今回、アプリケーションまで含めた導入プロジェクトの第一弾として CubeICE のプロジェクト全てを CI 環境上に構築する事を決めました。

CI 環境での都合により途中でリポジトリを 2 つに分割しましたが、Cube.FileSystem および Cube.FileSystem.SevenZip が C# の実装(≒ CubeICE のアプリケーション部分)、cube-soft/7z が 7-Zip のカスタマイズ部分となっています。共有ライブラリ部分を含めてまだ NuGet には公開していない事で AppVeyor の設定ファイルの記述に 1, 2 日悩みましたが、何とかテストを自動実行できる所まで構築できました。また、AppVeyor と同時にコード・カバレッジを可視化する Web サービスである Codecov とも連携しましたが、テストケースを記述していく上で当初の予想以上にここから得られる情報が役に立っていると実感しています。AppVeyor と Codecov を利用して実感した利点については、また別の機会にまとめたいと思います。

おわりに

CubeICE も最初の公開が 2011 年と言う事で、気付けばもう 6 年位もの間、多くのユーザに利用されている事になります。CubePDF 等でも同様の感想を抱く事が多いのですが、世に出たアプリケーションの寿命は、自分が開発を始めた頃(2010 年位)に漠然とイメージしていたよりもずっと長いものなのだなと改めて実感させられます。

圧縮・解凍と言う処理の観点から見ると、世の中全体としては文字コードUTF-8 に統一される方向にあり、いずれは文字コードが異なるせいで文字化けが発生するような状況もなくなっていくかもしれません。しかし、完全にそう言った時代がやってくるにはもうしばらく時間が必要で、後 10 年位は引き続き CubeICE のような機能も必要とされるのではないかと感じています。これから 10 年、様々な修正、改良を続けていく上で、今回少し時間をかけて構築したものが役に立ってくれる事を期待しています。

広告を非表示にする

一連の ALS Ice Bucket Challenge を眺めての雑感

少し前に ザッカーバーグCEO、氷水でびしょぬれに──ALSチャリティーで と言う記事を見かけた事を覚えていたのですが、今週に入ったあたりからこの ALS Ice Bucket Challenge と言うチャリティー運動が日本でもかなり盛り上がっているようです。せっかく盛り上がっている所でこんな事を言うのは、それこそ「氷水を浴びせる」行為かなとも思ったのですが、やっぱり気になったので個人的な意見を述べておきます。

概要

長くなりそうなので、先に概要だけ箇条書きにしておきます。

  • 今回のチャリティー運動全体に関しては、日本 ALS 協会も好意的な立場を取っている ようですので、今回指摘する以上の事をどうこう言うつもりはありません。
  • 私自身は、バトン(SNS バトン)と呼ばれるものも含めて「チェーンメール的な性質を帯びたもの」として全て否定的な立場を取っています。今回指摘する点も、これに関連したもので「意義や目的は別問題として、その伝播方法は支持できない」と言うものになります。
  • 今回、こう言った運動が広く認知された事により、似たような後追い事例が出現する可能性があります。その際には自ら、騒動の出所や該当する機関(今回の例で言うと、ALS 協会等)がどう言った態度を取っているのかをきちんと確認し、不明な場合には安易に騒動に乗らないようにして欲しいと願っています。

Ice Bucket Challenge とは

Ice Bucket Challenge とは、以下のようなルールを持つイベント全般を指すようです。

Within 24 hours of being challenged, participants are to video record themselves in continuous footage. First, they are to announce their acceptance of the challenge followed by pouring ice into a bucket of water. The bucket is then to be lifted overhead and poured over the participant's head. Then the participant can call out a challenge to other people.
In one version of the challenge, the participant is expected to donate $10 if they have poured the ice water over their head and donate $100 if they have not. In another version, dumping the ice water over the participant's head is done in lieu of any donation, which has led to some criticisms of the challenge being a form of slacktivism.

Ice Bucket Challenge - Wikipedia

Ice Bucket Challengeは、米マサチューセッツ州在住のALS患者、ピート・フレイツ氏が始めた、ソーシャルメディアを使ったチャリティーキャンペーン。指名を受けた人は、バケツの氷水を頭からかぶる動画を24時間以内にFacebookTwitterなどのSNSで公開し、次の人を指名するか、ALS Association(ALS協会)に100ドル寄付する――というルールだ。

「頭から氷水」動画、日本にも広がり 孫社長や山中教授も 難病患者支援のソーシャル運動 - ITmedia NEWS

今回は、2014 年 7 月中旬頃にある男性が Ice Bucket Challenge の寄付先として ALS Association を選択したのが発端となり、これまでにない大きな運動に発展したようです(参考:http://gqjapan.jp/more/andmore/20140820/ice_bucket_challenge_started)。

この運動で個人的に憂慮している点は「誰かから指名を受けると何かしらの行動を取り、その後、さらに別の誰かを指名する」と言う伝播方法が非常にチェーンメール的であると言う点です。

人々の善意の結果としてのチェーンメール

チェーンメール」あるいは「不幸の手紙」と呼ばれるものはインターネットが存在しない頃からある問題の一つですが、SNS と呼ばれる Web サービスが普及した頃からさらに多様な形を取るようになってきました。このチェーンメール問題ですが、各人の「善意」が積もり積もった結果として現れたと言う事例も少なくありません。

よく見かける例としては「特定の血液型の血液が不足しているので、献血をお願いする」と言うものでしょうか。これらのチェーンメールは、完全にデマなものから、事実も含まれているが伝播する過程において内容が改ざんされてしまったものまで様々な事例が存在するようです。

2000年5月下旬、「血液型がAB型Rhマイナスの妊婦が手術するので献血に協力してほしい」という善意から発信された電子メールが「チェーンメール」となって爆発的に広まり、献血の申し出や問い合わせが日本医科大多摩永山病院(東京都多摩市)に殺到した。

内容は事実ではあったのだが、改ざんされた内容で、メールが大量に出回ったりしたために、 妊婦が入院している病院に問い合わせが殺到、病院の診療に支障が出る騒ぎとなった。  

http://internetmuseum.org/museum/hoax/ab.html

昭和大学病院(東京・品川区)に入院している白血病の子どもに輸血が必要だ、という作り話の「チェーンメール」が携帯電話などに流されていることが分かった。メールは、知人の3歳の子どもが白血病で手術が受けられないため、RHマイナスB型の血液提供者はいないかを呼びかける内容になっている。現在は使われていない連絡先の携帯電話番号が記され、知人に回すように呼びかけている。メールは、2008年2月21日から出回っている模様で、同病院に100件以上の問い合わせが相次いでいるという。

昭和大病院入院の子どもへの輸血呼びかけるチェーンメール流れる : J-CASTニュース

こう言ったチェーンメールを転送する動機の多くは、自らの「善意」によるものであろうと推測されます。少しでも力になれれば……と思いチェーンメールに加担したが、結果として該当機関に想定外の処理(問い合わせへの対応等)が発生し、通常業務に支障を生む事に繋がったとして問題化する事例が数多く見られます。

今回の事例に関しては、日本 ALS 協会も好意的な見解を示しており、業務に大きな支障を与えたような事実は確認されていないようなので、この点はこれまでのチェーンメールの事例とは異なります。しかし、先に紹介したような問題については十分に注意しておく必要があるように感じます。

「ALSアイスバケツチャレンジ」は、ALS患者と患者団体を支援する募金イベントです。アメリカから始まり他の国を経て、先週末頃から日本で急激に広がっています。それにより、これまでALSを知らなかった人達から協会へ問合せやご寄付のお申し出を頂いており、心より感謝しております。頂いたご寄付は、ALS患者や家族が安心して療養が続けられる社会のために、大切に使わせて頂きます。

http://www.alsjapan.org/-article-705.html

「何となく拒否できない」雰囲気が醸成される危険性

別の問題点として、この類の「次に実行する相手を指名する」システムの場合、運動の意義・目的や盛り上がり具合によっては、何となく拒否しにくい雰囲気が醸成されて半ば強制的にイベントに付き合わせられる危険性が伴う点が挙げられます。

起業家の堀江貴文氏は自らのブログで、さほどこの運動に興味がないとしながらも、ソーシャルゲームを手掛けるドリコム創業者である内藤裕紀氏から指名を受けたため挑戦に応じると表明した。積極的な賛同がなくても人間関係によって、運動に加わっていく「バイラル」の力を暗示するものといえる。

ノーベル賞の山中教授も、ホリエモンも-- 「バケツで氷水かぶる」運動が日本でも急拡大 [インターネットコム]

この点は日本 ALS 協会も憂慮しているのか、「アイスバケツチャレンジ」で、冷たい氷水をかぶることや、高額の寄付をすることは強制ではありません。皆様のお気持ちだけで十分ですので、くれぐれも無理はしないようにお願いします。」と言う一文を明記しています。

今回の事例については、一部で好意的に評価されているように「次に実行する相手を指名する」と言うシステムではなく各人が自発的に参加すると言うものであれば、ここまで大きな社会現象になる事はなかっただろうと感じています。しかし、だからこそ、この伝搬性の高さが一歩間違うと「チェーンメール」と言う大きな社会問題として顕在化します。その意味で、今回の成功事例を以て、この手法(指名方式による伝播)を支持・評価する事はできないと言うのが私の現時点での立場です。

今回のような運動に参加する場合

今回のチャリティー運動が好意的に報道された事によって、今後、似たような後追い事例が発生する可能性があります。私自身としては、今回のような(意義や目的云々ではなく)指名性によって伝播していくシステムの場合には原則として無視する方が良いと考えていますが、もし、運動に参加しようと思った時には、運動の出所、および関係機関がどう言った態度を取っているのかを自らきちんと確認するようにして欲しいと願っています。

この際、注意すべき点として、過去の事例からも分かるように チェーンメールの真偽を確認するために関係機関に電話をかけたりメールを出したりする」と言う行為自体が通常業務の妨げになる可能性 があります。したがって、そう言った(チェーンメール的な)事象に遭遇した場合は、確認方法は Web ページ等の閲覧に留め、「関係機関が好意的な声明を発表していない限りは無視」と言う態度を取る必要があるのかなと感じます。

広告を非表示にする

魔法使いと黒猫のウィズで課金ガチャ騒動が起きているようです

気が付けば1ヶ月以上更新していませんでした。本当は別の記事で更新再開するはずだったんですが、まとまらないのでスマホゲームの話題。

クイズRPG魔法使いと黒猫のウィズ

ふとしたきっかけで 5 月初旬頃から「クイズ RPG 魔法使いと黒猫のウィズ」と言うスマホゲームを始めているのですが、このゲームの一部界隈で、ランダム型アイテム提供方式(所謂「ガチャ」)に関する騒動が起きているようです。

6 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2014/06/23(月) 23:20:15.43 ID:LnBoRh7N
SSパレード4640連ガチャ【割引間中約101万円】

B率…約64% A率…約31%
S率…約4 SS率…1%
SSパレード対象A&S…約2%

属性別の最多と最少(A率…約30%の属性別内約)
【火】ユアン…約8.7%  マナカ…約0.7%
【水】ルフレ…約7.9%  サクヤ…約0.9%
【雷】 レラ…約6.7%  ヒカリ…約0.7%

総数(2330回)での排出率ワースト
ぞんざい少女 リルム(SSパレード対象)…0.02%(1/4640)

SSパレード対象A&S排出率 総数(4640回)
ルミィ   …約0.34%
エイジ   …約0.28%
セレサ   …約0.28%
ヴァルザイン…約0.22%
リティカ  …約0.22%
リヴェータ …約0.17%
クルス   …約0.15%
リルム   …約0.15%
ルルベル  …約0.15%

4640連ガチャ集計結果

http://anago.2ch.net/test/read.cgi/applism/1403509926/

経緯を簡単に説明すると、ニコニコ生放送において「魔法使いと黒猫のウィズ」で提供されているガチャを 4,640 回(100万円以上かかる計算)も引いた人が出現したようで(参考:Twitter / amarone3847: 前のSSパレードを2日で4640連した結果纏めて頂きました)、これまでガチャに関連した様々な不満を抱きながら正確な確率を算出する方法がないために具体的なアクションを起こせなかった層が、絶好の検証データを得たと言う事で盛り上がっています(上記の表は、実際に引いた人とは別の有志の人が集計しているようです)。尚、ガチャを引いている様子は YouTube にも転載されています。

個人的にも、ガチャの確率に関しては投稿ユーザのバイアス(極端に良い結果、または極端に悪い結果ばかり投稿される傾向にある)が大きく、信頼性のあるデータを得る事はなかなか難しいと思っていたので、こう言った単一ユーザによる大量の連続した試行結果を得られるのは検証するに際して非常に貴重なデータであるように感じます。

課金アイテムの公平・公正感を保つために

これは「魔法使いと黒猫のウィズ」に限らないのですが、所謂「ガチャ」と呼ばれるものに対して、私が運営に是正して欲しいと感じるのは以下の 2 点です。

  • レアリティ毎に確率を表記して欲しい
  • 同じレアリティにも関わらず出現確率が違うと言った事はやめて欲しい

これらの内、特に気になっているのは後者となります。例えば、下記はガンホー社の運営する「ラグナロクオンライン」に関する個人的な指摘(文句)ですが、アイテムに対して何段階かのレアリティを明記しているのも関わらず、同レアリティの中でもさらに細かく出現確率を変えてしまうと、もはやレアリティの意味がないと言う問題があります。

上記は、ラグ缶2012 September と言う 2012 年 8 月頃に発売されたラグナロクオンラインの有料ガチャの当選アイテム一覧で、「A賞」から「E賞」まで分類されている事が分かります。一覧を見るだけでも「A賞の方になると当たりにくいんだな」と言う事は何となく想像が付くと思うのですが、この有料ガチャのトリッキーな特徴として、前述したページの注釈に「当選確率はA賞<B賞<C賞<D賞<E賞となっています。A賞が最も当選確率が低く、E賞が最も当選確率が高い設定となっています。また、アイテムにはそれぞれ当選確率が設定されているため、A賞・B賞・C賞・D賞・E賞それぞれの賞の中でもアイテムにより当選確率に若干の違いがあります」と書かれているように「同じカテゴリ(≒レアリティ)に属するアイテムでも当選確率が違う」と言う点が挙げられます。

当初から「じゃあ、その分類には何の意味があるの?」とは感じていたのですが、まぁそう言うものだと言う事で、この有料ガチャは現在も継続中です(参考:過去のラグくじ/ラグ缶アイテム一覧 -Roween-)。

ラグナロクオンラインの有料ガチャにおける「レア」とは何なのか? - Life like a clown

前述した「魔法使いと黒猫のウィズ」の 5000 回の試行結果を見ても、同じレアリティ(黒猫のウィズの場合、問題になるのはレアリティ「A」)にも関わらず出現確率が最大で 10 倍もの差がある事が分かります*1。「同じレアリティなら出現確率も同じ」の原則が適用されない場合、たとえレアリティ毎に出現確率が明記されるようになったとしても(同レアリティの中で好きなように微調整が可能なため)形骸化する可能性が非常に高いと言う危険性を孕みます。

もう少し具体的に見ていくと、「魔法使いと黒猫のウィズ」の事例でもっとも問題に感じるのは「A 精霊(パレード対象)」に分類されているアイテムの出現確率が、全体で見ても、軒並み最低レベルであると言う事かなと思います。「魔法使いと黒猫のウィズ」では、「ウィズセレクション SS パレード」と称して、定期的に「期間限定で出現するアイテム」を「ガチャ」の中に混ぜます。

SS パレード

これらの内、レアリティ最上位である「SS」アイテムの出現確率が極めて低いのはまだ納得できる(消費者の直感とも一致する)のですが、「レアリティ「A」の期間限定アイテムが、一つ上のレアリティであるはずの「S」よりも出現確率が低くなっている」のは個人的にかなり問題であるように感じます。レアリティ「A」(全体としては 30% 程度の出現確率)なら狙えるかもしれないとユーザを「錯覚」させ、「期間限定」と言う言葉でさらに射幸心を煽る形となっています。

ガイドラインは、一般社団法人 日本オンラインゲーム協会(以下、JOGA)加盟事業者が「オンラインゲーム安心安全宣言」に立脚したオンラインゲーム(インターネットに接続された端末機器、主にパソコンによってプレイするゲームをいう)の企画・開発および運営・運用を実施するにあたり、各種法令の遵守および消費者保護の観点から、利用者の皆様が安心して楽しめるゲームサービスを提供するために策定されたものである。

ランダム型アイテム提供方式における表示および運営ガイドライン(PDF)

上記は、日本オンラインゲーム協会 の運営ガイドラインの一文です。「魔法使いと黒猫のウィズ」の運営会社である株式会社コロプラは日本オンラインゲーム協会にも ソーシャルゲーム協会 にも参加していないようなので、こう言ったガイドラインを直接適用できる訳ではありませんが、「各種法令の遵守および消費者保護の観点から、利用者の皆様が安心して楽しめるゲームサービスを提供する」ために、公正さに関してもさらに議論していって欲しいと願っています。

*1:当初は「実装不備による偏り」と言う可能性も考えていましたが、出現確率の低いアイテムが 2 ちゃんねる等で「出にくい」と言われるアイテムと比較的一致しているため、現時点では、出現確率自体を変えているのだろうと推測しています。

広告を非表示にする

PR?Twitter スパム?

SoGap の今日の更新 を見てみると、FIAT | スペシャルオファー と言う記事がトップになっていました。タイトルからしてちょっと気になったので、この記事への Twitter の呟き一覧を見てみると以下のような状態になっていました。

Twitter スパム?

SoGap でのデータ取得時点で上記記事へのリツイート数は 3,000 件を超えているのですが、そのほとんどは似たのような呟きで占められていました。ちなみに、該当記事のはてなブックマークエントリ の最初の 3 ブックマークも同様のコメントで埋まっています。

はてなブックマークコメント

凄くスパム臭がするなぁと言う現象なのですが、わざわざ「PR」と付けている辺り、呟かれているドメイン自体が白か黒かはよく分からない感じです。コメントにちらほらと「Ads by Trend Match」と言う文字列が見えるので、Trend Match と言うサービス(アフィリエイトプログラム)を利用しているユーザがスパムだらけと言う話なのかもしれません。

何か、上記の記事への呟き一覧が Twitter スパム BOT リストとして使えそうだなぁと言う感想を抱きました。

広告を非表示にする

技術書の読み方として勘違いしていた、たった一つの事

http://d.hatena.ne.jp/higepon/20090129/1233212684 を見ながら、ふと、思い出したのでメモ。タイトルは、前述記事にならってつけてみました……本題の個人的に勘違いしていた事なのですが、それは、「技術書も小説のように、最初から最後まで、順番に読み進めていくもの」と思っていた事でした。

まずは第1章から第4章までを、じっくりと読まれることをお勧めします。次にカタログ部分をざっと読むようにします。最初はどこに何が書かれているかを大体知っていれば十分です。詳細について把握する必要はありません。実際にリファクタリングを行う必要が生じたときに、あらためて読む方が有効です。カタログは参照用の書き方なので、一度に読むのは大変だからです。

リファクタリング―プログラムの体質改善テクニック(p.xviii)

私自身は、かつては「読書と言えば小説を読む事」と言う意識で育った人と言う事もあってか、はじめに技術書を読み始めた時は、技術書の 1 ページ目から最後まで(頑張って理解しようとしながら)通して読む事をやろうとしていました。しかし、この方法だと、途中で自分の理解力が追い付かなくなる等でやる気を失い、結局、宝の持ち腐れ(積読本)が頻発する事となりました。

この状態から一歩前進できたのは、自分である程度まとまったプログラムを書くようになり、それに伴って問題にぶつかる頻度も増えてきた頃でした。自分で実際に問題にぶち当たってから技術書を読み直してみると、「何故、そう言う事をやろうとしているのか」と言う動機部分が肌で実感できるようになり、以前よりもそこに書いている内容がスムーズに理解できるようになったのです。この習慣が身に付いたきっかけの一つとして、その頃によくC++ライブラリクイックリファレンスと言う辞書的な技術書を(辞書を引く感覚で)読んでいた事も影響したのかなと思います。

モノにもよりますが、1 冊の技術書に記載されている内容と言うのはかなり膨大で、よほど該当分野に精通している状態でなければ初見で理解できる内容はたかが知れているのだろうと思います。それにも関わらず「通し読みで全部理解してやるぜ!」的な情熱で挑むと、大抵、その鼻をへし折られる結果となります。

また、技術書に書かれている内容は多くの場合いくつかのサブテーマが設定されており、途中の内容をすっ飛ばして読んでも該当部分を理解するのに大きな支障はないような構造になっています。したがって、上記にもあるように、初見時は導入的な章を読んだら後は各サブテーマの概要(最悪、タイトルだけでも良いか)だけを覚えて(脳内インデックス化)、詳細な内容の把握・理解は実際に問題にぶち当たってからに先延ばしするのが、結果として効率良く技術書を読み進めていけるのかなと現時点では感じています。

……と言う事を書こうかと思ったら、2 年前にほぼ同じ事を書いていました。引用している部分まで完全一致していたのは、我ながら少し驚きました。

広告を非表示にする