t-wadaのブックマーク / 2005年8月24日

t-wada id:t-wada

2005年8月24日のブックマーク (10件)

Gmailで別のメールアドレスからメールを送る方法 - Ogawa::Memoranda
Posted by: Hirotaka Ogawa @ August 24, 2005 12:20 AM | GmailではもともとReply-Toに別のメールアドレスを設定することはできましたが、Fromに別のアドレスを設定することはできませんでした。そのため、例えばGmailでもらったメールの返事を別のメールアドレスで送るとか、出先でちょっとPCを借りてメールを送るとか、そもそもGmailのインタフェースですべてのメール処理を完結させるとか、そういう目的に使えなかったわけです。が、実はそれが最近設定できるようになったことを某氏に教えてもらったので、その方法を紹介しておきます。まずGmailのインタフェースを英語に切り替えます(普段から英語インタフェースを使用している場合にはこの作業は必要ありません)。画面の右上の「設定」をクリックして「メール設定」画面を開き、「Gmail表示言語」を
t-wada 2005/08/24
リンク
Gmail Maniacs
gmail-maniacs.net はお客様がお探しの全ての情報の原点です。一般的な項目からお客様がお探しのものまで、 gmail-maniacs.net は全てここにあります。きっとお探しのものが見つかるはずです。
t-wada 2005/08/24
リンク
要素還元論から混沌の縁へ - 変わりつつあるソフトウェア開発の価値観 - 4
要素還元論から混沌の縁へ 1. はじめに科学が今日のように発展したのは「要素還元論」という考え方のおかげです。何だか難しい名前が出てきたからってページを閉じないでください。その意味しているところはいたって簡単なのですから。要素還元論とは，世の中の事象を細かい構成要素に分解し，各要素を調査，分析して，解を導き出し，それらの解を積み重ねていけば，その事象全体の解に到達できるというものの考え方なのです。要素還元論を簡単な数式で表現してみることにしましょう。 y = 3 * x という式を考えてみてください。この式の x に 6 を代入すると，18 という答えが得られます。こういった一次式の場合，x を要素に分解し，その結果となる値を足し合わせることでも y を計算できるのです。　つまり，6 という値を 6=(x' + x'') という要素に分解し，y = 3 *
t-wada 2005/08/24
think

agile
リンク
IBM
IBMの技術と知見が、さまざまな業界・分野において、お客様の挑戦や前進に向けた取り組みを支えています。
t-wada 2005/08/24
groovy
リンク
http://ttmp.skife.org/index.php/Protocol
t-wada 2005/08/24
ruby

j2ee

messaging
リンク
IDE4Laszlo
Page Not Found Sorry! The page you requested was not found. Additional Resources Discover these carefully selected resources to dive deeper into your journey and unlock fresh insights Office If you need immediate assistance please contact the Community Management team support@communitysite.ibm.com Monday - Friday: 8AM - 5 PM MT
t-wada 2005/08/24
j2ee

messaging
リンク
TheServerSide | Your Java Community discussing server side development
t-wada 2005/08/24
j2ee

messaging
リンク
データベースカバレッジという考え方 - きしだのHatena
データベースアプリケーションのテストデータを用意するとき、どういうデータを用意しますか？「注文があって出荷してないデータ」「注文があって出荷していて入金がないデータ」という風に業務の流れにそってデータを考えることが多いと思います。ただ、テストの本を見ても、どうやってテストデータを用意するかということが書かれていることは多くありません。というか市販の本で見たことがありません。データベースアプリケーションでは、ひとつの処理でまったく分岐がなく上から下にSQLを順番に発行するということが少なくありません。そういうとき、C1とかC2とかの処理カバレッジというのは簡単に100%に近くなってしまい、テストがアプリケーションの状況を網羅しているかどうかという指標にはなりにくくなります。データベースアプリケーションでは、「すべての処理を行ったかどうか」という処理カバレッジでは充分ではなく「すべての
t-wada 2005/08/24
testing

dbms
リンク
「テストを最初に書くことのメリット」？ - dann's blog
http://d.hatena.ne.jp/thata/20050823#1124765700 僕が開発をする場合はインターフェースから書き出すことは最近はまずないです。インターフェースを検討するために実装から書き始めます。ある程度実装をして試行錯誤してみてから、インターフェースを書きます。何故かと言うと、ラフスケッチがないと、本当のインターフェースが見えてこないからです。僕がTDDを試してみて思うのは、TDDでは試行錯誤の段階がないために、インターフェースの修正を初期段階で頻繁に繰り返すことになるのでロスが大きいということです。だから、ラフスケッチにTDDは向いていないんじゃないかなと思っています。検討する度にassertionと実装を変更するのは速度が遅く、ラフスケッチには向かないと思っています。 TDDの感覚は、僕にはどうもいきなり本番書いているような感じがしてどうもしっくりき
t-wada 2005/08/24
TDD

design
リンク
Peak Obsession
t-wada 2005/08/24
RoR

ruby

java
リンク
- 2005年8月25日
- 2005年8月24日
- 2005年8月23日