こんにちは、 @kz_morita です。 今回は、WSL 上で Rust の開発を行い、Windows 上でそれを実行するためクロスビルドするための方法についてまとめます。 対象のソースコード 今回は、WindowsAPI を Rust から叩くようなアプリケーションをWSL 上で実装して、Windows 向けにクロスビルドして動かしてみます。 具体的には、MessageBox API を叩いて Windows 上で MessageBox を表示してみます。 WindowsAPI を叩くために windows crate を使用します。 ソースコードには、 Microsoft公式のこちら に記載されているものを利用しています。 以下 Cargo.toml です。 Cargo.toml [package] name = "win_message_box" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] [dependencies.windows] version = "0.43.0" features = [ "Win32_Foundation", "Win32_UI_WindowsAndMessaging" ] 以下ソースコードです。 src/main.rs usewindows::{core::*,Win32::UI::WindowsAndMessaging::*};fn main(){unsafe{MessageBoxA(None,s!("Ansi"),s!("World"),MB_OK);MessageBoxW(None,w!("Wide"),w!("World"),MB_OK);}}クロスビルドをする クロスビルドために以下の cross crate を Install して、cross コマンドを使えるようにします。

こんにちは、 @kz_morita です。 トランザクション分離レベルについてまとめます。 分離レベルについて 以前の記事 で ACID 特性についてまとめましたが、トランザクション分離レベルは分離性についての概念です。 以下のような種類があります。 直列化可能 (Serializable) スナップショット分離 (Repeatable Read) Read Committed Read Uncommitted 上から順に分離レベルが高いものになっています。分離レベルの高さとパフォーマンスはトレードオフの関係にあります。 また、分離レベルにより以下の問題が発生したりしなかったりします。 Dirty Read Non-Repeatable Read Phantom Read 直列化可能 (Serializable) 直列化可能は、複数のトランザクションが並行で実行されたときでも直列で実行したときと同様の振る舞いになることを保証する分離レベルです。 一番制約が厳しいものですが、パフォーマンスは劣化します。 MySQL の公式には以下のように記載されています。 https://dev.mysql.com/doc/refman/8.0/ja/glossary.html#glos_serializable これは、SQL 標準で指定されるデフォルト分離レベルです。 実際には、この強度が必要になることはほとんどないため、InnoDB のデフォルトの分離レベルは次に厳しい REPEATABLE READ です。 スナップショット分離 (Repeatable Read) Phantom Read は起きるが Non-Repeatable Read と Dirty Read は起きないという分離レベルです。 Nonrepeatable Read (Fuzzy Read) が起きないように、複数バージョンのスナップショットを並行で管理するような仕組みが実装されていて、MVCC (multi-version concurrency control: マルチバージョンへ移行制御) と呼ばれる手法が用いられています。

こんにちは、 @kz_morita です。 今回は，『データ指向アプリケーションデザイン』を読んだのでその感想を書いていきます． 本について 以下の本を読みました． データ指向アプリケーションデザイン かなりの大著のため読むのに時間がかかりましたが一通り読むことができました． 目次は以下のような感じです． 第I部データシステムの基礎 1章　信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション 1.1　データシステムに関する考察 1.2　信頼性 1.3　スケーラビリティ 1.4　メンテナンス性 まとめ　2章　データモデルとクエリ言語 2.1　リレーショナルモデルとドキュメントモデル 2.2　データのためのクエリ言語 2.3　グラフ型のデータモデル まとめ　3章　ストレージと抽出 3.1　データベースを駆動するデータ構造 3.2　トランザクション処理か、分析処理か？ 3.3　列指向ストレージ まとめ　4章　エンコーディングと進化 4.1　データエンコードのフォーマット 4.2　データフローの形態 まとめ　第II部分散データ II.1　高負荷に対応するスケーリング II.2　レプリケーションとパーティショニング 5章　レプリケーション 5.1　リーダーとフォロワー 5.2　レプリケーションラグにまつわる問題 5.3　マルチリーダーレプリケーション 5.4　リーダーレスレプリケーション まとめ　6章　パーティショニング 6.1　パーティショニングとレプリケーション 6.

