kakerukaeruのブックマーク (1,508)

  • Googleに入社して10年が経ちました - YAMAGUCHI::weblog

    はじめに こんにちは、Cloud Operations suite担当者です。2021年4月18日でちょうどGoogleに入社して10年が経ちました。自分は転職で入社したときのことは書いておらず、前職を退職したときの記録しか残っていませんでした。いい機会なので記録として10年間を振り返ってみようかなと思いました。自分用の振り返りで特に推敲もしておらず、読みづらいと思いますが、とりあえずそのまま出します。 Google入社のきっかけ 当時はPython関係のコミュニティ活動やアウトプットをしていて、ちょうどそのときにGoogleのPartner Solution Organization(いまの gTech という組織の前身)のTechnical Account Managerという職種で空きがあるので、受けてみませんかとメールが来たのがきっかけでした。当時はGoogleというとソフトウェア

    Googleに入社して10年が経ちました - YAMAGUCHI::weblog
  • 優秀さについて

    Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します|Lillian|note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が

    優秀さについて
  • Go言語でLet's EncryptのACMEを理解する

    Let’s Encrypt TL;DR Let’s EncryptのベースのプロトコルであるACMEを理解する. まずACMEをベースとしたCAであるboulderをローカルで動かす.次にACMEのGo言語クライアントライブラリであるericchiang/letsencrypt(非公式)を使い実際にboulderと喋りながら証明書発行を行い,コードとともにACMEが具体的にどのようなものなのかを追う. はじめに 証明書というのは面倒なもの,少なくともカジュアルなものではない,というイメージが強い.それは有料であることや自動化しにくいなどといったことに起因している(と思う).そのようなイメージに反して近年登場する最新の技術/プロトコルはTLSを前提にしているものが少なくない(e.g., HTTP2). このような背景の中で登場したのがLet’s Encryptと呼ばれるCAである.Let’s

  • オープンソースのベストプラクティスを企業内で実践/How to implement InnerSource

    Developers Summit 2021の「オープンソースのベストプラクティスを企業内で実践 ~インナーソースのすすめ」というセッションの発表資料です。 https://event.shoeisha.jp/devsumi/20210218/session/3044/

    オープンソースのベストプラクティスを企業内で実践/How to implement InnerSource
  • プライバシーを保護する Oblivious HTTP の仕様 (OHTTP) - ASnoKaze blog

    2024/02/13 に、下記記事を書き直しました! asnokaze.hatenablog.com =========== ユーザのトラッキングを防ぐ「Oblivious HTTP」という仕様が、Mozilla及びCloudFlareの方らの共著でIETFに提出されています。この仕様では、ユーザのIPアドレスを隠す仕組みを提供します。これによって、サーバが受信した複数のリクエストが同一ゆーざのものであるかわかりにくします。 先行して、CloudFlareは「Oblivious DoH」という仕組みを提案している。これはDNS over HTTPSのクライアントIPアドレスを隠蔽する仕組みである。その仕組をHTTPに適応したのがOblivious HTTPである。 blog.cloudflare.com Googleが別途提唱している「Privacy Sandbox」でも、IPアドレスはユ

    プライバシーを保護する Oblivious HTTP の仕様 (OHTTP) - ASnoKaze blog
  • Don't Panic: Kubernetes and Docker

    By Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas | Wednesday, December 02, 2020 Update: Kubernetes support for Docker via dockershim is now removed. For more information, read the removal FAQ. You can also discuss the deprecation via a dedicated GitHub issue. Kubernetes is deprecating

    Don't Panic: Kubernetes and Docker
    kakerukaeru
    kakerukaeru 2020/12/03
    モチツケ
  • メルペイ VPoE による2020年の振り返り | メルカリエンジニアリング

    こんにちはこんにちは。 Merpay Advent Calendar の1日目を、メルペイ VPoE の hidek がお届けします。 はじめに 2020年は世界的に激動の年ですが、早いもので12月を迎えてそろそろ終わろうとしています。ということで、Advent Calendar 1日目として、メルペイの2020年を振り返ろうと思います。 実は去年も同じお題で書いたのですが、毎年使い回せるネタをチョイスした去年の自分を抱きしめてあげたいと思います。では去年と同じく、なるべく赤裸々に淡々と書いていきたいと思います。 プロダクトのチャレンジ 2020年のメルペイのプロダクトにおけるチャレンジを振り返ってみます。 前年である2019年は、2月にメルペイの最初のローンチを迎えてからiD 決済、QR・バーコード決済、「メルペイスマート払い」による後払い機能、ネット決済機能、と決済プロダクトしての基

    メルペイ VPoE による2020年の振り返り | メルカリエンジニアリング
  • Chrome への HTTP/3 と IETF QUIC の導入について

    .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

    Chrome への HTTP/3 と IETF QUIC の導入について
  • 「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)

    単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり1つや2つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え?そうなんですか?結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

    「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
  • noteでソースコードからIPアドレスが確認できた事態に関する追加報告とお詫び|note株式会社

    8月14日にご報告しました、note株式会社(以下、「当社」)が運営するメディアプラットフォームnoteにおいて、記事投稿者のIPアドレスが記事詳細ページのソースコードから確認できた事態(以下、「件」)について、note利用者のみなさま、noteのサービスに関わるみなさまに多大なるご迷惑とご心配をおかけしましたこと、改めて心よりお詫び申しあげます。 件発生後、最優先で原因を究明し、件への対応を実施しました。 その後、経営陣直轄の特別対策チームを編成し、1カ月半にわたり徹底した安全対策を実施。今回は、その対応および件を受けた安全性確保のための施策と、再発防止策についてご報告いたします。 1.件の概要と原因2020年8月14日6:14 利用者の方から「noteの記事詳細ページのソースコードからIPアドレスが確認できる」旨のお問い合わせを頂く (現象自体は2019年4月11日から発生)

    noteでソースコードからIPアドレスが確認できた事態に関する追加報告とお詫び|note株式会社
  • 日本初完全オンラインで、AWS GameDayを開催しました!

    はじめまして、技術部SRGでOREをしている柘植(@shotaTsuge)です。 普段はボッチの社会人学生をしながら、社内の至る場所でWell-Architectedを謳い、導入するお仕事をしています。 Well-Architectedの言い過ぎでこの前顎関節症にまでなりましたが、継続は力なりでAWS Well-Architectedの公式サイトに載せてもらうまで行きました。 ちなみに、推しのFive Pillarsは Operational Excellence Pillarです。 記事は、先月8月に、AWS GameDayをサイバーエージェントグループ企業向けに特別開催した内容のレポートになります。 開催レポートではありますが、AWS GameDayの競技内容については、触れません。(今後の参加者が楽しめるように、書くことができないため) 今回のイベントでは、グループ企業15社、総

    日本初完全オンラインで、AWS GameDayを開催しました!
    kakerukaeru
    kakerukaeru 2020/09/03
    ダブルスコアを付けられた2位が僕です。GameDay自体はとっても楽しかったです、ありがとうございました。 /  “最終的には1位のチームが2位のチームに対してほぼダブルスコアでの優勝となりました。”
  • RFC 8890 - The Internet is for End Users

    Hi, I’m Mark Nottingham. I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal blog, it does not represent anyone else. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other Standards posts There Are No Standards Police Wednesday, 13 March 2024 RFC 9518 - What Can Internet Standards Do About Centralisation? Tuesday, 19 December 202

    RFC 8890 - The Internet is for End Users
  • Changing World, Changing Mozilla | The Mozilla Blog

    This is a time of change for the internet and for Mozilla. From combatting a lethal virus and battling systemic racism to protecting individual privacy — one thing is clear: an open and accessible internet is essential to the fight. Mozilla exists so the internet can help the world collectively meet the range of challenges a moment like this presents. Firefox is a part of this. But we know we also

    Changing World, Changing Mozilla | The Mozilla Blog
  • Public DNS:CDNへの影響 | www.kosho.org

    Public DNS(1.1.1.1や8.8.8.8)を使うと、CDNが遅くなる(海外のサーバを割り振られる)と言われています。しかし、実際にはその影響は限定的です(国内ではほぼない)。今回は、その詳細をまとめます。 CDNのリクエストナビゲーション 昔はCDNのリクエストナビゲーションというとDNSによる名前解決を利用したものが主流でしたが、現在は、エニキャストが増加しています、またトラフィック発生源となっているメジャーな動画系サービスは、リクエストナビゲーションにURL生成を使っているなど、昔とは状況が変わっています。まず、それぞれのナビゲーション方法について、現状を見ていきます(細かな所は次回のBoFでお話します): エニキャスト概要同じIPアドレスを複数のBGP経路で使うPublic DNSの影響受けませんCDNサーバのIPアドレスは、国・地域によらず同じです使用会社新興系CDN事

    Public DNS:CDNへの影響 | www.kosho.org
  • HTTP Status Codes Decision Diagram - Infographic | Loggly

    With Hypertext Transfer Protocol aka HTTP status codes, the first digit of the code indicates one of five classes of responses. HTTP clients must at least recognize these five classes: The first class of codes is informational, indicating a provisional response while processing continues. The second class of status codes communicates that the client’s request was received and processed successfull

    HTTP Status Codes Decision Diagram - Infographic | Loggly
  • 社内勉強会で専門的技術力を高めるには

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯(ヤフー内のスキル任命制度/ネットワーク・セキュリティ)に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書

    社内勉強会で専門的技術力を高めるには
  • Service worker caching and HTTP caching  |  Articles  |  web.dev

    Service worker caching and HTTP caching Stay organized with collections Save and categorize content based on your preferences. The pros and cons of using consistent or different expiry logic across the service worker cache and HTTP cache layers. While service workers and PWAs are becoming standards of modern web applications, resource caching has become more complex than ever. This article covers

  • どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング

    Platform チームの@deeeeeeeetです. Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです.Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています.立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました. チームのメンバーが増えるほど1チームとして動くには限界がきており,またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました.これらの課題を解決するために組織変更を行い,Platform チームを複数の専門性に特化したチームに分割しました. 記事ではチームのデザイン,チームが分離しても独立性を保ちつつ

    どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
  • TCPが遅すぎる?QUICを使おう!

    「それ、QUIC使えないの?」 それがなんであれ、QUICを使うことを主張することで、みんなが「なんか良くわからないけど、TCPを置き換えたほうがいいのかな?」と思うようになるはず。全てのアプリケーションを、TCPの代わりにQUICを使うように修正するとなれば、この先10年間ぐらい、エンジニアみんなの仕事を作ることができます。業界愛ですね。 すでに、SSHやDNSのQUIC対応は始められています。既存のアプリケーションをQUICに対応させる難しさを調査するために、RustでBGP over QUICを実装してみました。 QUICの実装QUICは、TCPと同じく、パケットの再送、輻輳制御など、信頼性のある通信を実現するトランスポートプロトコルです。実装面の大きな違いは、TCPがオペレーティングシステムのプロトコルスタックの一機能として実装されるのに対して、QUICはアプリケーションで実装され

    TCPが遅すぎる?QUICを使おう!
  • QUICむけにAES-GCM実装を最適化した話 (1/2)

    4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC