布団が俺を呼んでいる

丘山大一のぶろぐ

Hololens

遅ればせながらご報告。
MSストアから、Hololens 届きました!
本業でトラブルが続いていたのでいまだに全然弄れていませんけど!


外観について


絶対他でも(多分)言われていると思うのですが、入れ物はまごうことなき「湯たんぽ」




電源

充電はUSB経由。
結構電力いるだろう、と思っていたからUSB経由はちょっと意外。
USBをつなげっぱなしにして装着すれば攻殻機動隊ぽく見える……いや見えないなw


実際につけてみる

わかってはいましたがちょっと重い。


初期設定

Hololens には付属の説明書がついており、そこには日本語の記載もあります。
なんだ、前情報だとサポートは英語だけって言ってたけど、日本語もあるじゃん。
これなら楽勝だね!

と、見事に騙されました

電源ポチーの後の設定、英語音声ONLYじゃないですかー!
英語聞かないと次に何やるのかも分からないじゃないですかー!

Hololensでは音声操作もサポートしています。とありますが、どっちかというと必須の模様。
「音声認識もできる」というより、「音声操作しないといけない」という手順もあります。
初期設定中、次の設定項目に進む時は「NEXT」と「言わなければ」なりません。

一人暮らしへの部屋。
夜中にヘッドセット被って。
「ねくすと」「ねくしゅと」「ねきゅすと」
とつぶやき続ける私。

……メッチャ怪しいですね!



というわけで、雑なHololens 紹介でした!
詳細は他の方々からどうぞ!(投げっぱなし)

購入はコチラから。

Twitter に登録しようとした

ワタクシは全然SNSというものを使いません。
ですが、この度ちょっと事情がありまして、Tiwtter アカウントをとろうと思いました。


そして登録して10分ほどで






まだアカウント登録しかしてないのに違反扱いされたでござる。
冤罪でござる! 殿、冤罪でござるぞ!


調べてみると

結構引っかかる人が多いみたいですね。
推測するに、アカウントがスパム扱いされたかな?
丘山大一で活動している時はoutlookアドレスだからスパム扱いされやすいだよね……。
そして丘山大一としての電話番号なんぞないので、自力解決不可能w


しゃーないので

サポートに連絡してみます。


しかし



電話番号がないから電話番号で解除できないよ、と送ったのにも関わらず、電話番号でやれと。
まあこのメール自体、自動返信なんでしょうね。
自動化対策を自動でやるのは合理的といわざるをえない。

まあもう面倒なのでTwitterは諦めますw


続々・初めてコミケ用同人誌を作った話

原稿の管理

原稿自体は、Github上にでがらし会のPrivateリポジトリを作成することで管理することが決まっていました。
Github で管理するのはいいのですが、ここで地味にネックになるのが、マークダウンで原稿が作成される、ということです。
※もちろん、別の形式で原稿を作っても良かったのだが、Github上ならマークダウンが便利だと判断。


マークダウンは印刷のための形式ではない

当たり前ですが、マークダウンはHTMLを簡易に書くことに重点がおかれています。
出てくるものは解釈されたHTMLであって、その解釈はブラウザやライブラリに依存します。特にTableなんかは顕著です。
また、Github上に置くだけでは連結することも、(当たり前ですが)頁番号を振ることもできません。
よって、「印刷用の何がしかの形式にするためのライブラリが必要」ですが、「成果物はそのライブラリに依存する」します。
でもって、書く人ごとに使っているライブラリ・環境は異なるわけです。
合同誌なのに、書いているのはマークダウン(=テキスト)なのに、人によって結果が異なる。ツライ。


ライブラリの選定ーGitbook

あれこれ悩みましたが、最終的にGitbookを使用することにしました。
※正確にはWindows+Git for Windows+Gitbook+calibre
決め手は、
  • PDFへの変換ができる
  • PDF化した時の結果が、マークダウン+Github(ブラウザ) で表示した結果に近い(個人ごとの差が小さいことを期待)
  • PDF化の結果が印刷に向いている(特に改ページ)
  • 現在のリポジトリの構造でそのまま動く
