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

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

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

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

Managing deploy keys | GitHub Developer Guide

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

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

参考

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

CircleCI Java

現象

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をデバッグ

IntelliJ IDEA JavaScript

前提

拡張機能を入れる

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

社内勉強会でライトニングトークしてきた

勉強会 LT 登壇

社内勉強会でライトニングトークしてきた。
フリーテーマだったので何話そうか迷っていたけれど、最近いい感じになってきたチームのコードレビューについて話してみた。

コードレビューを題材にしたものの、チーム開発が単なる個人の集合じゃなくて、コラボレーションが生まれた時に、チームの力は何倍にもなるんだってことが少しでも伝わっていたら嬉しい。

久々に人前で話したけどやっぱり緊張する。。
なお、サッカーチームのたとえの話が一番熱を帯びてたというフィードバックを頂きました笑

speakerdeck.com

QA勉強会に行ってきた #QAアーキ

12/20にQA勉強会に参加してきたので、印象に残ったことや思ったことなどを残しておく。
品質評価に焦点を当てた勉強会に参加したのは初めてだったかも。

connpass.com

テスト観点は意図を明らかにする

  • 仕様をなぞるのではなく、意図を明らかにするのがテスト観点
  • そのテストでは何を気にしているのか、意図を明らかにする
    • ✕: 1M以上のファイル、ファイルサイズによる挙動(仕様書のコピーにしかなっていない)
    • ◯: ディスクをいっぱいにして動かなくしたい(意図を明らかにする)
  • その意図は開発者が気にすることになる
  • 観点が正に開発者が気にすることにつながるので、開発・QAのコラボレーションがすごく期待できそう
  • 開発者が気になるけども、気付いていない観点をQAが出せるようになったらさらに素晴らしい
  • 観点洗い出しができるようになると、設計やレビューでQAが可能になる

品質保証を選択する

  • どのQA観点をどう作り込みどう検証するかまとめる→アシュアランスフロー
  • どこで何をするか整理すると品質保証が取捨選択できるようになる
    • 品質保証は選択ができないといけない
    • どこで何を保証するかが整理されていないといけない
  • 工程の責務が明らかになれば、自動化の注力先も分かる
  • 捨てる選択ができるようにするアプローチはｲｲﾈ!!

スピード感が求められる中でのアプローチ

時間があったので質問してみました。

質問
  • QA観点を洗い出して、アシュアランスフローに落とし込むのはとても有用だと思う
  • Webサービス開発のようにスピードが求められる場合、QA観点の段階から取捨選択が必要になるのではないか
  • そのあたりに何かアドバイスあれば
回答
  • 大切にしたいものによって、やり方は色々ある
  • 品質に網羅性を求めるのか、機動性を上げたいのか、開発能力を上げたいのかで異なる
  • 特にスピードが求められる現場であれば、「これはやらなくていいよね、大丈夫だよね」の納得感が得られるようなアプローチ
  • 妖精型
    • 気になるところや気にしているところを集めて整理していく
    • ティータイムを設けて、最近自分が出したバグを共有する会を設けているところもある
    • 決してプロセスを整理したりハンコを増やしたりするものではない

感想

とても有意義で面白かった。
QAと開発のコラボレートが具体的にイメージできるようになったのが一番の収穫かもしれない。

その他メモ

  • チェックを増やすと精度は下がる
  • （主に上層部批判の）組織論的な話が出るのはどこでもだなぁ
  • バグを出したら怒られる、っていうのが無駄なプロセスを増やす根源な気がした

資料

www.slideshare.net