AzureのCosmosDBをREST API経由で操作するPHPライブラリを作った

AzureのCosmosDBを使ったあれこれを作る過程で、CosmosDBのRESTAPIを叩くPHPライブラリが必要になったので作りました。

あんまり特別なことはしていないくて、ほんとにただRest APIをラップしたものです。

github.com

インストール

composer.jsonにarakaki-yuji/cosmosdb-clientを追加してください。

{
    "require": {
        "arakaki-yuji/cosmosdb-client": "^0.0.5"
    }
}

使い方

初期化

$client = new \CosmosdbClient\CosmosdbClient($cosmosdbSecretKey, $cosmosdbAccountName);

Databaseの操作

// create database
$client->database->create('database_id');

// list database
$client->database->list();

// get database
$client->database->get('database_id');

// delete database
$client->database->delete('database_id');

Collectionの操作

// create collection
$indexingPolicy = ['indexingMode' => 'lazy'];
$partitionKey = ['paths' => ['/Name']];
$client->collection->create('database_id', 'collection_id', $indexingPolicy, $partitionKey);

// list collection
$client->collection->list('database_id');

// get collection
$client->collection->get('database_id', 'collection_id');

// replace/update collection
$client->collection->replace('database_id', 'collection_id', $indexingPolicy, $partitionKey);

// delete collection
$client->collection->delete('database_id', 'collection_id');

Documentの操作

// create document
$doc = [
    'id' => 1,
    'name' => 'Yuji Arakaki',
    'email' => 'example@test.com'
];
$partitionKeyValue = $doc['name'];
$client->document->create('database_id', 'collection_id', $doc, $partitionKeyValue);

// list document
$client->document->list('database_id', 'collection_id');

// get document
$client->document->get('database_id', 'collection_id', $doc['id'], $partitionKeyValue);

// replace/update document
$client->document->replace('database_id', 'collection_id', $doc, $partitionKeyValue);

// query document
$query = "SELECT * FROM c WHERE c.name = @name";
$parameters = [['name' => '@name', 'value' => 'Yuji Arakaki']];
$client->document->query('database_id', 'collection_id', $query, $parameters);

// delete document
$client->document->delete('database_id', 'collection_id', $doc['id'], $partitionKeyValue);

良いデザインかどうかはさておき、APIのラッパーは筋力さえあれば誰でも作れる。

ありがとう、ハッカーズチャンプルー! ハッカーズチャンプルー2019のコアメンバーとして運営 & Paykeとしてスポンサーセッションしてきました!

今年もハッカーズチャンプルーのコアメンバーとして運営と、あとスポンサーセッションでの登壇もしてきました!

hackers-champloo.org

ツイートのまとめはこちらから。 今年もすごいツイート数で、すべてを見るのに数時間かかりそう。。。

togetter.com

Paykeとして、スポンサーセッションでの登壇

今年は僕の所属するPaykeとしてハッカーズチャンプルーのスポンサーにも参加させて頂き、今回スポンサーセッションを行いました。

登壇内容はこちらになります。

スポンサーセッションは初めて行ったのですが意外と登壇内容に気を使うということに今回始めて気が付きました。

ただ技術の話をしても良かったのですが、せっかく沖縄のエンジニアが数多く聞いてもらえる機会なので、Paykeという会社についも興味を持ってもらいたい。

しかし、ただ会社紹介をしても興味を持ってもらえないだろうし、自分自身も話をしておもろしくない。

そこで自分が日頃考えていて熱量持って話せるハッカーズチャンプルーとエンジニアコミュニティへの感謝の気持ちと、会社紹介を交えるエモい登壇となりました。

最後は時間切れの指笛がなってしまいましたが、なんとか一番伝えたいメッセージまでは届いたので良かったですw

アメンバーとしての準備「スタッフ・登壇者用イベントTシャツ制作」

僕の今イベント準備における最大のミッションは「スタッフ・登壇者用のイベントTシャツの制作」だったのですが、沖縄に新たに生まれたデザイナーコミュニティ「D#(ディーハッシュ)」の緑間さんと外山さんのご協力により最高に可愛いスタッフTシャッツが出来上がりました!

