徒然なるままに

結構面倒な処理 PHPでデータをDBから取得、表示する。この時ページネーションを行うのは、定番だけど…。 よく出てくる割には、案外面倒な処理。 Bootstrapだと、表示用のCSSは用意されているけれど、ロジックは無い。 フレームワークだと、ライブラリで持っていることもあるけれど、サクッと動く感じではない。 で、 DataTables を利用するという流れになるわけなんだけど…。 jQueryのプラグインで、tableタグをtheadとtbodyに分けて記述し、プラグインを呼び出すだけで、最低限の表の処理（ソートや絞り込み）を行ってくれる。 まあ、数百行程度なら、充分な速度で動いてくれる。 フレームワークで利用してみる 次のプロジェクトのために、色々とテストを行っている。 今回のDataTablesも、事前のテストの一環。 さて、フレームワークを使って、DBからデータを吸い出し、同様にDataTablesを利用するようにcodeを書きなおしてみる。 ところが、表示してみても、何も反応してくれない。（全く動作していない感じ） 項目表示の部分に△▽が表示されるはずなんだけど、これが出てこない。 もちろん、検索窓も、表示件数の処理も…。 なぜだ〜。 ということで、基本に立ち返りサンプルコードでテスト。 うむ、問題なく動作している。 と、ここまで作業して気づいたことがある。 テーブルを出力するページは、ひな形classを作っておいて、コンストラクタでオブジェクト生成している。ページごとに異なる部分だけ、オーバーライドするようにしているのだけれど… DBからデータを引っ張ってきて表示する時に、1列余分に追加して表示していた。 （表示・編集・削除のアイコンを付加していた） この時、最上部の項目を出力していなかった。<th></th>が1つ不足している状態。 図のように「編集」という文字を出力するように付加してみたところ、DataTablesがちゃんと動作してくれた。 当たり前といえば…当たり前。 データをソートさせる列の列名が存在していないので、エラーを起こしているのだった。 う〜む、こんなところで躓くとは、疲れてい

Ubuntu Oneって便利だったんだけど… Ubuntuを使ったことがある人は、一度は目にしているだろう標準サービス。 Dropboxのように同期型のクラウドサービスで、無料で2GBまで利用でき、OSに標準で入っている。 特に開発などしていると、Virtualboxや実マシンで何度もインストールしたりする場合に、とても重宝していた。 容量は2GBと少なく見えるけれど、OS自体が4GBもあれば充分稼働できる訳で、2GBという容量は充分すぎる。 予め、必要なツールやら設定ファイルなどを、UbuntuOneにコピーしておけば、インストール後ちょいちょいとコピーすれば、環境設定終了という感じで利用していた。 実機で開発したソースや、データなんかもローカルでUbuntuOneのフォルダにコピーしておけば、別の環境でバックアップ可能だし、文書や写真などを置かないと決めておけば、使い勝手はもの凄くよろしい。 大量のデータを移すのなら、Dropboxなど他のサービスを併用すれば良いだけだし、USBメモリやネットワーク経由でのコピーだって普通にできるわけで、それ程容量で困ったことはない。 でも、この４月にCanonicalはサービス終了のアナウンスを打ち出した…。残念。 しかも、終了期限は６月末。 これまでに、データは退避してくれとな。 Canonicalからメールがきた 終了のアナウンスは知っていたし、一応データはすでにバックアップしてあるので、問題はないのだけれど、親切にメールが届いた。 As previously announced, the file services for Ubuntu One have been discontinued. Your data is available for download until the end of July - if you haven't taken action already, you need to do so now in order to ensure you have a copy of all your data. In order to make it easy for you to retrieve all of