という点です。ブラウザによる差異は取り除けないので、ここは諦めたところです。
他にも幾つか候補がありましたが、単純な使い勝手でGitbookを上回るものがありませんでした。
しかし、この選定に時間がかかりすぎてしまいました。
ライブラリの選定に時間がかかる=出力結果が不定なまま=ページ数も未定 ということです。
そのうえ、ライブラリと格闘している間に――編集としてあるまじきことに――皆の原稿進行具合の監視が半端になっていました。
結果、当初40頁くらいの予定が、出力してみたら120頁にふくれあがるという事態にw
いくらなんでも120頁は多すぎ! ということで、皆に協力を仰ぎ、最終的に80頁にしました。
いやあ、完全に編集担当の不手際でした(汗)
みんなありがとう!


製本について
色々悩んだのですG、STARBOOKSさんにお願いしました。
ポイントは、
  • 実績がある
  • PDF受付が明示されていた
  • 一部の頁のみカラー に対応していた
  • 比較的安い
  • 会場に搬入してくれる
という点でした。
担当のお姉さんの声が可愛かったのが最大のポイントだったなんていえない。ちなみに会場にいらしていたそうですが、その人も可愛かったそうな。お会いできていないぞチクショウ。
特に、上記事情によりPDFで入稿しなければならなかったため、PDF受付ができることが確定で分かっていたのが非常に大きかったです。

また、仮入稿もできましたので、一度製作途中のものを入稿し、印刷に問題がないかどうか軽くチェックしてもらうことができました。
印刷所に依頼するのは初めてでしたので、コレができたのは安心感の意味で非常に大きいかったです。

いやはや、お世話になりました。


さて、3回にわたって長々と書きました。

正直、理想通りにはいかなかったところが多いですが、処女作&初編集にしては「そこそこ」できたかなあ、という感想です。
通してのご注意ですが、今回はあくまで「初めて」「合同誌の編集という立場で」「丘山としての考え」を書いたものです。
何かの参考になれば幸いですが、「正解」を提示したわけではありません。特に、「文章の完成度を高める」の件は、どちらかといえば小説等で有効な手法です。技術書を書くのであれば、あるいはそうでなくても、異論が出るところだと考えています。
そしてこの「異論が出る」ところがキモだと思います。
一人でやってても異論なんて出ませんからね。折角の合同誌ですから、黙々とやるよりも、意見をぶつけあってワイワイガヤガヤやりたいです。

諸々反省点もあります。数多の失敗もありますw
2回目以降の機会があれば、また違ったやり方をしたり、今回のやり方を洗練する形にでやっていきます。
しかし編集面倒くせえ編集は編集で面白いよ!



伊勢藤 同人誌ケース ブラック

新品価格
¥700から
(2017/1/14 21:16時点)

続・初めてコミケ用同人誌を作った話

前回の続きです。

文章の完成度を高める

完成度を高める=推敲の作業です。
いくつかのアプローチがあります。

その1:著者による推敲
最も基本的なものです。
最初から最後まで通して行われます。

その2:著者同士による推敲
余裕ができれば、著者同士による推敲も行います。
ただし著者同士の推敲は(お互いに遠慮するのもあって)さほど大きな変更をもたらしません。

その3:編集によるチェック
「一冊の本」としてまとめる都合上、用語を統一したり、権利上問題がある表現や素材を使用していないか確認します。
編集は文章それ自体よりも、枝葉を気にしたものをチェックします。

その4:読者によるチェック
最重要。
「そこそこ完成した文章」を「読んで」「見て」もらいます。
ここでいう「そこそこ完成した文章」とは、内容が最初から最後まで完結しているものを指します。
書きかけが無い、状態ということです(加筆する分にはよい)。
不思議なものなのですが、どんなにヒドイものでも、ヒドイ状態からちょっとずつ成長している姿を見ていると、最終的にボロボロであっても「最初に比べればだいぶよくなったよね」という結論に至りやすいです。
スパゲティコードをリファクタリングしていると、途中で多少クソコードが残ってしまっても「最初に比べればよくなったよね」という結論になりがちなのを想像していただければと思います。次にそのソースを見る人にとっては、やはりクソはクソなんですけどね。

