Visual Studio Codeがいい感じ

普段のちょっとしたメモ書きに使うエディタをVisual Studio Codeにしてみたのだが、これがどうして中々いい感じである。

code.visualstudio.com

普段ソースコードはほとんどIntelliJ IDEAで完結してしまうので、エディタで実装はほとんど行わない。
なので、エディタに求めていたのは下記。

• Markdownで書ける
• Markdownのプレビューができる
• Git操作ができる

Git操作はちょっとしたメモでもGit管理したいことは往々にしてあるし、Gistなどに連携することも多いから。

Visual Studio Codeはプラグイン不要でターミナルが開けるのがとてもよい。
Git操作はコマンドラインで行う派なので、ターミナルで操作できるのはうれしい。

ターミナルとの行き来が楽ちんなので、最近触り始めたdockerもVisual Studio Codeにお世話になってる。
Dockerfile記述→buildやコンテナ起動が楽にできる。

しばらくはメインのエディタになりそう。

こんな感じ

テーマ変更

基本設定→配色テーマから。

背景色は明るい方が好きなので、Quiet Lightにテーマ変更。
VSCに限らず、最近のエディタ類は後ろが暗いテーマが多い気がする。
きっとコントラストを付けやすいからなんだろうな。

自動保存

ファイル→自動保存から。

自動保存デフォでしてくれる方が好きなので、設定変更。

「わかる！ドメイン駆動設計 」を読みました

DDD、ドメイン駆動設計という単語は耳にしていたものの、ご多分に漏れず例の分厚い本に臆してました。
「わかる！ドメイン駆動設計 」ならボリュームも少なそうだし、読みやすいかなって思って読んでみました。

techbooster.booth.pm

つまみ食いしていた知識をつなぎ合わせて、DDDの雰囲気を掴むのにはとても役立ったと思う。
ただ後半に行くにしたがって明らかに疑問の量が増えていくので、やっぱり分厚い本と戦う必要がありそう。

とはいえとっかかりとしてはだいぶ気軽に読めたし、関心も高まったのでよかった。

次は実践ドメイン駆動設計を読んでみるのがよさそう。 また積読が増えていく。。

余談

ドメインエキスパートは見つけるのもそうだけど、協業して巻き込んでいくのが大変なんではなかろうかという思い。
スクラムのプロダクトオーナーと似た雰囲気の難易度を感じる。

mysqldumpでROW_FORMATが出力されなくなった #mysql

現象

MySQLを5.5から5.6にしたら、mysqldumpした際のDDL( CREATE TABLE とか)に、ROW_FORMATが出力されなくなった。
importでこけたので調査してみたらCompactで作成されており、追いかけてみるとdumpした時点のDDLにROW_FORMATの出力がなかった。

エラーメッセージ。

ERROR 1118 (42000) at line XXXX: Row size too large (> XXXX). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

ほんとは下記のように出力されて欲しい。

CREATE TABLE `table_name` (
  /* 略 */
) ENGINE=InnoDB AUTO_INCREMENT=5095266 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

対応

どうもmysqldumpに --compatible=ansi オプションをつけていたのが原因だったよう。

copatibleオプションは

古い MySQL サーバーやほかのデータベースシステムとの互換性がより高い出力を生成します。

とあるので、MySQL固有であるROW_FORMATを出力しなくなったということなのだろう。
オプションを外したら出力されるようになった。

メモ

-- ファイルフォーマットの設定確認
SHOW GLOBAL VARIABLES LIKE 'innodb_file_format';

-- ROWフォーマット確認
select TABLE_SCHEMA, TABLE_NAME,  ROW_FORMAT from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='schema_name' and ROW_FORMAT!='Compact';

-- テーブルごとのROWフォーマット確認
SHOW TABLE STATUS LIKE 'table_name';

参考

MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.5.4 mysqldump — データベースバックアッププログラム

Collectors.toMapで、同一キーを処理する #java

streamでMapに詰める

Javaのstreamを使ってMapにつめかえる場合、Collectors.toMapを使う。

Map<Long, String> fooMap = fooList.stream()
  .collect(Collectors.toMap(
     Foo::getId,
     Foo::getName
  );

しかし上記の場合だと、キーが重複していた場合に IllegalStateException が発生する。

同一キーを処理する

これを防ぐには、第三引数で同一キーに対する値を受け取れるので、処理を追加する。

Map<Long, String> fooMap = fooList.stream()
  .collect(Collectors.toMap(
     Foo::getId,
     Foo::getName,
     // この場合、先勝ちにしている
     (name1, name2) -> name1
   );

参考

fits.hatenablog.com

GitHubで何か自動化するならdeploy keysが便利だ

GitHubで特定リポジトリに対して何かを自動化する時、専用のアカウント用意しないとダメかなー、なんて考えていたらDeploy Keyと言うものがあった。

Managing deploy keys | GitHub Developer Guide

deployという名前だけど、deploy以外にも使える。
ReadOnlyにするなど、権限の制御も可能。

リポジトリ単位での作業なら、deploy Keysでほとんど事足りそうだ。

参考

• GithubのDeploy Keysを登録してパスワードなしでアクセスする - Qiita
• Read-only deploy keys · GitHub

CircleCIでメモリ上限値越えエラー #circleci

現象

CircleCIのビルドが TIMED OUT で失敗して、見に行ってみたら下記のようなメッセージが表示されていた。

Your build has exceeded the memory limit of 4G on 1 container. The results of this build are likely invalid. We have taken a snapshot of the memory usage at the time, which you can find in a build artifact named memory-usage.txt. The RSS column in this file shows the amount of memory used by each process, measured in kilobytes.

原因

どうやらCircleCIのビルドコンテナのメモリ上限は4Gらしく、それをオーバーしてしまったよう。 circleci.com

対応

前述のページを参考に、 circle.yml にJVMのオプションを設定する。
これでJVMのメモリ使用上限は抑えられるはず。
数値は適宜見直す。

machine:
  environment:
    _JAVA_OPTIONS: "-Xms512m -Xmx1024m"

補足

メモリ上限値越えの場合、CircleCIが memory-usage.txt というartifactsを生成してくれる。 どこにコストがかかっているか分かるので、調査の際に役立つ。

IntelliJ IDEA でJavaScriptをデバッグ

前提

• Chrome
• IntelliJ IDEA ULTIMATE 2016.3

拡張機能を入れる

Chrome Extensionを導入する。

chrome.google.com

ローカルデバッグ

プロジェクト内にある HTML + js のような形であれば、HTMLファイルを右クリック→デバッグ実行でOK。
ビルトインサーバーが起動して、デバッグできる。

http://localhost:<built-in server port>/<project root>/<path to the HTML file relative to the project root>

リモートデバッグ

リモートと連動したデバッグも可能。
たとえばSpring-Bootで作成したアプリケーションの画面を操作しつつデバッグできる。

1. Run/Debug Configurationsウインドウを開く（Run→Edit Configurations）
2. 「+」で「JavaScript Debug」を追加
3. Nameは適当に
4. URLにリモートデバッグしたいURLを入力(ex: http://localhost:18080/demo/ )
5. リモートが起動しているうえで、作ったConfigurationをデバッグ実行する

その他

• ChromeのDevlopper toolと共用はできない模様

余談

Spring-Boot + Thymeleafで開発している時、Thymeleafのキャッシュ（ spring.thymeleaf.cache=false ）をoffにしても再起動しないと反映しなくて困っていた。

Thymeleaf templates cache even when spring.template.cache: false · Issue #34 · spring-projects/spring-boot · GitHub

Then,after edit html template, must use CTRL+F9 to make the project.

MacだとCmd + F9 で明示的にリビルドが必要なだけだった。。

参考

IntelliJ IDEA 2016.3 Help :: Debugging JavaScript