約 986,649 件
https://w.atwiki.jp/tmiya/pages/82.html
17.3 フューチャー フューチャー は、他のクライアントスレッドにおいて並列に計算される値であり、クライアントスレッドによっていつか使用されます。フューチャーは並行プロセスのリソースを有効に利用するために使います。典型的な使い方は次のようです。 import scala.concurrent.ops._ ... val x = future(someLengthyComputation) anotherLengthyComputation val y = f(x()) + g(x()) future メソッドはオブジェクト scala.concurrent.ops において、次のように定義されています。 def future[A](p = A) Unit = A = { val result = new SyncVar[A] fork { result.set(p) } (() = result.get) } futureメソッドは、実行すべき計算 p をパラメータにとります。計算の型は任意であり、そのことは future の型パラメータ a によって表現されています。future メソッドでは計算結果を表すパラメータを取る、ガード result を定義します。つぎに、新しいスレッドを fork して、答えを計算し終了時に result ガードを起動します。このスレッドに並行して、関数 (訳注 future) は型 A の無名関数を返します。この無名関数は、呼ばれたときに result ガードが起動されるまでウェイトし、そして、一度 result ガードが起動されると結果の引数を返します。同じ時に、関数は同じ引数で result ガードを再起動しますが、関数の future 起動は結果をすぐに返せます。 前ページ 17 章 目次 次ページ 名前 コメント
https://w.atwiki.jp/redcloud/pages/25.html
目次 目次 四大要素 アクティビティ 状態変化時のコールバックメソッド 主なActivity 主なメソッド レイアウト定義(main.xml)で使える主なウィジェット インテント サービス コンテントプロバイダ 情報へのアクセス手段 memo/tips Androidに組み込まれているレイアウトを使う 指定インテントを取り扱えるアクティビティ一覧表示 設定画面を作成する リンク 四大要素 アクティビティ 状態変化時のコールバックメソッド onCreate onResume onStop 主なActivity Activity基底となるアクティビティクラス ListActivity一覧形式のアクティビティクラス ExpandableListActivity伸縮可能な一覧形式のアクティビティクラス MapActivity地図表示のアクティビティクラス PreferenceActivity設定情報を扱うアクティビティクラス 主なメソッド View findViewById(int id)idを指定してレイアウトファイルに定義されているウィジェットを取得 void finish()アクティビティを明示的に終了 Intent getIntent()このアクティビティを開始する契機となったインテントを取得 Application getApplication()このアクティビティが含まれるApplicationオブジェクトを取得 レイアウト定義(main.xml)で使える主なウィジェット TextView EditText ListView Button インテント サービス コンテントプロバイダ 情報へのアクセス手段 query insert update delete getType memo/tips Androidに組み込まれているレイアウトを使う android.R.layout.～ を使う。res/layout下にレイアウトxmlが無くてもOK（組み込まれているから） android.R.layout.simple_list_item_1 （例：ListActivityでよく使うシンプルリストレイアウト） 指定インテントを取り扱えるアクティビティ一覧表示 LaucherActivityを継承したアクティビティを作成する public class LauncherActivityExample extends LauncherActivity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.launcher_example); } @Override protected Intent getTargetIntent() { Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http //developer.android.com/")); //ブラウザ系アクティビティが対象になる return intent; } } 設定画面を作成する PreferenceActivityを継承したアクティビティを作成する XMLで設定項目を定義する res/xml の下に定義ファイルを作成（例：res/xml/pref.xml）※eclipseで[新規]→[Android XML File]でウィザードを使って作成すると雛型ができて楽 Activityクラス public class PreferenceActivityExample extends PreferenceActivity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); addPreferencesFromResource(R.xml.pref); //xmlの設定を読み込む場合はaddPreferencesFromResourceメソッド } } ソースコードで設定項目を定義する リンク
https://w.atwiki.jp/akios/pages/71.html
4. 型と値と変数 4.1. 型と変数の種類 4.2. プリミティブ型と値 4.3. 参照型と値 4.4. 型変数 4.5. 引数付き型 4.6. 型の抹消 4.7. 具象可能型 4.8. 未加工型 非ジェネリックのレガシーコードとのインタフェースを容易にするため、引数付き型の抹消や構成要素の引数付き型を抹消した配列型を型として利用できます。このような型を未加工型(raw type)と呼びます。 もう少し正確には、未加工型とは次の1つとして定義されます。 型実引数リストを持たないジェネリック型宣言の名前という形式の参照型 構成要素の型が未加工型である配列型 未加工型Rの非静的メンバー型、Rのスーパークラスやスーパーインタフェースから継承されていないこと 非ジェネリッククラス型やインタフェース型は未加工型ではありません。 未加工型の非静的型メンバーがなぜ未加工とみなせるのか、以下の例を考えます。 class Outer T { T t; class Inner { T setOuterT(T t1) { t = t1; return t; } } } Innerのメンバーの型はOuterの型引数に依存しています。もしOuterが未加工であるなら、InnerはTに対する有効な束縛がないため同様に未加工として扱わなければなりません。 このルールは継承していない型メンバーの場合のみ適用可能です。型変数に依存する継承された型メンバーは未加工型のスーパータイプを抹消するというルールにより生まれた未加工型として継承されます。これはこの説の後で記述します。 上記のルールともう1つ密接に関係するのが未加工型のジェネリック内部クラスはそれ自身未加工型としてのみ使用できるということです。 class Outer T { class Inner S { S s; } } 部分的な未加工型(生焼け型(rare type))であるInnerにはアクセスできません。 Outer.Inner Double x = null; // illegal Double d = x.s; なぜならば、Outer自身は未加工のため、Innerを含むその全ての内部クラスも未加工となるので、Innerへ型実引数を渡すことができなくなるためです。 未加工型のスーパークラス(とスーパーインタフェース)はその引数付き呼び出しにおけるスーパークラス(スーパーインタエース)の抹消です。 スーパークラスやスーパーインタフェースから継承されない未加工型Cのコンストラクター、インスタンスメソッド(8.4.、9.4.)もしくは非静的フィールドMの型は未加工型です。その未加工型はCと対応したジェネリック宣言内のその型の抹消に該当するものです。 未加工型Cの静的メソッドや静的フィールドの型はCと対応したジェネリック宣言内のその型と同じです。 型実引数を未加工型のスーパークラスやスーパーインタフェースから継承されない非静的型メンバーに渡そうとするとコンパイル時にエラーとなります。 引数付き型の型メンバーを未加工型として使用しようとするとコンパイル時にエラーとなります。 これは"生焼け(rare)"型の追放を限定型が引数付きであるケースにも拡張していることを意味していますが、内部クラスを未加工型として使用しようとすると以下のようになります。 Outer Integer .Inner x = null; // illegal これは上で述べたことの逆です。この半分焼けた(half-baked)型の実践的正当化はありません。レガシーコード内では、型実引数は使われません。非レガシーコード内では、ジェネリック型を正しく使い必要とされる全ての型実引数を与えるべきです。 クラスのスーパータイプは未加工型であっても構いません。そのクラスへのメンバーアクセスは通常と同じに扱われ、スーパータイプへのメンバーアクセスは未加工型に対するように扱われます。クラスのコンストラクター内では、superの呼び出しを未加工型のメソッド呼び出しとして扱います。 未加工型の使用はレガシーコードとの互換性を得るための譲歩でしかありません。Javaプログラミング言語にジェネリクスが導入されて以降に書かれたコード内での未加工型の使用は強く反対します。Javaプログラミング言語の将来のバージョンでは未加工型の使用は禁止されるでしょう。 型ルールの潜在的違反を常に廃絶することを確かにするために、未加工型のメンバーへアクセスがあれば、コンパイル時に未検査警告が出力されます。未加工型のコンストラクターのメソッドをアクセスする際のコンパイル時の未検査警告のルールは以下の通りです。 フィールドへの代入の時点 左オペランドの型が未加工型なら、抹消によりフィールドの型が変更されるとして未検査警告をコンパイル時に出力する。 メソッドやコンストラクターの呼び出しの時点 検索するクラスやインタフェースの型が未加工型なら、抹消によりメソッドやコンストラクターの仮引数の型が変更されるとして未検査警告をコンパイル時に出力する。 抹消があっても仮引数の型に変更がないメソッド呼び出し(戻り型やスロー節に変更があるとしても)について、フィールドの読出しについて、もしくは未加工型のクラスインスタンスの作成については、コンパイル時に未検査警告を出力しない。 上記の未検査警告は未検査変換やキャスト、メソッド宣言(8.4.1.、8.4.8.3.、8.4.8.4.、9.4.1.2.)、可変項数メソッド呼び出しで発生する未検査警告とは異なります。 ここでの警告はレガシーコード開発者がジェネリックライブラリを使用した場合を想定したものです。例えば、ライブラリはVector T 型のフィールドfを持つジェネリッククラスFoo T extends String を宣言します。しかし開発者はFooの未加工型であるeに対し (){e.fで整数のベクターを代入します。これはジェネリックス使用ライブラリのジェネリック使用プログラムがヒープ汚染を発生させるということでレガシーコード開発者は警告を受け取ります。 (レガシーコード開発者はライブラリからVector String を自身のVector変数に警告を受けることなく代入できます。つまり、Javaプログラミン言語のサブタイプ化ルールでは未加工型の変数に型の引数付けされたどのようなインスタンスに対する値も代入することができます。) 未検査変換による警告はレガシーライブラリーを使用するジェネリクス開発者が遭遇する2つのケースをカバーします。例えば、ライブラリのメソッドはVector型の未加工型を返し、使用者側はメソッド呼び出しの結果をVector String 型の変数に代入します。これは、未加工ベクターはString以外の要素の型を持っているかもしれないので安全ではありません。しかし、レガシーコードとのインタフェースを保つため未検査変換はまだ使用できるようになっています。未検査変換による警告はジェネリクス開発者がプログラムの違う箇所でヒープ汚染を起こすという問題が発生するかもしれないということを喚起しています。 例4.8-1. 未加工型 class Cell E { E value; Cell(E v) { value = v; } E get() { return value; } void set(E v) { value = v; } public static void main(String[] args) { Cell x = new Cell String ("abc"); System.out.println(x.value); // OK, has type Object System.out.println(x.get()); // OK, has type Object x.set("def"); // unchecked warning } } 例4.8-2. 未加工型と継承 import java.util.*; class NonGeneric { Collection Number myNumbers() { return null; } } abstract class RawMembers T extends NonGeneric implements Collection String { static Collection NonGeneric cng = new ArrayList NonGeneric (); public static void main(String[] args) { RawMembers rw = null; Collection Number cn = rw.myNumbers(); // OK Iterator String is = rw.iterator(); // Unchecked warning Collection NonGeneric cnn = rw.cng; // OK, static member } } このプログラムは、RawMembers T は以下のメソッドを Iterator String iterator() スーパーインターフェースであるCollection String から継承しています。しかし、RawMembers型はCollection String の抹消からiterator()を継承しています。これはiterator()の戻り型はIterator String の抹消であるIteratorであることを意味します。 結果として、rw.iterator()からの代入はIteratorからIterator String への未検査変換を要求し、未検査警告が発生します。 逆に、静的メンバーcngは未加工型のオブジェクトへのアクセスが完全な引数付き型で表されています。(インスタンスへの静的メンバーを通したアクセスは悪いスタイルと考えられており推奨されません。)メンバーmyNumbersはNonGenericクラス(抹消もNonGeneric)より継承されていますので完全な引数付き型です。 未加工型はワイルドカードと密接に関係しています。両方とも実在型に基づいています。未加工型はレガシーコードとの相互接続を達成するために型規則を故意に不安定にしたワイルドカードとみなせます。歴史的には、未加工型はワイルドカードより先に出現しました。最初に紹介したのはGJで、論文Making the future safe for the past dding Genericity to the Java Programming Languageで著者はGilad Bracha、Martin Odersky、David Stoutamire、Philip WadlerでObject-Oriented Programming, Systems, Languages and Applications (OOPSLA 98), 1998年10月のACM会議会議録の中で述べられています。 4.9. 交差型 4.10. サブタイプ化 4.11. 型の使用箇所 4.12. 変数
https://w.atwiki.jp/chugoku_rails/pages/14.html
１、はじめに 特徴、Java,C++との違い 実行環境 参考になるサイト ２、基本文法 基本型（クラス） 変数／定数 制御構文 スコープ 例外処理 ３、メソッド（関数） 定義 引数 返り値 ４、クラスとオブジェクト 基本クラス 定義 継承 クラス変数とクラスメソッド ５、モジュール 名前空間 モジュールの定義 Mix-in ６、使用例 入出力 p 数値 文字列 配列 ハッシュ シンボル モジュールの活用 クラスの活用 正規表現 テキスト処理 RS232Cでも通信 データベースの操作 rails データベースの定義 railsのmigrateかRDBMSのDML
https://w.atwiki.jp/java_pro/
練習問題スライド 疲れた時の読み物に プログラミング言語人気TOP10の簡易解説 Javaの道 機種依存文字一覧 疑りぶかいあなたのためのオブジェクト指向再入門 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 Javaのポリモーフィズムが理解できません。 - Yahoo!知恵袋 Part6 同じ名前で機能が異なるメソッド？ポリモーフィズムの謎 Javaのprotectedの意味 Java資格試験の練習問題（メソッド編） Java練習問題（複数クラス編） Java練習問題（キャスト編） SJC-P対策問題集 Java SE 5.0の新機能、列挙型を習得する Java 基礎知識( データ型 )【 Okapi Project 】
https://w.atwiki.jp/socup/pages/184.html
XCodeプロジェクト設定 XCode4.4の変更点 XCodeショートカット XCodeビルド設定 ビルド コード上で左右スワイプ 右クリックで リファクタリング XCodeビルド設定 ライブラリ XCodeのカスタマイズ XCodeプロジェクト設定 XCode4.4の変更点 XCodeショートカット XCodeビルド設定 ビルド コード上で左右スワイプ 開いているファイルを移動できる。 右クリックで balance delimiter 前後領域を選択状態にする reindent 選択行のインデントを整形してくれる shift right indent 選択行を右へインデント shift left indent 選択行を左へインデント move line up 選択行を一行上へ、上にあったものは選択行の下になる。 moive line down upの逆 comment selection コメントの付け外し リファクタリング リネーム 親クラス作成 親クラスにメソッド移動 子クラスにメソッド移動 メソッド化、関数化 変数のカプセル化 変数をセッター、ゲッター経由で触る様に変更。 XCodeビルド設定 http //developer.apple.com/library/ios/#documentation/DeveloperTools/Reference/XcodeBuildSettingRef/0-Introduction/introduction.html Xcode Build System Guide＞Build Phases 環境変数 $(SRCROOT) プロジェクトファイルのあるパス プロジェクトにライブラリの追加 依存関係がある場合は設定 例 zlibに依存したライブラリならリンカフラグ -lzをつける（他のリンクフラグ） ヘッダファイルを検索パスを登録しておく ライブラリ XCodeのカスタマイズ
https://w.atwiki.jp/hirotakaohkubo/pages/50.html
2014年度 Scala Design Patterns を輪講形式で読む。 http //www.springer.com/computer/swe/book/978-3-319-02191-1 著者 http //people.uwe.ac.uk/Pages/person.aspx?accountname=campus%5cje3-hunt Amzazon.comの書評を転載する。 I was excited to see a pattern book on Scala and the publisher, Springer, normally has good books. This book is an exception. The content is shallow. If you have the GoF book, this might provide some guidance on the Scala implementations, but the quality of print and graphics is just not worth the price. Some patterns have as little as 3 pages. Code samples are presented as graphic images and the graphics are horrible. The code samples are barely readable. Check out the Kindle version, the graphics don t get better in print. The first 50 pages of this 327 pages book covers UML, that leaves precious few pages to cover dozens of patterns. AND, no index is provided. Absolutely the worst Spring book I ve ever purchased, and I own many. もうちょっと調べてから本を決めるべきでしたね。 2012年度、2013年度 テキスト「独習デザインパターンC++」 Errata(公式) こちらには1刷の誤りのごく一部しか掲示されていないが、 現在はさらに多くの訂正が入った2刷が流通している。 また、2刷によってエンバグした箇所もある。 小生からの問い合わせが元で正誤表システムのトラブルが発見され、訂正されたようです。 C++の解説サイト 補足 p.61 「さらに、呼び出し側のクラス（関数）に」『に』がメソッドを作る位置にも読めるので、まるごと消す。 p.65 リスト getInstance()の中の map int, ... から if (it != ... までの3行のインデントを前後と揃える p.96 l.-5 「デコレーションケーキすべてを入れられる変数pFactory」変数の型の説明としておかしい。 p.97 図5.1 BirthdayDecorationクラスには+makeDecoration(String)メソッドもある p.108 l.1 「３つの処理呼び出」⇛「３つの処理呼出」or「３つの処理呼び出し」 p.145 l.7 「writeString()をオーバーライド」→「writeString()をオーバーロード」 p.148 図9.2 HTMLWriterObjectAdapterからHTMLWriterへの関係に、private変数pWriterの名前を補ってもよい p.161 リスト10.3 割と肝心な Command getPoint() メソッドの定義が抜けている。 p.176 GoFには、Facadeを使わずにサブシステムを直接操作する方法を妨げたりしない、とある。 p.186 図12.3 ConcreteSateA/B → ConcreteStateA/B §15 Proxyパターンを説明するのにこの例は筋が悪い。 p.239 リスト16.8 pDirector- constract(pBuilder); は construct の typo p.240 図16.1 各concrete HomeBuilder の getStructure() は setStructure() の typo p.265 図18.4 MediatorからColleagueへの矢印は逆。ConcreteColleagueA,BからConcreteMediatorへの矢印は逆で形も異なる。2刷で訂正済。 p.275 図19.2 Delivertyの属性successor_はpSuccessorのtypo p.276 図19.3 Handlerが目でなく日になっている。自分自身への依存にsuccessorと名前をつけると親切。 p.304 l.1 「visit()メソッドでは、検索対象のディレクトリまたはファイルの名前が指定されたものかを判断して、そうであった場合は」でないと意味が通じない。 p.306 図21.3 ListVisitor find() は ListVisitor visit(node Node) Stringの誤り p.308 §21.8 l.1 「クラスの要素を変更」では意味不明。「ビジターが走査するElement側のクラス階層にクラスを追加」のことか。 20章 メソッド名 write() → writeData() p.290 l.7, p.291 l.6, リスト20.9 l.15 リスト20.9 l.5 virtual writeData( → virtual void writeData( 同 l.11 CAbstract... → Abstract... 同 l.14 メソッド宣言に virtual void と型を追加 (virtualは必要？) p.293 図20.8 一番下 component operation(); → Decorator operation(); 21章の例 属性idは何も影響しない。add()メソッドも何も効いてこない。関係ない要素は省くべき。 逆に、add()メソッドは図にあるようにDirectory独自のメソッドであるべきで、NodeやFileにも入れるのはおかしい。 p.299 リスト21.1 l.6 findメソッドはvirtualにしなければならない 同 l.-7 Node* → Node* * 同 l.-5 if の条件式は .compare() の結果ママではなく == 0 しないと逆になる 同 l.-4 return* のアスタリスク不要 p.300 リスト21.2 l.5 デストラクタ virtual ~File(); が不要 同 l.6 add() に virtual 不要 (将来的にoverrideするなら本体の定義側に必要?) p.300 リスト21.3 コンストラクタでは children の初期化が必要、デストラクタの実体でこれの delete() が必要。 childrenは参照ではないので自動的に初期化される。よってデストラクタ ~Directory(); の宣言(l.5)が不要。 同 l.6 add() に virtual 不要か、合わせる。 同 l.7 find() も同上。 同 l.-4 new list Node* → Node find(name) 自分自身を検索するのを忘れている。 p.301 同 l.3 delete temp; は if の外に出さないとメモリリーク。 同 l.7 result → pResult p.305 図21.2 図中のオブジェクトの名前がずれていては意味を成さない。 1 find(node,name) と directory Node は名前を統一するべき また、対応するオブジェクト図を同時に示すべき。 p.314 リスト22.1 PieceのコンストラクタでnameをNULLに初期化しないで大丈夫か？ p.318 §22.6末尾 そういうスタイルもあるがmustではない。 p.320 リスト22.8 clone()メソッドをprotected にしたら呼べない。 p.321 §22.8末尾 「通常は」以下、聞いたこともないしこの説明で何をどうするのかさっぱり理解できない。 p.321 §22.9 全体的に意味不明。 Widget Setに用意されいてるクラスのインスタンスを生成することのどこがクローンなのか。 p.330 リスト23.7 l.6 "public "のインデントは0 l.14 "map int, BillCoin* ..." は何？ p.342 リスト24.1 getCell中の CCell → Cell l.-4 ; it != のセミコロンの後を空けるべき p.343 リスト24.1 addStack()中 CCell → Cell, (*it) → (*itCell) p.346 リスト24.3 ~SheetWithMemento() の最後の delete stack; は不要。 l.-5 }else{ は1文字ずつ空けるべき。 p.347 リスト24.3 undo() 最後の if (current = 0) は最初に if (current 0) return しているから不要。 undo() と redo() で変数スタイルが memento, pMemento と統一されていない。 addStack()中 currentからendまでの範囲をerase()すれば一度で済む。 currentまでイテレータを進める、という計算をパターンにしないのが不思議なレベルで頻出してうざい。 erase()はその要素をリストに含めていたことを捨てるだけなので、メメントがメモリリークする。 しかし単純にメメントをdeleteすると、持っているCellも壊してしまう。 p.348 ~CellMemento()中 2度編集されたセルの1度めの編集操作は、新規書き込みメメントのNewと上書きメメントのOldの両方に持たれている。 Sheetのデストラクタでstackのメメントを順にdeleteすると、この編集操作を2度deleteしておかしくなる。 最後の2行、CCellMemento→CellMemento 24章 メメントがどんなものか説明せずにコードを読ませる§24.4の展開はひどい。 サンプルコードも上に指摘したようにかなり品質が低い。 また、§24.6の一般形と、クラスの対比はとれてもメソッドの対比がとれていない。例として不適切。 CaretakerとOriginatorは別のクラスであり、Originatorのカプセル化を破壊しないような例でなければならない。 p.350 図24.4 ２つのコメントによるコード断片は、右がsetMemento(),下がcreateMemento()の説明だが、点線が届いていないので意味不明。 p.356 リスト25.2 最後の3つのコンストラクタ呼び出しの引数 (SPC)SEAT → _SEAT p.362 リスト25.9 ConditionalPolicy()の仮引数が行頭から始まっている。カッコの次のカラムにインデントする。 p.363 図25.3 ConditionalPolicyはAbstractPolicyのサブクラス 25章 InterpreterパターンはDSLと等価な考え方で、「コンテキストに依存して結果の変わる評価動作を持つ」だけでなく 「構文を持ち意味を組み立てられる」も本質の一部。ここの例では前者しか扱っていない。 拡張で導入したTimeConditionでその説明をしたというのも無理がある。 §25.4の「これがInterpreterパターンでござい」はひどすぎる。それはオブジェクト指向設計。 既知であったもの p.178 箇条書きの1 Idel → Idle
https://w.atwiki.jp/reginn666/pages/93.html
ダンジョン(スポナー部屋)に関するフック類. ダンジョン内に置かれるチェストにアイテムの追加・削除, 設置されるスポーンブロックに種類の追加・削除を行うメソッドが提供されている. スポナー関連 public static float addDungeonMob(String name, int rarity) public static int removeDungeonMob(String name) 名前で指定したMobをスポナーリストに追加, 削除するメソッドと, ランダムで登録されているMobの名前を取得するメソッド. addDungeonMobの引数rerityはゾンビが200, クモ, スケルトンがそれぞれ100で, 数字が大きいほど出現しやすい. なお, 同じ名前のMobが二度登録された場合, 単に出現率が上昇するだけ. チェスト関連 public static void setDungeonLootTries(int number) チェスト内に配置されるアイテムの最大数をセットするメソッド. public static void addDungeonLoot(ItemStack item, int rarity) public static float addDungeonLoot(ItemStack item, int rarity, int minCount, int maxCount) public static void removeDungeonLoot(ItemStack item) public static void removeDungeonLoot(ItemStack item, int minCount, int maxCount) ダンジョン内に設置されるチェスト内のアイテムを変更するメソッド類. rarityは100で最大, 必ず出現するようになる. バニラのMob設定 addDungeonMob("Skeleton", 100); addDungeonMob("Zombie", 200); addDungeonMob("Spider", 100); バニラのアイテム設定 addDungeonLoot(new ItemStack(Item.saddle), 100 ); addDungeonLoot(new ItemStack(Item.ingotIron), 100, 1, 4); addDungeonLoot(new ItemStack(Item.bread), 100 ); addDungeonLoot(new ItemStack(Item.wheat), 100, 1, 4); addDungeonLoot(new ItemStack(Item.gunpowder), 100, 1, 4); addDungeonLoot(new ItemStack(Item.silk), 100, 1, 4); addDungeonLoot(new ItemStack(Item.bucketEmpty), 100 ); addDungeonLoot(new ItemStack(Item.appleGold), 001 ); addDungeonLoot(new ItemStack(Item.redstone), 050, 1, 4); addDungeonLoot(new ItemStack(Item.record13), 005 ); addDungeonLoot(new ItemStack(Item.recordCat), 005 ); addDungeonLoot(new ItemStack(Item.dyePowder, 1, 3), 100 );
https://w.atwiki.jp/maimuzo/pages/37.html
プラグイン名 acts_as_paranoidプラグイン このプラグインができること やりたいことは理論削除。よくdelete_flag(boolean)などとしてフラグが立っていたら削除済みとして扱っていたようなものを、半自動化する。 destroyで本当に削除するのではなく、deleted_atカラムにタイムスタンプを入れるようにする。 find系メソッドを書き換えて、deleted_atカラムにタイムスタンプが入ってないものだけを検索対象とする 削除済みのものだけ、削除済みのものとそうでないものを含めた検索も可能 対象バージョン 1.2系 2.0系 ちょー簡単な使い方 ./script/plugin install acts_as_paranoid でインストールして、 class AddDeletedAt ActiveRecord Migration def self.up add_column users, deleted_at, datetime end def self.down remove_column users, deleted_at end end こんな感じでdeleted_atカラムを追加し、マイグレートできたらモデルに class User ActiveRecord Base acts_as_paranoid end てな具合に使用を宣言する。 すると、 destroyメソッドで削除ではなくdeleted_atを埋めるようになり findメソッドでdeleted_atがnullのものだけ対象にするようになり 削除済みも含めて何かしたいときはfind_with_deletedメソッドを使うか、 User.find( all, with_deleted = true)と使う でもちょっとバグいので、DoRuby|Ruby on Railsでacts_as_paranoidを使い倒すを参考にするのがいいかも。 公式ページ 公式 日本語解説ページ マルッと！|ActiveRecord 削除フラグで削除するプラグイン ※基本的な使い方はこれでOK DoRuby|Ruby on Railsでacts_as_paranoidを使い倒す ※Rails2.0への対応の悪影響や、バグのパッチを公表しています 外国語解説ページ まだ見つけてない のうはう AR.find_with_deletedまたはAR.find(..., with_deleted = true)で削除済みのものが検索対象に入るようなんだけど、バグっていてエラーになる。 Rails開発日記|論理削除プラグイン(バグ修正)この記事を参考に回避する必要あり。 あと上にも書いたけどDoRuby|Ruby on Railsでacts_as_paranoidを使い倒すとか。 コメント 名前
https://w.atwiki.jp/sklab/pages/51.html
CLRスレッドプール 単純な計算量依存の処理を実行する CLRスレッドプール CLRごとに１つのスレッドプールがある スレッドプールはすべてのアプリケーションドメイン間で共有 単一のプロセス内に複数のCLRがロードされている場合は複数のスレッドプールがある アイドル状態が続くと、スレッドは自動で起動し、処理を実行し終了する リソースの問題が出そうだが、アプリケーションがそれほど多くの処理を実行していないことを意味しているため問題ない 単純な計算量依存の処理を実行する スレッドプールのキューにタスクを投入するには、ThreadPoolクラスが利用される QueueUserWorkItemメソッド QueueUserWorkItem(WaitCallback callback, Object state) callbackに実際の処理を記述