spring-bootアプリをherokuにデプロイする #heroku #SpringBoot

Heroku SpringBoot

前提

  • herokuのアカウントは作成済
  • SpringBoot単独で起動可能にしている（外部DB等を必要としない）
  • git管理されている

heroku CLIのインストール

Macだとhomebrew。

brew install heroku

Procfileの作成

プロジェクト直下に Procfile という名前でファイルを作成する。

web: java -jar target/hoge-app.jar --server.port=${PORT}

herokuでは起動ポートが動的に変わるようなので、SpringBoot側のポート番号もherokuの環境変数で書き換えている。

作成したらコミットしておく。

ビルド、デプロイ

$ heroku create
$ git push heroku master

勝手にビルドが始まり、デプロイしてくれる。便利！

なお heroku create は初回だけでOK。

以降は修正をコミットしたら heroku push だけすればいい。

補足

pushした最後にURLがログに出るけど、 heroku open すると、ブラウザを起動してくれる。

heroku logs --tail しておくと、heroku上のログがトレースできる。

参考

モブプロディスカッションに参加してきた！ #mobProgramming #MobDiscussion

MobProgramming 勉強会 ポエム

モブプロディスカッションに参加してきました！

www.eventbrite.com

内容としては及部さんがDevLOVEの講演の再演をした後、会場の質問を中心にパネラーがディスカッションするというもの。

自分のチームでモブプログラミング、モブワークをし始めてだいぶこなれてきた感が出てきたけど、色々刺激を貰って考えることも多かった。

何より会場の熱量が高くて、それを感じられたのが大きかったかも。

思ったこと

モブプロはもちろん銀の弾丸じゃない。

パネラーの人たちも繰り返し言ってたし、それはきっとみんな重々承知している。

いいチームだからいいモブができる。

モブをやったからって必ずしもいいチームになるわけじゃない。

まず、いいチームを作ろう。

感じたこと

でもそれを飛び越えて伝わってくる、モブプログラミングの楽しさや素晴らしさ。

自分にも実感としてある。

本当に「一緒に作ってる」っていう感覚になる。

問題に一丸となって立ち向かうあの感じ。

突破口を切り開いて、全員で一気に加速するあの感じ。

迷っている時に、背中を押してくれるあの感じ。

困っている時に助けてくれるあの感じ。

モブプロをしたから最高になるわけじゃない。

でもきっと僕らがモブプロをしたら最高だ。

まとめ

モブプロしようぜ！

f:id:su-kun1899:20170711233439p:plain

gitignoreでホワイトリストを作成する #git

git

gitignoreで、明示的に指定したファイルしか扱えないようにホワイトリストを作成する方法について（意外と手間取ったので）残しておく。

ホワイトリスト方式とは

ここではgit管理において、明示的にgitignoreに指定したファイル以外バージョン管理としないという意味で使っています。

こんな構成をイメージ

  • 階層がある
  • 管理したいファイルや構造にルールはない
    • ファイル名や拡張子でグルーピングはできない
.
├── abc.txt
├── hoge
│   ├── aaa.txt
│   ├── fuga
│   │   ├── bbb.txt
│   │   ├── piyo
│   │   │   ├── ccc.txt
│   │   │   └── zzz.txt
│   │   └── yyy.txt
│   └── xxx.txt
└── xyz.txt

gitignore

こんな感じにするとうまく管理できる。

# すべてをignore
*
# すべてのディレクトリをホワイトリストに追加する
!*/
# ホワイトリストに入れたいファイルを戸別に許可する
!.gitignore
!xyz.txt
!hoge/aaa.txt
!hoge/fuga/yyy.txt
!hoge/fuga/piyo/ccc.txt

この例の場合、(書くまでもなさそうだけど)下記のファイルがバージョン管理対象となる。

  • xyz.txt
  • hoge/aaa.txt
  • hoge/fuga/piyo/ccc.txt
  • hoge/fuga/yyy.txt

補足

ポイントはすべてのディレクトリをホワイトリストに追加していること。

なぜわざわざこんなことをしているかというと、どうもgitignoreは上位ディレクトリがignoreされていると、下階層を再帰的には見てくれないらしい。

上述の例だと、ディレクトリをホワイトリストに入れないとaaa.txt、ccc.txt、yyy.txtはignoreされてしまう。

逆に言うと特定のディレクトリ配下を除外したい場合はそのまま指定すればよい（ hoge/fuga/ とやればfuga配下は丸っとignoreされる ）

ディレクトリがホワイトリストではなくなってしまうけど、gitは空ディレクトリは無視するし、.gitkeepも明示的に指定する必要があるので、実質問題ないと思う。

