タグ

関連タグで絞り込む (313)

タグの絞り込みを解除

designに関するa2ikmのブックマーク (508)

  • 「ルールが変わることは歓迎」、iPhoneアプリの第一線を走り続ける深津貴之氏の思考法とは | HRナビ by リクルート

    深津貴之氏は、iPhoneアプリ「ToyCamera」をヒットさせて以来、スマートフォンアプリの第一人者として活動を続けている。1年経てばルールが変わる激動のスマートフォンアプリの世界で、深津氏はいかにして変化に対応してきたか。「ルールが変わってリセットがかかることは、むしろ歓迎」と話す深津氏の思考法を聞いた。 プロダクトデザインの役割は「製品に何を入れないか」を決めること 今回は、深津氏の出発点にさかのぼって話を聞くことにした。深津氏は、武蔵工業大学(現在の東京都市大学)環境情報学部 都市情報研究室を卒業後、ロンドン芸術大学内のカレッジの一つ、Central Saint Martins College of Art and Designに入学し、プロダクトデザインを専攻する。 このプロダクトデザイン科のオリエンテーションで聞いた内容を、深津氏はよく覚えているという。「『流線型のかっこいい

    「ルールが変わることは歓迎」、iPhoneアプリの第一線を走り続ける深津貴之氏の思考法とは | HRナビ by リクルート
  • クラスの命名のアンチパターン - Qiita

    昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod

    クラスの命名のアンチパターン - Qiita
  • iOSアプリデザインリニューアルの舞台裏 - クックパッド開発者ブログ

    モバイルファースト室の @slightair です。 先ほど、デザインをリニューアルしたクックパッドiOSアプリ 6.0.0 をリリースしました。 https://itunes.apple.com/jp/app/kukkupaddo-no.1reshipi-jian/id340368403?mt=8 この記事では、どのようにして新しいデザインをiOSアプリに適用していったのかを紹介したいと思います。 新しいアプリの画面 スクリーンショットを見ていただければわかるように、全体的にフラットな印象を与える画面に変わりました。 トップ レシピ詳細画面 サイドメニュー この記事で全ての画面を紹介することはできませんが、ぜひダウンロードしてお手持ちのiOS端末で触ってみてください。 新デザインの適用 基的には、画面デザイン案をもらい、既存のアプリを修正して少しずつ適用していく形で進めていきました。

    iOSアプリデザインリニューアルの舞台裏 - クックパッド開発者ブログ
  • SMACSS 読んだ - CHROMA

    Scalable and Modular Architecture for CSS (日語) を読んだのでそのメモです。 CSSルールのカテゴライズ カテゴライズを行い、それに準じた命名をセレクタに付ける。 ベース レイアウト モジュール 状態(ステート) テーマ レイアウトには1つ以上のモジュールを保持する必要がある。 モジュールは最利用可能なパーツとする。 命名規則 レイアウト、状態(ステート)、モジュールにはプリフィックスを使用する。 レイアウトのスタイルにはlayout-を付ける。または、ドキュメントなどでコーディング規約をまとめてあるなら省略してl-と付けても良い。 状態(ステート)にはis-を付ける。 モジュールは作成される数が多いので、モジュールごとにプリフィックスを付ける。 /* Example */ .comment { } .comment-user { } ベースル

    SMACSS 読んだ - CHROMA
  • DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ

    ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬にわせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら

    DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
    a2ikm
    a2ikm 2014/07/18
  • エンジニアこそ色彩デザインを学ぼう - ppworks.jp

    学ぼうよ、と思っていて、 新人デザイナーのための色彩デザイン・配色のルールを学べる 作者: 柘植ヒロポン出版社/メーカー: ソシム発売日: 2011/10/01メディア: 単行 クリック: 1回この商品を含むブログを見る を読んでいました。 @ken_c_lo氏が以下のスライドで触れていますが、エンジニアがデザイン学ぶのマジオススメとのことです。よっしゃ、学ぼう。 新人デザイナーのための色彩デザイン・配色のルールを学べる 新人デザイナーのための色彩デザイン・配色のルールを学べる 作者: 柘植ヒロポン出版社/メーカー: ソシム発売日: 2011/10/01メディア: 単行 クリック: 1回この商品を含むブログを見る WEBというより印刷のデザイナー向けのなのかな?という印象なのですが色の使い方という意味では勉強になりました。 特色の話やCMYKプロセスカラーの話は一旦無視しながら

    エンジニアこそ色彩デザインを学ぼう - ppworks.jp
  • WebエンジニアのためのWebサービスデザイン実践講座

    DeNA 社内勉強会に呼んでいただいて、お話させていただきました。 Reviewに登場していただいてるサービスはこちらです。 動く小説投稿サイト Denkinovel by @katryo さん http://denkinovel.com/ ご協力ありがとうございました( ˘ω˘)

    WebエンジニアのためのWebサービスデザイン実践講座
  • HTML Snippets for Twitter Boostrap framework : Bootsnipp.com

    <link href="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/css/bootstrap-combined.min.css" rel="stylesheet" id="bootstrap-css"> <script src="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/js/bootstrap.min.js"></script> <script src="//code.jquery.com/jquery-1.11.1.min.js"></script> <!------ Include the above in your HEAD tag ----------> <div class="container"> <div class="row"> <input type="h

    HTML Snippets for Twitter Boostrap framework : Bootsnipp.com
  • Pteromys: Interactive Design and Optimization of Free-formed Free-flight Model Airplanes

    (Left) Our model airplane design tool analyzes the aerodynamic properties of a glider and optimizes while the user interactively designs the plane. (Center) The user fabricates the airplane. (Right) The airplane actually flies. Abstract: This paper introduces novel interactive techniques for designing original hand-launched free-flight glider airplanes which can actually fly. The aerodynamic prope

    Pteromys: Interactive Design and Optimization of Free-formed Free-flight Model Airplanes
  • 寿司ゆき (SUSHIYUKI) - ゆるふわお寿司のLINEスタンプ

    寿司ゆきとは? 寿司ゆきは、ゆるふわな雰囲気が特徴のお寿司のキャラクターです。あわゆきのTwitterイラストアイコン(アワユキコン)からスピンオフして誕生し、LINEのクリエイターズスタンプとして2014年5月に発売を開始いたしました。おかげさまでたくさんの方に可愛がっていただいている、今いちばんしあわせなお寿司です。 お持ち帰り用『折り詰め寿司ゆき』 寿司ゆきのイラストセット『折り詰め寿司ゆき』を無料でダウンロードできます。このページで規定するクリエイティブ・コモンズ ライセンス および「その他の許諾に関する事項」を守っていただければ、ご利用は自由です。内容をご確認の上、ご利用ください。

    寿司ゆき (SUSHIYUKI) - ゆるふわお寿司のLINEスタンプ
  • 排卵期予測アプリ「Clue」がデザインにピンクを使わない理由

  • 実践的な設計って、なんだろう?

    Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計

    実践的な設計って、なんだろう?
  • 大飴屋

    ようこそ 当サイトは東方同人サークル「大飴屋」のホームページです。 作者についてはプロフィールをご覧ください。最近の活動記録もあわせてご覧ください。依頼や相談など、お気軽にお問い合わせください。

    a2ikm
    a2ikm 2014/05/10
    デザインが綺麗だ
  • ツール寄りのサービス開発側が提供すべきはレールであってカスタマイズではない - kony.cc

    サービスのことを考えるうち、いろんな人の要望や欲求に答えたくなり、いろんな機能を盛り込もうとしてしまう。 そういうときにはYAGNIの精神に立ち返ればいいんだけど、それ以上に意識した方がいいのは「ユーザーはいい感じにして欲しい」のであって「自分の手であれこれ調整したい」わけではないということだと思う。 カスタマイズできることは機能を提供する側からするとすごく楽で、必要そうなものはとりあえず何でもかんでも追加することができてしまう。 ただそれはユーザーからすると「時間をかけてカスタマイズする」という余計な手間が増えるだけで、非常に辛い(もしかすると無駄な)時間を浪費することになってしまう。ユーザーはあくまでも「自分の苦痛を取り除いてくれる便利な仕組みを手軽に、かついい感じに使いたい」だけだったのに。 例えば、カスタマイズが好きなプログラマでさえ、エディタのカスタマイズと維持にはけっこう苦

    a2ikm
    a2ikm 2014/04/17
    “ユーザーはいい感じにして欲しい” カスタマイズする方法を調べるのも面倒だしね。
  • 《REST思想》と《リソース指向》と《Webページ》を一緒にしてはいけない - Qiita

    はじめに Ruby on Rails や同種のフレームワークを使っていると、《REST思想》と《リソース指向》と《Webページ》がごちゃまぜになったWebアプリケーションをつい設計してしまいます。 三つの違いを意識し、適切なWebアプリケーションを作成するようにしましょう。でないと後悔することになります。 なお、この三つの用語は来の意味とずれているかもしれません。 「コメント」、「編集リクエスト」大歓迎です。 解説 http://yourhost/books のURLでの一覧が取得できるようなWebサービスを提供するとします。 では /books を含めた各URLはどのように振る舞うべきなのでしょうか。 (URLと言っている部分でも実際はpathを指している場合があります。ご了承ください)

    《REST思想》と《リソース指向》と《Webページ》を一緒にしてはいけない - Qiita
    a2ikm
    a2ikm 2014/03/22
    もにょっとした部分をJxck_さんが突いてた。リソース指向とRESTはまた違うのか、勉強しよう
  • ドメイン駆動設計読んだ - はこべにっき ♨

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型購入: 19人 クリック: 1,360回この商品を含むブログ (130件) を見る ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれるだった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。こので例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のようなWebエンジニアとっては参考にしにくいかと思っていたのだけど、まったくそういうことはなく、たいへん参考になった。 ドメイン駆動設計でいうドメインとはソフトウェアが

    ドメイン駆動設計読んだ - はこべにっき ♨
    a2ikm
    a2ikm 2014/03/22
    積読してるし、そろそろ読むか…
  • Ruby RoguesメンバとiOSエンジニアのAPI議論 - ワザノバ | wazanova

    http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し

    a2ikm
    a2ikm 2014/03/21
    “つまりデータをどう保存しているかを反映させたAPIでなく、どのようにAPIが使われるのかを考慮してAPIをつくるべき” ですよねorz
  • 例えば OSFA な API をやめる - @kyanny's blog

    OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み

    例えば OSFA な API をやめる - @kyanny's blog
    a2ikm
    a2ikm 2014/03/07
    マスターデータのみを取り出すような場合には綺麗なRESTfulベースがいいけど、要求されるアプリケーションのロジックが端末によって異なる場合は分けたほうがよさそうだと最近思う
  • APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight

    ちょっと前にTwitterAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー

    APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
  • RailsでInteractorをうまく利用する - ワザノバ | wazanova

    http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m