MapStruct とは MapStruct の導入 MapStruct の簡単な使い方 @Mapping でプロパティをマップする 様々な @Mapping 定義 @MappingTarget でオブジェクトを更新する @Mapper インスタンスの取得 まとめ MapStruct とは Java Bean 間のプロパティのコピーを簡素化するコードジェネレーターです。 Commons Beanutils は実行時にリフレクションによりプロパティのコピーを行うのに対して、MapStruct はアノテーションプロセッサによりコンパイル時にマッピングコードを生成します。 生成されるマッピングコードは平易なメソッド呼び出しを使用するため、高速で、型安全で、理解しやすいものになります。 多層アプリケーションでしばしば行われる Entity と DTO の変換処理などのマッピングコードの作成を大幅に

自分がフロントエンドのアーキテクチャを考える時に、特に意識していることについてまとめてみました。 改善するべき点が多いと思っていますが、自分の考えを整理する意味で書き残したいと思います。 ここで言う「アーキテクチャ」とは？ この記事では、アーキテクチャについて主にコード間の依存関係の観点で考えています。 「なぜ依存関係なのか」については、次の意識しているポイントで触れていきます。 意識しているポイント 捨てやすくする 書いたコードを捨てやすいようなアーキテクチャを目指したいと思っています。 なぜなら、最初から良い設計はできないからです。（まれにできる人もいますが、少なくとも自分はできないです） 開発を重ねて理解が深まることで、より良い設計が見つかります。 良い設計が見つかった時に、既存のコードの修正・削除が必要になりますが、それができないと実現（実装）できないことになってしまいます。 コー

概要 2021/04/22に新しいWeb Componentsライブラリ、Lit(Lit 2.0)がリリースされ、同日ローンチイベントもYouTubeで生配信されました。 それに伴いPolymer ProjectがLitに改名されロゴが刷新されました。 ウェブサイトも新しく公開されました。チュートリアルとPlaygroundが刷新され、非常に便利になりました。 実装は https://github.com/lit/lit に公開されています。 LitElementとlit-htmlのおさらい 旧Polymer Project（Lit 1.0）では、lit-html(HTMLテンプレートライブラリ)とLitElement(Web Componentsを実装するためのライブラリ)の2つのライブラリが提供されていました。 LitElementにもテンプレート機能があったので、2つとも独立したライ

@nekobatoです。メルカリDesign SystemのWeb版開発者をしています。以前の記事で新しくなったメルカリ Webの紹介がありましたが、本記事ではそこで使われている、同じく新しくなったDesign System Webの紹介をします。 Design System Webの提供 Design Systemを元にした実装の構造はプラットフォームごとに異なりますが、Design System Webはmonorepoで管理されたnpm module群で、プロダクトはモジュールを用途に合わせて利用可能です。全てを使う必要はなく、基本的にはコンポーネントモジュール（CoreまたはReact）を利用すればDesign Systemの恩恵を受けられます。現在は新しくなったデザインのメルカリ Webで実際に利用例を見ることができます。 この記事はDesign System Webの技術的な概

FLEXY編集部の麻衣子お姉さんが、現場の最前線で活躍するエンジニアへ会いに行くこの企画。 「聞いたことあるけど良く分からない」「ざっくりと教えて」という非エンジニアならではの問いに答えてもらいます。技術書やWebで調べてもいまいち難しくて理解できないあんな技術やこんな技術。プロに優しく教えてもらいましょう。 今回のテーマは「アジャイル」。麻衣子姉さんもアジャイルという単語は聞いたことがあるものの、なぜ巷で流行っているのか、そもそもスクラムとの違いが何なのかは知らない様子。LINEの横道稔さんに伺いました。 アジャイルの基本をわかりやすく教えて！ 麻衣子：エンジニアの方がよく口にする「アジャイル」って何ですか……？「ウォーターフォール」との違いはなんでしょうか？ 横道：まず初めに、ウォーターフォールとアジャイルは対となる概念ではないということからお話させて下さい。 麻衣子：対比で語られるこ

柔軟性と拡張性の両立 LINEのデザインシステム構築における、フロントエンドエンジニアたちの挑戦 デザインシステムにおけるフロントエンド #2/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「デザインシステムにおけるフロントエンド」に登壇したのはLINE Front-end Standardizationチーム Front-end Engineerの岡崎晶彦氏。LINEはなぜデザインシステムを必要としたのか？　どのようにデザイ

