はてなブックマーク

ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)

連休の余韻も楽しんだので今日から散歩を再開した。ちょっと前までは「陽の光を浴びなきゃ！」と思って3時過ぎにウロウロしてたけど、これからはもうちょっと涼しい時間帯がいいなと思って、夕暮れ時に散歩しながら fukabori.fm を聴いてた。Value Object のお話。面白いなぁ 73. Value Object w/ kumagi | fukabori.fm kumagi さんの記事はこちら Value Objectについて整理しよう - Software Transactional Memo お絵描き PoEAA や DDD はだいぶ前に読んだことがあるけど、Value Object を雰囲気で捉えてるからちゃんと見直しておこうと思って、調べたりしながら絵を描いた。こういうことなのかな？ （絵をかくほどでもなかった・・・ Value Object とは？ kumagi さんも書いてる

ペアでやろうよー！ チーム内で知識を共有できるように、フルリモートでも一緒に仕事できるように、チームとしてプロジェクトに取り組めるように、「ペアでやろうよー！」ってなって「それいいねー」って思って、最近はペアで仕事をしてる そして、何年も前からうすうす感じてはいたんだけど、やっぱり、僕はペアプロが苦手だった！ので、ペアプロじゃなくてペアワークしてる ペアプロ？ペアワーク？ 「ペアプロ」は「ペアプログラミング」のこと。一緒にコードを書く。リモートワークなのでペアプロするときは、Zoom とかで画面をシェアしながらコーディングしてる 参照 → https://martinfowler.com/bliki/PairProgramming.html 一方「ペアワーク」って言葉は、正式な定義があるわけじゃなくて、自分がそう呼んでいるだけなんだけど「ひとつのタスクを二人で担当する」こと なんで苦手なん

昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている

前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br

CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン

僕は Java のウェブアプリケーションエンジニアなんだけど、ちょっと前は色んなチームに入ってサポートをしていてそれぞれのチームが使っているプログラミング言語が違ったり、今は新しい場所で違う言語でコードを書こうとしていたりで、この4,5年間は新たにプログラミング言語を勉強する機会に恵まれていて楽しい。 そういう勉強をしながら、ある程度自分の中に新しくプログラミング言語に入門するときの流れみたいなものができてきたなぁと思ったので書いてみる レベル と、その前に、自分の Java のレベルを Lv.20 としたら Java (Lv. 20) → 読み書きできる。プロジェクトの土台を作ることができる。Generics は雰囲気で触っている。JVM のことはあまり良くわからない。セミコロンなしでは書けない。 こんな感じなので、レベルを考えてみると、こうかなぁ？適当だよ Lv. 0 → 知らん Lv

最近 Clojure の勉強を始めてて FizzBuzz 書いて遊んだりしてる Clojure の勉強をしつつ FizzBuzz で息抜き - Mitsuyuki.Shiiba そして Clojure のアドベントカレンダーが空いてたから書くー Calendar for Clojure | Advent Calendar 2021 - Qiita 息抜きにどうぞー re:Clojure Conference 2021 re:Clojure 2021 のレコーディングがあったから、ぼーっと眺めてて、へー Notebook あるんだー便利そうーとか、難しい話はよく分かんないなーとか、飛ばしたり止めたりしつつ楽しんでたんだけど、Vlojure は見た目が面白いなーって思ったのだった ↓Vlojure のセッションの時間含めたリンク https://www.youtube.com/watch?v=

こんばんは。しーばです。この記事は Calendar for CircleCI Advent Calendar 2021 | Advent Calendar 2021 - Qiita の17日目の記事です。ほんとは明日に書くつもりだったけど、空いてたから今日書くことにした。 16日目は、ふなっきーの 緑(Succeed)と赤(Failed)を区別する - よりinclusiveなCircleCIを目指して - Qiita でした。なんか Failed の色が変わったなぁって思ってたら、カラーユニバーサルデザインに対する取り組みで、僕は全然詳しくなかったんですけど、そういう取り組みをしてるのって良いなって思いました。 さて、今日は CircleCI の Year End Party で東京に来てました。 オフィスに来たらヒューガルデンが無限に出てくる pic.twitter.com/k7OO

2021-12-14 更新 ======= Resource Class Pricing のページの情報が正しいと確認がとれました。Free プランでも、例えば Docker Executor の Medium+, Large が利用できるようになっているとのことです Docker Layer Caching (DLC) Free プランでも DLC が利用できるようになったと確認が取れました なので、このブログの絵の DLC は黄色の箱から白の箱に更新しました 英語版のドキュメントで該当部分の文言を削除しました（日本語版はしばらくお待ちください） この記事に書かれている情報は 2021-12-14 時点でのものになります！ 更新内容ここまで ===== どーも。こんにちは。こんばんは。しーばです。 この記事は Calendar for CircleCI Advent Calendar 2

何日か前に Dynamic Configuration で別のファイルを読み込んで実行して遊んだけど、そういえば、この continuation Orb って何をやってるんだろう？ってのが、ふと、気になった bufferings.hatenablog.com ので、適当に見てみよう。 continuation 前回はドキュメントに書いてある通りバージョン 0.1.2 を使ったけど、今日現在では 0.2.0 が最新か。次から最新を使っとこっと。 CircleCI Developer Hub - circleci/continuation このページの Orb Source のところに、Orb のソースが書いてあるので見てみる その前に ところで CircleCI の CLI でも展開することができる。例えばこんな sample.yml を用意して version: 2.1 orbs: con

