マイクロにしすぎた結果がこれだよ！
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
mruby + ngx_mrubyでアプリケーションを実装するという選択肢 - LIFULL Creators Blog
はじめまして、技術基盤部の相原(kaihar4)です！ 今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能 をmrubyで書き直してAWSに移行した話をしていきたいと思います。 この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRuby
33歳でアーリーリタイヤしたエンジニアが「技術力以外」の大切さを説く理由～『SOFT SKILLS』著者に聞く - エンジニアtype | 転職type
2016.07.28 働き方 プログラミングに関してズバ抜けた能力を持つエンジニアが、とあるシステムを作ったとしよう。コードは可読性が高く、最新のフレームワークを使いこなしてもいる。 にもかかわらず、ユーザーには不評で、ほとんど使われずに放置されているというケースを見たことがあるエンジニアは案外少なくないのではないだろうか。 一方、この世界では、技術力の面で平均かそれ以下のエンジニアたちが作ったシステムがユーザーから好評を得たというケースもままある。この2つのケースで、違いを生んでいるのは何なのか？ 実は開発担当者がユーザーの下に足しげく通ってサポートしていたり、ユーザーの声をつぶさに拾い上げながら機能開発をしていたなどと、「技術力以外」のところに理由があったりするものだ。 個人のキャリアでも、似たようなことがよく起こる。「技術的に優秀」であることと、「技術者として優秀」であることはイコー
Yumのセキュリティプラグイン | DevelopersIO
はじめに 藤本です。 みなさん、yumのことを「ヤム」と呼んでいますか？「ユム」と呼んでいますか？ 私は10年間「ユム」と呼んできましたが、先日、Wikipediaを覗いたところ、 「ヤム」と記載されていて、絶賛矯正中ですが、10年の月日は長かったようです。 なかなか治りません。。 そんなことはさておき。 先日、弊社メンバーに「yum-security」というYumのsecurityプラグインの存在を教えていただき、調べてみたのでご紹介させていただきます。 概要 みなさん、ミドルウェアの脆弱性対応をどのように取り組んでいますか？ 当ブログでも脆弱性情報の得方、脆弱性の対応方法についていくつかご紹介しています。 Linuxで脆弱性が見つかった場合の対応方法 まとめ 脆弱性対応は本気で取り組む場合、日々発信される脆弱性情報のウォッチ、脆弱性の対応要否判断、対応方式の検討、パッチ適用検証/影響確
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