f:id:arakaji-yuu:20190702102230j:plain
スタッフTシャツ

ハッカーズチャンプルーの「ゆるさ」と、沖縄感を出すための紅型色のシーサーがかわゆいやつです^^

こんな素晴らしいデザインを作れる人たちが運営するデザイナーコミュニティ「D#(ディーハッシュ)」ではデザイナー向けのイベントをよく行っていますので、デザインに興味のあるエンジニアの人たちはぜひ参加してみると楽しいと思います!

twitter.com

参加者としての感想

今回もハッカーズチャンプルーらしく、様々なテーマ、様々な技術の話が聞ける、非常にチャンプルーなイベントなって面白かったです。

最初のメインスピーカーであるdeeeetさんが「開発者向け基盤をつくる」という話でマイクロサービスアーキテクチャでプロダクトを作るために基盤がなにを提供するかという高レイヤーの話をしたかと思えば

speakerdeck.com

次のメインスピーカーhikaliumさんは「現代のコンピュータにおける自作OS事情」と一気に低レイヤーに話が移り、

docs.google.com

「高低差ありすぎて耳キーンなるわ!」というツッコミが会場中を響いたとかいなかったとか。

続いてメインスピーカーちょまどさんの「すきなことをやるということ」で、ちょまどさんのキャリアを通じて「好きなことを夢中になってやることが、今はわからなくても、きっと未来につながる」というメッセージがあり、

次のメインスピーカー、Doorkeeperの開発者でもあるポールさんの「サイドプロジェクトが利益を生むビジネスになるまでの苦労と長い道のり」のセッションでは、素晴らしいプロダクトを作り、たくさんの人に利用されていたとしても続く苦労と成功までの長い道のりが話されていて、本当に涙なしには聞けないセッションとなりました!

このセッションの終了後の@k_nishijimaさんのツイート、みんなお金を払おうな!

最後のメインスピーカーであるgongozさんの「What can Emacs be ?」というセッションでは、まさに「好きなことを夢中になってやる」を地でいくEmacs でメディアプレイヤーを作ったり、ファミコンエミュレータを作ったりした話が展開され、会場中が爆笑と感嘆の渦に巻き込まれました。

speakerdeck.com

LT勢も素晴らしく、最初にりゅうさんの「JavaScriptで黒魔術」という記号だけで好きな文字を出力するという謎技術が披露されたと思えば

speakerdeck.com

ちょまどさんのメインセッションのあとにLTを行ったいわむーさんは、「では皆さん、ちょまどさんのセッションでの興奮を落ちつけるためにヨガをやりましょう」といってLTの貴重な1分半をヨガ費やしたり(ちゃんとLTのフリになっていた)

「ラズパイでギターをつくる」というLTでギター経験者が泣いて喜ぶ楽器?をラズパイで作ったことを話したかと思えば

www.slideshare.net

沖縄に住む、本物の黒魔術士ことtompngさんの「意味不明プログラミングの世界」で発表された「実行可能な画像ファイル」という、最早一つのアート作品と言える作品に会場中が拍手喝采に包まれました。

メインセッション、LT、スポンサーセッションまで含めてすべての登壇者が素晴らしい発表をしてくださり、その内容を本当に楽しく聞いてくれる素晴らしい参加者の皆さんが来てくれ、それを運営のみんなで支える事ができた本当に素晴らしいイベントになったと思います!

ありがとう、ハッカーズチャンプルー!

SQLマイグレーションツール「mig」に、同名のテーブル、カラム、インデックスを作成しようとしたというエラーの場合はマイグレーションをスキップするというオプションを追加しました。

以前ブログでも紹介したこともある、PHP製のシンプルなSQLマイグレーションツール「mig」ですが、こちら社内のDBマイグレーションツールとして絶賛使用中で、実は地道にバグフィックスや機能追加を行っています。

arakaji.hatenablog.com

その中で、メンバーからの要望があり追加した機能について紹介します。

同名のテーブル、カラム、インデックスを作成しようとしたというエラーが出た場合マイグレーションをスキップするオプション「skip-duplicate-and-exists-errors」

