はてなブックマーク

世間の波に乗り、私もキーボードの自作をはじめました✌ 選んだキーボードは、左右分離型 Ergodoxインスパイア系の redox keyboard です。 MITライセンスで公開されているため、柔軟に弄れそうで良いなと思いこちらにしました。 (いずれフォークしてバツイチ・キーボードを作ろうという目論見もあり、、、) このキーボードを作成する上で、何が一番大変だったかというと、 とにかく、 ケース作成 です。 ようやく完成したケース↑です。 アクリサンデー 乳白色 3mmを切り出しました。 たかがこれしきと思われるかもしれませんが、私がレーザーカッターを舐めていたこともあり、ここまで数回の試行がありました。 (業者に発注した方が数倍楽安だった説があります…) 実を言うと… redox keyboard のケースは FalbaTech というサイトで購入することができます。 https://f

actix_web は Actor モデルを採用した Rust の web frameworkです。 「Actor モデルでwebリクエストを捌く」仕組みを雑に想像すると、 TCPリスナーがHTTPリクエストをメールボックスに貯め、それをワーカーであるActorが拾ってレスポンスを返す？ この仕組だと複数のActorで1つのメールボックスを共有する機構が必要になってきます。 しかし、Actorシステムを提供する actix にはこの機構はなさそうに見えます。 それに、恐らくこの仕組みでパフォーマンスを出すのは難しいでしょう。 そこで、actix_web がどのようにHTTPリクエストを捌いているのか、ソースコードを追ってみることにしました。 ※ 読み間違え等ありましたらコメント頂けると大変嬉しいです… 🙏 actix_web の構成 actix_web の依存関係を図示するとおおよそ下記

Jupyter Notebook 便利ですよね！ REPL感覚で使えるけれど、REPLより使い勝手良いし、セルごとに何度もやり直しできるし、リンクを共有すればコードもさくっと共有できます。 Scala にも spark-notebook や Apache Zeppelin などの ノートブック形式Webアプリケーションがいくつかありますが、いつも使っている Jupyter Notebook で Scala を動かしたかったので、今回 Jupyter Notebook のカーネルに Scala を追加しました。 この記事を書いた経緯なのですが、「jupyter-scala」 の名称が変わっていたりインストールの仕方が変化していたため、一旦まとめた次第です。 ※ この記事を書いているのは 2018.11.01であり、今後も変更の可能性は大いにあります。。。 Jupyterのインストール 既に

Erlang製のtsungというツールを使って負荷をかけました。 これは、複数のサーバをクラスタ化して負荷をかけることができるので、負荷側が先にパンクするケースを軽減できます。 パフォーマンス測定の前に actix_web 関係なく、 もはや Webサーバの基本と言っても良いのですが、actix_webを動作させるサーバと負荷サーバの両方で、 ulimit(システムリソース上限) と tcp系のカーネル・パラメータを調整します。 ulimit システムリソース上限を上限いっぱいに設定します。 /etc/security/limits.conf を編集します。 root soft nofile 65536 root hard nofile 65536 * soft nofile 65536 * hard nofile 65536 再起動します。 カーネル・パラメータ いくつかのカーネル・パラ

そんなに需要がないだろうなあ、と思いつつも、ちょっと面白かったので記事にしました。 Rust で書いたソースコードを Google製ビルド・ツール Bazel を使ってビルドします。 Rust の場合、通常であれば迷わず Cargo でビルドしたいところです。 しかし、多言語を扱う monorepo スタイルの開発であったり、C/C++ソースも一緒にコンパイルしたい場合、複数言語のビルドを一貫して行える Bazel という選択肢がでてきます。 (tensorflow/rust を使うときもですかね) 参考: 大規模ビルドシステムにおけるRustの扱いに関する議論 (ここでも議論されています) Bazel では、ビルドするためのルールを BUILD というファイルに記述します。 様々な言語向けのルールが既にたくさん用意されているので、BUILD にダウンロード設定を記述して使うことができます

