はてなブックマーク

はじめに 設計と開発プロセスの関係性 システムの構造とタスク構成 設計の影響（生産性、外部品質） ソフトウェア設計の知識と技能 経験則　（経験による暗黙知 ⇒言語化：原則、パターン、体験談） 習熟　（手を動かして内面化された経験則） 共創　（知識と技能の連結） ① ソフトウェア設計の基礎知識 a. 基本課題 複雑さと発展性 大きな泥団子 巨大な一枚岩（モノリス） b. 解決のアプローチ 関心の分離→部品化→モジュール化 交換容易性（モジュラー性） c. モジュール化：基本となる４つの技法 モデル 直接的な写像 カプセル化 仕様 ② モジュール化 a. モジュールの分類 機能(Function)と型(Type) インバウンド、アウトバウンド、演算 可変と不変 ブレークダウンとビルドアップ b. オブジェクト指向プログラミングのモジュール化 抽象データ型 型の連結 型の分類（subtyping

私はこの数ヶ月、趣味プロジェクトとして1980年代に栄華を誇った名作CPUである"Z80"のハードウェアエミュレータを開発しています。 これはZ80で動作しているコンピュータからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。 このトークではZ80ハードウェアエミュレータの解説を軸に、CPUの作り方や、その楽しさをお伝えします。 主なトピック: ・Z80ハードウェアエミュレータの構成 ・CPUを作るために必要なもの ・ソフトウェアエミュレータとハードウェアエミュレータの違い ・Raspberry PiでCPUを作る方法 ・Z80ハードウェアエミュレータの課題とその解決方法 CPUを作ってみたい方はもちろん、コンピュータの仕組みを理解したい方や、プログラムが実行された

CQRS/Event Sourcingは、非機能要件の側面で注目されがちですが、本来はDDDのための設計パターンの一つです。 今回は言語非依存に実装する方法を共有しつつ、一緒に手を動かして理解できるようするハンズオン用セッションです。 想定条件 コードを書きたい人はPCをご持参ください 事前にソースコードとセットアップ手順を共有します。あかじめセットアップし動作確認可能な状態でご参加ください。 対象言語でFizzBuzz以上のプログラムが書ける開発者向け ※難しいコードは書きません。手本のコードは共有します。 参加者はプログラミング言語としてGoもしくはRustの好きな方を選択できます ※このセッションを受けると他の言語でも実装できるようになります 想定データベースとしてはコマンド側がDynamoDB、クエリ側はMySQL(RDS) 実装ではREST API,GraphQLを使うのでその経

オブジェクト指向は大切、オブジェクト指向は難しいなどと言われますが、ではオブジェクト指向とはなんでしょうか？実際のところ、広く合意のあるような定義は見当たりません。 ただ、ここではこれからの開発作業をよりよいものにするための話をするべきなので「オブジェクト指向がきっかけだったのだから全部オブジェクト指向だ！」のような過去の栄光のような話をしてもあまり意味はありません。 そこでこのセッションでは、関数型など他のアプローチでも可能なことをオブジェクト指向から分離させていき、そうするとオブジェクト指向として何が残るのか、またそのような中で、今までばくぜんとオブジェクト指向として話されたことをどのように整理して扱うといいのかをお話しします。 内容はWEB+DB PRESS vol.132 「オブジェクト指向神話からの脱却」を発展させたものになる予定です。 https://gihyo.jp/maga

「エディタを好きになることなんて私分からなくてさ」 嘘か本当か知り得ない そんな言葉にまた一人堕ちる また好きにさせる 誰もが目を奪われてく 君は 完璧で究極の エディター！！！！！ 「Neovim」とは、Vimから派生したテキストエディタです。 素晴らしいエディタですが、SwiftをNeovimで書いている人は世界的にも非常に少ないです。 私はNeovimが好き過ぎて、SwiftをNeovimで書くことに挑戦しています。 そこで見えてきたXcodeとの違いを紹介しつつ、Neovimの魅力を思う存分に語ります。 【話すこと】 ・Neovimの概要と魅力 ・Xcodeとの比較 ・私のNeovim環境紹介とライブコーディング（ここがメイン） Neovimは私にとってのアイドルです。 この気持ちは絶対嘘じゃない！

Javaの入門書を終わって、文法を覚えたしJSPやサーブレットもやってみた、でもプログラムが作れるようになった気がしないという人は多いのではないかと思います。 このセッションでは、プログラムが作れるようになるためにどういう勉強をすればいいかを、どうやって動くプログラムを書くか、どんなプログラムを作るか、どうやってプログラムを作るか、作ったプログラムをどう動かすか、といった内容で解説します。

今年11月にリリースされる予定のPHPの最新バージョン8.2における機能強化・変更点を中心にPHPの開発に関する最新の情報，PHPコミュニティに関する話題について紹介します．PHPの最新動向に興味がある方向けに，初心者の方にもわかりやすい解説にしたいと思います．

SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。

