はてなブックマーク

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

「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea

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.7.1 をリリースできました。 https://itunes.apple.com/jp/app/hbfav/id477950722 これで iOS 8 にするとクラッシュする問題が解消されました。 ただし、iOS 8 でプッシュ通知を受け取ろうと設定しようとしたとき正しく設定できない問題が見つかったため、急遽修正しまして 2.7.2 の審査待ちです。デバッグの過程で既存のプロビジョニングファイルをいろいろいじったせいで、もしかすれば既存のバージョンもプッシュ通知が届かなくなっているかもしれません、申し訳ないです。プッシュが届かなくなっているもしくは iOS 8 でプッシュが来ないかたは 2.7.2 のリリースをお待ち下さい。 このところ HBFav の開発にあまり時間が取れず、バージョンアップの割に目新しい機能はほとんどありませんが

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

Go にはスクリプト言語でいうところの variable = a || b のような構文や三項演算子がないようなので、 var accessKeyId, secretAccessKey string if config["aws_access_key_id"] == "" { accessKeyId = os.Getenv("AWS_ACCESS_KEY_ID") secretAccessKey = os.Getenv("AWS_SECRET_ACCESS_KEY") } else { accessKeyId = config["aws_access_key_id"] secretAccessKey = config["aws_secret_access_key"] } とか var url string var err error if len(os.Args) == 1 { url,

フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

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

先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており

KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team

少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ

昨年 ELPA で elisp を管理 - naoyaのはてなダイアリー に書いたとおり、昨今は Emacs にもパッケージ管理システムが搭載されいて、どこからか elisp をコピペしてきてその後管理できなくなる･･･みたいなことはなくなった。 ただ、じゃあ ELPA で全て解決したかというとそんなことはなくて、ELPA はパッケージのインストール自体は簡単にしてくれるけれども、それだけだった。 elisp の管理も Bundler のように入れたいパッケージ一覧を書いて bundle install すれば全部まとめて入るみたいな、そういうのが欲しい･･･と常々思っていた。 と思っていたら、Cask というのを見つけた。これがずばりそのものだった。 (source gnu) (source melpa) (source marmalade) (depends-on "ag") (dep

HBFav で新着ブックマークが正しく取得できない不具合が発生しています - naoyaのはてなダイアリー で報告しました HBFav の不具合ですが、はてなブックマーク本体が修正されたことにより HBFav 側もこれまでどおり動作するようになりました。 はてなブックマークの「お気に入り」機能の不具合を修正しました - はてなブックマーク開発ブログ ご利用の皆様にはご迷惑をおかけしました。また、修正にあたったはてなスタッフの皆様に感謝申し上げます。 引き続き HBFav をよろしくお願いいたします。

何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです) https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集

朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい

@miyagawa の Podcast (まあ、このブログを読んでくれてる人にはわざわざ説明するまでもない) である Rebuild #29 で、iOS アプリのレビューの話になって、自分が作ってる HBFav も☆5個のレビューくださいね、と冗談半分で言ってたら、きづいたらレビューが50件近くついてました･･･! Podcast、出てみるもんですね! w 引き続き、☆5レビューをお待ちしてます。

今日はこのあと Github の Tokyo Drinkup January 2014 に行くのだが、先方から、もしかしたら 10分ほど Github について話してもらうかも、と打診された。話すか話さないかわからないが、もし話すとしたらと仮定し内容の整理も兼ねて以下「Github を使って雑誌原稿を書く」ということについて書いてみようと思う。 「Github を使って雑誌原稿を書く」もしくは「Github を使った雑誌編集者とのコラボレーション」について、である。 Web+DB PRESS の連載 ご存知の方もいるかもしれないが、このところ技術評論社の Web+DB PRESS で連載をしている。連載を始めて、もう一年近く経った。以前にも Perl に関する連載をしていて、そのときも数年ぐらい続けたので、間があきつつも、なんだかんだでそれぐらいの付き合いになる。 最近は特にテーマは決めず

新年あけましておめでとうございます。本年もよろしくお願いします。 えー、もう明日になってしまって今更宣伝してもという感じではあるのですが、明日開催される CROSS 2014 で、12:00 から 60分ほどセッションを開催します。「現場に聞く！テスト/CI/DevOps、実際のところどうなの」というタイトルでのパネルディスカッションです。 http://www.cross-party.com/programs/testcidevops/ 自分が司会で、他はクックパッドの id:secondlife (@hotchpotch)、KAIZEN platform Inc. CTO の @iandeth、はてなの id:hakobe932 (@hakobe) の4人と話します。 パネルディスカッション、というとテーマをあげてそれぞれの思うところを喋って貰う、みたいな形式もありますが、明日は自社ア

今年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 をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う

HBFav を 2.6 にバージョンアップしました。新機能としてタイムラインの自動更新機能を追加しました。 これまではタイムラインなどで新着記事を取得する場合、都度、手動で Pull to Refresh (引っ張って更新) を行う必要がありましたが、新しいバージョン 2.6 からはその必要がなくなります。ただし新ユーザーページ設定がオンの場合にのみ限り、本機能が有効になります。 我ながら、本機能でずいぶんと使い勝手が良くなったなあと思いました。特にプッシュ通知と併用すると、プッシュで配信されたエントリが HBFav を開いたときにはもう反映されるようになり、もはやネットワークの通信待ちすら発生しません。これは想像以上に快適で、あるエントリを読んでる間に配信されてきたブックマークもすぐにチェックできるので中毒性が増･･･ じゃなかった、とても便利です。 なお、プッシュが有効じゃなくても更新

RubyMotion Advent Calendar 2013 に何か書こう、ということでエントリ。 ご存知のように iPhone アプリの HBFav は RubyMotion で作っています。Objective-C ではなく。以前は Titanium Mobile で作っていましたが、去年にバージョン2として作り直すにあたって RubyMotion に移行しました。 RubyMotion に関しては以前、以下のエントリで概要を説明しています。 RubyMotion - naoyaのはてなダイアリー それから、今年 5月に開催した RubyMotion カンファレンスのスライドなどもあります。 実践RubyMotion - Speaker Deck RubyMotion が発表されたのは 2012 年の5月 とかで、それからずっと使い続けているので1年半近くが経ったことになります。App

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