こんにちは、 @kz_morita です。 Kindle Script という 端末を 1 年ほど前に購入して使い続けてみたので感想やカスタマイズしているものなどを紹介します． 使い心地などの感想 そもそも，Kindle Scribe を購入したきっかけとしては，技術書などを読むための電子書籍リーダーがほしいというモチベーションでした． 目に優しいとされている E-Link ディスプレイには興味があったものの，技術書を読むとなると既存の kindle 端末では少し画面が小さいという点がネックになっていて購入していませんでした． そんな折に，kindle scribe が発売され，これはよさそうだぞと思い立って購入しました． 結果としてかなり重宝しています． 良かった点 良い点としては，まず技術書を読むのに十分な画面サイズです． 10.2 インチのディスプレイがあるため技術書を読むのに困ることはいまのところないです． PDF なども amazon の Send to Kindle 機能などを用いると Kindle 端末に転送できるため読みやすく便利です． https://www.amazon.co.jp/sendtokindle E-Link ディスプレイは期待していたとおり目の負担がすくない (ような気がしている) ため時間をかけてじっくり読みたい技術書などには向いてるかなと思います． 第二に，ペンの書き心地もなかなか快適でした． 圏論の道案内を読んでいるときのメモ 書き心地やペン自体の筆圧検知などの機能については，さすがに iPad のペンの方が性能がよいとおもいますがメモをとるレベルであれば問題なく使えます． 第三に，充電の持ちがかなり良いです． 1 年間弱使いましたが，バッテリー切れ使えない．で充電しなければ．といったタイミングは一度もなかったです． 普段遣いしていて，まず充電きれないですし，ふと気が向いたときに充電しとくかー，くらいの感じで指しておけばかなりもちます． これは買った当初あんまり期待はしてなかったですがかなり助かってます． 微妙に感じた点 非常につかいやすいのですが微妙な点としては，10 インチもあるため電車の中などで，吊革につかまりつつ本を読むと行ったときに重量がなかなか重く安定しません． 携帯性という観点ではもう少し軽くて小さい端末のほうが向いているかなと思います． ただし，この弱点を解消すべく端末をカスタマイズしたので紹介します． カスタマイズ 以下のようなスタイルで今運用しています． 商品でいうと以下を装着しています． iRing Link2 Limited Edition Majextand M まず iRing ですが，こちらは iPhone などに付けることが多い商品かと思いますが端末の端にこちらをつけています． これをつけることで，片手でもつのがかなり安定します．

こんにちは、 @kz_morita です。 トランザクションの ACID 特性についてまとめます。 ACID 特性とは 以下の頭文字を取ったトランザクションの安全性を保証する特性のことです。 Atomicity (原子性) Consistency (一貫性) Isolation (分離性) Durability (永続性) 一つずつ説明していきます。 Atomicity トランザクションが原子 (Atomic) のようにそれ以上分割できない単位になっていることを指します。 トランザクションは、開始されたら commit され正常に終了するか、rollback され中断、破棄されるかのどちらかのみとします。 トランザクションが実行前か実行が完了している状態のどちらかのみのため、アプリケーションは失敗したらリトライすればよくシンプルになります。 SQL でいう、BEGIN ~ COMMIT, BEGIN ~ ROLLBACK は Atomic な単位を宣言するために使われる構文ということになります。 Consistency データが満たすべき制約や整合性が、トランザクションの実行中でも満たされているような性質です。 制約や整合性は、定義されたスキーマ通りのデータであったり、外部キーなどの制約、論理的な制約などになります。 一貫性は、データベースが保証できるものではなく、トランザクションを開始するアプリケーションが保証するものになります。 Isolation 並行して実行されている別のトランザクションとお互いが分離されているような性質です。 分離性にはいろいろなレベルがあり、一番強いレベルの分離性を持つのが、直列化可能性 (Serializability) とよばれるものです。 これは、トランザクションを直列に実行した場合と同じ結果となるように振る舞うような分離レベルになります。 他にも スナップショット分離 や、Read Committed などの Serializability よりも弱い分離レベルがいくつかあります。 （別でまとめようと思います） Durability トランザクションがコミットされたら、データが失われずに永続化される性質です。 データベースが分散しているかどうかで若干意味が変わります。単一のDBの場合はディスクに書かれたこと（リカバリ用の write-ahead ログなども含む）が、分散されているストレージの場合は、一定数のノードにレプリケーションされているといった形です。 ACID 特性を満たさないものについて ACID 特性を満たさないシステムを BASE と呼ぶそうです。 BASE は以下の頭文字です。

こんにちは、 @kz_morita です。 golang で html/template でHTMLを返すときに、JSON の整形をする方法についてのメモです。 結論 sprig というライブラリを使用すると、golang の HTML template 内で便利な関数を使えるようになります。 https://github.com/Masterminds/sprig https://masterminds.github.io/sprig/ そのなかに、toPrettyJson という物があるので使用すると JSON をいい感じにフォーマットしてくれます。 import ( "html/template" "github.com/Masterminds/sprig/v3" ) type Response struct { Body string `json:"body"` } func Handler(w http.Response, r *http.Request) { resp := Response { Body: "{\"hoge\": \"fuga\"}" } parameter := map[string]interface{}{"body": resp} temp, err := template.New("index.html").Funcs(sprig.FuncMap()).ParseFiles("index.html") if err != nil { /* ... */ } err = temp.

