たにしきんぐダム

プログラミングやったりゲームしてます

ScalaMatsuri 2018 / OSS Hackathon に参加しました

Scala イベント tech

ScalaMatsuri 2018｜日本最大級の Scala のカンファレンス

2018年3月16日(金)の Scala OSS ハッカソン / 2018年3月17日~18日の Scalamatsuri2018 に参加しました。楽しかった！

OSS ハッカソン

blog.scalamatsuri.org

ソイヤッて申し込んで良かった。scalikejdbc/scalikejdbc・skinny-framework/skinny-framework のプロジェクトへ参加しました。

最終的にハッカソンで取り組んだPRはこれらのPR

@seratchさんにいろいろアドバイスや現状のコードの経緯を聞きつつも、後者はハッカソン時間中にPRを出すに至らず...後日javadocを読み漁って何とかPRを出してマージしていただけました！ハッカソンに参加したからこそ貢献へのとっかかりが掴めたし、シュッとPRを出せました。参加してよかった。 @seratchさんも運営の皆様も本当にありがとうございました！

これからもやっていくぞ

Day1

会場付近の 東京お台場 大江戸温泉物語 | 【公式】大江戸温泉物語グループ｜癒しの温泉宿・旅館 に宿泊していました。早めに目が覚めてしまったので、お台場のそこらへんのカフェーで時間をつぶそうと思ったのだけれど休日朝のお台場ほんとに何もないな！！！コンビニでパンを買って海を眺めたりしてた。

LEGACY CODE FROM DAY ONE / @kubukoz さん

https://kubukoz.github.io/legacy-day1/#/

ソフトウェア開発プロジェクト進行におけるアンチパターンのお話

  • コードレビューはしない！
  • コードレビューは時間の無駄。なぜなら俺のコードはいつでも完璧だから
  • nitpickなレビューに一番こだわる
  • 統一的なルールに従わないコードフォーマットの推奨や、高度な技術を取り入れない
  • 早すぎる最適化や、早すぎるモジュール化...

などなどのアンチパターンを面白く話してくださいました。他にもプロジェクト進行におけるアンチパターンやソフトウェアメンテナンスにおけるアンチパターンなどなど、資料面白い。

sbt 1 / @eed3si9n さん

まず Lamport, Leslie. "Time, clocks, and the ordering of events in a distributed system." Communications of the ACM 21.7 (1978): 558-565 を引用してそもそも concurrent の定義を説明して、sbt の DSL ではどのように concurrent な処理を(直感的に)記述できるかということを説明していただいた。非常に分かりやすかった。

そして、sbt1 での 統一的スラッシュ構文や、sbt server による LSP サポート http://eed3si9n.com/ja/sbt-1-1-0-RC1-sbt-server の紹介。scalaで乱立するLSP実装は各所が共同してやっていくワーキンググループができたので、お互い歩み寄っていっているという話を聞いた。

この日は午後から用事があったため、ここで会場を後にした。懇親会に参加できなかったの残念...！

DAY2

朝ごはんです。コーヒーも美味しかった...

JDKのリリースサイクルの変更がScalaにどう影響するか聞きたい

きしださん や xuwei-k さんが中心になってお話していただいた。

このあたりのお話？

java 9,10 は短期サポート(半年) Oracle JDK に関しては 11 が 3年のLTS。なので、9,10に関しては手元できちんと動作することをテストしておきつつ、本番環境のバージョンアップはドーンと11まで上げるのが省エネなのではという話を聞いた。 しかし OpenJDK の 11 が LTS という話は特に聞かない気がする。Oracle氏〜

JVM Webアプリケーション メトリクス モニタリング

  • メトリクス取得
  • メトリクスの形式は
    • key value形式 -> (jmx や dropwizard) もう古いぜ
    • key+labels value形式
  • 最低限見てほしいもの
    • heap usage
    • gc lifecycle
    • thread pool
    • connection pool
    • アプリケーション固有のカスタムメトリクス
    • cpu / リクエスト数 / レスポンスタイム / ジョブキュー

などなど

あと3日でJava 10がリリースですが、興味ある人いますか?

出ましたね！

まだ内容追えてない...！

ノベルティ / たこ焼き

何故かたこやき配布してた。美味しかった

個人的に気に入ったノベルティの靴下と箸。珍しい！ 箸は開けてみると何も書かれてないただの上等な箸だった！ 株式会社ファンコミュニケーションズ さんはそれで良いのか！と思ったけれど逆に強烈に印象に残っているし、この箸使うたびに思い出している。

scala matsuri 2018 本当に楽しかったです。次回は何らかの形で貢献できると良いなと思っています。

シドニー旅行記

travel

4年前、大学一年次の春休みに大学の制度を利用してシドニーに約3週間(2014-02-22 から 2014-03-16)短期語学留学に行ってきた。

Google Photo を整理していたら大量に写真が出てきて懐かしくなったので、記憶にあるうちに旅行記を書いておこう。当時使ってたスマホの写真の画質があまり良くなくて残念！！

留学先

オーストラリア、ニューサウスウェールズ州のシドニーに位置する UNSW の留学生向け語学クラスに3週間留学した。

www.unsw.edu.au

当然たったの3週間では語学力の大幅な向上とかは無理なので異文化交流くらいな気持ち。大学の制度を使っていったので適当な留学エージェントを使うより安価で滞在できた。

(本来車校に通うために貯めてたお金を使って行ったので車の免許は今も持ってない。後悔はしていない)

町並み

Mascot

ホームステイ先はマスコットというシドニー空港のすぐ近く、歓声な住宅街で夜も静かだった。治安は結構良いという話だったけど日本と比べるとまあ良くないので夜はあまり一人で出歩かないようにと釘を刺された。

住宅街の道路です。初日に周囲を散歩してたときの写真、このあと知らないおじさんに宗教勧誘された。

気温・湿度ともに死ぬほど高いのと、ゴミは公道にある巨大ゴミ箱に適当に放り込んでおくみたいなシステムになってるためか道路でゴキブリを見ることが多々あった。日本のより強いし早いしでかい。

大学にはバスで通学していたのだけれど、シドニーの人々、とにかく「thank you」って言う。バス降りるときに運転手に対してもだし、カフェとかコンビニで品物を受け取るときも thank you って言っていた。これ凄く良い文化だと思うので日本に帰国してからも実践してる。

続きを読む

Bitcoin SPV Wallet を Golang で実装してみた

golang その他技術 tech

Golang と Blockchain 技術の勉強に、こちら の記事を参考にして Bitcoin の SPV Wallet を Golang で実装してみました。

github.com

結構雑ですが、とりあえず以下のことができます。

  • Bitcoin Address の生成
  • UTXOをかき集めて残高を計算
  • UTXOをかき集めて指定したBitcoin Addressに送金

実用には耐えませんが簡単なSPV Walletの一通りの機能は実装できたかなと思います

(そんなことなくてエラーハンドリングが雑だったりP2Pノードとしての役目を放棄してたり、取得するmerkleblockをハードコードした高さより高いblockのみ取得するようになってたりする)

参考

実装の際には主に @lotz氏のこちらの記事を参考に実装しました(ほとんど氏の実装をGolangに移植しただけw + 計算したUTXOを使って送り先と金額を指定するだけで送金できる機能)

こちらの記事では同様のWalletがHaskellで実装されており、解説がすごく丁寧で分かりやすいので、細かい解説が気になる方は是非読んでみてください！！

qiita.com

その他参考 🙏🙏

感想

Blockchain技術に興味を持ってMastering Bitcoinを読んだり簡易的なBlockchainもどきを実装してみて、全体像はなんとな～く分かってきたものの

  • Merkle Tree でトランザクションを検証するために Merkle Path を取得するってあるけど、具体的にどういう形で送られてくるんだ！？
  • スクリプトってどう表現されるんだ...
  • 「署名する」ってあるけど具体的にはどうするんじゃ

などなど細かい疑問がたくさんありました。

しかし今回SPV Walletを実装してみて少なくともSPV Walletの実装についてはしっかり理解できました。SPV Walletの細かい挙動に興味のある人は是非氏の記事を読んで自分の好きな言語で実装してみると良さそう！

Golangで簡易的ワーカー/ジョブキュー

golang tech
  • goroutineの数を制限しつつ並列にジョブを実行したい
  • ジョブは定期的に投入できたい
  • ジョブが空っぽになっても終了しないで欲しい
  • SIGTERMとか送ったら実行中のジョブが完了するまで待ってから終了してほしい

というようなものが欲しくなることが最近よくある！のでメモ

参考

実装

gistbe9fac4aa02419d68c6770a85e53c936

この実装ではmainの中のforループでのみジョブをenqueueしているが、

  • 定期的に外部リソース(APIたたいたり、DBを眺めにいったり)からデータを取得してジョブをenqueueしたり
  • HTTPサーバーをたててHTTP経由でジョブをenqueueできるようにして、別のプロセスから定期的にジョブをenqueueしたり

とかいろいろできて便利〜

JavaScript とクロスブラウザでの IME event handling (2017年)

JavaScript tech

この記事は CAMPHOR Advent Calendar 2017 22日目の記事です。
昨日は @ryota-ka による Type-level TypeScript - ryota-ka's blog でした。

CompositionEvent が多くの主要ブラウザでサポートされた2017年冬なら、JavaScriptで日本語入力に対応したちょっとした入力補完機能の実装はシュッとできると思ったのですが、ブラウザによって細かい実装が異なっていてちまちまとしたworkaroundが必要になったのでメモ

検証環境

KeyboardEvent.keyCode

IME によるテキスト編集中は keyodown イベントによって発火する KeyboardEventkeyCode は 229 になります。 これを使えば IMEによるテキスト編集中の keydown イベントにトリガする処理を制御することができる。

editorElem.addEventListener('keydown', function(event) {
  if (event.keyCode !== 229) {
    // do something ...
  }
});

https://www.w3.org/TR/uievents/#determine-keydown-keyup-keyCode

