コネヒト開発者ブログ

コネヒト開発者ブログ

面倒いの抜きでPHPの静的解析「Phan」を使ってみる with Docker

面倒いの抜きでPhanを使ってみる

あけましておめでとうございます!
サーバーサイドやってます金城(@o0h)です。

年末年始は毎年恒例の「ヘルシング全巻読み直し」をしていました。カッコいいですね・・

弊社ではPhanを用いた静的解析を行っております。
今回は、「多分、これが最も1番の最速さでPhanを試す方法になるんじゃないかな?」というお話をいたします。

cf) リファクタリング対象を選ぶ戦略を決めよう - コネヒト開発者ブログ

https://cdn.mamari.jp/authorized/5a522dc0-c5f0-4f0d-8f46-0016ac120004.jpg

tl;dr

  1. cloudflare/phan というイメージがあります
  2. これを使うと、「php7環境の用意」だとか「php-astの用意」とかいった手間を全部すっ飛ばしてPhanの静的解析が実行できます
  3. すぐ使えるようにコマンドがあるので、↑のページの "Getting docker-phan" のセクションを参照してください*1

*1:この記事を書き始めてから見つけたのですが、まさに「コマンドを使う」感覚でPhanを丸ごと実行できる!!というユーザー体験だと思います。すごい。。 → コマンド実行環境としてのDocker // Speaker Deck

続きを読む

アンチフラジャイルなチームを目指して

Merry Christmas
最後のプレゼント(記事)をお届け!

はじめに

本記事はコネヒト Advent Calendar 2017の25日目、つまり、最後のエントリーになります。

メリークリスマス!そして、宮崎あおいさんご結婚おめでとうございます!サーバーサイドエンジニアの @itosho です。

ここまで続いてきたアドベントカレンダーもいよいよフィナーレということで、今日は来年の抱負というかこれからのことを書いてみたいと思います。 あんまり技術的な話は出てこないと思いますが、1mmでも誰かに刺さるといいなぁ…と願いながら書きます。

2018年版僕が考える理想のチーム

僕は昔から個人ではなくチームが成長するために何をするべきか、もしくは組織の中で各人が有機的にワークするにはどうすればいいかを考えたり、実践したりするのが好きなのですが、ここ最近、気に入っているキーワードのひとつに「アンチフラジャイル」という言葉があります。

アンチフラジャイルとは?

ご存知の方もいるかもしれませんが、最初にアンチフラジャイルという言葉の意味について簡単に説明させていただきます。

そもそも、アンチフラジャイルという言葉自体は技術用語ではなく、著書『ブラック・スワン』で有名なNassim Talebさんが考えた造語です。日本では『反脆弱性』というタイトルで書籍が出版されており、分野としては行動経済学に位置づけられているのですが、他の分野でも有効な考えとして広く注目を集めており、ソフトウェアの世界では、特にマイクロサービスやDevOpsの文脈で使われることが多いようです。

また、アンチフラジャイルを理解するためには、まず、フラジャイル・ロバスト・レジリエンスという言葉を知っておく必要があります。

フラジャイル / Fragile

フラジャイルとは、一回の大きな変化で大きな損を生み出すものとして定義されています。 例えば、杜撰な計画をしたウォーターフォール型の開発は、一度大きなトラブルがあると、大きな手戻り(=損)が発生してしまうため、フラジャイルであると言えるでしょう。

そう言えば、Every Little Thingさんの歌にも同じタイトル(発音が違うけど)の曲があると思いますが、だいたいそんな感じです。

ロバスト / Robust

ロバストとは、フラジャイルの逆で、大きな変化を受けても、大きな損を出さないものとして定義されています。 先程の例で言うと、しっかりと計画を練られたウォーターフォール型の開発はロバストであると言えます。また、職業で言うと、サラリーマンはフラジャイルで医者はロバストに分類されるようです。 ただし、ロバストの欠点として、想定していない突発的な事態には対処出来ないことが挙げられます。

レジリエンス / Resilience

