2017年12月

こんにちは、しきゆらです。

今回は、DOMの変化により発火するイベントを知ったので、使い方をメモしておきます。

やりたいこと

DOMの数を数えて、数を表示したい。

というのも、最近のライブラリとかならば出来るんだろうけど素のJSでなんとかできないのか、と思って調べてみるとうっかりありました。

その名も、Mutation events！！

Mutation events – ウェブデベロッパーガイド | MDN

しかし、どうもこれは推奨されておらず代わりに使うものを教えてくれていますね。

MutationObserver

今回の本題。

これをつかうと、DOMの変更を検知して特定の関数を実行する事ができます。

といっても、基本的なものはMDNさんに使い方があるのでそっちもどうぞ。

MutationObserver – Web API インターフェイス | MDN

使い方

基本的には、newでインスタンスを作るだけですね。

// 監視するObserverを作る
let mutation = new MutationObserver(function(){
  console.log("dom change!!");
});
// 監視対象
let target = document.getElementById("hoge");
// 監視するものを指定
let config = {
  children: true,
  subtree: true,
};

// 監視開始
mutation.observer(target, config);

これにより、監視対象に変化があればnewした時に渡したイベントを実行してくれます。

変化の監視というのは、属性・文言・子要素等指定ができます。

必要なところを監視できますよ。

[table id=9 /]

基本的に、これらを連想配列で渡してあげればいけます。

childList、attribute、characterDataにはtrue/falseを指定するだけ。

簡単ですね。

これで、監視対象に変化があれば特定の関数を実行できるようになりました。

Reactさんの真似事が出来るかもしれませんね。

今回は、ここまで。

おわり

こんにちは、しきゆらです。

先日、とある用事があり北の大地から東京へ遠征に行っていました。

ただ行くだけではもったいないと思い、日程の中で参加できそうな勉強会がないかと探していたら、

ちょうど興味があったけど、あまり触れていないElixirに関する勉強会「tokyo.ex #8」と言うものが開催されていたので参加してきました。

ちなみに、Elixirに関する私の知識とは、このブログに書いてある事程度なので、どんなレベルかはお分かりいただけるかと思います・・・。

しかし、参加するのは勉強会。

勉強できればいいな、という軽い気持ちで参加してきました。

スライド等は上記リンクやハッシュタグから見れるため、各セッションタイトルとそれぞれのメモを少しまとめておきます。

Hot code upgrade in ACCESS

Erlangの仕組みであるhot code upgradeを仕事で使ってみました、というもの。

個人的にはErlangやElixirと他の言語との大きな違いであり、積極的に利用されているのかと思いきや

偉い人曰く、「使わない方が良い」機能なんだとか。

しかし、サーバをいちいち止めずに入れ替えができることや、何度もデプロイする時のコスト等を考えると使えたほうが良いかも。

そこで実際にコードを見たり、書いたりしながら仕組みを解読してみました、という話でした。

正直、内部構造やコードをろくに読めない状態でしたが

わかりやすい解説とデモのお陰で、使わない方がいいという理由、使うための工夫を知ることができました。

わからない言葉やコードが出ていても、デモと説明で雰囲気をつかめました。

AlchemistのためのCrystal

ElixirはErlangの文法にRubyっぽいアクセントを加えた言語です。

というような導入から入るようなサイトがいくつかある。

Crystalも同じようにRubyっぽい構文で書けて、型があって、速い言語らしいです。

・・・名前は知っていましたが、トップページにあるクリスタルの画像をギュン！ってやって遊んだ記憶しかない。

まさかElixirの勉強会でCrystalの話が聞けるとは思いませんでした。

内容としては、Elixirの得意不得意な部分とCrystalのそれはお互いに補えるはず。

そして、これらの言語を触れている人は、たいていRubyもかけるだろうし学習コスト低いかも。

だからどうでしょうか、という感じ。

CrystalがいかにRubyっぽく振る舞うように工夫しているのか、まだ正式リリース前なのでバグを踏むことがあって楽しいらしいです。

ここまでが、メインとなる２つのセッションでした。

