Unix System Monitoring and Diagnostic CLI Tools - HedgeDocAn opinionated list of CLI utilities for monitoring and inspecting Linux/BSD systems (Ubuntu/Debian, FreeBSD, macOS, etc.). Includes install instructions, examples, docs, and source code links.
COVID-19 感染予測 (日本版) の公開について | Google Cloud 公式ブログ
Google Cloud は今年 8 月に Harvard Global Health Institute とのパートナーシップのもとで COVID-19 Public Forecasts を公開しました。このサービスは予測開始日から将来 14 日間における米国内の COVID-19（新型コロナウイルス感染症）陽性者数や死亡者数などの予測を提供しています。この度、本サービスを日本にも拡張し、COVID-19 感染予測（日本版）の提供を開始します。日本版では予測開始日から将来 28 日間のあいだに予測される国内の陽性者数や死亡者数等の予測値を表示します。 米国で提供している COVID-19 Public Forecasts は AI と膨大な疫学的データを組み合わせ、さらに、時系列の予測を扱う斬新な機械学習のアプローチを採用することで実現しました。米国向けのこの初期モデルは今年 8 月に初
AWS Lambdaのデプロイパッケージをどの範囲で構築すべきか | DevelopersIO
はじめに おはようございます、加藤です。AWSで本格的なサーバーレス開発を行う際につまづいたり、悩むポイントとしてLambdaのデプロイパッケージをどのような範囲にすべきかということがあります。デプロイパッケージをどうすべきか私の考えをまとめてみました。 何回か出てくるディレクトリ図については、あくまでをイメージを掴んで貰うためのもので、この通りにディレクトリを構成し動くことを保証するものではありません。具体的なAWS CDKを使った構築方法は来月ぐらいにでも別途ブログにする予定です。 デプロイパッケージとは デプロイパッケージは、関数のコードと依存関係を含むZIPアーカイブです。コンパイル言語（Go、Javaなど）の場合はコンパイル済み関数のコードを含む必要があります。非コンパイル言語かつ、デプロイパッケージの容量が3MB以下の場合はマネジメントコンソールでデプロイされた関数コードを確認
GitHub、削除した「youtube-dl」は著作権を侵害していなかったとして復元
米Microsoft傘下のGitHubは11月16日（現地時間）、全米レコード協会（RIAA）からの申請を受けて10月に削除した「youtube-dl」関連のリポジトリを復元したと発表した。RIAAの主張は無効だと判断したとし、公式ブログで判断の経緯や削除ポリシーの改善について説明した。 RIAAの主張は、これらのリポジトリが提供しているyoutube-dlソースコードが、YouTubeなどが著作権のあるコンテンツを保護するために採用している技術（TPM）を回避するよう設計されており、これがデジタルミレニアム著作権法（DMCA）の第1201条に抵触するというものだった。 だが、GitHubは「著作権で保護された作品にアクセスするためにコードを使用できるからといって、著作権を侵害しない方法で作品にアクセスするためにコードを使用できないわけではなく」、youtube-dlは法律に違反せずに著作
レガシーシステムをDocker環境へ移行させた話
はじめに初めまして、FinatextグループのK-ZONEチームでインターンをしている松永と申します． 現在インターンではバーチャル株投資ゲームの「トレダビ」の改善を行っています． トレダビを長く運用し続けてきた弊社ですが、長年の運用から技術的負債が溜まっていました． その中の一つに、トレダビのローカルの開発環境でゲーミフィケーションサーバ(トレダビにおいてゲーム的な要素を担当するサーバ)がDocker上で動いておらず、ローカルで開発を進める際に特定の画面の確認ができないという問題がありました． この問題をどのように解決したかについて紹介します． トレダビの開発環境についてトレダビはRuby on Rails + MySQL + Java(ゲーミフィケーションサーバ)で運用されており、AWSの開発環境では以下のような構成で動作しています． しかし、トレダビのローカルの開発環境ではゲーミフィ
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
ECSのScheduled Taskを管理するツールを作った | おそらくはそれさえも平凡な日々
その名もecschedule。だいぶ前から作っていたのだが、この度実戦投入した。 https://github.com/Songmu/ecschedule Nature社では、ECS上でGoのサービスを動かしており、バッチ系の定期実行タスクもECS Scheduled Taskを利用している。 最近バッチの本数が増えてきて管理したくなり、このツールを導入しました。 便利だとは思うが、かなり社内事情にべったりであるため、フィードバック歓迎です。具体的には以下の制約を前提としています。 Rule名がユニークであること RuleにはTargetが1つだけ紐付いており、TaskのContainer Overridesでタスクを実行している ecspressoにかなり影響を受けており、ECS Scheduled Task用のecspressoのような作りになっています。 インストール % brew
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MacにおけるSIGSEGV/SIGBUS/SIGILL - Qiita
O'Reillyサブスクリプション和書まとめ - kawasima
セキチク | 委託先のセキュリティチェックをクラウドで一元管理
GitHub - aws-amplify-jp/awesome-aws-amplify-ja: 日本語で書かれているAWS Amplifyのツール、チュートリアル、記事などのリンク集