レジリエンスとは、ロバストを更に発展させた考えで、変化に強く、回復力が高いという意味を持ちます。 開発モデルで言うと、アジャイル開発はまさにレジリエンス的な考えを反映したものだと思います。 また、突発的な事態が発生しても、被害を最小限に留められるようにすることもレジリエンス的な考えで、具体的にはサーキットブレイカーの仕組みやBCP対策などがこれに当たります。

アンチフラジャイル / Antifragile

そして、お待たせしましたアンチフラジャイルの登場です。アンチフラジャイルの特徴を一言で言うと、アンチフラジャイルは変化に対して、損ではなく利益を生みます。

これまではレジリエンスなシステムであることが良いとされてきましたが、アンチフラジャイルは更にそれを推し進めたのが考えになります。 例えば、これまでは「障害をどう防ぐか」について腐心してきた方が多いと思いますが、「障害は起きる」という前提で動くのが、アンチフラジャイルの基本的な考えになります。

Netflixではいち早くこの概念を導入して、本番環境でわざと障害を起こしたり、Chaos Engineeringの原則を導入したりすることで、変化や障害に対処出来る強いシステムを作り上げることに成功にしています。

失敗から学ぶ、という表現では陳腐過ぎるとは思いますが、アンチフラジャイルは失敗を重ねることで、より強くなっていくものであり、この考え方はソフトウェア工学やアーキテクチャ論に留まらず、もっと会社や組織、チームマネジメント的な分野にも応用出来るのはではないかと僕は考えています。*1

強いチームをつくるために

例えば、チームの成長を止めない方法の一つとして、離職率を下げることが挙げられます。これは当然と言えば当然で、チームが成長するには経験や学び(ラーニング)の蓄積が必要だからです。*2

また、チームは一朝一夕には強くならないので、それを向上させるには小さな成功体験を積み重ねる必要があります。そうすることで、チーム力は徐々に強化されていきます。 加えて、各人が組織として有機的に動けるようするために開発プロセスやフローなどのルールを整備することも大切でしょう。

でも、世界は不確実だ

では、本当にそれだけで良いのでしょうか?

もちろん、離職率を下げることは会社としてとても大切なことですし、一度成功した起業家がそうではない起業家よりも次に成功する確率が高い*3というデータがあるように、成功体験を得ることは重要です。 また、組織が急速に大きくなっていくフェーズでは、大なり小なりルールを整備しないと日々の業務が破綻する可能性があります。

しかし、どうしたって、離職者を0にすることは出来ません。*4 幸いにも、現状コネヒトの離職率はかなり低い状態ですが、1年後どうなっているかは分かりません。もしかしたら、iOSエンジニアがある日突然、全員無人島に行ってしまうかもしれません。そうなって欲しくはないですが、その可能性は0ではありません。その時、これまで通り次の日から業務を続けることが出来るでしょうか?

業界にパラダイムシフトが起きて、これまでの常識が通用しなくなった時、今までの成功体験は本当に役に立つのでしょうか? どんなにルールを整備しても、いずれルールは破られます。何故なら、ルールは破られるために存在するからです。*5 また、ルールの中に生きていると、ルール外のことが起きた時に対処出来なくなったり、ルールの外側にある変化に気付きにくくなったりしてしまう危険性もあります。

目まぐるしく変化するこの不確実な世界で闘うためには従来のレジリエンス的な考え方だけではなく、アンチフラジャイルな考え方をチームに取り入れていくことが、この先を生きのびるためのひとつの方法なのではないかと僕は思います。

僕たちはアンチフラジャイルになれるのか?

とは言え、アンチフラジャイルなチームになることは容易ではありません。 アンチフラジャイルなチームになるためには、前提としてレジリエンスなチームでなければなりませんし、そもそも、レジリエンスなチームに辿り着くにも相当な努力が必要です。

しかし、諦めたらそこで試合終了です。

少しでもアンチフラジャイルに近づくために、最近、僕が意識していることは以下の3つです。

  • 職能・職域に囚われない
  • 小さな失敗を繰り返して成長する
  • ルールなしで自走出来るようにする

