Dribbble - Discover the World’s Top Designers & Creative ProfessionalsFind Top Designers & Creative Professionals on Dribbble. We are where designers gain inspiration, feedback, community, and jobs. Your best resource to discover and connect with designers worldwide.
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
オーバーエンジニアリングの正体とその向き合い方 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 問題は細部（あるいはその欠如）にあり。 議論とは、ソフトウェア開発の基本的な構成要素であり、スケーラビリティを向上させるためには避けられない摩擦であると言えます。議論を通して私たちは出来上がるものの品質に影響を与え得るような問題を早い段階で浮かび上がらせることができるのです。その1つがオーバーエンジニアリングの問題です。 ウィキペディアによると、オーバーエンジニアリングとは下記のとおりです。 十分な 安全率 や十分な機能の確保のためか、あるいはデザイン上の誤りのどちらかの理由から、アプリケーションが必要とする以上に強固で複雑なプロダクトがデザインされてしまうこと。 また、ウィキペディアには、オーバーエンジニアリングが好ましい場合として、さらに、このようなことも書いてあります。 ある特定の基準の下で安全
ソフトウェア設計が重要である理由 | POSTD
新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”（出典： Trent Erwin ／ Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
文章の作り方 - 伝わるデザイン 研究発表のユニバーサルデザイン
研究者や研究に関わる大学生や大学院生は、一年を通じて研究室ゼミや学会などで研究成果の発表を行なわなければなりません。また、近年、科学者でない人たちに対する一般向けのプレゼンや講演（アウトリーチ活動）の機会も増えてきています。他にも、研究論文や報告書を書いたり、研究費調達のために予算申請書やプロジェクトの提案書を作成したりすることも、研究者にとって欠かせない仕事です。これらはいずれも情報を他者（研究仲間や審査員、一般市民）へ伝えようとする行為であり、正確かつ効果的な情報の発信が望まれます。しかし、自己流で資料を作成して、闇雲に情報を発信していても、スムーズに情報は伝わりません。ときには誤った情報が伝わってしまい、研究の価値を正当に評価してもらえないことさえ起こりえるのです。 情報を正確にかつスムーズに他者に伝えるためには、情報をデザインすること、つまり文章を読みやすく整えたり、図表を見やすく
これだけ守れば見やすくなるデザインの基礎
2019/04/18に株式会社gumi様で行ったデザイン講義のスライドです。 デザインとは何か？デザイナーは何を考えてデザインを作っているのか？ という話から、実際にデザインを評価・検討するための言葉を紹介しています。
東京都 カラーユニバーサルデザイン ガイドライン
福祉保健局は、令和5年7月1日から福祉局と保健医療局に再編し、URLを変更しました。下の各局バナーからトップページに進み、分野別取組・キーワード等で検索をお願いします。 ブックマーク、お気に入り等に登録いただいている場合は、お手数ですが、再登録をお願いします。 The Bureau of Social Welfare and Public Health was reorganized into the Bureau of Social Welfare and the Bureau of Public Health on July 1, 2023, and the URL was changed. Please proceed to the top page from the banners of each bureau below and search by area-specific i
牛乳卵問題に学ぶ、`要望` と `要件定義` と `設計` と `実装` の違い - Qiita
はじめに 有名なプログラマージョーク プログラマの夫に「買い物にいって牛乳を1つ買ってきて。卵があったら6つお願い」と言ったら、夫は牛乳を6パック買ってきた。 プログラマーを笑う自虐ジョークとして使われがちですが、 良い題材なのでこれを元に要望 と 要件定義 と 設計 と 実装 の違いを纏めてみましょう。 下記、それぞれのフェーズの原理原則論を記載します。 各フェーズの原理原則 1. 要望 顧客(妻)の要望 を書き出す：顧客の仕事 買い物に行って牛乳を1つ買ってきて、卵があったら6つお願い。 2. 要件定義1（ダイジェスト） 顧客の要望から曖昧な点を除いて復唱する：PMの仕事 上記だとプログラマーの夫は牛乳を6本買ってきました。夫は妻に、要望をより具体的な形で復唱する必要があります。 ここでは、卵を6つ買ってくるという事を確認することで事故を防ぐことができます。 牛乳を1本買ってくる 卵が
データ視覚化のデザイン #1｜Go Ando / PREDUCTS / THE GUILD
こんにちは、THE GUILDの @goando です。 私はTHE GUILDの中でもデータを扱う仕事を中心に活動しており、「UXの改善をデータでサポートする」をミッションに取り組んでいます。 ざっくり言うと、THE GUILDのクライアント企業が運営するサービスのログを分析してユーザーの行動傾向からUXの改善点を見つけ出したり、マーケットの市場リサーチを通じてサービスの戦略の策定を支援したり、と言った内容です。 こうした活動を通じて、データ分析の結果をグラフ等のレポートに落とし込むという事を数多く行ってきました。 試行錯誤を繰り返しつつ、データをどのようなデザインで視覚化するとメッセージが伝わりやすいのか、逆にどういう点に気をつけないと誤解を与えやすいのか、といったノウハウを少しずつ蓄積してきました。 データ分析を台無しにするダメグラフかく言う私もかつて、そのグラフから何が言いたいのか
フラットなUI要素は、目につきにくく確信を持ちにくい
フラットインタフェースでは弱いシグニファイアがよく用いられる。クリックできることの手がかりを比較するアイトラッキングの実験では、ユーザーは、シグニファイアの弱いUIのほうが強いものよりも多くの労力を必要とした。 Flat UI Elements Attract Less Attention and Cause Uncertainty by Kate Meyer on September 3, 2017 日本語版2018年1月24日公開 デジタルインタフェースでは、フラットデザインが人気だが、それと並行して、シグニファイアが不十分になってきている。近年、多くのUIで、ユーザーがクリックできるものだと理解するために頼っている知覚可能な手がかりがはぎ取られ続けてきたからだ。 今回、我々はインタフェース上のユーザーの目の動きを追跡して視覚化するアイトラッキング装置を使い、クリックできることの強いシ
その資料ちゃんと伝わってる？ノンデザイナーに贈る、3つのポイントで格段に伝わる資料になる方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさん、こんにちは！ エイチームライフスタイルアドベントカレンダー2017の21日目の 今日は株式会社エイチームライフスタイルのデザイナー@mgmg121が担当します。よろしくお願いいたします はじめに みなさんは業務や勉強会でスライドの資料を作成することはありますか？ 私は普段、社内で営業やエンジニアのプレゼンを聞くことが多いのですが、話すのが上手い人、言語力が優れた人が多いためか「プレゼンうまいなぁ、いいなぁ！」とよく感心します。 ただ…実は… 資料がすこーし見づらくて「もったいない…！」と思うことが多いのも事実。 さらに伝わるプ
使いやすさ日記 by U'eyes Design Inc.
昨年末に各社から発売され、今年は普及年だったと思われるスマートスピーカー、我が家でもリビング、仕事部屋、寝室、風呂、車とほとんどの場所で待機しており、買い物リスト登録、家電操作などで大変重宝しています。 その中でいつも微妙に困っているのは天気予報です。便利は便利ですが、「明日の天気は？」と聞いた時のレスポンスに日付や曜日が含まれていないので、例えば深夜に言う「明日」とか「今日」がいつを指しているのか判断に困ります。月曜日深夜1時（厳密には火曜午前1時）に寝る前に明日の天気が気になったとして、「明日の天気は？」と聞いたとしましょう。音声アシスタントは「明日の天気は晴れ、気温は18度です」などと返してきます。さて、それは寝て起きた火曜日のことでしょうか？それとも正確に暦に基づいた火曜日の翌日、水曜日のことでしょうか？人間同士の会話であれば0時を過ぎていても寝る前に言う「明日」なら火曜日のことだ
先進的すぎるVR版『Rez』の到達点…VRの可能性であり、困難への先回りした解答さえ示す“傑作中の傑作”：「なんでゲームは面白い？」第七回
VR元年と呼ばれた2016年が過ぎ、VRは一般的にも普及した娯楽になりつつある……と言いたいところだが、なかなかそうは行かないようだ。VR体験へのハードルを下げてくれそうな存在であったはずのPS VRは発売以降、慢性的に品切れを起こし続けている。一般層への広い普及には、まだまだ時間が掛かりそうだ。 だが、そんな黎明期、過渡期的な現在にあって、既にVRメディアの金字塔と呼ぶべきゲームタイトルがある。 ――それは『Rez Infinite』だ。 （画像はPlayStationの公式サイトより） なぜ『Rez Infinite』はVRの金字塔とも呼ぶべき存在なのか。その答えは至ってシンプルだ。このタイトルは現状、VRメディアだからこそできる体験の本質を、もっとも端的な形で表現することに成功しているタイトルだからだ。 では、VRだからこそできる体験とは何なのだろうか？ 『Rez Infinite』
［GDC 2017］開発者が語る「ゼルダの伝説 BotW」のとてつもなく自由なゲームプレイはこうして実現した - 4Gamer.net
［GDC 2017］開発者が語る「ゼルダの伝説 BotW」のとてつもなく自由なゲームプレイはこうして実現した ライター：米田 聡 2017年3月3日に発売となった「ゼルダの伝説 ブレス オブ ザ ワイルド」（Nintendo Switch / Wii U，以下 BotW）は，ゼルダシリーズ初のオープンワールド型ゲームであることや，Nintendo Switchのローンチタイトルにもなっていることから，大きな注目を集めている。 そんなBotWの内幕を開発陣が語る講演「Change and Constant: Breaking Conventions with 'The Legend of Zelda: Breath of the Wild'」（変わるものと変わらぬもの，「ゼルダの伝説 ブレス オブ ザ ワイルド」で慣例を打ち破る）が，GDC 2017の3日めである北米時間2017年3月1日に
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダ鳥獣戯画 – 鳥獣戯画ベクター素材化サイト