はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 導きのはじまり おぉ、貴方は…褪せ人ですね。 そして、エルデンリングを求め、この狭間の地にやってきた。 この先、プログラミング学習の攻略に繋がる貴重なアイテム が、7つあるぞ すごいなにかだと思うだろう？ 以下の記事を、ご照覧あれい！ 1. 強い敵はスルーして先に進む プログラミングを勉強していると、序盤にツリーガードのような強敵が現れることがありますが、 スルーして先に進むことが大事です。 序盤から強敵と戦うと、ボコボコにされて心が折れます #include <stdio.h>は、こういうもんだと「おまじない」としてスルーする。 va

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 先月、 【「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由】 という記事を公開し、多くの反響がありました。 上記の記事では 「じゃあ、MVVMをやめて、アーキテクチャは何を採用すればよいの？」 という問いに対する、明確な答えを出していませんでした。 あれから時が経ち、今ならば、この問いに対して、 ぼくは 「The Composable Architecture(TCA)をおすすめします」 と答えることができます。 以下は公式ページから抜粋したものを翻訳しました。 「The Composable Archite

宣言的UIの登場で、ViewModelは、存在理由を失っている つまり、 SwiftUIにViewModelのデータバインディング機能が内包された時点で、 ViewModelは存在理由を失い、「ViewModel」という言葉自体も、なんだか意味がよくわからない言葉 になってしまいました。 ViewModelという言葉は 非常に曖昧 で人によって定義が違い、そもそもViewModelレイヤーでやるべきことが何なのか明確化されてないので、とりあえず面倒事は全部押し付けられがちです。 本来、別のレイヤーですべきこともViewModelにつっこんでたりします。 MVVMを採用すると余計な複雑性を生んでしまう。 SwiftUIでMVVMを採用してしまうと「ViewModel」という余計なレイヤーを挟んでしまうため、冗長で複雑になります。 データフローについて、ViewとModelがViewModel

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事では、RiverpodとFlutter Hooksを使う、はじめの一歩として、 カウンターアプリを作ってみようと思います。 今回作成したコードはこちらのリポジトリに公開しています。 https://github.com/karamage/riverpod_flutterhooks_example Flutterの状態管理パターン みなさん、Flutterの状態管理パターンは、何を使っていますでしょうか？ Flutterの状態管理パターンはいっぱいあります。 大すぎですｗ StatefulWidget Redux BLo

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 私は、不完全な人間です。 人より劣っているところ、弱みもたくさんあります。 しかしながら、なんとか、今日までエンジニアとして生きていくことができました。 私がこれまで、劣等感とどう折り合いをつけてエンジニアとして生きてきたか、説明したいと思います。 この記事で最も言いたいことは**「不完全な自分を認めながら、でも、自分の成長の可能性を失わない」**ということを伝えたいです。 劣等感にまみれたエンジニア人生 ふりかえると、劣等感にまみれたエンジニア人生でした。 「自分はダメなエンジニアなんだ…」 という想いが、思考の隅につきまと

はじめに Composition APIで、**Providerパターン(provide/inject)**が、なぜ重要なのでしょうか。 Composition APIを使えば「状態やロジック」を簡単にコンポーネントの外に切り出すことができます。 しかしながら、Composition APIだけでは「ロジックや状態は切り出せても、複数コンポーネント間で共有できない」からです。 Composition APIによって、荷物をダンボールに梱包はできても、運ぶ人がいない状態です。 みなさんは、VueのProviderパターン(provide/inject)って使ったことありますか? https://jp.vuejs.org/v2/api/index.html#provide-inject 「ん、Provider？ なにそれ？」って感じですかね。 Providerパターンとは、**「荷物を運んで、

はじめに Vue3のリリースが迫ってきました。 順調に行けば、公式リリースは8月上旬のようです。楽しみですね。 Our current target dates are mid July for the RC (release candidate) and early August for the official release of 3.0. https://github.com/vuejs/rfcs/issues/183 Vue3の目玉の機能として、**「Composition API」**があります。 この記事では、**「”なぜ” “なんのために” Composition APIを使うのか」**理由について、まとめています。 「Composition APIの使い方」についての説明は、この記事では割愛します。 以下の記事に、具体的なComposition APIの使い方とProvi

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 この記事は、Ginza.js#2にて登壇した、 「Jestを使って VueコンポーネントとVuexストアのテストコードを書いてみよう!」 のLTのスライド内容を元に記事を作成しました。 ソースコードは以下で公開しています。 https://github.com/karamage/vue_jest_test 動作環境 ・Mac OS 10.14.4 ・Nuxt v2.8.1 ・Vue v2.6.10 ・Node v10.15.3 以下の記事にTipsをまとめました。合わせてご確認ください。 Vue Test Utils と Jest でコンポーネントのユニットテストを書く際のTips https://qiita.com/karamage/items/6c2163f78557a69208a8 この記事で説明すること Jestとは? Jestのインストール Jestの基本的なテストの書き方