Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu

今年は妻が会社を辞め、イラストレーターとして独立することになりました。 個人事業主になると何をしないといけないのか、保育園への手続きはどうなるのか等、知っておかないといけない事もしなければならないことも山積みです。 中でも、確定申告まわりはわからない事だらけだったので、夫婦でこの本を読むことにしました。 isbn:978-4768311226:detail ぼくは会社員なので会社で年末調整をしてくれます。一方で、個人事業主になるとそういうわけにはいかないため、個人として確定申告をする必要が生じます。 確定申告自体あまり知らなかったのですが、確定申告には白色申告と青色申告があります。 多少大変でも青色申告の方が特別控除として最高65万円の控除が受けられる、純損失が繰越できる、専従者給与を経費算入できる等のメリットがあります。 freeeやマネーフォワード クラウド確定申告等、SaaSで経費等

新しいことを始めようとしていて、仮想プレスリリースを書くことを求められています。なにぶん初めての経験ではあるので、なぜ仮想プレスリリースが必要なのか、今後の自分のためにきちんと明文化しておきます。 仮想プレスリリースを書く目的 仮想プレスリリースに何を書くのか 参考文献 仮想プレスリリースを書く目的 仮想プレスリリースを書く目的を調べるときに多く出てきた文章があります。 "We work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it." つまりは、プロダクトのアイデアからはじめてそこに顧客を当てはめようとするのではなく、顧客から逆算して考えるというアプローチを取る。この文意を噛み締めながらプレスリリースを書く意

今年もあまり本が読めなかったけど、それでも今年に読んだ本の中でピカイチのものでした。 [ISBN:978-4873118567:detail] MVP を構築した後で良いフィードバックが得られたとしたら、イチからその MVP を作り直してサービスとして公開しよう、という話は仕事でもよく聞きます。 しかし、実際に MVP がスクラップ&ビルドで再構築されるのは稀有な例で、だいたいは MVP を修正して正式サービスにしようということがされがちです。 ぼくがこの本に出会ったのは、そういう場合に「どうやってアーキテクチャレベルで MVP から正式サービスへ推移させれば良いのか」に悩んでいたときでした。 この書籍で述べられる「進化」は、必ずしも直接的にその答えにはならないですが、それでも「アーキテクチャを進化」させるにはどのような考え・方法が必要なのか、 アーキテクトは何をしていけば良いのか、という

昨日 Linuc 303 (Security) を受験してきました。いわゆる資格試験はかなり久しぶり、特に Linux 系の試験となると 5 年ぶりになります。そう、なぜ 5 年ぶりに Linux 系試験を受けたのかというと、ぼくの LPIC Level 3 の有意性期限が迫っているためでした。 LPIC は認定制ですが、その有意性は 5 年間の期限があり、それ以降も当該の有意性を維持しようと思うと、同レベルあるいはより上位のレベルの試験に合格する必要があります。 ぼくは 2014 年に LPIC 304 (Virtualization & High Availability) を取得して以降、完全に放置してしまっており、あーそういえば LPIC そろそろ受けないとなぁと思ってマイページを見ると、もはや期限切れの瀬戸際でした。 試験予約を入れた当日に台風 19 号が到来した結果、LPI-J

新卒で入社した会社の新人研修で心に残っているのは、 "一次情報源にあたれ" という話でした。 要するに Blog 記事とか Qiita とかでノウハウを吸収するのは効率良いんだけど、そうする理由は何？とか、仕様として正しいの？と言われたときに、 このエントリに書いてありました、とかいうのはプロじゃないよね、という話で、そういうのは今でもできるだけ気をつけていたりします。 1 そういうわけで、RFC 参照しなきゃって気になるときは多くあるんですが、RFC を読みたいっていうとき、だいたい WebSocket rfc とかのキーワードで検索することが多かった。だいたいそれで要は足りるんですが、不安になるのは「これって他の RFC が出てたりしないかな」ってことでしたが、 そういうのの不安を軽減するのに IETF Datatracker が便利っぽい。 たとえば、oauth 2.0 について調べ

シェルスクリプトでシグナルをトラップするには、みたいなことを考えることがあって、そういえば trap という日頃なかなか思い出されない不憫なビルトインがあることを思い出しました。trap は bash のビルトインとして存在する便利なヤツですが、忘れられがちなので、ここで一つ、trap コマンドとはどういうものかを書いてみることにしました。 trap の基本 trap は、その名前の通り、シグナルを補足(trap) するためのシグナルハンドラを設定するためのビルトインです。 シェルスクリプトを長時間動かすみたいなユースケースは結構あって、別言語で実装されたバッチプログラムの起動だったり、ファイルツリーを探索して何か集計したりするとか、他システムとファイルを送受信したりです。 こういう長時間動かすケースではときどき、「あれ、意図せずシグナルを送られちゃったりしたときどうしよう」みたいなことを

スレッドダンプというと、JVM 言語に関する運用でマジで困ったときの頼みの綱みたいなイメージある。マジで困ったとき、じゃなくて、カジュアルに見れば良いんだけど、スレッドダンプのフォーマットが異常すぎてつらくなる。 そもそもなんなんだこのゴミみたいなフォーマットは。 一体誰がどういう思想の元でこのフォーマットを決めたのかさっぱり分からないし、人類を苦しめるために未来から来た AI が勝手に策定したのではないか。 "[ThreadPool Manager] - Idle Thread" #42 daemon prio=5 os_prio=31 tid=0x000000012a3a7800 nid=0x15503 in Object.wait() [0x000070000ab66000] java.lang.Thread.State: WAITING (on object monitor) at

今日はブラウザのキャッシュ制御の話。キャッシュについては主に性能面で語られて、情報漏洩に繋がる重要な制御であることは見逃されがちです。 CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして | メルカリエンジニアリング 情報漏洩自体はよくないことで、被害にあってしまった人はそんなこと言ってられないけれど、その原因を包みかくさず公開することで他山の石というか、間違いなく日本のセキュリティ意識は向上すると思います。 ぼく自身も、みなさんも、そろそろ Cache-Control: no-cache, no-store, must-revalidate しとけば良いんやろ、というゴミのような意識を改善しなければならないということで、ここにキャッシュについてまとめてみます。 Cache の種類 ブラウザで関連するキャッシュには主に 2 つほどあります。 private cac

さっき Cache-Control ヘッダの話を書いたんですが、もちろんキャッシュ制御に関しては Cache-Control ヘッダだけで収まる話ではなく、他にも多々のヘッダが影響を与えます。 その一つに、Vary ヘッダがあるので、今日はその話でも。 Vary ヘッダ Vary ヘッダは、RFC7231 で定義されているヘッダです。 vary というと「変わる」という意味を持つ動詞ですが、Vary ヘッダはその名の通り、「どのヘッダによってコンテンツが変わったのか」を示すレスポンスヘッダです。 例えば、よくあるタイプのスマートフォン対応の 1 つとして、User-Agent ヘッダを見て、PC 用 HTML を返却するか、スマフォ用 HTML を返却するかを切り替える実装を良く見ます。 この場合、レスポンスヘッダに Vary: User-Agent ヘッダを付けるのが常套手段です。ちなみ