ADMIS_Walker の雑記帳: 7月 2024

2024年7月27日

本日 #ssmjp 二本目、「運用改善、不都合な真実」の資料を公開しました。https://t.co/FLatAMO3Gz

ありがとうございました!
— HATANO Hirokazu (@tcsh) July 22, 2024

めっちゃ良い。特にこの問題認識は、運用改善に限らない。

> 単独の「課題」それぞれに対してピンポイントで対応していた。課題の数に比例して工数を消費する上、ツギハギの課題解決だらけになる
> https://t.co/gJpghb0ny1… https://t.co/7SrnqStjvP
— kokukuma (@kokukuma) July 26, 2024

まさにおっしゃる通り。

一方で、「特殊に見える要望」に新たな需要の萌芽を見出すこともあるので、きっちり要望を聞いて是々非々で対応することも大事。

かつそのような「特殊な要望」を標準サービスとして設計・提供できた時の達成感はめっちゃ大きい。 https://t.co/HoOVnZ6yUC
— HATANO Hirokazu (@tcsh) July 26, 2024

> 「特殊に見える要望」に新たな需要の萌芽を見出すこともあるので、きっちり要望を聞いて是々非々で対応することも大事

まさに! 要望の一つ一つって、自分たちの理想・実現したいことが、他のチームや会社・社会の要求とマッチしているかどうかをチェックするunitテストみたいなものなんですよね。
— kokukuma (@kokukuma) July 26, 2024

自分都合を押し付けてくるケースと、よく聞いてみると至極真っ当な要望であるケースがあるので、本当にしっかり聞いてみないと、もったいない&硬直的な組織に見られてしまうんですよね。
自分達の理想や実現したいことが社内や社会の要求とマッチしているか敏感であることは大事だなぁ、と思います。
— HATANO Hirokazu (@tcsh) July 26, 2024

いわゆるプライベートクラウド屋としては本当にこれ。

「ユーザが困ってるんだから」という善意で個別要望を聞いてあげるだとスケーラビリティで崩壊する。いかにサービスとして特殊要望を汎化したソリューションに変えれるかを考えるのがこの仕事の醍醐味。

なお周りの理解は乏しい模様（ https://t.co/xjyleqKfJd
— てぃーじぇ (@tj8000rpm) July 26, 2024

個別案件をやりたがる人ってUnix使ったことない人だと言う疑惑があって、既存の小さな道具の組み合わせで解決して欲しいことも、ほんの少しの違いですスクラッチから作るのを是としてしまうのよな。
いかにマルチックスが好きな人を諭せるか。。。コレが本当に重要なんよ。 https://t.co/LFb6HQ7wVm
— qooqle (@qooqle) July 26, 2024

ほんまそれです。

zabbix一つとっても、zabbixの中に独自カスタマイズしたスクリプトいっぱい仕込みたいとか、監視のためにネットワークにいっぱい足生やしたい、AIだ、機械学習動かすんだみたいなの言うてる方々がいて、一つのことをうまくやるという発想はないのかとおもてしまいました
— てぃーじぇ (@tj8000rpm) July 26, 2024

そうやって思うと、小さな道具の組み合わせで何ができるのか、鬼のようにリファレンスドキュメントを用意するとなんとかなったりするのかな？
AWSとかCiscoが使いやすいのって、こう言うドキュメントの豊富さな気はしてるんだが、それを社内でやろうとすると顧客規模が小さすぎてスケールせんのがな。 https://t.co/u20FwNgrP1
— qooqle (@qooqle) July 26, 2024

---

個人的にAWSに入れ込んでいる理由として、「UNIXの考え方」を随所で感じさせられる(一つのことを上手にやる)ことと、豊富なドキュメントが提供されてことが挙げられます。

