[scrum][book] Software in 30days を読んだ - HsbtDiary(2013-04-27)
■ [scrum][book] Software in 30days を読んだ あんちぽさんが原著を読んで他の本には無い話が多いと言っていたので読んでみた。確かに海の向こうで「よし、我が社もスクラムだ!」とやって撃沈した事例や、なんでスクラムのようなことをやるのかという話が多くて素朴な読み物として面白かった。 ただ、スクラムやるぞという時に読んでもぽかーんという感じになるので、その辺は他の本も読んだ方が良さそう。地味に、後半の付録にあるスクラム用語集とスクラムガイドが便利。 Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド Ken Schwaber KADOKAWA/アスキー・メディアワークス ￥2,817
エンジニアリングマネジメントについて - HsbtDiary(2018-12-01)
■ エンジニアリングマネジメントについて Pepabo Managers Advent Calendar 2018 1日目の記事です。 @hsbt が勤務先であるペパボで最近やっているマネジメントについて紹介します。昨年は執行役員CPO兼業務プロセス革新室室長として、主に社内の情報システムやワークフローのアップデートについて携わってきましたが、今年度は技術部長としてペパボの技術者組織を率いる=エンジニアリングマネジメントを担当しています。 エンジニアリングマネジメントと、ただのマネジメントではなくわざわざ「エンジニアリング」と頭につけているからには、それ特有の何かしらの特徴があると考えています。一つにはエンジニアは専門職であるということがあると思います。その専門職集団をマネジメントすることで成果を出すためにペパボでは以下のような事項を @hsbt は執行しています。 ペパボのエンジニアの評
人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について - HsbtDiary(2019-02-27)
■ 人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について 去年 @pyama86 さんが読みやすくて面白かったと話していたので買ってシュッと読んだ。 確かに面白くて、コンピテンシーという考え方はなるほどなって感じだった。いろんな立場の人が組織にはいるけど、より管掌や責任の範囲が広い人は狭い人ができることは当たり前とした上で、立場にあった評価の基準が重なっていくという話で、自分も含めて「わかるー」という感じだった。 後、この本では評価を決めるのは影響力というくだりがあって、これは特に専門職に分類される人には読んでもらいたいところなんだけど、エンジニアの場合だとシニアエンジニアは「技術力が高い」から評価されるのはなく「技術力が高いので結果として生み出されるアウトプットの影響力が高い」から評価されると置き換えるとわかりやすいと思う。 「アウトプット」と言われると OSS であ
Bundler-1.16.1 のリリースを手伝った - HsbtDiary(2017-12-22)
■ Bundler-1.16.1 のリリースを手伝った Bundler-1.16.0 がリリースされてから不具合はあるけど、どうなってんのこれ?というのが続いていて、いい加減なんとかしなければという気持ちになったので、すでに pr として出されているものや issue だけのもの、まったく何も動いてないものなどをガガガっと整頓してひたすらマージして stable ブランチで壊れたら直すというのを繰り返してやっとブランチのテストを安定させることができたので、@indirect に 1.16.1 をリリースしてもらった。 https://github.com/bundler/bundler/milestone/56 bundler だいぶわかって来たんだけど、ruby 本体と同じように master で直しまくってから安定版ブランチにバックポートするというリリースモデルなのに、そのバックポート
本当の夜をさがして を読んだ - HsbtDiary(2017-10-18)
■ 本当の夜をさがして を読んだ NHK ラジオで一番楽しみにしているミニビブリオバトルで紹介されていて、バトルの内容を聞くだけでこれは面白そうだ、と感じたのでシュッと買って bookscan 経由で読んだ。 http://www.nhk.or.jp/radio-blog/bangumi/nhkjournal/275316.html この本は光害というものを提唱して、科学的・統計的な視点から人体にとどまらず生物全体への健康被害について紹介したり、深夜に仕事に従事する人たちのインタビューや、人工による光の発明によって我々が何を失ったのかということを知ることができてよかった。明るければ防犯のためになる、というのも「雰囲気」でやっているだけで、実際には効果がない(むしろ明るくなることによって犯罪者にも有利になる面がある)というのはなるほどなあと感じた。 本書はスタートがもっとも明るい街といわれる
幹部合宿2日目, Ruby 2.5.0 の rubygems イマココ - HsbtDiary(2017-06-23)
■ 幹部合宿2日目 前日に続いて某所地下で議論を続けてました。夕方の手前くらいには終わったので、京浜東北線にのってシュッと帰宅。お疲れさまでした。 ■ Ruby 2.5.0 の rubygems イマココ @hsbt は Ruby 2.5 で Gemification 以外にも継続的に upstream が ruby/ruby 以外にあるやつのマージをやってるんで、rubygems 周りで今どうなってんの、というお知らせです。 まずは 5 月に 2.6.12 をマージしていた。 https://github.com/ruby/ruby/commit/708a10d35bf7d34da574ca3f2ae6be4bfffd5267#diff-d0025c89dbe0577be56358e4a356131b rubygems 2.6.12 のリリースノートは https://github.co
エラスティックリーダーシップを読んだ - HsbtDiary(2017-05-15)
■ エラスティックリーダーシップを読んだ 訳者の島田さんから頂きました。ありがとうございます。 昨年後半からマネジメントとリーダーシップというあたりも鍛えていかないとな、というところ考えていて マネージャが仕事の仕組みを作るというような文章を書いたりしているうちに、執行役員というますますマネジメント、リーダーシップの両方を発揮して組織を動かしていく必要が出て来たのでちょうどいい本だった。 著者はチームや組織の状態を サバイバルモード 学習モード 自己組織化モード の三つのフェーズそれぞれに対応したリーダーシップを使い分けて行くべきだと主張していてなるほどね、と感じた。確かに、サバイバルモードが続いていて疲弊だけする状態をどうにかして学習モードにしたり、学習がある程度できたら自己組織化を促してチームを成長させるというのはうまくいきそうな感じがする。 ただ最初の方では、マネジメントとリーダー(
zsh から fish にした - HsbtDiary(2017-04-21)
■ zsh から fish にした 春というのと MacBook Pro を置き換えたということもあって、この機会にシェルを zsh で引き継ぎ付け足しし続けていた環境から fish を 0 から設定して生きることにした。bash や zsh で読み込んでから fish で、という話もあったけどそれなら bash や zsh でいいじゃないかと思うので、無から fish で環境を作るというのを目的に進める。まずは homebrew で fish をインストール。 $ brew install fish そもそも fish をわかってないので、ゆるく調べてみると以下のような感じらしい。 エンドポイントとなる設定は ~/.foorc などではなく ~/.config/fish/config.fish にかく その他設定や function は ~/.config/fish/functions
Ruby 2.4.0 で導入予定の Integer Unification まとめ, 夏休みで北海道へ - HsbtDiary(2016-08-29)
■ Ruby 2.4.0 で導入予定の Integer Unification まとめ Ruby 2.4.0 で導入が予定されている Integer Unification が与えるであろう Ruby アプリケーションへの影響をまとめておく。 率直には rb_cFixnum や rb_cBignum が 2.4 からは見えなくなるので、それらを参照しているような native gem が対応していなければビルドできないためアプリケーションが動かなくなる。じゃあ、対応したバージョンに全てバージョンアップすればいいじゃん、という話なのだけど bundler が解決してくれる dependency 沼と絡み合って、単純には解決できずに 8 月現在は厳しい状態になっている。 json は Ruby が bundle している�バージョンですでに Integer Unification 対応がなされ
rbenv organization が爆誕 - HsbtDiary(2015-11-26)
■ rbenv organization が爆誕 今までオリジナルオーサーである sstephenson の下にあった rbenv, ruby-build が rbenv organization として独立した https://github.com/rbenv 実は rbenv, ruby-build は will_paginate の作者である mislav が精力的にメンテナンスを続けていて、 hsbt と sferik がサポートって感じで進んでおり、 sstephenson はプロジェクトには積極的には関わっていないという状態だったので、mislav が organization として独立させた、というのが経緯。 rbenv も ruby-build も issue を watch していると ruby の build が壊れているというのが見つかったりするというのもあるので、
[ruby] ruby 同梱の test-unit と minitest の今後 - HsbtDiary(2014-05-24)
■ [ruby] ruby 同梱の test-unit と minitest の今後 今朝のコミットで stdlib としての minitest が消えたので一度ゼロベースから考え直しという事になった。ふんわりしてるけど、議論している内容はこんなところ。 minitest5 は同梱しないで packaging やインストールプロセスのどっかで gem install minitest して入るようにしたい *.gem ファイルを同梱するのか、しないでパッケージ生成時に取得するのかは未定 test-unit は https://github.com/test-unit/test-unit を同梱したい(test-unit2 と呼んでいる) API に非互換があるのでどれくらい非互換があるかを調べる その場合は rubygems や rake 同様に trunk を upstream としたい
[github][travis][heroku] github の master に push したら travis を使って heroku にデプロイする術, Agile Samurai BaseCamp でインセプションデッキの使い.. - HsbtDiary(2013-12-08)
■ [github][travis][heroku] github の master に push したら travis を使って heroku にデプロイする術 www.ruby-lang.org は今は物理サーバーで動いているけど、密結合の原因となる物は完全に撤去して、もう heroku なりそれっぽい所で動くようになっているので、heroku 移行に先んじて travis 経由で master の HEAD を自動でデプロイするようにした。 https://travis-ci.org/ruby/www.ruby-lang.org https://github.com/ruby/www.ruby-lang.org/blob/master/.travis.yml rvm: 2.0.0 cache: bundler deploy: provider: heroku buildpack: h
master ブランチで pull request していいのは小学生までってこともない - HsbtDiary(2011-06-16)
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
[tDiary][github][ci] tDiary の CI 環境を Jenkins から travis-ci に移行した - HsbtDiary(2011-07-09)
■ [tDiary][github][ci] tDiary の CI 環境を Jenkins から travis-ci に移行した 今まで tDiary の CI はオレが Jenkins で用意した http://ci.hsbt.org を使っていたんだけど、github で ruby なソフトウェアなら http://travis-ci.org が一番 cool という噂を誰となく聞いたので移行してみた。 やったこと http://travis-ci.org に github アカウントでログインして token を取得 入手した token を github のプロジェクト設定 - Service hook にある travis の項目にコピペ、ユーザー名も入力しておく プロジェクトルートに .travis.yml を配置、ymlのオプションは https://github.com/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
