読者です 読者をやめる 読者になる 読者になる

RedPenで技術文書の誤りを指摘してもらおう

自然言語の誤りを指摘してくれるRedPenを手元で使えるようにしてみました、という記事です。気が向いたので、色々書いてみました。

エンジニアであっても意外と文書を書いたり見たりする機会が多い

エンジニアとしてはてなに入社後、コードレビューをする機会はもちろん多いですが、意外と自然言語(私の場合は日本語、英語がメイン)のレビューをする機会も多いことに気が付きました。他人の書いた文書に対するレビューに限らず、自分の書いた文書に対するレビューも含みます。

自然言語も機械が勝手に間違いを指摘して欲しい

プログラムでは各言語のlinterやciのテストを通すことで、レビュー前に単純な誤りに気づくことができます。typoやsyntax errorのようなささいなことを人間がやっていると疲れるので、機械が勝手にやってくれるのはいいですね。自然言語にもlinterっぽいものはいくつかあって、例えばMicrosoftのwordなどはそうでしょう。研究論文を書いてるときに簡単な誤りはwordに投げてざっとチェックして、というのをやっていました。

しかし、技術文書をwordに投げるとうまくいかないことが多いです。私の場合、markdownで文書を書く機会が多いですが、markdownのsyntaxをwordは当然ながら解釈してくれません。markdownのsyntaxに関する赤線なのか、日本語の文法としておかしいことへの赤線なのかを人間が判断していると、これまた消耗します。私はとにかく消耗したくないのです。

自然言語もルールで分かることは機械(RedPen)に指摘してもらう

自然言語もプログラミング言語と同様に文法を持ちますが、最大の違いは曖昧性の有無でしょう。自然言語処理の大部分は曖昧性をいかに扱うかとの戦いといっても過言ではありません。自然言語処理の研究分野でも最近誤り訂正の話題は活発に議論されていて、コンペティションも開かれています。Shared taskで有名なCoNLLでも2013年にテーマになりました。

100%に近い精度を出すことがまだまだ難しいため、このように研究分野になっているわけですが、ルールでも分かる簡単なものは将来と言わず今でも指摘して欲しいです。RedPenはその要望を満たしてくれるソフトウェアの1つです。

詳しい機能はサイトを見てもらうといいですが、私がよいと感じたのは以下の部分です。

  • 様々なマークアップ言語に対応している
    • markdownを含め、LaTeXにも対応
  • 日本語や英語など様々な言語に対応
  • 必要ない指摘は設定でオフにできる
    • 「誤りと指摘されたこの箇所は自分は誤りだとは思わない」というのがよくあるパターンですが、うざいと思ったら設定でオフにできます

インストールも簡単でした。

% brew install redpen

予想通り、指摘が多かったため、設定で以下の項目はオフにしました。

  • InvalidSymbol
  • KatakanaEndHyphen
  • EmptySection

指摘例

最近書いたブログの元テキストをRedPenに流してみました。私の場合、特に一文が長い表現を書いてしまう傾向があるのですが、SentenceLengthCommaNumberで怒ってくれているのはまさにそれですね。

% redpen --format markdown --conf /usr/local/Cellar/redpen/1.8.0/libexec/conf/redpen-conf-ja.xml ~/Dropbox/_posts/2017-03-20-清算用Slack-botを書いた.md 2>/dev/null
2017-03-20-清算用Slack-botを書いた.md:14: ValidationError[SentenceLength], 文長("121")が最大値 "100" を超えています。 at line: 昔のことは忘れてしまうので、清算用のSpreadsheetを作ろうとしましたが、出先で開くのは手間なので、slackからできるといいよねという妻の声がありましたが、外部でちょうどいいサーバーを持っていなかったので、そのときは流れました...。
2017-03-20-清算用Slack-botを書いた.md:14: ValidationError[CommaNumber], カンマの数 (5) が最大の "3" を超えています。 at line: 昔のことは忘れてしまうので、清算用のSpreadsheetを作ろうとしましたが、出先で開くのは手間なので、slackからできる といいよねという妻の声がありましたが、外部でちょうどいいサーバーを持っていなかったので、そのときは流れました...。
2017-03-20-清算用Slack-botを書いた.md:14: ValidationError[DoubledConjunctiveParticleGa], 一文に逆説の接続助詞 "が" が複数回使用されています。 at line: 昔のことは忘れてしまうので、清算用のSpreadsheetを作ろうとしましたが、出先で開くのは手 間なので、slackからできるといいよねという妻の声がありましたが、外部でちょうどいいサーバーを持っていなかったので、そのときは流れました...。
2017-03-20-清算用Slack-botを書いた.md:24: ValidationError[InvalidExpression], 不正な表現 "俺" がみつかりました。 at line: 俺は好きなエディタで書きたいし、gitでコード管理したいし、何ならTypeScriptで書きたいんじゃー、と思っていたところでいいエントリを見つけました。
2017-03-20-清算用Slack-botを書いた.md:29: ValidationError[InvalidExpression], 不正な表現 "最高" がみつかりました。 at line: 最高です、IDEAでリファクタリングや定義元に戻るとかもできるようになったので完璧です。

EmacsからRedPenを使う

Emacsで技術文書を書くことが多いので、Eamcs内からRedPenを叩けるとよさそうですが、すでに作っている方がいらっしゃいました。

作者の方がインストールの手間が省けるように、ディフォルトでは(作者が立てた)Herokuサーバーを見に行くようになっています。私の場合、オフラインで動いて欲しいことや社外に出すとまずい文書でも動いて欲しいということがあるため、設定でローカルのRedPenを見に行くように変更しました。

(el-get-bundle karronoli/redpen-paragraph.el)

(define-key markdown-mode-map (kbd "C-c C-r") 'redpen-paragraph)

(defvar redpen-commands
  '("redpen --format markdown --result-format json2 --conf /usr/local/Cellar/redpen/1.8.0/libexec/conf/redpen-conf-en.xml %s 2>/dev/null"
    "redpen --format markdown --result-format json2 --conf /usr/local/Cellar/redpen/1.8.0/libexec/conf/redpen-conf-ja.xml %s 2>/dev/null"))

(defvar redpen-paragraph-force-reading-whole t)

これでC-c C-rで校正の結果が出てきて、編集すべき箇所にすぐに飛べるようになったので、快適になりました。

まとめ

機械で指摘してくれる箇所は機械にやってもらって、人間はもっと本質的なところを考える時間を増やしていきたいですね。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

家庭内財政会議を開きました(2016年版)

2016年はとっに終わっているという声は聞こえない…。昨年の様子はこちら。

前提

30歳サラリーマンで京都で夫婦で共働き(子どもなし)です。今のところ財布は別々にしていて、家賃光熱費等の共通出費の用途には別途口座を設けています。お金を貯めるために普段の生活をめっちゃ頑張りたいわけではなく、外食もまあまあ多く、時には散財もしたい(apple watchも買ったし、iPadの一番でかいやつも買ったし、何ならswitchも買った)という感じです。しかし、新卒の最初の2-3年ほどは自分の収入と支出がいったいいくらなのかを全く考えずに過ごしていて、さすがにこれではいかんだろうと思い自分の財政状況を確認し出しました。結婚もしたので年に一度妻と一緒にそれぞれの財政報告会議を開き、将来の計画等について話す機会を作っています。

リタイヤ後にまあまあな生活をするためにはX000万必要そうなので(金融機関がぜったい教えたくない 年利15%でふやす資産運用術を元に計算)、年に100万程度を3.5%程度で株式/投資信託/債券/年金で運用という計算を立てています。3.5%のところはインデックス投資や10年の国債を買っていて、変にブレまくることはないので無駄に売買して取引コストがかからないように気を付けよう、程度しかやっていない(NISAは一度も売却していない)。それぞれのアセットにどの程度投資するかは、以下のエントリに書いています。

資産の時系列推移

2014年末からMoney Forwardで自分の口座や収入、支出を見るようになりました。推移は下の図の通り。Money Forwardで記録し始めた前後でNISAや確定拠出年金が開始しました。何となく縦軸の数字は隠していますが、エントリを読んでいくと大体想像が付く…。

f:id:syou6162:20170317073310p:plain

2016年は4月からはてなに転職したので、その前後で資産総額がぐらついています(退職月は手取りが少なく翌月には退職金でがっと増えた)。はてなに入社後は順調に資産総額は増えているのでいい感じかなと思います。前職時代は手取りが少なくボーナスでがっと増えており、年間で見ると増えている状況でした。

企業型確定拠出年金で毎月一定額が年金に行く関係で資産に占める年金の割合が多くなってきたのが2016年の大きな特徴でした。年金なので今すぐ使えるわけではないですが、税制面で圧倒的に優遇されているため今後も続けていこうと思います。企業型確定拠出年金での投資が増えているので、NISAは以前よりは額を抑えめでいこうかなと思っています。総額で年間100万投資できればよかろう、という目標なので。

収支

支出

絶対額は書かないですが、額の大きな項目を上げていきます。項目はMoney Forwardの項目をそのまま使っています。

家賃はやはり一番大きな支出の項目であり、固定費なのでなるべく下げたいですが、会社から遠いと疲弊するし狭すぎるとつらいので難しいですね…。今は通勤時間15分で自転車通勤なので、ギリギリまで寝られて満員電車で疲れることもなく快適です。家賃は支出の約3割を占めていました。収入がめっちゃ増えない限りは絶対額はなるべく増やしたくない…。

食費は次に大きい項目でしたが、はてなに入ってお昼がまかないが出たりTGIFで会社で飲み食いすることも増えました(技術勉強会のあとに寿司も出る)。その結果、食費の支出は昨年の60%まで削減されていました。マジか。

3番目に大きな項目が奨学金で、どうしようもないとはいえ毎月あるのは辛いですね。学部と修士で借りていたので、まだまだ7桁あります。幸い無利子なので、じわじわと返していきます。

特別な支出が4番目でこれは主に散財項目。apple watch、ipadやswitchなどがここでした。昨年と大体同額ペースできていましたが、年末に調子に乗ってapple watchやipadを買ったため、去年よりも増加した項目です。

教育・教養が5番目にきていて、これは主にAmazonの本の購入です。はてなに入って色々勉強しないといけない項目があるので、それ関連の本を買ったのと後はマンガが多い。

収入

ここも絶対額は書かないですが、前職時代よりは毎月の手取りは増えました。加えて、毎月の企業型確定拠出年金があるので、いい感じでした。

その他

ふるさと納税

2016年もふるさと納税を行ないました。2016年からワンストップ納税ができるようになっていたにも関わらず、すっかり忘れていて先週税務署に行ってきましたが。絶対額は大きくないですが、税金控除があるので、2017年もふるさと納税はやっていこうと思います。ちょうど昨日お刺身が届いたところでした、うまかった…。

共通口座の残高の監視

家賃振り込みを忘れると恥ずかしいことになりますが、定期的に見に行くのは面倒です。家賃口座を定期的にプログラムでクロールしてきてmackerelのサービスメトリックに登録するようにしました。残高が家賃を下回ったらslackに通知がいくので急いで入金するというプロセスができました。

清算用botの作成

家庭用の清算君(Slack bot)をGoogle App Scriptで書いた + TypeScript化した

こんな話です。大体は先人の真似っこ。

  • 家庭用の清算をGoogle Spreadsheetでやりたい
    • Spreadsheetを出先で開くのは手間なので、slackからできるといいよね
  • slackからSpreadsheetに書き込んでくれる君を作ろう
    • 外のサーバーでやるのも面倒だからGoogle App Scriptでやろう
  • Script Editorで書くのダルい、自分の好きなエディタで書きたい
    • ローカルで書けるようにして、ついでにTypeScript化した

TypeScriptの簡単な練習をしたい感じだったので、ちょうどいい練習になった気がします。

家庭用の清算をGoogle Spreadsheetでやりたい

現在、妻と家賃用口座以外は財布が別なので、定期的に清算をしています。昔のことは忘れてしまうので、清算用のSpreadsheetを作りました。出先で開くのは手間なので、slackからできるといいよねという妻の声がありました。しかし、外部でちょうどいいサーバーを持っていなかったので、一旦話は流れてしまいました…。

slackからSpreadsheetに書き込んでくれる君を作ろう

最近チームでid:daiksyさんがslackでKPTをSpreadsheetに入力できるkpt君(bot)を作っていました。これはGoogle App Scriptで動いているので、外部に自前でサーバーを持つ必要がありません。

これいいじゃん、ということで清算用botも真似させてもらって作りました。1時間もかからずできて快適。KUMAOはうちのぬいぐるみの名前です。

f:id:syou6162:20170320211958p:plain f:id:syou6162:20170320212003p:plain

Script Editorで書くのダルい、自分の好きなエディタで書きたい

簡単にできるようになったのはいいのですが、Google App Scriptのscript editorで書くの、めっちゃダルいです。俺は好きなエディタで書きたいし、gitでコード管理したいし、何ならTypeScriptで書きたいんじゃー、と思っていたところでいいエントリを見つけました。

最高です、IDEAでリファクタリングや定義元に戻るとかもできるようになったので完璧です。できたものも公開しておきます。

