oranie's blog

旧:iをgに変えると・・・なんだっけ・・・

都内近郊の駐車場雑感

筆者は運転にそんなに慣れていないのに3ナンバー車を乗っているので多分に主観が入っています。その点を差し引いて初心者ならそうだよなという目線で見て下さい。

子供が生まれてから車で移動する事が非常に増えた。理由として

  • 子連れは荷物がとにかく多い。着替えやオムツやら・・・
  • 熱中症対策や寒さなど気候が子供も親も辛い。
  • 子供がもしも泣いてもパーソナルスペースで済む。電車でギャン泣きしたときのいたたまれなさといったら・・・。
  • 新宿駅などベビーカーで移動することを絶対考えていない駅が辛い。
  • 単純に家と目的地までの移動時間が早い。乗り換えが多いと電車経由だと1時間半の距離が車だと30分とか普通にある。

というので、もう車以外で移動したくないくらいになった。そしてそれなりに色んな商業地域に行った時にメモ的な感想を残しておく。

まずおさらいとして

  • 自走式
  • 機械式
  • 屋内
  • 屋外

という要素があり基本は自走式屋内を目指している。次に機械式屋内。屋外は夏だととにかく暑い。暑すぎる。あと雨だとベビーカー出して子供乗せて・・・とか出来ないのでゆとりのためにも自走式屋内を優先度高くしている。 料金は時間あたりの料金と提携施設利用による割引、あと重要なので一日の上限金額があるかどうか。都内だと12分300円上限なし = 一時間1500円なのでフラッとご飯食べてコーヒー飲んだら数千円とかが余裕である。特に山手線駅近くの駐車場。子供がいると時間は読みにくいのでなるべく予想外の出費が無いようにしたい。

特に僕みたいな初心者に重要なのは事故らないような狭い駐車場に停めないことだ。100円をケチって結局車を擦るとかするくらいならたとえトータル500円高くても楽な駐車場に停めるべきだ。その観点でなんとなく覚えている都内のイメージを書いていく。

まず駐車場はそれぞれの系列ごとにTimesやリパークなどのアプリがあるとPPParkがまとめて検索出来て便利だと思う。僕のような車の運転に自信がない人に重要なのは値段よりも停めやすいかどうかだ。数倍高いとかならともかく一時間あたり100円しか変わらないのに都内の狭い道のなかにある駐車場を選択しないことだ。

新宿

西口ロータリーの駐車場は自走式かつ駅直結で良いし西口オフィスビル群は自走式地下駐車場が多いのであんまり困らないけど、伊勢丹とかは車で絶対に行く気がしない。高級車がバンバン伊勢丹立体駐車場に入るけどあんな狭い所にでかい高級車で行くの怖すぎてすごいなーって毎回思う。

自由が丘

自由通りなどのあの地域では大通りはだいぶ慣れたけど車で行く街ではない。不慣れなときなら歩行者+自転車+狭い道+踏切+狭くて混雑している駐車場と嬉しくない要素だけで構成されてて、駐車場見るとなんでこんなに高級車でみんな来ているのか。MASTというビルにたまに停めるけど地下に入る入り口の狭さは他の地域ではそうそう無いレベルだと思う。

東京駅

土日に行くならまあまあ。丸の内などの大きいビルも駐車場空いているので比較的停めやすい気がする。

渋谷

マークシティは近隣より高いけど自走式屋内の上に他の駐車場は軒並み狭いので快適。でも小さな子どもを連れて行くことがほぼ無い街である。

代官山

蔦屋は屋外自走式で混雑状況がタイミング次第。代官山アドレスは子供向けのお店が入ってて自走式屋内なのに意外といつ行っても空いている。

恵比寿

アトレ駐車場とガーデンプレイスの駐車場のどちらも屋内自走式でそれ以外は狭いし屋外なので使った事がない。

六本木

六本木ヒルズと六本木ミッドタウンは共に自走式+機械式が屋内にある。そして機械式がリフト型じゃなくて横に収納されるタイプなのでリフトの小ささに気を使うみたいなのがなくて非常に楽である。特に機械式の出庫は愛車がカッコよく登場するので子供だったら興奮しそう。子供が出来る前は仕事以外で来ることが無かったが子供向けのイベントや店が多く子連れでもレストランは慣れているので来たら楽しめる事が多い。

二子玉川