参考

stackoverflow.com

モブプログラミングに実況システム導入するのおすすめです #MobProgramming

MobProgramming

僕らのモブチームは実況システムというのを導入しているのだけれど、それがとてもいい感じなので紹介したい。

実況システムとは

思ったことや感じたことを皆が気軽に発言、共有できる場を用意すること。

モブプログラミング中にリアルタイムで加筆、修正していきます。

僕らの場合は HackMD を使っています。

どんなことを書くのか

本当に、「何でも」書きます。

今何をやってるか、思っていること、メモ、雑談、などなど。

勉強会やカンファレンスで、Twitterでハッシュタグ付けて呟いていくあのイメージです。

  • 今日はXXXからやるぞー
  • 念のためXXX確認しておいてよかった
  • XXX初めて使ったけどかなり便利
  • お腹すいた
  • XXX使えばもう少しすっきり書けないかな。。？
  • そろそろ休憩しよう

何がいいのか

発言ハードルが低い

作業を止めるほどでもないけど、ちょっと気になるなぁ、くらいの気軽さで発言できる。

もちろん大切なことはオフラインで発言すべきだけど、モブプロ中は実現したいことにフォーカスしてるので、本筋と論点が少しずれるようなことは言い出しづらいこともある気がする。

文字として残ってることで、キリのいいタイミングでチームで議論ができる。

後で相談しよう、は忘れてしまいがち。

ふりかえりに使える

僕らは一日の終りに実況をさらっと総ナメして、今日やったことを整理して、翌日やることを確認する。

一日の出来事を俯瞰してみることで、潜在的な課題やタスクに気付くことも多い。

気になってたことをその場で質問したり軽く相談したりもできる。

「なんでも」書いてあるので、チームの定性的な状態が分かったりもする（なんだか皆疲れてる？とか）。

情報がログになる

僕らの実況はマークダウン形式で書いているので、そのまま日報にしてesaに日報として残している。

情報がログとして残っているのは未来の自分たちに大きな意味を持つと思う。

ソロやペアだと共有知として情報を残すことに割く力が足りないことが多い。

でもモブだと手と目が多いことでスピードを落とさずに一定の情報をアウトプットすることができると思う。

たとえば分かりにくい仕様についてのメモだったり、フレームワークの使い方を調査した結果だったり、トラブルシューティングの記録だったり。

アウトプットしておくことで、他チームの助けになることもあると思う。

まとめ

ちょっと前に分報がいいとか悪いとか議論になっていたような気がするけど、実況＋日報とすることで、メリットを享受しつつ、デメリットを回避できると思う。

モブプロ＋実況システム、おすすめです。

f:id:su-kun1899:20170709170037p:plain

ドットインストールの独習会に参加しました #dotinstall

ドットインストールの独習会に参加してきた。

『ドットインストール』公式ブログ - 【7月6日】そろそろ時間をとってJavaScriptを勉強したい人向け自習会を行います

実は今回で参加するのは二回目。

抽選で当たった模様。倍率は知らない笑

前半はもくもく会で、後半は席の近い人やスタッフの方々と気軽に会話するミートアップといった感じ。
(ピザと飲み物が提供された)

一応独習の内容はドットインストールのレッスンかつJavaScriptということになっていた（今回の場合）。

Electron

JavaScript絡みで何がいいかなー、と思ったらElectron入門があったのでやってみた。

http://dotinstall.com/lessons/basic_electron

完全に初めてだったけど、中々楽しい。

一時間ちょっとくらいで、なんとかアプリを立ち上げて画面表示するくらいまではできた。

時代の流れ

Electron自体もNodeJSも最新のバージョンがレッスンのものとは大分違って、流れの速さを改めて感じる。

幸い、今日やったくらいのところだとそのせいでハマることはなかったけど。

gitignore

Electronだとgitignoreどうすんだろ？と思って何も考えずにググって出てきた↓をパクってみる。

Gitignore for Electron application development · GitHub

NodeJSだと node_modules はignoreするのか。。 npm start すると package.json 見てよろしくやってくれるのかしらん？

package.json がきっと maven でいうところの pom.xml なのかなー、と勝手に想像（違うかもだけど）

Visual Studio Code

普段コードは基本的に言語を問わず Intellij IDEA で書くんだけど、今回は何となく Visual Studio Code を使ってみた。

主にマークダウンのメモ帳としか使ってないんだけど、ちゃんと覚えればかなり強力にコーディングもできるんだろうなぁ、という印象。

とりあえずフォーマットのショートカットキーは覚えた。でも多分明日には忘れる。。

qiita.com

ミートアップ

