On 4/1, I went to Showakinen-koen to enjoying Hanami.
The weather condition is cloudy, it's unfortunately weather.
Cherry blossoms let us know coming Spring season.
I wish the temperature more higher than now, so it's comfortable to staying.

4月1日に昭和記念公園に花見に行ってきた。
あいにくの曇り空ではあったものの、春を感じさせる桜は良いな。
後は気温さえもう少し暖かくなってくれれば、過ごしやすいんだけどなぁ。

以前の日記で不具合の直し方を書いたけど、おそらくその頃から問題をはらんでたんだろうな…。

先週の月曜日、工場出荷時に戻したら、それ以降立ち上がらなくなりました。
こうなってしまうとどうにもならないので、即修理依頼を出して修理へ。
22日（火）に郵送で出して、翌日午前にサポート着、驚くことにその午後にはすでに発送済み…。
郵送の時間を除けば、1日で修理してくれたことになる。非常にありがたかったです。

自動車ニュースを読み解く (1) 自動運転の難しさ浮き彫りに - Google自動運転車、初の過失事故
http://news.mynavi.jp/series/motornews/001/

もちろん事故起こしちゃダメなんだけど、
ある意味、今このタイミングで人命にかかわらない事故を起こしたことは
決してネガティブなものではなく、ポジティブな影響を生むんじゃないかなぁ。

自動運転 = 事故を起こさない、という何か暗黙の認識があったりするけど、
少なくともここ10年で出てくるものは、完全なものではないと思うんだよね。
そうなると、人間がある程度サポートしてあげる必要がある。
「自動運転 = 事故を起こさない」という思い込みがあると、人間も「大丈夫だろう」と
楽観的に考えるんだけど、逆にそうでない事例があると、ある程度は気をつけようとする。
（少なくともここ10年のものは）完全ではない、ということを認識させる上で
このタイミング、特に大きな事故でなかったことは、ポジティブだと思うね。

「少なくともここ10年のものは」としているのは、今の仕組みだけではどこかで技術的な限界点が来てしまうと考えてる。
技術的に努力するっていうのも一つはありなんだけど、全体の仕組みとして変えていく必要があると思う。
例えば、単純なものだと道の白線を知るために今は画像認識をしているけれども、
そうではなくて、センサをあらかじめ埋め込んでおくとかね。
そうすれば、白線がかすれていて見えないとか、物の視覚になって見えないとか、問題はすくなくなる。

まぁ結論としては、100%を目指すのであれば仕組みから変えていく必要がある。
それまでは、自動運転だからと言って、過度に過信しないほうが良いかなというところ。
技術を信用していないわけじゃなくて、自動運転を普及するために思うところです。

いきなり繋がらなくなって、非常に焦った…。
平日だったらいろいろと不都合が多かったと思う。
さて、症状と直し方とそれぞれ書いておきます。

I was surprising to ZenFone5 can't connect to network.
The accident was happened on Saturday. It's lucky.
Following details are how to repair and the condition of the problem.

症状 / Condition

• Wifi / モバイルネットワークが繋がらなくなる
• 設定からON/OFFしても、ONにすることができない
• BluetoothもON/OFFできないように見える（ここはあまり深く見なかった）
• ネットワークのMACアドレスが見えない

私のケースだと、バッテリが切れたので充電して、起動したらこの症状が起きた。
SIMカードの抜き差しなども試してみたけど、全く反応する気配がなかったので、
ソフトウェアの不具合かなぁと推定。

• Wifi and Mobile Network can't connect
• The status can't change to ON or OFF
• Bluetooth status is also can't change(it's probably due to I'm not enough to observe it)
• MAC Address is can't display

In my case, the battery is low and charge it. Then, the problem was happening after power on.
I tried insert and remove SIM card, but it has no response.
I was estimated that the problem caused by Software.

直し方 / How to fix

1. ASUSのサポートページから最新のファームウェアをダウンロードする
   • http://www.asus.com/jp/Phone/ZenFone_5_A500KL/HelpDesk_Download/
   • 私の場合は "ASUS ZenFone 5 (A500KL) software Image: V11.4.6.103 for JP SKU only* を使用
2. AndroidをPCに接続して、内蔵ストレージ/SDカードのどちらかのルートディレクトリに上記ファイルをコピーする
   • zip圧縮されているけども、展開する必要はない
