問題タブ [state]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
opengl - Cg での OpenGL 状態変数へのアクセス
Cg シェーダー プログラムでOpenGL 状態変数(MVP マトリックスなど)にアクセスする必要があります。cgGLSetStateMatrixParameter()
これらの値は、C/C++ コードなどの呼び出しを使用して手動で Cg シェーダー プログラムに渡しています。これを行う簡単な方法はありますか?
algorithm - ステートマシンはどのような問題に適していますか?
ステートマシンが最も適しているプログラミングの問題は何ですか?
ステート マシンを使用して実装されているパーサーについて読んだことがありますが、ステート マシンとして実装することを叫んでいる問題について知りたいと思います。
testing - どうすればグローバル状態を回避できますか?
それで、私はグーグルのテストブログを読んでいました、そしてそれはグローバルな状態が悪くてテストを書くのを難しくしていると言います。私はそれを信じています-私のコードは今テストするのが難しいです。では、どうすればグローバル状態を回避できますか?
私がグローバルステートを使用する最大の目的は(私が理解しているように)、開発、受け入れ、および本番環境の間で重要な情報を管理することです。たとえば、「DBConnectionString」という静的メンバーを持つ「Globals」という名前の静的クラスがあります。アプリケーションがロードされると、ロードする接続文字列を決定し、Globals.DBConnectionStringにデータを入力します。ファイルパス、サーバー名、およびその他の情報をGlobalsクラスにロードします。
私の関数のいくつかはグローバル変数に依存しています。したがって、関数をテストするときは、最初に特定のグローバルを設定することを忘れないでください。そうしないと、テストが失敗します。これは避けたいです。
状態情報を管理する良い方法はありますか?(または、グローバル状態を誤って理解していますか?)
state - 状態を維持する方法の比較
Web 開発で使用するユーザー状態を維持するには、さまざまな方法があります。
これらは私が今考えることができるものです:
クエリ文字列
クッキー
フォーム メソッド (Get および Post)
Viewstate (私が推測する ASP.NET のみ)
セッション (InProc Web サーバー)
セッション(専用Webサーバー)
セッション (データベース)
Local Persistence (Google Gears) (thanks Steve Moyer) など
Cookie は安全ではなく、QueryString には長さの制限があり、見栄えが悪いなど、各方法には独自の長所と短所があることを私は知っています。;)
しかし、Web アプリケーションを設計するとき、どのアプリケーションにどのメソッドを使用するか、またはどのメソッドを避けるべきかについて、私はいつも混乱します。
私が知りたいのは、あなたが一般的にどの方法を使用して推奨するか、またはより興味深いことに、特定のシナリオでこれらの方法のどれを避けたいのか、そしてその理由は何ですか?
cookies - Web Dev-ショッピングカートのようなオブジェクトの状態をどこに保存しますか?
Webアプリケーションを構築しています。ユーザーのセッション中に、オブジェクトのようなショッピングカートの状態を保存する必要があります。
いくつかのメモ:
- これは正確にはショッピングカートではありませんが、ユーザーが作成している旅程のようなものです...しかし、ここではカートという言葉を使用します。b/cpplはそれに関連しています。
- 「放棄された」カートは気にしません
- カートが完成したら、後で取得できるようにサーバー側のデータストアに保存します。
そのステートフルオブジェクトをどこに保存しますか?そして、どのように?
- サーバー(セッション、データベースなど?)
- クライアント(Cookieキー値、Cookie JSONオブジェクト、非表示のフォームフィールドなど?)
- 他の...
更新:ターゲットとしているプラットフォームをリストすることが提案されました-完全に必要かどうかはわかりません...しかし、フロントエンドはASP.NETMVCで構築されているとしましょう。
asp.net - ASP.NETでViewstateを使用する必要がありますか
私は従来のASPからASP.NETに移行しており、多くの人がすでに「ビューステート」として知っているものに遭遇しました。私は自分の思い込みで銃をジャンプしているかもしれませんが、それは非常に面倒に見えます。私は過去に多くのASPフォームを開発しましたが、状態の維持に問題はありませんでした。別の方法がありますか、それともASP.NETでこのViewstateのことを学ぶ必要がありますか?Visual Studio 2008、VB.NETを言語の背後にあるコードとして使用し、Frameworkv3.5をSQLServer2005で使用しています。
process - 将来の調査のためにプロセスの状態を保持するために、プロセスのスナップショットを作成するにはどうすればよいですか?これは可能ですか?
これが可能かどうかはわかりませんが、非常に便利です。
定期的に失敗するプロセスがあります(Windows 2000で実行)。その後、再起動して再び失敗するのを辛抱強く待つ前に、それに反応するチャンスが1回だけあります。プロセスを作成しなかったため、デバッグするソースがありません。失敗は一見ランダムに見えます。
プロセスのスナップショットを使用して、障害に対する反応を繰り返し迅速にテストできました。
VM内で実行することを考えていましたが、この場合は不可能です。
編集:@Jon Cageは尋ねました:
スナップショットとは、失敗しそうなプロセス(メモリ、プログラムの状態などを含む)をキャプチャし、最後の数秒間を繰り返し再生して、他のコンポーネントにどのような影響があるかを確認することを意味します。
これはまさに私が言っていることです!
time - 状態と時間を超越するロジックとプログラム フロー?
いくつかの参照キーを使用して、アプリケーションのすべての可能な状態にインデックスを付けることが役立つかどうか疑問に思っています...
つまり、プログラムが開始され、考えられる結果が非常に多く、たとえば 8 つしかないとします。
ただし、各結果がさらに多くの論理状態をステップ実行することによって達成され、各分岐の間が状態と見なされ、キーにマップされる場合。
大規模なプログラムでは大量のメモリが必要になる可能性がありますが、キーに直接アクセスできれば (キーは時間またはロジックの深さに基づいている可能性があります)、プロセス全体を開始することなく、考えられる状況を即座にトラバースできます。新しいデータでもう一度。
子を持たないノードが最終的な結果であり、ノードとその親または子の間のすべてのブランチが「状態」であり、それぞれが異なるキーを持つツリーのように考えてください。したがって、プロセスの最終的な結果である葉は 8 つしかありませんが、子がなくなる前にロジックがツリーをどれだけ深く下っていくかに応じて、多くの「状態」が存在する可能性があります。
シミュレーション用かもしれませんが、大量のメモリが必要です。
java - Mementoパターン(およびコマンド)を使用して複雑なオブジェクトの状態を保存する
私は、数か月前に開始したJavaの小さなUMLエディタープロジェクトに取り組んでいます。数週間後、UMLクラス図エディターの作業用コピーを入手しました。
しかし今、私はそれを完全に再設計して、シーケンス、状態、クラスなどの他のタイプの図をサポートしています。これは、グラフ構築フレームワークを実装することによって行われます(私は、この主題に関するCayHorstmannの作業に大きく影響を受けています。バイオレットUMLエディター)。
友人の1人が、プロジェクトにDo / Undo機能を追加するのを忘れたと言うまで、再設計は順調に進んでいました。これは、私の意見では非常に重要です。
オブジェクト指向のデザインコースを思い出して、すぐにMementoとCommandパターンについて考えました。
これが取引です。2つのArrayListを含む抽象クラスAbstractDiagramがあります。1つはノード(プロジェクトではElementsと呼ばれます)を格納するためのもので、もう1つはEdges(プロジェクトではLinksと呼ばれる)を格納するためのものです。この図は、おそらく、元に戻す/やり直すことができるコマンドのスタックを保持します。かなり標準的です。
これらのコマンドを効率的に実行するにはどうすればよいですか?たとえば、ノードを移動したいとします(ノードはINodeという名前のインターフェイスタイプになり、そこから派生した具象ノード(ClassNode、InterfaceNode、NoteNodeなど)があります)。
位置情報はノード内の属性として保持されるため、ノード自体でその属性を変更することにより、状態が変更されます。表示が更新されると、ノードが移動します。これはパターンのMemento部分です(私は思います)が、オブジェクトが状態そのものであるという違いがあります。
さらに、元のノードのクローンを(移動する前に)保持すると、古いバージョンに戻すことができます。同じ手法が、ノードに含まれる情報(クラス名またはインターフェース名、ノートノードのテキスト、属性名など)にも適用されます。
問題は、図で、元に/やり直し操作時にノードをそのクローンに置き換えるにはどうすればよいですか?ダイアグラムによって参照されている(ノードリストにある)元のオブジェクトのクローンを作成した場合、そのクローンはダイアグラム内で参照されておらず、ポイントしているのはコマンド自体だけです。シャウド私は、IDに従ってノードを見つけるためのメカニズムを図に含めているので(たとえば)、図でノードをそのクローンに置き換えることができますか(またはその逆)?それを行うのはMementoとCommandパターン次第ですか?リンクはどうですか?それらも移動可能である必要がありますが、リンク専用(およびノード専用)のコマンドを作成したくないので、コマンドのオブジェクトのタイプに応じて適切なリスト(ノードまたはリンク)を変更できる必要がありますを参照しています。
どのように進めますか?つまり、オブジェクトのタイプ(ノードまたはリンク)によっては、オブジェクトの状態をコマンド/ mementoパターンで表現して、オブジェクトを効率的に復元し、元のオブジェクトをダイアグラムリストに復元できるようにするのに問題があります。
どうもありがとう!
ギヨーム。
PS:はっきりしない場合は、教えてください。メッセージを明確にします(いつものように!)。
編集
これが私の実際の解決策であり、この質問を投稿する前に実装を開始しました。
まず、次のように定義されたAbstractCommandクラスがあります。
次に、各タイプのコマンドは、AbstractCommandの具体的な派生を使用して実装されます。
だから私はオブジェクトを移動するコマンドを持っています:
MoveRemoveCommandもあります(オブジェクト/ノードを移動または削除するため)。instanceofメソッドのIDを使用する場合、ダイアグラムを実際のノードまたはリンクに渡して、ダイアグラムからそれ自体を削除できるようにする必要はありません(これは悪い考えだと思います)。
AbstractDiagram図; 追加可能なオブジェクト; AddRemoveTypeタイプ;
最後に、ノードまたはリンクの情報(クラス名など)を変更するために使用されるModificationCommandがあります。これは、将来、MoveCommandとマージされる可能性があります。このクラスは今のところ空です。私はおそらく、変更されたオブジェクトがノードであるかエッジであるかを判断するメカニズムを使用してIDを実行します(IDのinstanceofまたは特別な表記を介して)。
これは良い解決策ですか?
c# - ASP.NET セッション状態サーバー - シリアル化されていないデータの保存
ご存じのとおり、ASP.NET では、次の 3 つのモードのいずれかでセッション データを保存できます。
- インプロセス
- セッション状態
- SQLサーバー
InProc モードでは、シリアライズ可能でなくても、あらゆる種類のデータ オブジェクトを格納できます。ただし、セッション状態と SQL Server モードでは、シリアル化されたデータのみを保存できます。
私のプロジェクトでは、「InProc」モードを使用してセッションを保存する既製のポータルがあります。スケーラビリティと障害処理の問題があるため、代わりにセッション状態を使用する必要があります。
このポータルがシリアル化されていないオブジェクトをセッション コンテキストに内部的に保存しているという問題 (つまり、保存されたオブジェクトは ISerializable インターフェイスを実装していません)。私は彼らのコードにアクセスできません。コードを変更せずにセッション オブジェクトを State Server に保存できるようにするための回避策はありますか。これが何らかの形で役立つ場合は、まだ web.config ファイルにアクセスできます。