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から手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能
Ruboty のコードリーディングで Ruboty の仕組みを理解すると共に Ruby の設計・実装の定石を学ぶ #ruboty 概要 Ruboty のコードリーディングで Ruboty の仕組みを理解すると共に Ruby の設計・実装の定石を学びます。 確認対象は、コマンドラインで ruboty を実行して Ruboty が起動するまでの部分です。 はじめに Ruboty の構成を理解するために、この解説を作ろうと思ったのですが、 Plugin による拡張などを含めた高レイヤの設計技法 適切な命名により、単一責務で分割されたメソッド群 メモ化、 alias method chain , ..etc など様々な Ruby のイディオム など、 Ruby の良い作法を 高レイヤの設計技法 から 低レイヤのイディオム まで幅広く学ぶ素材として 非常に魅力的なソフトウェアであることに気づきました
日々の出来事、メンバーの働く様子や声、未来への想いなど、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
数日前に Pixate という iOS 向けミドルウェアがリリースされました。なんとiOSアプリの見た目を css で書けるという、全ウェブ開発者感涙のライブラリ。こりゃすげえ。ただし無料というわけにはいかず、18,000円くらいでこざいます。 2月9日 追記 トライアル版と、個人利用のための無料版が出たようです。 RubyMotion の teacupのように css チックな DSL で書ける、というものはありましたが Pixate はその辺とは次元が違ってて、普通に css ファイルに css を書くことができる。 button.blue { position: 60, 100; size: 200, 40; border-radius: 7px; font-family: 'Courier New'; font-size: 18pt; font-weight: bold; bord
#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を使ったり、人からパクったりして、極力失敗しない方法
Sooner or later, all developers are required to interact with an API. The most difficult part is always related to reliably testing the code we write, and, as we want to make sure that everything works properly, we continuosly run code that queries the API itself. This process is slow and inefficient, as we can experience network issues and data inconsistencies (the API results may change). Let’s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
