少し前に日野にできて気になったお店
ねぎ醤油ラーメンでいきました
思わずつゆをほとんど飲んでしまう、味に飽きがなくていい感じ
麺がなんか普段食べるのと違うな?という印象があったけど、何だろう?
久しぶりに当たりと思えるお店に出会ったかな
台湾南部地震で被災されました皆様に心からお見舞い申し上げます。
ところで、何か連日の報道を見てておかしいなぁと感じてたんだけど、
やっぱりこういうことなのね…。
いま日本人にして欲しいのは募金じゃない…台湾現地に住むブロガーの叫びに反響
http://spotlight-media.jp/article/246152118436948527
最初の地震の報道を聞いて、「あ、募金しよう」と思いたち赤十字のページ見ても何も出てない。
数日様子見てみようかーと思いながら、なぜ募金活動をしないか?考えてみて、
「あれ、そういえばあのマンション以外に何か被災してるんだっけ…?」と思いめぐる。
結局、亡くなってる方も例のマンションがほとんどで、周りは特に大きな問題にはなってないんだろうな。
最近、メディアとかそれを取り巻くいろいろに対して、残念なことが多いなと…。
(追記:2016年2月10日 8時49分)
と思ったら、赤十字からも募金開始しましたね。単に時間差の問題だったかな。
脳科学の視点から見た、人間のくせとか考え方を客観的に見つめた本
脳には妙なクセがある (扶桑社BOOKS)
http://www.amazon.co.jp/dp/B00CU5JXME/
さらっと読んでみると「あぁ、確かにこれある」って思うことが多いね。
と同時に、自分が無意識的にやっている癖があるんだよ、ってことを
多くの人が知ってくれると、議論してて困ることが少ないんだけどな…とも思ったり。
ま、まずは自分自身にあてはめて、うまく脳と付き合って行けると良いね。
気になったポイントは以下のとおり。
両国のポパイ、行ってきました。
常時いろんな種類のビールがあるようで、期待通りでした!
ただ、金曜日の夜ということもあって、店内は激混み。
店員さんが疲れてる感がちょっと気になったな(決して対応が悪いわけじゃないけど…)。
金曜日以外とか早い時間とか、さくっと飲んで帰るのが良さげなのかも。
当座預金のマイナス金利適用残高、当初は10兆円程度
http://jp.reuters.com/article/boj-idJPKCN0VC0UJ
記事見てて、210兆円も当座預金あって利息0.1%って
利子だけで2100億円なんだけど、どーやってまかなってるの?と気になった。
そういえば、日銀って上場してるわけだしIR的なものはあるよね、と
調べてみるとあったあった。
平成26年度業務概況書 :日本銀行 Bank of Japan
http://www.boj.or.jp/about/activities/act/act15.htm/
単位が億円で書かれてて、もう何がなんだかわからないけど
要点だけ見てみると以下のようになる。
平成26年度の損益の状況についてみると、経常利益は、前年度比4,331億円増益の1兆7,137億円となった。
(日本銀行 平成26年 業務概況書 33ページより引用)
内訳は国債で1兆円、為替の損益で700億円。国債の利回りは0.443%とのこと。
これだけ巨額の運用していると、0.4%の利回りでもすごい額になるんだな…。
ちなみに、余剰金がどうなるかと気になったけど、
(上場しているので)配当金、準備金と差し引いて、残りは国庫に納付するんだね…。
法人税、住民税及び事業税を差し引いた後の当期剰余金は、前年度比2,847億円増加の1兆90億円となり、ここから法定準備金積立額
2,522億円(当期剰余金の25%相当額)、配当金(500万円、払込出資金額の年5%の割合)を差し引いた残額7,567億円を国庫に納付することとした。
(日本銀行 平成26年 業務概況書 33ページより引用)
運用金額は、図表19から270兆円、ざっくり年金の倍の金額を運用していることになるのね。
こうやってお金の流れを見てると面白い。
前回の日記に缶ビールの銘柄ってよくわからないよね、と書いて
やっぱり確かめてみないとわからないよねと思い試してみた。
各社の代表的なものを購入。
一社抜けてる気がするのと、さすがに飲みきれないと思い断念。まぁプレモルは美味しい。
キリンの代表がこれなのか? という話は、後から調べてみて気づいた。キリンラガービールの方なのね。
飲んでみた印象、スーパードライだけは味が薄くてわかりやすい。
他の2つは違いはわかるんだけど、飲んで銘柄当てるのは無理だなぁ…。
味の好みとしては、スーパードライ以外になるね。
ただ、スーパードライは薄いけれども、何本も飲む場合は飽きが来づらいかなぁ。
やっぱり、結論としてはどれのんでも美味しい、かな。
「とりあえずビール」は昔の話 ビール系飲料出荷「過去最低」をまた更新
http://www.j-cast.com/2016/01/31256560.html
「とりあえずビール」はそのことよりも、お年寄りが増えるに連れて
飲む量が変わってるのもあると思うんだけど…。
売るターゲットがシュリンクしていて他に転用できる技術でない以上、
海外で頑張ってもらえればというところ。
(キリンのブラジルの件とかあまり良い話は聞かないけど)
まぁそれはさておき、日本のビールを飲んでて、あまり味の違いがよくわからないと思う。
確かに生ビールと缶ビールは違う、これはわかる。
ただ、缶ビールの銘柄で「どれがいい?」って聞かれると困ったり。
これってみんなわかるものなのかなぁ、といつも不思議に思ってしまう。
実際のところとしては、どれ飲んでも美味しいと思えるので
そういう意味では都合の良い舌をしているなと。
単に味覚音痴なのかもしれないけど…。
いろいろとあって、パソコン向けのメモリ(DDR4とか)の構成について
仕様を見てたんだけど、結構奥深いなと
ちょっと気になったところをいくつか上げてみた
自作PCとかでよくある問題だけど、原因の一つとしては
基板上のメモリの配線レイアウトとの整合性が合わないこと。
あまりマザーボード側を疑うことは少ないだろうけど、
ノウハウがないメーカーとか安いメーカだと
基板設計の問題で相性問題が出やすくなるのかなと思った
あと、温度要因もあったりするので、
memtestで通れば問題ないかというとそうでもないよね…。
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倍の転送速度となる。
しかし、同一のグループを読む場合は、性能低下が発生してしまう。
この点が今まで知らなかったし、あまり認知はされていないような気はします。
海外キャッシングの方法として代表的な方法 + Sony Bank Walletでの比較をしてみた。
代表的な方法としては以下のとおり。
使用したシートは以下においておきました。
間違えなどありましたら、ご指摘いただけるとありがたいです。
https://docs.google.com/spreadsheets/d/1Ajvtjo-JnyEUyQSWqPV-cgys2ZtKmaAYk3vqW49QF4A/edit#gid=0
結果はというと以下のような感じ。
クレジットカードは注釈の内容が重要。
キャッシング金利が高いので、明細に載ったらすぐに繰り上げ返済しないとダメ。
両替は意外と悪く無いかも?ただ、お店によるので一概には何とも。お金持ち歩くリスクもあるしね…。
そうなると、Sony Bank Walletが良い、という結論になりそうだけど、実際問題としてどこまで差があるか?
実際に海外でキャッシングしてみると、犯罪防止のためか1度におろせる金額が
決まっていたりして、実はATMの手数料が…という話もある。
また、差がつくと行っても短期の旅行だと言っても1000円程度でしょう。
トータルで見ると、個人的にはSony Bank Walletか割高でも国際キャッシュカードあたりが
一番面倒ごとが少なくて良いのかなと思いますね。
ソニー銀行が「Sony Bank Wallet」という海外向けの面白い商品を出していた。
気になったのは以下の2点。
海外で現地通貨をおろす場合、クレジットカードを使うようにしている。
ただ、これがいろいろと落とし穴があって、結構気を使うことが多い。
VISAデビットであれば、即時決済になるので金利の問題もないし、
スキミングは口座の残高の範囲なので良い。
後は後者の外貨預金口座からの直接出金、
今ちょうど円高進行というのもあって興味が湧いてくる。
他のカードとの比較をしてみようかな。
外出先とかで親戚に「あのときの写真がほしい!」とか言われたとき
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つのスレッドが存在しています。
各スレッドはポーリングをしていて、それ以外の時間はコンテキストスイッチのために
定期的にsleepを入れるようにしています。
今回の問題は、この"定期的なsleep"です。
ruby-profで各スレッドの処理負荷を計測すると以下のとおりとなります。
1Measure Mode: wall_time 2Thread ID: 70010781717220 3Fiber ID: 70010781716680 4Total: 6.980623 5Sort by: self_time 6 7 %self total self wait child calls name 8 45.84 6.876 3.200 3.677 0.000 52 Kernel#sleep 9 1.44 0.101 0.101 0.000 0.000 1 TCPServer#initialize 10 0.01 0.001 0.001 0.000 0.000 51 <Class::IO>#select
1Measure Mode: wall_time 2Thread ID: 70010781622000 3Fiber ID: 70010781619360 4Total: 5.175198 5Sort by: self_time 6 7 %self total self wait child calls name 8 68.86 5.167 3.564 1.604 0.000 52 Kernel#sleep 9 0.02 0.001 0.001 0.000 0.000 69 <Class::IO>#select 10 0.02 5.175 0.001 0.000 5.174 1 NodeRecvTask#run
1Measure Mode: wall_time 2Thread ID: 70010781621200 3Fiber ID: 70010781619380 4Total: 5.175243 5Sort by: self_time 6 7 %self total self wait child calls name 8 0.02 5.173 0.001 5.172 0.000 52 Kernel#sleep 9 0.01 5.175 0.000 0.000 5.175 1 MessageRouter#run 10 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
技術の立場からすると、逆に「特徴的な声から作ってるんだよ」と言えれば、
一般のかたにもわかりやすい表現になるね。