価値が出るポイントまで一気に進めてから次のタスクに取り組む - $shibayu36->blog;
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
優れたテストスイートの4本の柱を学ぶ - 「単体テストの考え方、使い方」を読んだ - $shibayu36->blog;
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある（Splitting a subfolder out into a new repository - GitHub Docs）。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
継続的に学習するために効いたやり方3つ - $shibayu36->blog;
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな？」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
PostgreSQLでSQLチューニングや障害状況調査に使ったクエリ達まとめ - $shibayu36->blog;
最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post
Macでdtrussを使ってシステムコールの実行時間を知る - $shibayu36->blog;
最近lsofを使ってportの利用状況をチェックしようとしたら、なぜか数秒固まるということが起こり、drussを使ってどこで止まっているか確かめたのでメモ。 dtrussというのは、簡単にいえばstraceのOSX版という感じ。どうやって使うかはOSXでもstraceしたい？よろしい、ならばdtrussだ - すがブロあたりをとりあえず見ると分かる。 ただ、単にdtrussを実行しただけだと、結局どこに時間がかかっていたのかよくわからなかった。manを見ていると、以下のようなオプションがあり、便利そうなので試してみた。 -e : それぞれのシステムコールの実行時間をmicrosecondsで出力する -d : コマンド開始からの実行時間をmicrosecondsで出力する とりあえず-eと-dオプション付きでlsofでどこに時間がかかっているか調べてみる。 $ sudo dtruss -e
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
