ジョエル･テストは（もはや若干）時代遅れ―今ならこう質問しよう | POSTD
ジョエル･テストとは、面接時に求人応募者が面接官に聞くものとして広く受け入れられている「12個の役立つ質問」のことです。このテストはJoel Spolsky氏が考案しました。彼のブログは開発者の間では有名で、この12の質問も広く知られていました。そして、スタック･オーバーフロー（創設者の1人がJoel Spolsky氏）によって、さらに普及することになります。スタック･オーバーフローの求人ページでは、求人を出す側の企業向けにこの質問を使ったチェックリストが用意されています。以下がそのジョエル･テストです。 ソース管理の仕組みを導入していますか？ １ステップでビルドを行えますか？ ビルドは毎日実行していますか？ バグデータベースを持っていますか？ 新しいコードを書くまえにバグを修正していますか？ 最新スケジュールを常に社内で共有していますか？ 仕様書を持っていますか？ プログラマは静かな作業
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー
NetflixのgithubリポジトリはWeb技術の百貨店だった - DiaryException
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部（2015/07/18現在分）調査してみた。 github APIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。 AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。 AWS用 aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
世界3拠点でGitHubドリブンで開発を進めるEdTechスタートアップ「Quipper」、ビール片手に明かすフラット組織の秘策とは | HRナビ by リクルート
世界中に複数の開発拠点を持つことは、タイムゾーンの違いなどの制約を抱え込むことになるが、透明性が高いエンジニア文化を作る上ではプラス材料でもある──そんな話を聞くことができたのが、Quipper東京オフィスで開かれたイベント「Quipper Drinkup #1」だった。 Quipperは、DeNA創業メンバーの渡辺雅之氏が英国ロンドンで創業したEdTechのスタートアップだ。ロンドン、東京、マニラの3拠点に開発機能を持つ。さらに、ジャカルタとメキシコシティにもオフィスがある。現在は中高生向け教育支援のツールをフィリピン、インドネシア、メキシコで提供中だ。 そのQuipperの東京オフィスで、ビール片手にエンジニア同士が交流するイベント（Drinkup）が開催された。ビールとピザで参加者とQuipper社員らが語り合った訳だが、その場の空気感は他のパーティーとはちょっと違う。なんといえばい
残業とプログラミングの効率について
プログラマーの残業についての質問です。 人月の神話などの教訓もあると思うのですが、どのくらいやるとどのくらい一人のプログラマーのアウトプットが落ちるのかなどのグラフやデータはあるのでしょうか。 コーディングする文字数の低下や、工数などの単位で示されているグラフはあるのでしょうか。 この辺について、自分を実験台にするのは悲しいので、参考に知りたいです。 例えば、ちょっと違いますが睡眠時間はこういうのがありました。 http://laugh-raku.com/wp-content/uploads/2013/05/7ae61a6d2298f57c5a19f9a46b49e7531.png こういうデータや考え方についてなにか知っている人いましたら、教えてください。 よろしくお願いします。
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
チームとして少ないミスで素早くアプリを継続的・持続的に作り続けるためのメソッド - Qiita
この投稿は DroidKaigi で話そうと思ったけど採択されなかった RejectedKaigi な内容です。 プログラムは、書けば書くほど複雑になります。行数が増え、分岐や繰り返しが増え、メソッドが増え、クラスが増え、パッケージが増え、管理するものは日に日に増えていきます。これらのものを使う側からすると、使うものが増えるということは、それだけ覚えることが増えることになります。勿論、IDE やエディタプラグインによって、そのような労力が極力減らされることもありますが、覚えることが少ないに越したことはありません。 この記事では、IDE やエディタプラグインはひとまず脇に置き、チームでコミュニケーションを取りながらコードを書くという観点で、従来のプログラミングのプラクティスを基に、開発時のミスを少なくし、チームで素早くアプリを作り続けていく方法論を深めていこうと思います。 Agenda 型を
「Google Code」、2016年1月25日に閉鎖へ GitHubへの移行を奨励
米Googleは3月12日（現地時間）、開発者向けにAPIなどを提供したり、オープンソースプロジェクトをホスティングするサービス「Google Code」を来年1月に閉鎖すると発表した。同日、新たなプロジェクトの作成はできなくなった。 Googleは2006年、オープンソースプロジェクト支援を目的にこのサイトを開設したが、その後、GitHubやBitbucketのようなプロジェクトホスティングサービスが立ち上げられ、多数のプロジェクトがそれらのサービスに移行していった。Googleは、Google Code上のプロジェクトに占めるスパムや悪質なものの率が高まってきていることも閉鎖の理由の1つだと説明する。 Google自身は既に、昨年10月に同社のAPI群のGitHubへの移行を開始し、Google Code上のプロジェクトを凍結している。 Google Code閉鎖までのプロセスとして、
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
開発効率アンチパターン
Oculus Rift 勉強会 関西 #02 【OcuBen関西】 https://ocuben.doorkeeper.jp/events/31601 『Oculus Rift入門』で使用した資料です Oculus Rift勉強会 関西 #01 【OcuBen関西】 https://ocuben.doorkeeper.jp/events/21033 『スマホでVRコンテンツを作る！！！』の発表に使用した資料です。 多少修正していますが、発表に使った資料をほぼそのままです。 【2015/3/29 資料更新】 ①タオバイザーがAmazonで購入可能なことを記載しました。 ②Cardboard SDKがUnity 5に対応したことを記載しました。 Durovis Diveを使用したVRスマホアプリの作り方について解説しています。 #OcuBen 関西に合わせて2つのAndroidアプリをPlay
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
WebブラウザだけではじめるRuby/Railsプログラミング - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これからプログラミングを始めてみたい人に向けて、Webブラウザだけですぐに使えるRuby/Railsのクラウド開発環境 (Nitrous.io) を紹介します。 Rails環境構築の壁 プログラミングを始めるためには、開発環境を構築する必要があります。RubyとRailsの開発環境の構築方法はRails Girls インストール・レシピが参考になりますが、いくつかのソフトウェアをインストールする必要がありました。 Ruby本体 Rails データベース (SQLite) エディタ (Sublime Text, TeraPad) ターミナ
システム統合にSOA？ RDBMS？ bashで十分！ － ＠IT
2009/09/07 毎年夏に開催される軽量プログラミング言語（LL：Lightweight Language）をテーマにした「LLイベント」。第7回目となる「LLTV」が、2009年8月29日に東京・中野で開催された。この記事ではプログラムの一部、「大改善!!劇的ビフォーアフター」をレポートする。前編では、Rubyによるfortuneコマンドの“増築”と、Firefox拡張によるslコマンドの実装というネタ系発表をレポートした。中編ではC言語にLisp風のマクロを取り入れ、lsコマンドのソースコードを約半分に削減する匠の技をレポートした。後編となる本記事では、売り場業務が滞りがちだった販売管理システムをbashコマンドで“建て直した”という劇的ビフォーアフターの発表をレポートする。 DBを捨ててテキストファイルに変換 「100万件ぐらいの検索なら、シェルだけでも1000分の数秒でできます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
awesome/readme.md at main · sindresorhus/awesome
http://openbook4.me/projects/92
Base DDD(ドメイン駆動設計） 参考文献を巡る旅
はてなブログチームの開発フローとGitHub
