Re: チームのベロシティを上げる vs. 安定させる - $shibayu36->blog;
yigarashi.hatenablog.com これが良い話だなと思ったので感想メモ。 「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象 「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち 何となく、悲観
Emacsで現在開いているファイルを一瞬でVSCodeで開く方法、そしてその逆 - $shibayu36->blog;
Reactを最近勉強し始めたのでVSCodeも使ってみるかと思っている。そうはいってもEmacsを使いたいときもあるので、 Emacsで現在開いているファイルをVSCodeで開く(カーソル位置も保持) VSCodeで今開いているファイルをEmacsで開く(カーソル位置も保持) の両方をやりたい。ということでやってみた。 Emacsで現在開いているファイルをVSCodeで開く 実装はこれ -> https://github.com/shibayu36/emacs/commit/9699a693d45b8d3b355b15b57c6e6b3f827d6483 単純にcodeコマンドを使って現在のファイル名、行数、カラム数を渡してあげると良い。 ;;; 現在のファイルをvscodeで開く (defun open-by-vscode () (interactive) (shell-command
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
dockerの公式のGet Startedのドキュメントが今のコンテナ技術の概念をいろいろ学べてお得 - $shibayu36->blog;
https://docs.docker.com/get-started/をやってみたのだけど、今のコンテナ技術の概念をいろいろ学べてお得だった。 Orientation and setup | Docker Documentation で、コンテナとVMの違いって何？というのが分かる Redirecting…でpythonのwebアプリを動かしながら、Dockerfileやコンテナやイメージの概念を学べる Redirecting…で、docker-compose.ymlとdocker swarmを用いて、コンテナをデプロイするのをやる これでコンテナをスケールさせてデプロイするイメージが分かる Redirecting…で、複数のノードに分散してコンテナをデプロイするのをやる これでコンテナとクラスタ管理のイメージが分かる k8sとかECSとかがやっていることが分かるイメージ Redirec
問題解決のための質問群を学んだ - 「考える技術・書く技術」を読んだ - $shibayu36->blog;
最近、自分は問題をうまく分割して解決する能力や、他の人に分かりやすく伝える能力がまだ足りていないと感じていた。そのあたりを強化するために、おすすめと言われた「考える技術・書く技術」を読んだ。 考える技術・書く技術―問題解決力を伸ばすピラミッド原則 作者:バーバラ ミントダイヤモンド社Amazon この本は、わかりやすい文章を作るために、ピラミッド構造で論理構造を作るという技術を教えてくれる本だ。この本を読み終わって、ピラミッド構造を作るという考え方は、問題を分割するということにも、文章を他の人に伝わるように分かりやすく書くということにも応用できる、非常に有用な考え方であると感じた。 まず最初にぱらぱら読んでいた感想は、非常に良いことが書かれてそうなのだけど、なぜか頭に入ってこないということだった。このためあまり面白くないなと思いながら、気になるところを付箋はったりメモしたりしながら読んでい
学校の教師ってミドルマネジメント学んだほうが良いのではないか - $shibayu36->blog;
教師って全員ミドルマネジメント学んだほうが良いのではないかっていう発想がなぜか出てきた— 柴崎優季 (@shiba_yu36) 2014年12月23日 なんかボーっとしてて思いついたので雑に書いてみる。 これまで学校で勉強してて 学校で学ぶことは知識量としては非常に少ない 結局は生きている間はずっと学び続ける必要がある そうすると学校では、学ぶ楽しさなどを感じさせて、主体的に学ぶ姿勢や学び方を学習させないといけない ということをずっと思っていた。結局小学中学高校で習うことなんて知識量としてはたかが知れている。そうすると教師は生徒に対して、知識量を増やすのではなく「学び方」を教えなければならないのではないか、と思っていた。 最近マネジメントの勉強をしていて、「学び方」を教えるのに非常に役に立つことが多いなと感じる。 まず学ぶことが楽しいと思うためには、何が必要か。まず最低限必要なのはマネジメ
「強いチームはオフィスを捨てる」を読んだ - $shibayu36->blog;
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン早川書房Amazon 最近リモートワークへの知識に興味が湧いてきたので、ひとまず強いチームはオフィスを捨てるを読んだ。元々はリモートワークについての思い込みがあり、そのためリモートワークの難しさのほうに目が行き過ぎていたのだけれど、この本を読んでみて少し中立よりになれたように思う。そういう面で今の時期に読むには非常に良かった。リモートワークの知識だけというより、普通に働いていても参考になる知識も得られた。 リモートワークを始めたいけど何から始めたらいいかについて分からない人には最適な本。ただし良い本であるという一方で、少しリモートワーク礼賛の傾向があるので、そこは一歩引いて読むと良いのかなと思う。とはいえ、ただ褒めているというだけでなくて、きちんとメリット
実践に繋げるように勉強する - $shibayu36->blog;
遅延評価勉強法だと得られなかったもの - As a Futurist... 漢(オトコ)のコンピュータ道: ヒゲモジャのギークが提案する技術習得戦略 を読んで、なんとなく気分が高まったので、自分の学習のことについて書いてみる。 以下の様なことを書いているつもり。 勉強は実践につなげると知識が定着すると思っている 実践課題を探すのではなくて、実践の目処のあるものを勉強する 一番簡単な実践課題として、自分の言葉でまとめ直すということをしている 実践に繋げる 僕は勉強する時は、いろいろ本を読んだり、情報を調べたりして、まず知識をつけようとすることが多い。ただし、それだけだとだめで、実践しないと知識が定着せず、どんどん忘れていき、結局意味ないということになる。実践大事。 大事なのはわかってるんだけど、実践するのは意外と難しい。本に練習問題あったりすることもあるけどあんまり面白くないし、良い実践課題
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
DevLove関西で「課題をテストで解決する」という発表をしました - $shibayu36->blog;
DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根本原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b
レガシーコード改善ガイドを読んだ - $shibayu36->blog;
レガシーコード改善ガイド (Object Oriented SELECTION) 作者:マイケル・C・フェザーズ翔泳社Amazon レガシーコード改善ガイドを読んだ。 この本では、レガシーコードの内部をリファクタリングする際に何を気にする必要があるかとか、非常に長いモンスターメソッドをリファクタリングしていく時にまずどこからやるかとか、そういうことが書いてある。とにかくレガシーコードに直面して何から始めたらいいかわからないという時にはおすすめ。 リファクタリングという本と近い内容だけど、僕の中ではこの本よりはリファクタリングの方がなんとなく肌にあった。また今度再読してみようと思う。 印象に残ったところを書いていく。 依存関係を排除する 「たいていの場合、テストの最大の障害となるのが依存関係です」と書いてあるのだけれど、これは確かにと思った。いつもは無意識にやっているけど、言語化されてよかっ
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
ペアプログラミングをしていたら、開発環境が良くなった話 - $shibayu36->blog;
最近、仕事で一週間に一度はペアプロをするということをしているのですが、これによって思ってもみなかった効果が出たので紹介します。 ペアプロというとプログラムを書いている人の後ろでもう一人が見ていて、逐次指摘などしながらプログラミングすることによって、生産性の向上やバグ発生率を抑えるみたいなことが言われています。僕自身もそう思いながらペアプロに望んでいたのですが、違うところで効果が出始めました。それは自身の開発環境がだんだん良くなっているということです。 ペアプロによって開発環境が良くなる 今回開発環境といっているのは、emacsなどのエディタや、ターミナルなど、ローカルマシンの設定などのことです。 なぜ開発環境がよくなっていっているというと、見ている時と見られている時のそれぞれにおいて、次のようなことが起こるからです。 見ている時 後ろから見ていると突然プログラムを書いている人が、自分の知ら
http://shibayu36.hatenablog.com/entry/2012/12/29/001418#mc?u=ainame
ふとemacsの設定どのくらいになっているのかなーと思って行数数えたら wc -l init.el inits/* | grep total 2303 totalと、とんでもないことになっていたので、これまでどんな設定してたか思い出すことも兼ねて、emacs設定大掃除をおこなってみました。そこで「これは捨てられないなー」と思った設定を淡々と書いていきます。 ちなみに実際の設定ファイルはhttps://github.com/shibayu36/emacs/tree/master/emacs.d を御覧ください。 init-loader.el emacsでinit-loaderを導入してみた - $shibayu36->blog; の記事でも書きましたが、init-loaderは便利です。最近の構成としてはinit.elにはinit-loaderの設定だけ書いて、inits以下に全部設定置いて
anything-git-project.elを少し手直ししてみた - $shibayu36->blog;
id:yaottiさんが作っているanything-git-project.el(プロジェクト内のファイルを絞り込んで操作するanything-git-project.el - yaotti's diary)ですが、gitでproject管理している人にとってはすごく便利です。 ただ、一つだけ不満がありました。 現在のディレクトリからの相対パスが出てしまう ../../とかあんまり見たくない そこでちょっとだけ手直ししてみました。 chomp elisp触ってるとchompが欲しいけど無い、みたいな状況に出会います。そこで以下の関数をユーティリティとして定義しておくと良いと思います。今回の手直しではこれを使ってるので、適当にどこかで定義しておいてください。 (defun chomp (str) (replace-regexp-in-string "[\n\r]+$" "" str)) 変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
