4K モニタを 2 枚買った

27 インチの 4K モニタを買いました。
LG の 27UL650-W というモデルで、1枚あたり4万3千円くらいでした。
電車が人身事故で止まってしまい、仕方ないなといって降りた駅近くにあった電器屋さんで見かけて、ベゼルも狭くてシンプルな出で立ちだし、これいいんじゃないか?って思ってこれに決めました。

https://www.lg.com/jp/monitor/lg-27UL650-W

これまでは、12年ものの 24 インチの WUXGA のモニタを 2 枚、縦にモニターアームを使って積んでいましたが、今回同じように縦に積みました。
12年も使ったんだから、もう流石に新調していいだろうって。

モニターアームは、24 インチから 27 インチに大きくなったんだから、モニターアームも長いものにしなきゃと思ったんですが、実際には長くする必要がなくて、上の方にはみ出してしまってなんか不格好になりました。
これは高さが 70cm あるんですが、60cm くらいで充分足りました。これはちゃんと計算すれば事前にわかったことなので、反省。

高解像度のディスプレイを使ってみて思ったのだけど、パソコンの文字が読みづらいと感じる一端は、解像度の不足だったかもしれないなーって思った。解像度が高いと単純に文字が読みやすくなる。

MacOS で使ってみた

最近 Macbook Pro 13 を買ったので、thunderbolt から hdmi への変換を 2 つ買って、2 枚のモニタに表示してみました。
仮想解像度は、2560 x 1440 くらいが、自分にはちょうどよかったです。
確か、27インチの5KディスプレイのiMacも仮想解像度の横幅が2560だったはずだなので、作ってる側も想定しているくらいの密度なんだろうなーと勝手に思いながら使っている。
画面に出せる情報量が増えて、文字もきれいで読みやすくなったので大満足。

主にブラウザ、vscode、IntelliJ、terminal くらいしか使っていないので、特段困ったことはありませんでした。
昔から高解像度モニタに対応しているからストレスなく使えるなーって感じ。

Windows 10 で使ってみた

Scaling は 175% にして使ってみた。
ブラウザ、vscode、IntelliJ あたりはまともに動く。

Studio Oneもまともにうごく。一部のvstプラグインについては、Studio One 側の機能であるスケーリングがまともに効かない。
普段から使用頻度が高いVSTがうまく動かなかったりするのでそこそこストレスフルだけど、まぁ許せる範囲。

Arch Linux(xfce4) で使ってみた

上記 Windows 10 にインストールされた VirtualBox 上に作った Arch Linux の VM に、以前から xfce4 環境を構築していたものの設定を変更。
設定を変更したのは下記URLに記載のある1箇所だけ。何の問題も生じていなくていい感じ。

https://wiki.archlinux.jp/index.php/HiDPI#Xfce

ノートPCを新調したりVPSを乗り換えたりした

なんか、最近、普段家で使ってるコンピューター周りを色々変えたのでそれについて書いてみる。

ノートPCを新調した

2014年頃のmacbook air 11inch から、色々悩んで2019年のmacbook pro 13inchのusb c端子が4つついてる方に乗り換えた。VMなどをそれなりに動かすことになるだろうと考え、メモリは16GB、SSDは512GBにした。
新調の一番の理由は、コタツを導入したのでコタツで色々できるようにしたかったけど、それには5年前のmacbook airでは主にメモリの量を中心に辛いと感じることが増えてきたこと。
新調にあたっては、現行の各種macbookはusb cしかついていないことが気に食わず、windows のノートPCにしようかなとも思ったのだけど、そうすると、ctrl + p,n,f,b あたりでのカーソルの移動ができない場面が増えてストレスを溜めるのだろうなぁと思ってしまったので、結局macにしてしまった。

usb cについては、実はあんまり外に何かを付けて使うということ自体がないけれど、もしもつけたとしても、電源やら画面やらを1本のケーブルにまとめられて、今はもう便利だとしか思わない。
昔は、usb cからいろんな端子に変換するための変換器みたいなのの種類が少なかったり値段が高かったりで大変だったみたいだけど、2019年だともうそんなでもないのかなと思った。

