Members of OpenTracing made a New Year’s Resolution in 2018 to communicate the progress made by the project regularly and consistently. To that end, this is the first of many posts to come. Read on to learn about what happened in and adjacent to OpenTracing in the month of January 2018. OpenTracing Project UpdatesDataDog, New Relic, Instana, and Skywalking Joined the OpenTracing Specification Coun
Announcing Spring Cloud GCP—integrating your favorite Java framework with Google Cloud For many years, the Spring Framework has been an innovative force in the Java ecosystem. Spring and its vast ecosystem are widely adopted, and are among the most popular Java frameworks. To do more for developers in the Spring community and meet our developers where they are, we’re announcing the Spring Cloud GC
This article contains a short reminder of what Contract Testing is, how Spring Cloud Contract implements it, and how Spring Cloud Contract can be used in a polyglot world. What is Contract Testing In order to increase the certainty that our systems behave properly, we write different types of tests. According to the test pyramid the main types of tests are unit, integration, and UI. The more compl
20191105 AWS Black Belt Online Seminar Amazon Route 53 Hosted Zone This document discusses DNS and Amazon Route 53. It begins with an overview of DNS records like NS, A, AAAA, CNAME, PTR and MX records. It then covers DNS concepts such as the domain name system, domain name registration and resolution. The document also discusses how Route 53 can be used to configure DNS settings across public and
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか? リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか?おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
僕は千葉県出身なのだが、そんな地元民の間でも地味な扱いの「君津市」。しかし、この君津は全国まれに見る大移住があった。 1960年代後半に八幡製鉄(のちの新日鉄)が君津に大規模な新工場を完成、工員やその家族などおよそ2万人もの北九州人がやってきた、日本史上にも残る「民族大移動」。 君津ではもっぱら北九州の方言が使われ、九州料理が出すお店がたくさん登場し、九州カルチャーが街を占拠した。当時、君津は九州だったのだ。 しかし、今は移住が本格化したときから50年も経った。そんな「リトル福岡」の今はどうなっているのかをこの目で確かめたい。 僕はバスタ新宿から1470円の高速バスで、アクアラインから房総半島を目指した。 ライター、番組リサーチャー。過去に秘密のケンミンSHOWを7年担当し、ローカルネタにそこそこくわしい。「幻の○○」など、夢の跡を調べて歩くことがライフワークのひとつ。ほか卓球、カップラー
初めまして。サイバーエージェント技術本部インフラエンジニアの@prog893です。今回は「AWA」という音楽ストリーミングサービスのMongoDBクラスタの復旧時間を短縮するために行ったインフラの改善について紹介したいと思います。復旧時間が12時間から55分まで短縮できたのですが、皆さんの参考になれば幸いです。(※注意:今回紹介する施策はAWAのインフラ構成や設定のものであり、他の環境で同じような効果が得られるとは限りません) AWAのデータストア構成 まず、現在のデータストア構成について軽く説明します。こちらの図でAPIサーバ,MongoDBに関連する構成の概要を示します: AWAのデータストア構成概要 メインのデータストアとしてはMongoDBを使っており、MongoDBのインスタンスはAWSで管理しています。APIサーバ、MongoDBのインスタンスがそれぞれのプライベートサブネット
Double O というサービスを作りました。 フロントエンドはピュアな Web Components を採用していて、バックエンドは Lambda と DynamoDB のみで構成しました。 (厳密には CloudFront とか API Gateway とかもあるけどそこは省いていいよね?) REST API 以外の Util 系の Lambda 関数はすべて AWS Cloud9 で管理することで環境構築も不要な Lambda ができて楽でした。 TL;DR サーバーレスについてはごく普通のことしかしていないので、詳しくは触れないでおきます。 ピュアな Web Components だけでサービスを成立させることができた。 HTMLElement クラスを継承するだけなのでメジャーライブラリは不要になった。 Web Components の Custom Elements は標準仕様
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く