夢ひろがリング

野望を考えないと。

要件

大本の要件は超高速で漫画を乱造する。 ネタを思いついて、鼻歌歌いながら落書きしたら本が出来る。いいね?

第一段階

まず、現在のCopiBonなるOSSでWebでソフトを配布し、 何時でも印刷用のデータが画像があれば出来る状態にする。 画像があれば本が出来る。いね?それだけ、確実に済ませる。

要するに、この段階で適当に書いた紙を集めて本に出来る。

ここまでを10月までに目処をつける。

PDFの出力もなんとか入れ込みたいところだが、なかなか難解で難しい。(いや、仕様書は有るんだけれどね。)

ターゲットはコンビニ等、以下の部分は攻めてみようと思う所存。

第二段階

CopiBonに簡易なお絵かき機能をつける。 これは多分2月までかかるだろう。

目標機能は

  • 追加機能はレイヤーがあって、
  • 線がかける程度。
  • ナビゲーターはつける。
  • 線の太さと
  • 消しゴムぐらい。
  • 筆圧には対応したい。
  • なので絵チャぐらいかな。回転機能は必要だろうか。
  • 輪投げ選択、矩形選択ぐらいはあり。
  • 塗りつぶしはあり。

抜きと入りは多分実装できない。能力的に。

第三段階

マークダウンの方言を書くと コマ割りが確実に出来て吹き出しに文字が入れられる。 マークダウン。この簡便さが重要。

この作業が現実問題として非常にヘビー(1ページに1〜2時間かかる)なので、自動化はかなり作業負担軽減をもたらす。

工数的に、来年の夏コミに間に合うだろうか。

第四段階

WebRTCによる連携を投入。 WebRTCで複数端末を同時連携させる。同じ作品を複数端末で同期出来るようにする。

しばらくはSkyWay等でショートカットしつつ、最終的には独自アプリを配布する形にはなると思われる。 いや、ポリシー違反がないなら別の実装になる可能性も有るが。

鯖のプラットフォームはAndoridアプリになると思われる。 出来るなら、Firefoxのアドオンで実装できるならしたいが、かなり変態じみたことをしなければいけない模様。 配布は今話題の野良apkになると思われる。特段の宗旨替えがなければOSSにするから自分でビルドしてもいいのよ?

すなわち、スマホでネタを書いて、タブレットで本に仕上げて印刷するという工程を全部つなげる。

第五段階

マストドンTwitter風に垂れ流した内容を集積させ、意味の通る順番に並び替えて、必要な部分を継ぎ足し、 不要な部分を削ぎ落とす作業を実施するアプリを作成する。 とにかく出す。出した後、時系列、因果律、伏線、ライトアップされている、されていない範囲、込めた意味を決めて 目視可能なUIを実現する。 読者にとって美味しい物は作者にも美味しいのだ。いいね?

ここで、人間の宿痾として、どうせ似たようなものしか書かないので、上記の最適化をAIにやらせられないか検討する。 人間の役目はただ、夢想して垂れ流して入力するのみ。

例え其れが本編の戦闘シーンは一切ないのに延々と兵器整備兵の日記が続くでもいいのだ。

そんな夢ひろがリング。

妄想:Color Classic2にRyzen Threadripper 2990WXを入れたい。

これは呪縛なのだ。

金もなく、ただどんどん性能がアップしていくパソコンをMacを見る学生時代

そこには夢が有った。まさにダグラス・アダムスの法則の罠。

35歳以降になって発明されたテクノロジーは受け入れ難い?「ダグラス・アダムスの法則」に賛否 - Togetter

この呪いにまだかかっている。もしかしたら一生この呪いは解けないのかもしれない。

いや、解く方法は有る。現物を、現物をこの手の中に入れた瞬間、呪いは解ける。解けるが、情熱も溶ける。

現状は

Macintosh ColorClassic この筐体は既に入手している。

先達は次のようにやっているが正直ぬるい。

2016 ColorClassic 改造をまとめてみた。さぁDIYはじめよう! : NitRo Blog

サイズ的にはMicroATXは確実に入る。なのでRyzen Threadripper 2990WXが現時点での最高CPUとなる。

ATXは分からない。

それなりのGPUも入れて、排熱が間に合うかどうかだけが問題だが不可能ではない。

予算

