2013年12月4日のブックマーク (11件)

  • git cloneでmrubyとってきて、mrubyディレクトリ内のbuild_config.rbに以下の設定貼り付けて、rakeしてbuild/mrbgems/mruby-oauth/example/tweet_timeline.rb に自分のtwitterのCONSUMER_KEYとか書いて、「./bin/mruby build/mrbge

    matsumoto_r
    matsumoto_r 2013/12/04
    mruby-httpのpull-reqマージされたから、これでtwitterのAPI v1.1試せるはず。
  • Sign in - Google Accounts

    matsumoto_r
    matsumoto_r 2013/12/04
    面白い
  • ポータブルなWebアプリケーション - naoyaのはてなダイアリー

    140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは

    ポータブルなWebアプリケーション - naoyaのはてなダイアリー
  • ポータブルなwebアプリケーションとそのインフラの未来の一考

    naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。 12-factor app ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。 The Twelve-Factor App The Twelve-Factor App(日語訳) Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。 とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Herokubuildpack という仕組みを使って、Heroku とインタフェース仕様

    ポータブルなwebアプリケーションとそのインフラの未来の一考
  • Vine

    The entertainment network where videos and personalities get really big, really fast. Download Vine to watch videos, remixes and trends before they blow up.

    Vine
    matsumoto_r
    matsumoto_r 2013/12/04
    こんなスーパーあるある久々に見たw (映画上のプログラミングと実際のプログラミングの比較動画)
  • 我慢から学んだ事

    人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 このエントリでは久しぶりに日記のような記事を書こうと思う。なので、いつもの技術エントリはですます調だが今日は日記調に適当な感じでいこうと思う。 自分は、他人への配慮を踏まえた上で思った事は言うべきだと考えている人間だし、それを我慢して空気を読んだり間違っていると思っているのにその意見に迎合するのは好きではない。もちろん、自分の言った事が間違っていたら、それを認め謝らないといけない。僕はそういう間違いを恐れない議論が必要だと考えている人間だ。 しかし、そうやって生きてきてはいるが、「我慢する事」は自分にとって非常に大事だと思っている。いつでもなんでもどんな時でも、言いたい事を言うのも良いのだが、我慢することで得られる事もあるという事を、年末も近

    我慢から学んだ事
    matsumoto_r
    matsumoto_r 2013/12/04
    年末だしちょっと振り返って書いた
  • 4歳の息子と0歳の娘がいる父親がおすすめの絵本を書いてみた - blog.nomadscafe.jp

    941さんが絵名作100リストというエントリーをあげていたので便乗してうちにあるからオススメを紹介してみる。 うちには4歳の息子と0歳の娘がいますが、(息子から見た)おばあちゃんがらでぃっしゅぼーやの絵くらぶというのに申し込んでくれていて、毎月絵が1冊届きます。親と息子でを選ぶと息子が好きな電車とか乗り物とか電車のに偏ってしまうと思うので、毎月いろんな絵が届くのはかなり良い。息子も新しいが来るのを楽しみにしています。 それに加えて、毎週木曜日に保育園からを借りてくるのと、近所の図書館で借りるがあるので、棚はいつもいっぱいです。 ずいぶん前からひらがなカタカナが読めていた息子なので一人でもを読むけど、毎日寝る前に2冊を読んでいます。寝落ちそうになりながら読んでいる事もあるけど、息子・娘ともにが好きになって、をきっかけに世界を広げていって欲しいと思うところです。

  • specinfra をベースとしたオレオレ Configuration Management Tool/オレオレ serverspec 構想 - Gosuke Miyashita

    specinfra v0.0.6 では、serverspec/configspec/Syllabus で実行する具体的なコマンドを SpecInfra::Command::* に統合しました。 以前のバージョンまでは「OS を自動判別し、OS に適したコマンドクラスを返す commands と呼んでいるレイヤー」を specinfra で提供していましたが、コマンドクラスは各プロダクト側で実装していました。 specinfra v0.0.6 では、コマンドクラスも specinfra 側で持つようになりました。 これで何がうれしいのかというと、オレオレ Configuration Management Tool が簡単に実装できるようになる、ということです。 Exec/SSH といったバックエンド実行形式の切り替えや、OSを自動判別して適切なコマンドを実行する部分はすべて specinfr

  • 若いエンジニアへ

    エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニア仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら

    matsumoto_r
    matsumoto_r 2013/12/04
    正当かどうかと、好みは別。正しいプロセスでなくともワクワクするし、そこに思い出はうまれる。改善されても、そういう過去の失敗は良い思い出。
  • Perl XS を書くようになったきっかけ - Islands in the byte stream (legacy)

    THE INTERVIEWS がサービス終了ということで、一つだけ消えるには惜しいというか懐かしい記事があったので少し加筆修正して転載します。JHackers でも似たようなことを話してますね。 Perl XS を書くようになったきっかけ、また、どのようにして今のような XS マジシャンになったのか。そのあたりの事をお聞かせください 2000年頃の話です。ぼくはCGIスクリプトでちょっとしたゲームデータの集計サイトをやりたくてプログラミングを覚えたのでした。これがそこそこ重い処理で、次第にもっと高速にしたいと考えるようになりました。一方、当時ぼくはお金もなくVPSも一般的でなかったので、CGIスクリプトしか選択肢はありません。そこで初心者ながらいろいろ調べることにしました。 とりかかったのは行指向のテキストで保存していたデータをSQLiteにすることでした。しかし当時はWindows上で開

    Perl XS を書くようになったきっかけ - Islands in the byte stream (legacy)
  • SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013

    SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY(スピーディ)。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究

    SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013