Goalist Developers Blog

EC2とELBでかんたんhttps環境構築メモ

AWSでhttps通信できる開発環境をさくっとつくる

こちらのお手軽パターンです

https://recipe.kc-cloud.jp/archives/11067

ドメインはすでに購入済み前提
証明書はACM(AWS Certificate Manager)で取得します

  • Amazon Linux 2
  • nginx 1.15
  • ALB(Application Load Balancer)

手順

  1. EC2インスタンス作成
    1.1. インスタンス作成
    1.2. インスタンス初期設定
    1.3. nginx導入
  2. ロードバランサー作成
    2.1. ALB作成 2.2. 証明書の設定
  3. http→httpsリダイレクト設定
  4. Route53設定

詳しく

1. EC2インスタンス作成

1.1. インスタンス作成

いつもこちらのqiitaみてます😘

qiita.com

今はAmazonLinux1と2のAMIどちらも選べますけど
今後のことを考えて2を選んでおきます

https://qiita.com/michimani/items/146d1f986d78e06d510e

EC2インスタンスにかけてるセキュリティグループで、80番ポートをオープンしておく

ロードバランサーの設定で使うため
サブネットは違うアベイラビリティゾーンでもうひとつ切っとく、使わないけど

こんな状態にしていきます

f:id:y-iio:20180925134027p:plain

1.2. インスタンス初期設定

yum更新

sudo yum update

タイムゾーンの設定

sudo timedatectl set-timezone Asia/Tokyo

1.3. nginx導入

こちらを参考にしました

www.rem-system.com

コミュニティリポジトリ使わないといけないので
後々面倒なことになったりするのかしら

sudo vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1

インストールと自動起動設定

sudo yum install nginx
nginx -version
sudo systemctl start nginx
sudo systemctl enable nginx

IPでブラウザからアクセスしたら

f:id:y-iio:20180925132459p:plain

デフォルトページが表示されてればおっけ〜です

2. ロードバランサー作成

2.1. ALB作成

いつもの😘

qiita.com

httpsリスナーを追加します

f:id:y-iio:20180925132531p:plain

2.2. 証明書の設定

ドメインはすでに持っている前提
ACMから新しい証明書をリクエストして使います

f:id:y-iio:20180925132544p:plain

あとは手順1で作ったインスタンスをターゲットグループに登録してELB作成

EC2インスタンスにかけてるセキュリティグループで、ロードバランサーのセキュリティグループを許可

ロードバランサーのDNSでブラウザからアクセスできるようになりました〜

3. http→httpsリダイレクト設定

公式を参考に設定ファイルを書き換えて

ELB を使用して HTTP トラフィックを HTTPS にリダイレクトする

sudo nginx -t
sudo systemctl restart nginx

4. Route53設定

route53のAレコードにロードバランサーのDNSを登録

ELB ロードバランサーへのトラフィックのルーティング - Amazon Route 53

これだけ!

Gitがやばい(3/3)!

Gitがやばいの最終編です!前回はbranch, merge, fetch, pullについて書きました。普通のプロジェクトにはここまでは必ず使うでしょう。

実は、もう一つのよくみる現象があります。それは「マージコンフリクト」です。「コンフリクト」が入ってるために何か怖いものに聞こえますが、とてもよくあって、とても簡単に解決できるものです。

マージコンフリクトを再現する

一編から使ってるプロジェクトを使って、マージコンフリクトを見てみましょう。

下準備

ちょっとした準備しましょう。masterブランチでA.txtとB.txtというファイルを作成してコミットしましょう。

$ nano A.txt
$ nano B.txt
$ git add .
$ git commit -m "A.txtとB.txtを追加しました。"

私は上記のようにしましたが、コミットすればなんでもOKです。 こういうのが出ます。

(Create mode image)
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 A.txt
 create mode 100644 B.txt

コンフリクトはどういう状況でおきるのか

さて、状況を想像しましょう。

