squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
yamlについて思うこと
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
モヤイ像の絵文字の話
https://turingcomplete.fm/12 を聞いていて、モヤイ像について昔ちょっと調べたのを思い出したので掘り起こしてみる。 Unicodeに収録された絵文字のなかに「モヤイ像」というものがある。これ、モアイ像ではなくて “Japanese stone statue like Moai on Easter Island”、つまり「イースター島にあるモアイ像みたいな日本の石像」として定義されている。ちなみにモアイ像の絵文字というものはないのであった。マジで？ マジで。 モヤイ像というのは東京の渋谷駅のランドマークになっているアレであって（細かく言うと色々あるのだがそれについては後述）、イースター島のモアイ像とは似せたようなかんじであってもまあ違う。髪もあるし。上述リンクの図像もまさに渋谷のモヤイ像のような見た目になっている。どうしてこんなことになっているのだろうか？ いっぽう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
