/note/tech

Go言語のTemplateで別ディレクトリに存在する同名ファイルをロードしたい

↑の質問者と同じことをしようとしていてハマったのでメモ。

Ginの Engine.LoadHTMLFiles は 内部で template.ParseFiles を使っているので同名のファイルがあると後からロードしたもので上書きされてしまう。

例えば、↓のようなファイルがある場合、 template/test1/index.html は template/test2/index.html で上書きされてしまう。

template/test1/index.html
template/test2/index.html

これは template.ParseFiles のドキュメントにも明記されている(とは言え、この挙動は直感を大きく裏切る初見殺しであり、限りなくバグに近いと思う)。

When parsing multiple files with the same name in different directories, the last one mentioned will be the one that results. For instance, ParseFiles("a/foo", "b/foo") stores "b/foo" as the template named "foo", while "a/foo" is unavailable.

(異なるディレクトリにある同じ名前の複数のファイルを解析する場合、最後に記載されているファイルが結果になります。たとえば、ParseFiles( "a/foo"、 "b/foo")は、 "b/foo"を "foo"という名前のテンプレートとして格納しますが、 "a/foo"は使用できません。)

https://pkg.go.dev/html/template#ParseFiles

ちなみに Engine.LoadHTMLGlob という関数も用意されており、 こちらは同名ファイルを扱えるかのようにリファレンスに書かれているが、Glob特有の問題(深い階層を作っていると再帰的にロードしてくれないなど)もあり、使い勝手がよろしくなかった。

とはいえ、これではあまり開発体験がよくないので解決策が無いものか調査したところ、↓のサンプルコードのように template.Parse を使うことで同じ名前のテンプレートを取り扱うことに成功した。

試してはいないが、 html/template だけでなく text/template でも同じだと思う。

package main

import (
    "embed"
    "html/template"
    "io/fs"
    "net/http"
    "os"

    "github.com/gin-gonic/gin"
)

// ↓embed.FSでファイルをバイナリに埋め込んでいる
//go:embed template/*
var templates embed.FS

func main() {

    r := gin.Default()

    // テンプレートをセット
    r.SetHTMLTemplate(loadTemplate())

    r.GET("/", func(c *gin.Context) {
        c.HTML(http.StatusOK, "template/index.html", gin.H{})
    })
    r.GET("/test1", func(c *gin.Context) {
        c.HTML(http.StatusOK, "template/test1/index.html", gin.H{})
    })
    r.GET("/test2", func(c *gin.Context) {
        c.HTML(http.StatusOK, "template/test2/index.html", gin.H{})
    })
    r.Run(":8080")
}


func loadTemplate() *template.Template {

    // 1. templateディレクトリ以下の全ファイルのパスを抽出
    fileList := []string{}
    err := fs.WalkDir(templates, "template", func(path string, d fs.DirEntry, err error) error {
        if err != nil {
            panic(err)
        }

        if d.IsDir() {
            return nil
        }

        // ファイル名をリストに保存
        fileList = append(fileList, path)
        return nil
    })
    if err != nil {
        panic(err)
    }

    // 2. 取得したファイルのリストからtemplate.Templateを作成する
    t := template.New("")
    for _, item := range fileList {
        bytes, err := fs.ReadFile(templates, item)
        if err != nil {
            panic(err)
        }
        // ↓t.New(item)とすることでファイル名がテンプレート呼び出し時のキー的なものになる模様
        t.New(item).Parse(string(bytes))
    }
    return t
}

とはいえ、今回は必要に迫られて動的なWEBサイト(JSONではなくHTMLを返却するタイプ)をGo言語で作ることになったが、動的なWEBサイトをGo言語で作成するメリットは全く無いように感じる。

動的なWEBサイトを作りたければ、PHP/Python/Rubyなどの動的型付け・インタプリタ系の言語を使った方が圧倒的に楽だし、知見も蓄積されている。

atlasgo.io

Atlas DDL is a declarative, Terraform-like configuration language designed to capture an organization’s data topology. Currently, it supports defining schemas for SQL databases such as MySQL, Postgres, SQLite and MariaDB.

(Atlas DDLは、組織のデータトポロジをキャプチャするように設計された、宣言型のTerraformのような構成言語です。現在、MySQL、Postgres、SQLite、MariaDBなどのSQLデータベースのスキーマの定義をサポートしています。)