これからはLTで数名の方たちが話をしてくれました。

Elixirのテストフレームワークっぽいものを作ってみた話

https://hex.pm/packages/struct_assert

Elixirの場合「＝」は代入ではなくパターンマッチ。

その為書き方が少し面倒になってしまう。

もう少しなんとかならないかな、と思い勉強がてら作ってみました、というお話。

この中で少し出ていた、CPAN Testerの話が印象に残っています。

# 本編じゃないん・・・？

これは、Perlの世界のお話で、Perlの各バージョンでライブラリが動くのかどうかを有志の人たちがテストして共有してくれるシステムのようです。

ライブラリを使おうとしてうまくいかない場合、Perlが悪いのか・自分の環境が悪いのかわからないことが多い。

そのためにこういう仕組みができたんだそうな。

Perlから影響を受けた言語はあるが、この仕組は引き継がれていないようで、もっと広まってほしいそうです。

# 実際、何度か困ったことがありました。ほしいですね。

Elixir(erlangVM)のメトリクスを監視したお話

この話は、内部構造を監視したい。

そこで便利なライブラリがありますよ、というお話。

正直、この辺のお話は全くわからず、スライドに出てきた画像をみて「へぇ」と思った程度しかありませんでした。

知識がないと、面白い話も面白くならないのは悲しいです・・・。

このお話の中でPromQLと言うものが出てきました。

フローチャート的なサムシングを書くための言語なのでしょうか。

柔軟なグラフを書くことが出来るので、おすすめ、とのこと。

ライブラリ作って♡

外部に公開するライブラリと、自分たちが作るためのライブラリ。

それぞれをどう作るか、というお話。

実際にライブラリを作ろうと思ったら、おそらくみんなが使えるような一般的な機能を持つものを作成し公開すべきだろう。

そして、公開したライブラリを自分たちてまとめたり手を加えたりするのがいい流れなのではないか、というお話でした。

あと、Elixirはまだまだライブラリが少なく、みんなで作って盛り上げようね、というメッセージで締めくくられました。

ヾ(〃l _ l)ﾉﾞ

Elixirを使った繊細なチャットを作ってみる

Elixirさんは安定したサービスを作る事ができる。

そして、アンチパターンというかやらないほうが良いこと・やってはいけないことが存在する。

でも、それらは実際にやってしまった場合どうなるんだろう・・・？

ということで、アンチパターンを盛り込んだアプリを作ってみました、というお話。

この発表は、面白い発想だな、と思いました。

やってはいけないことをあえてやってみることで得られることがある、たしかにそうですね。

このアプリ、Githubで公開されているので自分で触ってみることもできます。

まさに、Elixirでアプリ開発を行う際の避難訓練や〜(彦麻呂風)

とか思いながら聞いていました。

自作ライブラリの紹介

Elixir書き始めて、色々ライブラリ作っていました。

Elixirでお仕事したい、いいねこれ。というお話。

私も幾つか言語は触ってきましたが、ライブラリって雲の上の人たちが作っているイメージでしたが

自分が便利と思った機能だったり書き方だったりを共有するようなイメージなんでしょうか。

Github等のお陰でこのような共有が簡単になったので、いろんなコードを読めるようになった、と言うのはよく聞くお話です。

自分の書き方や作り方を共有して意見をもらったり、賛同してもらったりしながら開発を進めていく、と言うのは面白そうだな、と思った次第でした。

発表はここまで。

この後、プレゼント争奪じゃんけん大会が開催され勉強会は終了しました。

惜しくも、得られるものはありませんでした・・・、残念。

しかし、やはり勉強会に来る人や発表者の方たちはモチベーションが高いというか、楽しんでいるような印象を受けました。

あのような場でワイワイ学び合うと言うのはとても楽しいですね。

自分のやる気ももらえたような、そんな勉強会でした。

それと、

ということにつきますね。

こういうイベントが多いのはやはり東京、いい環境だなと思いました。

また参加したいですね。

今回は、単なる感想でした。

地元でもないのかしら、調べてみましょう。

おわり