セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。 では、個別に入力項目を増やすようなスキーマの変更を伴うアプリケーションのカスタマイズや、新たなテーブルを作成してそこに独自データを保存するようなアプリケーションの新規作成はできないのか？ といえば、そんなことはなく、セールスフォースが提供するプラットフォームの上で、自由に項目の追加や新しいテーブルの作成が可能です。 全ユーザーでスキーマを共有しながら、しかし個別のカスタマイズを許容する。この一見矛盾する要件を、セールスフォースはどのように実現しているのでしょうか？ （本エントリは「知られざる『マルチテナントアーキテクチャ』（2）～スケーラビリティのカギは組織ID」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル

チケットに対応してて（間接的に）教えてもらったワザ。 #20567 http://trac.macports.org/ticket/20567 いくつかのportには"-devel"とついた、開発版のパッケージがある。たとえば、cairoとcairo-develとかね。依存関係は通常パッケージ名で管理するようになっていて、どちらかがあればよい、という書き方はできない。バリアントでdepends_libを差し替えという手もあるけど、機能的に大差ないのなら避けたい。 そこで、 % ack -a -G Portfile depends_lib rb-rcairo rb-rcairo/Portfile 18:depends_lib-append path:lib/pkgconfig/cairo.pc:cairoのようにすれば、すでにcairo-develまたはcairoにより、pkg-config

もう2ヶ月くらい前になるかもしれませんが、Xcode関連で調べ物をしていたときに偶然見つけた方法をちょっと弄ったらうまい具合に SIMBL plugin 向けにも動いたよっという話です。 超ニッチな情報ですが、僕は超テンションが上がりましたのでご紹介。 Custom Executable を追加 メニューバーから　”Project” ＞ ”New Custom Executable” をクリック 出てきたウインドウに適当な名前を付けて、プラグインの対象となるアプリを選択。 Run Script Build Phase を追加 メニューバーから　”Project” ＞ ”New Build Phase” ＞ ”New Run Script Build Phase” をクリック 出てきたウインドウに以下のスクリプトをコピペ。 # clean up any previous products/s

CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。 mgさんのコメントを書きながら、考えたことをメモ。 【元ネタ】 アジャイル開発は受託開発の方が向いている: プログラマの思索 「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。 第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。 SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。 設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。 仕様変更が来たけれど、バグ修正を優先すべきか？ バグ修正よりも、目先のタスクをこなすべきか？ 全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？ 今、僕は

sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ

■ はじめに 先日、社内でこういう話題がありました。 「Windows 上のプログラム A からソースコードのないプログラム B を起動する必要があるんだけど、プログラム B はときどき異常終了しちゃったりする。内輪用だから落ちること自体は目をつぶるとして、プログラム B が異常終了した場合にはプログラム A 側でそれを上手にハンドルしたい。良い方法はないものか」 この話に興味を感じ、異常終了を起こす短いプログラムを作ってデバッガでトレースしながらヒントを探している内にふと思いました。 このプログラムを裸で実行すると、プログラム内で処理されない例外は図のような形でシステムによって処理されます。しかし、デバッガ上でデバッギ（デバッグ対象）として実行している場合はデバッガが例外の発生を検知しそれをユーザに伝えます。つまり、デバッガの制御下にあります。 ということは「デバッガとして動作するコード

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo!ショッピング担当の吉野です。 今回はタイトルの通り、headコマンドとtailコマンドのソースコードを読んでいきたいと思います。 ■はじめに 皆さんご存じの通り、headコマンドはファイルの先頭からn行(バイト)を出力し、 tailコマンドはファイルの末尾からn行(バイト)を出力するコマンドです。 ほかにもパイプの入力に使ったり、[tail -f]でログファイルの出力監視に使ったりと、 UNIXを使う上では欠かせないコマンドと言えるでしょう。 headとtailは見た目の動作は似ているようですが、ソースコードの中は結構違います。 さっそく見ていきましょう。 ＜headのソースコード＞ http://www.

はじめまして。面白法人カヤックの村瀬と申します。ArkというWebアプリケーション作成用のフレームワークを開発しました。今回から4回にわたって、このリリースしたばかりの「Ark」について紹介させていただきます。 Ark（アーク）とは Arkは、Perlで作られたWebアプリケーションフレームワーク（WAF）です。 Arkの特徴としては Catalystに似たインターフェース CGI／FCGI／mod_perlなどさまざまな環境で実用的に動作する CGI用モードの存在 日本製であり、日本語ドキュメントが充実している などが挙げられます。 Catalystに似たインターフェース Catalystは、Arkと同様にPerl製のWebアプリケーションフレームワークで、現在、Perlのフレームワークでは標準となりつつあるものです。 Arkは開発動機の1つが「CGIでも実用的に動作するCatalyst

先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出

翻訳者の角谷さんより献本をいただきました。ありがとうございます。 アマゾンに以下のレビューを投稿したのですが、なぜか1ヶ月以上待っても表に出てこないので、こちらに出します。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ この本が問いかけているのは「開発者にとって客は敵なのか味方なのか」という問いだと思う。 私がソフトウエアの見積りの本を読む時に、漠然と期待してしまうのは、「これで客の口を塞ぐことができるか」ということだ。つまり、自分が「これは1000万円かかりますね」と言って顧客がそれを値切ろうとした時に、「いやこの見積りは正確です。なぜなら....」と言うような、建築における構造計算のような理論武装が欲しいと思ってしまう。 こういう思考の暗黙の前提は、「開発者と顧客は敵同士である」ということだろう。 見積りも仕様も開発者と顧客の間で交わす契約である。契約とは

電子工作の経験がなくても、誰でもハードウェアを自作できる時代が来ていた！ 2009-06-07 『電子工作』 なんとなく興味はあるけど、電気回路なんてまったくわからないし、はんだごてとか使うのもやたら危なそうだし...というイメージが（少なくとも個人的には）ある電子工作の世界。 そんなイメージは、とあるセミナーでぶっ壊されました。 なんと、最近の電子工作の世界は「プログラミング未経験でもperlでCGIやPHPぐらいならできそう」と同じくらいのところまできていたのです。 たとえば、PCを使わずに「人が通ったことをセンサーで感知して、自動的にtwitterにpostする機械」を、電子工作経験がほぼゼロの僕でもちょっとがんばれば作れそうと思えるぐらいでした。 「できたらいいなあ」が「やればできちゃう」ぐらいになってて、なんだか、視野がぐぐっと広がった感じがしてかなりテンションがあがりました。

Apache CouchDBに関するメモ書き。 ＃理解が不完全なので、後で正しく書く。 【元ネタ】 Apache CouchDB: The CouchDB Project Web 時代の非リレーショナルデータベース: 第 1 回 Apache CouchDB の概要とインストール Web 時代の非リレーショナルデータベース: 第 2 回 Apache CouchDB と Ruby on Rails を使って wiki アプリケーションを作成する Web 時代の非リレーショナルデータベース: 第 3 回 Apache CouchDB で MapReduce フレームワークに基づく問いあわせを行う MOONGIFT: ? Web2.0時代のニュータイプDB「CouchDb」:オープンソースを毎日紹介 CouchDBはこのように説明されている。 CouchDB を探る CouchDB はオープン