Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか（本当はそこまで考えていなかったけど）悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 本記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能
Rails Guidesでは「Resource Routing: the Rails Default」として namespace, resource, resources といったメソッドを利用する方法が紹介されている。これまでとりあえずこの機能を使って開発してきたが、これは果たして本当に積極的に利用した方が良い機能なのか。 あるとき 試しにTwitterのAPIのようなルーティングを定義しながら、Resource Routingを利用する場合としない場合とを比較してみることにする。ここでは (Resource Routingを利用するメリットを出すためにも)、API用のPrefixとして各パスの先頭に /api/v1 を付けることにする。このAPIはアクセストークンの発行や、tweetの取得、投稿、ユーザやフォロワー情報の取得などの機能を提供する。また、/api/v1 以下のどのパターン
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
10/4に渋谷で開催された「モバイルUI/UXのキホン」 に参加しました。2011年からいろいろなテーマで開催されている歴史のある勉強会なのと、ディスカッションや意見交換を通じた双方向性を大切にしている、学びの多い勉強会でした！ 今回は勉強会の中で特に参考になった点を書いていきます！ 🍣 発表スライド発表の際に使われたスライドです。しっかりとした内容です！ 発表スライドは「prezi」というサービスを使っているそうです。動きのあるカッコイイデザイン！ 🎃 UI/UXは最近のバズWordデジタルガジェットでは特にいえることですが、市場が成熟してきて機能的な差別化が難しくなってくると、ユーザーの体験(UX)が重視されるようになってくるそうです。スマホアプリケーションは特にこういった要素が強く、ココ最近は『UI/UX』がバズWordになっているそうです。 🐹 UI/UX/IAの言葉の定義ま
10/27(土)に 第一回プログラマ向けデザイン勉強会 を開催しました。 この勉強会は毎月やっている デザイナー向けプログラム部 (P4D) の逆バージョンで、デザイナさんにプログラマがデザインを教わるという趣旨で開催しました。 そして講師役として、いつもP4Dの方でもお世話になっている @machida さん、@ken_c_lo さん、@saucerjp さんの3人にお願いしました。 もっともこの3人をはじめ、P4Dに参加されているデザイナさんは普通にJSやFlash、ObjCなんか書いていたりして単にデザイナと呼んでいいのかどうかは怪しいところですが。 RailsエンジニアのためのTwitter Bootstrapカスタマイズ例 まずは@machidaさんのTwitter Bootstrapのカスタマイズ例の話からでした。 このテーマはP4D参加のプログラマからしきりにリクエストの
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
Getting Real や Basecampなどで有名な37signals、そこのデザイナーである@jonasdowney さんがよいことを書いてらして、そうだよなーと思ったので訳してみました。英語あまり得意でないので割と勢いで適当に意訳しました。誤訳あったらすいません。 原文：Learning Rails made me a better designer by Jonas of 37signals - Signal vs. Noise （以下、翻訳）--- Railsを学んだことで私はより良いデザイナーになった Jonas Downey wrote this on Feb 22 37signalsのデザイナーはコードを書く。HTMLやCSSだけではなく、RubyやJavaScriptも書く。私たちはプログラマの手助けなしで、当然のごとく自分のアイデアを実装することができる。 新しいB
#p4d Rubyistのためのデザイン講座 12:30 - 13:30 発表1: @machida さん / 「RailsエンジニアのためのTwitter Bootstrapカスタマイズ例」 13:50 - 14:50 発表2: @ken_c_lo さん / 「少ない手間と知識で "それなり" に見せる、ズルいデザインテクニック」 15:10 - 16:10 発表3: @saucerjp さん / 「ノンデザイナーのための配色理論」 16:30 - 17:45 実習: オトナの塗り絵で学ぶデザイン 発表内容は、前回の「第一回 プログラマ向けデザイン勉強会 #design4p」の再演で、前回1画面に詰めすぎて喋りにくかったという反省から、きちんとスライドを分割して臨もう…と思っていたのですが、前の晩にさあ作業をしようと思ったらいつの間にか寝てしまい当日の朝になっていたという失態をやらかし、
Sassを使ったり、人からパクったりして、極力失敗しない方法
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
