・インターネットが壊れた
・突然パソコンが消えた
これもう分かんねぇな
これだけ機械に弱いとかそんなレベルじゃないんですがそれは
Not A Numberのものを使用したのかな？
・夜中腹減んないすか？→プログラマは夜型が多い
・王道を征く→コーディング規約を守る人間の鑑
・アイスティーしかなかったけどいいかな？→JAVA
・焼けたかな？→プロジェクトが炎上していないかを確認
・これもうわかんねぇな→連日の徹夜で頭が回らなくなっている
・やわらかスマホ→プログラマは最新ガジェットを好む
ぶっちっぱ！→B(rainfuck) CHI(LL) Pa(scal) 全てプログラミング言語の頭文字
暴れんな！暴れんなよ・・・！→熱暴走
まっ多少はね？→全てのバグを取り除くことは不可能
じゃけん夜行きましょうね〜→今夜もデスマーチ
ステロイダー→アステロイド曲線を使っているという意味
まくらがでかい→クワイン・マクラスキー法のプログラムにより得られる恩恵はでかい
イリュージョンかな？
パソコンに自信ニキがいたら教えていただけると助かります
ぶっちっぱ！(メモリリーク)
なお実用レベルかどうかは怪しいもよう
初対面でツイッターのID聞いてくる奴は†悔い改めて†
草生える
そいつの中だと国民総Twitter時代が来てんだね
なんのこったよ
サボってるように見られそうで嫌なんやが
長年の間にオブジェクト指向プログラミング（以下OOP）という言葉自体がかなり混乱をきたしてるんや。
そもそも、OOPという手法は２つに大別できるんや。
ほんでこれら２つは互いにほとんど何の関係も無いから注意してくれや（これらを混同してる人がプロのプログラマにもあまりにも多過ぎるで）
まずはAlan KayがSmalltalkでサポートさせようとしたメッセージングによるOOP。これについては、
ttp://worrydream.com/EarlyHistoryOfSmalltalk/SmalltalkHistoryHOPL.pdf
とか参照してくれや。
（SELFやJavaScriptなんかでプロトタイプベースのOOPというのもあって結構独自の進化を遂げとるんやけど、一応概念のminimizationを目指してここから派生したもんやから省略しとく）
この意味でのOOPでは、オブジェクト間で伝達されるメッセージとそれに対する振る舞いの記述が最重要概念になる。
SmalltalkやObjective-Cなんかはこの流儀を採用しとる。
もう一つは、Bjarne StroustrupがC++で体系付けたクラスベースのOOP。モジュールの単位としてのクラスが最重要概念になる。
ttp://www.stroustrup.com/whatis.pdf
も参照してくれ。
で、こっちがC++やEiffelやJavaやC#、DelphiやDなんかも含めて現在の主流となっとるから、以下にこれ学ぶ上でのガイドをちょろっと書いとくわ。
クラスベースのOOPの目的は、モジュールの凝集度を上げると同時に結合度を下げるということに尽きる。
そのためにモジュールの単位としてクラス（すなわち実装を伴った抽象データ型）を使うわけや。
抽象データ型の理論的な背景は、
ttp://www.amazon.com/dp/0136291554
に詳しいけど、ようは型をその実装ではなくそれに対して可能な操作の集合で特徴付けようというもんや。（この本はいまんとこクラスベースOOPについて最も系統だって纏められた本やからOOPするなら絶対に所持しといてや）
んで、プログラムを記述する際には、プログラムに現れる共通性を抽象クラスとして抽出し、その共通性内での流動的要素を具象クラスとしてその背後にカプセル化していくわけやな。
その方法は、
ttp://www.amazon.com/dp/0321247140
この本がお勧めや。内容も優しいしな。特に、名詞や動詞でクラスやメソッドを抽出するとか言うソフトウエアの組織化には何の役にも立たん（その割に意外と広まってしまってる）頭悪い方法を信じてもてるような人は絶対に読んでや。
それから、良いクラスを作る上でのガイドラインとなるLSPやOCPやDIPやISPやSRPなどの原則を学べるということで、
ttp://www.amazon.com/dp/0135974445/
も読んどいてや。これを読めばGoFのデザインパターンなんかもこれらの原則からの帰結に過ぎんいうことが分かるはずや。
最後に、OOPにおいて重要なクラスの継承やけど、実は安全な継承というのはかなりむずい。その一助となるDesign by Contractという手法があるんでこれも知っといて欲しい。
それには最初にあげた、
ttp://www.amazon.com/dp/0136291554
と、実践面で役立つと言う意味で、
ttp://www.amazon.com/dp/0201634600
も読んどいて欲しい。
みんなもC#、しよう！
オブジェクト志向っての後者の意味だけやと思っとったわ
まだ前者を全然読んでないんやけど、
前者「ブラックボックス化」
後者「継承を元にしたクラス化」
の話な気がする。ちと読んでみよう
たまげたなあ……
いつもCでは色々書いてるんやけどC++になるとソース読解すら出来んのや
SEでも何でもないんやが、こういう専門書的な本を取り敢えず一冊買って読んでみようかなあ
増税前に買いたいぜ
OOPの入門はやっぱりJAVAやね
ああ＾〜いいっすね＾〜
ワイも最初にオブジェクト指向触ったの C# なんやけど、
手続き型的な流儀だけでなんとかしちゃおうみたいな節がいまだにあるので、
もうちょっとオブジェクト指向ちゃんと理解しなきゃ・・・(使命感)
C++の難しさはOOP以外のプログラミング技法が混在するところにあると思うんや。
具体的には、
・C言語のような命令プログラミング
・OOP
・ジェネリックプログラミング
・関数プログラミング
・テンプレートメタプログラミング
・プリプロセッサメタプログラミング
・DSEL
ってとこやね。
最初の二つは良いとして、まずジェネリックプログラミング。
OOPでの抽象の単位がクラスであるように、ジェネリックプログラミングではコンセプトというものを抽象単位に用いる。これによって抽象に非侵入的な階層構造を導入することで、とても拡張性に富んだ設計が出来るんや。さらに静的に解決される多相性によって、高い抽象度を保ったままにも関わらずCで書いた場合と同等、あるいはそれ以上の実行時速度を実現することが出来る。ただOOPのような実行時の柔軟性は無いけどな。
次に関数プログラミング。HaskellやOCamlなんかのように、数学的な意味での関数を抽象単位に用いるプログラミング手法や。副作用の無い小さな関数は最利用可能なプログラムの部品として物凄い役立つんや。それらの関数で成り立つ定理を証明しておくことでプログラムを数学的に扱うこともめっちゃやりやすい。仕様からのアルゴリズムの導出なんかもな。
テンプレートメタプログラミングとプリプロセッサメタプログラミングはどっちかというとライブラリを記述する際に役立つ。前者は型システムを拡張してライブラリ利用者の安全性を高めたり、状況に応じた実装をコンパイル時に自動選択してプログラムの効率化を計ったりとかに使うんや。後者はC++でC++の字句にアクセスできる唯一の手段やな。例えばベクトルクラスを書いてて、xとかxzとかxyzとかの名前のメンバ関数がたくさん欲しい時にプリプロセッサに全てを自動生成させたりな。
最後のDSEL（Domain Specific Embedded Language）言うのは、今扱っている問題を記述するのに必要な言語を、テンプレートメタプログラミングやプリプロセッサメタプログラミングを駆使してC++の枠組みの中で自前実装してまおういう話や。Boost.MSMなんかやと、状態マシンを記述するのにC++の中で状態遷移図を記述できるようになっとる。
で、や。
近年のプログラミングやと大規模なソフトウエアの複雑さにどうやって立ち向かうかっていうんが常に大きな問題として立ちはだかってるんや。
OOPやと >>36 で書いたように、クラスを用いてモジュールの凝集度を上げつつ結合度を下げることでソフトウエアに修正を加える際に影響範囲が出来るかぎり小さくなるように配慮してプログラムを作っていく。
ただ、クラスという抽象単位がbetterではあっても常にbestな選択であるとは限らんわけや。他の手法なら同じ部分プログラムをもっと簡潔に記述できるいうこともある。
そんでC++でのプログラミング手法は、場面場面で最良の抽象を行えることを目指して進化してきたんや。
ところがC++が最初からサポートしてたんはこの中やと最初の二つ、命令プログラミングとOOPだけや。
まずジェネリックプログラミング。実のところC++の標準ライブラリはOOPではなくジェネリックプログラミングに基づいとる。C++の標準ライブラリの真の柔軟性を利用するにはジェネリックプログラミングを理解することが不可欠や。にも関わらず、C++自体はジェネリックプログラミングのコンセプトをサポートしとらん。ユーザはコードに直接現れへんコンセプトをドキュメントで把握する必要がある。（実は2011年版のC++規格でコンセプトを言語に導入する議論が交わされてたんやけど今回は見送られた）
次に関数プログラミング。ここで重要な代数的データ型や無名関数も長年ライブラリに頼って来た。（無名関数はBoost.LambdaやPhoenixと言ったDSELで実現して来た。2011年版のC++規格で無名関数は言語に導入されたけど、それは多相的ではないのでまだこれらの受容は無くならんと思う）
テンプレートメタプログラミングに至ってはほとんど歴史的偶然で発見された手法や。（テンプレートに関するエラーメッセージの中にたまたま素数列が含まれてるのを発見したというのがその起源らしい）
んでまあC++でのプログラミング技法言うんはこういう本来意図してなかったことも含めてふくれあがっていった訳や。せやからC++を本当の意味で使いこなすにはかなりの知識量が要求される。
それでももしC++のこの特性に興味惹かれるなら、これらの手法の為の機能が整理しなおされてるD言語という選択肢もある。
OOPだけで良いならそれこそ皆様が挙げてくださっとるC#やJavaでも良いと思うで。
長い
三行で頼む
うちの周りじゃpythonが流行っとるからワイも手を出して見たいんやけど、初心者大学院生程度に向いてる参考書ってどれかね？
構文を備えたLisp
普通に考えて、３０歳未経験者がプログラマを目指すのは辞めた方がいいですかね？
再就職に向けて職業訓練行くか、他の仕事に絞っていくかで迷ってます。
javaの入門書を一冊やりましたが、なんとなく分かりますけどあまりピンとこないという感じです…
でも人が集まりすぎると各言語の信仰者同士で対立しそう
にわかプログラマのわいが恥ずかしくなってきたわ
同期通信って何だよ、オイ
ちなswitchとかstructとか覚えた程度の初心者
AILEくんの更新に役立つようなツールつくりたい・・・つくりたくない？
ネットワークプログラミングはむずいやね。
プログラミング言語の構文を勉強してる段階やったら、とにかくいろいろ書いてみてまずはプログラミングという行為自体に慣れてとしか言えへんけど、一応そのうち役立ちそうな本何冊か紹介しとくわ。
既にTCP/IPの知識があるならソケットプログラミングの勉強には、
ttp://www.amazon.com/dp/0131411551/
このシリーズがお勧めや。
で、実際ある程度の規模以上のプログラムを書くとなるとプログラムに（修正を加えていっても破綻しないような）良い構造を持たせてやる必要がある。
そこで先人達の良い設計を集めたPattern-Oriented Software Architecture言うシリーズがあるんやけど、その２冊目、
ttp://www.amazon.com/dp/0471606952
これがネットワークプログラミングするなら必読や。
C++でやっていくなら、上記の知識を踏まえた上で、
ttp://www.amazon.com/dp/0201604647
も良いね。これにも通信に関する設計のパターンが詳しく載っとる。
ソケットプログラミングを良い感じに抽象化したACE言うんのガイダンスでもあるんで、C++でのネットワークプログラミングが大幅に楽になるはずや。
あと近代的なC++のネットワークライブラリやと、Boost.Asio
ttp://www.boost.org/doc/html/boost_asio.html
も使いやすくてお勧めやで。
自分で書くなら理解してる範囲でだけ使っていけばええんでそこまで身構える必要は無いで。
そのかわり他人のコードを読むなら先に書いたような知識が普通に使われてたりするから苦労することになるかもしれんな。
あとチームで開発する時には最初に互いの知識の擦り合わせしとかんとやばいことになる。
Pythonに関してはきちんと使ったことないんでアドバイスできん。すまんな。
他人の人生左右しそうな質問に答えるのは気が重いんやけど…
ぶっちゃけると、30歳未経験で雇ってもらえて、それなりに定時退社もできる会社をワイは知っとる。けど実際の所この条件やと大半の会社はいわゆるブラック企業や。
せやからwebで検索して申し込むって形やとかなり分の悪い博打になる。
それに未経験で任せられるような作業にプログラミングの楽しさなんかほとんど無いし、とても製品レベルの品質には無いソフトウェア売ってる会社も多い。
もし本当にプロのプログラマ目指すなら最低でも一年、出来れば二年は本気で勉強して技術力つけて欲しい。
もちろんよほど才能でもない限りそれくらいで一流にはなれんやろうけど、他人と議論交わしたり得意分野作るくらいは出来る。
ほんでその勉強と並行して人脈を作るんや。
いまから良い環境でプログラミング出来るようになろう思たらとにかく人脈が鍵や。
学生時代のツテとかなくていまから新しく人脈作るんやったら、まずは各地で開催されてる勉強会とかオススメや。
ttps://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k@group.calendar.google.com
場所によっては腕の立つプログラマも遊びに来てるから、懇親会とかに積極的に参加してな。
それからもう一つ考えられるんは、twitterとかはてなとかのブログとかで目立つことやな。
実際のところ大手の人間も含めてこういうところ観察してる人は多いから、技術的に尖った話しまくっとったら目付けて貰えることもある(それで採用された人も何人か知っとる)。
それから人脈があれば企業に属さずともフリーでやってくって選択肢もあるで(国内やと東京以外はきついかも知れんが)。腕が立つなら月200万くらいで雇うこともある。
こんだけ書いたけど、実際にやろう思ったらかなりの覚悟がいると思うで。やってみたところで絶望的にプログラミングの才能無いって人もおるしな。
実際こういうルートで完全未経験から一年ちょっとでそれなりに名のある会社に入った人も知っとるけど、ワイに>>49の才能を測ることは出来んし、この話はどうしてもプログラマでやって行きたいって場合だけ参考にしてな。
そうそう。ホンマおっしゃる言う通り。やっぱり現代人の基礎教養やと思ってある程度は勉強しておくべきやな。
pythonの件は残念やけど、俺もTCP/IPについて知りたかったんや。>>55にある本も買いたいなあ。
丁寧にどうもありがとう。
>>55で紹介した本はある程度TCP/IPの知識があることを前提にしてるから注意してや。
完全にTCP/IP初心者なら、
ttp://www.amazon.co.jp/dp/4274068765
辺りが分かりやすいと思うで(ワイが読んだんはもっと昔の版やから5版の内容までは保証でけへんけどな)
ただ、あんまり厳密に書かれた本や無いから、ある程度慣れてきたら
ttp://www.amazon.com/dp/0321336313/
このシリーズとかで知識補ってや。
クラスの切り方が汚いと全然進まない，コードを直す気にもならない，新しい方法が閃かない
逆に綺麗に切れると俄然やる気が湧く．進みも早い．大げさかもしれんけど芸術品のようだあ
プロになる予定はないけど，センスを磨く方法っていうのはないもんかなあ？
やっぱり本を読んだり勉強会に参加したりしなくちゃいかんかなあ
C#使ってるからMSのライブラリ逆コンパイルして覗き見してたりするけど，
ソース見てるだけじゃ上達しないもんかな
一日中見てても飽きないから楽しい(^q^)
コード書いてて時間が経ってくるとクラスを割り直したい衝動にかられて書き直しちゃう
時間の無駄だと分かってても書きなおしちゃう，ヤバイヤバイ
でも美しく仕上がると無上の喜びなんじゃあ＾〜
くっそわかる
はじめの方モデル設計しないでくっそ汚いクラス作って後で後悔しますよ〜
結構前に書いた自分のコード見てるとこんなんばっかで頭にきますよ
流石に最近はある程度クラス割りするようにはなってきたけど、
どういう風に割ればいいかっていうのは全然勉強不足だし書籍も漁るべきなんやなと思った (小並感)
新スレたててもたんやけどどないしよ
クラスを作る時に考慮するべきことは多いねんけど、CVA（commonality/variability analysis, 共通性/可変性分析）とSOLID原則（SOLID principles）いうもんが役に立つから何回かに分けて紹介しとくで。
CVA言うんは、問題領域の中から変化しにくい要素（共通性）と変化しやすい要素（可変性）を見つける作業や。特にプログラムを開発するとっかかりにはなる。
例えばゲームを作ってると考えようや。
このゲームではプレイヤーは騎士やモンクや魔法使いになれるとする。これらの共通点はどれも「職業」であるということや。そこで、
abstract class Job { }
class Knight : Job { }
class Monk : Job { }
class Mage : Job { }
みたいなクラス群が考えられる。
共通性を抽象クラス、可変性を具象クラスで表現したことに注意してや。
さらにプレイヤーが職業の他に種族も選べるとしよか。
abstract class Race { }
class Human : Race { }
class Dwarf : Race { }
class Elf : Race { }
種族（Race）が共通性や。
個々のクラスのインターフェースは、他のクラスからどのように使われるかによって決定すべきなんやけど、これは後で説明する。
ほんでプレイヤークラスと職業クラスと種族クラスの関係がどうなるか考えたらまあ、
class Player { Job job; Race race; }
みたいな感じになるやろう。
CVAに関して詳しく知りたければ>>36で挙げた、
ttp://www.amazon.com/dp/0321247140
を読んでくれ。
OOPより広い範囲の話になってまうけど、
ttp://www.amazon.com/dp/0201824671
も参考になる。
ところで初心者がやってまいがちなことに継承を多用しすぎるっちゅうんがある。
例えばさっきの例やと、「ドワーフの魔法使いなプレイヤー」を表現する為にMageDwarfPlayerみたいなクラスを作ってまうんや。
これやと仮に種族が１０種類、職業も１０種類に増えたとしたら、10 x 10で100個もクラス作らなあかんことになってまう。
こういう組合せ爆発起こさん為にも継承より集約を用いた設計を心がけなあかん。
ついでSOLID原則なんやけど、
これは、
SRP（Single responsibility principle, 単一責任原則）
OCP（Open/closed principle, 開放/閉鎖原則）
LSP（Liskov substitution principle, Liskovの置換原則）
ISP（Interface segregation principle, インターフェース分離原則）
DIP（Dependency inversion principle, 依存性逆転原則）
の五つの原則の頭文字とった略称や。
一つ一つ簡単に紹介していくけど、長くなりそうやから次のレスに回すで。
引き続いてゲームを例にSRPを説明するで。
SRP（Single responsibility principle, 単一責任原則）言うんは、「一つのクラスは一つの責務だけを持つべき」って原則や。
せやけどんなこと言われても意味が分からんと思うんで、ワイは「クラスを変更する理由は多くとも一つでなければならない」っていう言い回しの方が好きや。
例えばゲーム内の敵を表現するクラスが、その敵を動作させるメソッドと、その敵を画面に描写するメソッドの両方を持っているとする。
これやと、例えば敵の描写方法の変更が、敵の動作にまで影響を与えて不具合が生じてまうかもしれへん。
こういうときは敵の動作を司るクラスと敵を画面に描写する為のクラスの二つに分離するべきや。
ただ、あるクラスに複数の変更が生じるかどうかは、実際のところ初見では分からんことも多い。逆に一見複数の変更が生じるように見えても、実はそれらの変更は常に同時に発生するいうこともある（その場合クラスの分割は無用な複雑化を招くだけなのでせえへん方がええ）。
せやから確信が持てんときは、実際に変更が発生するときまで分割は遅延しとけばええ。
次のレスに続くで。
OCP（Open/closed principle, 開放/閉鎖原則）言うんは、「モジュールは拡張に対して開いていて、変更に対して閉じていなければならない」って原則や。
もうちょっと丁寧に言えば、プログラムを変更しようと思った際にモジュールに新しい振る舞いを追加することでその変更に対処できる（拡張に対して開いている）、かつ、モジュールの振る舞いを拡張してもそのモジュールのソースコード等に影響が無い（変更に対して閉じている）いうことや。
例として次のC言語で書かれたコードで考えてみることにする。
enum EnemyType { ORC, TROLL };
struct Enemy { EnemyType type; };
struct Orc { EnemyType type; /* other properties… */ };
void drawOrc(struct Orc*);
struct Troll { EnemyType type; /* other properties… */ };
void drawTroll(struct Orc*);
void drawAllEnemies(Enemy** es, size_t n) {
for (size_t i = 0; i < n; ++i) {
struct Enemy* e = es[i];
switch (e->type) {
case ORC: drawOrc((struct Orc*)e); break;
case TROLL: drawTroll((struct Troll*)e); break;
}
}
}
このdrawAllEnemiesはOCPに違反しとる。敵が追加されるたびにdrawAllEnemiesを修正せなあかんからな。
例えば敵としてDragonを追加したら、case DRAGON: drawDragon((struct Dragon*)e); break;みたいな行を追加せなあかんやろう。
しかもこういった変更はdrawAllEnemiesだけやなくて、敵を纏めて処理するような全ての関数に波及してまう。EnemyTypeで分岐してるような部分全てを調べるハメになるいうことや。
そこで、このコードをC++を使って次のように書き換えてみてみるんや。
struct Enemy { virtual void draw() const = 0; }
struct Orc : Enemy { void draw() const { } }
struct Troll : Enemy { void draw() const { } }
void drawAllEnemies(std::vector<std::shared_ptr<Enemy>> const& es) {
for (auto e : es) e->draw();
}
これならDragonを追加したい場合も、既存のコードを一切変更せずに、Enemyから新しく派生させれば良い。すなわちこのモジュールは、拡張に対して開いており、変更に対して閉じておる。
……ところが、問題はこれでは終わらん。
今作ってるのが2Dゲームで、戦闘画面では飛行しているDragonは地面にいる敵より後ろに描写せなあかんとしよう。敵の描写に順序付けが必要になったと言うことや。
この場合drawAllEnemiesの中身を書き換えて、敵をソートして書き換えなあかんいうことや。
残念ながらdrawAllEnemies関数はこの変更に対して閉じておらん。
この変更に対して閉じるにはどうすれば良いか。
Enemyの派生クラスを順序付けようとした場合、OrcやTrollの中で比較対象のオブジェクトの型を調べて順序を指定するのはまずい。新しいEnemyの派生クラスを作るたびにすべての派生クラスの修正が必要になってまう（最初のOCP違反が戻って来てまう！）。
この場合、別のEnemyの派生クラスの順序を記述したテーブルを別のモジュールに用意して、Enemyからそのテーブルを参照するようにすれば良い。こうすればEnemyの順序付けに対して閉じていないのはそのテーブルだけに局所化される。
さて、１つ目のOCP違反に対してはともかく、２つ目のOCP違反に最初から対処しておくことは難しい。
このことから得られる教訓は、あらゆる変更に対して閉じているようなモジュールを書くことは予知能力でも無い限りワイらには不可能やいうことや。
現実的には、実際にプログラムの変更が必要になったとき、そのときになって初めてその変更に対してモジュールを閉じるっちゅーことが多い。
問題が表面化した時に戦略的に閉じるいうことやな。
次のレスに続くで。
LSP（Liskov substitution principle, Liskovの置換原則）言うんは、「派生型はその基底型と置換可能でなければならない」って原則や。
OOPでは派生クラスはその基底クラスと置換可能でなければいけないっちゅーことやな。
単純な例で説明するで。
次みたいな長方形クラスがあったとする。
struct Rectangle {
virtual void width(int w) { w_ = w; }
virtual void height(int h) { h_ = h; }
int width() const { return w_; }
int height() const { return h_; }
int area() const { return width() * height(); }
private:
int h_, w_;
}
そして後にプログラムに正方形クラスが必要になったとする。
そこで、このRectangleを継承して、
struct Square : Rectangle {
virtual void width(int w) { Rectangle::width(w); Rectangle::height(w); }
virtual void height(int h) { Rectangle::width(h); Rectangle::height(h); }
}
のように正方形クラスを作る。
数学的に正方形は長方形なので、いわゆるis-a関係も満たしており、一見正しそうに見える。
ところが、既存のコードに次のような関数があったとする。
void f(Rectangle& r) {
r.width(10);
r.height(5);
assert(r.area() == 50);
}
この関数はrの高さを変更しても横幅の長さが変更されないことに依存しとる。
従って、rにSquareのインスタンスが渡された場合、この関数は正しく動かんのや。
Rectangleの変わりにSquareが使えんいうことはすなわちLSPが破られとる言うことや。
is-a関係の存在は正しい継承の為の必要条件やけど、十分条件では無いいうことやな。
こんな単純な例でも問題が発生したのに、現実のプログラムはこんなもん比較にならん程複雑や。せやからそこでの（実装の）継承も、慎重に使っていかなあかん。
ではどうやったらこの問題を防げたか、いうことを考えてみよか。
はっきり言うと人間の直感に頼った方法では辛すぎるんで、ワイはDbC（Design by Contract）言う手法を用いるんがええと思っとる。
この手法やと、各メソッドにその事前条件と事後条件を記述することになる。
事前条件言うんは、そのメソッドを呼び出す前に成り立たせておかなあかん条件で、事後条件言うんはそのメソッドを呼び出した後に成り立っとることが保証される条件や。
例えばRectangleのvoid height(int h)には、
h_ == h && w_ == old w_
言う事後条件が考えられる。
先の関数fを書いた人は暗黙にこの事後条件を仮定しとったわけや。
ほんで、DbCによれば、派生クラスのメソッドにおいて、事前条件はその親クラスのものと等しいかより弱くないとあかん。また、事後条件はその親クラスのものと等しいかより強くないとあかん。言い換えれば、派生クラスのメソッドにおいて、事前条件はその親クラスのものを含意し、事後条件はその親クラスのものに含意されなあかんのや。
Squareはこの条件に違反しとるんで、環境がDbCをサポートしとれば自動的に検出することが出来る。
DbCは、EiffelやDやと言語そのものがサポートしとる。
C++やと、
ttps://svn.boost.org/svn/boost/sandbox/contractpp/doc/html/index.html
こういうライブラリを利用できる。
C#とかの.NET言語やと、
ttp://research.microsoft.com/en-us/projects/contracts/
こういうもんがある。
DbCにおける事前条件や事後条件、クラス不変表明と言った条件は、クラスのインターフェースの一部やと考えられる。クラスの利用者はこれらの条件に依存してプログラムを記述することが出来るわけや。せやからこれらの条件は、非常に有用なクラスのドキュメント（しかも機械的にチェックされる！）とも見なせる。その意味でも積極的に使っていって欲しい。
DbCの良い解説は、>>36でも挙げた
ttp://www.amazon.com/dp/0136291554
を参照して欲しい。
DbCの概要だけ知りたい場合は、
ttp://www.amazon.com/gp/product/0130065781/
の一章も良い感じや。
DbCを実践する上では、これまた>>36でも挙げた
ttp://www.amazon.com/dp/0201634600
が非常に役立つ。
後、こういう論理的な条件を扱う都合上、述語論理に親しんどくとやりやすい。
ttp://en.wikipedia.org/wiki/First-order_logic
次のレスに続くで。
DIP（Dependency inversion principle, 依存性逆転原則）について説明するで。
今、モジュールAを実装する為にモジュールBが、モジュールBを実装する為にモジュールCが必要やとする。（一番上位のモジュールがAで、一番下位のモジュールがCになっとる）
一番単純に実装してまうと、
A ―> B ―> C
みたいに、モジュールAがモジュールBに依存して、さらにモジュールBがモジュールCに依存するような依存関係になる。上位のモジュールが下位のモジュールに依存してる状態や。
OOPで言うならクラスAがクラスBに、クラスBがクラスCに依存してる状態やね。
せやけどこれやと例えばクラスCを修正しようとすると、それに依存してるクラスB、さらにそのクラスBに依存してるクラスAにまで影響が及んでまう。
そこで、これらの間にインターフェースXとYを挟んで、
A ―> X <― B ―> Y <― C
の形にしてみよや。
この形やとCに修正を加えてもBやAには影響は及ばんし、Bに修正を加えてもAやCには影響は及ばん。
ほんで例えばインターフェースXは、Aを実装するにはどういう操作を必要としているかで決めることが出来る。つまり、上位のモジュールの実装方法を考えることでそのモジュールが必要とするインターフェースが規定されるわけや。
そこでインターフェースとそれを規定するクラスをグループに纏めると、
[ A ―> X ] <― [ B ―> Y ] <― [ C ]
みたいに表せる。
最初のA ―> B ―> Cとは依存関係を表す矢印が逆になっとるね。
こういう風に、上位のモジュールが下位のモジュールに依存するのでは”なく”、下位のモジュールが上位のモジュール（が規定する抽象インターフェース）に依存するべきやっちゅーのがDIPや。
class A { void f() { } }
例えばこのクラスAのメソッドfを実装するときには、そのメソッドfを実装するのに必要な操作の集合を考えて、それをインターフェースとするんや。
class A { X1& x1; void f(X2& x2) { /* ここはX1やX2のメソッドを使って実装する */ } }
インターフェースをメンバにするか引数にするかはそのライフタイムとかクラス内での利用範囲とかいろいろ考慮して決断してや。
ほんでからこれらのインターフェースX1やX2を実装したクラスB1やB2を実装するんや（場合によってはB1がX1とX2の両方を実装するいうようなこともあり得る）。
ときどきクラスをそれ単体で便利に作ろうとする人を見ることがあるんやけど、クラスのインターフェースはそのクラスの利用者側から決定すべきなんや。
インターフェースを考えるときは、それが持つメソッドの事前条件や事後条件（や不変条件）も考えて、利用者側はそれらに依存して実装すると厳密に書けて良いで。
OOPの話からは少し離れるけど、これらの条件はそのインターフェースを実装するクラスのメソッドを書く際にも役に立つ。
事後条件を満たすようにコードを記述していくっちゅーんは数学的に正しいimperativeなアルゴリズムを記述する基本手法やからな。
もし命令プログラミングのアルゴリズムの記述に興味があれば、多少数学的な素養が必要やけど、
ttp://www.amazon.com/dp/0387964800
ttp://www.amazon.com/dp/013215871X
ttp://www.cs.ox.ac.uk/publications/books/PfS/
ttp://www.amazon.com/dp/0387984178
辺りが役に立つで。
次のレスに続くで。
ISP（Interface segregation principle, インターフェース分離原則）言うんは、一つのクラスにインターフェースを押し込めるんやなくて、関連性の高いインターフェースはグループ化して分離すべきやっちゅう原則や。「クラスの利用者に、そのクラスの利用者が利用しないメソッドへの依存を強制してはならない」とも言える。
例えばクラスAを実装するのにクラスBの機能が必要やと考えようか。
せやけどこの時AはBの全てのメソッドが必要やない。
こういう時、Bのメソッドの部分集合をインターフェースXとして分離し、AはXに依存すべきなんや。
もしAが利用せえへんBのメソッドにも依存しとったら、Bのインターフェースの利用してない部分の変更に対してまでAが影響を受けてまうことになるからな。
こういったインターフェースの分離も、クラスの利用者側から考えていくことで行いやすい。>>72でも書いたように、クラスの利用者が必要とする最小の操作の集合を考えて、それらの中で関連性の高いものを纏めてインターフェースとするんや。ほんでからそれらのインターフェースを実装するクラスを記述する。（もし既に必要な機能を提供しとるクラスがあるなら、それに対するアダプタークラスを用意したってもええ）
ところで、こうやって個々の利用者に対してインターフェースを分離して考えとると、実際にはいくつかの利用者の集合がほとんど同じインターフェースに依存しとることがある。そういうときはそれらの利用者の集合に対してインターフェースを分離してやることで、プログラムに現れるインターフェースの数を減らしてやれる。インターフェースが増えるとその分コードも複雑化するんで、バランス感覚が重要やな。
また、プログラムをインターフェース主導で記述しとると、ときどき、
interface X1 { void f(); void g(); }
interface X2 { void g(); void h(); }
class A : X1, X2 { void f(){} void g(){} void h(){} }
みたいに、複数のインターフェースが同じメソッドを宣言してまうことがある。
せやけどX1とX2が異なる利用者に対して公開されてるインターフェースなら、X1とX2の重なりが小さいうちは同じメソッドを両方のインターフェースで宣言することになろうともこれらのインターフェースは分離したままでもええやろう。
それから、これまたインターフェース主導でプログラムを記述してると起こることがあるんやけど、例えば次みたいに関数kの実装にインターフェースX1とX2が必要になったとする。
void k(X1& x1, X2& x2) { }
このとき、X1とX2が共にクラスAで実装されることがある。
そうすると、関数kの呼び出し側は、
A a;
k(a, a);
のようになるやろう。
１つの関数に同じオブジェクトを２度渡してるわけで、これだけやと一見奇妙にも思える。
せやけど、これで別に問題があるわけやない。
ワイらはインターフェースをそれらの関連性の強さで分離したわけで、他の利用者も常にX1とX2を同時に必要とするわけやないからな。
さらに、関数kの引数自体も、未来永劫同じオブジェクトであり続けるとは限らんわけや。
これでSOLID原則の簡単な紹介は終わるけど、補足を次のレスに続けるで。
1人でやるときはクラス図とか描かなくていいって言われてきたけど、
ワイみたいに頭ん中整理するのが苦手な奴はちゃんと描いたほうがいいのかもしれんね
クラス図とか書いてみるのも頭の中の整理にはええね。
ただ、図いうもんはあくまでも概念の特定の側面を記述するもんでしかない言うことは念頭に置いといてや。
時々そういった図だけを使ったモデリングに傾倒してまう人をみかけるんやけど、そうはならんように注意してくれ。
UMLなんかも、Martin Fowlerが
http://www.amazon.com/dp/0321193687
の中でも述べてるようなスケッチとしての利用程度で十分や。
（ちなみにこの本UMLモデリングのエッスンス言うタイトルで日本語版が出とるみたいなんやけど、このタイトルつけた人の正気を疑うわ）
>>68辺りからだらだら書いてきたけど、良いクラスを記述するには今書いてるプログラムの中の流動的な要素をいかに上手くカプセル化していくかが重要や。
ほんでその大半は実際にコードを書きながらでしか達成できへんのや。
図でも何でも開発に役立つと判断したもんは積極的に利用していくべきやけど、あくまでもプログラムのコードのを記述することが設計の主体や言うことを忘れんといてな。
文法は入門書でわかったけど、いざ自分で書こうとするとでっかい１クラス
にコード詰め込む素人なんで勉強になるなあ
しかしこういうの見てると、ホントプログラマって専門性高いと感じる
なんで単純労働って思われてるんやろうなあ
プログラマが軽く見られることがあるんは、おそらくソフトウエアの開発工程を他の工業製品のような開発工程に当てはめようとしたことに起因してると思うで。
仕様の策定や設計とかを担う上流工程と、製造とかを担う下流工程にソフトウエア開発を分割出来ると考えた人らがおるんや。ほならプログラマは与えられた設計に従って、画面に向かってコードを打ち込んでくだけやってな。
せやけど実の所、プログラミング言うんはソースコードっちゅうソフトウエアの設計図を成果物とする設計行為に他ならん。
ここまでの中で出した事例からも分かると思うけど、実際にプログラミングという行為を伴わずに保守性と拡張性を伴ったソフトウエア設計は不可能なんや。(メソッドの事前条件や事後条件なども含めて)クラスのインターフェースとかのプログラムの仕様策定に関してもな。時には実現可能性や速度なんかの面で、要求仕様にまでフィードバックされることもある。
ワイが今まで見た限り、大手、中小に関わらず、上流下流を分割してるような所のコードは例外なく糞や。昔はいわゆるデスマーチのヘルプに入ったこともあるんやけど、お前らの開発体制がデスマ招いてる原因やろっちゅーことがほとんどやった。
ttp://www.developerdotstar.com/mag/articles/reeves_design.html
でも述べられとることなんやけど、もしソフトウエア開発を他の工業製品のような開発工程に当てはめるんやったら、製造工程はコンパイルやリンクなどのソフトウエアのビルド工程になるやろう。ほんでこの製造工程がほとんど完全に自動化されとるんがソフトウエア開発の特殊な所やな。
あとはテストの為のコストが異様に安いっちゅうところか。これはクラスとかのユニットテストを気軽に書いて、その結果をガンガン設計にフィードバックしていけることを意味しとる。それにテストを記述しやすいクラス言うんはすなわち他と結合度が低く凝集度が高いクラス言うことやから、クラスより先にテストを記述する言うんは良いクラスを書いて行く上で重要なことや。テストを書く中で見えてくることも多いし、インターフェース決定の助けにもなる。
実際のところ、テストもデバッグもコーディングも、もちろん普通に設計と呼ばれる行為も、プログラムのソースコードを記述する為のあらゆる活動は設計なんや。ほんでこれらは決して分離独立して行えるような類のもんではない。
せやから良いプログラマになろう思たら、多くの知識と経験が必要になってくるんや。
あと、ときどきプログラミングには数学的知識が必要ない言われることがあるけど、これにもワイは極めて懐疑的や。
仕様を形式化して無矛盾性を証明すること、仕様を満たすプログラムを形式的に導出すること、プログラムが仕様を満たしていることを証明すること。
常にこれらを実践することは現実的には難しいんやけど、可能な限り行うよう心がけておけばプログラムの誤りは劇的に減らせる。
それに直感で考えるんは難しい問題も、形式的になら簡単に解けることも多い。
加えて証明のしやすいプログラムを目指すと、プログラムに良い構造が持たらされる傾向もあるんや。
ありがとニキー（大感謝） 「プログラミングも設計」ってすごく腑に落ちたわー
行く先々で聞いた「プログラミングは他人にやらせる低価値工程 人海戦術」って風潮がぴんとこなくてなあ
「人売り会社はアカン。でもプログラミングなめた企業もあかんやろ」って直感があった
それで要件定義からコーディングまで全部やる小さい会社に入ったけど
正直不安も大きかった、でも安心できたわ（自分語りしてスマンな）
数学の方は、まだワイにはわからん でも文系のワイでも「直感では正しかないのに負の解もでてくる」
「ベン図では書きようもないような、複雑な論理学の命題が公式使えばとける」みたいな経験はある
数学得意な人は、プログラミングでも数学的な問題解決ができるやろうなあ 自分も心に留めておくわ
UML図はクラス図も含めて何種類か授業でやったんやけど、
ﾊﾟﾊﾟﾊﾟｯとスライド見せられて終わりだったから書籍の紹介ありがとナス！
英語はあまり得意ではないから日本語版のタイトル助かるんじゃ＾〜
スケッチ程度の利用でも手段として持っておけるようになりてぇなぁ・・・
コピペだけでも作れそうじゃないすか？(素朴な疑問)
くっさ
無理やで(真顔)
あれでマイコンをきらいになる人は多い (確信)
でもハードウェアは買い足ししなきゃいけないし，使えるようになるのも１年先
映像技術は水物だし，早く触ってみたいんだよなあ
なお，テストするだけで動くおもちゃを作ったりはしない模様
ホモはハッカー
単純にfor文でカード[i]とカード[乱数()%52]をスワップして行けばいいんですかね
商用ゲームだと、どんな感じでやってるのか気になるゾ
(その慣用句だけは)やめてくれよ・・・（絶望）
最近忙して亀レスになってもてすまん。
標準ライブラリとかにシャッフル用の関数があるならそれを使えば一番ええ。
例えばC++ならstd::random_shuffle関数がそれやな。使う場合は次に説明する擬似乱数生成エンジンも併用してや。
自前で実装する場合は、いくつか考えやなあかんことがある。
まずは擬似乱数生成関数の質や。
ttp://www001.upp.so-net.ne.jp/isaku/rand.html
詳しくはこの辺見てくれ。
例えばC++の場合はstd::mersenne_twister_engineとして上記のURLで紹介されとるメルセンヌツイスタ法を使った擬似乱数生成エンジンも用意されとる。
次に、一般にrandom() % nという方法で乱数の範囲を得るのは偏りが出てあかん。
分かりやすいようにrandom関数が0から10の範囲を返すとして、random % 10を考えると、0が出る確率だけ他の数が出る確率の2倍になってることがわかるやろう。
一様分布する整数の範囲が欲しいときはちょっといろいろ考えなあかんことがあるんやけど、最近の言語は大抵擬似乱数の値の範囲を指定できるから、そういうのを使ってくれ。
例えばC++の場合は、std::uniform_int_distributionとかがそれやな。
で、シャッフルの実装やけど、あまり考えずに次みたいに書いたらあかんで。
// rand(m, n)は整数の乱数r(m≦r<n)を返す関数、csは長さnの配列とする
for (int i = 0; i < n; ++i) swap(cs[i], cs[rand(0, n)]);
これやと正しいシャッフルにならへんのや。
csの要素が取り得る順列はn!通りある。
一方、このループが実行される間にrand(0, n)が返す値の列は全部でn^n通りある。
このn^n通りの列が得られるのが全て等確率やとすると、csの要素が取り得る順列が等確率で得られるにはn^nがn!で割り切れやなあかん。
せやけど3≦nのときこれは割り切れやん。
せやから3≦nのときこれは正しいシャッフルになっとらんのや。
正しくは、
for (int i = 0; i < n - 1; ++i) swap(cs[i], cs[rand(i, n)]);
こうやな。
はぇ〜すっごい解説･･･、%で範囲絞るのはよく考えなくてもダメでしたね
cs[rand( 0, n )]からcs[rand( i, n )]になったのはn^n通りをn!通りにして
必ず割り切れる様にって事で良いのかな、理解するのﾁｶﾚﾀ･･･
あと関数も教えてくれてありがとうございます、丁度C++でやってました
わいももっともっと頭が良ければゲームとか作れたかもしれんわ…
Java8出たけど会社じゃ使えないんじゃ^〜
(いまだにJDK1.4使い続けてる所もあるし)ま、多少はね？
なお自分はまだチュートリアル見てる模様
考えたこともなかった できる人がいるんやなあ
unityのフリーで足りない人は、Proは高いし作っちゃうのもええかもしれんな
洋書に抵抗なければ3Dエンジンの製作学ぶのもそう難しくは無いで。
専門書や論文読むのに必要な数学の基本は、Mathematics for 3D Game Programming and Computer Graphics, Third Editionにだいたい網羅されとる。
ttp://www.amazon.com/dp/1435458869/
この本の初版は日本語版が出てて業界ではお勧めされることも多いんやけど、後の版でサンプルコードがシェーダアセンブラからGLSLに変更されてたりそもそも内容がめっちゃ加筆修正されとるんで絶対に原著読む方がええ。
リアルタイム3Dレンダリングの基礎はReal-Time Rendering, Third Editionがめっちゃわかりやすくてお勧めや。
ttp://www.amazon.com/dp/1568814240/
この本も日本語版やと一個前の版になってまうな。
ゲームエンジンの開発については、ワイが読んだ中ではEberlyの3D Game Engine Architectureや3D Game Engine Designがよう纏まってて良かったわ。
ttp://www.amazon.com/dp/012229064X/
ttp://www.amazon.com/dp/0122290631/
こういう本で基本的な知識身につけたら、GPU GemsとかGame Programming GemsとかShaderXとか、CEDECやGDCの資料とか漁って興味ある技術吸収していけばええ。
ただワイ自身はこのところゲーム開発からは離れとるんで、最近はもっとええ情報源出とるかもしれんということだけ最後に付け加えとくで。
最近の大学とかは環境が楽やからってJavaScriptを最初に教えるらしい
UIすぐ作れるからますますゲーム作るの流行るんやろか
ワイはFortranちゃんと使ったこと無いからわからんのやけど、今あえてFortran選ぶ理由って何かあるんかね？
外から見てる分には安全面(TMPで次元解析を型システムに任せたりリソース管理をRAIIに任せたり)でも速度面(最近のコンパイラは大抵vectorizationもサポートしとるしETによって巨大行列の遅延評価なんかも自然な構文で書けるし)でもC++とかでええんちゃうのって気がするんやけど
ワイも詳しくは知らんけどマイナーなメインフレームとかだとc/c++コンパイラの出来が悪かったりしたらしい
未だにそうなんかはわからんけど今更メインフレーム向けコンパイラの需要が高まるとも思えへんからなぁ
ああ、私は理論計算やってるんだけど、単純に演算速度がやっぱり早いっていう理由で使ってる
SPARC系CPUだとCでも同じ速度でるけど京とかTSUBAME用はFortranで書いてるし
そもそも普段のXeon環境での計算だとやっぱりFortranの方が早い
それって例えばgccならコンパイラオプションはちゃんと-O3とか-march=nativeとか-ffast-mathとか-fomit-frame-pointerとかその他もろもろ指定してvector attributesとかも使った状態でも？
そこらへんのできるかぎりの最適化オプションは全部してるよん
だから理由がよくわからんちんだからしかたなくFortran使ってる
SPARCくんとか糞高だし、そもそも最近あんま並列効率でなくなってきて引きこもってXeon沢山繋いでるだけだからなぁ…
究極的に最適化されてるならどっちも同じ速度がでそうなもんなんだけどな
Xeon沢山繋いだPC使えるとかすっげぇ羨ましいゾ
国民の税金なんだよなぁ…
アルゴリズムの最適化とかは人手が足りなく手が回らないのが実情で少し申し訳ないとは思ってる
一応社会貢献してるから許しちくりー
日本は研究にかけるお金が少なすぎるなんて話も聞くけど、
人手が足りてないところもあるんすね〜
それより、Fortran はかなり昔の言語で既に置き換えられつつあるみたいなイメージだったけど、
今でもかなり最先端の分野で使われてるみたいでたまげたなぁ・・・
２年くらい前にワイが以前数値計算やっとったときにThe Computer Language Benchmarks Gameのコードとかを変形していくつかXeon X5650上でgcc 4.5でコンパイルしてベンチマークとったときは、vector attributes使えばだいたいCの方がFortranより速かったんやけどなぁ
今手元にXeon無いしこの追試の為だけに買うのもアレやし…
いまんとこ自分の周りでは2687v2か2690v2がメインになってるけどIntel Fortranでコンパイルしてる
The Computer Language Benchmarks Game見てみたけど配列の触り方によっちゃあCのほうが早いのもあるんだなぁ
ちなみにこの中じゃPerform an N-body simulation of the Jovian planetsが一番私がやってるものにプログラム的に近いんだけど
それだとIntel FortranのほうがCより速いみたいね…
ちなみにE5-2687v2とかE5-2690v2今たしか一つ３００ｋくらいだった気がする
なんでこんな場末のホモブログにいるのかこれもうわかんねぇな
タワーの筒みたいなマックプロ買うなら考えた方がいい
・GPGPUしますか？
GPU×２＋Xeonの不良債権の粗大ゴミ×１の構成です
一応冷えやすいからOCはしやすい
あのレベルならオイル冷OCE5ｖ２系列でもいい
液体窒素使ったXeonのｖ２のOCのほうがいい
GPGPUOCしたいにしても別にPhiでいいんじゃないの？
（金づきこむつもりならXeon Phiでもいい）
良い感じにできたらソースどっかにあげるわ
>>100ニキを発見して嬉しい
ありがとナス！
オイル冷ってのもあるのは初めて知った
ハードの話だからあんまり関係ないけど
日本だとHPCテックが売ってるらしい
浮動小数点数が満たす代数法則を纏めた文献が欲しいゾ
とりあえずこれ読むところから始めてみるゾ…
理系にありがちなんだよなぁ…
ワイの学校の授業やとプログラミング自体はほんま基礎的なことしか教えてくれへんくて、どっちかと言うとハードウェアとか論理学とか数学とかの授業のが後々役に立ったわ
10日くらい経ったけど出来ましたか？(小声)
悪意での攻撃とか考えると考慮すべきことめちゃくちゃありそう
CSRFとXSSあたり対策しとけば大丈夫大丈夫へーきへーき
1.5 の Generics のときは無理矢理後方互換持たせたくせによー
群論からしてもうすでに理解できないんだよなぁ…ｱｰﾅｷｿ
手続き脳ならアセンブリ言語、しよう！
ちなみに私は何をするにもwinAPIを叩く必要があることに気づき撃沈しました
やっぱりEffielfがナンバーワン！
最近みんなHaskellから圏論入ってる気がするからOOP全否定な空気があって
OOSCから入ったワイはいやーキツイっす(素)
でもまあプログラム導出するならBird-Meertens formalismの方が楽だし
圏論の概念モジュール化するにしてもHaskell使うと楽だし…
OOADが好きでモデリングから設計、実装を導出するのをサポートさせたいと思って圏論勉強してる
ただOOAD周りはOOP以上に失敗した歴史があるから輪をかけて辛いんだよなぁ…
Alloyなんかは関係を基礎に置いてるみたいだからallegoryで仕様の抽象化できそうな気はするけど
もしくは圏とか群とかは教わるけどプログラミングは独学だったりするのかな？
国内はよくわからんけどOxfordとかだとプログラミングへの(圏論も含んだ広い意味での)代数学の応用を研究してるグループがあるな
国内だと実践的なプログラミングからはちょっとずれるけど、計算機科学専攻の人は型理論やプログラム意味論から圏論に触れることが多いんちゃうかな
やっぱPHPって神だわ
CakePHP is not God
プログラミング関連の用語には他の略称と重複してて検索を妨害し合ってる事例が多すぎるンゴ
本物品質のiphone ケース ブランド販売市場
iphone携帯ケースコピー品提供いたします;低価格で通販。
取扱商品：↓↓↓↓
iphone ケース ブランド iphone5/5s ケース ヴィトン
iphone ケース ブランド iphone5/5s ケース シャネル
iphone ケース ブランド iphone5/5s ケース エルメス
iphone ケース ブランド iphone5/5s ケース グッチ
iphone ケース ブランド iphone5/5s ケース MCM
iphone ケース ブランド iphone5/5s ケース YSL
iphone ケース ブランド iphone5/5s ケース プラダ
ブランド風iphoneケース手帳型偽物販売市場
セキュリティ責任者 ：佐藤 順子
聯絡E-Mail:bybuy188@yahoo.co.jp
業界最高い品質ブランド 携帯 ケース専売店が送料無料
順子店舗ホームページURL: http://www.by-buy.net
質問してもええんやで？
ソシャゲとかなら別かもしれんがそこまでモバイルを意識することないけどなぁ
今日の id が XSS になったので >>120 兄貴の掲示板が無事出来たのが気になるゾ
ちなC++
出れるなら出るのは別に構わんのちゃう？
大抵の大学はまず地区予選出場者選ぶためのローカルコンテストやると思うからまずはそれ勝たんといかんと思うけど
でしか鍛えられないんですかね・・・？
協力会社とソース共有したいんだけど、自社内でサーバとかVPN環境作れそうにないから
そういうサービス使いたいんだけど、上がいい顔しないんだよねえ
押し通すかどうか迷ってる
論理立てて話すのと似てるような気もするけども
エンコーディングがEUC_JPの時点で絶許やし、API提供しないくせにHTMLガバガバで草生える
TF2とかポータルとかゲームのソースエンジンとかに詳しくなるためには
何を勉強したらいいんですかね？てかプログラム関係ある？
MAPのトリガーとかそういうの詳しくなりたいんすけど
本とかないし・・・
Hammer でマップを作りたいの？ Mod でゲームを作りたいの？
何をしたいにしろ、公式の開発者向け Wiki を読もう。
って思ってたんだよなぁ・・・
2時間格闘した結果77文字が限界でした・・・
a;main(){for(;a++<100;puts(a%5?"":"buzz"))printf(a%3?a%5?"%d":"":"fizz",a);}
料理とかいいんじゃない？(適当)
はえーすっごい・・・
自分も今度チャレンジしてみるゾ
最近各所で話されてる自動削除ツール、作れなくもないやん！って思ってたけどHTMLガバガバなんか・・・
ちなネットプログラミングは全然なんでExcelVBAのIE操作とかで考えてた
HTMLガバガバは別に頑張ればなんとかなる
問題はスレ一覧の情報を簡易取得する便利APIが無いこと
せやから全スレから個別にHTTP叩くとかいうあほみたいなことせな全スレ情報取れない
したらばほんとひで
アカン全然分からん
http://jbbs.shitaraba.net/internet/20196/subject.txt
スレ一覧の情報ってなんだか分からんが、例えばこ↑こ↓の情報から順次取るんじゃいかんのか？
見当違いのこと言ってたらスルーしてくれてええで
その情報だけでいけるんならええけど、例えば自動削除とかやりたいならスレ建てた時間とか欲しいやん？
それを取ろうとすると結局全スレ個別で取らなあかん
スレ立て時間はここに書いてあるxxx.cgiの数字がUNIX時間で対応してるっぽいで(多分)
それ以上の情報は個別に当たるしかないが・・・
あっ、ホンマ・・・
したらば全体でのトータルindexかと思ってたワイ 無能
ウイルスサイトか何か？
xhtml好き
<br /> すき
どうして xhtml2.0 じゃなくて html5 が生き残ったのか私には理解に苦しむね (ﾍﾟﾁﾍﾟﾁ)
でも<br />のほうがしっくりくると思った(XML使用者並の感想)
main(){void(*p[5])()={e,f,b,d,s};p[!(i%3)]();p[!(i%5)*2]();p[!!(i%3*i%5)*3]();puts("");p[!(i%100)*4]();i++;main();}
次は再帰を縛らなきゃ（使命感）
これもうわかんねぇな
http://i.imgur.com/20JyS2c.jpg
http://ideone.com/CWWDJV
やりますねぇ！
右肩上がりで人が増えるっぽくて嬉しいけどこのままだとAILEくんが過労死すると思った（小学生並みの感想）
SgmlReaderくんが便利そうだと思った (小並感)
まともなHTML書かないプログラマひでより嫌い
おつしゃす！
ソース中の大胆な告白はプログラマの特権
ピークで400スレ/日とかAILEくんがサボったら3日でパンクじゃないか・・・
このままだといずれ限界迎えるだろうし
ただ、移行がボトルネックになるんやろなぁ
どうなんでしょうね
いいゾ〜これ(ステマ)
はえ＾〜すっごい・・・
コンパイル時計算とか確信的スギィ！
就職する前に『ファイル管理ソフト作ってフリーで配布してました』とか『アプリ開発してました』とか、
そういうのが見つからん。ゲーム開発ってもバカにされそうだしどうすっかな〜
Functor！Applicative！Monad！Functor！Applicative！Monad！って感じ？
そもそもテンプレートメタプログラミングはErwin Unruhがチューリング完全になるまでに複雑化してしまってると批判したのがきっかけなんだよなぁ
それを聞いてテンプレート最高やんけ！ってなる標準委員会ははっきりいって異常だ
管理画面も SSL 使ってないしクラッキングをやろうと思えば (王者の風格)
でもカスタマイズ性が高まると新しいエディタでは情報が少ないのが痛い
GreaseMonkeyでしたらばくんのスレ削除画面にいろいろ情報を追記するscriptを作ってみたやで
というかスレ立て日時すらもここに載せないしたらばくんの仕様はどうかと思う
しかも一度に30個しかスレ消せない仕様とかね・・・
https://gist.github.com/john1851/d8627dc26ab3f9db847a
(連投)許してください何でもしますから!
勢い表示とソート機能を付けたゾ
稚拙なコードですまんな
自己満でやってるだけだからゆるして
でももしjsでのdom操作に自信ニキいたら色々教えてほc
うーんこの
ガバガバ削除援助スクリプト更新したんやで URL >>244
したらばくんの制約で一度に30スレまでだけど、念願の半自動削除機能を導入できた
あとは任意の判定式についてこれができればワイの自己満足も完成や
あとスコープ広い…広くない…？
反応ｳﾚｼｲ･･･ｳﾚｼｲ･･･
一理ある>分離
スコープも全然考えてなかったけど､混乱を避けるためにももっと関数に分けたほうが良いかな
リファクタリングしてみた
http://ideone.com/JoRVIA
関数は正直10行超えたら分割するくらいの気持ちでIKEA
あと、グリモンの固有API使ってないから他ブラウザのブックマークレットでも動くようになったはず(テストしたとは言ってない)
http://ideone.com/Cb9HCQ
ワイ初心者、プロのコードを前に無事死亡
JavaScriptの本をちゃんとよんで勉強しようとおもった(小並感)
今はまず257ニキのコードを眺めて勉強させていただきます
そういえばグリモンのinclude、excludeは掲示板によって違うので
shitaraba.net/*/config/data/thread_delete
にしたほうが一般化出来ますね
だから本心大して詳しくなく関心もないのにEmacsいいよEmacsとかいったりやっぱりVimがナンバーワンとか言ったりしてる
なにかにこだわりを持つ振りをして他者と意図的に衝突することでしか交流の仕方がわからんのや
いかんのか？
そういいたい気持ちは全くもってわかるんだが、そういってるやつのコードが自分よりはるか格上だと正直嫌になる
（さらに言えばそういう奴に限ってたいてい上手い）
どうでしょう
エディタ戦争はプロレスとして楽しいから仕方ないね♂
自分はより良いエディタを知れるかもって期待もあるなぁ
よって、コピペも簡単に出来ないemacsは糞(裏切り)
謙遜禁止は了解した
以後気をつける
コードゴルフする必要はないけど短くするように意識したほうがいいコードが書ける
特に1000行以下の短いやつ
ナイスでーす
そういえばJavaScriptのArray.prototype.toSourceはECMAScript標準じゃないしlatestのChromeには無いから使わない方がいいと思う
入れ子階層が一階層ならtoStringで代替できる
toSource復活して欲しいけどなー俺もなー
数値計算しかしない自分にはいや〜きついっす(素)
数値計算とか関数型の得意分野そのものじゃないですかね…
OCamlくらい構造が丸見えな言語なら慣れてなくてもヘーキヘーキ
いきなりHaskell(しかもネット上で転がってるようなポイントフリーバリバリなやつ)とか行かない限りヘーキだから
MinGWでコンパイルしようとするとavast先生がエラー報告してくれてコンパイルしたexeファイルをチェストボックスに入れてくれます。
助けてください
あと最初にCやると8割方挫折するけど頑張って
って思ってる節があるのはやっぱりC言語から入ったからなんだろうか
やVSN1
右クリ"管理者として実行(A)"をﾎﾟﾁｰであかんのか？
最近サクラエディタからVimに転換しました(練習中)
矢印キー使わないのは確かに効率良いと思う
なによりLinux系OSのサイト見てるとVimが使えるの前提で書いてあるんだよな
入力補完がfoo〜↑気持ちいい〜
これ読んで練習しますよ〜ｽﾙｽﾙ
表紙が淫夢くんみたいだとおもった(小波)
>>273
>>274
>>275
遅くなったけどありがとナス！
普通に勉強時はavastは切ろうと思います。
MinGWなのはC言語の勉強に使ってる教科書のチュートリアルではMinGWを使ってるからです！
教科書が終わったらVSにしようと思います。
あとJavaも並行して勉強してアプリゲーム開発的なのができたらいいなと思ってます。スマホもってないけど
http://i.imgur.com/ZWKzLWHl.jpg
オライリーの入門viの表紙はメガネザルくんだそうです
禍々しい雰囲気が似てますね
オライリーHPのたまに目がギョロッと動くメガネザルくんだいすき
http://www.sist.ac.jp/~suganuma/game/Java/frame/index.htm
上記のサイトのgame.htmlとGame.javaをコピペしたところなのですが、
htmlを開くとエラー：Game.classが見つかりませんとでてしまいます。
下記のソースのparam name="dir"〜の部分にGame.classが入っているフォルダの場所を直接打ち込みましたが、
アドレスの打ち方がおかしいのでしょうか？
お願いします。
<!DOCTYPE HTML>
<HTML>
<HEAD>
<TITLE>ゲーム枠の作成</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<LINK REL="stylesheet" TYPE="text/css" HREF="../../master.css">
</HEAD>
<BODY CLASS="white">
<H1 STYLE="text-align: center">ゲーム枠の作成</H1>
<P CLASS="center">
<object type="application/x-java-applet" width="410" height="310">
<param name="code" value="Game.class">
<param name="dir" value="file:/C:\Users\●●●\workspace\action_game_2\bin"> ←ここ？
</object>
</P>
</BODY>
</HTML>
http://www.sist.ac.jp/~suganuma/game/Java/frame/index.htm
にあるMainPanel、StartPanel、GamePanel、GameClearPanel、GameOverPanel を入れたら
ClassNotFoundのエラーは消えてくれましたが、（なぜだか理由は分かりません。単にHTMLでGame.classを呼び出すのに失敗しただけだと思っていたのですが、、、）
今度はunsupported major.minor version 52.0のエラーが出てきました。
なんかもうどうしたらいいのか良く分からないのでお願いします＞＜
Web系プログラミング全くの門外漢だけど
"unsupported major.minor version 52.0"ってことは、
使っているJDKだかJREのバージョンが合っていないってことじゃないの？
ありがとうございます。
"unsupported major.minor version 52.0"はどうやら
1.8でコンパイルされたデータを古い実行環境で起動すると出てくると言う事らしいですので、
実行環境はコマンドプロンプトのjava -version、javac -versionで調べてみたのですが、
それぞれ"1.8.0_11"、"1.8.0_11"
と表示されるので、実行環境は古くないはずだと思うのですが、
何か原因があるのでしょうか？
ちなみにeclipce(luna)で、
環境設定→Java→インストール済みのJRE→jre8(デフォルト)
環境設定→Java→コンパイラー→コンパイラー標準レベル→1.8
にしています。
http://www.java.com/ja/download/installed.jsp
のサイトで確認したら、なぜかバージョン7と表示されて
コントロールパネルから開いたJavaのバージョンは8とでています。
意味が分からないです。２つともアインストールするのが一番手っ取り場やいのでしょうか？
あとマルチですごめんなさい＞＜
今流行のjavascriptやって、どうぞ
オレもしかしてガチの池沼無能なのかもしれんゾ（絶望）
あとGame.javaじゃなくてGame.asだと思うゾ
カタカナ用語が多すぎィ！
>>288
ありがとうございます。eclipceはてっきり自動でjavaファイルをclassファイルにコンパイルしてくれると思ったのですが、
もしかして違うのでしょうか？
.Game.asについてですが、サイトにはGame.javaとかかれていますのでてっきりGame.javaで書いたほうがいいのかなと思いました。
後、javaをはじめてみて思ったのですが、プログラムを書く以前に、
・gif画像を読み込んでアプレット上に表示するプログラムを書いたのですが、
eclipseくんの実行アプレットだと、読み込んだgif画像を出力してくれない（たしかアプレットはローカルデータを通さないからですよね？）
・HTML（ローカル、ネット上にアップした方の両方とも）でjavaを出力しようとすると安全面関係のエラーや、"unsupported major.minor version 52.0がでて表示されない
・コントールパネルからjavaのバージョンを確認すると8なのにfirefoxで確認するとなぜか7になっている。
・そもそも他のサイトのjavaアプレットのコンテンツ(例としてスーパー正男など)の、javaのバージョンが古いためか開かない。
と正直かなりストレスが溜まったのですが、これらの現象はJavaを扱う方にとっては普通の事なのでしょうか？
おそらく私が知識不足すぎてこうなっているので、不徳のいたすところと、反省しておりますが。。。
すまぬ、何故かActionScriptの方見てた。
だからjavaファイルで問題ないゾ
申し訳ないからちょっとやってみるかなー俺もな〜
http://i.imgur.com/KrBFhFG.jpg
実行環境はwin7の64,java version "1.8.0_11",jreはjre7とjre8が入ってるね
元々java環境入ってなかったからjdk,jreは全部最新のモノ入れました
後eclipceは使ってないです
にしたらスーパー正男は動いたゾ
unsupported major.minor version 52.0については
jreを一旦全部消して新しく入れ直した方がいいかもね
（32bit版、64bit版どっちも入れよう）
ソースのhtmlのapplet codをプロジェクト名.クラス名にしたら表示できました！
ありがとナス！本当に助かりました！！
perl楽しすぎて辞められない
すごいh本読んでもわからなかった
昨日の8月15日にいつものアゴヒゲのおっさん（49歳）と先日メールくれたペンギン好きのIT土方のにいちゃん
（44歳）とわし（53歳）の3人で県東にある川の土手の下でペアプログラミングしあったぜ。
今日は明日が休みなんでコンビニでモンスターエナジーとピザを買ってから滅多に人が来ない所なんで、
そこでしこたまモンスターエナジーを飲んでからやりはじめたんや。
3人でHHKPro打ちあいながら最小構成だけになり持って来たUSBメモリを3本ずつPCに入れあった。
しばらくしたら、テキストエディタの挙動がひくひくして来るし、コンパイラがCPUの歓声を求めてマシンの中でぐるぐるしている。
アゴヒゲのおっさんに設計の穴を埋めさせながら、兄ちゃんのソースのコメントを見直してたら、
先に兄ちゃんがわしのソースに安易なgoto文をドバーっと出して来た。
それと同時におっさんもわしもエンバグしたんや。もうコード中、バグまみれや、
3人で出したバグを手で掬いながらお互いにプルリクエストを出しあったり、
goto文まみれのスパゲッティコードを放棄してテスト駆動開発したりした。ああ〜〜たまらねえぜ。
しばらくやりまくってから又テストを走らせるともう気が狂う程気持ちええんじゃ。
アゴヒゲのおっさんのソースにわしのオレオレ言語処理系を突うずるっ込んでやると
S式がBrainfuckと圏論でずるずるして気持ちが良い。
にいちゃんもおっさんのコードにDSL突っ込んでマイナー言語をつかって居る。
コピペまみれのおっさんのソースを添削しながら、思い切りGPL汚染したんや。
それからは、もうめちゃくちゃにおっさんと兄ちゃんの自作ライブラリを使いあい、
バグを潰しあい、二回もカーネルパニックを出した。もう一度やりたいぜ。
やはり大勢で計算機まみれになると最高やで。こんな、変態親父とバグあそびしないか。
ああ〜〜早くバグまみれになろうぜ。
松江市であえる奴なら最高や。わしはA3*5A*35,おっさんはA5*4B*3C、や
バグまみれで勉強会やりたいやつ、至急、pgpでメールくれや。
rootのまま作業して、本番環境で rm -rf / の実験やろうや。
http://bjorn.tipling.com/if-programming-languages-were-weapons
>>3
申し訳ないが故人を生き返らせるのは NG
大惨事じゃないか（憤怒）
もう終わりだぁ！誰か助けて！（切実）
ＵＳＢをパソコンに差し込んでも反応せんのです…
いつもだと「ﾃﾞﾛﾝｯ」って鳴って読み込んでくれるんやけど、認識すらされない状態
ほかのＵＳＢを指しても反応なしだし、再起動やらを何度か試してみても効果なし
一回だけ復活した（ためしにＰＳＰくんを指す→反応あり→よっしゃ！大丈夫やんけ！→一回抜いて指しなおす→反応なし）から物理的に死んでるわけじゃないみたいです
ちなみにiphoneに入ってる写真の資料をＰＣに転送するのが目的です
他のプログラマニキはどう思うでしょう
ワイはにわかやからね許してね
あっ、そっかぁ…
ちなみに ＰＳＰで反応→ＰＳＰﾇｷｰｱｲﾌｫﾝｸﾞｻｰ→反応なし→ＰＳＰﾓｯｶｲｸﾞｻｰ→反応なし って感じです
こっちこそ手間かけさせちゃって申し訳ないです
>>315>>316
多田野写真じゃなくて、会社でつかうクッソ重要なデータだからなぁ…
つい最近クラウド系で事件が起きたっていうし怖いです…（小声）
中途半端に挿したり傾けたりしても無反応ですか？
何度かやってみたけど駄目でした…（小声）
iphoneくんのケーブルはちゃんと充電できるし、その可能性は低いと思うで
まぁこのままじゃアレやし、メールで一枚ずつ送ることにしますわ みなさん手間かけてすいませんでした
もはや関数すらいらないと思う
リストだけでチューリング完全になる気がする
(NG機能と外部板登録ができて化けずに書ける専ブラが見つから) ないです。
やっぱりUTF-8がナンバーワン！
論文？なんのこったよ（すっとぼけ）
でも他の人からも愛されすぎてて、プラグインくんたちと一緒に使うと
よく衝突するのがつらい
よいこのみんなは気をつけようね！
逆に遅くなるんか...
怖いなーとづまりすとこ
ワイは好きです(半ギレ)
岡崎市立中央図書館「君が、マンボウくんだね？」
気が向いたら一日限りで動作させても…バレへんか
え何それは(興味)
見たーいー見たーいー
ぺるりさん？
子飼とLinusとゆきひろを連想して草を禁じえない
それよりしたらばってどうやって書き込んだらいいんですかね？
bbs.cgiとかにPostすればいいのはわかるけどどこにbbs.cgiあるか分からなくてあー泣きそ
関数名をtypoしエンバグしたのは明白
それを後付けでリンクするまで実在するかどうかわからない、
コンパイラの騒ぎを知らない、という言い訳がまかり通れば何でもアリの無法地帯になってしまう。
はっきり言って実装者や擁護者の意見反論でも何でもなく、屁理屈の域を出ないよ。
実装者(>>204)はゴネてないで謝罪した方がいい
しっかり罪を認識しなさい。
はっきりいってバグ曲線の威を借りエンバグを正当化する今のNaNじぇいは異常だ。
今回の件が社内Wikiで公になり実装者が反省して、バグがなくなることを切に望む。
Matz is Jesus Christ.
それこそ今のNaNじぇいに必要なものじゃないですかね？
どうやってまとめるかではなく、どうやってスレを保存して使えるようにするかが問題になってるっぽいですし
したらばの仕様って検索しても見つからんのやけどdatをread.cgiがhtml化しとるんやないの？(無知)
したらば側が出してるのか
どうなんでしょうかね？
過去ログ送りにされたスレは HTML 化されてそれっきり・・・って感じじゃないですかね・・・？
まあ個人的なプログラミングの練習ゥ・・・でやってた可能性も微レ存だけど
でもAILEくんが少しでも楽になるなら何か協力したいけどなー俺もなー
見た感じ2chのライブラリもなさそうだし
文字コードの問題があるけど両対応のやつ作ったら結構ありがたがられると思うゾ
じゃけん作ってgithubにあげますよ〜イクイク…ヌッ！（失踪）
ノンケ に 1919 の ダメージ
次は書き込みに対応させますよ〜書く書く…ファッ！？（エラー）
クッキー☆が関係するわけでもなさそうだしこれもうわかんねぇな
外部からの書き込み禁止はOFFになっているのかな？
IEなどのブラウザを内部で走らせてるんですかね？（無知）
UAもリファラもHOSTも設定したがだめだったゾ
言語はrubyでまだif 文とか配列レベルのマンボウです…
中身の有用性は知らないですが…
http://paiza.hatenablog.com/entries/2014/11/19
あとこの逆引きRubyというサイトもいいゾ〜これ
http://www.namaraii.com/rubytips/?FrontPage
プログラム自体が初心者だから勉強することから勉強するゾ