サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
blog.shibayu36.org
オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが
最近、ユーザーのニーズを理解して定性的な意見から施策の優先度をちゃんと決められるようになりたいと思っている。そこでUXリサーチについて学習しようと決めた。そこでまずは「はじめてのUXリサーチ」を読んだ。 はじめてのUXリサーチ ユーザーとともに価値あるサービスを作り続けるために 作者:松薗 美帆,草野 孔希翔泳社Amazon この本では質的リサーチの方法について、さわりの部分を全体的に学べる。何もわからないところからの入門として最適だと感じた。特にいろんな事例を交えて説明してくれることがありがたい。 個人的に印象に残ったのは以下の点。 UXリサーチには「何を解くと良いか、正しい問いを立てるため」の探索のリサーチと、「どのように解くと良いか、正しい解決策を作るため」の検証のリサーチがある。この二つは目的や状況に応じて使い分けたり、組み合わせたりする必要がある インタビューなどで質的リサーチを
サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか?」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか?」「この指標に繋がると言っているが
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA(自分の担当分工数10日)、プロジェクトB(自分の担当分工数20日)で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め
エディター側でなくCLI側でgit grepするのはいろんなオプションを渡せて便利だ。たとえば --and や --or でいろんな条件で絞り込んだり、-C オプションで周辺の行も一緒に見ることもできる。 一方でCLI側でのgit grepでは、エディター側をさっと開きにくいという問題がある。そこで、git grepの結果をfzfでさらに絞り込んだ上で選択するとすぐにエディターで開けると便利そうと感じ、git-grep-fzfというコマンドを作ってみた。 使ってみている様子はこんな感じ。grepした後にfzfで絞り込んで該当行をエディターで開いている。https://github.com/golang/go に対してgit-grep-fzf Sortedしている様子。 また、git grepに渡せるオプションはこのコマンドに渡すことができるので、複数条件で絞り込んで周辺行を見ながら開くこと
Emacs実践入門 ~思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus) 作者:大竹 智也技術評論社Amazon ようやく読んだ。とりあえずEmacsを使いはじめてtutorialを終えたくらいの人や、そろそろEmacsの設定ちゃんとしようと思う人はまず読んでおくと良いとおもった。 僕の中では出てきた拡張がほとんど知っているものだったのでその点については参考にならなかった。しかし、フォント設定など基本設定まわりなどはずっと昔に設定した後そのまま放置していたので、その部分の最近の設定方法を知ることが出来たのが良かった。 フォント設定の等幅設定が特に参考になった。 これまでは以下のようにしていた。しかしこの方法だと文字の拡大縮小をするとおかしくなり、文字サイズを固定して開発するしか方法が無かった。 (create-fontset-from-ascii-font "
最近仕事では機能開発ではなくデータ分析の仕事をしばらくやっているのだが、同僚から「本物のデータ分析力が身に付く本」というムックが良かったと聞いたので読んでみた。 本物のデータ分析力が身に付く本 (日経BPムック) 作者:河村 真一,日置 孝一,野寺 綾,西腋 清行,山本 華世日経BPAmazon この本は「データを集計し計算する」といった、いわゆる一般的にはデータ分析のメインと考えられていていろんな書籍で語られているような部分には焦点を当てず、その前後で何をすべきかを語ってくれている。たとえば データ分析実行の前には、開発設計で書くようなdesign docのようなものをデータ分析設計としてまとめる。さらに生データを見てデータの信頼性や傾向を事前チェックし、設計と事前チェック結果を見て分析方法を選択する データ分析実行の後には、結果の確からしさの検証をしつつ、バイアスを避けた結果の解釈を行
前回MySQLのREPEATABLE READとREAD COMMITTEDの違いを知るために色々試した - $shibayu36->blog;という記事を書いたところ、yoku0825さんにMySQL 8.0以降だとperformance_schema.data_locksが使えると教えてもらったので試した。 ちなみに、後ろからロックがぶつかるクエリを実行しなくても、MySQL 8.0だとSELECT * FROM performance_schema.data_locksでロックの範囲を確かめることができます。 ギャップつきロックがInnoDBのスタンダードで、X lockがレコードとギャップのロック、X not gapが単なるレコードロックになります— yoku0825 (@yoku0825) February 27, 2024 テーブル定義 CREATE TABLE `posts`
Goのパッケージごとのビルド時間を計測したいんだけど (どのパッケージのビルドに何秒かかってる、とか見たい) どうしたらいいのか、ちょっとググってみたけどランタイムにおけるパフォーマンス測定の話題ばっかり出てくる— うたがわきき (@utgwkk) February 26, 2024 前やったことあるがブログに書いてなかったのでメモしておく。 まずGoのビルド時間についてはAnalyzing Go Build Times | howardjohn's blogが非常に分かりやすく参考になる。この中でAction Graphというものに言及があり、これを使うことでパッケージごとのビルド時間を可視化できる。 例えば自分のgo_todo_appというものを使ってみる。 まずgo buildでactiongraph.jsonを吐き出し $ go build -debug-actiongraph=a
MySQLのトランザクション分離レベルについてふんわりとした理解しかないなと感じた。もう少し理解するために、とくにREPEATABLE READとREAD COMMITTEDの違いを手を動かして色々確認してみた。 以下の記事を参考にした。 [RDBMS][SQL]トランザクション分離レベルについて極力分かりやすく解説 #SQL - Qiita MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.1 トランザクション分離レベル 大まかな違い 公式ドキュメントを見る限り ノンリピータブルリード、ファントムリードが発生するか 範囲に含まれるギャップへのほかのセッションによる挿入をブロックするか の違いがありそうに見える。 ノンリピータブルリード、ファントムリードが発生するかを試す 以下のテーブルを作る。 CREATE TABLE `posts` ( `title`
Goで関数の引数に、struct Aという型もしくはstruct Bのどちらかを受け取るということをしたかった。interfaceをちゃんと切ってそれに必要なメソッドをAとBに実装することで実現できることを知った上で、あまり丁寧にそういうことをせずにやりたい。 色々調べると、genericsを使うとできるようだ。 package main import "fmt" type A struct { Field1 int } type B struct { Field2 string } type AorB interface { A | B } func PrintAorB[T AorB](s T) { // Tで受け取ったものをそのままs.(type)とは出来ないので、一旦anyへキャスト switch v := any(s).(type) { case A: fmt.Println(v.
最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理
毎年恒例YAPCに行ってきました!いやー今回も楽しかったですね。いろんな種類の発表もあり、久しぶりの人や名前は知っているけど話したことない人ともたくさん関われました。スタッフの皆さん、こんな楽しいカンファレンスを開催してくれてありがとうございます。 発表としてはy_matsuwitterさんの「経営・意思・エンジニアリング」がもっとも印象に残っています。自分はエンジニアの立場でもちゃんと経営のことを知っておいた方が良いと思い、最近少しずつ学習しています。なぜなら知っておくことで自分の課題意識を自分の視点からだけでなく、経営に関わるメンバーのメリットを意識して伝えられ、その結果目線を合わせて改善に取り組めるからです。そういう気持ちがあったため、この発表の中で説明されていた経営の3つの変数と4つの制約の話は非常に参考になりました。 懇親会や二次会では、ar_tamaさんに着いて行ったらakir
異文化理解力という本がおもしろいと聞いたことがあり、興味があったので読んだ。想像以上に面白く夢中になって一気に読んでしまった。 異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養 作者:エリン・メイヤー,田岡恵英治出版Amazon この本は、国ごとの文化が、そこに属する人々の知覚・認識・行動へどれほど影響を与えているかを教えてくれる。指標として8つを提示し、それぞれの中で各国がどのような位置にいるかを相対的に示してくれる。8つの指標とは次のようなものだ。 コミュニケーション:ローコンテキストvsハイコンテキスト 評価:直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック 説得:原理優先vs応用優先 リード:平等主義vs階層主義 決断:合意志向vsトップダウン式 信頼:タスクベースvs関係ベース 見解の相違:対立型vs対立回避型 スケジューリング:直線
この記事はクラスター Advent Calendar 2023 シリーズ2の20日目の記事です。昨日はMSA_iさんのClusterの会場アップロードを楽にしたいでした。 入社エントリで書いたとおり、7月にクラスター株式会社に入社し、その後ソフトウェアエンジニアとしてサーバーサイドをメイン領域とし半年ほど仕事をしてきました。そこで今回は自分の半年の様子を振り返りつつ、クラスターでのサーバーサイドエンジニアの仕事の様子をお届けできたらと思います。 半年でやったこと オンボーディング 最初は何はともあれオンボーディングです。入社直後は人事部から会社の規則の説明を受ける、社長の加藤さんとランチを食べながら会社のミッション・ビジョンの話を聞くというところからスタートします。 その後はエンジニア側のオンボーディングフローに入ります。エンジニア用のオンボーディングドキュメントが存在しており、そのドキュ
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか
たとえばユーザー向け開発とリファクタリングなどの内部改善を、スプレッドシートの別シートで管理していたとする。これらを別シートに分けている理由は管理したい情報がそれぞれで違うためだ。 一方、それら進行状態については全部一覧で見たいことがあった。そうすることで、全てのタスクを含めて状況を把握しやすいためだ。 これを対応するためにGoogleスプレッドシートでいろいろ試してみたのでメモ。 シートの例 https://docs.google.com/spreadsheets/d/1IJ4qORImjfzVDodH0Z4vINRmXcqYjg9095uRVlTfSRI/edit#gid=0 にサンプルを作ってみた。シート1には機能開発一覧としてID、ステータス、タイトルという列を使って管理している。シート2にはリファクタリング一覧としてID、ステータス、名前、担当者が入っている。 QUERYと配列結
タイトルを見てなんとなく興味が惹かれたので読んだ。想像以上に面白くてためになった。 多様性の科学 作者:マシュー・サイドディスカヴァー・トゥエンティワンAmazon 自分はこの本から多様性が実際に何に役立つかを学ぶことができた。世の中では多様性が大事と非常に多く言われている。しかし自分は多様性の高さによってどのような効果があるかについて理解ができていなかった。この本はいろんな観点から効能について教えてくれる。例えば興味深かったところは 人の物事の捉え方には、ただものを見るという単純な行動にさえ、文化に基づく違いがある。ある問題において、見方が多様な集団を作ることにより、新たな捉え方や落とし穴への気づきが得られる 逆に同質な集団の場合、考えていることが正しいと周りも同意するため、それが間違っていたとしても信じてしまう 賢い個人がいるだけでなく、解決しようとする問題空間の中を網羅するような多様
git stashをもっと便利に扱いたいと思い、fzfを使って使いやすくしてみた。以下のURLに載っているものを参考にして自分にとって使いやすいように改変した。 fzfでGUI選択したファイルをgit stashするシェルスクリプト git-stash-explore できたこと 今の変更ファイルをfzfを使って選択して、選択したものだけをstash (git-stash-select) stash一覧の中から中身をpreviewしながら選び、apply or deleteする (git-stashes) 現在の変更ファイルから一部を選んでgit stashするコマンド fzfでGUI選択したファイルをgit stashするシェルスクリプト を参考に、git-stash-selectというコマンドを作った。 #!/usr/bin/env bash # Get the root direct
設計やアーキテクチャについて学び直したいと思い、今回はセキュア・バイ・デザインを読んだ。 セキュア・バイ・デザイン: 安全なソフトウェア設計 Compass Booksシリーズ 作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版Amazon この本の作者は「オブジェクト指向入門」という本の思想に共感しているようで、自分もその本が大好きなので、共感できる内容が多かった。またDDD周りで定義されている用語を教えてくれるので、その辺りがぼんやりしてきていた自分にとって、再度学び直すきっかけになった。 以下のトピックが印象に残った。 集約によって、複数のエンティティの状態変化を常に正しくできる。論理的なトランザクション(DBのトランザクションではない)を作れるということ 妥当性確認は以下の順で行うことで、より負荷のかかる高度な妥当性確認を
gotesplitにAdd -race to list when it is specified for test optionsというPullRequestを投げたのだが、この背景を書いておこうと思う。 まずGoでは-raceオプションについて、以下のような挙動を起こす。 -raceフラグをつけるとruntime/raceがおそらく一番依存の深いところに追加されてコンパイルされるっぽい? https://github.com/golang/go/blob/go1.21.2/src/cmd/go/internal/load/pkg.go#L2573-L2576 あたり? そのため、go testとgo test -raceはビルドキャッシュが全く異なる。つまりgo testのビルドキャッシュはgo test -raceのビルドに全く使われないし、その逆も同じである gotesplitの以前
最近アーキテクチャ関連の知識を身につけようと思い、進化的アーキテクチャを読んだ。 進化的アーキテクチャ ―絶え間ない変化を支える 作者:Neal Ford,Rebecca Parsons,Patrick Kuaオライリー・ジャパンAmazon 言葉の定義が独特で、正直この本は難しいな〜と思った。勉強になったなと思うことは、変更しやすいアーキテクチャを作るための流れの部分。自分は以下のように作ると解釈した。 そのアーキテクチャが対象とする領域で、進化しても保護したい重要な特性を特定する 例: スケーラビリティ、監査可能性、即応性など それぞれの特性に対して適応度関数を定義する 適応度関数とは、あるアーキテクチャ特性がどの程度満たされているかを評価する客観的な指標 たとえば即応性を、全レスポンスの95%tileのmsで指標化するみたいなイメージ 定量指標がどの値を超えたら望ましくないかを定義し
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
あるファイルが最近どの程度の頻度で更新されたのか、マージコミット単位(≒PullRequest単位)で調べたいことがあった。git logのコマンドを使ったら簡単に調べられたのでメモ。 たとえば1年以内に https://github.com/x-motemen/ghq のレポジトリで .github/ 以下に変更を加えたマージコミットを取得したい場合はこんな感じ。 $ git log --merges -m --first-parent --pretty=format:"%cd - %an: %s(%H)" --since="1 year ago" .github/ Sun Apr 16 23:27:26 2023 +0900 - Masayuki Matsuki: Merge pull request #359 from x-motemen/coverage(e7f736f22376d
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
build cacheがうまく使えているかを調べる必要があり、どのパッケージが再コンパイル予定かを確認するコマンドを調べたのでメモ。ちょっと自信がない部分もあるので間違っているところがあったら教えてください。 先に結論から言うと、go listを使った以下のコマンドで確認できる。-depsで依存関係も含めて辿り、StaleなpackageだけStaleな理由も併記して表示する。 go list -deps -f '{{if .Stale}}{{.ImportPath}}:{{.StaleReason}}{{end}}' ./... たとえば https://github.com/golang/protobuf を使って試してみる。 go clean -cacheで全てのbuild cacheを飛ばした状態の表示。標準ライブラリなども含めて全てコンパイルする予定であることがわかる。 $ go
あるディレクトリ以下で特定のパターンにヒットする行を全て削除する - $shibayu36->blog;に引き続き、やり方を模索してみた。 たとえばgolangを使っていて、ある処理をt.Cleanupに寄せたので対応するdeferを全部消したい時がある。 // StartHogeHelperの中でt.Cleanupを使って自動でhogeHelper.Close()を呼ぶことにした hogeHelper := StartHogeHelper(t) // この行を消したい defer hogeHelper.Close() これはつまり「StartHogeHelperを呼んだ次の行でdeferを呼んでいたらdeferの行を削除する」と言い換えられる。もちろんこのやり方だと間違ったものも削除することもあるが、そこは手動で直すとして、ひとまず大多数を自動削除したい。 awkを使って実現する。また効
次のページ
このページを最初にブックマークしてみませんか?
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く