サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
sharply.hatenablog.com
HaskellはWebフレームワークだけでもYesod, Snap, Happstackといった重厚長大型のフレームワークに加え、軽量なもの/API向けのものでもSpock, Scotty, Servantなど乱立しているが、Template Engineとて例外ではない。Blaze-html, shakespeare, mustache, stache, ede, lucid, heistなどこれもまた様々存在し、特にSpockやScottyといったフレームワークではテンプレートエンジン選択の自由度が高いので、どれを使おうかと思い、調べたのでここにメモを残す。 Template Engine stache Mustache ede lucid blaze-html shakespeare heist Template Engine stackoverflow.com stackoverf
tl;dr それぞれのプロセスがどのぐらいのメモリを使用しているかを知りたい。 コマンドで確認する システム全体のメモリ使用量を確認する cat /proc/meminfo linuxではデバイスもプロセスもファイルとして扱えるので、catできる。 MemTotal: 8073996 kB MemFree: 333772 kB MemAvailable: 4262036 kB Buffers: 600280 kB Cached: 3386552 kB SwapCached: 0 kB Active: 4668596 kB Inactive: 2382920 kB Active(anon): 3061940 kB Inactive(anon): 286724 kB Active(file): 1606656 kB Inactive(file): 2096196 kB Unevictable:
tl;dr React-NativeでiOSやAndroidのネイティブアプリを作る際、自分が使った中で便利だったUIに関するライブラリをいくつか紹介する。 探し方や導入方法など github.com ここにReact-nativeに関連する様々な情報がまとまっており、その中にライブラリも多数収録されている。 依存がjavascriptだけのものはnpm install --saveすればよい。一方でコンパイル時に組み込まなければならないものは、GithubのReadmeなどに説明があると思うが、最近ではrnpmを使う、あるいはreact-native link <packagename>といったコマンドでプロジェクトに自動で組み込んでくれるようになっているので、手動で各ファイルに追記するよりミスを防げるので安全であると言えよう。 react-native-gifted-chat(旧 re
tl;dr Kerasという機械学習のフレームワークのサンプルにあるLSTMを使い、テストコードを生成して、それをもとにテスト駆動開発してみた。 Kerasを試してみる 以前、紹介記事を書いたのでそちらを参照していただけると幸いです。 sharply.hatenablog.com また、MLPを使った文の分類については以下の記事をご参照ください。 sharply.hatenablog.com ソースコードを生成してみる Kerasのexamplesに含まれているlstm_text_generation.pyを使って、文を生成してみることにチャレンジしてみたいと思います。ここではLSTMという構造が使われていますが、LSTMについては別の記事で少し紹介したので、そちらとその参考ページを参照いただけたら幸いです。 sharply.hatenablog.com さて、元のコードではニーチェの文書
はじめに 機械学習、特にディープラーニングが近頃(といってもだいぶ前の話になりますが)盛んになっています。CaffeやChainerといったフレームワークもありますが、特にGoogleがTensorflowでtensorboardと呼ばれる簡単に使える可視化基盤を提供して有名になったのを機に、Tensorflowで機械学習を始めてみたという方も少なくないと思います。 しかしTensorflowは低レイヤーな行列演算、ベクトル演算を記述するには適していますが、機械学習モデルの記述という面では書きにくいことも確かで、何かが動いていることは確かめられたけれど自分で何かをするには敷居が高かったです。例えば、Tensorflowでsoftmax層を定義するには、以下のコードを書く必要があります。 # softmax, i.e. softmax(WX + b) with tf.variable_sco
前回の記事 sharply.hatenablog.com 本稿ではRaft, Bitcoinの Proof of Work, Proof of Stakeそれぞれのアルゴリズムについて説明する。 分散合意プロトコル Raft 難解であったPaxosより簡単であることを標榜しているアルゴリズムで、そこまで多くないノード数で、密結合なネットワークにおける分散合意が想定されており、Paxosではあまり触れられなかったリーダー選出手法についてはこちらの説明のほうが腑に落ちやすいと思う。実際にetcdなどで実装されており、ログレプリケーションなどで用いられる。 ここでは明確にプロセスは状態機械として扱われる。各リソース上のそれぞれのプロセスは本質的に平等であり、プロセスはLeader, Follower, Candidateの3stateのどれかを持つ。Leaderは交代する場合があり、それをter
tl;dr 分散合意プロトコルについてサーベイしたので、メモを残す。 2PC 3PC Paxos Raft(次回) Proof of Work(次回) Proof of Stake(次回) 分散システムについては素人の筆者が書いたため誤りが多いと思うので、できれば確認のため元論文を参照してもらいたいです。 introduction 基本的な定理, 用語 CAP定理: 分散システムは、一貫性 (Consistency)、可用性 (Availability)、分断耐性 (Partition-tolerance)のうち最大でもいずれか2つしか満たすことはできない。 レプリケーション: 一貫性を保ちながら、リソース間で情報を共有すること。 RPC: プログラムであるノードから別のノード上の関数を呼び出すこと。ここでは、ノードから別のノードにメッセージを送ることという理解でもたぶん大丈夫だと思う。
このページを最初にブックマークしてみませんか?
『sharply.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く