iTunes ConnectのAppアナリティクスでAppStoreのPVが見れるようになってハッピー
何よりもAppStore閲覧数が見れるのがうれしい
バブルデコレータのAppStore閲覧数(ノープロモーションなのでしょぼいPVですが)
https://itunes.apple.com/jp/app/baburudekoreta/id741537396?mt=8
アプリをインストールしてもられればその後はログを仕込むなり何なりでユーザー動向は追えるが、AppStoreのアプリページがどのくらい閲覧数があってどのくらいの割合でインストールまで繋がっているかが今まで分からなかった。
AppStore閲覧数が見えるようになった事で、プロモーション用の画像やアプリ説明文のチューニングをデータを元にして出来るようになった！素晴らしい！
ありがとう、Apple！
[asin:477415783X:detail]
Qiitaに投稿してみた
Qiitaを使ってみた
とある事情から、Qiitaにまとめる必要があったので書いてみた。
結構PVが来る
書いて半日くらいで66PV来ていた。
結構すごいなQiita
kobitoがとりあえず便利すぎる
これ、すごい便利。
デフォルトでチートシートがあるとか、最高。
使い分け？
とはいえ、Qiitaとこのブログの使い分けをどうしようかな。
しばらくは両方使ってみようかな。
Apache SetEnvIfでenvに一つの値しか設定出来なくて困った
ApacheのSetEnvIfは便利
access_logで画像関連のlogを出したくない時にこんな感じの設定を入れる。
SetEnvIf Request_URI "\.(gif)|(jpg)|(jpeg)|(png)|(css)|(js)$" no_log CustomLog /var/log/httpd/access_log combined env=!no_log
Request_URIで別条件も入れたくなった
外部に公開したくないサイトの場合、basic認証をかけるんだけど、LBや監視からのヘルスチェックだけはbasic認証をかけたくない。
SetEnvIfを使ってこんな感じで書けるのだけれど、、、
d.hatena.ne.jp
すでに、Request_URIのenvをno_logで使ってしまっているので、この方法は使えない。
SetEnvIfでkeyとvalueを追加出来るようになったら良いのに！！！
アプリ広告収入 2015/04
個人的に作っているアプリの広告収入
拙作の大した事無いアプリの広告売上を公開しています。
ほとんどのアプリが単なる学習目的でしたがせっかくなので収益化を少しながらしています。
とてもしょぼい金額ですが、反省も込めて。
売上 @nend
ときめきエキスプレスStation ¥27
https://itunes.apple.com/jp/app/tokimekiekisupuresustation/id660044163?mt=8&at=10l8JW&ct=hatenablog
バブルデコレータ(iOS) ¥407
https://itunes.apple.com/jp/app/baburudekoreta/id741537396?mt=8&at=10l8JW&ct=hatenablog
バブルデコレータ(android) ¥369
https://play.google.com/store/apps/details?id=org.waremon.bubble2&hl=ja
高額喫煙納税 ¥0
https://itunes.apple.com/jp/app/gao-e-chi-yan-na-shui/id902170473?mt=8&at=10l8JW&ct=hatenablog
計 ¥803
売上 @AdMob
THE じゃんけん ¥35
https://play.google.com/store/apps/details?id=org.waremon.janken&hl=ja
原発を運転せよ ¥0
https://play.google.com/store/apps/details?id=org.waremon.fissioin2&hl=ja
音神経衰弱 ¥0
https://play.google.com/store/apps/details?id=org.waremon.soundmemory2&hl=ja
計 ¥35
CentOS7でdaemontoolsを動かす
CentOS6からはインストールしただけだとdaemontoolsは動かない
CentOS6の場合はこちら
wp.kaz.bz
CentoOS7の場合はどうすんだ？
centos7はデーモンをsystemctlで動かすので、daemontoolsもそれに従うと良さそう。
こんな感じでdaemontools.serviceを作る
# cat /etc/systemd/system/daemontools.service [Unit] Description=daemontools Start supervise After=getty.target [Service] Type=simple User=root Group=root Restart=always ExecStart=/command/svscanboot /dev/ttyS0 TimeoutSec=0 [Install] WantedBy=multi-user.target
そのあと以下を実行でめでたく動きます
systemctl enable daemontools systemctl start daemontools
MySQLでdatetimeに10000年を指定すると残念な事になる。
MySQLのBETWEENに'10000-01-01 00:00:00'のように9999年以上の値を入れると予期せぬ結果が返ってくる
MySQL ver : 5.6.20
こんなテーブルに対して
mysql> select * from date_test_table; +---------------------+ | date | +---------------------+ | 2015-01-01 00:00:00 | | 9999-01-01 00:00:00 | | 0000-01-01 00:00:00 | | 1015-01-01 00:00:00 | | 3015-01-01 00:00:00 | +---------------------+
BETWEENのminのほうに1000年と間違えて10000年を指定してしまった。
普通はエラーになるだろうと思ったらなぜかレコードが返ってきた。
謎い。
mysql> select * from date_test_table where date between "10000-01-01" AND "2050-01-01"; +---------------------+ | date | +---------------------+ | 2015-01-01 00:00:00 | | 0000-01-01 00:00:00 | | 1015-01-01 00:00:00 | +---------------------+
どうやら挙動的には0000年になっているっぽい
DateTimeは0年から9999年まで
そもそもMySQLのDateTime自体が9999年までしか対応していない。
更新はエラーだけど参照はwarning
実際に10000年に関してのクエリを打ってみると、更新はエラーになるが参照はwarningという不思議。
mysql> insert date_test_table set date = '10000-01-01 00:00:00'; ERROR 1292 (22007): Incorrect datetime value: '10000-01-01 00:00:00' for column 'date' at row 1 mysql> select * from date_test_table where date = "10000-01-01 00:00:00"; Empty set, 2 warnings (0.00 sec) mysql> show warnings; +---------+------+--------------------------------------------------------------------+ | Level | Code | Message | +---------+------+--------------------------------------------------------------------+ | Warning | 1292 | Incorrect datetime value: '10000-01-01' for column 'date' at row 1 | +---------+------+--------------------------------------------------------------------+
BETWEENは空文字でも受け付ける
一方で、BETWEENは空文字でもクエリを受け付ける仕様のようだ。しかも自動的に最小の値になっているっぽい。
mysql> select * from date_test_table where date between "" AND "2050-01-01"; +---------------------+ | date | +---------------------+ | 2015-01-01 00:00:00 | | 0000-01-01 00:00:00 | | 1015-01-01 00:00:00 | +---------------------+
BETWEENとDateTimeの仕様の合わせ技でおかしな事に
この二つの挙動が合わさると、BETWEENのmin側に10000年を入れるとempty(="")と評価されて、0000年からのレコードを返してしまうようだ。
まとめ
そもそも、10000年を渡す方が悪いのでアプリ側でバリデーションをしっかりしましょう。という事で。
![エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド](https://m.media-amazon.com/images/I/41oqE-9dM2L._SL500_.jpg "エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド")
