関西Javaエンジニアの会(関ジャバ) '17 10月度 - connpass https://kanjava.connpass.com/event/68169/ での発表資料です。
![DDD失敗談を話して学んだこと](https://cdn-ak-scissors.b.st-hatena.com/image/square/286f1f3c151c2e1082f44ae79e12ba30934fe5ac/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4c6e6dadbdf24f65bc6b75b0aa5a8cd8%2Fslide_0.jpg%3F8803400)
きっかけ 尊敬するエンジニアの一人 @nobuoka さんのつぶやきがきっかけ。 いつも思ってるんだけど、サーバーサイドとモバイルアプリの両方に同じバウンダリーコンテキストのドメイン層があったらドメイン知識が分散してることにならない?? (サーバー側にドメイン層があるならモバイル側にドメイン層は不要では論者)— Nobuoka Yu (@nobuoka) 2017年10月14日 常々自分も同様のことを考えていて、基本的には賛成。 しかし実際の開発においては 「(複雑な場合 は持たないとつらいなぁ)」 という実感があり、話してみるとnobuoka先生も同様の実感をもっているもよう。 今回はその 複雑な場合 とは実際どんな場合なのかを考えてまとめてた。 注意 この手の議論は燃えやすいので、しっかり前置きしておきます。 ここに書いてある考えが絶対的に正解とは自分自身考えてないです。こう言う風に考
7 คาสิโนออนไลน์ ชั้นนำที่ดีเยี่ยมที่สุด Ichimaruni-design คาสิโนออนไลน์ ขอชี้แนะ 6 เว็บเดิมพันออนไลน์ชั้นหนึ่ง ที่มีครบทุกสิ่งที่มีความต้องการ ไม่ว่าจะเป็น คาสิโนออนไลน์ บาคาร่าออนไลน์ ไพ่โป๊กเกอร์ออนไลน์ พร้อมรับโปรโปรชันเครดิตฟรีที่แจกให้แบบจุใจ เว็บไซต์ตรงไม่ผ่าเอเย่นต์ เล่นง่าย ได้เครดิตฟรี ๆ ไปเลย UFABET เครดิตฟรี ไม่รับมิได้แล้ว กับโปรเด็ด โบนัสปัง UFABET เครดิตฟรี สิ่งดีๆที่เรามีให้เฉพาะสมา
ゲームジャム(Game Jam)にはさまざまな形があるが,その多くは24〜48時間という短時間でゲームをゼロから完成させることを目指す。だがその一方で,1か月という余裕のあるスケジュールでゲームの完成を目指すゲームジャムも存在する――ただしコードが合計で13KBを超えてはならないという,別の縛りがそこにある。はたして,この特殊なゲームジャムによって,参加者はどのような知見が得られるのだろうか? Game Industry Conferenceでの講演の模様をお届けしたい。 短時間(24〜48時間)でゲームを作る「ゲームジャム」というイベントは,全世界で一斉に開催するグローバルゲームジャムを筆頭に,さまざまな団体(あるいは企業内)で行われている。 そして,これまで多くの場合,「ゲームジャムがもたらすメリット」について語られてきたが,その一方で「ゲームジャムが持つ問題点」も,少しずつ開発者の間
テスト駆動開発の考案者 Kent Beck が記した原典『Test-Driven Development by Example』を新たに訳し直し、新訳版『テスト駆動開発』としてオーム社から復刊しました。ただ訳し直すだけではなく、初めての方にも旧訳版をお持ちの方にも読んでいただけるための工夫を凝らしました。 テスト駆動開発 作者:Kent Beckオーム社Amazon 電子書籍版は Kindle 版は Amazon Kindle ストア、 PDF 版と EPUB 版は 達人出版会 から発売されています。 テスト駆動開発 作者:KentBeckオーム社Amazon テスト駆動開発【電子書籍】Kent Beck(著), 和田卓人(訳) オーム社 発行日: 2017-10-20 対応フォーマット: PDF, EPUB 詳細を見る 『Test-Driven Development by Exampl
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と
@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない?って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか?」という話をします。 結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。 まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。 その上でReduxの特殊性は Stateがピュアなオブジェクトで表されている Stateの更新はイベントを契機に常に同期的に行われる 以上2点により いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
Original: Making sense of atomic design: molecules and organisms by Alla Kholmatova 本記事は、原著者の許諾のもとに翻訳・掲載しています。 frasco.io 👆こちらに移転しました。 我々のインタラクションデザイナーである Alla Kholmatova が FutureLearn での Atomic Design の利用の状況について考察します。 1年前、私たちは FutureLearn での最初のパターンライブラリ開発について、そしてなぜ我々が Atomic Design を使うことになったのかについて著しました。 全般的に、Atomic Design は我々のチーム内でうまく機能しています。それはインターフェイスの理解の共有や、さらなるモジュール化への移行、我々のデザイン言語の進化などに貢献しました
id:smoking186 さんの指摘を受け, First Authorの名前などを付加しました. どうもです. 記事内のcodeは最適化などを施しておらず, 冗長に, 定義どおりに書いています. ifがまとめられたりとかしますが, そのあたりはご容赦を... Rubyでlevenshtein距離を見て以来, 個人的にdiffブームが来ていた. 計算量O(ND) / O(NP)のalgorithmなどがあるのは知っていたが, 論文(英語)および, 解説のみ, またはソースコードのみなど分かれているものが多く, algorithmに疎い自分には理解するのに大変時間がかかってしまった. しかしやっとわかったので, 解説+JS実装してみる. 解説とソースコードがセットだと, 多少はわかりやすくなるかと... 自分は正直これくらい細かく言われないとすぐにはわかんない人なので(the O(ND)だけ
こんばんは. 気がつけばもうずいぶんと涼しくなってきました. 勢い余って凍ってしまったりせぬよう, くれぐれも普段の言動にはお気をつけください. はじめに さて, 我々人類にはどうしても二つの文字列 (あるいは行ごとに区切られたテキスト) 間の差分を求めなければいけない瞬間が発生します. 先人たちはそういった時のために diff のようなツールを開発し, それを利用することで文明はめざましい発展を遂げてきました. しかしながら, 使用するアルゴリズムを比較検討したい場合, 「差分」の定義を変えるなどして既存のアルゴリズムに変更を加えたい場合, diff のない異世界に飛ばされて自分で実装しなければいけない時などにおいては, 差分検出アルゴリズムについての理解が必要不可欠です. というわけで, この記事では文字列間の差分検出とは何かということと, 差分を求める三種類のアルゴリズムの紹介・解説
さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー
2017年10月6日『まぼろしのJS勉強会 #1 「ナウいJSの書き方・考え方」』にて発表した資料です。 https://maboroshi.connpass.com/event/66502/ #mbrs_js_study
ここ半年開発していた動画サービスをベータ版ながらリリースしました(正式リリースは 4 月)。そのサービスの開発において、以前投稿した Atomic Design を採用しました。本記事では Atomic Design を実案件に導入した結果と感想を書いていきます。 Atomic Design の基本的な概念に関して知りたい方は Brad Frost 氏の原文、もしくは私の以前の記事↓を参照できます。 最近よくクリエイターが移住するカナダで Atomic Design を学ぶ Atomic Design を導入して正解 結論から書くと、今回 Atomic Design を導入したことは正解でした。コンポーネントの粒度を論理的に説明できるガイドラインとして十分すぎるほどの役割を果たしてくれました。 このガイドラインがあることで、デザインに関してさほど関心がない人(たとえばデザインよりもエンジニ
西田雅博 株式会社ビズリーチ HRMOS事業部 エンジニア 最近はフロントエンドメイン、サーバーサイドもやってました Angular4, Play Framework (Scala), React 雑? この勉強会の後半で必要になる RxJSの前提知識だけカバーします もくじ RxJSってなに Observable Subject BehaviorSubject RxJSってなに 非同期やイベントのコールバックをmap/filter/reduceなどのコレクションのAPIぽく扱えるライブラリ Rx.Observable.fromEvent(window, 'click') .distinctUntilChanged( (prev, next) => prev.pageX === next.pageX ) .filter(ev => ev.pageX < 400 && ev.pageY <
noteのコア体験は、「読む楽しさ」と「書く楽しさ」だと考えています。 本来ならコア体験は、調査でしっかりと導くべきものです。しかしアカデミックなUXとは異なり、実際のスタートアップ環境では時間とリソースに限界があります。このため調べながらも、走り出さなければなりません。 まず序盤はヒューリスティック(経験)ベースのデザインを行いつつ、調査やテストが可能なところから、裏づけやチューニングを行う流れになりそうです。 以下、「読書体験」における「可読性」のパートのメモ。noteチームにとりあえず提案する予定の諸々です(現時点では個人の見解です)。基本的には「当たり前のことを、当たり前に」やる予定。「これもやっとけ」的なことがあれば、タイポグラファーの諸先輩の方々には、ぜひご意見をお伺いできればと。 書体をサンセリフ系に変えるべきか?デジタルでは、一般的にサンセリフ体の可読性は、ローマン体よりも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く