Hype Driven Development(HDD) シード・アーリーステージのスタートアップの開発者のみなさん、こんにちは。突然ですが、ソフトウェア開発していますか？毎日設計しコードを書いていますか？私は毎日しています。毎日ビジネスドメインと向き合っております。今日はそんなみなさんに、弊社のソフトウェア開発の失敗談（ ハードシングスへの突入と脱出 の「根の深い技術的負債」を掘り下げる内容になっています）を共有します。この失敗からなにか参考になるものがあれば幸いです。 実際に起ったこと 2018年初頭にサーバレスとDDDの導入 弊社のHiCustomerサービスのアーキテクチャはサーバーレスとDDDを軸に設計されました。サーバーレス環境としては、AWS APIGateway、AWS Lambda、AWS DynamoDBを使ったAWS推奨の構成を採用しました。DDDはGolangを使用

はいさい！ちゅらデータぬオースティンやいびーん！ 今回の記事は筆者に珍しく、技術紹介ではなく、僕の個人的な意見を書きます。あくまでも、自説です。 React自体は画期的で、プログラミング界に貢献したプロジェクトだと思っていますし、完全に否定したいわけではありません。 Reactに対する違和感＝芽生えては大きく育った種 筆者はReactがとても好きでした。JavaScriptが好きになったきっかけもReactでした。何から何までもReactで書き直して、Custom Hooksを作って、refを子部品に渡したり、バリバリ満喫していました。 Vueも仕事の関係で習得せざるを得なくなったのですが、Vueは最高に大嫌いでした。これならReactで書き直してやるぅ！と思ったりも。 Reactについて社内でも導入を推進したり、React入門の勉強会を開いたりもしています。 しかし、そんな筆者は、最近に

権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい

ペイトナーでエンジニアをやっている脇田慎平（@shimpeee_）です！ 僕が入社した2022年5月からチーム内でペアプロ導入を提案し、実際にこれまで何度か実施して得た経験や気づきを書きます！ 結論 めちゃくちゃにイイです！！！ これからも続けていきます！！！ 以降、始めたきっかけや良かった点、苦労したことなどを書きます。 きっかけ ペイトナーには、「同期作業」という文化があります（僕がとても素敵だと思う会社文化のひとつです）。 「オンラインで繋いで、仕事の会話するもよし、雑談するもよし、黙って作業するもよし」 というものです。 業務上でのもくもく会みたいなものです。 「biz側（PM） x エンジニア」の同期作業を週2回、各30分ずつやっているのですが、これがもうすごく良くてですね。。。 ペイトナー社では現在、フルコミットメンバーは週2の出社でオフィスの席数の関係で出社日を曜日で分散させ

超速で成果を出す アジャイル仕事術 プロフェッショナル2.0という働き方 【本の概要】◆今日ご紹介するのは、先日の「未読本・気になる本」の記事でも大人気だった一冊。 いわゆるコンサルタント系の仕事術本なのですが、この手の本の中でも個人的ににしっくりくる内容でした。 アマゾンの内容紹介から一部引用。★ベストセラー『アーキテクト思考』共著者でグローバルで活躍する気鋭のコンサルタント初の単著！ ★答えがない時代に、素早く成果を出す方法がわかる ★ＡＩやロボットにも代替されないスキルが身につく ★組織に頼らなくても生きていける力が身につく ★世界中の誰とでもコラボレーションして成果を出せる力が身につく 中古価格が定価をはるかに上回っていますから、「10％OFF」のKindle版がオススメです！ Story map / visualpun.ch 【ポイント】■1.心に留まったイベントをまとめて自分だ

ANDPADフロントエンドエンジニアの小泉（@ykoizumi0903）です。Vue / Nuxt での開発を行っています。 このテックブログでも、 Vue Composition API を使った開発にまつわる記事を過去に何件か書いていますが、現在担当しているプロダクトの開発に携わるようになって2年ほど経ち、いわゆる技術的負債と呼ばれるようなものも少しずつ増えてきました。 そういった状況を改善するアプローチの1つとして、Nuxt.js の既存リポジトリにおける型チェックのルールをより厳しい設定に変更する、という取り組みを2ヶ月ほどかけて行いました。 今回はその取り組みにおける道のりを振り返って、苦労したことや良かったことなどを書いてみたいと思います。 導入を決めるまでの流れ きっかけは noUncheckedIndexedAccess を知ったことから 弊社のSlackにはtimes文化