皮算用をする。単位は諭吉。

  • Ryzen Threadripper 2990WX 25万
  • ママ板 5万
  • メモリ DDR4 Unbufferd DIMM 16GB x4 8万
  • SSD NVMe 256GB 3万
  • グラボ RX570 8GB 4万
  • 電源 650W Titanium 3万
  • TR4対応水冷クーラー 2万
  • 8インチRetinaモニタ 1万ちょい

合計:51万ちょい

ヒャッハー

パーツを固定する内部骨格の資材も2〜3万かかるのでまあ。 でも、この現物を手に入れた時、呪いが解けると思われる。

HTMLでコピー本を作るプロジェクト

コピー本データをコンビニコピー機をターゲットに簡単に作るプロジェクトを作成中。

CopiBon- dest top

f:id:ryunosinfx:20180806003028p:plain

コピー本の原稿データ

コピー本の原稿を作るのはいい。

問題は印刷だ。

原稿を規定の解像度に収めるのはいい。 が、いざコンビニに印刷用のデータを持って行くとなるとこれが難しい。

  • コンビニのコピー機の性能は?
  • どのサイズまでなら受け付ける?
  • 実際に印刷できる範囲は?

これらを考慮すると過去の経験により

B5版向けの原稿用紙が300dpiであるとき、257mmが高さで、 コピー用にギリギリを狙うと、断ち切り線までは600dpiで272-274mmに拡大する

4184x5909がベストピクセル@B5サイズとしたのでこれでJpeg100%品質で10MBを超えなければセブンイレブンで印刷が可能になると・・・

セブンイレブンコピー機の仕様を確認すると次のような制約がある。

7000万画素までしか対応しないのか・・・ということは8366px四方になるのだが・・・ なるほど、7035x9949までしか印刷できなくて、600dpiだと長辺が421mmなのでギリギリA3が印刷可能であると。確かにスペック通りだわ。 だったら7000万画素印刷可能とかだけじゃなくて600dpiでA3(7035x9949px)まで印刷可能ですとか謳って欲しい。なるほど、こりゃコソビニで1200dpiの印刷なんぞ出来んわけだ。

ちなみに最近触った感じだと

  • セブンイレブン:PDFの選り好みはしない
  • ミニストップ:PDFの選り好みをする。スマホから直接吸い出しが出来る模様。まだ繋いだことはない。
  • ファミマ、ローソン:一旦マシンにファイルを取り込む。どこまで出来るかは不明。

ここのまとめがいい感じ。

togetter.com

そもそもの動機

さて、この画像を作るのが苦行で仕方がない。 平均4時間はかかる重労働である。これが、ボタン一つで済むなら10分ぐらい時間がかかっても嬉しいではないか。時間はなによりも貴重である。

一旦自動化はしたものの

というのも、メインで使用しているGimpはPyhon-Fuなどの自動化ができなくはないが 不安定である。実際作ったがGimp2.10も出たしね、動くかどうかよくわからない。 作ったものを再インストールする。これも骨である。なにやら手の混んだ儀式が必要だった記憶がある。 なので、やはりインストール不要で、何時でも使えるものが良い。

という要件からWebで実装を開始した。

先達の調査

www.vector.co.jp

の一箇所だけだが見つけた。 残念!基盤技術がプロプラでした。Windowsユーザはいいかもしれない。でも私はLinuxユーザだし使えないことはないだろうがあんまり魅力を感じない。理由は思ったより省力化されないという点。

Webのいいところ

Webのいいところはブラウザに配信すればインストールが完了なのである。 まどろっこしいインストール先のフォルダの 指定も要らない。ただ、ブラウザを開いて指定のURLを開けばおしまいである。

次の要望も叶う

  • ①自宅はLinuxで統一したい→Linuxでも使える
  • ②移動中にも使いたい→スマホで使える
  • ③職場の昼休みにも使いたい→スマホ
  • ④配布をイージーにしたい→ギフハブ

(ただしIESafari、Edge等プロプラな連中はよくわからない。IEは言語道断、他もなにせ実機がないでな。なのでこのプロジェクトではFOSSなChrome、Chromiume、Firefoxを念頭に話を進める。)

ちなみに