こんにちは、 @kz_morita です。 DynamoDB のキャパシティユニットについて調べたのでまとめます。 DynamoDB のキャパシティユニットについて DynamoDB の料金体系の一つとして、キャパシティユニットという単位での料金課金があります。 キャパシティユニットは以下のような基準で消費されます。 Read 読み込みのキャパシティユニットは、読み込むDynamoDB のアイテム 4KB ごとに消費されます。 また、読み込みには以下の種類があり、それぞれ消費するユニットが違います。 (デフォルトは、結果整合性のある読み込みです。) 種類 消費ユニット 強力な整合性のある読み込み 1 トランザクション読み込み 2 結果整合性のある読み込み 0.5 たとえば 1 Item のデータサイズが 6KB で、結果整合性のある読み込みをするとすると 1 Item を Read するのに 1 unit 消費します。 ceil(6KB / 4KB) * 0.5 = 2 * 0.5 = 1 トランザクション読み込みであれば、 ceil(6KB / 4KB) * 2 = 2 * 2 = 4 となります。

こんにちは、 @kz_morita です。 CDC (Change Data Capture) といわれる技術について調べたのでメモです。 CDC について CDC: Change Data Caputure は Database などのデータの変更を追跡して、他のシステムやサービスに対して通知したりデータを流したりする仕組みの総称です。 たとえば、RDB の変更されたデータを Stream キュー などに流して後続の処理を実行するといった使い方ができます。 データベース以降の処理をイベント駆動のアーキテクチャにすることができるため、Stream 処理パイプラインなどとの親和性が高いように思います。 また、データのレプリケーションなども用途の一つにはいるかと思います。 たとえば、AWS の RDS から別のデータソースにリアルタイムでデータをレプリケーションしたいといったケースにも使用できそうです。 参考 変更データキャプチャとは Change Data Capture とは? 実現するための技術 CDC を実現するための技術としていくつかあります。 debezium debezium は、Java 性の OSS の CDC を実現するための技術です。 基本的に、Kafka というストリーム処理プラットフォームのコネクター (Kafka Connect) として実装されているため、DB から Kafka Stream のキューに流すといったユースケースでは使えそうです。 また、以下の記事で紹介されているように Embedded といわれる仕組みを使うと任意の Java コードを埋め込めるため、たとえば Amazon Kinesis にデータを流すなどある程度自由な事ができそうです。

こんにちは、 @kz_morita です。 オブザーバビリティ・エンジニアリングを読んだ の記事でも紹介されていた OpenTelemetry についてまとめます。 OpenTelemetry について OpenTelemetry については、 opentelemetry.io というWebページで紹介されていました。 公式サイトによると OpenTelemetry はトレース、メトリクス、ログなど (テレメトリデータと呼ばれる) を作成し管理するために設計されたフレームワークやツールキットのことです。 OpenTelemetry には、 すべてのコンポーネントについての仕様 テレメトリデータの形式を定義する標準プロトコル 一般的なテレメトリデータ型の標準命名スキームを定義するセマンティック規則 テレメトリデータの生成方法を定義する API 共通ライブラリとフレームワークの Instrumentation を実装するライブラリエコシステム コード変更を必要とせずにテレメトリデータを生成する自動計測コンポーネント 仕様、API、テレメトリ データのエクスポートを実装する各言語の SDK OpenTelemetry Collector、テレメトリ データを受信、処理、エクスポートするプロキシ OpenTelemetry Operator for Kubernetes などの他のさまざまなツール などが含まれているようで、プロトコルや仕様などから、実際の SDK やライブラリなどまで含まれているようです。 とくに、データ収集のバックエンドではなく、テレメトリデータの生成、収集、管理、エクスポートに重点をおいていて、データをどのように保存するかや、どのように可視化するかみたいな点については OpenTelemetry の範囲外で別の商用のサービスなどに任せられているそうです。 具体例をいうと、DataDog などは、OpenTelemetry をサポートしているサービスの一つです。 https://docs.datadoghq.com/ja/opentelemetry/ Observability と OpenTelemetry については、 OpenTelemetry は Observability を実現するためのツールキットになります。 前回の記事 でも触れましたが、Observability とはシステムの出力を調べることによって、システムの内部状態が理解できる能力のことになります。 具体的には、トレースや、メトリクス、ログなどのテレメトリデータを調べることによって、いまシステムに何が起きているのかがわかるというのが、Observability が高い状態と言えると思います。 逆に言うと、どのようにテレメトリデータを生成、収集、管理すればシステムの内部状態がわかるのかという点について標準化を目指しているのが OpenTelemetry と言えそうです。

