タグ

ブックマーク / qiita.com/naoya@github (11)

  • 無限リストによるエラトステネスのふるい - Qiita

    Elixir では Stream モジュールを使って、遅延評価と無限リストを扱うことができるがそれによりエラトステネスのふるいを、Haskell と同じように無限リストを使った記述ができるか・・・というのが今回の試み。結果としては、カッとなれば、できる。 以下、Stream の解説も交えてお届けする。 Enumerable プロトコルと Enum および Stream Elixir の Enum モジュールには map/2 や filter/2 や zip/2 など、コレクション操作に必要な関数が多数実装されている。以下はそのドキュメントの例である。Functions のところに Enum の関数が列挙されているのが分かる。 ちなみにこのドキュメント閲覧は Dash の画面。自分は主に iOS 開発のドキュメント閲覧によく使っているが、見ての通り Elixir のドキュメント参照にも便利。

    無限リストによるエラトステネスのふるい - Qiita
  • Elixir の Emacs でのコード補完を auto-complete で - Qiita

    alchemist のコード補完 Emacs で Elixir 書くには elixir-mode に加えて alchemist を使うのが定番。 alchemist は "Elixir Tooling Integration Into Emacs" ということで、Emacs の中から Mix や IEx を使えるようにしたり、ドキュメントを引けるようにしたりいろんなインテグレーションをしてくれる。 Mix integration Compile & Execution of Elixir code Inline code evaluation Documentation lookup Definition lookup Powerful IEx integration Smart code completion Elixir project management Integration w

    Elixir の Emacs でのコード補完を auto-complete で - Qiita
  • Elixir と Reactive System に関する考察 - Qiita

    Reactive Manifesto の印象 正直 Reactive Manifesto を初めて読んだときは、Akka や Erlang についてよく知らなかったし「何か変わったことが書いてるか?」ぐらいの感じではあった。 しかしながら先日発表のあった Typesafe Reactive Platformで作るReactive System このスライドを見て、ようやく自分の中で具体例との対応付けができた。 Reactive System ・・・ Scala の Akka と Erlang, Elixir 引用するが、スライドでは「Reactive System の価値」として Reactive Manifesto にある Elastic / Resilient / Message-driven / Responsive を以下のように位置づけ整理している。 そして Scala 界隈で

    Elixir と Reactive System に関する考察 - Qiita
  • Elixir のバイナリデータに対するパターンマッチで AIFF を解析する - Qiita

    バイナリに対するパターンマッチでバイナリを分解 Elixir のパターンマッチはバイナリデータに対して利用することが可能で、実際、なかなか実用的である。 例えば 4バイトずつ整数と文字列が連続して埋まっているバイナリがあったとすると <<size::unsigned-integer-size(32), id::bitstring-size(32)>> = some_data というパターンマッチを書くと、size と id という変数にそれぞれの値が束縛される。Ruby だと unpack を使ってその辺のバイナリを弄ったりするが、それよりもずっと簡潔且つ宣言的に記述できるのが良い。 AIFF のバイナリを Elixir でいじる とはいえ、なかなかバイナリをいじる機会はないのでこの折角の機能を試す機会がなかったのだが、つい先日たまたま RubyAIFFファイルをいじるスクリプト書いた

    Elixir のバイナリデータに対するパターンマッチで AIFF を解析する - Qiita
  • Elixir のプロセスを使ってフェイルセーフなアプリケーションを作る ─ 失敗は恐れず泥水にダイブ - Qiita

    [翻訳] Elixirのプロセスアーキテクチャ または私は如何にして心配するのを止めてクラッシュを愛するようになったか にもあるように Elixir においては例外処理は、それを頑張ってなんとかしようとするのではなく、軽量プロセスのコンテキストでむしろすすんでクラッシュさせてしまえ、というのが良い作法である。 クイズ番組で ○ か × か答えを選んで壁に突っ込んだ先に、正解ならクッションが、不正解なら泥水があるという企画があるが、それに喩えるなら 泥水だろうが何だろうが躊躇せずダイブしろ! というのが Elixir 流 (俺調べ) である。 もとい、クラッシュさせてどうするのかというと Supevisor を使って、別プロセスから該当プロセスを監視しておいて、クラッシュしてもアプリケーション全体としては間違いなく動いている状態を保証するのが正しい。 カッとなってちょっとそのための例を書いて

    Elixir のプロセスを使ってフェイルセーフなアプリケーションを作る ─ 失敗は恐れず泥水にダイブ - Qiita
  • 『Programming Elixir』より "Think Different(ly)" - Qiita

    あの Dave Thomas が書いた『Programming Elixir』を買ったのでぼちぼち読んでいる。 Chapter 1. に Elixir の特徴を巧みに表現した文章があってカッとなったので、引用しておきたい。 Object orientation is not the only way to design code Functional Programming need not be complex or mathematical. The foundations of programming are not assignments, if statements, and loops. Concurrency does not need locks,semaphores, monitors, and the like. Processes are not necessaril

    『Programming Elixir』より "Think Different(ly)" - Qiita
  • Elixir のパターンマッチを攻略しよう - Qiita

    Elixir にあって RubyJavaScript のような言語にない特徴といえば 軽量プロセス (+ OTP周り) パターンマッチ の2点が大きく、その他の部分というのはだいたい「あの言語のこれだな」という風に対応させて理解できる(パターンマッチを実装した他の関数型言語になれてる人にとっては別かもしれないが)。 特に後者のパターンマッチの方は Elixir の文法の多くの部分の基礎になっている。従って、主観的にはパターンマッチさえ理解できれば Elixir の半分以上は理解できたと思っていいんじゃないかと思っていたりする。 というわけでカッとなってパターンマッチについて書いてみる。 パターンマッチとは パターンマッチの例で、いきなり {x, y} = {1, 5} とかいう例を見せられても「変数扱うのに便利な記法か何かですかね? (ES6 の Destructuring assi

    Elixir のパターンマッチを攻略しよう - Qiita
  • Elixir の OTP (GenServer 編) - Qiita

    [翻訳] ElixirにおけるOTPの紹介 という記事が上がってた (いつも翻訳ありがとうございます) のでそれに触発されて勢いで書いてみる。 ちなみに今後発売される Web+DB PRESS Vol.88, 89 の連載では2回続けて Elixir の記事を書いているよ。 もとい Elixir 状態を扱うにはどうするのが定番か 軽量プロセスを使ったクライアント/サーバーのありがちな実装 それを GenServer を使うとどう書けるのか GenServer 使うとどんないいことがあるのか あたりを解説してみる。 Elixir のプロセスで状態を扱う Elixir で状態を扱いたい場合は軽量プロセスの仕組みを使って、プロセスの中に状態を閉じ込めて、そのプロセスとのメッセージパッシングで状態への操作を行うのが定石である。 その例として、例えば key + value を保存できるプロセスを作

    Elixir の OTP (GenServer 編) - Qiita
  • Elixir のリスト内包表記でクイックソート - Qiita

    Elixir にはリスト内包表記という記法があり、これを使うとリストに対して 任意の条件でフィルタリング 別の値へのマッピング というよくある操作を簡潔に記述できる。 http://elixir-ja.sena-net.works/getting_started/18.html 例 iex> for n <- 1..10, rem(n, 2) == 0, do: n * n [4, 16, 36, 64, 100] これは 1 〜 10 の値のうち偶数の値の自乗を求めている。このように Elixir ではリスト内包表記は for で始まる式になるようだ。 このとき n <- [1 .. 10] が生成器 (generator) : 入力になるリストの指定 rem(n, 2) == 0 がフィルタ : リストに対してこの条件でフィルタリングする n * n が構築子 (constructor

    Elixir のリスト内包表記でクイックソート - Qiita
  • React 雑感 - Qiita

    3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄を解消する。また結果的にテスタビリティを高める あたりだろうか。 React というと最初に目につくのは VirtualDOM だけれども、VirtualDOM は 1 や 3 を達成するために障害となった技術的課題を解消するためのテクニックであってそれ以上

    React 雑感 - Qiita
    clavier
    clavier 2015/03/18
  • Go の変数初期化に伴う条件分岐をもっと良い感じに書きたいと思ったが諦めるしかないようです - Qiita

    Go にはスクリプト言語でいうところの variable = a || b のような構文や三項演算子がないようなので、 var accessKeyId, secretAccessKey string if config["aws_access_key_id"] == "" { accessKeyId = os.Getenv("AWS_ACCESS_KEY_ID") secretAccessKey = os.Getenv("AWS_SECRET_ACCESS_KEY") } else { accessKeyId = config["aws_access_key_id"] secretAccessKey = config["aws_secret_access_key"] }

    Go の変数初期化に伴う条件分岐をもっと良い感じに書きたいと思ったが諦めるしかないようです - Qiita
    clavier
    clavier 2014/09/14
  • 1