Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
RuboCop リネーム騒動の所感 - @kyanny's blog
Is it time to change the name? · Issue #8091 · rubocop-hq/rubocop · GitHub Rubyists, we must do better | timriley-info The RuboCop Name Drama Redux | Meta Redux 件の騒動を知る前に「Black Lives Matter の流れに乗って名前変えたらいいんじゃねーの」とは思った 難癖をつけられて揉める前に済ませておくほうが楽そう、とか FactoryBot のことを当然思い出しながら 個人的に RuboCop は好きではなく愛着もないので、というのもある リネームしたら？という提案自体は、まぁ妥当な範囲内だと思う master ブランチやめます話もあることだし https://twitter.com/mislav/status/1270
連鎖退職 - @kyanny's blog
要約 感想 メモ ハイライト 優秀な人材の退職が組織に与える影響 マネジメント体制 ファーストランナーの退職が逆に良かったケース 信頼される管理職 連鎖退職の火消しをして燃え尽きた管理職 要約 これは「従業員が立て続けに辞める事象 = 連鎖退職」について分析した本である 連鎖退職には二種類ある ドミノ倒し型 蟻の一穴型 「ドミノ倒し型」は、退職による業務負荷の増大が原因 「蟻の一穴型」は、影響力がある人の退職で職場の問題が顕在化することが原因 「ドミノ倒し型」は人的余裕の少ない中小企業に多く、「蟻の一穴型」は大企業に多い（管理職や経営者が職場の問題を放置していたことが原因のため） 予防策 採用 採用前にネガティブな面も含めて詳細に情報提供する 採用基準を変更して合う人をとる 人事評価 報酬の分配方針（成果主義） 評価結果に対するフィードバック キャリア形成支援（メンター制度） 定期的な配置
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
最近思ったこと - @kyanny's blog
LINE上場でニュースメディアがライブドアの話を書いたり、元LDという肩書きのいろんな人たちがSNSに何か書いたりするとき、たいてい「ライブドアには優秀な人材がたくさんいて今も様々な業界・分野でOB・OGが活躍していて云々」と、自分が勤めていたころにはすでに会社を去っていた古株の人たちや、すでに偉くて平社員からはやや近寄りがたい存在だった人たちなどがポジティブに言及しているのをみるにつけ、自分は優秀ではないその他大勢の一人に過ぎなかったということ、それ以前に彼らは自分のことなど覚えてもいないだろうということを考えてしまい、鬱々とした気持ちになる。ピークを過ぎたベンチャーに入社するっていうのはそういうことなんだろう。そして静かに怒りがわいてくる。おれのことなど道端の石ころほどにも気にかけなかったやつらを、やり方はわからんがとにかく見返してやるぞという怒りこそおれがここまできた原動力だったのだ
Quipper に入社して丸3年が経った - @kyanny's blog
Quipper に入社して丸3年が経った。そんなことすっかり忘れていた。3年と言われてもピンとこない。体感的にはものすごく昔のことのように感じられる。それだけいろいろあって濃い日々を過ごせたということだと思っておこう。 せっかくなので、 Quipper 日本オフィスの変遷になぞらえながら振り返ってみる。 入社前夜 前職で担当していたサービスの事業展開がうまくいかず、英語を使う環境で仕事をしてみたいという希望もあり、海外スタートアップ企業への転職を考えはじめたのが2013年の3月だった。 3月上旬にWantedly で見つけた Engine Yard のソフトウェア開発者募集に応募して選考に進んだものの、合否がなかなか出ず、やきもきしていた頃に前職の同僚で同じサービスをペアで開発していた @banyan に「Quipper に転職するんだけど話聞いてみない？」と誘われたのが4月の半ば（たしか
第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
Qiita::Team やめた - @kyanny's blog
Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
次の5年のロールモデルが見つからない - @kyanny's blog
自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面
Speaker としての #rubykaigi 2014 を終えて - @kyanny's blog
RubyKaigi 2014 二日目 9/19 11:30 から Hall A にて <%= link_to "bundle", "update" %> - Make "bundle update" more fun to review という発表をさせていただきました。お聞きいただいた皆さん、ありがとうございました。 https://speakerdeck.com/kyanny/percent-equals-link-to-bundle-update-percent-make-bundle-update-more-fun-to-review Compare Linker というツールの紹介と、なぜそれを作ったのか、そして開発を通じて得た学び、などについて発表しました。 Compare Linker については You can review "bundle update" efficien
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
Atom.io に乗り換えられなかった - @kyanny's blog
きっかけは些細なことだった。 Emacs で RSpec のテストケースを書いていて、全体的に動作がのろくてイライラさせられた。どうやら ruby-mode だか ruby-electric だかが悪さをしているらしいが、何年も前に .emacs.d に放り込んだもので、どんな風に設定するのかも覚えていない。最新バージョンに入れ替えてみたら、手元でちょろっとカスタマイズしていた改行時のオートインデントだか何かの挙動が変わってしまい、気になってコーディングどころではなくなった。 もともと Emacs Lisp は読むのも書くのも苦手で嫌々ながらも騙し騙し付き合ってきたが、このときばかりは心底うんざりして、もうこんな古代のツールに頼るのはやめにしよう、自分の仕事は高度に知的な作業であるはずのプログラミングであって多彩で変態的なキーボード操作を駆使してテキストを編集しまくることではない、ならばも
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
おれがはてなブログPro初日に1年コースを契約した理由 - @kyanny's blog
http://b.hatena.ne.jp/entry/staff.hatenablog.com/entry/2012/02/13/172342 はてなブログProに対して「高い」とか「競合に比べて機能が少なすぎる」とか「腕に覚えがあるエンジニアならさくらのVPSで全部自力で作れてしまう」とか、肯定的ではないコメントが散見されるので、初日にProにした俺ががなぜ1年分8200円を払う気になったのか書いてみる。 高い？ 本当に？他が不当に安すぎるのでは？これは正直いって職業柄ふつうの人に比べて金銭感覚が狂ってる自覚はある。けどあえて書くと、ウェブサービスの価格は安すぎる。BtoCなウェブサービス運営の仕事に就いたことがある人ならば同意してもらえると思う。フリーミアムとか無理だから。はてなブログはリリース当初から記事下にアドセンスをでかでかと貼っていて評判が悪かったけど、広告モデルは規模が全て
Farewell, #shibuyarblunch - @kyanny's blog
#shibuyarblunch のサイトをアーカイブ化しました。Lokka (CMS) で運営されていましたが、現在は静的サイトとして配信しており、今後は更新されない予定です。 2020/11/10 更新: heroku の bamboo stack (!) を使っていて動かなくなっていた && ドメインも変わってリンク切れになっていたのでアプリを作り直しました。 大江戸Ruby会議01 で僕と @1syo さんが意気投合し始まった #shibuyarblunch でしたが、発起人の二人が渋谷を離れてしまったことや、途中から運営を取り仕切ってくださった @tyabe さんの主催する渋谷.rbが「渋谷近郊のRubyistのための地域Rubyistコミュニティ」という役割を担うようになった等の事情により、定期的な活動が途絶えていました。 大量のスパムコメントが投稿されているなど好ましい状態では
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
GitHub's Markdown Rendering API compatible API - @kyanny's blog
Today I launched GitHub's Markdown Rendering API compatible API. http://gfm-kyanny.sqale.jp/ (Hosted by Sqale : ) This is a markdown rendering API service compatible with GitHub's Markdown Rendering API. Pros No Rate Limit (almost) compatible with GitHub's Markdown Rendering API API endpoint path is same Input data format is compatible Cons Does not support GitHub integration mode parameter will b
Rails と時刻 - @kyanny's blog
時刻の扱いは難しい。タイムゾーンを跨ぐと格別に難しい。 Rails を使っていても難しさに変わりはない。むしろ時刻のやっかいな部分を隠蔽してくれるが故に余計にややこしくなることもある。 config.time_zone と config.active_record.default_timezone Rails アプリケーションで時刻を司る代表的な設定値は config.time_zone と config.active_record.default_timezone だ。いずれも config/application.rb で設定できる。詳細は Ruby on Rails Guides: Configuring Rails Applications 参照。 config.time_zone でアプリケーションのタイムゾーンを設定する。デフォルトでは UTC になる。日本向けのウェブサイトで
Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
