読者です 読者をやめる 読者になる 読者になる

ソフトウェア開発者の日常

こだわりなく書きたいことを書いていきます。

PHP:実行時間の制限を確実に回避できるのは?

PHP

PHPの実行時間の制限について書きました。
ajya.hatenablog.jp

max_execution_timeの値を長い時間をにして止まらないのを確認するのも方法ですが、1秒という極端に短い時間にして試してみました。
確かに1秒で終了したので、max_execution_timeの値で制限ができるようです。

どっちを使う?

max_execution_timeの説明には、「より詳細な情報については、 set_time_limit() 関数の説明を参照ください。」とあるので、set_time_limit()の説明を見てみました。
PHP: set_time_limit - Manual

こちらを使えば、max_execution_timeの値を設定するのと同じように、実行時間の制限ができることが分かりました。
実際1秒と設定してためしたら、1秒で終了しました。

興味深かったのは、User Contributed Notesのこちらのコードです。
PHP: set_time_limit - Manual

ループの外側で1度だけset_time_limit(1)を呼び出した場合と、ループの外側で1度set_time_limit(1)を呼び出して、ループ内でもset_time_limit(1)を呼び出す場合とで、結果が違うことが書かれています。
1秒に制限されているので、ループが1秒以上かかれば強制終了してしまうでしょう。
それを回避するために、一定回数で再度設定しなおせば、タイムアウトのカウンタがゼロになって制限時間が再スタートするのというのが理解できます。

f:id:AJYA:20161209060304j:plain
photo credit: jepoirrier Oops! Delhaize DigitalShelf is not responding! via photopin (license)

set_time_limit()を使ってみる

set_time_limitの興味を持ったコードのように、ループの外側で1度set_time_limitを呼び出して、ループ内でもset_time_limitを呼び出しておけば、確実に実行時間の制限を回避できそうなので、こちらの方法を採用します。

PHP:実行時間の制限はどうなっているの?

PHP

以前お客さんのWindows Server環境で、PHPで作ったコマンドラインから起動するプログラムを実行していました。
半年に一度ほどの作業で、時間がかかる処理というのはわかっていました。
処理の状況から1時間半くらいで終了するかと予想して待機していました。

1時間経過したところで、突然コマンドラインから起動したプログラムが停止しました。
制限時間に達したので終了したようなメッセージが表示された記憶があります。
幸い再度プログラムを起動すれば、続きから処理できるようにプログラムを作ってあったので、再度起動して処理を完了しました。

コマンドラインから起動する場合は、実行時間は無制限の筈

以前、php.iniのmax_execution_timeの説明を読んだことがあります。
PHP: 実行時設定 - Manual

コマンドラインからの起動すると無制限になると記憶していました。
改めて見ましたが、「PHPコマンドライン から実行する場合のデフォルト設定は 0 です。」と書かれていました。

以前お客さんの環境でコマンドラインから実行して途中で終了してしまったのとつじつまが合いませんが、終了してしまったのは事実です。

f:id:AJYA:20161208062222j:plain
photo credit: www.digicrea.be RawTherapee - next step in creation RawBat via photopin (license)

プログラムから設定しておく

以前とは別のお客さんの環境で、PHPで作ったコマンドラインから起動するプログラムを実行する予定があります。
コマンドラインから実行する場合、無制限というのを信じてもいいのですが、懸念があります。
プログラムからの設定で回避できるのかわかりませんが、max_execution_time を大幅に大きな値にしてみようと考えています。

設定は、ini_set()を使えばできます。
PHP: ini_set - Manual

<?php
ini_set("max_execution_time",43200); // 12時間
?>

max_execution_timeの値はint型なので、int型の範囲に収まっているか念のため確認したところ、収まっていました。
PHP: 整数 - Manual


今となっては以前プログラムが止まってしまったお客さんの環境で試すことができないのが残念です。

気が滅入る仕事を行っているときの気持ちのコントロール

考え

何年仕事をしていても、気が滅入る仕事があります。

不具合の報告資料を作成しているときが当てはまります。
スケジュールの遅延が発生して、スケジュールを遅延報告と遅延を反映したスケジュールを作成しているときも当てはまります。

良くないことを報告するときに当てはまります。

f:id:AJYA:20161207061010j:plain
photo credit: bettie_xo My school report - Summer 1958 via photopin (license)

気が滅入る仕事は、やりたくない仕事