Terraformのような風味でDBスキーマを定義できるということらしい。

正直、SQLを直接記述することに対する優位性が読み取れなかった。

Nginx と自前の認証システムを組み合わせてセキュアなリソースを制限する

nginxのhttp_auth_request_moduleを用いた認証システム

このぐらいシンプルだと既存システムとも組み合わせやすそう

ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか

Pythonにおけるデザインパターン

基幹システムの変更を楽で安全にする

【イベント参加レポート】ドメイン駆動設計を導入するためにやったこと

【登壇レポート】「ドメイン駆動設計を導入するためにやったこと」に、弊社エンジニア・ミノ駆動が登壇しました!

SREチームの作り方と5つの導入ステップを理解する

公取委、システムエンジニアの取引実態調査スタート 「買いたたきなど下請け法上の問題がある」

ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]

巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例

マイクロサービス化した結果、人間の認知能力を超えてしまう現象

1つのwebサービスの開発に30を超えるGitリポジトリを把握しないといけないの人間の把握能力を超えてる気がする。

@sinsoku_listy

あるあると思いつつも、全てを把握しなくてはいけないならそれは抽象化に失敗しているのではないだろうか

[レポート] SaaSアーキテクチャーのパターンを学ぶ #reinvent #ARC306

プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か? #RSGT2022

実践知に勝る知識はない。知識を得たら実践、を繰り返す。

知識と経験のバランスは大事。知識は実践で活かす目的で得るものなのに、いつしか知識を得ること自体が目的になり、経験よりも知識のウエイトが多くなるとあたかも自ら経験したかのように錯覚し、やがて評論家のようになる。

実践知に勝る知識はない。知識を得たら実践、を繰り返す。

@atsushimatsumo8

1on1、単に雑多な相談の場所になると「そういうので話すことはない」とか「特別思っていることはない」とかに...

1on1、単に雑多な相談の場所になると「そういうので話すことはない」とか「特別思っていることはない」とかになって最終的に「そういう話題だけなら時間がもったいないので仕事に戻らせてほしい」となるメンバーもいるので設計が難しい。

@odashi_t

1on1、「軽い雑談の場として...」と設定しちゃうマネージャは多いけど、軽い雑談ならあまり体力を使う話はしたくないな...ってなって「特に相談したことは無いです」になりがち。

むしろ、話題や目的を明確にした方が満足感がある印象。

メンバーの定期メンテナンスを目的とするなら↓みたいなアジェンダがあった方がよい。

Qiita記事「エンジニアの"有害な振る舞い"への対処法」への強烈な違和感

207で1年間磨き続けた1on1のフォーマットを公開します

1on1のフォーマット

・現時点でのポジティブニュースを3つ教えてください。

・体調は100点満点中何点ですか?

・モチベーションは100点満点中何点ですか?

・日々の仕事は順調ですか?人生は前に進んでいますか?あなたや家族は幸せですか?

・業務内容について気になること・不安・心配事はありますか?ざっくばらんでOKですので、教えてください。

・ほかのメンバーと仕事をする上で、気になること・不安・心配事はありますか?

・現在の仕事量、余裕はありますか?ないですか?

・人生の不安はありますか?

・私が改善すべき点や、成長できる余地、全社的にやったほうが良いと思うことについて教えて下さい。

・高柳(マネージャーの名前)から期待値や所感のフィードバック

・他になにか話しておきたいことはありますか?

・クローズドアジェンダはありますか?

フロントエンドのテストのモックには msw を使うのが最近の流行りらしい

Firefoxの利用者から「突然ネットにつながらなくなった」報告が殺到 影響範囲は世界中か

Webブラウザ「Firefox」の利用者から「突然重くなりネットにつながらなくなった」という声がSNS上で上がっている。これらの報告は、13日午後4時50分ごろから世界中で投稿されており、日本国内でも同様の投稿が相次いだ。

確かに突然全然つながらなくなった時があったな。再起動したら直ったけども。

教育により大量生産できない本当に特別な技能がプログラミング

「難しい人」の話が年末年始話題になってたけど faker.js の話とかもまさにこれであって、身も蓋もない話だけど、対人関係上の問題を抱えていることはいいプログラマーになる要因の一つだったりするんだよな。はっきりいえば性格いい奴だけ集めてるとカスみたいなもんしか出来ないというのがある。

@ssig33

