ビアバッシュメモ
ピザの量
- 人数÷3枚
- LまたはXL(3000-3500円くらい)
- クアトロ3種類
飲み物
- カクヤス
- ビール、人数×1.5本 (350ml缶)
- お茶、お茶、炭酸、非炭酸
- 当日注文だと冷えてないので前日までに注文できると良い。
お金
- 最初に集める。
- 1人1000円だと足りない。1500円だとおつりがめんどくさい。よって2000円。
- 2000円だとちょっと多いかもしれないので学生や発表者をひいきする。
- 注文の量を増やすなら酒じゃなくて食べ物にしたほうが余らない。
その他
- 紙皿、紙コップ、ウェットティッシュ
- http://d.hatena.ne.jp/hyoshiok/20081017
Typesafe が社名変えたがってる話
mixi 社はいつモンスターストライク社に変わるんだろうという冗談を言っていたら、なんと Typesaefe 社が社名を変えたいと言い始めました。最初エイプリルフール的なものかと思いましたが、冗談じゃないようです。冗談じゃないよ。
May 18, 2015 | What’s in a name? | Typesafe
自分は Typesafe 社の人間ではないし、人様の会社の社名変更に口を出すとかも変な話ですが、open process だ、意見をくれと言われたらそりゃ嫌って言うよ、だってめんどくさいもん!!
実際typesafeの社名とか全く興味ないしopen processとか言ってるけど反対多くても変えるんでしょ。自由に変えてもらってもいいけど、自分としてはめんどくさいだけでメリットないから意見ないかって聞かれたらそりゃ反対って言うよ、って感じ。
— Toshiyuki Takahashi (@tototoshi) 2015, 5月 21
具体的に何がめんどうか、については瀬良さんのツイートをご覧ください。
Renaming #typesafename will be a burden to Scala community, e.g. ivy repo, groupId and out-dated docs. Please put OSS community first.
— Kazuhiro Sera (@seratch) 2015, 5月 20
↓ というわけで便利なボタンを設置しました。ご利用ください。
WEB+DB Press 86 に PHP での画像処理についての記事を書きました
4/23 発売の WEB+DB Press Vol.86 に PHP での画像処理についての記事を書きました。 画像をこねくり回すという内容ではなく、Web アプリで画像を扱うときに気にするべきことを広く浅くカバーしようという内容です。基本的な Imagick (imagemagick) の使い方から、有名な最適化 Tips、それからジョブキューを活用した負荷対策や、サムネイルの動的生成などについて実際に pixiv で使われている技術をベースに解説しています。PHP に限らずこれから画像を扱うシステムを作ろうとしているけれど、ちょっと自信がないなあという人にはおすすめの内容です。是非手に取ってみてください。
- 作者: 結城洋志,沖元謙治,足永拓郎,林健太郎,大竹智也,内田誠悟,伊藤直也,中山裕司,hiroki.o,泉水翔吾,佐藤太一,高橋俊幸,西尾泰和,舘野祐一,中島聡,橋本翔,はまちや2,竹原,麻植泰輔,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/23
- メディア: 大型本
- この商品を含むブログを見る
Slick のコードを生成する sbt プラグインを作りました
Slick コードを生成のイブラリがあり、公式のほうにいくつか使い方のサンプルがありますが、毎回コピペするのもなあと思って sbt プラグインにしました。今のところ Slick 2.1.0 に依存しています。Slick 3.0.0 が出たらそれ用のバージョンも出そうと思います。
インストールは plugins.sbt に addSbtPlugin を加えた上で、コード生成に使う JDBC ドライバを追加します。
// plugins.sbt addSbtPlugin("com.github.tototoshi" % "sbt-slick-codegen" % "0.1.0") // Database driver // For example, when you are using PostgreSQL libraryDependencies += "org.postgresql" % "postgresql" % "9.4-1201-jdbc41
build.sbt の設定は以下のような感じです。
// build.sbt import scala.slick.codegen.SourceCodeGenerator import scala.slick.{ model => m } // required slickCodegenSettings // required // Register codegen hook sourceGenerators in Compile <+= slickCodegen // required slickCodegenDatabaseUrl := "jdbc:postgresql://localhost/example" // required slickCodegenDatabaseUser := "dbuser" // required slickCodegenDatabasePassword := "dbpassword" // required (If not set, postgresql driver is choosen) slickCodegenDriver := scala.slick.driver.PostgresDriver // required (If not set, postgresql driver is choosen) slickCodegenJdbcDriver := "org.postgresql.Driver" // optional but maybe you want slickCodegenOutputPackage := "com.example.models" // optional, pass your own custom source code generator slickCodegenCodeGenerator := { (model: m.Model) => new SourceCodeGenerator(model) } // optional // For example, to exclude flyway's schema_version table from the target of codegen slickCodegenExcludedTables in Compile := Seq("schema_version")
sourceGenerators in Compile
に加えることでコンパイルの前にコード生成が走ります。この設定では毎回コード生成が走りますが、毎回同じファイルが生成されるため、再コンパイルされることはありません。コード生成自体の時間が気になる場合は slickCodegen
タスクにキャッシュを入れればよいと思います。sbt の FileFunction.cached
とか使えば簡単に実装できると思います。
デフォルトでは Slick の SourceCodeGenerator
によりソースコード生成が行われますが、以前このブログにも書きましたが、java.sql.Timestamp
じゃなくて joda-time を使いたい、などということがあると思います。そのときは slickCodegenCodeGenerator
にカスタマイズした SourceCodeGenerator
を設定します。
slickCodegenCodeGenerator := { (model: m.Model) => new SourceCodeGenerator(model) { override def code = "import com.github.tototoshi.slick.PostgresJodaSupport._\n" + "import org.joda.time.DateTime\n" + super.code override def Table = new Table(_) { override def Column = new Column(_) { override def rawType = model.tpe match { case "java.sql.Timestamp" => "DateTime" case _ => super.rawType } } } } }
データベースマイグレーションと共存させる
本編ここから。Slick に限った話ではないですが、すでにデータベースにあるテーブルを使ってコード生成を行うという仕組みは、データベースマイグレーションツールとの相性が非常に悪いです。play-evolutions や play-flyway は Play アプリケーションの起動時にデータベースマイグレーションを行うため、コード生成とマイグレーションがデッドロックしてどうしようもありません。
今のところは dev-mode のデータベースマイグレーションは play-flyway ではなく、Flyway の sbt プラグインを使うことで回避しています。テストのときなどの Slick のコード生成が終わった後では play-flyway も使えるようになります。ちょっとダサい気がしているけれど、追加する設定も少ないし、まあ良いかという感じです。sbt ではなく Flyway のコマンドラインツールを使うというのでも良いと思います。
困ったことに Flyway の sbt プラグインを使ったからといってこの問題とさよならできるわけではありませんでした。実はこのプラグインもコンパイルの後にマイグレーションを走らせる作りになっているため、Flyway 用に別の空プロジェクトを使って、そこでマイグレーションを行う、というようにしました。flyway
という空プロジェクトを作ったら、マイグレーションは flyway/flywayMigrate
というコマンドで実行できます。
設定を見てもらうのが早いと思うので、サンプルプロジェクトにまとめて置きました。
回避に回避を重ねましたが、最終的な設定としては一応理解可能なレベルにまとめられたのではないかと思います。最初はサブプロジェクトで FakeApplication を使って無理やり Play.start してマイグレーションを走らせて...みたいなことをしていた(意味わかるでしょうか)のですがそれよりはずっと良いと思います。
退職しました
ピクシブを退職しました。 主に健康上の理由です。 (在宅勤務もさせてもらって、おかげさまで最近やっとよくなってはきましたが。) 退職はしましたが、4月からはフリーランスっぽい感じで仕事を続けます。
ピクシブに転職したのは、なんか楽しそうと思ったからなのですが、 実際とても楽しく過ごすことができました。
// TODO ここにいいことを書く
仕事はバックエンドの改善、課金周り、画像のアップロード、ストレージの移行、APIの移行などをやっていました。1年半で 99784 行のコードを追加し、251930 行のコードを削除しました。
今後は業務委託という形で今の仕事を継続する予定ですので、 次の WEB+DB PRESS で私がピクシブの連載を担当していても不思議に思わないでください。
基本リモートでよければ、他の仕事を受けることも可能です。 技術要素にはこだわらないですが、Play/Scala が得意分野です。 Play 導入してみたけどよくわからんぞなどとお困りでしたら呼んでください。 仕事がなければアルパカ牧場でも始めようと思います。
ピクシブのみなさん本当にありがとうございました。4月からもよろしくお願いします。
個人/社内 Maven Repository を作る
オープンソースの Scala ライブラリは sonatype を経由して Maven Central にデプロイするのが定番となっています。Maven Central のアカウントを持っていない、とかクローズドにしておきたい、などの理由から自前で Maven リポジトリを持ちたくなることがあるでしょう。
Maven リポジトリはなんとなくセットアップが面倒そうに思われていそうですが、実際には Web サーバ上にルールに従ってファイルが配置されているだけです。Artifactory や Nexus などの管理ツールもありますが、それらをインストールしなくとも簡単にセットアップが可能です。
例えば、gh-pages をリポジトリにしている人はたまに見かけます。自分も Sonatype のアカウントを作る前はそうしていました。それから svn リポジトリに jar を突っ込み、それを web 上に公開している人もいます。そういう風にリポジトリを公開するには、まず自分のローカルに Maven リポジトリを作り、それをアップロードする、という手順を踏みます。
自分のローカルにリポジトリを作るのがめんどうな場合は、WebDAV や scp を利用して、直接 Web 上のリポジトリにライブラリをデプロイすることも可能です。今回は WebDAV を使うことにしました。
まずは Web サーバの設定です。これは簡単で、WebDAV を有効にするだけです。Apache であれば次のような設定となります。 http://mvnrepo がリポジトリの URL です。
<VirtualHost *:80> Servername mvnrepo DocumentRoot /var/www/mvnrepo DavLockDB /var/lock/apache2/DavLock DAVMinTimeout 600 <Location /> DAV On </Location> </VirtualHost>
リポジトリができたら、リリース用のディレクトリとスナップショット用のディレクトリを切りましょう。 例えば、リリース用のディレクトリは http://mvnrepo/releases, スナップショット用のディレクトリは http://mvnrepo/snapshots という風にします。
次に、build.sbt に設定を追加します。
// Maven スタイルでデプロイする publishMavenStyle := true // テストは含めない publishArtifact in Test := false // 他のリポジトリのライブラリに依存することを許容する設定 pomIncludeRepository := { _ => false } // リポジトリの設定 // SNAPSHOT バージョンであれば、http://mvnrepo/snapshots に // リリースバージョンであれば、http://mvnrepo/releases にデプロイする publishTo := { val inhouse = "http://mvnrepo/" if (version.value.trim.endsWith("SNAPSHOT")) Some("inhouse snapshots" at inhouse + "snapshots") else Some("inhouse releases" at inhouse + "releases") }
他に pomExtra の設定などもありますが、Maven Central ではないのでなくてもデプロイできるので割愛します。
さて、これであとは publish コマンドを打つだけですが、一つ問題があります。 sbt の問題か、sbt が依存するライブラリの問題かはわかりませんが、デプロイをするとき、パスの途中のディレクトリを作ってくれないのです。たとえば com.example という group_id で hello というライブラリの scala 2.11.x 用のバージョン 0.1.0 をデプロイしようとすると、その配置ディレクトリは /releases/com/example/hello_2.11/0.1.0/ ですが、このディレクトリを作る処理をせず、いきなりファイルを配置しようとするため、エラーが発生してしまいます。
これを避けるためには、自分で WebDAV の MKCOL リクエストを送る必要があります。もしくは Apache ではなく nginx を使って、create_full_put_path の設定を on にします。
今回は諸事情により、Apache を使うことになったので、自前で MKCOL を打つことになりますが、そんなことはやってられないので、解決策を探したところ、webdav4sbt という sbt プラグインを見つけました。このプラグインをインストールすると、sbt が publish の前に MKCOL リクエストを送ってくれるようになります。
しかし残念ながらこのライブラリはメンテナンスされておらず、ダウンロードもできない状態だったので Fork しました。scala 2.11 対応させ、名前も sbt-automkcol という風に変えました。
https://github.com/tototoshi/sbt-automkcol
注: 以下、情報が古くなっているのでGitHubのREADMEを参照してください
project/plugins.sbt に
addSbtPlugin("com.github.tototoshi" % "sbt-automkcol" % "1.5.1")
build.sbt に
import com.github.tototoshi.sbt.automkcol.Plugin._
AutoMkcol.globalSettings
と設定してください。
Apache の認証情報は ~/.sbt/0.13/build.sbt に書きます。
credentials += Credentials("inhouse maven repository", "mvnrepo", "user", "password")
これで Apache の場合でもデプロイができるようになります。
Maven リポジトリのセットアップ方法を紹介しましたが、オープンソースのライブラリであれば sonatype のアカウントを手にいれるなどして、Maven Central へデプロイすることを強くお勧めします。野良リポジトリの多くはいつのまにか管理されなくなり、ライブラリがダウンロードできなくなっているというのをよく見かけるからです。今回 Fork した webdav4sbt もリポジトリがなくなっていました。その点 Maven Central にデプロイすれば削除できないのでライブラリが消えることもありませんし、sbt に resolver の設定を追加する必要もありません。