●発表のアーカイブ動画はこちら:https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座:https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「…
こんにちは、@nerusanです。 皆さんは、状態管理ツールなどは使っておられますでしょうか。 例えば、有名なところでは、Redux, Recoilなどがあります。 今回は、Reactにおける状態管理についての動向を知ることで、なぜ、Reduxが使われるようになったのか?何をReduxなどのグローバルな状態管理ライブラリで扱えばいいのか?現状どうなっているのか?を調べたので、記事にしたいと思います! 自身の解釈なので、もしかしたら、誤ったことを言っている可能性もあるので、その際はご指摘いただければと思います m(- -)m SPAの流行り SPAとはSingle Page Applicationの略であり、新しいページに移動する際、サーバからページを再読み込みするのではなく、JavaScriptを使って、クライアント側のブラウザで動的にページを書き換えるアプリケーションを指します。ページご
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
ポエム。 つまり?予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
更新履歴 2020/03/23 IoT について追記 その他に帝国兵さんのツイートを追加 サーバーレスカテゴリーを追加して AWS Lambda を追加 ASP.NET Core Razor Pages を追記 2020/03/24 kennakamu さんの「個人的に C# が向かないと思うこと」へのリンク追加 本文 昔ブログにこんな記事を書きました。 C# で何か出来るのか?まとめてみた あれから 2 年が経って昔からある Windows 専用の .NET Framework に対する新機能の提供が終わり、クロスプラットフォームに対応した .NET Core が今後のメインストリームとして .NET 5 → .NET 6 のように進化していくことが 2019 年 5 月の Build 2019 で発表されました。以下の Blog 記事がアナウンス後に発表されています。 Introduc
こんにちは、delyコマース事業部エンジニアの小川です。 先月11月に入社し、エキサイティングな毎日を過ごしています。 この記事はdely Advent Calendar 2019 - Qiitaの24日目の記事です。 昨日はSREの松嶋さんが「AWS RunCommandを使ってEC2上に監視ダッシュボードをサクッと作る(Ansible+Terraform+Grafana編)」という記事を書いてくれましたので是非そちらも読んでみてください! tech.dely.jp コマース事業部では、現在「事業開発」と「ソフトウェア開発」がほぼ同時に進行しており、プロジェクトにおける確定要素と不確定要素が複雑に絡み合っています。 スピード重視でゴリゴリ実装していくのも興奮しますが、変化に耐えづらい実装をしてしまうと、その後の開発スピードに影響していまい、事業のスピードが落ちるなんて事にもなりかねません
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か?何が正しくて何が間違っているか?も重要なのだが、それよりは、なぜそれが生まれたのか?何を解決しようとしたのか?どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか?を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
Introduction Developers have a number of choices today when it comes to selecting a JavaScript framework or UI library for building scalable web apps. React / Next.js, Vue / Nuxt, Angular…the list of solutions continues to grow, but just how do you decide on which to use in a sea of so many options? To help you understand the options, we created TodoMVC - a project which has offered the same Todo
MVCとは UIを持つアプリケーションソフトウェアを実装するためのデザインパターンである。 MVCではプログラムをModel、View、Controllerの3つに分割して書くことで機能の独立化・可読性の向上を図ることができる。 MVCを調べるとこんな感じの説明がでてきたと思います。 でも最初はピンとこないかもしれません。「デザインパターン?」「機能をなんで独立させなくちゃいけないの?」「結局なんのためにMVCにするの?」 今回は10サイトくらい見ても結局わからなかった人のためになるべく難しい言葉を使わずに、図解してわかりやすくMVCについて説明していきます。 日常生活に即して例をみていきましょう 一旦プログラムから離れて、わかりやすいところからMVCについて解明していくことにします。 おじさんのレストラン 子供のころから自分の店を開くことを夢見ていたおじさんが、ついにレストランを開業しま
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か? MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
Vue.js は普通の Web ページにもゆるふわに導入しやすい点がメリットの一つですが、(SPA ではない) Rails アプリで使う時は少し考えて書かないとつらくなってくると思います。 例えば、ある <select> 要素の値に応じて別の <select> 要素で選択可能な値をフィルタリングするという機能を実装したい場合を考えます。フィルタリングの機能を持たない、ただのフォームであれば Rails のフォームヘルパーで簡潔に書くことができます。 <% # コントローラーから渡す %> <% @categories = [['Category 1', 1], ['Category 2', 2], ['Category 3', 3]] %> <% @items = [['Item 1', 1], ['Item 2', 2], ['Item 3', 3]] %> <%= form_with(
Talk presented at PHP UK Conference 2017 in London, England.
フロントエンドとJavaScript JavaScriptのMV*向けライブラリ BACKBONE.JSによるWebアプリケーション開発について 「オープンソースカンファレンス 2013 福岡」の HTML5と最近のフロントエンド事情で発表した資料です。 Read less
初心者と中級者、上級者の違いとは何でしょうか? 初心者は、 知識が少ない 開発したソフトウェアの数が少ない 中級者・上級者はその逆で、 知識が多い 開発したソフトウェアの数が多い その結果生まれる実質的な差は、 「初心者はかんたんなものしか作れないけど、中級者・上級者は難しいものを作れる!」 ということです。ですから、初心者が中上級者になるには難しいソフトウェアを作るのに役立つ知識を身につければ良いわけです! 難しいソフトウェアとは、 ロジックが複雑で難しい 規模が大きい 性能要件が厳しい 納期が短い など、いろいろな難しさがあります。 これらのハードルに対抗する知識・技術について紹介します。 規模が大きいソフトウェアを作るための技術 規模が大きいソフトウェアを作るための技術には、以下のようなものがあります。 モジュール分割 アプリケーションアーキテクチャ フレームワーク プログラミング作
エンタープライズで使える!実践から学ぶJavaScript MVCフレームワークの選び方 酒巻瑞穂(html5jエンタープライズ部) 現在エンタープライズシステムの開発現場では、シングルページアプリケーション(SPA: 単一のWebページで構成されているWebアプリケーションのこと)アーキテクチャの採用が模索されるなど、根本的な開発パラダイムにおいて大きな変化が起きようとしています(全体的にどのような変化があるかはエキスパートNo59の佐川夫美雄さんの書かれた「JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例」によくまとまっています)。 こうした変化の一部を支えているのが、JavaScriptによるMVCフレームワークです。数あるフレームワークの中で、実際にどのフレームワークを採用するかというのは、開発コストだけではなく学習・運用コストにも関わる、非常に大きな
はじめに ひと月程前に、ViewControllerを肥大化させないためのMVC構成案を書いたのですが、その後もアプリ開発の勉強をひそかに続けておりまして、その過程で単純なMVC構成のアプリを作りました。 (入力→確認→登録実行のWEBではよくあるフローの事です) アプリ自体はダミーのため、全く存在価値がないのですが、せっかく作ったので記念に公開します。 (需要があるのかは分からないですが) (ちなみに、前回の記事はソースコードでのUI実装を前提に書いたのですが、今回はStoryboardを使用しました。あと、 DataSourceは今回分けてないです) サンプル置き場 以下のライブラリを使用しますので、 CocoaPods にてインストールしてください。 (動かさないのであれば特に不要です。というかダミーなのであまり動かす意味がない)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く