今週SIGMODと併催でフィラデルフィアで開催されたDBTest '22というワークショップでトレジャーデータでのTrinoのアップグレード時のテストに関する発表をさせていただきました（自分はリモートで発表させていただきました）。 .@takezoen from @TreasureData is giving the first talk of the day at @Dbtest_io on "Journey of Migrating Millions of Queries on The Cloud" pic.twitter.com/D7zenrHaOI— Manuel Rigger (@RiggerManuel) June 17, 2022 内容的には以前Presto Conference 2020でお話しさせていただいたものとほぼ同様ですが、今回は新たに執筆した以下の論文を元にした発

Good morning, my new workplace! pic.twitter.com/b4jEO3jun8— Naoki Takezoe (@takezoen) 2018年8月1日 Good morning, my new workplace! pic.twitter.com/NZfDYWvHUS— Naoki Takezoe (@takezoen) 2018年8月9日 トレジャーデータに入社したと思ったらいつのまにかArmに入社していました。 何を言っているのかわからないと思いますが、私もよくわかりませんでした。

Today is my last day at BizReach. I learned a lot of things here. Thanks for exciting days over 4 years! pic.twitter.com/wrPANaxbKW— Naoki Takezoe (@takezoen) 2018年7月31日 本日、2018年7月31日をもって4年と4ヶ月勤務した株式会社ビズリーチを退職しました。いわゆる退職エントリというもので、誰得な気もしますが自分の振り返りという意味で書いてみたいと思います。 入社しばらくしてから3年ほどはScalaで作っている新規サービスのバックエンドの開発・運用をやっていました。社の誇るスーパーエンジニアや優秀な若者たちと共に新規サービスの立ち上げというエキサイティングな仕事ができたのは大きな刺激になりました。大人数でのScala開発は

2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。 それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。 1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。 2点目については（ユーザインターフェースに関する権利については諸説あるようですが）、GitBucketが「GitHubク

先日のデブサミ2016でピクシブの川田さんによるモデレートでGolang（メルカリのbokkoさん） × node.js（古川会長） × Scala（わたくし）という謎の組み合わせでパネルディスカッションをさせていただきました。 event.shoeisha.jp ユーザ層や適用領域が異なる言語ということもあり、噛み合うのか若干不安があったのですが、いい感じにまとまったのではないかと思いますw パネルディスカッションのまとめ 総論としては ハードウェアのリソースを使い切るために並行処理がますます重要になっていく ただし、アプリケーションのレイヤではなるべくそれを意識させないことが重要 という当たり前といえば当たり前の話だったのではないかと思います。ECMAScript7のAsync/Awaitは記述は同期的だけどブロックはしないという意味で理想に近いかもしれません。 普通にWebアプリを書

Hacker Newsでこんな記事が流れていました。Hacker Newsでのコメントはこちら。 agateau.com こういう記事でAlternativeとしてGitBucketがあげられるようにならないといけないなぁと思うもののそれはさておき、先日の障害のときのようにGitHubが落ちたら仕事にならなかったりとか、SourceForgeやGoogleCodeの件を見ても今後GitHubのサービスがずっと今の形で継続するという保証はどこにもありませんし*1、さらにGitLabのオンプレ版であるGitLab CEはGitBucketと直接競合するということもあり、機能面を把握しておくためにGitLab.comを試してみることにしました。 GitHubやBitBucketなどのアカウントでログインすることができ、これらのサービスからリポジトリをインポートすることもできます。試しにリポジトリ

その昔、自宅PCにLinuxをインストールして頑張っていた頃はEmacsを使っていたり、その延長で職場でもMeadowやxyzzyなどを活用していたものですが、Eclipseを使い始めてからめっきりEmacsから離れてしまっていました。 ところがここ最近、MacBookを使い始めたり、仕事柄サーバのメンテナンス等でターミナルを使う機会が圧倒的に増えたり、周囲の影響もあったりして久しぶりにEmacsに復帰してみることにしました。Emacsをちゃんと使うのは10年ぶりくらいですが、同僚のEmacserに教えてもらいながら環境を整備してみました。 パッケージをインストールするための準備 最近のEmacsはmeplaというリポジトリからパッケージをインストールできるようです。~/.emacs.d/init.elに以下を書いておきます。 (require 'package) (add-to-list

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

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