VSCodeのFindで今マッチしている場所にボーダーを引いて見やすくする - $shibayu36->blog;
VSCodeでFindしている時に、マッチしているwordは背景色が変わって分かるのだけど、今どこにフォーカスしているかが分かりづらかった。これが特に問題が起こるのがReplaceをしようとしている時で、Replaceするたびに今どこ？とマッチ箇所を探していた。これだと時間がかかって困る。 調べてみるとTheme Color | Visual Studio Code Extension APIに書かれているように、自分のsettings.json内で自分用に色を調整し、見やすくカスタマイズ出来ることが分かった。これでFindの現在のマッチ箇所を見やすくしてみる。 Findの色のカスタマイズは editor.findMatchBackground: Color of the current search match. editor.findMatchHighlightBackground:
VSCodeの置換でEmacs風の挙動を再現する - $shibayu36->blog;
個人的にEmacsの置換のy/nで一つずつ置換するかしないか決められるUXが好きなので、VSCodeの置換でも近しいことが出来るように設定してみた。以下のような設定をすると、Replaceのインプットにフォーカス中にcmd+yでReplace実行、cmd+nでスキップということが出来る。便利。 keybindings.json // replaceでy/nでreplaceするかしないか選べることを模倣 { "key": "cmd+y", "command": "editor.action.replaceOne", "when": "editorFocus && findWidgetVisible && replaceInputFocussed" }, { "key": "cmd+n", "command": "editor.action.nextMatchFindAction", "whe
開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
ALBで特定のpathのときだけCognito認証を通す構成をaws-cdkで作る - $shibayu36->blog;
管理画面の時だけ認証をかけたいみたいな要件はよくある。今回はその要件をALBで特定のpathの時だけCognito認証を通すという構成で実装してみたのでメモ。構成はaws-cdkを使った。 やりたいこと /admin/以下の場合はCognitoの認証をかけ、許可したユーザーしかアクセスできないようにする それ以外のパスではアプリケーションに認証なしで繋がるようにする 実装 aws-cdk 1.62.0を使って実装した。なお今回のコードは実際の実装をミニマムに変更しているので、動作確認はちゃんと出来ていない（たぶんそのままだと動かなそう）。雰囲気だけ感じてください。 import { IVpc, Port } from "@aws-cdk/aws-ec2"; import { Ec2Service } from "@aws-cdk/aws-ecs"; import { Application
Jamboardを使ってオンラインでプラニングポーカーをする - $shibayu36->blog;
Jamboardを使ってオンラインでプラニングポーカーをするお試しをしてみたので知見を共有します。 課題 リモートワークで全員がオンライン前提となり、かつプライベートエリアなのでミーティングではビデオを付けたくないメンバーがいる。もちろんミーティングの円滑化のためにビデオを付けることを強要したくはない。 しかし、プラニングポーカーはこれまで指でフィボナッチ数を出すというモデルでやっていた。ビデオを付けない人がいる場合、このやり方ではプラニングポーカーができない。 こういう状況で、どのようにプラニングポーカーで見積もりを行うかが課題となっていた。 Jamboardを使ってオンラインでプラニングポーカーをする解決案 GoogleのアプリでJamboardというホワイトボードアプリがある。これを使ってプラニングポーカーをしてみた。 やり方 付箋でフィボナッチ数とカーソル置き場を並べたJamboa
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする - $shibayu36->blog;
開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。 ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。 以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうま
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
長い期間、継続的にブログを書き続けるための工夫 - $shibayu36->blog;
10年前からブログを始めて、10年間コツコツコツコツ学んだことや考えたことを記事として書き続けてきた。その結果、ついにブログの記事総数が1000記事近くになってきた。10年間かなり頑張ってきたなあと感慨深い。ありがたいことに読者数も1000人ほどいて色んな人に見てもらえるようになり、これも継続的に書き続けたおかげだなあと思う。 また、ずっとブログを書き続けてきたことで、以下のような多くのメリットを受けることができた。 ブログを書くこと自体が自分の頭の整理に繋がる その後知識を忘れたとしても、ブログを見返せば思い出せる 初めからブログに書くつもりで勉強すると、勉強の効率が上がる 反対意見とかツッコミを入れてくれる人が出てきて、自分の思い違いを正したり、より考えを洗練させることができる 記事を書き続けていると意外と読者が増えていて、気合を入れた記事を書いた時もみんなに見てもらえる 完全公開の場
メンターを初めて経験する人に、最初に読むものとしてオススメしている書籍たち - $shibayu36->blog;
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
Github Actionsをcronとして利用し、notify-issues-to-slackを動かす - $shibayu36->blog;
以前、レビュータイムや定期的なissueチェックのためにGithubのissueを検索してSlackに投稿するCLIツールを作ったで紹介したnotify-issues-to-slackだが、これまでは 適当に立てたサーバーのcronで動かす Jenkinsなどで実行する という方法で動かしていた。 しかし、issueをslackに通知するためだけにサーバーを立てたりするのもだるい。そこでGithub Actionsで動かしてみた。 Github Actionsを動かすレポジトリのみを対象とする場合 secrets.GITHUB_TOKENを使えば、そのレポジトリへアクセス可能なので、何も設定せずとも以下のように設定できる。 .github/workflows/notify-issues.yml name: daily bug report on: schedule: - cron: 30
Next.jsアプリケーションを動かす環境をaws-cdkを使って構築する(with CloudFront/S3/Fargate) - $shibayu36->blog;
Next.jsをproduction環境で使うために外観を掴んでおきたいと思い、Next.jsアプリケーションを動かすAWS環境をaws-cdkを使って構築するサンプルを作ってみた。だいぶ荒削りだけど、参考になる例にはなったと思う。 https://github.com/shibayu36/nextjs-on-ecs 利用した技術 AWS CloudFront S3 ECR ECS aws-cdk Docker Next.js + TypeScript 今回作ったアーキテクチャ 全てのリクエストをCloudFrontに通すフルCDNアーキテクチャ フルCDNアーキテクチャ実験 / Minami Aoyama Night #1 - Speaker Deck フルCDNアーキテクチャでサービス設計した話 - Speaker Deck next buildで生成した静的ファイルはS3から配信
最近連載開始して3巻程度で好きな作品たち - $shibayu36->blog;
社内の朝会のスピーチで発表したのを公開しておく。 漫画の連載追いかけるの好きです。最近連載が始まって単行本3巻程度のもので、好きな作品を紹介します。 大ダーク・1巻 大ダーク (1) (ゲッサン少年サンデーコミックス) 作者:林田 球小学館Amazon ダークファンタジーの設定が良いし絵が最高 ドロヘドロの作者の新連載 ドロヘドロも2巻から爆発的に面白くなった漫画だけど、大ダークもそのような雰囲気を感じて楽しみにしてる 夏目アラタの結婚・1巻 夏目アラタの結婚 (1) (ビッグコミックス) 作者:乃木坂 太郎小学館Amazon 殺人鬼と面会室ごしに恋愛していく(????)話。サスペンスっぽい。ハラハラします 医龍の作者の新連載 スキップとローファー・2巻 スキップとローファー（２） (アフタヌーンコミックス) 作者:高松美咲講談社Amazon ほわほわしてて癒やされる。主人公がいい子。 疲
0になるくらいなら0.1でもいいから学ぶ - $shibayu36->blog;
以前は、学習するときはきちんと頭に入ることを重視しようという考え方をしていて、パソコンに向かえる時に集中して勉強するようにしていた。最近はその考えを変えようとしていて、0になるくらいなら0.1でもいいから学ぶと思うようにしている。 この考えに変えたい理由は、今は子供が小さく、2人目も産まれたため、育児によって自分の自由な時間が減ってしまったからだ。2人目が産まれて驚くほど自由な時間が減った。大体1日で自由になる時間は、2〜3時間くらい（朝1時間、夜2時間くらい）。この時間で学習も趣味も休息もプライベートのTODOも全て賄う必要がある。ちなみに子供が体調を崩したり、何かイベントがあったりすると時間は全て吹っ飛ぶ。 こんな中、きちんと頭に入ることを重視しすぎると、もう全く何もできなくなってしまうなと思った。そのため、効率が悪くてほとんど学習になっていなくても、0.1でもいいからやるようになった
Apollo platformのチュートリアルをやった - $shibayu36->blog;
Hatena-Textbook 2018学習日記(5) - GraphQL編 - $shibayu36->blog;のようにHatena-Textbookを用いて最近のモダンなWebアプリケーション開発の学習をしているのだけど、TypeScript + GraphQL + Apollo Client + Reactの部分でそれぞれの技術の基本知識を理解できていなかったので、エラーが起きたときに何から直したらよいかわからない状態になってしまっていた。 前回はGraphQLのクエリについて学んだ - $shibayu36->blog;でGraphQLを少し掘り下げたので、今回はApollo platformについてチュートリアル( https://www.apollographql.com/docs/tutorial/introduction/ )を行いながら学習を進めていった。 Apollo
GraphQLのクエリについて学んだ - $shibayu36->blog;
Apollo Clientについて学ぼうと思い、Introduction - Apollo Basics - Apollo GraphQL Docsをやっていた。しかし、これをやる中でGraphQLのクエリ言語についてあまり分かってないことに気づいたので、Queries and Mutations | GraphQLを見て、クエリについて学習した。 Fragment、queryの命名、変数を使ってRDBのプレースホルダー的なことをする方法、ifの利用などが分かってよかった。以下メモ書き。 Fragmentを用いてクエリの再利用ができる 引数名を用いてFragmentに変数を引き継ぐこともできる query HeroComparison($first: Int = 3) { leftComparison: hero(episode: EMPIRE) { ...comparisonFields
Emacsで現在開いているファイルを一瞬でVSCodeで開く方法、そしてその逆 - $shibayu36->blog;
Reactを最近勉強し始めたのでVSCodeも使ってみるかと思っている。そうはいってもEmacsを使いたいときもあるので、 Emacsで現在開いているファイルをVSCodeで開く(カーソル位置も保持) VSCodeで今開いているファイルをEmacsで開く(カーソル位置も保持) の両方をやりたい。ということでやってみた。 Emacsで現在開いているファイルをVSCodeで開く 実装はこれ -> https://github.com/shibayu36/emacs/commit/9699a693d45b8d3b355b15b57c6e6b3f827d6483 単純にcodeコマンドを使って現在のファイル名、行数、カラム数を渡してあげると良い。 ;;; 現在のファイルをvscodeで開く (defun open-by-vscode () (interactive) (shell-command
topにおけるCPUのsteal/niceは何か調べた - $shibayu36->blog;
入門監視を読んだところ、CPUのstealやniceが何か分からなったため調べてみた。今回はそのメモを書いてみる。あまり自信はないので間違っていたら指摘してください。 steal リソース制御でサービスレベルを確保せよ：実践！ Xenで実現するサーバ統合（5）（2/3 ページ） - ＠IT が参考になった。 steal列には、ゲストOSがリソース要求を行ったにもかかわらずCPUリソースを割り当ててもらえなかった時間の割合が表示されます。steal列に0％以外の値が表示されている場合はCPU利用率閾値設定が行われているか、ほかのゲストOSあるいはホストOSが同時にCPUリソースを要求して「取り合い」の状態になっていることが考えられます。特に閾値を設定していないにもかかわらずこのstealの値が高いようであれば、そのホストサーバは全体として過負荷になっているか、前述のCPUマッピング設定がアン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
特定のファイルだけgit stashする - $shibayu36->blog;
