私が愛したタコライス
渋谷でランチどこ行こうって迷いますよね。
そこで今回は私が愛してやまないタコライスを紹介したいと思います。
私が愛すタコライスとは
毎週火曜と金曜のお昼に、マツコと嵐のおかげで渋谷一いや東京一デミグラスハンバーグがうまいと話題沸騰中、毎日行列、満員御礼でウハウハのキッチンハセガワ!!のちょうど向かいに、
黄色いワゴンが停まっていて、そこでタコライスが売られています。
ケータリングっていうんですかね。
実はここのタコライスも、あのキッチンハセガワに負けないくらい行列ができていて、いつも30分くらい並ぶのですが、それでも私は週2回欠かさず食べます。
私がタコライスが好きな理由
なぜキッチンハセガワほど話題にもなっていないタコライスごときに30分も並んでまで買うのか。
1. うまい
美味です。サルサソースの辛さがトマトのみずみずしさと中和されてちょうどええとかそんなんいらないです。
ひき肉とチーズとサフランライスのベットに、シャキシャキのキャベツの布団が被さっていてそれを一緒に口に運んだ時の絶妙な味のバランスが!とかもいらないんです。
ただただ一言、美味なんです。
2. 栄養満点
ここのタコライスは野菜が大量に入ってます。 これは私の偏った主観ではなく、タコライスの宣伝文句にこのタコライスを食べると無意識の内に、1日に必要な野菜の半分が取れちゃいますと書いてあります。アメイジング!
一人暮らしだと、相当アグレッシブな気持ちを持たないとなかなか野菜を食べないですよね。
それがここのタコライスを食べるだけで、1日に必要な野菜の半分も摂取できるなら、そんな幸せな事無いはずです。
さらに、2つ食べたら1日分。4つ食べれば...というようにあなた次第でほぼ無限の野菜を簡単に摂取することもできます。
そんなこと言うなら、伊藤園の1日分の野菜飲めばいいじゃないとか言う人はキッチンハセガワに行ってください。
3. カスタマイズが可能
モノと情報がありふれたこのご時世、「あなただけ!」という価値が差別化になります。
なんとここのタコライスは辛さや野菜の量などを自分好みに調整することが可能なんです。
アンビリーバブル!
ちなみに私のお気に入りカスタマイズはご飯普通盛り、辛さ控えめ、チーズ多め、野菜多めwith フレンチドレッシングです。何回も通っていることから店員さんとはほぼマブダチなので、普通盛りで!というと上のメニューで作ってくれます。
客の好きな注文を覚えるということもまた、ブランドロイヤリティを高めるための一つの戦略になっているのでしょう。
一流ホテルも脱帽です。
最後に
以上が私のアモーレの紹介でした。 正直紹介することでさらに行列ができたら嫌だなと思ったのですが、私にマツコや嵐ほどの影響力があるわけがありませんので無問題でした。 ぜひとも一度は食していただきたいと思います。
ちなみに渋谷とか行かねぇよという方、安心してください。店舗もありますよ。
実はこのアモーレ、こちらのMOTO's KITCHENというお店が運営しているのです。
tabelog.com
名前から推測するにここのオーナーがもこみちファンなのは間違いないでしょう。
場所は東急池上線の長原駅を出て右に歩いて3分位のところにあります。
ぜひ渋谷になんか行かねぇ方はそちらに行ってみてください。タコライス以外にも色々なメニューがありお酒を飲みながらタコライスを食べるという、違った楽しみ方もできるかと思います。
P.S. 個人的にキッチンハセガワはデミグラスハンバーグよりチキンピカタが美味しいと思っております。
go build No such file or directory
go buildで実行環境のバイナリを生成して、それを実行しようとしたら
No such file or directory
が出てハマったのでメモ。
go build時の$GOOS
と $GOARCH
の指定が間違っていたため上記のエラーが出たよう。
ここの指摘の通り32bitで64bitのバイナリを動かそうとしていたのがダメだった見たく、
GOARCHをamd64から386に変更すれば、動かすことができた。
ココらへんの知識がないので、勉強せねば。
リモートホストのmysqlにログインできない時の確認箇所
ec2上のdockerから別のec2上に起動してあるmysqlにアクセスしようとした際に、
Access denied for user
というエラーが出てはまった。
原因としてはmysql側で外部からのアクセスを許可していなかったのと、mysql内のデータベース操作権限を与えていなかったからだった。
まず外部からのアクセスを許可するには
/etc/mysql/my.cnf内のbind-address
の箇所を書き換える。
デフォルト127.0.0.1になっているので、ここにアクセス許可を出すIPを追記していく。
もしどこからでもアクセスさせたい場合はbind-addressをコメントアウトすれば、可能になる。
mysql内の操作権限は、
mysql > GRANT ALL PRIVILEGES ON db名.(テーブル名 or *) TO 'ユーザー名' IDENTIFIED BY 'パスワード'; FLUSH PRIVILEGES; //反映
でアクセス権限を許可できる。 ↑は全ipに対して許可してしまうので、実運用ではホストの制限をするなどは必要になるかと。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.1.4 GRANT 構文
ホスト制限等はドキュメントを。
ssh_exchange_identification: Connection closed by remote hostエラー
ssh_exchange_identification: Connection closed by remote host
CircleCIからawsにssh接続させようした時にハマったエラー
ググってたらサーバ側でIP制御してるからとかいう記事があり、そういえばEC2のセキュリティグループにCircleCIのIP許可してないと思い、追加したのだがまだ解決しない。
ssh debugとかしていろいろ試してみるも解決しなかったが、
なんてことはない CircleCIコンテナのsshconfigにUserを追加していなかったので、どのユーザーで認証するかが渡されてなかったっぽい。
sshconfigの存在を知らず、先輩のコピペを理解せずにそのまま使っていたのがダメですな。
AWS上のDockerにアクセスする
ポートフォワーディングなるものを知らなかったのでメモ
aws上にnginxのdockerコンテナを立ち上げたのだが、アクセスできず悪戦苦闘していたところ、ポートフォワードを設定していないのが原因だった
docker run -itd -p 80:80 imageID nginx
-p 80:80のところがポートフォワーディング。
EC2の80にアクセスしてきたものをdockerの80に転送しますよというもの。
これで80で待ち受けているdocker上のnginxにアクセスできた。
hashicorpのottoを触ってみた③ ~Appfile
前回 hashicorpのottoを触ってみた② ~ビルド・デプロイ
infraの設定からデプロイまで行いました。
ただデフォルトの設定で、全て行ったので今回はそのカスタマイズを行うAppfileについて書いていきます。
Appfileはプロジェクトのrootに置くことで、反映されます。
ただ反映されると言ってもotto compileを叩いてcompileするまでは反映されません。
Appfile
Appfileの書き方を実際に見ていきます。
//Appfile application { name = "otto-getting-started" type = "ruby" } project { name = "otto-getting-started" infrastructure = "otto-getting-started" } infrastructure "otto-getting-started" { type = "aws" flavor = "simple" } customization { ruby_version = "2.1" //goの場合の書き方はgo_version = "1.4.2" }
ottoの公式サイトから持ってきました。
軽く説明すると
application
nameはプロジェクトの名前(一意じゃなくてもいい)
typeはアプリケーションのtypeを記述
typeは今のところJAVA,docker,go,node.js,ruby,pythonがデフォルトで対応しているようです。project
nameはprojectの名前で一意にする必要があります。
infrastructureはotto infraで作成したinfrastructureの設定名
次に書くinfrastructureの名前と同一名にする必要があります。infrastructure
typeはdeployされる環境の名前です(現状awsだけっぽい?)
flavorには、simpleとvpc-public-privateの2つが設定可能です。
simpleはaws上に最低限の構成でdeployします。
vpc-public-privateを設定するとbastion hostsやNAT serverなどを使った踏み台を経由するような構成でdeployが行われます。
(ここらへんまた詳しく調べたい)customization
これは基本的にotto devしたときにプロジェクトで使っている言語を見て、必要な物をinstallしてくれるのですが、その中でもversionを変更する必要がある場合に使います。
見ての通りrubyの2.1を落としたい場合に使っています。記述しないとデフォルトのバージョンがinstallされます。
このようにrootディレクトリにAppfileを置き、otto compileを実行することで、カスタマイズができます。
もっと細かいことができると思うので(awsのregionとか切実に変更したい)もっと使ってみて次回書いていきたいと思います。
hashicorpのottoを触ってみた② ~ビルド・デプロイ
だいぶ前のhashicorpのottoを触ってみた① ~ローカル環境構築
の続編です。
今回はローカルに作った環境をAWSにデプロイするところまでを書いていきます。
otto infra
前回
otto dev
でottoの環境を作成しました。
otto infraはそれをデプロイする先のinfra構成の設定ファイルを作成します。
otto infra
と叩くと、内部でterraformを使っているみたく、terraformのインストールを求められます。
インストール後AWSのaccess_key,secret_key,公開鍵,ottoが管理する設定ファイルの暗号化のパスワード(今後のコマンド叩いた時に入力を求められる)を求めてくるのでそれを入力。
するといろいろ動きながら、VPCやらsubnetやらinstanceやらの設定をごにょごにょして作成してくれます。
*もし設定の入力ミスをした場合は~/.otto.d/cacheを消してotto infraを叩けば再度設定が行えます。
完了した後otto statusを叩くと、
otto status ==> App Info Application: otto-getting-started (go) Project: otto-getting-started Infrastructure: aws (simple) ==> Component Status Dev environment: CREATED Infra: READY Build: NOT BUILT Deploy: NOT DEPLOYED
現在の進捗状況が分かります。infraがREADYになってますね。
otto build
次はデプロイするためにビルドを行います
otto build
これを叩くと今度はpackerのインストールが求められます。
インストール後、デプロイ先がAWS環境なので自動的にAMIが作成されるのですが、
まだgoのプロジェクトのビルドには対応していないようでエラーが出ました。
なのでbuildからはrubyのアプリケーションで行いました(わかりにくくすみません)
rubyプロジェクトだと無事AMI作成できました。
otto deploy
いよいよデプロイです。 これも簡単で
otto deploy
と叩くだけです。
するとAWS上に今まで設定したものが実際に反映されていきます。 *デフォルトのデプロイ先のリージョンがus-east-1(米国東部)になってるので注意。 多分変更できるんじゃないかと(次回調べます) otto deployの最後に
Outputs: url = http://ec2-50-90-121-35.compute-1.amazonaws.com/
のようにurlが吐き出されるので、url先にアクセスするとプロジェクトがデプロイされて動いているのが確認できます。
以上がinfraの設定からデプロイまででした。 今回ほぼデフォルトでデプロイしたので、次回はリージョンとか変更するなどいろいろ設定を変えてデプロイまで行いたいと思います。