migでマイグレーションSQLファイルを作成するとファイル名のプレフィックスとしてタイムスタンプが付与され、マイグレーションを実行するとそのSQLファイルのタイムスタンプがmigrationsテーブルに追加されます。 マイグレーションを実行するときには、このテーブルのレコードを見て実行していないSQLを判断し実行しています。

しかし、例えばどこかの環境のDBのSQLダンプを取得してそれを実行して作ったDBの場合、そのSQLダンプ内にmigrationsテーブルが含まれていなければすでにテーブルやカラム、インデックスが作成されているのにそれらを作成をするSQLを実行しようとしてエラーが発生します。

マイグレーション実行時に「skip-duplicate-and-exists-errors」というオプションをつけると、同名のテーブル、カラム、インデックスを作成しようとしたというエラーの場合は、このマイグレーションSQLは実行したものとみなしてmigrationsテーブルにレコードを追加してスキップするという機能を追加しました。

$ mig-cli migrate skip-duplicate-and-exists-errors

なぜ追加したのか?

うちの開発チームではmigの利用は開発環境に限定していて、本番環境へは手動でSQLを実行しています。

理由はソースコードの変更と違い、DBへの変更はパフォーマンスへの影響も大きく実行順番やタイミングの調整も行いたいため、あえて手動で実行しています。

つまり、本番DBにはmigで使うmigrationsテーブルがありません。

以前「Paykeの技術基盤チームの取り組み」という内容で発表をしたこともあるのですが、Paykeでは開発環境にもほぼ本番同等のデータを使うようにしているため定期的に本番に類似したデータのdumpファイルを取り込んでいます。

speakerdeck.com

そのたびにmigrationsテーブルと実際の各テーブルの構成が変わってしまい、migで不要なエラーが発生してマイグレーションが進まないという問題が発生しておりました。

この問題を解決するため、「skip-duplicate-and-exists-errors」というオプションを追加することにしました。

ソフトウェアは使うと磨かれる

migは小さなソフトウェアですが、ホントに自分たちのユースケースとして必要だから開発して、それを実際に利用し、そのフィードバックをもとに少しづつ改善しています。

実際に自分で使ってみるだけだと今回のような機能は思いつかなかったですが、実際チームで使うなかでフィードバックがあって開発することができました。

この機能以外にも、一つのSQLファイルに複数のSQL文が入っていても実行できるようにしたり、SQLファイルの最後に複数の改行が入っている実行に失敗してしまうというバグを修正したりと、地味だけど着実に改善しています。

やはりソフトウェアは開発してリリースするだけだとだめで、実際使われてフィードバックを得ないと磨かれていかないのだと実感しました。

migはおそらくうちの社内だけで使っているソフトウェアですが、いつか世界中の人に使われて自分の名刺代わりになるようなソフトウェアを作っていけるように今後もコツコツやっていきます。

個人プロジェクトとして開発したWebサービス「Collabo」をOSSとして公開しました。

タイトルで言いたいことはすべてなのですが、去年個人プロジェクトとして開発していた「Collabo」というWebサービスGithub上でOSSとして公開しました。

github.com

公開時のブログはこちらです。

arakaji.hatenablog.com

なぜ公開するのか?

公開する理由ですが、簡潔いうと「けじめ」をつけるためです。

Collaboは自分が仕事以外で初めて自分一人で開発して公開まで行ったプロダクトで思い入れもあるのですが、結局自分自身もほとんど使っていないプロダクトになってしまいました。 自分が使わないので、そもそも人に使ってもらえないですし、開発も滞っています。 そのままただプロダクトとして死んでいくなら、せめてソースコードぐらいは公開することで自分のポートフォリオにしようと考えて公開することにしました。

自分のClojureで書いた初めてプロダクトとしてソースコードを公開し、一区切りをつけたいと思います。

Collaboの開発で学んだこと

モチベーション維持の難しさ

リリースまではなんとかがんばれたのですが、リリース後はやりきった感が出てしまってなかなか次の開発に進むことができませんでした。

以下にも書くのですが、自分自身が実際に使うプロダクトにしないとやはり改善をし続けるモチベーションを維持するのは難しかったです。

すでに代替サービスが有る場合、自分のプロダクトでも品質悪ければ使わない

