DBのデータ量が増えてきた場合の対策の1つとしてユーザIDなどをキーにデータベースを分割するシャーディングと呼ばれる手法があります。これをJDBCのレイヤで実現してしまうsharding-jdbcというライブラリを見つけました。 github.com sharding-jdbcは中国のdangdang（当当）というEC大手企業が開発したOSSで、SQLをパースし、SQLに含まれるシャードキーを抽出して接続先のデータベースや、参照するテーブルを切り替えてくれるというものです。 使ってみる まずはpom.xmlに以下の依存関係を追加します。 <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.4.1</version> </dependency>

昨年から密かに作り続けていたScala WarriorというWebアプリケーションをScala関西 Summit2016にあわせてリリースしました。 github.com これはRuby WarriorにインスパイアされたScala学習用のゲームで、Scalaコードを書いて侍を操作しステージをクリアしていくというものです。 実装にはScala.jsを活用しており、プレイヤーが入力したコードをScala.jsでJavaScriptにコンパイルし、それをクライアントにサイドに返却してブラウザ上で実行しています。エディタではCTRL+SPACEでコード補完、CTRL+Sでコンパイル結果の確認ができます。このあたりのコードはscala-js-fiddleを参考にさせていただきました。 とりあえず動くものをリリースしたというだけでステージ数も少ないのですが、今後少しずつ改善していければと思っています

AWSでは様々な便利なサービスが提供されています。中にはRDSやElasticCacheのように既存のミドルウェアに対するマネージドサービスを提供するものもあり、これらについては既存のミドルウェアを使って開発することができますが、AWS固有のサービスについてはアプリケーションを動作させるには実際にサービスに接続する必要があり、開発環境が制限されてしまいます。 もちろんソフトウェア側で抽象化しておき、DIなどの手法を用いてモックに差し替えるという方法も考えられますが、特にストレージとして利用するサービスなどの場合はインタラクションが必要になるのでモックでは再現しづらいですし、やはり実際に動作するサービスに接続して開発やテストを行うほうが効率的です。 そこで、AWSのサービスを擬似的にローカルで再現することのできるプロダクトを集めてみました。 S3 node.jsで動作するs3-proxyが使

先週の社内勉強会では@tagomorisさんにお越しいただき、ISUCON5で使われたベンチマークツールについてお話しいただきました。 資料も公開していただいています。 Tale of ISUCON and Its Bench Tools from SATOSHI TAGOMORI www.slideshare.net ISUCONで使われるベンチマークツールは アプリケーション以上に負荷をかけきるための性能 アプリケーションの処理結果を検証するための機能 という相反する2つの要件を同居させる必要があるため、既存のベンチマークツールやテストツールを利用できないため毎回スクラッチで開発されているそうです。 今回はhttp_loadを使おうと思っていたけど、一週間前にhttp_loadではセッションが扱えないことに気づいてJavaでjetty-clientやJackson、Jsoupなどを使っ

ScalaのWebフレームワークについて、昨年某所で書いた記事をアップデートしてみました。マイクロサービスが流行ってきたり、Playは2.4になっていろいろ変わったり、ScalaのライブラリやフレームワークもFutureやモナドを活用したものが増えてきたり等々、この一年でScala界隈のWeb開発事情もいろいろと変化してきています。 Play2 出たばかりの頃はPlay 1.x系でできたことができなかったり、バグだらけだったりでコミュニティでも暴動が起きそうになったものですが、喉元すぎればなんとやら、いまでも使いにくい部分も多いのですが、Typesafe社のお墨付きということもあり、なんだかんだでデファクトスタンダードの位置を確立しているのではないかと思います。 ユーザ数が多いだけあり、プラグインや周辺ライブラリ、Web上での情報等も豊富です。 ただ、Play 2.4でGuiceを使ったD

Scalaをどうやって学ぶのがいいのか？ということはScalaを使い始めた数年前からずっと考えています。よく「Scalaは難しい」と言われますが、 どこが難しいのか？ なぜ難しいのか？ ということを、これまで書籍や雑誌記事、ハンズオンなど入門用のコンテンツを作ってきた経験を踏まえて整理してみました。 まず、Scalaが難しいといわれる理由のひとつに学ばなくてはならないものが多すぎるという点があげられます。Scalaはオブジェクト指向言語ですが、関数型言語の特徴的な機能を取り入れているため、きちんと理解するには両方の言語のイディオムを学ぶ必要があるためです。 ただ、Scala自体は必ずしも関数型言語の知識がなくても使えるように設計されています。最初はBetter Javaとして一般的な手続き型オブジェクト指向言語の延長として使い始めることができ、Scalaの特徴的な機能に触れていくことで少し

ScalaでAWSといえば瀬良さんのAWScalaですが、なんとAtlassianが同様のAWS SDKラッパーを出してきました。しかもScalazベース。これは注目せざるを得ない！ https://bitbucket.org/atlassian/aws-scala/overview というわけで早速簡単なコードを書いてみました。S3にファイルをアップロード、ダウンロードするだけのプログラムです。 import java.io.{File, FileInputStream} import com.amazonaws.services.s3.AmazonS3Client import io.atlassian.aws.s3._ val bucket = Bucket("mybucket") val key = S3Key("build.sbt") val location = Content

Slick 3.0がリリースされたので、GitBucketをSlick 3.0にアップデートするべくいろいろ試してみました。 Slick 3.0は別名Reactive Slickというだけあり、これまでとはプログラミングモデルがドラスティックに変わっています。具体的に言うとDBIOActionというオブジェクトを介してデータベース操作の定義と実行が明確に分離されています。要するにMonadicなプログラミングスタイルになっているということです。 他にもReactive StreamsとかOptionサポートの強化などSlick 3.0の新機能はいろいろありますが、一番大きいのはこの点だと思います。 また、DBIOActionの実行は全面的にFutureベースになっています。Playなどと組み合わせて使用する場合、Slickを使った処理があってもAsyncResultで返すことができるように

Reactive Streamsというのはノンブロッキングなback pressure可能な非同期ストリーム処理の標準的な仕様を提供しようというもので、実装としてはAkka Streams、RxJava、Reactor Composable、Ratpackなどがあります。 Reactive StreamsについてはAkkaのコミッタであるKonrad Malawskiさんの以下のスライドがとてもわかりやすいです。 2014 akka-streams-tokyo-japanese from Konrad Malawski ストリーム処理（というか非同期メッセージング全般に言えることですが）では受信側の処理能力を超えるデータを送信し続けるといずれキャパシティを超えてオーバーフローが発生してしまうため、送信側に比べて受信側の処理能力が低い場合は送信側が手加減してデータを送信する必要があります。な

Dockerの日本語書籍が早くも電子書籍で登場しました。 Docker入門 Immutable Infrastructureを実現する 作者: 松原豊,米林正明出版社/メーカー: 技術評論社発売日: 2014/04/25メディア: Kindle版この商品を含むブログ (5件) を見る Kindle版の他に技術評論社さんの直販サイトでEPub版を購入することができます。 https://gihyo.jp/dp/ebook/2014/978-4-7741-6504-2 技評さんの直販サイトはユーザ登録をしないといけないのでこれまでは避けていたのですが、サービスにロックインされるKindleでは可能な限り本は買いたくないし、技評さんの電子書籍は最近Hack本といい面白そうなタイトルが出ているので今後にも期待できそうと思い今回初めて利用してみました。 内容は書籍換算で約70ページとのことでコマンド

昨年亡くなられた高橋信頼さんのコラムを2001年から2013年まで1本ずつまとめたものです。 高橋信頼のOSS進化論（日経BP Next ICT選書） 作者: 高橋信頼出版社/メーカー: 日経BP社発売日: 2014/03/14メディア: Kindle版この商品を含むブログを見る Linuxの普及からFirefoxの登場、Javaでのシステム開発におけるフレームワーク、Ruby on Rails、Seasar2、オープンソースのパッケージ製品、最後の数年は復興支援など世の中に完全にOSSが根付いたことでOSSそのものよりも社会的な部分まで踏み込んだ、2000年代以降の特に国内エンタープライズにおけるOSS事情を追体験できる内容です。 価格もページ数もお手軽ですし、1本のコラムが適度なサイズなので読みやすいです。やはり電子書籍は現状リーダーの使い勝手も含めてこういうコンテンツが向いていると思

その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。 当時僕の参加していたプロジェクトでは、 SQLで書いたら数秒〜数分で済むであろうバッチ処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで

最近仕事でExcel方眼紙を読んだり書いたりするプログラムばかり書いているのですが、そんなExcel方眼紙を支える最新のJava技術を紹介したいと思います。 なにはなくともPOI JavaでExcelと言えば外せないのがPOIです。以前はJExcel APIという対抗馬もあったのですが、Excel 2007に対応していないので現在ではPOIが唯一の選択肢といっていいでしょう。 POIは非常にプリミティブなAPIを提供するライブラリで、使いこなすにはそれなりの修練が必要です。そのため、可能であれば実際の読み書きには後述するXLSBeansやjXLSなどを使った方がよいでしょう。ただし、jXLSのようなテンプレートエンジンでは細かいセルのスタイル設定などはできないため、POIを併用しないとならないケースも多いです。Excel方眼紙を支える技術のベースとして押さえておくべきライブラリといえるでし

