サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
blog.shibayu36.org
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;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また
あるstruct構造の中のdbというタグの内容に何が含まれているかをすべて取得したい時があったため。 たとえばこういう構造があったとして type Timestamp struct { CreatedAt time.Time `db:"created_at"` UpdatedAt time.Time `db:"updated_at"` } type JsonField struct { Foo string `json:"foo"` Bar string `json:"bar"` } type Post struct { ID int64 `db:"id"` UserID int64 `db:"user_id"` Body string `db:"body"` PostedAt time.Time `db:"posted_at"` Deleted bool `db:"deleted"` N
ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス
PRです。妻が書いた「めんどくさがりやの自分の機嫌を取る暮らし」が本日発売されました。 めんどくさがりやの自分の機嫌を取る暮らし (BAMBOO ESSAY SELECTION) 作者:てらい まき竹書房Amazon 僕から見ても、妻はめんどくさがりやなのに「こんな生活がしたい!」という理想は高い性格に見えています。そういう性格を満たすために色々工夫をしているのですが、その工夫がコミックエッセイになりました。目次をピックアップすると、こういう話題を取り上げています。 髪の毛のケアがめんどくさい…でも、ツヤツヤ髪になりたい! 文字だけの本を読むのがむいてない…でも、いろんな知識を身に付けたい! 果物の皮をむくのがめんどくさい…でも、フルーツたくさん食べたい! お湯を沸かすのがめんどくさい…でも、お白湯生活始めたい! 眉毛を描くのがめんどくさい…でも、似合う眉毛を手に入れたい! 花を育てる才能
clusterのリアルタイム通信サーバーの漸進的な進化 - Cluster Tech Blogを見て、リアルタイム通信の仕組みに興味を持った。しかし、MQTTプロトコルは使ったことがなく、どのようなプロトコルなのか、何がそんなに効率的なのか、なぜIoTなどでよく使われるのかなどが分からない状態だった。 そこでChatGPTを使えば自作しながらMQTTプロトコルを学べるのではないかと思い、https://github.com/shibayu36/go-mqtt-playground にて作り始めた。ひとまず簡易的にCONNECT/SUBSCRIBE/PUBLISHをハンドリングできるようになったのでメモしておく。 MQTTプロトコルの特徴 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html のAbstractが
GitHub Copilotについて調べていたときに見た Research: quantifying GitHub Copilot’s impact on developer productivity and happiness - The GitHub Blog の記事の中で、開発生産性を測るSPACEフレームワークを使って計測しているのを見かけた。SPACEフレームワークという文字は見たことあったが調べたことはなかったので、この機会に調査した。その調査の中で開発生産性の可視化の改善方法についても考えたため、考えたことをまとめておく。 まずSPACEフレームワークがあったとしても、これをそのまま使うことはないと感じた。個人的に5カテゴリの分類の納得感があまりなく、計測する指標の例の計測難易度が非常に高いと感じたためだ。また使う難易度も高く見えて、使う人にも専門性が必要と感じるため、フレー
次のページ
このページを最初にブックマークしてみませんか?
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く