現在のWeb(クライアント側javascript)の状況を説明すると

  • Indexeddbでデータ保存が出来る。
  • WebWorkerマルチスレッドも可能
  • FileAPIでファイルの読込、バイナリ、画像の加工も可能
  • zlib.js等でzipファイルの生成も出来る。
  • PDFだって作れる。
  • ServiceWokerにてオフラインでブックマークから開いて動かすことも可能
  • 速度はネイティブプログラムの2〜3倍程度の遅さに収まる
  • 外部からのPush通知にはサーバーが必要、プログラム内でならNotificationAPIで自分で出せる。

したがって、何でも出来るのである。

進捗

次のステップで進めている。

  • ①アプリを開く
  • ②画像をアプリ上に集める
  • ③画像をアプリ上でプレビューで確認
  • ④画像を出力ページに割り付け
  • ⑤アプリで割り付けをプレビューで確認
  • ⑥出力設定をする
  • ⑦ファイルの生成
  • ⑧zipでまとめてダウンロード。ファイル名は日付入り
  • ⑨後はノーチェックで解凍、印刷。(実際にコピー機にぶち込んで作業が止まらないかの実地テスト)

現状は⑥、⑦のまだ画像の加工ができたところまで 道のりは長い。

GPD Pocketを入手してUbuntu17.10Beta2を入れる。

さあUbuntuで使うぞ!

なぜWindowsじゃないのか?それはLinuxの方が使いやすいからだよ(ニッコリ)

事前準備

まず、BIOSをちゃんとLinux対応版に入れなおす。 そしてコルタナにサヨナラを言う。(何故かWindows10のイメージが販売元?から公開されている)

情報源と対応、その注意点

kapper1224.sblo.jp

ここに書いてあることがほぼ正しいのだが、 問題はそのままUbuntu17.10Beta2を入れると書いてある内容は当てにならない。

そう、バージョンが問題なのである。

kledgeb.blogspot.jp

ここに書いてあるとおり、Ubuntu17.10Beta2からはWaylandで起動する。 これが何が問題かというと、まだ設定画面と設定処理を上手く紐付られていない。設定画面に設定のボタンが表示されないのである。他のコマンドも試すが、何よりGnome前提なので動かない。 なので、設定画面から出来ることが非常に限られている。

  • 画面がローテートしない。

なので、一度、gnome-sessionを入れて、セッションをgnomeに変更する必要がある。 一応、外部ディスプレイを繋げればその設定過程で変更は可能。

ちなみに、USBメモリで起動した段階では音もなるし、画面の向きも変えられるので結構なハマり道ではある。

できたこ

次の点はgnome-sessionを入れた後は最初のページの内容に従えば問題はなかった。

  • Wifi接続
  • スピーカー:画面からは音量操作はできない。
  • 画面輝度:画面からは音量操作はできない。
  • マウス速度:画面からは音量操作はできない。
  • 日本語入力:Windowsキーを使えば切り替えが出来る。
  • スリープ:蓋を閉じてスリープ、蓋を開いて起動、いずれも問題はなくできる。
できてないこと
  • BluetoothLinuxで動く方法がまだ不明のもよう。
  • バッテリ容量の計測:カーネルが対応してないっぽい。
  • ファンの回転:カーネルが対応してないっぽい。

使用感

一日1時間未満なのでバッテリー不足や加熱は問題にはならない。 スーツジャケットの内ポケットにすんなりではないものの入るし、顔を出さない。 が、スマホ3台分の重量は結構重い。

ポインター

TKBのの愛用家としてはポインターは問題はないどころか使いやすい。 ただし、立って使用をするにはやはり片手での利用は難しい。 あとキーボードはいろいろ不可解な配列ではあり、DELとBSのキーが逆なんじゃ。そこが辛い。 正直、両手が使えればタブレットと同じ程度のスペースで立って使えるのはありがたい。 しかし、クリックボタンの手前の淵は邪魔。

速度

流石にAtomZ8750。遅い。 EditorのAtomを起動するのに猛烈に時間がかかる。CPUが上に張り付いて離れない。 起動した後は全てオンメモリになるので問題はおこらない。

(そうなんだ、メモリの容量やモニタの大きさは職場より上だからな)

やはりeMMCは遅い・・・ なのでディスクに速度は2.5inchなHDD並と思ったほうがいい。

画面はそこまで遅くない。

モバイルバッテリに繋いで

