タグ

2011年12月22日のブックマーク (10件)

  • APIとDesign Documentでカクテルブックに挑戦

    APIとDesign Documentでカクテルブックに挑戦:ゆったリラックス! CouchDBがあるところ(2)(1/5 ページ) オープンソースでモダンなドキュメント指向データベース、CouchDB。今回は実践的な「カクテルレシピブック」を作りながら、CouchDBの特長を解説します。サンプルプログラムをダウンロードし、実際に体験してみてください。(編集部) カクテルのレシピブックをCouchDBで作ろう 第1回「“動物図鑑”で知るCouchDBの特徴」で、ドキュメント指向のデータベース、CouchDBの概要をお伝えしました。連載の第2回目はCouchDBの具体的な操作方法である、HTTPを利用した基的なAPIやDesign Documentがテーマです。カクテルのレシピブックをCouchDB上に作る場合を例に解説していきたいと思います。レシピブックの1ページが1つのドキュメントにな

    APIとDesign Documentでカクテルブックに挑戦
  • Officeユーザーにこそ?CouchDBでお手軽アプリ開発

    第3回は、CouchDBを利用してWebアプリケーション開発を行うためのツールと、Windows版CouchDBについて紹介します。筆者はCouchDBをWebアプリケーション開発者だけが使うのではなく、システム管理者やMicrosoft Officeで事務処理を行っているユーザーにとっても有意なツールだと考えており、そういった方面での活用できるのではないか? と考えています。 CouchDBを使った開発は、いままでとどう違うの? Webアプリケーションの世界で、いま現在よく使われているのは「3層モデル」と呼ばれる仕組みだと思います。クライアントからのリクエストに対し、アプリケーションサーバがデータベースからデータを持ってきて、処理した上でクライアントに結果を返す、というイメージです。CouchDBを使った仕組みでは、CouchDBをホスティングしているサーバがいるだけです。つまり、Cou

    Officeユーザーにこそ?CouchDBでお手軽アプリ開発
  • ついに登場! 究極の見積もり技法(その1:解説編)

    「ソフトウェア技術者の最高の能力は、見積もりだ!」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的(正確に見積もるだけでは不十分)」「見積もりの具体的な方法(精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある)」「見積もりの応用(見積もり値に合わせる制御と再見積もり)」「見積もりの調整(状況に応じて開発量とスケジュールを再見積もりしなければならない)」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は

    ついに登場! 究極の見積もり技法(その1:解説編)
  • MIMOが効くしくみ | 無線にゃん

    今話題の通信速度倍増技術といえば、もちろんMIMO。これ、実際にはどういう条件で効きやすく、どういう条件だと効きにくいのか、というのがあると思うのですが、今回は私なりの考えを披露してみようという一言。※別サイトからの加筆・再掲です MIMOは、あるアンテナから出たデータと別のアンテナから出たデータを、受信側のアンテナでうまく分離することで実現します。これは、イメージとしては、カメラのフォーカスと似たような感じ。カメラのフォーカスの場合はレンズの焦点距離を変化させて「一番はっきり見える位置」を探すわけですが、電波の場合はアンテナのパラメータを調整して既知のデータをうまく見えるフォーカス位置を見つけ出して、そのときの周囲のデータを読む、ということを別々の系統に対して行うことで複数のデータ列を読み出します。 一応補足ですが、実際は、「アンテナパラメータをちょっとずつずらしてきっちり見える位置を探

  • ISO26262 Part.6 ソフトウェア開発(手法)

    自動車分野向け機能安全規格「ISO26262」のソフトウェア開発(手法)概要 これまで自動車分野向けの機能安全規格「ISO26262」の概要について解説してきましたが、今回は最終回として、ソフトウェア開発における“手法”にフォーカスし、その内容を紹介したいと思います。 ISO26262の準形式手法、形式手法 機能安全規格では、要求や設計を「準形式手法」や「形式手法」で記載することがあります。 ここで使用する準形式手法は、ISO26262FDIS(最終ドラフト)版により、「UML」や「SADT」が推奨されており、汎用性や準形式検証(シミュレーション)を考慮するような場合には、UMLを利用することが多いと考えられます。 一方のSADTは、次のような図を用いた手法となります。 UMLについては他の連載や関連する情報が多く存在するので、稿では、これまであまり紹介されてこなかった形式手法について解

    ISO26262 Part.6 ソフトウェア開発(手法)
  • DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ

    プログラム開発のために Android 上でアプリが起動するまでの過程を調べてみました。備忘をかねて、ソースコードをひと通り追跡した記録をここに控えます。 まとめ ※クリックすると大きな図が開きます Zygote(ザイゴート)プロセスは、Android システムブート時に起動し DalvikVM 体と Android プログラムの実行に必要なダイナミックリンクライブラリと Java のクラスライブラリをロードした状態で待機する常駐プロセスである Zygote プロセスの目的は、同プロセスを fork することによりプログラム実行用のプロセス環境を素早く効率的にシステムへ提供することにある UNIX ドメインソケット /dev/socket/zygote が Zygote プロセスへのインターフェイスであり、同ソケットにプロセス生成要求を送出すると Zygote はプロセス fork を実

    DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ
  • トラフィックが急増! ボトルネックを退治しよう〜 : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の14日目です。 このシリーズも、初めは専らアプリケーション寄りの話題でしたが、ここ二回ほどはインフラ寄りの話題でした。今日はさらに(OSIの7階層モデルにあてると)下寄りの話題になります…。できるだけ分かりやすく書くつもりですので、お付き合い頂ければと思います。 負荷分散機がボトルネック さて、DSAS for Social ではいくつかのアプリケーションが動いているわけですが、では1つのアプリケーションがピーク時に使う帯域はどれくらいになるか、皆さん想像がつきますでしょうか。答えはもちろんアプリケーションによって全く変わるのですが、今まで記録した中での最大値は、2Gbps を越えました。これは、サーバに搭載されている NIC の能力を越えています。もちろん、1台の web サーバでこの

    トラフィックが急増! ボトルネックを退治しよう〜 : DSAS開発者の部屋
  • 【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む

    組み込みソフトウエア分野において、日でも要件管理の導入が進みつつある。 要件の実現はシステムの開発において必ず求められることなので、これまでもExcelなどを駆使することで、要件の管理や実現は何らかの形で実施されてきた。 だが、近年、ソフトウエアを含んだシステムの複雑性が増すにつれ、その安全性に関して説明責任を向上させようとの意識がさまざまな業界で高まってきた。ハザード解析およびリスク・アセスメントを行い、安全要件を立てた後、それらが後工程の成果物にキッチリと反映されているか。膨大な要件に対してそれを体系的に追跡することが求められつつある。いわゆる、要件のトレーサビリティの確保である。

    【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む
    vcc
    vcc 2011/12/22
    要件管理ツールは、実質的に米IBM社の「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」の三つ
  • Appleが半導体ベンチャーの買収を狙うわけ

    フラッシュ・メモリは携帯機器やパソコンのデータを蓄えるメモリ、という単純な部品ですが、アプリケーションに特化した、メモリを制御するシステム技術が重要になっています。フラッシュ・メモリは世界で最も進んだ微細加工の技術を使って製造され、2012年には10数ナノメートル(1ミリメートルの10万分の1)にまで微細化された製品が商品化されます。 微細化はメモリの容量が大きくなる利点はあります。その反面、1個のメモリの蓄える電子の数が減ったり、周囲のメモリとの間の干渉などにより、信頼性が悪化する欠点があります。メモリへの書き換えの回数が増えるに従って、メモリが壊れてしまうのです。10年前のフラッシュ・メモリが1万回書き換えることができたのに、最近のフラッシュ・メモリを書き換えられる回数は、数千回にまで減ってきています。 Anobitが得意とするのは、そんな壊れやすいフラッシュ・メモリの誤りを訂正するシ

    Appleが半導体ベンチャーの買収を狙うわけ
  • https://av.watch.impress.co.jp/docs/series/np/500646.html