はてなブックマーク

GitHub Actions の timeout-minutes を明示的に指定しなかったことで minute quota 溶かしをやらかしたので作りました。 背景 パブリックなリポジトリで GitHub Actions を使っていると出くわすことはないかと思われますが、プライベートなリポジトリで GitHub Actions を書いていると timeout-minutes を指定し損ねたジョブが延々と走り続けて minute quota (Team plan だと 3,000 分/月) を浪費してしまう 😭 みたいなとても悲しいできごとが発生することがまれにあります。 それというのも、timeout-minutes を指定しなかった場合のデフォルトのタイムアウトが 360 分 (すなわち 6 時間) という長大な値となっているがために、下手こいて終わらないジョブを 9 回走らせてしまう

Gradle で管理されている Spring Boot アプリケーションのバージョン情報などをアプリケーションコードから動的に参照できるようにするためのメモです。 ビルド情報を Spring Boot アプリケーションに埋め込む 具体的にやるべきことは リファレンス にも書かれているとおり、以下の 2 つだけです。 Spring Boot Gradle Plugin を利用する build.gradle ファイルに以下を記述する 試しに、上記設定を記述した状態で ./gradlew bootBuildInfo を実行すると、build/resources/main/META-INF ディレクトリ配下に以下のような、バージョン番号などビルドされる (された) アーティファクトに関わる内容の build-info.properties ファイルが生成されます。 build.artifact=s

一般公募の枠で CfP 出してあえなくリジェクトされたテーマを、スポンサー枠で勝手に敗者復活させてお話してきました。 はじめにPermalink Java 標準のクラスライブラリには、いくつかの乱数生成器の実装 (クラス) が存在しています。長年 Java でアプリケーションを書いている方であれば状況に応じてそれらの実装を使い分けることも難しい話ではありませんが、Java を扱い初めて間もない方にとってはそう簡単な話ではありません。 たとえば java 乱数 のようなクエリでググるとその状況がうかがい知れるのですが、巷にはプログラミングスクール各社の SEO を目的としたコンテンツが溢れていて、それらはいずれも「java.util.Random とか Math.random() とかなんでそんなレガシーなクラス/メソッドしか紹介しないの？ この記事を書いたライターというかエンジニアの人たち

Debian をベースイメージとする Docker イメージは JDK に留まらず、JRE のみのイメージや slim パッケージのイメージも提供されています。いずれにおいても、Debian がビルドした JDK/JRE を利用しています。 Oracle Linux をベースイメージとする Docker イメージには、Oracle がビルドした OpenJDK が含まれています。当然のことながら、この OpenJDK のビルドは LTS ではありません。また、JRE のみの Docker イメージは用意されていません。 Windows はよくわからないのと興味がないのでパス、です。 なお early access の Java 12 以降になるのですが、Alpine Linux をベースイメージとする Docker イメージ が提供されるようです。この Docker イメージには Orac

Google Kubernetes Engine (GKE) 上で稼動させている Java アプリケーションのログをいい感じに Stackdriver Logging で閲覧できるようにするメモです。 TL; DRPermalink REST API を直接叩くのはライブラリ由来のハングアップ問題に遭遇しかねないので避けた方がいいよ アプリケーションからのログは JSON フォーマットで出力するといいよ ログレベルを表すフィールドは "severity" の名前で出力しよう タイムスタンプは "timestampMillis" と "timestampNanos" をセットで出力しよう Spring Boot アプリケーションなら spring-cloud-gcp-starter-logging を使うのがいいよ はじめにPermalink GKE を利用してコンテナ化されたアプリケーショ

