カテゴリー別アーカイブ: Linux

タスク管理をtrelloからOpenProjectに変えようかなと思ったけど結局redmineにした話

今回の移行に当たって考えたことのまとめから書いておく

Wrikeは最高だけど、高すぎて厳しい。
OpenProjectは貧乏VPSには性能面で辛かった。
結局Redmineしか選択肢がなかった。
RedmineをDockerでインストールするとプラグインのインストールが辛かった。

ことの経緯

自分は生きるのが下手で、タスク管理やスケジュール管理がうまくできず、どうやってこれらをやっていくのかということについて色々試行錯誤していたりします。

昔はredmineで何でもかんでも管理することで落ち着いていたのですが、

  1. タスクの数が増えてきた時にごちゃごちゃしてくる
  2. 自力でホスティングするのめんどくさい
  3. UIが前時代的で辛い

あたりが理由で、trelloに移行していました。
子供が生まれてあんまり難しいことを家でやらなくなっていたので、シンプルな使い勝手のtrelloがとてもいい感じでした。
ただ、このところ子供がある程度大きくなってきて、自分が色々する時間も取れるようになってきたので、何か新しいことをしようと思った時に、タスクの入れ子が1段階しかできないtrelloだと複雑なことをしようとしたきのタスクのドリルダウンがしづらくて窮屈に感じられるようになってきました。

なので、タスクの入れ子現実的な範囲でいいので入れ子にできることを条件に色々探して見ました。

Wrike試してみた

2017年っぽいUIでスッゲー使いやすくて、これにしようって思ったのですが、試用期間が終わると、Freeではタスクの入れ子ができないので今回の要件に合わない。
けど課金額はどうだ?と思って調べて見たところ、課金は1人あたり月 $5と書いてあったので、$5ならVPS1つ借りるのと同じだしいけるんじゃないかと思ったんですが、5人ぶんまとめて契約しなきゃいけないらしく、1人で使うとしても月$25になってしまって辛いということが判明し断念。

すごくつかいやすいのに。もうちょっとカジュアルに使える価格設定だったらよかったのになぁと後ろ髪を引かれつつ使うのをやめました。

OpenProjectを試してみた

自力でホストしてもいいので何かいいものないかなぁと思って探して見たところ、最近はOpenProjectというOSSのプロジェクト管理ツールがあるという情報に当たったので、試してみようと一念発起。
公式でdocker imageが用意されていたので、これを利用しようとGoogle Compute Engineに1番安いインスタンスを立てて、dockerホスティング用のイメージを起動。その上にインストールすることを試みました。
が、なんかインストールがコケる。

インストールの感じを見ていると、どうも、dockerのイメージがでかいらしく、ディスクを使い切ってしまっていた模様。
なるほどね、と思って手元のPCのLinuxのVM上にdocker環境を整備してそこに入れてみたらいい感じで動いた。

Wrikeほどの使い勝手はないものの、RedmineよりはちょっぴりモダンなUIで、これでいいんじゃないかと思ってメモリの使用量を軽くチェックして見た所、起動するだけで1.2GBほど使う模様。
なんか、dockerのイメージ内に、サービスの本体であるRubyだけでなく、postgresやmemcacheも含んでいた。なるほど、イメージがでかいわけだ、とある程度納得。
しかし、メモリ使用量がこれでは、やすいVPSやクラウドインスタンス上に立てっぱなしに使うってのは若干厳しい。

とはいえ、ものは試しだと思って、昔契約した2GBのメモリが使える海外の安いVPSにインストールしてみた。
そしたら、起動はちゃんとしたものの、めちゃめちゃ重たい。
多分、ブラウザとサーバ間のレイテンシが何倍にも重なってUIの表示に効いてくるような作りになっているんだと思う。(未検証)

となると、手元のVMや家の中に置いたサーバーで動かすにはいいけど、外に置こうとするとレイテンシが辛くなってしまうな、ということで、これも不採用。

Redmineに戻ってきてしまった

色々不自由な点もあるけど、軽いし、もうredmineでいいや ということで、Redmineを改めて使い始めることにしました。
インストールはdockerで気軽に。アップデートもきっと手軽にできるでしょう。
いい時代だ。

Dockerでインストールした時にプラグインどうするんだ問題

