はじめに ZOZOTOWN開発本部の武井と申します。ZOZOTOWNのフロントエンドリプレイスプロジェクトを主に担当しております。ZOZO DEVELOPERS BLOG でも「ZOZOのリプレイスプロジェクトで得られる唯一無二の経験。大規模サービスを進化させるやりがいとは」というインタビュー記事を掲載しておりますので、もしよろしければこちらも併せてご覧ください。 さて、本題です。現在ZOZOTOWNではオンプレミスかつ、モノリスだった既存システムをマイクロサービスAPIに責務を分割したり、インフラをクラウドに移行したりしています。しかし、いわゆるWebのUIを構築するためのシステムは現在も既存システムに新機能開発や機能改修を行なっており、リプレイスに着手できていませんでした。 そこで、まずホーム画面から段階的にリプレイスすべく設計・開発を昨年から行ない、無事リリースできました。ZOZOT

こんにちは、タイミー開発プラットフォームチームで業務委託として働いている宮城です。 タイミーはリリースから4年が経過したプロダクトで、2022年の前半から一部領域でGraphQLを利用し始め現在導入を進めています。 本記事では、GraphQLをプロダクトに導入する上で判断に迷った箇所や課題に対して、タイミーでの意思決定とその理由を紹介します。参考にしていただければ幸いです。 GraphQLの選定理由についてはこの記事では触れませんが、CTOの@kameike が以下のイベントで詳しく紹介する予定です。まだ参加申し込みは可能ですので、興味がある方はぜひ合わせてご覧ください。 timeedev.connpass.com なお、本記事のタイトルはソウゾウさんの以下の記事にインスパイアされています。 engineering.mercari.com GraphQLの「Getting Startedの

こんにちは、@nerusanです。 皆さんは、状態管理ツールなどは使っておられますでしょうか。 例えば、有名なところでは、Redux, Recoilなどがあります。 今回は、Reactにおける状態管理についての動向を知ることで、なぜ、Reduxが使われるようになったのか？何をReduxなどのグローバルな状態管理ライブラリで扱えばいいのか？現状どうなっているのか？を調べたので、記事にしたいと思います！ 自身の解釈なので、もしかしたら、誤ったことを言っている可能性もあるので、その際はご指摘いただければと思います m(- -)m SPAの流行り SPAとはSingle Page Applicationの略であり、新しいページに移動する際、サーバからページを再読み込みするのではなく、JavaScriptを使って、クライアント側のブラウザで動的にページを書き換えるアプリケーションを指します。ページご

【出身】東京都 【年齢】27歳 【職業】エンジニア兼ブロガー 【趣味】バスケ,読書,麻雀,旅行,ブログ 【好き】自由,刺激的,合理的なこと 【嫌い】不自由,単調,非合理的なこと My軌跡本章では大学入学以降に絞ってお話します。 大学入学以前のハニ太郎は「友人と遊び、部活に明け暮れながら青春時代を過ごしました」といったような感じです。 公認会計士を目指しTACに通う大学に入学してすぐの話です。 公認会計士になるべくTACに通い始めます。 上記を見てもらえれば分かると思いますが、大したことも考えずに行動してしまいました。 今思えば反省しかないです。 結局、公認会計士試験には合格できず挫折。 ただ後悔は全くしておりません。 というのも、社会人の方と勉学に励むという素晴らしい経験をすることができたからです。 また、日商簿記検定1級には合格できました。 会計学や会社法など社会人として必要とされる知識

この記事について SWR について色々と学んだので、その知見をここで共有したいと思います 💪 ※ 基本的に以下の公式サイトの情報を参考にしています 📖 そのため、この記事で出すサンプルコードなどは主に上記の公式サイトから引用させてもらっています。予めご了承ください 🙏 SWR とは何か？ SWR は、Next.js を作っているVercel 社が開発しているデータフェッチのための React Hooks ライブラリです。"SWR"と言う名前は、 stale-while-revalidate の頭文字をとって名付けられています。そのため、SWR はstale-while-revalidateに基づいた処理と設計になっています。 stale-while-revalidateについて解説したい所ですが、解説するとすごく長くなってしまうため、ここでは「 キャッシュをなるべく最新に保つ機能 」