プログラマー/SWEというのは本当に特別な職業であって、たとえば欧米なら普通専門的な職業の求人では必ず学位を求めるわけだけど、プログラマー/SWEだけがこの例外で「学位もしくは同等の経験」というような書き方で実質学位不問なのよね。教育により大量生産できない本当に特別な技能がプログラミング

@ssig33

もし教育により高い確度で価値を提供できる SWE になれる、という状態になれば言い方悪いけど業界全体で「難しい人」と手を切れるんだよな。俺は切られる側だろうが。ただ実際そうなってない。

@ssig33

そういう側面もあるかな

フロントエンドは原理的に美しくない世界だから、コード書ければ書けるほどやりたくないになりがちなんだよな

フロントエンドは原理的に美しくない世界だから、コード書ければ書けるほどやりたくないになりがちなんだよな。そして人材難になる。サーバーサイドは美しい世界にできる

@kis

それ以上いけない

増田氏のDB設計哲学

テーブルを記録の意味別に適切に分割する。

主キー制約、一意制約、外部キー制約、NOT NULL制約を徹底する。

適切なデータ型を選ぶ。

テーブルをスキーマでグルーピングする。

スキーマ名、テーブル名、カラム名を日本語にする。

区分はコードよりも名前で一意識別する。

これらを徹底するのが良い設計

@masuda220

データの品質が上がり、SQL文が読みやすくなり、プログラムの変更が楽で安全になる。

逆の設計が生み出すデータ内容の乱雑さ、SQL文の読みにくさ、プログラムの変更のやっかいさと比べれば、こういう設計の価値が具体的に理解できる。

@masuda220

Ubie Discovery における組織開発をソフトウェア開発的に理解する

エンジニアの生産性を上げるにはWHATよりもWHYを伝えること

完璧な要件が固まってから相談するというアンチパターン

多くのエンジニアではない新人プロダクトマネージャが陥りがちがアンチパターンがあります。

それは、エンジニアに気を遣ってできるかぎり作業時間を確保するために要件をギリギリまで詰めた状況になるまで話を持っていかず、なんとか「何を作るのか(WHAT)」が固まったタイミングではじめてエンジニアに共有するというパターンです。

こうして、ちゃんときまったWHATが出来上がってからHOWの開発を進めようすると、現状のシステムとのミスマッチや開発に時間のかかる箇所などがあっても、それらすべてを開発しようとしても、効率化できる余地は少なくなってしまいます。

結果、思ったよりも時間がかかってしまって、エンジニアの技術力が低いのではないかという不信を招いてしまったり、もっと簡単にできるかもしれない仕様にしないプロダクトマネージャに対して、能力が低いのだと考えてしまったりと、両者に決定的な溝をつくってしまうこともあります。

また、予想以上に納期がかかってしまうときに、それを無理やり短期化を実現するために想像以上に品質を犠牲にしてしまうこともあります。

しかし、WHY(なぜ、その機能が必要か)という一段抽象的な目的を理解できていると、別のWHATが浮かぶ可能性があります。そちらのほうが適切な速度でマーケットインできる可能性があり、そうすればもしかしたら生産性が高いと感じられるかもしれません。

プロジェクト・マネジメント・システムは存在しうるか

OSSで共有地の悲劇が起こることにどう対処するか

faker.js の作者のあの行動を「悪意」だと解釈するの、マジ、やめろ。あれは作者の「心の叫び」の表現でしか...

faker.js の作者のあの行動を「悪意」だと解釈するの、マジ、やめろ。あれは作者の「心の叫び」の表現でしかなく、ギリギリの線で踏み留まってたやん。本気の悪意ある行動されてたら、全然もっと阿鼻叫喚な事態になってたで?

@wraith13

オープンソースという参加者の信頼でなりたっている世界に対する攻撃なので「悪意」でしかないし、「心の叫び」は余所でやれとしか言いようがない。

npm含む、パッケージ管理システム自体の脆弱さとは関係なく、開発者の行動としては完全に擁護不可能である。

大企業は無償利用せず金銭的支援を行えと警告したのに改めないので作者がついに激怒、毎週2000万回以上ダウンロード...

人気オープンソースライブラリ「colors.js」と「faker.js」の開発者であるMarak氏が、これらのnpmライブラリを意図的に破壊しました。colors.jsおよびfaker.jsに依存しているプロジェクトは多数存在しているため、その影響が懸念されています。

