ギタフリ用コントローラ + GamepadAPIでアーメンブレイク - マルシテイア
起床即アーメンブレイクした ギタフリ用コントローラ持っててPCにつなげる人はここで試せます http://gmork.in/guitarbreaks/ 解説 GamepadAPI というのがある http://www.w3.org/TR/gamepad/ これは GamepadAPI と Web Audio API 組み合わせて音鳴らしてるだけ。 クオンタイズ頑張ればもっとキレイに鳴らせるかなー 経緯 先日のWeb Music ハッカソンにギタフリ用コントローラで発表してる人がいて、GamepadAPI の紹介してた。 （名前わすれてしまった…） 実は僕も以前同じ事をやろうと思ってギタフリ用コントローラ買ってたのだった。 Processingとかで試してたんだけど、Mac で上手く認識されなくて諦めた。 今回リベンジするにあたって、「もしかしたらコンバータが悪かったのかな？」と思いPS用コ
Cluster
Node.js v0.6 の新機能として cluster モジュール が導入されました．cluster モジュールは，HTTP を含めた TCP 接続を複数の子プロセス (ワーカプロセス) で処理することにより，特にマルチコア環境でのスループット (リクエスト／秒) を向上するための機能です． しかし，ドキュメントにはその使い方が書かれているだけで，どのように実現されているかは書かれていないので，ここで簡単に紹介しておきます． Node.js のクラスタ機能は v0.5.10 で突然コマンドラインオプションとして導入されましたが，直後の「東京 Node 学園祭 2011」が行われた頃にはコマンドラインオプションは廃止されて cluster モジュールによって API が提供されるようになり，その翌週の v0.6.0 リリース数時間前にはその API が変更されるというドタバタぶりでした
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
なぜネットワーク運用自動化が進まないのか Why is it difficult �to automate network operation
2015/4/24に開催された wakamonog x ssmjp x BIGLOBE = wasabi イベントで発表した資料です。http://ssmjp.connpass.com/event/13173/ This is lightning talk presentation for study event in Tokyo.
書き直さない時代の気分 - steps to phantasien
なんとなく続き。(前回) Martin Fowler が蒸し返すまで、 自分は書き直しについてことさら何か書く気が起きなかった。 どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。 部分的に書き直す 最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。 小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れ
俺のaltjsがこんなに簡単にpegjsで作れるわけがない - Qiita
この記事はJavaScript Advent Calender 2014の10日目の記事です。 altjs作りたいやろ 半年前にこんなLTをやった。未完成で放置するのは気持ち悪いので、この機会に完成させようと思った…んだけど、advent当日の時点でまだ完成してない。すまんな。ただ知見は多少溜まったので、基本的なaltjsの作り方と合わせて紹介しようと思う。 altjsってどうやって作んの？ 方法は様々だけど、 文法をPEG(pegjs)で記述する ソースコードを、Parser APIで定義されるASTに変換するロジックを書く 変換されたASTを、escodegenでJavaScriptのコードにさらに変換する というのが今ならやりやすいと思う。結局ある構文をjsに変換するだけで、変換は既存のツールを使えるので、実はそんなに広い知識を要求せず、0から王道のコンパイラを作るみたいな壮大な話に
WHATWG Streams APIについてのメモ - maru source
こんにちは丸山@h13i32maruです。 WHATWG Streams APIを少し触ってみたので、そのメモです。 ドキュメント WHATWG Streams このメモはLast Updated 21 January 2015を元に書いた whatwg/streams サンプルやリファレンス実装などがある このメモはcommit 879902を元に書いた Stream APIがブラウザにやってくる @jxckさんがnodeのStream APIと絡めてWHATWGのStreams APIを紹介している 概念 JavaScriptのプログラム中で処理する(大きめな)データの読み書きを統一的に扱うためのインターフェースをStreams APIとしてWHATWGが策定している。例えばXHRで大きなファイルを読み込んだ時にはすべてのデータを読み込んだあとにコールバックが呼ばれる*1。これだと読み
Webパフォーマンスにおけるイニシャライズとランタイム
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
権限管理を実装するときの地味な話 - ✘╹◡╹✘
「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド
REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
関数型言語を学ぶことは実務でどう役に立ったか - Rejasupoem
関数型LT大会で「実社会の問題を解決する関数型言語」というタイトルで発表しました。 というのも、会社で「すごいHaskellたのしく学ぼう！」の輪読会をしていて、最初こそ10人以上の人が参加していたのだけど、章が進むごとにどんどん人が離脱していって、主催者としてはなんとか完走したいという思いがあったので、調べたのですが、 ヒアリングから、この二つの線がクロスしたときに、人は離脱するという知見が得られました。 ということで、Haskellに対して実用性を見出したいと思いながら半年を過ごしたのですが、実用的 = 仕事で使うということであれば、今の現場でHaskellに移行するのは現実的ではありません。 でも、Haskellには関数型言語のエッセンスが詰まっていて学びが多かったと思っていて、直接的には使っていないけど、概念として役立つことがあると思ったので、それを伝えるために今回文章に起こしまし
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
HTMLでWeb APIをつくる - Qiita
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
niw.at — iOS で文字数制限つきのテキストフィールドをちゃんと作るのは難しいという話
「そんなん簡単やろ」と思いますよね。 たとえば、「UITextField 文字数制限」でググれば山のようにブログ記事やらコードが出てくるし、Stack Overflow に載ってるコードのコピペ一発で解決しそうに思えませんか? 実は文字数制限をつけたテキストフィールドはそんなに簡単な話ではないのです。 shouldChangeCharactersInRange:replacementString: は使えない子 今回はこれに尽きます。 UITextField や UITextView のデリゲートで呼ばれる textField:shouldChangeCharactersInRange:replacementString: やtextView:shouldChangeCharactersInRange:replacementString: は使ってはいけません。 より正確に言うと、使うとき
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
wavelet行列で高速な「もしかして友だち？」検索 | 株式会社サイバーエージェント
業務経歴： Sierでのソフトウェア開発・大手メディアでのサービス運用を経て2012年サイバーエージェント入社。 アメーバ事業本部コミュニティサービスの開発責任者を経て、現在はアドテクスタジオで広告配信技術に注力。 好きな分野はグラフ探索とチューリングマシン。 ソーシャルサービスでは、ユーザ間のつながりやユーザ同士の類似性がとても重要です。 つながりの近いユーザや自分と似ているユーザを「もしかして友だち？」とサジェストすることでユーザ間のつながりを伸展させることができます。 そこで、ユーザの「つながり」具合が似ているユーザを「友だちかもしれないユーザ」としてサジェストを行うことを考えました。 しかし「つながり」のデータというのはユーザ数のベキ乗であるため、容量が大きくなりやすい性質があります。 即ち、「つながり」類似度の算出には時間がかかる、ということです。 この「つながり」類似度算出
最小最速で作るaltjs - mizchi's blog
最近、というか昨日からTypedCoffeeScriptの開発再開してAST 気分が盛り上がってるので、簡単なチュートリアルでも。 この記事でやること ASTの取得 ASTの生成 JavaScript の出力 やらないこと 構文解析 準備 適当にプロジェクト作ります。 $ mkdir tinyaltjs $ cd tinyaltjs $ npm init # 色々聞かれるけどEnter 連打で良い $ npm install escodegen esprima prettyjson --save esprima はJavaScript のコードをASTに変換。 escodegen は AST から JavaScript を生成。どっちもConstellationさん製 escodegenはConstellationさん製で、彼はesprimaにもコミットしてます。この界隈に来ると基本的に彼
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON Schema で Web API のスキマを埋めよう
Inouetakuya
http://api-portal.nhk.or.jp/ja