でも、読み込んでいくと全体構成がいけてないことにも気付くAWS公式ドキュメント… (手元で全体構成作り直して使ってますw https://t.co/fFoE5KaOrm
— HATANO Hirokazu (@tcsh) July 26, 2024

ダメなリファレンスも含めてユーザーグループのネタになるんで、オープンなコミュニティ万歳ですねw
— qooqle (@qooqle) July 26, 2024

---

運用改善ではどうにもならなくて、再設計(非連続的な変更)をしたときの例。

その運用自動化では行き詰まる〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 (JANOG42)https://t.co/Rfrh6ntVWM
— HATANO Hirokazu (@tcsh) July 26, 2024

運用改善、不都合な真実 / 20240722-ssmjp-kaizen https://t.co/slZyS5qbub
>運用改善も自動化も効果は限定的
>やるべきは運用の再設計

わかりみしかなかったが言うが易しである
— Jun'' (@jungm__) July 26, 2024

これを言語化するのに15年掛かりました(笑

> 言うが易し https://t.co/sTfb4rraX5
— HATANO Hirokazu (@tcsh) July 27, 2024

---

この資料は、エンジニアが4桁いる会社で実際に自分がやってきたことをまとめたものです。
誰でもできる、とは言わないですが、この資料を見てやり方を変える人が増えれば良いと考えています。

(「正論だけど現実的ではない」と言ってしまった時点で実現しない、とは思っています。) https://t.co/vHPdOt2Mv0
— HATANO Hirokazu (@tcsh) July 26, 2024

いきなりグランドデザインを作ることは不可能、というのは、未経験ならその通りですが、ある程度業務経験がある人であれば、、、、できて欲しいなぁ。。。 (抽象化能力ある人が希少という問題)
— HATANO Hirokazu (@tcsh) July 26, 2024

言ってることは正論だとは思うけど、現実的ではない話かなあと思う。いきなりグランドデザインを作ることは不可能だし、「やればわかる！やらなければ、一生わからん！」という話があるので、知見が溜まったら定期的に全体を見直そうぜという方が妥当と思うけどねえhttps://t.co/H0N1Bo7lyU
— てるろー (@terurou) July 26, 2024

スモールスタート自体は悪くないと思うんですよ。「各部門からEXCELマクロが排除できないんですが！！！！」という感じで、ちょっと喉元を過ぎると全く見直しをかけずにそのまま残り続けることの方が問題
— てるろー (@terurou) July 26, 2024

「スモールスタート自体は悪くない」というのは経験を積ませるという意味ではおっしゃる通りですが、業務本番について言えばマネジメントやアーキテクトが機能していない、っていうことです。。。

「スモールスタートではじめよう」って言葉が出てくると「それはプロの仕事ですか?」と感じる派です https://t.co/GHQO3BwuJZ
— HATANO Hirokazu (@tcsh) July 26, 2024

現場の創意工夫の積み重ねでクソ運用が出来上がることをクソと言うこと自体はまあ間違ってないと思うんだけど、かといって、「現場で勝手な改善をするな、御上から沙汰が下るのを待て」というのも傲慢だとは思うんよねえ。
— てるろー (@terurou) July 27, 2024

「上がやるべきことやってないので、現場の工数が無駄になっている」と言いたいんですが、なかなか伝わらないものですね…

あと、現場も良かれと思ってやっていても、悪化の片棒担いでいることに気付かないとダメだよ、と言う観点はあります。(それを傲慢と言われるのですかね… https://t.co/dl1idmHejt
— HATANO Hirokazu (@tcsh) July 27, 2024

プロフェッショナルとして、「自分の工数が無駄になるけど良いですか?」とマネジメントに問う&説明することは、大事な責務の一つだと思うんですが、そうでもない、ですかね?

(自分も上手く説明できた時と出来なかった時が当然ありますが > アウトプットの質に直結)
— HATANO Hirokazu (@tcsh) July 27, 2024

---

スモールスタートって全体の計画を作った上で部分から始める場合、そもそもインクリメンタルにやっていく場合、草の根的にやっていこうという場合が混在している気がする。どれが正しいということもないが、文脈を意識しないとかくあるべしな人と衝突が起こるから認識合わせは必要よなという感。 https://t.co/FDPayuQYyf
— 天野遠景@がんばれない (@tokagetail) July 27, 2024

マネジメントやアーキテクトがきちんと機能している組織で、チャレンジングな領域について、リスクと組織知の蓄積を勘案した上で、本番環境でスモールスタートする、ならばコントロール可能なのでありですが、そんな組織がどれくらいあるのか...
— HATANO Hirokazu (@tcsh) July 26, 2024

自動化でも、IaCでも、運用改善でも「スモールスタートではじめよう」という発表が多すぎる問題。

そういうのは、個人の趣味や研鑽でやるべきで、お仕事でやるときは「勝ち目が見えてから」やるべき。

そのためにPoCや検証は必要ですが、本番でやっちゃだめ。
— HATANO Hirokazu (@tcsh) July 26, 2024

(問題が露見する頃には自分は担当から外れられてるはずだろうから)スモールスタートではじめましょう、という闇のパターン
— HAL_FS_H (@HAL_FS_H) July 27, 2024

時間稼ぎパターンｗ
— 天野遠景@がんばれない (@tokagetail) July 27, 2024

大きめの企業だと割と見かけるパターン。

しばらく前だとkubernetes関連とか、最近はIaCが圧倒的にこれ… https://t.co/ex8bkOSvd3
— HATANO Hirokazu (@tcsh) July 27, 2024

研鑽を大きめの企業で業務としてやるのがITだと許されないとするとマジ闇ですな。研究所なんて研鑽しか無いのに。
— ARAKI Yasuhiro ☁ AWS Solution Architect (@ar1) July 27, 2024

本番導入ありきでやるのがあかんのですよ… (ポイントオブノーリターンからの片道切符
— HATANO Hirokazu (@tcsh) July 27, 2024

阻止限界点探しが必要になりそう
— ARAKI Yasuhiro ☁ AWS Solution Architect (@ar1) July 27, 2024

2024年7月22日

プログラムの仕様というものを、「コードがするすべてを表現する文書」と捉えると意味がなくなる。そんなもの読むよりコードを読んだ方がよい。そうではなく、契約、あるいは責任の分界点を表現すると考えれば、意味がある。…
— 杉本啓 (@sugimoto_kei) July 14, 2024

ソフトウェア開発で「正しいやり方」があるという考え方には慎重になった方がいいと思う。例えば昔は、「オブジェクト指向」が正しい手法であり、よいコードが書けないのはそれを理解してないか正しく実践していないからみたいな感覚が一世代以上にわたって幅を利かせていた。あれはなんだったんだ？
— Rui Ueyama (@rui314) July 16, 2024

数百人や数千人が関わっているプロジェクトの「正しいやり方」と、自分がちょろっと作っている小気味よく動くプログラムのための良いやり方は当然違うと思う。

一般的に良いとされている手法と違っても、自信を持って開発していけばいいと思う。大切なのはいい感じのものを作れるかどうか。
— Rui Ueyama (@rui314) July 16, 2024

ソフトウェア開発に必要なのはわかりやすい文章を書くのと同じような能力かなと思う。うまくまとまっていて自然と読める、みたいな。

こう書けば意味不明な人でもわかりやすい文章が書けるみたい魔法のような手法がないのと同じで、プログラミングに正解は今のところない。
— Rui Ueyama (@rui314) July 16, 2024

スルーしなきゃと思ってたけどだめだった。この「正しい」っていうのが、いかにも理系の良くないところが出てる世界観だなって気持ちを言わずにいれない。数学のような正誤を証明できる美意識。でも数学は自然科学かと間違うぐらい美しくできているけれど、突き詰めると決めの問題でしかない人工物 https://t.co/42cwk8YcG1
— 田中ひさてる (@tanakahisateru) July 17, 2024

突き詰めると人為的な定義にすぎないことを、普遍的だと信じる人間の行動パターンは、中世ヨーロッパだと完全に、宗教学が頂点に立って決めていたことで、いまだ科学的と思われている近代思想は、その直系の子にすぎないという危うさを持っていることを、文系エンジニアはもっと理系に伝えてほしい
— 田中ひさてる (@tanakahisateru) July 17, 2024

数学は既知の材料を集めて「本当にそうだ」と一般化して言うのに都合の良い学問で、哲学は「本当はそうじゃないかもしれない」と未知の問題をひとつ投げかける学問。哲学に完全解はないけれど、完全解っぽいものに対して、全てがそうではないと反証する向きの思考力に貢献すると思う
— 田中ひさてる (@tanakahisateru) July 17, 2024

「現在、世界には4種類の高所得国しかない。1) 英語圏、2) イギリスに近い国、3) 資源に恵まれた国、そして4) 日本とその旧植民地である。」
1〜3まではよく研究されているが、なぜ4なのか？産業革命がなぜ日本に最初に広がり、他の非西洋諸国には広がらなかったのかに関するデータドリブンの研究。 https://t.co/ppYb5Cqgek pic.twitter.com/caUwCwpbAI
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

