テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ
Kibelaの開発から離れました - deglog
もう一ヶ月前ですが、ふと思い立ったのでブログに。9月いっぱいで3年半かかわってきたビットジャーニー社 (BJ社)が運営するKibela (https://kibe.la/)の開発から離れました。 僕とKibela 2015年にクックパッド社からの出向社員*1として、当時は社長1人だったBJ社に参加。社長が技術顧問業で資金を調達し、僕がKibela立ち上げに責任を持つという役割分担でスタートしました。去年の夏からは僕がクックパッドに復帰 (出向解除) した関係で、兼業していました。 役割的にはプロダクトマネージャー業に軸足を置きつつ、初期は人も居なかったのでデザインからインフラまで、プロダクト立ち上げに必要なことは何でもやってました。2017年春に正式リリースして、今ではNewspicksさんやSmartHRさんなど、多くの会社でご利用いただけるようになりました。 Kibelaというサービス
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
第2回 オンラインゲーム・テクニカルオープンカンファレンス | SQUARE ENIX
スマートフォンの普及とともにネットワークの品質や速度も近年めまぐるしい勢いで変化しており、ソーシャルゲームを代表とするオンラインゲームもユーザー同士がコミュニケーションを行いながらプレイするマルチプレイが主流となってきました。普段何気なくプレイしているオンラインゲームですが、それらを支える技術の難易度やセキュリティ、開発規模・コストは、様々なノウハウによって支えられており、数多くのオンラインゲームをリリースする弊社では、そのノウハウが日々蓄積されております。 前回、2014年に開催させて頂きましたオープンカンファンレンスから約4年ほど経過してしまいましたが、この春、第2回目という位置づけで、社内のエンジニア・テクニカルディレクターによるオンラインゲーム開発手法を中心にテクニカルカンファレンスを開催する運びとなりました。オンライン開発に関するセッションはもちろんのこと、最新の開発手法からセキ
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
個人プロダクト開発で、困った時にどうするか - Qiita
Introduction Webエンジニアであれば、「自分達の手で0から作ったプロダクトで世の中を変えられたらな、それで食べてけたらなー」と夢見ることがあるのではないでしょうか。 私たちは、夫婦2人で、プライベートの時間でアプリ開発と運営をしています。その過程でぶつかった壁がとてもたくさんありました。 全てのプロダクトで当てはまることではなく、あくまでも特定のケースなのでなかなか一般的な手法として展開しずらい事例が多いですが、これらの困った体験が何かのお役に立てればと思い書きました。 実際に起こったこともあれば、起こってはないが、経験から推測するとこのケースはこう対処すればいいのかもしれないと思ったこと、の両者を記載しています。本やブログなどで得た知識をそのまま紹介するというよりは、実体験に基づいた内容になっています。 人が集まるまで 作る時間が無い 困った たくさん機能開発したいが、普段
伝統的なゲームデザインをUnityで表現する | Made with Unity
ゲームエンジンの波紋 汎用ゲームエンジンというものは現在では数多あるが、その中でUnityというものは若干異質に感じる。Unityは「ゲーム開発の支援」ではなく、最初から徹頭徹尾「ゲーム開発の民主化」という掲げたコンセプトを貫いているからだ。その信念はプロとアマの壁やプラットフォームの壁だけでなく、業種間の壁にも穴を開け、それは今もなお続いている。 特筆すべきはUnityに関するコミュニティ形成、交流の場を早期から行っていたことではないだろうか。「ビデオゲーム」というスタート地点こそあれど、現在ではあらゆる業種のトレンドや技術、リソースがUnityという共通言語を通して存在する。 旧態依然とした日本の「企業のノウハウに依存するビデオゲーム」の開発は大きく揺ぎ、ソーシャルゲームの発展と共に清濁併せ呑む混乱が確かにあった。 私自身ゲームエンジンの展開によりプログラマーという職業が失われるなどと
無料で整える趣味チームの開発環境 - Qiita
簡単に言うと以下のようなことができます。 メンバ数 制限なし プライベートリポジトリ 作成可 任意のデバイスからのチャット(～1万メッセージ)、ファイル共有(～15GB) 毎月2000分 までのCI 24時間稼働のChatbot 24時間稼働のVM (1vCPU, 0.6GB) × 1 イメージ図から大体想像つくかと思いますが、Blumix上のHubotでSlackからChatOps的なこともやってます。 VMの 起動 / 停止 定期ジョブの実行 起動中VMの通知 課金額の通知 VMでのコマンド実行 地味にありがたいのは「 起動中VMの通知 」「 VMの停止 」あたりですかね。 無料枠だけではどうしてもリソースが足りないときは当然有料のVMを借りるんですが、なんとなく止め忘れちゃったりすることもあるので、 気づくことと停止がSlackだけでサクッとできる のは非常に重宝します。 あとは「課
料理も、睡眠も、仕事もハック！ GunosyのCTOが教える開発効率を上げるメソッド｜ハイクラス転職・求人情報サイト AMBI（アンビ）
料理も、睡眠も、仕事もハック！ GunosyのCTOが教える開発効率を上げるメソッド エンジニアなら誰もが効率よく開発を行いたいはず。でも、どうすれば？GunosyのCTOである松本勇気さんが、忙しさに負けず、開発効率を上げるための方法を教えてくれました。 開発支援・効率化ツールやChatOps等で業務ハックに余念のないエンジニアは多いでしょう。では、エンジニア視点で日常をハックすると、どのように生活が変化するのでしょうか。 株式会社GunosyのCTOの松本勇気さんは、若手ながらも10を超えるプロダクト、50人以上の開発メンバーを束ね、日々多忙に過ごしています。それだけでなく、業務で社内のインフラから機械学習基盤、広告配信、アプリ開発まで、全プロダクトの技術的な意思決定に携わりつつ、さらにはプライベートの時間もしっかり確保しているといいます。 松本さんが実践する、ライフハック術を綴っても
新しいディレクターが来て会議を変えた話
がっきー@漫画家総合垢 @gakky88NSR ゲーム開発時代の話。 開発の中盤、開発は難航していた。 会議はミスやトラブルの責任の追求が中心に行われ、処刑場になっていた。 ある日、新しいD（ディレクター）が配属された。 僕の大好きなゲームを作った人だった。 2017-02-10 22:39:45 がっきー@漫画家総合垢 @gakky88NSR Dが来て初めての会議。 リーダーはいつもの様にミスした者や遅れた者を探し、追求し、叱った。 Dはそれを見て笑った。 「ずっとこんな事してたの？」 「やめやめ！会議のやり方を変えます」 2017-02-10 22:40:07 がっきー@漫画家総合垢 @gakky88NSR 「まず、進捗の報告は出来てない物、問題のある物だけで良いです。 出来てる物は予定表で分かるから必要無い。 で、その問題がどうすれば解決出来るか、助けがいるなら何が欲しいかだけを話し
素人が半年頑張ってWebサービスを作った話 - 変なサービスを作るのが好き
半年ほどかけてWebサービスのプロトタイプを公開するところにこぎつけたのでその記録をしておこうと思います。 作ったもの 一言で言うと「Webブラウザで閲覧したページの履歴を共有するSNS」です。 History（履歴）を流す（stream）ということでHistreamと名付けました。 Chrome拡張をインストールして、ウィンドウを選択し、オンにするとそのウィンドウで見たページ履歴を自動でアップロードします。 そしてWebサービスでアップロードされた履歴を整理された状態で確認したり、友達の履歴を読めたりします。 Chrome拡張: Histream-Extension - Chrome Web Store Webサービス: https://histream.io 作ろうと思ったきっかけ 今から一年前、大学２年の冬にワンタップダイエットというアプリを作っていました。プログラミングするのはほと
技術採択のときにやるべきこと - まるまるこふこふ
初めに 新規プロジェクト／既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客＝ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
React on 現場 ~ あるいは Modern JavaScript on Rails ~ - Qiita
これは何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料。特に理由はないが公開するのを忘れていた。 スライドモードのリリースにあたって公開する 近況(2016/01/16) 昨年9月 Kobito for Windows => Qiita開発チーム モダンなJS(当社比)を導入しようとした モダンなJSとは(mizchi主観2016版) npm/browserifyで依存を解決 Babel/ES2015 React/Flux Testable No More jQuery plugins ※これらの基準について今回は割愛 現実(2015) CoffeeScript Sprockets / グローバル名前空間渡し Backbone JSのテストはjasmineで数件 (※request specは豊富) jQuery plugins
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『妖怪ウォッチ ぷにぷに』 制作秘話 仁義の虎
日経電子版アプリ 穴のあいたバケツ開発
How we cook cookpad.com 2016