React のコンポーネントのテストを書いてたら、テストは成功してるんだけど、こういう感じの Warning が出力されるって場合がある Warning: An update to Counter inside a test was not wrapped in act(...). When testing, code that causes React state updates should be wrapped into act(...): act(() => { /* fire events that update state */ }); /* assert on the output */ ステートを変更するときは act で囲んでねって書いてある。だから、囲めばいいのかなぁ？って思ってたら、ちょっと触った感じ、どうやらそういうことでもないみたい。ので、うろうろしてたら、この2

そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー！ https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ

長くなっちゃったから最初にまとめ まとめ picocli は便利。 デフォルトでサジェスチョンの機能がついている。なので、オプションやサブコマンドの定義だけしておけば、ミスタイプしたときにサジェスチョンを出してくれる。 オプションの場合は、先頭2文字が一致するオプション一覧 サブコマンドの場合は、先頭2文字じゃなくて、似たものを出してくれる こんなつぶやきを見かけて がくぞさんのこんなつぶやきを見かけて そういえばCLIのオプションパーザのライブラリは多種あるけど、定義されてないオプションが指定されたときにオプション名から類推して正しくはコレじゃない？ってサジェストしてくれるような機構まで盛り込んだライブラリってあるのかな？— がくぞ (@gakuzzzz) August 11, 2021 あぁ、たしかにそういうのフレームワークに含まれてたら便利だなー、picocli だったらありそうだけ

この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。 note.com 信頼する まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。 対話 自分の期待を共有する 「自走できるようになってね？」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、

「スクラムで開発をしているか？」 と聞かれると「うーん」ってなる。それは、あなたの中のスクラムの定義による。 そして、スクラムの定義に厳しい人だけでなく、多くの人にとって、僕のやっている開発はスクラムではないだろう。 Doneの定義が明確ではなくてもスプリントを始めるし、スプリントバックログアイテムは全部は完了しないのが普通だし、スプリント中の差し込みも当然あるものとして開発をしている。 プロダクトマネージャー（POに近い役割）は2人いるし、プロジェクトマネージャー（SMに近い役割）も2人いるし、エンジニアのリーダーとしての開発マネージャーもいる。 全然スクラムじゃないよね。 でも、僕の中では、もうこれでスクラムと呼んでいいことになっている。 僕の中のスクラムの定義 じゃあ、僕の中のスクラムの定義ってなんだろう？ それは、何をやっているかではなくて、どう反応していけるか。 Commitme

SCRUMMASTER THE BOOK を読んだ。 books.rakuten.co.jp もっと大きな物語 最初は（ほうほう。。。）って読んでて途中で（んー？？？）ってなってその後（あぁそういうことか・・・まじかwww）ってなった。面白い。スクラムの中のスクラムマスターという話よりも、もっと大きな物語だった。だけど、ページ数も多くなくて読みやすくて楽しかった。 わー！いただきました。よむー！ https://t.co/T8dEP6bUay pic.twitter.com/lC0t1SRCMN— Mitsuyuki Shiiba (@bufferings) September 4, 2020 悩むだろうなぁ スクラムマスターとして動いてる人であるかなぁと思うのが、雑用係みたいになってるとか、自分がいらなくなることを目指すけどその後どうしよう？とか。 特に後者の、チームとしてある程度うまく

4/26 に発売されます！ 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー！」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

ぼやーっと書いてみようと思ったら、ほんとにぼやーっとした感じになってしまった。まいっか。 いい感じのスクラム？ バックログアイテムが小さく作られてて内容が明確で スプリントの途中で差し込みもなくて開発者たちは開発に集中できて 他のチームとの依存はなくてすべての開発がチームの中だけで完結する。 そういう状況だと、まぁ、なんかいい感じに開発できるんだろうなぁと思ったりする。 実際は？ (1) バックログアイテムを準備するのがまず大変。 (2) それから、サービスを運用しているので突然の依頼や問い合わせみたいな差し込みはあるし。 (3) 他のチームとの依存もある。 (1) バックログアイテムの準備が大変 バックログアイテムの準備のときには、プロダクトマネージャーが色んなステークホルダーと調整したり、ビジネスチームやデザインチームと相談したりしつつ、もちろん開発者たちの意見を聞いたりもする。 「開

追記 2021-02-14 Toolchains はまだ IDEA ではサポートされてないみたい。IDEA を使うときはこれまでの書き方をしておく方が良さそう。 Support detecting SDKs from Gradles toolchain support https://youtrack.jetbrains.com/issue/IDEA-252328 追記ここまで === 昨日、Gradleのことを書いたのだけど。そういえば、触ってる中でもうひとつ学んだことがあったので、今日はそれについて。今日もタイトルの通り。 bufferings.hatenablog.com 昨日も書いたけど、Gradleって変化が速い印象あるので、しばらくするとこのやり方よりも良いやり方が出てくるかもしれない。今日は、2021年2月時点のGradle 6.8.2のお話。 これまでの書き方 これまでは、

Gradleでマルチプロジェクトってどうやるんだろう？って公式ドキュメントを眺めて遊んだのでメモ。タイトルの通りの話。 Gradleって変化が速い印象ある。ので、しばらくするとこのやり方も非推奨になるのかもしれない。2021年2月時点のGradle 6.8.2のお話。 ❯ gradle -v ------------------------------------------------------------ Gradle 6.8.2 ------------------------------------------------------------ Build time: 2021-02-05 12:53:00 UTC Revision: b9bd4a5c6026ac52f690eaf2829ee26563cad426 Kotlin: 1.4.20 Groovy: 2.5.12 A

15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