Facebookが障害で止まった日、プログラマはいつもより多くのプルリクエストをマージした。解析ツール企業が明らかに Haystack社はGitHubのリポジトリを監視し、プルリクエストやマージなどをメトリクス化して分析することでプログラマの生産性やボトルネックなどを計測するサービスを提供しています。 同社は、Facebookが障害によって停止した日はいつもよりプルリクエストのマージが増加したと、ブログ「Facebook Outage Increased Developer Throughput by 32%」(Facebookの障害によりデベロッパーのスループットが32%増加した)で紹介しています。 Facebook Outage Increased Developer Throughput by 32%: https://t.co/GBlNpjpMx1 — Haystack (@use
こんにちは!スマートキャンプ ソフトウェアエンジニアの中川です。 リモートワーク全盛の昨今ですが、みなさんはチームのコミュニケーションをどうされていますか? 弊社のBOXIL開発チームはこのたびメインのコミュニケーションツールをDiscordからGatherに移しましたので、今回の記事ではそのなかで得られた知見やコツなどをご紹介できればと思います! 前提・リモートワークにおけるコミュニケーションの二大方針について Discordによる同期的なコミュニケーションで起きた課題 Gatherとは Gatherによって起きたポジティブな効果 カジュアルな雑談の創出 ほどよいプライベート空間の確保 オフィスの視覚的な再現 全体 執務室エリア キャンプスペース(広間的なエリアやなんとなく集まる場) 会議室エリア 1on1エリア Gatherに足りてないこと・期待したいこと 提供されていない機能は補完で
大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
現在WantedlyではNode.jsのパッケージ管理にyarn v1を使っています。現在私は開発者体験の改善を目指してyarn v2への移行を検討しているのですが、その過程でyarn v2が誤解されがちだと感じるようになりました。そこで社内への情報提供も兼ねて、いくつか誤解されがちだと思われる点を紹介したいと思います。 (わかりやすさのためにyarn v2と呼んでいますが、 yarn v3以降も含みます。これらはメジャーバージョンアップではあるもののyarn v1→v2のようにアーキテクチャが刷新されるわけではないからです) ポイント1: yarnをv2にするのにPnPは必須ではないyarn PnPはyarn v2の目玉機能で、パッケージをnode_modules以下に展開せずに仮想化してロードできるようにするというものです。node_modulesの展開作業が不要になるほか、依存関係の
この記事は2020年10月28日に行われたさくらの夕べ Tech Night #3 Onlineにおける発表を文章化したものです。 ダーシノと申します。さくらインターネットでフロントエンドエンジニアをやっています。この記事では、発生したバグをプログラマーに的確に伝えるためのバグ報告の書き方について説明しようと思います。 バグ報告にはコツがある! プログラマをされている方で、過去にこんなバグ報告をもらった経験はないでしょうか。例えば「動きません」とだけ送られてきたりとか、イラッとした感情も含めた「使えねぇな!」みたいな報告、「アレもコレもソレもおかしいよ」みたいな、いろんなものが書かれた報告もあると思います。バグを残してリリースしてしまったプログラマーとしては非常に申し訳なくて今すぐ対応をしたいのですが、さすがに先ほどのようなバグ報告を受けても、我々プログラマは対応のしようがありません。「申
社歴3年業界歴●●年・・・、システム部のハライといいます。 サポートエンジニアからスタートしたのに、いつの間にか開発者になっていました。 主にphpを使ってましたが、最近はpythonと両刀になっています。 趣味は弓道、読書、絵画(鑑賞と描く方も)、なにか手作業で作ることとデジタル嫌いな完全アナログ人間です。 私はGMOリサーチに入社以前から、とある大学教授の研究にツール提供という形でお手伝いをしています。 ツールといってもExcelVBAで作成したもの、「エンジニア」でメシを食ってるにしては少々恥ずかしくなるレベルではあるのですが、他業界への支援、とまとめてみると、労少なくして寄与多し、くらいのことが可能なケースもある、という事例のご紹介になります。 テックネタとは言い難いところがありますが、この程度でも役に立つのか、ということを知ってもらい、なにかの折にお手伝いする側になる後押しになれ
また、TechnologyRadarの各項目は更新されていくものであるため、更新・追加・新登場かどうかも直感的にわかるように表現されている。Newは新しく追加された項目、Movedin/outは以前紹介されたことがあるが所属リングが更新された項目、No Changeは以前紹介されている項目を指している。 あくまでもこれらの項目はThoughtsWorks社が独自の目線でピックアップし、分類したものである。それを考慮した上で、自社に採用できるツールを探すことはもちろん、次に定着しそうなツールはなんだろう、と言った別の目線でリングや新登場の情報を読み進めるのも面白いかもしれない。 ちなみにGoogle Sheetのテンプレートを使えば自分だけのRadarを作成することもできる(https://www.thoughtworks.com/radar/how-to-byor)。 リモートワークのテク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く