（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三

ペパボ研究所 研究員／プリンシパルエンジニアの三宅(@monochromegane)です。 ペパボ研究所では、新卒のエンジニア研修の一環として、2020年7月13日から5日間に渡って機械学習入門の研修を担当しました。 本エントリでは、研修内容をスライドと共に紹介します。 GMOペパボの新卒エンジニア研修における機械学習研修の位置付け GMOペパボの新卒エンジニア研修は、5月のGMOインターネットグループでの合同研修プログラム（GMO Tech Bootcamp）と、6〜7月のGMOペパボでの研修プログラムから構成されています。 6月以降の研修では、Webアプリケーション、フロントエンド、セキュリティ、コンテナとデプロイなど様々な技術要素についてプログラムが組まれており、今年から機械学習研修がこれに連なることになりました。 VP of Engineering 兼技術部長の @hsbt の言葉

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

こんにちは。mattn（@mattn_jp）です。一部の方はご存じかもしれませんが、僕は普段あまり皆さんの前に登場することはありません。どちらかというとお堅いSI業で仕事をしています。社会人になってから今まで一度も、Web業界と呼ばれるB2C（Business to Customer）な職種に転職したこともありません。 ですが、今ではOSS（オープンソースソフトウェア）を通して、多くのエンジニアと友達になり、カンファレンス等で何度かお話しする機会をいただくまでになりました。この記事では、OSSに縁遠いはずの僕が、いかにしてOSSと出会い、そして多くの方たちと知り合うチャンスを得たのかをご紹介したいと思います。 オープンソースとの出会いはVim 日本のVimコミュニティを作る VimConfで作者Bram Moolenaarと握手 Vimから得られたチャンスや出会い GoコミュニティからGo

こんにちは！メルカン編集部のnatukifmです。 2020年6月23日、メルカリでは、全社的なコミュニケーションツールとして導入しているSlackの社内利用ガイドラインをGitHubにて公開しました〜！ Slack上での情報共有や連絡を円滑にするため、2016年につくられた本ガイドライン。細かな改定を重ねられてきたものの、2016年当時からほぼ変わっていなかったりします。 そこで本日の#メルカリな日々では、社外公開したばかりのメルカリ社内Slack利用ガイドラインをちらっとご紹介します！ Slackを使ううえでの前提 1：オープンであることを意識する ・ プライベートメッセージやプライベートチャンネルの利用は禁止しないが、人事・インサイダー情報以外は、コミュニケーションコストの低減と、風通しが良くオープンである社風を維持するために基本的にオープンにする ・ チャンネルへのinvite/l

ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝

データ視覚化やダッシュボードデザインは文字通り「視覚化」「デザイン」というくらいですので、目に見えているところだけを語られがちです。しかし、実は最も重要なのは徹底したオーディエンス（ユーザー）主義の意識、そして質の高い問いの設定です。なぜなら、オーディエンスは、つまらないと感じたり、わからないと感じるとすぐに離脱するからです。これはとても単純で当たり前とも言えるのですが、データ視覚化に夢中になっていると忘れがちなポイントです。 下図は、ダッシュボードに表れるものとその根底に潜む要素を模したものです。データ視覚化の深層部分はこのような氷山で説明できるのではと考えています。 上側半分はよく語られがちですが、下側は見過ごされがちです。ですので、本記事では、上側から下側まで一気通貫のチェックリストを紹介します。弊社では、プロジェクトの開始時から最後まで考えていることです。これらの要素は相互に影響し

最近のWebサイトで見かける、ページのレイアウトをはじめ、ナビゲーション、フォームのさまざまな入力要素、インタラクション要素、UI要素などのCSSでの実装コードをまとめたCSS Layoutを紹介します。 すべてシンプルなコードで実装されており、外部ファイルやフレームワークは一切必要ないので、簡単に利用できます。 ブックマークや、スニペットに登録しておくと便利ですね。 CSS Layout CSS Layout -GitHub CSS Layoutの特徴 CSS Layoutの使い方 CSS LayoutのレイアウトやUI要素91種類 CSS Layoutの特徴 CSS Layoutは、CSSで作成された一般的なレイアウトとパターンのコレクションです。 依存は一切なし フレームワークも必要なし CSSハックもなし すべて実際の使用例 MITライセンスで、商用プロジェクトでも無料で利用できま

スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG　大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン

フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR

電子情報学特論： Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *

新型コロナウイルス対策として様々な企業で在宅勤務が推奨される中、VPNに関する発言を耳にする機会が増えた。「大勢が使い始めたので速度が落ちた」「社内からの利用申請が急増した」といった恨み言が中心だが、興味深いものもあった。なんでも「グーグルはテレワークにVPNを使っていない」のだという。 米グーグルは従業員が在宅勤務をする際にVPNを一切使っていない。インターネット経由で利用できるSaaS（ソフトウエア・アズ・ア・サービス）の「G Suite」などで業務が完結するから、といった単純な話ではない。開発システムや経理システムといったあらゆる種類の社内アプリケーションが全てインターネット経由で利用できるようになっているため、従業員はそもそもVPNを利用する必要がないのだという。 同社はこうした社内事情を「BeyondCorp」という取り組みとしてWebサイトや論文で公開している。さらに2017年

はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op

ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも