「変更しやすいUI」を意識したデザイン | keisuke tsukayoshi
いくつかのサービスのデザインに関わって、最近思うようになったことを書いてみる。 要約すると サービスデザイナーはプロダクトの最終的なゴールを高めることを目的としてデザインすべき。あと最初から本気だすとUIの変更要求に対して簡単に舵がとれなくなる。 ということが言いたい。 ※新規サービス開発の初期デザインのお話です 最初から本気は出さない 最初から本気を出すと、最適なUIでないにも関わらずみんなが気に入ってしまうような間違った素敵デザインが生まれてしまったり、リニューアルしたくても作りなおすのに工数がかかりすぎるデザインが生まれる。一から百まで全部本気だすなというわけではなく、最適なUIがまだ手探りな状態においては凝ったデザインはPDCAサイクルを鈍化させてしまう、ということ。 素敵デザインをするのは、出来る限り最適なUIに目測をつけてしっかり検証を終えてからとりかかっても遅くはないと思いま
DB の state は State Machine で管理する - ボクココ
最近は毎日プログラミングの日々を過ごしている。 そんな中、とあるテーブル(ドキュメント)で状態を管理しなきゃいけない場面があった。 この問題の一つの手としてはstate をint で保存し、一つ一つの数字を何かしらの状態に紐づけるやり方だ。これを実践してみたことがある方ならわかる通り、後でこれをメンテする人がいったいその数字が何なのか、をいちいちどっかのドキュメントを見て調べなければならない。これの管理がとても面倒。何かの状態が新しくできたらそのドキュメントもちゃんと更新しないと、色々崩壊する。 State Machine State Machine はそれぞれの状態と、状態の遷移を管理する一種のデザインパターン。これにより、数値での管理をなくし、さらにある状態からある状態への遷移を限定することができる。例えば、状態として「走る」「歩く」「止まる」「寝る」があるとしよう。いきなり「走る」か
Ruby on Rails移行勉強会を実施しました！withランサーズ株式会社 | ITANDI技術ブログ
横沢です、本日もよろしくお願い致します。 先日のエントリに興味を持って頂き話を聞きたいという事で、ランサーズ株式会社の永田さんと堀川さんをお招きしRuby on Rails移行についての勉強会を行いました。実際には「移行」という部分だけでなく、システムやサービス全般に関わる様々な議論が行われとても有意義な時間が過ごせたと思います。ランサーズ株式会社の永田さん、堀川さん、改めてありがとうございました！ 勉強会で利用したアジェンダスライドを掲載しておきます、ディスカッションベースで進めたのでスライドの内容は薄いです。 今回外部の方と話しをする事で新たに発見、感じる事が多々ありました。 ・移行時にサービスを絶対に止めない、あるいはダウンタイムを最小化するにはどうするか ・CakePHP等に比べ１プロセスが重くなりがちなRoRでピークアクセスに対応するにはどうするか ・PHP系フレームワーク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
