RubyGems 3.0.0 をリリースした - HsbtDiary(2018-12-19)
■ RubyGems 3.0.0 をリリースした RubyGems の5年ぶりのメジャーバージョンアップである 3.0.0 をリリースした。RubyGems や Rake のリリースは何度やっても魂を消費する。 https://rubygems.org/gems/rubygems-update/versions 自分が触ることが多くなってからいい加減 Ruby 1.8/1.9 を考えたコードを書くのはしんどくなったので、基本的に理不尽な非互換は起こらないようにリリースマネジメントを注意しつつ、Ruby 2.3 未満のサポートを切ったものを 3.0.0 としてリリースした。 https://github.com/rubygems/rubygems/graphs/contributors?from=2017-12-25&to=2018-12-18&type=c 上記の通り、ここ一年の開発アクテ
エンジニアリング組織論への招待を読んだ - HsbtDiary(2018-03-28)
■ エンジニアリング組織論への招待を読んだ 最近話題になっているので二日くらいでシュシュっと読んだ。 エンジニアリングの本質を「不確実性の削減」と位置付けて、それをテーマにエンジニアが常々大事だと感じているプロダクト開発やコミュニケーションの中の様々なプラクティスや考え方について、何故これらのエンジニアリングが重要なのか、ということを幅広く取り扱っている大変良い本だった。 不確実性コーンであるとか、経験主義やスクラムであるとか、技術的負債などプロダクト開発が特に難しいとされている昨今だと前提知識となっているようなトピックをよくこれだけ全部詰め込むことができたなあと感心するくらいちゃんとストーリー立てているのがすごかった。 個人的に良かったトピックは 認知フレームとリフレーミング 内心は見ることができないが、行動は見ることができる OKR による目標の透明化 というあたりかなあ。最近の仕事の
YAPC::Okinawa 2018 ONNASON に参加した - HsbtDiary(2018-03-03)
■ YAPC::Okinawa 2018 ONNASON に参加した 今回は発表も何もなく、スポンサー特典でランチセッションで少しだけ喋るということをして、それ以外は単純に参加するだけしてきた。 この日はあいにくの大雨で朝から傘をさしたり、させなかったりしながら集合場所に集まって固まりながらバスで OIST まで移動。乗ったバスはメルカリさんによるスポンサーで、kazeburo さんによる会社紹介やムービーを見た後に、引き続きベヨネッタをプレイしてた。 メインホールのの風景はこんな感じ。どの席にもテーブルと、電源がありつつ、インターネットも十分な速度が出る状態でコード書くのに大変捗る感じで良かった。 ノベルティの一覧の風景、DeNA のノベルティが Qi の充電器でびっくりした。とても実用的だしすごいなあ。フリークアウトのコーヒーも美味しくいただきます。 発表はずっとメインホールに居座って
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 で直しまくってから安定版ブランチにバックポートするというリリースモデルなのに、そのバックポート
rubygems master のテストコードを ruby 本体にマージしても動くようにした, Atom から VS Code に乗り換えてみた, レトロスペース坂会館に行ってきた - HsbtDiary(2017-08-16)
■ rubygems master のテストコードを ruby 本体にマージしても動くようにした rubygems/rubygems のコードは基本的にディレクトリ構成だけ少し変えて ruby 本体にコピーすればインストール前のビルド直後の ruby バイナリでもテストが全て動くということになっているんだけど、ちょっと油断すると ruby 本体では動かないコードが rubygems master に入ったりするので夏休みの時間を使って全部直した。 (なんでこういうコミュニケーションロスっぽいことが起きるのかは builderscon tokyo 2017 で話しました) 直したテストケースは以下の二つ。 https://github.com/rubygems/rubygems/pull/1986 https://github.com/rubygems/rubygems/pull/1987
WANTEDLY TECH BOOK を読んだ - HsbtDiary(2016-08-25)
■ WANTEDLY TECH BOOK を読んだ 達人出版会で WANTEDLY TECH BOOK という目次をパラパラ眺めたら面白そうな本があったのでサクッと読んでみた。 http://tatsu-zine.com/books/wantedly-tech-book 内容自体は章ごとに粒度がバラバラでうーんという箇所があって、本全体としての完成度はもう少し頑張りましょうというものの、wantedly という会社はこういうポリシーでこう開発してるんすよ、というのがサッとわかるという意味で良書だった。似たような部類としては thoughtbot の playbook などがあって、ようは開発標準というものだと思う。 ペパボでもこういうものをそろそろ用意して、ロギングは td-agent + TD, サービス基盤は OpenStack, CDN は～みたいのを一通りまとめて、読んでおけば全社
docker を使う開発環境をそろえた - HsbtDiary(2016-04-08)
■ docker を使う開発環境をそろえた 今まで単なるバイナリビルド環境としてしか使ってなかった docker を CI でまともに使い始めたのでいろいろ用意した。 docker の実行環境 Docker Toolbox で作る。ローカルマシンは Virtualbox の boot2docker イメージを default として使っている。Azure で動かしている個人用 VM にも docker engine を入れて、秘密鍵を作成してから tlsverify モードで起動するようにした後に docker-machine の none driver で登録して docker-machine env azure とかしてリモートでも実行できるようにするなどして分散している。 none driver で作成した場合 .docker/machine/machines/azure/confi
自動化するときに考えること, 森美術館の年間パスポートを買った, 鮨一新で寿司懐石コースを食べてきた - HsbtDiary(2015-05-03)
■ 自動化するときに考えること 所属が技術基盤チームということもあって、あらゆること(コードはもちろん、組織の仕組み、作業プロセス、QAなど色々)を改善するというのを毎日考えている。 改善と聞くとすぐに自動化を思い浮かべてしまうけど、自分はなんでも自動化することは良しとしてないので、まず最初に考えることを紹介する。どこかに出典があったような気もするのでここに書いてあることがオリジナルではないと思う。 まず、仕事を大事なこと/些細なことと1年(月)に1回起きること/毎日起きることの2軸にわける。そして、組み合わせの4つについてどうすればいいかを考える。自分の中の基準は以下のとおり。 1年に1回起きて大事なことは、手順書やチェックリストを作成する 1年に1回起きて些細なことは、無視しないで気がつけるようにする 毎日起きて大事なことは、自動化する 毎日起きて些細なことは、発生しないようにする よ
雑に出来ないって言わない, Asakusa.rb 第302回 - HsbtDiary(2015-04-04)
■ 雑に出来ないって言わない マーケット、ビジネスサイドからの issue に対して「これは無理です」「出来ません」というエンジニアを散見する。エンジニアと名乗る人にとって出来ないことはなくて、省略された部分を補うと「(指定された期日までに現在のリソースでは)出来ません」となるはずなのに、括弧の部分を省略している人が多い。 ようは、issue がはっきりしていて後は達成するだけというフェーズにおいては、 知識レベルや技術力が低いので学習しながら進めていると、期待している期日までに達成することが困難 技術力は備えているものの金か人が不足しているのでリソースを調達しながら進めていると、期待している期日までに達成することが困難 の2つしかないわけだ。上記のような状況において「出来ません」な場合に出来ることは、issue を削る、リソースを新たに投入する、期日を延ばすというQCDのどれを諦めるかと
[ruby] 最近の rubocop の使い方 - HsbtDiary(2014-08-11)
■ [ruby] 最近の rubocop の使い方 rubocop はとても便利だけど eval とか別に知ってて使ってるし、if foo = bar やめろとかまで言われると知ったことかとなってしまうので ~/.rubocop.yaml に下のような内容を書いて動かしている. Lint/Eval: Enabled: false Lint/AssignmentInCondition: Enabled: false あと、「今すぐ直せオラオラ」みたいなやつは Lint/UselessAssignment くらいなので最近は $ rubocop --only Lint/UselessAssignment だけで十分な感じになっている。これでもかなりゴミコードを検出できるので rubocop 素晴らしい。
[oedo04][asakusarb] 大江戸 Ruby 会議 04 を開いてきた & 発表してきた - HsbtDiary(2014-04-19)
■ [oedo04][asakusarb] 大江戸 Ruby 会議 04 を開いてきた & 発表してきた 大江戸 Ruby 会議 04 を江戸東京博物館で開催してきた。 大江戸 Ruby 会議は asakusarb プレゼンツということで出来るだけ省力で開催するようにしていて、松田メンバーが招待講演者との調整、角谷メンバーが会場係、たっかんメンバーが懇親会の手配、自分が会計係、会場準備に集まれるメンバーとコンテンツ係のメンバーという布陣で github の issue も10個あったかな?というくらいのよくわからない運営で回ってしまった。自己組織化～。 名札は今回も @maztomo さんの作成。これ手書きというのを知ってまじで!とびっくりしてしまった。こういうデザイン好きです。 自分も朝一で発表してきた。流れは去年の RedDotRubyConf で発表した内容を最新の状況に revis
[gem][ruby] 便利ライブラリやライブラリの使い方の探し方, 攻殻機動隊 ARISE を見た - HsbtDiary(2013-07-08)
■ [gem][ruby] 便利ライブラリやライブラリの使い方の探し方 新卒氏にどうやって、メソッドがライブラリのどの辺にあるのかとか、ライブラリ内のファイルの場所を調べているんですかと聞かれたので、なんでかなと考えてみたら pinboard で rails や ruby のタグが付いているエントリをだいたいチェック agig を使ってテッキーな人が star を付けるリポジトリをだいたいチェック gem-src を使って、自分が使っている gem は全てローカルに持って来て、何かあれば ag や find ですぐ調べる bundle update して何か変更点あったら、全部 git diff で見ている 何か調べようとおもったら、google や github 経由の公式ドキュメントや http://rubygems.org/gems/foo を見る というのをひたすら毎日やってるから
[work] ペパボ新卒エンジニアの研修を開始している - HsbtDiary(2013-05-22)
■ [work] ペパボ新卒エンジニアの研修を開始している 先月から先週まで福岡で CS 研修をしていた新卒エンジニアが東京に戻ってきたので今週から bootcamp を開始している。基本的に gist に以前貼った物(何故か二つとも gist のエラーで見えなくなってしまった...)をベースにあそこからさらに組み替えたものを実施している。 以下基本的な時間割。 10:00 : @hiboma によるブリーフィング(朝会ってやつ) 10:15 : RailsTutorial Rails4 edition をやる 11:15 : 初めての Ruby を @hiboma とシステムの裏の小話を含めて読む 11:45 : RailsTutorial の続きと @hsbt や @kentaro による補講、TDDとかRESTとかモデリングとかを老害トークっぽく 13:00 : 昼休み 14:00
[scrum][book] Software in 30days を読んだ - HsbtDiary(2013-04-27)
■ [scrum][book] Software in 30days を読んだ あんちぽさんが原著を読んで他の本には無い話が多いと言っていたので読んでみた。確かに海の向こうで「よし、我が社もスクラムだ!」とやって撃沈した事例や、なんでスクラムのようなことをやるのかという話が多くて素朴な読み物として面白かった。 ただ、スクラムやるぞという時に読んでもぽかーんという感じになるので、その辺は他の本も読んだ方が良さそう。地味に、後半の付録にあるスクラム用語集とスクラムガイドが便利。 Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド Ken Schwaber KADOKAWA/アスキー・メディアワークス ￥2,817
[work] paperboy で着席してやっている仕事 - HsbtDiary(2012-05-11)
■ [work] paperboy で着席してやっている仕事 最近何やってるんですかと良く聞かれるので募集要項の職務内容をベースにやってる事を書いておきます。 新しい方法論や技術の導入 Scrum の大枠とか XP の個別のプラクティスをかいつまんで紹介したり、これらを部分的に導入して開発速度を上げるという活動をやろうとしています。個人的にはサービスの立ち上げ、リニューアル、大きい機能の追加の時にはインセプションデッキを作るというのをやろうと思っています。 後は Redis だとか MongoDB のようなものに続く技術の検証や導入を切り込み隊長としてやるのも今の仕事です。他にも Ruby で何かおかしなことや開発メンバーが躓いたポイントを取り除くのも積極的にやったりしています。 開発手法の整備 とりあえず、Github にして他のプロジェクトのコードにもちょっかいかけるくらいを目指してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[kindle][book] 「空気」の研究を読んだ - HsbtDiary(2013-11-04)
[work] 震災発生を想定しての自宅勤務の日だった - HsbtDiary(2013-04-18)