2020-01-07

git addするときにerror: 's/' does not have a commit checked outというエラーが出て困ったので原因を追う

小ネタです。

$ git add -A
error: 's/' does not have a commit checked out
fatal: adding files failed

addできない。困った。

何が起きているのか

$ ls
README.md  s/
$ ls -la s
total 12
drwxr-xr-x 3 masawada masawada 4096 Jan  7 16:46 ./
drwxr-xr-x 4 masawada masawada 4096 Jan  7 16:46 ../
drwxr-xr-x 7 masawada masawada 4096 Jan  7 16:46 .git/

どうやら s というディレクトリが作られていて、中に .git ディレクトリが作られている状態。しかしこんなディレクトリを作った記憶はない… 一体何故…

ディレクトリが作られた原因を探る

ひとまずhistoryを眺めたところ、いつもと様子がおかしいコマンドを発見しました。

$ git git s

自分はgitconfigのaliasで git s を git status -sb に指定しています。

[alias]
    s = status -sb

しかし git を重ねてしまっているのがおかしそう。実行してみましょう。

$ git git s
WARNING: You called a Git command named 'git', which does not exist.
Continuing in 0.1 seconds, assuming that you meant 'init'.
Initialized empty Git repository in /home/masawada/sandbox/git/s/.git/

やはりこれが原因でディレクトリが作られていた!! しかし平時は git git と重ねても単にエラーが出て終了するだけです。

assuming that you meant 'init'

これはgitconfigでautocorrectを有効にしているから。git git と重ねると git init に補完されてリポジトリのディレクトリが作られてしまう、というオチでした。

[help]
    autocorrect = 1

autocorrectについてはこちら

git-scm.com

2019-12-02

年始にLinuxデスクトップを使い始めて1年が経とうとしている

これははてなエンジニア Advent Calendar 2019 2日目の記事です。

こんにちは、 id:masawada です。2ヶ月前まではブログチームのエンジニアでしたが、最近はマンガビューアを開発するチームに在籍しています。

弊社では開発に利用する端末を決められた上限額の範囲内で自由に選ぶことができます。多くのエンジニアがmacOS上で仕事をしており、WindowsやLinuxをデスクトップ環境として利用しているエンジニアはどちらかというと少数です(少なからずいます)。近年では多くのプロダクトのローカル開発環境でDockerを利用できるようになっており、OSの差異によってセットアップに躓くことがなくなった結果Linuxデスクトップへの移行のハードルが下がる傾向にあります。

自分も去年まではmacOS上で仕事をしていましたが、今年の頭にLinuxデスクトップに切り替えてようやく1年が経とうとしています。この記事では具体的にmacOSからどうやってマイグレーションしたのか、Linuxにして良かった点・困った点などを紹介します。

どういう環境を利用しているか

まず普段自分がどういう環境で仕事しているかをご紹介します。

端末: ThinkPad T480
- フロントバッテリあり
- オプション品: ThinkPad バッテリー 61++, ThinkPad Thunderbolt3 ドック
OS: Arch Linux

購入当時最新だったThinkPadのうち、ArchWikiで動作確認が取れているものを選択しました。Xシリーズはいつのまにかバッテリの取り外しができず、RJ45も廃止されていたので検討から外しました。オプションでフロントバッテリを選択しており、リアバッテリのホットスワップが可能なようにしています。実際、6セルのリアバッテリもあわせて購入しており、会社に居るときと自宅に持って帰るときで付け替えられて便利です。ThinkPad Thunderbolt3 ドックはネット上で動作するか確認できませんでしたが、まあ問題ないであろうということで購入しています。ThinkPadだと全部あわせて予算に収まるのでお財布にも優しいですね。

基本的にオフィスツール系がG Suiteで完結しておりMacやWindowsでしか開けないものはエンジニアはほぼ扱わないので、その点で困ることはありません。強いていうならiOSアプリエンジニアへの転向ができないくらいです。

なぜLinuxデスクトップにしたのか

丁度PCの更新時期が近づいたためリプレース先を検討し、Linuxデスクトップにしました。具体的には以下のような課題を解決したいという意図がありました。

