登山飯で味噌キムチうどん鍋してきました

こちらのブログ

【伊勢原の大山で登山してきました】

https://alexander.achanblog.mydns.jp/?p=356

の際に、登山飯を行ったので、そのときのレポートです。

 

日頃はお湯を山頂で沸かしてカップラーメンを食べるくらいで満足していたのですが、

 

今回は、もっと登山飯っぽいことをやってみました。

完成したのはこちらです。

味噌キムチうどん鍋

材料はこちらです。

食材

  • うどん5玉くらい(冷凍)
  • キムチ1パック(白菜キムチ)
  • 豚肉300グラム(冷凍)
  • 長ネギ
  • 味噌
  • だし(顆粒タイプ)
  • 2リットル
  • チーズ(パンとかに乗せるやつ)

調理器具

  • ガスコンロ & カセットガス
  • おたま
  • 菜箸

食器類

これらを6人で分担して持ってきました。

 

手順を追って説明していきます。

 

持ってきたものを広げます

水を1.5リットルほど入れて沸騰させたら

うどんとネギとだしを投入します。

豚肉を投入します

ニラを投入します。

キムチを投入します。

タッパーに入れて持ってきた味噌です。

味噌を、おたまと菜箸で溶かします。

写真は撮り忘れましたが、

たまごは4つでちょうど入る大きさのタッパーがあったのでそれに入れてきました。

クッキングペーパーで巻いてゴツゴツならないようにしたら、

山頂までリュックに入れていても、割れずに持ってこれました。

 

たまごを割ります。

たまごを溶きます。

鍋も良い感じに煮立ってきて、こんな感じです。

溶いたたまごを投入します。

完成です!!

1杯目はそのまま食べて、

2杯目は少し濃いめにして、チーズを入れました。

チーズは器の下に敷いておいて、その上からうどんをかけると

良い感じにチーズが溶けて美味しいです。

 

男性3人、女性3人で行ったのですが、

女性はちょうど良い感じでした。

男性はおにぎりとか持って行くか、うどんの量を増やすかしたら

ちょうどいいと思います。

 

以上、

山頂で味噌キムチうどん鍋でした!

登山飯好きな人の助けになれば幸いです!

今回初めて少し凝った登山飯にチャレンジしてみましたが、

とても楽しかったので今後またいろんな登山飯にチャレンジしてきたいです。

伊勢原の大山で登山してきました

伊勢原の大山

https://www.ooyama-cable.co.jp/

に行ってきたので、そのときのレポートです。

今回のスケジュールとしては

  1. 伊勢原駅北口に集合
  2. 伊勢原駅北口 ~ 大山ケーブル駅まで、神奈川 中央交通バスで移動
  3. 大山ケーブル駅 ~ 阿夫利神社まで、ケーブルカーで移動
  4. 頂上まで登山 & 昼食 & 下山
  5. 阿夫利神社 ~ 大山ケーブル駅まで、ケーブルカーで移動
  6. 大山ケーブル駅 ~ 伊勢原駅北口まで、神奈川 中央交通バスで移動
  7. 伊勢原駅 ~ 東海大学前駅まで、小田急線で移動
  8. 東海大学前駅 ~ さざんかという温泉まで徒歩で移動
  9. さざんか ~ たいざんという焼肉屋に徒歩で移動
  10. 焼肉を食べて解散

です。

伊勢原駅北口に 9:00 に集合して

解散したのが 20:15 です。

下山後に伊勢原駅に着いたのが、だいたい15:00くらいです。

伊勢原駅北口 ~ 大山ケーブル駅まで、神奈川 中央交通バスで移動

土曜日だったのですが、9:05 に北口発のバスがあります。

時刻表はこちらです

http://www.kanachu.co.jp/dia/diagram/timetable/cs:0000800825-1/nid:00128127/rt:0/k:%E4%BC%8A%E5%8B%A2%E5%8E%9F%E9%A7%85%E5%8C%97%E5%8F%A3

大山ケーブル駅まで直行するバスもあります。(時刻表に「直」の印があります)

伊勢原駅北口 ~ 大山ケーブル駅まで、神奈川 中央交通バスで移動

直行便には乗らなかったのですが、

25 分で大山ケーブル駅に着きました

大山ケーブル駅 ~ 阿夫利神社まで、ケーブルカーで移動

景色がとても良かったです

頂上まで登山 & 昼食 & 下山

頂上までの登山は約 1 時間 30 分ほどでした。

あまり休憩は挟みませんでしたが、急な傾斜は少なく、初級者でも登りやすいと思います。

ただ、足場は結構ゴツゴツしているところが多いので、

登山靴かトレッキングシューズはないと厳しいと思います。

下山は、見晴らし台を経由して 1 時間ほどかかりました。

 

昼食の際は、登山飯を楽しんでみました!

よければそちらのブログもご覧ください!

【登山飯で味噌キムチうどん鍋してきました】

https://alexander.achanblog.mydns.jp/?p=364

阿夫利神社 ~ 大山ケーブル駅まで、ケーブルカーで移動

こちらも行きと同様、景色がとても良かったです