6ページもの論文ですが、結論としては、辞書の編纂、科学技術用語の造語、科学技術書の翻訳、教育への集中投資による科学技術の自分たちの言語による体系化と吸収が決定的であったであろう、というもの。
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

上に引用したFig. 6。1870年には技術書の84％が英語、フランス語、ドイツ語、イタリア語の4言語で書かれていた。1910年、西欧の上位4言語で書かれた技術書は技術書全体の66パーセント、第4言語の日本語は技術書の19パーセント。なんと、この時点では日本語の技術書は英語で書かれたものを抜いている。
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

「明治天皇の「五箇条のご誓文」のうちの一つでは、「知識は、帝国統治の基礎を強化するために、全世界に求めるものとする」と宣言された。従って、新政府の全構成員は、西欧のアイデアを吸収して日本を強化することを支持することが求められた。」
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

「招聘した外国人に支払う費用だけでもかなりの支出が必要で、1876年には政府支出総額の約2％、東京大学予算の3分の1、文部省予算の2分の1、1879年には公共事業予算の3分の2を占めていた。海外留学の費用は年間政府支出の最大0.20％を占めていた。」
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

「技術政策に直接支出するだけでなく、明治政府は教育政策も展開した。これは重要なことで、企業家や経営者が技術的知識を吸収できる人的資本を持たない限り、技術的な知識を日本語で提供してもほとんど意味をなさないからだ。」
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