こんにちは、 @kz_morita です。 普段時計型のデバイスとして、Fitbit Sense を使用しているのですが、ポモドーロを腕時計型デバイスで行ったら捗ったので紹介します。 使用しているアプリ 以下の Pomodoro Timer というアプリを使用しています。 Pomodoro Timer 現状、Fitbit Sense でポモドーロタイマーは探した当時はこのアプリしか見つけられませんでした。使用感もとてもシンプルなみためで最低限の機能があり満足しています。 触覚によるアラート PCやスマートフォンをポモドーロタイマーとして使用する際は、音か画面で時間の経過を通知すると思います。 腕時計型のデバイスを使用して初めて気づいたのですが、個人的に音や視界によるアラートより触覚によるアラートのほうが自分にはあってる気がします。 Fitbitは腕時計型デバイスのため、通知は腕時計が振動することにより検知することになります。 うまく言語化できないのですが、通知を受け取ったときの不快感が少ないように感じています。音によるタイマーは結構びっくりすることが多く、完全に作業に没頭するというよりは残り時間を気にしながら作業してい多様に感じます。 触覚によるアラートになってからは、自然にアラートにきづけるため個人的に負担が少なく、そのおかげか作業に集中できるような気がします。 が、あくまで個人的なものですし、気のせいな面も否定しきれない上、他の人にもあてはまるとは言えないです。 ちなみに、Fitbit を購入してから目覚まし時計も Fitbit の振動によるものに変えました。 最初は振動くらいじゃ起きないかなと思いましたが、自分は意外と振動による通知でちゃんと起きれることがわかりました。 余談ですが、VAKタイプというひとによって得意な感覚のタイプを分ける考え方がNLP心理学にあるらしいです。 人には “得意な感覚” がある。NLP心理学から考える、「優位感覚」を利用したコミュニケーション技法。 もしかしたら、自分は触覚が優位なタイプに分類されるのかもしれません。 まとめ 今回は、ポモドーロを Fitbit による振動で行ってみた感想などを書きました。 個人的に結構快適に感じているので普段から愛用しています。 腕時計型のデバイスを持っていて、ポモドーロやられている方は是非試してみてほしいなと思います。

こんにちは、 @kz_morita です。 最近読書について、色々と考えたり、新しい試みをしているのでそのことについて書きます。 自分にとっての読書と先入観 普段から主に技術書を読むことが多いのですが、興味のある本を買っては積読するということを繰り返しています。 読むスピードが遅いけど、興味のある本はつきないのでどんどん積読が増えてしまっている現状です。 さらに積読が増えてくると、もともと読みたくて買ったのに読むのが義務っぽくなってきてさらに読むのが億劫になったりします。 そして、読書をする際に自分は以下のような先入観があります。 読んだところを完璧に理解しないといけない 読み飛ばしたり、漏れがあるともったいない 本に書いてあることは正しい 1回ですべて理解しないといけない これらは無駄に完璧主義である自分の性格にも関係しているのですが、この先入観があると本を読むという行為が大変な作業となってますます本を読む回数が減ったりしていました。 考えていることと、試していること 最近はとにかく読書のハードルを下げて、読書量を増やし Input 量を増やそうと考えてます。 ハードル下げるために、1回の読書の重要度をできるだけ下げたいので以下のような考えで読むようにしてます。 積読は仕方がない 本から１つでも学びがあればそれで良い 本は何度も読む前提なので 1 回の読書で頑張らなくても良い 色々な箇所で言われていることな気もしますが、これらを再認識しながら読むようにしてます。 最初の積読に関しては毎月出版される本が大量にあるなかで、人間の本を読む処理能力に限界があるため興味の幅が広ければ広いほど積読は仕方ないという話を聞いて、肩の荷はおりました。 その内容については ↓ の YouTube で触れられています。 考え方は上記の通りですが、それに加えて試していることがいくつかあるのでそれも紹介します。 複数回にわけて本を読む 以下の方法を試してみています。 1,2回目: タイトルや図などだけさっと見る 3 回目: 行を目で追う 4 回目: メモを取りながら通読 大体 1,2回目は 1 時間くらい、3 回目は 2 ~ 4 時間くらいで読み切るイメージです。 1,2回目で特にこれ以上読まなくて良いと思ったらそれで終えても良いですし、4回目の読書時にはある程度のざっくりとした内容が頭に入っているので、メモをまとめることに注力できると思います。 今までの読書方は以下のようなイメージです 理解度を 1章ずつ完璧にしていくようなイメージですが途中で挫折しやすいかなと思います。 複数回読むということは ↓の画像のようにすこしずつ章全体の理解度を上げていくイメージです。 興味深いところだけ、詳細に読むみたいな取捨選択もできるかなと思います。 まだ試したてなのですが、すぐにあった効果としては読書の頻度は間違いなく上がりました。 しばらく継続してみようと思います。

こんにちは、 @kz_morita です。 普段作業効率化のため、Launcher アプリとして Alfred を使用しています。Alfred には Snippet 機能がありそこにいろいろなものを登録していて便利だったので一部紹介してみます。 以下のような format で紹介してみます。 # snippet のタイトル # 説明 $ {実際に実行するコマンド} git 系 過去の こちらの記事 でも紹介している git コマンドを登録していて定期的にお掃除したりしています。 お掃除系はこんな感じ # git remove merged # マージ済みブランチの削除 $ git branch --merged | egrep -v "\*|master|develop" | xargs git branch -D # git plune # リモートで消されたブランチをローカルに反映 $ git remote prune origin # git git remove origin removed branch # 削除されたリモートブランチとおなじローカルブランチを削除 $ git branch --format "%(refname:short) %(upstream:track)" | grep "\[gone\]" | awk '{print $1}' | xargs -IXXX git branch -D XXX 他にも以下のようなものも登録しています。意外と使います。

