デザイナーじゃなくても知っておきたい色と配色の基本 | knowledge / baigie
色は私たちの身近に存在する視覚要素であり、日々の生活や行動に多大な影響を与えています。しかし、美術やデザインの専門教育を受けない限り、これほど身近な色を体系的に学ぶ機会はほとんどありません。 近年、ビジネスの現場でもデザインの重要性がよく語られます。ビジネスレイヤーで語られるデザインは課題解決を意味する広義のデザインであることも多いですが、その概念がプロダクトに落ちる段階では、ビジュアルデザインのような狭義のデザインも考えていかなくてはなりません。自分自身がデザイナーではなくとも、デザインを評価・判断すべき立場になることも、当然あるでしょう。 デザイナーでなくても、仕事の中で色を扱うシーンは他にもあります。PowerPoint等を使ってビジネス文書を作成をするとき、誰もが色を用いるでしょう。色の知識があれば、より効果的なドキュメント作成が可能になります。 このように考えると、色はデザイナー
会社のなかの筋を知る - やしお
それなりに人数の多い会社の中では、誰に話を通すだの何だのといったことがある。この前、入社3年目の若い同僚に 「それは話の持っていき先が違うよ」 「でも○○さんからそうしろって聞いて」 「それは○○さんがわかってないよ」 「そんなこと言われたってわかんないですよ」 と不愉快そうに言われて、それはそうだと思った。 どこにどう筋が通っているかというのは、背後に理屈がある。その理屈を見せずに結論だけ言っても混乱させるだけだ。それでもう少しきちんと説明したい。 その前に自分で整理しておこうと思った。 建前と実態 まず最初に考え方の枠組みについて。考える方向には建前と実態がある、とみなす。 建前 ： 条件から出発して、順番に考えたら「こうなる」という理屈 実態 ： 現実にこう運用されている、という観察結果 建前＝演繹的=セオレティカル、実態＝帰納的＝プラクティカルという感じで、逆方向のアプローチだ。こ
組織のなかで働く技術 - やしお
会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
ITエンジニアが誤った情報にツッコミを入れるのは「正しさハラスメント」ではない - give IT a try
はじめに 先日、はてなブックマークで話題になっていたこちらの記事を拝見しました。 確かに「一理ある」といえばそうなんですが、僕個人はこの意見に対して率直に「NO」だと感じました。 僕は基本的に自分の専門分野であれば、結構積極的に技術記事にツッコミを入れていくタイプです。 このエントリでは、なぜ僕は「NO」だと感じたのか、そしてなぜ積極的にツッコミをいれていくのか、その理由について書いていこうと思います。 元記事の要点 僕なりに元記事を要点をピックアップすると次のようになりました。 ITエンジニアの中には初心者の成功体験を折りに来る人がいる。 筆者は成功体験の「気持ちいい」状態を阻害する行為に疑問を覚える。 初心者にはセキュリティ周りについて教えても仕方がない。 初心者もいずれセキュリティ対策について知識を得るはずだ。 早すぎる指摘が生まれるのは「それが間違っているから」だ。 初心者にはまず
二次創作やってるやつらは全員死んじまえ
以下独りよがりで感情的なポエムだからそれが嫌なら回れ右しろ ここで言う二次創作とは著作権を持っている第三者がいるような原作もののことであり 正式に許諾・監修(不要ならなくて良い)・ロイヤリティの支払い(不要ならなくて良い)をしているものは除く お前らファン活動の一環としてコミケとかで二次創作物を配ってるよな？それはいい その二次創作物を配るときに対価を受け取ってるよな？死ねよ ファン活動とか大義名分を言ってるけどお前らが作品を衰退させてるってわかってやってるか？ 言い過ぎか 衰退させる一端を担ってるに訂正しておく 俺も昔はコンテンツの発信者だったんだよ といっても個人ではなく企業に所属してやってただけなんだけどな そこに就職してすぐのうちは情熱に燃えてキャラクタに入れ込んで 入れ込んで入れ込んで入れ込んで 我が子のようなって比喩があるけどさ 比喩どころか自分が育て上げた我が子そのものなんだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新潟糸魚川の火災で焼失した加賀の井酒造の日本酒が入手困難に→糸魚川のお酒や特産品を買うことは街全体の支援になるという事