How Google SRE and Developers Collaborate - IT Revolution
July 12, 2022 How Google SRE and Developers Collaborate This post was adapted from the paper “How Google SRE and Developers Collaborate by Christof Leng, Tracy Ferrell, Alex Bligh, Michal Gefen, Betsy Beyer with help from Salim Virji from the Spring 2022 DevOps Enterprise Journal. Google’s Site Reliability Engineering (SRE) team is a specialist engineering organization focused on designing, buildi
限界集落で 2 年間リモートワークをしていたプログラマが 4 ヶ月間東京で働いてみて感じたこと - dunno logs
個人的な記録なので、誰かが読むにはコンテキストが不明な部分も多いと思いますが振り返りとして。 東京で 4 ヶ月 なんということはなく、妻が埼玉で里帰り出産をすることになったので、本社がある東京に埼玉から通うことにさせてもらった感じです。この手の勤務地変更は会社でも初めてだったと思うのだけど、地方勤務者が本社に勤務地変更するということで受け入れてくれて助かりました。 リモートワーカーとしての私 リモートワーカーとして皆さんが浮かべるイメージは在宅で自由な時間でという感じだと思いますが、私の場合はリモートワーカーと呼ばれてるものの、実際は他にも勤務者が居る地方（と言っても山奥）のオフィスで東京と同じ勤務時間働いているので、どちらかというと支社とかで働いている人に近いと思います。 たぶん、場所が超山奥で開発・営業拠点的な意味は全く無い場所なので、リモートワーカーぽく扱われているのかも。 一方で、
良いディフェンダーはタックルをしないし、良いエンジニアは障害対応をしない · takus's blog
Amazon のオススメ本に出てきた「 サッカー データ革命 ロングボールは時代遅れか 」を読んでみました。 この本は、野球界における「 マネーボール 」のように、 サッカーを様々なデータを元に見つめ直すような内容になっていて、 例えば、チームが負けているときに交代によって最大の効果を得るためには、 1 人目の交代を後半 13 分、2 人目を後半 28 分、3 人目を後半 34 分までに行うべきとか、 極端に能力の高い選手を獲得するのと弱点となる選手の穴を埋める補強はどちらがいいのかとか、 統計を元にしたサッカーに関する興味深い考察が多かったのですが、その中に 1 つ引っかかる話があったのでそれについて書いてみます。 良いディフェンダーはタックルをしない 本書の中で、 四半世紀に渡ってマンチェスター・ユナイテッドを率いた名将ファーガソンが、 オランダ代表のディフェンダー、ヤープ・スタムを放
SHIROBAKOみゃーもりの優秀さ
Stargazer Meetup #1 http://connpass.com/event/18896/
考えることを減らすという指針 - Konifar's WIP
最近チームメンバーが増えてコードレビューの数も増えてきました。 レビューでお互いが納得できるような説明を何度もするのも嫌だし、『よいコードとは何か』ということについて自分の思考を整理すべきかなぁと考えていました。 よいコードについてはすでに議論されつくされていて、最後は好みの問題という人もいるしケースバイケースだという人もいると思います。たしかにそうだなぁとも思うんですが、レビューで指摘する際にそのように伝えてしまうと相手は次から何をどう考えてコードを書けばいいかわからなくなってしまうし、最低限自分なりの指針を明確にしておく必要があります。 で、自分の指針を整理した結果、 考えることを減らす に落ち着きました。 この指針に沿って、考えたことをまとめておこうと思います。項目とか綺麗にまとまってないですが、このブログはタイトルの通りwork-in-progressなのでまぁいいかなぁと言い訳し
重箱の隅をつつく - 学校では教えてくれないバッドノウハウ英語 #10 - bkブログ
重箱の隅をつつく - 学校では教えてくれないバッドノウハウ英語 #10 学校では教えてくれないバッドノウハウ英語の10回は、 nitpick, cherrypick という、ともに pick で終わる表現を取り上げたいと思います。 "nitpick" は「あら探しをする」という意味の表現です。動詞にも名詞にも使われます。nit はシラミの卵という意味で、シラミの卵を摘み取るのはいかにも小さなこと、という響きがあります。コードレビューの際に、重箱の隅をつつくような指摘をするときにぴったりの表現です。nit-pick とハイフンが入る場合もあります。 例) It's just a nitpick but I think "file_name" is better than "filename". 重箱の隅だけど、 filename より file_name の方がいいと思うよ。 Please
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 - XOOPS専門-株式会社RYUS
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 カテゴリ : 技術全般 2010-10-14 19:37 MySQLのInnoDBはトランザクションが使えたり、行ロックが使えたりして、データの整合性の点でMyISAMに比べて優れています。 業務系アプリになると、データの整合性が重視されることも多く、トランザクションを使うことも増えます。 今回、そのトランザクションを使っていて、思いもよらないクエリがきっかけで、テーブルにロックが掛かってハマりました。 テーブル構造はこのような感じ...。 CREATE TABLE `working` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col` int(11) NOT NULL DEFAULT '0', PRIMARY K
若い同僚を疲弊させたくない - やしお
隣の席に入社2年になる若手社員がいる。私が半年前に今の部署に異動してから様子を見ていて、大変そうな状況になっている。まだ経験の浅いうちに、仕事のマネジメントをしてくれる人がいないというのはつらいことだなと思った。 自分が入社して配属された部署には、課の下に3、4人程度の「チーム」があってリーダーがいた。そのリーダーが部署間の調整や仕事の割り振り、メンバーの進捗を確認したり、あるいは物事の判断をしていた。メンバーにはきちんと仕事がフィルタリングされた状態で入ってきたし、業務の負荷量も把握してくれていた。だからメンバーは自分の作業に集中すればよかった。またメンバーが「いったいどういう背景や経緯でこの作業があるのか」と聞けばリーダーはきちんと教えてくれたし、あるいは「これはこうした方がいいのでは」といった提案も受け付けてくれていたから、「ひたすら作業ばかりをしてむなしさが募る」といったこともなか
後輩のH.Aです。降臨させていただきました。 「どういう規模のどういう職..
後輩のH.Aです。降臨させていただきました。 「どういう規模のどういう職場で、二人がどういう立場で働いているのか分からない」とのコメントがありましたので補足します。 いわゆるユー子で、全体の規模は60人程度。わたしも先輩も新卒採用の正社員です。所属しているチームは7人です。インフラ、ネットワークまわりの運用をやっているチームです。 わたしは3年目。私立文系出身で、いまのチームに異動して半年になります。それまではプログラミングを中心にやっていました。 先輩は4年目で、工業大出身。ずっといまのチームにいます。最初っからバリバリ仕事ができて「驚異の新人」と呼ばれ、非常に高い評価を受けている方です。 そもそもですね、 わたしが業務を引き継ぐのはIさんからであって、あなたからではないです。 なぜあなたがわたしに業務を指示するのか、なぜわたしを指導しようとするのか、ずっと疑問に思っていました。 それが
Treasure Dataに入社しました - myui's memo
3/31付けで4月から国立研究開発法人になった産業技術総合研究所を退職致しまして、4/1からTreasure Dataに入社しました。第一号のResearch Engineerとして東京オフィスで働きます。 CTOの太田さんから2013年頃に一度お誘いを受けておりましたが、2014年になってまた声を掛けて頂き、2年越しでの入社となりました。 なんでTreasure Data？ 現在のTreasure Dataでは、毎秒45万レコード、4,000億レコード/日ものデータが投入されていて、Hiveで処理されるデータ量も3+ペタバイト/日と急速な発展をとげております。研究でもこの規模のデータ量を扱うことはGoogleやFacebook等の一部の研究者を除いてはありませんから、非常に挑戦的な課題に取り組める環境であることにDB研究者として第一に魅力を感じました。優秀なエンジニアが集まっていて刺激的
2014年にリモートで試したミーティング類のパターン - はまさき
今年の初めからアメリカに引っ越したので社内の人とのやり取りをどうするかという悩みに現実的に直面し、この1年で色々試したのでセーブポイントとしてまとめておくことにした。（ブログの記事を書かなさすぎてはてな記法忘れつつある...） チームとミーティングの距離感 8人くらいの会社。誰もがSPOFで、何かに詳しい人間はだいたい一人に絞られる*1。会社として重要な箇所に一人だと心許ないというより、誰も休めなくなってしまうので概ねわかるだろうという他者を含めるか、共有するなりで冗長化して、2人以上がひとつの何かに取り組んでいる形を組織中に点在させている。 その2人の間や異なる担当間でそれぞれミーティングの時間を取っておきたいが、大仰に週例、月例、毎朝のスタンドアップみたいなミーティングをそっくり入れ込むにはちょっと負荷が大きいので何か工夫が必要だ。 勤務地は強制していない。オフィスはあるけれど必要にな
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
某R社を５日でクビになった話 - Code.io
2015-03-07 某R社を５日でクビになった話 Hello,World!個人開発でぬくぬくやってきたエンジニアの僕が、縁あってエンジニアインターンし、５日目にしてクビになるという出来事があり、学びが多かったので綴りたいと思います。 ◼︎某社との出会い 焼き肉をおごるという企画で、スカウトが来て、オシャレでキレイな焼き肉屋さんでランチをしました。そこで、スゴイエンジニアさんに「このサービスのこの部分をこうしたほうがよくて、ここまで作ったので開発してもいいですか？みたいにすれば自分のやりたい開発ができるんだよ」と言われ、自分のエンジニアのイメージがガラッと変わって魅了されて、興味を持つようになりました。そのスゴイエンジニアさんは、今も憧れているスゴイ方です。カッコイイなと思っています。 ◼︎某社の技術責任者との出会い 会社訪問を予定していた日に、スゴイエンジニアさんにスゴイエンジニアさんの
退職します - たごもりすメモ
先にまとめ 現在の勤務先を退職することにしました。本日が最終出社日です。 次はまだ決まっていません。というか、どことも具体的な話はまだしていない、という段階です。面白そうな職場はどこにあるかなと探している段階ですので、魅力的なところに心当たりがある方はぜひご連絡ください。色々な人と話ができるといいなあと思っています。 現職について 11月半ばくらいまでは転職はまったく考えていませんでした。が、その頃の世間の技術的な流れなどを見ていて、ちょっと技術的に異なることをやろうかなあ、と考えたのが直接的な理由です。今後どうするかを考えたとき、せっかくなら働く環境なども変えてしまった方がこれからの人生が刺激の多いものになりそうだということで、現職を退職することを決めました。 やりたいことを変えるだけなら社内でやればいいだろう、という話を会社側からはされましたし、もっともなことでもあるのですが、同時に前
Paxosアルゴリズム - Wikipedia
Paxosとは信頼性が低いプロセッサのネットワークにおいて合意の問題を解決するためのプロトコルの集合である。 合意とは参加者のグループにおいて単一の結果について合意を得るプロセスである。参加者や通信手法に障害が起きる可能性がある場合、この問題は困難なものとなる[1]。 合意プロトコルは分散コンピューティングにおける状態機械アプローチの基礎であり、これはレスリー・ランポート[2]により提案され、Fred Schneiderによってサーベイがなされている[3]。 Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年であった[4]。 これ以前に、ナンシー・リンチ、Cynthia Dwork、Larry Stockmeyerは"部分同期"システムの広い範囲における合意形成方法を例証している。Paxosは分散トランザクションの文脈において、1988年にOkiとBa
プログラミングの生産性を上げるには - 聞かれてもいないことを喋る
Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで
Home - Neovim
Features Extensible API is first-class: discoverable, versioned, documented. MessagePack structured communication enables extensions in any language. Remote plugins run as co-processes, safely and asynchronously. GUIs, IDEs, web browsers can --embed Neovim as an editor or script host. Lua plugins are easy to create just like Vimscript plugins. Your config can live in init.lua! AST-producing parsin
)
採用面接ゲリラガイド(version 3.0) - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年10月25日 水曜 無政府主義者とフリーラブの提唱者とバナナの権利の擁護者の寄せ集めの一団が、プエルト・バリャルタを出たラブボート号をハイジャックし、7日以内に要求が受け入れられなければ616人の乗客と327人の乗員もろとも、船を沈めると脅している。要求は何か? 番号を控えていない小額紙幣で100万ドルと、評価の高いWaterloo Fortran IVコンパイラ、WATFIVのGPL実装だ。(フリーラブの連中がバナナの権利の連中と合意できることがいかに少ないかは驚くばかりだ。) フェスティバルクルーズ社のプログラミングチームのチーフプログラマとして、あなたはFortranコンパイラを7日間でスクラッチから作れるか判断しなければならない。あなたには2人のプログラマがサポートにつく。 どうだ、できるか? 「条件によりますね」とあなたは答える
関東ITソフトウェア健康保険組合<ITS>
重要なお知らせ 2023.09.11 令和5年台風第13号に伴う災害により被災された皆様へ 2023.08.17 令和5年台風7号に伴う災害により被災された皆様へ 2023.08.10 令和5年7月7日からの大雨による災害により被災された皆様へ 新着情報 一覧 RSS 2023.12.12 【事業主様 事務担当者様】給付金送金のお知らせ等について 2023.11.27 軽装勤務（ノーネクタイ）の通年実施のお知らせ 2023.11.21 【Pep Up】体重測定チャレンジが12月1日よりスタート！ 2023.11.20 電話等通信機能復旧のお知らせ 2023.11.13 【事業主様 事務担当者様】給付金送金のお知らせ等について 2023.11.06 【適用一課】年収の壁・支援強化パッケージにおける取扱いについて 2023.11.06 令和5年度 健診実施要領更新のお知らせ 2023.11.0
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
街角のクリエイティブ