Redmineには、プラグインが存在しています。いくつかのプラグインをDockerでインストールした手前、コンテナの中に踏み込んでプラグインをインストールするのはなんだかダサい気がしました。なので、自分でプラグイン用のDockerfileを書いてプラグイン類をインストールしました。
複数のプラグインを入れるのでそれぞれのDockerfileは分割して作成しました。
Dockerfileは、ベースとなるイメージの名前とバージョンを指定して、このイメージにどういうファイルを追加するのか、どういう風に起動するのかといった情報を追加して行くという書き方をするようになっています。

例えば、2つのプラグイン(それぞれプラグインAとプラグインBとする)をインストールするために
公式Redmineイメージ -> プラグインA追加イメージ → プラグインB追加イメージ
という順番でイメージを拡張するとします。
この時、プラグインA追加イメージを作るためのDockerfileには、ベースとなるのは公式Redmineイメージですよと書いてありますし、ブラグインB追加イメージを作るためのDockerfileにはベースはプラグインA追加イメージですよと書かれています。
なので、例えば、上記の状態から、やっぱりプラグインAが不要だから、プラグインAを取り除こうと思っても、単純にプラグインA追加イメージを作成しないだけではダメうまくいきません。プラグインB追加イメージ作成用DockerfileにあるベースとなるイメージをブラグインB追加イメージから公式Redmineイメージに書き換えないといけないという手間があります。

そんな感じで、若干、長く管理できるんだろうか、大丈夫なんだろうかという疑問は持ちつつも、とりあえずDockerでやっていこうということに決めました。

ちなみに、プラグインは、easy gantt plugin(free)Time Loggerだけ使ってます。シンプルに。

プラグイン追加後のDockerイメージをdockerhubにアップしておこうかなとも思ったのですが、easy gantt plugin が GPL v2にも関わらず、ソースコードは配布して欲しくなさそうなので自重。プラグインダウンロード用のワンタイムのURLを生成したり、そもそもgithubあたりにも置いてなかったりして、長く使い続けられるのか若干不安。ただ、そういった不安に目をつぶれるくらいeasy ganttでredmineは使いやすくなるので使っていこうと思います。
easy gantt freeは、ソースコード開示をしぶったりせず、最初からインストール済みのDockerイメージを配布しちゃえば、試してくれる人、買ってくれる人増えるんじゃないかなって思ったりするんですが、そうでもないんですかねぇ。

それよりも、easy redmineのホスティングサービス売りたい感じなのかなぁ。


ConoHaのAPIを叩く・・・のは面倒くさかったのでnovaコマンドを使ってみた。

ConoHa VPSのインスタンスをコマンドラインから操作したい!

こんにちは。先日、ConoHa VPS上にVDI環境を作ったよ!という日記を書きまして、結構いい感じに実用しております。

で、先日作った環境だと、起動や終了のためにウェブブラウザを使ってConoHaのポータルを開いてマウスでポチポチするひつようがありまして、それってちょっと面倒くさい。起動や終了やイメージの作成なんかを自動化したいなぁとおもうのは人のサガでありまして、なので、APIを叩いて、コマンドラインツールを作ろうかなぁ、などと思ったのですが・・・

Conoha VPSはOpenStackベースだからOpenStack向けのコマンドラインツールが使える!

よくよく考えたら、ConoHa VPSは、OpenStackというOSSのクラウドを作るためのソフトをベースに作られているので、OpenStack用に作られたコマンドラインツール群を用いてある程度コントロール可能なはずです。なので、まずはOpenStack用のコマンドラインツールのうちVMの起動、停止、削除などを行えるnovaコマンドについて試してみることにしました。

novaコマンドとは

OpenStackは、幾つかのサーバで構成されています。それぞれのサーバはAPIを公開しています。このうち、VMを起動したり停止したり削除したりといった操作を行うサーバをnovaと呼びます。novaコマンドは、novaのAPIを叩き、novaの持つVMを起動したり停止したり削除したりといった機能を呼び出します。

novaコマンドのインストール

OpenStackを構成するサーバや、これらのサーバを操作するためのコマンド群をインストールする方法には、いくつかあります。今回は、手元にある環境がCentOS 7.1だったため、RDOと呼ばれる、OpenStackをインストールするためのyumレポジトリに置かれているrpmのパッケージをインストールすることにしました。CentOSやFedoraならこの手順で大丈夫なはずです。

これでnovaコマンドがインストールできました。

ちなみに、UbuntuにはUbuntu OpenStack Installer が用意されていますし、pipのパッケージとしても公開されているので、好みに応じてインストール方法は選べそうです。