そんなcolors.jsとfaker.jsの開発者であるMarak氏が、意図的に破損したバージョンをリリースしたことで、これらのライブラリに依存するプロジェクトに影響が出ています。aws-cdkのような人気の高いオープンソースプロジェクトを利用するユーザーがこの異変に気付き、状況を報告しています。

Marak氏はcolors.jsのバージョン1.4.44およびfaker.jsのバージョン6.6.6に非ASCII文字を追加しており、これによりアプリケーションが同ライブラリを利用すると、アメリカ国旗が無限に出力されてしまうバグが発生するようになりました。color.jsは正常に動作する最新バージョンが公開されていますが、faker.jsの過去バージョン(バージョン5.5.3)にダウングレードすることで問題を回避可能です。

colors.jsの利用者は、「colors.jsの作者は報酬が支払われないことに腹を立てているようで、ライブラリが読み込まれるたびにアメリカ国旗を出力するようになりました。なんてこった」とツイートしています。

2020年11月、Marak氏は「敬意を表し、フォーチュン500に属する企業および他の小規模企業に対して、私が無償で開発してきた成果物を提供するつもりはありません。他に言うことはありません」「これを機会に、私と6桁(数千万円)の年間契約を結ぶか、私が作成したプロジェクトをフォークして他の誰かに開発を継続してもらう必要があります」と言及しました。

また、Marak氏はこれらのライブラリのREADMEページに「アーロン・スワーツに何が起こったでしょう?」と記しています。なお、アーロン・スワーツ氏は、すべての人が平等かつ自由に情報にアクセスできるようにするために、MITキャンパスネットワーク上にあるJSTORデータベースから数百万件のジャーナル記事をダウンロードし、法廷闘争の末に自殺したという著名ハクティビスト。

NOTE:

JavaScript ライジングスター 2021

JavaScript界隈も以前よりは落ち着いた感じだが、それでも新しいものがどんどん出てくるな

石に割りやすい方向(石目)があるように、一枚岩に見えるシステムも業務活動に沿った割りやすい方向がある

巨大なデータベースを分割して

巨大なテーブルを分割して

巨大なSQLを分割して

巨大なジョブネットワークを分割して

巨大なバッチ処理を分割すれば良いだけだな。

方針はきわめて単純。

石に割りやすい方向(石目)があるように、一枚岩に見えるシステムも業務活動に沿った割りやすい方向がある。

@masuda220

今回は業務を大きく変えるという取り組みではなく、現在の事業活動の構造や方針にシステムを整合させる取り組みなので石目も読みやすいし、石目が実際の業務とはねじれている箇所も特定しやすい。

ねじれている理由も、技術視点の共通化や、20年前には一般的だった設計思想の影響が明確な箇所が多い。

@masuda220

AWS Well-Architected ドキュメントが読みやすくなりました!!(AWS Well-Architected ドキュメントの歩き方2022)

未だにスライドなり技術記事なりを公開する時は、詳しい人に「こいつアホか」と言われる恐怖と戦いながら、ですね

未だにスライドなり技術記事なりを公開する時は、詳しい人に「こいつアホか」と言われる恐怖と戦いながら、ですね。「知識は公開しなければ」という思いが10として、「公開してイヤな思いをするのイヤだな」という思いが8~9くらい。わりと拮抗してる。

@kaityo256

意味不明なマウント仕掛けてくる異常者がいると「あ、もうやめとこ」ってなるな

見積もり(Estimate)をしない。絶対しない。. 開発において「見積もりする」というのは、スクラム特有の...

----

----

----

----

DBスキーマ変更管理ツール sqldef を試してみた

最近 sqldef の名前をよく聞くようになった気がする

データ基盤をサーバーレスで構築したので概要を紹介

グーグルがファームウエア仕様の統一図る、「ソフトウエア定義」時代の終焉近し

それが近年、ハイパースケーラーが開発するサーバーやネットワーク機器などハードウエアの仕様(スペック)の共通化が進んでいる。その舞台はメタの主導で2011年に生まれた「Open Compute Project(OCP、オープン・コンピュート・プロジェクト)」だ。OCPにはグーグルやマイクロソフト、米Apple(アップル)などが参画。各社が開発したハードの仕様や設計図をオープンソースとして公開するだけでなく、OCPで各社の担当者が議論し、新しい仕様を生み出している。

