月: 2017年2月

今日から、早くも４月から始まる新年度の準備として、アカウントの登録が始まりました。３月には、卒業した学生のアカウント削除もあるので、予め解っていることなら、異動の対応なども早めに行うようです。

以前、勤めていた会社では、たとえ１ケ月前に異動があると解っていても、正式な辞令の出る１週間前でないと異動に関わる情報を一切出せない方針だったので、アカウント登録やらパソコンの準備に苦労した覚えがあります。大学では、新しく着任する先生でも、事前にシラバスの登録が求められるようで、こんな早くから新学期の準備が始まっています。

卒業生については、在学中に使ってもらっていたソフトウェアの権利とかを抜く必要があり、名簿をつき合わせて確認します。それらは、卒業式後すぐに権利を開放する処理を行うのだそうです。その事前確認をやっているのですが、名簿を見て思ったことが。

入学時に作られた名簿から消えているアカウントがかなりある。４年前に入学した学生が６００名近くいたはずだが、そのうちの５０名を超える人のアカウントが既に削除されていた。それぞれ、いろいろな理由で途中で退学した人だと思う。実際、この１年に何人も退学しており、その度にアカウントを削除してきた。

芸術系の大学なので授業料が安いとはいえない。道具や材料にもお金がかかるので、大学では費用がかかる方かもしれない。家の都合で費用を払えなくなった人もいるようだ。さらに、自分が目指したものと違うと感じる人もいるだろう。

とはいえ、大学で何かを学んだと思うので、それを今後の生活に生かしてほしい、とつくづく思う。

ブログの更新をきれいに見せるページを作成しているが、その後の話。

表示するまでに当初 30秒ほどかかっていた処理が、10秒程度まで改善したのだが、まだまだ10秒というのは遅い。JavaScript で動いていた時は砂時計が回っていたのでで何かやているなと解るが、PHPだと読み込みに時間がかかっているように見てて、待つ時間が長く感じる。

ブログはWordPress だし、RSS の出力も WordPress の機能を使っているのだからWordPress を高速にすればいい。世の中には、KUSANGI というキットも販売されている（無償だったかも）ようなのでそこで使われている技術を使っていけば、そこそこ早くなるかもしれない。

Virtual Box に入った CentOS7 で、試しに PHP をキャッシュする仕組みを試しに入れてみて計測したところ、かなり効果が高い。これはいけるのでは、と思い本番環境に入るかどうか調べてみた。

実は、本番環境は、かなり古い。３月に入れ替えをと、お願いしているところ。もしかしたら、予算の都合で４月になるかも、と言われているがすぐにも入れ替えしたいような機種。
/proc/cpuinfo を見たら、CPU は Core2 duo だった。

model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz

このＣＰＵはノートＰＣ用のはず、なんていうのは無視するしかない。（薄い１Ｕタイプのサーバーは、ノートＰＣと同じような基盤で作られたのが多かったはず）

こんな世代のサーバーなので、入っているＯＳは、CentOS5系。さすがにデフォルトの PHP では WordPress が動作しないので、PHP 5.3 が導入されている。ということで、PHPでは古めのキャッシュ機能しか使えない。

データベースのMySQLももちろん古いバージョンということになる。 これでは最新の WordPress 高速化機能は使えない。

そのため、次の２つを適用することに。

・PHP の古いキャッシュ機能の apc
・MySQLのキャッシュ機能

まず、apc は php 5.3 の devel や pear をインスールして pecl install apc で簡単に導入できました。pear が普通に使えるのは便利。

MySQL は、簡単な設定のみ。読み出しだけで書き込みがめったにない　WordPress では、クエリーをメモリーにキャッシュするのは問題ないと判断。

ab コマンドで計測したら、グーグルで検索したサイトの ab コマンドの結果に比べて１桁小さいものの、改善が見られました。

でも、まだまだ遅い。
画像をたくさん使ったブログページがやたら遅いな、と感じたこともあるのですが、CPU がそもそも遅いので、手を入れてもこんなものか。最新の機種に交換できたらあの遅いページも、もっと使えるようになるのかな。

去年の12月までは JavaScript で動作していたが、Google API が利用できなくなり使えなくなっていたブログ更新の紹介ページ。PHP で作り直しました。

JavaScript と同じようなことをやればいいから２日もあれば、と思い始めたのですが、障害がありすぎて２週間近くかかっています。当初は、simplexml_load_file で簡単に持ってこれる予定だったのですが、完全に破綻。しかも、30秒近くかかる処理をどうやって短縮するか、という課題も。

simplexml_load_file は早々にあきあらめて、XML を文字列として受けり、XMLReaderで処理することに。さらに、使われているXMLの仕様の違いから、３パターンに対応するように、処理を複雑化。

そして、アクセス時間の短縮化に着手。
アクセス時間の短縮は、PHPの cURL ライブラリの curl_mukti 機能を使いました。いっきに32サイト分を管理している１台のサーバーにリクエストしたら、サーバーがダウンする恐れもあるので、同時アクセスを５つに制限するため、処理がまた複雑に。

しかも、CURLOPT_POST を ture にしないと XML を取得できないサイトがあることが判明。サイトによって ture にするしないのデータと条件を追加。さらに、CURLOPT_POST が ture だと HTML 形式に XML が埋め込まれた文字列になるので、加工が必要。さらに複雑に。

オリジナルのJavaScriptで書かれた HTML ファイルは、8kバイトほどでしたが、今回PHPで書いた版は、12kバイト。1.5倍に増えてます。それだけ複雑な処理になってしまった。
それだけ、Google API が優秀だったということかも。使えなくなったのは残念です。

Google のRSSのAPI廃止で、今、派遣先の大学で情報発信に使っているブログの更新状況が公式サイトでは見れなくなっています。

ネットでざっと見た限りでは同じ機能を PHP で簡単に作れそうでした。それで始めたのですが、予想外に手間がかかっています。まず、何がまずかったか。

・RSSのフォーマットは１つではない

ブログは WordPress だからと甘く見てたのですが、RSSを実装する方法はいくらでもあるようです。大学で使っているブログには、いろいろなバージョンの WordPress が使われており、プラグインも利用者が自由に決めています。そのせいでしょうか、確認した限りでは３通りのパターンがありました。

どうもよく知られているのが、「RSS2」というフォーマットを「Atom」というフォーマットの２つのようです。この２つには互換性がありません。

さらに、Atom の派生版があるようです。構造は、「Atom」のもののようですが、使われているタグが違っています。そのため、XML を読んだら、この３つの仕様に合わせて、内部を解析する必要がありました。

・とにかく遅い

Google API を使っいた時は、なんかもっさりしているな、くらいで済んでいたのですがPHP で毎回各サイトに　RSS の問い合わせを行うと、異様に時間があかります。20秒から30秒、画面が更新しないのはかなり問題かと。

PHP の内部の XML 化処理に時間がかかっているのか、と思ってsimplexml_load_file() からXMLReader に変えてやってみたのですが、それほど効果ｈありません。RSS を取得する先が32箇所というのがネックになっている、と思うのですが、今のところお手上げ。

どうも、cURL というライブラリを使うとアクセス時間が短くなるらしいのですが、今回は、うまく作れませんでした。マニュアルでは並列処理することで処理時間を劇的に短縮できるのだそうです。そのうち試してみるつもりです。

・仕様もちょっと問題が

JavaScript から PHP に作り直しているブログの更新を紹介するページでは、ブログに貼り付けられた画像を縮小して、サムネイルとして利用しています。この画像を切り出す処理も手間取った１つ。

ブログは WordPress で動いているんだからなんとかなると思ったのですが、 WordPress のバージョンの違いで、HTML のタグ内の記述が少し違っているます。HTML のタグ内を解析するライブラリも探せばいいもがあるのかもしれませんが、どうせ簡単な文字列のマッチングで画像の URL を拾ってＯＫ、という前提で始めたので、最初からガリガリ書いてました。

そしてこの処理で最後に困ったのは、src=./wp-contents/update …. を書かれたHTML。このパスの書き方は間違いなく WordPress ですが、相対記述の場合、URL を合成するのは面倒。私は、このケースでは記事の中の画像を利用するのをあきあらめました。

一応、テスト環境で動いていますが、あまりに遅いので、いまだに保留にしています。せめて、今の半分の時間で動いてくれれば、使えるレベルなのですが。

実は、MySQL に直接アクセスして最近更新のあった記事を調べた結果を表示するページが既にあります。このページはほんの数秒で表示してくれます。汎用性は落ちますが、こっちのやりかたで作り直すか。でも、別にいる管理者が簡単に、RSS で確認するページの追加や削除ができなくなるものダメだし。どうすれば、Google API を使っていた時みたいに、みんながハッピーになれるか、まだまだ思案中。

こんな２月になったやっと解ったのだが、派遣先の大学の活動を紹介するブログの更新状況を表示していたページが、Google Feed API を利用しており、１２月から動いていなかった。なんとも間抜けな話です。

言い訳すれば、ブログに関しては私が管理しているサーバーで公開しているので、何か不具合があればすぐに対応できるのですが、この Google Feed API を使ったページは、外部の業者が管理していました。

しかも、その業者はあくまでサーバーの管理でコンテンツはノータッチ。今の担当者は公式サイトは更新するものの、別の業者が作ってそれっきりの紹介ページがどうなっていたか知りませんでした。

幸い、サーバー管理を担当している業者が親切に Google Feed API が廃止になったからだと教えてくれたので、この件が発覚しました。以前は、更新のあったブログが一目瞭然だったのですが、今は、ただのリンクページに置き換わっており、どのブログが更新されたか、全くわかりません。

ということで、更新のあったブログを紹介するページがあってもいいのでは、と思い、PHP で作り直すことにしました。

ところが、なかなかうまくいかない。
RSSで持ってくるXMLの情報に統一性がありません。
この時点で、やっと、RSS1.0 、RSS2.0、atom という３つの仕様があることがわかりました。
それぞれに合わせて解析する処理を書く必要があります。

また、以前使っていたページは、更新のあったブログの最初の画像を縮小表示して見やすくしていたので、PHP でこれを実現しようとしたのですが、やっぱりうまくいきません。XMLのブログ本文を解析して画像ファイルを特定する予定だったのですが、HTMLの書き方に統一がないため、うまく画像だけ切り出すのにいろいろ指向錯誤するはめに。

ネットに情報が多いし、以前使っていた JavaScript は簡単に記述で実現しているから１日もあればできるだろう、くらいの簡単な気持ちで始めました。しかし、３日経っても、まだゴールが見えません。HTMLから画像を切り出す処理で、まだまだワーニングが大量に出てきます。１つ１つ潰しているのですが、HTMLの書き方って、以外と自由度が高いので条件分岐が増える一方。改めてＷｅｂブラウザのHTML処理エンジンの優秀さを実感してます。

たぶん、画像の切り出しがなければ、そんな手間はかからなかったかもしれませんが、それだとインパクトに欠けるし。世の中のエンジニアはどうされているのでしょうね。丹念にネットで調べていくと、いろいろ解りました。みんさん、やはり困っているようです。調べた結果、やはり丁寧に作っていくしかないようです。

ネットでざっとしらべたところ、PHP の simplexml_load_file() で　WorkPress の feed
を読み込めば簡単みたいによく書いてありますが、これはウソ。
日本の２バイト文字コードの都合で、これではXMLとして読めないことが多いようです。
WordPress を処理するなら、日本語の２バイト文字は避けられません。今回は文章は使わないので、ばっかりあきらめて、XMLの取り込みを優先しました。

最後は、ここを参考にさせてもらいまいした。

http://yznote.blog19.fc2.com/blog-entry-38.html
[PHP] PHP simplexml_load_string でパーサーエラー

http://q.hatena.ne.jp/1180743477
PHPで、RSS等のXMLを取得し、パースしています。

やっぱり日本語の２バイト文字を扱うのは難しいですね。

とはいえ、PHP で処理するのに約20秒もかかるので、このまま使う訳にいかず、今のところ
保留中。

このページに、一週間ぶりにアクセスできました。

WordPress 4.7 のセキュリティーホール騒動が始まって以来、全くアクセスできない状態で記事の投稿はおろか、ftp での過去の記事の退避などもできない状態でした。復旧してほっとしてます。

無料で使わせてもらっているのであまり文句は言えませんが、過去に何度も繋がらないことがあったので、またか、という感じです。しかし、ここは　PHP がかなり自由に使えるので便利なことから、他に移る気になれません。不便ではありますが、サービスが続くかぎり使わせてもらおうと思ってます。

それと、騒動が始まる直前に、WordPress は　4.7.2 にアップしてたので、私のこのサイトは被害にはあってませんが、ニュースを見るとかなりの被害が出ているようです。

155万サイトが改ざん被害、WordPressのREST API脆弱性を20のグループが攻撃、米Feedjit報告

155万サイト、という数字は、あまりに大きくて想像できませんが、フィッシングサイトに悪用されているらしいし、酷いことになりました。

フリーソフトなので自己責任とはいえ、今後はなんらかの対策が必要になるでしょうね。

記事の投稿ができるようになったので、このブログも徐々に更新していきます。

教室のテレビ画面にパソコンの映像が出ない、という問い合わせがありました。

派遣の先の大学は芸術系の大学ということもあり、パソコンで映像資料を表示してそれを学生に見てもらいながらといった授業が普通で、各教室にはプロジェクターや大型の液晶ディスプレイが設置されています。

狭い教室にも大型の液晶テレビが設置してあり、これに映像を写して授業を行っています。今日、こういった狭い教室で、パソコンの画面が液晶テレビに表示されない、という不具合がありました。

ケーブルを交換してみたり、入力端子を交換してみたのですが、やはりダメです。昨日はうまく出たのに、なんで？　と先生に聞かれたのですが、全く解りません。液晶テレビの入力切替を出すと、信号が来ているようですがさっぱり映りません。ところが、液晶テレビへの接続を、HDMI から VGA に交換したところ、映るようになりました。よく液晶テレビに VGA の端子が付いていたな、と実は驚いたのですが、とりあえずこれで授業はできたようです。

