こんにちは。強いUIはボタンを捨てるをスローガンにScrapboxを開発しています。shokaiですshokai.icon Helpfeel Advent Calendar 2022の5日目の記事です 昨日はHelpfeelエンジニアのyado.iconさんでした 採用面接中にチャーハン・ピラフ判定器とスタバ警察botで盛り上がる会社に入った | 株式会社Helpfeel ヨコハマハウスフラペチーノがエンジニア採用の役にたった？みたいで良かったです <a>タグの挙動を工夫する事で、Scrapboxからみたいなボタンをなくしました 更新ボタンの役割は2つ 更新がある事を教える 押すとアプリが更新される Scrapboxも昔こういうメニューがあった 今はもう無い では解説ですshokai.icon SPAのタブ永遠に開きっぱなし問題とは？ SPAとstaticなwebサイトの違い static

当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう？　あらゆるソフトウェアに通用する原則はあるのでしょうか？　そもそも「原則」とは何を意味するのでしょう？ 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良

こんにちは。福岡オフィスで課題解決部に所属しているエンジニアの petamoriken です。趣味で ECMAScript の動向を追ってたりします。よろしくお願いします。 この記事では私がレガシーだったピクシブ百科事典のフロントエンドを如何にしてリファクタリングし、モダン化していったかを紹介していこうと思います。 まずピクシブ百科事典の構成の調査 ピクシブ百科辞典のフロントエンドのコードは複数の JavaScript がクラシックスクリプト形式で読み込まれ、実行されていました。もっと詳しく説明すると、ページ共通のエントリーポイントの中で今どのページにいるかの判定をし、そのページに必要なスクリプトを LABjs というライブラリを使って動的に <script> タグを追加することによって読み込んでいました。 これにより別のコードで定義されたグローバル変数を使うのが当たり前の状態になっていま

「Web Speed Hackathon 2022」という「非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技」があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う「高速」とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で「学生向け」と「社内（サイバーエージェント）向け」が行われたらしく、まだ500点を出した人はいません。 そこで僕は「満点を出したい」と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日（17日）、ついに500点満点を出しました！ たぶん、レギュレーションはクリアしている、はずです（もし違反してたらすいません…）。 自動で行われる「Visual Re

はじめに 私事ですが11月12日に結婚式をあげました。 私達夫婦はよく一緒にアプリを作っているので、今回もなにか一緒に作れないかと思い、余興のクイズアプリを作ることにしました。 ついでに席札もQRコードにして、webアプリ内でメッセージも入れれるようにしました。 作ったもの ユーザーに配布用のサイトと、披露宴会場で投影する用のサイトの２つを作りました。 ユーザーに配布用のサイト 当日はこういう↓感じの席札を用意しました。 この席札は名刺サイズで印刷して一人ひとりラミネートしたのですが、地味に大変な作業でした。 QRコードを読み取ると、以下DEMO動画のようなサイトが現れます。 ちなみにクイズに関してはスクリーンに問題が表示されるまでは回答できないようになっています。（DEMO動画では省略） ページの表示速度を上げたかったので、uuid、名前、メッセージ等に関してはcsvでダウンロードしてか

こんにちは、あるいはこんばんは。村山です。皆さまGoogleアナリティクス4(以下、GA4)との戯れには慣れてきましたでしょうか。GA4の使い方は「完全に理解した」という方もいれば「まだまだこれから計測実装していくから触っていない」みたいな方もいらっしゃるのではないかと思います。 今回は、後者である「これからGA4を計測実装していく」方にむけて、どのようにGA4の計測実装を推進したら良いのか書いていこうと思います。 どのようなイベントを計測するべきか？ データに関わる方が1名と少ない場合 データに関わる方が2名以上の場合 データ計測の設計書となるドキュメントが必要だ GA4はさまざまなイベント計測方法がある GA4管理画面内の「イベントの変更」 GA4管理画面内の「イベントの作成」 GA4管理画面内の「オーディエンストリガーイベント」 GTM内からイベントタグの発火 GA4の計測設計にはN

2022年11月7日（月） 「現場で役立つシステム設計の原則 - Forkwell Library #9」 発表資料

こんにちは。サービスインフラ-Bグループの宮本・高野です。 今回はManabiCon第3回で発表した「梅田オフィスで認証VLANを導入したプロジェクト」について紹介します。 自己紹介 梅田オフィス構築後に発生した問題 前提 フリーアドレス 通信品質の安定 本題 そもそもVLANとは何なのか？ じゃあ認証VLANとは何なのか？ 認証VLANのキーワード「IEEE802.1X」とは？ プロジェクト概要 プロジェクト体制 プロジェクトの予定期間 実現したいこと 検証時の苦労 苦労したことその1: 必要機材とテストパターンの洗い出し 苦労したことその2:検証環境の構築 苦労したことその3:VLAN設計変更 苦労したことその4:有線LAN接続時、通信が不安定になる 苦労したことその5:認証VLANを利用しているPCへリモートデスクトップ接続ができない 在宅勤務・出社勤務 802.1X の認証モードに