前回からの検討内容… DBを使ったアプリを作成する依頼があったので、内容を検討。 ターゲットとなる環境が厳しいので、いろいろと検討し、そろそろ決めることにした。 クライアントが古めで、アプリを入れて動かすのは故障時のリスクが高すぎる。 何せ外部に接続していないXPマシンが1台含まれており、メモリが512MBと超遅め。 壊れるまで使いたいという希望。 3台のクライアントで利用するのだけれども、扱うデータは担当者別で同時に同じデータを触ることはない。 要はアプリは1種類で、データは3種類になるという縛りがある。 そのうちの1台が古いXPということなので、最低のマシンで動作するようにしないといけない。 そこで、当初LibreOffice上のBASE+マクロ（BASIC）で構築しようと思ったけれど、XPマシンに入れて快適に動きそうにない。 VB or VC# or etc.+SQLiteも検討したが、Microsoftに縛られたくない。 ということで、Linuxサーバ（内部向け）の上で、SQL+PHPで構築して、ブラウザで利用という事で進めることにした。 テスト環境を準備 通常なら、Virtualboxでサーバを構築して、その上で作業をするのだけれど、今回は14.04が出たばかりなので、検証を兼ねて14.04にUpgradeしたノートPC上を作業環境にしてみる。 まずは、apacheのインストール。 $ sudo apt-get install apache2 動作確認で、開いてみると「お！ぉぉ！！！」今までの殺風景な it worksではなく、洒落た画面になっていた。 ついでに、Firefoxも最新のものに更新したので、chromeみたいなタブになっていて、何だか違和感ww 一応スクリーンショットを撮ってみた。 ぱっと見た感じはchromeのようだけど…。確かにFirefoxなんだよね〜。 検索窓が別に用意されているけれど、アドレスバーの欄に入力しても検索してくれて変な感じ。 続いてphpのインストール $ sudo apt-get install php5  本当に、楽になったもんだ。依存する必要なモジュールは勝手に入れてくれるし…。

3.9への更新案内が来た… これまで、マイナーアップデートは自動で実施してくれるので、何もしなくてよかった。今回は3.8系から3.9系へのメジャーアップデートなので、手動で指示をする必要がある。 まあ、いつも何も考えずに実行していて、問題がなかったので、安易に実行したら…。 通常なら、メンテナンスモードからすぐに復旧するはずなのに、一向に戻ってこない。 サイトにアクセスしても、メインテナンスモードである旨が表示されるのみ…。 ググると、「.maintenance 」を削除することで、一時的にメンテナンスモードを解除できると書いてある。 やって見る価値はある。 そして、アクセスするとwarningとエラー吐きまくっている。 まずい！！ これが、お客のwordpressではなかったのが、不幸中の幸い？ Warningはとりあえず、置いといて…。最後のErrorは「Fatal error: Cannot redeclare _relocate_children() (previously declared in /export/sd08/www/jp/r/e/gmoserver/7/2/アカウント/ドメイン/wordpress-3.5-ja-jetpack-undernavicontrol/wp-admin/includes/post.php:863) in /export/sd08/www/jp/r/e/gmoserver/7/2/アカウント/ドメイン/wordpress-3.5-ja-jetpack-undernavicontrol/wp-admin/includes/deprecated.php on line 1190」 となってますゎ。 背中に冷や汗が…。 ダッシュボードにも入れないので、再度updateと言うわけにもいかず…。 まずはバックアップ 多分、プラグインが上手くいかなかった様子。 ほとんどpluginを入れてない別のサーバで試すと、すんなりと更新ができた。 （この状況で試すのはある意味、勇気がいるんだけど） FTPは使えるので、一旦全コピー。どこまで更新作業が終わっているかわからないけれど、何とかしたい。 修復作業は以下の

テキストブラウザを使おうと思って… そもそも、変更したサイトを確認する意味で、テキストブラウザを使おうとしていた。 いつもならLinux上で操作するのだけれど、VirtualBoxを起動するのが面倒なんて思い、Mac上でも動いたはずとかすかな記憶を頼りに動かそうとした。 iTermを開き、 $ w3m www.********.com と。 すると、入っていないよ、というので入れた方が早いなと思いインストールすることにした。 $ brew update fatal: unable to access 'https://github.com/mxcl/homebrew/': SSL certificate problem: Invalid certificate chain Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master まずは、updateをしようと思ったら、いきなりエラー吐いてますやん。 操作手順を間違えたのかと、思い、確認してみる。 $ brew home http://brew.sh/index_ja.html を確認するが、特に問題はない。 最下行の「さらに詳しいドキュメント」からgithubのwikiを見ようとすると、証明書の警告が表示されて、開くことができない。 先のエラーもgithubだったし…。 う〜む、最近gitを見に行っていないので、仕様が変わったのか？証明書のエラーっぽいし…。 何だか、おかしい感じ。 こんな画面は、これまでに見たことがない。 アドレスバーから、情報を見てみると、図のような証明書に関してエラーを吐いている。 念のため、Firefoxでも確認してみたが、同様に開くことはできない。 つまり、マシン（ネットワーク的な）の問題っぽい。 以前は、見ることができていたし、この所納品までは環境を変えたくなかったので、新しいソフトは入れていないので、考えられるのはアップデートくらいか…。 ググってみる これは、他でも起きているに違いないと思ってググってみたら、すでに解決策まで提示されていた。

今さらEUC_JPって感じだけど すでにサーバ環境がUTF-8をデフォルトとするようになって、随分経っているので必要となるケースは少ないんだけど、今回はハマりました。 通常であれば、UTF-8でDBを構築していけば、特に問題もなく引っかかるようなところは何もないのだけれど…。 サーバの移行のため、仕方なくEUC_JPを使うことに。 旧データベースは、プログラムもEUC_JPで構築されている。 プログラムの書き換えは動作検証に時間がかかるので、そのまま動かしたい。 まぁPostgreSQLは文字コードを選べるので、問題ないだろうと…。 サーバにPostgreSQLをインストール これは問題なく、いつも通りapt-getで入れてオシマイ。 何も引っかかるところはありません。 ついでに、phppgadminも入れておく。 これで作業が簡単になる。 旧サーバにも入っているので、確認がしやすいですな。 若干、バージョンが異なっているので、その点だけ要注意と。 さてphppgadminを使ってDBをEUC_JPで作ろうとしたら、上手くいかない。 createdb: database creation failed: ERROR:  encoding EUC_JP does not match locale en_US.UTF-8 見慣れぬエラーですね…。しかもDBは作成してくれない。 何か操作を間違えたのかと、見直すが、特に手順に問題はない。 「ERROR:  encoding EUC_JP does not match locale en_US.UTF-8」でググってみると 、最初に答えが見つかった。 「 名称未設定：Ubuntu12.04LTSのPostgreSQLでEUC_JPのデータベースを作る 」とまんま同じ内容だった。 これによると、 createdb -T template0 -E EUC_JP --locale=C dbname と、localをCで作りなさいということらしい。 試しに、コンソールから試してみると、確かに文句も言われず作成してくれる。 phppgadminでもできるはず  この方法は、postgresユーザで作業するコンソ

途方に暮れる状況になった 保守に行った先でのこと。 毎日正午にMicrosoft Updateのチェックをするようにドメイン・コントローラ側で設定し、SWUSへ確認に行くようにしてある。 いつも、ほぼ問題なく更新がなされている。たまに使用していない期間の長いマシンがあったりして、更新が滞る程度のものだ。 利用している事務のおばちゃんが「このところ毎日お昼に更新がかかって、再起動するんだけど、何とかならないか？」というクレームだった。 毎日は大げさだろうと、他の設定を終えた後に確認に行く。 定時を過ぎているので、担当者はすでに帰宅済み。 まあ、確認しておこうと、電源を入れ、Administratorでログオン。 Microsoft Updateで更新を確認する。 確かに、1個未適用のものが存在する。手動で更新してみる。 更新終了し、再起動。 再度、ログオンし、Updateを確認する。ホホウ、さっきと同じ更新が出てくる。 確かに、おばちゃんの言う通りだ。これが毎日続くと腹立つわな〜と思いつつ、調べて見る。 「該当の更新はKB2862330だ」マイクロソフトのKB（ナレッジベース）を見に行くと、http://support.microsoft.com/kb/2862330 USBドライバのセキュリティUpdateらしい。10月8日に出ている。 しかも、「2894518 複数回の再起動が必要なソフトウェア更新プログラムのために、構成マネージャー内でタスク シーケンス エラーが発生することがある」なんて書いてある。 ひょっとして、これか？と思い、2度ほど更新を行ってみるが、一向に変化なし。 そこで、Googleに頼んでみる。 すると、「 KB2862330が繰り返し何度も表示される 」なんてページをコミュニティに見つけた。全く同じ症状じゃないか。 この内容によると、 Microsoft Fix It! を適用することで治ったと言うじゃないですか…。 このページで「今すぐ実行」を選択すれば、作業してくれるらしい。 ということで、実行。 エラー項目が見つかり、完了の報告が出る。 では、これでUpdateができるようになったの

久しぶりにpostgresqlを触る 以前は、postgresqlばかりだったんだけど、気付けば、最近はMySQLばかり触っていた。 今回依頼のあった案件が、すでにpostgresqlで構築されているものをリプレースするという内容。そのため、自鯖にコピーを作り、開発をすすめることにした。 postgresqlをインストール。 これは、何も問題ない。 $ sudo -s # passwd postgres # sudo - postgres ここまでは、問題ない。 $ sudo apt-get install phppgadmin 手作業での設定は大変なので、GUIツールを入れて利用する。 まぁ、多少の設定は必要だけど、ほとんど何もない。 ローカルIPからの接続を許可する程度。 ブラウザでアクセスする。 http://localhost/phppgadmin はい！OKと…。さすがにあっけない。 バックアップから再構築 お客さんのDBからdump.sql.gzを取り出す。 構造＋データなので、一気に復元できるはず。 同じ名前で、DB作って、インポートする。 インポートの場所は、最初戸惑ったけどSQLのところにあるんですねぇ…。（メモメモ） 参照から、先ほど取り込んでおいたdump.sql.gzを解凍してdump.sqlにしてあるものを指定。 実行を押すと…。 「サーバーが指定されていません」って？？？ 意味が分かりません。 /var/log/apache2/error.log を覗くも、有意義な情報は得られず…。 あれこれ試してみるけれど、dbサーバは動いているし、phppgadminも正常に動いている。 仕方なく、ググってみたら… phpPgAdminで「サーバーが指定されていません!」 なんてそのままのエントリーを発見。 もっと早く、調べればよかった。 php.iniの設定を書き換えろと。 post_max_size = 32M upload_max_filesize = 32M そういうことか。dumpしたデータが大きすぎて、uploadできていなかった訳だ。確認すると、dump.sqlは16.5MBほどある。 圧縮したデータは900KB弱

テストを繰り返していたら… 見出しのような「dpkg: 復旧不可能な致命的なエラーです。」と表示されて、apt-getもdpkgも中断するようになった。 その時のメッセージは、以下の通り。 (データベースを読み込んでいます ... 80%dpkg: 復旧不可能な致命的なエラーです。中止します:  パッケージ 'texlive-latex-extra-doc' のファイル一覧を読み込んでいます: 入力/出力エラーです E: Sub-process /usr/bin/dpkg returned an error code (2) synapticでもソフトウェアセンターでも、同じエラーで停止する。 根本原因は、「パッケージ 'texlive-latex-extra-doc' のファイル一覧」が読み込めないことらしい。 そこで、コンソールから、確認してみる。 $ sudo -s # cd /var/lib/dpkg/info/ # cat texlive-latex-extra-doc.list この時点で、入出力エラーを吐いてくる。 どうやら、ファイルが壊れたか、ディスクが逝ったか…。 とりあえず、texlive-latex-extra-doc.listをできるだけコピーしてみる。 # cp texlive-latex-extra-doc.list /home/userXX/texlive-latex-extra-doc.list そこで、コピーしたファイルを元の場所に上書きしてみる。 すると、apt-getなどの操作で、内容がおかしいと言ってくる。 当然、checksumを取っているので、整合性がないと言うわけだ…。 最後の手段 いろいろと検索してみるが、あまり良い方法が見つからない。 仕方なく、このパッケージがなかったことにしてみる。 # mv texlive-latex-extra-doc.* /home/userXX/ と一旦、移動させてみる。 そこで、apt-get updateなりしてみると、なんと…何事もなかったように振る舞う。 問題は、該当のパッケージを使っているものや、依存関係が発生した場合にどうなるかだけれども