去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて

「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ

今度はSpinnakerに興味を持ったので、ローカルのminikubeでやろうとしたけどできなくて、GKEのチュートリアルでやってみたメモ。さくっと終わるつもりだったのにいつも通り色々あったかな。 Spinnaker Continuous Deliveryツール。チュートリアルやって動いた、程度なので中身は全然理解してない。 www.spinnaker.io @deeeetさんの記事見て興味を持ちました。 tech.mercari.com 見た目好き。 minikubeでやってみよう→失敗 ローカルのminikubeで動かしてみようと思って、ここを見ながらhelm入れるところまでいって、その後Spinnaker入れようとしたらできなかった。もうエラーの内容も覚えてないけど、バージョンの違いとかなんだろうかな。 thenewstack.io ここで時間かけて原因をチェックするより、とりあえず

昨日はこんな感じでIstioとそのサンプルプロジェクトであるBookinfoをGKE上にデプロイしたので、それを使って今日はIstioのルーティングをごにょごにょやってみる。雰囲気で。 bufferings.hatenablog.com やること Istio / Intelligent Routing に書いてある3つのタスクをやる。 Istio / Configuring Request Routing Istio / Fault Injection Istio / Traffic Shifting Bookinfoのつくり サンプルプロジェクトのBookinfoの画面はこんな感じ。 つくりは https://istio.io/docs/guides/bookinfo.html に説明があるんだけどこんな感じ。Envoyってのがサイドカーコンテナとしてアプリの隣にデプロイされてて、そいつ