今回は、何らかのパラメータを扱うAPIを設計する際に、どこにパラメータを含めるべきかという問題について。 選択肢は3つあります。 1. クエリストリングに含める 2. リクエストボディに含める 3. パスに含める それぞれどんなユースケースに適しているのか例を挙げます。 1. クエリストリングに含める 何らかのリソースのフィルタリング、ソート、ページングを実現したいときに用います。 クエリ と名前がついているくらいですからね。 一覧や検索が主ですね。ゆえに GET 以外で見ることはほぼありません。 ただし、認証のような例外もあります。これは後述します。 検索

最近 React のドキュメントが新しくなったということで読んでみた。第一印象としては、とにかく懇切丁寧で React というか JavaScript すら初心者という読者でも基礎的な考え方が身に付くようになっている。ただ、深い内容まで読み進めると「同じ Virtual DOM のフレームワークでも Elm とだいぶ違うな」と改めて思った。 これはどちらが良いとか悪いということではなく、一長一短あると思う。筆者は長いこと Elm を使ってきたが React も嫌いではなく、趣味を含め色々な場面で重宝している。ただ、 Elm Architecture の提供するシンプルな仕組みには依然として価値があると思っており、それがあまり世の中に知られていないのが勿体無い。というのが、この記事を書こうと思った動機である。 昔は「部分的に取り入れても Elm メリットは享受できないから Elm やってよ」

Rubyのブロックを雰囲気で使ってる人に向けて、ブロックの使い方を整理する。 ブロックとはなにか ブロックは「処理の集合体」です。無名関数とかラムダ式とかクロージャのようなものです。 例： # { ... } がブロック [1,2,3,4].map { |e| e + 1 } # do ... endがブロック [1,2,3,4].map do |e| e + 1 end

はじめに この記事を持ってQiita400本目の投稿です🎉🎉🎉 みなさん、日頃見ていただきありがとうございます。 今回はそんな400本目を記念して、Qiitaを書き始めてをふりかえりつつ Qiitaを書くことで人生が大きく変わったということをお伝えできたらと思います！ Qiitaを書き始めたきっかけ 私がQiitaを書くきっかけになったのは今から3年前のエンジニアとして働いて半年ほど経った頃でした 私「先輩、何見てるんですか？？」 先輩は、会社でLaprasのスコアを画面で見ている 先輩「あーこれは、自分の技術力を可視化してくれるやつです。転職とかで将来役立つと思うから登録しておいたほうがいいですよ」 私「そんなのあるんですね、登録しています！」 それから数日後 私「なるほど。この技術スコアをあげるにはGithubを更新したり、記事をあげたりするといいのか」 私「でも、Githubに

OpenCVを使用して画像から複数のオブジェクトを認識し、切り出すための一般的な手順は以下のようになります： 前処理: 画像を読み込みます。必要に応じて画像をリサイズします。グレースケールに変換するか、あるいは必要に応じて色空間を変更します。オブジェクトの検出: エッジ検出、閾値処理、または色に基づくフィルタリングなどを使用してオブジェクトを検出します。輪郭検出を行い、オブジェクトの境界を見つけます。輪郭の処理: 検出された輪郭をフィルタリングして、ノイズや小さなオブジェクトを除去します。必要に応じて輪郭を近似します。オブジェクトの切り出し: 各オブジェクトの境界ボックスを使用して画像からオブジェクトを切り出します。オブジェクトごとに個別の画像として保存するか、表示します。後処理 (オプション): 切り出されたオブジェクトをさらに処理するためのステップを行います。例えば、オブジェクトのサイ

こんにちは、アルダグラムでエンジニアをしている松田です。 Reactで状態を管理するにあたっては、useStateの利用が挙げられることが多いです。 実際、数値や文字列、真偽値などのプリミティブな値であれば、useStateが適切なケースが大半でしょう。 ただ、値を投入するだけではなく、追加・削除・更新といった操作が要求されるケースもあると思います。 その際に、配列やオブジェクトなどといった形式でデータを取り扱うことに併せて、useReducerやuseContextの利用も視野に入れると、開発手法の幅が広がります。 今回は、次の目標に掲げるUIを実現する過程を、useReducerとuseContextの活用方法の1つとしてご紹介します。 目標 以下のような操作ができるUIを作成する。 名前と年齢を入力して、ユーザーを作成 作成したユーザーは一覧に表示 各ユーザーの権限(一般 or 管理

はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と

はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基本的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