こんにちは。インフラエンジニアの永井(shnagai)です。 サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。 アーキテクチャ リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい リードレプリカアクセスにLB機能がある リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散 レプリカ0の場合は、writerにアクセスがいく アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行

こんにちは！今年もコナン映画にいってきました、コナンでは服部派のエンジニア結城(@super_manner)です(*´ڡ`●) さて、今回はAPIをチームで開発するうえでつよーい味方になるツールを２つ使い比べた結果をご紹介しようと思います!! そもそもPawとInsomniaとは？ 双方ともREST APIクライアントです。 Paw paw.cloud Insomnia insomnia.rest APIを作成していると、POSTする必要があったり、User-AgentやRequestHeaderによる制約を受けたりで プラグイン追加が加速したりしますよね。 うっかりそのまま他のサイトを閲覧して全部がxmlで表示されたりすることもしばしば。 そんな煩わしさも、これらのクライアントを使うことで開放されるのです!! APIをメインに開発されている方にはもはや必需品になっているかもしれませんね。

こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F

こんにちは、PHPなどを書いている金城 (@o0h_) です。ここ暫くはファミリーマートのリーフレタスと大根のサラダとセブン-イレブンの15品目のサラダボウル（和風ドレ）が私の食生活においてヘビロテしています。*1 話は変わるのですが、コネヒトでは、ログの収集+データの分析用途のツールの1つとしてmixpanelを利用しています。 mixpanelが凄いな、と感じる点 データの送信はシンプルなAPIリクエストで行われ、データの分析も割と踏み込んだフィルタリングやビジュアライズが手軽にできます。非常に柔軟なデータ構造・・「People」と「Event」という主語+動詞的な関係性を意識した設計は、多様なデータを格納しやすくデータ同士を組み合わせて利用するというニーズに潔く答えていると思います。 それと同時に、限界もある その一方で、この「何でも収まる、柔軟な設計」というポテンシャルを100%引

こんにちは、最近AbemaTVでフリースタイルダンジョンを深夜に見る習慣が出来て寝不足気味の田村(@Utmrer)です。 みなさんはアプリのトラッキングにどのAnalytics Toolを使っていますか？Google AnalyticsやFlurry, Facebook Analyticsなどいろいろありますが、弊社では主にMixpanelを使ってトラッキングしています。 Mixpanelは一定のデータ量までは無料で使う事ができるので最初は良かったのですが、サービスが成長してくると結構な金額になってきてます。 そこで日々良いツールは無いかと探していたのですが、Google I/Oで発表されたFirebase Analyticsが無料という話を聞いたので試しに使ってみることにしました。 簡単なトラッキング プロジェクトの作成やアプリの追加は公式のドキュメントを参考にしてください。Consol

【後日談】 qiita.com ソースコードを公開しています〜、もしよろしければご一緒にどうぞ！ Slackの話をします ご無沙汰しております。 コネヒトでPHPを書いている金城 / @o0h_です。 突然ですが、皆様Slack大好きですか。 起床すると真っ先にSlackの赤い丸を消しに行く生活を送っていますか。 コネヒトではSlack大好き従業員・役員が多く、この中で日々色々なやりとりが繰り広げられています。 そんな風にSlackを使っていると、「もっとコレしたい」「アレできないの」が溢れてきます。 先日の島田の記事でも、その一例を紹介いたしました。 Slackの情報が「まとめにくい」問題 非常にフロー型の情報・交流に適したツールだな、と思うわけです。 パッと言える。スッと目に入る。 そうすると、「その場で思いついたアイディア」などを刹那的に投げつけていきたくなります。 ・・・が、その速

こんにちは、デザイナーのきよえし(@kiyoe_furuichi)です。 ママ向けサービスを運営する私たちは社内で働く約7割が子育て中のママさん・妊婦さんで、実際にユーザーとして日々サービスを使っていただいています。 そのため普段の会話から直接アイデアやフィードバックをいただいたりと、開発チームとユーザーの距離がとても近い環境です。 今回は、そんな私たちが社内で行っているユーザーヒアリングについてご紹介したいと思います。 社内ヒアリングの課題 これまで行ってきた社内ヒアリングの方法として、質問・報告用のSlackチャンネル*1でご意見・ご要望を募ったり、ランチの際にラフにお聞きするといった方法でヒアリングさせていただいていたのですが、そんな中、このような声をいただくことがありました。 業務中気になることがたまにあるけど、伝える前に忘れてしまう！ 細かすぎることだから伝えるまでもないかと思っ

こんにちは CTOの島田(@tatsushim)です。 今回はビジネスチームのメンバーと一緒に「技術で勝つ」チームをどう創るかという点についてご紹介させていただければと思います。 勝ちたい！ 突然ですが、Webサービスを創るからにはそのサービスをNo.1のサービスにしたいと思っています。しかし数の勝負では大企業に勝てません。 日本の3人に1人のママが利用するmamari事業を支えているのはたった11名の社員です(2016年3月4日現在)。 少数精鋭で戦うために、弊社ではビジネスチームにも積極的に技術を使ってもらっています。 技術を使ってもらうメリットには以下のようなものがあります。 エンジニアとコミュニケーションしやすくなる ビジネスissueからの要求でエンジニアのリソースを取ることが減る 全員が「技術」で解決しようという思考になる 以下、実際に私達が今実践している3つの工夫について、解

お久しぶりです、社内で「ラブライブ、紅白出場おめでとうございます」と声をかけられる田村(@Utmrer)です。 私はiOS/Androidのクライアントサイドとサーバーサイドの実装をどちらも担当しているのですが、「ローカルサーバーで開発してるAPIを使いながら、アプリも開発する」ということをよくします。 その時に、アプリ側で通信するhostを本番環境のhostから自分のPCのローカルIP(192.168.1.XX, 10.0.1.YYなど)に変更してローカルサーバーとアプリを通信させていたのですが、IPv6サポートの流れからか、iOS9では出来なくなりました。*1 ローカルサーバーと通信出来ないとぶっつけ本番でデプロイする恐怖や、変更する度に開発環境にデプロイする煩わしさと戦わなければいけません。 それらを避けるためにiOS9でもローカルサーバーと通信する方法をご紹介します。 TL;DR

こんにちは！ CTOの島田(@tatsushim)です。 先日mamari tech nightというエンジニア向けのLTイベントを社内で開催しました。 その際にママリのインフラ構成について発表したのですが、当時を振り返り大事だなと思うことがあったので、今回はその学びを共有したいと思います。 完璧なインフラ構成は必要ない 結論からお伝えするとサービスの立ち上げ時に「完璧なインフラ構成は必要ない」というお話です。 ママリの最初のインフラ構成 実はママリの最初のインフラ構成は以下のような構成になっていました。*1 構成は1台のEC2インスタンスのみで、もちろん、DB(MySQL), Apacheなどは全部入りです。 しかしインフラ構成はしばらく変えず、アプリケーションの機能開発にリソースを割きました。 そのインフラ、本当に今必要？ サービスを創る際、1エンジニアとしてはそのサービスを滞りなく運