HPCメモ

HPC(High Performance Computing)に関連したりしなかったりすることのメモ書き

モバイルモニタ導入

最近、モバイル環境を強化中なんですが、まずは手軽にできるところからということで、サブディスプレイを導入しました。

この手の用途では定番のGeChic on-Lapシリーズだと13インチモデルは約4万円。

ところが、こちらのcocoparなる会社(?)の製品だと約半額の2万円程度。しかも、HDMI2系統な上にVESAマウント対応の穴があるということで、こっちを買ってみました。

以前のモデルでは、amazonのレビューに「穴は空いてるけどネジが切られていない」とか書かれてましたが、改善されていたようです。*1 とりあえず、こんな感じでM4の長ネジを差し込んで超簡易スタンドのできあがり。

f:id:n_so5:20180710141552j:plain

肝心のディスプレイの性能ですが、とりあえず仕事中にサブモニタとして使ったり、Fire stick TVを挿してPrimeビデオで動画を見る程度なら特に問題は無さそうです。 背面の操作ボタンのところの加工精度が甘いのか、ちょっと振るとボタンが筐体と当たって音がしたり、ボタンによって出っ張り具合が違っていたりと、かなりチープな感じはしますが、そんなことより値段が安い方が良いという方には、お勧めできる製品です。

f:id:n_so5:20180612112557j:plain

あ、あと筐体の塗装がヤワなので、付属のスタンドと一緒に持ち運んでたら、背面にざっくりと傷がつきました・・・orz 多少傷がついたところで、動作に支障は無いので私は気にしませんが、気になる方はケースも付属しているGeChicの方が良いかもしれません。

*1:しかし旧モデルも併売してるっぽいので要注意

vue-cliでwebアプリ作成

ちょっとしたwebアプリをスクラッチで作る機会があって、vue-cliを使ってみようと思ったんですが、先人の解説記事どおりにやっていると

vue init webpack new-project

  Unknown command init.


   vue-cli · Failed to download repo vuejs-templates/[object Object]: Response code 404 (Not Found)

といった感じで怒られます。

公式webページを見ると

npm install -g @vue/cli
# or
yarn global add @vue/cli

vue create my-project

と書かれてて、そもそもパッケージ名からして違う・・・

とりあえず、initが無いって言ってるから、公式推奨のcreateをしてみると

vue create new-project

  Unknown command create.
  vue create is a Vue CLI 3 only command and you are using Vue CLI 2.x.

どうやら、メジャーバージョンが上がって色々変わってるようです。

というわけで、長い前置きでしたがvue-cli 3系列をちょろっと触ってみたメモです。

インストール

ドキュメントにある、

Zero config rapid prototyping via @vue/cli + @vue/cli-service-global.

というのを試してみたいので、このふたつをインストールします。

> npm install -g @vue/cli @vue/cli-service-global

新規プロジェクト作成

vue create new-projectとするとcursesっぽいテキストベースのメニューが現れて色々選択できます。

が、今回はこちらは使わずに、vue serveコマンドの方を使っていきます。 ドキュメントにあるように、とりあえず適当なvueファイルをApp.vueという名前で作成してコマンドをたたくとビルドしてからサーバを起動してくれます。

> echo '<template><h1>Hello!</h1></template>' > App.vue
> vue serve -o
 DONE  Compiled successfully in 1164ms                                                                                                                                                            21:56:50

 
  App running at:
  - Local:   http://localhost:8080/ 
  - Network: http://192.168.0.31:8080/

  Note that the development build is not optimized.
  To create a production build, run npm run build.

vueファイルの名前をApp.vue(またはapp.vue)以外にする場合は、この後に続けてファイル名を指定します。 また、-oオプションは、ビルド後にブラウザを開いて表示するという指定なので、不要であれば外してください。

f:id:n_so5:20180531223630p:plain

あとは、ゴリゴリとApp.vueファイルを更新すればとりあえず動くものはできるはずです。

this is only recommended for rapid prototyping.

とのことなので、ある程度のものができたら createでプロジェクトを作ってそっちに移行する方が良さそうですが。

docker環境構築 on Mac

