はじめに 本記事はコネヒト Advent Calendar 2018の24日目のエントリーです！ qiita.com メリークリスマス！Androidエンジニアの富田です。今回はKotlin IDE PluginのKontributeに関する小話で、plugin-common.xmlが生まれてちょっとだけめんどくさい作業が減ったよという内容を紹介します。 Kotlin IDE PluginのKontributeって？ 以下のようなCode InspectionやIntentionなどの機能についてのKontributeを表します。 github.com 詳しい内容については割愛させていただきますが、Kotlin IDE PluginやKontributeについて興味を持った方はぜひ、しらじさんの下記資料をご覧ください！ photos.google.com Kontributeする上でここが

こんにちは。エンジニアの安達 (@dachi_023) です。会社用アカウントとして @ry0_adachi を用意していましたが全然呟かなくなっちゃったので辞めました。複数アカウントの運用って面倒ですね...。はい、コネヒト Advent Calendar 2018 の20日目はDockerとJSです。 まえがき DockerfileにJS (とかCSSとかHTMLとか) のビルド処理を書いてコンテナ立ち上げてブラウザで見えるところまでの話です。 本記事では最低限これができていればそんなに遅くならないよねってものをいくつか書いています。コードは GitHub に上がってますのでそちらを見ていただいてもOKです。このコードは create-react-app で生成したものをビルドしてコンテナ上のNginxで公開するという簡単なものですが、実際にママリのProduction環境に投入したも

はじめに 本記事は コネヒト Advent Calendar 2018 の19日目のエントリーになります。 こんにちは！先日PHPカンファレンス（通称: ペチコン）でLT登壇させていただいた @itosho です。 ペチコンのことも書きたいのですが、ペチコンでもGoの話をしたので、今日はGoのテストを話をしたいと思います。具体的には、今年公開した gdp というCLIツールのテストを書く時に工夫したことを紹介します。 ちなみに、gdpがどういうツールなのかは以前 Go製のCLIツールを公開しましたという記事で説明しているので、もし興味がある方はこちらも読んでいただけると嬉しいです。 開発初期のコード gdpにはリモートリポジトリに指定したtagが存在確認を行う処理があるのですが、当初はこんな感じのメソッドを用意していました。*1 呼び出される側 func IsExistTagInRemot

こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、12/4,5で行われたJapanContainerDays v18.12にスピーカーとして参加させていただいたので、 登壇内容の振り返りと2日間通じて参加した感想を簡単に書こうと思います。 この記事はコネヒト Advent Calendar 2018の7日目の記事です。 qiita.com 発表内容 コンテナを本番導入することでチーム開発がどう変わっていくかというテーマの元お話してきました。 このイベント自体は、今最も勢いのあるKubernetes関連のセッションが8割くらいを占めていた印象ですが、 オーケストレーションツールやその他エコシステム導入の一歩前でこれから本番でコンテナを使っていこうという段階の方々をターゲットに、 本番コンテナ化を後押しできればいいなというような気持ちで資料を作りました。 実際に会場でアンケ

こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。 以前書いた、Fargateに関する調査のまとめ記事はこちら。 tech.connehito.com 内容はざっくり下記3項目です。 いきなりFargateはハードルが高め 良かった点 コンテナのリソースキャパシティを簡単に変更出来る オートスケーリングもシンプルに組める 安定運用 つらい点 タスクの起動速度がEC2バックエンドと比べるとやはり遅い 料金面 いきなりFargateはハードルが高め Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。 今回のF

Creating Effective Dashboards こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。 つい先日、なんか気分が乗らないぜ〜〜って時にスピナーベイトを読み直してみたんですけど、気分の悪さが・・・上塗りされました・・・気をつけましょう。 スピナーベイト (1) (バーズコミックス) さて、今回は抽象的な話になります。 「チームで毎日見るようなプロダクトの成長のためのダッシュボードってどういうのを作るんだっけ」という内容です。 TL;DR 以下のポイントを抑えると「効くダッシュボード」ができるのでは、と考えています。 「なんとなく」で作るのはダメ🙅 目的を持ち、「誰が」「いつ」「何のために」という意図を明確にする 通常のプロダクトと同じく「UX」「ペルソナ」大事 「必要なこと」を厳選する。全てをダッシュボード上でやる必要はない digるのは他の場所で。ダ

こんにちは。インフラエンジニアの永井(shnagai)です。 これまでEC2バックエンドでECSを運用してきたが、Fargateを採用するにあたり、EC2バックエンド時と比べた差分についてまとめてみました。 内容は、ざっくり下記5項目について。 NW(awsvpc) タスク定義 サービス AutoScalling メトリクス/ログ Fargateをやってみたというのは出たての頃にやったので、今回は本番運用を考えるにあたり知っておいたほうがよさそうな点についてまとめてます。 tech.connehito.com NW(awsvpc) アーキテクチャ的に一番大きく変わるのは、NWの部分だと思う。 EC2上で、タスクを動かすときはデフォルトだと「bridge」が指定されるので、ホスト経由で外部と通信を行っていた。同一タスク(コンテナのリッスンポートが同じもの)を効率的にEC2上で動かすために、動

