並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 8 件 / 8件

新着順 人気順

技術的負債 例の検索結果1 - 8 件 / 8件

  • 「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている

    「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている Tailwind CSS 1 を一目見た人、特にCSS初学者のうちけっこうな割合が「これエグい負債になりそう」と思う気がする。なぜなら実際にそのような意見をちらほら見るからなんだけども、自分はあんまりそうは思っていないし、微妙に今のCSSについて誤解があるような空気も感じるのでその理由を説明したい2。JSXと同じで嬉しさを理解して使い慣れればなんてことはないのだけど、一方でその背景にある話はJSXより複雑なので単純に使って慣れればいいという話でもなさそう。 なお、この記事は私の以下の2ツイートを膨らませたものです。 Tailwind CSS、剥がすのは大変そうだけどそれをもって重大な負債になると評せるかは微妙に思っている https://x.com/aumy_f/status/18220941478532

    • この世の中に溢れているので自分が発言する必要はないが「ソフトウェアは認知の限界まで複雑になる」を自分なりに再考する - じゃあ、おうちで学べる

      人間が何もしないと病気になるのと同じように、ソフトウェアも何もしないと複雑になる。 はじめに ソフトウェア開発の世界に飛び込んでから、「ソフトウェアは認知の限界まで複雑になる」という言葉を耳にしたとき、正直なところ、「ほへー」って思いながら何も理解していませんでした。しかし、大規模なシステムに携わるようになって、その言葉の重みを身をもって感じるようになりました。内部構造や相互作用が複雑化し、全体を把握するのが難しくなっていく。それは挑戦であると同時に、私たち開発者の存在意義を問いかけるものでもあります。 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon この複雑性との闘いは、時に苦しいものです。でも、それを乗り越えたときの喜びは何物にも代えがたい。私たちの

        この世の中に溢れているので自分が発言する必要はないが「ソフトウェアは認知の限界まで複雑になる」を自分なりに再考する - じゃあ、おうちで学べる
      • テックリードのポジションを設ける際に考えたこと - Sansan Tech Blog

        はじめに Eight Androidチームのチームリーダーの山本です。 私たちのチームでは2024年6月から新たにテックリードのポジションを設け、2024年4月入社のメンバーにその役割を担ってもらっています。 それまでEight Androidチームに明確なテックリードのポジションはなく、チームリーダーである自身が暗黙のうちにその役割を兼務している状態でした。今回、新たにテックリードのポジションを設けるに当たり、考えたことをまとめます。 背景 これまでチームでは2つの取り組みでアーキテクチャの検討と、新技術導入や技術的負債の改善を行ってきました。 技術基盤改善 新技術導入や技術的負債の改善を行う 週に1回2時間の時間をかける チーム全員が作業する アーキテクチャ検討会 レビューなどで発生した汎用的な技術的な論点や、大きなアーキテクチャ変更の話題を扱う 週に1回2時間の時間をかける チーム全

          テックリードのポジションを設ける際に考えたこと - Sansan Tech Blog
        • 後回しにしない組織はどう作る?論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】 | レバテックラボ(レバテックLAB)

          TOPインタビュー後回しにしない組織はどう作る?論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】 株式会社ログラス 開発本部長/事業執行役員VPoE 伊藤 博志 ゴールドマン・サックスのテクノロジー部に新卒入社後、同社の機関システム開発に従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社発のJavaのOSSであるEclipse Collectionsのコミッター兼プロジェクトリードやOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。スタートアップ2社を経て、READYFORに入社し執行役員VPoEに就任。同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的負債の返済、新規プロダクト開発を牽引。2022年10月に株式会社ログラスの開発部へエンジニアとして入社。エンジニアリングマ

            後回しにしない組織はどう作る?論文『銀の弾丸』から紐解く「あの時やっておけば」と決別する方法【ログラスVPoE伊藤】 | レバテックラボ(レバテックLAB)
          • 「顧客志向」を中心とした開発戦略と取り組み 【ラクス イベントレポートまとめ】 - RAKUS Developers Blog | ラクス エンジニアブログ

            8/7(水)にRAKUS TechConference(以下TechCon)が開催され、盛況のうちに閉会しました。本記事ではその様子を、TechConを開催する目的や背景、当日発表資料なども交えながらご紹介します! TechConとは? TechConの開催目的 今年のテーマは「顧客志向」 ラクスの開発組織にとって「顧客志向」とは なぜ「顧客志向」をテーマに選んだのか? イベント概要 発表の紹介 「顧客志向」の開発組織 マルチプロダクトでのプロダクトマネージャーのリアル 拡大するマルチプロダクトSaaSの顧客理解にデザイン組織はどう取り組んでいるか 急成長する大規模プロダクト開発のマネジメント課題とアプローチ パフォーマンス向上とリソース管理のためのアプローチ 急成長するサービスを支えるためのインフラ戦略 楽楽精算のQA改革~楽楽精算でのQA専門組織の実践と成功事例 新たな顧客課題に挑む1

              「顧客志向」を中心とした開発戦略と取り組み 【ラクス イベントレポートまとめ】 - RAKUS Developers Blog | ラクス エンジニアブログ
            • コンサルとSIerとIT部門の共同謀議の成れの果て、偽装DXプロジェクトはよく燃える

              本当に嫌になってしまうよね。何の話かというと、DX(デジタルトランスフォーメーション)という言葉の「乱れ」についてである。もうめちゃくちゃだ。単なる「IT活用」が「DX活用」という意味不明の話に化けたりするし、DXの名の下に実施されたはずの基幹システム刷新が単に技術的負債を解消する案件に過ぎなかったりする。私はDXという言葉を大切にしなきゃいけないと思ってきたが、こんなことではバズワードと化したDXはもう使うのをやめたほうがよいかもしれないな。 この「極言暴論」で何度も書いてきた通り、DXとは「デジタルを活用したビジネス構造の変革」のことであり、その「魂」はデジタルのほうではなくトランスフォーメーションのほうだ。そんな訳なので、DXと呼べるものは、(デジタルを活用して)全く新しいビジネスを創るか、(デジタルを活用して)既存のビジネスを大きく変革するかしかあり得ない。にもかかわらず、「それっ

                コンサルとSIerとIT部門の共同謀議の成れの果て、偽装DXプロジェクトはよく燃える
              • ZOZOTOWNのiOSチームを支えるチーム運用 - ZOZO TECH BLOG

                こんにちは、ZOZOTOWN開発本部でZOZOTOWN iOSの開発を担当しているらぷらぷです。 2024年8月現在、ZOZOTOWN iOSチームは正社員と業務委託の方をあわせて全14人で構成されてます。 組織上、ZOZOTOWNのiOSチームは開発1部と開発2部の2チームに分かれています。しかし、リリースバージョンの計画・開発フロー・技術課題・その他チームに関わる課題意識はiOSチームメンバー全員で共有しながら改善を進めています。 そのような共有・議論がここ数ヶ月、週次イベントとして固定化してきたので、各イベントの振り返りも兼ねて皆さまにZOZOTOWNのiOSチームを支えるチーム運用の数々を紹介します。 1つのバージョンがリリースされるまで まずはこちらの図をご覧ください。 ざっくりですが開発期間を省いてQA準備からリリースまでの流れを描きました。今年から毎週金曜に定期的にQA配布す

                  ZOZOTOWNのiOSチームを支えるチーム運用 - ZOZO TECH BLOG
                • 【海外記事】PyTorchは死んだ、これからはJAXだ — 深層学習フレームワークの現状を語るブログ記事が話題に

                  8月17日、「PyTorchは死んだ、JAX万歳」と題した記事が公開され、海外で人気を博している。この記事では、PyTorchの問題点と、それに対するJAXの優位性について、コードサンプルを交えて詳しく分析されている。 この記事では、PyTorchが科学計算の分野でどれほどの生産性を低下させ、技術的負債を増大させたかを強調している。PyTorchは本来、迅速なプロトタイピングを目的として開発されたが、その設計は大規模な分散システムでの使用に適していないという。 設計思想の違い PyTorchの設計思想は、TensorFlowの静的でパフォーマンス重視のアプローチに対して、動的でデバッグが容易、そして「Pythonらしい(Pythonic)」フレームワークを目指すというものである。しかしこの設計思想は、特に大規模なプロジェクトにおいて、スケーラビリティとパフォーマンスの面で妥協を強いられる。

                    【海外記事】PyTorchは死んだ、これからはJAXだ — 深層学習フレームワークの現状を語るブログ記事が話題に
                  1