自宅のElasticsearchとKibanaをAmazon Elasticsearch Serviceに引越し

例のごとく簡単なことしかやっていないのであまり参考にならないかもしれないですが、アクセスポリシーや自宅からどうやってAmazon Elasticsearch Serviceにデータを流すか、kibanaで閲覧するかは参考になる人がいるかもしれません。前置き終わり。

なぜMac MiniからAmazon Elasticsearch Serviceへ?

約二年前から自分に関連する可能な限りの情報(お金や位置情報、作業時間などなど…)をElasticSearchに放り込み、kibanaで可視化や検索がさっとできるような環境を自宅のMac Miniで運用していました。

そんなわけで二年ほどMac Miniで運用していましたが、以下のような理由で移行を考えてました。

  • Mac Miniも大分古い(5-6年前に買ったやつ)ので、そろそろ買い替えたい
    • SSDではなくHDDなので今となってはつらい。地獄かよ
    • 新卒入社直後だったので、金なしだった記憶がある…
  • ElasticsearchおよびKibanaのバージョンを上げたい
  • 仕事でAWS連携をやっているにも関わらず、個人ではAWSをほとんど使ったことがなく割と(かなり?)まずい
    • 使い勝手とかどういうメトリックが欲しくなりそう、というのは自分もドックフードしてみないと分からない

Mac Miniを新しく買い替えるのが一番無難でコスパも最終的にはよい気がしたのですが、ずっと個人でAWS使ったことないっていうのはどうなのか…というのがひっかかったのでAWS上で運用することにしました。EC2を借りて、そこでElasticsearchやKibanaをインストールして、というのでもよかったのですが、自分の性格的に色々できる環境だと色々やりすぎて本末転倒なことをやりそうな気しかしなかったので、Amazon Elasticsearch Serviceに移行することにしました。

AWSの設定

  • AWSのアカウント作成、クレジットカードの登録
    • MFAを有効化
  • グループの作成
    • Elasticsearchの読み書きができればいいので、AmazonESFullAccessのポリシーのみを持つグループを作りました
    • kibanaもダッシュボート等の情報を保存する必要があるので、readだけなくwriteの権限も必要

Amazon Elasticsearch Serviceの設定

  • Create a new domainで新しいドメインを作る
    • elasticseachのバージョンを選択。新しいのを使いたかったので、5.1を選んだ
  • Configure clusterでインスタンスのタイプを選択
    • elasticseachの5.1を選ぶにはmicroではなく最低でもsmallを選ぶ必要があるということにここで気づく…
  • Set up access policyでアクセスポリシーを選択
    • IPアドレスベースかロールベースかで選べる
    • 自分の場合、自宅や会社からkibanaが見れるといいなと思ったので、ロールで制限した

こんな感じにしておきました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::XXX:user/es-manager"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:ap-northeast-1:XXX:domain/YOUR_DOMAIN/*"
    }
  ]
}

これでElasticsearchやKibanaが立ち上がります。といっても立ち上がってくるまで20-30分くらいかかった気がする。アクセスポリシーを変更してそれが反映されるのも同じくらいの時間がかかるようです。

データを流す先をMac MiniからAmazon Elasticsearch Serviceに変える

自宅のMac Miniでは大体のタスクは

  • jenkinsでjobがキックされる
  • データ取得元からクロールする
  • 取ってきたデータをcurlでElasticsearchに流し込む

といった流れで動いていました(nasne残量の例自宅の回線速度を取る例)。例えばruby speedtest_logger.rb | curl -XPOST localhost:9200/_bulk --data-binary @-のエンドポイントをAWSに向ければ終わり、という予定でいましたが、アクセスポリシーの関連でそのままcurlでやるのは難しそうでした。aws-sdkを使うと対応できそうな雰囲気がありますが、Elasticsearchに流し込むプログラムはbash、ruby、perl、pythonと多岐に渡り(どうしてこうなった…)、流し込むjenkinsのjobも50程度まで増えていたので、困りました…。自宅も固定IP環境ではないので、IPのアクセスポリシーでやると運用が難しい。ここが一番時間がかかった。

先人の知恵を調べたところ、proxyを立てて、そこを通すという手が簡単そうでした。goなので簡単にビルドできる。go1.5じゃないといけないのが面倒といえば面倒ですが、割とすぐできる。