5V3Aの電流を取ると事前に噂を訊いてたのでわざわざ新しいバッテリーを用意したが、 実際に計測をすると5V0.5Aしか消費しなかった。 ただ、標準のやつはPDを話すのか12Vを出していた。いつかAnckerのPDを話すバッテリーを試しに買って試してみたい。

とりあえず、現状不具合はないので良い。

Ubuntuの壊れかけたHDDからのデータ救出劇。

状況

HDDが死亡。

  • ディスクが読み込み専用になって気がつく。そのまま放置するといろいろ面倒な用途マシンので頑張って治すことにする。
  • Ubuntuusbメモリから起動してfdisk -lをすると見える。
    • しかし、sudo mount /dev/sda1 /mnt とかやってもマウントできない。
    • USBアダプだで接続しないとやばそうな気配を感じるほど末期。
    • USBアダプタでそのうち見えなくなる。

対策を次のようにした。

死亡HDDから吸い出しの儀

死亡HDDは次のアクションでどれぐらいヤバイ状況になるのかわからないので極力何もせずに吸い出しに専念する。

  • まず大容量のHDDを部屋の片隅から発掘した。幸いにも故障したHDDの数倍でかい容量のHDDが発掘される。
  • 次にこの死亡HDDと吸い出し先の数倍でかいHDDをマシンにつなぐ。
    • この際、死亡HDDは正常にマウントできないのでUSBアダプタ経由とした。
  • sudo fdisk -lでつながっていることを確認。
  • まずはddコマンドでHDD全体を吸い出す。ところが不良セクタ多数により吸い出せない。
  • 次のコマンドでエラーセクターはスキップして読み込む。512byteセクタなHDDなのでbs=512にしておく。
    • sudo mkdir /mnt2

    • sudo mount /dev/sdb1 /mnt2

    • sudo dd if=/dev/sdc of=/mnt2/sdc512.img bs=512 conv=noerror,sync

  • 不安になるほどうじゃうじゃエラーが出てくるので我慢して全部吸い出し終わるのを待つ。
  • 終わったら吸い出しファイルが異常なサイズになってないかは確認する。異常な場合は何か間違っているのでよく調べてね。
まずはマウントしてみよう

マウントをする。イメージファイルなのでデバイスではない。なのでまずはループバックデバイスにひも付けてデバイスとして見えるようにする。

  • sudo losetup /dev/loop1 /mnt2/sdc512.img

  • このままではfsckを流せないので、再度中のパーティションについてマッピングを行う。

    • sudo kpartx -a /dev/loop1

    • これにより、/dev/mapper/loop1p1とかでパーティションが見えるようになる。
  • fsckをかけてみる。

    • sudo fsck -yf /dev/mapper/loop1p1

  • スーパーブロックがぶっ壊れてダメな場合があるのでその場合スーパーブロックのみ再構築して再度fsckを試みる。

    • sudo mksf.ext4 -S /dev/mapper/loop1p1

    • sudo fsck -yf /dev/mapper/loop1p1

  • 中のファイルをマウントして取り出す。

    • sudo mkdir /mnt2p1

    • sudo mount /dev/mapper/loop1p1 /mnt2p1

    • sudo cp -pr /mnt2p1/xxxxx ./

VMのディスクの復旧と容量アップ

