ソフトウェア開発の礎となる知識体系の基盤「SWEBOK」とは？ 最新第4版の内容と開発現場での活用法
真のエンジニアリングには「定量化＆定性化」が不可欠 「『エンジニアリング』してますか？」という参加者への問いかけからスタートした鷲崎氏の講演。同氏によれば、エンジニアリングの辞書的な定義は「科学に裏打ちされた技術活動・学問体系」とされており、ソフトウェアの開発運用を行う際にこの定義を満たしていれば、きちんと「エンジニアリングを行っている」と表現できる。 ただしSWEBOKにおいては、ソフトウェアエンジニアリングを「ソフトウェアの開発運用保守に対する体系的、規律的、定量的なアプローチの適用」としている。この定義に則れば、個々の技術者の直感、すなわちそれぞれが良かれと思うスタイルで開発を行うカウボーイコーディングは、ソフトウェアエンジニアリングではないことになる。 加えて、鷲崎氏はソフトウェアエンジニアリングを「定量的であることが望ましい」とする。定性的な部分はもちろん、品質の測定評価や顧客満
Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
アプリケーション開発者はどこまで知っているべきなのか？ 前提知識整理のための、コンテナワークロード超入門
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。まずは、コンテナワークロード超入門として、コンテナのデプロイ時とクラッシュ時に起こることを紹介します。全3回。 自己紹介 原トリ氏：オーナーシップの塊、トリです。本日はタイトルにあるとおり、アプリケーション開発者はAmazon ECSあるいはKubernetesといったコンテナオーケストレータのことを、どこまで知るべきかについて話します。もともと「どこまで知ればいいのか」というタイトルでしたが、思いが強すぎて「知るべきか」に変わりました。 あらためて
入門監視やSRE本に学ぶ障害対応フォーメーション - An Epicurean
システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に
20年間ソフトウェアエンジニアとして働いて学んだ20個のことまとめ
By Sergey Galyonkin ソフトウェア開発企業・Simple Threadの創設者であるジャスティン・エセリッジ氏が、ソフトウェアエンジニアとして20年活動した経験を基に、学習において重要なポイントやコーディングにおいて意識するべきポイントなどを20個にまとめて公開しています。 20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/ ◆1：自分がまだ多くを知らないことを自覚する エセリッジ氏は、たとえ何十年間ソフトウェアエンジニアとして働いたとしても、それぞれのエンジニアが持つ知識には違いがあり、他のソ
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
「エーペックス」の仕組み:開発者によるサーバーとネットコードの解説
これは、とある「エーペックス」のプロプレイヤーのネットワーク経路（レイテンシーを表示しています）です。彼のインターネットモデムから、私たちのサーバーへと到達しています。インターネット接続の本当の状態を判断するため、私たちは何度も調査を行います。最善の状態であれば、彼は31msのレイテンシーでゲームを楽しめていることが見て取れますね。ですが最悪の場合だと、522ms付近です。つまりこの場合だと、接続に500msもの振れ幅があるため、ゲームの遊び心地はかなり悪いということです。彼のローカルISPネットワークの接続は不安定ですが、平均を見てみると非常に稀なケースであることがわかります（平均が31mで、最低値が264ms。たまたま起きたのでしょう）。しかしその後、ローカルのISPとISP1の間でレイテンシーが急増しています。これはプレイヤーとゲームサーバーの間のノードの一つです。この二つの間でパケ
チームで運用と戦い、おいしい牛カツと出会った話 | メルカリエンジニアリング
Merpay Advent Calendar 2020 の 9 日目は、バックエンドエンジニアの @sou がお送りします。 今日は少し泥臭く、この一年チームを成長させながら運用と戦ってきた話を書こうと思います。 私の所属するチームは加盟店情報の管理を担っており、その性格から運用に伴う作業が数多く発生します。 どんなプロダクトにも運用はあると思いますが、このチームが直面した運用の負荷はそのボリュームと複雑さから、私のキャリアの中でも最大と言えるものでした。 その運用に私たちがどのように立ち向かい改善を行ってきたか、みなさまの参考になれば嬉しく思います。 なぜそんなしんどい運用を頑張っているのか、メルペイでのやりがいや楽しさ、頑張った結果の美味しい牛カツと日本酒のお店に出会えた話も添えさせていただければと思います。 ここで言う運用とは、事業を進めていく上でさまざまな場面で発生する、自チーム以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