このプロジェクトには、二人が参加しています。二人はそれぞれのタスクがあります。 AくんはプロジェクトでA.txtのファイルで、「Aがすごい」を書くのがタスクです。 BさんのタスクはA.txtに「B.txtをみて!」を書き、B.txtに「Bが一番すごい」を書くことです。

くだらない内容ですが、重要なのはAくんとBさんが両方A.txtを編集することになります。こういう状況ではマージコンフリクトが起きる可能性があります。

シミュレーション

やってみましょう。AくんとBさんのためにそれぞれのブランチを切りましょう。

git branch B-branch

でBのブランチが作成できます(すでに知ってましたね)。

git checkout -b A-branch

上記のコードは

git branch A-branch
git checkout A-branch

を一行で書くためのやり方です。

f:id:c-pattamada:20180918160640p:plain

はい、現在A-branchにあります。では、Aくんのタスクをしましょう。 A.txtの中で、「Aがすごい」と書いて、保存して、コミットしましょう。

f:id:c-pattamada:20180918160723p:plain

masterに移って、マージしましょう。

git checkout master
git merge A-branch

ここでは、mergeのあとで書くブランチ名が現在checkoutされたブランチにマージされます。

f:id:c-pattamada:20180918160757p:plain

git logでAくんのコミットがみれます。ここは無事マージできましたね。問題なし!

マージコンフリクトが登場

では、Bさんのタスクも完了しましょう。git checkout B-branch

ここに気づくべきことが、A.txtがまだ空っぽのままです。なぜかというと、BさんのブランチがAくんのコミットの前の状態に切られたからです。 実際のプロジェクトでは、二人が同時に仕事している想定ですと、この状況はすごくよくあるかと思います。 A.txtに「B.txtをみて!」を書き、 B.txtに「Bが一番すごい」を書き、コミットします。 そして、masterに移ってマージしましょう。

git checkout master
git merge B-branch

うまくいきましたか?!や、ダメでした。 AくんとBさんが同じファイル(A.txt)を編集しましたので、gitが上書きすればいいのか、両方入れた方がいいのかなどがわかりません。 マージコンフリクトが行ってしまいました。

f:id:c-pattamada:20180918160825p:plain

マージコンフリクトを解決する

マージコンフリクトが起こっています。文字エディターでA.txtを開いてみますと驚くかもしれませんが…

<<<<<<< HEAD
Aがすごい
=======
B.txtをみて!
>>>>>>> B-branch

が書かれてます。javaだった場合には必ずコンパイルエラーが出るでしょう。

現在はmasterのブランチにB-branchをマージしようとしてますので、masterの現在のコミットはHEADと書かれてます。 <<<<HEAD=======の間には現在のmasterの状態。 =======>>>>>>> B-branchの間にはB-branchの状態。

今回は私が管理者で決める立場にあるので、両方の変更を含めたいと思います。 中身を編集して

「 Aがすごい
B.txtをみて!」

の状態で保存、または古い方を削除する判断もありえます。

ターミナルに戻り、git statusで様子みましょう。 マージしても大丈夫のファイル、B.txtが緑で、A.txtがまだaddされてないので

git add A.txt
git commit -m "マージコンフリクト解決"

おめでとう!初コンフリクトを解決できましたね。

最後に

ここでは、マージコンフリクトがどういう状況で起きるのか、そしてどんな風に解決できるのかについて書いてみました。この記事の内容と以前投稿した二つの記事で通常の時のgitは使えるかと思います。

Gitの機能は他にも山々あります。特にrebase, cherry-pick, submoduleなどが面白いですが、興味があるかたはそちらも調べてみてください(またあとで、私が投稿する可能性もありますw)。

これでGitに対しの自信が持てるようになってたら嬉しいです!

ちょっとした復習に、

Gitを使う利点

1) バージョニング管理で定期的にサーブ・ロールバックができる。

2) 複数の人が同時に複数の関係ない機能を同時に開発できるシステム

だと思いますので、一人のプロジェクトでも、大きいなプロジェクトでもとても便利です!

ぜひ、使ってみてください!

Getting Started with Dart (1/∞)