あとは、読者に「同じ印刷物」を渡して読んでもらうことです。
(重要なのは「同じものを見てもらう」ことです。ちなみに、この方針はでがらし会では非常に強い反発を受けました。)
同じものを渡す理由は、同じものを見たときの感想、指摘事項を集めるためです。
違うものを渡しても違う感想が出てきてしまうのは当たり前なので、意味がないからです。
違うものを読んでいる場合は、(編集の中では)意図して「別物を読んだ」感想として取り扱うようにします。

また、一定周期で印刷しできる限り参加してもらい、なるべく複数回チェックしてもらうように……するつもりでしたが、スケジュール上無理でした。orz
編集の大敗北。

読者によるチェックでは、誤字・脱字等の枝葉より、「面白かった」「つまらない」「色がない」「読みづらい」「読みやすい」「ここの意味が分からない」「興味ない」等の感想が欲しいところです。また、できれば赤ペンなどで紙に書き込んでもらいましょう。
さらに期待されるのは、赤ペンによる読者同士の論争があればなおよしです。
論争がある=色々な読み方がある、色々な意見がある ということだからです。
そして、読者同士の論争をもたらすということは、それは
人に考えさせるよい文章か、
結論を出せていないダメな文章か、
どちらかになっている可能性があります。
それが著者に伝わればベストです。


何を読むか

著者、編集は書きかけのテキストでもなんでもOKです。
ただし、読者側が、そういった中間成果物を読むのはなるべく避けます。
最終的に、紙媒体としての同人誌になるならば、同サイズの紙に印刷したものを読みます。
最終的に、PDFとして出力するならば、PDFで読みます。

大切なのは、「最後にどうやって公開するか」に則ったものを読むことです。
時折、「最後は紙だけど、推敲中は画面で見るからいい」という人もいますが、それは大いなる間違いです。
開発現場の世界に例えるなら、受け入れテストするのに、デバッグで使っていたexeでテストしているようなものだからです。
同じものは作れなくても、「最終成果物と極力近いもの」をでテストすることが重要です。

Q:そうはいっても、画面に出ているものを印刷するのだから同じでは?
A:ぶっぶー

画面で出ているものと紙とでは、大きく異なります。
  • 文字サイズが、画面では拡大できるが紙ではできない = 読みやすさが異なる
  • 画数の多い文字が、印刷したらつぶれてしまって読めない = 印刷の精度の問題
  • 紙では常に見開きだが、画面ではそうとは限らない = 一度に目に入る情報量が違う
  • 紙では片面に画像、もう片面に文字という構成がとれるが、画面ではそうとは限らない = 一度に目に入る情報量が違う
  • 片面に画像、もう片面に文字となるはずが、印刷したら頁の都合上、めくった次の頁に分割されてしまった = 構成の問題
主にこれらが問題となります。
逆に、最終的に電子化するならば、なるだけ画面で見るべきです。


修正の要否の最終判断は「作家に任せる」

商業ではないので、編集の権限はそこまで強くありません。
ここまで、推敲の話をしてきましたが、修正するかどうかは各著者にお任せします。


お金の話をなるべくする

ここらでちょっと毛色の違った話をば。
何をやるにしてもそうなのですが、合同で実施する場合、お金は確実に揉めます。
同人誌についても、「利益を出すのが目標」「トントンになればいいや」「同人誌は赤字で当たり前」は人によって意見が分かれます。
同人誌で利益が出ると色々面倒なのですが、それでも「売る、ということは利益を出すこと」と考える人もいるわけです。
この辺りの意見は、各人バラバラでもいいのですが、「合同でやる時の方針」は早めに固めておく必要があります。
よって、折を見て費用、利益、各人の負担額を提示し、意思の統一を図っておきます。