気が滅入る仕事でも、その原因によって気持ちの落ち込み度合が異なってきます。
自分自身が原因なのか、周りが原因なのかで異なります。

周りが原因なら、なんでそうなんだよと文句の気持ちがあります。
その分気持ちの落ち込みが少なくなります。

自分自身が原因の場合、相当気持ちが落ち込みます。
あのときこうしておけばよかったと思い出して反省もしています。

気が滅入る仕事は正直逃げ出したくなります。
投げ出したくなります。
とんでもないことが起きて、状況が一変しないかと思うときもあります。

後のことを考える

とんでもないことが起きて、状況が一変したことなど一度もありません。
そんなことは妄想でしかないこともわかっています。
それでもそういうことを考えて、なんとかならないのかと思ってしまいます。

こういう状況になったらときは、自分自身がどういう行動ができるのかと考えます。
逃げ出したらどうなる?会社を辞めれるのか?全てを捨て去るのか?
投げ出したらどうなる?開き直れるのか?

どれもできません。
できないならできる行動は?

相手や周りに相談して、状況が少しでもよくなるような行動をとるか、状況を終わらせるかの行動をとるしかありません。
少しでも前に向かって行動をとるしかありません。


こんなことを日々考えながらすごしています。

時間が見通せないことの不安

仕事

以前、作業手順があって、時間がわかることによる安心感について書きました。
ajya.hatenablog.jp

このシステムの次の利用方法のための設定依頼がありました。

作業手順を見て不安になる

設定しようと作業手順を見ました。
いつもなら手順の前に、手順を行うために必要な時間が記録されていますが、今回分はなぜか記録されていません。
これまで何度か作業を行っているので、作業に必要な時間はわかって、記録できるはずです。

データ量が毎回違うので、作業にかかった時間が毎回大きく違うため、記録しなかったのかもしれません。
2日間に分けて作業を行って、作業にかかった時間が曖昧になったため、記録しなかったのかもしれません。

作業の内容を見る限り、1時間以上2時間以内と感じました。
1時間の違いは大きいです。
本当に2時間で終わらせられるのかと不安を感じながら、作業を始めました。

f:id:AJYA:20161206053658j:plain
photo credit: AlbinoFlea Self-Portrait at 8:02 pm via photopin (license)

必要な時間を記録して次回の安心感を得る

時間の記録をしつつ作業を行いました。
結果は予想した時間内の1時間半で終わりました。

データ量が毎回違うので、必ず1時間半で作業を終わらせることができるかわかりません。
それでも今回の記録として1時間半を作業手順の先頭に、必要な時間として記録しました。

これで次回以降は、作業に必要な時間の目安があります。
毎日30分ずつ作業すれば3日で終わりそう、初日に1時間確保して2日目は30分で終わりそうなど、作業のスケジュールが考えられます。


改めて時間を記録することの大切さを感じました。
仕事上の作業に限らず、通勤するときなど、時間の見通しがあることにより、必要な時間を適切に確保できます。
これからも記録できる時間は、記録をしていきたいと改めて感じました。

今年、折り畳み式補助便座と掃除機を買ってよかったです。

お題 買い物

お題その2「今年、買ってよかった物」、という書き出しになって、お題その2って付くのはお題を選んだからですが、変更してもいいのかわからなかったので、そのままです。

今年もいろいろ買って記事にもしてきました。
「買い物」カテゴリーで探すと以下の記事がありました。
ajya.hatenablog.jp
ajya.hatenablog.jp
ajya.hatenablog.jp
ajya.hatenablog.jp
ajya.hatenablog.jp
ajya.hatenablog.jp
ajya.hatenablog.jp

いっぱい買ったわけではありませんが、いろいろ買ったんだなということを改めて思い出します。

今年、買ってよかった物は2品

どれも多少なりとも考えて買って、使えているものばかりなのでどれもよかったです。
あらためてよかった物を選ぶと、折り畳み式補助便座と掃除機になります。

折り畳み式補助便座は、子どもを連れて出かけるときは必ず持っていきます。
子ども用トイレがないときでも、大人用トイレで安定して子どをを座らせることができます。
子ども用トイレがなくてどうしようと困ることがなく、助かっています。


掃除機は以前使っていた物に比べて、軽るくて持ち運びしやすいです。
吸い込む能力は変わりません。
以前使っていた物に比べて、機能は減りましたが減った不都合を感じてはいません。
軽いことはいいことだと改めて感じました。



