Private content!This content has been marked as private by the uploader.

There has been a shift in service based architectures over the last few years towards smaller, more focussed "micro" services. There are many benefits with this approach such as the ability to independently deploy, scale and maintain each component and parallelize development across multiple teams. However, once these additional network partitions have been introduced, the testing strategies that

2018/05/23 しがないラジオMeetup #1

Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.

Microservices play a major role in many organizations today. The movement gained momentum with the seminal article by James Lewis and Martin Fowler, followed by Sam Newman's book and numerous talks and articles by Thoughtworkers, folks from Netflix, Google, and many others. Microservices quickly made it to the Trial ring on the Thoughtworks Technology Radar, but they've never made it into the Adop

僕は数年前に改善グループってのを立ち上げて、部内の他のグループに行ってそこの改善を手伝うみたいな活動をしてる。開発の進め方の改善をしたり、アーキテクチャーの改善をしたり、他のグループの人どうしをつないだり、とか。そういう感じのこと。 そしたら、この前「うちの部署の改善活動の参考にしたいから、意見交換しようー」って、他の部署の人が話をしに来てくれて、そのおかげでぼやーっと感覚でやってた自分の頭の中が少し言葉にできたのでメモ。 良くないの こういうのは良くないよねーって話をしたのが。 上からの指示で改善活動をさせられてるけど意味分からん。 みたいなの。 良くないの２ でも、こういうのも良くないよねーって話をしたのが。トップダウンじゃうまくいかないから現場を中心にしよう！ってことで 「ぜひ自分たちで問題と思ってるところを出して、それを改善する方法を考えて、実施してください！」みたいなの。 結局そ

僕は、Javaのエンジニアだけど。全然JVMについて詳しいわけでもないし。技術トレンドのキャッチアップも、だいたい3,4年遅れてる感じあるし。Linux上でサービスを動かしてるけど、Linuxがどんな風に動いてるか分かってないし。 エンジニアとしてまだまだだなーって思うんだけど。 でも、そんな僕でも、結構役に立ってるように感じてはいて。だから、自分の強いとこってなんだろうなー？って考えると。こんな感じ： 事業部や編成部やプロデューサーと信頼関係を築いてお互いに同じものを見ながら開発できること 目の前でサービスを生き残らせるためにどんな技術的負債を受け入れないといけないかのトレードオフを考えること とは言っても、サービスを開発することの先にあるサービス運用を中心において開発すること メンバーじゃなくてチームとしての場が会社に残るようなチームづくりをすること 技術的に尖ってるって訳じゃないけど

What will you ask your audience?Turn presentations into conversations with interactive polls that engage meetings and classrooms.

背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う

頭の中にスタックが3つしかないからネストは3つまでがいいし。リンクを辿って色んなところに飛ぶと戻ってこれないし。こういう意味にも取れるけどどっちだろう？とかなるし。似たようなことが複数の箇所に書いてあると目diffをしてしまうし。気が散りやすいし。 自分にとって読みやすいドキュメントを書く だから、書くときは「自分が頑張らなくても読めるように」と思って書く。そしたら、他の人にとっても読みやすいんじゃないかと思って。 そんな風にして最近書いたドキュメントを褒めてもらって喜んだので、こんなこと気にしながら書いてるかなーと思うのをメモ。ふわっとした話。 誰にどうなって欲しいか？ 具体的に誰か一人を想像する。「全員にとって」ではなく「その人にとって」価値のあるドキュメントにする。 彼は、どうしてこのドキュメントを見たいと思ったのか？何に困っているのか？ 彼は、今どんなことを知ってるのか？ 彼は、こ

Java Advent Calendar 2016の16日目の記事です。 ※追記： Javaslangは、名称がVavrに変更になりました Javaで関数型プログラミングを行うためのライブラリとしてJavaslangが存在しています。 Javaslangは、Scalaの長所をJava言語にできる限り導入することを目的としています。 関数型プログラミング用のデータ構造や制御構造を提供してくれているようです。 関数型言語もモナドも詳しく理解していない私がとりあえず触ってみました。 利用準備 pom.xmlに以下を追加します。（今回のエントリを書くにあたってはバージョン2.1.0-alphaを使用しました） <dependency> <groupId>io.javaslang</groupId> <artifactId>javaslang</artifactId> <version>{javas

仕事で外部のエンジニアに依頼したドメイン移行が正しく動作していなかったため、良い機会と思いDNSについて調べました。 名前解決の方法 そもそも名前解決とは何かというと、ドメインとIPアドレスを紐付けることです。手法として以下の2つが上げられます。 /etc/hostsに直接対応を記述する方法 /etc/resolve.confにDNSサーバーのIPアドレスを記述し、問い合わせる方法 今回はDNSサーバーによる名前解決について説明していきます。 DNSによる名前解決 ドメインツリーによる負荷分散 全世界に無数に存在するドメインの解決を一台のネームサーバーで担当するのは不可能です。そこでDNSでは下記のように、各階層に意味を持たせ、下位のドメインを管理させることで分散型の構造を構築しています。 ドメインツリー キャッシュサーバーによる高速化 クライアントからDNSサーバーに対してドメインを問い