Collaboはだれでもプロジェクトを作成して公開し、そのプロジェクトのイシューを管理することができるサービスです。 しかしプロジェクト管理サービスは他にも代替サービスが無数にあり、そのどれもが数年前から存在していて品質が磨かれているものばかりです。

最初は自分のプロダクトをリリースしたらドックフーディングしながら改善していこうと思っていたのですが、自分のプロダクトでもリリース時点で既存プロダクトよりも使い勝手がよくないと自分ですら使いたくなりませんでした。

やはりせっかく作るのであれば、せめて自分だけでも「このプロダクトは他のプロダクトよりも優れている!」と信じられるものにしないといけないなと学びました。

次の個人プロジェクトについて

次は「単機能でシンプルだが代替サービスのない、もしくは代替サービスをよりも自分は優れていると信じられるプロダクト」を目指して開発したいと思います。

やっていくぞ!!!

2019/02/02に行われた「沖縄・宜野湾エンジニア勉強会 #6 in ギークハウス沖縄」に参加して、「Paykeの技術基盤チームの取り組み」というタイトルで発表してきました

タイトルどおりなんですが、2019年2月2日にギークハウス沖縄で行われた「沖縄・宜野湾エンジニア勉強会 #6 in ギークハウス沖縄」に参加して、「Paykeの技術基盤チームの取り組み」というタイトルで発表してきました。

もう結構時間あいちゃっているんですが、自分のためのログとしては残しておきたいのでブログを書いてます。

ginowan.connpass.com

去年はコミュニティへの参加は控えていたんですが、今年はやっていくぞ!という目標も立てていたので、発表にも応募。 2018年10月から技術基盤チームを設立して、約4ヶ月程度チームで取り組んできたことを整理して発表してきました。

発表資料はこちら。

他の登壇者の方もかなり面白くて、エンジニアの生存戦略、資本主義ゲームの戦い方、Web技術で定規を作ったり、JSの仕様を駆使した黒魔術を披露したり、K8sの話があったりと盛りだくさんの多種多様な話があり、最高に面白かったです。

登壇資料をまとめてくださっているので、ぜひ見て下さい。

ginowan.connpass.com

あと何より良かったのはギークハウスのコーヒーが美味かったのとWifi環境が爆速だったことですね!

2次会には諸事情で参加出来なかったのが残念でしたが、トータル最高に楽しかったです。

ありがとうございましたー!!

「沖縄のスタートアップ企業で働くエンジニアのリアル」というイベントでパネルディスカッションに参加してきました。

主催の方からご連絡を頂き、「沖縄のスタートアップ企業で働くエンジニアのリアル」というイベントでスタートアップで働くエンジニアの一人としてパネルディスカッションに参加してきました。

re-build.connpass.com

30人もの参加者に来て頂き、沖縄の中でスタートアップでエンジニアとして働くという注目度が高くなっていると実感しました。 参加者には現在エンジニアとして働いている方と、プログラミングスクールなどを出てこれからエンジニアとして働きたいと思ってスタートアップに興味を持った方が大体半々くらいいる感じでした。

パネルディスカッションでは事前にテーマが設けられており、それに関して話していく、その中で会場からの質問があれば答えていく構成になっていました。

このブログでは僕が回答した内容をまとめておこうと思います。

パネルディスカッション

大手企業とスタートアップ企業の違い

僕の場合は前職も入社したとき社員が約15名程度だった会社がその後70名まで成長したようなベンチャー企業で、今回も10名いないくらいのときに入社し現在40名以上に成長しているスタートアップ企業なので、まず大手企業のことを知らないという前提で話を聞いてほしい。

僕の場合スタートアップ企業の大きな特徴はその変化の速さだと考えていて、エンジニア目線でも求められるもとがどんどん変化していく。

たとえば立ち上げフェーズであればそもそもそのプロダクト自体が世の中に受け入れられるかわからない状態なので、品質よりも速く開発してリリースすることが求められる。 ある程度受けいられるということがわかり投資を受け、エンジニアの数も増やすフェーズになれば開発自体はもちろん高速で進めつつも、品質を高めることやチーム開発のための体制を整えることも必要になってくる。 さらにチームも増えたり会社としてデータドリブンな意思決定をしていくためにデータ分析のための基盤を整えたり、継続的な開発を行えるようにミドルウェアフレームワークのアップデートを継続的に行うため体制や仕組むを作るなども求められる。

