ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような

昨日のことになりますが HBFav 2.8.1 をリリースしました。主な変更は iPhone 6 解像度対応 はてなブックマーク追加時に認証を再度要求されてしまう問題の修正 の 2 点です。 これまでは折角画面サイズが大きくなった iPhone 6 や 6 Plus で HBFav を使っても解像度は iPhone 5s のころのサイズのままで、引き延ばされて表示されていました。結果的に文字がぼやけるなどの状態でしたが、今回改めて iPhone 6 と 6 Plus 解像度に対応したことで見た目もくっきり、一画面に収まる情報量も増えました。 不具合の修正は、長らく続いていた、一度認証したのにしばらくするとまた認証を要求されてしまう問題の修正です。自分の手元ではなかなかこの問題が再現せず、原因が特定できずに困っていましたがようやくそれがわかって修正できました。いろいろとご不便おかけしましたが

2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN)　という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─

pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a

HBFav をお使いいただきありがとうございます。 現在のバージョン 2.6.1 は、iOS 7 から iOS 8 にアップグレードするとアプリ起動後、記事一覧を読み込んだところでクラッシュしてしまいます。 クラッシュの原因を修正したバージョン 2.7.1 を先週には App Store にアップロードしたのですが、まだ審査待ちでリリースできていません。申し訳ございません。今しばらくお待ち下さい。

事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更

今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr

今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う

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