後半の懇親会的なやつは、作業していた席で基本そのまま実施。

立食形式とかじゃなくて助かる。。（人見知りには地獄になるので）

仕事何やってるのかとか、何で参加したのかとか他愛のない話。

ドットインストールのサービスの特性上そうなんだろうけど、若いエンジニア（志望含む）か、非エンジニアが多く参加している印象。

考えてみると、非エンジニアの人とプログラミングを介して話すことはそうないと思うので、いい機会だったのかもしれない。

ポエム

参加者の中に学生さんがいたんだけれども、これから就活らしい。

エンジニアになるのか、そうじゃないのかは知らんけども。

SIなのか、事業会社なのか、大企業なのか、ベンチャーなのか知らんけども。

きっとどこに行ってもそれなりに大変なことはあると思う（多分）。

でもそれらを補って余りあるほどの楽しいことがエンジニアリングの世界にはあると僕は思ってる。

それぞれの場所で、お互いがんばれたらいいね。

知らんけども。

構文解析ハンズオンに参加してきました #構文解析ハンズオン

勉強会

ちょっと行ったことのない感じの勉強会に参加してきました。

lang-impl.connpass.com

GitHubにテストコードと回答の付いたソースコードがあって、cloneしてテストを通すようにする流れ。

午前中にイントロダクション的な講義があった後は、課題の説明→コード書く→解説を繰り返す感じだった。

扱った課題

  • １桁整数
  • 非負整数
  • 単純な算術式
  • 一般的な算術式
    • 四則演算
    • ネスト可能
    • カッコによる優先順位変更
  • JSON

自分は一般的な算術式の途中までしか行けなかった。。

構文解析初挑戦

前提知識が何も無い中で挑んだので中々難しかった。

テストがあったので、テストが通るように自力の力技で進めてたんだけど、算術式あたりで限界を迎えた。

Qiitaでちょうど似たことを扱ってる記事があり、参考になった。

qiita.com

反省点としては、Javaとしての書き方やオブジェクト指向的な書き方（というか、普段コード書く時に最初に考えること）が先に来てしまって、構文解析の理解を妨げてしまった気がする。

たとえば、Stream使うとか、処理の共通化とか、状態管理（インデックス位置の扱い）なんかは、一旦脇においたほうがよかったかも。 (逆にいうと、Javaでやったけど、言語から一歩引いて処理の仕方を考えるというのは普段やらないことなのですごく刺激があった気はする。)

たぶん本当はBNFの方が重要で、BNFがしっかりできれば、あとはコードに落としこんでいくだけなのかなぁ、なんて思ったり。
（あぁ、だから構文解析器があるのか？）

残念ながらコードに落とし込む力が足りずにタイムオーバーでしたが。。

まとめ

  • 正規表現ではできないことを無理やり正規表現でどうにかしようとしているのを見かける、っていう話は印象に残った。

  • 構文解析の知識がついたかは自信ないけど、朝の11:00から夜19:30くらいまで、普段とは違う形で頭を使ったのはすごく有意義だったと思う。
    （最後の方は頭から煙出てた気がする）

  • 本格的な構文解析は考慮しなきゃいけないことさらにたくさん増えそうだし、自分が普段何気なく使ってるようなParserの凄さを実感した。

  • ちょっとドキドキしながら参加したけど、楽しい一日だった。

当日の資料

kmizu.github.io

モブプロに魔法感あった #mobProgramming #ちら裏

MobProgramming チラ裏

概要

もう最近はずっと、チームの作業は基本的にモブプログラミングになってる。（今は6人体制）

ちょっと印象に残る出来事があったので残しておく。

きっかけ

今進めている実装で、一部モヤモヤすることところがあった。

ちょっとテストがめんどくさかったり、どうもスマートさに欠けるというか。

んで、「この辺モヤモヤするよねー、何とかなんないかなー」となんとなしにつぶやいてみたんです。

そしたら

そこから議論が始まって。

設計というか実装方針とかが決まって。

実際に実装してみて（もちろんモブスタイルで）。

テスト通してうまくいって。

もっと良くなんないかなー、ってリファクタリングの議論して。

こうしてみたらどうだろ？って色々試して。

似たような感じのとこも適用できそうだったって展開して。

あっという間にスマートな実装に生まれ変わった。

すごくない？

もちろん自分も議論に参加したし、モブプロもしたんだけど。

なんかモヤモヤを吐き出したら、いつの間にか始まってあっという間にできあがった感じがして。

「魔法かよ！」って思いました（笑）

まとめ

もちろん銀の弾丸ではないんだけど、モブプロ最高なので続けて行きます。