If an Input Method Editor is processing key input and the event is keydown, return 229.

Gecko

GeckoではIMEによるテキスト編集中はkeydown/keyupイベントが発火しないみたいですね

https://bugzilla.mozilla.org/show_bug.cgi?id=354358

deprecated

KeyboardEvent.keyCode は deprecated なようです。W3Cでも keyCode 属性が記載されていたのは Legacy Key Attributes の欄ですね、keyCode はプラットフォームや実装依存の値なので、排除していきたい流れなのかも。

KeyboardEvent.keyCode - Web APIs | MDN

KeyboardEvent.isComposing

KeyboardEvent.isComposing - Web APIs | MDN

  • IMEのような text composition system によるテキスト編集中は true となるreadonlyな属性
    • 後述する compositionstart と compositionend の間で発火したイベントなら true
  • Browser compatibility
    • MDN の Browser compatibility では(デスクトップの) IE, Safari で未対応と書かれていますが、検証環境の Safari 11.0.2 では KeyboardEvent.isComposing の値を取得することができました。
    • 検証環境の Microsoft Edge 41、IE11 では、KeyboardEvent.isComposing は undefined になってしまうようでした。

将来的にはこちらを使うと良いのだろうけど、IE, Edge で未対応なのでまだ使えそうにはないですね...

InputEvent.isComposing

InputEvent.isComposing - Web APIs | MDN

  • text composition system によるテキスト編集中は true となる readonly な属性
    • 後述する compositionstart と compositionend の間で発火したイベントなら true
  • Browser compatibility
    • MDN の Browser compatibility では(デスクトップの) IE, Safari, Chrome, Opera で未対応と書かれていますが、検証環境のOpera49、Google Chrome では InputEvent.isComposing を取得できた。
    • Microsoft Edge 41、IE11 では、KeyboardEvent.isComposing は undefined になってしまうようでした。

こちらも将来的にIMEによるテキスト編集中の InputEvent かどうかの判断にはこの値を使うと良いのだろうけど、IE, Edge で未対応だとまだ使えそうにないですね。

CompositionEvent

CompositionEvent - Web APIs | MDN

  • compositionstart: IMEによるテキスト編集開始時に発火
  • compositionupdate: IME で編集中のテキストが変更された時に発火
  • compostionend: IMEによるテキスト編集終了時に発火
  • MDN の Browser compatibility によれば Opera は未サポート、Safariは ? と書かれていますが、検証環境のSafari, Operaではイベントは発火するようでした。
    • ただし data 属性は未実装だったりする様子
  • InputEvent がIMEによるテキスト編集中のものかどうかを調べるには InputEvent.isComposing を使う代わりに、CompostionEvent を監視して状態を管理すると良さそう
var isComposing = false;

editorElem.addEventListener('input', function(event) {
  if (!isComposing) {
    // do something ...
  }
});
editorElem.addEventListener('compostionstart', function(event) {
  isComposing = true;
});
editorElem.addEventListener('compostionstart', function(event) {
  isComposing = false;
});

楽ちん

CompositionEvent/InputEvent の発火順序

詳しくは

IMEによるテキスト編集開始/編集中

event note
compositionstart 編集開始時
beforeinput
compositionupdate
ここでDOMが更新される
input

テキスト編集終了時

event note
compositionend
beforeinput
ここでDOMが更新される
input

このようなイベント発火順序となるのでIMEによるテキスト編集中の InputEvent は必ず compositionstart と compositionend の間に発火する、はず。

確認してみた

実験用スクリプトを書いて検証環境のブラウザで確認してみた

  • IE11, Edge41: テキスト編集終了時の input イベントが発火してないように見える？
  • Google Chrome, Safari, Opera: テキスト編集終了時の input イベントが compositionend の前に発火してる？

うーむ僕のスクリプトの書き方が悪いだけなのかな？詳しい人教えてください

CompositionEvent/KeyboardEvent の発火順序

詳しくは https://www.w3.org/TR/uievents/#events-composition-key-events

IMEによるテキスト編集開始/編集中

event note
keydown
compositionstart 編集開始時
compositionupdate
keyup

テキスト編集終了時

event note
keydown
compositionend
input
keyup

確認してみた

またもや雑に実験用スクリプトを使って検証環境で調べてみる

  • Firefox: 最初の方でも書いたけどIME編集中はkeydown/keyupイベントが発火しない https://bugzilla.mozilla.org/show_bug.cgi?id=354358
  • Safari: テキスト編集終了時keydown が compositionend の後に発火してる(このときの keyCode は 229)
  • Edge: テキスト編集終了時に keydown も keyup も発火しない

現状だとブラウザ実装によってイベント発火順序が結構違うみたいですね...あまり使うことはない気がするけど、ブラウザ間のイベント発火順序の違いを吸収するためのworkaroundは Handling IME events in JavaScript – Not Rocket Science に詳しく書かれていて良かった。

参考

まとめ

現状だとブラウザ互換性を考えると結構複雑ですね、2017年になっても日本語入力はやっぱり難しい。