こんにちは、Androidエンジニアの富田です。先日KotlinFest 2018というKotlinカンファレンスに参加してきましたので簡単に内容を共有したいと思います。 Kotlin Fest 2018とは kotlin.connpass.com KotlinFestとは「Kotlinを愛でる」をテーマに、Kotlinに関する知見の共有と、Kotlinファンの交流の場を提供する技術カンファレンスです。海外ではKotlinConfという約1300名規模のKotlinカンファレンスがありますが、それに負けないくらいの熱量を持ったカンファレンスでした。有難いことにこんな可愛いトートバッグも頂きました！ 発表内容 オープニングトーク(長澤太郎さん、藤原聖さん) 内容 Kotlinを愛でるをテーマに 日々の開発、業務を楽しむ Kotlinを盛り上げ Kotlinは可愛い言語 みんなでKotlinを

こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、メインサービスで使っているDBを、RDS for MySQLからAmazon Auroraへ移行した話について書こうと思います。 Auroraの良さについては、一つ前のブログにまとめているので気になる方はこちらをご覧ください。 tech.connehito.com なぜAurora移行を行ったのか 可用性を担保しながら、コストメリットが享受できる RDS for MySQL時代は可用性を確保する為に、マスター、レプリカ全て MultiAZ構成で組んでいました。しかし、MultiAZだとアクティブ-スタンバイ構成なので、スタンバイ機はトラフィックを捌かず寝ている状態になります。 Auroraにすることで、マスター - レプリカ間のフェイルオーバーが可能になり、全てのRDSインスタンスをアクティブに運用することで、同じマスタ

おはようございます。こんにちは。こんばんは。 高校野球が大好きなリードエンジニアの @itosho です。甲子園が終わってしまったので、夏も終わりです。 実は先日ひっそりとGoで書いたCLIツールをOSSとして公開したので、今回はその宣伝をさせていただきます。リポジトリはこちら！ github.com 何が出来るのか？ 一言で言うと「tagの作成とリリースノートの作成」が出来ます。はい、それだけです。 tagの作成 tagの作成と言ってしまえばそれだけなのですが、弊社のサーバーサイドのリポジトリはGitHubのmasterブランチにマージされたタイミングでステージング環境にデプロイされる運用になっています。 また、tagがpushされたタイミングで本番環境にデプロイされるようになっており、tag pushがデプロイ戦略において重要な役割を担っています。 もちろん、tagを追加してpushす

こんにちは。ママリのiOSアプリを担当している @kichikuchiです。 コネヒトでは定期的に社内のスペースを用いてコネヒトマルシェという勉強会を開催しています。 本ブログにて先日(2018/8/7)実施した第3回目のイベントの様子をご紹介します！ connehito.connpass.com 今回のマルシェのテーマ 今回のテーマは「iOS」です！ コネヒトマルシェは毎回テーマを変えていて、初回がAndroid、前回がwebフロントでした。 LTの様子 アプリの導入画面の実装 簡単まとめ ウォークスルー、コーチマークのライブラリは非常に多い 各種ライブラリを比較した結果自作した そもそも導入画面が本当に必要か？を考える必要がある Swift5のOwnershipでメモリ効率化 簡単まとめ ownershipはswift5に導入予定 メモリ管理をより高度に制御可能になる サーバーサイドs

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

こんにちは！「M-1グランプリやるなら教えてほしかったんだけど？」と思っている金城(@o0h_)です。 ちょっと寂しいので、最近読みました「ここは今から倫理です。」のリンクを貼ります。 ここは今から倫理です。 1 (ヤングジャンプコミックスDIGITAL) 作者: 雨瀬シオリ出版社/メーカー: 集英社発売日: 2017/11/22メディア: Kindle版この商品を含むブログを見る さて昨日は、英語が聴ける・話せるようになりたい・・・・と思っているところにガツンとくるトミーさんの記事でした。 引き続いてのAdvent Calendar Day16、わたくしからはSlackのbotの話でもいたします。 標準の「自動レスポンス」を再発明してリッチにする 皆さんも、自動レスポンス(という名前でいいのかな・・)は利用しているのではないかと思います。 設定画面で「キーワード」と「反応」を入れると反応

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

こんにちは！ 東京なのに周辺にポケストップが1つもない田舎に住んでいます、@fortkle です（世田谷公園の徒歩圏内に引っ越したいです）。 さて、みなさんはPHPアプリケーションのデプロイツールに何を使っているでしょうか。 今回コネヒトで Deployer というPHPで書かれたデプロイツールを採用したのですが、なぜDeployerなのかという理由と、実際に使っているおすすめの設定をいくつか共有したいと思います。 ※ Deployerのインストール方法や基本的な使い方を知りたい場合は既にインターネット上に良い記事がたくさんあるのでそちらを参考にしてみてください。 デプロイツール、どうする？ 今回、新しく小規模PHPアプリケーションをデプロイする機会があったため下記の条件で新しくデプロイツールの選定を行いました。 PHPのアプリケーションなので デプロイツールもPHP製のもの を採用したい

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

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