なんか突然東京行きたくなったので、ひょひょいと行ってきた。 たまたま立ち寄ったクックパッドっていう会社でクックパッド流UIの作り方という勉強会してたので、偶然持ち合わせていたはてなステッカー渡したりおいしい料理いただいたりした。 UI/UXのためのSass 池田さん / サービスデザイン部 Sass / Haml (エンジニア・デザイナー問わずに) Github デザイナーもpull req 一つのサービスを複数チームで開発 各デバイスで速いサイクルでの開発 Sassとは → ぐぐれ 全体のデザインを束ねる → デザインガイドライン ガイドライン Sassで統一的なものを提供する 画像を使わずにCSSでデザインするメリット mixinをつかって統一できる 画像編集がいらない プロパティの変更によってデザインに幅をもたせる事ができる mixinの中身は応用がきくような仕組みにしておく 検証を
前回の記事「Ruby、君のオブジェクトはなんて呼び出せばいいの?」で、Rubyには大量のメソッドがあることが分かりました。今回はその補足として、各クラスごとのメソッド数を数えてグラフ化してみます。 インスタンスメソッドを数える まずは、インスタンスメソッドを数えましょう。グラフ化の対象は、10以上のメソッドを持つクラスです。最初にクラスごとのメソッド数をリストアップします。 klasses = ObjectSpace.each_object(Module) def live(methods) methods.reject { |m| "#{m}".start_with? '_deprecated' } end methods = klasses.map do |k| [k, live(k.methods(false)).size, live(k.instance_methods(false
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
XMLの操作を標準化した物としてDOMやらXPathやら各種規格が存在するわけですが、JSONでもそのようなよく利用される操作を共通化した物が存在すると便利な場面もあるかもしれません。 そこでIETFのappsawg WGで提案されているのが、JSON PointerとJSON Patchです。 まだ提案されたばかりでほとんど何も決まっていないのが実情なのですが、もしRFCとして公開されるほどの物が出来上がれば、標準的な枠組みとしては強力な物になるかもしれません。 JSON Pointer JSON PointerはXMLで言う所のXLinkとXPathの機能を併せ持ったような物で、JSONの構造の中のあるオブジェクトを表すのに用いられたり、URL中においてfragment identifierとして使われる事でJSONの構造中の特定のオブジェクトを指し示すのに使われる事を想定しています。
RailsにおけるRESTfulなURL設計勉強会 つぶやきのまとめ。 千駄ヶ谷.rbなのに渋谷にあるミクシィで行いました。
本サイトでも何度か紹介している「Blabo!」がリニューアル。これ面白いサービスなのでぜひチェックを。 ポストイット風オンラインボードUI 色々な人のアイデアを集められるという基本的な機能は変わらず、ポストイット形式のUIを採用するなど、特にデザイン面で大幅にリニューアルが掛かっています。 例えば「コワーキングスペースにもっと気軽に来れるようにするためにはどうしたらよい?」というアイデアボードを見てみましょう。現在71(!)もの投稿が集まっています。しかも投稿がどれも面白い。UIいい感じです。 投稿はツイッター/フェイスブックと連動しており、ソーシャルメディアでの拡散効果もあります。 ・若者の投票率を上げる施策を、一緒に考えて下さい! ・日本の図書館がもっともっと楽しくなるにはどうしたらいいんだろう? ・防災対策しようと思った時にあると嬉しいウェブコンテンツって? などなど、創造性を刺激す
2012年04月05日01:53 カテゴリ RESTをとるか、WebSocketをとるか どうせWebアプリケーションを作るのなら、できるだけRESTfulに作りたい、と僕は今でも思っている。 とはいっても、セッションIDをcookieに保存する例のように、あえてRESTのスタイルを崩すべき場合もあろう。 非同期処理についても、RESTにこだわってジョブリソースを云々するより、WebSocketを使って完了をクライアントに伝えるほうが簡単だ。だから、スタイルを崩してWebSocketを使ってよい。 本当にそれでよいのだろうか。気になったので、RESTの提唱者であるRoy T. Fielding氏がWebSocketをどう評価しているのか調べてみた。理解に誤りがあればご指摘いただきたい。 Re: [hybi] WebSockets (2009-03-30) なぜWebページからのプッシュが必
公開されたのはもう去年のはなしだけど、Facebook の リリースエンジニアリングの Tech Talk (予告編) は面白い。話している Chuck Rossi さんは Facebook のリリースエンジニアリングチームのリーダーだ。 彼は “The business requires change, but change is the root cause of most outages!” と話をはじめる。Facebook の規模で毎日変更をリリースするために、リリースのリスクをできるかぎり減らさなくてはいけない。そのために出てくるのが「文化」と「道具」だ。 現在のソフトウェア開発では開発者と顧客 (your mom) の間に薄いレイヤーしかない: 昔は QA とかプロダクトマネジャーとかいろいろいたけど、いまは違う。 ブランチとリリース: 開発者は trunk にコミットする。日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く