1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
全自動水玉コラ生成マシーン - onk.ninja
全自動水玉コラ生成マシーン 聖夜なので表題のものを作った。 https://github.com/onk/auto_circle_collage processing で書いたアプリだけど、この記事の内容はほぼ OpenCV の話です。 仕組み 水着を自動認識して「隠す」とマーク 顔を自動認識して「見せる」とマーク マークに沿って円充填 水着領域の自動認識 最初のアプローチ OpenCV を使って肌色認識 選択領域を膨張 -> 収縮させる 肌色との差分を取れば水着領域が完成 肌色認識 先人が大量に居た。RGB 色空間ではなく HSV 色空間を使うというのがコツなようだ。 HSV色空間 - Wikipedia HSV 色空間なら影になっている部分も抽出できる。 今回は Hue: 7..15 を肌色として定義した。 PImage detectHada() { // 作業用に hue で gra
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
2019-04-01 に「チーフエンジニア」という肩書きを手に入れてしまった。 はてなのエンジニア組織にはチーフエンジニアという役割のエンジニアがいて、評価や採用、その他大小諸々の施策を通じて、技術部門全体の生産性と幸福度を向上させるのがその仕事です。 はてなのエンジニアのバリューズ - Hatena Developer Blog 前職でも新卒採用、中途採用のお手伝いはしていたのだけれど、今は主業務の一つとして担当しているので、僕がどこを見ているのか、というのを書きとめておこう。 履歴書 チラ見しています。 「通勤片道1時間ぐらいかかりそうだけど大丈夫かなぁ？」とか「趣味がルービックキューブじゃん！ はてなの speedcubing 部と戦わせたろ」とかを見ています。 職務経歴書 まぁまぁ見ています。 プロジェクトで使った技術、特にアーキテクチャについてを一番見ていると思います。次にプロジ
git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
なんか京都に移住することになった 明けましておめでとうございます。 突然ですが、京都に住むことになりました。 理由は家庭の事情です。我々はもう親から車の免許を取り上げるとか、同居とか介護とか、 そういうことを考えなければいけない年齢なんですよ……。 さて、気になる職についてですが、FA 宣言させていただく形になりました。 まだ在職中で最終出社日も決まっていない異例の記事ですが、 引っ越し日程から逆算して次の就職先(＝通勤経路)を決める必要があるのです。 今後に関して まだ何も決まっていませんが、2 月中旬には決めちゃう感じのスピード感です。 京都にオフィスのある会社 フルリモートの実績がある会社 のいずれかで働きたいと思っています。 他の要素としては 開発言語には特にこだわりはありません。Ruby だと今の知識が全て活かせるのでマッチしやすそうです サーバサイド/クライアントサイドにもあま
はてなで働くエンジニアにアンケートシリーズ第2回 onk - Hatena Developer Blog
こんにちは、id:hitode909です。今回は、id:onkに話を聞いてみます。 onkさんとはここ半年ほど隣の席に座っていて、マンガチームでの課題を足がかりに、CTO室の時間を使って全社的な問題を解決しようと日々活動しています。 id:onkにアンケート はてなidとその由来を教えてください いつどんなきっかけで入社されましたか? 現在の仕事を教えてください チーム内の立ち位置を教えてください 今日一日の流れを教えてください 最近うまくいったことは何ですか? 最近うまくいってないことは何ですか? ふだん大切にしていることは何ですか? はてなはどんな会社ですか? おわりに id:onkにアンケート はてなidとその由来を教えてください 苗字の大仲 (ONaKa) からです。2004-2005 年ぐらいに取得したはず。当時は (今も？) 母音を省略するのがカッコイイという雰囲気があったと思
これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ
「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。 「読める」になるために 言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。 Ginza Rails27 igaiga - Speaker Deck 著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。 たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。 できることを知る るりま (Ruby リファレンスマニュアル) の Enumerable、String Rails Guides の Active Support Core Extensions 日本語
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感 - id:onk のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
rubocop のしつけ方 - onk.ninja
rubocop のしつけ方 TL;DR rubocop --auto-gen-config して Offense count の多い順に毎日数個ずつ設定を確認したら 僕の使っている .rubocop.yml ができました これが onkcop か…(ゴクリ / “僕の使っている .rubocop.yml” https://t.co/KVryle9SJq — そのっつ (SEO Naotoshi) (@sonots) October 26, 2015 rubocop とは コーディング規約に準拠しているかをチェックする gem です。 https://github.com/bbatsov/rubocop こんなコードに対してかけると def badName if something test end end 以下のような警告をしてくれます。 Offenses: test.rb:1:5: C:
ピクシブさんに「社会人交換留学」してきました 会社の公式な取り組みとして「社会人交換留学」という面白実績を作りましたのでご報告です。 4/20〜4/24 の一週間、ピクシブ社で仕事してきました。 初出社 — Takafumi ONAKA (@onk) April 20, 2015 色々書いてると長文になっちゃったんですが、お付き合いください。 公式発表はこの辺り。 株式会社ドリコムとエンジニア職社員の「社会人交換留学」を実施しました - ピクシブ株式会社 採用サイト 社会人の交換留学!?ピクシブの現役エンジニアがドリコムに1週間のインターンシップを実施!! | 株式会社ドリコム 目次 何を得ようと考えていたか どんな準備をしたのか 受け入れが終わって 行ってる最中の様子 総括 何を得ようと考えていたか 主目的は 異文化に密に触れることで自社のそれと比較し、安心感や危機感、技術的審美眼を手に
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
自分がこうありたいというメモ。 作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。 これは今 GPT-4 に聞いた。 Q: 作業者と開発者の違いを100文字ぐらいで教えて。 A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。 単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つける
吉祥寺.pm30 で、チューニングがテーマだったので、マネージャとメンバー間で期待値をチューニングするという LT をしてきた。 トークタイトルは熊とワルツを。トム・デマルコの本です。 熊とワルツを リスクを愉しむプロジェクト管理 作者:トム デマルコ,ティモシー リスター日経BPAmazon 「管理」という言葉 「管理」と訳される単語は色々ある goo 和英辞書 によると 〔経営〕management 〔経営，運営〕administration 〔統制〕control 〔監督〕supervision 英辞郎 on the WEB によると administration〔【略】admin. ; adm.〕 caretaking（建物・土地などの） caretaking〈英〉（学校などの公共施設の） charge conduct（業務などの） control custody（大事な物の） d
Mountable Engine だらけの Rails アプリ開発 はじめに これはドリコムアドベントカレンダーの 2 日目です。 1 日目は id:sue445 さんによる ドリコムを支える中間ポイントシステム - くりにっき です。 お前誰よ id @onk ドリコム歴 2006/12/01 中途入社 9年目に突入しました 仕事 アプリケーションエンジニア 2009/04 から Rails アプリを触るように 主にサーバサイドを担当しています 今日の話 「普通に Rails アプリを作ると Mountable Engine を少なくとも 5 個は使う時代になったよね」って話をします。 目次 Mountable Engine とは Mountable Engine の作り方 Mountable Engine のテストの書き方 Mountable Engine の設定を書きたい 管理画面付
モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。 モジュラーモノリスとは モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。 有名なのは Shopify のヤツ。 モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。 モジュラーに移行するタイミング 僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。 世の中で見つけたモデル
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
先日 Wantedly さんのエンジニアリングマネージャー座談会に出演させていただいた。 wantedly.connpass.com テーマは、「エンジニアリングマネージャーの課題を相談したい人が多い」「その相談パブリックにしよう」なので、自分が最近課題に思っている「変化の速度感」についてざっくばらんに会話できたらなーというのが期待だった。 イベント中には、大きく 4 つの話をしたのかな。それぞれ会話の中では話しきれなかったことも補足しつつ書いていく。 技術スタックが違うチーム プロダクトと専門組織のバランス 専門組織を立ち上げるポイント 採用と oss-guild 技術スタックが違うチーム リンク先を見て貰うと顕著に分かると思うけど、はてなでは、そこそこバラバラな技術スタックを使っている。 hatenacorp.jp インフラは AWS、Google Cloud (オンプレはやっと撲滅し
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
スライド共有サービス hellshake を作りました ※2018-02-26 プロジェクト名をリネームしました。 https://github.com/onk/hellshake/pull/36 はじめに これは 【その1】ドリコム Advent Calendar 2015 - Adventar の 2 日目です。 1 日目は id:sue445 さんによる 社内gemとOSSのgemのメンテについて - くりにっき です。 【その1】ドリコム Advent Calendar 2015 - Adventar 【その2】ドリコム Advent Calendar 2015 - Adventar 今年のドリコム Advent Calendar は 2 本走るよ！ お前誰よ id @onk ドリコム歴 2006/12/01 中途入社 10 年目に突入しました 仕事 アプリケーションエンジニア R
migration の中で model を触ったら必ず reset_column_information する - onk.ninja
migration の中で model を触ったら必ず reset_column_information する 治安の悪い Rails アプリケーションでは、migrate 中に model の不整合で怒られることがあります。 class AddAgeToUsers < ActiveRecord::Migration[5.1] def up p User.first # 1 add_column :users, :age, :integer # 2 User.create(name: "Taro", age: 16) # 3 end end 1 で User model を触ってしまっているので add_column 前の DB の状態がキャッシュされて 2 で追加した add_column は別にキャッシュをリセットしないので 3 で ActiveModel::UnknownAttrib
社内から見たドリコム - onkはギリギリ霊長類
ドリコム 社員ブログガイドラインver0.3 〜社員・バイト向け〜 公式発表していない情報は公開しない 会社や個人にとってネガティブな印象を持たれる情報は公開しない 【【共有】ブログガイドラインver0.3-タカ派グループのブログ】 に引っかかる……かなぁ？イマイチ判断付かないので，この記事が消えていても気にしないでください( 言及したいのは ドリコム退職にあたり-宮崎謙介⇒加藤謙介（＠ドリコム）の誰にも見せないつもりの日記 について。 っていうか はてブ の方。 大好きなモノを貶されるとやっぱりムキーってなっちゃうモンで。思わず一言言いたくなりますよね。 二十代半ばの一番成長出来るこの時期に，魅力のない場所に居たいとは思わないですよ。僕は自分にとってプラスだと思うからドリコムに居るんだ。この思いは伝わって欲しいな。 誰かが 学校や会社の意味は「半径0クリック」に凄い人が居るかどうかだ っ
本記事は、はてなエンジニア Advent Calendar 2020 の 18 日目の記事です。昨日は id:YaaMaa さんでした。 yaamaa-memo.hatenablog.com 社内チャットではこの話で盛り上がったときにトライ木も作られており、良い頭の体操になっていました。 さて、本題。 Hatena::Let を眺めていて、こんな URL に気づいた。 http://let.st-hatelabo.com/onk/let.iframe?code_id=g5G0uOeEqfcA;key= クエリパラメータにセミコロン……！ パッと考えるとこれは { code_id => "g5G0uOeEqfcA;key=" } となりそうで、というか Ruby で実際にパースするとそうなる。 uri = URI("http://let.st-hatelabo.com/onk/let.ifr
例えば日記を書くときに、午前 2 時に書いたものは前日分としたいことがある。またユーザがメチャクチャ多いサービスでは、0:00 を回ったら翌日のログインボーナスを配る、としていると、まだユーザが多い時間にサーバの処理が要求されて大変なので、28:00 を日付変更線にしたいことがある。 こういうときには module AppTime def self.beginning_of_day(time) t = time.change(hour: 4) t <= time ? t : t - 1.day end end を作って、 AppTime.beginning_of_day(Time.current) を使うと「アプリ内の日付変更線では何日なのか」が取れる。 # 02:00 は前日扱い time = Time.zone.parse("2021-01-31 02:00") AppTime.beg
RubyKaigi 2017 でどんな発表をしたか 発表スライド 荷物とともに PC 送っちゃったのであとで貼ります ほぼ同内容のテキストはこちらの 4 記事です。 RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST 発表時の twitter での反応 togetter にまとめておきました。 API Development in 2017 - RubyKaigi 2017 #rubykaigi - Togetterまとめ Proposal 事前資料の公開が推奨されていたので、CFP に出した内容も置いておきます。 事後になってしまい申し訳ありません。 Title API Development in 2017 公開されてから思ったんだけど、RubyKaigi は ruby の API の話が多いので
何番煎じか分からないけど、最近やったので。 前提知識 AWS Lambda + Amazon API Gateway で HTTP リクエストを受け付けることができる AWS Lambda ではコンテナイメージを動かせる New for AWS Lambda – Container Image Support | AWS News Blog AWS Lambda で Sinatra アプリを動かすための公式サンプルがある https://github.com/aws-samples/serverless-sinatra-sample つまりコンテナ化した Sinatra アプリを Lambda 上にデプロイして HTTP リクエストを受け付けることができる。 動かす準備はもう全部整っていて、お手軽そうですね。 Ruby アプリを Lambda で動かすコンテナイメージを作る Sinatra
Rails Developers Meetup 2017 で RSpec しぐさについて話した - onk.ninja
Rails Developers Meetup 2017 で RSpec しぐさについて話した Rails Developers Meetup の年末拡大版である、Rails Developers Meetup 2017 で発表させていただきました。 RSpec をどう書いていくと良いのかの指針、みたいな話です。資料はこちら スライドを作るにあたって考えたこと 「5 分では RSpec の こう書くべき という話にたどり着けない」が最初の山でした。 考えてみれば 第 1 回 Rails Developers Meetup の willnet さんの話 が同じ題材 (RSpec の書き方) で、35 分枠だったので当然ですね。 そこで伝えたいことを絞ることにしました。どうせ聴衆は Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
体制を考えるときに意識していること - id:onk のはてなブログ
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
書類選考時に見ているポイント - id:onk のはてなブログ
ストーリー性のあるプレゼン - id:onk のはてなブログ
意識的に職位を下げる - id:onk のはてなブログ
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
手を動かさないマネージャーを試している - id:onk のはてなブログ
なんか京都に移住することになった - onk.ninja
「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
Ruby/Rails の勉強に何読んだらいいかと聞かれたとき - id:onk のはてなブログ
ピクシブさんに「社会人交換留学」してきました - onk.ninja
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
作業者じゃなく開発者でありたい - id:onk のはてなブログ
期待値をチューニングする - id:onk のはてなブログ
Mountable Engine だらけの Rails アプリ開発 - onk.ninja
Modular Monolith はどの辺りから考え始めるものなのか - id:onk のはてなブログ
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
フルタイムでやる仕事を作る #wantedlydev - id:onk のはてなブログ
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
スライド共有サービス hellshake を作りました - onk.ninja
クエリパラメータのデリミタに ; を使うこともできる - id:onk のはてなブログ
アプリ内の日付変更線をズラす系の実装 - id:onk のはてなブログ
RubyKaigi 2017 でどんな発表をしたか - onk.ninja
AWS Lambda でコンテナに入れた Sinatra を動かす - id:onk のはてなブログ