会社の同僚に触発され、Rustの勉強も兼ねてSlackボットを作ってみました。 使ったライブラリなどを含めてご紹介させて頂きます。 ※ 作成時のRustのバージョンは1.15.1です。 全体像 構成はシンプルです。 cronで30分毎にSlackボット(Rust CLI)を実行します。 Slackボットは起動すると指定株価一覧が記載されたCSVを読み込み、そこに記載された株の価格情報をGoogle Finance APIに取得しにいきます。 前日の終値から3%以上上昇もしくは3%以上下落した株の価格をSlackにメッセージとして送信します。 ソースコードはこちらに公開しています。 https://github.com/x1-/finance ※ Google Finance APIの詳細はこちらの記事をどうぞ。 プロジェクトの作成 Cargoを使ってプロジェクトのテンプレートを作成します。

日本ではフリーでオンラインの株価取得APIが全然ありません。 オンラインで株価を取得しようとすると下記のような状況です。 Yahooファイナンスをスクレイピング -> Yahooファイナンスに禁止されている Google Finance API -> 公式ページに「今はもう使えないよ」 kabu.com API -> 法人向け。個人には未提供 楽天証券RSS, 岡三RSS -> アカウントとExcelが必要 k-db.com -> CSV。リアルタイム性はなし しかしGoogle Financeのドキュメントなし非公式APIが存在しており、こちらを使ってリアルタイムに株価を取得することができそうです。 https://www.google.com/finance/getprices?q=6420&x=TYO&i=86400&p=1Y&f=d,c,v,o,h,l&df=cpct&auto=1

今回から何回かに分けて、機械学習で日本酒の味のタイプのクラスタリングをする動画をやっていきたいと思います。 Part1はデータを取得するスクレイピング編です。 機械学習はまず、データを集めるところから始まります。 日本酒の銘柄マスタを作るために、こちらの日本酒物語のサイトからスクレイピングをかけて銘柄を取得し、日本酒銘柄CSVを作ります。 スクレイピングにはPythonのBeautiful Soupを使います。こちらはAnacondaをインストールすると、一緒に入るのでそれを使います。 スクレイピングするソースはこちら python２系 # -*- coding:utf-8 -*- import urllib2 import codecs from bs4 import BeautifulSoup f = codecs.open('sake.csv', 'w', 'utf-8') f.wr

Rundeck Rundeckとは簡単にいうと高機能なcronです。 cronと言われると、「サーバにログインしてcrontabで編集して…」というのを思い浮かべますが、Rundeckは違います。 Web GUIからスケジューリングします。 実行サーバとRundeckサーバは独立しています。 実行履歴がWeb GUI上から閲覧できます。 Rundeckの機能はまだまだ沢山あるのですが、cronと比較しながらRundeckを紹介していきます。 ジョブをスケジュールする cronはcrontabコマンドを使い、下記のようなcron書式でジョブの実行スケジュールを記述します。 SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ 10 * * * * /bin/which bash > /dev/null 2>

Java7 Update4 (java7u4) で正式サポートされたG1GC(ガベージ・ファーストGC)ですが、Java9ではデフォルトGCになることが確定しています。 参考: JEP248 またG1GCは、CMS GCを長期的に置き換えるものとして計画されています。 そこで、どのようなアルゴリズムなのか知っておいたほうが良さそうなので調査しました。 G1GCが向いているケース G1GCが向いているのは下記の環境です。 ヒープサイズが大きな環境(6GB以上) 一時停止可能時間がシビア(0.5sec未満) Oracleの 9 ガベージファースト・ガベージ・コレクタによると、CMS GCもしくはParallel GCを使っていて次のいずれかに該当したらG1GCへの切り替えを検討しましょうとのことです。 Javaヒープの50%超がライブ・データ(≒必要なデータ)で占められている。 オブジェクトの