次回に続く!


伊勢藤 同人誌ケース ブラック

新品価格
¥700から
(2017/1/14 21:16時点)

Windows Phone (Windows Mobile) Windows Update 後の再起動ににかかる時間(10.0.14393.693)

Updateのことを完全に忘れていたので同人誌の話はまた今度。

今回はこんな感じ

アップデートファイルのダウンロードや更新自体は済。再起動にかかる時間だけです。
合計15分で更新が完了しました(歯車云々の時間は省略)。
またいつもの時間です。
コレ、いつも15分で終わるように設計されているわけじゃない……ですよね?

状況によって時間は大きく前後すると予想されますので、目安の一つとして。


バージョン

端末はNuAns Neoです。
本日時点の各バージョンは、
バージョン:1607
OSビルド:10.0.14393.693
ファームウェアリビジョン番号:1028.020.001.92
ハードウェアリビジョン番号:1.0
無線ハードウェアバージョン:1.0
チップSOCバージョン:8952

更新情報

一応掲載。

最近、Windows Mobile の動きがないけど大丈夫かしら。


20170113 追記

いきなり再起動がかかりました。
調べてませんが、なんだったろう?
バージョンなんかは変わってないみたいです。

初めてコミケ用同人誌を作った話

昨年のC91用に、「でがらし会」として作成しました。
今回は編集としてのお話や考えを書いていきます。

経緯

「でがらし会」の代表が「技術書の同人誌作りたい」と突然言い始めたことが発端です。
私は文章を(好き勝手に)書くのが好きです。大学時代もちょいちょい仲間と冊子を作っていました。
なので、話を聞いたときも、いいんじゃないかな、と(書き手として)思っていました。
しかし技術書って書いたことないなー、何を書けばいいんだろうなー、とボンヤリ考えていた時、でがらし会代表である凡人のお言葉がありました。

代表:「編集をやって」
私:「え、やだ」

それ絶対面倒やんけ、と思い速攻で断った記憶がありますが、他に立候補者がでなかったので編集とあいなりました。


編集担当

さて、編集の最初の仕事は、「そもそも編集って何やるのさ」という自己定義です。
私の経験の中では、合同で本を作る際は
  • 代表者(発起人。この人の名前で出す。最終決定権保持者)
  • 会計(お金をとりしきる)
  • 編集長(本の設計、監督)
  • 編集担当(ページ調整や挿絵管理)
  • 印刷担当(印刷管理、コピーを大量にとる場合は力仕事もあり)
  • 読者(本の作成には直接参加しないが、文章を読んで意見を言う人)
等の役割・仕事があります。
ホンマモンの出版社ではないので、実際にはこれらを兼任しながら進めますが、注意点として、原稿を書く人は原稿を書くことのみに注力し、上記の役割・仕事には原稿が完成するまではなるべく関わらない/関わらせないようにします。
理由は幾つかありますが、重要なのは「作業を手伝っていたら原稿が完成しなかった」という事態を避けるためです。
わりとシャレにならないので。

ちょっと話はズレましたが、今回は「会計」「編集長」「編集担当」「印刷担当」を受け持とう、と決めました。
残った代表者は「凡人」。
読者は、「同人誌作成に直接参加していない勉強会のメンバ」を半強制的に巻き込むことにしました。
ただし、会計、つまりお金は揉め事の原因となります。特に一人でコレをやってしまうと透明性に欠け、後々に禍根を残しかねません。
よって、費用としてあつかうものについては、代表を確実に通すことにしました(権限の一部を放棄)。
どちらかといえば、
  • 「決定権が強い代表が暴走するのを防ぐために、お金についての決定権は会計が持つ」
  • 「会計は主と副の両方を置く。二人置いて監視できるようにする」
  • 「主は通帳を持ち、副が判子を持つ。コレにより、多額のお金の使い込みを防ぐ」