かつてサーバーなどハードの仕様は売り手側のITベンダーが決めていた。今は買い手側であるハイパースケーラーが、OCPを通じて仕様を決め始めている。OCPの仕様に従ってITベンダーがハードを製造すれば、自社が欲しい仕様のハードを自社で開発せずとも入手できるようになる――。それがハイパースケーラーの目指した「理想」だった。

そしてルス氏によれば、今日のサーバーにおいては部品ごとにファームウエアの仕様がバラバラであることが、検証作業の妨げになっているのだという。

サーバーはマザーボードを中心に、SSD(ソリッド・ステート・ドライブ)などのドライブ、インターフェースカード、温度などを計測する各種センサー、電源装置、冷却装置といった様々な部品で構成されている。こうした部品には制御用のファームウエアが搭載されているが、その仕様は部品やメーカーごとにバラバラだ。サーバーを使う側であるグーグルとしては、ファームウエアを自由にコントロールしたりカスタマイズしたりできないことが、悩みの種なのだという。

同時にグーグルは、ファームウエアが稼働するサーバーの各部品についても、OCPを通じてモジュールとして再定義しようとしている。背景にはサーバー部品の種類がここに来て増加している事情がある。

例えばグーグルやマイクロソフトは近年、独自に開発したセキュリティーチップをサーバーに搭載し始めている。このセキュリティーチップは、サーバーOSのブートプロセスの改ざんを防いだり、OSやファームウエア、チップなどの改ざんを防いだりする。

さらにグーグルやマイクロソフトは、これまでサーバーCPUで実行してきたネットワーク関連処理やストレージ関連処理を、それ専用のチップにオフロードし始めている。こうした専用チップは「SmartNIC」や「IPU(Infrastructure Processing Unit)」「DPU(Data Processing Unit)」などと呼ばれている。

2000年代後半、米Intel(インテル)製の安価なサーバーCPUの性能が向上したことによって、それまでは各種専用チップが担っていたネットワーク関連処理やストレージ関連処理を、サーバーCPUとソフトウエアの組み合わせで担えるようになった。SDN(Software Defined Network)やSDS(Software Defined Storage)など「ソフトウエア定義」の時代の到来である。グーグルやメタなど買い手側がサーバーだけでなくストレージやネットワーク機器まで自社開発できるようになった背景には、ソフトウエア定義という技術トレンドが存在した。

しかし現在、サーバーCPUの性能向上は頭打ちになった。その結果サーバーには再び、様々な専用チップが搭載されようとしている。前述のSmartNICやIPU、DPU以外にも、機械学習専用チップやGPUなどもサーバーに搭載され始めた。ソフトウエア定義から専用チップへと、時代は転換しようとしている。

PCサーバを並列に並べて使い潰す時代から「やっぱ専用チップの方が性能出るわ」の時代に回帰しつつあると。

まぁ、変なベンダーロックインが発生しないならソフトウェア開発側としてはどっちでもいいかなといった感じか。

ゆずたそ流スライドデザインTips集

なぜ半導体不足が世界規模で起きているのか?

トヨタ式のJIT調達はサプライチェーンの健全性に依存しているので世界規模の混乱に対しては脆弱であったと

TikTokのByteDance社がパブリッククラウドに参入。「Volcano Engine」(火山引擎)クラウドは仮想マシン...

動画共有サービスのTikTokを提供するByteDance社は、クラウドサービス「Volcano Engine」(火山引擎)の提供を先月から開始し、パブリッククラウド市場に参入しました。

現時点のVolcano EngineのWebサイトを見る限り、説明はすべて中国語であるため、当面は中国国内向けサービスとして展開されるものと推測されます。

とはいえ、コンシューマ向けのTikTokを成功させた同社が、主にエンタープライズ向けのように見えるサービス群を抱えたパブリッククラウドをこれからどのように展開させていくのか、注目したいと思います。

コンシューマサービスのTikTokがパブリッククラウドサービスに参入とか。

成功するかしないかはともかく、パブリッククラウドサービスがポコポコ立ち上がるということは、それだけエンジニアの層が分厚いということで、そこは素直に凄い。

ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ

判断と決断の違いと決断のコツ

----

----

----

----

チームが成長するために必要だと思うリーダー・マネジャーの振る舞い

残して良かったドキュメント、いまいちだったドキュメント

残して良かったドキュメント

