GitHub時代の開発委託とは？ デブサミでQA@ITの事例の話をします - QA@IT公式ブログ
2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013（デブサミ2013）の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例（仮） 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008：すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」？ Rubyのまつもと氏が講演 IIJのRuby対応PaaS「MOGOK」は、どんなサービスか？ さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話
Devlove2012 どうしたら良いシステムが作れるのか
2012年12月15日に開催されたDevLOVE2012での「どうしたら良いシステムが作れるのか� - あなたが進むべき道を決めるための�アーキテクチャとマネジメントの話」の資料です。
HTML5/CSS3にも対応、HTML/CSS/JavaScriptを整形・チェックするオンラインツール -Dirty Markup
Dirty Markup [ad#ad-2] Dirty Markupはウェブ制作者がよく使う下記のツールをまとめたような感じです。 HTML Tidy CSS Tidy JS Beautify Dirty Markupの使い方は簡単で、右側にコードをペーストし、左側でHTML/CSS/JavaScriptを設定し「Clean」ボタンをクリックするだけです。
株式会社永和システムマネジメント アジャイル事業部
開発前〜開発までは無料。 システムをリリースし、実際に使い始めてから利用料が発生します。 さらに、リリース後4年目以降はサービス利用料が半額になります。
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
第15回 セッションとビューステート
ご存じのとおりステートレスなシステムであるWebでは、他ページへの移動はもちろん、同一ページへのポストバックでさえ、何も手を打たなければ、すべての状態は失われてしまう。ポストしたときフォームにテキストが入力されていたとしても、レスポンスが戻ってきたときには、そのフォームは空っぽになってしまうということだ。ただ、ASP.NETの場合は、Webサーバ・コントロールの状態を保存しておくビューステートと呼ばれる仕組みが用意され、自動状態管理が行われるため、テキスト・ボックスが空になることはないわけだが、これは見えない所で処理されているからであって、Web一般という視点で見れば例外にすぎない（ポストバックとビューステートについては本連載第2回で解説している）。 しかし、ラウンド・トリップを越えて保存したい情報は、何もWebサーバ・コントロールのプロパティばかりではない（ラウンド・トリップについては本
はてなブログ | 無料ブログを作成しよう
今の自分は、出会った人や読んできた本によって、できあがっている あの小冊子は、新聞の付録だったのか、記憶が曖昧で定かではないのだが、1ヶ月に1回程度の頻度で届いていた気がする。オールカラーで内容もさまざまだった気がする。その中には、プロ野球の選手名鑑もあって、私は、母から受け取り、大切にしていた記憶がある。母は、…
デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
納品物に係るＩＰＡの考え方
今までは ドキュメント中心にした検収を実施 発注仕様書との整合性をドキュメント上でチェック ソフトウェア開発の標準的な工程に対応したドキュメントを求めていた 外部設計書 内部設計書 ソース/ロードモジュール 結合試験報告書 総合試験報告書 取扱説明書 今後は 提出ドキュメントを大幅に削減・簡素化 検収はドキュメントではなくソフトウェアそのもので実施 発注仕様通りにソフトウェアが開発されたかどうかを検査 提出物は以下のもの ソース/ロードモジュール 開発成果報告書（ソフトウェアの機能、操作方法、試験成績を簡単に記述） 従来求めていた、「外部設計書」、「内部設計書」、「各試験報告書」、「取扱説明書」は不要
システム開発に欠かせない見積もり前提条件について | DevelopersIO
こんにちは！おおはしりきたけです！今日はシステム開発に欠かせない見積もり前提条件について書きたいと思います。 ■はじめに 弊社では、受託開発を多くやっております。受託開発は、最初のスタートが重要です。私見ですが最初のスタートで成功確率の80%は決まっているといっても過言ではないと思っております。そのくらいスタートというのは大切だと思っております。エンジニアの方々の中には、営業さんが「あとはヨロシクッ！」と言って金額しか決まっていないプロジェクトを経験し苦い思いをした方も多いのではないでしょうか。弊社では、そのような事が起こらないよう営業さんとは密な連携を取りプロジェクトが成功可能かという判断をし、成功可能なプロジェクトに対し開始するということを行っています。その作業の中でも特に重要なのは、見積もりの前提条件です。 ■なぜ前提条件が必要か 見積もりを出すときの流れは大まかにいうと以下のように
RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa
自社内に立てるのもOK。Ruby on Rails製、シンプルなGitHubクローン·GitHaven MOONGIFT
GitHavenはGitHubクローンのオープンソース・ソフトウェアです。Ruby on Railsで開発されています。 バージョン管理システムの一つGitが爆発的に人気を集めるきっかけになったのがGitHubです。そんなGithubクローン（今では結構変わってしまいましたが）として有名なのがGitoriousですが、今回はもう一つGitHavenを紹介します。 トップページです。さっぱりとした画面です。まずはサインアップまたはログインを行います。 サインアップする際に公開鍵も登録できます。この辺りはSSHを使うgitらしいサービスです。 無事サインナップ完了です。 リポジトリを作成しました。この表示もGithubに似ています。 リポジトリの設定画面です。パーミッションの設定も可能です（プライベートリポジトリを作成できます）。 ユーザ設定画面です。 ユーザプロフィール画面です。リポジトリが
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
Web自動テストツール「Selenium 2.0」登場 | エンタープライズ | マイコミジャーナル
Selenium is a suite of tools to automate web app testing across many platforms. WebアプリケーションやWebサイトの自動テストを実施するためのツールであるSeleniumの最新安定版が「Selenium 2.0」として公開された。安定版としてはSelenium 1.0.3がリリースされて以来となる。2.0は1.0.3と互換性があるため、1.0.3のユーザは2.0に置き換えるだけでアップグレードが可能と説明されている。2.0にアップグレードすることでFirefox 5やIE9など最新のブラウザに対応できるほか、バグ修正や安定化といった恩恵も受けられる。 Selenium 2.0の最大の特徴は「WebDriver API」に対応したことにある。Python、Ruby、Java、C#のすべてにおいてWebDrive
オライリーの書籍「ウェブオペレーション」、最新の現場から届く「継続的デプロイ」「コードとしてのインフラ」「トラフィック急増への対応」などへの実践的なアプローチ
オライリーから献本いただいた書籍「ウェブオペレーション － サイト運用管理の実践テクニック」。Webサイトの運営ノウハウ本ならApacheの設定やチューニングといった一般的な事柄が載っているのかと想像してページを開いてみると、見事に裏切られました。 本書のテーマとなっているWebサイトの運用管理、Webオペレーションは、変化の渦中にある仕事です。 変化というのは、例えばインフラの面ではクラウド化とそれに伴ってプログラマブルなインフラが登場し、スケーラブルなアーキテクチャの重要性が高まっています。ソフトウェアデリバリの面では、パッケージソフトからオンラインサービスへという大きな流れがあり、それに重なるように新機能を継続的にデリバリしていくという継続的デプロイやアジャイル型の開発が注目されるようになってきました。 現場から届く18章のエッセイ 本書はこうした新しい時代のWebオペレーションを実
memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
SA取ったど〜(´・ω・`) - 山奥通信 増刊号
はい、SAも取ったので、恒例の「資格を取ったからこそdisりますよ」シリーズです(・∀・;) さて、一般的には、「システムアーキテクト」と言う言葉は2通りくらいの意味で使われていると思うわけですが( ・ω・) 一つ目のケースは、こういう感じのやつで。 戦略的〜ビジネスの観点から〜みたいな話と、テクノロジーをリンクして語る アーキテクトと言うか、CIO補佐というかCTOと言うか スーパーマンで、そんな人は日本に何人もいないよ、みたいな人達(´д｀;) 二つ目のケースは、こういうの感じのもので。 フレームワークの選定をしたり(・ω・) システム構成のレイヤと機能による水平/垂直の分割をしたり(・ω・) トランザクション戦略を決定したり(・ω・) 一通りのサンプルを作って展開したり(・ω・) 非機能要件を考慮して処理を非同期化することを決めたりとかも(・ω・) 足りないライブラリは自作したり(・
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rockstar JSLint プラグインで JavaScript コードの品質をチェック
http://dl.dropbox.com/u/224433/kayac-01-log/index.html