  |
はてなキーワード: 整数とは
「ランダムな整数がランダムな個数引数に渡されて、それらを添字順にひとつずつ足して行き、５０を超えたらそれまでの配列の中身を返す」みたいなのってどうやって書くんだろう。
手続き的に書くなら
var randoms = [10, 20, 1, 6, 8, 0, 0, 0, 20, 10];
var total = 0;
for (var i = 0, len = randoms.length; i < len; i++) {
total += randoms[i];
}
return randoms.slice(0, i);
みたいな感じですぐ思いつくんだけど、純粋な関数型って変数も許してないしこういうやつは reduce するんでしょ。
まったくわからない。できないんだとしたら何が優れてるんだ。
もちろん、関数型的に each とか map とかすると見やすくなるケースが多いのはわかってるけど。
できること、できないこと、そういうのがあるから結局マルチパラダイムな言語でいい感じに取捨選択してねーってことなのかなあ。
議論していて、とても板がみずらいので。
こちらをお借りします。
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
> 「クルセイド」には
攻撃順序の判定ではありません、上記に記載した通り「優先権」を得ます。
「移動、待機、スキル使用、攻撃の判定を能動的に宣言できるタイミング」である「優先権」を得ることが出来るのです。
「優先権を持っているプレイヤーが全ての行動ができる」とは限りませんので、覚えておくとよいですよ。
http://anond.hatelabo.jp/20140506144603
これだけのものを「ちゃんと」読めば、そりゃあなんとかなるでしょう。
しかし、何万円になるんだ。
しかも、離婚は結婚生活の破綻だけど、離婚しなかったからといって幸せとは限らんよな
配偶者が嫌だのうざいだの死んでほしいだの、四六時中言ってる人はリアルでもネットでもまったく珍しくない
多少多めに見積もって、半分ぐらいは共同生活の運営に失敗してるのではないか
で、考えると、「自分の意思で結婚を選択し、維持し続ける」って割と難しい行為だよな
家事やら、子育てやらを単純に「労働」とみて、生活費の配分を「利益分配」と捉えて個人としての経済的利益を大きくしようとすると
「いかに相手にやらせるか」「いかにして相手から分捕るか」って話になる
結婚だけじゃなく、あらゆる共同作業でありうる話だけど、ただ乗りしてくる奴にペナルティは必要
会社みたいに全く働かない奴はある程度排除できれば問題ないけど、結婚の場合はその時点で破綻する
だからあらかじめ、「自分の負担を最小にしよう」ではなく、「なるべく平等にコスト負担しよう」という
合意形成が必要ってのは、一見明らかな気がするけど、これって実はかなり難しい
家事等を全部半々にすればいいじゃん、という人も居るけど、どれくらい家庭の外で労働してるかは違うから
客観的に見て「これが平等な労働配分」ってのは定義しづらい。それこそ「家事労働は年収一千万」なんていう人も出てくる
そうするとどうなるかというと、交渉と駆け引きの問題になる
ゼロサムだから自分の利益主張するほど破綻につながる。だから、結婚を維持したいと思ってる側が「不利」になり、破綻してもいいかと思ってる側が「有利」という話になる
お互いの能力や結婚維持した気持ちが拮抗してればいいけど、差が出ると年収800万で小遣い1万の哀れなおっさんやらが誕生するわけだ
超単純モデルで考えると、破綻したり、一方が大損したりすることを排除できないどころか誘発するシステムとわかる
とはいえ、結婚生活終わらせるのもコストがかかるのは事実。これをでかくすれば破綻しないわな
まず社会が支払わせるコスト。裁判所は結婚の破綻の原因と認定した方に相手への賠償金払わせる上
離婚者はバツn(nは1以上の整数で離婚経験回数)という不名誉なレッテル貼られて、再婚しにくくなり、煩い親戚にゴチャゴチャ言われるわけだ
前者に関しては必ずしもデメリットにならんし（むしろ利益になることもあるので、これ自体が破綻リスク高めることも）
後者に関しては、バツnの人々が増えるにつれて社会圧力は弱まっていく傾向にある。今後もそうなるだろう
親権もった方は再婚しない限りシングルで育てなきゃならんし、そうじゃないほうも養育費がかかる
配偶者に何の情もなくても子供への悪影響や偏見を心配して離婚しない場合も多々ある。血縁関係は結婚と違って解消できないしね
しかしこのコストも将来的には減少していくのではないかと思われる
子供への偏見に関しては絶対数の増大にともなって漸減するだろうし、社会福祉も（どうなるかは確定ではないが）長期スパンでみれば拡大するだろう
欧州の国をみならって結婚制度改革！事実婚の権利増進！なんて流れもあるし、すくなくとも今後50年は離婚しやすい方向に進むだろう
なんかどこかで聞いたような話を書いてきたけど
的に一部ブコメ民に総括されそうな気がする。だが、そういう「理想的な結婚」はますます減っていくのではないかと思う
なぜなら、そういう価値観を持った人間は「不利」だからである。
「互いを尊重」するには前提として相手に尊重してもらうことが必要だ。離婚に抵抗がなく、自分の利益を求める人間はますます増えていくであろうから
そのような理想的な相手とマッチングするのは難しい。仮にうまくいっても、その子供が同じ価値観をもって結婚に臨むとまた同じ難しさがある
こうして考えると、そういう理想をもった人間は淘汰されやすく、「自分の利益が大事。場合によっては即離婚オッケー」派がどんどん増えていく結果となる
ますます「互いを尊重する」結婚は難しく高コストになり、そういった価値観を持つ人間はそもそも結婚をしようとすらしなくなる
こういった流れになるのではないか
こういう予測のもと、どういった制度変更が可能なのか妄想してみる
そもそも結婚維持なんていらんかったんや。子供うまれりゃオッケーオッケー。独身者にもその分課税な
人間の性欲はなくならないし、破綻コスト下げまくれば参入者は増える。
実は現実的かも。北欧モデル的？いったん定着すればまず後戻りはしない・できないだろう
発想は前時代的だが、なぜかSFチック。まあ今世紀中にはないと思うが
去年ネットの預言者がこういってた。なんでも2012年末にアセンションがくるようですな
あれ？今年って西暦何年だっけか？
ありそう。人口減少への道のような気がしなくもないが、別にそうなると決まったわけじゃなし
というか人口減少してるのって恋愛してない若者と、キモオタの増加のせいだよね。人類から活力を奪う風俗店とアニメとエロゲを規制しすれば解決！そもそも日本人たるもの国力増強のため（略
次の文を読んで、あとの問いに答えなさい。ただし、組み換え価（％）は
ある生物において、遺伝子Ａ、Ｂ、Ｄはそれぞれa, b, dに対して優性であるとする。
遺伝子型がＡＡＡＢＢの個体とａａｂｂの個体とを交雑したところ、Ｆ１はすべて
〔ＡＢ〕であった。続いて、このＦ１を（①ａａｂｂの個体と交雑）したところ、
（②その子には〔ＡＢ〕：〔Ａｂ〕：〔ａＢ〕：〔ａｂ〕が６：１：１：６の比で生じた。）
次に遺伝子型がＡＡｄｄの個体とａａＤＤの個体とを交雑したところＦ１は
（③〔ＡＤ〕：〔Ａｄ〕：〔ａＤ〕：〔ａｄ〕が２０１：９９：９９：１の比で生じた。）
１．（ ）①のような交雑を何と呼ぶか答えなさい。
２．次の文中の（ア）～（オ）に入る適切な語句や数値を書きなさい。
上の結果は、メンデルの（ ア ）の法則にしたがっていない。すなわち、
遺伝子のＡとＢ、ａとｂはそれぞれ連鎖していることがわかる。ところが、その連鎖は
不完全で、減数分裂第（ イ ）分裂の（ ウ ）期に、相同染色体間で（ エ ）が
起こり、その結果として、遺伝子の組み換えが（ オ ）％の率でおこったと推定することが
できる。
３．（ ）②の個体のうち、遺伝子の組み換えによって生じた個体の遺伝子型をすべて書きなさい。
４．このＦ１からＦ２をつくると、その表現型とその分離比はどのようになるか答えなさい。
５．（ ）③より、遺伝子Ａ－ｄ間の組み換え価（％）を求めなさい。
６．別の実験で遺伝子Ｂ－ｄの組み換え価を求めると、４％であった。
Ａ,Ｂ，Ｄ（ａ，ｂ，ｄ）３つの遺伝子の総体的な位置と、相対的な距離を
図示しなさい（遺伝子Ａはすでに解答欄に記入してある）。
プログラム:定義づけられた物事を進めていく妥当な手順・方法の決定、および物事・手順・方法の記述書
(コンピューター)プログラミング:コンピューターが進めていく物事を定義し、妥当な手順・方法を決定し、記述すること。
プログラミング = デザイニング union コーディング;
デザイニング:進めていく物事を定義し、妥当な手順・方法を決定すること。
コーディング:コンピューターが進めていく定義づけられた物事の決定された妥当な手順・方法を、記述すること。
CD(コーダー):コーディングする人。プログラマーとは限らない。
SE(システムス エンジニア):進めていくべき物事を定義する人。プログラマーとは限らない。
PM(プロジェクト マネージャー):(プログラマー)プログラマー。(コンピューター)プログラマーとは限らない。
※日本のソフトウェア業界ではSEが定義した物事を、何の工夫も無くそのまま記述するCDという体制となっている。
つまり「物事を進めていく手順・方法」が余りにも稚拙で、PGと呼べるSEやCDが居ない。
※「物事を進めていく手順・方法」の巧拙の例としては、
PG: (初項 + 最終項) x 項数 /2
というように、例えば巧拙の差は「上手い・エレガントな方法・アルゴリズム」だったりします。
・継続的に勉強できない(1週間で最低10時間は、何があっても勉強しましょう)
・論文・学術書が読めない。(コードはお堅い理論的に筋道立った文章の極致の一つです)
・100ページくらいなら一晩で修得してやろうという気合いが無い(一晩で仕様書読み込んで次の日から活かす必要があったりします)
・仕事のやり方に疑問を抱かない(楽するためにはどんな苦労も厭わず、常に最善を考えましょう)
・いつかはマネジメントをしたい(人を使うよりも、プログラム組んで仕事させた方が、安くて速くて正確ですよ)
※(笑)なマネジメント:下僕に進捗という数字を報告させて、自分の握っている進捗管理という方眼紙のマス目を埋める作業。
自身の雇い主にマス目の埋まり具合を報告する作業。
※ここで以下の1~4を6ヶ月がんばっても挫折する方は、「一山いくらのコーダー」にしかなれない可能性が高いため、
しがみついてしまうと、真っ当な技術者の足を引っ張ることになります。
・逐次実行、条件分岐、反復実行
・ポインタ ※最近、情報学科のくせに学部でポインタを教えない大学があり、そういうところは真っ当な大学ではございません。
1)O'REILLYの[amazon:C++実践プログラミング]を最初の「ポインタ」まで読んでください。
2)C++の実行環境をC99で整えてください。(環境の準備は自分で面倒を見てください)
3)ポインタを用いて、文字のLinkedListクラスを実装してください。
※LinkedListとは以下の仕様を満たすクラスとします。(C++でJavaのLinkedListを実装)
http://docs.oracle.com/javase/jp/6/api/java/util/LinkedList.html
4)LinkedListの入れ子でTree構造をつくり、再帰を用いて、全要素をコンソール出力するプログラムを作ってください。
5)4)をクリア出来た人は、この本を1年以内に全部読んでください。
ただし、C++は複雑怪奇な言語のため、これ以降は知識レベルの修得で構いません。
私は中3の時、STLやBoostどころかbooleanの無い時にこの本を9ヶ月で読んでおります。
※私が面接に出る場合は、当該内容のLinkedListやQuickSortの概要を直ぐさま説明できる人は、可能性有りと○を出します。
面接で「LinkedListを勉強してきました、直ぐさま説明できます」といって、「そんなの出来て当たり前だ」と言ってくれる会社は殆どございません。
大抵はポカーンとして意味不明という顔をする文系人事だったり、「そんな技能必要ない」というところが殆どです。
逆に「できて当然」と言ってくれる会社は、技術をしっかり学べる可能性大です。
★ここまでクリアした方は、「入門者」と呼んで差し支えございません。次は「初級者」への挑戦です。
※初級者になるためからは、べらぼうに学ぶべきことが広がります。
燎原の火のごとく。
※筆者の立場
Joelさんの「Javaスクールの危険」に賛同するので、ポインタ優先ということで。
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
たとえ動的型付けでも整数と文字列は足せないわけで、結局型がないわけではない。そう言った意味で、動的型付けの恩恵を得るには暗黙の型変換が必要不可欠だ。またダックタイピングによって関数へ適用できる型が静的な言語より広いことが多い。そう考えると動的型付けのパワーは、関数に渡せる値が幅広いおかげで以下の2つのご利益があることだと思う。
動的型付けをする言語では、ほとんどのものを文字列や、汎用のリスト型や辞書型のまま表現することが多い。これに対し、静的な型付けをする言語では専用の型をどんどん用意し、それらの型を変換する関数を用意しておく。型が多ければ多いほど、関数は部分関数から全域関数へと近づく。つまり不具合は減る。よって、静的な型付けをする言語で正しく型を設計することで不具合を減らすことができる。
しかし、その分型を明示的に正しく変換する必要がある。IPアドレス型、HTTPヘッダ型、Cookie型、ファイル型・・・様々な型をそれぞれ正しい記述で書く必要がある。対して動的な型付けの言語ではこれらを文字列や辞書型のまま扱う傾向が強いので、それっぽい文字列やそれっぽい辞書をマニュアルなしで組み立てて関数に渡すことができるので、開発工数が低い可能性がある。
もっとも、IDEが優秀であれば型変換する関数を正しく予測してくれるのかもしれない。ので、型変換するコードを瞬時に書ける程度優秀なIDEがあれば不具合が少なくて済む分静的型付けの方がいいし、そういうIDEがないのであれば文字列や基本型だけの知識でどんどん書ける動的型付けに軍配があると言えるんじゃなかろうか。
不具合のないプログラムを書くのであれば、動的型付けでも静的型付けでも生産性は一緒な気がする。むしろ静的型付けの方が不具合が入り込む余地がもともと少ない分生産性は高くなるだろう。多くの人が認める通り、不具合のあるプログラムを書くことはプロとしてあるまじき行為で、恥じるべきだ。
しかし、不具合のあるプログラムは世の中に存在しえないもので速攻削除すべき、と考えるのは行き過ぎだ。残念ながら現実は学問や理論の世界とは違う。プログラムが以下の条件を満たす場合、不具合があってもなくてもいいので、とにかく素早く作ることが求められる。不具合があってもいいのであれば、前述したように少ない知識でも適当に組める動的型付け言語の方が、とりあえず動くまでの期間や人的リソースの調達のしやすさなど、軍配が上がる可能性は高い。不具合のあるプログラムでも許容されるのは以下の場合だ。
3つ目の理由がとにかく大きい。「1日でバグだらけのものを作って動かし始め1ヶ月後にバグをほぼなくす」のと「2週間でほぼバグがないものを作って動かし始める」のとでは、前者の方が金額で言えば後者より倍優れていることになる。バグのある物をお客さんへ提供しているにも関わらず、だ。
もう言わなくても分かると思うが、この条件に当てはまるのがWEBサービスの開発だ。ユーザに多少エラー画面が出ても、ほとんどのユーザはそんなの慣れっこだ。プログラムはサーバにアップロードすれば簡単に修正できる。そんなWEBサービスださい？恥ずかしい？ああ、そうだ。しかし、そんなこと関係なしに、リリースすれば財布にはお金が入ってくるし、しなければお金は入ってこない。
逆にこれらの条件にあてはまらない開発はたくさんある。医療系や金融系は不具合の損失が重大過ぎる。組み込み系やパッケージ系は、製品を売り初めてしまえば修正は困難だ。
そういうことではない。
小学校算数の世界の「掛け算」は整数や実数上の通常の意味での積とは異なる演算なんだよ。
「整数×単位系」という空間上に定義された演算で、単位系の方に「単一単位からなる単位」(集合Aと書く)と、
A×B->Aという演算しか定義されていない(B×A->Aかもしらんがそこは知らない)のが小学校式。
もちろん、そんなしちめんどくさいことしなくても、単位系の代数構造が通常の数上の積演算の構造に従うことを
説明すれば可換性も含めて自明なわけだが、小学校教師の8割くらいは(そのブログの奴と同じように)単純に馬鹿なので
その辺ろくに理解してないし、残りも、特に頭の悪い子に合わせるためにそうしているようだ。
そもそも、国民全員に格安で提供される教育のクオリティなんてそんなもんだろう。
いわゆる「クラスサイズパズル」論争の仕掛け人として、少し補足。
見落とされがちな点であるが、
実際の学級人数が「４０人」「３５人」ピッタリになるケースは、レアだ。
例えば「２年生人数が７１人で、文部科学省の基準だと３５人学級」という場合、
７１÷３５＝２．０３と割り算して「クラス数＝２．０３」とはならない。
切り上げ処理で「３クラス」となる。
この場合、実際の人数は７１÷３＝２３．７、つまり２３人ないし２４人のクラスになってしまうことになる。
そして、この点が最も重要なんだが、
「第二次ベビーブーム時代と比べて、学級当たり人数が減少している今では、
先述のケースで「２０１２年時点の２年生は７１人」の小学校も、
１９７９年時点では「２年生は１４１人」だったかもしれない。
１クラスの人数は１４１÷５＝２８．２人、２８～２９人だ。
２８～２９人のクラスと、２３～２４人のクラスでは、大分違う。
「１学年に４～５クラスが当たり前」だったため、
言い方を変えると、人数の多さで以て「冗長性を確保」していたのだ。
しかし、少子化が進んで、１学年１クラスとか２クラスとかが珍しくなくなると、
３６÷３５＝１．０３、切り上げて２になって、
人数＝３６÷２＝１８になってしまう。
少子化によって、このような「予期せざる少人数学級」が、多数出現してしまうのである。
「１学年１８人」となると、いわゆる秀才、上位層の厚みも少なくなるだろうし、
競争も起こりづらくなる。
マスコミが「４０人学級」「３５人学級」と報道した際、我々は第二次ベビーブーム時のイメージで、
「実際の編成は、３７人だったり、３３人だったりする程度だろ？」と思いがちだが、
学年まるごと少子化現象によって、
「運悪く中途半端な人数だと、２２人とか、１８人とか、想像以上の少人数クラスが出現しかねない」
実は財務省が用意したペーパー
の１０ページに、「２０年前と比較した場合の、実際のクラス人数対比グラフ」が存在していて、
「２５人以下学級」出現比率が増えていることが明らかになっている。
Joel氏の採用面接ゲリラガイドにもあるように、デキる開発者と一緒に仕事をしたいというのは、開発者なら誰でも思うことだ。
そこで、自分が面接する側だったら、初歩の初歩レベル、即ちプロとしてあり得ないレベルの人を足切りするような、くだらない質問を2つ考えてみた。
Java、VB.NET、C/C++、PHP、Perlといったオープン系では広く普及している言語で、ごく普通のPCやサーバで動作するコードを想定し、実装方法を考えてもらうというもの。
ここでポイントとなるのは「プログラムに正解はないが、明らかな間違いはある」という考え方。
つまり2つの質問に対して、明らかに間違った回答をしてきた人が失格ということ。
では上の問いで想定している明らかな間違いは・・・
どっちも教科書でよく見るやり方だけど、仕事でそれやるのは頭悪すぎて話にならないということで。
ちなみにそれぞれの質問で何を見ているか、デキる開発者には一目瞭然だと思うけど、説明すると
結局、コードを書くときに一番大事なのはそういう能力であって、間違っても努力や気合じゃないってこと。
プログラムはclassに記述します。たとえばSampleという名前のclassを作る場合、Sample.csファイル内に次のように書きます。(C#の場合、ファイル名とクラス名は同一でなくても良い。複数のクラスを書いても良い)
public class Sample { }
プログラムはclass内のMainメソッドの先頭から実行されます。Mainメソッドは次のように書きます。
public class Sample { public static void Main( String[] args ) { // 処理を書く } }
Console.WriteLine( "Hello world" );
コメントです。
// 一行コメント /* 複数行コメント */
// 変数 int num;
データ型です。C#のデータ型には値型と参照型とがあります。以下は値型のデータ型です。
// int(整数)型 int num; // char(文字)型 char c; // float(単精度浮動小数点)型 float val; // double(倍精度浮動小数点)型 double val; // bool(論理)型 bool flag; // DateTime(日付)型 DateTime date;
以下は参照型のデータ型です。
// String型 String s; // 配列型 String[] array;
プログラムをコンパイルするには、コマンドラインで以下のようにします。
csc Sample.cs
プログラムを実行するには、コマンドラインで以下のようにします。
Sample.exe
mono ./Sample.exe
int、float、double型の変数に数値を代入できます。int型には整数だけ代入できます。float、double型には整数でも小数でも代入できます。
int i = 2; int i = 100000000; float num = 1.234f; double num = 1.234;
四則演算です。
num = 1 + 1; num = 1 - 1; num = 1 * 2; num = 1 / 2;
商の求め方です。割る数と割られる数が両方とも整数の場合、計算結果の小数点以下が切り捨てられます。
num = 1 / 2; // 0
割る数と割られる数のどちらかが小数の場合、計算結果の小数点以下が切り捨てられません。
num = 1.0 / 2; // 0.5 num = 1 / 2.0; // 0.5 num = 1.0 / 2.0; // 0.5
余りの求め方です。
// 余り mod = 4 % 2
インクリメントとデクリメントです。
// インクリメント ++i; // デクリメント --i;
String str = "abc";
// 結合 String join = "aaa" + "bbb"; // 分割 String[] record = "aaa,bbb,ccc".Split( "," ); // 長さ int length = "abcdef".Length(); // 切り出し "abcd".Substring( 0, 2 ) // abc // 検索 int result = "abcd".IndexOf( "cd" ) // 見つかった場合はその位置、見つからなかった場合は-1が返る
配列です。
// 配列の宣言 int[] array;
配列の生成です。配列の生成時には要素数を指定するか、初期データを指定します。
int[] array; // 要素数を指定して配列を生成 array = new int[5]; // 初期データを指定して配列を生成 array = new int[] { 1, 2, 3 }; // 宣言と同時に配列を生成 int[] array2 = new int[5];
配列の要素の参照と代入です。
// 要素の参照 array[0] array[1] // 要素の代入 array[0] = 1; array[1] = 2;
array_num = array.Length;
int[] from = new int[] { 1, 2, 3 };
int[] to = new int[5];
from.CopyTo(to, 0);
if文です。
if ( 条件 )
{
}
if ～ else文です。
if ( 条件 )
{
}
else
{
}
if ～ else if文です。
if ( 条件 )
{
}
else if ( 条件 )
{
}
while文です。
int i = 0; while ( i < 5 ) { // 処理 ++i; }
for文です。
for ( int i = 0; i < 5; ++i ) { // 処理 }
int[] fields = new int[] { 1, 2, 3 }; foreach (int field in fields) { // 処理 }
C#では関数をメソッドと言います。メソッドを作るには次のようにします。戻り値を返却するにはreturn文を使います。
static int sum( int num1, int num2 )
{
int total;
total = num1 + num2;
return total;
}
ファイル入出力です。ファイル入出力を行うには、プログラムの先頭に以下を記述します。
using System.IO;
以下がファイル入力の雛形になります。ファイルのオープンや読み込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamReader reader = null; try { reader = new StreamReader(filename); String line; while ((line = reader.ReadLine()) != null) { } } catch (IOException e) { // エラー処理: } finally { if (reader != null) { try { reader.Close(); } catch (IOException e) { } } }
またはC#ではusing ステートメントと言うものがあり、この様にも書ける
String filename = "text.txt"; using (StreamReader reader = new StreamReader(filename)) { try { String line; while ((line = reader.ReadLine()) != null) { // 読み込んだ行を処理 } } catch (IOException e) { // エラー処理: } }
usingをつかうとCloseがなくなったことからわかるようにusing(){}を抜けるときに自動的にDisposeメソッドを呼び出し、オブジェクトを廃棄する。その分コードがスッキリするが、使いにくい場面もあるので考えて使うこと。
以下がファイル出力の雛形になります。ファイルのオープンや書き込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamWriter writer = null; try { writer = new StreamWriter(filename)); writer.WriteLine("abc"); writer.WriteLine("def"); writer.WriteLine("fgh"); } catch (IOException e) { // エラー処理: } finally { if (writer != null) { writer.Close(); } }
こちらもusingを使って書ける。が、割愛する。
C#でよく出てくる知っておいたほうがよい文法の一覧です。
繰り返し文の途中で抜けるにはbreak文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { break; // 条件を満たす場合、for文を抜ける。 } }
残りの部分処理をスキップし、次の繰り返しに進むにはcontinue文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { continue; // 条件を満たす場合、残りの部分処理をスキップし、次の繰り返しに進む。 } }
例外を投げるにはthrow文を使用します。
throw new Exception( "Error messsage" );
try { // 例外が発生する可能性のある処理 } catch ( Exception e ) { // 例外発生時の処理 }
教職員の採用については、俗に「定数法」と呼ばれる法律があり、それに基づく各都道府県の条例に基づいて、正採用の教職員の数は明確に決まってる。具体的には、現行の定数法は１クラスを40人としているので、仮にとある都道府県に40000人の生徒がいたら、クラスの数は1000。そうなると、各クラスには担任副担任２名を置くので、正採用できる教職員の数は2000人ということになる。基準の適用の仕方は色々あるし、小学校の定数は最近若干変わってきているし、他にも自治体独自で作る枠もあるし、一方実際のクラス数はもっと多い（全ての学級の「上限」が40人なのだから、それより数の少ないクラスもある＝実際のクラス数は40で割ったより多くなる）が、とにかく、大体そんな感じに「正採用の人数」は決まっている。
で、統廃合のときどうするかだけど、当然「いつ」統廃合するかは決まっているから、計画が決まるあたりから採用調整を行う。子どもの数は出生数から分かるわけだから、将来的にどのくらい学校が必要か不要かはある程度分かっているわけで、それを見越して採用調整を行う。特に、この20年間くらいは、子どもの数の急激な減少期だったりしたから、学校の統廃合も激しく進み、相当の採用調整を行う必要があった。
かといって、雇っている教員のクビをぽんぽん切れるわけではないので、教員の数を減らすには、原則「早期退職」とか「定年による自然減」に拠るしかない。統廃合前にそれをある程度進めないといけないので、たとえばある学校を一つ統廃合する前の年には、その一校分くらいの教員数を減らし終わってる必要がある。だから、大体その前年まで採用数を減らして教員の数を減るに任せる必要がある。だから、前年くらいにはその都道府県の中に（足りない分を補う）期限付き講師があふれるという減少が起こるというわけ。まあ、学校を廃校にすると言っても、いきなり全学年が消えるというつぶし方をしなくてもよい。新１年生が入ってこない状況にすれば、教員数は１学年ずつ減らしていくという手もあるから、講師による調整数も、せいぜい１学年分ずつということにもできる。それでも、この10年くらいは、複数の学校を一気に統廃合する関係上、さすがに調整きかない分もあるためか、定年後の再雇用枠とか、教育委員会内への出向とか、研修センターで研修とか、まあいろいろ無理矢理な調整をする必要があることもあった。
上の増田が書いてる「２クラスに教師が３人」というのは、色々勘違いがあって、そもそも「１クラスに２人」が標準だから、２クラス３人ならむしろ教師が足りないことになる。多分（主たる）担任のことを言ってるのだと思うが、３人の教師が付くのは、学級担任とは別枠の何かとして配当されているという事情によるのであって、「教員が余ってるからぶちこむ」とかそういう事情とは違うと思う（そんな余裕はない）。多分、片方の担任の指導力に不安があるとか体調不安があるとかクラスに発達障害の子どもがいるとか、まあそんな事情だろう。
それにしても、期限付き講師は、昔は採用に際し有利になることもあったようだが（逆に、前評判が出回って不利になる人もいたと噂に聞くが）、今は特にそういうことも原則ないと思うので、そうなると本当に、採用試験に受からない限り、使い捨てである。色々と問題は多いと思う。
facebookにはイイネ！ボタンなるものが付いていて、これはその内容に賛同できるもしくは気に入ったものに対しての意思表示をして、自分以外の友達にもそれを知ってもらうものである。
ある記事等に対してはそれまでにいいね！ボタンが押された人数が常にカウントされていて、その範囲は0～∞（多数の正の整数）となる。
しかし、実際の人間の心理としては、全く感心のない0からとても賛同できる多数の+以外にも、全く賛同できない否定的な-方向の意見が存在するはずである。ところが、facebookにはよくないね！ボタンなどはないのだから、いいね！ボタンの押された回数と実際に見た人の意見は一致しないのである。