なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
同期&待機 - Kazzz's diary
先日書いたエントリで、Androidのユーザインタフェースはシングルスレッドモデルを使用しており、UIスレッド以外のスレッドでウイジェット(GUI)を操作することは禁止されていることと、その回避策を書いた。 Instrumentationによるユニットテストでは直接ビューを触ってはいけない この例では単にUIスレッドと同期させておしまいにしたのだが、更に困ったことが発生する。 マルチスレッドで処理を書いたことのあるプログラマであれば、既に気がついていると思うのだが、この場合、 UIスレッド上での処理はHandler、ひいてはLooper上でディスパッチされてから処理されるため、処理を依頼した側(この例ではInstrumentationスレッド)からは終了を知ることができない。 つまりユニットテスト中で activity.runOnUiThread(new Runnable(){ @Over
throw Life - AndroidのHandlerとは何か？
AndroidでWeb APIを使う場合、マルチスレッドによるユーザビリティ向上を以前のエントリで説明しました。 AndroidアプリのUIはシングル・スレッド モデルです。 単純にマルチスレッドにしてUIの操作をしてしまうと、CalledFromWrongThreadExceptionでアプリがダウンしてしまいます。 これを回避する仕組みがHandlerです。 Handlerの仕組みを簡単に説明しようと思ったのですが、 またもや長くなってしまったので、先にまとめます。 AndroidのUI操作はシングル・スレッド モデル ユーザビリティ向上の為にはマルチスレッドが必要 Handlerで実現 Handlerを使わない場合に起きる例外は実行スレッドのチェックで発生 Handlerを使うと、UI Threadの持つキューにジョブを登録できる キューはUI Threadにより実行される
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