分散TensorFlowでロジスティック回帰 -Distributed TensorFlow- その1の続きです。 前回TensorFlowでシングル・ノード版のロジスティック回帰を実装し、MNISTの分類を行いました。 今回はロジスティック回帰を並列実行します。 並列実行環境 並列実行環境として物理マシンを並べても良いのですが、お手軽にDockerコンテナを使います。 CentOS7にDockerを入れ、DockerHubからTensorFlowコンテナイメージを持ってきます。 yum -y install docker # dockerをサービスとして開始 systemctl start docker systemctl enable docker # DockerHubからtensorflowイメージをpull docker pull gcr.io/tensorflow/tensor

前回、Apache FlinkとはでFlinkの概要に触れたのですが、今回は実践的にkafkaと連携させ、Apache Zeppelinでアドホックに分析してみます。 Zeppelinを使うのは、単純に、jar作って実行するのが面倒だからです(^_-)-☆ 概要 fluentdでデータを収集し、Kafkaにデータを送ります。 Zeppelin上のnotebookからflinkの集計ジョブを実行します。 flinkジョブはKafkaに集約されたストリーミング・データを集計します。 というわけでfluentd, Kafkaをインストールしていきます。 ※ この記事ではCentOS 6.7 Finalを使います。またサーバ上ではrootで作業しています。 ※ また、jdkはopenJDKの1.8を使用しています。 fluentd, Kafkaインストール この記事ではfluentdとKafkaを

ストリーミング処理に本気で取り組む必要があったので Apache Flink を使ってみました。 Apache Flinkとは？ 分散ストリーミング処理エンジンです。 ストリーミングのみならずバッチ処理も行うことができますが、ストリーミングと静的データとを同じインターフェイスで扱うことができます。 分散システム 協調 フォルト・トレランス データ・ストリーミングにおける分散環境 を提供すると謳っています。 本体はScalaで書かれていますが、java, scala, python* のAPIクライアントが用意されています。 クライアントは一連のオペレーションをデータフローとして記述します。 公式URL: http://flink.apache.org/ 2016-03-08 メジャーバージョン(1.0.0) リリース。 2016-05-25 現在, 1.0.3。 Apache Flink

expressやるときにいつもちょうどいいサンプルが無いので、備忘録的な感じでgitに上げました。 ログイン認証する時用のSessionストレージにRedis使っています。 MySQLに接続する部分は、どっかからコピってきました。 gitのソースコードはこちら MVCと書いてありますが、REST APIなので、Viewがないです（サンプルでつけた程度） むかーし書いたPython bottoleの記事もどうぞー

Docker流行ってますね。 そんなわけでmacにDocker入れてmacのブラウザからDockerのnginxにアクセスできるようにしたいと思います。 Docker Toolboxというのがあるので、これでサクッとmacにインスコできちゃいます。 動画内で使用したコマンドはこちら Centosのイメージをダウンロードしてくる $ docker pull centos ダウンロードしたイメージ一覧 $ docker imagex コンテナを起動する ローカルのDocuments/dockerをdocker内の/dockerと共有フォルダとして、inkenコンテナという名前で立ち上げています。 $ docker run --privileged -td -p 80:80 -v /Users/inken/Documents/docker:/docker --name inken centos

IT業界で働くエンジニアです。名前の通りバツイチです。 理論や抽象的概念が好きだけど人に説明するのが下手。

ascii(e: Column) 先頭単語のasciiコードを数値型(Int)で返却します。 sql: select ascii( e ) as n from ... DataFrame: df.select( ascii( $"e" ) as "n" ) 例) eが”apple”だとしたら97が返ります。

この記事はApache Spark Advent Calendar 2015 22日目の記事です。 完成したTableauダッシュボード。 ことり隊というのはこれ↓のことです。 ゲームセンターにあるUFOキャッチャーのプライズです。 ゲームセンターにもいろいろ特徴がありまして、ことり隊が置いてあるゲームセンターとそうでないゲームセンターがあります。 ゲームセンターをしらみつぶしに回ってことり隊を探すのも大変なので、Twitterを利用してことり隊の入荷情報をキャッチすることにしました。 1. ゲームセンターのtwitterアカウント まずは東京都内のゲームセンターをリストアップしてtwitterアカウントを探します。 ゲームセンターのリストは 全国ゲーセン地図Wikiから取得しました。 ゲームセンターの名前からtwitterアカウントを探しました(※ここは手動(；´∀｀)です)。 2. ゲ

SQL関数の花形、集計関数です。 基本的にはGROUP BYと一緒に使用します。 ※GROUP BYを使用しないとグルーピングを伴わない集計になり、全件カウントなどに使います。 approxCountDistinct(e: Column) approxCountDistinct(columnName: String) approxCountDistinct(e: Column, rsd: Double) approxCountDistinct(columnName: String, rsd: Double) グルーピング内のアイテム数の近似値を返します。 アイテム数が少ない場合は正確な値を返します。アイテム数が多い場合に近似値となります。 第２引数に相対標準偏差(RSD)を指定し、近似の許容度を設定することもできます。 sql: select approxCountDistinct( e

add_months(startDate: Column, numMonths: Int) startDate に numMonths を加算した日付を返します。 sql: select ( startDate, numMonths ) from ... DataFrame: df.select( ( $"startDate", $"numMonths" ) ) 例) startDate = “2015-10-31 01:20:50”, numMonths = 1の場合、”2015-11-30 01:20:50″が返ります。

シンボル表現と$メソッドはimport sqlContext.implicits._を行い、implicit classをインポートすると使えるようになります。 ・WHERE WHEREはデータのフィルタリング条件を指定します。 ※ここらへんはSQL99等の仕様と同じです。 SQL >>> SELECT * FROM dataframe WHERE col2 > 0 DataFrame >>> DataFrameではfilterを使うこともできます。 DataFrame .where( $"col2" > 0 ) DataFrame .filter( $"col2".isNull ) ・JOIN JOINは複数のデータ(テーブル)を条件に従って結合します。 使えるJOINタイプは下記のとおりです。 単にJOINとだけ指定するとINNER JOINとなります。 LEFT SEMI JOINは

Sparkを実行できるWebUIをいくつか比較してみました。 対象としたのは下記の３つです。 Apache Zeppelin pyspark + Jupyter(iPython Notebook) spark-notebook Spark付属のSpark Web Interfaceは実行状況のモニタリングやRDDの状態が可視化されていて非常に便利なものなのですが、上記とは毛色が異なるため今回比較対象に入れていません。 Hueのnotebookやdatabricks cloudに関してはまた今度。。。 まずはそれぞれの概要を少しご紹介します。 Apache Zeppelin Apacheが作っているnotebook形式のWeb UIで、対話型実行ができます。 この記事を書いている時点での最新バージョンは0.6.0です。 Scala, Python, SQL(Spark), SQL(Hive)

notebook形式のWebUIでsparkを実行するspark-notebookを使ってみました。 https://github.com/andypetrella/spark-notebook spark-notebookは、scala-notebookをforkして作ったそうなんですが、 元々のscala-notebookはiPython Notebookにフィーチャーされて作ったものだということで、 iPython Notebookユーザには非常に馴染みのあるインターフェイスになっています。 インストール インストール方法はいくつか用意されています。 バイナリファイル dockerイメージ debianパッケージ ソースコード 私はデバッグできるようにソースコードを使いました。 ソースコードを使う場合はsbtでビルドと起動を行います。 # GitHubからcloneします $ git

order byにインデックスが効かないケースの前に・・・order byにインデックスが使用されるのは、どんな時？ 単独でインデックスが張られているカラムをorder byに指定したとき。 Where節内で使用したカラムとorder byで指定したカラムと合わせて複合インデックスが張られているとき（ただし、Where内では定数が指定されていること） この通りに指定してもインデックスが効かないケースがあります。 それが下記です。 ※ key1はkey_part11で構成されるインデックス、key2はkey_part21とkey_part22で構成されるインデックスとしています。 order by句に複数のインデックスを使用する SELECT * FROM t1 ORDER BY key_part11, key_part21, key_part22; この例では２つ以上のインデックスをord