Idobataにデプロイの通知をさせる - 良いあそなすちゃん
idobata最高ですね。https://idobata.io idobataはHerokuやGithubなどと連携することでコミットしてpushすると自動的に通知が来たりしてだいぶ便利なんですが、自分のWebサービスでHerokuを使っていないとデプロイの情報まではやって来ません。これはちょっと駄目ぽいのでdeploy.rbにをいい感じにしてみましょう。idobataには便利なAPIがあります。 gist6844690 はい。これだけですね。実に簡単ですね。最高ですね。 僕のasonas.jpの部屋には僕しかいないし、デプロイも30秒ぐらいで終わるのであんまり意味がないですが、idobataを使いはじめた人はどんどん活用してみるといいと思います。
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
The power of MySQL GROUP_CONCAT
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
藤田晋『ユーザー目線の勘違い』
ネットサービスのプロデューサーや 開発陣と仕事をしていると、 最初はユーザー目線で創っていた 筈なのに、いつの間にか そうではなくなっていくパターンは 大きく分けると二つあります。 （１）収益を稼ぐことを優先する。 （２）運営側が使わせたいサービスを 全面に押し出す。 そして、実感値として圧倒的に（２）の ケースのほうが多いです。 昨日も新規サービスをチェックしていて、 「それは我々が使わせたい機能の ゴリ押しでしょ」 「ユーザーが使いたいものではなくて、 自分が使わせたいんでしょ」 などと指摘したのですが、この話、 今まで本当に数えきれないくらい同じ 話を多くのプロデューサーにしてきました。 「ユーザーに対するデリカシーが お前は足りないんだよ！」 とか、 「おもてなしの心がないのか！」 などと口汚く罵ったこともあるのですが、 大抵の場合、それを指摘された側は、 怒ってる私をみてキョトン
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
ユーザーの知識は低いレベルで停滞する
学習というのはたいへんな作業なので、ユーザーのやりたいことではない。その結果、彼らはユーザーインタフェースの探索をすることもなく、ほとんどの機能について知らないままだ。 User Expertise Stagnates at Low Levels by Jakob Nielsen on September 28, 2013 日本語版2013年11月25日公開 コンピュータシステムを長期間利用しているユーザーでも、知っていて使っているのは利用可能なコマンドや機能のほんの一部だけであることは多い。デザインのユーザビリティが優れていれば、ユーザーはシステムを利用しはじめて間もなく、かなり容易に一連の基本機能を理解する。しかし、その後、彼らは伸び悩み、それ以上はたいしてスキルが上がらない。システムを頻繁に使っているユーザーですら、年にわずか1つか2つの新しい知識を身につけられるようになるまでには何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vagrant と Chef でつくるはてなブックマークの開発環境
Run Silex Application in Command Line