(Once again the lines above are editable so go ahead and replace my name with yours and press play button ▶️)

If you have missed my previous blog, you may find it here

developers.goalist.co.jp


Let's start learning the fundamentals of Dart.

f:id:vivek081166:20180827200359p:plain

In this tutorial, we shall learn about the basics of Dart Programming Language.

DartPad

Having the Right Tool for the Right Job is Important. Isn't it?

DartPad (https://dartpad.dartlang.org/) is an open-source tool that lets you play with the Dart language in any modern browser.

Yeah!! you read it correctly... No Installation... No Environment Setup...
DartPad is all you need to start learning/coding in Dart. Just open a DartPad on your browser and start writing your dart program.

f:id:vivek081166:20180827162548p:plain

On the left, you have workspace to write program and after clicking ▶️ Run button output of the program will be displayed in the console on right.

Dart Fundamentals

Program Structure

All Dart programs have to start with main()
main() is what we call a function and a function basically is a part of the program that does something. (more on that in subsequent bog :D stay tuned)

f:id:vivek081166:20180827164801p:plain

In the above code, program flow stars with void main()thereafter program prints Hello on console with print function print("Hello")
All dart programs have to start with main()

Variables and Typing

As you know, in programming, variables are used to store information to be referenced and used by programs. In other words, a variable is a value that can change, depending on conditions or on information passed to the program.

There are two ways to declare a variable in Dart
1) Dynamic Typing
2) Static Typing

Dynamic Typing

Dynamic typing is a weak typing which you might have seen in Javascript where a variable can have different types based on the type of value assigned to it.
Dynamic Typing : Variables can have different type
Let's try declaring and initializing variables with Dynamic Typing



In case of weak typing; type of a variable change depending on the circumstances.
In the above program, variable var a can hold a value of any type (string, integer, boolean etc.)
When not initialized all variables declared with var identifier always hold null value.


Side Note:

Single Line Comment in Dart Start with "//"
e.g.
// This is a single line comment

Multi Line Comment in Dart is enclosed in "/**/"
e.g.
/*
* This is supposed to be
* a multi-line comment.
*/


Static Typing

Static typing is a strong typing which is similar to other programming languages like Java, C more recently Typescript, where type is stated while declaring the variable and cannot be changed later.
Static Typing : Type of the variable is stated while declaring it and cannot be changed.


Life is easy with Strict Type checking, isn't it?

f:id:vivek081166:20180827183926p:plain


Learn about Dart in details here

www.dartlang.org

じゃ、That's it for this post... will come back with more on this...
Till then happy learning... :)

新卒三期、ブログを書く(エンジニア編)

こんにちは。

今年新卒として入社し、開発部に配属となった増田です。

以前、マスダさんという方がデザインブログに自己紹介を書いていますが、別人です。
僕はスプラトゥーンやっていません。
ただ、そのマスダさんとは出身大学も年齢も勤務地も同じだったりします。
どうでも良いです。

さて、ここから自己紹介(という名目の自分語り)をだらだらと。
技術ブログではありますが、技術的なお話は何もありません。


入社前

僕はゴーリストに入社する以前は精神的に健康的な大学生活を送っていました。
いや別に今精神的に不健康な生活を送っているというわけではないです。

どんな生活だったかというと、
お昼をすぎた頃に目を覚まし、お天気と気分が上々であれば服を着替え、
自転車に乗り、電車に乗り、大学へと向かい、
着いた後は大学の中にある一番大きな図書館の二階の、
これまた大きな窓に面する席で、
のんびりとただ読みたい本を読むなどする生活です。

その窓から見える細く高い木の枝や葉が、ゆさゆさ風に揺られているところとか、
自転車に乗っていたり雨の日には傘をさしていたりする学生たちが
構内をぞろぞろと行き交っている様子とかを、
ときたまぼんやり眺めるような、そんなゆったりとした時間の中を生きていました。

講義は必要最低限行かなければならないものにだけ行っていました。
なんなら必要最低限の講義さえ行かないことも。
おかげで一回生前期の取得単位数が一桁だったりしました。
そんな生活をした結果、二留。
ただの阿呆です。

