タグ

ブックマーク / bufferings.hatenablog.com (9)

  • TDDを実践する中で身につけてた「設計に関するスキル」を3つ - Mitsuyuki.Shiiba

    TDDを実践する中で身につけた「設計に関するスキル」があるなぁと思ったのでメモを残しておくことにする。TDDをやるときのスキルではなく設計をするときのスキル。 染み込んでいる TDDは以前に書いたように(ってもう7年も前か・・・)あんまり使わなくなっている。でも心の中にある。ウェブアプリケーションエンジニアとしての自分にとても大きな影響を与えている。 bufferings.hatenablog.com TDDから学んだ設計に関するスキル 3つ思い浮かんだ まずは動くものを作る 必要な分だけ作る 「ありえない」の処理を考える 注意 ウェブアプリケーションを書くときのことを考えながら書いている。ライブラリやフレームワークのようないろんなユーザーから利用されるものは、今回の話の対象ではない。 1. まずは動くものを作る TDDで実装を書くときは「キレイじゃなくてもいいからテストがグリーンになる(

    TDDを実践する中で身につけてた「設計に関するスキル」を3つ - Mitsuyuki.Shiiba
  • git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba

    git-replay というコマンドが追加されたみたいなので触ってみた。とは言っても、自分はあんまり凝ったことはやらないので、細かいところまでは踏み込まずに最低限の使い方ができたらいいなってくらいの気持ちで触った。 github.blog この記事には、こんな風に書いてある↓ git replay exists to address these challenges. It offers an alternative to git rebase that, in addition to being far more performant: Can operate in bare repositories. Can rebase branches other than the currently checked-out one (in non-bare repositories). Can

    git-replay を最低限の使い方で触ってみた - Mitsuyuki.Shiiba
    miguchi
    miguchi 2024/02/27
  • DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba

    以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ?って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DBRDBMS)を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

    DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
    miguchi
    miguchi 2024/01/28
  • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

    最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから

    こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
  • これからは 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

    これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
    miguchi
    miguchi 2020/05/01
  • Javaのコンテナのメモリ割り当ての考え方をまきさんに教えていただいたので記録 - Mitsuyuki.Shiiba

    何度か教えていただいているので、今度こそしっかり覚えておきたくて、まきさんからのコメントを記録。 ## メモリサイズの考え方 SpringBootのアプリをコンテナとして動かす場合には768MB以上必要で、1GBくらいは割り当てる必要があるのではないかという僕のコメントに対していただいたコメント。 それは不正確..Tomcatを使う場合は最大コネクション(スレッド)がデフォルト200で+50スレッドくらい余裕を見ると250M (-Xss1M)でデフォルトのReservervedCodeCacheSize 240MとDirectMemorySize 10M加えた上にMaxMetaSpaceSizeがざっくり50Mくらい足すと550Mくらい使ってこれHeapを足すとコンテナサイズ— Toshiaki Maki (@making) November 16, 2019 その前提であればHeap 2

    Javaのコンテナのメモリ割り当ての考え方をまきさんに教えていただいたので記録 - Mitsuyuki.Shiiba
  • サービスエンジニアとサービス開発と3年後 - Mitsuyuki.Shiiba

    最近何人かからキャリアパスの相談を受けてて、話をしているうちに自分の考えが少し整理できた気がするので忘れる前にメモ。雑記。 ## サービスエンジニア 僕の今いる部署に求められてるエンジニアは、技術をコアにしたエンジニアじゃなくて、サービスをコアにしたエンジニアだと思ってる。図の左側。技術を突き詰めて「この技術で何ができるか」というよりも、サービスのことを考えて「このサービスのためにあの技術が使えないか」という感じ。 ## アプリ開発とサービス開発 Webアプリの開発経験が10年以上あります、って人よりも、新卒の2,3年目の人の方が頼りになったりして、どういうところなんだろうなぁ?って思ってたんだけど。アプリ開発スキル、と、サービス開発スキル、が別のスキルってことなのかもしれない。 サービスを開発するときは、アプリの機能を実装するだけじゃなくて、全体のアーキテクチャ、インフラ、ビジネス側の運

    サービスエンジニアとサービス開発と3年後 - Mitsuyuki.Shiiba
    miguchi
    miguchi 2018/12/13
  • 僕のチームのGitの開発フロー - Mitsuyuki.Shiiba

    を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん?ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを

    僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
    miguchi
    miguchi 2016/02/05
  • 開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba

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

    開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
  • 1