Jenkins 復旧のためにこれを追いかけようとしていますが、GlassFish のソースが大きすぎてまだ手が回っていません。
投稿者: Kaz Nishimura
GlassFish アップデートで障害発生
このサイトで稼働させてきた GlassFish 4.0 を新しい 4.1 にアップデートしたら Jenkins が動かなってしまいました。
GlassFish 4.0 は 4.1 のスナップショットより不安定だとか話があったので、Update Tool を使って 4.1 にアップデートして起動したら…動かない…あれ?
そんな訳で、コンフィギュレーションをゼロから作り直したり、必要もないのに (1台でw) クラスターにしていたのをシングル サーバーに変えたりとか、試行錯誤してみた結果、WordPress は復旧したものの Jenkins はどうやっても初期化エラーで動かないという問題が解消できませんでした。クラス ローダーの挙動に影響されてるように見えるんですがねえ。
会計ソフトを発注しました
以前に弥生会計を使った経験から個人事業用の会計 (青色申告) ソフトを発注しました。最近はクラウド ベースの個人向け会計サービスもあるんだけど、毎年約10,000円の支出になることを考慮すると、毎年の保守サポート料金 (最低9,720円 税込) と比較しても、購入してしまった方が有利だとの判断に傾きました。
QNAP の Google+ コミュニティ
前に書いた QNAP Turbo NAS に xllmnrd を載せる話に関連して、Google+ で QNAP のコミュニティをやってます。興味があればご参加ください。
Google Play ニューススタンドに対応しています
このブログは Google Play ニューススタンド エディションで読めます。モバイル デバイスに適したレイアウトで表示されますので、ぜひ一度お試しください。
パスワード管理のあれこれ
今や多くのインターネット サイトでユーザー認証でパスワード入力を求められる時代になってますが、安全のために同じパスワードを使い回すなと言われるものの、全く異なるパスワードをサイトごとに覚えられるほどの記憶力のない人は、自分なりにマイ ルールを作って覚えやすくしてたりすると思います。
しかしサイトによって許されるパスワードに制限があったりして、なかなかマイ ルールどおりにならなかったりもしばしばです。良くあるパターンは英数字で大文字と小文字は区別するのだと思いますが、たまに大文字と小文字と数字をそれぞれ1個以上入れろだの、さらに記号も入れろだのとか言われると覚えるのが面倒になってきます。全部記号入りにすれば解決するかと言えば、記号を拒否するところとか、挙句の果ては最長でも8文字しか使えなくて、セキュリティを軽視してるのかと言いたくなるところもあって、なかなか解決しそうにありません。
秘密の質問というのも実際上は追加のパスワードを設定するだけなので、有効かどうか怪しいものですし、信頼できるサードパーティに認証を委ねてしまうのも一つの手なのかとも思ったりしますね。
RAD Studio に対するスタンス
これまたどうでもよい話ですが、私の RAD Studio に対するスタンスについて釈明しておきます。
一応公言しているつもりですが、私はオープンソース推進派ですので、原則としてはオープンソースでないソフトウェア利用は避けたいと考えています。それではなぜ RAD Studio を使うのかといえば、見栄えのする GUI を簡単に作成できるオープンソースのツールに適当なものがなかったからに過ぎません。JavaFX があるじゃないかと指摘されるかもしれませんが、JRE への依存性を考えるとためらわざるを得ないというのが正直なところです。
RAD Studio でも Delphi ではなく C++Builder をメインにしているのも、C++ であれば別の環境への移植が容易だろうという判断によります。RAD Studio を利用する上では Delphi でやった方が簡単なことはいくつもあります (インターフェース定義等) が、ほかに Object Pascal の使えるオープンソースのツールがない以上は C++ 以外の選択は現在のところ考えられません。
そんなわけで、個人的に RAD Studio のコア部分についてはオープンソース化してもらえると、バグ修正などでフィードバックができるようになって大変ありがたいのですが、今の状況を見るとまずあり得ないでしょうねえ。
本の紹介『テスト駆動開発による組み込みプログラミング』
以前にも紹介したかなと思いつつ、テスト駆動開発 (TDD) の本です。この本は組み込みプログラミングに TDD を適用する手法を扱っていて、実機テストが十分にできないことによる品質の低下や手戻りに伴う遅延に対して、あらかじめテスト可能なコードを書いておくという一つの解を示しています。
手短に書けば、PC でテスト可能なように作っておけば、実機がなくとも論理的に明らかな誤りを早期に発見することができるので、実機テストへの依存を減らすことができるということですね。これを実際に実行できるプロジェクト チームが現実にどれだけあるのか疑問です。
PHP について
どうでも良い話ですが、私は個人的に PHP が嫌いなのです。それが Quercus で WordPress を動かしている一つの理由。
それでも WordPress を使う理由は、PHP 以外で書かれた WordPress に匹敵するソフトウェアが見つけられなかったこと。全くどういうわけか、広く使われている Web アプリケーションの多くが PHP で書かれているので避けては通れない。
避けて通れないなら、別の方法 (Quercus) を使ってやろうというのがせめてもの抵抗であるわけです。