今Reactを使うならピュアなCSSをサポートするUIフレームワークやライブラリを選定するのがマルそうと思った話
最近個人開発でNext.jsの環境を立ち上げた際に、スタイリングをどうやってやろうかなと迷ったので初心に帰って最近のスタイリングについて調べ直してみました。結構面白かったので、記事にまとめることにしたので、よかったら読んでみてください。 本記事では以下に触れます。 React界隈におけるスタイリング方法の歴史的変遷 なぜタイトル通りピュアなCSSをサポートする機構が良いと感じたか おすすめのスタイリング機構 ざっと振り返るReactのスタイリング方法の歴史的変遷 私が最終的にピュアCSSを推したいと思った理由をお話する前に、爆速で変わり続けるReactとともに、スタイリングはどう変遷していったのかをざっとまとめたいと思います。 （こういうのって、歴史と組み合わせて理解すると、結構深まりますよねと思っているのは私だけでしょうか…、いえそんなことはないはず😊） 大昔: CSS Modules
入社 4 ヶ月の私が初見コードでも開発のスタートダッシュを切る技術 - エムスリーテックブログ
はじめに 前提となるマインドセット 具体的な Tips コードを読まずに理解する技術 とりあえず Clone する インタフェースで理解する テストコードで理解する 慣習名で理解する コードの詳細を理解する技術 デバッガを使う とりあえずサンプルコードを書いてみる 分からないなら聞く 初見コードに安全に変更を加える技術 インタフェースを明らかにする Stub としての実装を用意する Design Doc を書く テストを書く まとめ We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています はじめに 京都オフィス在籍で、AI・機械学習チームの山本(@hiro_o918)です。 このブログはサテライトオフィスのメンバーで投稿されるブログリレー 3 日目の記事になります。 関西在住だとオフラインでのコミュニケーションに悩みが
Google Apps Script を TypeScript に移行した話 - Stanby Tech Blog
株式会社スタンバイでフロントエンドエンジニアをしている川野です。 フロントエンドエンジニアという役割を担っていますが、最近では開発者体験や開発生産性というところに興味があり、そのあたりの改善にもよく取り組んでいます。 はじめに 私たちのチームでは、Google Apps Script (GAS) を利用して、非エンジニアの人たちがシステムにスプレッドシートのデータをアップロードできる仕組みを構築しています。 GAS は手軽に開発でき、プロジェクト開始当初の小さな要求を満たすには十分なものでした。 しかし、プロジェクトが進むにつれ次第に要件が増えていき、GAS で対応するのが大変になるほど複雑になってきました。 また GAS では、型の恩恵を受けることが難しかったり、エディタのサポートが満足いくものでなかったりし、増大していく複雑さに立ち向かうのが難しくなってきました。 このような課題を解決
利きプロセススケジューラ
kernel/vm探検隊part7の発表スライドです。 https://kernelvm.connpass.com/event/330079/
リモートチームとして成長し、生産性を上げるための挑戦の軌跡 - LegalOn Technologies Engineering Blog
こんにちは、LegalOn Technologies 検索・推薦チームの志水と勝田です。 我々のチームではこの1年をかけてチームビルディングやアジャイル開発に繋がる様々な手法や施策を試し、その成果が徐々に出てきました。今日はその過程を紹介いたします。時間がかかっても必ず成果は出ると思うので、似た取り組みをしようとされている方はぜひ参考にしてみてください！ はじめに 2024年春、「LegalOn Cloud」がリリースされました。これまでの開発では、各機能に専任メンバーを割り当て、定期的な情報共有や技術的な相談を行う方式を採用していました。この開発スタイルは、開発内容が明確な状況下で高いパフォーマンスを発揮していました。しかし、属人性の解消や、不確実な状況への柔軟な対応のため、より効率的でスケーラブルな開発スタイルを追求する必要性が生じました。 検索・推薦チームは全員がフルリモートで働いて
早くて安全、以外のRustの好きなところ
こんにちは。Rustを愛し、Rustに愛された男です。 BoostDraftでは、一部のシステムでRustで使用しています。そこそこQPSのあるAPIサーバーや、そこそこ量のあるデータの解析などです。 Wikipediaでは、Rustの説明として以下のような一文から始まっています。 Rust（ラスト）は、性能、メモリ安全性、安全な並行性を目指して設計された 引用元：Rust (プログラミング言語) また公式サイトでは、Rustを使う理由として「パフォーマンス」「信頼性」「生産性」が挙げられています。 早くて安全！にフォーカスされがちなRustですが、僕がRustを使う一番の理由は「生産性」です。 なので今回は、生産性に寄与しそうな、僕のお気に入りポイントをいくつか紹介したいと思います。 エコシステム Cargo CargoはRustにおけるビルドシステム兼パッケージマネージャです。 ビルド
Tidy First? 個人で実践する経験主義的ソフトウェア設計 | Ohmsha
コードを整理して読みやすくするには、扱いやすい部分に分割する必要があります。本書は、XPの考案者でデザインパターンやテスト駆動開発のパイオニアであるケント・ベックが、システム全体の構造を考えて、どの段階で、どのように整理するかを提案します。たくさんのコードを含んだ大きな関数がある場合、それを論理的に小さなかたまりに分割する方法を解説し、結合性、凝集性、コード整理の費用対効果など、ソフトウェアデザインの背後にある理論を学びます。
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
レガシーシステムにどう立ち向かうか 複雑さと理想と現実 2024/11/06 【挑戦者必見！】DDDで複雑なシステムをリアーキテクチャをした1年の体験談withミライトデザインhttps://asken.connpass.com/event/332947/
Tauri（V2）は滅茶苦茶いいぞ！という布教をしていきたい - Qiita
概要 Elin Custom Portrait EditorというツールをTauriとSveltekitを使って製作したんですが、 制作にあたって「Tauri、良すぎない？」と感じたのでその魅力を伝えていきます。 1.ビルドしたファイルサイズが本当に小さくコンパクトな構成 元々別のツールをElectronで制作していたんですが、いざビルドしてみると本体exeだけで200MBを軽く超える超巨大アプリになってしまうのが困りものでした。 (インストーラーで配布する前提の仕様だろうし開発もそこまで気にしてないんだろうけど、私はインストーラー不要のポータブルアプリ派なので…) Electron BuilderでPortable設定にすれば単一.exeとして出力も出来るけど、今度は実行速度が犠牲になってしまうという特大の罠が待ち受けています。 対するTauriはビルドサイズがだいたい10MB前後と非常
軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう
DDDからOOPのプラクティスを学ぶのではなく、OOPのベストプラクティスをスタイルガイド本で学んでDDDに活かそう
楽楽販売 案件開発チームを紹介します！ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、あるいはこんばんは。 私は楽楽販売の案件開発チーム（新機能開発チーム）の開発リーダーをしている@tacloseです☆ 今回のブログでは、楽楽販売の案件開発チームの構成や業務を紹介しようと思います！ 累計導入社数4,400社突破の楽楽販売がどのような開発体制で、普段どんな事に取り組んでいるのかを知ってもらえればと思います！ 楽楽販売の開発チーム構成 チームの紹介 チームのミッションは何か？ 普段具体的にはどんな事をやっているのか？どんな事を考えているのか？ 最近行った業務改善とは具体的にどんなものがあるのか？ 今後の展望 さいごに まずは各チームの業務分担から説明します。 楽楽販売の開発チーム構成 チーム名 業務 DevOpsチーム 運用・保守、リリース作業等を行うチーム SAチーム カスタマーサポートが対応出来ない技術的な問い合わせに対応するチーム VCチーム ベトナム開発拠点
会社の資料を今すぐDifyで要約しよう！ - Qiita
はじめに 最近、Qiitaに投稿される記事を見ていると、「Dify」という単語をよく目にするようになりました。記事の内容から、自分のPC上でChatGPTのような「チャットボット」を簡単に作成できるツールのようだと感じたため、今回はDifyの構築方法や操作感について確認してみることにしました。 Difyのインストール Difyのインストールと環境設定は、公式サイトの以下のページを参考に進めました。 今回はWindows OSでgitコマンドを実行できるように事前にインストールしておく必要があります。また、Docker Desktopもあらかじめインストールされていることが前提条件です。これらの手順については、多くのサイトで詳しく解説されているので、そちらを参考にしてください。 事前に必要なこと： 項目 説明
SREの前に
2024年11月06日(水) 18:00～19:00の予定に遅刻してしまい、大変申し訳ございませんでした。お詫びとして、当初非公開予定であった資料を公開させていただきます。元々、公開する予定ではなかったので補足が足りない部分などあると思いますのでご容赦下さい。 ブログなどで補足情報出すかもなので気…
EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog
はじめに こんにちは！コンテナ基盤グループの楠本です。 前回の記事EKSコンテナ移行のトラブル事例：FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blogを投稿してから半年以上も経ちました。（時が流れるのは早い… 前回はSREグループコンテナ化推進チームとしてでしたが、今回は挨拶の通りコンテナ基盤グループとしての投稿です。 元々ECエンジニアリング部門のSREグループとして活動していましたが、今年初めに組織編成があり、プラットフォームエンジニアリング部門の１グループとして活動しています。 今回は組織とのミスマッチからEKS on FargateからEKS on EC2へ切り替えた話をご紹介します。 見どころは EKS on Fargateとプラットフォームエンジニアリングとの相性 EKS on EC2へ移行する際に検討したこと 移行して得られたこと の３点です
マイクロソフトが買収したコンテナ最適化Linuxの「Flatcar Container Linux」、CNCFのインキュベーションプロジェクトに採択
マイクロソフトが買収したコンテナ最適化Linuxの「Flatcar Container Linux」、CNCFのインキュベーションプロジェクトに採択 マイクロソフトは、同社が2021年に買収したコンテナ環境に最適化されたLinuxディストリビューションである「Flatcar Container Linux」（以下、Flatcar）が、Kubernetesの開発などを主導するCloud Native Computing Foundation（以下、CNCF）のインキュベーションレベルのプロジェクトに採択されたことを発表しました（CNCFの発表）。 "I couldn’t be more delighted with the news that the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee
Google コードレビュー・ガイドライン要約【コードレビューの基準編】
はじめに レビュー基準について再考する機会があり、調べていたところ、すばらしい記事を発見しました。 Google がコードレビュー・ガイドラインを公開しているようです。 有志の方による 日本語訳版 もありました。 今回は日本語訳版の内容を元に、筆者なりに概念をまとめてみました。 「Google コードレビュー・ガイドライン要約」シリーズとして、書いていきます。 シリーズ構成 ※リンクが貼られていない箇所は未要約です コードレビューの仕方 コードレビューの基準 ← here!! コードレビューの観点 コードレビューの進め方 コードレビューのスピード コメントの書き方 取り下げへの対応 CL 作成者のガイド 適切なディスクリプション 小さな CL レビューコメントへの対応 緊急事態の CL 本シリーズ通して 少し長くなりますが、本誌議の立ち位置を書いておきます。 気にならない方は 用語 まで飛
過去の経緯の調べ方 - Konifar's ZATSU
何かの取り組みを始める時、たいていまずは"過去の経緯"をざっと調べると思う。そうしないと過去に起きた問題を踏んでしまったり再発明をしてしまったりするからである。 皆当たり前にやっているように見えて、この過去の経緯の調べ方には意外とスキルのバラつきがある。自分も常にうまくできているわけではないので、思考整理のために雑に書き出してみる。 たとえば一例として、「Androidの自動テストの方針」を決めようとしているとしよう。背景にある課題は適当に想定してほしい。次のようなステップで過去の経緯を調査していく。 1. 調査期間を決める 調査はダラダラとやってしまいがちなので自分で期限を決める 内容にもよるが、自分は半日~1日に設定することが多い。社外の方とのスケジュール調整が入る場合には1週間くらいかかることもある 例で言うと、自分ならいったん1日で設定してガッと集中して調べてキャッチアップすると思
食べログの実践事例に学ぶ：プロジェクト進行におけるスピードと品質を保つ段取り - Tabelog Tech Blog
はじめに こんにちは。食べログ開発本部 ウェブ開発1部の大橋と中村です。 私たちは食べログのサーバーサイドの開発を担当しており、今回食べログで利用している決済システムの機能拡張に伴うリプレイスを行いました。 今回のプロジェクトを進めていて特に感じたのが「ステークホルダーが多いプロジェクトほどスピードと品質が手を動かす前の段取りの良さによって決まる」ということです。 本記事では実際に行った決済システムのリプレイスを事例に段取りがプロジェクトの品質および開発スピードにいかに寄与するのかを紹介します。 段取りの重要性 この章からは段取りの内容についてお話しします。 段取りができているとは下記3つの状態だと考えています。 業務や要件、実際の利用シーンが決まっている アサインするチーム・ステークホルダーが決まっている チームの間でシステムやデータの責務が明確になっている 段取りは序章でお話しした通り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - BemiHQ/BemiDB: Postgres read replica optimized for analytics
4ヶ月かかる作業を1ヶ月で完遂。大規模システム開発を高速化させる“タスクフォース型組織” —イオンネクストの事例から学ぶ ｜AEON TECH HUB