travisCIでdockerを使えばubuntu以外の色々なOSでテストができるらしいということを知って、試行錯誤していたんですが try and errorで.travis.ymlを書き変えてはgithubにpushしてtraviCIに「ちゃうでー」と怒られるのを繰り返すのが辛くなってきたので 手元のmacにdockerの環境を作ってみました。

必要なのはこれだけ

> brew cask install docker
> open /Applications/Docker.app

アプリが立ち上がって、パスワードを聞かれるので正直に答えるとdockerが使えます。

> docker --version
Docker version 18.03.1-ce, build 9ee9f40
> docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

> docker run -it ubuntu bash
# uname -a
Linux 562794c23cf8 4.9.87-linuxkit-aufs #1 SMP Wed Mar 14 15:12:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>docker rm `docker ps -a -q`
562794c23cf8
df64e1d5290b
9da30ff61d16
384cdda9dd3a
````

vagrantでvirtual boxを立ち上げるのに比べると、格段に早いですねー

まーchroot環境(微妙に違うか)だから、障害対応とかはvagrant + virtual boxで再現環境を作らんとだめだろうけど、普段の開発はこっちでも良いような気がしてきた。

あとはdocker環境でテストが動くように書き換えてから、.travis.ymlに再挑戦か・・・

git stash popで発生したコンフリクトを解消する。

さきに参考URL

dackdive.hateblo.jp d.hatena.ne.jp

こんな流れで作業していてはまりました。

あるファイルを編集中に障害の調査をしなきゃならん事態が発生

編集中のファイルをstashして同じブランチで障害の調査を開始*1

デバッグコードを埋め込んだり、ついでに見つかったバグを修正したりでstashした時に修正中のファイル以外を修正

さて、編集したファイルは被ってないからstash popするべー*2

あら、コンフリクトしてますな・・・

という状況です。

"foo" "bar" "baz"の3ファイルがリポジトリにあったとすると fooとbarは手元のファイルを残して"baz"だけstashしてたものをとり込むという操作をやりたいのです。

こんな時はこんな感じで、必要なファイルだけをstashからcheckoutして上書きできます。

> git checkout --theirs stash@{0} baz

この後、bazはgit stashした時のファイルに戻って、さらにgit addされた状態になってます。 stashの方も残ったままなので、不要であれば

> git stash drop

して消しておきましょう。

stashしたものだからpop時のオプションでなんとかなるだろうと思って調べてたんですが、どうやらそういうわけではないようです。 しかし、スタックに積んでおいて全部出さずにちょっとだけ持っていくとかお行儀悪いなwww*3

*1:これがそもそもの間違い。一旦ブランチを切って保存した上で元のブランチから調査用のブランチを切るべき・・・なんだけど作業を始める時の精神状態だと全部破棄してstash popで戻ってくりゃおっけーって思うんですよねorz

*2:一時的に修正中のファイルをリネームしてgit checkoutしたような感覚でいたけど、stashはあくまでworking directory全体を保存してるので別のファイルを弄ったらそりゃーコンフリクトしますね・・・

*3:いや、最終的にはdropしてるけど・・・

mermeidのサポート状況

今までgitlabのこと微妙なやつだと思ってたんですが、markdownでmermaidをサポートしてたんですね!!

docs.gitlab.com

普段使っているbitbucket & githubでどうなるかというと、こんな感じでただのコードブロックとして表示されます。*1

bitbucketの場合 f:id:n_so5:20180405220451p:plain

githubの場合 f:id:n_so5:20180405220459p:plain

ところがgit labだとこんな感じでグラフとして表示されます。 f:id:n_so5:20180405220255p:plain

ちなみに、はてなだと

graph

graph TD
    A-->B;
    A-->C;
    B-->D;
    C-->D;

sequence diagram

sequenceDiagram
    participant Alice
    participant Bob
    Alice->John: Hello John, how are you?
    loop Healthcheck
        John->John: Fight against hypochondria
    end
    Note right of John: Rational thoughts <br/>prevail...
    John-->Alice: Great!
    John->Bob: How about you?
    Bob-->John: Jolly good!

gantt chart

