サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
bufferings.hatenablog.com
pnpm を触り始めた ちょっと前に npm のことを勉強したときに、ゆうくさんに pnpm のことを教えてもらって気になってたので、触り始めた。 bufferings.hatenablog.com pnpm はパッケージをグローバルストアに保存して、各プロジェクトの node_modules ではハードリンクを使用する。だから、ファイルをコピーしなくていいので容量もくわないし、インストールのスピードも速いのか。へー!便利。 ハードリンクを使用するので、プロジェクトとストアが同じディスクにないといけないことを頭の片隅に入れておこうかなってくらい。 ストアの中身 そのグローバルストアのデフォルトの場所は、macOS だと ~/Library/pnpm/store/v3。どんな風に保存されてるんだろう?と思ってのぞいてみたら、こんな感じになってた。途中で切ってるけど2文字のフォルダがたくさんあ
ぶじに最初の一週間が終わった bufferings.hatenablog.com 気持ちが新鮮なうちに、自分が意識していることメモ。大きくはこの2つかな。 相手は、いちばんいい方法を選んでくれている 自分は、考えを明示的に言葉にする 相手のこと 「相手は、いちばんいい方法を選んでくれている」と信じる。 新しい環境に飛び込んで、まだ慣れてないときには特に、自分の中で情報が足りていないので、不安になったり、混乱したりする。そんな状況だと、相手の内面に原因を押しつけてしまうバイアスがはたらく(と思う)。 何かをしてもらえていないと感じたときに「この人は自分のことをめんどくさいと思ってるのかもしれない」みたいに、相手の気持ちに原因を求めるの。自分が受け入れる側だったときのことを考えると、実際はそんなこと全然ないのにね。 だから「相手は、いちばんいい方法を選んでくれている」と信じることを意識する。
昨日、4月1日に株式会社カケハシへ入社した。 株式会社カケハシに入社しました - Mitsuyuki.Shiiba 明日から仕事が始まるので、ひとつの区切りとして、この3ヶ月半をふりかえっておこうと思う。ちょっと長くなっちゃった。 前職を退職 ウェブアプリケーションエンジニアとして転職活動をしますー! - Mitsuyuki.Shiiba 12月15日付けで前職を退職することになったため、ブログを書いて「転職活動します!」とツイッターにポスト。ありがたいことにたくさんの方が声をかけてくれたり、応援してるよって言ってくれたりして嬉しかった。 外資への応募も少し考えてたけど、こんなに声をかけてくれたので、その中で探すことにした。レイオフじゃないと、こういう形で転職活動をすることもないから、いい経験だなと思いつつ。 カジュアル面談 12月から1月にかけて77社にお声がけいただき、42社とカジュア
株式会社カケハシに入社しました https://www.kakehashi.life/
Jestではじめるテスト入門 本日「Jestではじめるテスト入門」がついに発売されました 🎉🎉🎉 peaks.cc CircleCI時代の同僚の伊藤さん @ganezasan が「Jestの自動テスト本の執筆を手伝ってくれませんか?」と声をかけてくれて「これからテストを書きたいって人に向けたJestの入門書を書きたいんですよ!!」って熱く語ってくれて「いいなぁ」と思ったので参加しました。本を書くなんて初めてのことなので、自分なんかに書けるかなぁとドキドキしてたのですが、周りの方々の助けのおかげで、なんとか書き上げることができました。 そして、監修はなんと和田さん @t_wada です。自分が自動テストについて書いた文章を、和田さんに監修していただけるなんて、それだけでとても幸せだなぁと思っていたのですが、「むちゃくちゃ面白かったです!」って言ってもらえたので、もう出版しなくても満足し
先週、npm installとnpm ciについて調べて考えたことを書いたのだけど、ドキュメントを読んで、頭の中で考えたことをまとめただけなので、これだけだとちょっと気持ち悪いなと思って。簡単ではあるけど実際の動作を確認することにした。 bufferings.hatenablog.com 結果 だいたい想像どおりだった。今回のサンプルプロジェクトで実験した結果は次のとおり。 (1)と(2)は、キャッシュがない場合のnpm ciとnpm installの速さ。想像では「npm ciの方が多少速いのかな?」と考えていたけどほぼ同じだった。node_modulesがない状態から始まるので、npm ciはnpm_modulesを削除する必要がない。一方で、npm installも既存のnode_modulesをチェックする必要がなくて、package.jsonとpackage-lock.jsonの
うりうりさんの↓のコメントを見て、そういえばnpm ciって見たことあるけどチェックしてないなぁ。というかnpm installも雰囲気で使ってるなぁ。と思ったので、うりうりさんに教えてもらったことを手がかりに、npm installとnpm ciについて調べた。 これ、node_modulesキャッシュしてたり npm install使ってるけど npmのグローバルキャッシュ(~/.npm)をキャッシュした上で npm ciで早くなったりしないんだろうか GitHub Actions上でテストを約3倍早くした話https://t.co/MpmFktGBxU— wreulicke (@wreulicke) March 14, 2023 ちょこっと検索して見てみたところ、新旧情報があって自分が混乱したのと、公式ドキュメントには概要は書かれているものの詳しい内容は書かれていないので(僕が見つけ
ふとしたときに、ぼーっと考える 会社(や評価をする人)は何をもって「このソフトウェアエンジニアはいい」って判断するのがいいんだろうなぁって。むずかしくない?入社前じゃなくて、入社した後のこと。自社ウェブサービスを開発しているソフトウェアエンジニアのこと 特に伝えたいことも答えもなくて頭の中のメモ 分かりやすいならいい その人の開発したものが、バグだらけだとか、そもそも設計ができないとか、そういうのだと分かりやすいからいい。まずは、バグを減らそうねとか、設計ができるようになっていこうね、という話 あと、やってることが周りから見えないとか、コメントとかが攻撃的で一緒に働いてる人が嫌な気持ちになるとか、まぁ、そういうのも「違うよね?」って言えるし、コンピテンシー評価で伝えていけたらよさそう ある程度のモノができている場合は、どうだろう? もっと早く作ってほしかった! って考えるかもしれない。確か
昨日と比べて今日一歩前進してる? もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり(幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった) そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない 計
しばらくしたら次のことを考えたいなと思ってるので、よい仕事や空いてるポジションがあったら教えてください!— Mitz Shiiba@フルスタックエンジニア (@bufferings) December 8, 2022 突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。 この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。 ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいで
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます!今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ? 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな?スクラムマスターはこうあるべきだよとかって話?と思ったのだけど、読み始めてみるとそうじゃなくて、
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
サイボウズさんの、この記事を読んだ blog.cybozu.io とても面白い。良いなと思う。ぼーっと想像して遊んでみる。全部想像だよ 職能横断チームへ 2019年の組織変更ではマネージャーをなくしたことに目がいくけど、職能ごとの組織から職能横断のプロダクトチームに変更したことがまず興味深い 職能横断のプロダクトチームだと良さそうなのは プロダクトのことを第一に考えることができる 職能間の壁をなくして全員で取り組むことができる 結果として、プロダクトをより良くするための開発サイクルが速く回るようになったんじゃないかな。それと、開発・テスト・リリース・運用など全てのフェーズからのフィードバックをチームが得られるので、そこからの改善も進んでそう。とても良さそう 職能別組織が持っていた良さ 一方で、以前の職能別組織の場合に良かったのは 自分の専門領域に集中して取り組むことができる 専門知識を持っ
こんどこそGo言語の勉強をしてる k8sやDocker周りでよく見かけるので、Go言語をちゃんと読めたらいいなぁとは何年も前から思ってたのだけど。チュートリアルをやってみたり本を読み始めてみたりしては、すぐに別のことに興味が移ってしまって続いてなくて。でも今回は仕事で触ることになるので、真面目に勉強を始めてしまった やっぱり必要に迫られるとちゃんと続くので嬉しい。業務時間を使っても勉強してるし、勉強は業務時間の中だけでいいよって言われてるのだけど、欲深いので家でも本を読んだりして楽しんでる。今読んでるLearning Goって本は結構好きな感じなので、読み終わったら感想を書こうかなと思ってる Learning Go [Book] 先月日本語訳が出てる O'Reilly Japan - 初めてのGo言語 今日は今の自分の技術書の読み方をメモしておくことにした 技術書を読むとき だいたい、こん
1年 CircleCI に入って来月で1年になる。あっというまだなぁ。 色々と面白いことが転がってるので全然飽きないし、スキルが高ければ高いほどその面白いものをもっと拾えるので、どんどんスキルアップしていきたい気持ち。 仕事のやり方を忘れようとしてる その一方で、いま僕は仕事のやり方を忘れようとしてる。これまでずっとやってきた自分の仕事のやり方をいちど忘れてみようと思っているのだ。もっと肩の力を抜いて、リラックスした気持ちで仕事をしてみたい。がんばらないように。 のだけど、これが思ってたより難しい。 つい、がんばってしまう。がんばる方がラクだと思ってしまう。そっちの方がラクならがんばったらいいやん。って思うかもしれないけど。せっかくなので違う働き方に挑戦してみたい。どんな景色が見えるんだろう?ということに興味がある。 過程より結果 今のチームでは、いちばん大切なこととして「プライベートを第
なんか、あんまりいい感じじゃないなぁって思うコードに出会ったとして、それをクソコードと呼ばないようにはしてたんだけど、いつからか、そもそもクソコードだと思わなくなってる そのときの、そのコードが書かれた環境があって、それは、その人が持っているスキル以上のことをなんとかしないといけなかったのかもしれないし、めちゃくちゃなスケジュールの中でやらないといけなかったのかもしれないし、お試しで作ったものをそのまま使われちゃったのかもしれない あんまりいい感じじゃない構造だったとしても、そのコードによってシステムは動いて価値をもたらしていて、そのおかげで僕がそのコードに出会ってるんだから、それはとてもスゴイことだなぁって思う コードを悪者にして文句を言っても何も変わらないし、僕はエンジニアなのだから、そのコードをより良いコードにすればそれでいい 自分がコードを書くときには少し気をつけたり、あんまりいい
を書いてみる気分 今日の時点での自分のやり方なので、またしばらくすると変わってるかもしれない 僕には、最初に考えたとおりに実装できるようなスキルがないので コードを書きながら形にしていく感じ サイズ だいたい、チケット一枚が、5,6時間で実装できるくらいのサイズになってる 2,3日くらいでレビューまで終わって本番にデプロイすることが多いかな (基本的にはそれくらいってだけで、1,2週間くらいかかるような長いやつもある) 技術的なフィージビリティチェックとかはこの前に終わってる 実装を頭に思い浮かべる こんなふうにすれば良さそうかなぁ このあたりは何パターンか考えられるけどどっちがいいかなぁ とか頭の中に思い浮かべる とりあえず動くものを実装 まずは思い浮かべたものが全部つながって動くかをサクッと確認したいので雑に実装する そして、気づくことがいくつかある あれ?この場合どうなるんだろう?っ
例えば「会議が多い」という意見に、どう対応しよう? 普通に考えたら「無駄な会議を減らそう!」かな だけど、できれば僕は「だからどうしたいと思ってるんですか?」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる (順当→)会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな
config.yml を分割できる Orb を作ったよー Split Config Orb という Orb を作った こないだからちょこちょこ試してたやつを Orb にしたのだ。この Orb を使うと config.yml を分割できる。Orb にしたから簡単に使えるよー! config.yml が大きいから分割したいー!って場合や、モノレポで複数サービスを入れてるから各サービスごとに config.yml を書きたい!って場合に使えるかなぁって思ってる もしちょっとでも興味があったら、実際に使ってみてフィードバックをいただけると嬉しいです。フィードバックを元にして機能をブラッシュアップできるといいなと思ってます!GitHub の Issue でも Twitter でメンションくれても OK です! GitHub Issue: Issues · bufferings/orb-split-c
ぼーっと CUE のドキュメントを読みながら CUE という設定用の言語・・・と呼んで良いのかな?のドキュメントを読みながら https://cuelang.org/ 「これ、いろんな機能があるけど、それは置いといて、YAML の合成が簡単にできるのでは?・・・とすると、CircleCI の設定を簡単に分割できて面白いかもなぁ」 と思ったので試してみた。わりとアリかもしれない 今回のサンプルコードはここ: github.com どういう感じ? こんな感じに適当に分割した設定を ❯ tree .circleci/configs .circleci/configs ├── header.yml ├── job1.yml ├── sample │ ├── job2.yml │ └── mixed\ sample.yml ├── workflow1.yml └── workflow2.yml 1
とても雑記 個人の成長は必須かなぁ? よーはつのツイートを見て、古川さんのスライドを見て、「グループや会社は成長して欲しいなぁって思うけど、個人の成長はどうなんだろう?僕は『今、自分が持ってるチカラで会社の成長を支える』ぐらいがいいなぁ」みたいなことをぼやーっと考えた ここ数年、こういう組織の支援もやっているけど、ほんとに難しい… 開発組織の持続可能性について https://t.co/8HpulzqngQ pic.twitter.com/Jx9LFuH0p2— yoh nakamura (@yohhatu) July 12, 2022 意識低い 最近の自分は「成長しなきゃ!」「そして自分の成長で会社の成長を支えなきゃ!」みたいなのはあんまりなくて、意識は低い方かなぁと思う。「それはそれ、これはこれ」な気持ち 単純に、新しいことを学ぶのは楽しいし、昨日できなかったことが今日できるようになる
去年の夏頃に使ったやつ。なんとなく、公開しておいてもいっかなぁって考えてたことを思い出したので公開。住所とか会社名とかは消してる 考えてたことは 忙しい中でパッと見て「話を聞いてみようかな」って思ってもらえたらいいなって気持ちで書こ 経験を全部書いてもよく分からなくなりそうだから、3つくらいアピールできそうなこと書いとこ ICとして働きたいからマネージメントよりもエンジニアリング経験アピールで この歳で背伸びをしたり伸びしろアピールをしても仕方がないので、今の自分をそのままを書いとこ 右側の一覧の、例えば Java 15年分のスキルがある感じはしないけど、まぁ嘘ではないし書いとこ みたいな感じ。シンプルすぎるかなぁとも思いつつ、まぁ、これで書類通らないところとは、ご縁がなかったってことでいっかなーくらいの気持ちで 実際は、これと一緒にカバーレターを書いて、そっちに「どうして応募したのか、ど
ぼーっと。最近は、フルスタックすきまエンジニアっぽい。と思ったので、とりあえずタイトルだけ書いて、深く考えずに書き始めてみる 僕は、好きなサービスの周りのことだと、何をやっても楽しいタイプなので、これをやったらチームにとって良さそうかな、って思うことをやってたら楽しい。ただ、そのままどっかに行ってしまうとあれなので、軸足はコーディングに置くように意識してる あと、自分は色んなことを同時に考えられるタイプではないので、たくさん面白そうなことがある中で、最大でも3個くらいしか選べないよなぁと思っている。それ以上手をだしてしまうと、混乱する。だから、今の自分がどのスキマを埋めるのがいちばんいいかなぁってのを雰囲気で考えながら動いてると思う。たぶん 具体的に何をやってるかなぁって考えてみる。色々あるけど、同時にやってるわけじゃなくて、どれかをやってるときは、別のことは横に置いてる コード周り 軸足
ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「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 さんも書いてる
かなり良かった 「良いコード/悪いコードで学ぶ設計入門」を読んだ。読む前は特に書くつもりはなかったんだけど、かなり良かったからブログを書くことにした gihyo.jp どういう本? この本は、読みやすくて変更しやすいコードの書き方と設計についての入門書 どのようなコードが悪いコードなのか、そこにどういう問題があるのか。それに対してオブジェクト指向設計で、どのように設計してコードを書けば、より良いコードを書くことができるのかを、分かりやすい例でコードを追いかけながら、学ぶことができる 読むと良さそうな人 2,3年目くらいで「もっと良いコードを書きたい!」とか「どんなコードが良いコードなんだろう?」って考えてる人や もうちょっと経験があって、機能追加や改修をするときに苦労をしてきて「どんな風に作ればこの苦労を減らすことができるんだろう?」って悩んでる人には、特におすすめ それ以外でも、今はコー
ペアでやろうよー! チーム内で知識を共有できるように、フルリモートでも一緒に仕事できるように、チームとしてプロジェクトに取り組めるように、「ペアでやろうよー!」ってなって「それいいねー」って思って、最近はペアで仕事をしてる そして、何年も前からうすうす感じてはいたんだけど、やっぱり、僕はペアプロが苦手だった!ので、ペアプロじゃなくてペアワークしてる ペアプロ?ペアワーク? 「ペアプロ」は「ペアプログラミング」のこと。一緒にコードを書く。リモートワークなのでペアプロするときは、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 でバージョン管理されている
次のページ
このページを最初にブックマークしてみませんか?
『Mitsuyuki.Shiiba』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く