盲目的に --add-modules の JVM オプションで解消するのはやめて、Java 11 に備えてちゃんとした対処をしてみよう、というお話です。 Java 9 のモジュールシステムと deprecated なモジュールによる問題Permalink Java 9 ではモジュールシステムの導入と同時に、Java の標準クラスライブラリを構成するモジュールのうち Java 11 で削除される予定のモジュール (JEP 320) が deprecated となりました。具体的には同 JEP に記載されているとおり、以下の 6 つのモジュールが削除予定となっています。 java.xml.ws: JAX-WS (Java API for XML-Based Web Services) java.xml.bind: JAXB (Java Architecture for XML Binding

※ 発表で使用したスライドより、本質的ではないスライドは省いています。 振り返りPermalink CfP を投げるときに何を血迷ったか 20 分枠で応募してしまったがために、時間的な制約によって深い・細かい話は一切できずに代表的な圧縮アルゴリズムのざっくり説明とその Java 向けライブラリの紹介、そしてちょっとした比較に終始してしまいました。これでは、発表タイトルにある「極める」とは程遠い内容だな… と反省するばかりです。 なお、Java そのものからはちょっとずれた「データ圧縮」というテーマ設定での発表ではありましたが、ご回答いただいたアンケートで もう少しロジックに踏み込んだ話が聞きたかった。 という声があったり、Twitter 上でも こういうの好き。20分しかなかったので圧縮の「比較」に注力したのだと思うんだけど、45分あれば少し踏み込んでアルゴリズムの違いとかも話してくれそう

Java アプリケーションを Docker コンテナ上で実行しようとしたときに、ベースイメージとしてどの Docker イメージを選ぶのがよいかを考えてみます。 はじめにPermalink Java で Web アプリケーションを開発して運用、というと、昔は Tomcat をインストールしたサーバに JAR ファイルや WAR ファイルを配布してデプロイしていたような記憶が微かに残っているのですが、数年前からは Spring Boot のように組み込み Tomcat などを採用し、Maven や Gradle のビルドオートメーションツールの力を借りて Java アプリケーションの実行に必要な JAR ファイルをひとまとめにした fat JAR (uber JAR) を構築し、単体の JAR ファイルだけを Java がインストールされているサーバに配布してデプロイ… とすることが圧倒的に

ファクトチェックを技術的に支援する取り組みPermalink 昨年 6 月の ファクトチェック・イニシアティブ 設立とともに始まった テクノロジーを用いたファクトチェック支援 を目指すプロジェクト1 では、ファクトチェッカーの方々の業務を自然言語処理や機械学習を用いて効率化したり、またファクトチェックの成果物であるレビューデータをオープンに利活用できる仕組みを作ることを目的としています。 今回のデブサミでは、特に前者の取り組みについてお話ししました。発表資料は以下になります。 発表を終えてPermalink 発表では「ファクトチェック」の説明にかなり時間を割いて話をしたので、その分技術寄りの話がちょっと手薄になってしまった感がありました。自然言語処理や機械学習の濃ゆい話を期待していた方にはちょっと物足りない発表だったかもしれません 🙇 なおそのあたりの話題については発表でも言及したとおり

ちょっと前に巷で話題になっていた A/B テストに関する MS の論文 A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments をご多分に漏れず読んでいるので、自分なりに気になったところを掻い摘んでメモを残していきます。 今回は chap.4 Metric taxonomy のメモです。 (Photo by Vitaly V. Kuzmin / Wikipedia) A/B テストにおける指標値 (メトリクス) の分類Permalink この論文では、A/B テストの結果を定量的に見るためのメトリクスをその目的ごとに以下の 5 つに分けて扱っています。 Data quality metrics Overall evaluation criteria (OEC)

書籍をレビューさせていただいたご褒美に「仕事ではじめる機械学習」を電子的にご恵贈いただいたので、(レビューでひと通り読みはしたが、いま一度) 読んでみたメモというか個人の感想を残しておきます。 ソフトウェアエンジニアとして機械学習と付き合うPermalink ソフトウェアエンジニアという立場で「機械学習」と接すると、機械学習の「理論的・技術的な面白さ」を味わったり「機械学習によってなにか凄い結果が得られるんじゃないか？」といった期待を持つと同時に、「どうやってプロダクションのシステムに組み込むのか？」とか「はたしてシステム的かつ精度的に安定して運用できるのか？」といったエンジニアリング面の悩みに苛まれることになるかと思います。 さて世の中に出回っている機械学習関連の書籍を俯瞰してみると、かの「機械学習プロフェッショナルシリーズ」のように理論寄りの書籍もあるものの、多くは特定の機械学習ライブ

TL;DR: Java の java.util.Random#nextGaussian() や java.util.concurrent.ThreadLocalRandom のそれよりも 3 倍 以上速い正規乱数生成器 (正規分布に従う乱数生成器) を実装してみたよ、というお話です。 (Header photo by NJR ZA ) はじめにPermalink ここ最近、お仕事的な何かで強化学習っぽい機能を実装したり、現実世界のとある問題を単純なモデルに置き換えてシミュレーションをぶん回してみる機会がちょこちょことあるのですが、そのような機能やシミュレータを実装しようとするときに「それなりの品質の乱数を とにかく速く 吐き出してくれる乱数生成器があると便利なんだけどなあ…」ということを時々思っています。 今の仕事で利用することの多い Java (or JVM 上の言語) では、Java

TL;DR: ガンマ分布に従う乱数生成器を Java で実装し、Commons Math の実装と比較して 最大で約 16 倍 (任意の形状パラメータの乱数を生成する場合) の速度効率を達成しましたよ、というお話です。 (Header image: Mundhenk at en.wikipedia) ガンマ分布に従う乱数生成の実装方法Permalink これまで 正規分布に従う乱数生成、指数分布に従う乱数生成 をそれぞれ Java で実装してきましたが、今回はガンマ分布に従う乱数生成を Java で実装してみます。 ガンマ分布 は、形状パラメータ k>0 と スケールパラメータ θ>0 (もしくは形状パラメータ α=k と比率パラメータ β=1/θ) の 2 つのパラメータを持ち、その確率密度関数は次の式で表されます。 f(x)=xk−1e−x/θΓ(k)θk ガンマ分布の形状パラメータ

「一様乱数を足し合わせて平均値をとった値は正規分布っぽくなるよ」というツイートを見かけて、「それって統計的にどうなんだろう？」という疑問が湧いたので検証してみました。 はじめにPermalink 昨日・一昨日ぐらいに Twitter 上でちょっとした話題になっていた アニメーションの監修で、「 Random();の代わりに、(Random()+Random()+Rrandom()+Random()+Random())/5.0f; を使うと、動きにコクが出る」と言ったら、ピュアオーディオ扱いされるのですが・・・これは根拠のあるアルゴです。 — 深津 貴之 (@fladdict) 2016年11月3日 というツイートに関連して、「一様乱数の平均値を正規乱数として代用する」的なツイートをちらほら見かけて気になっていたので、統計的に検証してみましたよ、というブログエントリです (このツイート自体に

Java において JSON を読み書きするライブラリといえば、いまや Jackson がデファクトスタンダードかと思います。今回はこの Jackson をハイパフォーマンスに扱う方法について、第十七回 #渋谷java で発表してきました (発表資料はこのエントリの最後に掲載しています)。 About “Jackson”Permalink Jackson について (それなりの経験がある Java エンジニアであれば釈迦に説法ですが) 簡単に説明すると、JSON を始めとして XML や YAML などのテキスト形式のデータフォーマットから Avro などのバイナリフォーマットにも対応した、データの読み込み・書き出しを実現するデータ処理ライブラリです。 mvnrepository.com の JSON Libraries ページ を見ると明らかなように、Gson などの他の JSON ライ

ブログシステムとして Jekyll と Minimal Mistakes テーマを導入してみたメモです。 はじめにPermalink ここ 6 年ほどは (年間の投稿量はわずかながら) Blogger を使ってブログエントリを書いてきましたが、 標準では Markdown 入力に対応しておらず、タグを手打ちしなければならなくて辛い ゴテゴテしておらずシンプルでいい感じのテーマが少ない かといってテーマをカスタマイズしようとすると、それはそれでタグ地獄に陥って辛い モバイル対応が十分とは思えない などの理由により、この先も Blogger を継続して利用するのは難しいと判断し、ブログシステムを Github Pages with Jekyll に乗り換えることにしました。 なお、乗り換え先のブログサービス・ブログシステムとして、今回はてなブログと Hugo, Jekyll を比較検討しながら

LexoRank とは何か？ 世の中に転がってる LexoRank の日本語解説記事がどうにも腑に落ちない内容だったので、この記事をしたためることにしました。 SharedArrayBuffer とクロスオリジン分離の問題への対処の記録 Legalscape (リーガルスケープ) アドベントカレンダー 2021 の 12/20 (月) のエントリです。本日のエントリは、Legalscape が遭遇した SharedArrayBuffer とクロスオリジン分離の問題についてお送りします。