SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
アジャイル開発にセキュリティ対策を組み込む、マイクロソフトが「Security Development Lifecycle」の新版を公開
アジャイル開発にセキュリティ対策を組み込む、マイクロソフトが「Security Development Lifecycle」の新版を公開 ソフトウェア開発の際に、仕様策定から実装、運用にいたるまで、あらゆる観点でセキュリティ対策を盛り込んでおくことは、特にWebアプリケーションにとって非常に重要なことです。これからさまざまなアプリケーションがクラウドに対応することを考えても、開発プロセスそのものにセキュリティ対策のこともきちんと組み込んでおくことが望まれます。 マイクロソフトは、OSやアプリケーションなど自社開発しているソフトウェアの開発プロセスにセキュリティ対策を組み込んでおり、そのガイドラインを「Microsoft Security Development Lifecycle」として公開していました。 下記の図がMicrosoft Security Development Lifecy
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
変化に強い情報システムを作る---目次
企業情報システムの設計者に現在最も求められているスキルの1つが，変化に即応できる設計力だ。経営ニーズの変化に対応して，情報システムを迅速に改修できなければ企業の競争力が落ちてしまうからだ。3回の連載で情報システムの拡張性を高める設計技法を，組織体制から開発工程，保守工程の全域にわたって解説する。 【上級】変化に強い情報システムを作る 第1回（前半） 全体像とケース1 【上級】変化に強い情報システムを作る 第1回（後半） ケース2とケース3 【上級】変化に強い情報システムを作る 第2回（前半） 上流設計段階での手法/概念データモデル 【上級】変化に強い情報システムを作る 第2回（後半） アプリケーション・ポートフォリオほか 【上級】変化に強い情報システムを作る 最終回（前半） 論理コンポーネント分割（1） 【上級】変化に強い情報システムを作る 最終回（後半） 論理コンポーネント分割ほか
続・Agileでうまくいかないとき - masayang's diary
Agileでうまくいかないときと同じ著者による続編をまたまた適当に翻訳。 Allan: More Agile failure modes ちょっと前にAgileでうまくいかないときという話題を取り上げたけど、その後いろいろ考えているうちに、さらに二つの失敗状態があることに気づいた。(気づいた、というのは変な言い方かもしれない。失敗するパターンを見つけた、というべきか。) 一つ目は、開発者達が「俺たちAgileやってるぜ」と宣言するだけの状態。名付けて「なんちゃってAgile」。Agileだと宣言する事で、文書作成は無視できるし、プロジェクト管理も回避しちゃうし、ハックし放題。 正直言ってこれはAgileではないし、Agileやってる人には迷惑だ。こういう人達の中にはAgileでやりたいというのも混じっているのだろうけど、きちんと理解し、ちゃんと経験を積まないと、Agileしていくってのは難
Tokyo O life - ずばぴたテック » nowa [ノワ] : サービス終了のお知らせ
最初に謝っておきます。ゴメンなさい。 nowa は2009年3月31日（火）をもちまして、サービスを終了させていただくこととなりました。 ご愛用いただきましたユーザーの皆様には多大なるご迷惑をお掛けし、深くお詫び申し上げます。 なお、書き込みは2009年3月16日（月）をもって停止させていただきます。 [From nowa [ノワ] : サービス終了のお知らせ] ライブドアの新世代ブログサービスとして、2007年春に始まったnowa（ノワ）が、わずか2年で終了。 それまでのlivedoor ブログよりもライトなユーザーを取り込み、同時に収益化しやすいブログサービスを目指していたけど、いまいち存在感を発揮できなかった。本家のlivedoor ブログに「新管理画面」と「みんなのクチコミ」がついたことで、nowaを継続する理由もなくなったということでしょうか？（実際は、nowa撤収の前準備として
デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 - 角谷HTML化計画(2009-02-12)
Invalid Text■<%=sn number %> <%=flickr_left '3274768929' %>デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 つかれたのであとで書く。とりあえずスライド。最後までスライドめくれてよかった。 写真はtakaiのを借りてます。練習不足(というかスライド完成したのが10分前)でリモコンを見すぎてしまいました。情けないです。 The way to the timeless way of programmingView more presentations from Shintaro Kakutani. (tags: devsumi2009 xp) slideshare.net kakutani.com よくある質問と答え Q:動画はいつ公開されますか？ A:録画してません。 Q:予稿とかないの？ A:ありません。ひとえ
デブサミ2009 はてなの開発戦略
2. 自己紹介 舘野祐一 id:secondlife はてなブックマークリードプログラマ Perl, JavaScript ... 社内開発環境の整備 開発環境改善大好き！ Development Environment Conference 開い たり
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
プログラミングテクニックのまとめ - プログラミング日記
とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
MOONGIFT: » これはすごい！Firefoxを使ってサイトのモックアップを簡単に作成する「Pencil」:オープンソースを毎日紹介
これはデザイナーのみならず導入必須のソフトウェアと言えそうだ。 Webサイトを作る際には、モックアップが必要になる。それをベースにして「ここをこうしよう」「次はどこに遷移させよう」といった議論が可能になる。頭の中だけではイメージがはっきりせず、意見も出しづらい。 ドラッグアンドドロップでモックアップを作成できる そんなモックアップを作成しようと思ったら、紙やHTMLオーソライズソフトウェア、画像編集ソフトウェアを使うことが多かった。だが画像編集ソフトウェアではチェックボックスやテキストボックスが作りづらい、HTMLオーソライズソフトウェアではデザインの微調整が面倒、紙では重ね書きしづらい…とそれぞれに欠点があった。そこでこれを導入してみよう。 今回紹介するオープンソース・ソフトウェアはPencil、Firefoxアドオンとして動作するモックアップ作成ソフトウェアだ。 個人的にはモックアップ
はてなインターン1週間のまとめ - Gemmaの日記
まずはじめに、京都は美人が多い。 はてなのジョエルテスト ソース管理システムを使っているか？ Yes. gitを使っている １オペレーションでビルドを行えるか？ Yes. 毎日ビルドを行うか？ Yes. 障害票データベースを持っているか？ Yes. gitと連携する内製ツールをつかっている。 新しいコードを書くまえにバグを修正するか？ Yes. 更新可能なスケジュール表を持っているか？ Yes. はてなグループを使っている。 仕様書を持っているか？ Yes. テスト駆動開発なので、テストが動く仕様書。 プログラマは静かな労働環境にあるか？ Yes. 買える範囲で一番良い開発ツールを使っているか？ Yes. テスト担当者はいるか？ Yes. プログラマを採用するときにコードを書かせるか？ YES YES YES! 「廊下での使い勝手テスト」を行っているか？ Yes. 満点。 はてなの開発 サ
Google社内のコードレビューについて - shibacho’s diary
森崎さんのblog経由で知りました。 興味深いのであとで見ようと思います。
はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー
はてなブックマークに関連エントリーを配信する機能を追加しました。詳しくは 告知日記で。 この関連エントリーは、株式会社プリファードインフラストラクチャー (以下 PFI) の技術者のみなさんと一緒に開発しました。週末に2泊3日で京都で合宿をしてコア部分を作り、その後京都と東京に分かれてオンラインで連絡を取りながら2週間ほど作り込みをして、今日リリースです。 この合宿では何チームかに分かれて、今回の関連エントリーの機能以外の開発も行っています。その辺の成果はまた後日にリリースできるのではないかと思います。 はてなブックマークの一つの問題として、昔のエントリーがデータベースに埋もれてしまうという点がありました。その問題の解決策としての類似記事抽出、それから検索機能の強化を以前から考えていました。PFI のメンバーのみなさんは情報検索技術のスペシャリストです。アカデミックな研究の成果を製品化を通
グーグル エンジニアのまじめな日常 ― ＠IT
グーグルがどのようにソフトウェア開発を行っているかは、これまであまり詳細が明らかにされてこなかった。だがグーグルは6月10日、開発者向けイベント「Google Developer Day 2008 Japan」を開催し、グーグルのソフトウェアエンジニアがグーグルでの仕事術を語る「Google ソフトウェアエンジニアの日常」という講演会を実施した。スピーカーは、NECでITエンジニアとして勤務した経験がある藤島勇造氏。2006年からグーグルのソフトウェアエンジニアとして働いている。藤島氏は、グーグルでのソフトウェア開発方法について、グーグルのカルチャーと自身の見解を織り交ぜて語った。 グーグル ソフトウェアエンジニアの1日の流れ 藤島氏の1日は、朝10時ごろ出社し、メールをチェックすることから始まる。この時間にメールを見る理由は、米国にいる同僚に連絡が付きやすい時間帯だからだ。 午前中の主な
30days Album Information | 30days Album を支える技術 #0 〜 サーバ構成概要
こんにちは、mizzy です。30days Album では、全体的なシステムデザイン、ストレージ API の開発、サーバ構築などを担当しています。このブログでは、「30days Album を支える技術」と題して、裏側でどういった技術が使われているのか、ご紹介していきたいと思います。もちろん、技術スタッフは私だけではないので、他のスタッフにも各自担当した技術について紹介してもらう予定です。 第0回目は、サーバ構成の概要についてです。30days Album の論理的なサーバ構成は、以下の図のようになっています。（実際には、1台のサーバが複数のコンポーネントを兼ねていますので、物理的な構成はこの通りではありません。） 各コンポーネントと、コンポーネント間の関係について、もう少し詳細に解説します。 リバースプロキシが、直接ユーザさんから見えている唯一のサーバで、ウェブブラウザからのリクエスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースソフトウェアの育て方