はてなブックマーク

皆さん、家計簿つけてますか？僕は何度もつけようと試みたことはあるのですが、その度に諦めて来た口です。 諦めた原因というのは一概に 面倒くさい からなんですよね。 同じ理由で諦めた方も多いのでは無いかと思います。人類の中で僕だけ怠惰ということでないよう、ぜひそうあってほしいです。 ただ、怠惰はプログラマの 三大美徳と言われていますので、毛頭改善する気はないです。 そこで、何が一番面倒くさいのかを考えたところ、費用のカテゴライズなのかなと思っています。 僕は家賃を除く月々の出費の 9割ほどがクレジットカード払いなので、どこどこに対していくら払ったかというのは比較的簡単にわかります。 それで、家計簿とかで良くある円グラフとか線グラフとかを可視化したいのですが、ここでカテゴライズされていないことが大きな問題になります。 そこで本記事の目的は、支払先と支払金額を元にして、その出費のカテゴライズを行う

はじめに WEBアプリケーションでフロントエンドの開発をしていると、グラフ表現 （※離散数学のグラフではない、線グラフや棒グラフを指しています） を組み込みたいことが出てきます。 しかし、グラフは一般的にスクラッチで作成すると大変なので（軸の設定とか線の見やすさとか、考えることが多いです）、既存のライブラリを使用して、設定や css で少しいじるくらいで上手いこと綺麗に表示されて欲しいです。 そこで、 chart.js を angular で作られたプロダクトに組み込む方法を考えます。 書いてあることと書いていないこと 書いてあること angular（>= 6.0.0） で作られたプロダクトに chart.js のグラフを組み込む方法 （おまけ）angular（>= 6.0.0） で作られたプロダクトに vis.js のグラフ（離散）を組み込む方法 書いてないこと chart.js や v

はじめに 以前、「GCP で Autoscaling Groups を使う」という記事で、インスタンスグループからオートスケーリングを設定する方法をご紹介しました。 あれからおよそ 10ヶ月が経ち、docker を始めとするコンテナ化が主流となりつつありますので、docker に対応したオートスケーリングの方法を書きます。 対象読者 GCP をコマンドラインツールから操作したことがある人 GCP上でシステム（またはアプリケーション）を完結させたい人 docker を用いた開発・運用経験のある人 kubenetes を触ったことがあるか、英語のドキュメントに抵抗がない人 おさらいと課題 前回の手順を確認すると、おおむね次のような手順をたどるとオートスケーリングが設定できていました。 インスタンステンプレートを作成 マネージドインスタンスグループの作成 オートスケーリングポリシーの設定 言葉に

2年ほど前に elasticsearch-rails検証 という記事を書いたのですが、今でもたまにいいね・ストックしてくださる方がいるので、その後どう運用しているかの続きを書きます。 目次 結局採用したの？ どういうコンセプト？ 設定方法は？ 困ったところある？ 結局採用したの？ 目次に 4つ項目が並んでいる時点でお察しですが、採用しました。 どういうコンセプト？ 前回、複数モデルにまたがるクエリ のところで、 そもそも authors に関する情報も article の index として保存してしまうと、authers の index を作成するときに情報が重複することになるので、index の更新時間が単純に考えて重複した index分だけ増えます。 なのでこういう使い方は、仮にできたとしてもアンチパターンまっしぐらかも知れません。 と書いたのですが、若気の至りと言いますか、RDB

はじめに 弊社では GCP（Google Cloud Platform）上の GKE（Google Container Engine）を使用して幾つかのサービスを提供しています。docker を使う理由というのは以前にも何度か（Appendix参照）書いたので、そちらを参照していただければと思います。 付け加えるとすれば、環境の差異を吸収してくれるし、pod が落ちたら勝手に生き返らせてくれるし、デプロイするのにダウンタイムとかエラーとか気にしなくて良いし（これは後述します）、控えめに言って後戻りはしたくないです。 とは言うものの、まだ日の浅い技術なので運用していくと色々と問題が出てきます。 そこで、わりとクリティカルな表題の問題に当たったので、自身への備忘の意味も込めて書いておきます。 想定読者 docker に関する基礎的な知識を有している人 kubernetes を触り始めた人 GC

Google Coloud Platform には、負荷に応じてインスタンス数を自動的に増やしてくれる機構（Autoscaling）があります。 Autoscaling（オートスケーリング）機能を使用するためには、以下の条件を満たす必要があります。 Managed instance groups（管理されたインスタンスグループ）であること Autoscalingポリシーと target utilization（対象使用率）が定まっていること Managed instance groups（管理されたインスタンスグループ）であること Google Compute Engine（以下 GCE）では、インスタンスの集合を定義することができます。 これは、インスタンスグループと呼ばれ、例えばロードバランサに繋ぐときにこの単位で管理することができます。 インスタンスグループには 2種類あって、1つは

