深層学習のための分散キャッシュシステム - Preferred Networks Research & Development
エンジニアの上野です。Cluster Servicesチームという、PFNのKubernetesベースの機械学習基盤を開発・運用するチームに所属して、基盤の改善や新機能の開発に務めています。本記事では、深層学習における学習データセット読み込み速度の改善を目指して開発し、現在もKubernetes上で運用中の分散キャッシュシステムを紹介します。 PFNの機械学習基盤については、ブログ「2022年のPFNの機械学習基盤」もご参照ください。 深層学習における学習データセット読み込み 深層学習を高速化するため、深層学習に向いたアクセラレータの開発が日々続けられています。PFNで開発しているMN-Coreシリーズや、NVIDIA社製GPUもそのひとつです。これらのアクセラレータは高速に行列演算を行うことができ、深層学習の1イテレーションにかかる時間を高速化、ひいては深層学習を活用する研究開発全体を加
3rd-party JavaScript のリスク対策に CSP（Content Security Policy）を活用する
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、プラットフォームエンジニアの中山です。 Web サイトにはしばしば 3rd-party JavaScript を導入することがあります。たとえば Web 解析ツール、いいねボタンのような SNS 連携機能、広告掲載や効果測定目的のコードスニペットなどは多くの Web サイトで導入されています。 その一方で 3rd-party JavaScript は Web サイトを閲覧するユーザーに対して悪影響を及ぼしかねないため、導入とあわせたリスク対策も必要となります。 そこで、今回は Content Security Policy（以降 CSP）を活用した 3rd-party JavaScript のリスク対策について、ヤフー
Gorilla, the golang web toolkit
Project Status Update - Jul 17, 2023We were going to wait until the transition was complete to make an announcement, but it seems that the cat is out of the bag… We are excited to confirm that the Gorilla web toolkit project has a new group of Core Maintainers! We are all thrilled by the positive response from the community so far. Here is a list of what we are currently working on to complete the
research!rsc: Coroutines for Go
This post is about why we need a coroutine package for Go, and what it would look like. But first, what are coroutines? Every programmer today is familiar with function calls (subroutines): F calls G, which stops F and runs G. G does its work, potentially calling and waiting for other functions, and eventually returns. When G returns, G is gone and F continues running. In this pattern, only one fu
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
このブログがFediverseに対応しました
Twitter が日々壊れゆくなか、周りの人が Misskey や Mastodon や Threads に住居を移すようになりました。 私も移住先を検討してみたものの、移住先のプラットフォームだっていつまで持つか分からないし、複数のプラットフォームにアウトプットを分散させるのも良くないなぁと思い、 最終的にマイクロブログがだめならブログでいいじゃんと自分を納得させるに至りました。 せっかくなら ActivityPub に対応して、Fediverse の人からリモートフォローできるようにして、反応が見れたら嬉しいよねということで色々と調べて対応させることができました。 本ブログは「@blog.tyage.net@blog.tyage.net」でリモートフォローすることが可能です。 このブログは hugo で生成しており、静的ファイルのみ配信しています。 それは変えたくなかったため、Acti
『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Magnolia Tech
ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには 作者:Tomasz Lelek,Jon SkeetオライリージャパンAmazon ソフトウェア開発経験の最初の段階で「一つの機能には複数の選択肢が有って、メリット・デメリットがそれぞれ有り、それらはトレードオフの関係に有り、容易には決めることができない」という事実を教えてもらえる機会に遭遇できていれば、その人はとても幸運だと思う。 先輩や上司が一方的に、「一つの確かな方法」をただ伝える、みたいな場面（それが必ずしも一般的にはそうとは言えない方法であったとしても）も多いのではないでしょうか。 どんなに設計上の意思決定ができている人でも、その頭の中では「色々な選択肢の中で悩んで、ベストではないかもしれないけど、前の前の課題に対してよりベターな方法」を選んでいる。でもその思考の過程を見せてくれる人はとても少ない。
Basic認証、Digest認証、Bearer認証、OAuth認証方式について - プログラミング初心者がアーキテクトっぽく語る
Basic認証、Digest認証、Bearer認証、OAuth認証方式はRFCで標準化されている認証方式の中で最もよく目にする方式だろう。 Basic認証とDigest認証は多くのサーバ、クライントで実装されており導入障壁が低い認証方式だ。 機密性の高いデータを扱うサービスでは比較的安全なBearer認証、OAuth認証方式を目にすることが多い。 ここではBasic認証、Digest認証、Bearer認証、OAuth認証方式について簡単に触れる。 この4つの概要を理解しておけば大体のWebサービスは理解できるだろう。 もしサービスが固有の認証方式を実装していた場合でもこれらの方式との類似性に着目すればすぐに理解できるはずだ。SAMLやOpenIDと言ったより複雑な認証方式を理解する上でも助けになると考える。 1. Basic認証方式 最も理解しやすいのがBasic認証方式だ。RFC 261
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
