結構前のエントリになりますが、cles::blogさんで紹介されている「プログラミングは設計か製造か？」に感銘を受けました。はてブを見ていると、最近になってwebarchiveから発掘されたようです。 ソフトウェア設計とは何か？ 原文はこちらで公開されている模様。 What Is Software Design? by Jack W. Reeves - developer.*, Developer Dot Star 全編にわたって非常に示唆に富んだ内容となっています。印象深かったトピックは以下。 ソースコードは設計であり、ドキュメントである ソフトウェア開発における「製造」とはビルドである 製造はコンパイラとリンカの仕事であり、コストは非常に小さい テストやデバッグは設計の検証と洗練のプロセスである 他の工学分野のそれと等価で手を抜くべきでない 「コーディング」「テスト・デバッグ」「（俗に
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
昨年のエントリー、 DDDについて、だらだらと からのびのびになってしまいました、 Smart UI アンチパターンについて。 Smart UI アンチパターンは コの業界で非常に目にするパターンで、また、素人が素人のままで仕事が出来てしまう パターンなのですが、その是非を論じる前に、まずはどういうものかを整理したいところです。 一言で言えば、「Smart UI、アンタ良い者なん？悪者なん？」 * * * DDD の Smart UI “Anti-Pattern” を読んでいると、これは本当にアンチパターンなのかとも思えてきます。 Advantages Productivity is high and immediate for simple applications. シンプルなアプリを作る上では生産性は超高いし、出来るのも早いよ！ Less capable developers can
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。 お客様はアジャイルがお好き 私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。 顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリッ
2020-06-02 Comments/Subversion/TortoiseSVNメモ/コミットしたログメッセージが編集できない 2020-03-31 ゲームを作る上でのバッドノウハウ/十字キーがボタンとして認識される 2019-11-12 Comments/Wiki/PukiWiki/スパム(spam)を防止する方法 2019-11-01 Delphi/XML/Delphi付属のXMLライブラリ 2019-08-27 Comments/SaGa2 秘宝伝説/モンスター一人クリア 2019-07-11 Comments/git/git rebaseを元に戻す方法 2019-06-08 VBA/関数呼び出し時に「オブジェクトが必要です。」というエラーが出る 2019-03-07 Comments/PhotoShop/「下のレイヤーとグループ化」はどこいったの？ 2019-02-06 Rub
アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と
『ベスト&ブライテスト』という本をご存知でしょうか。大学などで政治学を学ばれた方にはお馴染みかもしれませんが、New York Times のデイヴィッド・ハルバースタムが著した本で、米ケネディ政権がベトナム戦争の泥沼にはまっていく過程を追ったものです。「ベスト・アンド・ブライテスト」とは文字通り「最良にして聡明」という意味で、ケネディ大統領の下で政策決定に関与した優秀な人々のこと。そんな優秀なチームがなぜ誤りを犯すのか？という疑問について考える内容になっています。今日取り上げる『プログラマーのジレンマ』という本を読み始めたとき、真っ先に思い出したのがこの本でした。本書はさながら、プログラム開発版の『ベスト＆ブライテスト』と呼べるでしょう。 あえて一言で言ってしまえば、『プログラマーのジレンマ』はよくあるデスマーチのドキュメンタリーです。しかし他の類似書と異なるのは、取り上げられているチー
FireMobileSimulatorはFirefox/Chrome版ともに配布・メンテナンスを終了しました。本ページの内容は記録のみの目的で残しています。 FireMobileSimulatorとは？ FireMobileSimulatorは、主要３キャリア（DoCoMo/Au/SoftBank）の携帯端末ブラウザをシミュレートして、モバイルサイト開発を容易にするために作成されたGoogle Chrome/Firefoxの拡張機能です。携帯端末のHTTPリクエスト、絵文字表示、位置情報送信機能などの動作をシミュレートすることができます。 モバイルサイトをPCで閲覧するために、従来からある方法として、キャリア公式シミュレータの使用、Proxyの使用、Firefoxのuseragentswitcher+modify headersの組み合わせ等、色々と手段はありましたが、これらの方法はそれぞ
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り！ 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
濃縮還元オレンジニュース Microsoftの開発現場ではVSSではなくCVSが、プロジェクト管理はMS ProjectではなくExcelが使われている Microsoftに勤めている人との会話をまとめたものです。Googleの開発手法は最近カンファレンスなどでよく聞きますが、Microsoftでどのように開発を行っているのかはあまり知られていない気がします。 まず、コードレビューをかなり重要視しているようです。コードと単体テストが終わったら旧ソースとのDiffをチームメンバーに配り、メールベースでレビューを行います。レビューは1行1行細かく行い、全員がOKと判断したら再度テストを行いチェックインします。コードレビューはチーム全員で行うため、チームの能力が徐々に平均化していく効果があるようです。なおバグが出た場合、チーム全員でレビューしていることから「チーム全員に対する説明責任」が生まれ、
こんにちは、佐々木です。 他社サイトへのリンクが含まれるような開発環境で作業を進める場合、使用しているブラウザを「リファラを送信しない設定」にする必要があります。うっかりクリックしてしまったサイトに送信したリファラから「開発環境のURLがばれてしまう」という危険を防ぐためです。 つまり、リファラを送信する設定のまま開発環境で作業を進めることは、「スーツの内ポケットにキャバクラのマッチが入ったままになっている」のと同じくらい無防備な状態といえます。惨事が起こる前に、しっかりと準備をしておきましょう。 『Internet Explorer』の場合 『Internet Explorer』（以下、IE）の場合は「Proxomitron」を使う方法もありますが、リファラを送信しない設定だけであれば「Fiddler2」のほうが簡単ですので、ここではその方法を紹介します。 Fiddler2 を使ってIE
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
アメリカはカリフォルニア、ベイエリアのゲーム会社で働くようになってから丸3年がすぎた。ちょっと前には転職もして、別のアメリカ企業を経験中。日本のゲーム会社で5年くらい、アメリカで3年くらいゲームを作ってみて、ようやく言語にできるくらいまとまってきたので、ゲームの作られ方の大きな違いをメモしておこうと思う。もちろん、自分は、たくさんあるゲーム会社のほんの一部しか知らないので、まったくもって一般論を語る気はない。あくまでも自分の見知った範囲での考察。 ■「思いついたらとりあえずやってみる」が美徳 俺が思うに、アメリカ発のゲームと日本の伝統的なゲームの違いの源泉はここにある。彼らはちょっとアイデアを思いつくと、すぐ実行してみる。俺からすると取るに足らないネタでも、"That should be cool!"を連発してとりあえずやってみる。どうやら、それが美徳らしい。うだうだ仕様を考えて、プログラ
2008年05月19日11:45 カテゴリYAPC::AsiaLightweight Languages プログラミングとアプリ開発の違い ああ、YAPC::Asia::2008のトリ、Perl Is unDeadを見せてあげたかったなあ。 プログラミングのジャンルと難易度(および Web プログラミング批判) - 黎明日記 だってそうだろ？ 「 Web アプリケーション」なんてカッコイイ名前の割に、受け取ったデータを簡単に加工してデータベースに突っ込んで取り出して……それで終わりじゃないか。ビデオやスライドが上がるまでしばらくかかると思うので、とりあえずは以下をご覧あれ。 はてなブックマーク - タグ yapcasia2008 Simon Cozens - YAPC Asia and talking in Japan YAPC::Asia 2008 2日め - てきとうなメモ で、Sch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
