Heroku で Scala Getting Start

前回の続き。

Heroku公式のGetting Startをやろうと決意

Getting Started on Heroku with Scala and Play | Heroku Dev Center

ページに沿って1つ1つ確認していくだけ

IntelliJで実行。

Play Frameworkのバージョンが2.xでちょっと隠蔽されてしまっているっぽいので、そこだけわからんという感じ

2.6で空プロジェクトをいれて表示させてみるか。

  • Githubにあるサンプルコードで動きが見れる
  • Herokuへのデプロイ、ローカルでの起動のさせ方がわかるようになる
  • Pluginを利用してLog出力、管理やDBへの接続へのやり方がわかるようになる

概ねこれらがわかるようになる

Scala+PlayFramework+Heroku をやろうとしてうまくいってない

2/20現在の状況で、WEBアプリのお勉強がてらタイトルのことをやってみたときのメモ

前提

以下の環境

  • Mac Book Pro 2017
  • Homebrew導入済
  • git 導入済
  • Herokuアカウント取得済
  • IntelliJ インストール済

Scalaのインストール

svmの導入

バージョン管理もしたいので 下記のブログにあるようにsvmを導入

yuroyoro.hatenablog.com

基本的にはgitクローンしとけばいい

git clone https://github.com/yuroyoro/svm.git

Scalaにupdate入ったなーというタイミングで更新(されてなかったらfork pull requestしような)して、再配置。配置箇所は一応使いやすいところ

/usr/local/bin/svm とかにしておくといい。コピーした場合は chmod 755 しとくこと

Scalaのバージョン確認とインストール

公式サイトで最新バージョンの確認

https://www.scala-lang.org

svm install 2.12.8

これだけ。終わったら動作確認はこんな感じ

$ scala
Welcome to Scala 2.12.8 (Java HotSpot(TM) 64-Bit Server VM, Java 10.0.1).
Type in expressions for evaluation. Or try :help.

scala> :q

起動時にバージョンが表示されているので狙ったバージョンで起動できていることを確認。

REPLから抜けるには :q で。困ったら :help

sbtのインストール

brew install sbt@1

※ 参考リンク

sbt - Download

終わったら sbt aboutで、バージョン確認(上記URLの最新になっているはず)

Play Frameworkを試してみる

こういうときは一度公式をちゃんと見よう!見ないでQiitaだけ見てたら古い記事の罠でEOLのものを使ってたりするからね!(しっかりハマりました)

Getting Started with Play Framework

任意のディレクトリで

sbt new playframework/play-scala-seed.g8

途中、下記を聞かれるが、気にしないでEnterで平気

This template generates a Play Scala project

name [play-scala-seed]:
organization [com.example]:

上で指定したディレクトリが作成されているので、移動してからsbt run

しばらく待ったああとに、起動したら

http://localhost:9000

にアクセスすれば、WelcomePageが表示される

IntelliJ で設定

作成したプロジェクトかをインポートするだけ。簡単!

IntellJでエラーページからソースコードへダイレクトに飛べるらしい。なので以下の設定をしておく

conf/application.confに以下を追加 play.editor="http://localhost:63342/api/file/?file=%s&line=%s"

build.sbt に以下を追加

fork := true // required for "sbt run" to pick up javaOptions

javaOptions += "-Dplay.editor=http://localhost:63342/api/file/?file=%s&line=%s"

反映されるか試してみる

app/views/index.scala.html

@()

@main("Welcome to Play") {
  <h1>Welcome to Play!</h1>
  <h2>Edit Sample</h2>   <- 追加
}

終わったらhttp://localhost:9000 にアクセスしてみると変更が反映される

※ RELOADに数秒かかるので、ちょっとだけ待ったほうがいい

herokuにデプロイしてみる

まぁ、いつものやりかたで。(heroku create とかしてくやつ)

Not a supported Play version: 2.7.0. This plugin is compatible with: [PLAY_2_2_X, PLAY_2_3_X, PLAY_2_4_X, PLAY_2_5_X, PLAY_2_6_X].

Gradleでこのエラーが。まじで。最新サポートされてないじゃん

ハマったこと

PlayFrameworksのバージョン

バージョンが古いものとか新しいもので使うものが違ってた点。特に最新はsbtしか対応していないという点

HerokuがサポートしているPlayFrameworkのバージョン

2.6までだった。 最新が2,7でこれ使ってローカルとかやってたから、めっちゃハマった。最新使えないのはちょっと考えものか、もしくはある程度枯れた技術で安定稼働できるかという利点があるんだろうけど、とりあえず最新でやってみるか精神だとハマる

次のトライ

Heroku上で動かせるようにするを目標に、チュートリアルしてみる

リーダブルコード 第三部、第四部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

第三部 コードの再構成

10章 無関係の下位問題を抽出する

  1. 関数やコードブロックを見て「このコードの高レベルの目標は何か?」と自問する
  2. コードの各行に対して「高レベルの目標に直接的に効果があるのか? あるいは、無関係の下位問題を解決しているか?」と自問する
  3. 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。

10章のキモは - プロジェクト固有のコードから汎用コードを分離するということ

11章 一度に1つのことを

  • コードは1つずつタスクを行うようにしなければいけない。

