Windowsのプロダクトキーが分からなくなり、再インストール時に困った経験はないだろうか。こうした場合、プロダクトキーを一発で表示してくれるソフトを使えばよい。 Windowsマシン、それも同じOSのマシンを複数台所持していると、どのマシンにどのプロダクトキーを使用していたか分からなくなることがある。複数台のWindowsマシンのうち1台を再インストールすることになった場合、どのCDとプロダクトキーを使うのか迷った挙句、うっかり使用済みのプロダクトキーを入力してしまうこともある。 →Windowsだけでなく、インストールしたソフトのプロダクトキーを調べるにはこちら インストール済みのWindowsのプロダクトキーを確認するには、レジストリの特定のキーを参照するといった方法もあるが、もっと手軽に確認するためには「Windows Product Key Viewer」を利用するとよい。このソ

食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな？とあれもこれもと手を出すうちに2，3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか？QAやテストやドキュメントなどはいりませんか？誰に承認をえるのですか？これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ

ログは、システムの障害解析（デバッグ）や運用モニタリングに使うことを想定して、コンピュータに発生したイベントの履歴を時系列に沿ってファイルに出力したものである。有用なデータではあるが、扱いにくい面がある。そのため、複数のログを突き合わせて分析するといった活用が難しく、従来はもっぱら一つのログを単独で利用するにとどまるケースが多かった。 扱いにくい面とは、例えば「ログを一括して処理するには対象ログを各サーバーから収集しなければならない」「ログはサイズが大きくなりがちなので収集する場合は一部を抜き出すなどの加工が必要」といったことである。ログに新たなデータが書き込まれた際に、それを即座に取り出す手段が用意されていないこともそうだ。 こうしたログの扱いにくさは、「ログ収集基盤」と呼ばれるソフトウエアを使うことで克服可能である。ログ収集基盤は、複数のログを結び付けて分析する際などに必要な、対象ログ

想定サーバー apl(収集サーバー) fluentdを起動した集約サーバー ログの保存やグラフを表示するサーバー(Growthforecast使用) 流れ aplサーバーからアクセスログをfluent-agent-liteで収集、fluentdを起動しているサーバーに受け渡してログのパース、情報の整形、グラフ表示サーバーに送信 収集サーバー cd git clone git@github.com:tagomoris/fluent-agent-lite.git sudo mv ~/fluent-agent-lite /usr/local/src/ cd /usr/local/src/fluent-agent-lite sudo ./bin/install.sh sudo vi /etc/fluent-agent-lite.conf TAG_PREFIX="apache" LOGS=$(cat

以下のような、サーバ構成でWebサーバのログを収集したいと考えたとします。 デプロイなどの関係上、設定ファイル（configファイル）はサーバごとに変更したくないという場合があります。 同じ、local6.info でログサーバに投げるため、通常ログサーバ側では同じログファイルに保存されますが、ホスト名などでフィルターをかければログファイルを分けることができます。それをやってみます。 転送元サーバの /opt/syslog-ng/etc/syslog-ng.conf （ホスト名:web-a、web-bともに同じです） /opt/syslog-ng/etc/syslog-ng.conf source s_local { file ("/proc/kmsg" program_override("kernel: ")); unix-stream("/dev/log"); internal();　

整理するためのメモ。 よくある問題: プロジェクトごとの依存モジュールの管理 全環境共通でインストールするとモジュールのバージョンが分けられない local::libやcartonを使ってプロジェクト専用のインストール領域を作るのが良い しかし実行するPerlのバージョンが違うと動かなかったりするし だったらPerlそのものもプロジェクトごとに管理した方が 同一アーキテクチャの複数サーバにデプロイするときも1箇所で環境作ってディレクトリ丸ごとrsyncで済むし というわけでプロジェクト専用のPerlをperlbrewでインストールして使おう ビルドに時間かかったりもするけどまぁ最初の一回だけだし我慢 手順 既にperlbrew自体は標準の方法でインストールしておいていて使えてる、という前提で $ cd <PROJECT_ROOT> $ export PERLBREW_ROOT=${PWD}

久しぶりにVMWare Playerを使いました。 個人としてVMWare Player 3あたりから何度も使ったことがありますが、企業人として使うとどういう制約があるのか、気になったので調べてみました。 2012.12.13 VMWare PlayerにWindows98を稼働させる手順を書きました。 VMWare Playerを使ってWindows98を稼働させる手順～シリアルポートとかパラレルポートとか 2014.04.12 コメント内容を反映しました。 VMWare Playerの商用利用について VMWare Player 5の画面タイトル部に「非営利目的の使用のみ」と表記されています。 あれ、WorkStation購入しないといけないのか？と思い、調べてみたところ、VMWareに直接確認されたユーザさんがいました。 VMwarePlayerの「非営利目的の使用（商用利用）」はど

VMware Playerは当初より「非営利目的の使用のみ」利用可能である。最新版のVMwarePlayer 5.0では、これがWindowのタイトルに表示されるようになった。 で、問題になるのが、この「非営利目的の使用のみ」とはどこまで指すのか？という点。いろいろ検索してみたりして、分かる範囲でまとめてみた。 コスミー報告書[社外秘] - VMware Player のライセンス（商用利用について）では、 私が知りたいのは以下だ。以下が商用利用に当てはまるのか否か。 ①会社の業務における作成するプログラムのテストをゲストOSで行う。 ②会社で個人の事務作業に使う。 ③個人事業主がプライベートで使う。 さんざんWebで検索したが、上記のEULAを読み解いたり、FAQの文言から推察したりではっきりした答えは分からなかった。 誰かサポートに聞けよ！と思ったが意外に誰もいない。（聞いたけど公開し