novaコマンドの設定

環境変数に設定されている値を使うので設定します。必要な情報はConoHaのダッシュボード右下のAPIボタンのところを叩けば参照したり設定したりできます。

以上をファイルに書き込んでおいて、必要に応じて読みだすようにすると楽だと思います。

novaコマンドを使ってみる

novaコマンドを実行すると、どういうオプションがあるのか色々表示できます。

起動したり、削除したり、リブートしたり、イメージを作ったりなど先日のVDI作成エントリで必要な操作は全部コマンドラインから実行できることが確認できました。これまでブラウザからしなければならなかった作業がコマンドラインからできるようになりました!これでちょっと楽になりました。

インタフェースを守ってくれているConoHaの中の人に感謝!

おそらく、ConoHaではOpenStackのコードをそこそこ変更していると思うのですが、それでもAPIを変更せずに守ってくれているおかげで既存のツールを使えてとてもありがたいです。

中の人たちに感謝しつつ、OpenStackを前提としたエコシステムのありがたみを享受して楽しく生きていきましょう。

以上です。


VDI環境をConoHa上に作った、その理由。

安くVDIを実現したい!

お小遣いに悩めるIT系サラリーマンの皆様こんにちは。
最近は、容量が小さいSSDを積んだノートPCが多くて、なんだか困りますよね。
ホストに入っているOSがWindowsやOS Xなのだけど、Linux環境が欲しい!でも、SSDの容量が小さいのでVMを作ってディスクの容量をガバガバ食うのはちょっとつらい。
かと言って、新しいPCを用意してそこにリモートアクセスするのも、PCを買うのも電気代もかかっちゃって、なかなか厳しい。
と言うシチュエーションはまま有ると思います。というか、僕自身がそうですしね。

そこで、考えてみました。クラウド上に開発環境を作ればいい!と!思いつきました。
でも、クラウドに置いたLinuxのインスタンスにはsshでアクセスして、emacsやvimで開発するんでしょ?ちがうんだよ!IntelliJやsublimeみたいなもっとリッチな環境が使いたいんだよ!という人、多いと思います。
と言うか、僕自身がそうですしね。

というわけで、いろいろ試してみたところ、ConoHaのインスタンス上にTigerVNCを用いてアクセスすることで、安くVDI環境を構築できたので紹介します。

なんでConoHaを選んだのか

インスタンスの料金体系がVDI向き

ConoHaのインスタンスは、1時間刻みで課金されます。
お小遣いに悩めるIT系サラリーマン的には、開発環境は常時起動しているわけではありません。
例えば、仕事から帰ってきた後とか、土日だけとか、限られた時間、安く使えることが大切なのです。
なので、細かい粒度で課金してくれるConoHaはとてもこういった用途に向いているな!と思うわけです。

50GBまでディスクイメージの保存にお金がかからない

これがけっこう重要なポイントで、一般的なクラウドでは、インスタンスの電源を切っても削除しなければお金がかかりつづけます。
インスタンスの削除を行うと、一緒にそのインスタンスで用いていたディスクのイメージも削除されます。
したがって、インスタンスを削除し、課金を止めるためには、ディスクのイメージのバックアップを取得する必要が有ります。
ConoHaでは、このディスクイメージバックアップが50GBまで無料です。
そして、インスタンスが用いるディスク容量は低スペック~中スペックくらいのものは50GBです。
なので、ディスクイメージを無料でバックアップすることが可能です。

したがって、
インスタンスの停止 → ディスクイメージのバックアップ取得 → インスタンス削除
という手順を踏むことで、ディスクイメージを保持したまま課金を止めることができます。

また、インスタンスの起動時にバックアップイメージを書き戻して起動することが出きるので、
インスタンス削除時の環境を取り戻すこともできます。

必要に応じて性能が選べる

インスタンスをバックアップイメージから書き戻して起動する際には、以前に用いていたインスタンスと異なる性能のものを選ぶことができます。
したがって、普段は最低スペックのものを用いておき、必要に応じて、高性能のインスタンスを選ぶことで、簡易に性能向上が可能デス。

SSDが乗っている

人間が直接扱う環境に関しては、CPUが早いよりもSSDが乗っていることのほうが体感速度に影響は大きいと思います。
ConoHaは全部のインスタンスがSSDで動いているので、人間が快適に使うのに向いていると考えます。

日本国内にホストされている

