# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお

Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳

[beta] Next.jsクイズ2 • <p>にはなにが表示されるでしょうか？ /app/page.tsx "use client"; import { useCallback, useEffect, useState } from "react"; export default function Home() { const [date, setDate] = useState(); const fetchDate = useCallback(async () => { const response = await fetch("/api"); const data = await response.json(); setDate(data.date); }, []); useEffect(() => { fetchDate(); }, [fetchDate]); return ( <

１日中ずっと仕事でMacを使っているぼくがほんとに使っているアプリを順不同で12個あげていこうと思う。 Google、Microsoft、など定番アプリは除外している。 １．AltTab 現在使用しているアプリを一覧表示して選択できるアプリ。 たくさんアプリを開いていて使いたいアプリが埋もれてしまったときとか、２つのアプリを行き来したいときに便利。 Windowsだと標準の機能みたいだ。 「開いているウインドウがないアプリを隠す」という設定にして格段に使いやすくなった ２．Alfred Macのすべての起点となるアプリ。 アプリの起動、ファイルやフォルダ、ウェブサイト、Google Driveの検索、離席時のスクリーンセーバー起動、計算機などできることは数しれず。 ぼくがよく使うのは、 ・Dropbox内のフォルダ検索 ・Google Drive内のファイル検索 ・計算機（地味だが使いやす

SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。

2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro

さて、 今回はオフィスにて「ER図とは？」を学ぶランチを開催しました🍔 ゲームのDBなんて考えたことが無いので、ER図アウトプットに至るまでを記事に残してあげようと思います。 今回は、リリース時に同僚みんなで遊んでいたスマホゲーム「マリオカート ツアー」を使って マリカーのフレンドランキング画面を出すために必要なDB設計を考えます。 軽いランチなので、事前に参加者が通勤中の電車内で作成できるくらいのボリュームを目指しました。 データベースとは・・・？という初心者メンバーでもイメージしやすいように。 こういうアウトプットは初めてですが、徐々に慣れていきたいです。 【開催概要】 ・参加者：ファッションIT企業のPM、エンジニア、事務・・・などなど ・開催時間：1時間（事前アウトプット作成：20〜30分程度） ・その後：SQLを初心者と書いてみるランチも実施しました。 →BigQueryがSQ

UXについて色々と考えることがあり、少し言葉にまとめてみた。何が正しいという話ではないが、率直に感じていることである。 意図されたBad UX 車を運転する人なら経験したことがあると思うが、「近づかないと識別できない信号」というのがある。 この手の信号は、近付くまで青なのか赤なのか判別できない。そのため信号の近くになるまで、このまま進むべきか、ブレーキを踏むべきか、とドキドキさせられる。 先日までペーパードライバーだった私は、当初、スムーズな運転を妨げてストレスを感じさせるこの信号を、液晶の表示角度などの計算を誤った設置ミスだと思っていた。 しかしこれは、複雑な交差点などでの交通事故を防ぐために意図的に仕掛けられたもののようである。 いちドライバーとしては、けっして心地よい体験ではない。しかし、社会全体にとっては良い方向に向かうようデザインされた信号といえる。 このような「意図的にユーザー

Reactと状態は切っても切れない関係です。なぜなら、Reactは状態に基づいて画面を更新するコンポーネントベースのUIライブラリだからです🤝🏻 そんなReactの状態を管理・操作しやすくしてくれているのが、React 16.8から登場したフックです。それゆえ、フックを正しく利用するにあたってReactの状態の理解は非常に重要であり、Reactの状態の理解があやふやだと、予期せぬ挙動やバグのもとになりかねません。 今回の記事では、Reactの状態を理解しながら適切な箇所で適切なHooksを選択していくプロセスを再確認できた！自信を持ってReactをコントロールできるようになりそう！と言えることをゴールとしています🎉 今回使用した即席匿名メモアプリのコードベースです。 サークルでは、コミットに沿って説明をしていきました。（あくまで即席なので細かいこと気にしながら作ってませんorz） 【

最近の流れを見ていての感想文なので、ideaとして投稿します。筆者のバックグラウンドとしては、Remixの商業記事を書いたり、App Routerの商業記事を書いたりしている人です。 さて、筆者は2022年の秋から、社内システムではありますがRemixをプロダクション運用しています。また、Next.jsのApp Routerについても、パラダイムとしてはRemixにインスパイアされた部分が多い[1]おかげで、順調にキャッチアップできています。 RemixとApp Routerは、ルーティングとデータフェッチを高度に統合しており、Progressively Enhanced SPA（PESPA）と呼ばれることもあるそうです。PESPAについては、次の記事が話題になりましたね。 このPESPAであるRemixを実運用する中で、フレームワークの手触りが近年触ってきたものと大きく違っている点があっ

Niigata 5分 Tech #4と、モニクル社の社内LT大会で喋ったやつです https://niigata-5min-tech.connpass.com/event/307076/

前回は、「UIデザインってそもそも何なの？」という概論的な説明と、UIデザイン未導入の組織の中でみんなでデザインを始めてみるための施策（プロトタイピングとユーザビリティ評価）を話しました。 今回はサービス、プロダクト開発において、デザイナーではない人でも知っていて損はないUIデザインの重要ポイントについて説明します。主に以下の３つのテーマについて順番に議論をしていきます。 デバイスやソフトによるUIの違い ユーザーにかかる身体的・認知的負荷を理解する UIの重要概念（ナビゲーション、インタラクションなど）を知る 「ちょっと」と銘打っておきながらめちゃくちゃ長いnoteになってしまったので、気になる項目だけ読むか、何回かに分けて読んでいただくことをおすすめします、。 ※どこか内容に間違ってる部分やご意見ありましたらコメントいただけたら嬉しいです。 デバイスやソフトによるUIの違い皆さんがお使

はじめに Go言語用のEbitengineというゲームエンジンに興味があったので、試しにスイカゲームもどきを作りってみました。Ebitengineを使うと意外と簡単にスイカゲームもどきを作る事ができたので、なるべく分かりやすく作り方を紹介してみようと思います。 まずは先に完成品をお見せします。ちなみにフルーツの回転は面倒くさいので実装しないことにしました。 ちなみにEbitengineはwasmでも普通に動きます。ビルドしたものをこちらに置いたのでブラウザから実際に動かす事ができます。 それではスイカゲームもどきを作って行きましょう。 描画する まず一番初めにフルーツの画像を作るところから始めます。これはリンゴ、オレンジ、ブドウ、パイナップル、メロン、スイカのつもりです。 続いてフルーツを定義します

はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ（複雑で長い文字列、90日でパスワード変更など）が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン

2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー（引き継ぎ前のコードを書いた本人）の許可を得て使用しています。登場するコードは全て本物、登場するデータは講演用の架空のものです。

PHPカンファレンス北海道2024 https://fortee.jp/phpcon-hokkaido-2024/proposal/7d223fcd-ecc8-4cfb-92b2-4987749463d8 Lについての補足記事 https://asumikam.com/entry/2024/01/12/144338 Sについての補足記事 https://asumikam.com/entry/2024/01/13/152513

循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community