住民税を口座引き落としにしないたった一つの理由
6月といえば、住民税の通知書が届く時期ですね。みなさんはどのように住民税を支払っていますか?やっぱり口座引き落としでしょうか。
確かに口座引き落としにしてしまえば納付を忘れる心配もないし、一度手続きを済ませてしまえばあとは放っておけばいいので楽でいいですよね。住民税の封筒の中に口座引き落としの申請書も同封されているので、反射的に手続きを進めたくなってしまいます。
でもその手続き、ちょっと待った!
住民税の支払いは WAON でしませんか?
WAON とは
イオンが提供している電子マネーです。他の電子マネーと同様、事前にチャージしておけば買い物の支払いがスムーズに行えます。
なぜ WAON なのか
住民税をはじめ、収納代行は基本的に現金での支払いとなります。
しかし、ミニストップでは現金だけでなく WAON でも支払うことができるようになっています。2016年の2月に対応できるようになったばかりなので、まだ世間ではあまり認知されていないかもしれませんね。
話を戻します。
WAON で支払うとなぜお得なのか?
その答えは、WAON ポイントが貯まるからです。
こう言うと実は少し語弊があるのですが、詳細は後述します。
ポイントが貯まる仕組み
仕組みについて説明します。
WAON で買い物をすると、200円につき1WAONポイント(1円相当)が付与されるようになっています。
しかし、実のところ収納代行に関しては WAON で支払ったところでポイントが発生することはありません。
そこで重要となってくるのが、WAONカードです。
WAONカードの中には、SUICAのようにオートチャージ機能を搭載しているものが存在します。
オートチャージ機能といえば、残額が不足した場合に自動で一定額をチャージしてくれる便利機能ですね。しかし、WAONカードのオートチャージはそれだけではありません。なんと、オートチャージした金額もまた、ポイント加算の対象となるのです。この機能を利用すれば、収納代行であってもオートチャージ時のポイント加算を狙えるわけですね。
ちなみにWAONカードにはいくつか種類があるのですが、イオン系列店をよく利用する方には『イオンカードセレクト』の取得をおすすめしています。
イオンカードセレクトとは
イオンカードセレクトは
といった機能が搭載されたカードです。
作るのは簡単で、イオン銀行口座を開設する際に一緒に作れます。口座開設しなくても作れることは作れますが、こちらの記事に書いた通り、積立用途としては最強の銀行ですので、ぜひ口座も作っておきましょう。
どれくらい得をするのか
では、実際に住民税をWAON払いすることでどの程度得をするのかを計算してみます。
オートチャージでのポイント化レートは、200円につき1ポイントです。そして、一度に収納代行をWAONで支払うことのできる額の上限は5万円となっています。上限を超えた分は現金での支払いとなります。
住民税は通常4回に分けて納付しますので、住民税の総額が20万円以下であれば、全額WAONで支払うことができます。今回は住民税がちょうど20万円だった場合を想定して計算してみます。といっても、20万円を200円で割るだけなんですが。
200,000 / 200 = 1,000ポイント
なんということでしょう。住民税の支払い方法を変えるだけで 1,000 ポイントもゲットすることができました。
これはやらなきゃ損でしょう!
WAONのポイントなんていらない!という方は
WAON ポイントは不要でも、マイルならどうでしょう?WAON はマイルにも移行が可能なポイントなんです。
ちなみにイオンカードセレクトではなくJMB WAON カードを使えば、取得したポイントをそのままマイルとして加算していくことも可能ですよ!
最後に
今回は住民税をWAONで支払う話をしましたが、他にも自動車税や各種公共料金など、様々なシーンで活用できます。
税金は額が大きいですので、せっかくですからキャッシュバックと思ってポイントを狙っていきましょう!
つけ麺屋で本格担々麺を食べてきた
今回のお店はこちら。舎鈴さんです。
このお店はあの有名な六厘舎の廉価版チェーンとなっていて、六厘舎に近い味をお手頃価格でいただくことができます。
本来ならばつけ麺を食べるところですが、ここでつけ麺を食べても何も面白くありません。みんな食べてますし。
そういうわけで、今回はつけ麺を封印して担々麺をチョイスしてみました。
他にもメニューがある中、なぜ担々麺なのか?
それは
担々麺が大好きだから
です。単純明快ですね。
それではその担々麺をご覧いただきましょう。
どーん。
いかがですか?これだけ見たらつけ麺屋とは思えないですよね。
しかし驚くのはこれからです。まずスープをいただいてみると、非常に濃厚で本格的な味がします。辛さもなかなかのパンチ力です。というかめっちゃ辛い。
麺を持ち上げると、濃厚な担々スープが麺に絡みまくっています。若干スープを吸ってる気配もありますが、これがたまりません。濃厚スープの味を余すことなく楽しむことができます。
担々麺好きとして言わせていただきますが、これほど完璧な担々麺にはなかなか出会えません。私は運がいい。
そして、最後にもう一つ重要なな情報をお伝えします。
こちらの担々麺は
690円での提供
となっています。驚くことに大盛りにしても790円という安さ。
なんということでしょう。廉価版とはいえ、安すぎませんか。こんなに安くてうまいのでは、もう他の担々麺を食べに行く気がしませんよ。
みなさんも是非つけ麺だけでなく担々麺も食べてみてくださいね。
あ。一つだけ注意してほしいのが、本当に辛いのでお腹が弱い方は牛乳等胃の粘膜を守るものを摂ってから食べるようにしましょう。
そうでないと、夕方にトイレで第二ラウンド目を戦う羽目になるかもしれません。
そう、いまの私のようにね。
【ブログ開設2ヶ月目】大台の1万PV突破しました!
こんにちは。racchai です。
早いもので、ブログを開設してから2ヶ月が経ちました。というわけで、いろいろと結果を発表していきたいと思います。
PV
タイトルにも書きましたが、なんと1万PVを突破しました!
本日までの合計アクセス数が14150で、先月の合計アクセスが1622でしたので、今月のPVは12,528ということになりました。
なんと1万PV以上も増えたんですね。うれしいです!
記事数
記事数は前回 38 だったところ、現在 76 ということでちょうど倍になりました。目標は 80 と設定していたんですが、残念ながら達成ならずという結果です。
一応毎日更新はしていたものの、忙しくてなかなか一日に複数回投稿ことができませんでした。残念!
読者数
この1ヶ月で読者数が一気に増えました。というか前回の運営報告のときには一人もいなかった気がします。。
現在の読者数はなんと51人!ありがとうございます><
読者が増えると、モチベーションが増えていいですね。
人気記事トップ3
では、2ヶ月目に投稿した中でのアクセス数トップ3を発表したいと思います!
第3位
249PV でこちらの記事が第3位にランクインしました。
個人的にはもっとアクセスが増えてもよかったんじゃないかと思ってるんですが、狙ったものほどアクセスは伸びませんよね。こんなもんです。
第2位
次いでアクセスが多かったのはこちらの記事です。
1記事で1,328PVを集めた上、初のホッテントリ入りを果たしました!ひゃっはー!
Atlassian Japan の公式アカウントでツイートしていただいたこともあって、広く拡散されたのが要因ですね。どんどん拡散されていくのでテンション上がりっぱなしてした。ありがたいことです^^
第一位
そして栄えある第一位はこちら!
なんと400ブクマ超え。1記事で6,342ものPVを集めました。総合でもホッテントリ入りしましたし、ITカテゴリーでは一番上のポジションをキープしていました。もちろん人生初バズです。
もうなんかこの記事がバズってる間は喜びよりも、いろいろ通り越してこわかったです。
当時の気持ちはこちらの記事にまとめましたのでよろしければどうぞ。
ひとこと
先月は毎日平均して20~30アクセスくらいしかなくて、100PVいったら大喜びだったわけなんですが、最近は100PVが最低ラインで200PVを超える日もだいぶ増えてきました。『継続は力なり』は本当だったんですね。
来月は平均500PVくらいになるといいなあ。がんばろう!
find がいらないなんて言わせねえよ!
前回の記事では locate コマンドをご紹介しました。
その結果、友人が
『じゃあもう find いらないじゃん』
とかいうものですから、そういうことじゃないということで find についての記事を書いておくことにします。
find を使うケースはいろいろあるのですが、個人的によく使うコマンド例をご紹介します。
ファイルだけ/ディレクトリだけほしい
find コマンドには -type
オプションが存在しており、ここに指定したタイプで結果を絞り込むことができます。
/etc/nginx
以下のファイルだけほしい場合
$ find /etc/nginx -type f /etc/nginx/naxsi.rules /etc/nginx/mime.types /etc/nginx/koi-win /etc/nginx/scgi_params /etc/nginx/fastcgi_params /etc/nginx/win-utf /etc/nginx/uwsgi_params /etc/nginx/sites-available/default /etc/nginx/naxsi_core.rules /etc/nginx/proxy_params /etc/nginx/koi-utf /etc/nginx/naxsi-ui.conf.1.4.1 /etc/nginx/nginx.conf
/etc/nginx
以下のディレクトリだけほしい場合
$ find /etc/nginx -type d /etc/nginx /etc/nginx/sites-enabled /etc/nginx/sites-available /etc/nginx/conf.d
その他にも、シンボリックリンク(l)やソケット(s)などいろんなタイプを指定することが可能です。
最近作成/更新されたファイルがほしい
例えば、定期的に古いログファイルを削除したいケースなどで利用します。作成されてから30日以上経過したログファイルを探し出したいときは、以下のように実行すればすぐに見つかります。
$ find /var/log/myapp/ -type f -mtime -30
逆に直近30日前のログファイルを出力する場合はこちら。-
を+
に変えるだけです。
$ find /var/log/myapp/ -type f -mtime +30
ちなみにですが、-delete
オプションを付与してやれば検索結果のファイルを削除することもできます。
$ find /var/log/myapp/ -type f -mtime -30 -delete
検索結果を受けてコマンドを実行したい
これもよくやりますね。例えば、/var/log/myapp/{日付}/{時間}/error.log
のようなログファイルがあったときに、すべての日付の13時台のログから特定の文字列を抽出したりします。ちょっと例が特殊ですかね。気にせず実行例を書いてみます。
$ find /var/log/myapp/ -name 13 -type d -exec "grep SomeError {}" \;
少しだけ解説しますと、-exec
オプションの中に実際に実行するコマンドを記載します。実行時に検索結果の各行が{}
に代入され、順番に実行されていきます。最後の \;
がコマンド終了を意味しています。
コマンド自体は少し複雑かもしれませんが、これを覚えておくといろいろと便利なのでおすすめです。
中にはそれ xargs でできるよ!という方もいると思いますが、xargs よりも -exec
の方ができることのバリエーションが多いので好きです。
最後に
紹介する例は少なかったですが、locate コマンドとは利用シーンが明確に異なることがわかっていただけたでしょうか。locate コマンドはファイルが見つからない場合の最終手段で、細かく条件を指定して便利にファイルやディレクトリを検索するためのものが find なのです。find がないと本当に困るんです。
もう find がいらないなんて、言わせねえよ!
locateコマンドなら迷子になったファイルも一瞬で見つかるよ!
あのファイルどこいったかな?あのライブラリはどこにインストールされたんだろう?
そんなときこそ、locate コマンドの出番です。
locate コマンドとは
ローカルに保存されているすべてのファイル名をデータベース化し、その中からファイル検索することができるコマンドです。find のように毎回実ファイルを見に行かないため、高速に処理することができます。
事前準備
locate コマンドはほとんどの場合デフォルトでインストールされています。では何の準備が必要なのかと言いますと、locate コマンド自体はデータベースから検索するだけのコマンドですので、データベースが存在していなければ何もできないのです。したがって、事前にデータベースを作成しておく必要があります。
といっても、こちらのコマンドを実行するだけです。
$ sudo updatedb
ちなみに Mac の場合は locate コマンド実行時に以下のメッセージが出ますので、メッセージに従ってコマンドを打てばOKです。
> WARNING: The locate database (/var/db/locate.database) does not exist. To create the database, run the following command: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.locate.plist Please be aware that the database can take some time to generate; once the database has been created, this message will no longer appear.
初回実行時には全ファイルをデータベース化するので、数分かかります。二度目以降は差分更新になるので、数秒で終わります。
事前準備#2
これで locate コマンド自体は使える状態にはなりましたが、もうひとつやっておかなければならないことがあります。
それは、データベースの定期更新です。ローカルファイルは日々変化していますので、定期的にデータベースを最新にしておかなければ、いざというときに困ることになります。
というわけで、updatedb コマンドは cron で定期実行するように設定しておきましょう。
ファイルを検索してみる
準備ができたら、何かファイルを検索してみましょう。例えば、nginx の設定を変えたいけどどこに設定ファイルがわからないとします。いったん nginx
をキーワードに検索してみましょう。
$ locate nginx /etc/nginx /etc/default/nginx /etc/init.d/nginx /etc/logrotate.d/nginx /etc/nginx/conf.d /etc/nginx/koi-utf /etc/nginx/koi-win /etc/nginx/mime.types /etc/nginx/naxsi-ui.conf.1.4.1 /etc/nginx/naxsi.rules /etc/nginx/naxsi_core.rules /etc/nginx/nginx.conf /etc/nginx/proxy_params /etc/nginx/scgi_params /etc/nginx/sites-available /etc/nginx/sites-enabled /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default /etc/rc0.d/K20nginx /etc/rc1.d/K20nginx /etc/rc2.d/S20nginx /etc/rc3.d/S20nginx /etc/rc4.d/S20nginx /etc/rc5.d/S20nginx /etc/rc6.d/K20nginx /etc/systemd/system/multi-user.target.wants/nginx.service /etc/ufw/applications.d/nginx /lib/systemd/system/nginx.service /usr/sbin/nginx /usr/share/nginx /usr/share/doc/nginx-common /usr/share/doc/nginx-core /usr/share/doc/nginx-common/CHANGES.gz /usr/share/doc/nginx-common/NEWS.Debian.gz /usr/share/doc/nginx-common/changelog.Debian.gz /usr/share/doc/nginx-common/copyright /usr/share/doc/nginx-core/CHANGES.gz /usr/share/doc/nginx-core/changelog.Debian.gz /usr/share/doc/nginx-core/copyright ... ... ...
おっとっと。たくさん出てきてしまいましたね。上の結果を見ればわかりますが、キーワードはディレクトリ名にもマッチしますので、検索対象のファイル名がわかる場合はなるべくファイル名で検索した方がよさそうです。
それでは気を取り直して、nginx.conf
で検索してみましょう。
$ locate nginx.conf /etc/nginx/nginx.conf
一発で見つかりました。しかも検索自体は一瞬なので、ストレスフリーです。
これまで find /
してた人はぜひ locate コマンドを使ってみてください!
【Python】Pillowを使ってサムネイルを生成してみよう
サムネイルといえば ImageMagick ですが、自由にライブラリをインストールできない環境ではアプリケーション内でサムネイルを生成する必要がありますね。
Python では Pillow というライブラリを使ってサムネイルを生成することができますので、本記事では簡単な実装例を紹介してみます。
なお、本記事では Python2.7 ベースで記載することにします。(バイナリを扱う処理は Python3 よりPython2.7の方がわかりにくい気がするので)
インストール
pip を使ってインストールするだけです。
$ pip install pillow
適用にサムネイルを作成してみる
以下は 100x100 のサムネイルを生成するコードです。
from PIL import Image img = Image.open('original.jpg', 'r') thumbnail_size = (100, 100) img.thumbnail(thumbnail_size) img.save('thumbnail.jpg', 'JPEG')
いかがでしょうか?特に内容を解説しなくても、ぱっと見てなんとなく何をしているかわかりますね。シンプルなサムネイルを作る分には、これだけ知っておけば問題ないです。
ちなみに import 文が PIL となっていますが、これは Pillow が PIL プロジェクトの fork であるためです。PIL 自体の開発は止まっていますので、気にせず Pillow を使うようにしてください。
メモリ上でサムネイルを作成する
さきほどのコードはファイルシステムに保存された画像ファイル名を指定して、そのままファイルシステムへサムネイルを書き出す方式でした。
大体の場合はそれで十分なのですが、場合によってはファイルシステムを一切経由せずネットワークのみで完結したいケースもありますので、その方法についても書いておきます。
以下は S3 から読み込んだ画像ファイルをサムネイル化してS3 にそのままアップロードすることを想定したコードになります。
from PIL import Image from StringIO import StringIO from io import BytesIO # S3から画像ファイルを読み込む img_bytes = fetch_image_from_s3() img = Image.open(StringIO(img_bytes)) thumbnail_size = (100, 100) img.thumbnail(thumbnail_size) thumbnail = BytesIO() img.save(thumbnail, 'JPEG') # サムネイルを S3 へアップロードする upload_thumbnail_to_s3(thumbnail.getvalue())
さきほどとは違い、img
オブジェクトはバイトデータを使って取得しています。また、サムネイルの生成についても img.save
には書き出し先として BytesIO を渡すようになりました。注意してほしいのが、この方式はメモリへの負担が大きいですので、サイズの大きい画像ファイルを扱う場合には避けるようにしましょう。
exif 情報を考慮してサムネイルを生成する
JPEG 画像を扱う場合の話ですが、前述のサムネイル処理では exif(Exchangeable digicame-exif file format)情報を反映してくれません。
そのため、オリジナル画像が90度回転しているものをサムネイル化すると、横向きのサムネイル画像が作成されてしまいます。(ウェブサービスでたまに横向きのサムネイルを見かけると思いますが、そのほとんどは exif 情報が反映されていないのが原因です)
そういったことにならないよう、サムネイル作成時にオリジナル画像と同じ向きになるように回転させてやる必要があります。
つまりは、ImageMagick でいう --auto-orient
オプションと同じ処理を自前で用意しなければいけません。
自前で用意と聞くとめんどくさそうな印象を受けますが、ご安心ください。そんなに難しい処理ではありません。
まずは JPEG 画像から exif 情報を抽出します。 exif 情報の抽出には、Image オブジェクトの _getexif
を使います。
img = Image.open('original.jpg', 'r') exif = img._getexif()
次は回転方法を決定するために Orientation 情報を取得します。 exif 情報は辞書となっており、Orientation値 は 0x112 をキーとして取得することができます。
# exif が Orientation値を持っていないこともあるので、1 (回転なし) をデフォルトとして取得するようにします orientation = exif.get(0x112, 1)
Orientation 値を得ることができたら、あとは決められた処理で画像を回転させてあげるだけです。
以下は Orientation 値に対応する回転関数を定義したものです。なお、回転関数については、こちらの記事を参考にさせていただきました。
convert_image = { # そのまま 1: lambda img: img, # 左右反転 2: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT), # 180度回転 3: lambda img: img.transpose(Image.ROTATE_180), # 上下反転 4: lambda img: img.transpose(Image.FLIP_TOP_BOTTOM), # 左右反転&反時計回りに90度回転 5: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT).transpose(Image.ROTATE_90), # 反時計回りに270度回転 6: lambda img: img.transpose(Image.ROTATE_270), # 左右反転&反時計回りに270度回転 7: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT).transpose(Image.ROTATE_270), # 反時計回りに90度回転 8: lambda img: img.transpose(Image.ROTATE_90), } thumbnail_img = convert_image[orientation](img)
やるべきこととしては以上です。あとは回転した画像をサムネイル化してやればOKですね。
では、最終的に必要となるコードを以下にまとめてみます。
img = Image.open('original.jpg', 'r') exif = img._getexif() orientation = exif.get(0x112, 1) convert_image = { # そのまま 1: lambda img: img, # 左右反転 2: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT), # 180度回転 3: lambda img: img.transpose(Image.ROTATE_180), # 上下反転 4: lambda img: img.transpose(Image.FLIP_TOP_BOTTOM), # 左右反転&反時計回りに90度回転 5: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT).transpose(Image.ROTATE_90), # 反時計回りに270度回転 6: lambda img: img.transpose(Image.ROTATE_270), # 左右反転&反時計回りに270度回転 7: lambda img: img.transpose(Image.FLIP_LEFT_RIGHT).transpose(Image.ROTATE_270), # 反時計回りに90度回転 8: lambda img: img.transpose(Image.ROTATE_90), } thumbnail_img = convert_image[orientation](img) thumbnail_size = (100, 100) thumbnail_img.thumbnail(thumbnail_size) thumbnail_img.save('thumbnail.jpg', 'JPEG')
まとめ
いかがでしたでしょうか。ImageMagick ほど楽はできませんが、ある程度なら少ない実装量で実現できることがわかりましたね!
ぜひお試しください。
【祝400ブクマ達成】ホッテントリ入りする喜びと哀しみについて語ってみる【初バズ】
経緯
こちらの記事で初のホッテントリ入りを果たしました!めでたい。
普段だと土日のアクセス数なんて50もいけば良い方なのですが、何気なくアクセス数を確認してみたら3000アクセスを超えているわけです。
人間、本当に驚くと固まるんですね。頭が真っ白になって、何が起きているのかなかなか把握できなかったです。リアルタイムで50-60人ほどのアクセスがずっと続いていることを確認して、ようやくバズっていることを理解しました。
ブログを開設してもうすぐ2ヶ月になりますが、初バズだったので非常に嬉しいです!バズるという現象は、ブログの更新を続けていればいつかは来るものとされていますが、人によっては一年以上かかるという記事を見かけたこともあり、自分はいったい何年かかるかなあと不安に思っていたところでした。
それにしても、公開から5日も経過した記事がなぜここまでバズる結果になったのか。。自分には珍しくささっと書き終えた記事だったこともあり、驚きを隠せません。
喜び
バズったこと自体もうれしいですが、それ以上に大量にブクマコメントをいただけたことが私にとって一番の『喜び』でした。
ブログを書いている人ならわかると思いますが、誰にも読まれていないと感じる状態が一番つらいんですよね。
初めはアクセス数が増えてくるだけでもうれしかったりしました。でも、それはただの数字でしかないわけなので、読まれたい欲を満たすものではないのです。
今回コメントいただいた中には、記事の内容を評価してくださっている方もいて、感激しています。これでまた、当分ブログを続けることが出来そうです。本当にありがとうございます!
哀しみ
ホッテントリ入りはうれしいことばかりではないというのが、今回の発見でした。
一般的には、ネガティブなコメントが付くのが悲しいとか、炎上するのがつらいとかがありますが、私の場合はそれではありません。
二日間ほど総合とテクノロジーカテゴリの上位に掲載されていたものが、突然消え去ったのです。ホッテントリから外れた瞬間、ブログへのアクセスはみるみる落ちていき、もうすでにいつも通りのアクセス数に戻りつつあります。
盛大に盛り上がった後、突如それがなくなってしまったので、心にぽっかり穴が開いたような気持ちです。この喪失感はこれまで経験がありません。
遊びに来ていた孫が一泊で帰ってしまったみたいな気持ちなんでしょうか。孫いないからわかりませんが。
ここ数日は、帰ってしまった孫を想いながら思い出の写真を見るように、6/4 のランキング2位になったスクリーンショットを眺めて懐かしんでおります。
ひとこと
ホッテントリから消えるのはいいですが、一応400ブックマークも付いた記事なんですから、もう少し優しくフェードアウトさせてくれてもいいじゃないですか、はてなさん。