そんな感じで、家に帰ってきてもコンピューターいじるときは机と椅子に座ってガッツリと向き合うしかなかった状態が、こたつで緑茶でも飲みながらのんびりと色々する、みたいに変わった。

あと、結構前だけどテレビにkindle fire tv stickを刺した。なので、家族と一緒にスマホで撮った写真をみたり、webページを一緒に眺めたりといったときも、kindle fire tv stick に Air Playで接続してさっさとテレビに画面を表示できるようになった。これが想像以上に便利で、テレビは見るだけのものから、家族の間で情報を共有するための道具に変わってきたな、みたいな意識の変化があった。

windowsのノートPCを選んでいたら、Air Playではなくmiracastで画面を表示することになると思うんだけど、miracastについては使ったことがなく、どの程度使い勝手が良いものなのか知らない。実際のところどんな感じなんだろうか。

VPS乗り換えた

かれこれ7年くらい、sakuraのVPSを何度かインスタンスのタイプを乗り換えつつメインで使い続けてきたけど、支払いが月極なので、遊ぶ際にインスタンスを新しく作ったり破棄したりといったことがやりづらくて辛いという理由で、色々お試しするときののVPSについては別の海外のVPS業者の日本リージョンを併用している状況が1年ほど続いていた。
(sakuraにおいて、インスタンスを上げたり壊したりといった用途には、おそらくsakuraのVPSではなくsakuraのクラウドが想定されている。だから、自分がsakuraのVPSがターゲットとする客ではなくなってしまったので辛いという話であって、sakuraのVPSのサービス内容が良くないというわけではないと思う。)
海外VPSを1年使って、これと言ったトラブルも特になかったため、sakuraの方は引き上げ、海外VPSの方に一本化した。
もともとsakuraにメモリ2GBのインスタンスが1台、海外VPSの方にメモリ1GBのインスタンスが1台あったが、これを4GBメモリの海外VPSに1台にまとめた。
値段的にはsakuraのメモリ2GBと海外VPSのメモリ4GBが同じ価格だったので、月々の支払いは減ることになったし、管理対象も減ったし、いい感じだなーと思っている。

引っ越しにあたり、勉強も兼ねて、ホストOSの上にソフトを色々インストールするのは控え、全部dockerコンテナの中に入れた。全部のサービスをdocker-composeで管理するようにした。
結果として、自分がどういうサービスを立てているのかということが明確になって、覚えておかなきゃいけないことが減ったので良かったなぁと思った。

あ、なので、このblogも実はお引越ししたあとだったりします。なんとなくテーマも変えました。

k8s のクラスタを組んでその上に全部移すということも考えたけれど、自分が動かしっぱなしにしておきたいアプリケーションの総量に対して、k8s 自体の主にメモリに対するオーバヘッドが大きすぎてなんかもったいない気がしたというのと、スケールアウトしなきゃいけないほど上で動くアプリケーションが増えたり減ったりするわけでもなく、コンテナ冗長化をかっこよく行う必要も特にないなーと思ったので、シンプルにdockerとdocker-composeで全部済ませてしまうことに今回はした。
k8s がこなれてきて、オーバヘッドがあんま気にならないくらい小さくなってくるというか、オーバーヘッドが小さい構成も手軽に組めるように状況が整ってきて、自分自身がそれを使いこなすノウハウがこの先数年で溜まったら、k8sベースにすることもあるのかもしれない。と思う。

なんかまぁ、そんな感じです。
全部コンテナに入って取り回しが良くなったので、調子よく色々やっていきたいなー。

複数マシン間で、atomで取ったメモを同期するための環境を整えた

自分は、いろんな作業をするときに、人に報告したり、twitterに書いたりするほどでもないことを、atomを使ってmarkdown形式でメモをとりながら進めています。
1台のマシンでメモを取るだけなら、シンプルでいいんですが、VMを含め、複数台のマシンを行ったり来たりしながら作業するとなると、これらの間でどうやってメモを同期するか、という点が悩ましくなってきます。
今回のエントリは、どうやってatomを用いて、複数のマシンでどうやってメモを同期させるか考えたっていう、そんなお話。