「義務教育は1872年に始まったが、1877年の文部省の報告書によれば、「国民はまだ教育を有益なものと考えておらず、親は不満を抱いている」ため、ほとんどの日本の親は子どもを官立学校に通わせることを拒否した。」
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

「政府の圧力は、非エリートの日本人の反教育的態度をすぐに克服した。学校に通う男女の割合は、1874年には適格男子の39.9%、適格女子の15.1%であったが、1879年には男子の58.2%、女子の22.6%に上昇した。1890年には、男子の90.6％、女子の71.7％が小学校に就学していた。」
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

翻訳書と、新語の造語の爆発的増加。 pic.twitter.com/4LYztp8fs4
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

翻訳書と新語造語の1960年代後半からの爆発的増加の後、1880-1910年に日本の輸出に占める製造財の割合が爆発的に増加した。 pic.twitter.com/gmWepNnUaV
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 18, 2024

1960年代：誤
1860年代：正
すみません。。。
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 19, 2024

この論文、66ページもありますが、明治期の日本の成功のあり方がまとめられているとても良い論文で、DeepLとか使えば、比較的容易に読める部分が多いので、ご興味のある方はぜひ。https://t.co/jzwgRpHxAh
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 19, 2024

改めて思いますが、明治期は、科学技術と教育全般にに国としてすごい勢いと熱量で「選択と集中」してたわけですね。科学技術と教育への投資は比較的すぐに莫大なリターンをもたらすことが明治の日本人にもわかっていたのに、今、そうでなくなってしまっているのは謎。
— Tsuyoshi Miyakawa (@tsuyomiyakawa) July 19, 2024

とても面白そうな論文だったので、全編ざっと読んできました。既に下記のスレッドに丁寧に論旨がまとめられていますが、せっかく読んできたので、備忘メモとして自分でサマライズしてみます。 https://t.co/fhN1vddDoP
— 伊藤（ex外資系ポンコツ） (@itoexex) July 19, 2024

一生一緒にNVIDIA‼️とかウキウキしてたら、CEOが売却しててワロタ🤣
含み益は幻だ、利確が正義✨ pic.twitter.com/lBpiHVI4pu
— シンチャオ：平凡な係長 (@Nifty50JEPI1489) July 20, 2024

議論をしている時に相手が議論相手の個人のパーソナリティ的なものに対して指摘の軸を移し始めた時は、もうその相手は万策尽きていて以降はもう議論ではなく対象がムカつくという気持ちだけなっている状況なので、こうなりそうな前に適当な所で降りて話を収束されるのが大事だよねーと思う。
— komitsubo (@komitsubo) July 21, 2024

ここでもっと踏み込むとそれが正論だろうが妥当だろうが関係なく、今後本当に親の仇くらい永続的にヘイトを持たれ続ける。正直百害あって一利もない。なので議論をする時は主張の正当性よりも相手との関係を大事にした方がいい事は世の中多い。相手が下りられない人であれば猶更そう。
— komitsubo (@komitsubo) July 21, 2024

特に常に白黒つけたがる人は、ゼロサムな話しか出来ないし、議論＝ゼロサム、または優劣と本当に思っているので自分の思い通りにならないとこのモードに入る事が多い。これは本当にどうしようもないのでとばっちりを受けないようにする事も大事。本当に人間関係ってデリケートで難しい。
— komitsubo (@komitsubo) July 21, 2024

そして何故かこういう人は彼ら的な議論が好きだったりする。そういう人達は類友界隈でやっててくれればいいんだけど、たまに飛び火する。そういう時は本当にゲンナリしてこんな感じになる。そして最近絡まれてる。ホントなんでそうなるの？とトホホである(個人の感想です)。 pic.twitter.com/PeD8OpcM85
— komitsubo (@komitsubo) July 21, 2024

s/収束される/収束させる/ ですね。誤記がへらないなぁ。反省。
— komitsubo (@komitsubo) July 21, 2024