こんにちは、 @kz_morita です。 今回は、 『オブザーバビリティ・エンジニアリング』 を読んだので感想などを書いていきます。 本について オブザーバビリティ・エンジニアリング オブザーバビリティ・エンジニアリング 目次 本書への賞賛 まえがき 序文 第Ⅰ部　オブザーバビリティへの道 1章　オブザーバビリティとは？ 1.1　オブザーバビリティの数学的定義 1.2　オブザーバビリティのソフトウェアシステムへの適用 1.3　ソフトウェアにおけるオブザーバビリティについての誤解 1.4　なぜ今オブザーバビリティが重要なのか？ 1.5　メトリクスを用いたデバッグとオブザーバビリティの比較 1.6　オブザーバビリティを用いたデバッギング 1.7　オブザーバビリティは現代のシステムのためにある 1.8　まとめ 2章　オブザーバビリティとモニタリングにおけるデバッグ方法の違い 2.1　モニタリングデータのデバッグへの活用方法 2.2　オブザーバビリティがより良いデバッグを可能にする理由 2.3　まとめ 3章　オブザーバビリティを用いないスケーリングからの教訓 3.1　Parseの紹介 3.2　Parseでのスケーリング 3.3　現代のシステムへの進化 3.4　現代的な実践に向けた進化 3.5　Parseにおけるプラクティスの変革 3.6　まとめ 4章　オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性 4.1　クラウドネイティブ、DevOps、SREクイックリファレンス 4.2　オブザーバビリティ：デバッグの昔と今 4.3　オブザーバビリティがDevOpsとSREのプラクティスを強化する 4.4　まとめ 第Ⅱ部　オブザーバビリティの基礎 5章　構造化イベントはオブザーバビリティの構成要素である 5.

こんにちは、 @kz_morita です。 今回は、 『Clean Craftsmanship』 という本を読んだのでその感想などについてまとめます。 本について Clean Craftsmanship 規律、基準、倫理 おなじみのボブおじさんの、Clean シリーズの本になります。 Craftsmanship についての本で 以前 ソフトウェア職人気質 という本を読んで気になってたので、最近でたこの本も気になって読んでみました。 目次は以下のような感じです。 (長すぎるので折りたたんでます) Clean Craftsmanship 目次 序文 はじめに -「クラフトマンシップ」という言葉について - たったひとつの道 謝辞 著者について 第1章　クラフトマンシップ 第I部　規律 - エクストリームプログラミング - テスト駆動開発 a リファクタリング - シンプルな設計 - 協力的プログラミング - 受け入れテスト 第2章　テスト駆動開発 - 概要 - 基本 - 結論 第3章　テスト駆動開発応用 - ソート1 - ソート2 - 行き詰まり - AAA（準備、実行、アサート） - テストダブル - アーキテクチャ - 結論 第4章　テスト設計 - データベースのテスト - GUIのテスト - テストパターン - テスト設計 - 変換の優先順位説 - 結論 第5章　リファクタリング - リファクタリングとは？ - 基本的なツールキット - 規律 - 結論 第6章　シンプルな設計 - YAGNI - テストでカバーする - 表現の最大化 - 重複の最小化 - サイズの最小化 第7章　協力的プログラミング 第8章　受け入れテスト - 規律 - 継続的ビルド 第II部　基準 - あなたの新しいCTO 第9章　生産性 - 絶対にS**Tを出荷しない - 安価な適応力 - 常に準備万端 - 安定した生産性 第10章　品質 - 継続的改善 - 恐れを知らない能力 - エクストリームな品質 - QAを軽視しない - QAは何も発見しない - テストの自動化 - 自動テストとユーザーインターフェイス - ユーザーインターフェイスのテスト 第11章　勇気 - お互いをカバーする - 正直な見積り - 「ノー」と言う - 継続的挑戦的学習 - メンタリング 第III部　倫理 - 最初のプログラマー - 75年 - オタクから救世主へ - ロールモデルと悪役 - 我々が世界を支配する - 大惨事 - プログラマーの誓い 第12章　有害 - 第一に、害を与えてはならない - 最高傑作 - 再現可能な証拠 第13章　誠実 - 小さなサイクル - 容赦ない改善 - 高い生産性を維持する 第14章　チームワーク - チームとして働く - 正直に公正に見積もる - 尊重 - 学習をやめない 訳者あとがき - ソフトウェアクラフトマンの歴史 - クリーンクラフトマンシップ 訳者紹介 索引 感想など 大きく分けて 3部構成になってました。