言葉にしてみると、至極当たり前のことばかりかもしれませんが、いきなりスーパーマンにはなれないので、まずは自分に出来ることから地道にはじめていくしかないのかなと思っています。

今回参考にさせていただいたアンチフラジャイルの世界という記事の中にアンチフラジャイルのメタファーとして、ドラゴンボールのサイヤ人が登場するのですが、個人的に秀逸な例えだと思っていて、スーパーサイヤ人が集まったチームが出来たら…と想像するだけでわくわくします…!

繰り返しになりますが、アンチフラジャイルなチームをつくることは容易ではありません。しかし、アンチフラジャイルなチームになろうすること、少なくともその態度を示すことがアンチフラジャイルへ繋がる第一歩なのだと僕は考えています。

おわりに

ここまでお付き合いいただきありがとうございました。

長文を書き散らした挙句、結論めいたものもなく恐縮ですが、来年はここに書いたことを意識しながら、サービスをもっと大きく出来るよう、より一層頑張っていく所存でございます。 とは言え、頑張り続けるにはエネルギーが必要なので、素敵なメンバーとわいわい働くことでエネルギーをもらいながら、愉しく頑張っていければ最高ですし、その頑張った成果をまた来年のアドベントカレンダーで報告出来ればもっと最高だなと思っています。

それではよいお年を!

参考文献 / サイト

めっちゃたくさんお世話になりました。

おまけ

www.youtube.com

*1:そもそも、最初にこの概念を利用したと言われる元NetflixのAriel Tseitlinさんもアンチフラジャイルな組織というタイトルの記事を書いています。

*2:ラーニングの蓄積の重要性については、伊藤直也さんの開発組織マネジメントのコツに要点がまとめられています。

*3:DHHさんがいることで有名な37signals(現Basecamp)の書籍である『小さなチーム、大きな仕事――働き方の新スタンダード』の 「失敗から学ぶこと」は過大評価されている の章より引用

*4:出来ることと言えば、せめてネガティブな理由でなくポジティブな理由で去って行くことくらいでしょうか…。

*5:これは極論かもしれませんが、そういう側面もあるかと思います。

Docker運用基盤をECSからFargateにリプレイスした未来について考察してみた

こんにちは。インフラエンジニアの永井(shnagai)です。

この記事はコネヒト & aws-fargate Advent Calendar 2017 22日目の記事です。

※本当は別記事二本書く予定だったのですが、パワー不足で一本にまとめさせてもらいました。

コネヒト Advent Calendar 2017 - Qiita

AWS Fargate Advent Calendar 2017 - Qiita

コネヒトでは、本番環境のほとんどのサービスでDockerを導入し、ECSを使ってサービス運用しているのですが、今回のre:Inventで発表されたFargateにこの環境を置き換えるとどんな未来が待っているかについて、考察してみました。

現状の自分が認識している情報ベースで書いているので、正確な情報とはいえずツッコミあれば指摘いただけると幸いです。

目次

  • Docker導入で何を目指したかったのか
  • 下記テーマについて、ECS→Fargateにリプレイスした先の未来を考察
    • インフラ的な運用面
    • コスト面
    • 監視周りの話
    • スケジュール系バッチと集計系バッチの話
  • これからの課題
  • まとめ

Docker導入で何を目指したかったのか

そもそもECSやFargateを動かすには、アプリケーションの実行基盤をDocker化する必要があります。 コネヒトでは、約半年かけて開発環境から本番までDocker化を進めてきたのですが、改めて目指していた状況と現在を振り返ってみたいと思います。

【解決したかった課題】

  • 開発環境が不安定

多数のVMにより、ホストに負荷がかかり重くて開発速度に支障が出てきていた

  • 本番/開発環境の乖離

開発、本番それぞれ別環境/オペレーションでOSやミドルウェアのメンテが必要なため必然的に乖離が生じる

tech.connehito.com

【導入後の経過】

  • 開発環境が不安定

Docker for Mac特有の問題が少しあるものの、概ね開発環境への不満はなくなりました。

  • 本番/開発環境の乖離

