Regional Scrum Gathering Tokyo 2018に行ってきた #RSGT2018 #ちら裏

RSGT2018に行ってきた。

別にレポートでもなんでもない。

参加して感じたことや考えたことが、自分の中で整理されて言葉になってきたものを、ただ書きなぐっただけのちら裏。

2018.scrumgatheringtokyo.org

Scrumが好きだ

いろんな話を聞いてやっぱり僕はScrumが好きだなぁと再確認した。

フレームワークとしてのScrumも勿論なんだけど、考え方や価値観とか。

特に学習を前提にしているところと、検査・適応・透明性の三本柱。

Scrumは、いつだって僕にヒントをくれるし道標になってる。

理想のチームとしてのスクラム

http://rugbyreferee.aspota.jp/IMG_3943.JPG

理想のチームについて考える機会があった。

僕にとっての理想のチームはラグビースクラムがメタファーになってる。

開発手法としてのスクラムじゃなくて、由来になってるスポーツのスクラムそのものが。

強力な個人が求められることはもちろんあるだろうし、自分も1人のプレイヤーとしてもっと成長したいってのは常に考えてる。

でも僕が一緒に働きたい、作りたいって思うのはガッチリ肩を組んで、一丸となって問題に立ち向かうチーム。

今年の目標が決まった

「毎日少しずつ実験する」を今年の目標にする。

必ずしも仕事の現場に限った話ではなく、日々心がける。

人生やキャリアについても最近悩むことが多かったが、リチャードシェリダンに勇気をもらった。

Run the experiment!

自分の人生で実験するのだ。

実験しよう。失敗しよう。恥かいてこう。

npmを使ってみる #nodejs

npmってなんなのん?

npmはNode.jsを使う時のパッケージ管理ツールっぽい。

mavenとかGradleに近いものと理解した。

使ってみる

nodeが入っているなら一緒にインストールされているっぽい。

$ npm -v
5.6.0

package.json

workspace的なところで npm init すると、npmの管理プロジェクトになる。

質問に答えると、 package.json が作成される。

プロジェクト名やバージョン、依存が記述される。

mavenにおける pom.xml 的なものと理解した。

依存ライブラリの追加

npm install {ライブラリ} とやると依存に追加される。

package.json も自動で更新される。

同時に package-lock.json というのが作成される。

lockの方はバージョンが固定して記述されているものらしい。

package.json の方ではバージョンをレンジで書いたりする

基本的には両方まとめて管理するもののよう。

yarnってなんなのん

npmと一緒によく出てくるyarnというものがあるらしい。

役割的には一緒のもので、パフォーマンスがyarnの方がいいみたい。

Node.js的にはnpmが公式になっている模様。

一度にたくさんのことは覚えられないので、差し当たってはnpmを使っていく所存

Nuxt.jsの環境構築 #nuxtjs

Next.js とか Nuxt.js とかって何よ

サーバーサイドレンダリングって何よ

qiita.com

いきなり不要論とか言われましても

qiita.com

クライアントサイドで実行するJSをサーバサイドでも実行できるようにするって言う感じなのかな。

サーバサイドレンダリングというかUniversal JavaScript?

Vue.js

jp.vuejs.org

ユーザーインターフェイスを構築するためのプログレッシブフレームワーク

らしい。プログレッシブが何なのかは分からない。

とりあえず「はじめに」をコピペしつつ動かしてみた。

書き味はそんなに悪くない印象。

リアクティブって言葉、定義が広すぎてよく分からない

IDEA、Ultimateならプラグイン使える

Vue.js - Help | IntelliJ IDEA

Nuxt.jsの環境構築

nodebrew

nodeのバージョン管理をできるnodebrewを入れる

$ brew install nodebrew
$ nodebrew help
nodebrew 0.9.8

nodebrewを無邪気に使おうとしたらディレクトリがないとか言って怒られた。

Warning: /Users/hogehoge/.nodebrew/src/v8.9.4/node-v8.9.4-darwin-x64.tar.gz:
Warning: No such file or directory

ディレクトリを作ったら大丈夫になった。

$ mkdir /Users/hogehoge/.nodebrew/src

Node.js

nodebrewで最新の安定版をインストールする。

$ nodebrew install-binary stable
$ nodebrew ls
v8.9.4
$ nodebrew use v8.9.4
$ node -v
v8.9.4

Vue.js

$ npm install vue

CLIも導入する

$ npm install --global vue-cli
$ vue --version
2.9.2

Nuxt.js

サンプルプロジェクトを作る

$ vue init nuxt-community/starter-template hello-nuxt

依存するパッケージのインストール

$ cd hello-nuxt/
$ npm install

起動

$ npm run dev

http://localhost:3000 で起動します。

参考

qiita.com qiita.com

「UNIXという考え方」を読んだ

UNIXという考え方―その設計思想と哲学

有名な本だけど、はじめて読んだ。

その名の通り、UNIXというOSの考え方の解説本なんだけど、その考え方が本当に素晴らしいと思う。

「Small is beautiful」に始まり、「できるだけ早い試作」「効率より移植性」など、プログラミング・エンジニアリング・その他仕事のやり方全般に応用できる考え方の目白押し。

個人的には、少し異なる文脈で学んできたことに通じるものも多いんだけど、違った切り口で言語化されているので改めて頭の刺激になった。

「すべてのプログラムをフィルタとして設計する」はあまり意識したことのない考え方だったので、コーディングとかでも積極的に取り入れていきたい。

薄くてサクッと読めるところもよい。おすすめ。

読書メモ