大山ケーブル駅 ~ 伊勢原駅北口まで、神奈川 中央交通バスで移動

こちらも行きと同様、約 25 分ほどかかりました。

ただ 1 つ教訓がありました。

直行便でないバスが既に来ていたので、それに乗ったのですが

5分後に直行便が来る時刻表になっていました。

すると、伊勢原駅につく頃には、直行便のバスとほぼ同じようなタイミングで到着しました。

下山して疲れている状態だったので、少し待って直行便のバスに乗れば

座れて、かつ、そんなに先のバスにも遅れずに到着できるかもしれません。

伊勢原駅 ~ 東海大学前駅まで、小田急線で移動

さざんかという温泉に行くために、2駅移動しました。

東海大学前駅 ~ さざんかという温泉まで徒歩で移動

駅からさざんかまでは、徒歩で約 7 分です。

途中にコンビニもあります。

 

さざんかは、思った以上にフロントからキレイな温泉でした。

ジェットバスや電気風呂、露天風呂やサウナもあります。

平日 700 円、祝日 850 円で入れるにしては、そこそこいいなと思いました。

 

食事をするところもあります。

さざんかの HP はこちらです。

http://onsen-sazanka.com/

さざんか ~ たいざんという焼肉屋に徒歩で移動

さざんかから徒歩で5分ほどのところに

「たいざん」という焼肉屋があります。

味も普通に美味しかったです。

 

また、あまり見ないタイプの網を使っていて、

定期的にヒーターの部分に水を流すことで網に焦げがつきにくいような仕組みになっていました。

半数が女性だった、ご飯も食べたというのもありますが、

お腹いっぱい & お酒も 3 杯くらい飲んで

1 3000 円で済みました。

コスパの良いお店だと思います。

画像は牛タンです。とても美味しかったです。

たいざんの HP はこちらです。

http://www.fukuyamashouji.jp/taizan.html

まとめ

登山からの温泉という王道な流れでしたが、

  • 温泉
  • 焼肉

共にとても満足する内容でした。

とてもオススメです。

difficult points that make static website, using Route53, CloudFront, ACM and S3 via https

i think, there are some difficult points make https static website using Route53, CloudFront, ACM and S3.

so i searched and writing knowlege in this blog.

Route53

can’t select CloudFront distributions at CNAME Alias, after setting CloudFront.

please set Alias ” No “, and set CloudFront Domain Name in Value.


ACM

please set region US East (N. Virginia) when you get certificate.

if you other region you set, you can’t  select certificate in CloudFront AWS conslole.


CloudFront

can’t set certificate, after you get certificate at US East (N. Virginia) region.

answer 1:

please wait few days.

if you get certificate at Certification Manager, you can’t select in CloudFront immediately.

i waited few days and i could selected it.

 

ansewer 2:

you upload certificate by aws acli.

maybe you can select certificate at CloudFront AWS console immediately.

but i don’t try this method.

https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/

displayed file list of XML, via CloudFront

please set ” Default Root Object ” at CloudFront AWS console.

example, ” index.html “.

Access Deny occur, when you access your domain.

please set ” Alternate Domain Names (CNAMEs) ” your domain at CloudFront AWS console.

Access Deny occur via CloudFront

please public access setting, at S3 object and bucket at S3 BucketPolicy.

i setting every thing, but i can’t access.

there is possibility used cache at CloudFront.