このような変化が1年や半年どころか3ヶ月単位のレベルでやってくるのが、変化のスピードが早いスタートアップ企業の特徴だと思う。

なぜスタートアップ企業を選んだか?

転職活動中に今の会社以外からも複数社からオファーがあり話を聞いていたが、自分が入ることで最も価値を発揮できる、成長を加速させることができる会社を選んだ。

僕が入るときは次の投資が決まる前だったので、可能性としては入社して3ヶ月後には潰れるという可能性もあるとは思っていた。 ただ僕が入ることでプロダクト開発を加速させ、エンジニア組織を強化し会社としてもプロダクトとしての価値も上げられると考えたのでいまの会社に参加することを決めた。

エンジニアとしての成長はあったか?

会社の成長・変化の早さに合わせて、エンジニアに求められるものも変わりそれに答えているうちに成長出来ていたと思う。

いまも開発組織をスケールさせていくために技術基盤チームのプレイングマネージャーとしてエンジニアリングとマネジメントの両方で様々な仕事を行っているので、さらに成長できると考えており楽しみ。

親や周りの反対はなかったのか?

仕事を辞めるのも決めるのも基本的に自分判断で親への相談とかは特に問題なかった。

結婚しているので嫁ブロック的な話もあると思われるが、うちの場合は嫁も同じスタートアップ企業で働いているので、全く問題ない。

給与的には入社時は会社自体がお金のない時期だったこともあり前職のときよりも給与を下げて入社したが、いまはもうその額は超えている。

実際、残業は多いのか?

スタートアップやベンチャーの特にITは残業が多いイメージが強いと思うが、今の会社の場合はゼロではないがかなり少ない。

アプリやその他のバックエンドシステムをリニューアルをしたときには残業が発生してかなり忙しい時期もあるが、平均的には残業せずに定時で帰っている。僕らの場合既婚者や子供がいる社員が最初の10~20名程度のときからいたため、働き方の健全性も高いし、自分たちの状況に合わせて柔軟にリモートワークをしたりすることも普通なのでかなり働きやすい。

沖縄で就職する理由

子供も生まれたこともあり、子育ての環境として実家がある沖縄は快適なのでそのまましばらくは沖縄で働きたい。 ただ、単純にエンジニアとしての成長ややりがいだけを見たら東京の方がコミュニティも面白い会社も多いので東京に行くのが最適だと思う。

自分が楽しくエンジニアとして生きていくために必要なのは良質で多様なエンジニアコミュニティと高い給料が払えつつかつ面白いプロジェクトをしている会社とそこに集まってくる優秀な面白い人々だと思っている。

沖縄で快適に子育てしつつ、そのエンジニアとしての環境を自分で作っていけるようにコミュニティ活動をしたり、今入っているスタートアップ企業を成長させて高い給料がはらえつつ面白いプロジェクトをしている会社にしていこうと思って沖縄で活動している。

会場からの質問

沖縄のコミュニティや会社などエンジニアを取り巻く状況の課題はなんだと思いますか?

僕は沖縄以外の場所でエンジニアとして働いたことはないが、コミュニティ運営などを通して知り合った県外のエンジニア方々の話や僕の肌感覚としては、沖縄はエンジニアのコミュニティも活発だし優秀なエンジニアも多い。しかしそこで育った優秀なエンジニアがその価値を発揮したり更に成長できるようなプロジェクトを持った会社が少ないし、その価値に見合った給料を払える会社も少ない。

そのため沖縄のエンジニアとしてのキャリアパスがある一定のレベルを超えるとフリーランスになるか東京の会社に転職するしかない。

その課題を解決するために、僕はスタートアップの中で会社を成長させ、優秀なエンジニアに見合った給料とプロジェクトを提供出来る会社を作ろうと活動している。

スタートアップに入社したいと思っているが、そういう会社にどうやったら出会えるか?

