これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
読みやすいコード（僕にとって） - Mitsuyuki.Shiiba
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
Schema Registryについて - Mitsuyuki.Shiiba
昨日の続き。 bufferings.hatenablog.com Avroを使ってメッセージをシリアライズ・デシリアライズするのに、スキーマを保存しておいてくれる場所があると便利だよなーってことで、Schema Registryが(僕の中に)登場。 Schema Registry? Schema Registry — Confluent Platform 3.2.2 documentation Avroのスキーマを保存したり取得したりするためのRESTfulなインターフェイスを持ってる。スキーマのバージョンを保存してるので、スキーマエボリューション的な用途で使えるっぽい。僕は、まだスキーマエボリューションについては勉強してないので、「ふーんバージョンがあるんだね」ってくらい。 Confluent Platform? Kafkaを作ったチームがConfluentって会社を立ち上げて、Kafk
Avroについて - Mitsuyuki.Shiiba
昨日、関ジャバで喋ったのしかったよー(∩´∀｀)∩ bufferings.hatenablog.com その発表のために色々と新しいことを学んだので、ちょこちょこ気が向いたときにアウトプットしておこうと思う。数カ月後に全て忘れているであろう自分のために。 てことで、今日はAvro。余談ですが、勉強会に行くと勉強になるけど、勉強会で登壇するともっと勉強になるからおすすめです！ Avroとの出会い 同じ学年にAvroさんという人がいるのは知ってたけど、違うクラスだから喋ることもないかなーって思ってたくらいの距離感(なんの話？) 名前を初めて聞いたのは、去年のSpring Oneに行った時。Spring Cloud StreamでData Microserviceだー！って言葉が押し出されてて。Avroの名前がでてきてたのはSchema Evolutionという文脈の中だったなという印象。「メッ
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
もっと瞬殺で作るMesos + Marathon + Dockerクラスタ環境 on Azure - Mitsuyuki.Shiiba
この牛尾さんの記事からまだ1年半くらいしか経ってないのに、もうほんとに色々と変化の流れが速すぎて、僕はもう少し枯れたところでどんぐり拾いみたいなのするのが好きなのに、どうしてこうなった感。 qiita.com 僕のこの記事自体ももう来年には古くなってるんだろうな。あ、なので、2016年10月現在の情報ですので注意してくださいー。 Microservicesの素振り環境 Microservicesって仕事でいきなり「やってみたい！」って言って導入できるようなもんじゃないなって思って。技術力も運用力も組織力も、色んなもののレベルが高くないとひどく失敗してしまいそうだなって。とはいっても、結構色んな問題を解決してくれる一面もありそうだから、まずはどんなものなのか、技術的に少し体験しておきたい。というのが動機。 Javaが好きなので、Spring Cloudで作ったアプリをDockerに入れて、複
僕がよく使うGitコマンド14個 - Mitsuyuki.Shiiba
僕がよく使うGitのコマンドの整理をしておこうと思った。 1. git clone リポジトリから取ってくる まずはcloneするよね。手元にあってちょうど良い感じなのがmakingさんのjsug-shopだったので、これで進めてみる。 $ git clone git@github.com:bufferings/jsug-shop.git Cloning into 'jsug-shop'... remote: Counting objects: 299, done. remote: Total 299 (delta 0), reused 0 (delta 0), pack-reused 299 Receiving objects: 100% (299/299), 427.05 KiB | 193.00 KiB/s, done. Resolving deltas: 100% (96/96),
お気軽Ansibleはじめ - Mitsuyuki.Shiiba
Ansibleを使ってみようかなと思って Ansible が使える Vagrantfile を作っといた。 github.com Ansible Local Provisioner Ansibleトライするのに、Macにインストールせずにやりたいなって思って。Vagrant 1.8で導入されたAnsible Local Provisionerを使うことにした。 shin1x1.hatenablog.com Ansible 2.0を検出できない でも、なんか、Ansible 2.0でなんか変わったみたいで、Ansible Local ProvisionerがAnsibleを検出できないみたいね。こんなエラーがでた。 default: Installing Ansible... The Ansible software could not be found! Please verify tha
Vagrant 1.8 で追加された Snapshot 機能を触ってみた - Mitsuyuki.Shiiba
今朝、Vagrant + Ansible Local Provisionerで遊んでた。 bufferings.hatenablog.com 最後に「snapshot機能が追加されたんだったっけー？」とか思って気になったので調べた。 1.8で追加されてた 結論から言うと、1.8で追加されてた。 vagrant snapshot - Command-Line Interface - Vagrant by HashiCorp クラスメソッドさんの紹介記事を見てsnapshot機能が印象に残ってたんだな。 Vagrant 1.8の新機能 Linked CloneとSnapshotを試してみた ｜ Developers.IO snapshotコマンド push&popとsave&restoreの2系統ある。 push & pop 名前から考えたらスタックかな。 vagrant snapshot p
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
技術的負債の返済より前に - Mitsuyuki.Shiiba
サービスの保守とかしてて、あーやっぱり長年つぎ足されてきた秘伝のタレコードは読みにくくて大変だなー。って。ちょっとずつリファクタリングするのを楽しんだりする。 だから、なんとなく、技術的負債ってのは、そういう長年の継ぎ足しの中で生まれてくるもんだと思い込んでた。のだけど。 そういえば、僕はここ数年で、新規プロジェクトに何度か関わってて、振り返ってみると、あれ？最初から負債を抱えてたな…。 つまり、負債ってのは、経年劣化だけじゃなくて、コードが書かれた瞬間にも存在するってことか。そりゃそうか。ふむ。 じゃあ、こういうこと？ チームには負債を生み出すポテンシャルみたいなものがあって。その負債ポテンシャルが高いチームは、新規開発だろうと、追加開発だろうと高い負債を生み出すのだ。 そうか。｢このチームで負債を返していきたいね｣って勝手に思ってたけど、技術的負債の返済より前に、まずこのチームの負債ポ
チケットの粒度 - Mitsuyuki.Shiiba
娘を寝かしつけるのに一緒に眠ってしまったあとに目が覚めて眠れないので明日朝早いので眠くなるといいなぁと思いつつブログ。 チケットの粒度について しばらく試行錯誤してたんだけど、てか、もう2年くらいあーでもないこーでもないってやってた気がする。 のだけど、いったんここかなというところを見つけられたっぽい。エッセンシャルスクラム読んだの大っきい。 スクラムスタイル で開発してるので。ユーザーストーリー中心のバックログなのだけど。 ユーザーストーリーはストーリーポイントを持っていて、リリースプランニングに使っている。 ユーザーストーリーをスプリントバックログに入れるときに、タスクに分割して時間見積もりをする。という感じ。 なのだけど ユーザーストーリーが「リリースできる単位」って考えると大きくなってしまって。より大きい概念が欲しいなーと思ってエピックを使ってみたら、思ったよりユーザーストーリーを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