事務所に戻ってから、これは解像度の問題では、と思い調べました。使っていたのパソコンは、新しい MacBook Air だったので、パソコン側の液晶に表示している解像度と、液晶テレビの解像度が違っているかもしれないと思ったからです。そう思って調べた中に、液晶テレビの解像度は、DVD/BDプレイヤーに合わせてあるのでＰＣの解像度の全てに対応している訳ではない、という記述がありました。しかし、昨日はちゃんと映ったそうなので、これが原因ではありません。

調べている途中、教室行った際に、液晶テレビの電源を切ってみる、というをやっていなかったことに気が付きました。いや、初歩的なミスです。

VGA はアナログ信号なので液晶テレビ側はこれを一旦デジタル信号に変換して表示します。
しかし、今回使っていた HDMI はデジタル信号なので、同期してないと信号が伝わりません。液晶テレビとパソコンが最初に繋がった時に同期して、お互いのハード仕様を確認してから映像を伝えることになるのですが、ケーブルの抜き差し程度では同期のやり直しができな
かったのかも。

昨日、うまく表示できたのは、この同期がうまくいってたから、ということでしょう。今回、VGA ケーブルで映るようになったのは、MacBook Air の Thunderbolt 端子から HDMI に変換するアダプタから、VGA に変換するアダプタに交換したことで、液晶テレビを新しいデバイスとして認識しなおしたからかもしれない。なので、MacBook Air の Thunderbolt 端子から HDMI に変換するアダプタが入っていたので、それを外して、液晶テレビの電源を切り、完全に最初からやり直せばよかった。

今、パソコンには HDMI 端子が付いていますが、より小さくて汎用性の高いUSB typeC 端子に置き換わると言われています。変換アダプタの利用が増えると、今回のようなトラブルも
増えるのかな。

派遣先の大学の売店で、新しいＰＯＳシステムを導入することになり、今はその手伝いをしています。商品マスターの登録とか、準備にやる作業はたくさんあるのですが、細かいことは何も決まっておらず、とにかく導入しよう、ということで、運用直前にバタバタと登録中。後から実は違うよ、というのが山ほどでてきそうです。

運用開始の前日、ＰＯＳレジのメーカーの人が来て、使い方をレクチャーしたので参加しました。ＰＯＳレジは、スーパーやコンビニで見慣れていますが、どうやって使うかは全く知りません。かなり新鮮な体験でした。

今のレジは、バーコードリーダーが付いているので、商品に「ピッ」とするだけで値段が表示されます。実は、裏で一品一品リストを見ながらパソコンで登録したのですが、現場では簡単にレジ打ちできます。

また、バーコードの無い商品はタッチパネルにタッチするだけ。パネルはウィンィドウ形式になっているので、種類毎にページを切り替えてタッチというのもできます。

そうやって全ての商品を打ち込んだら、小計ボタンをクリック。お金を預かったらその金額を打ち込んで現計ボタンを押す。そうするとドロアーが開いておつりが出せるようになると同時に、レシートが出てくる。

ここまでは、コンビにでは、高校生がバイトでやっているので、難しいことは無いのでしょう。

話を聞いていてよく解らないのは、間違った場合の訂正。
商品を読み取った後から、これやっぱり買わない、となった場合とか、同じ商品を２回読み取ってしまったとか、でしょうか。レシートを出す前なら、それまで読み込んだ商品が、タッチパネルに表示されているので、それで操作できるようです。

また、一度出てしまったレシートの分をマイナスする方法もあるようです。前の会社の経理システムは、処理を間違えてやり直す場合は、一旦、マイナスの帳票を出して、正しい帳票を登録する、という手順が必要でした。簿記の付け方がそうだからみたいですが、レシートの打ち直しは、そんな感じの処理でした。

まあ、会計の仕組みの末端にあるので、正しく処理するとそうなるのかもしれません。現場の方は慣れているようで、従来のレジとの違いなどを熱心に質問していました。お金に関わる仕事では、簿記の考えは必ずついてまわるので、時々復習しておかないと話についていけません。今回も、かなり頭を使って聞いてました。

なお、ＰＯＳレジはネットに繋がるし、内部にHDDを内蔵しているなど、ほぼパソコンです。HDD内蔵なのでUPSに繋いで運用するそうです。電源スイッチも、ＯＮのためのスイッチで、停止はパネルから操作します。電源スイッチを長押しすると、強制的に電源が切れるので操作しないでください、だそうです。

今は、スマートフォンやタブレットを使ったＰＯＳ端末が流行だそうです。また、売上げデータはクラウドで管理するのも一般的になりつつあるようです。ＰＯＳレジの箱の中のパソコンに、そういったネットワークやデバイスを管理するソフトを入れておけば、高機能なＰＯＳシステムが比較的簡単に作れそうですね。