trait は当初 2008 年に PHP の言語開発者コミュニティへ提案され、長い議論期間を経て 2012 年リリースの PHP 5.4 で導入された機能です。 それから 10 年がたち、trait は「ちょっと試しに使ってみよう」というものから、各開発現場において使われる中で少しずつその立場を変えてきました。 さて、実際どのように変わったのでしょうか？ 先日、今年に出る PHP 8.2 へ向けて言語機能追加の RFC を提出しました。PHP の trait で定数を定義できるようにするというものです。 静かな議論期間を経ての RFC の投票開始後、PHP の開発者向けメーリングリストから最初に得られたのは驚くべきリアクションで、要約すると次のようになります。 「trait は言語にとってまったく不要なものであり、使われるべきでないものを改善すべきではない」 続々と RFC に No の

サイボウズのGaroon（ガルーン）は今年で20周年を迎えるグループウェアです。 このセッションでは、20年にわたって開発が続いている巨大なレガシープロダクトのPHPバージョンを7.4から8.0にアップデートした際に得られた知見についてお話しします。 Garoonはさまざまな組織を支えるグループウェアであり、お客様の業務にまつわるデータをお預かりする性質上、セキュリティの確保が重要な課題です。 そのため毎年欠かさずにPHPのメジャー／マイナーアップデートを行い、常に最新のセキュリティ更新を取り込める状態を保っています。 しかしGaroonはPHP4系の時代から脈々と開発が続いているため、コードベースは巨大でありレガシーなコードが多分に含まれています。 さらにPHP本体にパッチを当てて自前でビルドしていることもあり、PHPのバージョンに対する依存度も高いです。 今年はPHP7.4からPHP8

タウンワークiOSアプリは、10年以上開発が続いています。度重なる機能追加や仕様変更によって、プロダクトは徐々に複雑に、レガシーになっていきました。そのため、Clean Architectureの導入によるレガシーからの脱却を図りました。 Clean Architectureに則りドメイン層を分離してみましたが、いくつか不明な点があり、技術顧問の和田卓人氏に相談したところ、そもそも我々のモデリングにたくさんの改善点があることがわかりました。 そこから、チームの中で既存コードからドメインモデルを発掘し、再設計する旅が始まりました。 このセッションでは、ドメイン層が何をするかよくわからない、設計に困っている人に向けて、アプリにとってのドメインとは何か、どのように見つけ出し設計すればよいか、そして評価の方法について私たちの経験を交えてお話します。

STUDIO社のVue2のプロダクトを開発を止めずにVue3に移行した話をします。 どのようにやっていったか なぜやるか Vue CLI → Vite Vue2 → Vue3 OptionsAPI → CompositionAPI（script setup） Vue3非対応ライブラリの対応 移行コスト Breaking Changes振り返り どこがしんどいか 完走した感想 やったほうがいいか、やらないほうがいいか

ORM が高性能になり、SQL (クエリ) を意識の外に置くことも増えてきました おかげでより開発効率も向上し、スピーディ・高品質なコードが書ける率も上がっています しかし…アラートは突然やってきます 落ちるページ表示速度、上がる DB サーバー の Load Average そして大量のスロークエリ もちろん原因はこれだけではありませんが、僕らの日常では、1つのスロークエリが DB サーバーを停止させることも少なくありません SQL は書き方次第で簡単に障害に繋がります また、障害発生時、プログラムがどんな SQL を実行しているのか 実装した SQL は速いのか、遅いのか それがわからないと、障害解析で困る場面も多いです 障害などの緊急事態を回避する以前に、品質の観点でエンジニアには日常的に以下が求められると考えています。 スローログ監視 スロークエリ解消 スロークエリ予防 本セッショ

Eigen は高速な行列計算を行うための C++ ライブラリで、ヘッダのみで構成される純粋なテンプレートライブラリです。 現時点では Swift は C++ と直接連携できないので、Swift から Eigen を使うには C または Obj-C でブリッジする必要がありますが、 Linux でも使えるようにするには Obj-C は選択肢から外れます。 また Eigen はテンプレートライブラリなので、「Swift 側の Wrapper 型も係数に関して generic にしたい」（× EigenIntMatrix, EigenDoubleMatrix, … / ○ EigenMatrix<Int>, EigenMatrix<Double>, …）という欲求も生まれます。 この LT では、両立が難しそうな二つの課題： Eigen を Swift から C を経由して使うこと Wrappe

シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 Discord Channel: #track1-8-spa-security

エンジニアに「状態管理うまくいってますか」という言葉を投げつけるのは、心に深い傷を刻む結果になると一般に知られています。 宣言的UIの流行により、GUIアプリケーションにおける支配者は状態（データ）となり、表示コンポーネントは状態の落とす影に過ぎない存在となりました。これにより「開発者は状態管理だけをうまくやればいい」という仕組みが出来上がるのですが、我々は次の現実に直面することになります。そもそも状態管理をうまくできない、と。 私がウェブ技術を17年間触れてきた中で、状態管理というのは最も難しい技術に分類されると感じています。そしてウェブ技術をベースにしているReact Nativeではその問題が直撃します。 密結合にすると変更に対して硬直化する、疎結合にすると流れが把握できなくなる、綺麗にするために状態管理ライブラリを入れたのに逆に散らかってきた、公式サイトに書いてある方法でやっても改

Presentation Type [Choose either from Standard / BeginnerSpeaker / StepUp]: Standard Level [Choose either from Beginner / Intermediate / Advanced]: Advanced Categories [Choose either from Java SE / Jakarta EE / Server-side / Cloud / JVM / DevOps / Tools / Others]: Java SE カンファレンス終了後にJJUG YouTubeチャンネルでセッション動画の公開を希望する / Agree to publish your session to JJUG YouTube channel after conference [Yes or N

もしもこんなことを言われたら「何言ってんだ、できねぇよ」と言うと思います。 しかしながら双方似ている部分があり、とっつきやすいのも事実です。iOSエンジニアの皆さん、Androidアプリも作ってみたくありませんか？ このトークでは、私がiOSエンジニアからAndroidエンジニアに転身した経験を活かし、iOSエンジニアにとってわかりやすい形でAndroidアプリ開発について説明してみたいと思います。もちろん40分ですべて熟知してもらうのは難しいです。なので、Androidアプリを作る上で要になる部分の解説や、躓いたときに自力で原因を探るためのデバッグ手法の説明に重点を置き、自走できる状態へ導きたいと思います。 目次 ・Swiftと比較しつつKotlinを学ぼう ・基礎の基礎、Activity、Fragmentを理解しよう ・ConstraintLayoutでUIが組めるようになろう ・よく

1990年代以降オブジェクト指向プログラミングの普及により、クラス設計、インターフェース設計、GoFのデザインパターンなどが提唱され、近年ではMVC系、DDD、Clean Architectureなどのアーキテクチャの議論が盛んに行われています。 これらももちろん大切ですが言語やアーキテクチャに依存せず、多くのプログラマが必ず検討をする設計として「関数分割」が存在しています。 関数分割の基準については、上記のデザインパターンやアーキテクチャでは議論されていません。 関数の実装は世のプログラマの全員が毎日行うことであり、欠かせない設計であると言っても過言ではありません。 しかし「テスタビリティが高い関数にする」のような基準に留まり、明確に言語化されていることが少ないです。 そこで本セッションではこの関数分割の良し悪しを測る指標として提唱されている凝集度と結合度を紹介します。 これらは構造化プ

昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。

企業におけるデバイス管理手法の一つに、MDMを用いる方法があります。 しかし、有料のMDMソリューションサービスを個人で触るハードルは高く、MDMを試すことができてない人も多いのではないでしょうか。 このトークでは、オープンソースMDMのmicromdmを用いたMDMサービスの立ち上げ方やMDMCertを用いたMDM Push証明書の取得法、API経由でのMDMコマンドの発布について紹介していきます。

PHPといえばレンタルサーバー、そういう時代がありました。いや今もあります。 数多くのサイトを提供しているレンタルサーバーは、PHPerKaigiのようなカンファレンスにいらっしゃる「エンジニア」な人たちには少々嫌われているような気がします。おっしゃることはわかります、私も人に手放しで勧めたりはしません。 しかし、私はレンタルサーバーが好きです。 長らくCMS実行環境としてしか見られていないレンタルサーバーですが、時代が進むにつれ、あれ？これっていいんじゃないの？もしかしてワンチャンあるのでは？という魅力も増えていると私は考えています。 いま一度私とレンタルサーバーを見つめてみましょう。 話す事 ・PHPer目線で見る、レンタルサーバーの強みと弱点 ・レンタルサーバーをPHPerとして活用するテク ・モダン（？）なデプロイと開発、運用 ・VPSからレンサバにアプリを移管する話 話さないこと

2019年1月からエンジニア系YouTuberを始めました。すると、今まで見えなかった初心者エンジニア界隈や、プログラミングスクール、その生徒たち、対立するエンジニア系インフルエンサーなどが見えてきました。本トークでは私から見るエンジニア界隈の闇をできるだけポップにお話します。

サーバサイドエンジニアは多いけどiOS/Androidなどのネイティブアプリエンジニアは少ない、という会社さんは結構多いのではないでしょうか？ 私はこれまで、何の因果か社内やプロジェクトの中でiOSアプリ担当が自分だけ（他のエンジニアはみんなサーバサイド担当）という「ぼっち」環境で数年くらい過ごしてきました。 また、現在仙台に住んでいるということもあり、東京のように頻繁に勉強会が開催されているわけではないため、あんまりiOSエンジニアのお友達が多くなく、情報共有やキャッチアップする機会も少ないという状況です。 このトークでは、そんなぼっちiOSエンジニアが新たなアプリを開発してリリースするためにやってきた以下のような取り組みや、その過程で起きた出来事を余すところなくお伝えし、最終的にはこのiOSDCで少しでも多くのiOSエンジニアのお友達を作りたいと思っています。 ぼっちだからこそ、自動化