あと大学にいたときには大学生らしくサークルに入っていて、
そのサークルの人たちと関わっているときにはしみじみと幸せに包まれたりなど。

あの時間が僕の人生のハイライトです。
どうあがいてもあれ以上幸せな時間はもうないだろうと思っています。
読みたい本を読み、好きな人たちと関わり、寝たいだけ寝て、...。

自然体。


就活

そんなのんびりした僕も、働かないといけません。
非常に残念ではありますが、現状そういうことになっているらしいので。

というわけで普通にイメージされるような就活をするのですが、
上手くいきませんでした。
上手くいかなかったというよりは面倒くさくなって諦めたと言うのが正しいのでしょうけど。
三社ほどにESを提出して、面接してもらって、それで終わりです。
諦めの早い、つまり潔い男なのです、僕は。

大きな挫折経験やそこから立ち直るまでの過程も、
何かを成功させたとか他の人を引っ張ったというような経験も、
人に話せるような立派な夢も目標も、
何もありませんでした。今もないです。

その上、志望動機は生活するのにお金が必要だからとりあえず働きたいというだけで、
その浅はかな動機を飾り立てるような元気もなく。
いろいろと無理でしたね。

でもむしろ僕みたいな人の方が絶対に多いはずで、
その辺の大学生が人に話せるような目立った経験とか立派な目標とか持ってるわけなくね
って思っています。持っていたらすみません。僕が世間を知らなかったということで。

基本的に親に言われるがままに受験したとか、
とりあえず公立の中高行って通りそうな大学に行って
普通にバイトしたりサークル活動したりしてたとか、
そういうものじゃないのですかね。知りませんけど。
とか言うのを書き続けると長くなるのでこの辺にして。


とはいえ働きたい(働かなければいけない)気持ちはあったので、
電子の海原を彷徨っていたときに見つけた採用イベントに参加し、
そこでたまたまゴーリストを知って、
流れのままに面接などをしてもらったら内定をもらえて、
というわけで僕はここでこうしてブログを書くに至っております。

ちなみに、いまだにどうして自分が内定をもらえたのかよく分かっていません。
こんな人間なので。
以前あった会社での食事会の際に、採用担当をされている人事の方から
「いや本当なんで採用したんだろうね」というようなことを言われもしましたし、
僕が採用されたのはたぶん何かの間違いなのでしょう。

でもまぁ何かの間違いだったとしても
幸運なことに今更採用面接がやり直されたりすることはないのです。
むしろこの僕をどう上手く使うかは上の人の腕の見せ所、
というくらいの気概でいます(嘘です。そんな大きな肝はありません)。


入社後

何はともあれめでたくゴーリストに入社して
東京の方で二ヶ月ほど研修を受けたのち、
どこかの部なりチームなりに配属されて、僕は大阪に移り、
そこから職種別研修があり、というような流れがあるのですが、
そういうのは他の新卒さんのブログを読んでいただければ分かると思いますので
僕は省いていきます。
そう、ビジネスでは効率の良さが求められるらしいのです。
ちなみに、僕の研修の成果はこちらに。

研修という名前はしていますが、順を追ってあれこれ教えてもらうようなものではなく、
初めはがっつり放置されてどうしようもなくなった頃に解答を提示される、
というような感じでした。僕の場合は。
僕以降の人(2019以降の大阪の新卒エンジニア?)は放置されるようなことはたぶんないらしいです。

一応大学の頃にちょこっとプログラミングに触れたりはしていたものの、
そんながっつりやったことはなく、
なのに全然知らない言語とかフレームワーク(この言葉自体理解していなかった)とかを言われて、
じゃ後は頑張ってね、なんて。
いや厳しいものでした。

今はその研修のときとはまた別のプロジェクトに割り振られ、
毎日パソコンの画面を見ながらプログラミングをしております。
プログラミングしかしておりません。
目が疲れます。
あとお腹もよく痛めます(汗と冷房のせい)。


大阪支社

せっかくなので僕のいる大阪支社の雰囲気をちょっとだけお伝えしようかと思います。

とにかく東京の本社の方に比べて静かです。
ざっくり言うと会話がないということなのですが、
でも最近は比較的賑やかな場面もあったりして、
別に非人間的な生活が営まれているというようなわけではありません。

人数が今のところ5人で、僕にはすごく心地良いです。
でもきっと今後増えていくのだろうなぁという予感はあります。予感というか、増えていきます。

僕は周りの人が増えれば増えるほどその人たちとの間に距離を感じてしまうらしいので、
人が少ないのはすごくありがたいです。少なすぎるとあれですけど。

大阪支社の上司(という言葉は正直違和感しかないのですが)の方々(と言ってもお二人)も、
先輩も同期もみな良い人たちで、感動しております。
僕自身が良い人かどうかは知りません。人によりけり。


そんな感じでもう十分書いた気になったので、この辺で。
結局大阪支社は静かなところということしか書いていませんが、
それで全部と言っても過言ではないでしょう(流石に過言)。


おしまい(終わりはいつも突然に)。


Visual Studio Code拡張機能の紹介

こんにちは。

Visual Studio Codeはマイクロソフトによって開発されているソースコードエディタです。

Visual Studio Codeの利点は無料で、使いやすいことと多くのプログラミング言語に対応していることです。 また、適切な拡張機能をインストールすることで、標準では用意されていない機能を追加し、Visual Studio Codeをさらに便利な開発環境に進化させることができます。

現在、ゴーリストのフロントエンドチームはAngularを使っているので、本日Angularを使うフロントエンド開発のため、いくつかの好きな拡張機能について紹介させていただきます。

1. Angular 6 Snippets

Angularをプログラミングするとき、AngularのキーワードとAngularの構文とAngularのコーディング規約を補完するための拡張機能です。Angularプログラマに非常にお勧めです。

Angular 6 Snippets - TypeScript, Html, Angular Material, ngRx, RxJS & Flex Layout - Visual Studio Marketplace

2. CSS Grid Snippets

2次元レイアウトを、HTML/CSS を使って簡単・自由に操作できるCSS Gridの構文を補完するための拡張機能です。フロントエンド開発者とデザイナーに非常にお勧めです。

CSS Grid Snippets - Visual Studio Marketplace

3. Debugger for Chrome

Google Chromeを使って、Visual Studio Codeソースコードエディタでソースコードに直接的にブレークポイントを追加して、デバッグするための拡張機能です。フロントエンド開発者に非常にお勧めです。

Debugger for Chrome - Visual Studio Marketplace

4. TSLint

書いているTypeScriptのソースコードを解析して、既に定義されたルールに違反していることがある場合、警告が出される拡張機能です。プログラムの保守性・安全性を保ち、機能的なバグを防ぐため、TypeScriptプログラマに非常にお勧めです。

TSLint - Visual Studio Marketplace

まとめ

良いツールを使うことで、プログラミングは大変なことから楽なことになりますね。

Visual Studio Code拡張機能をインストールすることは簡単です。上記の各リンクをクリックして、拡張機能の表示ページにある「Install」ボタンをクリックすれば、拡張機能は自動的にインストールされます。
デフォルトではなくて、拡張機能を詳しく設定したい場合、上記の各リンクをご参考ください!

紹介させていただいた拡張機能を使ってみて、楽しいプログラミングの時間をお過ごしください!

Gitがやばい!(2/3)

いよいよGitのやばさの続きですね。

前回の「Gitがやばい(1/3)」では基本コマンド、status, commit, addなど、そして便利なgitignoreの書き方などの最低限の知識を説明しました。

今回はよくある状況 1) 一回リリースしてからも開発が続く状況 2)他の人と一緒に開発を行ってる設定

には必ず必要となる、Gitのブランチ・マージなどの本格的なバージョニング部分に触れたいと思います。

では、始めましょう。

Level 2: branch, merge, fetch, pull,