so remove cache at Invalidation tab of CloudFront console. and input ” /* “.


S3

you can access “static website hosting” url. but can’t via CloudFront.

there is possibility, you did’t setting public access policy at S3 object and S3 bucket.

so you setting public access setting at it.

if you have too many object.

using aws cli command is very useful.

aws s3 sync . s3://my-bucket/path –acl public-read

error occur when public access setting at S3 bucket.

please select ” false ” at Piblic access settings of Permissions.

this function is add AWS console, at November 18th, 2018.

Route53 + CloudFront + ACM + S3 で https する際にハマったこと

ネットの記事をみながら構成していくなかで、ハマったこと

Route53

CloudFront の設定が終わって、Route53 で、登録したドメインの CNAME に、CloudFront のドメイン名を登録するときAlias を選択しても、Target の候補に CroudFront が出てこない。

Alias No を選択して、Value CloudFront のドメイン名を入力しよう。


ACM

証明書をとるときは、リージョンを「バージニア北部」にしよう。

そうしないと、CloudFront の画面で取得した証明書を選択できない。


CloudFront

バージニア北部」で証明書を取得しても CloudFront の画面で設定できない。

解決方法1:

待つ。

ACM で証明書を取得しても、すぐには CloudFront の画面で選択ができない。

私は 1,2 日待ったら選択できるようになりました。

 

解決方法2:

手動でアップロードする。

私は試してないですが、手動でアップロードすることですぐに反映されるみたいです。

Amazon CloudFrontの独自ドメインSSL証明書をAWS CLIでアップロードする

CloudFront 経由で S3 にアクセスしたら、ファイル一覧の XML が表示される。

解決方法:

CloudFront の設定画面で、「Default Root Object」を設定しましょう。

例えば、index.html など。

取得したドメインで、CloudFront 経由でアクセスすると AccessDeny になる。

CloudFront Alternate Domain Names (CNAMEs)」に、

アクセスしたいドメインの値を設定しましょう。

CloudFront 経由で AccessDeny になる。

S3 バケットポリシーで、オブジェクトとバケット全体を、パブリック公開設定にしましょう。

もろもろ設定したけど、やっぱりダメだ。

CloudFront でキャッシュが残っている可能性があります。

CloudFront Invalidations “/*” を設定して、全てのキャッシュを削除してみましょう。


S3

static website hosting url にはアクセスできるが、CloudFront 経由でアクセスできない。

バケットと、オブジェクトがパブリック公開になっていない可能性があります。

バケットポリシーを公開設定にして、各オブジェクトを公開設定にしましょう。

オブジェクトが大量にある場合は、 aws cli を用いてコマンドでサイドアップロードするのが手っ取り早いです。

aws s3 sync . s3://my-bucket/path  –acl public-read

バケットポリシーを公開設定にしようとするが、エラーになる。

「アクセス権限」の「パブリックアクセス設定」を全て false にしましょう。

この機能は、201811/18から AWS に追加されました。

Laravel の apache 設定

チュートリアルを進めていて、/tasks の URL に遷移しても、

index.php ではなく、/public/tasks にアクセスしようとしてしまう場合。

 

公式ドキュメント

https://readouble.com/laravel/5.1/ja/installation.html

にも書いてあるが、.htaccess が動作していない可能性がある。

そのときには、apache の .conf ファイルに下記のように設定をする。

<VirtualHost *:80>
    DocumentRoot /path/to/public/
    ServerName foo.example.com
    <Directory /path/to/public>
        Options Indexes
        AllowOverride None
        Require all granted

        Options +FollowSymLinks
        RewriteEngine On

        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^ index.php [L]
    </Directory>
</VirtualHost>

【コネヒトーク3rd「ここでしか聞けない!ブランド化するサービスの裏側を大公開」】に行ってきました

コネヒトーク3rd「ここでしか聞けない!ブランド化するサービスの裏側を大公開」

https://connehito.connpass.com/event/104037/

に行ってきたので、そのときのレポート

 

TKY+N LAB & DESIGN inc.  代表 タカヤ・オオタ さんから

Corporate IdentityCI)について

3つの要素で作られている。

  • mind identity
    どのような意思をもって作られているのか?
  • behavior identitiy
    我々はどんな行動をとるのか?
  • visual identity
    どんなロゴがいいか?全体的にどのようなトーンでつくればよいのか?

その中の一つとして、ロゴっていうのもあるということ。

なぜ、スタートアップのCIを担当しているのか?

  • 社会に対しての課題を明確にしているから思想が現れやすい。
  • story が大事。

UIの体系化と飽和化

いろんなUIが出てくるのが、昨今激しくなっている。

例えば、kurashiru と delish kitchen で比べたときに

こっちでできることがこっちでできないということが薄くなってきた。

これまでは、機能優位性で戦って来たが、これが飽和化してくると

使う理由が「ブランド」になってくる

なので、ブランドデザインは大事

株式会社Hotspring 代表取締役 有川鴻哉 さんから

事例照会

いま、ズボラ旅というサービスを展開している。

ブランディングを意識したサービス作りについての話をしようと思います。

私が考えるブランディング

  • サービスを主観ではなく第三者の目線で捉える
  • ものごとを考えるときの主語を「ユーザー」「社会」にする。
  • それによって、社会にどういう変化が起きるのか(小さなものでもいいから)を意識する。

 

ズボラ旅はLINEで完結するサービス

UILINEのまま。

ブランドを伝える唯一の手段はLPだけ?

 → ブランドのみで戦う。

ブランディングは見た目だけじゃなくて

サービスのアピールとかも含まれる。

ブランディングドリブンなサービス作り

全てはプレスリリースから

最初に、

機能追加することよりも、プレスリリースのような記事を書いてみるのが大事。

  • 機能、サービスを一言で表す
  • どんなメリットがあるのか、どんな社会になるのか
  • なぜ今そのサービスが必要なのか?機能追加するのか?理想と現実のギャップを埋める

一人よがりのコミュニケーションにならないようにしよう

誰に何を伝えて、どんなアクションをしてほしいか?それだけ徹底的に考えましょう。

例えば、「xx億円調達しました!」とかだけだとダメ。

それによってどのように社会が変わるのかを伝えないとダメ。

応援される、愛されるためのひと手間

これをやることでユーザに愛されるサービス作りができる。

サービスの中には必ず「人」がいる
その人を感じとってもらえるようにしよう

正直であること

サービスや昨日は失敗することもあります。
けど、そこで、どうして失敗したんだということを問いかけることが大事。

事例として、キャンペーンをやったが全然盛り上がらなかった。

  • twitter で、「キャンペーンのハードル高い?」と聞いてみた。
    • 「そもそもキャンペーンってなに?」という回答が多かった。
    • 質問をすることで、ただのキャンペーンとみせかけて、ユーザに知らせることもできる。
    • 素直に、ギャップがあったのでリトライさせてくださいということを伝える。
    • アンケートに答えることで、自分が協力したので、もう一回行ってみよう感をユーザに出すことができる。

コネヒト株式会社 代表取締役社長 大湯俊介 さんから

「ママリにおけるリブランディング」

世に出たサービスのリブランディングについて

2018年にリニューアルをした。

裏側公開ということなので、そういう話をしようと思います。

 

ママリはいま、世の中のママの3人に1人くらいが使っているサービス

業界最大なのに、軸がなかった。

そうすると、あらゆる場所でブレが生じてしまった。

  • 社外発信についてだったり
  • コンテンツの記事の内容だったり
  • 営業の人の性格性だったり。

そこで一旦、サービスの軸を決めようとなった。

その手段としての、リブランディング。

ユーザ、全従業員を巻き込んでつくった。

ユーザへのアンケートも行なった。

ママリはどういうサービスか?ということを twitter で聞いた。

また、従業員(当時半分くらいがユーザに近い存在)にアンケートもとった。

結果、そこから、

「ママの一歩を支える」

というテーマと、それを説明する文章を作った。

軸も作った

  • 自ら選ぶための知識を提供する
  • 一歩踏み出す自信を育む
  • 行動したママを受け入れる社会をつくる

ロゴについても、軸に則したストーリーも埋め込んだ

リブランディングをしたことによって

みんなの焦点が合うようになった。

まとめ

リブランディングは

  • サービスの使命を組織内にも浸透させる絶好の機会
  • 軸を起点にした新しい未来がみつかる好機

パネルディスカッション

質問に対しての Q & A 形式でパネルディスカッションが行われた。

Q1.

リブランディングの数字、KPIについてどういうふうに定めていますか?

A1.

オオタさんから

社内での意識だったり、ユーザの声を形にして落とせたか?という話のほうが大きいと思う。

指標でいうと、そのシンボルはどのように今後使えるのか?いろんなところに露出したときにクリエイティブとして使えるのか?ということをみたりする。

有川さんから

今後軸を考える上で、どのくらい使いやすくなったか?というところから測れると思う。

大湯さんから

発信に使いやすいとかの設計ができてるとか、どういう人に使ってほしいんだっけということを考えるのが大事なのかなと思う。

 

Q2.

「ママの一歩を支える」ということに、日々の業務が繋がっていることを意識するために工夫していることはありますか?

A2.

オオタさんから

特になし。

有川さんから

プレスリリースしてみるかな。

文章にしてみて、それと照らし合わせて、繋がりを感じたりしている。

大湯さんから

ワークショップを行なっている。

必ず集まって月一回やっている。昔から。

毎回テーマを決めて、サービスについて考えるということをしている。

昼休み開けにみんなで 10 分アプリを使いましょうとか。

そういうところで、理念を感じるようにしている。

つまり、接触頻度と角度を高くすること。

 

Q3.

これは難しいなと思うことはあるか?

A3.

オオタさんから

Payme

SNSは面白くないなと思っている。

それを超えることは難しい。

カジュアルでありながら、発信したいことを出せているのか?ということが難しい。

有川さんから

それを、デカくなっても支えられる土台が大事だと思っている。

大湯さんから

人っぽくするのが難しい。

人っぽくするからミスもある。

人の感じは親しみを出すために出したほうがいい。

形式張ったものだと、人はミスに耐性がない。

 

Q4.

リブランディングを外に押し出す理由は?ぶっちゃけお客さんには関係ないよね?みたいな意見もあると思うが。

A4.

オオタさんから

社内だけで済む。だと一方通行になってしまう。

一方通行にしないことで、外を意識することができる。

そのサービスがどういう目をもっていているのかというのを表明する必要があると思う。

有川さんから

特になし。

大湯さんから

巻き込んだほうがいいと思っていて、

途中でのリブランディングだったので、ユーザと一緒に作ったんだよ感を出したかった。

ちょっと参加したことで、自分(ユーザ)も協力したんだよっていうことをして

仲間を増やすことができる。

 

Q5.

プロダクトドリブンだなと思った。プロダクトが先か?ブランドが先か?でいうとどう思っている?

A5.

オオタさんから

どちらが先というよりも、並走だと思う。

何でブランドやるかというと、プロダクトを伸ばした上で、さらに効率よく世の中に広まりやすいとかいうメリットがある。

有川さんから

サービスがあることによってなので、当然プロダクトから入ると思う。

それをより効率的に社会に出したいとか思うと、相乗効果があると思う。

大湯さんから

リブランディングは超大変です。

そういう意味でいうと、最初からちゃんと設計するべきものだとは思った。

ただ、ブランディングは後から付いてくるものだとも思っている。

最後に

Q6.

2020年を見越して、こういうデザインがいいんじゃないの?と思っていること

A6.

大湯さんから

VRが普及してくると思う。

普通の縦型のデザインから横型のデザインになるんじゃないかと想っている。

5gに関連してて、動きが大事になると思う。

動いているなかでも映えるデザインとか、そういうのがくると思っている。

有川さんから

デバイス依存が激しい。例えばiphoneとか。

あと2年くらいで、デバイス依存から解き放たれると思う。

目には見えないような部分でサービスが表現されていくと思う。

コミュニケーションだったりがそれにあたる。

そういう概念が生まれると思う。

オオタさんから

スタートアップをよく担当している理由としては

アイコン勝負なところがあるから。

ただ、今後はリアルな空間に今後サービスが出て行くとしたら、今のアイコンは映えないなと思う。

空間に依存していないデザインというのが重要になってくると思う。

[AWS] IAMユーザで請求情報を確認する

AWSの請求画面を表示するには、デフォルトの設定だと

root でログインしなければ見ることができません。

今回は IAM ユーザでログインして請求画面を表示させる方法を書きます。

公式ドキュメント

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html

 

IAM ユーザで請求画面を表示させるには、次の 2 つの設定が必要になります。

  • root でログインし、請求画面を IAM ユーザにも表示させるように設定
  • IAM ユーザに、請求画面を表示させるポリシーをアタッチ

 

root でログインし、請求画面を IAM ユーザにも表示させる設定

root でログインし、右上のバーからアカウントを開きます。

画面をスクロールし、「IAM ユーザ/ロールによる請求情報へのアクセス」を開き

「IAM アクセスのアクティブ化」にチェックを入れ「更新」します。

IAM ユーザに、請求画面を表示させるポリシーをアタッチ

請求画面を表示させたい IAM を選択し、

「Billing」のポリシーをアタッチします。

これで請求情報の全て(請求書 や 予算 など)が表示できるようになります。

個別に許可したい場合は、下記のドキュメントを参考に個別にポリシーを付与しましょう。

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html

IAM ユーザでログインしなおし、請求画面を開くと問題なく表示ができました。

 

チャリを車に積む

イベントに行くためにチャリを車に積んだときの知見です。

レンタカーを借りてチャリ2台を車内に積みました。

レンタカーは日本レンタカーで V-A クラスの車種にしました。

https://www.nipponrentacar.co.jp/service/truck/index.htm


まずは後部座席を倒します

乗せるために買ったものです。

  • 梱包材
    車を傷つけないためにチャリの下に敷きます
  • 自転車の荷紐
    チャリが倒れないようするために使います
  • テープ
    敷いた梱包材を止めるのに使います

梱包材を敷きます

後輪スタンドを車内に置きます。

前輪を外した状態でチャリを入れます

外した前輪と車体を荷紐で固定します。

この状態でこんな感じになります

もう一台も同様にして入れます(今回は1台目とは前後逆に入れました)

積んだ時のスペース感や荷物がどれくらい入るかの参考になれば幸いです。

この状態での前部座席は、普通に座れるくらいの余裕はあります。

チャリは間にもう一台積められそうですね(3人は座れませんが)

以前車中泊をした際には、一人は後部座席のチャリの間で寝て、

もう一人は前部座席を倒して寝ました。

【アーキテクチャ ディスカッション Vol.1】に行ってきました。

アーキテクチャ ディスカッション Vol.1

https://istyle.connpass.com/event/97862/

に行ってきたので、そのときのレポート

 

ディスカッション形式のメモです。
発言に対する発言を1つインデントするようにして書いています。

※正直、うまくまとめられている自信がないので、会話を追って雰囲気が伝われば幸いです。

 

ビジネスロジック層のモデリング

  • active record を使ったときのモデリングが難しい。どうモデリングをするかで分離の仕方が変わる。
    • DB を一回忘れるのはどうか?
    • DB のことは一旦忘れるけど、どこまでを考えるのかが重要になりそう。
    • それって DB を最初が存在している前提では?ソフトウェアの内部構造って、オブジェクトの意味やライフサイクル単位で作っていくと良いのでは?あまり、テーブルに引っ張られて考えるのはよくないかもしれない。
      • その分析ってどうやって始めます?
        • 業務フローから考えます。業務をプログラムに落とし込むにはどうしたらいいのかを考える。
        • この言葉はどういうカテゴリなんだろうとか。
          あまりプログラミングというか、サービス仕様だったりデータのカテゴリわけをする

          • この場合のデータってなんですか?
            • 仕様に出てくる言葉のこと。
            • モデリングっていう言葉の意味が幅広いので、焦点はここだよっていうのを考えるようにする。
            • エンジニアが使うことばっていうのはいろいろな意味があるので、その意味を付箋で貼ってみたりとかもする。
              部分部分でやっていかないといけない。業務の一番重要なところはどこなのかを聞いて、そこに焦点をあてるようにしている。

              • ドメインというのは、答えが出た時に、どういうことをやったんですか?
                • 僕らが行ったこととしては、経済活動という古くから使われているものをドメインとおくことにした。
                  入荷なのかなのかの単位を人それぞれだったが、少しずつリファクタリングすることで擦り合わせていった。
                  図書館アプリを練習で作ってみようとなった時に、
                  会社は貸し借りが大事なのか?いや、在庫管理が大事だ。となって、在庫管理をドメインとして初めて行った。

Clean Architecrue を採用した話

  • 最初始めたときは、どうしてもこの形にならなかった
    presenters を使わない人もいて、translater を使う人もいた。
    スクラップ  &  ビルドを繰り返して、最終的にはこの形になった。
    大事なのは UML 図だった。

    • entity はきっとトランザクション管理でもよいのだと思った。
      ヘキサゴナルアーキテクチャがきて、そのあとこの形になったと思っている。
      オニオンアーキテクチャはただ単にドメイン駆動設計のことを行っているだけなので、use case の部分。
      僕はこれ、浸透させるために教育させるのは無理だと思った。
      なので、ツールを作った。
      WEB のときは、 presenter のときはいらないと思った。
      非同期処理は contorller が返してくれたほうが都合がいいときが多い。
      なので、WEB の場合は presenter はいらないが、GUI ツールのときはいると思っ

      • 教育は諦めた的なことを言っていて、ツールを作ったという話があったが、
        こういう手順でやってねということをやると、考えずにやってしまう人が出てきそうだが、どう思うか?

        • ツール使った方が早くできるよ、というメリットを提示して納得してもらった。
          保守フェーズをやったことがないエンジニアって、伝わらないからつらい。運用する辛さが伝われば話も伝わる。
          そういう意味では、モノリシックで1000行ぐらいあるメソッドの保守とかしてもらったほうがいいかもですね笑(会場でも笑いが起こる)
  • presenter について最近本を読んでて思ったことがあるが、
    本では、presenter はテストしにくい部分とテストしやすい部分を分けましょう、という話が23章であった。
    その中では、 view はテストしにくいが、viewmodel まではまだテストできるという内容だった。
    プログラミング言語中で、日付オブジェクトというものを view に渡したときに
    文字列に変換しなければいけない。
    日付オブジェクトを文字列に変換するのが presenter
    その文字を活用するのが view という感じにしていたので、
    presenter は必要なのでは?と思った。

    • dto を使っていて、テストするので、そこは問題ではないと思った。
  • clean architecture に乗っ取ってるかを管理する CI ツール気になる。
    • それは取り組みをやっている。構文を解析してチェックするようにしている。
      java で gladle を使ってやっているが、導入も簡単なので良い。
      ドメインの依存すべき方向とは逆方向になっているときなど、そういうのはすぐに検知できる。

DB に入れるときに レポジトリって入れると思うが、何を引数に渡している?

  • DB の方は基本的にイベントを保存するようにしている。
    失敗談で、entity を渡すっていうようにしていたら、
    レポジトリの中で新しい entity が渡されたときに、古いものとの差分をとって DB にインサートとかしていたので、その管理がつらくてやめた。

    • 僕もentityというか集約をインサートしている。
      • それってentityとテーブルに差がない状態になる?
        • いや、差がある。
        • DDD のいいところが、イベントをインサートするとDBは肥大化するが、ドメインは綺麗に保てることができるのでそこがいいと思っている。

レポジトリにおいて、参照系と更新系で分けている人はいますか?

  • 参照系だとオーバーヘッドが大きいと思うが、参照系でもユースケース層もあったほうが便利だよねという面もあって、みなさんの事例を聞きたい。
    参照系と更新系を同じレポジトリで管理するか否か?ということ。

    • Clean Architecure の場合は、ユースケースがインターフェイスになるので、レポジトリ使わないパターンで行った。
      • レポジトリはそのまま経由させて、書くのは RDS を使って読むのは Elastic Search とかを使ったりもしている。
        • たしかに書くのは多くなる。DB の先って何年か後に違うのにしようという話が出てくるので、そういう風にしている。
        • 両方とも同じように扱いたいので、レイヤを挟まないようにしている。
          • 逆に、レイヤを分けるようにしている人いますか?
            • 挑戦はしている。ドメインを守りたいみたいな方向でそういう風にしている。
            • 読む先と書く先が違うからという理由があるが、
              キャッシュが落ちた場合って、DBに取りにいくと思うが
              そういう場合はインターフェイスは同じだが、中身は違うようにしている。

キャッシュって、みなさん(Clean Architectureの)図でいうとどこに入れていますか?

  • DB のところに入れている。
    ただ、ドメインをまたぐときに困る。

Clean Architecture って、人と会話するのが苦手な人にとっては苦痛かもしれない

  • 人と会話して、こっちの人は商品って言ってるけど、こっちでは違うことを言っていて、
    そこの分析をやるのが楽しい。
    逆にそこを分析してからでないとコードに落とし込めないと思う。

    • お金をもらって、人に本当に必要なものを作るためには、人と会話ができないといけない。

ドメイン駆動をやっていると、自分の言語がプログラムになってくるのでプログラムを英語で書くのが辛くなる。

  • 逆に日本語のローマ字で書くと良いと、結構読みやすくて良い。

Clean Architecture の本を読んで思ったが、実践に使うには大きなサービスでないとやりずらい。ただ、実際に手を動かさないと習得しずらい、みなさんはどのようにしていますか?

  • 教育を2週間、題材を用意してやってみた。
    すると、完璧に理解するのは難しくても、コピペすればなんとかできるという状態には持っていけた。
  • 個人的には、小さいサービスを作ってみて練習している。
    自分の中で鉄板のお題(RSSリーダーを作るみたいな)を作ってみるというのをやっている。

    • その時って実際に業務でやるときとのレベル感というのが出てきてしまうと思うが、
      どうやってその差分を埋めてますか?

      • 埋まらないですね。ただ、どうしても抑えておきたい部分(例えば例外ハンドリングの仕方とか)はやるようにしている。
  • うちの会社ではレビューで学んでもらうようにしてますね。小さい単位で業務を任せて、レビューして教えたりする。

Flux アーキテクチャって Clean Architecture に似てるって思った人います?

GUIを組んでるときに思ったんだが、形的に似ているなと思った。
そのとき思ったのが、サーバーを介さなければ同じ形になるのかな?と思った。
特に思った人がいないので、この話はやめます笑

ゲームアプリのエンジニアも Clean Architecture に興味あるらしいですよ。

  • ゲーム全体をそうするのはしんどいかもしれないが、一部分だけ Clean Architecture にしてテスト可能にするのは良いと思う。

みなさんどういった経緯で設計とかアーキテクチャに興味を持たれましたか?

  • 僕の場合は 13 年続くでかいサービスを一人で保守していて、そこでアーキテクチャが必要だと思うようになった。
  • 自分でクソコードを生み出して保守しきれなくなって、あるべき姿ってどんなんだろうと思ったのがきっかけ。
  • コアなモデルのほうに興味があったのが一つと、学生のときに設計やアーキテクチャの情報がたくさん入ってきたので、そこがきっかけ。
  • オブジェクト指向から始まって、すごい人が言ってるからいいものに違いないと思って勉強から入った。
  • DBに興味がもともとあった。データモデルが出発点になって、それがきっかけ。
  • 入社したときに、Android が世に出たときくらいだった。一番最初の Activity に何千行もあるアプリを保守しなければいけなくなった。
    そこをどうにかしなきゃねって思って、アーキテクトの考え方になって言った。保守しやすいアプリケーションを突き詰めたら、今に至った。
  • 炎上しているPJがあって、どうにかしてくれというふわっとしたオーダーがあった。
    そういうもののセオリーってテストを書いて始めていくのだが、どうせだからドメイン駆動設計(というのがあるらしいレベルだった)を突っ込んでみたのがきっかけ。
    炎上PJってもしかしたらチャンス(新しいことに取り組める)なのかなと思った。
  • 他者が作ったが放り出したものと同じものを作ってくれと言われた。
    それが、ループが17段あったりもした。
    そういう過酷な状況の中で生き残るためには設計が必要だと思った。
  • 会社が、一人で作って一人で運用している人が多く、アーキテクチャを知っていないと自爆してしまうことがあるので、それがきっかけになった。

分析系の処理を書く(マイクロn秒)ときには、Clean Architecture は採用しないことが多い。

  • なぜかというと面倒臭いから。
    速く返さないといけないときとかは一つのファイルにたくさん書いたりする。

    • それはそれでいいと思う。
      そのソフトウェアが求められている関心事による気がする。
      人が運用する上での複雑性を解決するのが Clean Architecture だったりするし、
      速く返さないといけないとかだと技術的なアプローチが必要になるので、そのときどきにあったアプローチが必要
      Clean Arhitecture は万能薬ではないので、適材適所なアプローチが必要になってくる。

本の内容に関して

「本当の重複」と「偶然の重複」があって、

  • 重複を排除すれば無条件で良いと思っている人がいるが、そこについて書かれているのが嬉しかった。
    • このコードを重複させるべきかどうかという点を考えた時に、
      テストできるコードが設計ができるコードというわけではないと言われたりもした。

組織の形態がアプリケーションに反映されてしまうという法則がある。

  • 組織の形態はなかなか変わらないが、アーキテクチャはよりよいものにしたいと思うときがあるが、みなさんどうしていますか?
    • うちは microservice を採用していて、新しく入った人にはローテーションして多くを触ってもらうようにしている。
      そういう風に知識を蓄えてもらうようにしている。
  • 組織変えなきゃなと思いながらコードを書いたりもしている。
  • 何かサービスを作ろうとなったときに、新しく部署が生まれてそこで作るような文化になっている。
  • スクラッチで作られるサービスがたくさんあるので、横軸で共通で使えるようなライブラリとかプラットフォームがあったらいいと思うが、
    いまのところ組織と同じ形になってしまっている。
  • アーキテクチャ設計と組織設計って同じだと思っていて、組織設計やる気持ちがないとアーキテクチャ設計できないと思う。
    組織設計はマネージャーがやるというマインドだとできないと思う。
  • 結論、組織設計から逃げない。

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門に行ってきました

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門

https://supporterzcolab.com/event/533/

に行ってきたので、そのときのレポート

 

以下、講義を聴きながらのメモ

 

登壇者の方は、留学の経験があるが、

留学したからといって、すぐに英語ができるわけではない

それがきっかけになって勉強しようと思った。

 

その辺の本屋で、「2語で伝わる英会話!」とかいう本が多いが

そういう楽して学べる英語は本当の英語ではない。

 

この勉強会を通して、

みなさんが英語への一歩が踏み出せればよい。

エンジニアが英語できると何がよいか?

嬉しいことはすでに分かっている。

が、英語を勉強するのはとてもしんどい

なので、目標やモチベーションが大切。

嬉しいこと1: 入出力のスペック大幅アップ

入力

  • 最新のドキュメントが読めるようになる。
  • 疲れずに英語のドキュメントが読める。

出力

  • 例えば、技術ブログなどを英語で書くと、海外の人も見てくれる。
  •  OSS 活動がしやすくなる(PR  のコメントやコミットメッセージなど)

嬉しいこと2: 市場価値の高い人材になれる。

嬉しいこと3: もちろん、お給料が増える

いろいろなデータを見ていると、英語ができていると年収が上がる人が多い。

嬉しいこと4: 転職の際の選択肢が広がる

例えば、海外企業に勤めたいというのがまず浮かばない。

それは、英語ができないから。

それで選択肢が減っているのはとてももったいない。

嬉しいこと5:  かっこいい。

 

英語のジャンルを4象限に分けたとき

  • listening (リアルタイム・自分でコントロールできない)
  • speaking (リアルタイム・自分でコントロールできる)
  • writing (ノンリアルタイム・自分でコントロールできる)
  • reading (ノンリアルタイム・自分でコントロールできない)

どれが難しいか?

ノンリアルタイムの方が、翻訳ツールなど使えるので簡単

事前に準備できるspeaking, writingは、自分でコントロールできるので簡単

逆に準備できないのは、相手に依存しているので、むずかしい。

準備すれば誰だって英語でスピーチできる。

結論からいうと、

listening が一番難しい。

speaking ができれば、writing はそれを書くだけなので speaking のほうが難しい。

エンジニア向け、英語表現テンプレート

英語の人は、あいさつの始まりに「調子どう?」みたいなのをめちゃめちゃ言う。

ただ、how are you? はほとんど言わない。

what’s up の返答は i’m fineじゃだめ

最近なんかあった?とかそういうことを聞かれている。なので返答は難しい。

 

ずっとyesを使ってると、硬い人だと思われるので、いろんな表現を使えると良い。(yup など)

コミットメッセージとかは、日本語よりも英語のほうが簡単だったりもする。

主語とかいらないんで、動詞から始まっていい。

speaking 攻略

格好つけずに簡単に喋る

 

発音

日本人を知ってる海外の人は、日本人が英語の発音がひどいことは分かっているので

海外の人もそこは日本人に合わせて喋ってくれる。

逆に、自信なくして小さい声で喋ると、もっと伝わらないのでよくない。

 

喋りながら、発音が難しい単語は避けるようにする。

R と L の発音は本当に難しい。

が、R と L を入れ違えたときに存在しない単語だったら

相手が意味を汲み取ってくれるので、意外と大丈夫だったりもする。

Q & A

Q1.

英語をはじめたきっかけは?

A1.

学生の頃の先生が良かった。

 

Q2.

こういう勉強方で良かったというのはあるか?

A2.

実際に喋るのがよい。skypeとかで喋れるサービスもある。

DMM 英会話など。

 

Q3.

話をしていると、分からない単語があって、スペル自体も分からないから調べようがなさそうだがどうすればよいか?

A3.

スペルが分からなくても、それっぽい単語でぐぐったら、googleがもしかしてこの単語?とサジェストしてくれるので、それをつかっている。

 

Q4.

下手な英語を喋って相手を怒らせたときの対処方は?

A4.

そもそも怒らないと思う。そうとう変なこと言わなければ。

 

Q5.

日頃、ものを主語にしてしまうことがおおいが、人を主語にしたほうがよい?

A5.

いや、それでもよい。

 

Q6.

ゲームのチャットで英語を勉強するのはよいか?

A6.

何もしないよりは良いが、ゲーム特有のスラングとかもあるので、仕事で喋るほうがよい。

 

Q7.

どの程度英語ができたら市場価値として英語ができると言えるか?

A7.

どのくらいかはわからない。ただ、自分は英語できますと言える。

 

Q8.

実務として、エラーを検索するときは、どういう検索の仕方をしたほうがよいか?(効率の良いググり方は?)

A8.

普通に日本語で検索することもある。そのほうがわかりやすいので。

 

Q9.

英単語を覚えるためにどっかに保存している?

A9.

頭の中に保存している。話すときに何か見たりはできないので。

補足:

alcというサイトが良い。

辞書のようなサイトだが、辞書ではなくて、その単語を使った例文が表示される。

 

Q10.

日常で使うテンプレートとかある?

A10.

それが難しい。エンジニアに限定すると用途に特化して作れるが、日常会話は難しい。ので、テンプレートは持っていない。

 

Q11.

英語のpod cast など使っているか?

A11.

聞いていない。ただ、聞くとしたら自分の英語レベルにあったものを聞いたほうがいい。