表題の通りですが、本記事では次の事項は扱いません。 gatling の使用方法 目的 テレビ露出時にかかる負荷をある程度予測しておくことで、それにかかる費用をできるだけ小さく留めること（最小化とは言いません）。 最小化しようとするとギリギリのラインを攻めるためにかなり厳密に見積もらないといけなくなりますが、そうすると人件費の方が高くつくので本末転倒です。 その計算をするのに僕のリソースをもって 1日かかるなら、1〜2万円多く AWS や GCP に献上した方が他の仕事も進められてみんな幸せです。 従って、本記事での検証は比較的ざっくりです。 構成 本試験は、以下の様な構成のアプリケーションを対象に行います。 AWS 特に特筆すべきことのない、標準的な構成です。 DNS とかはあまり関係ないので抜いています。 Amazon ELB Amazon EC2 Amazon RDS（MySQL、マス

タイトルの通り、『なぜベンチャーで docker を使うのか』の続編です。 弊社の代表が NHK の某番組に出演させていただく機会がありまして、実はこんなことをしていました。 gatling による負荷試験とテレビ露出見積り GCP で Autoscaling Groups を使う 前者はあまり関係ないのですが、後者に関して docker を使っていると便利そうだな、というケースがあったので、ごく短い記事ですが続編として投稿します。 さて、後者の記事で、Managed instance group の作り方 という節を書きました。 記事中ではイメージからインスタンスグループを作成する、という方法を紹介していますが、実はここで docker形式のイメージをマウントすることができます。 ここで考えたいのは、dockerイメージを使用しない場合の autoscaling の運用です。 記事中で紹

昔話 僕が機械学習を学び始めた頃は、そもそも github なんてものはなくて、 ネットに落ちてるソースを落として来てコンパイルして「あー、よくわかんないけど動かない・・・」 となるか、「あー、よくわかんないけど動いた・・・」となるかどちらかでした。 そうでなければ、自分で拙いコードを書いて、どこまで正しく実装できているかわからない （計算機科学的に効率の悪いコードだったことは間違いない）コードで実験していました。 ところが最近は、あまりに複雑な理論の実装であっても、たいていは github にあがっているのです。 そして github に公開されるということは、使い方が明示され、かつ誰でも使えるように 平易なインターフェースが容易してあります。 Jubatus はまさにそんなフレームワークで、複雑な理論を一切知らなくても機械学習ができてしまう夢の様なものです。 http://jubat.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昨年ごろから急に docker って流行り出しましたよね。 https://www.docker.com/ 僕も docker のチュートリアルをひと通りやってなんとなくコマンド覚えたんですけど、chef で良くない？ってなって結局使わずじまいでした。 ただ、最近になって、ちょっと思い直している部分があって、 Docker は Kubernetes 使ってこそだろーと思って勝手に自社サーバ持ってる企業だけが恩恵にあずかれると思っていたのだけど、その管理はクラウド屋さんに任せて dockerfile 書いておけば dev/stg/prd

はじめに WEBアプリケーションの中で、検索機能を付けたくなることありますよね。 普通に考えたら、検索エンジン用のサーバーを構築して、そこに solr なり elasticsearch なりを入れて、Rails から httpリクエストを飛ばして・・・ってやれば良いと思うんですが、Rails のモデルと elasticsearch のドキュメントの対応関係を考えたり、 その周りの設計をしたりと結構手間がかかります。 うーん、もっとこう、モデルとドキュメントが一対一くらいの感じで対応してくれて、使いやすいやつないかなぁー というわけで、こちらの gem の検証です。 elasticsearch-rails よく見たら elasticsearch の公式リポジトリでしたね。 elasticsearch は公式サイトからダウンロードしてきて、適当に設定しておいてください。この記事では説明しません

Cassandra とは？ Cassandra は 2008年に Facebook によってオープンソース化された分散型KVSです。 Amazon Dynamo の作者の一人である Avinash Lakshman と、Facebook のエンジニアである Prashant Malik によって設計されました。 Cassandra は、高可用性（High Availability）を持ち、コモディティハードウェアやクラウド基盤上で線形スケーラビリティ（Linear Scalability）と耐障害性（Fault-Tolerance）を提供します。 誤解を恐れずに平たく言えば、 ノードに障害が発生してもサービスを提供し続けることができ、 ノードを追加することで線形に性能が向上し、 通信障害などによってメッセージが損失しても継続してサービスを提供する ということです。 分散コンピューティングに