GitBucket + MariaDBの構築でハマった件

言うほどハマっていないです。

前提条件

  • Ubuntu 16.04
  • GitBucket 4.15.0
  • MariaDB 10.2.7

ISSUE_OUTLINE_VIEWがおかしいだの何だの怒られる

MySQLのバグ(というか仕様)で、ビューのFROM句でサブクエリを使えない、というのが原因。普段、仕事でもビューを使うことがないのでそんなこと全く知りませんでした(情弱

どうしましょうと思いググってみると、本家GitBucketのissueに解決法が載っていました。

github.com

4.14.0でビューを作成するSQLが変更になっているので、上記に書いてあるSQLでは対応できません。といっても、サブクエリ部分を別のビューに切り出しているだけなので、ソースと見比べながら作業すれば修正自体は数秒で終わります。

ということで、最新の4.15.0対応版が以下のSQL。

CREATE OR REPLACE VIEW ISSUE_OUTLINE_VIEW_SUB1 AS
  SELECT
    USER_NAME
    , REPOSITORY_NAME
    , ISSUE_ID
    , COUNT(COMMENT_ID) AS COMMENT_COUNT
  FROM
    ISSUE_COMMENT
  WHERE
    ACTION IN ('comment', 'close_comment', 'reopen_comment')
  GROUP BY
    USER_NAME
    , REPOSITORY_NAME
    , ISSUE_ID;

CREATE OR REPLACE VIEW ISSUE_OUTLINE_VIEW_SUB2 AS
  SELECT
    USER_NAME
    , REPOSITORY_NAME
    , ISSUE_ID
    , COUNT(COMMENT_ID) AS COMMENT_COUNT
  FROM
    COMMIT_COMMENT
  GROUP BY
    USER_NAME
    , REPOSITORY_NAME
    , ISSUE_ID;

CREATE OR REPLACE VIEW ISSUE_OUTLINE_VIEW AS
  SELECT
    A.USER_NAME
    , A.REPOSITORY_NAME
    , A.ISSUE_ID
    , COALESCE(B.COMMENT_COUNT, 0) + COALESCE(C.COMMENT_COUNT, 0) AS COMMENT_COUNT
    , COALESCE(D.ORDERING, 9999) AS PRIORITY
  FROM ISSUE A
  LEFT OUTER JOIN ISSUE_OUTLINE_VIEW_SUB1 B
  ON (A.USER_NAME = B.USER_NAME AND A.REPOSITORY_NAME = B.REPOSITORY_NAME AND A.ISSUE_ID = B.ISSUE_ID)
  LEFT OUTER JOIN ISSUE_OUTLINE_VIEW_SUB2 C
  ON (A.USER_NAME = C.USER_NAME AND A.REPOSITORY_NAME = C.REPOSITORY_NAME AND A.ISSUE_ID = C.ISSUE_ID)
  LEFT OUTER JOIN PRIORITY D
  ON (A.PRIORITY_ID = D.PRIORITY_ID);

マリア様がみてない

PostgreSQLに移行したいです。

ReactもVue.jsもAngularJSも万能ではないよ

React好きですか?私は大好きです。仮想DOM、素敵じゃないですか。でも、会社のプロジェクトで採用しようとは全く思わないです。

JSフレームワークの話題といえば、やれReactだ、やれVue.jsだ、やれ脱jQueryだ、というのがここ数年のトレンドだと思います。これ、もう辞めませんか?フレームワークを使えばどんなものにでも対応できる、なんてものは幻想です。

先日、社内のアプリ開発チームと話をする機会があったのでいろいろと聞いてみたのですが、React Nativeを採用したアプリがあったけれども全てSwiftなどネイティブ言語に戻したらしいです。
とある人が率先してReact Nativeに取り組むも、デザイナーやプロデューサーからは批判続出、挙げ句の果てにはその人は退職して残された人がメンテを続けるという。
可読性の落ちていくコードに、ネイティブのような細かな処理を実装するのが困難(ノウハウも蓄積されていないため)で、まあガッカリだったそうで。

私はアプリ開発とは別の世界でやっているので、正直詳しいことはよくわからないのでなんとも言えないのですが、話を聞く限りでは良いことが何もなかったとのこと。うーんこの。
Web開発にしても、各種ライブラリのアップデートに対応していくなんて無理ゲーです。そんな工数はないですよ。

そんなこんなで自分の所属チームでは以下のような形で落ち着いています。

基本ライブラリ
  • jQuery
  • Underscore.js
モジュールバンドラ
  • webpack
トランスパイラ
  • Babel

普通ですね、超定番。枯れ始めた良い感じのツールたちです。セレクタはSizzleでいいのでは?AjaxはPromise使えばいいじゃん?などという話も出たのですが、結局は誰でも使いやすいようにjQueryに(あと面倒なブラウザテストを避けるためにも)なっています。

結局のところ、弊社のようにサービスを継続させていくにはメンテナンスが不可欠なわけで、仮に担当者が変わっていっても対応し易いようなものを開発していくしかないよなぁというのが所感です。仕方ないね、サラリーマンだもの。
そして仮に新しい技術やツールを採用するとしても、本当にそれが必要なのかどうかについてチーム全体で検討し合うべきだと思いますです。

PHPで日付操作するときのアンチパターン

どんな言語であっても、日付を扱うのは何かと厄介なのものです。

例えば、PHPで先月末日をyyyymmdd形式で表示したい場合。ググってみると以下のような書き方をしているサイトをチラホラ見かけます。

<?php
echo date('Y-m-t', strtotime('-1 month', strtotime(date('Y-m-1'))));
// 2017-02-28

動作は問題ない、けどちょっとこれは乱暴すぎでは?最低でも以下のように書くべきだと思います。

<?php
echo date('Y-m-d', strtotime('last day of last month'));
// 2017-02-28

この書き方は何かと便利なので覚えておいたほうがいいです。

<?php
$now = time();
$yesterday1 = date('Y-m-d', strtotime('-1 day', $now));
$yesterday2 = date('Y-m-d', strtotime('yesterday', $now));
// $yesterday1 === $yesterday2

PHP: 相対的な書式 - Manual


まあでもdate()とstrtotime()よりも、DateTimeクラスのほうが何かと捗ります。

<?php
$date = new DateTime('last day of last month');
echo $date->format('Y-m-d');
// 2017-02-28

date()はタイムゾーンがサーバ依存になってしまいますので、Webアプリ的な意味では正直言って論外です。strtotime()に関してはバッファオーバーフローするなどのバグで有名ですし。

date()とstrtotime()を使いまくっているソースを見かけた際には、ぜひプルリクしてあげてください。