信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =後(プログラム改修編)=

    こんにちわ。パグと申します。前編はこちら→https://core-tech.jp/blog/article469/今回は新人プログラマーが「WEBサイトの改修」を命じられた場合の、具体的な作業工程を書きます。もしもあなたが1〜2年目の新人、新卒で、作業をまとめて大量にふられたときに、何からしたら良いのか、わからなくなってしまったら、「情報を整理すること」から始めてください。1.調査をするメモ書きなのか、きちんとした仕様書で来るのかは不明ですが、仕様の確認フェーズでは、・修正をする範囲を洗い出す作業・QAを洗い出す作業の2点を行います。例えば、このページにバナーを追加してください、といった作業の場合・・・・PC/SPなど両UAに入れるのか?・類似画面がないかを確認します。画面名指定のない場合は同じような画面がないか、などQAとしてリーダーやお客様に確認します。例えば、このページのこの情報を削除してください、といった作業の場合・・・・その情報はTBLから出力されているのか、ベタで書いてあるのか・TBLから情報を出している場合は、使用しているカラムや文言で、プロジェクトファイル全体をGrepし、影響範囲をメモなどにまとめておきましょう。そして、その内容に誤りがないか、QAとしてリーダーやお客様に確認します。紐づく情報でGrepしたり・・・、類似Contollerを探したり・・・それらをまとめてQAで出し、自分が実際作業に入る前に聞きたいことをまとめておきます。ここまでが調査のフェーズです。2.詳細設計をする通常、詳細設計の前に基本設計や方式設計などをすると思いますが、今回はPG向けに記載しているため、事前にそれらが完了していることを前提に書いています。設計工数を取ってくれるチームの場合は、設計書のテンプレートがあると思いますので、それに従って行いましょう。設計工数をくれないような小さな作業の場合は、修正対応するContollerやClassに、コメントで作業をかいていきます。//XXXModelを呼び出す//Dataを加工する//Viewに渡すなどのコメントを記載したら、もっと細分化します。//XXXModelを呼び出す//Model内のメソッドの In(変数はXXID)//Outはどんな形か //Notfoundの場合はどうするか//Dataを加工する//1の場合はXXという文字列にする//2の場合はXXという文字列にする・・・//Viewに渡す//渡す変数が未使用か調べる//どのような形で渡すか・・文字列なのか、配列なのか、オブジェクトなのか・・・まとめて考えて混乱する場合は、とにかく細分化していきます。特に良く見るのが、AJAXの機能を書こうとして混乱している人です。AJAXの場合、JS、PHP(などのサーバーサイド言語)、HTMLと分かれているので混乱するかと思いますが・・・こんな風に分割します。HTML・どんなタグがトリガーになるか、Classなのか、Idで呼ぶのか、どんなイベントか・どこに値を戻すのか、Divなのか、Spanなのか、それとも何かの子NodeなのかJS・イベントをかく、ボタンクリックなのか、値変更なのか・イベント詳細を書く、Inは何かOutはどうしたいか、GetなのかPostなのか、どのURLに渡すのか・想定する文字列が戻ってきたら、どこのタグに出力するのかPHP(サーバーサイド言語)・PostまたはGetでなにを受け取るのか、それとも受け取らないのか・受け取った値をどうするのか(例えばModelなどを呼び出し値を取得するとか)・Outするときに加工するか(RestContollerなどの場合はResponse戻しやEchoしないと出ない場合などに気をつける)上記を順番に書いていき、自分が理解のできる「最小の処理」まで分解します。基本的に「代入とIF文と繰り返し」が書ければほとんどの処理がかけます。どんなに大きな案件も、代入とIFと繰り返しで成っています。(これはあくまで自論です。)なので、新しく触った言語で一番最初に覚えることは、代入方法、分岐の書き方、ループの書き方です。3.細分化された単位にPGをあてていく細分化すると、何度も書いているような処理は、関数にしたほうがいいな、とか細かいところが見えてきます。あとは、書いたコメントと同じ処理をPGで1行1行書いていくと、作業が完了します。このときに絶対に焦ってはいけません。焦って色々な方向に気を散らすと完成しないので、自分が最小化させた単位でかける部分だけをどんどん書いていきます。うまく書けない部分は飛ばしても良いのです。4.細分化した単位でテスト仕様書を作成する単体テストっていうのは、PG単位でのテストです。手動でやってませ〜んとか言わない。そいうことじゃない!!プラスで、修正していない範囲のテストができていれば完璧です。テスト仕様書を書きながら、うまくできなかった部分や、考慮が足りない部分を修正して、CD完了です。最後に詳細設計の工数をくれない案件も少なくはないですが、いきなりプログラムを書き始めるよりも、コメントでも良いので、詳細設計をしたほうが、結果的に戻りが少なく、矛盾が少なく、工数的には短く済むので、案件をもらうととりあえずパニックになる人は、調査と詳細設計をぜひやってみていただきたいと思います。次回は新規作成編を書きます。ではまた・・・。
  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=こんにちわ。パグと申します。最初に、簡単に自己紹介をすると、私は新人PGではありません。SIerに出向して5年ほどはスタンドアロン型のシステム開発をしていました。WEB未経験から、WEBサイト制作をメインとしているコアテックに転職して、7年経過するSEです。そんな私は、最近新人PGの進捗管理をする機会が多いのですが、手が止まってしまう新人が多いのを目撃して、また、自分も同じように新人の頃、手が止まることが多かったので、あの時、こうしてれば・・・と思ったことを前半後半に分けて書いてみました。仕事って一言で言っても様々で、ツールの講習会開いて欲しいとか、システム(サイト)作って欲しいとかSQL書いて欲しいとか、社内環境整備して欲しいとか様々なのですが、今回は、WEBサイト制作に関して、自分の中でルーティン化しているものをまとめます。(事前準備)案件アサイン前に、その企業(チーム)の環境などを展開されると思います。私の場合はどの現場(チーム)に行く場合も大体その現場の言語やツール関連の本を2〜3冊、知らないフレームワークの場合はマニュアルをざっくりと読んでから、そのチームに参画していました。1、まずは改修、新規作成のスコープをはっきりさせる今渡されている作業が、細分化されているものの一部なのか、この案件の全てなのか、つまり、これを作ったら案件完了なのか、自分が作っても他の人が終わってなければ完了にならないかを認識します。初めての現場でドキュメントや引き継ぎ事項に「納品物」がはっきりと書いてない場合は、直接関係者に聞いておきましょう。これは会社によっても会社内のチームによっても異なるからです。(納品物の例)・ソースだけで良い→ソース管理ツールにPUSHしたら終わり→物理的にファイルが欲しい→サーバーにアップして欲しいなど・テスト仕様書も欲しい→Excelで欲しい→特定のフォーマットで欲しい→スクリプトが欲しい・テスト仕様書にエビデンスも欲しい→同上など、納品物も案件によって異なります。2、自分の担当部分のスケジュールをはっきりさせましょう渡された期日が、コーディング完了日なのか、テスト完了日なのか、リリース日なのか、顧客引き渡し日なのかは出向先やチームによって異なりますが、勝手にスケジュールを引いて間に合わないとなると困るので、自分の作業を完了し、渡す日がいつなのかって部分を、PM、PLまたは顧客ときちんとネゴって文章に起こしておくといいと思います。文章に起こすっていうのはチャットでもメールでもいいんですけど、口頭でやり取りした場合言った言わない問題が発生しないようにするため、口頭で話をした後に関係者をCCに入れたメールなどで再確認した方がいいです。それは相手を信頼していないからではありません。自分自身で期日が間違えていないかを再認識するためでもあります。期日を入れる例は以下のとおり。——X月X日X時 コーディング、単体テスト完了X月X日X時 受入テストX月X日X時 リリース日——3、大枠の作業の洗い出しをしますすごいざっくりとした作業工程の洗い出しをします。今回はWEBサイト制作のPGのフェーズなので、簡単に以下のような行程に分かれるかと思います。・詳細設計・CD→作成する機能の大枠を考える・単体テスト・結合テスト4、現行システムを把握するお見積もりを作るような立場の人だと、現行システムを把握するのは、スケジュールを切る前にやりますがPGでしたら、案件開始前に把握できれば良いかと思います。運用案件の場合、渡された仕様書以外に修正が必要な点がないかを把握することが大事です。それによりスケジュールの達成可否が大きく変わるためです。・現行システム全体を把握→このフェーズでは全体像をざっくり捉えるのが大事です。→インフラ構成だとか→全体画面数だとか→TBL構成だとか・機能追加部分の現行ソースを読む→コード規約だとか→命名ルールだとか・案件進行ルールを把握しておきます5、終わるのか終わらないかを考えてみる。ここまでで、X月X日までに何を作らないといけないかってところが割と具体的になっています。スケジュールが鬼のようにきつい案件も勿論たくさんあります。その場合は、「できない」っていう勇気が大事です。私が経験した企業は10社あるかないか(上場企業から20名程度の小さな会社まで規模は様々)ですが、どの企業様でも、仕事なんだからできないっていうな、とか体育会系的なことを言われることはありませんでした。伝える際には、・ここまでなら終わる・X日あれば終わる・なぜ無理なのかを具体的に伝えてください。ただ「こんなんおわんないっす〜」では伝わらないのでダメです。これとこれは終わりますが、この部分だけ、後出しにしてくださいなどの提案がないと、PL(PM)もじゃあどれくらいやってもらえるのかな?というのを想像できないためです。ちなみにこの工程は、残業時間を含めない状態で考えた方がいいです。残業すれば終わる工数というのは、すでにスケジュールに無理があるからです。————————最後にプロジェクトのリーダーは作業をふるときに通常、作業が終わらないことを想定して、保険をかけながらスケジュール作成しますので、自分で無理かもしれないと思ったときには、正直に伝えてもらったほうが予定を組みやすいです。仮に、できる!と思って作業を始めても、終わらないと思った時点で、速やかに伝えることが大事です。渡された仕事が仮に全て終わらなかったとしても、自分でそれを伝えられていれば、あなたの評価が下がることはありません。周りの人が巻き取ったとしても、それはあなたの責任ではありません。新人のうちは、他者と協力しながらでも良いので、自分でできることを、できる限り順番にこなしていく、というのを意識して仕事をします。もちろん、そんなに優しくない企業もシチュエーションも沢山あると思いますので、思い通りにいかないことも理不尽なことも沢山ありますが、誠意を持って対応することで、理解してくれる上司や同僚は、多いと思います。次回は具体的にコーディングや設計に入るところを記載していきます。ではまた・・・。
  • 画像:ブログサムネイル

    at CORETECH

    午後休をとって、子供のお誕生日のお祝いをしました!

    秋、ありませんでしたね。こんにちわ。パグです。そうかそうか、もう1年経ったのか・・・好き!!(キティちゃんのYoutubeの真似)10月は娘がお誕生日だったので、去年は時差出勤を使って早帰りをしましたが、今年は午後半休をとって早帰りをして、お祝いしました。もちろん一日有給を取っても良いのですが・・・私は育休明けより時短勤務で、10時〜17時(休憩1時間+6時間)が定時となっています。その為、午後お休みにすると、13時に帰れるのです!なんだか有給0.5日でそんなに早く帰れるなら、半休でいいやってなりませんか?私だけ?そんな訳で午前中は仕事をして、午後からデパートに行って食材を買い込み、準備しました。去年はALL手作りにこだわって、こんな感じに。→去年の様子https://core-tech.jp/blog/article256/14時からのお買い物+料理だと微妙に遅い時間になってしまって、子供のお腹が空きすぎて大変だったので、今年は半手作りでちゃちゃっとハロウィン+誕生日をお祝いしました。10月のハロウィンシーズン特有のケーキや器は、本当に可愛いですね!やはり・・・かぼちゃくらいじゃアンパンマン様の求心力には勝てませんでしたけど・・・娘はエビが大好きなので、ガーリックシュリンプやフライドチキンなど、大喜びで食べてくれました。時短勤務制度についてもう少しお話しすると、国で定められている時短勤務の対象年齢は子供が3歳になるまで、ですが、コアテックでは、未就学児までを対象としているので、もう少し早く帰って、子供と過ごしたいパパ、ママは3歳を過ぎても時短勤務のまま働くことも可能です。子供が大きくなるまで、お誕生日のお祝い当日を、家族でゆっくり過ごせる環境で働いてみませんか?https://core-tech.jp/jobs/では。また〜!
  • テクログ

    IT業界で長年やってるのに、なんなのか答えられない単語について語る2

    こんにちわ。パグです。今日もモヤモヤ理解してるけど説明できない内容について語ります。1はこちら→プロトコルについてhttps://core-tech.jp/blog/article445/今日は「セッション」についてです。OSI参照モデルのセッションではなく、HTTPのセッションです。はい、じゃあ説明していきます。セッションってなんなの?って聞かれた時になんて答えますか?セッションとはとかで調べたり、先輩に聞いたりして、・通信に先立って、2台のホスト間で必要なデータをやり取りすること・WEBページを開いて離脱するまでの1連の流れのこと(参考リンク)https://www.seohacks.net/basic/terms/session/https://wa3.i-3-i.info/word1791.htmlこういった説明をよくされるのではないでしょうか。この二つは、実は同じ話をしているのですが、内容を理解していないと全然異なるものに感じます。そのためセッションという言葉の意味が曖昧になります。セッションを理解する前に、WEBブラウザが表示されるまでの仕組みについて説明します。WEBサイト、というのは、ユーザー(のPCやスマホ)からどこかのWEBサーバーにリクエストを投げます。WEBサーバーからはこのリクエスに応じたページを返信して終了します。例えば、私が、どこかのサイトで買い物をしたいとします。ブラウザにURLを入れるか検索サイトでアクセスすると、このサイトのトップページが表示されます。そこで買い物をする場合にどういったやり取りがなされるかというとーーーーーーSTARTーーーーーー私:トップページが見たいサーバー:ほらよ(トップページ返す)ーーーーーー私:これ買いたいサーバー:ほらよ(カート画面返す)ーーーーーー私:クレカはこれねサーバー:ほらよ(決済画面返す)ーーーーーー私:購入できたから、画面閉じるーーーーーーENDーーーーーーWEBは通常このような流れで、サーバーからは「ほらよ」と画面が返された時点で一回毎のやり取りは終了します。ここに今どういった状態であるかを保存する機構を持たないためです。でも上記のような買い物をしたい、のような動作の場合、トップページからカート画面へ遷移する時に、どの商品を持って遷移したか、とか、決済画面に行く時に、どのユーザーであるのか、などをサーバー側がわかっていないと、適切な画面を返すことができません。ですが、HTTPの通信には、このような情報を保持する箇所がありません(※1)。じゃあ現在の技術ではどのようにして現状の状態を保持しているのかというと、ここでやっと「セッション」がでてきます。「セッション」とは一連のやり取りの中で、今の状態を維持したまま相互に通信されている状態のこと、と理解しましょう。例えば、STARTからENDまでの流れを「1つのセッション」として説明すると、STARTからENDまで私がログインしていて、この商品を買って、このカードで買うという現状状態を保持した状態で、サーバーと私が通信している、この現状状態を保持した状態での通信が1つのセッションです。たまに、セッションをクッキーのようなものやキャッシュのようなものと誤解されている方がいますが、それはクッキーであり、キャッシュであって、セッションは保存するところの名称ではありません(※2)。通信に必要な情報を保持したまま通信を行なっている状態の方をセッションと呼びます。このセッション中に、どこに情報を保存するかというと、通常はクッキー+何か(RDSやKVSやmemchacedなど)またはクッキーに直接本体を突っ込む。または、ファイルで持っている。など色々と種類があります。いずれも、暗号化された状態で、たとえその実体を盗まれたとしても、中身が見えないようにした状態で保存している必要があります。最初に出てきた・通信に先立って、2台のホスト間で必要なデータをやり取りすること・WEBページを開いて離脱するまでの1連の流れのこととはつまり同じことを指していて、どちらの言葉も使って説明すると・・・「WEBページを開いて離脱するまでの1連の流れの中で、通信に先立って、2台のホスト間で必要なデータをやり取りすること」→これが完璧なセッションの説明となります。新人に聞かれた際にはドヤ顔で答えてあげてください。クッキーやキャッシュと混同して混乱している新人さんがいたら、「それはセッションの保存領域のことでセッションのことじゃないからぁ(ドヤァ)」と説明してあげてください。———(※1)ログイン情報とかでない場合は、POST、GETでいけるんちゃうかって考える人もいると思うんですが、今回はあくまで「セッション」の説明だということに注目してください。(※2)今回はsessionStorageの説明ではありません———以上になります。いずれ。また。
  • テクログ

    IT業界で長年やってるのに、なんなのか答えられない単語について語る

    こんにちわ。パグです。私はスタンドアロン型のシステムのSEを7年。WEBシステムで7年。ほぼ15年IT業界にいるわけなんですけど、探究心がほんとないんですよね。でも、IT業界って探究心がなくても意外と仕事ができちゃったりするんですよ。でも結局は表面上の理解しかしてないわけなので、設計する時にめちゃくちゃ考えるんですよ。なので、今回は、ねえ、それってなんのこと?って聞かれた時に、ドヤ顔で答えられるほど自分で理解したことについて書きます。今日は「プロトコル」についてです。プロトコルってわかりますか?IPとTCPとかFTPとかPOPとか色々種類があるあれですよ。じゃあさ、プロトコルってなに?って言えますか?プロトコルってなんですか?って新人に聞かれた時に、最もわかりやすいな、と私が思った回答はこれです。プロトコルとは、規約のこと。規約とは、なんの規約なのか。コンピュータ同士が通信を行うための規約のこと。なんでそれが必要なのか?例えば、コンピューターって、出たての頃は、各メーカーで規約が異なったわけなんですよ。すると、送信元と受信先で同じ端末を持ってないと、通信できないじゃないですか。それじゃ不便だよねってなって、世界的に標準的な規約が決まりました。これがRFCという形式で技術仕様が公開されていて、その通りに製品を作ると異なるメーカー同士でのやり取りが可能になるわけです。RFC準拠しないとどうなるか?別に怒られたりはしません。RFCに準拠しない場合、通信ができなくなります。名指しするとあれなので、わかるように最近困ったRFC準拠してない事例を挙げるととある携帯キャリアがメールアドレスの作成仕様をRFC準拠してない形で許可していました。これはすごく昔、もう10年以上とか前に独自で出していたもので、キャリアメールとは、機種変更をしても大抵引き継がれるので、このせいで、この頃にRFC準拠してない形式で作られたメールアドレスに対して送信ができないという事象が発生しました。メールサーバー側で、RFC準拠してないメールアドレスをリジェクトしていたためです。この時、対策としては、メールアドレスの前後にクオートを入れて、文字列として認識させることで、送信できるようになったのですが、エンドユーザーに、そのメールアドレス変えてよ。なんてなかなか言えないので大変に困ったのを覚えています。ね。RFC守らないと困るでしょ。なので、現在のコンピュータ、ミドルウェア、ソフトウェアのほとんどがこの規約を遵守して作られています。さて、最初の話に戻ります。つまりプロトコルとは、ルールのことです。こういう風に送ってね。こういう風に解析してね。というルールのこと。ちなみにHTTPもWEBのプロトコルになります。プロトコルは、単語じゃなくて略称なので、全て語尾にPがついています。HTTP(HyperText Transfer Protocol)FTP(File Transfer Protocol)IP(Internet Protocol )SMTP(Simple Mail Transfer Protocol)はい。今日はここまでです。バイバイ〜
  • 画像:ブログサムネイル

    テクログ

    CloudWatch Logsエージェントがローテートさせるとtimestamp is more than 2 hours in future.で止まってしまう件について

    こんにちわ。パグです。本日はCloudWatch Logsエージェントのログがtimestamp is more than 2 hours in futureで止まってしまう件について書きます。現在の環境はFuelPHPで、主にFuelPHPのローテートログをCloudWatchエージェントでPUSHさせたいって内容になっています。が、恐らく他の環境のログの場合で起きた事象もこれに近しいのではないかと思います。CloudWatchLogsエージェントは導入済みで、ローテート時にうまく動かない人向けなので、そもそもCloudWatchLogsにログが反映されていない場合は別の要因によるのではないかと思います。[/server/fuelphp/logs] datetime_format = %Y-%m-%d %H:%M:%S file = /path/to/fuel/app/logs/20*/*/* buffer_duration = 5000 log_stream_name = {instance_id} initial_position = start_of_file log_group_name = /server/fuelphp/logs 他にマルチラインの設定などが必要かと思いますが、簡単に書くとこんな感じに設定。CloudWatch側では、log_group_nameで検索ができるようになりますが、翌日「 timestamp is more than 2 hours in future.」とエラーが出ておりPUSHイベントが動いていません。色々調べていて、皆大好きStackOverflowを見て見ると、以下のような記事が。https://stackoverflow.com/questions/40604940/cloudwatch-logs-acting-weirdhttps://forums.aws.amazon.com/thread.jspa?threadID=243092この記事の人に激しく同意>Yes I'm experiencing the issue too. Is there a way to reset the state file without doing this?うん。私もそう思うわ。それやらないでResetしたいんだよぉぉぉぉ。はい。じゃあ。本題です。awslogsのPUTイベントが失敗する原因は以下です。PutLogEvents オペレーションの制約に従って、次の問題によりログイベントまたはバッチがスキップされる場合があります。以下本家のマニュアルから抜粋https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html注記1.データがスキップされた場合、CloudWatch Logs エージェントはログに警告を書き込みます。2.ログイベントのサイズが 256 KB を超過した場合、ログイベントは完全にスキップされます。3.ログイベントのタイムスタンプが 2 時間以上未来の場合、ログイベントはスキップされます。4.ログイベントのタイムスタンプが 14 日以上過去の場合、ログイベントはスキップされます。5.ログイベントがロググループの保持期間よりも古い場合、バッチはすべてスキップされます。単一の PutLogEvents リクエストでログイベントのバッチが 24 時間実行されている場合、PutLogEvents オペレーションは失敗します。上記の3がこの「 timestamp is more than 2 hours in future.」というエラーにあたります。タイムスタンプが実行時間より2時間以上未来日になっているので、スキップしますとのことで、最初はUTCと日本時間のズレのせいかと考えたのですが、どうもズレている時刻が異なります。実行タイムスタンプの調べ方はStackOverflowに書いてある通りで「/var/lib/awslogs/agent-state」をsqlite3で検索(JSON形式で保存されているので実行された体の時刻を調べます)調べるストリームIDは/var/log/awslogs.logに出ています。2019-09-28 06:01:02,041 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Removing dead reader [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/27.php] 2019-09-28 06:01:02,041 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Removing dead publisher [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/*/*.php] 2019-09-28 06:01:02,044 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Starting publisher for [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/28.php] 2019-09-28 06:01:02,044 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Starting reader for [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/28.php] 上記の77cbf636732d4f124469c8ccb0f71abeです。(PATHはサイトの詳細が記載してあるので少し削りました)これを検索します。[root@server]# sqlite3 /var/lib/awslogs/agent-state SQLite version 3.7.17 2013-05-20 00:56:22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> select * from push_state where k="8deaef1856dda2abe912ceedc4180f53"; 上記のkの部分にストリームIDを入れると、JSONからPUSHした時にイベントが出てきます。8deaef1856dda2abe912ceedc4180f53|{"start_position": 248, "source_id": "8deaef1856dda2abe912ceedc4180f53", "first_timestamp": 1570412666000, "first_timestamp_status": 1, "sequence_token": "49599891918873079124975725871068904036184047788058782002", "batch_timestamp": 1570412666866,  "end_position": 369}|2019-10-06T21:00:13|2019-10-07T01:44:32 このFirstTimestampとbatchtimestampが明らかに前日になっています。前日になっていますが、9時間ズレとかではありません。なのでUTCの問題ではありません。なんでかなーと調べていくと、書き込まれない時に、ローテートされた後のログストリームIDがずっと変わらないではありませんか。2019-09-28 06:00:58,041 - cwlogs.push.reader - INFO - 12879 - Thread-1346 - Reader is leaving as requested... 2019-09-28 06:01:02,041 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Removing dead reader [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/27.php] 2019-09-28 06:01:02,041 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Removing dead publisher [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/*/*.php] 2019-09-28 06:01:02,044 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Starting publisher for [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/28.php] 2019-09-28 06:01:02,044 - cwlogs.push.stream - INFO - 12879 - Thread-1 - Starting reader for [77cbf636732d4f124469c8ccb0f71abe, /logs/2019/09/28.php] 2019-09-28 06:01:02,045 - cwlogs.push.reader - INFO - 12879 - Thread-1348 - Replay events end at 384. 2019-09-28 06:01:02,045 - cwlogs.push.reader - INFO - 12879 - Thread-1348 - Start reading file from 74. 2019-09-28 06:01:02,045 - cwlogs.push.batch - WARNING - 12879 - Thread-1348 - Skip event: {'timestamp': 1569618001000, 'start_position': 74L, 'end_position': 153L}, reason: timestamp is more than 2 hours in future. 2019-09-28 06:09:30,216 - cwlogs.push.batch - WARNING - 12879 - Thread-1348 - Skip event: {'timestamp': 1569618569000, 'start_position': 153L, 'end_position': 229L}, reason: timestamp is more than 2 hours in future. ダメだった時のログはこんな感じで。Removing dead publisherしてるのにStarting publisherのストリームIDが変わらない。77cbf636732d4f124469c8ccb0f71abeこの場合、翌日になっているのにずっとタイムスタンプ上9月27日の朝6時とかになっているので、9月28日のPUSHとならずに、スキップされてしまいます。原因は、FuelPHPのログって、一番上位に<?php defined('COREPATH') or exit('No direct script access allowed'); ?> こんな感じの固定文言が出ているんですけど、こいつが前日とまったく同じなものだから、Startを前日のログから検索してしまって、日付がリセットされないーって内容でした。なので、FuelPHPはCoreの LogsClassをOverwriteして2019-10-01 08:26:02<?php defined('COREPATH') or exit('No direct script access allowed'); ?>タイムスタンプを突っ込んでやりました。2019-10-07 06:00:08,256 - cwlogs.push.stream - INFO - 14088 - Thread-1 - Removing dead reader [729a61c49dafeeb9472f9bc030510546, /logs/2019/10/06.php] 2019-10-07 06:00:08,261 - cwlogs.push.stream - INFO - 14088 - Thread-1 - Starting reader for [8deaef1856dda2abe912ceedc4180f53, /logs/2019/10/07.php] すると、ログに設定した日付を判別して、勝手にローテートされるようになりました。うまくローテーションがかからなくてログの一部が翌日になったら送れなくなった人はお試しください。(Sitemapって、エラーじゃないやんけとか、いわない。)ではでは〜。