参考：「Google のエンジニアはどうやって開発しているのか?」
「へ?たのめも」 さんとこのエントリーにあった「Google のソフトウェア・エンジニアリング 」を発見。Google Developer Day Tokyo での鵜飼さんのプレゼンがわかりやすくまとめられていました。 最近、あるきっかけで異様にGoogleへの興味が沸いてきているのですが、その理由はおそらく企業としての興味というよりも中の人たちの文化的な部分に対する興味なんだろうな、と実感。 いくつか注目した点をピックアップ。 Google のプロジェクト・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる チームは少人数 (2?6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割 ２?６人っていうのがバランスがよさそう。なるべくフォーカスは絞ってシンプルでコンパクトにってことですね。 Google のソフ
Unixコマンド生活実践 — ありえるえりあ
ディレクトリ操作 lsの使うオプション ...-l,-a,-F,-i # ディレクトリをすべて消す場合(先頭の\は後述) \rm -rf ディレクトリ名 # 全部コピー cp -ar srcdir destdir ...-aはGNU lsのオプション # cp -aがどこまで信用できるか不明、あるいはGNU lsがない時に、使うテクニック tar cf - srcdir | (cd /destdir; tar xf -) ファイル操作(リンク) ハードリンク vs. シンボリックリンク ln #ハードリンク ...異なるファイル名で同一のi-nodeを共有(ls -iで確認可能) ln -s #シンボリックリンク ...ポインタ 注意点 ハードリンクは対称(ln a bでもファイルaとbに主従関係はない) i-nodeはデバイス(dfで見えるディスクデバイス)で一意なので、デバイスを越えて
SVN標準ディレクトリ構成 - atsukanrockのブログ
はじめに SVNの標準的なディレクトリ構成の良さが、やっと理解できたのでメモしておく。 上記についての解説は、インターネット上にたくさんあるが、それでは私には良さが理解できなかった。だが、SVN自体のリポジトリ（SVNで管理されている）を見て、その良さを理解できた。『*The* Subversion Repository』を参照のこと。『README』を読むと、基本的なことがわかる。 ディレクトリ構成図 SVN自体のリポジトリの、ディレクトリ構成の一部を以下に抜粋する。末尾が「/」はディレクトリ、それ以外はファイルを表す。 / + README + branches/ | + 1.0.x/ | + 1.4.x/ | + 1.4.x-r24119,r24121/ | + 1.5.x-issue2489/ | + arterm-soc-work/ | + issue-2382/ + tags/
きれいなプログラミングコードの書き方：プログラミングの基礎知識 - 久保清隆のブログ
プログラマによって色々なプログラミングスタイルがあると思うが、センス・オブ・プログラミング! 抽象的に考えること・データ構造を理解することを読んで、きれいなプログラムを書く方法については共通点があると思ったので、本書を参考にきれいなプログラミングコードを書く方法についてまとめた。 目次 目的を理解する 書く時のことよりも、読む時のことを考える 愚直でも読みやすく インデントは統一する コメントは無駄なコメントを書かずソースの意図を書く 例外は、本当に例外的な場合だけに使う 名前のつけ方を重視 命名法 省略しない 同じことを書いてはいけない コピペをやめる 関数に分割する 机上デバッグは時間の無駄 良いコードとコーディングレベル 良いコード コーディングレベル 目的を理解する何らかのコーディング規約に従ってプログラムを書くなら、常にその理由を理解すること。 盲目的に規約に従うことは、規約が全
Webの負荷テストに使えるフリーソフトウェア | OSDN Magazine
Webアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。 負荷テスト用のツールはいろいろあるが、メンテナンスが行われていないもの、フリーでないもの、インストール手順が明確でないものを除くと、curl-loader、httperf、Siege、Tsung、Apache JMeterの5つが候補として残る。 JMeterについては、すでにDaniel Rubio氏が取り上げているので、ここでは詳しく説明しない。ただし、最後のまとめでほかのツールと共に簡単に触れている。 curl-loader curl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープン
毒親といふもの、 （と自己責任論）
・中学校２年まで、母親に近親相姦（軽度）されていた。俺はノンケな男。 ・母親は虐待されて育った ・父は育児不参加、家は母親の独裁政治。 ・小５から高１入学まで、周りに日本人がいない英語圏に放り込まれてたこともあって、母親のいっていることは特に疑わずに信じていた。 日本の高校に入った。 ・最初は摩擦がすごかった。カルチャーショックかと思ったけど、母親に都合よくゆがめられていた世界の解釈がおかしいということだったんだろう。 ・母親はメンヘラなんだとわかった。 ・母親によって作られた人格は母親のit、マリオネットにしかならないことがわかった。 母親を信仰する、母親による、母親のための、家庭内宗教。 そんな感じ。 ・なにかがおかしいとはカルチャーショックとして捉えられてはいた。 ・母親に育てられた人格は到底役に立たないばかりか、僕を原理主義的な行動原理に拘束する有害なものだととらえるようになった。
見積もり仮想体験の旅へ、いざ出発！
表1 FPポイント表。このポイントを基にして、次の表2の実測表に当てはめる。複雑さの程度によって（低い、中ぐらい、難しい）ポイントに差をつける ※注「そのほか」とは、筆者が実務上必要と感じているために追加したもの このFPを出した時点で、工数や工期の算出もできます。 しかし、前回の「見積もり仮想体験、準備から始めるべし」で述べたように、FP法は機能の広さ以外の部分をカバーしていません。品質の重さやタスクの深さという視点が抜けていますので、必然的にケースによっては軽い見積もり（つまり過小な金額の見積もり）になってしまうことになります。 ISBSG法やCOCOMO II法でFP法の欠点を補う そのため、ISBSG法やCOCOMO II法の指標を利用することで、ある程度FP法の欠点をカバーできるのです。 ISBSGというのは、「The International Software Benchma
分散バージョン管理Git/Mercurial/Bazaar徹底比較
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
機能要件は3階層で整理
上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Site Under Maintenance