本書の手順

  1. コードが行っている「タスク」をすべて列挙する。この「タスク」という言葉はユルく使っている。「オブジェクトが妥当かどうかを確認する」のように小さなこともあれば「ツリーのすべれのノードをイテレートする」のようにあいまいなこともある
  2. タスクをできるだけ異なる関数に分離する。少なくとも異なる領域に分割する。

12章 コードに思いを込める

コードをより明確にする簡単な手順を使う

  1. コードの動作を簡単な言葉で同僚にもわかるように説明する
  2. その説明のなかでs使っているキーワードやフレーズに注目する
  3. その説明に合わせてコードを書く

声に出すラバーダッキングは有効である。

13章 短いコードを書く

  • 最も読みやすいコードは何も書かれていないコードだ

  • 汎用的な「ユーティリティ」コードを作って、重複コードを削除する。

  • 未使用のコードや無用の機能を削除する
  • プロジェクトをサブプロジェクトに分割する
  • コードの「重量」を意識する。軽量で機敏にしておく
  • 不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
  • 最も簡単に問題を解決できるような要求を考える。
  • 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。

新しいものはなるべく書かない

第四部 選抜テーマ

14章 テストと読みやすさ

  • 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
  • コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。
  • テストには最もキレイで単純な値を選ぶ。

15章 「分/時間カウンタ」を設計・実装する

割愛。

リーダブルコード 第二部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

第二部 ループとロジックの単純化

7章 制御フローを読みやすくする

  • 条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
  • 条件の並び順の優劣
    • 条件は非定型よりも肯定形を使う。例えば、if(!debug)ではなくif(debug)を使う。
    • 単純な条件を先に書く。ifとelseが同じ画面に表示されるので見やすい
    • 関心を引く条件や目立つ条件を先に書く
  • 衝突することがあるので自分で判断する
  • 行数を短くするよりも、他の人が理解するのにかかる時間を短くする
  • 変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る

8章 巨大な式を分割する

  • 巨大な式は飲み込みやすい大きさに分割する
  • 「頭がいい」コードに気をつける。あとで他の人がコードを読む時にわかりにくくなる。
  • 巨大な式の分割の最も簡単な方法は「説明変数」を導入すること。以下の3つの利点がある
    • 巨大な式を分割できる
    • 簡潔な名前で式を説明することで、コードを文書化できる
    • コードの主要な「概念」を読み手が意識しやすくなる

9章 変数と読みやすさ

この章は下記の問題について考える。

  1. 変数が多いと変数を追跡するのが難しくなる。
  2. 変数のスコープが大きいとスコープを把握する時間が長くなる。
  3. 変数が頻繁に変更されると現在の値を把握するのが難しくなる。

解決は

  1. 邪魔な変数は削除する。
  2. 変数のスコープをできるだけ小さくする。
  3. 一度だけ書き込む変数を使う。

リーダブルコード 第一部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

1章 理解しやすいコード

  • コードは理解しやすくなければいけない
  • コードは他の人が最短時間で理解できるように書かなければいけない
    • コードを理解するとは「バグを見つけられる」「変更を加えることができる」「6ヶ月後の自分も含んだ他人が上記を行える」
  • 理解する時間を短くするコードのためのコメントもあり

第一部 表面上の改善

2章 名前に情報を詰め込む

  • 名前に情報を詰め込む

テーマ

  • 明確な単語を選ぶ
    • 気取った言い回しよりも明確で正確な方がいい
  • 汎用的な名前を避ける(あるいは、使う状況を選ぶ)
    • tmp・it・retvalのような汎用的な名前を使うときは、それ相応の理由を用意しよう
  • 抽象的な名前よりも具体的な名前を使う
  • 接尾語や接頭語を使って情報を追加する
  • 名前の長さを決める
  • 名前のフォーマットで情報を伝える

類語辞典を活用しよう

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する
  • 最善の名前とは誤解されない名前
  • 自分が書いたプログラムが正しく他人に理解されるかどうか

4章 美しさ

  • 一貫性のあるスタイルは正しいより重要だ
  • 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
  • コードの「列」を整列すれば、概要が把握しやすくなる
  • ある場所で【A・B・C】のように並んでいたものを、他の場所で【B・C・A】のように並べてはいけない。意味のある順番を選んで、常にその順番を守る
  • 空行を使って大きなブロックをロン履歴な「段落」に分ける

5章 コメントすべきことを知る

  • コメントの目的は、書き手の意図を読み手に知らせることである
  • コードからすぐわかることをコメントに書かない
  • コードを理解することに役立つものなら何でもいいから書こう
  • コメントを書く作業は3つに分解できる
    • 頭の中にあるコメントをとにかく書き出す
    • コメントを読んで(どちらかと言えば)改善が必要なものを見つける
    • 改善する
  • 酷いコード+コメントではなくコードそのものを改善すること

6章 コメントは正確で簡潔に

  • コメントは領域に対する情報の比率が高くなければいけない
  • 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
  • 関数の操作はできるだけ正確に説明する
  • コメントに含める入出力の実例を慎重に選ぶ
  • コードの意図は、詳細レベルではなく、高レベルで記述する
  • よくわからない引数にはインラインコメントを使う(例:Function ( / arg = / ...))
  • 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