3. 電源ボタン + 音量を下げるボタンでメンテナンスモードに入る
4. "Enter SD Download mode"を選択、"Apply update from internal(external) storage"を選択
5. 先ほどコピーしたファイルを選択
6. 自動的にアップデートが始まるので、終わるのを待つ
7. これで完了

おそらく、バッテリが切れた時に内部のロックファイルに不整合が生じたか、
カーネルモジュールが破損しているような印象。
そこで、強制的にファームウェアを更新すればOK。
原因は結局深くはわからず。adb logcatでログを見たりもしたけど、いまいち理由はわからなかった。。。

1. Download latest firmware from ASUS support page
   • http://www.asus.com/jp/Phone/ZenFone_5_A500KL/HelpDesk_Download/
   • In my case, using "ASUS ZenFone 5 (A500KL) software Image: V11.4.6.103 for JP SKU only*
2. Android connect to PC and the above file copies to the root ofInternal storage of External Storage
   • the file compressed by ZIP, but it's not need to expansion
3. Press Power Button and Volume Down Button, then it will be maintenance mode
4. Select "Enter SD Download mode", next is select "Apply update from internal(external) storage"
5. Select the above file copies from PC
6. Update is automatically starting. Waiting for finish.
7. Complete!

おそらく、バッテリが切れた時に内部のロックファイルに不整合が生じたか、
カーネルモジュールが破損しているような印象。
そこで、強制的にファームウェアを更新すればOK。
原因は結局深くはわからず。adb logcatでログを見たりもしたけど、いまいち理由はわからなかった。。。

Maybe, when the buttery is low and shutdown,
some problem is happen the Lock file had been no consistency or Kernel modules are broken.
I think it can repair by overwrite latest firmware to current firmware.
Finally, the cause is not understand.

I had thought I would move to other place before half years ago.
But the plan has changed after a year for family reasons.
Umm... it's a little problem of the future plan.

半年ぐらい前から引っ越ししようか、という話はあったんだけど、もう1年先送りになった。
うーん、先のことを考えるとちょっと出端をくじかれた感じ。

In Spring season, cedar pollen is increasing and
a lot of people become to allergy to pollen.
I have a allergy to pollen too.
In my case, I get heavy sneezes.
When I have a sneeze, it will rob my vitality.
At 9 or 10 pm, I get so sleepy by it.

花粉症の季節になってきた。
主に自分の場合だとくしゃみがひどい。
くしゃみがひどいとすごく体力を使うので、
夜の9時頃になると意識がもうろうとし始める。。。

台湾南部地震で被災されました皆様に心からお見舞い申し上げます。

ところで、何か連日の報道を見てておかしいなぁと感じてたんだけど、
やっぱりこういうことなのね…。

いま日本人にして欲しいのは募金じゃない…台湾現地に住むブロガーの叫びに反響
http://spotlight-media.jp/article/246152118436948527

最初の地震の報道を聞いて、「あ、募金しよう」と思いたち赤十字のページ見ても何も出てない。
数日様子見てみようかーと思いながら、なぜ募金活動をしないか？考えてみて、
「あれ、そういえばあのマンション以外に何か被災してるんだっけ…？」と思いめぐる。
結局、亡くなってる方も例のマンションがほとんどで、周りは特に大きな問題にはなってないんだろうな。

最近、メディアとかそれを取り巻くいろいろに対して、残念なことが多いなと…。

（追記：2016年2月10日 8時49分）

と思ったら、赤十字からも募金開始しましたね。単に時間差の問題だったかな。

いろいろとあって、パソコン向けのメモリ（DDR4とか）の構成について
仕様を見てたんだけど、結構奥深いなと
ちょっと気になったところをいくつか上げてみた

メモリの相性問題

自作PCとかでよくある問題だけど、原因の一つとしては
基板上のメモリの配線レイアウトとの整合性が合わないこと。

あまりマザーボード側を疑うことは少ないだろうけど、
ノウハウがないメーカーとか安いメーカだと
基板設計の問題で相性問題が出やすくなるのかなと思った

あと、温度要因もあったりするので、
memtestで通れば問題ないかというとそうでもないよね…。

DDR4のアクセス速度

DDR SDRAMは2つのDRAMを同時にフェッチして、
2つのデータをバースト転送することで、メモリクロックに対して2倍の転送速度となる。
DDR2, 3はDDRに対して2倍、4倍のバースト長にする（同時に同時にフェッチするDRAMも2倍、4倍）ことで
2倍、4倍の転送速度が実現できる。
（メモリクロックは世代が進んでもほとんど変わりはない。
理由は微細化が進んだぶんが容量に転嫁されてるからとか…）
以下の図を参考にするとわかりやすいです。

[拡大画像]【後藤弘茂のWeekly海外ニュース】 JEDECが「DDR4」とTSVを使う「3DS」メモリ技術の概要を明らかに
http://pc.watch.impress.co.jp/img/pcw/docs/488/696/html/20.jpg.html

問題はDDR4の場合、8倍になるか？という話
実はDDR4の場合は同時にフェッチするDRAMの数はDDR3の場合と変わっておらず、
バンクグループを2つ同時に読むことで8倍の転送速度を実現している。
ただ、このバンクグループが問題になり、一回のフェッチで
異なるグループを読む場合は8倍の転送速度となる。
しかし、同一のグループを読む場合は、性能低下が発生してしまう。
この点が今まで知らなかったし、あまり認知はされていないような気はします。

外出先とかで親戚に「あのときの写真がほしい！」とか言われたとき
Dropboxの公開リンクを送ってあげればすぐに見られる。これが結構便利だった

何故か、rbenvを入れてからcronに登録したrubyの処理が失敗する…。
結論から言うと、rbenv自体は直接関係なかった。
PATHの設定を変えた際にbashのパス解決ができなくなっただけだと思う。

エラーとしては以下のものが出ていた。文字化けして意味がわからず…。

/usr/bin/env: bash: ã 㠮よ㠆㠪ファイルやディレクトリ㠯㠂り㠾㠛ん

localeを英語にすればよかったのだろうけど、推測で以下のエラーだと仮定。

/usr/bin/env bash: No such file or directory

export PATH=""で環境変数をまっさらにしてから、
cronに設定している環境変数を一つ一つ追加して確認。
すると、実は/binと/sbinのパスが抜けている事がわかった。

なぜこのタイミングで問題が露呈したのかはわからないけど、
おそらく、bash_profileのPATHにrbenvを追加したことが影響してるのかな…？
とりあえず解決したので深追いはしないことにした。

複数スレッドで同時にsleepを行ったとき、
sleepの引数の時間より数倍の時間がかかってしまう事があった。
いろいろと試行錯誤はしてみたけど、イマイチ理由はわからず…。
とりあえずメモだけしておく。

背景

今回のプログラムはとあるネットワーク上のサーバ、以下の4つのスレッドが存在しています。

• 接続待機スレッド（accpet thread）
• データ送信スレッド（send thread）
• データ受信スレッド（recv thread）
• メッセージルーティングスレッド（msg thread）

各スレッドはポーリングをしていて、それ以外の時間はコンテキストスイッチのために
定期的にsleepを入れるようにしています。
今回の問題は、この"定期的なsleep"です。

ruby-profで各スレッドの処理負荷を計測すると以下のとおりとなります。

接続待機スレッド（accpet thread）

 Measure Mode: wall_time
 Thread ID: 70010781717220
 Fiber ID: 70010781716680
 Total: 6.980623
 Sort by: self_time
 
  %self      total      self      wait     child     calls  name
  45.84      6.876     3.200     3.677     0.000       52   Kernel#sleep
   1.44      0.101     0.101     0.000     0.000        1   TCPServer#initialize
  0.01      0.001     0.001     0.000     0.000       51   <Class::IO>#select

データ送信スレッド（send thread）

 Measure Mode: wall_time
 Thread ID: 70010781712700
 Fiber ID: 70010781619120
 Total: 5.175139
 Sort by: self_time
 
  %self      total      self      wait     child     calls  name
   1.94      5.174     0.100     5.073     0.000       52   Kernel#sleep
   0.01      0.001     0.001     0.000     0.000       17   IO#write
  0.01      5.175     0.000     0.000     5.175        1   NodeSendTask#run

