はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ

「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」カオスなプロダクト開発を効率化したら硬くて息苦しい官僚組織になっちゃった! 大企業病の罠を乗り越え若々しいチームを実現するぞ 効率化を進めていったら息苦しい組織になってきたと悩む方に向けたセッションです。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19268 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関連スライド 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt20

弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege

※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ

循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community

よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。 出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニア

1. 『失敗の科学』マシュー・サイド 著、有枝春 訳 2. 『ヒューマンエラーは裁けるか』シドニー デッカー 著、芳賀 繁 訳 3. 『なぜエラーが医療事故を減らすのか』ローラン・ドゴース 著、林 昌宏 訳 4. 『IT失敗学の研究』不条理なコンピュータ研究会 著、日経コンピュータ 編 keyboard_arrow_down はじめに keyboard_arrow_down 失敗を科学する keyboard_arrow_down 失敗が再発するメカニズム keyboard_arrow_down ミスを厳罰化するとミスが報告されなくなる keyboard_arrow_down ミスから学ぶチームのつくり方 keyboard_arrow_down スイス・チーズの喩え keyboard_arrow_down IT失敗学の研究 keyboard_arrow_down おわりに 明確なゴールと計画

はじめに 昨年2023年は、株式会社NoSchoolのCTOとして、オンライン家庭教師マナリンク（https://manalink.jp/ ）に関わる開発、エンジニアリングマネージャー、採用、UIデザイン、運用保守、PMなどを兼任していました。 本記事では、エンジニアリングマネージャー（以下EM）を兼任していて考えたことをまとめていきます。 シリーズA前後のスタートアップという特異な状況かつ、マネジメントしたメンバーも3人と小規模なためあまり参考になる知見か分かりませんが、現時点での自分の考え方の備忘録的な意味も込めてまとめておきます。 考えたことまとめ それでは早速矢継ぎ早に考えたことをまとめていきます。 テキストによる情報量の欠落を想像するようになった 直接会話することと、文字でやり取りすることを比べると、つくづくテキストって情報量が欠落するなぁと思います。ソースレビューのコメント1つ

開発言語 開発当初はObjective-Cで書いていましたが、やはりSwiftの方がStruct/EnumなどSwiftyに書けるのが便利で、徐々にSwiftへ移行しています。 Swift / Objective-C（古い機能はObjective-Cで書いてあるので移行中） HTML/CSS（アプリサポート用サイトのコーディング） Python（画像のリサイズなどで自動化スクリプトをつくるとき） Ruby（fastlaneのアクション作成） Bash（Info.plistの設定変更やxcodebuildの自動化バッチをつくるとき） 利用しているWebサービス 定番のサイトも多いですが、カテゴリ分けして整理してみました。 リファレンス系 以下に書いてあるサイト以外にも個人の技術ブログなどにもとてもお世話になっています。 Qiita（情報収集/アウトプット） Developers.IO（情報収

発表した場所: https://timeedev.connpass.com/event/299088/ 発表者: https://twitter.com/__hiza__

そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。 事業が大きくなると組織という仕組みの重要性が上がる 同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります： コーチング紹介 ヒューマンスキル紹介 爆速アウトプットを組織的に支える施策 事業の急成長における表側と裏側 稟議入門 こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少

たぶん2023年一番お世話になったライブラリです。 2022年まではsimdjsonをよく使っていたのですが、新規プロジェクトはGlazeばかり使っています。 開発が活発だし、ISSUEへの対応が速いのもありがたいです。 良い点 SIMDを利用していないのにsimdjsonやyyjsonと遜色ない速度で動作する 構造体やクラスだけでなくSTLコンテナもJSONとの直接読み書きができる 中間データに独自バイナリ形式を利用してさらに高速化できる いまいちな点 長い文字列が多いJSONデータの読み込みではSIMDを使っているライブラリに対して不利になる 最後のフィールドのカンマやコメントの読み込みに対応していない ストリーム的な処理はない(と思う) 代替ライブラリ 似たようなアプローチでSIMDを使ってさらに速いJsonifierというライブラリがあります。 純粋な速度を求める場合にはこちらを使

初心者むけK8sハンズオンの補助資料です https://qiita.com/minorun365/items/0441e4878f0984a9fc0a

背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと

これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す

こんにちは。カミナシでプロダクトマネージャー（PM）をやっている中村です。 最初に謎の宣言をするのですが、自分は「XXができるコツ１０選！」みたいな記事が比較的嫌いです。（嫌いなんかい！）嫌いなんですが、、思うことがあってこんなタイトルの記事を書いています。 PMの仕事をする中で、「プロダクト戦略ってめっちゃ大事！」って思うことが多いのですが、一方で、「プロダクト戦略ってなんか高尚すぎて、とっつきにくい！」と考えている人も多そうだなとも思います。 この２つの思いを合わせ持つ中で、「戦略的思考」と「コツ」のようなそのへんにうるさい人がこの記事見ると怒られそうな２つのキーワードを併せもった記事を書いてみて、「プロダクト戦略立てられそう！もっとよくできそう！」と少しでもライトに思ってもらえると嬉しいと思いました。 ということで、あえて『「プロダクト戦略どう立てたらいいかわからん」な人に贈る7つの

この記事は FastDOCTOR After Advent Calendar 27日の記事です。 はじめに ファストドクター株式会社でテックリードをしている shirauix と申します。 弊社では、ある Next.js アプリケーションを別会社のパートナーさんに外注することによって初期開発を行いました。ある時点からこのシステムを内製化することになったのですが、それにあたって多くの課題を解決する必要がありました。 この記事では、外注と内製のそれぞれのメリット・デメリットや、内製に切り替える際にどんな苦労があったのかについての赤裸々な事例をご紹介します。 対象となる読者 外注で初期開発したシステムを内製に切り替えてメンテナンスしようとしているエンジニアの方 新しくシステムを開発したいが、外注と内製のどちらを選択すべきか悩んでいる方 外注と内製の違い 外注するか内製するかはあくまで手段の話であ

この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法

弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists

この記事は「paiza Advent Calendar 2023」の最終日の記事です。 最終日はpaiza株式会社で社長をやっている片山がお送りいたします。 タイトルはほぼ釣りです。 ちなみに、paizaはITエンジニア向け国内最大の転職・就職・学習プラットフォームです。（paiza.jp) 記事概要絵にかいた餅は大した価値はなく、実行し成果が出せて初めて価値がある 実行プロセスやプロダクトが良くても、市場ニーズがなければ価値はない 計画は粗くてもいいから一筆書きで描き切ることが重要 一筆書きで書いたら実際に動いてすぐ更新すべし つまり実行が出来る計画を描き、実際に実行し、発見があれば即修正しながら成果を出せ、というごく当たり前な内容です。 ただそれがとても難しいので、どのあたりでつまづきやすいのか、経験を元にまとめてみました、という記事です。 計画は荒くてもいいから一筆書きで書き、高速に