たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に

震災からしばらくたった２月頭頃、神戸市の職員が避難所に派遣された。ところがどうも初期のころ、ボランティアとぶつかることが多くその日ももめていた。「何をもめているの？」と聞くと、インスタントラーメンを被災者に配りたいのに市役所職員がそれを許さない、と言ってボランティアは怒っていた。 市役所職員によると、被災者全員に公平に配れないのであれば、配ってはいけない、という。味噌ラーメンと塩ラーメンを合計したら被災者全員に配れるのだが、「それだと塩ラーメンが欲しい人に味噌ラーメンが配られたりなど、もめる原因になる、だから配ってはいけない」と頑張っていた。 私は「ちょっと任せてほしい」といって、その市役所職員と話すことに。「救援物資の管理、お疲れ様です。ところで問題のインスタントラーメン、どこから来たかご存じですか？」と尋ねた。「神戸市からですよ」との答えに私は首を振り、「いいえ、違います。私たちボラン

あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも

にちかの色、変すぎワロタｗｗ ダサさに学ぶ色彩学　〈主題〉 なぜアイドルマスターシャイニーカラーズの「【♡まっクろはムウサぎ♡】七草にちか」はダサく見えるのか （なぜ相対的に隣の子がおしゃれに見えるのか） 「にちかの友達かわいい！」 最近よく聞きますね。 こんにちは。 シャニマス初心者、かつ件のSSR未所持です。 門外漢として、色彩学の観点で話します。 なのであくまでネタ提供、くらいに思ってください。 ただ、SSRの七草にちかさんを見た瞬間に、強烈な違和感を覚えたもので……。 シャニマスの絵にこういった印象を覚えたことはあまりなく。この違和感が、なにに起因したものなのか。考えていきます。 （この文に七草にちかさんの人格を否定する意図はなく、七草にちかさんにこの色を与えた制作陣の色彩設計を分析したものです） 1-1　色相で読み解く七草にちか 【♡まっクろはムウサぎ♡】のムービーを初めて見たと

イラストレーションの練習を100日やりました．知らないことばかりだったので勉強していてとても楽しかったです！ いいタグがあったので記念として初日に描いたものと並べておきます#進化してたらRT見た人もする#画力変化ビフォーアフター pic.twitter.com/WKhBvyZSoi — 都路 燕禅 (@enzen3852) November 29, 2020 イラストの練習を始めてトータル100日を突破しました．一旦立ち止まって初日のイラストと今のイラストを比べてみると，見違えるほど上達できたかなと思っています． そこで今回はこの記事で，私が100日でどんな練習を行い，どんな変化を遂げていったかを振り返ってみようと思います． (追記: 60日目と70日目のイラストの削除について。着物や扇子などの模様は、自分の手元や実家にある実物の写真・インターネットの写真などを複数参考にして、いずれのデザ

回答 (5件中の1件目) この質問にかなり先行して2015年、Quora（本家）で投げかけられた質問として、 Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern? なぜ、関数型プログラマらは、オブジェクト指向(OOP)言語のデザインパターンを、言語の欠陥の象徴だと批判するのでしょうか？モナドもデザインパターンじゃないんですか？ があります。...

あんど( @ampersand_xyz )と申します。 クイズメーカーなど、色々なサービスを個人でリリースしているフリーのエンジニアです。 個人開発を支える技術のアドベントカレンダーではサービスを構築するArchitectureに関する技術の話題が多いなか、周りの方やマシュマロからの匿名メッセージ質問でUIのことに関する質問などが多かったので、本投稿ではUIやデザイン周りに関するTechnic…と言えるほど上等なものではないのですが、そのあたりの技術をお話したいと思います。 なお、自分は正直かなり我流で適当にやっているので、もっといい方法のツッコミなど歓迎しております。 1.画面サイズの最大・最小幅を最初に決めておく まずはじめにここを決めます。 いかにリキッドデザインやレスポンシブで画面を作成するといえども、極端に幅が小さい、または大きいデバイスを相手にする場合、どうしてもサイズ整合性を