VDIはネットワーク越しに用いるものなので、手元の環境からホストされているインスタンスまでのネットワーク的な距離、主にレイテンシが重要になります。
ConoHaは国内にインスタンスをホストしてくれるため、レイテンシを小さく抑えることができます。

まとめ

以上の理由で、安くVDI環境を構築するのに、ConoHaは向いていると考えます!
このエントリも、ConoHa上で起動した最低スペックのインスタンス上のIntelliJ IDEAで書いています。
まったく何の問題もなく使えています。
新しい開発環境は欲しいけどどうしよう・・・と悩んでいる方、
ConoHaはユーザ登録すると、いくらか分か無料で使えますので、ぜひ試してみてくださいね!


Linux(fedora 21)の上でVisual Studio Code を使って sails.js の開発をしたい!

あらまし

さいきん、アニイベZというアニソンがかかるクラブイベントのをまとめたポータルサイトの拡張機能の開発を担当することとなりました。開発には、いろいろな経緯があって、 node.js 向けの RoR 風フレームワークである sails.js というフレームワークを用いて開発を行うことにしました。

これまではemacsのjs2-modeで開発を行おうと試みてきたのですが、無名関数を使うとインデントが大きく崩れたり、補完がなんだか上手く効かなかったりと、効率の悪い状況が続いてきました。

何かいいIDEは無いものかなぁ。WebStormはお金かかるからなぁ。。などと思っていたところに、Microsoftの開発者向けカンファレンスである Build 2015 にて Visual Studio Code という、WindowsでもMacでもLinuxでも動く、.Netとnode.js向けのIDEが発表されたという報道を見て、おー、これ、試してみるかー と思って、試してみました。

sails.jsもnode.jsもよくわかってないのでトンチンカンなことを書いているかもしれませんが、自分のための備忘録というか、作業ログってことで。

ここに書いてあるのを真似するとできるようになること

  • Visual Studio Code である程度補完がきくようになる
  • ブレイクポイントを置いてデバッグできる

できるようにならないこと

  • ormapper(waterline)とかblueprintの補完はできない
  • 他にもいろいろできないことがありそうだけどまだよくわからない

やりかた

1. まずはsailsを動かす

1.1. fedora 21 をインストールする

してください。自分はWorkstationをVMware Player上にインストールしました。

1.2. node.js と npm をインストールする

とりあえず、node.jsとnpmをyumでインストールします。

でも、このままだとnpmのバージョンが古くてsailsがインストールできないので、一度npmを最新版にします。

これでnpmが新しくなりました。

1.3. sails をインストールする

というわけで、sailsをインストールします。

1.4. sailsを動かしてみる

として、webブラウザで http://localhost:1337 を見るとテンプレートのページが見えるはずです。

2. Visual Studio Codeをインストールしてデバッガで止めてみる

2.1. Visual Studio Code をインストールする

まずは、Visual Studio Code公式サイトからVisual Studio Code をダウンロードしてきます。zipなので適当に圧縮を解いて、適当な場所に置きます。自分は取り敢えずホームディレクトリのvscってディレクトリに置くことにしました。

ってすると起動します。おお、かっこいいではないか。

Screenshot from 2015-05-07 23:56:23とりあえず右側のWelcomeタブは適当に眺めた後に閉じちゃいましょう。

2.2. さっき作ったsailsのプロジェクトを読み込んでみる

File -> Open Folder でさっき作った visualstudio_sails ディレクトリを選択。すると、でぃれくとりのツリーが見えます。適当にフォルダを開いてやると、ファイルの中身も見えます。

Screenshot from 2015-05-08 00:03:56

2.3. 実行環境の設定をする

Visual Studio Code内からsailsを実行したりデバッグしてあげたりするためには、nodeやsailsがどこにおいてあるかを伝えなきゃダメだよなぁということで、その辺りを設定します。

左に縦に4つ並んでるアイコンの一番下に虫禁止マークみたいなのがあるので、それをポチッとしてやります。すると、今までディレクトリ構成を表示してたところが、変数やスタックを表示するための物に切り替わります。その上の方に、如何にも設定用のアイコンといった趣の歯車のアイコンがあるので、そいつを押してやると

Screenshot from 2015-05-08 00:09:02なんか、launch.json という如何にもプログラムを動かすための設定を記述するために使うっぽいファイルが開きます。

歯車の左にあるドロップダウンリストの内容は、このjsonファイルの configuration 配列によって定義されているオーラを感じますので、このファイルをコメントと空気を読んで編集します。

