Bazelの解説（TS, Dockerイメージ、リモートキャッシュ）
Bazelは大規模なプロジェクトでも高速にビルドすることができる強力なビルドツールとして知られています。一方で、その仕組みや実際に使用する方法についての紹介されることは少なく、まだまだあまり普及していないと思います。特にNode.js/TypeScriptをBazelでビルドする方法についての解説はかなり珍しいと思います。 この本ではBazelによるビルドがなぜ高速なのか基本的な原理の説明から、実際に自分が作成したサンプルコードを使用してTypeScriptプロジェクトのビルド、Dockerイメージの作成までのコードを解説をし、最後のBazelの大きな特徴であるリモートキャッシュを実際に使う方法まで紹介します。 ぜひhttps://github.com/Kesin11/bazel-playgroundを手元にcloneして頂き、実際に動かしながらBazelによるビルドを体験してみてください
Ruby on RailsのGPL汚染まとめ（mimemagicの件） - 大根's ＩＴブログ
("汚染"という言葉をあまり良く思わない方もいると後から知りました。たしかにその通りだと思います。次から気を付けようと思いますが、とりあえず本記事ではそのまま"汚染"の表現を使います。ご了承ください。) 2021年の3月、突如としてRailsのGPL汚染の話題がネット上を駆け巡りました。 リチャードストールマンがFSFへの復帰を発表した途端にこんなことが起きるなんて…。 偶然にしてはすごいタイミングですね。 GitHub Enterpriseのコードが公開されるの？と盛り上がっておりますが、果たしてどうなりますでしょうか。 さて今回は本件についてまとめていきます。技術者だけでなく法務や知財の目線でも分かるように書いていこうかと思います。 ★私は法律の専門家ではありません。この記事に法的根拠はありませんので何かあっても責任は取れません。ご理解ください。 概要（経緯） 概要はこのissueのや
Spotifyが開発者ポータル「Backstage」をオープンソース化
Spotifyは2020年3月16日（米国時間）、社内向けに開発し、活用してきた開発者向けポータル構築プラットフォーム、「Backstage」をオープンソース化したと発表した。 Spotifyは2020年3月16日（米国時間）、社内向けに開発し、活用してきた開発者向けポータル構築プラットフォーム、「Backstage」をオープンソース化したと発表した。 Backstageでは、さまざまなインフラ関連ツール／サービス、ドキュメントを単一のポータルにまとめ、分かりやすく表示する。エンジニアは自身の作業に適したツールを容易に見つけることができ、一貫したユーザーインタフェースで利用できる。これにより、開発者はツールの利用に費やす時間や労力を減らし、アプリケーションの構築に集中できるという。 同ツールの背景として、Spotifyはオープンソースソフトウェア（OSS）のインフラ関連ツールが爆発的に増加
Cloud Spanner のロックについて
この記事では Cloud Spanner の並行性制御が何であるのか、結果として何を実現しているのかを見てから具体的なロックの実際の挙動について追っていく。 なお分散システムとしての話はあまりないので期待しないように。 この記事では実際の挙動を確認しながら書いているつもりだが、 2021年3月現在の挙動がサイレントに変わることもあることには注意してほしい。 TL;DR Cloud Spanner はロックフリーな Read-Only Transction と、堅実にロックを行う Read-Write Transaction の2つのアクセスパスを持ち、 ROMV と呼ばれる方式に最も近い。 その他技術との組み合わせの結果として分散システムでありながら Serializability と Linearizability を兼ね揃えた理論上最も強い一貫性を実現しており、 Google はそれを
ぼくのかんがえるKubernetes(EKS)のツラミと理想のターゲット
Kubernetes（EKS）を業務で使い始めてほんの少し感覚が掴めてきました。いわゆる ダイニング=クルーガー効果 で言うところの カンゼンニリカイシタ！ というやつですね。 Kubernetes(EKS)はすごく強力な技術なのですがやはりツラミもあります。今回は触ってみて感じたツラミをまとめました。 技術導入を検討されている方への参考になれば幸いです。 前提 記事の内容は完全に私個人の意見です。 ここの記事で記載している Kubernetes とは主にAWSのEKS(またはその他のマネージド・サービスでのKubernetes)であり、自前運用の素のKubernetesのことではありません。 自前でKubernetesをまるっと管理する場合にはここで書いてあること以上のツラミが出てくると思います...。 ネガティブなポイントを多く記載していますが、これはEKSをディスりたいための記事では
PFN の ML/DL 基盤を支える Kubernetes における自動化 - DevOpsDays Tokyo 2021
location_city Tokyo schedule Apr 16th 02:00 - 02:45 PM JST place Hall A people 10 Interested Preferred Networks（PFN）は深層学習などの最先端の技術を最短路で実用化することで、これまで解決が困難であった現実世界の課題解決を目指しています。コンピュータビジョン、自然言語処理、音声認識、ロボティクス、コンパイラ、分散処理、専用ハードウェア、バイオインフォマティクス、ケモインフォマティクスといった幅広い分野で研究開発を行っており、それを支えているのが Kubernetes を用いて構築しているオンプレミス/ベアメタルの GPU クラスタです。 本セッションでは、PFN が Kubernetes を用いてクラスタを運用するなかでどのような障害が起きるのかを紹介し、また障害対応をどのように
AWS Startup Tech Meetup #3: かんたんコンテナロギング選手権
コンテナでログをどう取得すればいいの？そもそもどういうログがあるのか？ ログの取得パターンから活用方法まで、 @prog893 が選定のためのヒントとサンプルアーキテクチャで紹介します。
フロントエンドとオブジェクト指向
フロントエンドの実装にオブジェクト指向をどのように取り入れるかを考えます。 動機 近年のフロントエンドは、Reactなどのフレームワークを使ったコンポーネントベースの設計が主流だと思います。コンポーネントは、HTMLによるマークアップ、CSSによるスタイリング、JavaScriptによる振る舞いがひとまとめにされた、再利用可能な部品です。 コンポーネントの設計を考えていると、次のような疑問が生じます。 何を基準にコンポーネントで分割すればよいか。 コンポーネントの粒度はどれくらいが適切なのか。 どのタイミングで抽象化すれば開発コストが無駄にならないか。 分業した際にコンポーネントの分割や粒度の基準をどのように統一するべきか。 そこで、いろいろ調べたり試したりしたところ、フロントエンドの設計にオブジェクト指向を取り入れることが、これらの答えの一つになるのではないかと考えました。 この記事では
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
