katsuyukikun’s diary

とある天パーエンジニアのblog

壮大な良い目標をもつことが結構大事

sao-movie.net

SAO(ソードアートオンライン)の映画、オーディナル・スケールなるものを見に行ってきました。しかも無駄にMX4Dです笑。

MX4Dはアメリカのロサンゼルスで1991年に発足したMediaMation社によるもので2012年頃から色々な劇場で使われ始めたようです。日本では、2015年4月10日にオープンしたTOHOシネマズ ららぽーと富士見での展開が初となりました。

MX4DはTOHOシネマズ独自の「TOHO 4D PROJECT」のもと展開される、TOHOシネマズだけの映像アトラクションシステムとなりますので、限定された劇場だけでしか体感することができません。

また、以下が体験できます。

・シートの突き上げ ・首元への感触 ・背中への感触 ・香り ・風 ・水しぶき ・足元への感触 
・地響き ・突風 ・霧 ・ストロボ

 

いやー、やはりあの世界に夢を持ちますよね〜〜〜、、、とまあ今日からの3連休を早速夜更かしからスタートしている訳ですが、そんな中「最強のNo.2」という本を読んだのでそれのアウトプットでもしようかなと思います。

 

 

最強のNo.2 (U25 SURVIVAL MANUAL SERIES)

最強のNo.2 (U25 SURVIVAL MANUAL SERIES)

 

 

 

この本は2013年に出たものでサイバーエージェント取締役の曽山さんの著書。ここでいいう「最強のNo.2」というのは以下であると冒頭で定義してくれている。

「最強のNo.2」を言い換えれば、誰かにとって「必要不可欠な存在になる」ということだ。メンバー、上司、経営者、つまり会社にとって必要な人になれば、それは社会にとって必要な人となる。

 

大きなことを成し遂げようとすると一人ではできない、だからこそ仲間が必要だしその仲間たち自身が”組織”を強くしていく必要がある。こうすることで会社は成長し、意味ある価値を世の中の人たちにより多く与えることができる。そのためには全員が組織に目を向ける必要があるし、その組織・その会社で必要不可欠な人間になることができれば社会にとっても必要な存在になることができる。では、そのためには何をすればよいのでしょうか?その答えに近づける考え方が紹介されている本といっても過言ではない内容だと思います。

 

そこまで内容が長くないので全て紹介してもよいのですが、文章にすると長くなりそうな気がするので心に残ったことをピックアップしたいと思います。姿勢・マインド・やりかたの3つにわけて記述できればと思います

 

姿勢

この本では以下3つを紹介しています。

  • 自分の中に問いを持つ
  • 『ANDの才能』で考える
  • とことん素直でいる

 

この中でも『ANDの才能』で考えるは当たり前ではあるのですが改めて「なるほどな〜」と感じました。これどういうことか「会社AND自分」になるように思考し、実行していくということです。会社への貢献を通じて自分のやりたいことをやるというまさにどちらかひとつではなくどちらも手に入れてしまおうという発想です。逆にORで考えるというのは、会社に所属していたら自分のやりたいことができないといった発想のことです。「これがやりたいんだ!!」という人はそれが会社の貢献になるようにつじつまを合わせれば良いだけである。逆にそういったやりたいことがない人はどうするのか、これに関しては会社がこれからどうなっていくのか、そのためにどういうことをしていくべきなのかといった事業戦略的なことから落とし込んで興味ありそうなもの、取り組むべきものというのを洗い出すのも手かもしれません。

 

というか個人的には後者の発想でしたww「なんか技術力つけたいんだけどやることわかんねーな」という感じだったのでこれから事業がどうなっていくから今これしとくかというほうが成果出せるのと新しいことやれるしで良いことづくめでした!

 

マインド

どの視座から物事を常に考えるのかということです。この本の中では特にその考え方をするための「習慣づくり」という括りになっています。以下3つを紹介しています。

  • 決断経験
  • 意思表明
  • 大きな志