html5jえんぷら部、日本Javaユーザグループ主催の勉強会でScalaのWeb開発事情についてお話しさせていただきました。 http://atnd.org/events/42782 以下は発表で使用したスライドです。 JavaからScalaへ from takezoe HTML5とかWeb標準の勉強会だったと思うのですが、発表者の皆さんはほぼ無関係のお話をされていましたw HTML5やWeb標準というとフロント寄りの話になりますが、JavaやScalaという切り口で考えると致し方ないところかなと思います。 ただ、普段のJavaやScalaのイベントと違って客層が事前に読めず、個人的にはScalaと言ってもどういう話をすればいいのか結構悩んでいたので、先に登壇された皆さんのお話を聞きながら話す内容やスライドを微調整して、当初は淡々とPlay2とScalatraの紹介をするつもりだったのを

Scalaで実際にシステム開発を行う上でかなりの高確率で遭遇するのがFunction22問題（またはTuple22問題）です。Scala Conference in Japan 2013のセッションではScalaの問題点として挙げたのですが、実際はいろいろと思うところもあるので書いておきます。 Function22問題（またはTuple22問題）とは？ Scalaのフレームワークではケースクラスへの値のマッピングにタプルを使ったり、値のバインドやアンバインドにapplyメソッドやunapplyメソッドを使うものが多いのですが、Scalaには以下のような制約があるため、22個以上のプロパティを定義することができない、というものです。 22個以上の引数を持つ関数を作ることができない（メソッドとしては定義できますが、変数に代入したり関数渡しをしようとするとコンパイルエラーになります） 要素が22

Scala Conference in Japan 2013で発表させていただいた「使ってわかったScalaのここがダメ！Play2によるシステム開発事例」のセッションで使用したスライドを公開しました。 海外の方も参加されるとのことでスライドは頑張って英語で作ってみました。そんなに難しいことは書いてないので意味は伝わるかと思いますが、おかしなとこがあるのはご容赦ください。 基本スライドでネタ出しをして、要点は口頭で話すという流れだったのでスライドだけ見ても言いたいことがあまり伝わらないかもしれません。いろいろと文句ばかり書いていますが、本当に言いたかったのは個々の問題点がどうこうということではなく、以下の二点です。 Scalaは充分に実用的な言語ですが、Javaと同じ感覚で使うと痛い目を見ることもあるので注意して欲しいということ（新しいものを導入して失敗すると悪いイメージを払拭するのが大変

2月28日(土)に開催されたScala Conference in Japan 2013に参加させていただきました。前日も終電帰りでしたが気合いで朝一のセッションから参加しました（開幕には間に合いませんでしたが…）。 「Up up and Out: Scaling Software with Akka」 TypesafeのJonasさんによるAkkaの概要的なセッションでした。 Akkaの基本的な使い方からRouterやSupervisorといった重要なコンポーネントの説明、アクターを使用したアプリケーションを設計する際の注意点（危険なタスクは死んでもいい末端のアクターでやらせる、防御的なプログラミングではなくクラッシュしてからリカバる）など、このセッションでAkkaに興味を持たれた方が多かったのではないでしょうか。 「Akka を用いたデータストリーム処理・解析プラットフォーム」 サイバ

日経SYSTEMS 2013年2月号にScalaの記事を書かせていただきました。 http://ec.nikkeibp.co.jp/item/backno/OS0238.html この雑誌はそもそも技術者向けではなくマネージャ向けの雑誌だと思います。今回Scalaの記事を書かせていただいたのは、技術的な話というよりもプログラマがScalaを使いたい！と言った場合に上司の方やユーザさんの判断を後押しする材料になれば、と考えてのことです。 業務で新しいものを使う場合「楽しいから」ではなくて何かしらメリットがある必要があります。 で、自分で実際にそこそこのサイズのプロジェクトで使ってみて、Scalaを使うメリットというのは明らかにあるわけです。ただ、そのメリットを第三者にわかりやすく説明するのがとても難しいんです。Scalaはプログラミング言語なのでそれを使って新しいことができるようになるという

いつの間にかGoogle Playで購入できるようになっていました。自分では実物を見ていないので、どんな感じなのかはよくわかりません。キャプチャしたもののようですが、検索とかはできるのかな？ ただこれ、Android端末じゃないと読めませんし、Google Playブックスのリーダーアプリはあまり評判がよくないみたい。できればDRMフリーなフォーマットで電子化して欲しかったなぁ…というのが正直なところです。まあ初めての電子書籍なので記念に買ってみようかな、と思ったのですが、試しに買うにはちょっと躊躇ってしまう価格ですね^^; 雑誌や映画レンタルのようにコンテンツを消費して終わりというサービスであれば端末やサービスにロックインされることによるリスクは低いので試しやすいのですが、技術書のようにそれなりの価格のもので、さらにずっと手元に置いておきたいコンテンツとなるとやはりDRMがかかっているも