Top > 読み物 > 日記 > 2010年7月 -1冊目-
- 1日
- 2日
- 3日
- 4日
- 5日
- 6日
- 7日
- 8日
- 9日
- 10日
- 11日
- 12日
- 13日
- 14日
- 15日
- 16日
- 17日
- 18日
- 19日
- 20日
- 21日
- 22日
- 23日
- 24日
- 25日
- 26日
- 27日
- 28日
- 29日
- 30日
- 31日
2010年7月1日 （木曜日）
手違い
ホテルの予約に失敗
何度かコミケに参加してきて、ホテルの予約に失敗したのは今回が初めてだと思います。というのも、いつも6月半ば（当落が決まったその日）に予約を入れるのですが、今回はそれを見送ってしまい、今日になって予約を入れることに。結果的にいつもより三週間ほど遅めの予約になったのですが、いつも使っているホテルで3連泊を取ることができませんでした。普段なら土曜日が真っ先に満室になることが多いのですが、今回は日曜日が満室で、金曜日、土曜日はけっこう空いていたので、月曜日がお盆最終日であることが原因と考えられます。または、月曜日に何かイベントがあるのかもしれませんね。
最終的に、いつも利用しているホテルを2軒はしごする形で予約を取ることになりました。
2010年7月4日 （日曜日）
手違い2
ゆうぱっくの配送遅れ
私の記憶が正しければ、7月1日というのは荷物の繁盛期のひとつだったかと思います。7月1日といえば、お中元の解禁日。この日にあわせて受注件数は増え、6月30日～7月1日はお中元におけるひとつのピークといえるでしょう。取扱量が増えるとわかっている日にわざわざ統合するというのは、現場のことを知らない上層部が勝手に決めたことのように感じてしまいます。上層部が7月1日に荷物が増えることを知っていれば、混乱が発生することを予期できるでしょうし、そうなるとこの日に統合をするというのは常識的な発想では出てこないはずです。
また、経営的な視点に立てば決算期である10月にあわせて統廃合を実施することが考えられます。ということは、お中元も一段落し、クリスマス商戦や年末商戦を回避することができる9月に統合するのが常識的な判断だったと言えるでしょう。
各種ニュースを見てみると、原因として局側が「職員の不慣れ」や「（統合による）取り扱い荷物量の増加」などをあげていますが、最終的には「繁盛期に統合を行うことを決定した上層部のミス」が原因なのでは、と思います。
これだから（元）公務員は（以下自主規制）。
2010年7月6日 （火曜日）
原稿進行中
夏コミ新刊、制作日記
| 作業項目 | 進捗率 | 前回比 | |
|---|---|---|---|
| 本編 | 第一章 |  100% |
+100% |
| 第二章 | 0% | ||
| 第三章 | 5% |
+5% | |
| 第四章 | 0% | ||
| 第五章 | 0% | ||
| 第六章 | 0% | ||
| お化粧 | 0% | ||
| 修正パッチ | 0% | ||
| 装幀 | デザイン | 0% | |
| 具現化 | |||
毎年恒例進捗率グラフ、かもーん。
原稿を書きつつ、紙の在庫を確認していかないと行けないですね。
2010年7月8日 （木曜日）
改変の時
foobar2000 0.8.x → foobar2000 1.0.x
0.8から0.9へのマイナーバージョンアップをするだけで、導入しているプラグインに互換性がないというその開発方針にうんざりして0.8で止めていましたが、0.9以降はcueシートの取り扱い方が良くなっているようで、cueシートをよく使う私としては結構興味があったので、勢い余って移動しました。
数分後、私のデスクトップには初期画面で立ち上がるfoobar2000 1.0.xの姿が！
インストール場所を分離したのにもかかわらず、1.0.xが0.8の設定を全て上書きして、0.8の設定も初期設定に戻る当たり、開発方針に（以下自主規制）。
さて、当然のごとく、再生中の曲をサーバーに送信してこのウェブサイトを表示した時に下に組み込むプラグインも動作しなくなったわけで、代替え機能を暫定的に使ってみています。JavaScriptによる挿入を行っていますが、面倒なのでNoScriptタグは使っていません。
2010年7月9日 （金曜日）
私女だけど、黒髪ロングに白いワンピースを妄想するオタっていい加減現実を見なさいって思うのよね。
おっと、妄想の中に入り込んでくるのは内政干渉っていうので、出て行って下さい。
新刊に登場する場面なのですが、ワンピースの部分を描写したかったので、書き換えに挑んでみました。
変更前
リビングのテレビの中では、最近流行っているという芸人がコントで観客の笑いを誘っていた。そんな様子を見ながら、テレビの前にあるソファーに缶を置―――こうとしたとき、絨毯の上に丸まって寝ている砂沙美の姿が目に入ってきた。真っ白な、下着ともネグリジェともとれる薄手のワンピースに身を包んだ砂沙美は、まさにすやすやと寝息を立てていた。
「おまえも好きだなあ。」
変更後
リビングのテレビの中では、最近流行っているという芸人がコントで観客の笑いを誘っていた。そんな様子を見ながら、テレビの前にあるソファーに缶を置―――こうとしたとき、絨毯の上に丸まって寝ている砂沙美の姿が目に入ってきた。まさにすやすやと寝息を立てる砂沙美は、下着ともネグリジェともとれる薄手の白いワンピースに身を包んでいる。（ここに描写を挿入）
「おまえも好きだなあ。」
最初の文章では描写を挟む場所がなかったので、文章の順番を入れ替えて、描写を挿入できるようにしてみました。さあ、思いの丈をぶちまけよう。
2010年7月10日 （土曜日）
改変の時、その2
SeaMonkey → firefox
ネスケユザーだった私は、ネスケが頓挫した後、それを引き継いだSeaMonkey1.0にそのまま移行したのですが、そのときには既にFirefoxが存在していました。サブブラウザとしてFirefoxも導入しましたが、メインはSeaMonkeyのままでした。
しかし、SeaMonkeyがメジャーバージョンアップにより2.0となった時、それはFirefox3.0のコードを大幅に流用したものであり、SeaMonkey1.0における独自機能はほとんど引き継がれませんでした。それはつまりSeaMonkeyでやれることはFirefoxでもできるという状態に他なりません。現状におけるSeamonkeyの優位性で真っ先に思い浮かぶのは、OS起動時に本体を読み込んでおくことによって、ブラウザの起動が高速化するという物でしたが、それはSeamonkeyがブラウザスイート（もはや死語ですよね。メールの送受信がブラウザ主体となった今、ある意味ではブラウザがメーラーの役目を果たしていると言えますが）からであるがゆえの重さを改善するための機能であり、ブラウザの機能しか持っていないFirefoxはそのような機能を使わずとも、そこそこ高速に起動します（これを解決するためのプラグインもある）。
そこで、foobar2000も移行したので、ブラウザもFirefoxに移行することにしました。クッキーやブックマークは引きつぎ終わりましたが、パスワード関連は引き継がれていないので、これを随時引き継いでいくためにしばらくSeamonkeyは残すことになりそうです。いずれにせよ、さようならSeaMonkey、ですね。
とりあえず、スキンはフォックス子にしておいた。
夏コミ新刊、制作日記 （28:57）
| 作業項目 | 進捗率 | 前回比 | |
|---|---|---|---|
| 本編 | 第一章 | 100% |
- |
| 第二章 | 0% | ||
| 第三章 | 15% |
+10% | |
| 第四章 | 0% | ||
| 第五章 | 0% | ||
| 第六章 | 0% | ||
| お化粧 | 0% | ||
| 修正パッチ | 0% | ||
| 装幀 | デザイン | 0% | |
| 具現化 | |||
ワンピースの描写が終わったよ！
2010年7月11日 （日曜日）
改変の時、その3
FFFTP → FileZilla
長年愛用してきたFFFTPのインターフェイスから離れるのは難しいと思っていますが、以前使ったこともありますし、それなりにカスタマイズをすることで結構似たようなインターフェイスにできたので、FFFTPからFileZillaにFTPクライアントを移行しました。
やはりパスワードだだ漏れのFTP通信ではGumblar攻撃に対して非常にもろいですし、さくらサーバーがSFTPに対応したと言うこともあり、これを機に完全移行しました。設定もほぼ完了し、空の彼方へ、希望風、そして友人が展開するFTP鯖へのアクセスも可能な状態に。
FFFTPの作者はGumblar攻撃をFFFTPで防げないことは認知しているようですが、開発に時間を割りさけないようでその対応は見送るようですし、こうなったら私が移動するしか無いのです。
FFFTPといえばプロバイダーやレンタルサーバーで、設定方法のページが必ずといってもうけられるほど有名なソフトですが、それ故にSFTPに対応していない（＝Gumblar攻撃を防げない）ことが仇となったと言えるでしょう。無料のソフトですが、その完成度があまりにも高く、普及率も高かったがための悲劇でしょうね。
文面の流れからいって、FFFTPがGumblar攻撃を助長しているかの表現ですが、それは勘違いです。SFTPに対応していないサーバーやクライアントなんてごまんとありますし、そもそもユーザーがAdobeのソフトをちゃんとアップデートしていればここまで被害は広がらなかったはずです。
2010年7月14日 （水曜日）
タイトル未決定
夏コミ新刊、制作日記 （26:50）
| 作業項目 | 進捗率 | 前回比 | |
|---|---|---|---|
| 本編 | 第一章 | 100% |
- |
| 第二章 | 0% | ||
| 第三章 | 50% |
+35% | |
| 第四章 | 0% | ||
| 第五章 | 0% | ||
| 第六章 | 0% | ||
| お化粧 | 0% | ||
| 修正パッチ | 0% | ||
| 装幀 | デザイン | 0% | |
| 具現化 | |||
第三章は以前からやりたくてもやっていなかったある手法を使って書いてみようと思っている章です。この章は半分を書き上げてからが大変なので、これから数日はちょっと難航するでしょうけど、ノートに書き留めた文章配分が正しければ、うまく仕上がるはずです。
もっとも、このような手法が一太郎で再現できるかどうかは試していませんけどね！
いざとなったらフォトショで画像にしてPNGで埋め込むしかないでしょう。
そう言えば、先日カレンダーを見て気づいたのですが、今週末から来週の月曜日まで三連休なんですね。それまでには三章を終わらせて他の章に取りかかりたいですね。
冊子としての情報を公開できる段階ではありませんが、当初の予定では50ページ前後の作品になると予想しています。
2010年7月22日 （木曜日）
タイトル未決定
夏コミ新刊、制作日記 （6:43）
| 作業項目 | 進捗率 | 前回比 | |
|---|---|---|---|
| 本編 | 第一章 | 100% |
- |
| 第二章 | 0% | ||
| 第三章 | 100% |
+50% | |
| 第四章 | 0% | ||
| 第五章 | 0% | ||
| 第六章 | 0% | ||
| お化粧 | 0% | ||
| 修正パッチ | 0% | ||
| 装幀 | デザイン | 0% | |
| 具現化 | |||
第三章、超難産でした。
黒髪本はノート先行型で、ノートに書いてある記述を文章に起こす作業が中心なので、割ときびきびと原稿が進むのですが、第三章後半は予想していたとおり難産でした。制約が多い章なのでその制約の枠の中に納める作業が、作品を書き上げる作業よりも重労働でした。
次はこの作品の中心をなす第四章当たりを加工かと思います。
来月の第一週最終日当たりにはページ数を含めた概要を公開できると思います。
2010年7月25日 （日曜日）
タイトル未決定
夏コミ新刊、制作日記 （14:27）
ふと手を止めて画面右側に表示されているプロジェクトリストを見る。ここまで書き上げた作品と、まだ執筆途中のテキストファイルが羅列されている。執筆用ソフトは純粋なテキストエディッタではない。だからこそ外部プログラムにコマンドラインを渡して立ち上げることもできる。早速その機能を使って文字数をカウントしてみる。オプションスイッチ〈"%f" /h /t /z〉を受け取ったカウントプログラムは即時にそのファイルの文字数を、括弧や読点、句読点を除いた数字で教えてくれる。表示される文字数から私は悟った。
「あれ？ 予定より多くない？」
元々は40ページほどの作品になる予定だった。しかしそこに表示された文字数は既に20ページを超える量に相当する数字だったのだ。
といった具合で予想よりふくらんでおります。
このまま全て書き上げてボリュームをアップするか、プロットの段階でボリュームが足りないと思い後から付け足した作品を削って冊子全体としての完成度を高めるか、選択を迫られています。
しかし、第6版のCSSはすばらしいね（自画自賛）。本文中に小説を書いても違和感のない表示にほれぼれしそうです。
2010年7月26日 （月曜日）
タイトル未決定
夏コミ新刊、制作日記 （27:42）
| 作業項目 | 進捗率 | 前回比 | |
|---|---|---|---|
| 本編 | 第一章 | 100% |
- |
| 第二章 | 40% |
+40% | |
| 第三章 | 100% |
- | |
| 第四章 | 0% | ||
| 第五章 | 0% | ||
| 第六章 | 0% | ||
| お化粧 | 0% | ||
| 修正パッチ | 0% | ||
| 装幀 | デザイン | 0% | |
| 具現化 | |||
第二章邁進中。このペースだと水曜日には書き上がりそうです。加速させて火曜日には書き上げたいけどどうなるかな…。
黒髪本は、表では「章」という記載方法になっていますが、形式的には短編集です。作品毎に結びつきは一切ありません。ちなみに、構想ができた時から脳内では「一人黒髪アンソロジー ～ずっと作者のターン～」と呼んでいます。
現状における最大の問題点は、タイトルが全くうかばないのでこの文言がそのままタイトルになってしまう可能性が少なからずあるということです。どうしよう…。
当初の予定では一作品当たり8ページ編成で、全48ページと割と軽めの作品を目指していたのですが、昨日の日記の通りちょっとふくらむことになりそうです。第三章が予想の倍になるなんて誰が予想したことか…。
ソフトウェア統合計画
まだ少し先の話になりますが、秋口からのReSin-ens第三巻執筆開始に伴い、使っているソフトウェアの編成を変更しようかなと考えています。今現在、ReSin-ensのアイディアは全てTreeDocProというソフトで管理しているのですが、このソフトの開発が終了して早2年。作者のサイトも消滅し、未来のないソフトです。
一方で、普段執筆に使っているGinnie（WHiNNYの後継ソフト）が結構順調に更新を重ねており、安定してきたと言っても過言ではありません。WHiNNY同様のプロジェクト管理機能も備わっている上に、メモ帳の延長線上にあるTreeDocProと違い、エディッタの延長線上にあるこのソフトはエディッタとしての機能を備えていると言えます。
ReSin-ensは第二巻まで、アイディアをまとめるTreeDocPro、実際の執筆にWHiNNYと使い分けていました。しかし、その後WHiNNYの開発が終了し、Ginnieへ移行していきました。黒髪本はアイディアをまとめるところから執筆までGinnieを使った最初の作品です。そしてその執筆過程において、従来のTreeDocProとWHiNNY、TreeDocProとGinnieといった組み合わせに劣らない、むしろ行間設定や色の設定が不可能に近いTreeDocProよりも良好な環境を構築できる事に気づきました。
TreeDocProは非常に軽快に動作する（テキストファイルを表示するだけのソフトといっても過言ではない）という利点がありますが、デメリットも多いソフトでした。作業環境の整理整頓ということも含め、今後はGinnieに一本化していこうかと思います。
ただ、この手の一本化をフリーウェアで行うという事についてのデメリットももちろん存在するのですが…。（有料のソフトはサポートなどで新しいソフトへ移行できるツールが配られたりするが、フリーウェアにはそう言った手段が無いに等しいなど）
