約 3,146,306 件
https://w.atwiki.jp/seasartaro/pages/12.html
コメントプラグイン @wikiのwikiモードでは #comment() と入力することでコメントフォームを簡単に作成することができます。 詳しくはこちらをご覧ください。 ＝＞http //atwiki.jp/guide/17_60_ja.html たとえば、#comment() と入力すると以下のように表示されます。 名前 コメント
https://w.atwiki.jp/gamebiz_database/pages/84.html
サービス終了リストを年ごとにリンクを並べただけのページですが、何年にお探しのゲームが終ったのか調べたい方はご活用下さい。 順次更新予定です。 2014年 サービス終了リスト2014年版 2015年 サービス終了リスト2015年上半期 サービス終了リスト2015年下半期 2016年 サービス終了リスト2016年上半期 サービス終了リスト2016年下半期 2017年 サービス終了リスト2017年上半期 サービス終了リスト2017年下半期 2018年 サービス終了リスト2018年上半期 サービス終了リスト2018年下半期 2019年 サービス終了リスト2019年上半期 サービス終了リスト2019年下半期 2020年 サービス終了リスト2020年上半期 サービス終了リスト2020年下半期 2021年 サービス終了リスト2021年上半期 サービス終了リスト2021年下半期 2022年 サービス終了リスト2022年上半期 サービス終了リスト2022年下半期 2023年 サービス終了リスト2023年上半期
https://w.atwiki.jp/gamebiz_database/pages/32.html
東京都中央区築地。2005年3月3日サイバーエージェント出身の村田マリ氏により設立。 2012年2月21日、gumiにゲーム製作部門を譲渡した後に解散。 mixi版配信リスト タイトル名 ジャンル サービス開始日 サービス終了日 備考 スイーツコレクション 育成収集 2009年11月? スイコレ運営に運営譲渡 スイーツコレクション2 育成収集 2010年11月12日 2012年10月1日 gumiに事業譲渡 mobage版配信リスト タイトル名 ジャンル サービス開始日 サービス終了日 備考 スイーツコレクション 育成収集 2010年1月27日 不明 スイーツコレクション2 育成収集 2010年9月? 2012年10月1日 gumiに事業譲渡 すしコレクション 育成収集 2011年3月? 不明 〃 ギルドメシア カードバトルRPG 2011年12月26日 2012年5月? 〃 gree版配信リスト タイトル名 ジャンル サービス開始日 サービス終了日 備考 スイーツコレクション2 育成収集 2010年6月29日 2012年10月1日 SP版2011年6月29日、gumiに事業譲渡 すしコレクション 育成収集 2011年4月28日 不明 gumiに事業譲渡
https://w.atwiki.jp/socialgamematome/pages/42.html
FLOWER KNIGHT GIRL 【ふらわーないとがーる】 ジャンル RPG 対応機種 ブラウザゲームiOS/Android 配信元 DMM GAMESFANZA 開発元 Your GAMES 配信日 ブラウザ 2015年1月27日 iOS/Android 2018年8月29日 定価 無料(一部課金アイテムあり) プレイ人数 1人 レーティング FANZA アダルトゲーム ポイント 初心者に色々な意味で優しい不具合対応とそれに対する補填が優秀キャラ間のバランスが悪い 概要 特徴 基本システム 評価点 賛否両論点 問題点 総評 余談 概要 DMM GAMESが2015年初頭に送り出した実際に存在する花をモチーフ（※擬人化ではない）としたブラウザゲーム。当時は似たようなブラウザゲームが数多く輩出され、本作もその無数のゲームの内の一作に過ぎなかった。しかし、本作は様々なユーザビリティに注力した結果、DMMを代表とする筆頭ゲームとなり得たのである。 特徴 主人公はスプリングガーデンと呼ばれる異世界にて、花騎士（フラワーナイト）を統括する団長として、補佐官であるナズナと共に様々な任務をこなしていく。花騎士とは、世界花という大いなる力の加護を得た超人じみた人間のことであり、絶対に女性で名前はすべて実際に存在する花となっている。しかし、あくまで命名に花の名前が使われているに過ぎず、花を擬人化したものではない（見た目などは花をモチーフにしているため、誤解されやすいが）。ファンの呼称は主に「花騎士」「お花」。本ページでは前者を使用するものとする。 基本システム クエスト 3分に1回復するスタミナを消費して受ける任務。この際、パーティは戦友（もしくはクエスト専用のパーティか、野良パーティ）を含めて最大5パーティ組むことが可能。1パーティにつき、編成できる花騎士は5名。 移動力 クエストマップはいくつかのマスで構成されたもので、よりこの数値が高いパーティが素早くマスを移動できる。 勲章 「全モンスタ―討伐」「全宝箱回収」「ステージクリア」「全ボスモンスター討伐」の内の3つ条件を達成することでアイテムやキャラをゲットできる。 スロット数 装備できるアイテム数。初期は1で、最大は4つ。同じキャラを掛け合わせるか、特定素材によって確実に成功する。 スキルレベル 攻撃時に一定確率で発動する強力なスキルの発動率のこと。初期は1で最大は5。同じキャラを掛け合わせることで低確率で成功するが、特定素材によって確実に成功する。 進化・開花システム レベル上限である60（開花は70）を超えると特定素材を使用して新たな見た目と能力を得る。 昇華システム レアリティ5以下（最大は6）のキャラクターに特定素材を使用して、最大レアリティの6にランクアップさせる。元のレアリティが低いほど特定素材の数は多く必要。また、スロット数やスキルレベルの大きさである程度素材の緩和が可能。 レベル上限突破 「覚醒竜 センティ」という素材を使って、1体につきキャラレベルを5上げる。最大は110。 クジラ艇 総勢40人の花騎士を引き連れて巨大モンスターと戦うイベント。4種類ある属性も合わせる必要があるため、初心者にとっては参加自体が難しい。 評価点 初心者でも安心な難易度 配信当初はお世辞にも評価点というには程遠いものだったが、現在は後述する大量の詫び石、豊富なサービスアイテムなどで、無課金でもそれなりに楽しむことができる。いわゆるエンドコンテンツなクエストも存在するが、クリアに必須というわけでもないので、ブラウザゲームでありがちな「難しくて特定のキャラが必要」といったことはほとんどない。 フットワークが軽い運営態勢 （悲しいことに）この業界では珍しくユーザ視点で堅実な運営を行っている。目に見える不具合はもちろん、「そんな不具合知らないんだが」というものまで幅広く、かつ迅速に改善がされている。しかも、その度に何度も何度も詫び石として華霊石（魔法石のこと）が配布され、ユーザからは「身に覚えのない詫び石が団長を襲う」ともっぱら言われている。もはや、詫び石を投げるためにわざわざ理由をつけているとしか思えないほど頻繁にである。このためか、DMM GAMESで行われたユーザアンケートでは、異常とも思える「 好きな理由のTOPが運営 」という事態になった。ここまで運営が愛されるゲームは他にないと思われる。ちなみに、詫び（もしくは配布）石の例としては「不具合改善」「過去攻略が難しかったクエストを緩和化した際の補填」「ニコ生で起きた珍事(*1)」「○ヶ月運営記念キャンペーン(*2)」「コミケ参加によるお礼（一体何に対するお礼なのか）」など。 魅力的なキャラクター達 花言葉を元にした、もしくはまったくそうでないキャラ付けをされていたりする。性格は基本的にラブ勢が多く、不快になるようなキャラはほとんど皆無（好みによるところもあるが、このあたりは徹底している）。しかも、忘れた頃に非常に癖の強いキャラ(*3)が実装されたりと、変化球も非常に面白く楽しめる。その美しいキャラクターグラフィックを、SDという形で戦闘シーンなどで再現しているが、これが類を見ないほどの高クオリティを持っている。3Dじみた動きをしたり、非常に細かい動作を丁寧に表現したりと、まさに見ているだけで芸術といえるほどの素晴らしさである。このSDに惹かれて団長になったユーザも数多く存在する。 距離が近づいた最高レアキャラ 排出率がかなり絞られているレアキャラが、ガチャ実施時に得られる「虹色メダル」で好きなキャラと交換可能となった(*4)。また、課金必須ではあるが、特定キャラを対象に好きなときに交換可能な「スペシャルチケット」、 非所持キャラのみ 確定で出現する「スペシャルガチャ」も頻繁に実装しており、高品質パーティを組むことは困難ではなくなっている。 全年齢、成人向けに配慮されたイベント 好感度システムで、贈り物を100%になるまでキャラにプレゼントすることで全年齢は「デートイベント」成人向けは「お楽しみイベント(*5)」が発生する。どちらも非常に力が入っており、いつでも回想可能。 力が入りすぎている季節ボイス キャラ数は800ほどだが、全キャラにシーズン限定の特殊ボイスが実装されている。しかも、 年毎にそれぞれセリフは異なる のが凄まじいこだわりよう。 スタミナ消費の回避 クエストを行う際、途中でパーティが全滅したりやり直したいときの撤退を選ぶとスタミナが消化されない。これにより、様々なパーティでクエストを吟味する余裕がうまれた。 賛否両論点 一部難易度の高いマップ ノーマルクエストには、未だに勲章取得が困難なマップが存在する。具体的には各ステージマップ内の害虫を全滅させなければならない中で、討伐対象のいるルートへ進めるかどうかが完全に運任せのランダムパネルに委ねられる局面がかなり多く、運が悪いと何度も周回する羽目に陥ってしまう。ゴール到着前に撤退すればスタミナを消費せずに済むが、それを差し引いてもかなり面倒。 また第3部最終盤には「かなり強力なボス格の敵との連戦」というステージもあり、パーティ次第ではかなりの大苦戦を強いられることとなる(*6)。強力な戦友の助っ人パーティを使ってでもクリアさえすれば勲章コンプリートできるのは救いか。 シナリオ 初期はシナリオがなかったのだが、サービス運営が続いていく内に実装したものがある。しかし、お粗末というか後付というか、他のクエストに比べて文章量も質も段違いで悪い。肝心の現行のシナリオは、よく言えば「無難」、悪く言えば「当たり障りがない」といえる。このノリが好きというユーザも存在する。時々だが、力の入ったシナリオもあったりするので、そのときは見ごたえがある。 UIの重さ 2019年6月17日にHTML5に移行したが、全体的にまだ重さは残っている。ただし、強化合成画面は比較的軽くなったため、今後の対応が期待されている。 物足りない18禁シーン 若干古参のゲームであるため仕方ないが、Live2Dは多くが非対応(2021年から徐々に実装)、かつイラストが差分含め 2枚しか存在せず 、そっちに使えるかは微妙という意見が多々。シチュエーションもある程度テンプレ化しており、バリエーションに欠ける。テキストとイラスト自体はかなり力が入っている。 物足りない全年齢版 全年齢版に先駆けて実装したデートイベントだが、お楽しみイベントと違って一枚絵が存在せず、終始ADV画面での進行となる。シナリオ自体は悪くないのだが、やはりお楽しみイベントと比べると味気なさは否めない。しかも、成人向けでもデートイベントが視聴可能になったため、全年齢版を選択する理由が（性的なイベントを希望しない限り）ほとんどなくなってしまった。 スマホ版とのイラスト差異 スマホ版は全年齢対象（DMM GAMES提供のアプリを除く）であるため、露出度の高いキャラのイラストが修正されている。この修正のされ方の良し悪しがかなり賛否が分かれている。胸元や臀部を隠すのはまだわかるが、脇やへその部分も修正（しかもされていないキャラもいたり統一性がない）されているのは首を傾げたくなる。コラボキャラ（下記参照）であるシオン（ノコンギク）の胸元がかなり際どいのも納得がいかない(*7)。ただし、元々露出の度がすぎていたキャラ（例であげれば進化バラ）の修正はなかなか高評価だったりする。 SDやボイスの格差 本作の評価点ともいえるほどのクオリティを誇るSDであるが、初期に実装されたSDキャラと最新のキャラとで大きな技術力の差が出ている。例えば、「喜び」のポーズで初期キャラは「片手を上げ下げする」だけなのに、最新キャラは「独自にアクションを豊富に行う」といったほど。この辺りは、初期キャラのSDをリメイクしてほしいという意見が多く見られる。 また近年のキャラでも、モーションの殆どが左右に少し揺れるだけなど、悪い意味での手抜きな印象を受けるSDはちらほら見受けられる。 ボイスに関してはSDほど目に見えて悪い点はなく声優陣の演技も良好だが、初期に実装されたキャラは（作風の模索的な意味でも仕方ないとは言え）台詞内容が近年のそれに比べて淡白な印象は人によっては気になる。ホーム画面でのボイスや贈り物を渡したときなどが顕著か。 虹色メダルの仕様変更を通して生じたキャラ間の入手難易度格差 先述の虹色メダルの項での注釈にも記した通り、現在当該アイテムで交換可能なキャラは「2020年1月20日までに実装された恒常ガチャのキャラ」及び「虹色メダルとの交換のみで獲得できるキャラ」に限られている。裏を返せばそれ以降のキャラは現状虹色メダルを貯めても獲得できず、「特定のキャラを狙って」入手する手段が非常に限られてしまっている。 具体的にその難易度について掘り下げると、一部ガチャの特典や配布等で稀に得られる「☆6交換チケット（プレミアム）」は虹色メダルと同じ交換範囲、頼みの綱となる「開花・復刻ガチャ」のピックアップ確率も実装時ガチャより低い上所謂「天井」が設定されておらず、無課金ならごくたまに開催される「引き直しガチャ」に頼るしかない。課金限定ガチャも「未所持の☆6をランダムだが1体確実に入手できる」というものが多数派であり、特定キャラを狙うならより広範囲を交換対象とするチケット付きガチャの開催を待つ必要がある。 ただ、（狙わなくても排出率が狭き門であることは兎も角として）虹色メダルの交換対象内キャラだけでも良質なパーティは編成でき、それ以降のキャラがいないから不利になるという局面もそうないという点は強調しておく。一目見て気に入ったキャラを中々獲得できないのは相当なもどかしさがあるのもその通りではあるが…… 誰得なコラボイベント 2019年3月より「転生したらスライムだった件」とのコラボが決定。しかし、もともとコラボ元の作品は全年齢であるため、FANZA版ではイベント自体が存在しない。また、入手できるキャラは虹色メダルの対象外であり、入手は虹色メダル実装前の修羅の道を極める。しかも、イベント終了後はイベントの回想はできないし、再入手も（復刻含めて）一切不可と宣言されている（これは版権上仕方ないのかもしれないが）。問題なのが、このコラボで「どちらも全く得しない」という点である。花騎士のプレイ層は「20台～40台」、転スラはなろう作品なので恐らく「中高生」が主なターゲットであり、噛み合わない。それに、花騎士と転スラの関連性が乏しく、第一こちらは「成人向けゲーム」あちらは「全年齢向け」という大きな隔たりがある。この頃、転スラがこの時期にやたらめったらコラボを行っているので、花騎士がその煽りを受けたものだと感じるユーザが多数を占めている。実際、ニコ生のときもプロデューサーはあまり乗り気ではなく、渋々コラボを引き受けたという印象が非常に強い。ただし、結局のところ興味がないならばスルーすればいいということであり、義務感を迫るものではない。報酬が欲しいのであれば無心で周回すればいいだけである。転スラも知名度の高いアニメなので、団長の中にも視聴者は存在しており、それでコラボを歓迎している方もいるので嬉しい部分もある（逆が存在するかは甚だ疑問だが）。 その後、 「ランスシリーズ」「ワルキューレ ロマンツェ」 といった、成年向け作品とのコラボも行われた。こちらも版権の都合上、復刻などは絶望視されているものの、しっかりお楽しみシーンが設けられている上、シナリオの親和性もまずまずだったので、概ね好評の様子。主役キャラが（見た目的な意味で）散々な目に遭っているのが特徴。 問題点 キャラクターの性能バランス 顕著に表れているのが「最高レアキャラ」間と「昇華キャラ」のバランス。このキャラクターの性能さが数字が読めればすぐに理解できるほど、上位下位互換の差が大きい。しかも、昇華キャラは苦労に見合った性能と、そうでない差が非常に大きく、強昇華キャラは「★7レアリティ」と呼ばれるほど強力といわれるが、弱昇華キャラは「★5よりマシ」と呼ばれるほどの格差がある。このバランス間も運営は問題視していたようで、特定キャラのバランス改善が大きく告知された。これにより、キャラクター間の格差は減ると思われたが、実際は「 弱キャラの修正が中途半端 」で「 候補になかった強キャラが突如修正 」という火に油を注ぐ改修が行われた。幸い、本作はこういった問題を気にしないでも攻略が容易なのが救い。しかし、だからといってキャラ性能で格差を出していい理由にはならない。そのキャラが好きな団長にとっては尚更である。しかし、2021年6月14日に 初期キャラ143人に対して大規模かつ大きなバランス調整がなされた。 これにより各キャラの性能における格差は非常に縮まったものの、 対象外のキャラとの格差は更に広がってしまった。 （参考ページ） 一強になりがちなパーティ構成 2017年初頭までは「デバフ(*8)パーティ」が最強だったが、現在は「クリティカル(*9)パーティ」がほぼ一強。デバフが廃れた理由は、デバフしても意味がないほど強力な攻撃性能を誇る敵が実装したため。そうなると、先手必勝で1ターン目で確実に撃破する火力パーティが推奨されるのは当然となる。近年はこれだけではとっぱが難しく、多種多様な構成が求められているが、それそれで高難易度に拍車がかかっていると新参団長には不評。ただし、この問題が浮き彫りになるのはエンドコンテンツの超高難易度クエストのみであり、通常のクエストではよほど能力にチグハグでない限りは攻略は可能である。 開花絵の問題 開花は運営当初は視野になかったシステムで、古参のキャラは通常と進化のみしかイラストが存在しなかった。そのため、開花の際にイラストが更新されない花騎士は多数存在して、酷いものでは数年単位で進化絵のままというものもある。中には著名なイラストレーターが担当しているキャラもおり、そちらの実装はかなり絶望視されている。これは「艦これ」(*10)でも似たようなことが起きており、本作のみの問題とはいえない。 別バージョンの問題 同じキャラで、別の衣装を着たキャラが実装するときがある。その機会は「キャラ人気投票イベントでの上位入賞」および「 いきなり 」。後者は何の誇張もない事実である。ただし「いきなり」の対象はあくまでレアリティが★5以上のキャラに限り、それ未満のキャラは前者の投票イベントで入賞する必要がある。このため、人気投票といえば「実装が困難な低レアキャラの上位バージョン獲得」のチャンスとなるわけだが……。ここまで書けば察してもらえたかもしれないが、問題は「人気投票の対象が 絶対に必要なキャラ と 必須ではないキャラ が入り混じっている」ということである。レアリティが5以上であれば、人気の結果に関係なく「いきなり」実装することがあり「人気の結果が必須」なキャラが割を食っている問題が存在する。特に花騎士の一人である「アネモネ」は入賞率が相当高く、毎回入賞枠を圧迫感しているということで所謂「殿堂入りシステム」が導入されるまでキャラとは別に批判の的になっていたのは有名な話。 総評 ブラウザゲームでは非常にプレイが楽しく、界隈では問題視されがちな運営の態度も信頼できるため、長いスパンでプレイするのであれば非常におすすめである。肝心のブラウザ部分の動作が重いのがネックであるが、プレイに大きく支障をきたすほどでもないので、慣れればそこまで気にならない。お手軽に高品質、かつ高頻度の石補充可能なゲームという点は本作の強みといえよう。 余談 ハイクオリティなOP風のPVアニメーションが存在する。過去の人気投票で上位を獲得したキャラ（あとナズナも）が総出演するため、未見の方は視聴してはいかがだろうか。ちなみに、サムネに出ているキャラ「ヒガンバナ」がそのときの一位だった。
https://w.atwiki.jp/seasartaro/pages/68.html
Splitterクラスは文字列を分解するときに使用します。以下の文字列があるとします。 "Tokyo,Shinagawa,,Nagoya, Osaka,," ","で区切られた文字列ですが、ところどころ歯抜けがあります。 これをJavaで分解すると以下のソースになります。 String[] parts = stations.split(","); for (int i = 0; i parts.length; i++) { System.out.println("station = " + parts[i]); } 結果は以下です。 station = Tokyo station = Shinagawa station = station = Nagoya station = Osaka Shinagawaの次の空文字は抽出されましたが、Osakaより後のデータが無視されていました。 Splitterを使ったサンプルコードは以下のようになります。 List String stationList = Splitter.on(",").splitToList(stations); for (String part stationList) { System.out.println("station = " + part); } 結果は以下になります。 station = Tokyo station = Shinagawa station = station = Nagoya station = Osaka station = station = String.splitで無視された空文字もリストに含まれています。 Splitterの基本的な文法は以下になります。 Splitter.on(区切り文字).splitToList(対象文字列); 以下のようにすると、空文字を飛ばす事もできます。 List String stationTrimList = Splitter.on(",").omitEmptyStrings().splitToList(stations); for (String part stationTrimList) { System.out.println("station omit empty = " + part); } 結果は以下になります。 station omit empty = Tokyo station omit empty = Shinagawa station omit empty = Nagoya station omit empty = Osaka
https://w.atwiki.jp/kata-niho/pages/440.html
原語 social 和訳 その他の品詞 社会、公共、 公 (おおやけ／こう)、公衆、社交、一般、世間、巷、 世 (よ)、世俗 漢字一字 公、世、俗、巷 やまとことば おほやけ（公）、よ（世）、まち（町） 備考欄 辞書 説明 廣辭林新訂版 （無記載） 新訂大言海 （無記載） 角川国語辞典新版 （無記載） 大英和辭典 〔形〕［一］社會ノ,社會ニ關スル,社會上ノ,社會的.［二］交際好キノ,交際上手ノ,社交ガウマイ,社交的.［三］社交上ノ,社交ノ,社交ニ適スル,社交的ノ.［四］社會ヲナス,社會的,社交的.［五］【動】①群居的,群棲的.②群體ヲナス.［六］【植】叢生ノ.［七］【繼受ろーま法】團體ノ,會社ノ. 同義等式 原語単位 social＝公共 カタカナ語単位 ソーシャル＝公共 附箋：S ソ 英語
https://w.atwiki.jp/seasartaro/pages/86.html
あるクラスのオブジェクトのリストを別のクラスのリストに変換する、 FluentIterable.transformメソッドのサンプルコードです。 変換前のクラスとしてFluentIterable.filterメソッドの紹介で使ったWarriorクラスを再度使用します。 class Warrior { public Warrior(String name, Integer hp, Long exp){ this.name = name; this.hp = hp; this.exp = exp; } public String name; public Integer hp; public Long exp; } 変換後のクラスで以下を使用します。 class RedMage { public String name; public Integer hp; public Integer mp; public Long exp; } Warriorと比べるとmpというメンバ変数が追加されています。 変換処理を定義するため、3章で紹介したFunctionクラスを以下の通り実装します。 class JobChange implements Function Warrior, RedMage { @Override public RedMage apply(Warrior warrior) { RedMage mage = new RedMage(); mage.name = warrior.name; mage.hp = warrior.hp / 2; mage.mp = 50 - warrior.hp; mage.exp = warrior.exp; return mage; } } 上記で、WarriorをRedMageに変換しています。その際以下の処理をしています。 hpを半分にする。 50からhpを引いた数値をmpとする。 テストコードは以下になります。 Warrior w1 = new Warrior("bartz", 30, 123L); Warrior w2 = new Warrior("lenna", 10, 123L); Warrior w3 = new Warrior("faris", 20, 123L); Warrior w4 = new Warrior("galuf", 40, 123L); List Warrior warriorList = Lists.newArrayList(w1, w2, w3, w4); Iterable RedMage transformedList = FluentIterable.from(warriorList).transform(new JobChange()).toList(); for(RedMage mage transformedList) { System.out.println("name = " + mage.name + ", hp = " + mage.hp + ", mp = " + mage.mp); } fromに変換したいWarriorのリストを設定し、transform1に変換の定義を設定し、さらにtoList()とすることで、 結果リストを取得しています。 出力した結果は以下になります。 name = bartz, hp = 15, mp = 20 name = lenna, hp = 5, mp = 40 name = faris, hp = 10, mp = 30 name = galuf, hp = 20, mp = 10 hpとmpが変換された新しいクラスのリストが作られた事が確認できました。
https://w.atwiki.jp/seasartaro/pages/61.html
カリー化ですが、カリー化についてのWikipediaがあります。 ...最初は意味が分からなかったです。 あと、「カリー化 メリット」とかでググったページを見たのですが現時点でも完全な理解はしていないようです。 まずはScalaでどう実現できているかを頭に入れてからみた方が良いかと。 コップ本ではカリー化の説明として、クロージャを使って関数を分割しています。 以下が宣言です。 scala def curry(x Int)(y Int) = x + y; curry (x Int)(y Int)Int クロージャのやり方で、最初に部分的に値を入れます。xが1を持つよう値を入れてみました。 二番目の引数がある場合、プレイスホルダーの_を入れないとエラーになります。 scala val curry2 = curry(1)_ curry2 Int = Int = function1 残りの引数yを入れて出力させます。 scala println(curry2(2)) 3 1 + 2 = 3で3が出力されています。 次に発展系として、引数三つの関数のカリー化に挑戦しようと思います。 def curry2(x Int)(y Int)(z Int) = x + y * z; 一つ目の引数に1を与えてみます。プレイスホルダーは_一つです。 yとzでプレイスホルダーを2つ付けるのではと一瞬思う人も居るかもしれませんが、一つです。 val curry02 = curry2(1)_; 残りの引数を与えて出力させてみます。 println(curry02(2)(3)) 以下が出力です。 7 1 + 2 * 3で7という想定通りの結果が出力されました。
https://w.atwiki.jp/seasartaro/pages/34.html
条件を指定せず、全てのドキュメントを取得します。 public final void findDoc2() { Mongo conn = null; try { conn = new Mongo("localhost", 27017); } catch (Exception e) { e.printStackTrace(); } WriteConcern wc = new WriteConcern(1, 2000); conn.setWriteConcern(wc); DB db = conn.getDB("blog_app"); DBCollection coll = db.getCollection("users"); DBCursor cursor = coll.find(); System.out.println("count = " + cursor.count()); while (cursor.hasNext()) { BasicDBObject obj = (BasicDBObject)cursor.next(); System.out.println(obj.toString()); } } 結果出力は以下になります。 { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d0"} , "name" "user-0" , "team" 0.0 , "score" 24.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d1"} , "name" "user-1" , "team" 1.0 , "score" 38.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d2"} , "name" "user-2" , "team" 2.0 , "score" 26.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d3"} , "name" "user-3" , "team" 0.0 , "score" 82.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d4"} , "name" "user-4" , "team" 1.0 , "score" 79.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d5"} , "name" "user-5" , "team" 2.0 , "score" 43.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d6"} , "name" "user-6" , "team" 0.0 , "score" 79.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d7"} , "name" "user-7" , "team" 1.0 , "score" 93.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d8"} , "name" "user-8" , "team" 2.0 , "score" 14.0} { "_id" { "$oid" "5184c79dc401ef5c9cf0f8d9"} , "name" "user-9" , "team" 0.0 , "score" 22.0}
https://w.atwiki.jp/seasartaro/pages/74.html
Objectsには変数がnullの場合の処理を簡単に記述できるメソッドがあります。 変数の型は何でもかまいません。 以下、例として文字列が変数に格納されている場合はその文字を、変数がnullだった場合はnullを表す文字列を格納する処理を書いてみます。 String str1 = "apple"; String str2 = null; if (str1 == null) { str1 = "value is null"; } if (str2 == null) { str2 = "value is null"; } System.out.println("str1 = " + str1 + ", str2 = " + str2); 結果は以下になります。 str1 = apple, str2 = value is null これをguavaで実装してみます。 String str1 = "apple"; String str2 = null; str1 = Objects.firstNonNull(str1, "value is null"); str2 = Objects.firstNonNull(str2, "value is null"); System.out.println("str1 = " + str1 + ", str2 = " + str2); 結果は以下になります。 str1 = apple, str2 = value is null こちらの方がif文がなくなり、すっきりしました。 注意として、第一引数と第二引数が両方ともnullの場合NullPointerExceptionが発生します。