はてなブックマーク

概要 最近 (Electron になった v10 以降) の Evernote が重すぎて、単純に起動するのにも待ち時間があり、起動中もあらゆる動作が重くてメモ用途には使うにはストレスを感じることが多く、どこかのタイミングで移行しようと思っていたので、時間を取ってがっつり移行をした。 Evernote が Electron を採用したことも最悪なのだが、M1 Mac が一般に発売されてから 1 年経とうとしているのにも関わらず一向に M1 対応される気配はなく x86_64 バイナリを Rosseta 2 経由で動かさざるをえないのも最悪で、とにかく重たいし、起動しているだけで本体がほんのり熱くなりバッテリをガンガン持っていく。ただのメモアプリとして使っているのにこれは良くない。 Activity Monitor.app で見た図が以下。 Evernote がとにかく電力食いであることが分

GNU coreutils を入れてる M1 Mac で Python 3.x のビルドが通らないのをなんとかする。 # GNU 版での表示 $ uname -a Darwin MBA101.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 arm64 arm64 MacBookAir10,1 Darwin 結論 記事タイトルで半分くらい言っているのだが、 M1 搭載機では GNU 版 uname の出力が BSD 版 uname と異なっており、 config.guess にてその出力を利用しているのが原因だった。 わざわざ GNU 版 coreutils なんかを入れて普段使いしてる人間は少ない模様。ググって

概要 タイトルで全部言っているんだけど、 therubyracer や mini_racer や libv8 や libv8-node あたりの消耗しがちなやつや問題が起きがちなやつは execjs が入っていればそもそも使わなくていいらしい。 詳細 execjs の README には以下のように書いてある。 ExecJS lets you run JavaScript code from Ruby. It automatically picks the best runtime available to evaluate your JavaScript program, then returns the result to you as a Ruby object. ExecJS supports these runtimes: therubyrhino - Mozilla Rhino

概要 Before Google Cloud Platform f1-micro インスタンスで CoreOS が動作していた。 sinatra の Docker コンテナが動的なコンテンツを返していた。 とはいえほぼ静的な html なので、 SSL 終端もしていた nginx コンテナに強めのキャッシュを持たせていた。 After Amazon Web Services 予めビルドした静的コンテンツを S3 に放り込む。 S3 + CloudFront(CDN) + ACM(SSL) + Lambda@Edge で配信。 詳細 GCP は Always Free という無料枠で f1-micro インスタンスを使わせてくれるのだが、これはもう滅茶苦茶弱いマシンなんですよね。使うにしても色々工夫して使わないといけなかった。 しかも無料かと思いきや Static IP Charge という

iOS/macOS アプリ開発時のコードサインで発生しがちな手作業で面倒な部分をちょこっと自動化する。 概要 秘密鍵周り、証明書周り、コードサインの概要は 分かっている 、という前提で書いている。 組織的な事情によって Automatically manage signing が上手く機能しない場合が割と稀によくある。 実際に調査したり試行錯誤していたのは 2018 年の 11 月中頃の話なのだけど、まとめといた方がいいなと思って情報をまとめた。 手元の開発機になりがちな MacBook Pro や iMac など、他にも各所で CI として運用されがちな Mac mini など、普通に暮らしていると現代のアプリ開発環境ではビルド環境は複数に分散しがちで、それに伴って手作業メンテナンスおじさんが発生しがち。 色々な運用形態があるし、チームの大きさなどの要素もあるので、 適度な自動化 をした

概要 git コマンドはとにかく便利で、大体なんでも取れる。 SHA-1 Hash を取る。 予想外に色々なやり方がある。 git rev-parse HEAD git rev-parse --short HEAD # short git rev-list --max-count=1 HEAD git show -s --format=%H HEAD git show -s --format=%h HEAD # short git show-ref --hash --head HEAD

概要 git push したらブログが更新されるようにしたのだけど、Slack に投げてた通知が味気ないなと思い、お洒落にしようとしたら沼だった。 Before: After: 詳細 と言っても公式ドキュメントを見るのが一番良い。 Incoming Webhooks # Advanced message formatting Basic message formatting Attaching content and links to messages 知見としては 絵文字で手軽にお洒落になる。 "attachments" の中の "fields" に "short": true で要素を放り込むとお洒落になる。 面倒臭がらずにリンクを張るようにするとお洒落になる。 細かい要素 ("author_name" とか "author_icon" とか) を面倒臭がらずに入れるとお洒落になる。

概要 環境変数を指定して起動してやると git コマンドの挙動を制御することが出来る。 ssh が絡む部分だと GIT_SSH や GIT_SSH_COMMAND や GIT_SSH_VARIANT などがある模様。 ~/.ssh/config や gitconfig を弄ることが難しい場合や、環境に依存しないシェルスクリプトを書く場合などに役に立ちそう。 詳細 ドキュメント や ここ を読めば良い。 ssh が絡む部分だと git fetch や git pull や git clone や git push あたりだろうが、僕は git fetch で上手く動いてることしか確認していない。 GIT_SSH_COMMAND が使えるのは 2.3 以降 Git 2.3 has been released を見るに 2.3 以降でないと使えないらしい。 使えない場合は GIT_SSH の方が

概要 docker image build で毎回 bundle install が走ると遅くなりがちなので、なるだけキャッシュを効かせたい。 よく変更されるアプリケーション部分の COPY よりも先に Gemfile と Gemfile.lock だけ COPY しておいて RUN bundle install するような Dockerfile にしておく手法が良さそうだと思う。 先に Gemfile.lock を生成しておく必要があるので、bundle install を走らせて Gemfile.lock を取り出すスクリプトを書いた。 alpine ベースのイメージを使うと軽い。罠も無くは無いけど。 あと細かい知見とかを書いた。 詳細 /path/to/your/great/app が以下のような構成になってるとして $ tree /path/to/your/great/app /p