こんにちは、 @kz_morita です。 今回は、 Apache Flink を試してみるのにあたって、docker の環境を作ってサンプルを実行してみたのでそのメモです。 いかに docker-compose ファイルとかをコミットしてあるので良ければ参考にしてみてください。 https://github.com/foresta/flink-on-docker flink を動かす flink は、stream 処理を実行するための framework です。 Docker で動かすために以下のページを参考にしました。 https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/resource-providers/standalone/docker/ 上記は、docker run コマンドでそれぞれ起動しているため、今回は docker-compose.yml ファイルを作成しました。 version:"3"services:jobmanager:image:flink:latestcontainer_name:flink-jobmanagerports:- "8081:8081"networks:- flink-networkenvironment:FLINK_PROPERTIES:"jobmanager.rpc.address: jobmanager"command:jobmanagertty:truetaskmanager:image:flink:latestcontainer_name:flink-taskmanagernetworks:- flink-networkenvironment:FLINK_PROPERTIES:"jobmanager.rpc.address: jobmanager"command:taskmanagertty:truenetworks:flink-network:上記は Flink の jobmanager と taskmanager を起動しています。それぞれを簡単に説明すると、jobmanager は Flink で実行したいジョブを管理するもので、実際に処理を行う worker node が taskmanager になります。 公式ページのこちら がわかりやすいです。 ちなみに、jobmanager には、WebUI が用意されているため、8081 ポートに接続できるようにしています。 上記の docker-compose ファイルを用意したら起動します。 $ docker-compose up -d 起動すると、localhost:8081 で以下のような WebUI にアクセスできます。

こんにちは、 @kz_morita です。 Scala (Java) で正規表現クラスを使っている際に遭遇したエラーについてまとめます。 Illegal group reference エラーについて Scala で以下のような正規表現を使用するコードを書いていました。 import scala.util.matching.Regex val regex = "【(.*)】".r val replacer = (m: Regex.Match) => "(" + m.group(1) +")" regex.replaceAllIn("hogehoge【fuga】", replacer) // hogehoge(fuga) 【】 を() に変換するといったようなコードです。 上記は正常に動くのですが、以下のようなテキストは正常に動きません。 regex.replaceAllIn("hoge【$abcde】", replacer) 上記は、以下のような Illegal group reference エラーが出ます。 java.lang.IllegalArgumentException: Illegal group reference at java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1067) at java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:907) at scala.util.matching.Regex$Replacement.replace(Regex.scala:898) at scala.util.matching.Regex$Replacement.replace$(Regex.scala:898) at scala.util.matching.Regex$MatchIterator$$anon$4.replace(Regex.scala:876) at scala.util.matching.Regex.$anonfun$replaceAllIn$1(Regex.scala:512) ... エラーの原因 "【(.*)】".r という正規表現で 【】 の中身の文字列をキャプチャするのですが、その中に、$ 記号がある場合にそれを正規表現の置換対象とみなしてしまうようです。 どういうことかというと、hoge【$abcde】 というテキストだと、【】の中の $abcde というテキストが、マッチしますがその中の $a という部分が後方参照で置換する対象だと解釈してしまいます。 しかし $a というのは、参照できないため Illegal group reference エラーになります。

こんにちは、 @kz_morita です。 以前の記事 で、WSL 上に Scala をインストールしたのですが、このときはWindows側にインストールした IntelliJ から、sbt プロジェクトが import できずに IntelliJ での開発を断念しました。 今回は、WSL に IntelliJ を Install して Scala を開発するところまでをやってみます。 準備 まず、WSL 上で GUI アプリケーションを動かすための準備をします。 https://learn.microsoft.com/ja-jp/windows/wsl/tutorials/gui-apps 上記の公式サイトに書かれていますが、wsl を update して 再起動します。 管理者権限で Powershell を起動して、以下のコマンドでアップデートと再起動を行います。 > wsl --update > wsl --shutdown 次に実際に GUI アプリが動くかどうかを試すために、Ubuntu で使えるファイラである、nautilus をインストールします。 $ sudo apt install nautilus -y ちなみに自分の環境では、上記コマンドが 404 Not Found になってインストールできなかったのですが、update を一度したら正常にインストールできました。 $ sudo apt update インストールができたら、起動してみます。 $ nautilus 以下のようなアプリが立ち上がれば成功です。

こんにちは、 @kz_morita です。 今回は、Scala の Try 型についてまとめます。 scala.util.Try Scala で例外をハンドリングするためには以下のようなコードで実現できます。 def div(a: Int, b: Int): Int = { try { a / b } catch { case e: ArithmeticException => { println(e.getMessage()) 0 } case e: Throwable => throw e } } println(div(4, 2)) // => 2 println(div(2, 0)) // => 0 scala.util.Try というのを使用すると以下のようにかけます def div2(a: Int, b: Int): Try[Int] = { Try { a / b } } println(div2(4, 2)) // Success(2) println(div2(2, 0)) // Failure(java.

