  |
はてなキーワード: 例外処理とは
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
とりあえず、近場にいる色んな夫婦の生活を密かに観察してみることにした。
「離婚しちゃったのか」
捜索開始から、いきなり出鼻をくじかれた。
だがシロクロは意外にも喜んでいる。
自信満々にそう言ったシロクロを見ながら、俺たちはため息を吐いた。
「タオナケの言うとおりだ。その結論だと、離婚するために結婚していることになってしまう」
「シロクロには難しい話かもしれないけど、離婚ってのはしないに越したことはないものだから。そんなものをゴールに据える位なら、最初から結婚なんてしなければいいって話になっちゃう」
「つまりシロクロの結論は破綻しているってこと。それに結婚した後の生活もあるなら、離婚したってその後の生活もあるだろ。だから離婚はゴールじゃないよ」
「うーん、それもそうか」
ミミセンの話をシロクロが理解できたとは思えないが、納得はしているようだ。
「次だ！ 次いってみよう！」
====
「あそこの人たち」
「いわゆるホームレスってやつだね」
「私、聞いたことがあるんだけど、ああいう人たちを“人生終わってる”とか言ってる人もいるらしいわ」
生きているのに人生終わってるって、よっぽどのことだ。
「そうか、つまりアレがゴールだ！」
「うーん、でも皆がみんなああいった風になるわけじゃないでしょ」
それもそうか。
一見すると人生終わっているように見えるが、あれでも生きていることには変わらない。
ホームレスが例外処理できれば、ここで結論を出してしまってもよかったのになあ。
「……ひょっとして、ゴールなんてないんじゃないかな」
こういう時、割と核心をついたことを言うのがドッペルだ。
俺も何だかそんな気はしていた。
その気持ちはみんな同じだった。
けど、いつまでも見えそうで見えないゴールラインに、みんなヤキモキしていたんだ。
「そんなこと言っても、こんなに探しているのに、まるで見つからないじゃないか」
「ゴールのないレースなんて走りたくない！」
「シロクロ、僕たちはレースの話なんてしていないよ」
だが、意外にも一理ある考えだ。
シロクロは何も考えずに言ったのかもしれないが。
ゴールもなしに人は走り続けられない。
ペース配分できないからな。
「うーん……」
この時の俺たちはさしずめランナーズハイで、いつまでも走れるような心地だった。
だがそれは、そう遠くないうちに息切れすることを意味していた。
それまでに、何とか結論を欲しい。
====
「なんか、あそこ騒ぎが大きくなってるな」
ホームレスの溜まり場で、やたらと人が集まっている場所があった。
変装が得意なドッペルに様子を見てもらう。
服をどこで用意していたかは知らないが、たちまち風景に馴染んだ見た目になる。
しばらくすると、俺たちが思っていた以上の成果報告をもって帰ってきた。
「……どうやらホームレスの人が誰か死んだらしい。原因は分からないけれども」
死。
「となると、ゴールは死ぬってことか」
「うーん、確かにもう先はなさそうだよね」
「それとも天国とか地獄とかが実在するなら、死ぬこともゴールじゃないのかな」
「とは言っても、それは実在するか分からないしなあ。それに、もし輪廻転生とかいうのがあったりしたら、ゴールどころかスタートに戻ってるよ」
「うーん……」
俺たちは走る体力も気力もなくなっていたんだ。
皆でしばらく唸っていると、ドッペルが何かに気づいたそぶりを見せる。
自信はなさそうで、恐る恐るその可能性を口にした。
「……なんだか“ゴール”って、候補含めてロクなものじゃないよね」
発想の転換に感動した一同は、まさに答えを見つけたといわんばかりに喜ぶ。
実際は何も導けていないんだけど。
「なるほど。そう考えると、結婚をゴール扱いされるのは確かに不服かもしれない」
「私、女だけど、その考えに賛成するわ」
「カンコン！ ソウサイ！」
皆も迎合する。
「きっと、このまま探し続けても有るかどうかすら分からないし、あったとしてロクなものじゃないよ。そんなものを無理して暴いても、誰も得しない」
こうして、俺たちのゴール探しは、ゴールかどうかはともかく終着には向かったのである。
VBAわかりますけど（キリッ）みたいな人が作ったマクロを直すのが苦痛すぎる。
なんでもエクセルでやろうとすんな。
マスタのデータをエクセルに貼り付けたものをつかってVBA組むな。
変数はご丁寧に一番先頭で宣言祭り、コントロールの名前が連番、無意味な処理、データの件数を取得するためだけに同じSQLをCOUNTにして実行、無意味なループに、ifの4段ネスト、メソッド名が不適切（checkXXX）、スコープは全部Public、定数の概念無し（マジックナンバー多すぎ問題）、型変換の概念無し（文字列を数字にぶっこむ）、例外処理なし、その他突っ込みどころ多数
オブジェクト指向なにそれおいしいの状態のコードがどんどん増えていく。
そこは残業も土日出勤もあるところで、保育園の子供がいると無理ということで、
復職するときは事務課みたいなところに配属されることになった。
会社って縁の下でこういう仕事する人がいて成り立っているんだなーと、今まで知らなかった仕組みを知ることが出来たし、
学生の時に暇つぶしで資格をとった簿記が今更ながら役に立ったのもうれしかった。
でも、正直つらい。
今の仕事は種類が多く、その上量も多い。手順は複雑で、１つでも飛ばしたり順番を間違えたりするとものすごく怒られる。
覚えても覚えても次から次へと新しい種類が出てくる。
少しでもミスを減らそうと、自分で判断フローチャートを作ってみたが、いちいち当てはめて判断していると人の３倍は時間がかかる。しかも、毎日のように新しい例外処理が出てきて、そのたびに新しく書き足したフローチャートは無駄にどんどん長くなっていく。そしてなぜかミスは減らない。
残業がない課という話だったのに、定時では全く終わらず毎日残業していて、保育園の延長料金が家計を圧迫している。
前のイベント企画課の時は、ボーナスの査定も上だったし、普通は偉くならないともらえない表彰状を最年少でもらったこともある。
ちなみに１２月のボーナスは、今まで見たこともない低評価だった。つらい。おかげで育休中の家計の赤字も補てんできず、子供の学費もほとんど貯金できなかった。
普段の給料は半分が保育料で消えるので、ボーナスだけが貯金のチャンスだったのに。つらい。
前の課に戻りたい。でも保育園は１９時までしか延長できないし、土日はやってない。
なぜライジングサンコーポレーションのSEってのはプログラマーに対して、仕様書に書いていない事をやらせるのか？
仕様書に記載していなかった事を作りこんでいなかったら、不具合扱いされた。
いや、書いてある事を実現出来なかったらそれは不具合と認めるよ。
「書いていない」というと「常識だろ」と言われる。あんたらの製品の常識かもしれないが、こっちには常識では無い。
ましてや、全てを底辺プログラマーのせいにして、なんとかという精神的追い詰め会議に呼び出すのはどういう事か？？？
それでも、「書いてくれ」と言い続けると、「全てを網羅出来ない」と開き直る精神がすごい。
なら「こちらも全てのエラー処理例外処理等を網羅出来ない」と言い返すのはタブーである。ここまで言うと、ライジングサンコーポレーションのエライ人達はキレる。
品質向上プロジェクトとかあるようだが、プログラマーをいびる事で品質が上がると思っていたら大間違いだ。
君たちのその開き直りを直す方が先ではないかね？
大企業のシステムエンジニアは目の前の膨大なコードの前に立ち尽くし、いかに事故を起こさずに今回の客の要求だけを反映するか四苦八苦し、実装後はただ逃げ切る日を夢見る。俺の腐れ上司もちょこちょこっとシステム修正しオフラインで活躍し……ああつまり飲み会やゴルフで部長に媚びへつらい別の部署へ逃げ切っていった。
そうして俺の直上司は誰もいなくなり、一人か二人の学生上がりＰＧをメンバにもった俺が今度は修正をする番になる。
要求を読む。結構無茶な要求だが、敵はそれだけじゃない。コードが正ならコードを読めばいい。ただこの腐れ切ったコードが本当に正しいとは限らない。
俺は更新履歴の腐れ切ったワードの仕様書を開く。誤字脱字のオンパレード。例外処理云々といった赤字が散見されつぎはぎだらけのゾンビーになっているのがわかる。
腐れ切ったコードと腐れ切った仕様書。この仕様書の記載をしたのはファイルの更新日からすると二代前の部長だ。当時を思い出す。あの異常なスケジュール下でいいかげんな部長が変更仕様を仕込むとすれば、まずここの影響範囲の見込みを漏らすだろう。しかも高圧的な得意先だ。タフな交渉術を持たない部長のことだから得意先の負荷が高いインのテストパターンは申し入れしなかっただろう。ここも危ない。ああ、こっちもヤバそうだ。
そうやって前任者を想像しながら仕様書を読み込んでいくと、そこここに前任者のゴーストを読み取ることができる。俺はこいつをぶち殺すのが好きだ。まるで前任者自身をぶち殺せるかのような錯覚に陥る。
仕様書を生まれ変わらせる。そしてコードを生まれ変わらせる。腐れた部分をぶち殺す。このときの感覚を俺はエンジニアズハイと呼んでるが、この業界、多かれ少なかれみんな似たような体験をしたことがあると思う。
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
議論していて、とても板がみずらいので。
こちらをお借りします。
269 ：（´ー｀）y─┛~~ ◆UxQ8uxJMok：2014/05/31(土) 20:12:01.17 発信元:123.225.138.170
> 全てこちらの論証通りとさせていただくだけですので、
> 私としては問題ございません。
オマエが真似れば殺しに行くだけだからこっちも問題ない。
という訳で、上記のとおり、
下記論証で解決いたしました。
連番召還ではないですが、「場札を出す処理に連番の条件を要す」に該当。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
> 「場札を出す処理に連番の条件を要す」に該当。
との反論がありましたが、
連番とは
複数の番号が連続していること。また、その番号。
とのことですので、１に対する２、２に対する１も連番となります。
２つ以上の整数があれば成り立つ形式ですね。
何をですか？
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
こんな初歩的な質問が来るとは……侮っておりました。
基本的に、「デッキが０枚なら敗北する」というルールエフェクトも
「山札が尽きたときに自動誘発する効果」なのですが、多分聞き入れられませんので具体例を。
Laboratory Maniac / 研究室の偏執狂 (２)(青)
クリーチャー — 人間(Human) ウィザード(Wizard)
あなたのライブラリーにカードが無いときにあなたがカードを引く場合、代わりにあなたはこのゲームに勝利する。
2/2
万が一の保険
[部分編集]
OPERATION
O-73 青 1-3-0 R
CHARACTER(UNIT)
CH-S29 白 2-3-1 R
【(自動A)：自軍本国が0枚になっても、自軍プレイヤーは敗北しない】
【(自動D)：ターン終了時に自軍本国が0枚である場合、そのターンの終了直後、自軍プレイヤーの新たなターンを開始する。新たなターンの終了時、自軍プレイヤーは敗北する】
「山札がつきた際に自動誘発する効果」とやらを具体的に提示してみました。
破壊するって書いてある：それも含めての誘発効果です。「コストの支払い」は行われません。
速度と戦闘力は反比例しない、凄い速度は威力に等しいので前提が崩壊しています。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
すごい！超時空会話が出来ました！
まず、その「当該ゲームシステムについての記述」とやらを具体的に提示できねば反論として破綻。
手札の定義をしてください。
まさか、全てのゲームに手札があると思っているわけではないですよね？
私ですらゲームをつくる際には「このゲームは～～を手札とします」という定義を行います。
ちなみに「最初に選んだ手持ち札」という前提であれば、金色のガッシュベルTCGの魔本でやっています。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
デッキの１枚目と２枚目が手札になる仕様というだけで……「任意に選択できる」のですが。
あれ？ なにか私分かり難いこと言いました……？
一応、ポケットモンスターカクメン列伝という、手札を全て任意に選べるものもありますから、
そういう方向性を話した方がよかったのですかね？
手札の定義をしてください。
ボードゲームとかでは、場にある３枚のカードから好きなのを手札に移していいよ、とか良くありますね。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
◆UxQ8uxJMok ：2014/05/30(金) 23:40:05.89 ID:mGswB6A1
の記載にて反論が認められませんでした。
優先権は元々細分化されているので、そもそも論理が成り立っていないかと……。
ttp://mtgwiki.com/wiki/%E5%84%AA%E5%85%88%E6%A8%A9
ちなみに、この項目がTCGに限っていないので、TRPGやウォーゲームなどでは乱戦処理などで
「標的を指定できない限定的な行使の権利」や遠距離攻撃の一方的に「標的を指定する権利」がありますね。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
↑パクリの兆候を感じた段階で、裏取りせず下記の警告文が送られ、そのトレーディング・カード・ゲーム制作者は～。
↑実物カードゲームhttp://ai.2ch.net/test/read.cgi/entrance2/1395426290/の～。 カードゲームに限定ね。 ほぃ、論破完了ｗｗ
すごい行間を読むと、確かにそうなっているみたいですね、難しいですが。
上記優先権に関しての記載にて反論が認められませんでした。
遊技王の優先権の処理は必然的にこうなるようになってませんでしたか？
ttp://yugioh-wiki.net/index.php?%CD%A5%C0%E8%B8%A2=
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
それであれば、「特に本校に記載されている"特別な許諾行為"を行わずとも"当該行為と同様の処理は行うことができる"」ということですね。
特許権にあります「有用な発明」項目の独自性に含まれないため、特許権としての効力を失います。
もし、「相手に干渉しない場合の行動は続けられる」という場合では他カードゲームよりも優位性はないので、
「有用な発明」項目の独自性に含まれないため、特許権としての効力を失います。
その昔、実際のTCGとして出たアルテイルにはAgi(素早さ)の処理がありました。
どちらのターンであれAgi順に優先権が決定していたと思います。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
> 「クルセイド」には
攻撃順序の判定ではありません、上記に記載した通り「優先権」を得ます。
「移動、待機、スキル使用、攻撃の判定を能動的に宣言できるタイミング」である「優先権」を得ることが出来るのです。
「優先権を持っているプレイヤーが全ての行動ができる」とは限りませんので、覚えておくとよいですよ。
トイレのドアを開けたまま用をたす癖がついちゃってさ～。って言ってわかる？
やあ、当方東京在住30代後半同期入社職場結婚共働住居賃貸男女２児保育園在籍痔主歴15年です。
http://anond.hatelabo.jp/20131130161624
↑に書いたアレコレの一日のフロー＋例外処理は単なる事務処理みたいなもんです。
育児が辛いとも楽しいとも一切書いてないのに何故か子供を愛してないと書かれる不思議。
コーラを飲んだらゲップが出るでしょ？それとコーラが美味いか関係あんのか？無いだろ！？
愛情かけたら子供の熱が治るの？糞まみれの衣類が綺麗になんの？って話ですわ。
まともに子育てに取り組んだ方々からは「それってふつーだよね」ってブコメを頂いていま
すが、そのとおりであほみたいに余裕が無く見える保育園育児だけど、あそこに書いたこと
って保育園に通わせてる親だったらほぼ皆、普通にこなしてることだから我々夫妻が特殊と
いう事では無い。（妻のみが担当している家庭も多々あるが。）
当たり前の育児を読んだだけなのに「ドヤ顔で忙しいアピールうざい」みたいなコメントは最も
んで、もっと工夫して楽すれば？というご意見について書ききれなかった実践している（し
た）事を以下に述べる。
・結婚直後
・妊娠中
0歳時以外の保育園入園は倍率が非常に高く困難であることを調査。翌4月で保育園入園の
方向で決心。（公立保育園は例外以外は4月以外入園出来ない。これ超重有。）
夫も子供の面倒をみれるよう母乳とミルクの混合で栄養を与えることとする。
これにより、夜泣き時や妻寝不足や体調不良時に母乳が出ないから夫には手出しは出来な
いという状況を回避。
・住居
諸事情で当初住まいを引っ越す際に賃貸のメリットを活かし妻実家～保育園の中間地点へ
移動。
あくまで予備としてのみ活用。
急な発熱時。どうしても行って欲しい通院等予備的に月に１・２度は妻母の出番となる。
・食洗機
当然使用。
正直我が園はどの家庭も忙しい。よって飲み会などは少なめと思われるが、開催された
場合は常に夫妻同時出席。
・食事
保育園で出されるバランス栄養食品に便り、正直手抜き気味。特に夫の作る料理はコメ・
肉（OR魚）・作りおきの何か・味噌汁（スープ）・果物。的なものが多い。
・第二子妊娠計画
前回の反省を活かし4月～夏頃の出産を計画（赤子の時間を長時間育児休暇する為）。
子作りを前年夏以後に実施。
計画通り夏前に出産。翌4月に0歳時で入園成功。（第一子がいると二人目の子供は同一保
予定が計画され次第相手に通告。相手の日程が空いていれば機械的に参加可能となる。
何がいいって言うと、育児を大きなストレスに感じる事が無く楽しむ事が出来る。
（もちろん子供にイラッとする事はしょっちゅうだがあくまで一時的な話。）
・一日中子供の世話をしなくていい（デメリットとして、初めてしゃべった。初めて歩い
・通勤時等に会話出来ており、自分の時間が足りないので、夜・休日などにパートナーに
話を効いて欲しい等、思うことは無く自分の時間も少しは使える。
・仕事トラブル発生時等に社内インフラメール等で即時相手に連絡・バトンタッチ出来る。
・相手が昼間なにやってるか気にならない。
もちろんこれらはパートナーとの関係性にや子供の性格や仕事のストレス度等様々な要因が
からむので一概にはいえないのは当たり前であるが、少なくとも我々夫妻は共働きしてい
る事で子供を愛していないという事は一欠片も無く、むしろストレス少なく子育てをエンジョイ
していると自信を持って言える。
