デザイン上級者は、中級者と初心者と何が違うんだろう？って思った時に、こちらの本が役に立ちました。 『上達の法則 – 効率のよい努力を科学する –』という本です。この本には、碁や茶道など、あらゆる分野に共通する上級者の特徴がのっています。この本を参考に、デザイン上級者の特徴と、上級者になるための実践方法を書いてみました。 デザイン上級者の特徴 1. 上級者は一つのデザインから読み取ることが多い 一つのデザインを見たとき、上級者の方が中級者、初級者よりも気づくことが多いです。例えば、背景に薄くグラデーションがかかっているとか、縦のグリッドのラインが揃っているなど。 また、そのデザインからたくさんの情報を引き出しているので、長く見ても退屈しにくいという特徴を持っています。 2. 上手なデザインをするということに高い価値をおいている 上級者は、デザインに対して本気で取り組む度合いが高いため、上手な

My iPhone 11 is perfectly fine, but the new buttons on the iPhone 16 are compelling

Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo

全国的にインフルエンザが猛威をふるい出している昨今、読者諸賢の住まい周辺ではいかがだろうか。筆者の子どものクラスでは、とうとうクラスメートの半数が撃沈、学級閉鎖の憂き目を見た。 学級閉鎖すると病臥してない子どもまでもが戒厳下におかれる。基本的に自宅待機、すわチャンスとばかりにネズミの国や海に出かけてはイケナイのである。学童保育に行くことも禁止される。働く親にとっては我が子の発症ももちろんだが、学級閉鎖も恐怖だ。 しかし学校内でどんなに感染症が跋扈しようと、いま発症してない全ての子どもたちは、他人事のようにピンピンしている。彼らはいかに気温が限りなく0度に近い状態であっても、体感的に暑いとなれば綿シャツ一枚で活動することを厭わない。 北風吹きすさぶ児童公園の日だまりに寄り集まる小学生男子たち先日子どもたちの通学路で不審者対応パトロールに当たっていた筆者。こちらは耐寒フライトジャケットを着込ん

提案資料や設計資料をアイコンや図入りでわかりやすくしたいけれど、寄せ集めたアイコンは図柄がばらばら…足りないものがある･･･など思ったことはありませんか？ そんなご要望に答えて、資料に使えそうなアイコンセットをぷちぷち自作してみました。 今回は需要の多いビジネス系アイコン60種類(png形式)です。 顔あり顔なしバージョンがありますので用途に合わせて。 ↓アイコン見本↓ ↓使用例↓ 個人使用も商用もフリーですので、気に入ったら提案書や設計書で、デザインのポイントとして、是非使って下さい。(二次配布はご遠慮願います) もし好評でしたら、次回作も？ こんなん欲しいなーというご要望も、 コメント欄・ブコメ・Twitter などでお待ちしています！ ダウンロードはこちらから Tweet hinata Webデザイナーをやっているイラスト描き屋さん。 記事を書きながらデザイン勉強していきます！ が、

1. ソーシャルゲーム スケールアウトの歴史 gussan@Drecom Co., Ltd. Copyright © Drecom Co., Ltd. 12年2月20日月曜日

タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、

チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多