「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
Volleyを使うときに気をつけることメモ - Qiita
開発中のアプリに「ネット上からの画像の取得とキャッシュをする」処理があったので、不安定なオレオレ実装からGoogle謹製のVolleyに乗り換えてみました。 Volleyの導入やスタートアップはこちらなんかを参考にするといいと思います。 今回はVolleyを使う上での実用的なメモを備忘録代わりに書いておきます(@mhidakaさんに助けてもらいました) 1. 一度にRequestを投げすぎるな！ Volleyがレスポンスを返すおおまかな流れは Requestを生成 RequestQueueに投げる ディスクキャッシュを探して見つかれば返す インターネットから拾ってきて返す という感じです。RequestQueueに投げてからレスポンスを返すまでは別スレッドで動いてくれるので、UIスレッドを停止させることはありません。 ところで、このDispatcherがVolleyでは1つしかなくて並列化
[AWS]AmazonS3にアップロードでRequestTimeTooSkewedのエラー WEBアプリケーション研究室 開発ノート
AmazonS3にアップロードをするシステムで、何もいじってないのに突然エラーで上がらなくなりました。 レスポンスを調べてみると RequestTimeTooSkewed The difference between the request time and the current time is too large. 900000 ***** ******************* Thu, 22 Sep 2011 16:51:06 +0000 2011-09-22T15:55:54Z こんな感じ。"Skewed"っていうのが見慣れない単語だったんですけど「歪められた」みないな意味らしい。リクエストには時間がかかってないので怪しいのはRequestTime。 サーバーに接続してdateしてみると10分時間が進んでました。 date --set="2011/09/23 00:50" 時間を
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