具体的にはこんな感じにしてみました。

Launch Sails.js って書いてある要素が追加した部分になります。これを保存すると、さっきのドロップダウンリストにLaunch Sails.js という選択肢が現れるので、これを有り難く選択します。

で、その左にある如何にも実行ボタンっぽい右向きの緑色の矢印を押すと

Screenshot from 2015-05-08 00:19:36なんか、エラーがでる訳です。

エラーの内容を確認すると、

Cannot start OpenDebug because Mono (or a Mono version >= 3.10.0) is required

なんか、Monoの3.10.0以上が必要だと言わます。なるほどなるほど、じゃあMonoをインストールしてやろうと思って、yum install ’mono*’ なんてやろうものなら fedora 標準のバージョン2.10のmonoがインストールされ、とても残念な気持ちになるので、ここはぐっとこらえます。

2.4. 新しいmonoをインストールする

Monoの公式ページにインストール方法が明示してあるので、ありがたみを感じながらこれに沿ってyumのレポジトリをまずは有効化します。

 

これで、yumのレポジトリが有効になったはずです。レポジトリの名前を確認するために yum repolist を実行すると

download.mono-project.com_repo_centos_ が追加されたレポジトリのようですので、このレポジトリの中のmonoをインストールしてやります。

で、さっき押したときにエラーが出た、如何にも実行ボタンっぽい右向きの緑色の矢印を押すと

Screenshot from 2015-05-08 00:37:09なんか、黄色い右向き矢印が出て、如何にもプログラムの先頭で止まってるなーというオーラを感じられます。なので、如何にもコンテニューボタンっぽい上部真ん中に現れた、右向きの三角形を押してやります。すると、なんかsails.jsが動き出したオーラが感じられるので、ブラウザで http://localhost:1337 を確認してあげるとちゃんと動いているのが確認できます。

赤くて四角いボタンを押すと止まります。実行と停止を何回かやってもとりあえず上手く動きます。ここで設定が終わったオーラを感じますが、もう一息です。

2.5. 何かコードを書いてデバッグしてみる

ここまで来たら、何か実際にコードを書いてブレイクポイントを置いてみたいという衝動に駆られるのが人間の性です。なので、適当にuserなどという名前のapiを作ってみます。

visualstudio_sails ディレクトリ内で

ってやると、userという名前のmodelとcontrollerが作られます。よし、早速実行だ!と思って実行ボタンを押して、いざ http://localhost:1337 に接続しようとすると接続できません。その内、実行が終わったような感じで、画面上部中央のデバッグ中にだけ表示されるボタンも消えてしまいます。

ここで、何かがおかしいと感じて、./Code を実行したコンソールを改めて確認すると色々表示されている中に

error: Error: The hook orm is taking too long to load

という文字列を見つけることができると思います。何やらormapperが上手く動いていないらしいぞ、と感づきます。

ここで、 visualstudio_sails ディレクトリ内で、 sails lift すると

In a production environment (NODE_ENV===”production”) Sails always uses
migrate:”safe” to protect inadvertent deletion of your data.
However during development, you have a few other options for convenience:

1. safe – never auto-migrate my database(s). I will do it myself (by hand)
2. alter – auto-migrate, but attempt to keep my existing data (experimental)
3. drop – wipe/drop ALL my data and rebuild models every time I lift Sails

What would you like Sails to do?

info: To skip this prompt in the future, set sails.config.models.migrate.
info: (conventionally, this is done in config/models.js)

warn: ** DO NOT CHOOSE “2” or “3” IF YOU ARE WORKING WITH PRODUCTION DATA **

と表示され、どのようにデータを引き継ぐか決めろと迫ってきます。さらにこの状態で何もせずに放っておくと

prompt: ?:  error: Error: The hook orm is taking too long to load.
Make sure it is triggering its initialize() callback, or else set sails.config.orm._hookTimeout to a higher value (currently 20000)
at tooLong [as _onTimeout] (/usr/lib/node_modules/sails/lib/app/private/loadHooks.js:92:21)
at Timer.listOnTimeout [as ontimeout] (timers.js:112:15)

というエラーを吐いて、タイムアウトして終了します。さっき、Visual Studio Code 上で実行したのに動かなかったのはこれが原因だなーとわかります。先程のエラーメッセージの中に

