FelicaLiteカードを購入した。 昨年には発表されていたが、販売が始まったのがつい最近、そのうえ業務用のため個別販売は基本的にされていない。そんな中1枚から販売している会社を見つけたので早速注文してみた。 felicaカード(左)とFelica lite カード(右) 普通の生カードが届いた。中のFelicaチップが違うだけで、外側は今までと同じ。 早速IDmを読みとってみたが、通常のFelicaと同じく、一意のIDmが取得できた。 通常のFelicaが、1枚あたり1500円前後、このFelicaLiteは1枚400円。 一意のIDmを使って、ユーザー認証程度に使うには、FelicaLiteで十分である。 FelicaLiteシールも今後出荷されるとのこと。シールになればもっと気楽に使えるようになるだろう。 開発キットも、AdobeAIR・AdobeFlash対応版だと無償で利用でき
ウォータフォールモデルによる開発手法の基礎(w) ...ソフトウエア開発手法の基礎をまとめてみました。 レビュー(r) ...レビューの仕方 コード作法・設計作法(c) ...コード作法 デバッグ(d) ...デバッグの仕方 JUnitとは(u) ...ソフトウエア開発手法における JUnitの使い道をまとめてみました。 eclipseメモ(e) ...eclipseのショートカットなど デバッグ技法について明確に書いてある。事例がハードウエアよりだが、文脈を読めば問題なくわかる。 ルールが9にまとめそれぞれがわかりやすく、基本的で大事な物ばかり。当たり前のルールだが意識化して行くにはとても役に立つ。デバッグ時に焦ってしまう人にお勧め
まず、単体テスト自動化のメリットとデメリットを整理します。 メリット テスト実行のコストを下げる。 コードによりテスト項目を記載するので、項目に曖昧さが無くなる。(テスト準備ミスなどが減少) テスト実行のコストが少ないので、不具合修正の時に、他のコードに影響していない事を確認することが容易。 自動化されているため、業務知識が無い他の部分を担当しているメンバーでも、実施やデグレード確認が可能になる。 1つめ テスト実施コストは劇的に下がる。2人月ぐらいのコストが、1Hで終わることも少なくない。 テスト環境のセットアップ時間など細かいこともあるかもしれないが、トータル的には工数削減につながる。自動でテストされるので実施中は、他の作業を行っていても問題ない。 2つめ 日本語などと違い、テストコードとして記述するので、曖昧性が排除される。また、レビューを行わなくても、自分で、テスト項目の精
Googleのコードレビューのプロセス、ツールの紹介がここ(Youtube)にある。55分と長いのでなかなか全部をみる時間がなかったが、休日に時間がとれたので観た。このエントリはそのときのメモだ。 Googleのコードレビューのプロセスはオープンソースのものと似ている。オープンソースのものより若干強制力のあるプロセスとそれをサポートするツール(Mondrian)があるそうだ。ビデオでプレゼンされているのは、Guido van Rossum氏、Pythonの作者でGoogleに就職して最初の仕事がMondrianの開発だったそうだ。定着しているプロセスの実行を支援するツールは非常に頼もしいだろうなぁと思う。 詳細はビデオをみていただきたいが、プレゼンの概要は以下のとおり。 プロセスはオープンソースのレビューのやり方がベースとなっている。 (前のバージョンとの差分をMLに投げるとレビュアがその
Database Modeling Excelは指定フォーマットに沿ってDB設計書を作成することでSQL文に変換してくれるExcelファイルです。 システムの設計書を作成する中でデータベース定義書を書くことがあると思います。そんなときにはDatabase Modeling Excelのテンプレートに沿って記述してみましょう。そうすれば作成した後、SQL文に簡単に変換できますよ。 ファイル構成です。このExcelファイルはデモ兼テンプレートとなっています。MySQL/Oracle/SQL Server用が用意されています。 MySQL版です。まず表紙があります。 各テーブルの定義です。この形式に沿って自分で記述します。 ルールも書かれています。 処理を行うバッチファイルの内容です。 実際に生成されたSQLファイルです。MySQLのものを読み込めばMySQL対応のSQLが出力される仕組みです。
トラブル時、ユーザーが本当に知りたい情報は何か:仕事を楽しめ! エンジニアの不死身力(18)(1/2 ページ) 不死身力が試されるトラブル対応 前回『「潜在バグはある」という意識でトラブル解決に臨む』では、システムトラブルへの意識の持ち方と、プロジェクトメンバー間の関わり方についてお知らせしました。 前回は開発チーム内向けの記事でしたが、実際のトラブルでは、開発側だけではなくユーザー側にも影響を与えます。トラブル時のユーザー対応として最も重要なスキルの1つが、「状況をうまく説明できる力」です。トラブルは業務に影響を与える分、ユーザーの不安をあおらないための工夫が必要なのです。 今回は、「トラブル発生時のユーザーへの伝え方」について解説します。 トラブルが発生したとき、ユーザーが知りたい情報は何か トラブルが起きたとき、私たちがもっとも知りたい情報は何でしょうか。 例えば、乗っている電車が急
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く