定期的に人に説明する内容

・入社時にやること

・今導入している技術やサービスのまとめ

・制度上のフローやガイドラインなど

新しく何かを始める際の記録

・技術を導入する際の選定の比較や議論

・制度が変わる際、過去とこれからの差分

・大きめなプロジェクトのまとめ

フィードバックのまとめ

・Request for Comments

・社内検証中に見つけた問題点

・ユーザーやクライアントの皆さまからのフィードバック

調査記録

・技術の調査

・市場の調査

残してもいまいちだったドキュメント

いつからいつまでの話か分からない

振り返りやまとめがない

書きっぱなしはダメということだな

Engineering Managerの役割を無くしてみた

----

----

----

----

K3ai

K3Sベースの機械学習プラットフォームかな?(よく見てない)

MySQL、PostgreSQL、SQLite3、SQL Serverのスキーマ定義を宣言的に管理するsqldefを、MySQLで試す

本当にtransactionは必要なのか?

エンジニアにおける"難しい人"への対処法

DockerとVS Code Remote Containersを用いたフロントエンド開発環境構築

「3種類」で管理するReactのState戦略

だからデータベース設計とかAPIデザインは1番命をかける場所だよね

マジで設計って大切で、Goの父であるRob Pikeも「正しいデータ構造を選択し、うまく整理していれば、アルゴリズムはほとんどの場合、自明のものになる。プログラミングの中心はアルゴリズムではなくデータ構造」なんて言ってるし、だからデータベース設計とかAPIデザインは1番命をかける場所だよね

@komi_edtr_1230

レビューの仕方

みずほ銀行 他行宛て振り込み 一時できなくなる不具合

みずほ銀行で30日午後、ATM=現金自動預け払い機などでほかの銀行宛ての振り込みが一時、利用できなくなる不具合が発生しました。現在は、復旧しているということです。

発表によりますと、30日午後3時半ごろから午後4時半ごろにかけて、みずほ銀行のATMとインターネットバンキングでほかの銀行宛ての振り込みの一部が利用できない状態になったということです。

銀行によりますと、夜間や休日の時間帯の入金処理に関わるシステムの設定に、人為的なミスがあったことが原因だとみられています。

影響が出た取り引きの件数は分かっていませんが、不具合はすでに復旧し、順次、振込先への入金の手続きを進めているということです。

ひぇぇ

三菱電機への不正アクセスで対象となった安全保障の影響に関する情報についてまとめてみた

Lustre ファイルシステムのファイル消失について(PDF)

この度は貴学スーパーコンピュータシステムにおいて、弊社 100%の責任により Lustre ファイルシステムのファイル消失の重大障害を来し、多大なるご迷惑をお掛けしたことを深くお詫び申し上げます。

2 ファイルが消失したユーザ様への補償について

この度のファイル消失は 100% 弊社の責であると考えており、補償につきましては、ユーザ 様、並びに、貴学のご意向に沿うようにいたします。

大迫力の謝罪文でチビリそう。

テクニカルサービス本部長が直々に土下座してるのと一緒だものな。

スーパーコンピュータシステムのファイル消失のお詫び

2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました.

・対象ファイルシステム:/LARGE0

・ファイル削除期間:2021年12月14日 17時32分 ~ 2021年12月16日 12時43分

・消失対象ファイル:2021年12月3日 17時32分以降,更新がなかったファイル

・消失ファイル容量:約 77TB

・消失ファイル数:約 3400万ファイル

・影響グループ数:14グループ (うち,4グループはバックアップによる復元不可)

ひぇぇ

プログラマなんて飯を食べれればいい派にとって「高1の途中以降の数学は要らない」と思う

リソースシステムを一新した「Krita 5.0」が公開

オープンソースのペイントソフトウェアKritaの開発チームは12月23日、メジャーリリース「Krita 5.0」を公開した。2年半ぶりのメジャーリリースとなり、多数の強化が加わっている。

安全で柔軟なAlways-Valid Domain Modelの作り方

オレ的EXPLAIN技を語っちゃうゾ

でっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。

少数派の意見かもしれないけど、プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。

@rui314

自分もそう。

大事ではないことを大事だと錯覚した結果、オーバーエンジニアリングになる

大河原克行の「パソコン業界、東奔西走」 NECの「元気な米沢!」活動に見る、PC事業を支えるDNA