と思ってここを読んでみたら面白かった。 kubernetes.io 理解したことをざっくりと書くと コンテナレベルからクラスタレベルへ Dockerからログを出力したとして、コンテナがクラッシュしたりノードが落ちたりしたときでもログは見られるようにしときたいよね。だから、ログの保存先は別にしといて、コンテナとかノードとかとは違うライフサイクルで管理したい。てのがクラスタレベルロギングって呼ばれてるコンセプト。 クラスタレベルロギングの前に基本とノードレベルの紹介から。 k8sのロギングの基本 コンテナから stdout とか stderr に出しとくと kubectl logs で見られる。 ノードレベルのロギング (Image from https://kubernetes.io/docs/concepts/cluster-administration/logging/ ) コンテナから

2,3日前にこういうのを書いたんだけど bufferings.hatenablog.com irofさんと喋ってたら「yyyyじゃなくてuuuu使わなきゃとかもありますよねー」って言われて「え？そうなんだっけ・・・あれー？全然知らない！・・・ような、頭の隅にあるような・・・」ってなって、調べといた。 どういうこと？ https://docs.oracle.com/javase/jp/8/docs/api/java/time/format/DateTimeFormatter.html yyyyは暦に対する年(year-of-era)、uuuuは暦とは無関係な年(year)。なんだって。 year-of-eraって何？ day-of-monthが、月始まりからの日にちだから、暦始まりの年ってことなんだろうな。ふむー。イマイチぴんとこない。から、やってみよう。 普通に書くとこうか。 @Test

この辺とか読みながら→ Introduction — Confluent Platform 3.1.0 documentation Twitter4Jで適当に英語のツイートをとってきて、Kafkaに流し込む。(キーとかの設定はtwitter4j.propertiesに入れておいた) @Component public class TwitterToKafka implements CommandLineRunner { @Autowired private KafkaTemplate<String, String> template; @Override public void run(String... args) throws Exception { TwitterStream twitterStream = new TwitterStreamFactory().getInstance

ここに書いてあるとおり、DC/OS UniverseにDatadogがあるのでAPI Keyを設定して有効にするだけ。 docs.microsoft.com そしたらグラフが出てきた（喜 全く分かってないけど、見た目には満足した。

同僚から「Spring Bootのこと教えてー」って声かけてもらったので、社内勉強会でこぢんまりと喋ってきた。 Spring Bootのコンセプト Springがコードレベルの、Spring Bootがアプリレベルの、Spring Cloudがサービスレベルの、みんながやることやっとくよ。な感じ。 ってつぶやいたらまきさんから @bufferings そういう話を非技術系の人によくしています。この図使ってますhttps://t.co/4RyLJzo1JS— Toshiaki Maki (@making) 2017年3月1日 って教えてもらったのでスライドを紹介しときました！あざます！ Spring Bootでおさえておくべき3つのこと 最初はどこまでがSpringでどこからがSpring Bootなのか分かってなくて「めっちゃ色々あって魔法みたいでよく分かんない・・・(ヽ´ω`)」ってなっ

この牛尾さんの記事からまだ1年半くらいしか経ってないのに、もうほんとに色々と変化の流れが速すぎて、僕はもう少し枯れたところでどんぐり拾いみたいなのするのが好きなのに、どうしてこうなった感。 qiita.com 僕のこの記事自体ももう来年には古くなってるんだろうな。あ、なので、2016年10月現在の情報ですので注意してくださいー。 Microservicesの素振り環境 Microservicesって仕事でいきなり「やってみたい！」って言って導入できるようなもんじゃないなって思って。技術力も運用力も組織力も、色んなもののレベルが高くないとひどく失敗してしまいそうだなって。とはいっても、結構色んな問題を解決してくれる一面もありそうだから、まずはどんなものなのか、技術的に少し体験しておきたい。というのが動機。 Javaが好きなので、Spring Cloudで作ったアプリをDockerに入れて、複

社内の勉強会でなんかしゃべれーってことになり。なんとなくSpockがどっかで気になってたので、SpockどころかGroovyすら触ったことほぼないですけど、ドキュメントをサラーっと読んで面白いなーと思うところをSpock Web Consoleで動かしつつ紹介してみたりしました！復習がてらもういちど読んでみまする。 Spock Web Console http://meetspock.appspot.com/ SpockBasics https://code.google.com/p/spock/wiki/SpockBasics Example 全体はこんな感じかな。読みやすいね。 class MyFirstSpecification extends Specification { def "pushing an element on the stack"() { setup: def s

ども。楽天大阪開発部の椎葉です。Regional Scrum Gathering Tokyo 2016 に仕事として行かせてもらいましたー！ まねーじゃ「行きたいんやろ？なら行こうよ？」 おれ「えー！」 かわぐちさん「話聞きましたー。社内の手続き済ませといたよ」 おれ「えー！(｀；ω；´)」 そんな感じ。幸せ。 1日目が終わってホテルに到着。明日も楽しみだなー。今日は雪の中がんばって歩いたりして間に合ったよ。そんなこんなで、RSGT1日目面白かったやで。メモ。 1時間目: The Story of LeSS BasのLeSSのお話。 "色々ルールとかで「こうしたらいいんやで！」みたいなのを言うの好きくなくて「こんな風にやってみたんやで！」みたいなのを伝えた方がいいんかなーって思ってるんだけど、やっぱり始めたばかりの人にはルールがある方が入りやすいってことみたいなんで、ルール書いといたよ！"

Jersey2がどんな風にHK2を使って、DIをコントロールしてるんだろう？って気になって。なので、Jersey2のソースコード読んでみることにしました。何か分かんないことがあっても、うらがみさんがいるから、安心(๑•̀ㅂ•́)و✧ ApplicationHandlerのinitializeとapply読むのおぬぬめ！— うらがみ (@backpaper0) 2015, 12月 12 まずはゴールと、やらないことから。 ゴール リクエストが来てからレスポンスを返すまでの基本的な流れを理解する。 やらないこと Jersey2やJAX-RS 2.0全体の読み込みは、やらない。 はじめる前に HK2って？と思って。さすがはすぬまさん、めっちょ分かりやすい。 HK2 の使い方（前編） - Programming Studio HK2 の使い方（後編） - Programming Studio Se

自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる