東京で食べて美味しかったお店をまとめてみた_part①

東京で今まで食べて美味しかったお店を急にまとめてみたくなってきた。

きっかけは家族と今まで美味しいお店の思い出を話しをしている中で、
店名を忘れてしまっていたから。

友人に紹介できるように整理してみたので、よかったら参考にしてください。

話は変わって、食べログのURLをリンクとして貼ろうとしたらアクセス制限がかかってました。。。

なんでだろう？直接

天茂(最寄り駅：赤坂)

retty.me

昔TVでこのお店が紹介されていたので行ってみたところ、かき揚げ丼はここが一番かなっていうぐらい美味しくてファンになりました。

キッチンプラス(最寄り駅：自由が丘)

retty.me

席は10席もないですが、洗練された洋食屋さん、という感じです。

個人的にはハンバーグがおすすめです。

みつばち（最寄り駅：自由が丘）

retty.me

おしゃれな居酒屋さん、という表現だけでは足りないぐらいここのお店の雰囲気が独特で最高です。

また、料理も一品一品がどれも美味しい。よく頼んでいたのはラー油がかかった豆腐。

ヘルシー、かつ美味しかった記憶があります。

あと蕎麦があってシメに食べてました。

雰囲気は本当いいので、みんなで飲むときに利用することをオススメします。

楳心果 （バイシンカ） （最寄り駅：都立大学）

retty.me

駒沢公園に向かう途中にあるお店。和菓子＋カフェだけではなく、朝はごはんも提供しています。

一度、その朝ごはんを食べたことがあるのですが、お米がおかずがなくても何杯でも食べることができるぐらい本当に美味しかった。

お米本来の美味しさを堪能することができる数少ないお店だと思います。

店内のデザインも茶室のような、落ち着く空間になっています。

外の景色を見ながらゆっくりお茶を飲んで過ごす。。。

贅沢な気分を味わうことができます。

元祖ニュータンタンメン本舗 京町店 （最寄り駅：川崎 or 八丁畷）

retty.me

駅からちょっと遠いですが、ニュータンタンメンといえばまずココ。

焼肉も美味しいので、シメとして食べて欲しいです。

ニュータンタンメンは一言でいえば元気がでるラーメンって感じでしょうか。
辛さもあり、にんにくたっぷりだけど、卵とのバランスが絶妙です。

山水苑（最寄り駅：川崎）　

retty.me

お肉はどれも美味しいのはもちろん、私はここのチヂミが好きで、来ると毎回頼んでしまいます。

今はどうかあるかわからないですが、ドジョウスープというがあり初めて食べました。

元気が出ます。

横浜らーめん 壱八家 スカイビル店 （最寄り駅：横浜）

retty.me

いわゆる横浜系ですが、スープはこってりではなくクリーミーという表現が正しいかな？バランスが取れたラーメンです。

休日は並ぶので早めに並ぶことをオススメします。

シェ・松尾　青山サロン（最寄り駅：渋谷 or 表参道）

retty.me

たまたま行ける機会があって、行ってみたものの、最初は場違いじゃないかと思うぐらいスゴイ緊張をしてしまった。

料理、空間、雰囲気とどれも豪華でした。

肝心の料理は美味しいのはもちろん、印象的だったのはお皿でした。

コースの雰囲気に合わせたお皿になっているのはもちろん、なんというかこう、料理とお皿とでアートな雰囲気を演出している印象を受けました。

たまにはこういったお店に通ってみるのもいいなあ、と思わせてくれたお店でした。

銀座フォアグラ（最寄り駅：新橋)

retty.me

知人に連れていって頂いたところ。

フォアグラをまた食べたくなるぐらい、柔らかくて美味しかったです。

夜に親しい人とワインとフォアグラと一緒に、楽しく語る。。。
贅沢な一時を体験できるお店だと思います。

どうとんぼり神坐(最寄り駅：渋谷)

retty.me

関西No.1と書かれた看板を目にしたことはあるけど、一人ぐらしのときはよく通っていたラーメン屋です。

白菜のシャキシャキ感、ニラのピリッとした辛さ、あっさりスープが大好きです。

私は途中ちょっと辛いニラを足したりして味を変化させてました。

梅林(最寄り駅：梅屋敷)

retty.me

いつも賑わっている居酒屋さん。魚が新鮮でどの料理も美味しいです。

また、店員さんがみんな元気なのもいいですね。

お店を通るときにおじいさんが焼き鳥を真剣に焼いている姿を
見ることができるのですが、思わず焼き鳥を頼みたくなります。

以上、現時点で思いつく限りのお店をまとめてみました。

まだまだ世の中には美味しいお店があるので行ってみて、いい思い出ができれば書き留めたいと思います。

「絵で見てわかるシステムパフォーマンスの仕組み」読みました。(2017年32冊目)

絵で見てわかるシステムパフォーマンスの仕組み

■感想 

ITに携わる人全員にオススメしたい本です。

その理由としては大きく2点あります。

 

1.サーバを構築してITサービスを展開することを前提に、システムパフォーマンスが全体的、体系的に書かれていること

 

2.いわゆる情報処理試験で出てくるような、スタックやキュー、アルゴリズム、レスポンス、スループット等々の説明が丁寧で理解しやすいこと

 

 

全体的に本書は著者の業務経験によるものをベースに書かれていることが多いので、実用性が高いです。

 

私はこの本を読んで、例えば次のような構成でシステムが成り立っていたときに、

 

クライアント→Webサーバ→APサーバ→DBサーバ→ストレージ

 

各それぞれ、どういったところを見てパフォーマンスチューニングをしていけばいいかがわかりました。

 

あとはパフォーマンスチューニングの実践して経験を積んでいきたいと思います。

  

■メモ

 

第1章　パフォーマンスの基本的な考え方

＜アルゴリズム＞

 

O(logn)とは？

→nを2で何回割ったら1になるか

 

・ループ処理→O(n)

・リストとループ処理→O(n)

・ツリーと検索→logn

・ハッシュアルゴリズム→O(1)

 

＜レスポンスとスループットの違い＞

 

レスポンス・・・いかに素早く反応を返せるか

→レスポンス重視は万能。レスポンスが早くなれば、普通、スループットも上がる

しかし、CPUのクロックやディスクI/Oの速度が頭打ちになっていることから

わかるように、物理的に早くするには限界がある

 

スループット・・・1回通信あたりに処理できる量

→同時に大量の処理をさばけるシステムをスループット重視のシステム

 

＜ロック待ちを解決する方法＞

・DBの表にロックをかけて、SQLを発行しているのであれば、

そのSQLを早く終わらせてあげれば、ロックを待っている時間が減る。

・ロックを分割する方法。DBの表にロックをかけるのではなく、行に対してロックをかけるようにする

 

 

第2章　パフォーマンス分析の基本

 

＜分析タイプ＞

・サマリ形式

→sarやvmstatのような、一定期間の情報を合計もしくは平均で見せてくれるツール

・イベント記憶形式

→個々の出来事を逐次記録する方式。パケットキャプチャやシステムコール記録

・スナップショット形式

→psコマンドやtopコマンドのようにその瞬間の状況を記録

 

＜OSのコマンド＞

・sar

→CPUの使用率とアイドル、読み書きI/Oの量、メモリの概況などがわかる

・vmstat

→実行待ちの平均プロセス数。何らかの理由で待たされている平均プロセス数。

スワップへのI/O、通常のI/O、コンテキストスイッチの回数

・ps

→主に、その瞬間にどんなプロセスが居るのか、その瞬間のプロセスの状態、

・netstat

→-aオプションでその瞬間のソケット、-rオプションでその瞬間のルーティング情報

-iオプションでインターフェースごとの統計

・iostat

→ディスクの使用率がわかる。-xオプションにより、レスポンスタイムや各種キュー長が分かります。

・top

→リアルタイムでOS全体の状況を把握するのに最適なコマンド

・pstack

→そのプログラム（プロセス）がその瞬間にどんな処理を実行しているのかが分かります。

・strace

→どんなシステムコールで待っているのか、OSの何の関数で時間を使っているのか

 

第3章　実システムのパフォーマンス分析

 

・Webサーバのアクセスログ

・アプリ/APサーバのログ

 

＜I/Oにかかる時間＞

ハードディスクのアームが動く時間＋回転待ちの時間＋実際の読み書き時間

 

第4章　パフォマンスチューニング

 

＜パフォーマンスチューニングの定石＞

・設定は大きすぎても、小さすぎてもダメ。ほどほどに

・チューニングは1つずつ進める

・再利用することで速くする

→DBのコネクションプール、Webのキープアライブ、APサーバのスレッドプール

・まとめて処理する

・高速化と並列化

・スケールアップとスケールアウト

・ループの省略、キャッチボールの削減

・参照頻度の高いデータはキーバリューストア化かハッシュ化する

・参照頻度の高いデータは使う場所の近くに置く

 

 

第5章　パフォーマンステスト

 

＜よくある失敗：9つのアンチパターン＞

・本番環境でないと再現しない

・パフォーマンスが出ない！パフォーマンス問題が解決できない！

・環境差異を考慮しないために問題が発生

・負荷シナリオ設計に不備があるために問題が発生

・バッファ/キャッシュの利用を考慮しないために問題が発生

・シンクタイムを考慮しないために問題が発生

 

第6章　仮想化環境におけるパフォーマンス

 

＜VM化とは？＞

1台の物理サーバ上に仮想的に複数台のサーバ（VM）を稼働させること

 

第7章 クラウド環境におけるパフォーマンス

 

＜観点＞

・コンピューティングリソースを構成する技術要素は変わらない

・アクセスするネットワーキングとリソースの利用と提供の形態が変わる

 

＜オンプレミス環境との変更点＞

・オンデマンド、セルフサービス

・幅広いネットワークアクセス

・リソース共有

・スピーディな拡張性

・サービスが計測可能

 

 

Webシステム作成時のボトルネックとなる制約の発見とその対処を学びたい①

本やネットを漁り、手探り感は拭えないけどタイトルに書かれていることができるようになりたい。

なので一旦、現時点で自分が調べたことをまとめてました。

こんな観点がもっと必要、とかあれば教えて頂けると助かります。

■CPU

CPU使用率は応用情報の問題に載ってあったので。計算方法を整理してみた。

【問題】

次のシステムにおいて，ピーク時間帯のCPU使用率は何%か。ここで，トランザクションはレコードアクセス処理と計算処理から成り，レコードアクセスはCPU処理だけでI/Oは発生せず，OSのオーバヘッドは考慮しないものとする。また，1日のうち発生するトランザクション数が最大になる1時間をピーク時間帯と定義する。

〔システムの概要〕

CPU数：1個

1日に発生する平均トランザクション数：60,000件

1日のピーク時間帯におけるトランザクション数の割合：20%

1トランザクション当たりの平均レコードアクセス数：100レコード

1レコードアクセスに必要な平均CPU時間：1ミリ秒

1トランザクション当たりの計算処理に必要な平均CPU時間：100ミリ秒

解法は次のステップで解くことができます。

①ピーク時間帯のトランザクション数は　60,000 * 0.2 = 12,000

②1トランザクション当たりの平均CPU時間は、レコードアクセス時間と計算処理時間の合計のため、

100*1ミリ秒（レコードアクセス時間）　+ 100ミリ秒　= 200ミリ秒　/　1トランザクション

③ピーク時間帯にかかるCPU使用時間は12,000 * 200 = 2,400,000 ミリ秒　= 2,400秒

④1時間は3,600秒のため　使用率は2,400 / 3,600  = 約67%

Hzとクロック数も応用情報の問題に載ってあったので。計算方法を書いてみた。

・Hzとクロック数から何回命令をだせるか？

【問題】

　「1GHzで動作するCPUがある。このCPUは，機械語の1命令を平均0.8クロックで実行できることが分かっている。このCPUは1秒間に約何万命令実行できるか。　

1秒間の命令実行回数＝クロック周波数　÷　1命令の実行に必要なクロック数　

　　　　　　　　　   = 1*10^9/0.8=1.25*10^9

ちなみに、ギガとかテラは10の何乗かは以下に整理してみました。

・キロ・・・１０００倍　＝　10^3
・メガ・・・１００００００倍 = 10^6
・ギガ・・・１０００００００００倍 = 10^9
・テラ・・・１００００００００００００倍 = 10^12

■I/O

レスポンスとスループットの違いは重要

・I/Oレスポンス＝I/O要求処理にかかる応答時間
・I/Oスループット＝単位時間当たりのI/O処理量

ここで、例えばレスポンスに時間がかかる場合は対処としてはどうしたらいいのでしょうか？何の処理によるものかをログを見ながら解析する？のかな。。。

■DB,SQL

実行計画から「cost」を分析して、重い場合はインデックスを貼ったり、Where条件の見直しをする、でしょうか。

ピーク時にどれぐらいのユーザ数がコミットや検索がするのかを算定することも重要ですね。この場合の計算方法はケースバイケース、なのでしょうか。

■Network

これも応用情報の問題にあったので解き方を整理してみました。

送るデータ容量とインターネットの処理量/秒から時間を求めていく、って感じでしょうか。

【問題】

100Mビット／秒のLANに接続されているブロードバンドルータ経由でインターネットを利用している。FTTHの実行速度が90Mビット／秒で，LANの伝送効率が80%のときに，LANに接続されたPCでインターネット上の540Mバイトのファイルをダウンロードするのにかかる時間は，およそ何秒か。ここで，制御情報やブロードバンドルータの遅延時間などは考えず，また，インターネットは十分に高速であるものとする。

解法としてはLANの伝送効率が80%なので、80Mビット／秒を。これはFTTHよりも遅いのでLANの計算のみでよい。

バイト単位に変換すると 10Mバイト／秒になるので、540Mでは54秒かかる計算になる。

まとめ

イマイチ網羅感がないため、体系立ったボトルネック分析ができていないですね。

現時点で理解していることを書いてみたので、もっといい情報があれば更新していきます。

Rails configのconsider_all_requests_localとは

trueにすると、すべてのエラーをブラウザに表示する。
falseに設定すると、ブラウザには詳細情報が表示されない。

私はこれをきちんと理解せず、trueにしていたため
本番と開発との違いが理解できずにいた。

デフォルトでは

・development環境はtrue、
・production環境はfalse

エラー時の動作を確認する際、developmentでもproductionと同様の動作をさせたいときは、config.consider_all_requests_local = falseにする

各設定ファイルの置き場はここ。

・ development: config/environments/development.rb
・ production: config/environments/production.rb

「10年戦えるデータ分析入門」読みました。(2017年31冊目)

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)

■感想

本書は「分析」をメインとした実用的なSQLの使い方や集計方法、アーキテクチャ設計まで書かれているので、幅広くSQLを学ぶことができます。

特に自分の場合は縦持ちテーブルを横持ちテーブルに変換する方法を知ることができたのが良かったです。

プログラムの本は書いてある内容を読むだけではなく、本に書いてあるSQLを自分のPCで実行してみるのが一番飲み込みが早いですね。

あと、分析とはカテゴリーが異なるかもですが、権限の設定や、チューニング技もあると個人的にはもっと知りたかったです。

また、初めて向けの本でもあるので、SQLを書くときのお作法(インデント等)もあるとより良いと思いました。

ちなみにフリーのSQL開発ツールを使うのであれば「A5」がオススメです。

A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール .. 松原正和

SQL整形から実行計画まで取れる優れたツールだと思います。

＜目次＞

第1章　10年戦えるデータ分析の技術
→SQLで分析すべき理由と、本書の概要

第2章　さわってみようRDBMS
→テーブルやカラムなどRDBMSの基礎概念と接続方法

第3章　簡単！select文でデータ探索
→Select文の基礎

第4章 すべての分析は集計から始まる
→集約関数とgroup by節を使った集計について

第5章　関数で自由自在に新しいカラムを作り出す
→関数と演算子を使って、他のカラムから関連する値を計算する方法

第6章 ジョインを制するものはRDBMSを制す-基礎編
→複数のテーブルを連結するジョインの基本とテーブル設計

第7章 ジョインを制するものはRDBMSを制す-応用編
→様々なジョインのバリエーションとアソシエーション分析

第8章 遅れて来た分析SQL最強の武器-ウィンドウ関数
→サブクエリーとウィンドウ関数

第9章　縦と横は難しい
→縦持ちテーブルと横持ちテーブルの変換

第10章　アクセスログのセッション分析をする
→章を通じて大きな分析に取り組む

第11章　10年戦えるデータ分析システム
→SQLを用いた分析システムのアーキテクチャ

第12章　ビッグデータに立ち向かう
→ビッグデータ技術を活用した分析システムの構成

第13章　SQLバッチの技法
→分析データベースにおいてデータを加工する手法

第14章　本書を読み終えたあとに
→発展的なトピックについて　

フェルナンド・モリエンテスを知っていますか？

「フェルナンド・モリエンテス」

誰？っていう人もいるだろうし、

ラウールとコンビを組んでいたFW、って答える人もいると思います。

私にとってフェルナンド・モリエンテスは自分が海外サッカーを観る

きっかけを与えてくれた人です。

忘れられないのが2003/2004のCL準々決勝、モナコVSレアル・マドリード戦。

レアル･マドリードにロナウドが加入しモリエンテスはポジションを失い、モナコへのレンタル移籍。ここでチャンピオンズリーグ史上最高と言われるジャイアントキリングを起こしてレアルをなんと倒しました。

準々決勝1戦目でゴールを決めたときに所属していたクラブを想って喜びを爆発させないでいる姿が、「格好いいなあ」っと思った記憶があります。

それからはファンになり、リバプール、バレンシアへ移籍してもウォッチしてました。

プレー動画を観てみたなかで、モリエンテスの凄さは次の3点だと思います。

・打点が高く、コントロールの効いたヘディングができる

・左右どちらの足からでもシュートが打てる

・味方を生かすプレーができる

センターフォワードって点決めてなんぼって感じの利己的なプレーヤーが多いなかで、

モリエンテスは周りを活かせる希少なFWだったなあって思います。

www.youtube.com

あと、↑の動画観ると、キーパーの股下をあえて狙っている？シュートが多いことがわかりました。

股下はコントロールが良くないと狙えないので、すごいなあって改めて思いました。

モリエンテス&ラウールのレアルでもスペイン代表でもいいコンビでしたね。

他にもアンリ&ベルカンプのコンビも良かった。

最近のイケてる2トップは誰だろう？3トップはBBCやMSNとか、多いですけどね。。。

モリエンテスを思い出していろいろと書いてみましたー。

「Webを支える技術」読みました。(2017年30冊目)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

■感想

感想としてRailsを使って簡単なWebサービスを作っていた私にとっては、RESTやHTTP,URI,の基礎理解を深めることができて大変勉強になりました。

現時点の私の理解力を元にですが、本書ではざっくりいえば次の2点を提供しています。

・Webの仕組みとその歴史・背景
・Web設計の基礎

もちろん、全てが理解できたというわけではないです。
自分で本書で書かれていることを実際に試しながら理解を深めていくしかないですね。

技術書はまずは文章に書かれている専門用語一つ一つを理解していないと全体理解ができないので、読むのにパワーと時間がかかりました。

下にも書いている本書リソースの定義が私が知っていたリソース（ハードディスク容量やCPUの処理速度、メモリ容量のこと）とは定義が異なっていたのでわかりにくかったです。

また、できればWebサービスを設計する上でボトルネックとなりうる、CPU・I/O・DB・NWといった、上記制約の発見の仕方。そして、正しく見積るための計算方法も知りたかったです。

＜メモ＞
■リソース設計とは？

クライアントとサーバの間のインターフェースの設計のこと。
どのようにリソースを分割し、URIで名前をつけ相互にリンクを持たせるかが設計の勘どころ

＜設計手順＞
　1.Webサービスで提供するデータを特定する
　2.データをリソースに分ける
　3.リソースにURIで名前をつける
　4.クライアントに提供するリソースの表現を設計する
　5.リンクとフォームを利用してリソース同士を結びつける
　6.イベントの標準的なコースを検討する
　7.エラーについて検討する

■RESTとは？
→Webのアーキテクチャスタイル

＜観点＞
・クライアント/サーバ:ユーザインタエフェースと処理を分離する
・ステートレスサーバ：サーバ側でアプリケーション状態を持たない
・キャッシュ：クライアントとサーバの通信回数と量を減らす
・統一インタフェース：インタフェースを固定する
・階層化システム：システムを階層に分離する
・コードオンデマンド：プログラムをクライアントにダウンロードして実行する

リソースとは「Web上に存在する、名前をもったありとあらゆる情報」
世界中の無数のリソースは、それぞれURIで一位の名前を持つ
URIを用いることで、プログラムはリソースが表現する情報にアクセスできる

＜単語メモ＞
microfomats
→HTML文書そのものにメタデータを埋め込む技術
Atom
→ブログなどの更新情報を配信するためのフィードだけではなく、実際には幅広い分野での
応用が可能な汎用XMLフォーマット
クロスドメイン
→不特定多数のドメインに属するサーバにアクセスすること
ファクトリリソース
→リソースを作成するための特別なリソース
悲観的ロック
→ユーザをあまり信用せずに、競合が発生しないようにする排他制御の方法
ステートレス
→サーバがクライアントのアプリケーション状態を保存しない状態制約