SF(すごくふつう)なブログ

記録・メモ・自己啓発・他

SerfをAWSで使った

serfとは

serfdom.io

クラスタ管理用のツールです。クラスタ全体にメッセージ送信を行ったり、クエリーを実行することで各ノードの色々な情報を収集したりすることが出来ます。

serfの持っている機能としては、

  • クラスター形成機能
  • ノードに対するイベント通知機能
  • ノードに対するクエリー実行機能(クエリーを実行すると、各ノードにイベントが通知され、なおかつそのイベントの実行結果を収集することができます)

といったものがあります。

今回やりたかったこと

あるアプリケーションの動作に問題が発生していました。

  • 問題の動作

    • アプリケーションがメモリリークを起こしており、long runningさせると一定時間経過後(350時間経過後)ランダムにOutOfMemoryを起こしてアプリケーションが終了してしまう
  • 期待する動作

    • (A) アプリケーションがOutOfMemoryを起こす前に再起動させ、メモリリークをリフレッシュする
    • (B) アプリケーションは複数のサーバーで動いていて、それぞれのアプリケーションは排他的に再起動する

期待する動作Aは何かしらのプロセス監視ツールで実現できますが、Bはよくあるツール(例えばcron)でやろうとすると非常に手間がかかります。今回は上記のBをシンプルに実現するため、また技術的な興味からserfを使うことにしました。

続きを読む

HackerNewsつまみぐい 2015/8/9

Erlang関係のスレッドがチラホラとあった1日でした。

元記事はBEAM(=ErlangVM)についての専門家の紹介とQAっぽい内容です。ただコメント欄はBEAMとJVMの比較で議論が伸びてますね。

元記事はErlangをいく選択すべきか?という内容。CPU負荷が高いのには向いていない、レイテンシースループットが必要な場合は向いているとErlangの本を読むと書いてある内容が羅列されていますが、向いていない項目の中にGlue-together style web applicationというのがあります。Railsっぽいアプリ(つまりDBとフロントがガッツリくっついてる=Glue-together?)はやらん方が良いと書いてあります。

対してHNのコメントで、下記のようなやり取りが行われています。

 
ffn 16 hours ago

    >Erlang is not good for Glue-together style web application
    Granted Elixir's Phoenix framework is not Rails level yet, it's system of plugs and heavy inspiration from rails actually makes it quite useable as a replacement for rails. Also immutability and the associated smaller memory footprint makes it more feasible to run cheaply on services like heroku or aws. Personally, I think elixir is a good boat to jump on to carry us over to the next world of web development.
    reply
    
    ElixirのPhoenixフレームワークはまだRailsのレベルには達していない。(少し略)Elixirは我々を次のWeb開発の世界へと連れていってくれる良いボートだ。
    
    troutwine 14 hours ago

        I wrote this article way back in 2013. Initial commit of Phoenix was Jan 18, 2014.
        But! you're quite right. Elixir is focusing on the web application type things that Erlang and the community around it has never much addressed. There's enough interoperability from Elixir to Erlang that you could probably say the ecosystem as a whole is addressing the problem if you squint hard enough.
        Side comment, it's been interesting to see Elixir grow since 2013. A lot of folks learn Elixir and then Erlang but I think it's less common to learn Erlang and then learn Elixir. It's led to an interesting situation where Elixir has had to bootstrap knowledge about OTP on its own terms without a large pool of domain experts sitting around. The asymmetry in knowledge--knowing Erlang does not imply knowing Elixir but knowing Elixir implies knowing Erlang--also makes me wonder how the squinting assumption above will shake out long-term. ¯\_(シ)_/¯
        
        (前半部分略)
        (だいたいの訳)
        - 多くの人がElixirを学びErlangを学ぶ、ただErlangを学びElixirを学ぶ人はあまりいないのではないか
        - それはOTPを、Elixir自身の言葉でさらにその領域の熟練者たち抜きで乗り越えるという面白い状況が生まれるのではないか

なるほどね、という感じです。僕もElixirはまだチラッとしか見ていないのですが、OTPの各ビヘイビアをElixir側でラップして提供していたりします。(AgentやTask.Supervisor) ElixirユーザーがOTPを意識せずに使えるようになるとより敷居が低くなって普及が進むのかもしれません。

Rustでスクリプト言語を作ってみようとする (2) - 字句解析部分

字句解析の部分

メモ

v2

  • enumに諸々のパラメータを持たせるのはやめる(パターンマッチを簡単にできるようにする)
  • マクロが便利そうなので積極的に使う

v1

ちゃんとできたら説明のようなものを書いてみたいと思うのですが、とりあえず今は書いてみたという進捗報告のみ。

token.rs

gist6160bb87695ea22afae3

tokenizer.rs

gist377346c4e24c7a5cccde

Rustでスクリプト言語を作ってみようとする (1)

Rustでスクリプト言語を作ってみようと思います。

その進捗報告および備忘録をつけていきます。

想定しているゴール

  • Rustで実装されたスクリプト言語の処理系が存在する
  • 字句解析・構文解析VMについてはライブラリを使わずにハンドメイドで実装されている
  • ユーザーがコマンドラインから操作するための何らかのバイナリが存在する

モチベーション

  • Rustの可能性を引き出したい
  • 言語処理系の中身を知りたい

考えている言語

正直はじめてこういった言語処理系を実装してみようとしているので、あまり奇抜なことはできません。なので、基本的に次のような言語を想定します。

  • Luaっぽいプロトタイプ指向言語を目指す

    • Luaソースコードyaccのようなパーサジェネレータを使わずに書かれているので、参考になると考えたため。
    • プロトタイプ指向の言語に興味があるため。
  • Luaの文法をできるだけ簡略化し、自分が実装可能な範囲で制限を加える

    • 実装しきることが現在の第一目標なので。

筆者の能力的な部分

情報系の授業は受けたことがありますが、コンピューターサイエンスを学んだ人間ではありません。ましてや形式文法や構文解析について専門的に学んだ経験もありません。そのような凡プログラマが私です。

当ブログのコンテンツの引用は自由です。