info: To skip this prompt in the future, set sails.config.models.migrate.
info: (conventionally, this is done in
config/models.js`)

と有り難く書いてあるので、config.models.js を開くと下の方に

// migrate: ‘alter’

と如何にもそれっぽい文字列が見当たるので、このコメントアウトを取ってあげます。すると、さっきの引継方法で2を選んだことに毎回自動的になります。

改めてVisual Studio Code のデバッガからsailsを起動すると無事起動します。あとは、好きなようにコードを書いて、デバッガで止めてと快適に使えると思います。

なんか、適当にコードをかいて、ブレイクポイントを置いて、コールスタックも変数の中身もちゃんと見えてるぞというスクリーンショットと共にお別れしたいと思います。それでは皆さんさようなら。

Screenshot from 2015-05-08 01:09:26

おつかれさまでした。

 


録画システムChinachuにChinachu以外で録画したファイルを管理してもらう

こんばんは。こんばんは。ちゃーりーです。

Chinachuいい感じなのに昔録ったファイルの管理ができなくて辛い

先日のエントリで、録画用のLinux入りPCを新調して、新しい環境ではChinachuという録画システムを使うことにしということについて書きました。

Chinachu のインタフェース好きですし、トランスコーディングしながらストリーミングもしてくれたりするのでとても便利だなーと思いながら日々使っています。
しかし、以前の録画サーバでepgrecを用いて取り貯めた動画は、Chinachu の管理外にあって、Chinachu で取り貯めたものと一緒に検索をかけたりできないですし、トランスコーディングをしながらストリーミングしてくれるみたいな便利機能も使えないですし、結構辛い。出来れば、過去に取り貯めたデータも Chinachu で一緒に管理したい!よね!

一緒に管理できるようにしてしまおう

というわけで、嫁さんが布団に寝そべってPersona Qを遊んでる隣でごろごろしながらノートPC開いて、既存ファイルを Chinachu の管理下に追加するパッチを書きました。Javascriptなんてろくすっぽ書いたことないし、とりあえず動けばいいだろうみたいなとても低いモチベーションで書いたので、色々ひどいですが、とりあえずgithubに上げておきました。

https://github.com/sirrow/Chinachu/tree/addrec

$ ./chinachu addfile -file 録画済ファイルのパス

ってするとそのファイルをとりあえず2000年1月1日の0時から30分間録画されたって情報付きで録画済ファイル情報に追加します。

同じことで悩んでた!渡りに船だ!という珍しいお方は、上記コマンドを実行すると chinachu/data/recorded.json だけを弄るはずなので、このファイルだけでもいいのでバックアップ取ってから試してみるようにしてください。

制限事項は山ほどあります・・・

  1. IDをランダムに作っていて、そのIDの物が既にあるかどうかなんて確認してないので衝突するし、衝突したら変な挙動するはず。
  2. 録画した日時が2000年1月1日 0:00になる。録画時間は30分になる。
  3. フラグとかも検出してくれない。

とかとか。。なんか多分ほかにも変なところたくさんあります。
あと、関数とかサブコマンドのネーミングセンスも悪いけど、直すのもなんだか面倒なので。
それに、chinachu と app-cli.js の中にコード追加しちゃったけど、これくらいシンプルだったら1ファイルで完結する別のツールにした方がよかったかもなー。 recorded.json に情報足すだけですし・・・

本当はファイル名から日付や録画開始時間をパースしたり、ファイルサイズや中身を確認して録画時間推測したりとか出来るともっとかっこいいとは思うのですが、

Chinachuに録画ファイル無理矢理追加したスクショ

昔録画したファイルと、Chinachuで録画したファイル、まとめて検索できるようになったし、まぁいいか!


intelの4コアatomの乗ったPCを3万円くらいで組んでTV録画マシンに仕立てた。という雑文。

これまで、atom330という2008年ころのatomのベアボーンにfedora17+epgrecを適当に突っ込んで録画サーバに仕立てていました。で、去年の夏あたりからおそらく熱で勝手に電源が落ちてたりしたのでどうにかしなきゃなぁと思っていました。とはいえ、最近までいい感じに耐えてました。でも、この5月末に気温の上昇のせいかどうかはよくわからんのですが、一日に何度も落ちるようになってしまいました。なので、ああ、もうこれは新調待ったなしだなと思って思い切って新調しました。

新調に当たっては、やっぱり電源をつけっぱなしにするものなので、消費電力は小さいに越したことないし、atomで組んでみることにしました。

っていうかatomいいじゃん。かっこいいじゃん。atom。

ハードウェア構成

最近、intel windowsのタブレットが普及する要因をつくったbaytrailのデスクトップ版であるCeleron J1900で行こうと兼ねてから思っていたので、これを用いてざくっと組んでみました。
ちなみに、録画には、PT3を使うことにしました。

部品 商品名 大体の値段(100の位切り上げ)
マザボとCPU Celeron J1900 Mini-ITX Q1900B-ITX 10,000円
メモリ SO-DIMM PC3-10600 4GB 4,500円
HDD WD Green 3.5inch IntelliPower 2TB 8,500円
電源とケース IW-BL634B/300B 8,500円
地デジキャプチャーボード PT3 12,000円

しめて 43,500円。
キャプチャーボードがなければ31,500円でatomとはいえ4コアのマシンが組める時代ですよ。すごい。
ちなみに上記価格は3桁め切り上げていたりとか、、ケース+電源はPT3使用時特有の事情があって、ちょっと高いものを選ばざるを得なかったとか、HDDも1TBで十分だったりとか色々値段が上がる要素があります。で、削れるところをちくちく削っていけば25000円弱で組めるところまで確認ました。ほんといい時代だなぁと思います。

ちなみに、PT3を使うときにはケース側にPCIカードを刺す拡張スロットがあるケースを買わないといかんのです。小さいケースはこの拡張スロットがないものが多いので、これだけでぐっと選択肢が減たりとか値段が上がったりとかしてちと辛い。

ICカードリーダーは元の録画マシンで使っていたものを転用。ちなみにこれです。
日本国内だとすごく入手性がいいやつ。

ソフトウェア構成

最近foltiaの社長さんと知り合いになったので、録画マシン組み直しの際にはfoltia anime lockerを使いたい!って思っていたのですが、現行のfoltia anime locker version3はCentOS 6.4ベースで結構古め。回避方法があるかどうかはよくわからないのですが、インストーラーが上がって来ませんでした。USBの割り込みがうんぬんとか言って。ちなみに、CentOS 6.5のインストールもとりあえず試してみたものの、こっちもダメでした。

時間があれば腰を据えて原因究明といきたい所なのですが、自分がオーガナイズしているパーティーが近くて、それの準備だとかremix作りだとかもあって、あんまり時間をかけてもいられなかったので、とりあえずfoltia anime lockerについてはここで断念。

気を取り直して、debian 7.5(Wheezy) + chinachu で組んでみることにしました。
基本、chinachuのインストール手順どおりでいけましたが、libccidにちょっとした修正が必要でした。

http://baalzephon.no-ip.org/tech/index.php?Linux%2F%E3%83%86%E3%83%AC%E3%83%93%E9%96%A2%E9%80%A3%2Flibccid

あとはなんかすんなり行った。よかったよかった。

で、適当にmediatomb設定して、iPadやらから見られるように。

結果

いろいろ快適です。
chinachuにはavconvを用いてトランスコーディングしてくれる機能もあるのですが、この機能は性能的にぎりぎり使えるかな?という感じ。

思うこと

foltia anime locker 使いたかったけど、使えなくて残念でした。
fedoraベースだと、年がら年中ユーザにアップデートを要求することになるのでキツいのはよく分かるけど、CentOSベースも新しいハードウェアになかなか追従できなくて大変だなぁという気がしました。RHEL6.0リリースが2010年ですしねぇ。
とはいえ長期に使い続けることを考えると、10年間アップデートが行われるRHELベースであることが重要ってのも分かるけどー。わかるけどー。

製品へLinuxを適用する際の難しさみたいなものを、休日にもかかわらずモロに受けてつらかったです。

とはいえ、atomで録画マシン組みたいって思ってる人は自分以外にもたくさん居そうだし、使えたらいいのになぁ。実はちゃんと使えます、とかだったら、いいのになぁ。。


YLUG(Yokohama Linux User Group)のカーネル読書会で喋ってきました。

昨日、5月2日に(Yokohama Linux User Group)のカーネル読書会でプレゼンしてきました。

内容としては正直あんまりたいしたことなかったので特段スライドをアップしたりとかはしませんが、LKFTをよろしくお願いします、というないようでした。

http://lkft.sirrow.info/

Linux Kernelには日々昨日が追加されていくし、それを全部追いかけるのはなかなか大変です。
LKMLという公式のメーリングリストもありますが、流量が多いのでこれを追いかけるのも辛い。
で、Linuxは新しい機能が増えると、その機能を有効にするかどうかみたいな設定項目が増えるので、その増分をblogに自動postすればPCからでもスマホからでも観られるし、便利ですよねぇ。という発表でした。

「カーネル読書会」という名前に見合わないようなカジュアルな内容でしたが、非常に評判がよくて、楽しかった。もうちょっと色々工夫して便利に出来ればいいなぁと思えてきました。

お酒のみながらいろんな人と喋れたし、本当に楽しかった。行ってよかったなぁ。

あと、twitterのbotないの?って言われたので作りかけだったの、作りきりました。

http://twitter.com/lkft_bot


HHKBは矢印キーがなくて使い辛いわけでもemacsやviで使うことを想定していて硬派ってわけでもないと思う。

HHKBが好きで、googleでHHKBと検索しては、HHKBを扱っているblogなんかをニヤニヤと眺める日々を送っております。
そういったレビューを見ていると、

  • 矢印キーがなくて使い辛い
  • emacsやviで使うことを想定していて硬派

みたいなことが書いてあるわけです。

で、
やっぱり矢印キーがあるRealForceにしました! とか
矢印キーあるが日本語のHHKB Pro 2 にしました! とか
HHKB Lite 2 にしました! とか

書いてあるわけです。。

僕は、それって違うと思うんですよ!

むしろ、HHKB(英字)のFnキー押しながら使うあの矢印キーは、
これはこれで超使いやすい
って思ってます。

これが、HHKB Pro 2 のキーマップです。

ぱっと見、Fnキーも、同時押しで使う矢印キーも変な場所にあるなぁという気分になると思います。
だけど違う!そこが間違っている!

右手の小指でFnキーを押すと矢印キーがちょうど人差し指と中指の場所に来ます。

ちょっと右手を移動させて小指でFnキーを押すだけで、人差し指と中指で矢印キーが操作可能になるのです!

なるほど!と 思いませんか?!
これは楽だ! 思いませんか?!

思いますよね!

vi派やemacs派、コマンドラインで日常生活を過ごす人にとって矢印キーなど不要で、それを取っ払ったHHKBはかっこいい。確かにそうかもしれません。
しかし、矢印キーが必要なアプリケーションを使用する場合にも、まったく困らない。
いやむしろ矢印キーは押しやすい場所にあるんだと、あなたももう気づいたはずです!

さあ!みんなでHHKB Pro 2(英字)を買いにいこう!


第八回 カーネル/VM探検隊で3回喋ってきました。

https://sites.google.com/site/kernelvm/ima-made-no-matome/di-ba-hui-kaneru-vm-tan-jian-dui

4月13日に カーネル/VM 探検隊というカーネルやらVMやらの勉強会で3回ほど喋ってきました。

あと、この日は、Re:animation vol.5 もあって、スタートから1時間半ほど、こっちにも遊びに行ってきました。

http://reanimation.jp

で、この日の twitter の日本のトレンドに、#kernelvm も #reani_dj も上がっていて、俺が日本のトレンドだー!みたいな気持ちになりました。


LKFT -Linux Kernel Feature Tracker- というblogを始めてみました。

なんか大げさなタイトルのblogなのですが。。

http://lkft.sirrow.info

に作ってみました。

Linux に増えたコンフィグを延々と1日に1回、自動でpostするだけのblogです。

なんでこんなものを作ったのかというと理由はとても簡単で、

Linux Kernel に興味を持っている人はたくさん居るはずだよなぁと。
でもLinux Weather Forecast をはそんなに更新頻度も高くない。
かといってLKMLをかたっぱしから読む根性もない。

という状態にある人はたくさんいると思っていて、じゃあ、簡単にLinux Kernelに追加された機能について知る方法はないのか?と考えてみました。

その結果、新しく増えたKernelのコンフィグとその説明を見ればある程度分かるんじゃないかというところにたどり着き、せっかくだからkernelを毎回みんながgit pullしてきて見るのも大変だろうし、blogにしてしまうかーということで、さくっと作ってみました。

これで、ある程度、新しいカーネルの機能について知ることができますし、さらに興味を持って深堀りするための入り口にも。。
なるといいな。

とりあえずはv3.0から追加された機能をずらっとポストしてみました。
今後は毎日1回ずつ新しい機能がポストされます。

 

当分はうまく動かないこともあるかもしれないけど。。まぁ、頑張ります。