Amazonクラウド上でPaaSを提供しているHerokuのエンジニアCraig Kerstiens氏が、Heroku社内でのソフトウェア開発がどのように行われているのかを紹介した記事「How Heroku Works - Teams and Tools」を、自身のブログに掲載しています。 全体の運営をアジャイルにしつつ、小さな独立したチームが独自のツールを使い、頻繁なコミュニケーションの下で開発を進めるのがHerokuのやり方のようです。記事からポイントを引用しつつ、先進的な例の1つとして見てみましょう。 チーム、コミュニケーション、コラボレーション 記事の冒頭で、チームがAPIやデータ規約によって構成されていることが説明されます。 Heroku is a largely agile company, we work in primarily small teams that talk
東京ラーメンショー2011 いきてーーー!みなさんこんにちは、nakamura です。 今日はプログラマだったりサーバ管理者だったり(もしくはその両方だったり)する方にお勧めしたいサイトとツールをいくつかご紹介します。細かい脆弱性のチェック等どうしても手間が掛かるものが多いですが、今回ご紹介するツールをうまく使うとその辺りだいぶ効率よくできると思いますよ! WEB アプリケーション関連 XSS Me XSS Me :: Add-ons for Firefox XSS のテストをある程度自動化してくれる Firefox のアドオンです。残念ながら Firefox3.0.* 系の頃に開発が止まってしまっているようですが、僕の環境では install.rdf の書き換えで問題なく動作しています。(Windows7 64bit + Firefox7.0.1) SQL Inject Me SQL I
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 前編に続いて、ファウラー氏の基調講演の様子を紹介しましょう。 (本記事は「マーチン・ファウラー氏が語る、、21世紀のソフトウェアデザインとしてのアジャイル開発(前編)。Agile Conference tokyo 2011」の続きです) 継続的インテグレーション アジャイル開発の中で重要な「継続的インテグレーション」と「継続的デリバリ」について話そう。まずは継続的インテグレーション。 複数のプログラマが集まって開発しているソフトウェアでは、それぞれのプログラマのコードをマージする作業に苦労する現場を多く見てきた。 あるソフトウェアプロダクトに二人のプログラマ
昨日のこととなりますが、札幌でソフトウェアの開発プロセスの1つであるICONIXをテーマとした勉強会を開催しました。ユースケース駆動開発BootCampという名称で、TDDBCの派生です。本家TDDBCと同様に、午前中は講演中心の座学、午後から演習で実際に手を動かして体験してみるというスタイルの勉強会です。最近はこの手の体験型勉強会がテスト駆動開発などを中心に広がりつつあるような気がします。 開催の経緯 実は3年ほど前に札幌Javaコミュニティを立ち上げた時、最初の頃に行っていたのが「ユースケース駆動開発実践ガイド」の読書会でした。この本は、ユースケース駆動開発に関してICONIXというプロセスを紹介しながら解説する本です。その後、自分としても関連したプロジェクトにユースケース駆動開発のエッセンスは取り入れるように取り組んでおり、一定の成果があったと感じております。そこで、このプロセスを広
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15%増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15%多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか?将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
在庫限り。人気のSurface Duo 2 が再入荷され、最大 36% OFF 中。ご購入はお早めに。
jQuery Meow mimics Growl notifications. It can be called within and jQuery bind event and passed various sources for message input, making it ideal for form validation, Rails flash notices, or a replacement for the alert() box. It's under active development right now and is lacking a bunch of features that are soon to come, including, callbacks. If you've got something to add, please fork the proj
It’s important to follow trends in your field to ensure you’re staying current on standards and protocols and perhaps more so in the field of coding. Programmers of all specialties can benefit from following industry-leading blogs to stay aware of the latest technologies. If you’re a coder of any sort you’ll want to subscribe to these useful programming blogs written by the top blogging coders. Ea
はじめまして、プロダクト開発部のkoyaと申します。4月から中途で入社しました。 今回は入社してみての感想や気づいたことなどをお伝えしたいと思います。 入社のきっかけは技術ブログ 前職もいわゆるプログラマーなのですが、「達人プログラマー」や「Joel on Software」といった本の影響もあって、ソース管理や自動化など開発全般にかかわる仕組みや環境作りに関心がありました。無駄な繰り返しはしたくないし、忘れたり間違いをなくすためにも自動化できるものは自動化したいタイプの人間です。 転職にあたってはそういった環境作りや仕組みづくりができる会社を選びたいと考えていました。そんなとき、はてなブックマークのエントリーで「開発者にやさしい環境」という記事を見つけました。 特に次の3つに惹かれました。 アジャイル開発やってるよ自動テスト、自動ビルド環境が整ってるよその他にも、いろいろ開発者にやさしい
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』(以降DDD)は、「
個人でWebサービスを作る際の考察に関する以下の記事が、とても興味深く面白かった。ここに書いてあることはだいたい同意で、自分も実践したいと思うことばかり。 個人でWebサービスを超高速でつくる人たちの作り方を考察。 │ モノづくりブログ 株式会社8bitのスタッフブログです で、記事の最後に執筆者が聞いてみたいこととして「個人Webサービスの場合、仕様書はどうしてるの?」と呼びかけていたので、僭越ながら自分が過去に作ったWebサービスの仕様書(Evernoteに書いたメモ)を公開してみる。公開するのはNekostagramとはてなスターカウンターのもの。 仕様書(TODOリスト)の書き方 自分の場合、Webサービスを作るときに書くものは「仕様書」などと呼べるようなちゃんとしたシロモノではなく、Evernoteに思いついたことをどんどんリストアップしていくだけ。いわゆるTODOリストですね。
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く