こんにちは、 @kz_morita です。 今回は、Rust で事前条件をどのように表明するのが良さそうかを調べてまとめました。 前提 Rust には、エラーハンドリングなどをするために Result 型などがありますが、回復不能なエラーを意味する panic があります。 panic は起きると異常終了するものです。 今回は、事前条件を満たさない場合には、panic させるようなコードを考えます。 コード例 n x n の正方行列を扱う型を考えます。 // n x n の正方行列を扱うための型 pubstruct SquareMatrix<T>{arr: Vec<Vec<T>>,n: usize,}impl<T>SquareMatrix<T>{pubfn new(arr: Vec<Vec<T>>)-> Self{// 事前条件: n x n の二次元配列であること letrow_count=arr.len();forrowin&arr{letcolumn_count=row.len();ifcolumn_count!=row_count{panic!("Arguments not n x n arr");}}SquareMatrix{arr,n: row_count}}}二次元配列の row_count と column_count が一致しない場合は生成できないように panic するといったコードです。 Rust で panic する方法 事前条件を満たさない場合に、panic する方法としていくつかあります。 panic! 上記のコード例で使用したマクロです。引数に与えられた情報を表示しつつ panic します。 assert 系 こちらはテストコードなどでおなじみの assert 系で、以下のようなものです。 assert!() assert_eq!() 上記のコード例は if 文 の結果により panic!

こんにちは、 @kz_morita です。 今回は、発売前から気になっていた以下の本を読んだので感想などを書いていこうと思います。 『スタッフエンジニア　マネジメントを超えるリーダーシップ』 本の概要 この本は、ソフトウェアエンジニアのマネジメント職ではないキャリアパスとしてスタッフエンジニア (超上級エンジニア) が紹介されています。 スタッフエンジニアになるためにどのようなスキルが必要化という点や、実際にスタッフエンジニアとしては垂らしている人のインタビューが掲載されていました。 目次は以下のとおりです。 ■第１部　スタッフとして活躍するために ・第１章　全体像 ・第２章　スタッフとしての役割 ・第３章　スタッフプラスの肩書を得る ・第４章　転職を決断する ■第２部　スタッフたちの実像 ・第５章　スタッフエンジニアのストーリー ・第６章　最後に ・補章　スタッフになるための情報源 ・解説　by 増井雄一郎 ※公式サイトより 感想 エンジニアとしてどのようなキャリアを歩んでいきたいかということを考えたときに、方向性としてマネジメントとスペシャリストという2つが思い浮かびます。 なんとなく、スペシャリストとしての道を進みたいと考えていたのですがその先の具体的なキャリアパスなどはあまりイメージできていない状態でした。 この本は実際にスタッフエンジニアとして働いている人のインタビューが載っておりどのようにその職についたのか、またどういったことが評価されてスタッフエンジニアとしての職についたのか、参考になる部分が多かったです。 読んだ印象としては、どの人も会社や他の人の生産性を上げるため、つまり会社全体に対する大きな貢献をしたことがきっかけになるケースが多く見受けられました。 このような他の上級エンジニアの人の話など聞く機会は少ないため参考になりました。 また、スタッフエンジニアにおける一般的な4つのアーキタイプの話が興味深かったです。 アーキタイプについては、下記のサイトでも紹介されています。 https://staffeng.com/guides/staff-archetypes/ それぞれ、以下の4つです。 テックリード アーキテクト ソルバー 右腕 詳細は本や先程のサイトが非常に参考になりますので参照してみてください。 このような名称と役割を知れたということが個人的には非常によくて、自分がどの方向性を目指すのか、どの方向性の役割に対して特にモチベーションが高いのかということを考えるきっかけになりました。 自分がどのようなスキルを磨いてどのようになっていきたいのかと言う観点で非常に参考になります。 さいごに 自分のキャリアパスについて考える際に非常に参考になる本でした。 定期的に読み返して、自分がどの方向性に向かいたいのか考えていきます。 おすすめできる対象の人としては、エンジニアとして数年経験してきたけど IC としてさらに上級のエンジニアを目指したいといった人になるかなと。 非常に刺激になりますし、キャリアを見直すきっかけとなる良い本になるのではないかと思います。

こんにちは、 @kz_morita です。 Rust のコードを書いていて、計算量が気になったので調べてみました。 対象のコードは以下のようなものです。 // 文字列を逆順にする lettext: String ="hogehoge".to_string();letreverse: String =text.chars().rev().collect();コードを読みとく まず、ぱっとこの処理を見たときに逆順に並び替えるだけなので、O(n) くらいで計算できそうと思ったのですが、計算量についてドキュメントが見つけられなかったので調べてみます。 実行している処理について見ていきます。 まず、String の chars() メソッドですが、これは String 型 の文字列を byte 列にして iterator として保持します。 https://doc.rust-lang.org/src/core/str/mod.rs.html#789 #[stable(feature = "rust1", since = "1.0.0")]#[inline]pubfn chars(&self)-> Chars<'_>{Chars{iter: self.as_bytes().iter()}}次に rev() ですがこちらは、Iterator を逆順で取得できるようにした Rev 型に変換します。 Chars https://doc.rust-lang.org/src/core/iter/traits/iterator.rs.html#3230-3239 #[inline]#[doc(alias = "reverse")]#[stable(feature = "rust1", since = "1.0.0")]#[rustc_do_not_const_check]fn rev(self)-> Rev<Self>whereSelf: Sized +DoubleEndedIterator,{Rev::new(self)}逆順に取れるようにする仕組みは、next() メソッドが override されており内部でnext_back() が呼ばれるようになっています。 https://doc.rust-lang.org/src/core/iter/adapters/rev.rs.html#31-34 #[inline]fn next(&mutself)-> Option<<IasIterator>::Item>{self.iter.next_back()}最後に、Rev 型の collect() メソッドが呼ばれています。 Rev 型は、Iterator トレイトを実装しているため、Iterator トレイトに実装されている collect() メソッドが呼べます。