Dockerfileに全ての情報を集約した為に、開発者自身がDockerfileをメンテナンスしながら日々の開発が行えるようになりました。 よくある、開発者からインフラへの「本番にこれ入れたいんでお願いします」的な話がなくなりました。 これは、アプリケーション実行基盤自体をコードで管理するというDocker化の一番の恩恵なのかなと思っています。

【新たな課題】

当初の目的は達成したのですが、Dockerの実行基盤としてECSを採用した為、今度は、ECSに関するオペレーションが新たな課題として持ち上がってきました。 ECSは、ご存知の通りEC2を束ねたクラスタを組みその上に、Dockerのコンテナを動かすというDockerオーケストレーション層のサービスです。

故に、EC2を強く意識しながら運用することが求められます。

  • キャパプラする時に、ホスト(EC2)側のリソースとタスク(コンテナ)のリソースを計算しながら本番トラフィックを捌ける構成を組む
  • 監視に関しても、コンテナ+ホスト(EC2)に関する二重の監視が必要

なので、インフラレイヤ含めたアプリケーション実行基盤は開発者だけで作れても、ECS上でトラフィックに耐えうるサービスとして動かすところはECSの専門的な知識がないとちょっと難しいという状況が生まれました。 キャパプラ・監視・デプロイ等、ECSのアーキテクチャを理解してないと運用は難しいといった問題が出てきたというところです。

そして、EC2を強く意識する運用から脱却したいなと待ち望んでいたところに、今回のre:InventでFargateというDockerコンテナのマネージドサービスが発表されました。 ここからは、東京リージョンにFargateが来てECSからFargateに乗り変えたらどんな未来が待っているのかというのを、自分が今認識している情報ベースで書き連ねたいと思います。

ECSからFargateに移行するとどうなるか

4つのタームに分けて個人的な考察を書きます。

Fargate実際に触ってみた時の所感はこちら! tech.connehito.com

インフラ的な運用面

現状

①クラスタ内のホスト(EC2)とタスク(コンテナ)を意識しながら、キャパシティプランニングをしないといけない

ECSだとクラスタとタスクを連動して考えないとならず、クラスタのキャパシティを確保した上で、タスク(コンテナ)のリソースを考えないといけない。 これは、オートスケールを組む際も同じで、面倒&事故につながる可能性も高いので今は使いづらい。 ※オートスケールをCPUトリガにしてても、緩やかに上っていくというより一気にしきい値超えてくるような状態多いですよね。だから、結局クラスタに余裕もたせる戦略の方が安全という話

②新規開発時にうまく動かない時は、たまにコンテナにSSHしてデバッグすることがある(あまりやらないようにはしてるけど)

例えば、新しいツールをECS上で動かそうとする時に、意図しない挙動をする事がある。 そんな時は、テスト環境でタスクを立ち上げて、コンテナ内にSSHして何が起きているかデバッグしている。 いくらDockerで開発環境で動いたものを持っていくと言ってもいざという時にデバッグは必要。 トラブル起きてる時に、top叩いてあたりつけたいですよねという話

Fargateになると

①の苦労がなくなる事が、Fargateを導入する一番のメリットになるのではと個人的には思っている。 ECS環境作る時に、裏にいるEC2を強く意識しながらサービスを作っていたからそこから解放されるのは大きい。 オートスケールする時に、まずEC2のリソース確保してからその中でスケール出来るコンテナ数とか考えたくないですよね。

②に関しては、マネージドサービスを使う時点で、SSHはまぁ出来ないだろうなという印象。 只、いざというときのデバッグを出来るような仕組みは欲しいなというのが正直なところ。

願望

サービスのオートスケールにAutoScalingGroupにあるようなスケジュールでスケールする機能がついてくるうれしい。サービス毎にピークタイムはもちろん異なると思いますが、予め予測出来ている負荷に対しては準備しておきたい。 これ入ると、かなり動的にコンテナ数を増減しながらコストメリットも出していくような未来的な運用が出来そうだなと思っています。

コスト面

現状