データ受信スレッド（recv thread）

 Measure Mode: wall_time
 Thread ID: 70010781622000
 Fiber ID: 70010781619360
 Total: 5.175198
 Sort by: self_time
 
  %self      total      self      wait     child     calls  name
  68.86      5.167     3.564     1.604     0.000       52   Kernel#sleep
   0.02      0.001     0.001     0.000     0.000       69   <Class::IO>#select
  0.02      5.175     0.001     0.000     5.174        1   NodeRecvTask#run

メッセージルーティングスレッド（msg thread）

 Measure Mode: wall_time
 Thread ID: 70010781621200
 Fiber ID: 70010781619380
 Total: 5.175243
 Sort by: self_time
 
  %self      total      self      wait     child     calls  name
   0.02      5.173     0.001     5.172     0.000       52   Kernel#sleep
   0.01      5.175     0.000     0.000     5.175        1   MessageRouter#run
  0.00      0.000     0.000     0.000     0.000       16   JSON::Ext::Generator::State#generate

問題点

今回sleepの引数は全て1msに設定しています。

上記のデータのうち、accept threadとrecv threadでsleepの回数に対する
時間がaccpetの場合60倍、recvの場合は70倍近くかかってしまっています。
1msのはずが約60ms。。。

おそらく、コンテキストスイッチの問題で遅くなっているのかなぁとは思っていますが、
それにしても時間がかかりすぎていてあまり納得はできていません。
もう少し調査方法を変えて見ながら探ってみたほうが良いのかも？

セブ島へ年末年始は行ってきました。
寒いのが嫌いなので、暖かいところで過ごせたのは良かった。
日本帰ってきたら「寒い…」とばかり言っています。

セブ島は主に2箇所、日本人がリゾートで行くマクタン島と
あまり一般的ではない（と思っている）バンタヤン島に行ってきました。

前者はMaribago Bluewaterというところに泊まって、年越しもここで迎えました。
プライベートビーチがあることが売りの一つだったりするんですが、
水質が綺麗ではなく非常に良くなかったです…。
一方でプールで過ごせば、リゾート気分が味わえるので良いかなと思います。

いずれにしても、繁忙期にわざわざ行くようなところではなく、
閑散期のちょっと安めの時期を狙っていくのが良さそう…。

後者のバンタヤン島、これが非常に良かった。
まず、日本人含め全体的に観光客が少ない。
国内でのツアーの取り扱いがないし、ローカルバスに乗ることになるので
少し難易度が高いことが理由だと思う。
セブシティから路線バスに3時間のって、さらにフェリーで1時間近くかかる。
観光客が少ない分、ホテルやその島全体がのほほんとした空間になっていて、
普段の疲れを癒やすのには本当に良かった。

また、海の水もこちらは綺麗。海を楽しむための場所、という感じがして良かった。
今回泊まったホテルはMarlins Beach Resortというところ。
海側の部屋にしたら、テラスからすぐ海に出ることができるし、
そのままテラスで海を見ながらくつろぐこともできるので最高でした。
お値段的にも1泊2人で1万ぐらいなので、Maribagoとかに比べるとそりゃもう…。
ただ、お風呂とかトイレとかはダメだったかな。。。

という感じで、ホテル事情を中心に書いてみました。
まぁMarbagoが良くなかったという話ではなく
バンタヤン島が最高でした、っていう話でした（笑）
（サービスとか含めると、Maribagoは日本人が行きやすいと思います）

今年も皆様お世話になりました！

今年一年を振り返ってみて、一番は結婚したことかな。
婚姻は3月、結婚式は9月でいろいろと準備が大変だった。
でも、思い返してみると楽しかったなぁ〜
また、いろんな方にご協力をいただいて、非常にありがたかったです。

あっという間の1年、気づくと年末だったなぁ…。
成果という点では、正直目に見えたものがあまり出ていない。
ただ、その下地となる考えや気持ちはまとまってきたと思う。
一つにはとにかくいろいろとやってみることかな。

もう26ということもあり、やっぱり焦る気持ちはある。
ただ、自分が面白い・役に立つと考えることをすべきと考えると、
自然のままに自分で考えて、それを形にできることが大切だと
この一年で思ったところ。

来年はそんな考えをまとめて、
結果を出せる一年にしていきたいと思います！

