約 2,289,365 件
https://w.atwiki.jp/conn/pages/20.html
エミュレーターでも実機でもデバッガが使えるので、ログ出力の意義をあまり感じない。 実機でアプリを実際に使ったとしても、ダウンロードされたアプリが出したログを開発者が確認できるわけでもないのであまり意味がないかもしれない。 どうせやるならばアプリで例外をキャッチした時点で、ダイアログを表示し開発者にトレース情報をメールなどで送りつけるよう促すのが効果的なのではないだろうか。うーん……ログの意義はやはり感じ取れない。 とはいえ、ログはアプリケーションの基本なので一応は動作を確認し、情報をまとめておく。 情報源 全ての本家の情報。英語です。 http //developer.android.com/tools/debugging/debugging-log.html http //developer.android.com/reference/android/util/Log.html http //developer.android.com/tools/help/traceview.html ログレベル DEBUGログは開発時のみ出力されるログです。実際のアプリに必要のない開発用のログはDEBUGレベルで出力しましょう。 ログレベルの解釈は人によって微妙に変わってきます。 以下に、一般的なログレベルの分け方を優先度順に表にします。 ASSERT ERRORよりも更に高いレベルのエラー。使いどころが分からない ERROR 通常のエラー。アプリケーションの特定の機能が使えない状態や、特定の操作がエラーによりキャンセルされた場合など WARN 警告。アプリケーションは利用できるがERRORを起こす可能性があったり、操作が完了されたものの不備がある可能性など INFO 単なる情報。起動、停止などを記録したりする。アプリケーションの動作に悪影響を及ぼすことはない DEBUG デバッグ情報。開発時のみに使用するログ VERBOSE 詳細な情報を出力する。開発時のみに使用するログ VERBOSEはDEBUGログよりも更に低いレベルで、開発時以外のコンパイルからは除外される。DEBUGはコンパイルに含まれるが、機器のログ出力レベルがデフォルトではINFOのため設定を変更しない限りは出力されない（ただし、ちゃんとisLoggableを評価してる場合に限る）。 ログ出力処理はアプリに非常に負荷がかかる。そのため不用なログ出力は控えるのが良い。 またif文でisLoggableを使用しログ出力の要否を確認することがshouldされている。isLoggableを評価しない場合、ログ出力レベルの設定に関わらずDEBUGログまで出力されてしまうようだ。 ログの確認方法 LogCat Eclipseからログ出力を確認するにはLogCatを使用するのが便利。 Eclipseのメニューから「ウインドウ」＞「ビューの表示」＞「その他」＞「Android」「LogCat」で開くことができる。 ワークスペース内のプロジェクトが出力するログをLogCatで確認する場合は、設定の変更が必要。 Eclipseのメニューから「ウインドウ」＞「設定」を開き、「Android」＞「LogCat」を選択し、そこで「ワークスペース内のアプリケーションからのメッセージのために logcat をモニターする」にチェックを入れる。 優先度の設定は、その優先度以上のログが出力されるとLogCatビューへの表示を開始し、フィルターを追加し該当プロジェクトのみの分を表示する仕組み。最低の優先度「VERBOSE」を指定すれば良い。仮に「ASSERT」を選択すると「ERROR」や「DEBUG」のログ出力ではキャッチされず、一切ログが表示されなくなる。 他のホームページなどの情報によると、これとは違う情報が書かれている。バージョンによって変わってくるのだろうか。悩ましい。 コマンドラインからlogcat コマンドラインから ADB を使用し logcat を実行する。 adb logcat と実行するとログが流れるが、ここにはEclipseから実行したプロジェクトのログは表示されない。 正しくは、 adb -e logcat もしくは adb -d logcat を使用する。「-e」が仮想Android端末、「-d」がUSB接続の実機。 また adb devices adb -s XXXXXXX logcat デバイスのシリアルを「devices」で確認し「-s」スイッチに続いてシリアルを指定することで、対象の端末分のみのログを表示することができる。 ログの出力方法 ログを出力するにはAndroid.util.Logクラスを使用する。 importするだけで使用可能になる。 ログレベルごとにメソッドが用意されており、ASSERTを除き、それぞれのレベルの頭文字がメソッド名になっている。 ASSERTレベルの wtf は、どうやら”What a Terrible Failure !!”（なんて不様な失敗だ！）の略らしい。 ASSERT wtf ERROR e WARN w INFO i DEBUG d VERBOSE v ログ出力メソッドを呼ぶときに必ず指定するタグだが、これはどれがログを出力したのか識別する文字列で、半角23文字以内で任意に設定する。 それぞれのメソッドには、 タグとメッセージを指定する タグとメッセージと例外オブジェクトを指定する ２種類が用意されている。 またwtfには、タグと例外オブジェクトを指定するものもある。 以前は日本語のログを出すと LogCat で文字化けしたらしいが、自分の環境では大丈夫だった。 例 String logtag = "HelloAndroid"; Log.i(logtag, "This is INFO メッセージ"); Log.d(logtag, "This is DEBUG メッセージ"); if( Log.isLoggable(logtag, Log.DEBUG) ) { Log.d(logtag, "This is DEBUG メッセージ if isLoggable(DEBUG) = TRUE"); } このコードを、特に設定を変更していない仮想Android端末で実行すると、上の２つだけが出力される。 デフォルトのログレベルはINFO。だが上のDEBUGメッセージは、ログレベルのチェックをしていないので出力される。 下のDEBUGメッセージは、ログレベルのチェックをしているので正しく出力が抑止される。 いちいちif分で囲むのも面倒なので、Logをラップしたクラスを作れば良さそうだ。 DEBUGログに関しては、isLoggableで評価するより、定数を評価する形にしたほうがコンパイル時にコードごと除去されるので、そっちの方が動作は軽くなりそうだが、未確認。
https://w.atwiki.jp/wixwiki/pages/37.html
WindowsInstallerは非常によく出来ており、何か想定外のことが起きたとき、必ず起動前の状態に戻してくれる。 例えばインストールの最中に、何らかのサービスを登録に失敗した場合、そこまでに配置した様々なリソースを 全てもとの状態（つまりインストール前の状態）に戻してくれる。WindowsInstallerによるインストールでは、 基本的に（カスタムアクションを除き）全て成功するか、全てを無かったことにするか、はっきりしている。 さて、問題なく動作するインストーラMSIファイルならよいだろう。自分が試しに作ってみたインストーラなどは、 動作しないことが多々ある。何か問題が起きて、インストーラが必ず途中でロールバックしてしまう、といった ような場合に、何を基にしてデバッグすればよいだろうか。 基本的にWindowsInstallerは標準的な動作（MSIファイルをダブルクリックして起動する）ではログなどが出力 されることはない。（インストーラー内部で個別に作りこんでいれば話は別だが、WindowsInstallerそのものが ログを出力することはない）WindowsInstallerがログを出力するようにするためには、WindowsInstallerの プロセス起動時にログを出力するようなオプションを与えればよい。 具体的にはコマンドプロンプト等で msiexec /i Hoge.msi /lv* hoge-install.log とすることで、Hoge.msiファイルを起動し、デバッグログを hoge-install.log に出力することになる。 （このオプションはWindowsインストーラのバージョンによって異なる可能性がある。私が確認したのは V3.01.4000.1823 だ。そのほかのWindowsInstallerのオプションについては、msiexec /? として自身で確認してみてほしい） visitor - (today - ) Author nagatyo コメント （注：コメントは管理人が適宜消去する場合があります） 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/iconix/pages/17.html
ICONIXプロセスの流れ 1.ドメイン分析プロジェクトの用語を洗い出し、用語を統一します。（同じものを表す用語が2つあったりしないように） クラス図をとても単純にしたものを使って、用語同士の関係を見やすく図で表します。 予備設計過程で更新するので最初は2時間以内に作成します。 2.ユースケース記述要求を満たすための振る舞いを具体的に記述します。（AがBを要求するとCはDする、等） 晴れの日のシナリオ（正常系）と雨の日のシナリオ（異常系）を全て見つけ出すように書きます。 図を使ってユースケース同士の関係を明確にします。 3.ロバストネス分析3つのオブジェクトを使って簡単に図を描きます。 ユースケース1つにつきロバストネス図を1つ描きます。 図を描く過程で、見落としていた振る舞い、データ、インターフェイスなどを見つけ出します。 見つかったものは1のドメイン分析、2のユースケース記述に随時追加していきます。 ロバストネス図をレビューし、要求→ユースケース記述→ロバストネス図の対応が取れていることを確認したら予備設計完了です。 4.シーケンス図1つのロバストネス図に対して1つのシーケンス図を描きます。 ロバストネス図で見つけ出したオブジェクト（バウンダリ、エンティティ）をシーケンス図のオブジェクトにします。 シーケンス図を描く過程で、どのオブジェクトにどの操作を割り振るのか決定します。 5.クラス図ドメイン図に属性と操作を付加し、名前を付けて作成します。 詳細設計のアウトプットとなります。 6.コーディング 7.テストロバストネス図のコントロールオブジェクトをそのままテストケースとすることが出来ます。
https://w.atwiki.jp/freememo/pages/92.html
概要 プロセス生成関数CreateProcess() コメント 概要 OSからメモリ領域などの割り当てを受けて処理を実行しているプログラム。 TOP プロセス生成関数 CreateProcess() 例）メモ帳起動する場合 TCHAR cmdline[] = _T("notepad.exe"); STARTUPINFO si; ZeroMemory( si, sizeof(si)); si.cb = sizeof(si); PROCESS_INFORMATION pi; ZeroMemory( pi, sizeof(pi)); if ( CreateProcess(NULL, cmdline, NULL, NULL, FALSE, 0, NULL, NULL, si, pi)) { // メモリリークの原因になるので、不要ならば、すぐクローズする。 CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } TOP コメント 名前 コメント TOP
https://w.atwiki.jp/iconix/pages/12.html
ICONIXプロセスとは何か 機能要求から ①簡単な図で ②他人がトレースできる形で ③漏れ、抜けのないように 詳細設計を導くやり方。
https://w.atwiki.jp/dai1357/pages/37.html
データベースの起動 ｜初期パラメータ?の読込み ｜SGA?の割り当て ｜バックプロセス?の起動 └－インスタンス起動－－－－－－ ｜制御ファイルの読込み └－データベースのマウント－－－ ｜データベースの整合性チェック ｜インスタンス・リカバリ(必要な時のみ) └－データベースのオープン－－－ 初期パラメータの読込み ・初期パラメータファイル または ・サーバー・パラメータ・ファイル の読込み
https://w.atwiki.jp/ora_tips/pages/12.html
DBの起動/停止 起動 １．nomount 【状態】 データベースファイルのマウント、オープンは行わない。 初期化パラメータファイルを読み込み、SGA バックグラウンドプロセスを起動後 アラートログファイル トレースファイルをオープンする。 【出来ること】 データベース作成 制御ファイルの再作成 初期化パラメータファイルの読み込み順 ①spfileSID.ora ②spfile.ora ③initSID.ora ２．mount 【状態】 初期化パラメータのCONTROL_FILE初期化パラメータで指定された制御ファイルをオープンした状態。 制御ファイル以外のデータベースファイルのマウント、オープンは行わない。 インスタンスとデータベースを対応つけをした後、制御ファイルをオープンし、データファイルとオンラインREDO ファイルの名前を取得する。 ※データファイルとREDOログの存在有無はチェックしない。 【出来ること】 オンラインREDOログファイルアーカイブの無効、有効化の設定 データベース作成 制御ファイルの再作成 ３．open（起動デフォルト） 【状態】 データベースユーザが接続して、利用できる状態。 制御ファイルから取得した情報をもとに、データファイルと、オンラインREDOログファイルをオープンする。 データベースの整合性をチェックし、必要であればSMONがインスタンスリカバリを行う。 【出来ること】 データベースアクセス 停止 １．normal すべてのDBユーザの接続を終了を待ってからクローズ、ディスマウントする。 チェックポイントが発生し、データベースキャッシュ及びオンラインREDOログバッファ内の情報が Diskに書き込まれる。次回起動時のインスタンスリカバリ発生しない。 ２．TRANSACTIONAL すべてトランザクションが終了するまで待ち、クローズ、ディスマウントする。 １同様にチェックポイント発生する。 ３．IMMEDIATE 進行中のトランザクション終了をまたずにクローズ、ディスマウントする。 １同様チェックポイントは発生する。 進行中のトランザクションはロールバックされる。 ４．ABORT 進行中のSQLが終了するのをまたずに即時終了する。 トランザクションのロールバックなし、チェックポイント発生しない。 次回起動時にインスタンスリカバリ実行される。 ※１～４共に新規接続受付不可
https://w.atwiki.jp/aster-infra/pages/205.html
システムの起動 システムが起動するまでの詳細な流れは、ハードウェアアーキテクチャによって違います。 今回は、x86アーキテクチャのコンピュータにおける流れです。 １、電源を入れるとBIOSが起動 ２、MBRに格納されたブートローダが起動 ３、ブートローダはカーネルをロードして実行する。 BIOS（Basic Input/Output System：入出力基本システム）は もっとも基本的な制御プログラムであり、基本的な入出力の管理を行います。 電源が投入されると、不揮発性メモリに格納されているBIOSが実行され、 下記のような作業を行います。 メモリのチェック ハードウェア設定の読み込み 起動デバイスのチェック 起動デバイスのマスターブートレコード内に格納されたブートローダを実行 マスターブートレコード(MBR) マスターブートレコードは、起動デバイスの先頭セクタです。 ここには通常、OSを起動するプログラムであるブートローダの一部と、 基本パーティションの情報を収めたパーティションテーブルが含まれています。 ブートローダ部分は446byte、パーティションテーブルは64byte、残りの2byteは 正しいブートセクタであるかを確認するマジックナンバーです。 ブートローダ 基本的にマスターブートレコードに格納される第一段階ブートローダと そこから第二段階のブートローダが呼び出されるというように分かれています。 マスターブートレコードの中に格納されるブートローダのサイズが制限されて、 ブートローダ全体を格納できません。 Linuxでよく利用されるブートローダには、GRUB(Grand Unified Bootloader)や LILO(Linux Loader)があります。 カーネルは組み込まれているハードウェアの検出、メモリのチェック、システムクロックの設定、 IRQの設定、ルートパーティションのマウント、最後にinitプログラム(/sbin/init)を実行します。 なお、カーネル起動中に表示される様々なメッセージは、起動後にdmesgコマンドで確認することができます。 initプロセス カーネルによって最初に起動されるプロセスがinitです。 initのPIDは『１』です。 initは、設定ファイル/etc/inittabの設定に基づき、様々な起動処理をする。 /etc/inittabファイルは、ブートアップ時や通常運転中にどのようなプロセスを起動するのかを指定するファイル 下記が/etc/inittabの書式です。 ID：ランレベル：アクション指示子：処理 IDエントリを識別するためのID（1～4文字）を指定する ランレベル～そのエントリが処理を行うランレベルを指定 アクション指示子～どのようなタイミングで処理を行うのかを指定 処理～initが実行するプロセスを指定 アクション指示子 boot ～ システム起動時に実行され、プロセスが終わるのを待たずに次の処理をする bootwait ～ システム起動時に実行され、プロセスが終わるまで次の処理を待つ ctrlaltdel ～ Ctrlキー、Altキー、Deleteキーが同時に押されるなど、SIGINTがinitに送られた時に実行する initdefault ～ デフォルトのランレベルを指定する once ～ 指定したランレベルになった際に一度だけ処理され、プロセスが終わるのを待たずに次の処理を行う。 respawn ～ 指定したプロセスが終わり次第再起動される sysinit ～ システム起動時に、bootやbootwaitより先に実行される wait ～ 指定したランレベルになった際に一度だけ実行され、プロセスが終わるまで次の処理をしない
https://w.atwiki.jp/bresson/pages/16.html
起動編 起動前の準備 FINAL FANTASY XI Confing を起動し、□ ウィンドウモードで起動する のチェックを外してください。 普段フル画面でプレイしている人は、この必要はありません。 インストール後にできたwindower.exeを実行してください。 スタートメニューに登録した場合はそこからでもかまいません。※セットアップ用とアイコンが同じなので間違わないように注意してください。 アップデートがあれば自動的に更新され次の画面が表示されます。 +をクリックしてゲームウインドウのサイズなどの指定をした新しいプロフィールを作成します。 名前と設定内容を変更します。 タイトルを「お試し用」とし、Japanを選択、画面サイズを1366*768（16：9）、ウインドウモードをWindowとしました。 ※FFXIのゲーム内設定は4：3、16：10、16：9です。縦横比に注意。 Game設定は初期値を使用、後で必要があれば変更しましょう。 左上の←をクリックで、スタートメニューに戻ります。 新しい設定『お試し用』が作られました。 右下→の左隣にある「ピン」のアイコンをクリックすることで作成したリストへのショートカットを作成できます。 FFXIを起動する。 リストを選択し右下の矢印で進みます。 Windowerのロード画面が表示され、POLが起動します。 いつも通りにログインしてください。 ※セキュリティトークン、ソフトウェアトークンによる認証をお勧めします。 ショートカットまたは、Windowerを直接起動し、これを繰り返すことで、複数のPOLを起動することが出来ます。 ログインすることで、FFXIの複数のアカウントを1台のPCで操作することが出来ます。 また、アカウントごとに窓のサイズを大小変えて起動することも可能です。 ※起動できる数の限界を試したことはありませんが、複数起動しても大きく負荷がかかっているようには感じません。 理由は、多くのプロセスを共有しているからではないかと思います。
https://w.atwiki.jp/sakawork/pages/20.html
psコマンドとkillコマンドpsコマンドオプション よく使ったオプション例 killコマンド オプション psコマンドとkillコマンド psコマンド 起動しているプロセスを表示させる オプション オプション 内容 a 全ユーザーのプロセスを表示(Linux) f すべてのプロセスを表示(Solaris) u プロセスのユーザ名と開始時刻も表示(Linux) x デーモンなども表示(Linux) e 全プロセスの情報表示(Solaris/Linux) l 詳細情報を表示(Solaris/Linux) よく使ったオプション例 オプション 内容 ps -ef Solarisで全ユーザ・全プロセスを表示 ps -aux Linux(HPも同様？)で全ユーザ・全プロセスを表示 killコマンド 起動しているプロセスにSIGNALを送る kill (オプション) (プロセスIDorジョブ番号) の形式で実行（プロセスIDorジョブ番号）のプロセスにSIGNALを送る デフォルトはSIGTERM オプション オプション 内容 なし (プロセスIDorジョブ番号)のプロセスにSIGTERMを送る -n (プロセスIDorジョブ番号) (プロセスIDorジョブ番号)のプロセスにnのSIGNALを送る - シグナル (プロセスIDorジョブ番号)のプロセスにシグナルを送る -l シグナルリストを表示 シグナル（番号/略） シグナル 意味 1 SIGHUP 端末の回線切れ/TERMを閉じた場合に発生デーモンの再起動にも使用 HUP ハングアップ 2 SIGINT Ctrl+Cで割り込みが発生した場合に発生 INT 割り込み 3 SIGQUIT Ctrl+\で終了した場合に発生 QUIT 終了 4 SIGILL 命令により不正なメモリ領域にジャンプした場合や権限のない命令を実行した場合に発生 ILL 不正命令 5 SIGTRAP デバッグ機能を用いている時に停止機能でとまった場合に発生 TRAP トレース/ブレークポイントでのトラップ 6 SIGABRT プロセスがabort()を呼んだ場合に発生シグナルハンドラから戻った時点でプロセスは終了 ABRT プロセスの中断 7 SIGEMT エミュレーショントラップが発生した場合に発生 EMT エミュレーショントラップ 8 SIGFPE 浮動小数点演算でゼロ除算やオーバーフローした場合に発生整数演算でもオーバーフローした場合に発生 FPE 不動小数点例外 9 SIGKILL killコマンドで発生させるハンドラでキャッチしたり無視することはできない KILL 強制終了 10 SIGBUS 未定義メモリ領域へアクセスした場合に発生 brハンドラでキャッチしたあとの動作はシステム依存 BUS バスエラー 11 SIGSEGV 不正なメモリアクセスによるページフォールトで発生 SEGV セグメンテーション違反 12 SIGSYS セグメンテーションフォールト システムコールの番号や引数が不正の場合に発生 SYS 不正システムコール 13 SIGPIPE 読み手のいないパイプへの書き込みが起きた場合に発生デフォルトでは受信プロセスが終了 PIPE 不正なパイプ 14 SIGALRM alarm()によるタイマーがタイムアウトした場合に発生 ALRM アラーム 15 SIGTERM killコマンドがデフォルトで送るシグナルハンドラでキャッチしたり無視することが可能 TERM 強制終了 16 SIGUSR1 ユーザ定義のシグナル USR1 ユーザ定義のシグナル1 17 SIGUSR2 ユーザ定義のシグナル USR2 ユーザ定義のシグナル2 18 SIGCHLD 子プロセスが終了した場合に発生子プロセスの終了原因が1～6の番号として送られる CHLD 子プロセスの終了 19 SIGPWR 電源断/再起動した場合に発生 PWR 電源 20 SIGWINCH ウインドウサイズを変更した場合に発生 WINCH 21 SIGURG 非動機I/O機能で使用。ソケット上に緊急データがある場合に発生 URG 緊急データ 22 SIGIO/SIGPOLL ファイル記述子に対してfcntl()でシグナル発生を指示した場合に発生 IO/POLL poll可能イベント 23 SIGSTOP プロセスグループの実行中断のためのシグナルハンドラでキャッチしたり無視することが可能 STOP 実行中断 24 SIGTSTP Ctrl+Zでフォアグラウンドジョブを中断した場合に発生 TSTP 端末からの中断 25 SIGCONT SIGSTOPによって停止したプロセスの再開に使用それ以外では無視される CONT 再開 26 SIGTTIN バックグラウンドジョブが端末からの入力待ちで停止した場合に発生 TTIN 端末からの入力待ち 27 SIGTTOU バックグラウンドジョブが端末への表示待ちで停止した場合に発生 TTOU 端末への表示待ち 28 SIGVTALRM プロファイラで使用 VTALRM 仮想タイマのタイムアウト 29 SIGPROF プロファイラで使用 PROF プロファイリングタイマーのタイムアウト 30 SIGXCPU プロセス実行時間がある値を超えた場合に発生 XCPU CPU時間制限オーバー 31 SIGXFSZ ファイルサイズがファイルシステムの制限を越えた場合に発生 XFSZ ファイルサイズ制限オーバー 32 SIGWAITING WAITING 33 SIGLWP LWP 34 SIGFREEZE FREEZE 35 SIGTHAW THAW 36 SIGCANCEL CANCEL 37 SIGLOST LOST 38～ SIGRTMIN TMIN 39 SIGRTMIN+1 RTMIN+1 40 SIGRTMIN+2 RTMIN+2 41 SIGRTMIN+3 RTMIN+3 42 SIGRTMAX-3 RTMAX-3 43 SIGRTMAX-2 RTMAX-2 44 SIGRTMIN-1 RTMIN-1 45 SIGRTMAX RTMAX ※記憶から遠のいてしまっているため、思い出し次第追記 使った覚えのないシグナルが多い