Blue/Greenデプロイを実現するために、必要なコンピューティングリソースの2倍をEC2インスタンスとしてクラスタ内に構えているため、サービスを稼働するために必要なコンピューティングリソースの2倍の金額がかかっている。 が、EC2のリザーブドインスタンスを使ってるので、実質は、オンデマンドインスタンスの四掛くらいの料金がECSでサービスを動かすためのコストとして掛かっている。

Fargateになると

ざっくり、オンデマンドインスタンスとの比較で約2倍の料金設定というレポートがあったので、クラスタで常時動くコンピューティングリソースが半分になると考えるとコスト的には現在と変わらないか、リザーブド値引き分があるので、少しコストが上がるのかなという感覚。 ココらへんは、東京リージョンにローンチされてサービスメニューを見てみないとなんとも言えないので、来たら確認しようと思う。

こちら参考にさせていただきました。http://tech-blog.abeja.asia/entry/fargate-ecs-spotfleet

願望

バッチ的な使い方でなく、Web環境で使うとなるとある程度固定的にコンピューティングリソースを確保しておきたいという要望はかなりあると思うので、コンピューティングリソースのリザーブド的なメニューが出てくるのではと推測しています。裏で動いているのはEC2だと思うので、リソースを予約してコストダウン図れるようにしていけたら幸せだなと思っています。

監視周りの話

現状

  • ECSだと、サービス(同じ役割のDockerコンテナの集合体)単位とクラスタ(EC2インスタンスの集合体)単位で監視をしている
  • ECS関連で取れるメトリクスは、CPU,Memのみで、Web環境に関しては、ALBのUnhealthyHostをコンテナの生存確認としてチェックしている
  • EC2側は、AutoScallingGroupのNWIn/OutとStatusCheckFailだけチェックしている

Fargateになると

監視項目はかなり減りそう(とれるメトリクスがCPU,Memだけなので)

  • CPU,Memをタスク定義で1コンテナあたりに割り当てていくから、今でいうサービスで取れるメトリクスの(CPU,Mem)だけを見ておく状態??
  • Memoryはハードリミット一択になりそうだから、OOMは気をつけないといけない
  • CPU使用率が一番重要なメトリクスになるのは今と変わらない
  • EC2側で気にかけているStatusCheckFailは不要になる

FargateのCPU,MemとALBから取れるメトリクスを組み合わせて監視を作っていく形になるだろう。 只、見るべきポイントが少なくなるのはマネージドサービスの恩恵を受けれる部分で、安定運用しているうちは変に高濃度なメトリクスは取ろうとしないで運用をAWSに任せるのが良いアプローチな気がする

願望

それこそDatadogとかMackerelとか使えよという話だが、プロセス監視とか高濃度メトリクスを手軽に取れるとよさそう。 後は、1台だけにNewRelicのようなミドルウェア入れるみたいな事出来るといいなと。 CloudWatchのメトリクスが何もしなくても値取ってきてくれるイメージで、Fargate(ecs-agent??)に組み込みの形で任意のメトリクスとか取れるといいなと思っています。

スケジュール系バッチと集計系バッチの話

現状

  • スケジュール系、集計系バッチともに、ECS ScheduleTasksを使って実行している
  • 現状起きていないが、集計系の重い処理はホスト側のリソース競合が起きることを念頭に起きながら運用しなければならない

tech.connehito.com

Fargateになると

バッチ系に関しては使い分けが必要と個人的には思っている

集計系バッチ処理

  • 時間への強い制約がないので、Fargateで強めのコンピューティングリソースを使いと従量課金でやるのがよさそう。Lambda的な時間制限もないので、この使い方は普及しそう

スケジュール系バッチ処理

  • 何時何分に動くことに意味があるバッチとかだと、どうしても初回起動の遅さがあるかなというのを危惧している(もちろんDockerイメージのサイズによるところが大きいがホスト固定されない分、Pull時のキャッシュが効かなくなるから)
  • ひとまずは、今のScheduleTaskで運用して様子を見る

願望

特になくて色々なユースケースが集まってくるといいなと思っています。

これからの課題

