タグ

bufferingsのブックマーク (3,365)

  • トランクベース開発とデプロイ - Mitsuyuki.Shiiba

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

    トランクベース開発とデプロイ - Mitsuyuki.Shiiba
    bufferings
    bufferings 2022/04/09
    書いたのだ。ブログに書くことで自分の勉強になるというやつ。書いてよかった。
  • 苦手なことは苦手なままでもいい 「誰も1人にしない」互いに補うチームのかたち

    「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。3回目は、1年間をかけて変化したチームの結果について。前回はこちらから。 チームを変えるために「並行プロジェクトをやめる」ことを提案 椎葉光行氏:意識していることはわかった。それをどう実践しているのということで、具体的に自分がどういう選択をしてきたかを、さっきのチームのサポートの中からいくつか紹介したいなと思います。 サポートの始まりは、エンジニアのスキルアップをしたいので力を貸してほしいという依頼でした。それを考えながら、ぼーっと見ていたんですが、スキルアップができていない

    苦手なことは苦手なままでもいい 「誰も1人にしない」互いに補うチームのかたち
    bufferings
    bufferings 2021/10/11
    #scrumosaka 2021の基調講演の最後の記事です!ありがとうございましたー!
  • 「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」

    「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。2回目は、誰も嫌な思いをしない変化のために実践したことについて。前回はこちらから。 誰も嫌な思いをしない変化のために「相手に期待しない」 椎葉光行氏:その頃の自分と、今の自分でいろいろと変わったとは思うんですけど、大きくこの2つかなと思います。 「相手に期待をしなくなった」それから「相手の気持ちを考えなくなった」です。 言葉にすると、人としてどうなのという感じがしますけど(笑)、でもこの2つが自分の中でけっこう大きな軸になっています。 何年か前に、娘が「2桁のかけ算教えて」っ

    「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」
    bufferings
    bufferings 2021/10/05
    #scrumosaka の基調講演の記事の中編ですー!わいわい。
  • 『マスターアルゴリズム』は全ての人々を機械学習(人工知能)の世界へといざなう「冒険物語」 - 渋谷駅前で働くデータサイエンティストのブログ

    しましま先生(@shima__shima)こと神嶌敏弘先生から、訳書『マスターアルゴリズム』をご恵贈いただきました。 マスターアルゴリズム 世界を再構築する「究極の機械学習」 作者:ペドロ・ドミンゴス講談社Amazon 書はビル・ゲイツが「AIを知るための」と絶賛したという"The Master Algorithm"の邦訳版で、実際に「難しい理論や数式は書かれていないがこの一冊を読むだけで現代の機械学習人工知能)の世界の全容を一望できる」優れただと個人的には感じました。また縦書きゆえいわば「読み物」的な立ち位置の書籍であり、研究者や技術者のみならずビジネスパーソンさらには一般の読書家にとっても読みやすく、尚且つ得るものの大きい一冊だと思います。 ということで、以下簡単にレビューしていきたいと思います。なお実は僕自身もしましま先生から発刊前の段階で翻訳内容の閲読を依頼されて一通り目

    『マスターアルゴリズム』は全ての人々を機械学習(人工知能)の世界へといざなう「冒険物語」 - 渋谷駅前で働くデータサイエンティストのブログ
  • JITとコードの暖気の実体 - #chiroito ’s blog

    どうも、趣味でOpenJDKのコミッタをしてます。 とあるブログを読んでいたら気になる点があったので検証してみました。 JITと暖気 Javaプロセスはアプリケーションを動かしながら必要に応じてバックグラウンドでバイトコードをネイティブコードにコンパイルします。このコンパイル時にはCPUリソースを使用します。 コンパイルにはいくつかのレベルがありますが、コンパイルされる前やレベルの低いコンパイルのコードはCPUのリソース効率が悪かったり、アプリケーションの処理中にコンパイルが実行されるとCPUリソースを奪いあったりなどが問題になります。 そのため、Java のアプリケーションで性能を気にする要件がある場合、番に近いリクエストを投げてコードをJITコンパイルする事があります。これをよく暖気と言います。これにより番のリクエストが来る前にコードを最適化し、よりCPUリソース効率の高いコードで

    JITとコードの暖気の実体 - #chiroito ’s blog
    bufferings
    bufferings 2020/09/19
    勉強になります!
  • コミュニケーションの方向に着目したふりかえりの方法 - よこなのへたのよこずき

    前職FOLIOではめっちゃいろんな経験をしたので、今更ながら少しずつブログに出してみることにしました。 はじめに 今回のテーマはチームの「ふりかえり」です。レトロスペクティブとか言ったりもするアレ、KPTとかやるアレです。 多くのチームと同じように、私の所属する開発チームも定期的なふりかえりを行っていました。会の構成を決めファシリテーションをするのは私です。 ふりかえりを進めるのは結構難しく苦戦しましたが、「これで上手くいってるのかな?」「どうしたらもっと良いふりかえりができるかな?」と考えながら色々試していくと、解決したい課題や改善点が段々と見つかってきました。そんな中、行き着いた*1方法があるので紹介します。 ふりかえりのやり方 道具はありきたりで、ホワイトボードとふせん(色の区別はしないので1色で十分。カラフルでも別にOK)です。 まずはホワイトボードを縦に1区切り、左は「ポジティ

    コミュニケーションの方向に着目したふりかえりの方法 - よこなのへたのよこずき
    bufferings
    bufferings 2020/04/28
    ふりかえり手法、よこなーる。よさそうー。
  • HomebrewのインストーラーをRubyからBashに書き直しました! - プログラムモグモグ

    みなさんはHomebrewをお使いでしょうか。macOSをお使いの多くの開発者が使っていると思います。 HomebrewのインストーラーはRubyで書かれており、次のコマンドでインストールするようになっていました。 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" HomebrewがRubyに依存していることは良いのですが (formulaの書きやすさはRubyならでは)、インストーラーの話になると事情が変わってきます。HomebrewのインストールコマンドはmacOSの工場出荷状態でも動く必要があります。こういうものにRubyを使っているのはリスクがあります。 将来的にmacOSデフォルトにRubyPythonが含まれなくなる (参考リンク

    HomebrewのインストーラーをRubyからBashに書き直しました! - プログラムモグモグ
    bufferings
    bufferings 2020/03/03
    すごいなー
  • 変化はできるだけ自然にポジティブに - Mitsuyuki.Shiiba

    この数年間は、エンジニアとして他のチームに入っていって、そのチームの改善をサポートする、という活動をしてる。 そういうときに自分が意識しているのは「自然とそうなるようにする」ということ。だって、それが例え良い変化だとしても、外からやってきた人から求められてする変化ってすごいストレスだから。 ここに行けたら良さそう、というのが自分には見えたとして、 これが足りない、ああした方がいい、どうしてこんな実装なの?とか、そういうネガティブな指摘をしても、構えられるだけだし、相手のストレスになってしまうし、良いことない。 このチームってこういうところが良いね、あの部分は難しいのによくやってるね、みんなお互いに助け合ってるの良いね、とか、そういうポジティブな部分を伝えながら、できている部分を認めながら、ちょっとずつ前に進むのがいい。 色んなタイプの人やチームやマネージャーがいるから、それぞれに合ったやり

    変化はできるだけ自然にポジティブに - Mitsuyuki.Shiiba
    bufferings
    bufferings 2019/08/24
    わざわざ「自分はまだまだダメだから変わらなきゃ」って思わせる必要なくて、「自分はこういう良いところあるから、このあたりも伸ばせたらもっと良くなりそう」って思ってもらえるようにするのが好きです。
  • 組織のフェーズによって求められるものって変わっていくよなぁ - Mitsuyuki.Shiiba

    もう今の会社で10年目に突入してしまってた。こんなに長く働くと思ってなかったなぁ。しみじみ。この10年間でほんとに色んなことが毎年変わっていってて、幸せなことに僕はエンジニアとして色んなチームやサービスに関わらせてもらってきた。 そんな中で最近思うのは、組織のフェーズによって求められるものって変わっていくよなぁってこと。そこに、楽しさと、難しさがある。 特に、サービス立ち上げ期と、組織の拡大期では、求められるものが全然違うので、立ち上げ期のメンバーが組織の拡大期にマネージャーをやると悩みそう。だし、いい感じにやってる人たちはすごい。 以下、ふんいき。こんな感じする。全然まとまってなくてざざっと書くけど。 ## サービス立ち上げ期 少数精鋭のメンバーが、持ってるスキルを存分に発揮してサービスの生き残りをかけて取り組むフェーズ。 寝ても覚めてもサービスのことを考えてるような人たちが、自分たちの

    組織のフェーズによって求められるものって変わっていくよなぁ - Mitsuyuki.Shiiba
    bufferings
    bufferings 2019/08/23
    #rsgt2020 のプロポーザルの宣伝も含めてふわっと書いてみたー!
  • 大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ

    ※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある3層構造です。何を見直して再設計するのか?それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く?当に? 開発対象のシステムはある情報の検索

    bufferings
    bufferings 2019/07/21
    DAOだけにするならクエリ用のDBを別で作って、メインのDBからデータを変換してそのクエリ用DBに投入する部分に業務ロジックが存在しそう。かなぁ。
  • モッククラスを使うべきか否か - 日々常々

    元ネタ: モッククラス、下から見るか?横から見るか? モッククラスを使うべきか否か、というネタを拾ったので書いてみます。これまでにモックについて殆ど書いてないことに気づいて驚きつつ。 Short Answer 「モックに何をさせたいの?」 質問に質問で返すなという感じですが、モックに何をさせたいか答えてみれば、モックを使うべきか否かはだいたい決まるよなーと思うのです。 モックは道具で、使うことで何かを改善するものです。 「このことをテストしたいから、モックをこう使う。」という文脈なく使用すると、無用な複雑性を作り込むことになります。 モックの使用は負債なので、十二分に利益を見込める場合にのみ使用するものだと思っています。 これはモックに限った話ではなく、何かを便利にするために道具を追加する際は必ず付いて回るトレードオフです。 Short Answer 露払い 使うべきか否か どちらでも差が

    モッククラスを使うべきか否か - 日々常々
    bufferings
    bufferings 2019/07/19
    ドメインレイヤーはモックを使わずに速いテストが書けるはず。その周りのレイヤーのUTはインタラクションをテストしておきたいことが多いから外部との境界でモックを使うことが多いかなー。
  • Using Akka Cluster for a payment service

    ScalaMatsuri 2019 Akka Cluster を採用した決済サービスをリリースしました。このセッションでは、Akka Cluster を使った開発で苦労した点や、従来の RDB を用いた CRUD ベースのシステムから、どのようにしてアクターモデルやイベントソーシング・CQRS と…

    Using Akka Cluster for a payment service
  • Clean Architecture in Practice @ScalaMatsuri2019

    実践 Clean Architecture http://2019.scalamatsuri.org/

    Clean Architecture in Practice @ScalaMatsuri2019
  • Case of Ad Delivery System is Implemented by Scala and DDD

    ScalaMatsuri 2019

    Case of Ad Delivery System is Implemented by Scala and DDD
  • ピュアなドメインを支える技術/pure domain model and the technology behind it

    Presented at ScalaMatsuri2019 https://2019.scalamatsuri.org

    ピュアなドメインを支える技術/pure domain model and the technology behind it
  • Scala関西の運営から抜けました - nocono

    この度、自身が立ち上げて主宰していた、Scala関西の運営から抜けました。 つい先日も勉強会でScalaの話をしたり、Scala関西Summit 2019も開催すると決めて、例年通り主宰として準備を進めていたので、この急な話はいろんな人を戸惑わせることは承知しています。 ですので、理由を公開しなければと思い、ブログを書いています。 最初に前置きしておくと、抜けると決めたのは当に急な話です。 あと、病気だとか実はスタッフと仲が悪かったとか、ネガティブな理由ではないです。 先日までScala関西やる気満々だったのも嘘ではないです。 抜けようと決断した前後にはいろいろな葛藤もありましたが、前向きな理由によるものです。その辺りはご安心(?)ください。 抜けようと決断した理由 運営から抜けようと考えることになったきっかけは、下記資料です 2019/05 Scala導入を検討したい人に向けた情報をま

    Scala関西の運営から抜けました - nocono
    bufferings
    bufferings 2019/06/12
    相変わらずかっこいいなー!
  • 安価なGKE(k8s)クラスタを作って趣味開発に活用する - えいのうにっき

    tl;dr GKEでk8s(kubernetes)クラスタを作成すると、各ノードはGCEインスタンスとして起動する GCEインスタンスには preemptible モードが指定でき、これはGKEクラスタとして起動するノードに対しても指定可能 GCEのf1-micro無料枠の適用と合わせて、この運用費用は約 $7.68/month 動機 GKEクラスタを維持する最安料金ていくらだろー— a-know | Daisuke Inoue (@a_know) 2018年6月11日 趣味開発用途として手軽にあれこれ試すことができて、それでいてできるだけ安くあがるコンテナオーケストレーション環境(k8s環境)がほしい。 k8sそのものを運用したい・そのノウハウを学びたいというわけではないのでマネージドサービスがいい 「k8s上でアプリケーション・サービスを運用する経験」がしたい その上で、できるだけ安く

    安価なGKE(k8s)クラスタを作って趣味開発に活用する - えいのうにっき
    bufferings
    bufferings 2019/06/09
    これ見ながらGKEのクラスタを作ってみた!
  • gRPCと手動テスト | メルカリエンジニアリング

    この記事はMERPAY TECH OPENNESS MONTHの5日目の記事です。 merpayでNFC決済のmicroservice (nfc-service) を開発担当している @Hiraku です。メルペイのバックエンドシステムは、各microserviceが主にgRPCを主な通信プロトコルとして用意しています。当然、各チームはgRPCサーバーを開発しています。この記事では、ちょっとした開発の日常をお見せしたいと思います。 とあるエンドポイントの場合 そもそもgRPCサーバーだけで、iOS/Androidのバックエンドができるのか?と思う方がいるかもしれません。 下図は、典型的なリクエスト経路を示しています。 merpay-gateway … 主にプロトコルの変換を担う merpay-api … BFF(Backend for Frontend)的な役割を担い、他のmicroser

    gRPCと手動テスト | メルカリエンジニアリング
  • モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編 - kawaguti’s diary

    は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ

    モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編 - kawaguti’s diary
    bufferings
    bufferings 2019/05/08
    うはー。良い取り組み方だなー。
  • モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary

    方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。 Hunter Industries にお邪魔してます モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。2年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。 ビザの関係で生産活動には従事できないのだけど、横で立ってるの

    モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary
    bufferings
    bufferings 2019/05/08
    やっぱり、見積もりをしないのは、今チームが一番重要だと思うことに全力で取り組めそうで良いよな。