「ネット上の言い合いで勝ててもそいつの人生って勝ってるのか？気にする暇があれば自分を磨け。一流を目指すなら他者の言動に構ってる時間はない筈だ」
部長の一言思い出して今日も頑張る。
— ふぇーす⚓️📸 (@rinc7600) July 20, 2024

並列で xz できる pixz 知らなかった
圧縮元が GB 級だと必須だなhttps://t.co/rBpGFGtJKz
— Takumi Sueda (@puhitaku) July 21, 2024

2024年7月14日

プログラムの仕様というものを、「コードがするすべてを表現する文書」と捉えると意味がなくなる。そんなもの読むよりコードを読んだ方がよい。そうではなく、契約、あるいは責任の分界点を表現すると考えれば、意味がある。…
— 杉本啓 (@sugimoto_kei) July 14, 2024

つまり、プログラムの仕様書は、個々のプログラマがなすべきことを詳細に規定するためにあるのではなく、プログラマたちの仕事範囲の線引きのためにある、と考えた方が有用だ。仕様を満たすためにどんなコードを書くべきかの判断は、各プログラマに委ねられ、その結果が批評の対象となる。
— 杉本啓 (@sugimoto_kei) July 14, 2024

プログラミングを始めて一年目。僕が、モジュールの中身は*ほぼ*書けたがインターフェースが固まっていない、と報告したら、先輩が、そんなことはあり得ない。仕様はインターフェースから固まるものだ。それが出来ていないなら中身も本当は出来ていないんだ、と言った。その通りだった。
— 杉本啓 (@sugimoto_kei) July 14, 2024

2024年7月8日

巷間では、営業プロセスやマーケティング手法が魔法の槌であるかのように語られがちだ。しかし、営業が強いと評判のキーエンスさんに関する本など読んでみると、いわゆる「営業力」で売っているというより、営業からのフィードバックで製品を良くして売っておられるように見える。
— 杉本啓 (@sugimoto_kei) July 8, 2024

学びたければ推しを作る pic.twitter.com/JLPYvIaSeH
— ひさ (@hisagrmf) July 8, 2024

2024年7月7日

PostgreSQLのuuid型はUUIDv7も格納できる。さらに主キーとして使う場合、Bツリーの特性もあり完全ランダムなUUIDv4よりもUUIDv7の方がINSERTは高速になる。わいわい / “PostgreSQL and UUID as primary key” https://t.co/aD2st5HBS1
— matsuu (@matsuu) July 6, 2024

UUIDv7 in 20 languages, check out the Dart version:
UUIDv7 is a 128-bit unique identifier like it's older siblings, such as the widely used UUIDv4. But unlike v4, UUIDv7 is time-sortable with 1 ms precision. https://t.co/hijbBZ37vO #flutter #flutterdev #dart pic.twitter.com/5EwuShrweS
— Marco Napoli (@JediPixels) June 15, 2024

UUID Wars: Many interesting details I didn't delve into. For example: index size reduction w uuidv7, slightly higher TPS w bigint, buffer cache contents vs usage counts during data loads. BIGINT is still a winner but uuidv7 is worth getting excited about. https://t.co/ks91U7EeyC https://t.co/oUHGVm2PBW pic.twitter.com/Xka91h6EU2
— Jeremy Schneider (@jer_s) February 4, 2024

Finally! Time-ordered UUIDs that will fix the DB index locality issue. Hello UUIDv7 (final review stages)! Good bye (?) ksuid and ulid https://t.co/LoJUbrpPZ8
— Francois-Guillaume Ribreau (@FGRibreau) October 10, 2023

2024年7月6日

C言語では、if elseについて実行順が保証されるが、switch caseでは、評価順が保証されないから、「敢えてif文で条件分岐」という話が書いてあったのは、アスキーから出ていた「C言語を256倍使う方法」だったと思う#老害
— S𝓱𝓲𝓰𝓮𝓻𝓾 F𝓾𝓳𝓲𝓽𝓪 (@shigerufujita) July 6, 2024

C言語を256倍使うための本にifはswitchに書き換えた方が良いけどどの順番で比較を行うか保証されてないからあえてifで書くこともあるよというようなことが書いてあった https://t.co/ipyfhKlA8m pic.twitter.com/GNTseCeB8w
— にょもこ (@tmkymd_) July 6, 2024

非機能要求グレードはマジでバイブル。 https://t.co/BXAd7u7Voh
— うめめ (@beConjuror) July 6, 2024

登録: 投稿 (Atom)