実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
プログラミングと楽しさの大切さ - どくらぼ
なんか書き残しておきたくなったので、唐突にブログを書く。 プロ野球選手のイチローが、42 歳でメジャーリーグ記録に迫る勢いで今でも活躍しているというニュースをたまたま見かけた。 仮に私の体にイチローの魂が突然宿ってしまったらどうなるだろう……というめっちゃどうでもいいことを考えた。たぶん、明日の朝、私は早朝ランニングをしていると思う。そこまで想像した時に考えたのは、やっぱりすごい人にはすごい理由があるんだよなってことだった。同時にきっと、よく言われていることではあるけど遅すぎるってことはないんだろうなとも思った。 すごい人には、すごいと言われるだけの理由がある。 だから例えば、すごいと言われたいのなら、すごいと言われるだけの努力や生き方が、キレイ事じゃなくてやっぱり必要なんだと思う。 でも、努力してがんばってすごいと言われるのって実は本質から外れているような気がする。 たぶん、好きでやって
Unity 5の新機能FrameDebuggerでグラフィックパフォーマンスを改善する - Qiita
追記：2015年11月27日 本記事の旧タイトルは「Unity 5 Proの新機能FrameDebuggerでグラフィックパフォーマンスを改善する」でしたが、これは本記事がUnity 5リリース前に書かれたためで、Unity 5正式版は無料版PersonalでCloud、Team Licenseなどのアドオンを除くエディタ上の全機能が使用可能になったため、本記事から「Unity 5 Pro」の記述を取り除きました。 Unityアプリのパフォーマンス最適化 UnityはMonoを採用しているため、C++やObjective-Cのようにネイティブのバイナリコードが出力されるわけではなくMono Virtual Machineで動作する中間言語が出力されそれを読み込んでアプリを実行しています。（iOSでは規約のためネイティブに事前コンパイルされています） と言っても現在ではCPUの性能が向上し、
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
関数や変数のネーミングに悩んだら「codic」に日本語名を入力するとある程度解決するかも
codicとは codicは、日頃、変数名や関数名に頭を悩ませるプログラマのためのネーミング辞書です。 以前は、プログラマ向けの単語辞書といった感じだったのですが、Ver.3からは、「日本語を入力すると、ふさわしい名前を勝手に生成してくれる」という仕様になりました。 例えば関数名を作るのに、「従業員数を取得する」と入力するだけで「get_employee_count」という名前を勝手に生成してくれます。 これだけでも、かなり便利なんですが、codicにはその他にも、プログラミングのための便利な機能が満載だったので、その使い方などを紹介したいと思います。 codicの使い方 codicの主な機能は、日本語を入力すると、勝手にネーミングを生成してくれると言うことです。 ただ、ちょっとした使い方次第で、より便利に利用できるので、その使い方などの紹介です。 基本機能 まずは、基本的な機能、「日本語
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
簡単インストールから始める初心者のためのRuby on Railsチュートリアル
Railsは、その名の通りプログラミング言語「Ruby」向けのWebアプリケーションフレームワークです。オープンソースで開発が続けられています。 よく見られるWebサービスは、データベースにデータを保存し、ブラウザーを使ってその入出力を行います。そのようなアプリケーションを作る場合、開発者はRailsを使うことで高い生産性を発揮することが可能です。 また、Railsはフルスタックなフレームワークなので、さまざまなタイプのアプリケーションを作ることができます。例えば、Androidアプリケーションに向けてJSONやXMLを出力するサーバーサイドに限ったアプリケーションを作ることもできます（参考「Androidアプリちょい足し開発レシピ（2）：TwilioとRailsで作る、電話でテキスト読み上げアプリ」）。 近ごろはエンタープライズ領域での採用も多くなり、業務システムのクラウド化をRails
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
宣言的プログラミングの「宣言的」って？ - sh-2の日記
疑問 関数型言語を取り扱う書籍や記事を読んでいると、しばしば「宣言的」なる単語が飛び出してくる。どうやら、関数型言語で大事にされる概念らしい。 ところが意味を調べるとよく分からない。例えばWikipedia曰く、宣言的には2つの意味があるらしいのだが…… 純粋関数型言語/論理プログラミング言語/制約プログラミング言語で書かれたプログラムを「宣言型」と称する。この立場では、「宣言型プログラミング」とはそのようなプログラミング言語のグループ全体の総称であり、命令型言語と対立する概念である。 宣言型プログラミング - Wikipedia ある出力を得るにあたってそれを作成する方法ではなく、出力の性質を記述することを「宣言型」と称する。例えば、HTMLは、ページがどう見えるかを記述するものであるため、宣言的である。HTML はタイトルやフォントやテキストや画像を指定するが、具体的にコンピュータの画
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
関数型プログラミングとは結局何なのか | 黒曜の吹き溜まり
この記事はドワンゴ Advent Calendar 2014の14日目です。 ちなみに前日は@erukitiさんでした。 他の方は「こんなもの作ってみた！」系の記事が多いのですが、技術系の話題であれば特に縛りはないようなので、今回はひたすら文章をつらつらと綴っていきたいと思います。 ここ数年、「マルチコア時代の主流は関数型だ」とか「Javaはもう古い！ 時代は関数型！」といった記事をよく見かけるようになった気がします。 大学でOCamlを学んできた自分としては嬉しい限りなのですが、なんだか関数型という言葉がバズワード的な使われ方をしている気がして、まるで「現在起こっている全ての問題を解決する銀の矢だ！」といわんばかりの雰囲気を感じるのが気になっています。 最近うちの部署でもにわかに「関数型っぽく書こう」みたいな機運が高まってることもあるので、この機に関数型プログラミングとはなにか、どのよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GUIアーキテクチャパターンの基礎からMVVMパターンへ
Kobito - プログラミングのメモやスニペットの記録に最適なMacアプリケーション