で、問題はここなのである。 せっかくの機会なのでディスクのサイズアップも行う。 手続きとしては次のようになる。

  1. 大きめのディスクイメージファイルを作る。
  2. 作ったディスクイメージにパーティーションを切る。
  3. 移行元のディスクイメージをマウントする
  4. ddでコピーする?それともフォーマットしてcopyコマンド?

  5. ddでコピーした場合。
    • ddでコピーすると動く。動くのだが・・・すぐに欠損セクタ由来と思われるfsエラーに引っかかってリードオンリーモードに入ってどうしようもなくなる。
    • とりあえずディストリ自身のバージョンアップを行うと以下の作業を延々と行うはめになる。
      • sudo fsck -yfc /dev/vda1

      • sudo reboot

      • sudo apt-get install -f

      • sudo dpkg –configure -a

      • エラーになって最初に戻る。
  6. フォーマットしてcopyコマンドでコピーした場合。
    まず、loopbackデバイスにひも付けて、マッピングしてフォーマットを行う。
    • sudo losetup /dev/loop2 /mnt2/newvmdisk.img

    • sudo kpartx -a /dev/loop2

    • sudo mkfs.ext4 /dev/mapper/loop2p1

    • sudo mkdir /mnt2loop2

    • sudo mount -t ext4 /dev/mapper/loop2p1 /mnt2loop2

    • sudo losetup /dev/loop1 /mnt2/oldvmdisk.img

    • sudo kpartx -a /dev/loop1

    • sudo fsck -yfc /dev/mapper/loop1p1

    • sudo mkdir /mnt2loop1

    • sudo mount -t ext4 /dev/mapper/loop1p1 /mnt2loop1

    • sudo cp -fr /mnt2loop1/* /mnt2loop2

  7. これだけでは当然ダメで、chrootしてgrubのインストールとupdate-grubを行う必要がある。
    • sudo mount –rbind /dev /mnt2loop2/dev

    • sudo mount –rbind /sys /mnt2loop2/sys

    • sudo mount -t proc proc /mnt2loop2/proc

    • sudo chroot /mnt2loop2 /bin/bash

    • # update-grub

  8. パスの関係上、grub-installだけはインストールCDで起動したVM上から行う必要がある。ないのかな?

    • # grub-install –recheck /dev/vda

  9. 仮にgrubが壊れていた場合。
    インストールしなおして再チャレンジするしかない。
    • sudo apt-get update

    • sudo apt-get install –reinstall grub

  10. 仮にsudoが壊れていた場合。

    とにかくgrubをいじってシングルユーザーモードで入って、rootのパスワードを設定する。sudoをそのまま再インストールか、再起動して再インストールする

qiita.com

  • $ su -

  • # apt-get update

  • # apt-get install –reinstall sudo

  • 運が良ければこのままディストリビューションのバージョンアップを行う。
    そう、運が良ければ。というのも不良セクター由来のバイナリ不良は各パッケージに及んでおり、パッケージ再インストールを行うより他確実に動く状態にはならない。fsckでは検出できない。 ディストリビューションのバージョンアップを行えればパッケージがほぼすべて最新バージョンに置き換わるはずである。
    • sudo do-releace-update

以上で動くようになるはず・・・

もちろん、不良セクター由来のデータ欠損はデータにも及んでいてだいぶ壊れてる気がするがないよりマシなのである。

くれぐれも多世代バックアップは欲しいなぁと思う次第。

システム構築の十戒

1:システムの一生は5年からそれ以上です、メンテナンスができないソースが一番つらいです。どうか組む前にそのことを覚えておいて欲しいのです。 2:お客様がシステムに何を要求しているのか、それを理解、要件定義書に落として握ったうえで組んで欲しいのです。 3:基盤、FW、ミドルウェアの仕様を確認して欲しい、それがシステム安定稼働の第一歩なのですから。 4:ロジックの存在理由についてコメントを書かなかったり、名称を適当につけたり、マジックナンバーや使い回しをしないでください。あなたは楽が出来るかもしれませんがチームのメンバーは理解に相当な時間を消耗します。 5:時々動作確認してください。ちゃんとしたテストができてなくてもコンパイルにビルドが通らないコミットはチームメンバーのテンションを下げます。 6:あなたがどんなレベルの修正をしたか、SCMのコミットログを見ればすぐわかります。 7:テストをする前に覚えておいて欲しいのです、プログラムは書いたとおりに動くということを。 8:バグだ、作動がおかしい、環境がおかしい、動きませんと言う前に、バージョンが最新なのか、仕様変更のタイミングや、手順書や仕様書を確認してください。もしかしたらDBとアプリのバージョンがずれていたり、必要な初期データがないかもしれない。それともそもそも動かす環境がもう別、クラウドなのかもしれません。 9:システムが運用フェイズに入ってもメンテをする想定でいてください。例え組むだけでも瑕疵担保期間というものが有ってメンテが必要な可能性が有ります。 10:システムが死ぬときは5年の寿命を迎えた時か、あまりにも糞すぎてお客が大枚叩いて作った今のシステムを捨ててもう一回作りなおしたほうが儲かると判断した時です。前者は幸せですが、後者は泥棒と罵られても仕方ない惨状です。

うん。やはり何か本質を外してる感がまだあるな。