これでlocalhostでAWS上のElasticSearchが見えるようになりました。ruby speedtest_logger.rb | curl -XPOST localhost:9200/_bulk --data-binary @-とやっていたプログラムもポート番号を変えればよいだけなので、簡単に対応できます。これでデータはAmazon ElasticSearch Serviceに流れるようになりました。

kibanaも見れるようになりましたが、しかしちゃんとは動いていないようでした(jsが4xxのエラーを吐いていて管理画面が真っ白)。これについてもnodeでproxyを立てて解決する、というのをdockerに作っている人がいたので、それを使うと動かせるようになりました。

環境変数でawsのkeyを渡します。

docker run -e AWS_ACCESS_KEY_ID=XXX -e AWS_SECRET_ACCESS_KEY=XXX -p 9200:9200 rlister/aws-es-kibana search-XXX.ap-northeast-1.es.amazonaws.com

kibana5だ、わいわい。

f:id:syou6162:20170319151121p:plain

各種情報をMackerelで見れるように

Amazon ElasticSearch Serviceの管理画面からは検索可能なドキュメント数やディスク残量などが分かるようになっています。

f:id:syou6162:20170319151425p:plain

しかし、普段はMackerelのダッシュボードを見るようにしているので、見る画面が増えるのは面倒です。mackerel-agent-pluginsを使って、同じ情報をMackerelにも登録しましょう。

mackerel-agent-pluginsはMacには公式対応していませんが、それぞれのプラグインはMacでも簡単にビルドして使うことができます(正確に言うと使えるものもあります。elasticseachは大丈夫)。GOPATHに移動してbuildするとよいです。

% cd go/src/github.com/mackerelio
% git clone https://github.com/mackerelio/mackerel-agent-plugins.git
% cd mackerel-agent-plugins/mackerel-plugin-elasticsearch
% go build

./mackerel-plugin-elasticsearchで動かしてみるとよいでしょう。これで準備は終わったので、設定ファイル(/usr/local/etc/mackerel-agent.conf)に書きましょう。ひとまずこんな感じで書きました。

[plugin.metrics.elasticsearch]
command = "/Users/yasuhisa/go/src/github.com/mackerelio/mackerel-agent-plugins/mackerel-plugin-elasticsearch/mackerel-plugin-elasticsearch -port=9876"

agentを再起動するとちゃんとメトリックが取れるようになっています。これでディスク残量等も監視できるようになって安心ですね。

f:id:syou6162:20170319151543p:plain

AWS童貞を卒業したので、暇ができたらlambdaでbotを作って遊んだりしてみようと思います。

データベースリファクタリングやデータ移行のタスクの進め方

よくある当たり前っぽい内容ですが、はてなに入る前はあまりやったことがなかったので勉強しながらやっていました(解析器の結果をapiで見せるみたいなことが多かったので、DBそもそもほとんど使っていなかった…)。最近はデータ移行職人業務をやっている。

前提

前提があったほうが説明が書きやすい。is_hogeのようなbooleanなフィールドがhogefugapiyoのようにenumな値を取るように変更が必要という前提で話を進めます。

作戦: 下の層から丁寧にやっていく

一気にやると大変なことになるので、下の層からちびちび進めていきましょう。Pull Requestを送るときに↓のようなやることリストを付けておくと、全体のどの辺をやっているか分かりやすくなるのでレビュアーにやさしい感じになりそうですね。

  • [model層]hogefugapiyoを表わすようなフィールドを追加
  • [DB層]hogefugapiyoを表わすようなフィールドを追加
  • [model層]is_hogeに破壊的な操作(作成/更新/削除)をするときに、hogefugapiyoを表わすカラムにも変更を反映
  • [DB層]is_hogeカラムの状態からhogefugapiyoを表わすカラムの残りを埋める
    • 例: is_hogeがtrueだったらhoge、falseだったらfugaみたいなSQLを発行したり
  • [model層]is_hogeではなくhogefugapiyoカラムのみで値を返すようにする
    • is_hogeカラムには書き込まれなくなる
  • [DB層]is_hogeカラムをdropする
  • [controller層]必要だったらhogefugapiyoの状態を返す、設定するエンドポイントを生やす
  • [controller層]is_hogeを返すようなAPIがあるようだったらhogefugapiyoフィールドも追加して返すようにする
  • [frontend層]APIでis_hogeを見ている箇所を追加されたhogefugapiyoフィールドを見て処理するように変更
  • [controller層]不要だったらis_hogeを返すようなAPIは消す

基本的には

  • 最初は両方に書く
  • ロジックを新しいほうを使うようにする
  • 使わなくなった箇所を消す

