タグ

ブックマーク / www.m3tech.blog (14)

  • SpringBootのdockerイメージを必要最小限に絞りたい(2019年9月版) - エムスリーテックブログ

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

    SpringBootのdockerイメージを必要最小限に絞りたい(2019年9月版) - エムスリーテックブログ
  • pytest ヘビー🐍ユーザーへの第一歩 - エムスリーテックブログ

    蛇行区間にはレールの内側に脱線防止ガードが設置される(文とは関係ありません)。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小です。 pytest は Python のユニットテストのデファクトスタンダードです。エムスリーでも顧客向けレポートや機械学習Python&pytest をヘビー🐍1に使っています。 ですが、実は pytest は、意外と入門のハードルが高い。と言うのも、pytest の公式ドキュメント が、fixtureのような新概念も登場する上、詳細で分量が多いからです(しかも英語)。初心者にいきなり読ませると挫折する可能性大です 2。 そこで、とりあえず使い始めるのに必要そうな情報を日語でまとめました。 pytest ってどんなライブラリ? unittest や nose から簡単に移行できる 書き方がシンプル fixture モックもできる プラグイ

    pytest ヘビー🐍ユーザーへの第一歩 - エムスリーテックブログ
  • コンテナベースシステムのデザインパターンに関する論文紹介 - エムスリーテックブログ

    エンジニアリンググループ AI機械学習チームの笹川です。 今回は、コンテナベースシステムのデザインパターンに関する論文 Design patterns for container-based distributed systems について紹介します。 なお、この記事は、社内勉強会であるM3 tech talkで紹介した内容をまとめたものです。 M3 tech talkは、エムスリー赤坂オフィスで隔週で開催されている5-20分程度のLTを数件行う勉強会で、そのトークテーマの振れ幅は最近の数回でも筋トレ、型システム、3Dプリンタ、量子コンピュータなどこのブログの数段上で、個人的にも毎回楽しみにしています。 M3 tech talkは、外部からの参加・登壇も歓迎しています。興味のある方はぜひ以下からお問い合わせください。 jobs.m3.com 論文の概要 今回紹介する論文は、HotClou

    コンテナベースシステムのデザインパターンに関する論文紹介 - エムスリーテックブログ
  • Pythonのパッケージ周りのベストプラクティスを理解する - エムスリーテックブログ

    砲撃する自走砲(PzH2000自走榴弾砲)。自走砲は戦車によく似ていますが、戦車ではありません。*編とは関係ありません。 こんにちは、エムスリー基盤開発チーム小です。 Pythonのパッケージ管理周りでは、 「setup.pyでrequirements.txtを読み込むのが普通なんですよね?」 「pipenv があれば venv はオワコンなんですね?」 「pyenvは要らないんですよね!?」 「Python歴史が古い分、Rubyなどに比べてカオス」 みたいな混乱をよく目にします。 実際、複数のツールがあって(一見)複雑です。また「なぜこうした状況にあるのか」がドキュメント化されているわけでもありません。 なので、私なりに整理してみることにしました。 ※「追伸」を追加しました。この記事では汎用プログラミング言語としてPythonを使うケース(Webアプリとか、CLIツールとか、ライブ

    Pythonのパッケージ周りのベストプラクティスを理解する - エムスリーテックブログ
  • JJUG CCC 2018 Fallで登壇しました - エムスリーテックブログ

    この記事はエムスリー Advent Calendar 2018 の21日目の記事です。 こんにちは。エンジニアリンググループの滝安(@juntaki)です。 先日のJJUG CCC 2018 Fallで「エムスリーでのKotlinへの取り組み」と題して、スポンサーセッションで星川(@oboenikui)と2名で登壇しました。 発表内容 資料はこちら 構成は大きく3つに別れており、前半を私が、後半を星川が発表しました。 Kotlinとエムスリーの歴史 サーバサイドの取り組み Androidの取り組み 先日の記事にも書かれていますが、発表の内容は2016-2018年にかけての「Kotlin in エムスリー総集編」です。 全体として、Javaで作ってきたアプリをKotlinに置き換えるときの技術的なノウハウと、ビジネスを進めながら新しい言語・技術を導入するという汎用的な観点で役立つ事例を共有す

    JJUG CCC 2018 Fallで登壇しました - エムスリーテックブログ
  • この処理Pythonでどう書く? - エムスリーテックブログ

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

    この処理Pythonでどう書く? - エムスリーテックブログ
  • luigiのtargetを自分で書くための解説 - エムスリーテックブログ

    こんにちは、エムスリーエンジニアリングG AIチームなんでも担当の安田(@dasoran2)です。最近 Hearts of Iron IV で世界対戦に勤しんでいます。 なにやらluigiが流行っているらしいので、一部カスタマイズをしました。 記事はluigiの家のコードのざっくりとした(Targetに必要な部分の)概要とやり方についてです。 なお、文中のコードはコメントの削除等いくつか加工しています。 luigiについて luigiはspotifyの開発しているワークフローフレームワークです。 github.com 詳細や使い方などは以前他の方が書いた記事を参照してください。 www.m3tech.blog luigiのファイル構成を眺める 早速ですがluigiリポジトリの構成を眺めて行きましょう。 luigiのリポジトリはざっくり以下のようになっています。 / luigi/: l

    luigiのtargetを自分で書くための解説 - エムスリーテックブログ
  • 機械学習で便利なluigiフレームワークの紹介 - エムスリーテックブログ

    AI機械学習チームリーダーの西場(@m_nishiba)です。 チームの機械学習系の開発にパイプラインフレームワークとしてluigiを使っています。 (実際にはluigiをラップしたようなモジュールを作っています。そのうち公開しようと思っています。) 今回は、luigiの使い方について紹介しようと思います。 (luigi==2.7.5で動作確認を行っています。) 基的な使い方 Taskの基的な書き方 luigiのタスクを作るには、luig.Taskを継承し、下記3つのメソッドをオーバーライドすれば良いです。 requires() 依存している他のTaskを返します。このタスクのrunが呼ばれる前にこの関数が返すTaskのrunが呼ばれます。 戻り値はTaskやTaskのlist, dictとなります。 run() Taskの実行ロジックを定義します。inputとして、requires

    機械学習で便利なluigiフレームワークの紹介 - エムスリーテックブログ
  • エムスリーSREチームのご紹介 - エムスリーテックブログ

    こんにちは。エンジニアリングGでSREチームのチームリーダーを務めている池田(@progrhyme)です。 以前のエンジニアリングG内には、システムインフラの構築・運用を主に担当する「インフラチーム」が存在していましたが、今年の7月から改称して「SREチーム」と名乗ることにしました。 以降では、SREチーム設立の経緯や、その役割、ミッション等について記します。 SREとは SREは「Site Reliability Engineering」の略で、2003年にGoogleで誕生したSREチームが実践してきたプラクティスに基づくシステム運用の新しい形です。 2016年にO'Reillyから同名の書籍が出版されたことで、IT業界を中心にその考え方やメソッドが広く普及していったと思います。 SRE(= Site Reliability Engineer)が単なる運用チームと異なるのは、彼らがソフ

    エムスリーSREチームのご紹介 - エムスリーテックブログ
  • bashスクリプティング研修の資料を公開します - エムスリーテックブログ

    こんにちは、エンジニアリングGの中村です。 以前にこのブログにてエムスリーでの社内研修について紹介しました。今回は、この中でのbashスクリプティング講座の資料を公開します。 www.m3tech.blog 弊社の中でもいろいろな用途でbashが使われていますが、bashは簡単に利用できるもののプログラミング言語としてはバグを生みやすい、辛い言語だと思います。 ここで紹介しているのはいわゆるコーディング規則というよりも、バグ防止と可読性向上のためのルールをTips集的にまとめたものです。 bashにおいてまだまだ注意するところはありそうですが、多少なりともわかりにくいスクリプトの削減になればと期待しています。 [追記: 2018-08-22] はてブにて以下のコメントをいただきました。 bashスクリプティング研修の資料を公開します - エムスリーテックブログ bashで50行以上になった

    bashスクリプティング研修の資料を公開します - エムスリーテックブログ
  • エムスリーのサービスレベル監視基盤を構築した話 - エムスリーテックブログ

    こんにちは、エンジニアリングGの高橋です。 去年の11月にエムスリーにSREとして参画してから、サーバのセットアップ作業などの基的なインフラ作業に加えて、各サービスのサービスレベルの設定や監視の仕組み作りなども行ってきました。 今回はそのサービスレベルを監視する仕組みをご紹介したいと思います。 稿の流れ SLI設定 SLO設定 各種メトリクスの収集 アラーティング 監視ダッシュボードの作成 まとめ 全体像 ざっくりとした全体像としては上図のような感じです。 また、この取り組みを実施した前後で、下のような変化(効果)がありました。 前 ログの収集はしているが、全サービスでは取れていない ログの収集経路がサーバによって異なる(Service AからElasticsearchとかもあったり) 後 全サービスのアクセスログを収集・閲覧可能 ログの収集経路を共通化 ほとんどのサービス(70以上)

    エムスリーのサービスレベル監視基盤を構築した話 - エムスリーテックブログ
  • タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ

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

    タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ
  • フロントエンド向けの API サーバリニューアルに GraphQL を検討している話 - エムスリーテックブログ

    エムスリーでマルチデバイスチームのチームリーダーをしている松原@ma2geです。 マルチデバイスチームはこちらのテックブログでは初出なので簡単に紹介すると、iOS や Android 等のデバイス対応を主導する開発するチームで、主に iOS, Android のネイティブアプリ開発から、アプリから叩く API サーバ(いわゆる Backends For Frontends(BFF))、プッシュ通知基盤システムのバックエンドサービスも開発しております。 私自身は3月までは別チームで Rails/Java/Elixir などを触っていましたが、4月から現チームに移動しこちらでもまた新たな挑戦をさせてもらっています。 💪 前提 今回はネイティブアプリ向けの RESTful な API サーバがレガシーとなっており、このサーバのリニューアルを検討している話を書きます。 対象のサーバはフレームワー

    フロントエンド向けの API サーバリニューアルに GraphQL を検討している話 - エムスリーテックブログ
  • GraphQL入門 - React.js & Express.js & Apollo の簡単チュートリアル - エムスリーテックブログ

    M3 ではグローバル CTO の Brian が、サービスの海外展開や技術基盤の共通化などを積極的に進めています。その中のプロジェクトの1つとして、アメリカで提供している医療ニュースのリニューアルにチャレンジしています。2018 年 5 月には日オフィス所属のイギリス人エンジニア @christophrowley と日人のエンジニア (筆者)が 1 ヶ月ほどニューヨークに出張してリニューアルの検討をしてきました。 ( ↑ Chrisが撮影してくれた NY の写真 ) 今回の記事は、リニューアルで採用を検討している GraphQLApollo + JavaScript で作るチュートリアルです。 TL;DR Apollo を使って、クライアントサイド、バックエンドを作るチュートリアルを紹介 英語海外での開発に挑戦したいエンジニアを絶賛募集中です。もし興味があればランチ行きましょう

    GraphQL入門 - React.js & Express.js & Apollo の簡単チュートリアル - エムスリーテックブログ
  • 1