サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
hakobera.hatenablog.com
三行まとめ WebRTC の getDisplayMedia API を利用した P2P で画面共有するサービスを作りました。 全て Managed Service (AWS & Firebase) 上で動作しており、ほぼノーメンテナンスでそれなりスケールします。 無料。ただし、音声無し、TURNサーバー無し、SLA 無しで、繋がらないこともそれなりにあると思うので、クリティカルな用途に使用することは非推奨 getdisplay.media 使い方 どういう風に使うのか、また遅延はどれくらいなのかを以下の動画をご覧ください。 配信側は WiFi で、視聴側の iPhone は LTE 回線で繋がっています。 Fully managed and serverless Screen Sharing Service: getdisplay.media 配信は GitHub 認証が必須ですが、視聴
こんなものは絶対に標準で入っていると思うんだけど、どうしてもみつけられなかったので、書きました。 使い方 String url = ... assertThat(url, matches("http://test\\.com/[a-zA-Z0-9]+/edit")); コード import java.util.regex.Pattern; import org.hamcrest.Description; import org.junit.internal.matchers.TypeSafeMatcher; public class RegexMatcher extends TypeSafeMatcher<String> { public static TypeSafeMatcher<String> matches(String criteria) { return new RegexMat
こんな Fragment を作れば良いと思う。 import android.app.DatePickerDialog; import android.app.Dialog; import android.content.Context; import android.content.res.Resources; import android.os.Bundle; import android.support.v4.app.DialogFragment; import android.view.View; import android.view.Window; import android.widget.DatePicker; import java.text.SimpleDateFormat; import java.util.Calendar; public class YearMon
この記事は Recruit Engineers Advent Calendar 2016 の15日目の記事です。 12月2〜3日に開催された RubyConf Taiwan 2016 にスピーカーとして参加してきました。 この記事ではカンファレンスそのものではなく、その前段階の CFP の書き方について、実際に RubyConf Taiwan 2016 に提出した私の実例をあげて、CFP に書く内容と、どういう点に注意して書いたかというのを解説してみたいと思います。自分自身も初めての CFP かつ、英語の CFP だったので、同じように挑戦してみたい人の参考になれば良いな、と思います。 なお、カンファレンスの雰囲気自体は4日目担当の remore さんが書いていますので、ぜひご覧ください。初めての海外カンファレンスでしたが、発表もパーティーもセッションもすごく面白かったです。 RubyCo
前置き hakobera.hatenablog.com この記事を公開した当時はまだオープンにできなかったのですが、実はこの記事は2月25日にリリースされたスタディサプリ(受験サプリ)を Quipper のプラットフォームに載せ替えるという移行プロジェクトを前提として内容も含んでいました。 【公式】スタディサプリ|苦手克服・定期テスト対策~大学受験まで 無事にリリースできたので、このプロジェクトで変わったことや導入したソフトウェア、ツールについていくつかピックアップして書いていきたいと思います。 目次 メンバーが増えた Infra as Code Deis AWS ECS + Docker + Locust による負荷テスト nginx (HTTP/2, ngx_mruby) 分析基盤 技術的課題 メンバーが増えた 前回の記事を書いた時はインフラ関連のエンジニア(Quipper では En
技術的課題を書くと、それを解決してくれるエンジニアが採用できるって話は本当ですか?というのは冗談としても、今の技術的課題をブログにまとめて公開するノーガード戦法も良いかと思う。— Kazuyuki Honda (@hakobera) May 25, 2015 このツイートがそれなりに反応があったので、有言実行してみる。 最初に書いておくと、これはQuipperの採用のための記事です。Quipper では下記のようなお仕事、技術的課題の解決に興味がある DevOps エンジニアを絶賛大募集しております。興味のある方は、Wantedlyの募集ページ から「話を聞きに行きたい」をクリックしてみてください。応募までは行かないけど、もっと詳しい聞いてみたいという方は私個人にでも良いのでご連絡ください。(Twitter で @hakobera にメンション or DM、または hakoberaアットg
目的 Kibana で Heroku アプリのログを可視化したい。ただし、レスポンスタイムとかは New Relic でも見れるので、ここではアプリが出力したらログを可視化する方法を紹介する。 また、今回、アプリからの出力を可能な限りに簡単にするために、アプリからは Heroku の STDOUT に出力するだけで、ログを Kibana サーバに送信できるようにしてみた。 具体的にはこう。(Ruby の場合) 出力の形式は、Treasure Data addon の方法 を真似ている。 puts "@[tag.name] #{{'uid'=>123}.to_json}" これで、tag.name が fluentd の tag 名に、それに続く JSON 文字列が送信するデータとして処理される。 環境 Amazon EC2 上に Kibana サーバを構築 OS は Ubuntu 13.1
結論 thunkifyをオブジェクトのメソッドに適用する時は、元のメソッドに代入するか、thisを元のオブジェクトにbindすること。 fs.readFile = thunkify(fs.readFile) // または var readFile = thunkify(fs.readFile.bind(fs)); ただし、fs.readFileはvar readFile = thunkify(fs.readFile.bind(fs));でも動きます。詳細は以下。 元のオブジェクトに影響を与えない、ということを考えると後者の方が良いかも。 原因 thunkify は、Node で generator を使ったプログラムを書く時に便利ですが、1つ気をつけることがあります。 thunkify の実装は以下のようになっています。 function thunkify(fn){ return func
インストール方法 Chrome ウェブストアで公開中です。 Gyazo Shot ソース Github上で開発しています。問題報告やプルリクエストなど大歓迎です。 https://github.com/hakobera/gyazo-shot 開発動機および機能 開発中の画面とかをサクッと共有するのに、Gyazoはとても便利です。 ただし、Web開発では、圧倒的にブラウザの表示内容を共有することが多く、いちいち領域選択して行くのは面倒です。また、領域選択に失敗して綺麗に撮れない場合もあります。 Gyazo Shot で目指したのは、「簡単にWebブラウザのスクリーンショットを共有できる」です。 Gyazo Shot はワンクリックで表示しているタブの表示領域のスクリーンショットを Gyazo で共有することができます。本家のクライアントアプリと同様、共有後は共有ページがブラウザで開き、クリッ
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
Heroku で Node.js を動かしても絶対的なパフォーマンスは得られないのだけれど、最近仕事で Node.js on Heroku をやっているので、実際にどれくらいのパフォーマンスがでるのか測ってみました。 今回調べたのは、主に3点。 2X Dyno (CPUとメモリが2倍のDyno。ただし、コア数は4のまま)を使うと速くなるのか? Cluster に効果はあるのか? Dyno 数はどれくらいが良いのか? ベンチマークは Node.js v0.10.9 を対象とし、全て siege のベンチマーク機能の結果です。ベンチマーク対象のコードは、Node.js 本家トップページに載っている例のHTTP サーバで、AWS の us-east-1 リージョンの EC2 m1.large インスタンスで実行した結果です。 $ siege -b 60S -c 100 http://server
あまり時間が取れなかったので、第5回は小ネタをちょこちょこと。 HTTPServer の prototype チェーン(継承関係) net.Server |- http.Server |- connect.HTTPServer - [mix-in] -> connect.HTTPSServer なので、net.Server や http.Server のメソッドが普通に使えます。 HTTP ヘッダーは全部小文字になっている 前回も書きましたが、middleware にくる段階で HTTP ヘッダーのキーは全て小文字になっているので、注意。 JavaScript で QueryString をパースしてオブジェクト化する際のイデオム bodyParser の中で出てきましたが、キーに対応するオブジェクトを探してきて、それが配列なら追加、単独のオブジェクトなら配列化して追加、オブジェクトが無い
1年前にこんなエントリを書きました。 僕の考えた最強の Node.js Document Viewer - hakobera's blog YAND 自体は結構使っていたのですが、色々あって Node.js v0.6.10 で更新を止めていました。 が、さすがに v0.8 用のものが欲しくなってきたので、v0.8.18 のドキュメントに更新しました。 YAND - Yet Another Node.js Documentation これに合わせて、ソースの整理もしたので、GitHub で公開しました。 hakobera/yand · GitHub 以下の様な感じで、特定のバージョン(多分、v0.8 以上じゃないと動かないと思いますが)のドキュメントを自分で作成できるようにしてあります。NODE_VERSION にドキュメントを作成したバージョンを指定します。 $ make NODE_VER
突然ですが、Node.jsで次のプログラムを実行した結果を答えてください。 var EventEmitter = require('events').EventEmitter; var event = new EventEmitter(); console.log('1'); event.on('open', function () { console.log('2'); }); event.emit('open'); console.log(3); 正解は少し下の方に書いてあります。 少しだけスクロールを我慢して考えてみてください。 正解は 1 2 3 です。 1 3 2 だと思っていた人も多いのではないでしょうか。(私だけかもしれませんが) つまり、表題の「EventEmitter.emit() によくある勘違い」とは、EventEmitter.emit()が次のイベントループで実行さ
この記事は東京Node学園祭2012 アドベントカレンダーの8日目の記事です。 この記事を書こうと思った理由 Node.jsに関するWeb上の記事を読んでいると、「Node.jsは静的コンテンツに弱い」とだけ書いてある記事をよく見かけます。有名なところだと、LinkedInのNode.jsのパフォーマンスに関する10個のTipsの3番目のTipsに"Don't use Node.js for static assets"とばっちり書いてあります。 確かにCDNやNginxに比べれば、Node.jsは静的コンテンツの扱いが遅いとは思います。しかし、それは LinkedIn くらいの超大規模なトラフィックがある場合には問題になるとは思いますが、小〜中規模なサイトでもNginxは必須なほど遅いのでしょうか?512MBしかメモリのないVPSにNginxとNode.jsを入れてやりくりすることがホン
テスト環境などで公開したくない場合に、Basic 認証をかけたいことがあると思うが、Exress でそれをやる方法。基本的に Express は Connect ラッパーなので、やり方は Connect と同じ。 Connect - basicAuth 注意したいのは app.use(app.router) の前に書かないと、ちゃんと動かない(認証キャンセルしても遷移してしまう)点。 ユーザ、パスワードは例によって heroku config で追加しておく。 heroku config:add BASIC_AUTH_USER=user heroku config:add BASIC_AUTH_PASS=passapp.configure(function(){ //.. (略) if (process.env.BASIC_AUTH_USER) { app.use(express.basi
Tuppari コミュニティについて これまで個人で Tuppari を書いていましたが、@seratch が Ruby ライブラリ書いてくれてので、これを機にコミュニティ体制に移行しました。 Tuppari の Ruby クライアントを書きました - case class HatenaDiary(id: Symbol = ’seratch2) 具体的には、Github の Organization にリポジトリを移動し、Node.js、Java、そして今回追加された Ruby ライブラリをまとめました。 Tuppari (Github Organization) Tuppari のメンテナになりたいという方、もしくは、Tuppari の各種言語のライブラリ書いたという方は権限を追加しますので、ご連絡ください。 IE 9 対応について Tuppari は WebSocket を使うので、原
Tuppari - WebSocket on Your Cloud - - Scalaとlift のはずだった ・・・ 前回、Node.js で構築した Tuppari (コンセプトは Pusher クローン)を紹介しましたが、実は API 仕様が公開されていて、Node.js 以外の言語/環境でもクライアントを作ることができます。 Tuppari API Reference で、これにもとづいて Java クライアントを作りました。他の言語でも書けると思うので、興味がある方は是非挑戦してみてください。そして、できたら教えて下さい。 tuppari-java Tuppari 公開記念ハッカソン 興味があればどうぞー。Node.js はちょっとわからないけど、Java なら任せろー、な方も大歓迎です。ご希望があれば、Tuppari の使い方、各自の環境へのインストール方法などサポートします。
Tuppari とは 東京Node学園 6時限目で発表した Node.js で作られた Pusher クローンです。 簡単に言うと WebSocket を利用した大規模 Broadcast に特化したサービスです。 インフラとしては Amazon Web Services (以降、AWS)上で動かすことに最適化されていますが、AWS以外でも動かすことは可能です。つまり、クラウド上に自分自身の Pusher を構築することが可能になります。 現時点では Pusher の機能には追いついていませんが、今後も鋭意開発を進めていくので、是非使ってみてください。 あと、WebSocket を使うので、IE9 以下では動きません。 8/15 追記: v0.2.0 から IE もサポートしました。 詳細は以下の記事を参照して下さい。 Tuppari コミュニティ始めました & IE に対応しました -
最近は Google Chart Tools や Highcharts のように綺麗なグラフがかけるライブラリが増えてきましたが、レーダーチャートをサポートしているものがあまりなく、あっても用途にマッチしなかったので jQuery と Raphael を使って、レーダーチャートが描けるライブラリを作ってみました。 作ってみましたといっても、正確には fork して改造になります。 ソース: hakobera/raphael-radar · GitHub デモ: Raphaël Radar Chart Plugin Sample サンプル こんな感じのチャートが書けます。 ソースは以下のような感じです。 var objects = [ { title: "Real Madrid C.F.", offense: 80, defense: 90, technique: 70, strategy:
4/18 に開催された 東京Node学園 5時限目 で @KOBA789 さんが自作のルータである Router-Line を紹介していました。 その時から便利そうとは思っていたのですが、最近ちょっとした API サーバを書く時に実際に Router-Line を使ってみて、改めて良いなと思ったので、サンプルを見せながら、個人的に便利だと思う使い方を紹介します。 Router-Line とは KOBA789/router-line · GitHub github で「A URL routing module for Node.js」と書いてある通り、Router-Line はシンプルな URL ルータで、それ以外の機能は持っていません。サーバを構築するには Node.js の http モジュールなどと組み合わせて使う必要があります。 個人的には API サーバのルーティングには、Expr
4/29 に奈良の能楽ホール(重要文化財!)で開催された 鹿駆動勉強会 に参加して、LTしてきました。関東以外の勉強会に参加したのは初めてでしたが、懇親会で twitter でしか知らなかった方々と直接お話できたりして、とても楽しかったです。 当日の流れや各LTの資料、参加報告 Blog などは Togetter に まとまっているので、そちらを参照してみてください。 #shikadriven 鹿駆動勉強会 - Togetter 感想 会場はこんな感じで、ここで LT できたのはとても貴重な体験でした。 勉強会は特にテーマ不定で怒涛のLT20連発。内容も多岐に渡っていて、普段聞くことがない内容のものもあり、とても刺激になりました。最近は興味のあるテーマの勉強会にしか言っていませんでしたが、こういう広いテーマの勉強会もまた参加してみたいと思いました。 自分も勉強会運営をしたことがあるのでわか
Node.js で WebSocket-Node を使って実装しました。 転送するめぼしい画像が見当たらなかったので、デスクトップをスクリーンキャプチャして転送してみました。 ブラウザはChrome 17以上か、Firefox 11以上が必要です。サーバ側は scrrencapture コマンドを利用している関係で Mac OS X限定です。 デモ 上半分が転送元のデスクトップ、下半分が転送された画像をブラウザで表示したものです。ニコ動のコメントの飛び具合を見るとわかると思いますが、800*600の解像度の画像を、横640に縮小して転送して、1FPSくらいです。(※ これはWebSocket の限界ではありません。速度は向上させる余地はかなりありますが、今回の本質ではないので気にしないことにします) ソースは github に置いてあります。 hakobera/screencast · G
前置き Experiences with Node.js: Porting a RESTful Service Written in Java - ZiggyTech 上記記事では、実験的にJava (Jersey + Hibernate on Tomcat) で実装された REST API サーバを Node.js で書きなおしてみたら、少ないリソース(CPU/メモリ使用量)でほぼ同等のパフォーマンスが出せたよ(ただし、O/Rマッパーを使用しない場合)、と書いてあります。この件に関して @koichik さんとやり取りしていた中で以下のような意見を頂いたので、実際にやってみましたという記事です。 @hakobera メジャーってことだと,あの比較が Play ではなく Tomcat なのは正解.日本的には Jersey ではなく Struts (もちろん 1 の方)なら更によかったw 2
Database-Driven Web Apps with Play! | Heroku Dev Center (we don’t recommend setting jpa.ddl to update for a real world production app. Use Play!’s database evolutions instead.) Heroku の Play のチュートリアル記事に「jpa.ddl=update が許されるのは開発環境までだよねー。本番環境では Play の evolutions を使ってね (・ω<) テヘペロ」(意訳)って書いてあったので、Heroku の Shared Database (PostgreSQL) で試してみたら色々とハマったので原因と解決方法を書いていこうと思います。 お勧めするならやり方くらい書いておいて欲しい・・・ 結論 先に
2012/8/7 追記 Heroku が公式で package.json での Node.js/NPM のバージョン指定に対応したので、現在は以下の方法は必要ありません。普通に package.json の engines に利用したいバージョンを書けばOKです。 以下の情報は古いです。 本日、開催された Heroku JP Meetup #3 で話してきた内容です。 内容としては去年の12月の東京Node学園3時限目のLTの進化版で、package.json の engines の指定を変えることで、Node.js のバージョンを切り替えられる公式の versions ブランチの利用法について解説しています。 Run Multi Version of Node.js on Heroku View more presentations from Kazuyuki Honda heroku/
Play Framework 1.2.4 では、標準の機能で複数データベースに接続することができません。 ただし、希望としては上がっていて、実は 1.3 では実装される予定です。 #706 Multiple database/JPA support - Play framework 1.0 (now in maintenance mode) - play しかし、現在のプロジェクトでどうしても複数のデータベースに接続する必要がある要件があったので、1.3 で実装される予定の機能をバックポートして使っています。 メモがわりにその方法を書いておきます。 注意点 データソースを複数管理するところまでしかやっていません なぜなら Doma を使っていて、JPA を使っていないから JPA も上記 branch では対応しているので、できるはず(未検証) 706 チケットの修正ブランチをみつける m
自分がNode.js でプログラミングをする際に、必ず参考にするページがあります。それは Node.js の公式ドキュメントです。 Node.js v0.8.12 Manual & Documentation バージョンアップにも追随して、最新の情報が得られるので、書いている人には頭が上がりません。情報量も十分です。(たまに空っぽのページとかありますが) ただ、このドキュメントを見たことある人ならわかると思いますが、すごく見難いのです。より具体的にはナビゲーションが良くないのと、検索がない、という2つの難点を抱えています。 というわけで、この問題を解決する Document Viewer を作りました。 名付けて 「YAND」=「Yet Another Node.js Document Viewer」です。 Yet Another Node.js Document Viewer [追記]
既にあるような気もするのですが、ちょっとだけ特殊な要件に対応したかったので、uglify-me という JS 圧縮ライブラリである UglifyJS のフロントエンドを Node.js で組んでみました。 hakobera/uglify-me · GitHub デモ 以下のようなケースにマッチします。 ビルドサーバや、各開発者のマシンに Node.js が様々な理由で入れられない Closure Compiler Service API で圧縮するのは、セキュリティ上の理由などでダメだと言われた 圧縮用処理がシェルスクリプトだけで記述できなければいけない ようするに、既存のアプリ、インフラ、開発環境にほとんど手を加えずに、JS の圧縮を実現するにはどうすれば良いか、という思想で作ってあります。上記のケースに当てはまらない場合、普通に UglifyJS の CLI か、Closure Com
次のページ
このページを最初にブックマークしてみませんか?
『hakobera's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く