自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
なんだか超局地的にATOKブームがきてるっぽいのでちょっと書いてみるか。 ATOK入れたらそれだけ超快適になるかっていうとそうではなくて、確かに変換エンジンとか辞書とかも良いんだけど設定いじるともっと快適になるのでみんな設定画面をちゃんといじりましょう（ATOKのバーが右下に出てる人は、その上で右クリック→プロパティで開ける）。 話し言葉モード 基本→変換→表現 が「一般」になっていたら「話し言葉」にしましょう。 これでくだけた表現を変換しようとして誤変換することがかなり減ります。PCを仕事に使わない人はほぼこのモード固定で問題ないはず。 推測変換 省入力・入力補助→推測変換を有効にする をONにして、頻度を高にしましょう。 推測変換自体はONな人が多いと思うけど頻度が「高」の人は少なそう。そもそもPC版ATOKでの推測変換とは、日本語入力途中にツールチップで推測候補が出て、Shift+E
10分で作るRailsアプリ という動画がRuby on Railsのすばらしさを短時間に説明してくれましたが、動画の説明は何より説得力がありますよね。画面キャプチャを何枚も貼って文章で説明するよりも、目で見て、間を体験すると感じるものがあります。何より見る方は楽。 作る方も楽だったらなあとも思います。 以前自分の設計したWEBアプリのマニュアルを、パワーポイント 100ページ以上の膨大な資料としてまとめたことがあります作りながらも「こりゃあだれも見ないだろうなあ。自分でもみないもの」と思いながらも、提出義務があって仕方なく作っていました。印刷したお客さんからは「紙の無駄だ」と怒られわ、HTML化してWEBアプリに「ヘルプ」をつけても電話がかかってくるのが先でした。 しかしそんな苦労に遭わないように、最近お宝を発見しました その名も「Adobe Captivate2」 まあまあとりあえずア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