GA4、導入しないといけないと思っていても、さっぱりわからんからやる気がしなくてどうしよう？ってなる時がありますよね。私も数か月前まではそんな感じでした。正直なところギリギリまで逃げ回りたかったんですが、そうもいかなくなったので勉強することに。 ではなんで「わからん」となってしまうのでしょうか？そこがわかれば対応もできるので「わからん」理由と解消法をまとめてみました。 「Google アナリティクス」と名乗っているところ ここがわからなくしている一番の原因です。Google アナリティクスと名乗っているので、今までのGoogle アナリティクスの延長線上にあるものだと思ってしまうんですが、全くの別物で生まれも育ちも違っています。 今までのGoogle アナリティクス UrchinはGoogleアナリティクスの元となった製品。グーグルに買収されGoogleアナリティクスがリリースされた後も、

週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、

今お世話になっているスタートアップの会社さんで、フロントエンドのVue2アプリケーションをマイクロフロントエンド化しました。 今後、Vue.jsを取り巻く環境が急激に変わった場合を想定し、React.jsもしくはVue3にアップデートしていくために、マイクロフロントエンドアーキテクチャを採用しました。 圧倒的な速度で進化していくフロントエンドのツールおよびライブラリ、これら全てにキャッチアップをして、技術的負債を取り除いていくためには、すでにマイクロフロントエンド以外の選択肢を除いてないと思います。 今回紹介するicestarkを実際に使ってみた上で、より多くの人にこのicestarkを知ってほしい！と思ったので、まとめてみました。 ハンズオン記事はこちら: 更新履歴 Whyマイクロフロントエンド 今回はVue2.XからVue3.xのアップデートを漸進的に行うための決断でしたが、そもそもな

記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEで働くエンジニアにいろいろと話を聞く「LINE Engineer Insights」。LINEの技術組織で働く個々人に、何を重視して技術者としてのキャリアを歩んでいるのか、今LINEで何に取り組んでいるのか、今後実現したいことなどを聞いていきます。 今回登場するのは、フロントエンド開発センターに所属する、フロントエンド領域のスペシャリストでありエンジニアリングマネージャーを担う花谷拓磨です。花谷がLINEに入った理由や働くうえで大切にしていること、OSS活動にかける思いなどをインタビューし支える思想や行動指針を聞きました。 事業や組織の核心に迫る仕事に携わりたくて、LINEへ入社 ――花谷さんがLINEに入った理由につ

MP3ファイルをダウンロード 内容紹介 GitHub Copilotの裏側、GPT、GPT-3、Scaling Law、Multi-head Attention、難解なトピックをわかりやすくする説明する方法などについて語っていただいたエピソードです。 出演者 GitHub Copilotの裏側、GPT、GPT-3、Scaling Law、Multi-head Attention、難解なトピックをわかりやすくする説明する方法などについて語っていただいたエピソードです。 話したネタ AIcia Solid Project GitHub Copilot とは？(補足: 本ep公開時点でGA) GitHub Copilot の裏側で何が動いているのか？ GPT(Generative Pre-trained Transformer) とは何か？ 言語モデルのパラメータとは？ パラメータって GPT

近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「

ぼーっと。最近は、フルスタックすきまエンジニアっぽい。と思ったので、とりあえずタイトルだけ書いて、深く考えずに書き始めてみる 僕は、好きなサービスの周りのことだと、何をやっても楽しいタイプなので、これをやったらチームにとって良さそうかな、って思うことをやってたら楽しい。ただ、そのままどっかに行ってしまうとあれなので、軸足はコーディングに置くように意識してる あと、自分は色んなことを同時に考えられるタイプではないので、たくさん面白そうなことがある中で、最大でも3個くらいしか選べないよなぁと思っている。それ以上手をだしてしまうと、混乱する。だから、今の自分がどのスキマを埋めるのがいちばんいいかなぁってのを雰囲気で考えながら動いてると思う。たぶん 具体的に何をやってるかなぁって考えてみる。色々あるけど、同時にやってるわけじゃなくて、どれかをやってるときは、別のことは横に置いてる コード周り 軸足