エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。普段はサービス開発やバッチ処理開発をメインにやっておりますが、チームSREに参加してからはこれに加えて担当サービスのインフラ管理、そしてクラウド移行に携わっています。 今回はそのクラウド移行の話そのものではないのですが、それと必ず絡んでくるインフラ設定に関してです。 アクセス元IPアドレスを知りたい Webアプリケーションがアクセス元IPアドレスを知りたいシーンというのは、大まかに二つかと思います。ログ記録用と、アクセス制限ですね。どちらもアプリケーションそのものではなく手前のWebサーバの責務のようにも思えますが、そうとも言い切れません。動作ログ、特に異常リクエストをはじいた記録なんかにセットでIPアドレスを付けたいとなるとアプリケーション要件ですし、アクセス制限についてもマルチテナントサービ

できません。 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 中村の記事で宣言したDocpediaの技術的チャレンジの記事も今回で最後です*1。 今回は、PCページとスマートフォンページで共通的に使用できるVue.jsコンポーネントをどうやったら実現できるかを考えて実装した例を紹介します。 仙台サンプラザ（せんだいサンプラザ）は、仙台市都心部東側の宮城野通に面してあるホール・ホテル・会議室などの複合施設。本文には特に関係ありません。 なぜレスポンシブにしたいのか? PCとスマホで共通のコンポーネントを使って工数を減らしたい 実例 構成 エントリー router AppModePlugin PCとスマホで処理を切り替える PCとスマホでデザインを分ける We are hiring! なぜレスポンシブにしたいのか? 冒頭のタイトルは、直接こう言われたのでは

こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 先日の中村の記事で宣言してしまったので、 今回は「医師版Stack Overflow」(仮名) のSpringBootのdockerイメージを 必要最小限にまで小さくする際に試したことをまとめました。 なお、ちょっと検索すると先人の記事が色々出てきますが、 当時はまだなかったdockerイメージや、JDKの機能の違いにより、今ではちょっと古い部分もあります。 今回の記事も、半年もしないうちに古くなると思うので、2019年9月時点での方法だと思って読んでいただけると幸いです。 メットライフドームは埼玉県所沢市にあるドーム球場。本文には特に関係ありません。 小さいdockerイメージのメリット イメージのサイズを小さくしたいと書きましたが、 そもそも、そのメリットをネットで調べてみてもあまり明確な答えは見つか

こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！ www.oreilly.co.jp 監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。 本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。 モニターリザード 各章の感想 「1章 監視のアンチパターン」について 「第2章 監視のデザインパターン」について 「3章 アラート、オンコール、インシデント管理」について 「5章 ビジネスを監視する」について 「6章 フロントエンド監視」について 「7章 アプリケーション監視」について

EF15形は高性能な電気機関車であったが、引き出し性能が蒸気機関車に劣ると誤解されていた。 誤った運転方法により本来の性能を引き出せていなかったのである。 （spaceaero2 [CC BY 3.0], ウィキメディア・コモンズより） こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 WEBサイトは RailsやSpringなどの「本体部分」だけでは完結しません。レポート作成・データ更新などの細かい処理も必要です。 過去にはこうした用途にはBashがよく使われました。しかし、Bashは落とし穴が多かったり、クラスなどの抽象化機能がなかったりして、規模が大きくなると辛くなります。 そこで、Bashの代替候補に挙がるのがPythonです。エムスリーでもかつてはBashを使っていましたが、現在は新規案件にはPythonを推奨しています。 しかし、実際にPythonで書き直そ

こんにちは、server-side kotlin や terraform を書くことが多い、エンジニアリングGの矢崎(id:Saiya)です。 タイムゾーンや日時の扱いについての話題がホットな昨今ですが、 そういった日時の扱いについて例えば以下のようなお話を受けることが少なからずありました: とりあえず日時は UTC からの時差情報付きで扱えばいいんでしょ？ DB に保存するときもタイムゾーン情報付きで入れておけばいいんでしょ？ こういったお話を振られた際に、思うところを一言でサッと説明できずもやもやする事もあり、 また web サービスにおいて日時・タイムゾーン・オフセットをどう扱うべきか？納得の行く説明をあまり見つけられなかったため、 筆者なりに考えをまとめてみました。 国家的祭典のために急にサマータイムが導入されるといった話に限らず、 クラウドサービスが UTC+0 の日時になってい