非同期開発体制を支えるドキュメント文化 / YAPC::Hiroshima 2024git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo
インフォーマルな文章を書く楽しさ / secondlife - Message Passing
皆さんはじめまして。ゲストとして呼ばれた、secondlife です。Tateno Culture といった形で以前森田さんが書いていたが、あれは Tateno Culture というよりは Hatena Culture の話だと思っています。なので、今回はインフォーマルな文章という主題とはずれるかもしれませんが、自分はなぜそんな感じの文章を書いていたのか、というのを当時のはてな時代を振り返り書いてみようと思います。 はてな社に居た当時、これが皆さんの想定するインフォーマルな文章かはさておき、さまざまな社内向け文章を社内の全員、とは言わないまでも、7-8割の人がけっこう書いていた。 自分もしょっちゅう書いていたのだけど、なぜ書いていたのかを今更考えると、それはひとえに『楽しかったから』だった。 なぜ楽しかったのか 当時は2006年頭、自分は15人目の社員として会社にジョインした。入社すると
プロダクト開発でドキュメントを書かないとどうなるか
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
Googleのソフトウェアエンジニアリング
Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。「謙虚、尊敬、信頼」、心理的安全性、ダイバーシティとインクルージョンなど公正を重んじる文化から、コードレビューやテスト構成法など人間の行動を規定するプロセス、継続的インテグレーションや大規模変更システムなど変化への対応を支援する自動化ツールの基盤技術まで、Googleが試行錯誤を経て獲得した教訓を余すところなく紹介しています。経済学、心理学、マネジメント論などを背景にした人間への深い洞察をふまえ、データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセスも解説。Google
✓DO、X DO NOT の誤訳事案
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
#03: New Grads Struggle / Data Scientists Strive
森田が紹介するのは新入社員が職場に慣れて活躍するまでの苦労について調べた Ramp-up Journey of New Hires: Tug of War of Aids and Impediments, 向井が紹介するのはデータサイエンティストの生態について調べた Data Scientists in Software Teams: State of the Art and Challenges です。どちらも Microsoft Research の研究者 Thomas Zimmermann と仲間たちが同社内で行った調査に基づく論文。Microsoft の舞台裏を覗き見ることができる・・・かもしれません。感想などはハッシュタグ #misreading などにお寄せください。 Ramp-up Journey of New Hires: Tug of War of Aids and Im
成功するチームの隠し味
同じ開発チームでも、バグが頻発するチームとしないチームがあるのはどうしてでしょう？また、障害をいつまでも復旧できないチームと、すぐに解決してしまうチームがあるのはどうしてでしょう？アトラシアンでは、異なる人種や性別だけでなく、性格やアイデンティといった見えない多様性の中で、パフォーマンス性の高いチーム（=成功するチーム）を築き上げる努力をしています。その「隠し味」をみなさんと共有したいと思います。
PyCon JP 2015 keynote
業務系アプリとして『声』を活用したサービスをサービスインしたときにやったこと ～第5回業開中心会議 交流会ライトニングトーク～ #devchu満徳 関
GitHubでコードを「公開しない」リスク？サイバーエージェント流、OSS時代の開発哲学 | SELECK
今回のソリューション：【GitHub（ギットハブ）】 〜「GitHub」でソースコードを社内・社外に公開し、オープンなコラボレーションを実現した事例〜 数々のサービスを生み出し続けるエンジニアリング集団、株式会社サイバーエージェント。そのエンジニアリング文化の中心には、「GitHub」を活用したオープンなコラボレーションがある。 同社ではプロダクトのソースコードは可能な限り全社公開すると同時に、 「スターインセンティブ制度」というリポジトリのスター数に応じたインセンティブを与える制度により、自身の書いたコードを社外へ公開することを推奨している。 ▼そもそもGitHubって何？という方はこちらの記事もどうぞ！ チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】 ソースコードを可能な限り公開していくという流れは、ITベンチャーのみならず世界的大企業にも派生
リモートワークの是非 - 特別編：トップエンジニアたちの夜 『シドニアの騎士』観賞会＆座談会 ～Part3～ | Tokyo Otaku Mode Blog
こんにちは、ライターの岡田大です。 お待たせしました。特別編「トップエンジニアたちの夜」のPart3をお届けします。 ※Part1～2未読の方＆内容を忘れてしまった方は、Part1・Part2を一読してからお楽しみください！ チームワークの重要性ならびに、仕事を円滑に進めるための“道具”について語り合った参加メンバーたち。話題は自ずと、スタートアップ企業のエンジニアたちの間に広く浸透しつつあるリモートワークへ……。 堀木 ところで直也さん、リモートワークについてはどんなお考えをお持ちですか？ 伊藤 あれ？ TOMさんではリモートワークはしてないの？ 関根 一部していますが、基本はみんな社内です。ただ、オフィスのスペースが手狭になってきたので、次に入ってくる人はリモートが視野に入ってくるかなと。輪番制にして、倉庫行ってくださいとか、明日からアメリカ行ってくださいとか（笑）。 一同笑 伊藤 3
まつもとゆきひろ×増井雄一郎のオープンソース談義 「1人の熱烈なフォロワーがいれば、OSSで世界を変えられる」 - エンジニアtype
GitHubの誕生で、コントリビューターの存在意義が高まった Matz そもそも増井さんがMobiRubyを世界に広めたいという一番の理由って何？ 増井 オープンソース開発の世界で自分のアイデンティティを築きたいという思いからです。もし海外で働きたい、エンジニアとして知名度を上げたいと思った時に、何かプロダクトがないと難しいかなと。なので、今はMobiRubyを成功させたいと思っているんです。 Matz なるほど。何でも聞いてください。 増井 まず、オープンソース開発でこの10年の間に大きく変わったのが、コミュニティのあり方だと思うんです。特に、GitHubがあるかないかってすごく大きい。まつもとさんは、GitHubがあることで一番違うと感じるのはどんなところですか？ Matz 10年くらい前、つまり「GitHub以前」って、バグレポートもイシュー管理も新しいリクエストも、パッチもアナウン
継続開発のススメ 2012-06 版 - Twisted Mind
変更履歴 2012-06-24 ドキュメントの所に *diag シリーズについて追記 概要 開発があればリリースがあり、リリースが終われば、メンテナンスがあり、さらに開発があります。プロダクトが EOSL (End Of Service Life) を迎えるまではこれを続ける必要があります。 去年の 8 月に「継続開発のススメ」というので、やっていることをまとめたのですが約 1 年経ってもう少し細かくまとめて見ようと思いました。基本的には自分がいる環境を前提に書いてます。 継続開発のススメ http://d.hatena.ne.jp/Voluntas/20110823/1314036482 開発スタイルは常に変化し続けていくべきだと思っています。これだ、というのを作らないのが一番良い開発スタイルでは無いかなと。 脳内を書き出しているので、日本語がおかしい上に一貫性が無いと思います ...
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
元々社員の約9割が在宅勤務の「リモートファースト」企業HashiCorp、創業者のハシモト氏が語った教訓
Rebuild: 240: Super Saiyan God Engineer (mayuko)
GitHub - yoshiori/manager-readme
オープンソースソフトウェアの育て方
Phacility - Home