TL;DR

  • atomのsync-on-saveはとても良い
  • WindowsとLinuxだとパッチ当てないと動かない(2017年10月12日時点)

gitでメモの同期をとりたい。でもコマンド打つの、面倒だな。

ファイル単位で同期を取る仕組みというのは、atomには色々あって、たとえばRemote-FTPというパッケージで実現することができます。
最初はこれを使っていたんですが、同期の粒度がファイルだと、複数のマシンで同じファイルを変更したときに、どちらかがどちらかをうっかり上書きして、せっかく書いたメモを失う、なんてことになりそうだなと思いました。
実際に上書きをしてしまったことはなかったものの、そういうことが起こりうるということを意識しなければならないのがなんとなくストレスでした。

だから、ファイルよりも小さい単位で同期を取りたい。
そうだ!僕達には、gitがある!gitを使おう!と考えました。

でも、gitも、コミットメッセージを書いたり、共有のためにpushしたりと、やらなければいけないことが多くてちょっと面倒です。

sync-on-save というパッケージに面倒事を引き受けてもらう

どうせ、自分が適当に見るメモなんだから、コミットメッセージなんて適当に自動でつけてくれればいいし、pushも勝手にやってくれればいいのに。
そんなパッケージないかなー?と探してみたところ sync-on-saveというパッケージがありました。

このパッケージを使って救われました。本当に欲しいものそのものでした。
コマンドパレットからEnable Syncすると、ファイルを保存したタイミングでgit commitとgit pushを自動でしてくれます。
あとなんか他の場所で同じファイル編集してたらmergeもしてくれる。

本当に便利だ。素敵だなぁ。

LinuxとWindows向けにバグがあって動かなかった→なおした

バグを見つけたので直しました!バージョン0.1.5からは何も考えずにATOMのパッケージをインストールすれば使えるようになりました!
みんな使ってみてね。

2017年10月12日時点でダウンロード可能な、バージョン0.1.4にはちょっとしたバグあり、WindowsとLinuxでは動きません。
直したのでプルリク投げてみるつもりです。

差分は1行なので、これ読んで今すぐ使ってみたい!って思った人は、sync-on-saveをインストールした上で、コードを直接いじるのが楽そうです。
コミットの情報はここにおいときますので参考にしていじってみてね。

https://github.com/sirrow/sync-on-save/commit/7df50d7094156b9fd030ab698a6ff69a680177af
おしまい。

本文に書ききれなかったけど書きたかった事

sync-on-saveを作った人について

sync-on-saveを作った人すごいなぁ、ありがたいなぁ。プルリクも投げなきゃいけないし、どんな人なんだろう?って思ったので調べてみたら、 Hajime Morita さんでした。
そういえば、rebuild.fm 聞いたことないし、今度聞いてみよう。

昔はssh + screen + emacsでメモを取ってた

自分は一昔前は、VPS上でscreenを動かして、その上で動かしたemacs -nwに、色んなマシンからsshでログインした上でattachしてメモを取ってました。
これはこれで悪い方法じゃなかった気がします。手軽だしね。ただ、ネットワークから切断されるとつらいんだこれ。
gitなら手元にコピーあるからネットワークなくても編集できるしね。そんなところが素敵。

タスク管理を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ならこの手順で大丈夫なはずです。

sudo yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
sudo yum install python-novaclient

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

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

novaコマンドの設定

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

export OS_USERNAME=APIユーザのユーザ名
export OS_PASSWORD=APIユーザのパスワード
export OS_TENANT_NAME=テナント情報のテナント名
export OS_TENANT_ID=テナント情報のテナントID
export OS_AUTH_URL=https://identity.tyo1.conoha.io/v2.0

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

novaコマンドを使ってみる

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

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

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

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

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

以上です。