※記事本文やコメント欄は長文ばかりのため、パソコンやタブレットなどの大きいディスプレイで読まれることをオススメします。 スマホのような小さいディスプレイだと「長文全体から意味を汲み取る能力」が大幅に低下するためです（それでもスマホの閲覧を意識して改行を多く入れています）。 追記を３つ行いました。 – 追記1 2017/07/15 – 追記2 2017/07/19 – 追記3 2021/01/20 —以下本文— ふと思い立ち、「国内家電は使いやすいのか」を念頭に入れ、その視点を意識しながら家電を使い、この一年間を過ごしてみました。 なぜそれをするキッカケになったのかと言うと、実家に帰省した際に、「洗濯機」の使い方がわからず挫折したからです。 ちなみに僕は今までにMacもWindowsもLinuxも使ってきており、プログラミングもやってきているので、 平均以上の「マシン」への打たれ強さはある方

本稿の執筆者、エンタースフィア代表・岡本基氏が元々任天堂のスタッフであったことは、古くからのネットユーザーには知る人も多いかもしれない。 さて、そんな氏に今回寄稿をお願いしたのは、ゼルダ新作『ゼルダの伝説 ブレス オブ ザ ワイルド』がらみのTwitter発言に編集部が興味を持ったのがキッカケ。さっそくプレイ記事の寄稿を打診したところ1週間後に届いたのは、Webメディアのコラムとしては常識ハズレの分量の大大大長文（！）。しかし今回のゼルダの歴史的意義を雄弁に語った論考であるとして、一挙掲載をすることに決めた。 本稿の1ページ目は、歴史的視座の分析。元任天堂スタッフとしての視点も交えつつ、この20年における世界のゲーム動向から見たゼルダ新作の意義を把握する。そして2ページ目は、詳細なレベルデザインの分析にもとづく、ゲームデザインの新規性の把握。昨今隆盛の「オープンワールド」はその通過点にすぎ

6月14日から3日間にかけて、アメリカで行われたゲームの見本市「E3 2016」。 それにあわせてゼルダシリーズの新作「ブレス オブ ザ ワイルド」の新トレイラーとプレイアブル体験版が公開された。 公式ホームページのトピックスに任天堂ブースの写真や体験版のプレイ映像がまとめられている。 topics.nintendo.co.jp 一通り目を通した俺はすぐに理解した。 今回のE3で発表になった「ゼルダ」関連の情報で一番重要（語られるべき）なのは、 ザコ敵「ボコブリン」であると。 今回初公開となった、 ボコブリンの造形（客観的な外見）は、見ただけで「ブレス オブ ザ ワイルド」が持つレベルデザイン（難易度設定やゲームとしての遊び）の原則が理解できるようになっている。 ※特に今作から導入された新しい仕組みや遊びが強く反映されているのがわかる まずは一番の特徴といえるボコブリンの「大きな耳」！ こ

こんにちは@kimutyamです。 今週末はいよいよScalaMatsuri2017ですね。 弊社は、今年も将軍スポンサーとして参加させていただきます。 そして今年も同人誌を配布させていただきます。 同人誌については去年配布した話を杉谷がブログで紹介しております。 labs.septeni.co.jp 今年の同人誌目次は以下となります。 ScalaでAndroidアプリ開発 単一責任の原則(SRP)についての見解と方法論 末尾再帰の呼び出し最適化の有無によるScalaコンパイラの挙動について Akka HTTP で LINE bot を作ってみました 新卒scalaエンジニアが書くISUCONの歩き方 去年に比べて記事数は少なめですが、内容は濃くなっております。 ちなみに私は弊社の今泉と一緒に『単一責任の原則(SRP)についての見解と方法論』を執筆しました。 (Scala関係ないw) 代わ

「いらすとや」についてはもはや説明はいりませんね。みなさんも一度くらいは使ったことがあるかと思います。商用フリーのイラスト配布サイトです。 で、今ちょっと話題になっていることがあります。「日本が『いらすとや』だらけになってる」というものです。 いつの間にか、日本が「いらすとや」だらけになってる(全文表示) – コラム – Jタウンネット 京都府 さらに一部では「単価の安いイラストレーターの仕事を奪いまくってる」「タダが当たり前になってしまうとイラストレーターがいなくなってしまう」といったネガティブな発言もネット上に出てきているそう。 [say]果たして本当にそうなんでしょうか？[/say] 今回はデザイナーの立場から「いらすとや」のスゴさを説明してみます。 いらすとやのイラストが無料の理由 そもそもイラストをすべて無料にしてしまってメリットはあるの？と疑問に思う方もいるかも知れません。 も