方が組織としてはよいのですが、今回はコレの逆をした、ということになります。
口座も作ってなかったしw


計画

まず大ざっぱなスケジュールを組みました。
  • 11月上旬:原稿中間〆切。方向性を固める。
  • 12月上旬:原稿〆切
  • 12月中旬:(そこそこ安く仕上げるための)印刷所〆切
  • 12月29日:C91当日
12月の予定は、C91及び印刷所の〆切からおおよそ逆算で決められます。
極端な話、スケジュールといっても、実は12月中の予定さえ組めればあとはどうにでもなります。
が、それは「印刷担当」の話。
「編集長」が決めなければならないのは、実は中間〆切だと私は考えています。


中間〆切の意義

関係者が少なく、またその組織内での本づくりのノウハウが溜まっている場合はいいのですが、今回のように関係者が多く、ノウハウが無い、しかも文章を書くのに慣れていない人が多い場合は、原稿の中間〆切をやや早めに設定しておく必要があります。


理由1:原稿未完成を防ぐ

原稿を完成させる。これには想像以上の労力と時間がいります。
が、これが大抵の場合、驚くほど小さく見積もられます。普段「こんなスケジュールと工数見積もりで上手くいくわけないだろ、PMはバカか」というような人でも、なぜか自分の書く原稿は「いけるいける」と勘違いします(経験者談)。

小説でも解説でもそうなのですが、大抵の場合は
  • 書く内容を決める
  • 全体の構成を決める
  • 書いていく
の順番に進みます。


……………………
………………
…………

すいません、ウソつきました。
こんな風には進みません。


大抵の場合は
  • 書く内容を決める
  • 全体の構成を決める
  • 完成系を妄想する
  • 妄想で満足して書かない
の順番に進み、見事に停滞します。
厄介なのが、「全体の構成を決める」というところ。
コレができてしまうと「後は埋めるだけや!」という気分になります(経験者談)。
実際にはその「埋める」作業が一番つらいはずなのですが。なぜだ。

そんなこんなで、企画開始直後に一気に構成まで練り上げた後、〆切一週間前になるまで停滞することが多いです。
そして〆切一週間前に書き始めた後、

「なんか書きたかった内容と違う風になっているな?」
「ん? 軽く読み直してみたら、構成に矛盾があるぞ?」
「あれ、3時間使って書いたのに全然進んでない……」

となります(経験者談)。
場合によっては原稿を書くが億劫になってきて、「気分転換にゲーム」、「旅に出ます」とか言い出す人もいます。
それでも大抵は書き上げてくれるのですが、まれにそのまま原稿を落とす人がいます。

かくして、慌てて書かれ、中間〆切直前に提出された原稿は、妙に浮ついた、誤字脱字が多いものとなります。
これを補正する時間が、中間〆切~最終〆切の期間です。


理由2:本の方向性を早めに見極める

これは作者側ではなく、編集側の問題です。
今回の本は、わりと自由なテーマであり、どのような原稿が出てくるか予想がつきませんでした。
また、どのくらいの頁数になるかも分かりませんでした(※次回以降後述しますが、今回、ここで失敗しました)。

そもそも外部に出せないような内容を提出する人もいるかもしれませんし、
頁数が予定よりも少ない場合は、コピー本の方がよいかもしれません。
頁数が多い場合は分冊、あるいは話し合いや投票によって載せる原稿を早めに決めたいところです。

どの問題であっても、編集のノウハウと、ある程度の共通認識が編集-作家間でできあがっていればクリアできます。
が、両方ともなかったのでチキンな〆切としました。


理由3:読者の意見を原稿に反映させるための時間を作る

これは完成度に関する話です。
アプリケーションのバグは、テスターが多ければ多いほど潰せます。
また、改善提案もテスターが多いほど集められます。
本も一緒で、読者が多ければ多いほど誤字、脱字、誤りが見つかりますし、
感想、意見も集められます。