この中ではタイトルでも述べた通り「大きな志」について記述していきます。個人的にはこれが一番目から鱗でした。

何をするにも大きなビジョンや志を持っているのと持っていないとではあとあと大きな差になると思っています。なぜならそういったものを持っている場合、そこに向かうために自分がなにをすればよいのかと考えるようになり、そのために日々行動することができるはずです。なので持つことは大切なのですが、この本の中では「人を動かすにはビジョンや志が必要」とあります。ただそんなもん理解しているけど持てねーよという方がいらっしゃると思います。そのときには「もし自分が世界史に残るとしたらどう書かれたいか」ということを考えてみてください。そしてそれを書き出してみて自分が一番ワクワクするものを志にするとよいかと思います!

 

やりかた

この本のなかで具体的な行動も書かれています。「目標を設定しましょう、評価をしっかりしましょう」と。そんななかで僕が大事だなと思ったのは以下です。

  • 環境力

成果を出せるような風土や仕組みを自ら作っていきましょうという話です。個人的にはこれはすごく大事だと思っています。あくまでも個人的な意見ですが、人はなにをするにも「その行動を促すきっかけ」で行動していると考えています。つまり三日坊主になってしまうのは、そうなるきっかけとなる行動をしているからで意思とは関係ないということです。なるほどなーと思うのでこちらの本も読んでみるとよいかもしれません。

 

新版「続ける」技術 (Forest2545Shinsyo 41) (フォレスト2545新書)

新版「続ける」技術 (Forest2545Shinsyo 41) (フォレスト2545新書)

 

 で、そこで大事になってくるのが環境作りです。良いと思っている行動をするときのきっかけを常に与えられるような環境をつくり、逆に悪い行動をするときのきっかけは起こらないように環境を作り変える。環境次第で日々の生活のなかで行動できることが決まってくると思っています。まずはなにを良いと定義するのか、その行動をするきっかけはなんなのか、行動をハックしていきましょう!

 

まとめ

定期的に自分がこの一生で成し遂げたいことがなんなのかというのを見直す時間というのは月1くらいで必要なのかもしれません。その度に変わってもいいと思います。過去どういうことを目指していて、現時点ではどうなのかログをつどつど残していきましょう。おそらくそのログを見直すときに毎月似たような考えが出ているならおそらくそれが本当にやりたいことだと思います。

一度しかない人生、自分で制限を設けることなくフラットに楽しんでいきましょう!!

 

 

終わり。

サーバー移行時のざっくりとした手順と考えるべきこと

ちょっとした記憶の整理。

2016年の10月くらいから2ヶ月間かけて事業の全サーバーをGMOクラウドからAWSへサーバーを移行したのでそのときの手順。本当は終わった直後に書けば記憶が鮮明なので詳細に書けたのに・・・それを言っても仕方ないのでとりあえず思い出せるだけ思い出します。

 

f:id:katsuyukikun:20170317012524p:plain

 

と話に入るまえにこういった大きなことをするときのポイントを述べておきます。それは

既存の環境(GMOクラウドの環境)をなるべくそのまま新規の環境へ(AWS)へ移す

 

これ結構大事です!移行しようとして色々調べたりすると「あれ?これいらなくね?」とか「え?これこのバージョンなの?あげたほうがよくね?」といったものが結構多く出てきます。しかしここはぐっとこらえて一旦、目を閉じましょう。もしリファクタリングみたいなことを同時にしてしまうとエラーになったときに、問題の原因特定が極めて困難になります。

ちなみに僕はアプリケーション側のサーバー設定のときに設定ファイル含めリファクタリングしながらやってしまい、結構困りました。エラーになったとき「新規のサーバーの設定ミスなのか?それともリファクタリングしたときのミスなのか?」と原因推測の範囲が分散してしまいわけわからなくなりました。もしこれをリファクタリングしないで進めていたとすると、既存の環境では動いていたのは事実なのでサーバーの設定ミスっぽいなと、ある程度明確に当たりをつけられます。もし古いものを新しくするときはこのことを覚えておくと結構早く物事を進められるかもしれません。

 

 