「UNIXという考え方―その設計思想と哲学」読書メモ · GitHub

reverse-proxyとforward-proxy

proxyって仲介屋さんくらいにしか認識してなくて、reverse-proxyとforward-proxyの理解があやふやだった。

少し理解できた気がするのでまとめておく。

forward-proxy

クライアントが経由地として「意識する」Proxyがforward-proxy。

一般的にはただのProxyというとこちらを指すらしい。
(reverse-proxyの対比としてforward-proxyと呼ばれる模様)

例えばリクエストヘッダに乗せたり、ブラウザで設定するようなProxyはforward-proxyになる。

用途としては、内部ネットワークから外部へ通信する時に、ゲートウェイ的に使いたいときとかなのかなー、と想像している。

reverse-proxy

クライアントが経由地として「意識しない」Proxyがreverse-proxy。

クライアントはProxyを目的地だと思っており、Proxyがクライアントを目的地へ連れていく。

例えば、Webサーバを建ててアプリケーションサーバにバランシングするような構成はreverse-proxyになる。

ApacheTomcatを連携して流すような場合は、Apacheがreverse-proxyになる。

Web開発やってると、Proxyっていうとどっちかっていうとこっちを先にイメージしないかな。。どうなんだろ(自分はそうでした)

SpringBootを環境毎にいい感じに起動する #SpringBoot

Intro

SpringBootは設定をapplication.yml(properties)で管理するが、システムプロパティやコマンドライン引数で上書きすることができる。

もちろんprofileを用意して切り替える形でも良いと思うんだけど、環境依存系の設定の場合、環境変数を利用するなどして、環境側から渡してあげると使い勝手がよくなると思う。(12Factor's App的な)

個人的にはアプリケーションで指定された環境変数を入れておくよりは、環境側から引数で明示的に渡してあげるような形式が好み。

環境から渡すことが検討に値しそうなプロパティをまとめておく。

コマンド例

java -jar hogeapp.jar \
  --spring.datasource.username=${HOGEAPP_USERNAME} \
  --spring.datasource.password=${HOGEAPP_PASSWORD} \
  --spring.datasource.url=${HOGEAPP_DATASOURCE_URL} \
  --server.port=${HOGEAPP_PORT} \
  --server.servlet.context-path="/stg" \
  --logging.file="/var/log/hogeapp.log" \
  --logging.level.root=WARN \
  &

spring.datasource.*

  • spring.datasource.username
  • spring.datasource.password
  • spring.datasource.url
  • etc

DBの接続先などは環境によって変わるものだし、外から渡すことを前提にしてもよいかもしれない。

ユーザやパスワードについては管理方法次第だと思うが、アプリケーションから管理を引きはがせるメリットがある。

管理方針によっては有用な気がする。

server.port

SpringBootの起動ポートを切り替えることができる。

--server.port=9000 にした場合、 localhost:9000 で起動する。

SpringBootアプリケーションの手前にWebサーバを立てることは多いと思うので、Portの管理を環境に任せられる。

server.servlet.context-path

コンテキストパスを変更することができる。

環境の違いはドメインで表現する手も有りだと思うが、 /dev , /stg , /prd のようにコンテキストパスで表現するというのはどうだろうか。

※SpringBoot2.0でプロパティ名が変わる模様(元々は server.context-path

--logging.*

  • logging.file
  • logging.level.root

SpringBootはログを標準出力するが、logging.fileを渡すとそちらに書き出してくれる。

ローテートはデフォルトだとサイズ(10MB)でされるようだ。

levelも変更できるので、ログの管理方針によってはありかもしれない。

停止

プロセスIDでKillする。

$ pgrep -f 'hogeapp.jar'
$ kill -TERM {プロセスID}

参考

Maven Assembly Pluginを使って、特定のリソースをjar形式で配布する #Maven

概要

DDLなどのリソースがアプリケーションとリポジトリ(プロダクト)が別で管理されている場合に、別プロジェクトからそのリソースを参照したい場合があると思います。

例えば、UnitTest等の利用等が考えられます。

二重管理を避けるために、jar形式でリソースを配布するようにすれば、参照側では依存関係に追加するだけで済み、Mavenのバージョン管理に乗っかることも可能になります。

Maven Assembly Plugin を使えば、特定のディレクトリをjarやzipで固めることができるようになります。

pom.xml

Assembly Pluginを追加します。

<build>
    <plugins>
        <!-- 中略 -->
        <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.6</version>
            <configuration>
                <!-- 成果物の名前にassemblyがidを振ってしまうのを無効にする -->
                <appendAssemblyId>false</appendAssemblyId>
                <descriptors>
                    <!-- include/excludeなどの設定は外部ファイルに記述する -->
                    <descriptor>.assembly/assembly.xml</descriptor>
                </descriptors>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <!-- packageフェーズでassemblyのゴールを呼び出すことで、jarにリソースを同梱させる -->
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

assembly.xml

includeやexcludeなどの設定は外部ファイルに記述します。

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 http://maven.apache.org/xsd/assembly-1.1.3.xsd
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 ">

    <id>assembly-sample</id>
    <formats>
        <format>jar</format>
    </formats>
    <!-- ディレクトリ階層をプロジェクトルートにするかどうか -->
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <!-- 例えばflywayのデフォルトディレクトリのSQLを固めるのであればこんな感じ -->
            <directory>src/main/resources</directory>
            <outputDirectory></outputDirectory>
            <includes>
                <include>db/migration/*.sql</include>
            </includes>
        </fileSet>
    </fileSets>

</assembly>

参考