tinygo 向けの JSON marshaler: go-json-ice を書いた - その手の平は尻もつかめるさ
English article is here: Released go-json-ice: a code generator of JSON marshaler for tinygo - moznion's tech blog tinygo では encoding/json を import するとコンパイルできなくなるという問題があり *1，なんらかの struct を JSON に marshal したい時に使える de facto な方法が無いように見えました．これに関しては例えば以下のような issue が立っています: github.com github.com つまり tinygo 上で任意の struct を JSON にしたい時は「手で気を付けてシリアル化する」しか方法がなかったわけですが，まあそれだと何かと不便だったので表題の通り json-ice という encodi
zabbix-internal-checks-exporterをリリースしました - その手の平は尻もつかめるさ
github.com 表題の通りリリースいたしました． これはなに Zabbix internal checks と呼ばれる Zabbix プロセスの状態を表現するメトリクスを定期的に収集し，Prometheus のメトリクスフォーマット (i.e. OpenMetrics) で export する Prometheus exporter です．愉快ですね．皆さんも愉快に思っていただけると嬉しいです． どんなときに使うの OpenMetrics を理解できる監視コンポーネントで Zabbix を監視する時 生きていると色々ありますね． 以上です，よろしくお願いします．最近の prometheus/client_golang はめちゃめちゃ便利で良いですね． よォZabbix……テメェは今まで自分が「監視する側」だと思って良い気になってたかもしれねェがよォ……これからはテメェも「監視される側
CircleCI 2.0でElasticsearchを起動しつつテストする - その手の平は尻もつかめるさ
例えばElasticsearchを使ったプロジェクトがあったとして，それをCircleCIで継続的にテストしたいとする．CircleCI 2.0はコンテナベースのCI環境なので，そのプロジェクトが採用している言語のコンテナの上でElasticsearchを動かす必要がある．どうするか． circleci.com CircleCIのドキュメントに記されている通り，docker imageは複数起動することができる．一番目に指定したdocker imageはprimary containerとして取り扱われ，stepsに書く手続きは全てそのコンテナ上で実行される．それ以降にdocker imageを指定した場合はそのimageがprimary containerと共通のネットワーク上で立ち上がり，そのコンテナ上で公開されているポートについてはprimary containerのlocalhos
Test::Fluent::Logger書いた - その手の平は尻もつかめるさ
表題の通りです．Perl5の話です． CPANにもあげてあります． https://metacpan.org/pod/Test::Fluent::Logger 何をするモジュールかというと，useするだけでFluent::Loggerのpost及びpost_with_timeの内容をインターセプトして，本来送るべき宛先には送らずに内部のリストにそれを貯めるという動作をするモジュールです．そしてそのリストをgetしてきて中身を確認したり，またリストを空にする (clear) こともできます． 使い方についてはSYNOPSISを読んでいただければわかると思います．とくに難しいことはありません． 本来はMockみたいな名前をつけるべきだったのかもしれませんが，こんなのテスト用途以外に誰が使うんだということでこの名前になっています． 毎度毎度この手のコードを書いていて，良い加減飽きたなという動機で
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
sprint という Java の string formatter を書いた - その手の平は尻もつかめるさ
sprint という Java 向けの String formatter を書いた． Maven Central にも置いてある． http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22net.moznion%22%20AND%20a%3A%22sprint%22 sprint は Sprint#ff() というメソッドを提供している．使い方としては以下の様な感じ． final Sprint sprint = new Sprint(); System.out.Println(sprint.ff("Hello: {}!", "John")); // => Hello: John! 処理としては，template を parse して placeholder とそれ以外とを検出して，その検出した placeholder に変数を埋めつつ文字列を生
Docker 使って golang で書いたツールの cross platform build をする - その手の平は尻もつかめるさ
まず以下の様なシェルスクリプトを用意する． #!/bin/bash # ここで依存しているパッケージを go get する # 例えば以下の様な感じ # go get -v gopkg.in/yaml.v2 # go get -v gopkg.in/redis.v3 for GOOS in darwin linux; do for GOARCH in 386 amd64; do export GOOS export GOARCH go build -v -o bin/tool-$GOOS-$GOARCH main.go done done darwin と linux について，それぞれ i386 と amd64 アーキテクチャ向けのバイナリを作るようなスクリプト．main.go はビルド対象のファイル．成果物はカレントディレクトリの bin 以下に生成されるので，あらかじめ mkdir
快適な連打機能を提供するためにサーバサイドが出来ること - その手の平は尻もつかめるさ
人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！ しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する
Jesque を頑健に使うために RobustWorkerPool というのを書いた - その手の平は尻もつかめるさ
8/16 (日) に京都でハッカソンが催されるとの事だったので遊びに行って，表題のものを作ってきました (実際には大部分は予め作っていた)． Jesque は Resque の Java 実装版で，今やっているやつではこれを使った JobQueue - Worker なシステムの実装を進めています． しかし Jesque Core の Worker Pooling の実装は調べてみると微妙な感じで，具体的にどう微妙かと言うと「Worker を Pooling する (つまり Worker を任意個生成する)」というところまでは面倒を見てくれるのですが，その Worker 群に対して死活監視等のマネジメントの一切をしないという問題があり，これは「不慮の事故で Worker が死んでしまった時 (Worker が poll している時に例外が上げられた時とか) にその Worker を生き返ら
Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ
kamipo traditional については以下の記事が詳しい． ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 ところでこれをJava，というかJDBCで有効にするには以下のように書いてやるとよろしい． try (final PreparedStatement preparedStatement = connection.prepareStatement( "SET SESSION sql_mode = 'TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY';")) { // This is "kamipo TRADITIONAL". More strict, healthy, nice. // https://github.com/kamipo/etcfiles/blob/
実行中のプログラムの進捗度を手っ取り早く確認したい - その手の平は尻もつかめるさ
完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな． そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう． (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．
Test::Synopsis::Expectationというモジュールをリリースしました - その手の平は尻もつかめるさ
このたび，Test::Synopsis::Expectationというモジュールをリリースしました． https://metacpan.org/pod/Test::Synopsis::Expectation https://github.com/moznion/Test-Synopsis-Expectation 使い方や仕組み等をid:mackee_wさんの記事で紹介していただいたので，そちらの方も併せてご覧いただくと良いと思います． SYNOPSISのコメントを使ってテストするTest::Synopsis::Expectation - ぱいぱいにっき CPANに上がっているモジュールを使う時，多くの方が何は無くとも真っ先にSYNOPSISを見て使い方をザックリ把握するかと思います．とりあえずSYNOPSISのコードをコピペしてみて，動くかどうか見てみる的な． で，SYNOPSISのコード
CUDA 初学者は「効率的なプログラミング」を一旦忘れた方が良いと思った話 - その手の平は尻もつかめるさ
ある事情でCUDA 初学者が集まる勉強会で (恐れ多くも) TA をやってきて、その時に色々と思うところがあったので書きます。 「CUDA を始める動機」が与える影響 CUDA (GPGPU プログラミング)を始めるにあたっての動機の大半は「処理を高速化したいから」だと思います。 中には「GPGPU を使ったプログラミングに興味があったから」とか「CUDA が面白そうだったから」とか、 そういう知的好奇心からCUDA を始める強者もいるとは思いますが、 「GPU 使えば処理にかかる時間を短縮できるんでしょ？」という即物的な動機からCUDA の学習や導入を検討する例が多いような印象を受けます。 で、その世相を反映してか、CUDA 初学者向けの書籍や記事には「高速に動作する処理の書き方」だとか「効率的なプログラムの書き方」という 発展的な内容にカジュアルに触れているものが多く、今回参加した初学
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
