少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
私がソフトウェア技術者をやめた理由 - Rails で行こう！
昨日、 人生の転機 - Rails で行こう！ の中で「ソフトウェア作りが嫌いだ」と言い切ってしまったことが引っかかっている。 私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 簡単な例を挙げよう。 うるう年を計算するアルゴリズムを考えてみる。うるう年とは、「4で割り切れて、かつ100で割り切れない年。ただし、400で割り切れたら、やはりうるう年」である。 def leap_year?(y) (y % 4 == 0) && ((y % 100 != 0) |
システムが無くなった日
自分のブログに書こうとも思ったのですが、会社が特定されてしまいそうなのでここに書きます。どこかに書かなければならないと思ったのは、この事実を誰かに伝えなければならないと思ったからです。 私が勤めていた会社はシステム屋さんです。2タイプの職場があって、一つはお客に注文を受けてシステムを開発してリリースして終了。もう一つはお客の会社に居候させてもらってシステムの維持管理をするというものです。私は後者のほうです。 お客は工場も複数構える結構大きな企業で、様々なプラスチック製品やコンピューター部品を作るところであります。日本だけじゃなくて海外とも取引があったと思います。 1. コンピュターシステムの入れ替えを要求されるこの不況のなか、様々な設備投資の資金を抑える事を進めていた中で、システムについても、もっとコストの安いものをと以前より私の会社の上役達と試行錯誤を繰り返してきたのですが、そもそものお
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
