kp

サーバサイドばかりやってきたワイ、フロントを勉強してみた

ふと、"今年はフロントやるか"と思って4月くらいからフロント周りを勉強してました。"フロント"って大雑把なって感じですがそのくらい大雑把に勉強してたのです

Vue.js

VueかReactを勉強しようと思ったんだけど、あまりフロント慣れしてないしフレームワーク的なもので簡単にモノを作ってみたいなという気持ちがあって、その場合それぞれNuxt.jsとNext.jsが存在すると知って、Nuxtの方が情報量多そうなのでVueにしました。 jp.vuejs.org

デザイナーの人に聞いてみたら「とりあえずSass使ったら良いと思う。記法としてはSCSSだ」となんか分かったようなわからないようなこと言われたけど、SCSS書いてます。CSSなのに入れ子出来てかっこいい。 あと、昔は大変だった気がするレイアウト周りがflexboxでとても簡単になってた。

www.webcreatorbox.com

Nuxt.js + TypeScript

Nuxt.jsの情報は英語情報の方が先に進んでいるのでこっちを見てます。 ここの情報だけでとりあえずNuxt.js書けるようになると思います。

nuxtjs.org

最近出来たNuxt.jsのTypeScript専門のページ。まだコンテンツは少ないけど最低限TypeScriptでNuxt.js始めるための情報がある typescript.nuxtjs.org

こちらはそのサンプル。まだサンプルもminimalなものしかない。でもNuxt.jsをTypeScriptで書くならこんな感じというのが分かるだけでもありがたいっす。 typescript.nuxtjs.org

firebase + TypeScript

TypeScriptは型とかの話は難しいのでとにかく動く上に簡単に説明してくれてるfirebaseのCloud FunctionのYoutubeがとにかく分かりやすくてよかったです。通して見るだけで「あれ？なんかTypeScript書けるかも」って気持ちになれる

www.youtube.com

この辺でCloud Functionとか読んだらそのままfirestoreの再生リストに言っても楽しい。

感想

週に数時間程度だけどちゃんとやってみるとフロント周りは随分楽に勉強出来るし分かったような気になれてとても良かったです。

というか、firebaseも含めれば一人でプロトタイプとか作れてしまえる気がしてきました。

MacにJavaやJVM言語を入れるときはsdkmanを使う

要は新しいマシンでKotlinを使いたかった

ふとKotlinを使うかと思ってcommand lineでインストールしようとして

brew install kotlin

したらJavaが入ってなくてさっと動かなかった。

Javaのインストールってわざわざインストーラ見つけてインストールとか面倒だし、JREだのJDKだのの最近の事情は全然よくわからないのでだるいなーってなった。

というわけでsdkman使いました。

sdkmanなら

sdk install java
sdk install kotlin

で済むのでとりあえず頭を空っぽにしてインストールできた。あーよかった

sdkmanのインストール

curl -s "https://get.sdkman.io" | bash

dellのxps13からWindows10使ってみて

  • タッチパッドはMacとずいぶん違う
    • うっかりカーソルがずれたりして使いずらい
    • マウスを買ってからだいぶいい感じになった。トラックボールでもいいと思う
    • タッチパネルも時々使う程度だけど便利。Macにもあったら良いのに
  • コマンドプロンプトもPowerShellも辛かった
    • 見た目が特にね¥(円マーク)とか
    • そのままだとsshも使えないとか
  • いろいろ悩まずにGit for Windows使ってこ
  • そして付いてくるGit Bash使ってこ
  • VagrantもDockerも動かすならhyper-v使いたくなるところだけど、Vagrantの制限あるし割り切ってVirtualBoxを使ってVagrant動かすようにした
    • Dockerの良い使い方まだよく分かってない
    • Vagrant内でDocker動かせば良いのではと
  • Vagrant使い始めたら途端に自分のほしい環境をセットアップでき始めて楽しくなってきた

foremanを読んでいく

github.com

  • thorを使っている
  • Foreman::CLI < Thorが最初に呼び出されるクラスでForeman::CLI.startが最初に呼ばれる
  • Foreman::CLIはコマンドラインからの入力のチェックなど実行前の準備
  • 主な処理はForeman::Engine#startで行う
  • Foreman::Engine::CLIはForeman::Engineを継承している
  • 継承しているけど結局継承しているクラスは1つだしforeman単体で使っていたらそんなに意味はなさそう
  • Foreman::Engine#load_procfileでProcfileを一つ一つのprocessとして読み込む
  • processはForeman::Processのインスタンス
  • 結局のところProcess.spawnをしている
  • ログの出力はForeman::Engine::CLI#outputで行う。キレイで分かりやすいログが出て来るのはこの実装のおかげ
  • あまり見たことないけど、foremanは他のライブラリが拡張したりするのを見込んでるのかな？
  • foremanと同等のものが多言語でもあるから1つ読んでると他の言語の勉強にも便利そう

Thor

Thor - Home

  • Rubyでコマンドラインツールを開発するのに使えるGem
  • ものすごくたくさんのGemに使われている

使い方

  • 基本的にrequire 'thor'してThorを継承して使う。
  • 利用する側gemの場合、よくbinの中に継承したクラスのstartメソッドを叩いている
  • foremanの場合Foreman::CLI.start
  • 引数も受け取るARGV
  • optionをラップしてくれるoption :fromみたいに

gormをWebアプリケーションに組み込む

gormを使ってみた

ちょっとgormを使ってみました。

Webアプリケーションを作りたいのでWeb周りはginを使ってみましたが、そっちはここでは関係ないです。

DBへのconnectionをどこで張ったらいいのかというのが少し悩んだんですが、深く考えずにmain()の中で作ってます。

package main

import (
    "fmt"
    "net/http"

    "github.com/gin-gonic/gin"
    "github.com/jinzhu/gorm"
    _ "github.com/jinzhu/gorm/dialects/mysql"
)

var db *gorm.DB

type User struct {
    ID            uint
    Email         string
}

func getUser(c *gin.Context) {
    var user User
    db.First(&user, c.Param("id"))

    c.JSON(http.StatusOK, user)
}

func main() {
    var dbErr error

    db, dbErr = gorm.Open("mysql", "mysql:root@/test_development")
    if dbErr != nil {
        panic("failed to connect database")
    }

    r := gin.Default()
    r.GET("/users/:id", getUser)
    r.Run()
}

これでgo run main.goを実行。 そういえばgoではパッケージ名と同じ名前の.goファイルを作ってmain()を書くのがベストプラクティスらしいけど、今回はmain.goにしちゃいました。

コネクション数の確認

今回はMySQLにつなげたのでコネクション数の確認をしてみます。

mysql> show status like 'Threads_connected';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 5     |
+-------------------+-------+
1 row in set (0.00 sec)

ここでブラウザからlocalhost:8080/users/1を何回か叩いてみて現在の接続数を見てみます。

mysql> show status like 'Threads_connected';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 5     |
+-------------------+-------+
1 row in set (0.00 sec)

5で変わらず。

これで接続はいいのかな。

gormのOpenはその中でsqlのOpenを叩いていて、 OpenのドキュメントにはOpenは一回呼ばれるだけで良くて並行して走らせても大丈夫なようなのでこのまま信じていこうかなと思います

// The returned DB is safe for concurrent use by multiple goroutines // and maintains its own pool of idle connections. Thus, the Open // function should be called just once. It is rarely necessary to // close a DB.