はてなブックマーク

GitHub Actions で同じビルドやテストを何度も実行しない方法を紹介します。 ホストランナーを ubuntu-linux にした場合、実行する必要のないジョブは 10 秒程度でスキップ可能です。 注意 この記事は自作の OSS ツール sver および私が現在所属するサイボウス社の グローバル向けAWS版kintone開発チーム の宣伝が含まれます。 Summary ビルドやテストといった CI のジョブに再現性がある場合は複数回実行しても意味がない ジョブが依存する環境やソースコードを元にハッシュ値を計算することで同等なジョブに一意なラベルをつけられる ジョブ実行後に実行済みラベルを artifact として保存しておくことで後続の同等なジョブをスキップできる 効果 最初に効果を示します。 sver というプロジェクトのジョブの実行結果です。 これは通常時のジョブの実行時間です

良い本がある コンピュータシステムの理論と実装という良い本がある。 コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方 作者: Noam Nisan,Shimon Schocken,斎藤康毅出版社/メーカー: オライリージャパン発売日: 2015/03/25メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る nand と flip-flap だけが最初に与えられた素子として、それをもとに加算器やメモリを組み立ててコンピューターを組み立てる。 そして、そのコンピューター上で動くテトリスというコンピュータゲームを開発するというものだ。（実は最後はテトリスではないが） 本書の前書き曰く、ハードウェア、アーキテクチャ、オペレーティングシステム、プログラミング言語、コンパイラ、データ構造とアルゴリズム、ソフトウェアエンジニアリングという、コンピュータサイエンスの基

SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者（ここではテナントと呼ぶ）が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少

バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、

バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