gantt
        dateFormat  YYYY-MM-DD
        title Adding GANTT diagram functionality to mermaid
        section A section
        Completed task            :done,    des1, 2014-01-06,2014-01-08
        Active task               :active,  des2, 2014-01-09, 3d
        Future task               :         des3, after des2, 5d
        Future task2               :         des4, after des3, 5d
        section Critical tasks
        Completed task in the critical line :crit, done, 2014-01-06,24h
        Implement parser and jison          :crit, done, after des1, 2d
        Create tests for parser             :crit, active, 3d
        Future task in critical line        :crit, 5d
        Create tests for renderer           :2d
        Add to mermaid                      :1d

やっぱ駄目かー

今だと簡単な図を作るのにも、画像として挿入する必要があるので、本文は更新されてるのに図だけ古いままなんて状況になることが多くて困ってるので、ぜひgithubやbitbucketにも追従してもらいたいところです。 ついでに、はてなの脚注機能(はてな記法と同じく二重括弧でくくると中の分が脚注として表示される機能)も便利なので、他のサイトでもサポートしてくれると有り難いなー*2

*1:各グラフはmermaidの公式ページにあるサンプルです

*2:Quiitaの脚注が使い難いのでアカウントは作ったけど、ついついはてなに書いちゃうんですよね・・・

タブレットPCスタンド

去年購入したASUSタブレットPC(surfaceっぽいやつ)がスタンドを立ててキーボードを手前に置くと画面の下の方が隠れて見えなくなるので、何種類か上方に持ち上げて保持するタイプのタブレットスタンドを使ってきたんですが、どれも使いはじめて1、2ヶ月もすると歪んでしまってディスプレイが水平を保てなくなってしまいました・・・

結構気持ち悪いのでどうしようかと悩んでたんですが、ふと思い立ってカメラ用の三脚と三脚にタブレットを保持する台を導入してみました。

サンコー カメラ三脚用タブレットデスク CLHCMAN3

サンコー カメラ三脚用タブレットデスク CLHCMAN3

Manfrotto ミニ三脚 PIXI ブラック MTPIXI-B カメラ用

Manfrotto ミニ三脚 PIXI ブラック MTPIXI-B カメラ用

このマンフロットの三脚についてる雲台が、あまり下を向けられないので、雲台on雲台とかいう間抜けな状態にはなってますが、一応満足できるスタンドが完成しました。

1/4インチネジのメス同士を90度くらいで固定できれば良い話なので、アルミブロックを買ってきてネジを二本埋め込んでから頭を飛ばせば良いのかなーとか考えてたんですが、既にそれっぽい製品があるんですね・・・

panproduct.com

これと接合用のネジを2本買えばビシっと決まるけど総額1万円を越える高級タブレットスタンドになりそうですo...rz

f:id:n_so5:20180307152726j:plainf:id:n_so5:20180307152743j:plain

【結論】 タブレットは机の上に直置きでキーボードを膝の上に置けば良いんじゃないか?

git mergeで特定のファイルを取り込む

別のブランチで修正したファイルの一部だけを取り込む必要があってぐぐってたんですが、なかなか同じシチュエーションの人が居ないようなので作業の記録を残しときます。

git mergeに特定のファイルを指定するようなオプションは無いので、ちょっと面倒ですがmerge -> 不要なファイルをreset ->commitという流れになります。

実際に使うコマンドはこんな感じです。

> git merge --no-commit -Xtheirs {mergeしたいブランチ名}
> git reset HEAD {mergeしたくないファイル名}
> git checkout {mergeしたくないファイル名}
> git commit

ぐぐるとcherry-pickでできるよ!みたいなことが書かれてるページもあったけど、cherry-pickはあくまで個別のコミットを適用するだけなので、mergeするブランチ側で同じコミットに必要なファイルと不要なファイルが混ざっていたり、複数のコミットでmergeしたいファイルを編集してると難しいです。*1

mergeするファイルが少なければ、こちらでやられているようにmergeするブランチ側でパッチを作って適用というのも一つの手だとは思います。今回は、mergeするファイルが大量&バイナリファイルがかなり含まれていたので使いませんでしたが。*2

blog.bgbgbg.net

*1:1回mergeされる側のブランチでコミットを分割してやればできそうだけど、面倒そう・・・

*2:merge commitの履歴が残らないというのも人によっては気になるかもしれませんね