トーバルズ氏、Linux開発の現状や生成AIについて語る
Linuxの生みの親であるLinus Torvalds氏は、ここしばらく表舞台に顔を見せていなかった。しかし、Linux Foundationのが開催したOpen Source Summit Japanでは、久々に多くの聴衆がいる場に姿を見せ、同氏の友人であり、Verizonのオープンソース責任者を務めるDirk Hohndel氏を相手に対談を行い、Linuxの現状について語った。 2人はまず、次のLinuxカーネルリリースである「Linux 6.7」について話した。Torvalds氏は、日本に向かう直前に、Linux 6.7の4番目のリリース候補版をリリースしたところだった。順調に行けば、クリスマス頃にLinuxカーネルの次のバージョンがリリースされても不思議ではないペースだ。 このようなスケジュールになったのは、Torvalds氏が「マージウィンドウをクリスマスの時期に持ってきて、クリ
Googleのソフトウェアエンジニアリング
Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。「謙虚、尊敬、信頼」、心理的安全性、ダイバーシティとインクルージョンなど公正を重んじる文化から、コードレビューやテスト構成法など人間の行動を規定するプロセス、継続的インテグレーションや大規模変更システムなど変化への対応を支援する自動化ツールの基盤技術まで、Googleが試行錯誤を経て獲得した教訓を余すところなく紹介しています。経済学、心理学、マネジメント論などを背景にした人間への深い洞察をふまえ、データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセスも解説。Google
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
コードの健全性: 礼儀正しいレビュー == 役立つレビュー
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Rebuild: 246: You Are Welcome (fumiakiy)
Fumiaki Yoshimatsu さんをゲストに迎えて、Netflix, Tumblr, ブログ、コードレビュー、Android, Jackquard などについて話しました。 Show Notes 三体 | 劉 慈欣, 大森 望 早川書房公式 "エンジニアの宮川達彦さんが配信するpodcastにて『三体』をご紹介いただきました" Black Mirror 球児のために作った「大盛りカツ丼」 甲子園の老舗食堂がやめた悲しい理由 Nosedive (Black Mirror) The True Story Behind Netflix's Mötley Crüe Movie The Dirt Ozzy Osbourne Has Rare Genetic Mutation, Scientist Claims Basketball or Nothing Lies My Teacher Tol
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
コードレビューのレビューはマネージャーの仕事 | POSTD
経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ
HRzine
HRzine Day（エイチアールジン・デイ）は、人が活き会社が成長する人事のWebマガジン「HRzine」が主催するイベントです。毎回、人事の重要課題を1つテーマに設定し、識者やエキスパードが持つ知見・経験を、参加者のみなさんと共有しています。
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
CoolなソロとHotなペアプロのあいだ
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「（WIP）プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、２人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Programming
at Productivity Engineering − Forkwell Meetup #4
技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った - 弥生開発者ブログ
Misoca開発チームの黒曜(@kokuyouwind)です。 先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。 お題「みなさんRubocopになってもらって『直しました』といってください。『何を直したんですか？』と聞くので、直したところを答えてください」 須藤さん「直しました」「何を直したんですか？」「RSpecをTestUnitにしました」 #nagoyark03— 黒曜@技術書典2 か-13 (@kokuyouwind) 2017年2月11日 流しの技術フェローに教わったペアプロのコツ 先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。 今回はkakutaniさんから教わった内容のまとめと
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
A whole new GitHub Universe: announcing new tools, forums, and features
ProductA whole new GitHub Universe: announcing new tools, forums, and featuresToday I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the people building the future of software. It’s an… Today I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the peopl
Rebuild: 126: Anti-Democratic Product Management (higepon)
Taro Minowa さんをゲストに迎えて、テックリード、プロダクトマネジメントなどについて話しました。 Show Notes Nguyen Tech Lead（TL/テックリード）の役割 honcho Good Tech Lead, Bad Tech Lead What are the job responsibilities of a Technical Product Manager? Rebuild: 98: Superhumans Wanted (Naoya Ito) Rebuild: 123: The Grail Dialogue (Naoya Ito) Bad Boss vs. Good Leader Image Microservices Google’s product strategy: Make two of everything Product Manager の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのRailsアプリケーション開発
モブプログラミング - Woody Zuill氏とのインタビュー
先輩から教えてもらったコードレビュー
Cookpad iOS Release Flow