話を戻して以下が手順です。

  • 既存のネットワーク、サーバー構成の確認

新規で0→1のサービスを作るならこんなこと考えなくて調べて洗い出してみたいなことをやらなくていいし、やるとしてもおそらく今だとgithubとかでどういう設計にしたのかを残しておくと思うのですが。。うちの事業は10年くらい前からやっていてそのときの記録が一切ないので現状を把握することから始めました。

 

  • 既存で使われているライブラリやツールの確認

うちはnginx→unicornでサーバーが構成されていました。各々のサーバーでどんなミドルウェアが使われいるのかを確認します。

 **ここまでが現状の理解になります**

  • 新規のネットワーク・サーバー構成の考案

ここは全体設計の話なのでかなり楽しかった記憶があります笑。サーバーの移行なんてそうそう行うものではないので「自分の考えた構成が残っていくのかぁぁぁ」と深く感動したものです。ただこの頃インフラなんて触ったことなかったので設計と言われてもなにがなんだか・・という感じでした。

なのでキャッチアップしながら進めました。以下が流れです。

1:とりあえず「サーバー移行」と適当にググったりインフラの本読んだりする。

Amazon Web Services 基礎からのネットワーク&サーバー構築

Amazon Web Services 基礎からのネットワーク&サーバー構築

 

 

2:それらを見て・読んでなんとなくの全体像を把握。名前すら知らなかったのもあったのでここでは本当に「こんな感じなのかー」という感覚をつかむ程度。 

3:(自分の環境を作ってまずは遊んでみるのもあり)

4:設計の本を読んだり、他社さんのを参考にしたりする。以下を読みましたね。あとはAWSのブログとか見てたような気がします。

 

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

 

 

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

 

 

aws.typepad.com

 

5:4まででなんとなく設計に必要そうな技術がわかるのでとりあえずそれらを知っておく、また似たようなことができるのもあるのでそれらの違いを理解する。僕の中では「elastic beanstalk / opsworks / cloudformation」の違いがよくわからなかったのでそれを結構調べましたww

6:以上のことを踏まえて設計を考える。真似でも良いと思います。その候補が上がったら、各々の候補同士でメリットデメリットを考える

7:デメリットを考えるときは「一番最悪のことが起こったときどう対処できるのか」という基準を持つとすっきりします。

 

全体の話に戻します。この先は言わずもがなですね。

  • 実際に構築

実際に作る前に部分部分で小さく作って問題ないのかの検証して、できなさそうならもう一度考えて作って検証するというのの繰り返しをやって「できる!」となった時点で実際の全体構築に入りました。

  • 全体のテスト

アクセステストやらDBがちゃんと動いているのかといったテストをしました。

  • 本番環境にする

 

というのが僕がやった時の流れです。実際に作るときには、「これできるのか?」みたいな検証に時間がかかってたような気がします。そんな時はAWSのサポートに問い合わせてみると答えが返ってくるかもしれません。最終こんな感じになりました。

 

f:id:katsuyukikun:20170317212708p:plain

 

 

こだわったポイントは以下ですかね笑

・この図だとわかりませんがcapistrano deployからblue green deploy方式に変えた

・この図だとわからないかもしれませんが、セキュリティ面強化のためにweb機をpublicにapplication機をprivateにおいた

・AMIを主体にcloudformaiton一発でこの環境ができるようにした

 

 

 

 

最後に・・・・

最近は、そろそろGCPを触る時が来たかなと思っているのでAWSからGCPに移行してみたというのもやってみようと思っています。

 

www.publickey1.jp

 

 

終わり。

 

DroidKaigiに初めて参加してみた

初めてブログを書きます!