東芝が世界初のノートPCとなる「Dynabook(J-3100 SS)」を市場に投入。わずか3カ月で98NOTEを開発せよ、との号令が米沢日本電気に下った。

出荷開始は、年末商戦突入直前の11月24日に決められた。米沢日本電気では、この時、初めて「逆線表」という手法を採用した。11月24日という出荷予定日を線表に書き込み、そこから遡って、作業日程を決めるというものだ。本来は、仕様検討や回路設計、検証、部品調達、生産、出荷と順を追って、線表が引かれる。しかし、逆線表では出荷日が最優先され、それにあわせて、すべての作業が決定するというものだ。そして、それがわずか約3カ月間に凝縮されている。

「当時は、なりふり構わず開発に取り組んだ。毎日のように、決定の遅れや指示の遅れを指摘し、問題解決を迅速に図っていった。過去に経験したことがない緊張感と危機感を持って臨んだプロジェクトだった」と柴田エグデグティブアドバイザーは振り返る。

2008/01/16に公開された記事

98NOTEは1989年発売らしいので、ギリギリバブル崩壊前の頃か?

イケイケの上げ調子の時はなりふり構わず働いていたことがよくわかるエピソードであるな。

めっちゃビビってます。力量不足の人が来ると、穴埋めしなきゃいけない分だけ仕事が増えるので...

めっちゃビビってます。力量不足の人が来ると、穴埋めしなきゃいけない分だけ仕事が増えるので。おうちに帰して下さい。

「技術力低いのに案件やるな」とか

「プログラミングはそんな簡単じゃないから」とか

駆け出しの人をビビらせるエンジニアって結構居るけど本心は「俺の仕事減ったらヤバいな」って思ってるだけだから気にせずGOです。

#駆け出しエンジニアと繋がりたい

#今日の積み上げ

#プログラミング初心者

@hanakikaede

@syauichi

ほんまそれぞ

「マイクロサービス」はそうとう小さく分割するイメージだけど、マイクロサービスはデータベース分割なので

「マイクロサービス」はそうとう小さく分割するイメージだけど、マイクロサービスはデータベース分割なので、データベースの分割で考えると、それほど小さく切り刻むわけではない。

1テーブル1マイクロサービスまで分割可能だけど、全てをそこまで分割するメリットはあまり無さそう。

@masuda220

振る舞い(なんらかのデータ処理)を伴うマイクロサービスではその通りだけど、ある種の静的(あるいは一部動的)なデータを配信するだけのマイクロサービスでは実質的に1マイクロサービス1テーブルみたいな構成になることもあった。

経緯としては、各種のマイクロサービスから参照したいデータ(ほぼ静的データ&リードオンリー)があるけど、マイクロサービス間でDBで共有するのは如何なものかということでデータ配信専用のマイクロサービスが爆誕した。

結果的には特に問題は無かったし、モックAPIでテストもしやすかったし、スキーマ変更をしても他のマイクロサービスに影響がないことが保証されてたので割と良かった。

tblsとGitHub Actionsを使ってDBマイグレーションを含むPRには自動更新したER図を追加する

よさそう

歳を取ると意見通せるようになったりするが、コレは逆に自分を律していかないとヤバいね

アーキテクチャの話、割と個人の体験談みたいなので話が通るけども、それは僕が信頼されてるから通るのであって、若かりし頃の自分は同じこと言っても通らなかったもんな。

歳を取ると意見通せるようになったりするが、コレは逆に自分を律していかないとヤバいね

@nagise

経験を信頼してもらえるというのはありがたいことだけど、そこに胡座をかいて何でもゴリ押しするようになると老害一直線なので最新の注意が必要なのだ。

詳解 リリース計画

不確実性を計画に押し込んで見なかったことにするのがウォーターフォール...

自分は

不確実性を計画に押し込んで見なかったことにするのがウォーターフォール

不確実性を人間の能力に押し込んで見なかったことにするのがアジャイル

という説明はたまにする

「アジャイル」に抱いている根本的な違和感がわかった(「」な点に注意)。「ウォーターフォール」とされる手法が、人間の計画立案能力や未来予測能力に関して高すぎる理想をもっていたように、「アジャイル」は人間のコミュニケーション能力について高過ぎる理想を抱いているように思う。

@kmizu

@tokoroten

んでさらに言うと

不確実性をプロセスに押し込んで見なかったことにするのがスクラム

