中国版ギットハブ、コードを検閲・遮断か？ OSS開発者に衝撃
中国におけるギットハブの競合サービスとして人気の「ギッティ（Gitee）」で公開されていたソースコードが一部非公開となり、中国のオープンソース・コミュニティに衝撃を与えている。理由は明らかではないが、中国政府による検閲が疑われており、イノベーションを阻害する恐れが指摘されている。 by Zeyi Yang2022.06.01 171 2 5月18日の朝のことだ。中国の数千人ものソフトウェア開発者たちは、中国企業「ギッティ（Gitee）」にホストされているオープンソース・コードがロックされ、非公開になっていたことに気づいた。ギッティは、国際的なコード・リポジトリ・プラットフォームであるギットハブ（GitHub）の競合サービスで、中国政府の支援を受けている。 ギッティはその日の遅くに声明を発表し、ロックされたコードは手作業でレビューされており、今後はすべてのオープンソース・コードが公開前にレビ
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
Goのリリースプロセスとブランチ戦略 - YAMAGUCHI::weblog
はじめに こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？ このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
Googleのソフトウェアエンジニアリング
Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。「謙虚、尊敬、信頼」、心理的安全性、ダイバーシティとインクルージョンなど公正を重んじる文化から、コードレビューやテスト構成法など人間の行動を規定するプロセス、継続的インテグレーションや大規模変更システムなど変化への対応を支援する自動化ツールの基盤技術まで、Googleが試行錯誤を経て獲得した教訓を余すところなく紹介しています。経済学、心理学、マネジメント論などを背景にした人間への深い洞察をふまえ、データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセスも解説。Google
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
成長の場を求めないソフトウェアエンジニア？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
スマフォブラウザゲームのパフォーマンスチューニング手遅れパターン - latest log
最近、こういう事例が増えてます ネイティブゲームアプリもグリグリアニメーションする昨今 🐤俺らもブラウザゲームの限界を目指そうぜ! 🐤盛るぜー盛るぜーー超盛るぜーー 数ヶ月後… 🐤来月リリースだけどカクカクします助けてーー 🐲きさまら何度やったらわかるんだ…そこに正座しろ…(ゴゴゴゴゴ) #こうですか?— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲なぜ作ってる途中で実機で動作確認をしなかったんですか? 🐤え、あの、CreateJS なら大丈夫かとおもって… 確認してませんでした 🐲(イラッイラッ #こうですか— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲(はぁ…)とりあえず実機動作とコードを見たいので開発サーバ名やログインする為の情報ください …2日後… 🐤…これで💦 🐲…動かない…あとminify解除してない状態な
Q. StoryboardとXIBはどう使い分ければいいんだろうか？ - Qiita
storyboardについて調べていたところ、StoryboardLintの作者の考えが興味深かったので該当のstackoverflowのエントリを抄訳した。訳はニュアンスが伝わればいいくらいの適当さです。 When to use Storyboard and when to use XIBs どういうときにstoryboardを使って、どういうときにXIBを使えばいいか、何かガイドラインはあるかな。それぞれの長所と短所はなんだろう。どういう状況でそれぞれを使えばいいんだろう。 動的にUI要素を組み立てる場合にstoryboardを使えないってのは知ってるんだけど。 (Asked by affian at 2012/2/22) Answer by henning77 at 2012/3/1 ぼくはXIBを使い込んだし、storyboardを使ったプロジェクトを二つ完成させたことがある。そこ
はてなブログチーム エンジニア座談会 - 株式会社はてな
2013年11月20日アプリケーションエンジニアはどのように仕事をし、どんなことを大切にしているのでしょうか。はてなでは、さまざまなサービスの開発を、複数のチームに分かれて行っています。サービス開発の現場で、はてなブログやはてなダイアリーを開発する「はてなブログチーム」から、id:onishi、id:hitode909、id:shiba_yu36、id:cockscombの4人に話を聞きました。 左からid:shiba_yu36、id:hitode909、id:cockscomb、id:onishi はじめに─本日は、はてなブログチームからプロデューサー兼ディレクターのonishiさん、そしてアプリケーションエンジニア3名にお集りいただきました。はてな社内にはいろいろなチームがありますが、特にブログチームではこのように開発している、という話をお聞きしたいと思います。よろしくお願いします。
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
Cookpad iOS Release Flow
LINEが開発体制、グローバル対応の秘策、サービス基盤の変遷を解説
はてなブログチームの開発フローとGitHub
「何故クックパッドのサービス開発は日々進化しているのか」という発表をしました。 - yoshiori.github.io