スペックワークを知っていますか？ 日本ではあまり定着していない言葉ですが、「スペックワーク (SPEC WORK)」というものが海外の広告デザイン業界で問題視されています。スペックワークを平たく言えば、「気に入ったらお金を払うよ (気に入らなければ払わない)」という類のクライアントからの要求です。 カナダの広告代理店 Zulu Alpha Kilo は、そんな業界のスペックワークについてNOを掲げ、5年前から提案依頼書の8割を断るという英断を行いました。当初は社員・クライアント含め、非常に混乱したそうですが、その結果、この5年間一度もスペックワークを行わず成長を遂げてきたのです。 そんなZulu Alpha Kiloが、一風変わった映像を制作しました。これを観ればデザイン業界の「スペックワーク」がいかに良くないことであるかが理解できます。スペックワークにNOというべきである！(Say no

イギリスのチェスタートンという批評家の名言に好きな言葉がある。 「なぜフェンスが建てられたのかわかるまで、決してフェンスをとりはずしてはならない 」 高級なクラブなどに行くと気づくのは、そこにある灰皿が極端に小さいことだ。小さく造形された灰皿はそれだけで独特な美しさを持っているが、ここには原作者の粋なアイデアが詰まっている。小さな灰皿は、一本でもたばこを吸えばいっぱいになってしまう。そうすると、スタッフが灰皿を新しいものに替える。そうするとことで、客への細やかなサービスを演出できるし、スタッフに自然と客へ細かく注目させることを可能にしている。 もちろん、これを違うやり方で実現することもできる。たとえばマネージャーが、スタッフに「客を細かく見ろ。灰皿は、客が一本たばこを吸ったら必ず変えろ」と言えばいい。そういうマニュアルを作ってもいいし、バックルームに貼り紙をしてもいい。なんらかの指示や号令

この投稿では、以前に TinyKeepDev が こちら で述べたランダムなダンジョンを生成する技法について説明しようと思います。元の投稿に比べて、もう少し具体的に話を進めるつもりです。まずは、以下に示したアルゴリズムの一般的な動作をご覧ください。 部屋の生成 はじめに、幅と高さを持つ部屋を円の中にランダムに配置しましょう。TKdevのアルゴリズムは、各部屋のサイズを生成するのに正規分布を用いています。これは一般的にとてもいいアイデアです。なぜかと言うと、これによってより多くのパラメータを扱うことができるようになるからです。幅/高さの平均と標準偏差間の異なる比率を選ぶと、通常は見た目の違うダンジョンとなります。 ここで実行すべき関数は getRandomPointInCircle です。 function getRandomPointInCircle(radius) local t = 2

国立競技場の件がようやくマシな方向に動き出したようだけど、こういう公共建築物を巡る話でいつも 「お金をかけないで作って欲しい」「無駄は省いて欲しい」という話が出てくるのが気になっている。 俺は、公共建築こそ多少のコストがかかってもいいからきちんと考えられた素晴らしい物を作って欲しいと思う。 ちょっと前に地元の図書館が建て替えられた。 省エネでエコらしいが、なんのこだわりもないただの箱みたいな建物になった。 建て替えられる前の図書館には愛着が持てたけど、このプレハブみたいな新しい図書館には愛着を持てる自信がない。 一方、武蔵境に出来た武蔵野プレイスという図書館に行ってみたらこれが素晴らしかった。 老若男女が思い思いに使える自由な雰囲気の図書館だった。 多分あの建物は地域住民に多大な影響を与え、愛されながら成長していくだろう。 でも、この武蔵野プレイスは明らかにうちの地元の図書館よりコストがか

こんど名古屋のWCANに登壇するが、そこで話の内容に繋がるイメージも兼ねて、かつ、以前登壇したUI crunchを思い出しながら、UIデザイナーについてウダウダ書いてみる。えと、ネットには公開しますしシェアもしますが、僕のマインドマップみたいな文章なので読まなくて良いと思います。ポジティブに足りないところをアドバイスしてあげようといういい人だけ読んでもらえるとうれしいです。 ■UIデザイナーとは？ 文字通りUIをデザインする人。UXの一パートではあるが、原則としてUXの責任者ではない。ただし特定の業界の特定のアプリのように、UX部分にお約束が決まっていて、作るもののの幅が限定されていると、UI = UXとなり、これがUI/UXと呼ばれるポイントではないかと思うが、厳密には、この２つの範囲は違う。 UXはどちらかというと企画寄りであるし、ビジネスと連動する場合はマーケティング寄りであったりも

以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