ってのも、まれによく言う

本当に「俺たちはスクラムをやっているから勝っている」っていう人たちがいっぱいいるのよ……

@tokoroten

ガバナンスが何もないところにスクラムを導入するには、

「スクラムを導入するといろんなことがが上手くいきます」って言うしかないんだけど、

それを言い続けていると、いつの間にか「俺たちは勝ってる」に変質するんだよね

とてもよく見た

@tokoroten

バグを許さない、完璧なリリースじゃないと許さない風潮をやめないと日本はこれから厳しいのでは...

そんなのモノによるとしか言えないんだよなぁ

技術的負債は開発者体験を悪化させる

Apache Log4jの脆弱性とともに浮かび上がったオープンソースのメンテナの責任範囲の問題

この場合は、最初に問題を指摘した(世界的な大企業であり、Log4j の脆弱性で被る金銭的被害額も多大であろう)Alibaba のエンジニア側が問題の修正の責任を負うべきであり、オープンソースのメンテナは大企業のために無償で働くべきではなく、他の人達は(早く修正しろと言い立てるのではなく)一歩下がって見守り、オープンソースの利用にともなうリスクと責任、そしてコストを受け入れるべきだ、というのが彼の提言である。

バグを見つけたら修正コード出して貢献しろというならまだ分かるけど、「修正の責任」まで負えというのはちょっとよくわからない。

再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ

Log4J問題で明るみになった「ボランティア頼み」の危うさ

関連:

テストを書くか書かないかの状況判断

RettyのDBの負荷を7割減した取り組み

なぜリンク存在確認がボトルネックだったのか

リンクの存在確認をする処理ですが、どこに負荷要因があるかというと、

  • 1度のページ閲覧(PV)あたりの発行クエリ数が多く、平均的に数百クエリ/PVが発行される
    • SEOの歴史的背景より、内部リンクそのものが多い
    • 十分な数のリンクを表示できるようにするため、表示されるリンクよりも多くのリンクを候補としている
  • キャッシュの有効期限を長くはできない
    • ページに掲載されるコンテンツ(お店)の数が日々増減するため
  • 対象のページ数が膨大である
    • Rettyまとめページは複数の条件(エリア・カテゴリ・目的など)の組み合わせから成っており、非常に多くのページが存在する
    • 短い有効期限でキャッシュが切れ、その対象が多いのでDBに直接発行されるクエリ量は大きくなる

という状況でした。

サービスはindex作成バッチとWebアプリケーションの2つから構成されていて、

  • バッチ: 日時バッチでindex(RustのHashSet)を生成しS3に保存する
  • Webアプリケーション: S3からindexを読み込み、それをもとに集合演算をするgRPCを提供する

となっています。

良いコードとは何か

Rob Pike のプログラミングに関する5つの掟

ドメイン知識を隠すコード、隠さないコード

Protocol Buffersを使ってSQSのメッセージを構造化してみた

【動画レポ】RPACommunityスポンサー動画「マジ、キツかったプロジェクトを教えて!」IT企業7社がライトニングトーク...

MySQLが得意なこと、不得意なこと(仮)

リファクタリング自爆奥義集

新卒研修2週間で一つのWebサービスをチームで作り切った話

8年もののサービスをフルリプレースした話

スケーラブル CI/CD with Nx モノレポ

社内で提供しているマイクロサービスの参考実装について

自走する組織に必要なのはルールではなくガイドライン

dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り

採用技術のあるべき姿を見つめ直し、ReactNativeとさよならをした話

「Atom」の開発者が究極のコードエディターを目指す ~「Zed」の開発が始動

ラクスにおける「システムを腐敗させない組織だった技術刷新」を行う取り組み

  • 取り組みの発端
  • これまでの軌跡
  • 継続のための試行錯誤
    • 割り込み作業対策
    • 認知度向上
  • 取り組みのサイクル
  • 大まかな進め方
  • おわりに ――この取組のつらみ
    • 成果が出るまで時間がかかる
    • 知見がいくらあっても足りない

よくあるオンプレOracleからRDSに移行したDBAの反省文

go-taskでストレスフリーな開発体験

組織に失敗学でPostmortem文化の定着を試みた話

インクリメントを作る意識で地に足をつけた開発をしよう

PR TIMESにおけるリファクタリングデー

僕がユースケース駆動開発をする理由

NEXT