「Gitがやばい(1/3)」で作ったプロジェクトをこちらにも使うと思います。

Branch

まずはbranchを作りましょう git branch new-branch “new-branch”の代わりに好きな名前を書くと、新しいブランチがその名前で作成されます。このやり方で、新しいブランチが現在のブランチと同じコミット履歴・ローカルのファイルの状況などになります。

git branch (パラメータなし) で現在、ローカルで置かれてるブランチが見れます。

f:id:c-pattamada:20180808183042p:plain

*が付いてるのが現在checkoutされてるブランチ。

git checkout new-branch で新しく作成したブランチに移動しましょう。

ちなみに、新しいブランチを作成して、それをcheckoutするための短い書き方もあって、それはgit checkout -b new-branchです。-bのフラグを入れることによって、checkoutが新しいブランチを作成してからcheckoutすることになります。

git logを打ちますと、このような出力が見られます。

f:id:c-pattamada:20180808183053p:plain

Masterとnew-branchのコミット履歴があります。現在は一緒です。 もう一つのコミットを作成しましょう

$cat > file.txt
some_text
$git add .
$git commit -m "another commit"
$git log

f:id:c-pattamada:20180808183103p:plain

追加のコミットがnew-branchの履歴だけにあって、masterがまだRevert "最初のファイル作成、と.gitIgnore"のコミットに残ってますね。

図をかくやり方もありまして

o-o <- master \ o <- new-branch

merge

これで終わりでしたら、mergeができます。それも、やり方が二つあって、一つはローカルでマージすること、もう一つはオンライン(remote)でマージする方法。ローカルの場合には、masterをcheckoutし、git merge new-branchでうまく行きます(conflictがない場合) 自分ならほとんどオンラインでマージしますので、そのやり方を説明します。

まずはnew-branchをpushしましょう。やり方覚えていますか? git push -u origin new-branch

そして、オンラインのリポジトリを確認しますと…

f:id:c-pattamada:20180808183121p:plain