Now, I'm moving to Narita Airport.
I will go to Cebu!
I will be relaax and getting energy to the new year.

セブ島に行くため、現在成田に移動中
今年一年の疲れをとって、来年の活力を貯めてきます～

日本人がしゃべる英語であれば何とか聞き取れて、理解できるようにはなってきている
が、外人の喋る声がほとんど聞き取れないんだよなぁ…。いや、ほんとに恐ろしいくらい。。。

たぶん原因の一つに普段の勉強がNHK Radio Newsだったり、
英会話にしても日本人の癖がわかってる人（それでいて、日本人がわかるように喋ってくれる）だから
偏ってきちゃうんだろうなぁ
クリアな音は問題ないけど、つながった音（いわゆるリンキング）が聞き取りづらい

英語舌のつくり方 ――じつはネイティブはこう発音していた!
http://www.amazon.co.jp/dp/4327440841

これとかどうだろうかなぁ
スピーキングに焦点を当てている本だけど、規則を知るという意味で良さそう
（正直、日本人がスピーキングをそこまでこだわらなくても、
双方の必要性がある状況であれば聞き取ってくれることが多いとは思う…。
逆に、英語チックな日本語はどれだけおかしくても聞き取れるわけだし。。。）

あと、Podcastも変えてみようと思っていろいろと聞いてみて、BBCが良さそうかな
比較的クリアにしゃべっているのでまだ聞き取りやすいけどね。。。

半年前に予約したので、念のためreconfirmの連絡をしてみた
行き先はフィリピン（セブ）、予約した3つのホテルにメール

結果、2件はエラーメールで弾かれる…。まぁそうだよねー

ひとまず、一番確認したかったところは確認できたので、
後は仮にダブルブッキングになっても諦めがつきそう
まぁそれも含めて旅の楽しみということで

事前に書き込むデータが決まっている場合（例えば、CSVからDBに入れる場合など）に早くする方法

一度In MemoryのSQLiteのDBを作成し、その中にデータを展開する
その後、SQLiteのBackupを使用して、DBの中身をファイルに書き出す
Rubyの場合は以下のサンプルコートが使える

http://www.rubydoc.info/github/luislavena/sqlite3-ruby/SQLite3/Backup

この方法は行数が多いデータ等には向いている
手元だと1500万レコードを追加するのに6時間ほどかかっていたのが
上記の方法を使って20分ほどに短縮することができた
要は、単純にdbへのwriteが遅かったってことだろうね

某バラエティ番組でこの話が出ていて、何も解説がされていなかったので。
ざっくりと言ってしまうと、CELPが使われているからってこと。

Mobile：CELP【しーいーえるぴー、せるぷ】
http://www.itmedia.co.jp/mobile/0307/30/n_keywords.html

技術の立場からすると、逆に「特徴的な声から作ってるんだよ」と言えれば、
一般のかたにもわかりやすい表現になるね。

git pullに関していろいろと調べてみると、あれこれと書かれてるんですが、
正直まどろっこしいというかややこしいというか…。

git-pullは幸い（？）なことにシェルスクリプトなので、
echoを入れてコマンド見れば良いんじゃないかなと思うんです。

ということで、主によく問題とされている以下の2点について調べてみました。

• git pull origin <branch>:<branch> をやってはいけない理由
• git pullするとカレントブランチが更新される理由
  • さらに言うと、単純なgit pullだと追跡ブランチも更新される理由（「追跡ブランチ」は後述）

（本記事はgit version 1.9.5 (Apple Git-50.3)をベースとして記述しています）

以下のようなリポジトリ構成の場合、

$ git branch -a
  devel
* master
  remotes/origin/devel
  remotes/origin/master

git pullは以下の結果となる。

$ git pull origin devel:devel
git fetch     --update-head-ok "origin devel:devel" || exit 1
git-merge              "$merge_name" HEAD 312fc9f10fc4cba111d72f322d6a71147d34d976

$ git pull origin
git fetch     --update-head-ok "origin" || exit 1
git-merge              "$merge_name" HEAD b909223d2d6094374e86bf32b036ff341ce149d6

git-merge

ここで注目するべきは2箇所。まず1つはgit-mergeの引数。
HEADにあるリビジョンをマージするから、 カレントのブランチにマージされるんです 。
git-pullのドキュメントにも

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch.