こんにちは、 @kz_morita です。 今回は、普段使っている Jira で作業時間を算出するために、Jira のアクションを使って計測してみたので、方法についてまとめます。 Jira で作業時間を計測する 下準備 まず準備として、Jira に以下の 3 つのカスタムフィールドを追加します。 着手時刻: datetime 完了時刻: datetime リードタイム(分): number 次にカスタムフィールドの ID を知るために、上記のフィールドが入ったチケットを実際に作成します。 作成したら右上のメニューから、XMLのエクスポート を選択します。 すると以下のようなXMLが表示できます。 後ほど使うので、着手時間フィールドのIDを控えておきます。 今回のケースだと、customfield_10034 となります。 ここまで準備できたら OK で、実際に Jira のアクションを作成していきます。 アクション作成 アクションですが基本的に、トリガー (いつ) と条件 (どれを) とアクション (なにする)をセットで作っていきます。 今回は 3 つアクションを作ります。 着手時刻記録用 完了時刻記録用 リードタイム算出用 着手時刻記録用 以下のような情報で作ります。 トリガー 課題のトランジション時を選択して、ソースステータスに、オープン ターゲットステータスに DOING を選択します。 要は課題が着手開始されたときのステータスの遷移時に発火するように設定します。 条件 今回は、対象のプロジェクトだけに適用するようなトリガーにしたいため、上記のような条件を設定しました。 アクション 上記のように、着手時刻のフィールドに対してトリガーが発火された時刻を入力するように設定します。

こんにちは、 @kz_morita です。 今回は，O’Reilly から発売されている 『入門 監視』 という本を読んだのでそのまとめです． https://www.oreilly.co.jp/books/9784873118642/ 目次としては以下のようなものになります． はじめに 第Ⅰ部 監視の原則 1章 監視のアンチパターン 2章　監視のデザインパターン 3章　アラート、オンコール、インシデント管理 4章　統計入門 第Ⅱ部　監視戦略 5章　ビジネスを監視する 6章　フロントエンド監視 7章　アプリケーション監視 8章　サーバ監視 9章　ネットワーク監視 10章　セキュリティ監視 11章　監視アセスメントの実行 付録A　手順書の例：Demo.App 付録B　可用性表 付録C　実践.監視SaaS 訳者あとがき 索引 読んだモチベーション 日頃から，システムを運用しているため，システムやアプリケーションの監視も行っています． 監視をするなかで，以下のような課題感があります． アラートの量が多く対応すべきものが見えにくい 出たアラートは自動でチケット化しているが，対応可否を判断するための作業に一定時間がかかる システムの一時的な不調により出るエラーだが対応が不要なものが多い アラートの数が多いとそれだけで，システムの重要な兆候を見逃す可能性もありできるだけ減らしたい． 一方で，数が少ないとはいえエラーがでているため誰も気づけない状態は避けたいため，アラートを減らせていないという状況にあります． これらの課題をうまく取り扱い，システムをより監視しやすくしたいというモチベーションで本を読みました． 読んだ感想 読んだ感想としては，監視というものについて体系的にどう考えるべきかという話からすぐに取り組めそうなプラクティスまであったのが個人的にはとても良かったです． たとえば，アラートを いますぐに対応すべきアラート 参考情報としてのアラート の２つに分けるという話があったのですが，これは自分の課題であったアラートが多すぎるというものの解決策として取り入れたいと思いました． 普段 Alert を Slack に通知しているのですが，参考情報としてのアラートについては Slack に通知せずに Ticket 化するだけというのがよさそうかなと思います．

こんにちは、 @kz_morita です。 今回は，個人開発をしようとしたときに，データベースのインフラ環境としてどれが良いか探していた中で見つけた PlanetScale という PaaS がよさそうだったので試してみたメモです． PlanetScale について https://planetscale.com/ PlanetScale は，MySQL をホストしてくれる PaaS で，公式では serverless MySQL platform という風に謳われています． 料金プランは以下から確認できます． https://planetscale.com/pricing Hobby という無料プランがあり，これがちょっとした個人開発をする上でよさそうだなと思って今回は触ってみることにしました． 制限は以下のような感じ 5 GB storage 1 billion row reads/mo 10 million row writes/mo 1 production branch 1 development branch Community support storage や，read , write の制限に関してはちょっと使ってみるくらいだったら全然足りるかなと思います． 本格的に運用する場合には，plan の upgrade や移行先を考える必要がありそうです． 触ってみる 基本的な登録フローは簡単で画面に沿って進めます． UI から，Database を作成することができます． (Free のプランでは database は 1 つのみ作成できるようです)