日米アマゾン転売価格比較サイトを作ったらカロリーメイトが九千円で転売されてた：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
現在、状況が変わり本記事を転売で利用する価値はありません。 カロリーメイトや漫画が米国で転売されるケースは無くなった。 日米間の送料が高すぎる。(送料は別途が多い) 値段が無茶苦茶な業者が多い。 変な値段で出品してすぐ取り消す業者も多い。そのため掲載された商品の多くがリンク切れ。この記事を書いてから、変な業者が増えすぎた。出品できても税関や輸出規制で配送できないこともある。 「米Amazonに転売して儲けてるけど質問ある？」という、警備員が米amazon転売で月25〜50万くらい儲かっているというまとめ記事がはてブ1200くらいバズっていたので「日米アマゾン価格比較サイト」を作りました。 前述の記事の言葉がパワーワードすぎる。 「商品右から左に流すだけで情弱共が次々とポチっていく あざーすwww」 「ちなみに米amazonが一番儲かってる」 「特に米amazonあいつらマジでなんでも買って
句点の打ち方 基本編 【文章技術：句読点の打ち方】：エディテック：オルタナティブ・ブログ
これまで、以下のエントリー（文章技術：句読点の打ち方）で句読点の打ち方について検討してきましたが、読点（テン）の話ばかりで句点（マル）については説明していませんでした。そこで今回は、句点の打ち方の基本について見ていくことにしましょう。 なお、今回の「基本編」では実用文・ビジネス文書を対象とし、詩や小説などの文芸作品は扱いません。 【文章技術：句読点の打ち方】 ｜ 読点を打つ日 ｜ 読点がいっぱい ｜ 文の意味を変えてしまう読点 ｜ ご存じのとおり、句点とは 文の終わりを示す「。」の記号 のことです。このように「文の最後に打つのがマル」という説明で済めばいいのですが、実際にはあといくつか知っておかなければならないことがあります。以下では、現代的なビジネス文書では「このように書けば問題なし」という句点のルールを示したいと思います。 皆さんの会社でも、独自に「社内文書標準」のようなスタイルガイド
『iOSヒューマンインターフェイスガイドライン』はUI解説書の枠を越えている ：国内・海外情報から見える『企業のWEB活用法』：ITmedia オルタナティブ・ブログ
中小企業がITを活用して売り上げにつなげるにはどうしたらいいか？WEBマーケティングとWEB戦略コンサル実績350社50業種以上の実績とノウハウで、海外の最先端情報を中心に、噛み砕いてご紹介。 作成者：中山陽平 iOS、実質的にはiPhoneのアプリケーションを作る際に参照してくださいと言う事で配布されている「iOSヒューマンインターフェイスガイドライン（以下iOS_HIG）」 弊社のシステムを真剣にスマートフォン対応にするために読み始めたのですが、この内容が、ただのインターフェイスのガイドラインだけではなく、さらに踏み込んだ内容になっていて驚きました。 Appleのサードパーティアプリに対する姿勢、サードパーティアプリケーションがiPhoneの大きな魅力であるという認識が、このガイドラインからはにじみ出ています。 App開発者以外もぜひ見ておくべき これはぜひ、WEBに関わる方は見て頂き
チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？ 情報処理学会第170回ソフトウェア工学研究会で発表した内容。坂東祐司、森崎修司、松本健一「セキュリティ要件のレビューにおけるチェックリストの表記方法の比較」。 チェックリストに収録された質問に答えていくことにより、レビュー対象の欠陥を検出する。論文では、90名超の協力者による実験を実施し、チェックリストを使わない場合、表記方法だけが異なる2種類のチェックリストの3つのグループで、指摘の正答数、正答率を調べた。チェックリストを使わない場合と比較するとチェックリストを使用したほうが、正答数、正答率ともに向上し、統計的有意差があった、というもの。 チェックリストを使ったほうが欠陥の検出数、正答率も高くなるという結果となった。今回のチェックリストは論文のタイトルのとおり、セキュリティ
スキャン代行サービス：BOOKSCANさんを見学：プログラマー社長のブログ：オルタナティブ・ブログ
たまたま著書をスキャンサービスの評価に使うというご縁から、スキャン代行サービスのBOOKSCANさんを見学させていただく機会をいただきました。まあ、一応著者の立場からの参加ということになりますが、私の場合、執筆は副業であり、本業のアピールを兼ねているということで、執筆でメシを食っている方とは基準が全く異なると思いますので、あくまでも個人的な興味から見学をしたという感想を書かせていただきます。 綺麗にしたばかりの入り口付近！ ちょうど社内でも自炊（自分で本をスキャンする）の話題は盛り上がっているところでした。メンバーの一人がもうすぐ結婚するということで、多くの蔵書を持つ彼は当然本の処分を迫られ、最初は中古屋さんに引き取ってもらおうかという話でしたが、他のメンバーたちが共同してオークションに出す作業を請け負うということで、そのときにも、実は裁断してから出品した方が高いという話になったり（実際は
速報：なんと！PCMCIAはメンバーに解散を発表：餅は餅屋、品質検証は品質検証屋：オルタナティブ・ブログ
ますます複雑化する開発製品の品質検証。エンジニアの皆さんに向けてAllion Labs, Inc.（アリオン）の島田が品質検証よもやま話をお届けします！ PCMCIA団体が解散し、ExpressCardコンプライアンスの運営はUSB-IFの下に ExpressCard技術およびコンプライアンスを推進しているPCMCIA(Personal Computer Memory Card International Association)は2010年1月31日をめどにPCMCIA団体を解散し、PCMCIAの資産やExpressCard技術およびExpressCardコンプライアンス/ロゴ認証プログラムの運営をUSB-IF団体に移行するとメンバー向けのリリースにて発表しました。 現在のPCMCIAメンバーは追加費用なく、USB-IFの下で満了までPCMCIAとの会員契約を維持し、契約満了後は、USB
ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
IEEE Transaction on Software Engineeringの論文Raymond P.L. Buse and Westley R. Weimer: Learning a Metric for Code Readabilityから。120人の被験者が10種類のオープンソースプロジェクトのソースコードの一部（20行等、非常に局所的）をもとに読みやすさに影響を与えることを実験結果から示している。 25種類のメトリクスと読みやすさとの相関を求めている。メトリクスには、コメント行数や予約語の数、空行の数、括弧の数、変数名の長さ、変数の個数などが含まれる。このうち、読みやすさに最も影響を与えやすいメトリクスとして、1位に変数の個数、2位に行数、3位に括弧の数、9位に空行数、15位にコメント行数が示されている。 この論文では、多くの人に短時間で読みやすさが評価できるように、対象ソース
クレイ・シャーキー曰く「情報洪水などない。それはフィルタリングの失敗だ」：シロクマ日報：オルタナティブ・ブログ
Twitter でつぶやいてみたら意外に反応をいただいたので、ちょっと書いておきましょう。以前も著作"Here Comes Everybody"をご紹介した、作家でコンサルタントのクレイ・シャーキー氏の言葉です： It's not information overload. It's filter failure. 情報洪水などない。それはフィルタリングの失敗だ。 実はこの言葉、昨年行われた Web 2.0 Expo NY で彼が行った講演のタイトル。残念ながら TED のようにスクリプトは公開されていないのですが、YouTube で動画を見ることができます： 彼のメッセージを簡単にまとめてみれば、こんな感じになるでしょうか： みんな「情報が増えた」と騒いでるけど、それはずっと昔から続いていることだ。 グーテンベルクが活版印刷を発明した時も、出版が容易になって世間に本があふれる結果となった
「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
ソフトウェア技術者のための英語（2: 多読、多聴）：An Agile Way：オルタナティブ・ブログ
【英語をたくさん読み聞きすること】 まずは、最初の「英語をたくさん読み聞きすること」という壁だが、あたりまえ、と思うかもしれない。これを強調したいのは、周りの多くの日本人が英語で作文したり発話したりして失敗している例をみると、英語で表現するときに、 内容を思いつく ⇒ 英語の単語に訳す ⇒ 文法を使って組み立てる とやっている風に見える。これは最後に出てきた文章を見ると「あぁ、これは伝わらないだろうな」というものになる。へたをすると、裏の日本語がすけてわかったりする。そうではなくて、伝わる英語で表現する手順は、 内容を思いつく ⇒ 過去に聞いた同じような文を思い出す ⇒ それを一部変えて文を組み立てる となる。 つまり、「過去に聞いた同じような文を思い出す」のが肝で、これはたくさんの英語に触れることが絶対的に必要な根拠だ。ぼく自身も、初めて使う動詞や初めて使う文章パターンは、まず伝わる確率
AS/400産みの親の退職：猫のベロだまり：オルタナティブ・ブログ
AS/400というコンピュータ(今はPowerシステムと表現されるが、ここはあえて古い名前で呼んでおく）に関わるコミュニティーの中で、最も有名な人物と言えばおそらくDr. Frank Soltisだろう。いくつかの革新的なアーキテクチャーを作り上げたのが彼であり、AS/400生みの親とも言われている。先日来日した際に聞いたところではIBM在籍40年とのことだが、さすがに今年末で退職するらしい。 一般に外人が日本で講演する際に課題になるのが、通訳を入れるのかどうかという点である。例えばお客様相手で質を求めるとなると、プロの通訳、しかも同時通訳を頼むこともある。一方コストをかけるほどではないけれども通訳は必要となると、社員が借り出されることになる。さすがに同時は無理なので逐次通訳で対応する。僕も何度かそういう役割を仰せつかったことがある。外人が話した内容のポイントだけは逃さないように殴り書きで
「iPhoneは失敗する」を予想した人たちの言い訳：CloseBox & OpenPod：オルタナティブ・ブログ
Mac、iPhone、iPod、歌声合成、DTM、楽器、各種ガジェット、メディアなどの情報・雑感などなど The Standardがおもしろい記事を掲載しています。1年前に「iPhoneなんてうまくいきっこない」と断言していた人たちにインタビューし、なぜそんな予想をしたのか、あなたの予想はいまでも正しかったと思っているのか、いまiPhoneを使っているのか、など切り込んでいきます。 ・The iPhone naysayers, one year later 米国ではウォルト・モスバーグ、スティーブン・レビー、デビッド・ポーグのテクノロジーライター3巨頭を味方につけてしまったこともあり、あからさまな反対者は少なかったようですが、その「間違ったほうに賭けちゃった人たち」がどう自己弁護しているかがなかなか興味深いのです。 「あの時点ではまだ3Gじゃなかった」「iPhoneはいいけど、いいのはja
上流工程に関わる人にこそプログラミングを経験してほしい：情報インフラ24時 眠らないシステム：オルタナティブ・ブログ
一般的にも、システムインテグレーション（SI）には大別して上流工程（要件定義・概要設計）と下流工程（詳細設計・プログラミング・ テスト）があり、どちらが欠けてもシステム開発は成功しません。 アクセンチュアでは、＜計画・分析・設計・構築・テスト・展開＞のフェーズに分けてSIプロジェクトを推進しており、 各フェーズで担当者が異なってもスムーズにバトンタッチできるようなアプローチを採用しています。 いずれにしても、SIプロジェクトの規模が拡大するにつれて、上流から下流まで一気通貫で直接作業を行う機会はなくなり、 むしろ分業によって効率化を図ろうという流れに必然的にたどり着くのですけど、これが無理解なセクショナリズムによって対立に結びつき、 そもそもの目的である顧客満足の達成を阻害するというケースがあります。 例えば、こんな状況を想像してみてください。 『クライアントの業務部門と直接折衝して要件定
Scott Ambler と ソフトウェア開発のメタファについて話をした。：An Agile Way：オルタナティブ・ブログ
IBM の中でテクニカル的にアジャイルについての発言をしているのは Scott Ambler です。今日は彼と話すことができました。Agile@Scale のBofです。 BOFは４人でしたので、ひざを突き合わせて話をしましたが、そのうち一人は、Agileというコンセプトに始めて出合った人。その人の、 「ソフトウェアは工学的に作るようにようやく進歩してきたのだ。Agileはその歴史を、人側に逆戻りさせようというのか？」 という質問に、 「昔、太陽は地球の周りを回っていると思われていた。しかし、回っていたのは地球だった。これがAgileのパラダイムシフト。もしかしたら、後何年か先に、宇宙の中心がみつかって、そこを中心に回っていることがまた発見されるかもしれない。ソフトウェア工学はまだ40年しか歴史がないのだから。」 といい答え。さらに、 「建築や土木をソフトウェアのメタファと捉えるのではなく
42歳の抱負。(現在のソフトウェア開発における３つの個人的課題）：An Agile Way：オルタナティブ・ブログ
先日、5/20で42歳になったので、抱負、というか今ぼくが課題に思っていること、考えていることをいくつかメモとして書いてみます。技術的なことと、ビジネス的なこと、そして人生についてのことがあります。 １．ソフトウェア工学 ソフトウェアアーキテクチャ、および開発方法論はまだまだ進歩過程にあるが、次の２つのことが最近分かってきており、今後より強く浸透していくのではないだろうか。 ・再利用性、という価値観と、変更容易性という価値観が独立し、これら２つの価値観は別個に発展する。オブジェクト指向をはじめとする設計手法は、再利用性という方向では組織・流通・資産化を含んだプロダクトライン、変更容易性という方向ではリファクタリング、テスト駆動、アジャイル、というそれぞれのプロセスを伴った方向に分化する。再利用性は、設計のみならず、知識の再利用がキーとなりパターンのようなコンテキスト情報を含んだ知識流通形態
Design by contractでソフトウェア機能を記述する：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Design by contractはソフトウェアの機能や関数/メソッドの事前条件、事後条件、いかなる場合でも不変である状態（条件）、を明らかにし、文書化する手法だ。機能や関数/メソッドが想定している範囲を明らかにし、想定外の使われ方を防ぐことにより不具合防止を支援する。 条件をソースコードに含めておき、条件を満たさない場合に、実行をやめたりするものを契約プログラミング（Programming by contract）と呼ぶ。assertのような言語仕様を使ったり、例外処理を使ったりして、機能や関数/メソッドが想定外の使われ方をしていることを明らかにする。 外部仕様に相当するドキュメントにはこれらの条件が比較的記述されていることが多いように思う。詳細設計、内部仕様やソースコードに記す場合には、対象の数が多くなることもあり、網羅的に記述するのはしんどいところだろう。形式的でないドキュメントに
マーケティング理論やリサーチで、イノベーションは起こせない：永井経営塾：オルタナティブ・ブログ
日本マクドナルド会長兼社長の原田泳幸さんのインタビューは、非常に啓発されました。 ---(以下、引用)--- 社員に最近よく言っていることは、スタッフをマネジメントするときに、いろいろな管理目標とかあるじゃないですか。数値管理して、数字で人を評価する、これをやったら社員は全員だめになる。最初は考えさせるんです。「考えをまとめ、自分の進捗をきちんと継続するために、こういうツールがある。これは支援ツールだよ」とマネジメントしないと、「これでこれをこのようにやれ」と言うと、それをやることが仕事になって、みんなの思考能力が犠牲になるわけです。 ---(以上、引用)--- 全く、その通りですね。 自分、または自分の組織の仕事の進捗をどのように管理するか、ということを考え抜いた結果、自分自身で数値目標を設定することは非常に意味があることだと思います。 また、チームメンバーと、仕事をどのように進めるかを
Web2.0が企業内に浸透しない理由：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
昨日はとある会合でEnterprise2.0について話してきた。聴衆は大企業の情報システム部門で主に企画を担当している人や意志決定を行っているCIOの方々。私のプレゼンに続けて、手嶋屋の手嶋社長からSNS、マイネット・ジャパンの上原社長からソーシャルブックマーク、エビリーの中川社長から動画共有サービスの企業内での活用について紹介があり一部はデモもあるという盛りだくさんの構成だった。 で、会合の終わった後の懇親会でこうしたEnterprise2.0系のツールの導入や検討状況についてちょっと聞いてみた。予想していたとおり、多数の企業ではEnterprise2.0というかWeb2.0への取り組みはまだまだのようだ。その理由をいろいろ聞いて回ったところ出てきたのは、 SNSやブログといった社内コミュニティは、維持や運営の負担が大きい 社内で日記を書く効果がわからない（他人の昼飯の話を聞いて何が面白
マネージメントが精神論だけを語りだしたら…
物事を動かす時、そして困難な事象に対応するときに精神論重要です。関係している全員の気持ちや方向性を一つにするために、精神論を説くことがときに有効な手段になります。 しかし、その一方で問題や課題を解決するときに、精神論にしか頼らないマネージメントは本来のマネージメントの機能を果たしていません。危機的な状況で、具体的な解決を伴わない精神論を打ち上げる人ほど、実は自らその窮状に関して責任を感じていないだけでなく、具体的には何も解決する力を持たない、いわば”はりぼて”のマネージメントであったりします。 また、危機的状況で精神論しか語らないマネージメントに見られる傾向としては、初めの手段（条件反射的手段）として組織的の組み換え、人員の追加、上層部へのエスカレーションといった短絡的手法を選択する傾向があります。問題を冷静に見つめ、解決に向けたシナリオ、具体的リスク、実現可能性といった対応方針として検討
CMMとAgileについて、Capers Jones の記事：An Agile Way：オルタナティブ・ブログ
アジャイルとCMMの比較記事です。 ■ Development Practices for Small Software Application http://www.stsc.hill.af.mil/crosstalk/2008/02/0802Jones.html Agile と CMM(or CMMI) の考え方の共通点として、 ソフトウェア要求は、常に変化する。 欠陥を修正するのは最もコストが高い。 高品質であることが、生産性と納期短縮につながる。 としていて、逆に異なる点として、 ドキュメントを書くことは二番目にコストが高い(Agile) 測定しなければ、継続的な改善は起こらない(CMM) を上げている。そして、1,000 FP の小さめのプロジェクトで、アジャイルチームとCMM 3 チームを統計して、 Agileの方が生産性(短時間あたりのFP）が高い。 Agileは欠陥潜在を下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