コネヒトの今見えているDocker周りに関する課題について、書いておこうと思います。

  • Docker導入を優先してやってきたので、Dockerイメージのリファクタ等に手をつけられておらず、イメージスリム化しないとFargateだと起動が遅くなるだろうからそこに着手
  • デプロイフローをECSありきで組んだので、Fargateにフィットさせるべく改良
  • すぐに使うことはないけど、k8sの情報も追いかけながら最適なDockerのサービス運用環境を探っていく(最近の話だと、マイクロサービス化した時の内部通信(例えばAPI間通信とか)はk8sのプロキシスタイルのほうが優秀なのかなと思ってる)

まとめ

今思ってることを書き連ねてみたが、Fargateを導入することで運用コストを下げてコンテナをサービス運用する、幸せにそうな未来が見えてきたので、早く東京リージョンに来て色々とやっていきたい。

手元で開発したコンテナを、あまり何も考えずにサービスとして動かせる未来が近づいてきている感じがした。(最初にオートスケール等を組んで運用にのせれば)

テーマ ECS Fargate 補足
インフラ的な運用面 EC2管理からの解放!!SSHは出来ないだろうけどそこはマネージドサービスと割り切る
コスト面 Fargateの方が少し高くなるのかも??(未知)
監視周りの話 気にかけるべきメトリクスが減るのは良いこと
スケジュール系バッチと集計系バッチの話 Fargateはコンテナ起動速度が少し気になる(Dockerイメージサイズ次第)

明日のコネヒトアドベントカレンダーは、katsutomu さんによる、記事です。 お楽しみに!

【資料公開】PHP Way #1 に登壇しました!~ コネヒトが考える技術選択の仕方について ~

f:id:tatsushim:20171220171449j:plain

この記事はコネヒトアドベントカレンダーの20日目の記事です。 qiita.com

こんにちは!

CTOの島田(@tatsushim)です。 昨日BASE社が主催する「PHP Way #1」に登壇させていただきました。 base.connpass.com #phpwayがトレンドに上がるなどイベントとしてはとても盛り上がりました。 今回は発表した内容の要旨を大きく3つに分けてお伝えしたいと思います。

発表内容

サービスの0→1で意識したこと

サービスの0→1ではユーザーに早く価値を届けることが最も大事だと考えています。
今回、勉強会の中で最初の質問として「なぜPHPを利用しているのか?」という問いがあったのですが、 ママリにおいてPHPを利用している理由は、当時のメンバー構成で最も早くアプリケーションを世の中に出すためにCakePHPを選択したからです。

コネヒトが考える技術選択の仕方

前述のように、コネヒトでは目的に合わせた技術選択を心がけています。
あくまで、技術はユーザーに良い体験を届けるための手段です。
例えば課題の解決に取り組む際に、その課題がバージョンアップで対応可能なのか、それとも新技術を導入する必要なのかを検討します。 その上で、目的によって最適な解を選択します。その結果、以下のような技術選択を行ってきました。

Before After
PHP5 PHP7
CakePHP2 CakePHP3
Objective-C Swift
Java Kotlin
Vagrant, Chef Docker

繰り返しになりますが、ユーザーに良い体験を届けることが第一目的だと考えています。

技術選択とOSSの関係

OSSへの貢献は将来への大きなリスクヘッジだと考えています。
コミットできるくらい使い倒したり、最新のリリースや今後の開発方針などを把握していることは次の技術選択のとても有益な情報になります。
現在、社内にはCakePHPのコントリビューターが
3人います。 先日富田さんのブログにもありましたが、彼は日本でも数人しかいないKotlinのコントリビューターになってくれました! このように、OSSへコミットしたり、PlugInを公開しているメンバーがいるのはとても心強いことです。

発表資料

詳細な内容についてはぜひ以下の発表資料をご覧いただければと思います。

終わりに

1人の参加者としてもとても有意義な時間でした。
会場提供のBASEさん、一緒に登壇してくださったえふしんさん、白井さん、準備してくださった方々、お越しいただいた皆様有難うございました!

以上、島田(@tatsushim)がお送りしました! 明日のコネヒトアドベントカレンダーは伊藤(@itosho)さんのターンです!