はじめに 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りとNode.js(Nest)やRailsを用いたバックエンド(API)の開発をしています。 その中で使っていたAPI設計について改めて学び直したのでまとめて行きます。 この記事の対象者 エンジニア初心者から中級者 APIについて学びを深めたい人 この記事の目標 APIについて学ぶ 我流ではなく正しいAPI設計について学ぶ この記事でやらないこと 具体的にコードを用いたAPI設計の書き方の説明に関しては下記の記事で解説をしています。 APIについて APIとは APIは"Application Programming Interface"の略で、直訳すると「アプリケーションを使プログラミングを使ってつなぐ」という意味

yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ

初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータン GoF/PoEAA 階層化アーキテクチャ DDD本のサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDD本のページを見てみよう！！！ DDD本の最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ

コンテンツ投稿系のWebサービスでは「ユーザーのページに好きな独自ドメインを登録できる」という機能をつけたくなることがあります。ユーザーからすると「コンテンツが自分自身の所有物であること」を感じやすいですし、コンテンツのポータビリティが上がりますし、とても夢がありますよね。僕もいつか実装してみたい機能のひとつです。 しかし、この機能を提供するには、以下のようなハードルがあります。 料金 ベンダーロックイン 複雑な実装（とくに認証） (1)の料金についてはデプロイ先によります。例えばVercelであればProプラン以上であれば無制限に独自ドメインを登録できます（Unlimited custom domains for all Pro teams）。 Google Cloudの場合にはCertificate Managerで独自ドメインごとの証明書を管理するのに「ひとつあたり○USD」という感

PHPerKaigi 2024に「ゴールド」「T-SHIRT」スポンサーとして協賛！ PHPでQuineに挑戦してみた in PHPerチャレンジ企画

社内勉強会用 デザイナーとフロントエンドエンジニアの境界をなくし、UI開発を加速させるためのコンポーネント設計入門 ※フロントエンドエンジニア視点 [Keywords] - 共通認識としてのデザインシステム - 共通認識としてのコンポーネント設計

ぼくは「スタートアップを量産する会社」を運営しています。 事業をバンバン立ち上げて、PDCAを回しまくって、うまくいったものだけを法人化する。「スタートアップファクトリー」とよばれる、日本ではまだ珍しいビジネスモデルです。 かつてヘンリーフォードが「Ｔ型フォード」によって自動車を大量生産したように、事業立ち上げのプロセスを「型」にして、起業に再現性をもたせる。 まるで工場のように、革新的な「会社」が次々に生まれていくーー。 それがぼくらの目指す世界です。 「そんなにうまいこといくわけない、ただの絵空事だろ」と思われるかもしれません。 でも実際、うまくいきはじめているんです。 SaaSモデルとして、初めての成功事例が、この「建材サーチ」というサービス。建材業界に特化したVertical SaaSです。 https://lp.kenzai-search.jp/実はこの事業、構想から半年で法人化

こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Componentのディレクトリ構成」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいてうまくいっていると感じているComponentのディレクトリ構成についてご紹介していきます。 ディレクトリ構成 Componentは src/components の中にまとめていて、その下に以下の4種類の分類ディレクトリを切っています。 src/components/page src/components/model src/components/ui src/components/functional 分類ディレクトリを考えるにあたって重視したポイントは以下。 新しくco

結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア

BPStudy#178〜成長し続け、変更を楽に安全にできるソフトウェア設計とは 株式会社ビープラウドが主催するIT勉強会 　2022年6月30日 設計を学ぶのは自分のため 「正しい」学び方があるわけではない 設計の学びに特定の到達点はない 何を学ぶのか 設計の学び方 上達する：練習して変化する 成長する：時間をかけて変化する ひらめき：突発的に変化する

NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。

2010年代を乗り越えてきた経験者が読むと良さそうという噂を聞いたので読んでみた。 内容まとめではなく感想です。各章のタイトルだけは丸々記載してますが、目次として上記ページで全て公開されているものです。 ちなみにこれ書いている私はソフトウェアアーキテクトではなく、フロントエンドアプリケーションの設計を担当するテックリードぐらいのレイヤーです。この書籍の中でいう「開発者」です。 業務ではフロントエンドアプリケーションの設計・実装をしています。 全体的な感想 1章（イントロダクション）、22章（効果的なチームにする）、23章（交渉とリーダーシップのスキル）が特によかった。 やっぱ "結局人" の部分が刺さってしまう。 心に書きとめておきたい3つを挙げるとしたら以下。 ソフトウェアアーキテクチャとは「構造」「アーキテクチャ特性」「アーキテクチャ決定」「設計指針」の4つから成る 「一見どう見えよう