というのを隣接する層毎にやっていくとスムーズでした。

知ってる && 試すといいやつ

CASE式

is_hogeカラムに値によってhoge_fuga_typeカラムの値を埋める、みたいなSQLを発行したいとき。boolなので、UPDATEを二回発行してもいいけど、CASE式を使うと一回で書けるのでよい。

UPDATE target_table SET
hoge_fuga_type =
  CASE is_hoge
    WHEN true THEN 0 -- hoge
    WHEN false THEN 1 -- fuga
  END
;

ALTER TABLEにかかる時間を計測

ALTER TABLEに予想しないくらい時間がかかって、サービスに影響が出るというのは避けたいので、backupサーバー等で時間をはかっておくと安心です。トランザクションを貼って、ROLLBACKすれば大丈夫。

hoge_fuga_service=> BEGIN;
BEGIN
hoge_fuga_service=> \timing
Timing is on.
hoge_fuga_service=> ALTER TABLE "target_table" ADD COLUMN "hoge_fuga_type" INT NOT NULL DEFAULT 1;
ALTER TABLE
Time: 82.552 ms
hoge_fuga_service=> ALTER TABLE "target_table" DROP COLUMN "hoge_fuga__type";
ALTER TABLE
Time: 7.523 ms
hoge_fuga_service=> ROLLBACK;

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

続Go言語に入門する

前回はこちら。書いてて楽しいので、地味に活動が続いている。

OSS活動

mackerel-client-go && mkr

mackerel関連のgoのライブラリとツールです。グラフアノテーション機能がリリースされたので、それをmkrで操作できるようにしました。mackerelなので仕事に関連しているのですが、週末に趣味時間でやっていました(Goの練習をしたかったのじゃ!)。

基本的にやることはWebAPIのラッパーなので難しいことはないんですが

  • goでのエラーハンドリング
  • コマンドライン引数周りの雰囲気
  • JSONの取り扱い
    • structを定義してjson decoderに投げればよい

が分かってよかったです。

自然言語処理

もう少し複雑だったりメモリやCPUを使う処理もgoで書いて感覚を掴みたいなと思ったので、次のステップとして係り受け解析器をgoで書いてみることにしました。絶賛WIPです。

Webアプリ

goでのwebアプリも書きたいという気持ちはあるけど、こちらはまだ未着手。既存のものを見たり、どのライブラリがよさそうか見たりしている。

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

データベース関連の最近の話題

最近といっても自分が新しく知ったとか使ってみたという感じのやつなので、全く目新しいやつではない。

PSequel

postgresqlのGUIクライアント。

ないと死ぬわけでもないし普段オペレーションするときはpsqlを使っているけど、テーブルの様子とかを見るのに便利。

  • カラムの定義(Not Nullとかディフォルト値とか型とか)、インデックス、外部キーの様子が一目で分かる
  • テーブルの一覧を絞り込み検索とかできる
  • GUI上でSQLも書ける
  • 好きなクエリをブックマークできる(これは特に使ってない)
  • CUIでもいいけど、何か考えながらやるときはGUIでやっているとやりやすいような気がする
  • めっちゃ複雑なことができるわけではない

トランザクションを張る

これもよくあるやつ(けど、あんまり自分やったことなかった)。更新処理とかをしたいんだけど、UPDATEミスってたら怖いしちゃんと反映されているかSELECTで確認してから正式に反映したい、というときにやる。些細な更新でもペアオペで一緒に見てもらいながらやると安心。

最初にトランザクション開始。

BEGIN;

更新処理をする。SQLをコピペすることが多いと思うけど、末尾のセミコロンを抜いてそこだけ手入力にすると最後に目視で確認するので安全度がちょい増す。

UPDATE hoge SET a = 0

結果を確認。

SELECT ...

よさそうだったら反映。

COMMIT;

ミスってた!!!という場合には反映しない。

ROLLBACK;

ROLLBACK前提で、UPDATEやALTER TABLEがどれくらい時間かかるのか試してみる、という用途でも使われる。時間を計測したいときには\timingとか打っておくと時間を出してくれるので便利。

CASE式

この本を読んで知ったやつ。

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

whereで分けて複数回クエリを発行しなくて済む。まだ読み込み足りていないけど、この本はSQL的世界観でどういうコードを書けばいいかを教えてくれるので結構参考になる。関数型で書くときには手続き型とは違った思考の方法をするけど、SQLを書くときには手続き型ではなく集合的な考えを使うあたり。