マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件 - Qiita
はじめに 世の中的に企業のデジタルトランスフォーメーション(以降DXと略)にどう取り組むべきか？というプレッシャーが日々高まっている昨今、皆様いかがお過ごしでしょうか。 DXに取り組むためには、システムのアジリティ(いわゆる俊敏性)を高める必要があると言われており、世の中的にはそれに求められるナレッジが確立されつつあります。その代表格である「マイクロサービスアーキテクチャ」が2014年に提唱され、そろそろ日本でも普及期に入る段階であると理解しています。 マイクロサービスアーキテクチャは最近までデジタルネイティブな企業が使いこなす道具という認識でしたが、2018年3月にコンテナオーケストレーションツールの KubernetesがCNCFを卒業した ことに伴って、エンタープライズ市場にもマイクロサービスアーキテクチャ採用の機運が高まりだしているように思います。 マイクロサービスアーキテクチャは
フロントエンドの開発環境に Docker は不要(少なくともMacでは) - mizchi's blog
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
Publickeyを始めてからちょうど10年になりました。ご愛読ありがとうございます。そして今後ともよろしくおねがいします。
Publickeyを始めてからちょうど10年になりました。ご愛読ありがとうございます。そして今後ともよろしくおねがいします。 おかげさまで、Publickeyを2009年2月に公開してから今日がちょうど10年目の日となりました。 個人が運営するブログメディアとして10年ものあいだ続けられることができたのは、記事を読みにPublickeyへ訪問していただいた数多くの読者のみなさまのおかげです。ありがとうございます。また、記事を書くためにいつも情報を提供いただいているベンダのみなさま、コミュニティや技術者のみなさま、他のメディアのみなさまにも感謝いたします。 と同時に、売り上げを支えてきていただいたクライアントのみなさま、代理店のみなさまにもお礼申し上げます。 Publickeyを立ち上げた2009年は、まだAmazon Web Servicesの国内での知名度はなく、Google App E
Webpackで行っていることを順番に試して、webpack-dev-serverで確認したメモ - Qiita
version: '3' services: # ビルドツール webpack: build: ./webpack volumes: - ./config/webpack/.babelrc:/app/.babelrc - ./config/webpack/elm.json:/app/elm.json - ./config/webpack/tsconfig.json:/app/tsconfig.json - ./config/webpack/webpack.config.js:/app/webpack.config.js - ../src/:/app/src - ../app/public:/app/dist - ../bkup:/bkup - ../dist/html:/app/html environment: - NODE_ENV=develop command: [yarn, sta
依存パッケージを更新するサービス「Dependabot」で Dockerfile の更新をチェックする - kakakakakku blog
Dependabot は依存パッケージの更新を定期的にチェックし，更新があった場合にプルリクエストを作成してくれるサービスで，現時点で「Ruby, JavaScript, Python, PHP」など，多くのプログラミング言語がサポートされている．他にも「Go, .NET」などは BETA & ALPHA 版でサポートされている．依存パッケージの更新が重要なのはわかっていても，月に1回など，定期的なイベントとして実施しているチームも多いと思うので，Dependabot を使うメリットがある． dependabot.com Dependabot 以外だと Greenkeeper や Tachikoma.io を使っているチームもあるし，CircleCI などと組み合わせて独自実装で実現しているチームもある．あえて自動化はせず「チームメンバーの教育目的で手動で依存パッケージを更新する」というチ
Webpackerへの移行を機にフロントエンド開発を改善 - メドピア開発者ブログ
こんにちは。メドピアでエンジニアをしている村上(pipopotamasu · GitHub)です。 普段はRailsを触っていますが、時々フロントエンド周りの開発もしています。 今回はメドピアの環境におけるWebpacker導入とフロントエンド周りの改善をテーマに記事を書きます。 目次 なぜWebpacker(Webpack)を導入するのか? フロントエンド改善計画 Webpackerの導入で気をつけたこと github.com なぜWebpacker(Webpack)を導入するのか? Webpackerを導入する背景として、主に2つの課題がありました。 JavaScriptのビルド時間が長い パッケージのバージョン管理ができない JavaScriptのビルド時間が長い 元々メドピアのフロントエンド開発においてBrowserifyというbundlerを使用していました。 しかし、これにはビ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Patreon logo