ソフトウェア的な課題
- Docker for Macのオーバーヘッドが大きいように感じる
- LinuxとmacOSではGNUとBSDのツールでオプションが違って難しい
ハードウェア的な課題
- バタフライキーボードよりはストロークの深いキーボードが好み
- Vimを使っているので物理Escが欲しい
  - ctrl-[ もあるけどネ
- RJ45が欲しいときがある
  - ないですか? ぼくはあります

どのようにマイグレーションしたのか

macOS上でLinux環境をプロビジョニングする仕組みをdotfilesに整備して移行しました。突然移行したとしても仕事ができないのは容易に想像がつくので、まずは業務の傍ら環境をせっせと作って、最後に一気に移行するというモデルです。

まずはmacOS上のVirtualBoxにArch Linuxの環境を用意してデスクトップ環境を用意しました。OSのインストールはスクリプト化しており、スクラップアンドビルドが容易な状態にしています。netinstのイメージを立ち上げて以下を実行するだけでインストールできるようになっています。最近は実行してませんが多分動くはず。

$ NEW_USERNAME=masawada bash -c "$(curl -fsSL https://dot.masawada.me/scripts/os_install)"

ちなみにこのスクリプト、 /dev/sda があることを想定して書いているのでThinkPad上では動きませんでした。なぜならディスクが /dev/nvme0n1 にマウントされていたため。その場で適当に書き換えて利用しました。

次にGitHubに公開鍵を登録します。プロビジョニング走行時には git clone をするので公開鍵が登録されていてほしいですが、当然デスクトップ環境がないので登録が困難です。そこで公開鍵を登録するスクリプトを用意しました。以下のコマンドで公開鍵をGitHubに登録できます。

$ bash -c "$(curl -fsSL https://dot.masawada.me/scripts/setup_github)"

以前書いたこの記事は、今回のための伏線でした。

masawada.hatenablog.jp

ここまでを終えた状態で、ちまちまプロビジョニングファイルを書いていきます。プロビジョニングにはmitamaeを利用しています。Itamaeのmruby実装で、バイナリをGitHub Releasesから引っぱってくるだけで実行することができます。これにより、プロビジョニングする環境を整える手間を省いています。ディレクトリ構造などは k0kubun/dotfiles を参考にさせていただいています。

roles/arch/default.rb を見ると具体的にどのようなソフトウェアをインストールしているかを確認することができます。あまり凝ったことはしていませんが、 polybar のビルドに時間がかかりsudoがタイムアウトしてしまうので、一時的にこれを防ぐ処理をしています。この実装は cookbooks/functions/default.rb にあります。

また、今回の過程で masawada/mitamae-plugin-recipe-plenv と masawada/itamae-plugin-recipe-nodenv を作ったのでよければご利用ください。

プロビジョニング自体は

$ bash -c "$(curl -fsSL https://dot.masawada.me/install)"

で実行できるようにしています。適当なドメインを取って自分のdotfilesのrepoへリダイレクトするように設定しておくと便利です。自分はドメイン( dot.masawada.me )をAWSのCloudFrontに向けておいて、OriginをS3のバケットに設定し、S3のStatic web hostingの設定で全てのリクエストをGitHubのファイル配信URLにリダイレクトしています。

よかったこと

最初に挙げた課題については全て解決しました。特にDockerについては、babelによるトランスパイルがだいたい3,4倍くらい高速化しました。マシンスペックの差による部分もあるはずで、実際には2倍ちょっとくらいには高速化してるんじゃないかなーと思っています。少なくとも docker-compose up してファンが高速回転することはなくなりました*1。この効果は結構大きくて、以前よりも快適に開発ができるようになったと感じています。

その他特筆すべきことはありませんが、特筆すべきことがないくらいには手に馴染んでおり満足しています。

困ったこと

マルチディスプレイ周りの挙動が怪しい

予想はしていましたが、マルチディスプレイ周りの挙動が怪しいです。ディスプレイの設定には xrandr を使うことになるのですが、ThinkPad Thunderbolt3 ドックを利用している場合、1コマンドで複数オプションを付けてマルチモニタ設定を行うと、抜き刺ししたときに xrandr 上では認識されているにも関わらずサブディスプレイの画面が表示されなくなります。xrandr をモニタの回数分発行することでこの現象を回避できます。

自分はディスプレイの設定を自動化するスクリプトを作っていて、F7を押下することでこれが実行されるようになっています。上記の問題については、このスクリプトの以下の修正で解決しました。

https://github.com/masawada/dotfiles/commit/a23480534f1f51b8299dcc6f0e53875d3258551b

Bluetooth周りが微妙に不安定

接続時にうまく掴まえられなかったり、繋いだままサスペンドしたときの挙動などが微妙に不安定で、BluetoothキーボードやBluetoothイヤフォンを使わなくなりました。キーボードについては、最近はHelix Picoを利用しています。イヤフォンについては、もともとSpotifyで音楽を聴いていたのでイヤフォンの接続先がスマートフォンになっただけで、操作はSpotifyのWebプレイヤーからするようにしています。Hangout等は直接有線のイヤフォンを刺すことにしています。

FAQ

LTSじゃないんですか?

はい。まあデスクトップだし、LTSじゃなくても派手に壊れることはないであろうというマインドでやっています。ほぼ毎日 pacman -Syu していますが、1年を通して派手に壊れたことはありません。せいぜいシャットダウン時にハングすることがあった、放置してサスペンド状態になると復帰しないことがあった、くらいでした。派手に壊れたら代替機(空き状況によるけどおそらくmacOS)を借りられるので、そのときはそのときと割り切っています。

次のPCもLinuxにしたいですか?

はい。先にも書いたとおり現状は特に致命的な不満はないです。指紋認証がなくて毎度パスワードを打っているのが若干大変くらいです。もともと使ってたMacBook Proにもなかったのでそんなに苦ではないです。

他のエンジニアにもLinuxデスクトップを勧めたいですか?

いいえ。自分は好きでLinuxデスクトップを使っているので壊れたら直すし使いづらかったら改善するので良いのですが、他のエンジニアがそうとは限らないし仮にも毎日使う端末なので直すのが苦痛というひとには全く合わないため強く勧めたりはしません。移行自体も準備するのは一苦労なので、やはり好きでなければ難しいでしょう。会話の流れで提案することはあります。

以上Linuxデスクトップに移行した話でした。細かい話題は書ききれなかったのでまたどこかで記事にしようと思います。

明日は id:yigarashi です。

*1:自分はこの現象を離陸と呼んでいます

2019-11-15

Vim + aleで保存時にperltidyを実行してコードを整形する

aleはこちら。非同期でLinterを実行したり、autofixしたりといった作業をやってくれるいつものやつ。

github.com

$ cpanm Perl::Tidy

して Perl::Tidy をインストールしつつ、aleが入っている状態で .vimrc に

let g:ale_fixers = { 'perl': ['perltidy'] }
let g:ale_fix_on_save = 1
let g:ale_perl_perltidy_options = '-pro=.../.perltidyrc'

すると完成します。

http://perltidy.sourceforge.net/perltidy.html

によると

A pathname begins with three dots, e.g. ".../.perltidyrc", indicates that the file should be searched for starting in the current directory and working upwards. This makes it easier to have multiple projects each with their own .perltidyrc in their root directories.

とのことで、この指定をしておくとcwdから親のディレクトリに向けて.perltidyrcを探しにいってくれます。これでホームディレクトリの設定に優先してプロジェクト毎の設定を反映してfixできますね。

2019-10-12

近況

これまでアルバイト期間含めて4年程度はてなブログの開発に携わっていましたが、今月の頭にマンガのビューアなどを作る部署へ転属になりました。

肩書きとしてはWebアプリケーションエンジニアなので普段はPerlとTypeScriptを書きつつ、ここ1年くらいはインフラ周りやプロジェクト管理補佐、チーム内外のサポートみたいな部分にも手を出しつつありました。直近ではインターン関連タスクのチーム内ディレクション役として携っていました。歴としても結構長くなってきており、そろそろ環境を変えたいなと思い、今回の異動を自ら希望した次第です。あとアニメとかマンガが好きなのでそこに貢献したかったというのもあります。異動したての今は言語こそほぼ変わらないものの、コードベースもチームの文化もなにもかも違うので新鮮な状態です。ちなみに具体的にどういう技術スタックでやっているのかはここに載っています。

一般的な会社だと新しいことに挑戦したい場合は転職するのが一番最初の選択肢として挙がるのではないかと思いますが、弊社の場合はたくさんのプロダクトをやっているので部署異動が実質転職ぐらいにドラスティックに環境を変える手段になって面白いです。アルバイト以外で転職したことないので根拠は薄いけど…

そんなはてなで働いてみたいという方はぜひご応募ください。会社の様子を聴きたいという方はランチで会話するのも歓迎です(会社でランチを食べられます)。Twitterなどで声をかけてくだされば調整します。

Twitterはこちら → @masawada

2019-05-07

freetypeのバージョンを2.10.0に上げたらfc-listにSijiが出てこなくなったので直す

polybarのアイコンフォントにSijiを使っているんだけど、突然壊れた。