追記

一緒に登壇してくださったお二人がブログを挙げてくださったのでご紹介します。

devblog.thebase.in

ameblo.jp

API tool PawのExtension/Tipsを紹介します!

皆さんこんにちは!
スターウォーズではチューバッカが一番かわいいと主張してやまない結城(@super_manner)です。
f:id:supermanner:20171219124909p:plain

この記事はコネヒトアドベントカレンダーの19日目の記事です。
今日は私が日頃お世話になり倒しているツール「Paw」の細かい機能についてご紹介しようと思います。

paw.cloud

Pawとコネヒト

Pawについては前回のこちらの記事でInsomniaとの比較としてご紹介させていただきました!

tech.connehito.com

当時最後のセクションで「コネヒトではInsomniaを採用しています」と書きましたが、
直後から複数のラインが動き始めたこともあり、ブランチ機能を活用できる機会が増えましたのでPawを採用する方向に決まりました。

Pawに入れておくと捗るExtension

Pawは公式が用意してくれているExtentionがたくさんあります。
幾つかはダウンロードやアップデート時に既にインストールされているものがあります。
Extensionは

  • Code Generators
  • Dynamic Values
  • Imports

の3つのカテゴリで開発されています。 (ref: Extensions for Paw, the most advanced HTTP client for Mac)
特にCode GeneratorsはPawを使用されていない方へ、一番使いやすいフォーマットで コマンドをお渡しするのに使用できるので
例えば 「Pull Requestに貼っておくだけでも容易に再現できる」 という点などで、非常に利便性を感じております。

cURL Code Generator

https://paw.cloud/extensions/cURLCodeGenerator
Curl形式でPawで作られたデータを表現するためのextensionで、私の普段の開発では最も使用頻度が多いです。 GUI上ではこの部分で確認できます。 f:id:supermanner:20171218215312p:plain

Markdown + Curl Code Generator

https://paw.cloud/extensions/CurlMarkdownGenerator
こちらは上記の派生系です。mdですのでドキュメントを作ったり、複数人開発の際の情報伝達に便利かと思います。
下記はweather hackのAPIで作った例です。 f:id:supermanner:20171219123819p:plain

Swagger 2.0 Code Generator

https://paw.cloud/extensions/SwaggerGenerator
最近流行りのSwagger用のCodeGeneratorです。コネヒトでは今のところSwaggerは使用しておりませんが、採用されているプロダクトで良い連携が生まれそうだなと思いました。
また、SwaggerのImporterもあるので合わせて使うと良さそうです。
https://paw.cloud/extensions/SwaggerImporter

Postman Importer

https://paw.cloud/extensions/PostmanImporter
https://paw.cloud/extensions/PostmanCollectionV2Importer
こちらは、有名なツールであるPostmanのImporterです。
使い方についても、ドキュメントで詳しく述べてくれているので、Postmanから移行される方はぜひ参考にしてみてください。
https://paw.cloud/docs/migrate/postman

Chance Dynamic Value

https://paw.cloud/extensions/com.atan.ChanceDynamicValue
これはOfficialのものではないのですが、任意のそれっぽい値を動的に生成してくれるものです。テストデータを自分で手打ちしなくていいので楽ができます。
f:id:supermanner:20171219124211g:plain

Templateをまるっとimportできる機能

最後に、最近気づいた便利な機能も合わせてご紹介したいと思います。 一般的なAPIを取りあえず試してみたい時などに利用できるかと思います。

[File] -> [Import] -> [Search API Template] を選択します。
f:id:supermanner:20171218213831p:plain

後は、任意のサービス名を入れるだけです。今回はSlackをチョイスしてみました。 f:id:supermanner:20171218214615g:plain

これは便利ですね。個人開発の時等に使用すると効率が上がりそうです。

まとめ

個人的に、Pawには日頃大変お世話になっているので、この記事を読んで一人でもPawを使ってみたいな、と思える方が増えれば嬉しく思います。
(もちろん、前回の記事で書いたInsomniaも応援しています!!)
明日は @tatsushim さんが渾身の投稿を放ちますので、お楽しみに!!