特別お題「2016年を買い物で振り返ろう」 sponsored by 三菱東京UFJ-VISAデビット

iPhone 6を初期化して再度インストールをする羽目になったので、随分アプリを減らすことができました

考え

こちらの記事を読んで、iPhone 6を初期化する羽目になったことを思い出しました。
cyblog.jp

初期化のする羽目になったことは、記事に書いています。
ajya.hatenablog.jp
ajya.hatenablog.jp

初期化する羽目になってから3ヶ月過ぎ、iPhone 6のアプリを追加したり削除することは、ほぼなくなりました。
初期化する前と初期化した後で一番違うのが、インストールしてあるアプリの本数です。

インストールアプリの本数を数えているわけではないので正確ではありませんが、以前は8画面使っていたのが、今では4画面で収まるようになりました。
フォルダへの入れ方が変わっていたりもあるので、厳密には比較できませんが、ずいぶんアプリをインストールしていないことになります。

f:id:AJYA:20161204061906j:plain

すべて消えたからこそ減らせた

冒頭に紹介した記事を読んだときに、記事中で紹介されている映画の主人公の行動が、iPhone 6を初期化してなにもない状況と同じだと思いました。
初期化したことで、最初から入れなおすことになり、必要なアプリからインストールしていきました。
利用頻度は低いけれど、使うことがあるアプリもインストールしました。
インストールしていたけれど、使っていなかったというアプリはインストールしていません。

使っていなかったアプリなんて、判断して消してしまえばいいのでしょう。
一旦インストールしてしまうと、今は使っていないけれど、使うかもしれないと思って、消す決断ができません。

経験をいかしたい

劇的にモノを捨てる、すっきりさせるには、何もない状態から始めるのが早いということを体感するいい機会となりました。
iPhone 6を初期化する羽目になった当初は、「いい機会」と考えるようになるとは、思いもしませんでした。
この経験を部分的にでもいかしたて、周りのモノを減らしていきたいです。

1週間の振り返り(11/26〜12/2)

仕事 週次

ジョイフルの日替わり昼膳のダブルチキンカツ&えびフライ膳です。
f:id:AJYA:20161203055539p:plain
えびフライは子どもに食べられました。

イオン名古屋茶屋のとんきちのから揚げマウンテン定食です。
f:id:AJYA:20161203055706p:plain
取り分けて食べました。
一人で食べると飽きそうです。

  • 11/26(土)
    午前中公園に遊びに行きました。
    以前近くを通って、ここに公園あるんだと知っていた初めてのところです。
    大きなすべり台や、ハンモックのようなブランコがあって、子どもはいろいろ遊んでいました。
  • 11/27(日)
    イオン名古屋茶屋に行きました。
    雨の日で午前11時頃に到着しましたが、立体駐車場と屋上駐車場はいっぱいでした。
    子どもは途中で眠くなって、抱っこを要求したり、僕と車に戻っていました。
  • 11/28(月)
    クエリで改行コードを削除するようにプログラムを修正していました。
    ソースコードがすっきりするので、なるべくクエリでおこなうように考えています。

ajya.hatenablog.jp

  • 11/29(火)
    不慣れなFreeBSDの環境に、ユーザーを追加しようとしたら、追加できませんでした。
    余分な入力をしたためですが、以前のメモ通りoおこなっていたので、以前のメモが間違っていたことになります。
    次からは間違えないように訂正をしておきました。
  • 11/30(水)
    プログラムの処理の流れを大きく変更していました。
    大幅に変更になることを前提として設計や開発をしたわけではありませんが、できる構造にはしてあったので、時間をかけず変更できました。

ajya.hatenablog.jp

  • 12/1(木)
    同じ会社の複数の支社のお客さんから、それぞれ案件の話をいただき、対応に追われていました。
    年末年始を見据えて、頼んでおこうという考えなのかもしれませんが、他の案件もあって、手が回らない状況です。
  • 12/2(金)
    仕様の取り違えが発覚しました。
    言葉の裏の真意が読み取れていませんでした。
    取り違えをした仕様の目的を聞いておけば、理解できて取り違えが発生しませんでした。


複数の案件を並行でこなしていますが、ピークがずれ込んでいる案件があって、予定通りに行かず、ギリギリでなんとかしている状態が続いています。
一時的に以前担当だった同僚に、お願いしたい状況です。