2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
2024/06/22にScrum Fest Osaka 2024 品川&葛飾トラックで発表させていただいた資料です。 Scrum Fest Osaka https://www.scrumosaka.org/ プロポーザル https://confengine.com/conferences/…
PyCon JPはいますぐ生まれ変わるべき
昨年からトラブルが続いているPyCon JPですが、9月27日のPyCon JP 2024を前にして、また新しい火種が生まれました。 2024年9月22日、PyCon JPの技術に対する不正の告発、並びに技術者と大衆に対しての警鐘（以下、怪文書2）というタイトルの記事が突如として公開されたためです。 この記事は、python_bokume2というアカウントで公開されていることから、およそ4ヶ月前の2024年5月31日にpython_bokumetsuというアカウントで投稿された採択されるプロポーザルを書こう!!（現在はアカウントごと削除されている。以下、怪文書1）を書いた人と同じ人物による投稿であることがうかがえます。 最初に記事に関しては、インターネットでいうところのいわゆる完全なる怪文書であったのに対して、今回の怪文書2では、具体的な登場人物の名前やSlackのログなど、実際におこなわ
大吉祥寺.pmにて、初プロポーザル&カンファレンス初登壇しました！
はじめに 早いもので未経験からエンジニアにジョブチェンして約2年が経ち、先日カンファレンス初登壇の機会をいただきました。今回はその時のことについて、なぜ登壇したいと思ったのか、まわりから受けたサポートなどについてお話ししたいと思います。 大吉祥寺.pmとは 吉祥寺.pmとは? 「吉祥寺.pm」は、当初Perlのイベントとして始まりましたが、次第に参加者の多様性が広がり、プログラミング言語や、データベース、設計方法論、キャリア、勉強会開催方法など、Perlに限らず、「それぞれが発表したいことを自由に発表できる場」に変わっていきました。発表枠は毎回必ず全て埋まり、常に新しい人が参加し続け、毎回全く違う発表が行われる、数あるテック系勉強会の中でもユニークなイベントになっていると言えます。 大吉祥寺.pmとは? 通常は、平日の夜に開催される吉祥寺.pmの拡大版として、大吉祥寺.pmは土曜日の終日開
教えて先輩！ 牧大輔さんインタビュー ──【後編】ポストコロナの新しい技術イベント、YouTubeで銀の盾 - SmartHR Tech Blog
「教えて先輩！ DevRelの立ち上げ方」に続く「教えて先輩シリーズ」の第二弾としまして、JPA（Japan Perl Association）の初代代表理事、buildersconの立ち上げ、YAPC::Asia Tokyo時代のYAPC（Yet Another Perl Conference）の運営で知られるlestrratこと牧大輔さんにお話をうかがいました。インタビュアーはSmartHRのDevRelのinaoです。 前編に続く後編は、主にポストコロナの新しい技術イベントやYouTubeのノウハウについてのお話です。 tech.smarthr.jp （インタビューは2024年7月に行いました。内容は当時のものです） プログラマーからのキャリアチェンジ ポストコロナの新しい技術イベント ほしい人にだけノベルティを渡す方法 ただ飯目当て対策 オンライン、オフライン、ハイブリッド You
教えて先輩！ 牧大輔さんインタビュー ──【前編】YAPC::Asia Tokyo、buildersconの運営秘話 - SmartHR Tech Blog
「教えて先輩！ DevRelの立ち上げ方」に続く「教えて先輩シリーズ」の第二弾としまして、JPA（Japan Perl Association）の初代代表理事、buildersconの立ち上げ、YAPC::Asia Tokyo時代のYAPC（Yet Another Perl Conference）の運営で知られるlestrratこと牧大輔さんにお話をうかがいました。インタビュアーはSmartHRのDevRelのinaoです。 前後編に分かれており、前編は主に牧さんご自身やYAPC、buildersconについて、後編は主にポストコロナの新しい技術イベントやYouTubeのノウハウについてのお話です。 tech.smarthr.jp tech.smarthr.jp （インタビューは2024年7月に行いました。内容は当時のものです） 生い立ち アメリカでのプログラマー時代 日本でのプログラマー
作り、造られ、創る
今日はbuilderscon 2024の開催日でした。 自分が立ち上げて（でも心折れて開催しなくなった）イベントを、自分が関わらないところで続けてくれるというのは、なんとも感慨深いものです。少なくとも俺のやろうとしてたことは意味があったんだな、という気持ちにさせられました。 開催にこぎつけた@nasa9084さん、ありがとう！他のスタッフのみなさまも本当にお疲れさまでした。 さて、今回私は運営にはTシャツのスポンサー以外一切ふれてないのですが、実は開催前日の時点でスケジュールに穴があくかもしれないという話をSlackで聞いたので、それを聞いた私はすぐさまGoogle Docsで原稿を書き始めました。で、すぐ書きおわったのですが、その時にはもうonkさんとsongmuさんが代役に決まったので私の話は無事オクラ入りになりました。 ならまあ、供養しとこうかな、ということでここに載せることにしまし
なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待 | blog.jxck.io
Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブ
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
PHPコア開発者になって半年経ったので、php-srcでの活動を振り返る - Qiita
こんにちは！PHPとCを主に書いています、Sakiです。日中はBASE株式会社さんでお仕事させていただいています。早朝と夜間にphp-srcでの活動をしています。PHP8.4のリリースマネージャーもやってます。 2024年からありがたいことにPHPコア開発者として採用していただき、半年とちょっとになりました。ちょうど一区切りということで、これまでの活動を簡単にまとめたいと思います。細かいものや、最終的に成果が出なかった（議論がまとまらなかったなど）ものは除外しています。 2023年、コア開発者になる前 実は私はphp-srcどころかOSSの経歴がかなり短いです。 はじめてのコントリビュート PHP8.1から、PDO MySQLでmysqlndをドライバとして使用し、PDO::ATTR_EMULATE_PREPARESがtrueの場合、PHPのネイティブタイプで値が返される、というように仕様
開発生産性指標を向上させるためにやってはいけないアンチパターン - Findy Tech Blog
こんにちは！ファインディでFindy Team+開発チームのEMをしている浜田です。 昨今、開発生産性を高めるための取り組みを行っている組織が増えてきていると感じています。 開発生産性を向上させるためには、まずは定量的に可視化することが重要です。 可視化することで現状を把握して、開発組織の伸びしろを発見したり、課題を明らかにし、改善活動に取り組みやすくなります。 一方、定量的な指標に焦点を当てすぎてしまい本質的ではない対応をしてしまい、指標は向上したものの実際の生産性は向上していなかったり、むしろ悪化してしまうこともあります。 この記事では、開発生産性指標を向上させるためにやってはいけないアンチパターンについて紹介します。 デプロイ頻度を向上させるために、デプロイプロセスは変更せずに実施回数を増やした デプロイ頻度はDORAが提唱するDevOpsの4つの指標(Four Keys)の1つであ
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
無邪気なエンジニアリングができなくなってきた
タイトルの通り。好きでやっているエンジニアがだんだん好きではなくなってきたような気がして、改めて何が起きているのか、思考はまとまらないから箇条書きする。 無邪気なエンジニアリングとはコードを読む、書くのIOがとにかくたくさん気になったOSSやサービスはすぐさわる記事や登壇で書く以外のアウトプットもたくさん無邪気なエンジニアリングをして、これになりたかったインターネットで一発当てる著名なOSSのコミッターカンファレンスのプロポーザルをたくさん通す本をたくさん書いているたくさん質の良い記事を書いて凄い PV 数なりたかったのその行く末生活を全てエンジニアリングに捧げようとする無理あらゆる技術イベントに顔をだそうとする私生活や仕事でしばしば予定がつかずキャンセル帰りが遅くなるのが良くないので、家から近いイベント以外いかなくなった（規模の比較的おおきい）コミュニティを主催するスポンサー探しで苦労こ
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
2024/07/13 大吉祥寺.pm 20分レギュラートーク 登壇資料
良いコードってどんなコードですか？という質問を受けたら何と答えるか - snoozer05's blog
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期（それぞれRubyの会社で働いている）と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2024年のRailsと自由について考える
僕のキャリアとワインと鍋 / daikichijojipm
集中して作業する技術/how_to_work_deeply
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