となっている。
このことから、リモートブランチをpullすることを期待して、"git pull origin <branch>:<branch>"すると
カレントブランチにマージされてしまいます。
また、上記の事から"git pull"だけだとカレントブランチに対しての更新は、意図通りのものとなります。

git fetch

もう1つはgit fetchの挙動。
git fetchはoriginのみを指定した場合は、originの追跡ブランチをすべて更新し、さらに追跡ブランチに対応するローカルブランチを更新します。
詳細な説明は以下のとおり。

When git fetch is run without specifying what branches and/or tags to fetch on the command line,
e.g. git fetch origin or git fetch, remote.<repository>.fetch values are used as the refspecs---they specify which
refs to fetch and which local refs to update.
The example above will fetch all branches that exist in the origin (i.e. any ref that matches the left-hand side of the value,
refs/heads/) and update the corresponding remote-tracking branches in the refs/remotes/origin/ hierarchy.

git fetchだけを試しにやってみると

$ git fetch origin
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:yasuharu/test
   312fc9f..c1f1af3  devel     -> origin/devel

の通り、fetchだけでdevelは更新されます。
このことから、git pullするとカレントブランチ以外の追跡ブランチも更新されることがわかります。

追跡ブランチについて

以下のページが分かりやすかったです。

• 追跡ブランチ (tracking branch) というブランチが何なのか調べた - snowlongの日記

  • http://snowlong.hatenablog.com/entry/2015/03/12/212455

• [git]ローカルブランチがどのリモートブランチを追跡してるのか確認する方法 - dackdive's blog

  • http://dackdive.hateblo.jp/entry/2014/02/02/235439

git pull しても更新されない

git pullしても以下のエラーで更新されない場合、追跡ブランチに登録されていないです。

 $ git pull
 There is no tracking information for the current branch.
 Please specify which branch you want to merge with.
 See git-pull(1) for details
 
     git pull <remote> <branch>
 
 If you wish to set tracking information for this branch you can do so with:
 
    git branch --set-upstream-to=origin/<branch> devel

もし、リモートブランチが"origin"の場合、説明の通りにすればOK。

git branch --set-upstream-to=origin/devel devel

git pull時のmergeするリビジョン

リビジョンはgit fetchした後の、.git/FETCH_HEADから取得します。
「not-for-merge以外のもの」（=カレントブランチ）がmergeするリビジョンになります。

$ git checkout devel
Switched to branch 'devel'
$ git fetch origin
$ cat .git/FETCH_HEAD
c1f1af3d7f4a02c252effb5ad8cdd390b541fff1                branch 'devel' of github.com:yasuharu/test
b909223d2d6094374e86bf32b036ff341ce149d6        not-for-merge   branch 'master' of github.com:yasuharu/test

$ git checkout master
Switched to branch 'master'
$ git fetch origin
$ cat .git/FETCH_HEAD
b909223d2d6094374e86bf32b036ff341ce149d6                branch 'master' of github.com:yasuharu/test
c1f1af3d7f4a02c252effb5ad8cdd390b541fff1        not-for-merge   branch 'devel' of github.com:yasuharu/test

NHK WORLD RADIO JAPANのPodcastのscriptが無いと
以下の日記で書きましたが、実はほぼ同様のものがあることがわかりました…。

• transcript付きの英語学習向けpodcast - yasuharu's Diary
  • http://yasuharu.net/diary/2826

実はこの日記を書いたタイミングで、NHKの要望に「script公開してほしいなぁ」と
メールしまして、（日曜日にもかかわらず）1時間ほどで返事がかえってきました。
結論としては、NHK WORLD RADIO JAPANは以下のサイトで公開されている
原稿がもとになっているとのこと。

• Top Stories - News - NHK WORLD - English
  • http://www3.nhk.or.jp/nhkworld/english/news/

最新のNHK WORLD RADIO JAPANの配信と聴き比べてみたら、
確かに原稿の部分は全く同じものを流していました。
ただ、NHKからの回答によると以下のケースはあるらしい。

• 配信時間の関係で一部カットされているもの
• 掲載されている時間に制限がある（概ね最初のアップロードから48時間）

最後の制限は少し気になるけど、まぁ毎日聞くんであれば問題ないかな。