技術系の話の定期的なアウトプットの場としてやっていこうかなと思います。qiitaでも良かったんですが、読んだ本のアウトプットとかだとちょっと場違い感があるので、こちらで気ままにやっていきます。

 

今回は第一回ということで何を書いて良いかわからないのでとりあえず最近行ってきたイベント、、、3月9日、10日とベルサール新宿グランドで開かれたDroidKaigi 2017について、今年初参加なのでその感想を軽く書こうかなと思います。

 

droidkaigi.github.io

 

そもそもDroidKaigiってなんなのかというと、Android技術情報の共有とコミュニケーションを目的の場です。ちなみに2015年から毎年開催されているカンファレンスで2017年は第3回目です。動員数800名、セッション数も2日間で67。スポンサーは30社と結構大きいイベントっぽいです。

 

【全体の感想】

そもそも僕はandroid開発経験ゼロ・・最近趣味でチュートリアルっぽいのをいじってるくらいのレベル、しかもカンファレンスというもの自体今回が初めてです笑。

そんな僕ですら、かなり良い勉強になりました!2日間で8000円でしたが払う価値は十分あるなといった所感です。(ご飯も美味しいし、お菓子も食べ放題wwマフィンみたいなやつがめちゃ美味しくてずっと食べてました笑)

 

【セッションの感想】

タイムスケジュールにはセッションの概要が載っています。そこにレベル感(初級〜中級といったもの)が書いてあり、自分のレベルに合わせて聞きに行けます。また今回がたまたまだったのかよくわからないですが、僕レベルでもわかるような、興味を持てるような内容が多かった印象ですね。あと全体設計の話、ドメイン駆動設計(DDD)の話はどこでもしてたなといった印象ですかね。マイクロアーキテクチャというワードも流行ってるしこの辺の流れなのかな・・・

個人的に印象に残っているのは以下2つ。

 

speakerdeck.com

 

 

speakerdeck.com

 

⬛︎ 大規模アプリのリノベーション

はてなブックマークアプリのリファクタリングについてのお話です。リファクタリングはまとまった時間を取らないと、それ自体が負の遺産になっちゃうよねという話から始まり具体的にどう進めていったのかというのが詳細にわかります。何年も行ってきているサービスに携わっている人なら非常に共感でき、学べることも多い内容だと思います。

 

⬛︎ androidアプリ開発の体力づくり

メルカリ→ソウゾウでandroidアプリ開発を行ってきた人が初心者向けに行ってくれたセッションです。「なんかアプリ作りたいけどアイデアねーよ」とか「技術以上にデザインの部分で詰まって困るよねー」といったアプリを初めて作る人が抱きそうな感情の共感から話が始まり、どういうマインドで作っていくべきなのか、また最新の技術はどうキャッチアップしながらやっていくのか、アップデートのタイミングはどうするのかといった内容でした!とりあえず頑張ってやってみようという気持ちになりましたwww

 

【会場の雰囲気】

セッションごとに自分で聞きたい部屋に行く、、大学の講義を思い出しました笑。会場自体はわりかしフランクな雰囲気だったかなと思います。

今回は、お菓子食べ放題コーナーと企業ブースが同じ部屋にありました。僕はマフィンを食べに毎回その部屋に入っていたのですがかなり賑わっていました。また企業側の方もフランクに話しかけてくださります。「今回初参戦なんですよね、しかもandroid開発も最近始めたばかりで・・」と言うと技術のこと含め色々教えてくれたりしました笑。そんなのもこう言ったカンファレンスだからこそ楽しめるのかもしれません。

 

【まとめ】

今年は初心者という域でしかセッションを聞けなかったので次回はちゃんと込み入った話を聞きに行きたいと思いました。あとどうせならめちゃくちゃandroidに触れて次回は登壇者としてやってみたいなという思いがふつふつと湧いています笑。

 

終わり。

 

 

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 

 

 

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)