エンジニアとして成長するための活動を活発に行っていればいいと思う。ここで言う活動とはOSSや自分のソフトウェアを開発して公開したり、コミュニティに参加して運営したり登壇したり、ブログを書いたりすることです。

僕らが会社を探すよりも遥かに強いモチベーションでスタートアップに限らずソフトウェアを扱う会社はエンジニアを探している。そういう会社は必死に探すので、上記のような活動をしっかり行っていれば比較的容易に出会えるようになると思う。

さいごに

去年は初めての子供が生まれたという状況だったのでコミュニティ活動はセーブしていたんですが、今年はより活動を増やしていこうと考えていました。 その状況で声をかけていただいたので喜んで参加したのですが、沖縄でスタートアップのエンジニアというものに興味がある人がこんなにいたことに驚きました。

また「私もスタートアップでエンジニアとして働きたいと思っている」というプログラミングスクールという方もいました。

その方々とTwitterでつながると作品として普通に面白いアプリを作っている方もいたので、いままでは経験者の採用のみに絞っていたのですが、これからはまだ業務経験はないが1年程度で会社のアベレージを超えていけそうな人を採用していくというのも全然ありだな〜と考え直す良いきっかけにもなりましたし、僕も刺激になってより一層頑張っていこうと思えるきっかけになりました。

イベントを主催してくださった方々や会場提供してくれた方々、一緒にパネルディスカッションに参加してくれた方々に参加者の方々も皆さんありがとうございました。

AWSユーザーにも知ってほしい、Azure Web AppがWordPressを乗せるのに最高という話

Azure Web Appとは

Azure Web AppとはAzureが提供しているPaaSの一つです。 その名の通りWebアプリを乗せるために適したPaaSで、負荷分散や自動スケーリング、またGit等を利用した継続的デプロイなどの機能も提供しています。

対応している言語が2019/1/20現在で以下のようになっています。

f:id:arakaji-yuu:20190120182551p:plain

WordPressをPaaSに乗せる上での課題

WordPressに限らないのですが、PaaSにWebアプリを乗せるときにはWebアプリ自体を「ステートレス」にしないといけません。 ステートレスとはその名の通り状態を持たないようにすることで、WordPressの例でいうと管理画面からアップロードする写真やインストールするプラグインがそれに値します。

PaaSはスケールアウトとスケールインといって、インスタンスを増やしたり減らしたり出来ることが大きな魅力の一つです。 しかし一つのサーバーの中に画像やプラグインのファイルが配置されていると他のサーバーからそのファイルが参照できないためにスケールアウトできません。

そのためPaaSにWordPressを乗せる場合には画像を専用サービス(例: S3)に送信したり、プラグインをgit管理して管理画面からは更新やインストールをしないようにするなどの運用にする必要があります。

しかし、画像をS3にアップロードするように修正するのも工数がかかりますし、プラグインをgit管理する場合はプラグインのインストールを開発チームが行わないといけなくなります。

Azure Web Appの何がWordPressに適しているのか?

Azure Web Appは状態があるWebアプリでもスケールアウトすることができる特徴があり、そのためWordPressに乗せるのに特別な改修をする必要がありません。

利用者側が気にすることはないですが、Azure Web Appの内部はざっくりいうとWeb WorkersとFile Workersに分かれています。

Web Workersが実際にリクエストを処理しプログラムが動作するサーバーになります。スケールアウトをしてインスタンス数を増やすとこのWeb Workersの数が増えます。

File Serversはhtmlやjs、画像やデプロイされるコードなどのファイル類が配置されているサーバーになります。これはAzure Storage Blobsがマウントされており、Web WorkersはFile Serversにnetwork driver越しにアクセスしています。

例えばインスタンスが3つに設定されたWebAppに載せたWordPress 上に画像をアップロードされると、プログラムレベルではサーバーのローカルディスクに保存しているように見えますがネットワークドライバー越しにFile Serverに保存されます。そのファイルを3つのWeb Serversから参照できるのでインスタンス数を増やしても減らしても大丈夫というわけです。

というわけで、もしWordPressのサイトをクラウドにのせたい場合はいつもはAWSを使っている方もぜひAzure WebAppを候補にしてみてください。

参考URL

azure.microsoft.com

docs.microsoft.com

msdn.microsoft.com