【ポエム】CTOだけどたぶん社内で1番コードにツッコミを入れられてる話

f:id:tatsushim:20171217164649j:plain

この記事はコネヒトアドベントカレンダーの17日目の記事です。 qiita.com

こんにちは!

CTOの島田(@tatsushim)です。 今回はポエムを書くのでポケモンGOでポッポを捕まえるときくらい何も考えずに読んでください。

はじめに

コネヒトは創業から6期目、ママリは3年目です。 プロダクトをつくりはじめて3年くらい経つとこういうことが起きます。

最初に書いたコード

ママリ立ち上げ時の初期コードは今リードエンジニアをやってくれている田村さんと私でほとんど書きました。それこそAWS上で構築したインフラから管理画面のJSまで実装してとにかくユーザーに価値を届けることに必死でした。

それから

ある程度サービスが大きくなってきて資金を調達をしたあとに運良く優秀なメンバーが入ってきてくれました。彼らはホントに優秀でかつ得意分野を持っているメンバーも多いです。なので私の書いたコードや設定に遠慮なく、ツッコミをくれます(ノ∀`)タハー

私の内心

そりゃー内心としては( ;`・~・) ぐぬぬ…という気持ちです。
「あのときはそのコード(設定)がベストだったんだ!」と言いたいところですが、今の最適解をちゃんと出してくれるメンバーたちの提案を受け入れないわけにはいきません。
というかこれはむしろ組織にとっては健全でどんどんプロダクトのコードとしては良くなっていくわけです。

その結果

メインアプリケーションのAPI等のコードはメンバーに託すことができて、今はインフラレイヤーの改善、採用、登壇、その他CTOとしての仕事をしています。
これらに集中できているのはコードにツッコミを入れてくれるメンバーのおかげです。
いつもありがとう。支えてもらい本当に感謝です。これからも宜しくお願いします。

終わりに

以上、島田(@tatsushim)がポエムをお送りしました。 12人のメンバーで、ここまで1日も切らさずにコネヒトアドベントカレンダーは続いています。 明日は田村(@Utmrer)さんのターンです!

物覚えが悪いのでSlackに色々と覚えてもらうappを作った話

こんにちは!「M-1グランプリやるなら教えてほしかったんだけど?」と思っている金城(@o0h_)です。
ちょっと寂しいので、最近読みました「ここは今から倫理です。」のリンクを貼ります。

ここは今から倫理です。 1 (ヤングジャンプコミックスDIGITAL)

ここは今から倫理です。 1 (ヤングジャンプコミックスDIGITAL)

さて昨日は、英語が聴ける・話せるようになりたい・・・・と思っているところにガツンとくるトミーさんの記事でした。
引き続いてのAdvent Calendar Day16、わたくしからはSlackのbotの話でもいたします。

https://cdn.mamari.jp/authorized/5a34f7a1-bc6c-46ad-b6f5-0019ac120002.jpg

標準の「自動レスポンス」を再発明してリッチにする

皆さんも、自動レスポンス(という名前でいいのかな・・)は利用しているのではないかと思います。
設定画面で「キーワード」と「反応」を入れると反応してくれるアレですね。 f:id:o0h:20171216185417g:plain

コネヒトではSlackにいろいろを集約していく風潮がありますので、こういう機能は「よく使うけど忘れがちなコマンド」や「使いたくなったときにすぐ引き出したいURL」を放り込むなどして活用しています。

しかし、標準の機能に対して「もっとこうできたらいいのにな!」という課題が段々と浮かび上がってきておりました。
具体的には以下の3点です

  1. Slackでの権限が強い人しか設定を行えず、「私の作業効率を上げたい」と願う全ての人の要望に応えにくい
  2. 設定画面を開いて登録!という手間がある
  3. 「登録済みキーワード」の検索や分類もできればいいのに・・・

これらの問題に対して過剰に対応を行いましたので、今回はそれについて技術的観点からの話題を中心にお話したいと思います。

続きを読む