とはいっても、読者側の都合もあるので、読んでもらえるよう長めの時間をとります。
※できれば1度、全員集めて読み合わせをしたかったところですが、今回は叶いませんでした。


次回

今回はここまで。
ちょっと記事が長くなってしまったので、分割します。
次回もできるだけ早くあげたいと思います。




職業としての「編集者」

新品価格
¥1,944から
(2017/1/11 00:43時点)

昨年の反省、今年の目標

新年始まって10日ほど経ってますけど気にしない気にしない。
遅ればせながら、あけましておめでとうございます。

昨年の反省

  • やっべえCCさくらの放映日間違えてたw 来年じゃんw
  • 前半はともかく、後半はあきらかに学習が失速していた。
  • 本をあまり読めていない。

今年の目標

  • Hololens がくる予定なので、それで遊ぶ。
  • いい加減3Dモデリングを勉強する。
  • 軽い運動(世間的には軽いが、本人にはキツイ)は週一を維持。
  • もう一本くらい、練習がてらUWPアプリを作る。
  • 読書量を増やす。月3冊くらいは読みたい。

※読書履歴には、ラノベや雑誌は含めていないので、それらを含めればもうちょっと増えることは増えます。

実にいい加減な一年になりそうですw


死ぬまでに行きたい! 世界の絶景 2017年 カレンダー 壁掛け CL-413

新品価格
¥1,215から
(2017/1/9 12:53時点)

コミケ

この頃更新が滞りがちだった原因がコイツです。
祭りって怖い。

詳細

サークル「でがらし会」としてC91に参加予定。
これに出すなんちゃて技術書を作りました。
スペースは「木曜日 西地区 "み" ブロック 23a」らしい。
……らしい、というのは、私は編集として参加していますが、当日行かないためですw
CM、CM。

さらなる詳細

でがらし会HPはこちら。
技術書作りは、私は編集担当として参加しています。裏方ですね。
そのため、ちょろっとしか文章を書いていません。


で、本については?

C#を中心に、ラズパイ、Xamarin、Firebird、設計論です。
概ね80頁、300円の予定。
よろしければお手に取ってくださいませ。


色々苦労したけど、そのあたりの話はコミケが終わってからまた書きます!



四日市 萬古焼き 急須 e408 紫泥

新品価格
¥1,890から
(2016/12/27 22:20時点)

Delphi でインターフェース変数が、他のインターフェースを実装しているかを調べる

Delphi で、「インターフェースで受け取った変数が、他のインターフェースを実装しているか」
をどのように調べるのかが分からなくて苦戦したのでメモ。

調べる前 「isでいけるいける」
コードを書いた後 「isだとコンパイル通らないやん……」

というわけで、正解はこんな感じ。


ソースは、ブラック企業から社員を取得し、その人物がプログラマーならなら残業させるというもの。

procedure hoge;
var
  IShain : ISalaryman;
  IShachiku :IProgramer;
begin
  IShain := BlackCompany.Shain;
  if Supports(IShain, IProgramer, IShachiku) then
    IShachiku.Zangyou;
end;

BlackCompany.Shainから返された値を、ISalaryman インターフェースで宣言されたIShainで受けとります。
このIShain変数の実体が、IProgramer インターフェースを実装しているかどうか調べるのがSupports メソッドです。
実装していないならFalse、実装されているならTrue が返り、第三引数(サンプルではIShachiku)にIProgramer にキャストされたものが入ってきます。
これでIShachiku 変数には、IProgramer 型が入ってきます。
後は残業させればよいヨロシ。

詳細は

下記の本に書いてあります(宣伝)



果実酒収穫

以前漬けていたものを収穫しました。

ドン!



コレを手元にある中で、一番高い酒のビンに入れれば、



おお、色もそれっぽい!
コレ騙せるんじゃね?

今年もソコソコいい出来かな。満足満足。


サントリー 果実の酒用ブランデー 紙パック 1800ml

新品価格
¥1,625から
(2016/12/18 20:34時点)