(ちなみに、このリポはhttps://github.com/vortexkd/git-tutorial で見れます)

ここでプルリクを出して、次の画面でマージしましょう。

f:id:c-pattamada:20180808183331p:plain

(緑のボタンを押したら...)

f:id:c-pattamada:20180808183359p:plain

さて、これで、ローカル環境にない編集をremoteで行いました。

それはどうやってローカル環境に持ってくるのでしょうか?

fetch

まずは、ローカルでmasterをチェックアウトをし、statusを確認しましょう

f:id:c-pattamada:20180808183429p:plain

ここではremoteのマージが見えない?!あれれ、?

はい、それはremoteの情報はまだremoteにしかなくて、ローカルにそれをみるために’fetch’を行いましょう git fetch

f:id:c-pattamada:20180808183639p:plain

もう一回確認しますと、ちゃんとありますね。うえに”Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.”と書いてあるのがその通知です。

ローカルでpull, merge,などの処理を行いたい場合にはまずfetchを実装した方がいいでしょう。「知らない間にremoteが更新されてるかもしれません。(共同開発の場合)

pull

では、remoteの編集をローカルに持って行きましょう git pull !

f:id:c-pattamada:20180808183458p:plain

すみません、間違いました。

こちらです。

f:id:c-pattamada:20180808183710p:plain

お疲れ様です! これで、gitのbranch, merge, fetchとpullも使えるようになりましたね!

teamLab Planets TOKYO DMM.com に行ってきた

f:id:watabe1028:20180806122230j:plain

こんちは。
今回もイベントレポートです。
前回の記事
またもや、ただの遊びです。

昨年の今頃、ヒカリエでのイベントレポを書きました。
1年が早いですね。
 

タイトル通りですが豊洲の方に行ってきました。
本当はBorderlessに行きたかったのですがチケットが取れず。。。
当日思いつきで豊洲に行ったらあまり待たずに入れました。
 
 

イベント概要

teamLab Planets TOKYO DMM.com
場所:東京都江東区豊洲6-1-16 teamLab Planets TOKYO
期間:2018/7/7 〜 2020年秋
時間:10 〜 25時
料金:2,400円〜(大人)
詳細:

planets.teamlab.art
 

はじめに

まず入り口でスマホを入れて首から下げれるケースが借りれます。
これで水に落とす心配はないです。

靴を脱いで素足になります。
不要な荷物をロッカーに預けます。
床が鏡張りになっているため女性はスカートはやめておいた方が良いです。
もしスカートの場合でも会場でハーフパンツの貸し出しもやっているので必ず借りましょう。
長ズボンの場合でも膝上までまくる必要があるので借りた方が良いかもです。
水深は40cmくらいと考えておけば良いと思います。
 
 

Waterfall of Light Particles at the Top of an Incline

https://planets.teamlab.art/tokyo/jp/ew/lightparticles/
f:id:watabe1028:20180806122322j:plain
(写り悪くてすんません)
はじめに足の洗浄?がてらに浅い水の中を歩きます。
坂の上に滝があります。
憑依する滝の小さい版みたいな感じですかね。
もうテンション上がります。
 
 

やわらかいブラックホール - あなたの身体は空間であり、空間は他者の身体である

https://planets.teamlab.art/tokyo/jp/ew/soft_black_hole/
ダメになるクッションが敷き詰められている感じ。
普通に歩けない人もいるし、押すなよ押すなよ、をやっている人もいます。
まだ序盤なのにうとうとしている人も。
こんな部屋がオフィスにあったら・・・
(写真なし)  
 
 

The Infinite Crystal Universe

https://planets.teamlab.art/tokyo/jp/ew/infinite_crystaluniverse/
f:id:watabe1028:20180806122430j:plain
やっと来れましたCrystal Universe!
前回のPlanetsの時はラボにいたのですが
納期前で社員公開の時に行けませんでした。
トテモキレイ!
みんなインスタに上げるために必死で撮影してましたw
 
 
 

Drawing on the Water Surface Created by the Dance of Koi and People

https://planets.teamlab.art/tokyo/jp/ew/koi_and_people/
f:id:watabe1028:20180806122524j:plain
f:id:watabe1028:20180806122549j:plain
結構深くて膝下ギリギリまでくる!
くっ足が短いか・・・
小さい子供たちが次々と水に飛び込んでいく・・・
次に行けないじゃん。。。
(服が濡れてると次に進めません、とアナウンスあり)
 
 
 

Expanding Three-dimensional Existence in Intentionally Transforming Space - Free Floating, 12 Colors

https://planets.teamlab.art/tokyo/jp/ew/transformingspace/
f:id:watabe1028:20180806122618j:plain
f:id:watabe1028:20180806122650j:plain
チームラボボールがたくさん!
背の高い人はガシガシ頭にぶつかるからご注意を!
これ、子供は楽しいだろうな。大人でもはしゃぐし。。。
 
 
 

Floating in the Falling Universe of Flowers

https://planets.teamlab.art/tokyo/jp/ew/fitfuof/
f:id:watabe1028:20180806122740j:plain
床に座ってみれます。
寝っころがっても見れる。
何種類もの花が咲いたり散ったり・・・
余裕で1時間くらいいれそう。
同じ景色が一切ないので本当にずっと見ていられる。。。
 
 
 

Cold Life

https://planets.teamlab.art/tokyo/jp/ew/coldlife/
見逃しました。
どこにあったんだろ?
分岐があったのか、見ていたのに気づかなかったのか、残念。
 
 
 

最後に

遅くまでやっているので仕事帰りでも十分寄れます。
普通に回って2時間くらい。
足を水に付けれるので涼めますw
(中は冷房も聞いてますし)
 
また当日券も買えるので思いつきでいけます。
チケットもそこそこ安い。
 
今はレストランもオープンしてるみたいです。
ステーキやロブスターが食べられるお店
ポテトやサンドイッチが食べられるお店みたいです。
 
 
仕事帰りアートを見てディナーとか良さげですね。
自分は終電あるから無理ですけどね!