脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba
いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日（2024年6月18日）発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き
git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba
git-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can
GitHubのMerge Queueとは何か？それと、認識しておきたいこと - Mitsuyuki.Shiiba
同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う？」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ（なんでもそうか・・・） Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ（ベースブランチ）の最新の変更を取り込んでからChecks（つまりCI）を実行して、それが成功したらマージしといて！」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
これからの時代に求められるアジャイルな組織づくりとリーダーシップ - Mitsuyuki.Shiiba
アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
ゆめみのフロントエンドコーディング試験の題材で React の勉強をしました - Mitsuyuki.Shiiba
ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
CircleCI の設定を絵に書いて頭の中を整理 - Mitsuyuki.Shiiba
2021-12-14 更新 ======= Resource Class Pricing のページの情報が正しいと確認がとれました。Free プランでも、例えば Docker Executor の Medium+, Large が利用できるようになっているとのことです Docker Layer Caching (DLC) Free プランでも DLC が利用できるようになったと確認が取れました なので、このブログの絵の DLC は黄色の箱から白の箱に更新しました 英語版のドキュメントで該当部分の文言を削除しました（日本語版はしばらくお待ちください） この記事に書かれている情報は 2021-12-14 時点でのものになります！ 更新内容ここまで ===== どーも。こんにちは。こんばんは。しーばです。 この記事は Calendar for CircleCI Advent Calendar 2
僕も41歳だー。CircleCI に入社しました。 - Mitsuyuki.Shiiba
そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー！ https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ
「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba
4/26 に発売されます！ 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー！」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
「まず公式のドキュメントを読め」というのは分かってるんだけど・・・ - Mitsuyuki.Shiiba
サービスやライブラリーやフレームワークを触るときは「まず公式のドキュメントを読め」というのは分かってるんだけど。なんだかつらいときが多くて。僕の順番的にはこういう感じだなーって思ったメモ。 1. 公式ドキュメントを読もうとする 雰囲気だけパラパラと。特に英語の場合は、中身を読もうとしてもすぐに挫折する。 後で倒しに来るために、いちどボスの姿を見ておこう。みたいな気持ち。 2. ググる：ブログとかキータとか Stack Overflowは、まだはやいので、ブログとかキータとかみたいにまとめられた情報を漁る。日本語の情報が少なければ英語のブログとかも。 みんなが使ってみた感じとか、どんな風に使ってるか、困ったかとかを知る感じ。 3. 手を動かす とりあえず、細かいことはいいから手を動かしてみようか。って。全く理解せずにチュートリアルとかをやってみる。 そしたら、自分が興味ある部分とかツールの使
Headless ChromeをDockerに入れてGebで遊んでみた - Mitsuyuki.Shiiba
昨日書いたんだけど、Kafkaを触ろうと思ってるんだよ？でも、触ろう触ろうと思ってると、違うものが目に入ってくるのであった。ということで Headless Chromeで遊んでみた Kafka一切関係なく、この記事を見かけたから。 Getting Started with Headless Chrome | Web | Google Developers この辺のこともあるので、ちょっと見とこうかなって。 Phantom.jsのメンテナー、プロジェクトの将来に疑問を呈し、その座を降りる ただ、今手元にある環境でごにょごにょするのもなんか嫌だなぁ・・・って思ったので、無駄にDockerに詰め込んでGebで遊んでみた。そして、そのせいで疲れた(ヽ´ω`) できあがったものは これ。 https://github.com/bufferings/sandbox-gebheadlesschr
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
信頼関係 ビジネス側の人編。 - Mitsuyuki.Shiiba
このまえ書いたのの続き この前の→ 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba 今日はビジネス側の人の信頼を得るために僕が考えていること。 例によって、相手の立場で考えるところから始めよう。 ビジネスな人なので、ビジネスゴールがあって、それを追いかけてるんね。そのビジネスゴールは絶えず変化し続ける。最初に決めた場所に、ずっと向かい続けてもしょうがなくて。常に状況をみてどこに向かうべきかを判断し続けないといけない。という状況。 開発チームに求めるもの ここで、ちょっとタクシーに乗ることにしよう。 「京都の醒ケ井高辻ちょっと下がったところまでお願いします。」 こういうタクシーだったらいいなーってのは。 目的地までの最善の道を知っていること。「最短の道」でなくてよくて。渋滞や工事を考慮して「最善の道」を選んで欲しいなーと。 「この道を通ってここま
開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba
組織パターンを読んでたら@haradakiroさんに「そんな風にして自分の頭の整理できるよ」と言われ。なるほど。と。なので整理。とはいえパターンに昇華させられるまで考えられたりはできないので雑だよ。 作りながら書いてるから最終的にどうなるかは僕も知らんよ。 立ち位置 最初に立ち位置を簡単に。 僕は自社でWebサービス作ってる会社のいちウェブアプリエンジニアです。 いい感じのチームでコードを書いて過ごしたい！ ↑ じゃあいい感じのチームを自分で作ろう！ ↑ じゃあチームの外側のコントロールしなきゃ！ ってだんだんやりたい場所から遠ざかっている感じ。てイマココ。 まぁこれも悪くない。 開発するときに考えていること まずは何をやるにも信頼関係を築くのが最初に必要よね。ないと色々面倒。 信頼を得て最初に取り組んだのが、プロジェクトのリーダーをBizLeadとDevLeadに分けたこと。 BizLe
信頼関係 開発チーム編 - Mitsuyuki.Shiiba
自分の中の考えをまとめるシリーズの続き。前回まではこんなの 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba 信頼関係 ビジネス側の人編。 - Mitsuyuki.Shiiba 今日は開発チームの信頼を得るために僕が考えていること。これで信頼編は最後！ いつもどおり相手の立場で考えるところから。とはいっても僕はエンジニアなので。自分のことを考えればいいのかな。 エンジニアは良いものを作りたい。お金が儲かるってのはもちろん良いんだけど、もちょっと奥の方に、誰かに喜んでもらえたら嬉しいとかがあるかなーと思う。とにかく良いものを作りたい。 でも、実際の仕事でそんな気持ちをそのまま出せるかというと。そういうもんでもなくて。それは何故だろう？と考えてみたんだけど。理不尽なことが多いからかな。と思った。 開発チームって工程的には下流にいて、だから、理不尽なこ
node.js の logging library の winston のソースを読む - Mitsuyuki.Shiiba
node.js を使い始めて javascript かわいいなーと思い始めたこのごろ まだ javascript の扱い方から勉強してるんだけど そんなわけなのでソースを読んで勉強しようかなと winston を選んでみた winston は nodejitsu 社が作ってる Flatiron ってオープンソースフレームワークのモジュールの一つとして開発されてるす いくつか便利機能があるんすが query とか、例外ハンドリングとか、profiler とか そのへんは今回は触らずにロギング周りを見ていくす この記事は 東京Node学園祭2012 アドベントカレンダー の 26 日目の記事です。 ファイル lib の中身はシンプル ├── winston │ ├── common.js │ ├── config │ │ ├── cli-config.js │ │ ├─
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
