「Jestではじめるテスト入門」を書きましたー #Jest本 - Mitsuyuki.Shiiba
Jestではじめるテスト入門 本日「Jestではじめるテスト入門」がついに発売されました 🎉🎉🎉 peaks.cc CircleCI時代の同僚の伊藤さん @ganezasan が「Jestの自動テスト本の執筆を手伝ってくれませんか？」と声をかけてくれて「これからテストを書きたいって人に向けたJestの入門書を書きたいんですよ！！」って熱く語ってくれて「いいなぁ」と思ったので参加しました。本を書くなんて初めてのことなので、自分なんかに書けるかなぁとドキドキしてたのですが、周りの方々の助けのおかげで、なんとか書き上げることができました。 そして、監修はなんと和田さん @t_wada です。自分が自動テストについて書いた文章を、和田さんに監修していただけるなんて、それだけでとても幸せだなぁと思っていたのですが、「むちゃくちゃ面白かったです！」って言ってもらえたので、もう出版しなくても満足し
学習を日常の開発に取り込むこと - Mitsuyuki.Shiiba
去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
サイボウズさんのマネージャー話を読んで想像して遊んだ - Mitsuyuki.Shiiba
サイボウズさんの、この記事を読んだ blog.cybozu.io とても面白い。良いなと思う。ぼーっと想像して遊んでみる。全部想像だよ 職能横断チームへ 2019年の組織変更ではマネージャーをなくしたことに目がいくけど、職能ごとの組織から職能横断のプロダクトチームに変更したことがまず興味深い 職能横断のプロダクトチームだと良さそうなのは プロダクトのことを第一に考えることができる 職能間の壁をなくして全員で取り組むことができる 結果として、プロダクトをより良くするための開発サイクルが速く回るようになったんじゃないかな。それと、開発・テスト・リリース・運用など全てのフェーズからのフィードバックをチームが得られるので、そこからの改善も進んでそう。とても良さそう 職能別組織が持っていた良さ 一方で、以前の職能別組織の場合に良かったのは 自分の専門領域に集中して取り組むことができる 専門知識を持っ
開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba
例えば「会議が多い」という意見に、どう対応しよう？ 普通に考えたら「無駄な会議を減らそう！」かな だけど、できれば僕は「だからどうしたいと思ってるんですか？」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる （順当→）会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな
ペアプロが苦手でペアワーク - Mitsuyuki.Shiiba
ペアでやろうよー！ チーム内で知識を共有できるように、フルリモートでも一緒に仕事できるように、チームとしてプロジェクトに取り組めるように、「ペアでやろうよー！」ってなって「それいいねー」って思って、最近はペアで仕事をしてる そして、何年も前からうすうす感じてはいたんだけど、やっぱり、僕はペアプロが苦手だった！ので、ペアプロじゃなくてペアワークしてる ペアプロ？ペアワーク？ 「ペアプロ」は「ペアプログラミング」のこと。一緒にコードを書く。リモートワークなのでペアプロするときは、Zoom とかで画面をシェアしながらコーディングしてる 参照 → https://martinfowler.com/bliki/PairProgramming.html 一方「ペアワーク」って言葉は、正式な定義があるわけじゃなくて、自分がそう呼んでいるだけなんだけど「ひとつのタスクを二人で担当する」こと なんで苦手なん
トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
最近 Fitbit つけて散歩してるので CircleCI + Pixela で見えるようにしてみた - Mitsuyuki.Shiiba
歩数で草を生やしてみたのだー。これで散歩の楽しみが増えたなー やってること やってることはシンプルで、こう↓ Fitbit の API で歩数を取得 Pixela に記録 というスクリプトをつくって CircleCI で定期的に実行 Fitbit? 最近 Fitbit Sense というスマートウォッチをつけて散歩してる www.fitbit.com 会社の福利厚生で健康のための補助があるので、それを利用して手に入れたのだ。散歩やジョギングをしたら勝手に記録されてるので便利。睡眠のログも取られてるので面白い Pixela? Pixela は日々の活動を記録して見えるようにしてくれる API サービス。いちばん最初に貼った画像みたいに GitHub の草を生やすやつみたいにしてくれる。操作が全部 API 経由なのも楽しい pixe.la せっかく散歩してるから せっかく散歩してるから Fit
後輩が自走できるようにサポートするぞー - Mitsuyuki.Shiiba
この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。 note.com 信頼する まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。 対話 自分の期待を共有する 「自走できるようになってね？」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、
「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba
4/26 に発売されます！ 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー！」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
2時間スプリントでソロ、ペア、モブ、学習セッションを実験した - Mitsuyuki.Shiiba
忘れる前に走り書き的にメモ。 ## Day0 実験の場をゲット！ とあるチームのテックリードから「助けて欲しい」という相談があった。話を聞くと、プロジェクトが遅れている状況で、まだ大きく分けて3つの技術的課題が残ってて、でも、チームはその技術にあまり詳しくないので先が見えなくて不安。ということみたい。 チームの構成は、プロダクトオーナー、テックリード、エンジニア2人の4人チーム。開発手法にはスクラムを採用してる。スプリント期間は2週間。 「いいよー。水曜から金曜の3日間だけなら手伝えるし、それで不安は解決できると思う。スプリントはその間は止めようかな」と言いながら、折角だから実験させてもらおうかなと思い、条件を出した。「この3日間は全員がこの課題解決を最優先すること」それから「僕の好きにやらせてもらうねー」。 実験してみたかったのは、別々に作業するのと一緒に作業するのとではどっちがどうなん
おなかいっぱいすぎる・・・DockerCon SF 18に行ってきた - Mitsuyuki.Shiiba
ということでDockerCon本編のログ。 前日までのお話はここ。 bufferings.hatenablog.com 最初に感想 あくまでも僕の感想だけど、こんな風に感じた： Dockerを取り巻くエコシステムの活気がすごい でも、その中心はDockerからKubernetesに移ってるように感じた そんな中で、Microsoftが存在感を出していて強いなぁって思った そして、また2,3年でKubernetesの次がやってるくるんだろうなって想像した Dockerを取り巻くエコシステムの活気がすごい 前回の記事でも触れたけど、Dockerを取り巻くエコシステムとして、モニタリング、プラットフォーム、セキュリティ、MLそれとIoTなどに取り組んでいる会社がほんとに沢山あって活気がすごい。 でも、その中心はDockerからKubernetesに移ってるように感じた 何年か前まではDocker
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
Zaleniumさんに動的にコンテナを立ち上げたり捨てたりしてもらいながらSelenium(というかGebだけど)のテストを実行してその録画を見る - Mitsuyuki.Shiiba
English version of this article is here: dev.to Zaleniumってことばを見かけたので触ってみた。 Zalenium? https://zalando.github.io/zalenium/ ちょこっと触ってみた感じ良さげ 1) ローカルマシンですごく簡単に試すことができる 2) Seleniumのテストを実行するのに合わせて動的にコンテナが起動する 3) テストが録画される 1) ローカルマシンですごく簡単に試すことができる Zaleinumを起動 # イメージを2つpullしてきて docker pull elgalu/selenium docker pull dosel/zalenium # 実行! docker run --rm -ti --name zalenium -p 4444:4444 \ -v /var/run/docke
Prometheusを触ってみる。のをDockerでやってみる。のとgrafana。 - Mitsuyuki.Shiiba
昨日の朝、ぼーっとしてたらこんな記事があったので qiita.com Prometheusっていうモニタリングツールがあるのかぁと思って。 prometheus.io 触ってみようかなと思ったのでした。 まずは動かす Dockerで動くとあんまり何も考えなくていいなぁって思ってたら、ちゃんとあった( Installing | Prometheus )。(∩´∀｀)∩ﾜｰｲ docker run -p 9090:9090 prom/prometheus で、9090にアクセスしたらとりあえず動いてる。 自分自身を監視してみる さっきのは起動しただけで何も情報がないので、実際に監視してみるとどんな感じになるのか。サンプルとして自分自身を監視できるみたいなのでやってみよう。 Getting started を読みながらprometheus.ymlってファイルを作って global: scrape
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
