知らないと損するアプリ開発におけるStateMachineの活用法（full版）.NET Conf Tokyo 2019 にて登壇。 https://vsuc.connpass.com/event/146588/ C# 8.0 の新機能のうち、非同期ストリームと呼ばれるもの(await foreach, await と yield の混在)について説明します。 また、非同期ストリームの内部的な仕組みの説明と合わせて、ValueTask や IValueTaskSource など、Task がらみのパフォーマンス改善の歴史を振り返ります。
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
Unityデザインパターン記事「Journeyballs engine: Unity design patterns」のメモ - Qiita
Journeyballsの開発者が書いたUnityデザインパターンのチュートリアル記事。 URL: http://www.holoville.com/blog/?p=166 マネージャ GameManager: 中心となるマネージャ。Unityエディターを通して、ゲーム設定を行ったり、SaveManagerを通して各ユーザのデータを取得する AspectManager: スクリーンの解像度などに対応するためのもの。 Notificator: イベントの通知はすべてここに送るようにし、ここで処理をする。シングルトン。 LevelManager: 新しいレベルのシーンが読み込まれるたびに、このマネージャがレベルを検知し、設定する。 SaveManager: セーブとロードを担当する。 ScoreManager: スコアと、各レベルでのスターを保持する。 SoundManager: すべてのサウ
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
デザインパターンの骸骨たち
『デザインパターン』 うんちくできると、かっこよさそうだよね～。でもあんな分厚い本読んでもピンとこないし、だいたいオブジェクト指向ってなに？なにが便利なのかよく分からんのだけど。いいじゃんなんでも。できればいいんだよ、できれば。 な～んて、思っていても、なんとなく オブジェクト指向が気になっている システム開発者は、多いのではないでしょうか？かくいう 私もそんな者の一人でした。 しかし、これだけ もてはやされているオブジェクト指向です。 なんか、便利なはずです。 そこで、私は、ＧＯＦのデザインパターン[1]を、できるだけシンプルに表現した、小さな小さなプログラム ～デザインパターンの骸骨たち～ を作ってみました。骸骨達 を骨の髄までしゃぶり尽くつくすせば、オブジェクト指向の真髄まで味わうことができるかも。！？ 『デザインパターンの骸骨たち（RE-BONE）』 では、内容を大幅に見直し、Ja
アブストラクトファクトリ(Abstract Factory) | Ruby デザインパターン
アブストラクトファクトリは、矛盾のないオブジェクトの生成を行うためのパターンです。 このアブストラクトファクトリをRubyコードで紹介します。 😀 ソースコードを使ったAbstract Factoryの説明Abstract Factoryをソースコードを使って説明します。 ここでは次のような池をサンプルとして取り上げます。 動物を表すクラス： アヒルを表すDuckクラスは、食事(eat)メソッドを持っている カエルを表すFrogクラスは、食事(eat)メソッドを持っている 植物を表すクラス： 藻を表すAlgaeクラスは、成長(grow)メソッドを持っている スイレンを表すWaterLilyクラスは、成長(grow)メソッドを持っている 池の生態系を生成するクラス： コンストラクタで動物と植物を定義する 動物、植物のオブジェクトを返すメソッドを持っている 池の環境(動物と植物の組み合わせ)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