ライズが駐車場大きい上に自走式屋内なので楽なのだがとにかく広い上に階層構造が複雑でどこに停めたのかちゃんとメモらないと分からなくなる時があった。特に「エレベーター乗ったら1Fがすぐ上だったからB1だっただろ」みたいな覚え方するとM1だのMB階だのフロアが実はあったり、エレベーターによってはここに止まらなかったりなど降りてすぐに自分がどこに停めたのか確認する事がどれだけ大事かを教えてくれる。

武蔵小杉

グランツリーは自走式屋内だけど東京方面から向かうと微妙に迂回させられるのでちょっとだけ面倒。駐車場自体は広いしエレベーターも多いので他の施設よりさすが気が利いていると思う。ただそれだけ子供向け、家族向けなので土日の混雑は凄い。

品川

マクセルアクアパークに行くために直結の品川プリンスホテルの駐車場に停めているが自走式屋外なので雨の時とか夏の晴天時は結構辛い。あと雨の時はビル入り口の車寄せがほぼワンボックスカーで占領される。アクアパークは年パス買うとコスパが最強なので子供が水族館好きなら年パス一択。

表参道

青山通りと表参道交差点付近や国連大学付近の大きいビルの自走式屋内駐車場が楽だと思う。それ以外はアプリで検索すると恐ろしい狭い道のなかの駐車場とかレコメンドされる可能性があるので誘惑に負けない事。

東京ディズニーランド・ディズニー・シー

さすがというか、駐車場が広いので停めた場所を忘れないようにする以外は自走式屋内かつ台数も十分なので困った事が無い。高速のICも近いのでディズニーは車で行った方が年寄りには快適さが違う。電車で行くと東京駅の京葉線乗り換えはなぜあんなに遠く辛いのか。

みなとみらい

子連れだと目的地は有名なアンパンマンミュージアム。何度か訪れたが他の商業施設も凄く子連れに優しかった。都内から向かっても意外と30分程度で到着するので実は下手に都内中心部の商業施設に行くより便利。少なくともうちはお台場行くよりもみなとみらいに行った方が楽だった。ズーラシアだの途中にある有名スポットもある。 駐車場は二子玉川や武蔵小杉と同じように大半が屋内自走式で大型商業施設+休日オフィスビルのガラガラ駐車場という感じで非常に停めやすい。

IKEA港北 駐車場が広い自走式なのであんまり困らない。満車って書いていても実は出入りが多いので意外とサクッと停めれたりする。

コストコ川崎 自走式屋内だがとにかく混まない時間に行くのが重要。特に土日のお昼頃から15時くらいまではフードコートでご飯を食べようとしている人も多いせいか駐車場が激混み。多くの人が空きそうな場所を狙って駐車場内でぐるぐるしたり待機するのでとてもピリピリしている。出庫する人も出しにくいのでアレなんとかして欲しいなーと思う。

今思い出せる範囲の記憶ではこんな感じである。ベンツのGLやアルファードなどのでかい1BOXとかで狭い駐車場停めている人は運転上手くて尊敬する。

MySQLに初めてINSERTするとアクセスが発生するファイルは何かという質問をどう調べるのか

yokuo825さんのカッコいいインタビュー記事を

t.co

読んで、この部分ですね

──例えばどのような話をしましたか? 
 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 

具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 

でこんなツイートしたんですが

この質問聞かれたら正直ほげほげふがふがって感じだったけどまあ・・・ソース全部読むのは・・・時間無いし・・・難しそうだし・・・でスルーしていました。ただPosgreSQL側の話題だったんですが、こんな分かりやすいツイートを拝見したので

自分でもMySQLシステムコールを取ってみました。ちなみにstraceによる調査方法はPercona先生も分かりやすく方法を書いてくれています。

www.percona.com

実行環境はAWS EC2上でMySQL Serverを起動 AMIはamzn2-ami-hvm-2.0.20210617.0-x86_64-gp2 Versionはmysql-community-server-8.0.26-1.el7.x86_64

結果から言うと

[ec2-user@hogehoge ~]$ cat /tmp/strace.out | egrep "open"
5701  openat(AT_FDCWD, "/var/log/mysqld.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 37
5701  openat(AT_FDCWD, "/var/log/mysqld.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 37
5701  open("./", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 37
5701  openat(AT_FDCWD, "./binlog.index", O_RDWR|O_CREAT, 0640) = 4
5701  openat(AT_FDCWD, "./binlog.~rec~", O_RDWR|O_CREAT, 0640) = 37
5701  openat(AT_FDCWD, "./binlog.~rec~", O_RDWR|O_CREAT, 0640) = 37
5701  openat(AT_FDCWD, "./binlog.000003", O_WRONLY|O_CREAT, 0640) = 38
5701  openat(AT_FDCWD, "./binlog.index_crash_safe", O_RDWR|O_CREAT, 0640) = 39
5701  openat(AT_FDCWD, "./binlog.index", O_RDWR|O_CREAT, 0640) = 4
5701  openat(AT_FDCWD, "./test/oranie.ibd", O_RDWR|O_CREAT|O_EXCL, 0640) = 37
5665  openat(AT_FDCWD, "./test/oranie.ibd", O_RDWR) = 37
[ec2-user@hogehoge ~]$ 

という結果でした。なのでログ書いてbinlog書いてすべてが終わったらibdファイルを書いているという動きのようでした。それぞれのファイルの細かい説明、特にbinlog周りは後ほど調べます・・・。.~rec~って知らなかった。 -> 昨日データ操作なのにmysqld.logに書いているのとりあえずなんかおかしいと思いながらそのまま書いていたけど、模範解答貰えたので追記。

AWS : Online Ask an ExpertにExpert Dayというのを企画したのでみんな相談に来てください

皆様はAWS LoftのAsk an Expertというのをご存知でしょうか?

AWS Loft Tokyo – Ask an Expert コーナーがオンラインで復活! | Amazon Web Services ブログ

AWS LoftではAsk an ExpertというカウンターがありAWS Loftに実際にお越しいただいて開発をする方が気軽にAWSメンバーに相談出来る窓口がありました。COVID-19の影響でAWS Loft 目黒が現在クローズしており、AWSに相談したい!という要望を受けオンラインでも提供をしています。

で、今はどんな質問でもその日に対応するメンバーがやります!という状況なのですが、サービスがとても増えたこともありメンバー内でも得手不得手が正直あると考えています。僕も自分が所属しているチームで専門にしているDynamoDBに関する質問へのサポートは自信を持っているのですが、他のサービスでは相談した方に満足が行く回答が出来るかと言われるとちょっとむずかしいかもしれない、だったらむしろこの日にサービスを特化して相談出来る日を作ろう!と企画した日になります。

という訳で同じ様な社内のメンバーを募り2021/2/19 金曜日だけはContainer/Database/Analyticsサービスに特化したExpert枠が追加されました。DBだけに限らずなので例えば

  • 想定しているワークロードでは、どのコンテナサービスと組み合わせてどのデータベースが良いか悩んでいる

  • データベースに入れたデータをどういう分析フローに載せれば良いのか悩んでいる

など、コンテナ x DB x Analyticsが組み合わさった相談ももちろん可能です。

注意点としては、専門以外の領域は対応が完全にベストエフォートになるので、General枠の方に相談を予約して頂いた方がおそらく満足出来ると思います。それぞれの枠で対応可能なサービスが記載されているので確認宜しくお願い致します。

予約フローは

Online Ask an Expert – Special Expert Day のご案内 | Amazon Web Services ブログ

で詳細が乗っていますがこちらでも紹介しますね。

awsloft.tokyo

このサイトの「オンライン相談」というタブからまず予約する画面 https://awsloft.tokyo/reserve

へ遷移してください。まだ登録がない場合、事前にAWS account IDを含めた情報の登録が必要になります。予約枠の画面が表示されたら

f:id:oranie:20210212200929p:plain
予約画面
赤のExpert Dayの枠を選択してください。時間帯によっては現在対応出来るExpertが違うため、ご自身の相談サービスが記載されている枠で予約をお願いします。また、予約をする際に相談内容を書いて貰うのですが、そこで記載がなかったサービスについては当日担当者が相談に参加しないので、例えば

こういうワークロードでDynamoDBとGlueとECSについて相談したい!という具体的なサービス名や、RDBMSとNoSQLで悩んでいるなどのリクエストを必ず記載お願いします!!

もし登録をする際に何か分からない、おかしいみたいなことがあれば #AWSLoft のハッシュタグをつけてTwitterにつぶやいて貰えれば、内容などによりますがベストエフォートでスタッフがサポート出来るときはお手伝いするかもです。

以上、皆様是非相談に来てください!好評なら第二回、第三回とやっていきたいなと考えています。

「秘伝のタレ」とはなんなのか?というコバンザメエントリ。

素晴らしい内容のエントリですね。

https://kazeburo.hatenablog.com/entry/2020/12/17/164857

ここで出てくる「秘伝のタレ」とはなんなのか?久しぶりにmy.cnf見て意味忘れていたので自分の復習というコバンザメエントリです。 それぞれの内容はオフィシャルドキュメントを確認するのが一番正確です。

innodb_doublewrite = 0 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_doublewrite https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html

innodb_flush_log_at_trx_commit = 2 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

上記2つは http://nippondanji.blogspot.com/2010/03/innodb.html にも解説があるのでそちらで確認がベスト。要は多少DIsk障害時の信頼性を犠牲にするけどより効率的にDisk I/Oを使うための設定か。

innodb_flush_method = O_DIRECT_NO_FSYNC https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_method

ここまでの3つでDisk I/Oを少しでも効率的にするのが目的だと思われる。

innodb_adaptive_hash_index = 0 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_adaptive_hash_index https://dev.mysql.com/doc/refman/5.6/ja/innodb-adaptive-hash.html https://dev.mysql.com/doc/refman/5.6/ja/index-btree-hash.html

今回のワークロードに向かないIndex処理をしない

という形がコトコト煮込まれた内容のようです。なので実運用上は問題無いケースもあれば、ある要件によっては設定するとウッという可能性もあるので無条件にスループットを求めてとにかくみんな設定すれば良いのかはエントリ主のkazeburoさんやyoku0825さんとかが解説してくれる気がします。そもそももう数年前にされている可能性高いけど、

「伝わる短い英語 Plain English」という本がとても素晴らしかった

2020/6/17 追記 そもそも僕の文章が分かりづらい、という至極まっとうなコメントがあったので若干修正。本を読見直してもっと分かりやすい文章書けるようにならないと。

今日こんなツイートしたら

結構色んな人がLikeしてくれたので改めてブログに。

自分は英語全然出来ないので仕事でもコンプレックス満載なんだけど、さすがにまずいと思ってちょっとは勉強しているんですね。どうしても長文とかがスッと頭に入ってこなくて、仕事のドキュメントやメールを見ても何度か読み直さないと理解出来ないし、同じような文章をメールで書けないので本当に駄目だなぁと思っていました。 ただ、英語出来ないことには変わらないけど、別に仕事などで必要じゃなければ難解な表現や文学的な表現とかはむしろする必要が無くてシンプルな英文を作れれば良い、むしろその方が有益というのをこの本で学べたことはかなり肩の力を抜ける気がしました。下手すると「俺が理解出来ないのはこの文章が難解な構造だからだ」くらいからスタート出来るので時間掛かってもまあ良いかとかなり精神的に気が楽になりました。

で、ちゃんと本の紹介をすると「伝わる短い英語―アメリカ、イギリス、カナダ、オーストラリア 政府公認 新しい世界基準Plain English」というタイトルどおりPlain Englishというフォーマットについての解説です。

jpelc.org

序盤少し引用すると

そして、現在のネットワーク社会による情報過多の環境下で私たちはスピーディーに情報処理を行い、コミュニケーションすることが強いられています。 現在の欧米のビジネス文章の1センテンスの推奨ワード数は20ワード以下です。 情報に修飾を施すことなく、ダイレクトで簡潔、効果的表現を駆使して、たった20ワード内で、情報を伝達するための工夫がされています。 そうした表現の効果と効率をルールとしてまとめたものがPlain Englishガイドラインです。 現在 Plain Englishで書かれる代表的なものが、米国大統領の就任演説であり、ウォール・ストリート・ジャーナル、投資家向けIR資料です。

というとても体系だったルールであり、

米国では、政府からの通達される文章に対し、平易な言語のムーヴメントが1970年代に始まり、1978年に当時の大統領であるジミーカーター氏が政府規制を「費用対効果」(cost-effective)と「わかりやすさ」を推進することで、それまでの問い合わせや訴訟における賠償コストを削減し、一人でも多くの国民が規制を遵守し、そのパフォーマンスの向上を目論み大統領令を発令しました。 現在では、多くの機関が平易な言語を義務化する長期的な政策をとっており、1933年証券法に基づいて、証券取引委員会(SEC)は、1998年にその規則に採用し、法的義務化がされました。そして、現在では、新聞、雑誌など一般的に使用されています。

となっており広く読まれるドキュメントを書く際には法的義務になっているルールのようです。

そのため本の中でも二重否定のような文章は単純な肯定文で書きなさいというような具体的な解説であったり、トランプ大統領のスピーチは小学4年生でも理解出来るレベルでわかりやすくなっている事がスピーチの効果を高めているなどの解説が書かれておりとても分かりやすく学べる内容になっていました。

日本語でもやりがちですが冗長であったり分かりづらく、難解な単語をとにかく多く出すことで自分の文章が良い文章のように見せようとする事を「多くの人が読む時に読みやすいかどうか」という観点で見直せるのは英語以外でも役立つ視点でした。

という訳で、簡単な書評ですが是非英語や分かりやすい文章を書くことを同時に学べるのでとてもお得な本だと思います。

目黒駅近くのテイクアウトやってたお店のメニュー写真

なんか真面目なエントリには程遠いけどせっかくなのでメモがてら。

5/7追加分

よし鳥は何度か行った事ある。焼き鳥屋で酒呑みたい。

f:id:oranie:20200509103715j:image
f:id:oranie:20200509103719j:image

5/6追加分

みんな大好きミート矢澤もテイクアウトやってる

ミート矢澤 東京 五反田本店

f:id:oranie:20200506143939j:image
f:id:oranie:20200506143936j:image

隣のあげ福も

とんかつ あげ福/index
f:id:oranie:20200506143943j:image

あげ福はほんと美味くて大好きなトンカツ屋。食いたくなって来た。

------

f:id:oranie:20200425224424j:image

sibafu
050-5304-6117
https://retty.me/area/PRE13/ARE13/SUB704/100000757098/

雅叙園近くで前のオフィスから近くだったのでチョロチョロ行ってた。少しエスニック風なアレンジしてる物が多いけど美味しい。

 

f:id:oranie:20200425224805j:image

http://www.bistro-jill.com/shop/shinatora.html

 

f:id:oranie:20200425225012j:image

http://www.bistro-jill.com/shop/

 

二店舗は同じグループでよく呑みに行ってた。ご飯が美味しい上にテイクアウトだと20%オフという凄まじくお得。 肉料理が美味しくご飯としても美味しいけど、食べるとお酒呑みたくなる。

 

f:id:oranie:20200425225138j:image
f:id:oranie:20200425225129j:image
f:id:oranie:20200425225142j:image
f:id:oranie:20200425225135j:image

 

この辺は普段行った事ないけど、この機会にテイクアウトしてみようかなと思ってとりあえずメニューだけ撮影。

 

 

 

iPhone11Proで使うeSIMはairaloが快適だった

海外旅行などでモバイル機器の通信をどうするかは以前こんな感じの記事を書いた。

oranie.hatenablog.com

そして昨年自分の不注意でiPhone7を微妙に壊してしまい、せっかくなのでiPhone11Proを買った。単純に容量がとにかくデカイのが欲しかったがカメラ性能が最高で本当に買ってよかった。子供も本当に可愛く撮れるし夜景とかも三脚無しでテキトーにやってもこんなに綺麗に撮影できるのかと感動した。

そしてiPhone11になったのでeSIMが使えるようなった事でまだ自分が実際に海外は行っていないが色々調べた結果airaloが良さそうだった。

www.airalo.com

そしてたまたま1月外出が多くて今使っているキャリアの帯域を使い切ってしまったので、検証がてら日本のSIMを買ってみた。感想としては本当に楽ちんでアプリポチポチしていたら慣れたら10分くらいでSIMが使えるようになる。またGB辺りの単価も安い気がする。

ただし通信量がunlimitedと書いているプランも実際はこんな感じで条件があるので買う前に一度確認した方が良い。

Twitterでつぶやいてから興味を持ってくれた人が実際に海外で試してくれたようだが、何も問題無く使えていたので多分日本だから簡単だった、みたいなのはなさそう。USだとt-mobile回線が使えるみたい。

唯一の問題は簡単設定用にQRコードが発行されるんだけど、これ設定するiPhoneのモバイル設定の追加画面のカメラでどうやって読み取らせるの・・・? スクショを一度どこかに送ってそれを読み込み・・・?誰か教えて欲しい。手動設定の情報もちゃんと表示されるしコピペも出来るから問題無いんだけど。

とりあえず今後の海外旅行などはeSIMで全て対応することで日本で使っているSIMを交換した後にちゃんとしまうとか、もし交換時にうっかりポロッと無くしたら帰国時どうしようとかの不安から解消されるのと値段も非常に安いので使っていこうと思う。