  |
はてなキーワード: 設定ファイルとは
何もしてないのに壊れた。と言いたいところだけど多分こないだドッカーをアップデートしたからだとおもう
でもあっぷでーとしただけでこわれないでほしい
ITってさマジでろくな情報がネットに転がってねーよな。あるかもしれんけどグーグル検索がゴミすぎてヒットしないっていう
とりあえず念力でdocker-comppose.yaml がおかしいかもしれないと当たりをつけた。
{service-name} っていうサービスをyamlにとうろくしてるんだけど、なんかの手違いでこのサービスの値をうまく読み込めていないのだろうと、直感だけで決めつける
そんでとりあえずyamlふぉーまっとをググってみてくる。
へいしゃかんきょうのファイルはyamlルート空間直下にサービスをチョクで併記する感じなのだが、ネットで出てくる参考記事にはservice: 要素でくるんでいる
今まで動いてたのが動かなくなるの死ねって感じなので死ねって祈りながら、とりあえずservice:要素をルートに追加して、いままでトップレベルに野ざらしにしてた各種サービス要素をservice:の下に入れる
docker-conpose up -d
ドッカーアップデートするのいいけど設定ファイル読み込みの後方五巻壊すんじゃねーよかす
自分が開発を始めたソフトウェアがイスラエルの企業の目に留まってそのまま現地に行っちゃった人のお話を読んでいた。
すごいなー→仕事心底楽しそうやなー→自分の実現したいことが周囲から認められて幸せそうやなーまでは思った。
けれども、こーなりたいなーとか自分もいつかのために勉学に励まなくちゃ！って気概まで全く至らなくて
プロ野球選手目指しますとはちゃうんだからと思っても、自分にはもう踏み出す足がないことにため息をついてしまった。
プログラミング嫌い、特にgo言語なにそれおいしいの？原始的で野蛮書くの辛いって口悪しくぶっちゃけたら転職の面接で落ちたばかりだ。
実際に似たような業界だけど、プログラマーとしての才能まじでないし、寿司打は一回り年下の後輩にぼろ負けするくらいタイピング遅いし、
正直コーディングよりも、yamlファイル、tomlファイルという設定ファイルをもっちり整えてる時間の方が好き。
マネージャー職もリーダーも無理。自分はこのポジむいてないなっていうのはよく知ってる。ソフトバンク行った同僚の残した資料を見てるとこれと同じレベルのドキュメント作る自信も皆無で。
数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。
CDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。
これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタイムに更新していくことができる。 next.js + vercel などはこのあたりをフロントエンドから CDN まで一気通貫に提供することでリアルタイム風にコンテンツを更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。
CDN の設定の反映の遅さというのは Cloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。
ただし上記の特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点を比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害はマジで全部落ちたのでこれとは関係ない問題だろう)。
Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。
大抵のユーザーは Web からの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルのスニペットをアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードを VCL でやってしまって、同じ URI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。
ただし VCL でいろいろな制御を実現しようと思うと、 VCL の表現力の低さにより地獄を見ることになるので、得られるベネフィットと相談しながらこのあたりはやっていくことになる。
Emacsのカスタマイズにハマると幾らでも時間が消えていくと言われていたが、私はC言語でタブ幅の設定をするくらいだった。
Strutsの開発でTomcatのプラグインが要ると書いてあったのでEclipseにインストールするとか、会社の人からメールで送られたVimの設定をそのままペーストするとかくらいで積極的にカスタマイズすることは無く。
IntelliJやVisual Studio Codeの無数の拡張機能にも興味が無い。
シェルの設定ファイルを頑張るのは時間の無駄！という主張に共感したわけでもなく、普通に関心が無かった。
1990年代からコンピューターを使っているにもかかわらず……
急に凝り出した。「Emacs Lispっていうプログラミング言語でいろいろできるのか」「Visual Studio Codeのマーケットプレイスには同じファイルを対象にした拡張がいろいろあるな」と、今更。
なぜ。
iMac買ってデータ移行してたけどMailのデータ移行で失敗した！
ググって出てきた環境設定ファイルを移動するやり方だけど、やってもMailには移行できなくて、その上アカウトの追加が選べなく追加ができなくなった
ねんのためとバックアップしておいた環境設定ファイルを戻してみても状態は変わらずアカウントの追加がグレーで選べない
修復は無理と判断してOSのインストールをし直そうとしたけどカタリナからHDが二つ作られてる仕様で、こちらも念の為ググって調べたら、まずデータ用の方は削除してそうじゃない方のHDは初期化しましょうってあったので削除・初期化したら不完全なシステムの一部がどうとかになってOSインストールができない！
これは本格的にやべえな・・・とさらにググって立ち上げ時にあちこちのキーを押しながらのやつで本当のイチからのインストール準備したけどやはり不完全なシステムで再インストールができねえ！これはアップルに送って直してもらうしかないか・・・と思って、最後にもう一度HDの初期化してみたらインストールできた！（涙）
結論的にはググって出てきた技術系ページをあてにするのはやめようという教訓
うそを書いてるわけじゃないと思うけどやはりそれぞれみんな環境が違うわけで公式情報を読み取って進むのがやはり一番正確だなと痛感
他のシステムとやりとりするデータのデータ形式やデータの項目を先に決めさせてくれよ。
設定ファイルにどういう設定項目を追加するかを先に決めさせてくれよ。
これらが決まったあとに、決まった仕様に従ってプログラムを作るのがプログラマだよ
センスの無い奴の問題は、知識がないことではなく、頭がおかしいことなんだ。
これは後天的に直せない。そして、センスのないプログラマは他人に迷惑をかける。だから、センスのない奴はプログラマになってはいけない。
こんなのは誰でも書ける。身長(m)と体重(kg)を受け取って、(体重)÷(身長*身長)を計算して出力するだけだ。
GUI等をつけたとしても、総コード行数10数行で実装できるだろう。
ところが、センスのないやつは全く違うことを考える。
彼らの一部は、BMIを計算するプログラムを作るのに、なぜかユーザー登録画面を作ろうとする。
そして、身長と体重のほかに、年齢や性別などの様々なパラメータを管理できるようにし、それらのパラメータを日ごと、あるいは週ごと、あるいは月ごとに入力できるようにし、指定期間での推移をグラフで表示するシステムを作り出す。
ユーザーごとに管理するパラメータの種類は増減するため、BMIを計算する場合、「身長と体重はどのフィールドに格納されているか」というような間接的な情報が必要になり、それを記載した設定ファイル等を読み取る別のプログラムを作り出す。
BMI以外の様々な指標を計算させるために、設定ファイルに書ける独自のDSLのようなものを作り、パラメータ同士の加減乗除や、指定した期間の移動平均などを計算できるようにする。
データ定義にもとことん拘る。単位を何にするかとか、グラフで表示したときに何色にするかとか、軸に単位を表示するかとか、スケールからはみ出したときにどう表示するか等のありとあらゆる情報を各パラメータに対して定義できるよう設計する。
こうして出来上がった巨大なシステムは、身長Hと体重Wを入力すると、W/H*Hの結果を表示するためだけに使われる。
既に述べたように、ここで問題なのは、彼がYAGNI（You Ain't Gonna Need It.）という原則を知らないことではない。
「普通の開発者ならあえてそんなことはしない」ということを自然に行ってしまうこと。これが本質的な問題なのだ。
ちなみに、センスのない奴の頭のおかしさというのは、本当に常軌を逸している。だから、読者がすっと腑に落ちるような例を挙げることは極めて難しい。
たとえば、「数学ができない生徒がいる」という現象を説明するためには、「計算問題は解けるが、文章問題は解けない」というような類型を示すことができる。しかし、「センスのないプログラマ」は、常人の世界観を超越しているので、そういうシンプルな例示や説明ができない。上に書いたたとえ話ですら、実在する彼らに比べれば、まだマシなのである。
なるほど、そういうものなんですね。
Dockerは、「Dockerfile」という設定ファイルを作って運用するみたい。
手書きでコマンドをまとめるのは、結構大変そうだから、こういう設定をGUIツールでチャチャッと済ませたい。
説明を最小限にして、操作の手順だけをまとめたら、これだけコンパクトな文量になるんだな。
もう13時だし、ここらで試しにインストールしてみるか。
ちまたにソフトウェアエンジニアの生産性は10倍違う！なーんていう話を聞くことがありました。
ほんとかよ！と思って生きてきました。そんなことあるはずない･･･と。
年齢は40代くらいの経験のあるエンジニアさん（仮にＡさん）で、単価はおそらく75～90万円/月といったところで、3人月フルコミットでした。
一方、私は、1人月（0.5人月、0.2人月、0.3人月で3ヶ月）の稼働でご一緒しました。
Ａさんは、バージョン管理ツールのログで、変更行数（追加と削除を合わせた数、※1）が、だいたい1ヶ月7,000行くらい。
私は、バージョン管理ツールのログで、同様に変更行数が、1ヶ月だいたい130,000行ぐらい。
うーん、まじなんなんだこの差は。10倍説を認めざるを得ない･･･
自分ができるエンジニアだとは全く思わないけどいくらなんでもひどすぎないか。
もちろん担当した機能の領域とか、自動生成のコードがあるとか（全体に対して過度に多いわけではない）、
テストデータとかに応じて程度の差こそあれ、10倍以上の差が出ている･･･
正直Ａさんの品質は良くない。まともにまともに動いていても仕様漏れ、考慮漏れがあたりまえの状況。
(※1)
この対象には、もちろん設定ファイルとかテストデータとかDDLとか、実コード以外の周辺のファイルもすべて含まれています。
自慢ではありません、ちょっとやるせない気持ちになったので、仕事の愚痴でした。
[追記]
なんだかんだ反応があって嬉しい。
あくまでバージョン管理ツール上の差なので、リファクタリングやパッケージ移動的なことをすると当然行数が増えます。
たまたまリファクタリングを多く行ったので、差分が多く出ただけじゃないか？と結論付けられるのも別良いです。
私的な感覚を表すために行数を測ってみただけで、行数の絶対値で生産性を測りたい意図はなく、相対的な数値の差がでている、というニュアンスです。
