はてなキーワード: Pythonとは
10 :名無しさん@お腹いっぱい。[sage] 投稿日:2010-07-08 14:19:43 ID:4+wg75AQ0
シビアなキーカスタマイズが絡む場合は、AHKかkeyhacのPython使うほうがいいかもしれない。
キー操作が絡んで、かつ速度を求めないなら、AHKやkeyhacからWSHやAutoITのスクリプトを走らせてもいい。
AutoItXはWSHから使えるのが便利なところ。素のAutoItのGUIの部分は使えんけど。
GUI使いたきゃ、HTAから使ってもいいし、ほかのDLL使ってもいい。
SFCminiのDLLとSeraphyのDLLまで使えば、UWSCやAutoHotKeyとほぼ同等のことを
javascriptやVbscriptの文法で出来てしまう。
テキストエディタなどWSHやdmscriptを使えるアプリのマクロからも、
他のアプリを制御したり、他のアプリのウィンドウの情報を取ってくることが簡単になる。
もちろん、出来ないことも大いけども。
いちいちコマンドラインツールを探さなくても、とりあえず今使ってるアプリを
スクリプトから制御することが簡単になる。
それは Python の実装による
stackless pypy では tail recursion の最適化は実装された
C# は趣味というか私生活で必用な時にしか使ってないです。他の方の意見を聞いたほうがいいと思う。趣味でやってる感想としては、まず過去のどろどろがないのがいい。標準ライブラリだけで殆ど足りちゃうのも初心者にありがたい。あたらめて考えてみると初心者に対する敷居は低いなあ。
作りたいものが明確なら結果への近道になる言語なのは確かなんですけど、プログラミングで何をしたらいいかわからないからプログラミング言語を知りたいという段階の人には薦めにくいかなあ。前記事で Python 薦めたのは元増田さんがそういう段階だからです。
関数型言語も趣味レベルでしかやってないです。関数型言語とは違うけど SQL は仕事で毎日使ってる。むかーし Haskell ぶんなげて、SQL 使ってたらなんかひらめきがきて、それから結構わかるようになった。(ようなきがする)関数型言語って独特の脳汁でるんだよね・・・難しい SQL 弄ってるときも同じ脳汁が出る。関数型っぽい脳みその使い方は他の関数型じゃない言語でもできるし気持ちいい。関数型言語自体は触った時間短いけど、ああいう脳みその使い方はすごく武器になると思います。
http://anond.hatelabo.jp/20100725025127
"どうすればいいか"を教わって、プログラミングが身につく人は多くありません。"なにをやりたいのか"を自分で生み出せないと、詰まってしまうし、なにより楽しくありません。
やりたいことがあれば手段は後からついてきます。これは物作り全般に言えることです。特に学び始めにおいてモチベーションを維持し勢いをつけるのに大事なのは"やりたいことがあるか"、もっと具体的に言うなら"作りたいものは何か"です。これがないと始まりません。それがどうしてもないなら、そういう状況に自分を追い込むのも有効です。仕事でどうしてもやり遂げなければならない状況に追い込まれれば人間 0 からでも身につきます。実際自分がそうでした。
とかく、プログラミングというのは手段さえ知れば、あとはだれがやっても同じ結果が出る生産業だと誤解されがちです。そういう認識で学ぼうとしても楽しくありませんし、本質を掴みにくいので応用が利かなく上達しにくいです。
本質は絵や音楽と同じです。言語を覚えるということは道具の使い方を覚えることでしかありません。音楽の理論や絵筆の使い方を知っているだけで、すぐに素晴らしい音楽や絵ができるでしょうか。殆どの人がそうは思わないはずです。プログラミングもそれと同じです。作りたいものがある人が圧倒的に強いのです。
んー、ここまで読んでも「やりたいことはないけどとりあえず勉強したい」というなら、すぐに動くものをつくりやすい言語がお勧めかなあ。
Google App Engine で Python をやるとか。 Python のいいところは、明快で作法にあまり迷わなくていいところです。自分がまったく言語やったことない知り合いにすすめるとしたらこれ。
レガシーではないちゃんとした JavaScript (http://www.crockford.com/javascript/ この辺にあるような) もいいです。ブラウザですぐ動きますし、 Firefox 環境なら本格的なデバッガまであります。 JavaScript は非常に誤解の多い言語ですが、悪いものではありません。 お手軽にグラフィカルなものを扱える、結果がわかりやすいので初心者向けです。それでいて、拡張性が高く、プログラミングに必要な概念、ロジックの殆ど再現できる底力も秘めています。
Perl はレガシーな作法がいまだに見受けられる (Perl って CGI のことでしょ的な解説が未だにある) のですが、初めから strict に慣れて、 CPAN にあるようなスタイルを参考にして、初めから OOP に突っ走るなら今からやってもいい言語です。 CPAN 等のリソースの豊富さとコミュニティの広さが強いです。ただ、懐の広さ、できることの多さゆえに初心者向きではないところもあります。
PHP はお勧めしません。理由は適当に検索してください。 PHP5 でかなり良くなりましたが、逆に言えば 4 と 5 では別言語と言っても良いほどです。古い考え方と新しいスタイルがごったになりすぎていて、かつて同じような状況にあった Perl に比べても、洗練されたスタイルを学びにくいと思います。また、ロジックの面白さに感動するような部分が PHP にはちょっと足りないです。
MMORPG やそのエミュレーターの中には、 Lua を使って AI やマクロやイベントスクリプトなどを組めるものがあります。すぐに結果が出て自分の役に立つものが作れるので、既にその手のゲームが趣味ならお勧めです。こうした用途では、自分の望む世界を構築するために嫌でも物事をモデル化して考えるので、自然と OOP 的な考え方やデザインパターンが身につきます。
VB は簡単に GUI アプリケーションが作れるのでやる人が多いですが、癖が強いし応用がききにくいのでお勧めしません。また、公開されているソースコードが少ないことも学ぶには不便です。
Ruby はそれほどやりこんでないのでコメントはしないでおきますが、悪くはないと思います。
C++ は何をすればいいのか?を聞いてる人にはすすめにくいです。作りたいものが明確にあり、ロジックを見つけることで応用が利く人ならほっといても覚えるでしょう。自分は、必要に迫られて身につきましたが・・・
個人的には、作りたいものがあってそれにマッチしてるなら、関数型言語を最初にやったっていいと思います。一度ロジックを掴み取る能力がついてしまえば、第二第三の言語は猛スピードで身につくので。
作ったものを公開して、人に見せたり使わせたりして、レスポンスを得るというのはモチベーションの維持や上達に非常に有効です。むしろ、早く上達したいなら必須と言ってもよいです。プログラミングの場合はこれがおざなりにされがちです。
絵を上達したいなら、 pixiv を薦められますよね。今下手かどうかは関係ない。上手くなりたい人が沢山投稿してる。歌が上手くなりたいなら、人前で歌う事は避けられない。ニコニコ動画などで公開してる人がいるよね。人の作品をみると刺激をうける。これはすごいパワーだってのはわかると思う。
プログラミングだって全く同じです。なのに、プログラミングは引きこもって一人で勉強する人が多すぎる。絵や歌は公開しても人に害を与えないけど、プログラミングはバグやセキュリティホールがあったら人に害をあたえるかもしれない、といった印象が強いのかもしれません。
それでも、もっとコミュニティに参加したり、作ったものを公開することが学び始めのうちから重視されていいのは事実。そういった面から考えると、バグやセキュリティホールが出来にくく、安全で、危険な動作がしようもない実行環境があり、加えて Web に公開しやすい言語が学びはじめに向いています。
こちらも参考にしてみて下さい
http://d.hatena.ne.jp/Hamachiya2/20090721
http://d.hatena.ne.jp/Hamachiya2/20080131
学校に行けば一人で学ぶよりは後押しや出会いがあるかもしれませんが、”やりたいこと””必用なこと””作りたいもの”が無い限り、殆どの人は身につきません。
また、残念なことに講師にも大変当たり外れが多いです。自分は専門学校にいったことはありませんが、講師の知り合いがいるのでよく学生さんの話を聞きます。結局の所、しっかり身につく人は、家に帰っても色々作りたいものを作って公開したり、著名なプログラマ達のブログを読みまくったり、フォーラムに出入りしたり、ML に入ってたり、 twitter で刺激的な知り合いをつくるとかしていて、そういうところでめっちゃ差がつきます。
学校に行くなとまでは言いませんが、学校いかないで身に付ける人は本当に多いし、学校いって身につかない人も本当に多いということは考えて下さい。
元増田さんがどの言語をやれば・・という方だったので仕方なくこのような書き方になってしまいましたが、作りたいものが既にある人はあまり”どの言語をやるか”には拘らなくてよいと思います。
そんなことよりも、今必用で/気軽に/すぐ結果がわかることをやるのが、始めてのプログラミングには大事。だから本当は、どの言語をやるかよりも何を作りたいのかを先に見つけてほしい。
目の前の意外なところにプログラミングは生かせます。できるだけ身近な、すぐ効果がわかるところからとりかかった方がプログラミングの楽しさにはやく気付けるはず。
みたいな導入口でもいいんだ。
例えば C++ でのプログラミングを初心者が 0 からやるのは難しいだろうけど、既存のアプリケーションのプラグインなら開発のためのテンプレートや目的に近い作例があってコードも短いからそれを改造するところから始められる。需要があるから楽しいよ。
オブジェクトのシリアライズツールであるプロトコルバッファについて書きます。
Protocol Buffers 本家
http://code.google.com/apis/protocolbuffers/
XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」
http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html
Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)
http://dodgson.org/omo/t/?date=20080712
プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。
独自の言語によりオブジェクトのインターフェースを規定することで、多言語対応を行っています。
例えばこんな感じ。
package tutorial; message Person { required string name = 1; required int32 id = 2; // Unique ID number for this person. optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } // Our address book file is just one of these. message AddressBook { repeated Person person = 1; }
以上のようなprotoファイルから各言語のソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。
googleによってC++, Java, Python用のライブラリが作成されましたが、他の言語に対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。
数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合は符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。
バイナリに保存されるデータは各メッセージのID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。
またオブジェクトを連続でシリアライズ/デシリアライズすることもできます。
すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。
(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)
message PbBase { require int32 id = 1; require int32 value = 2; require Derived derived = 10; // - Point !!! } message PbDerived { require string string_value = 1; }
継承元のメッセージの定義に、継承先のメッセージを持たせます。Baseを継承するクラスをシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。
例えばこんな感じ
Base *Base_DeserializeFrom(PbBase &pbobj) { // Arrange the classes which inherits from Base. if (pbobj.has_derived()) { return new Derived(pbobj); } else ... } class Base { ... virtual void Base::SerializeTo(PbBase &pbobj) { // Set the fields of 'pbobj', } ... }; class Derived { ... virtual void Base::SerializeTo(PbBase &pbobj) { PbDerived *derived = pbobj.mutable_derived(); Base::SerializeTo(pbobj); // Set the fields of 'derived', ... } ... };
protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。
message PbBase { require int32 id = 1; require int32 value = 2; } message PbDerived { required PbBase base = 1; // - Here is the point !!! require string string_value = 2; }
募集要項
・運営ツールの開発
求める経験
【必須経験】
・C/C++、perl、Ruby、Python、PHPなどを用いたプログラム開発経験
【歓迎経験】
C/C++, Perl, Ruby, Python, PHP全部使ったことあるよ!
PythonとPHPは仕事では使ったことないから微妙だけど。あとC++の言語仕様は完璧には把握できてないけど。
でもC/C++は商用のコンパイラを作るプロジェクトに参加してたこともあるしバッチリだよ。
Rubyは1.6の頃にインタプリタのソース全部読んだりしたけど最近の進化にはついていけてないかも。
【歓迎スキル】
・MySQL、PostgreSQL等のRDBMSに関する知識
このへんも全部あるよバッチリ。
そんなものは求められてないだろうけど、
RDBMSも3Dも仮に一から自分で全部作れと言われても簡単なものなら作れるレベルだよ。
しかし…
「ツイッター信者」にその素晴らしさを熱く語られたときの平和で適当なかわし方|石原壮一郎「大人のネットマナー教室」
http://diamond.jp/articles/-/7884
-----------------------------------------------------------------------------------------------
クラウドほど、経営層の人と現場の人との温度差が激しいIT用語はないと言えるでしょう。
経営層やCIOの人の中には、「クラウドの素晴らしいビジネスチャンスをもっとうちにも取り入れなければ!」という危機感を抱いて、
ことあるごとに現場の人への啓蒙活動に励もうとする“信者”が少なくありません。
その博愛の気持ちは尊いといえば尊いのですが、現場の人がさほどクラウドによるビジネスにメリットを感じない場合は、
どう対処していいのか困ります。今日も全国各地で、クラウド信者の経営層の熱い講釈を受けて、
尻を叩かれる現場の側が苦笑いを浮かべているという構図が繰り広げられていることでしょう。
自社がクラウド事業に参入することにさほどメリットを感じない側のあなたが、そういう災難にあったときはどう対処すればいいのか。
程度の差こそあれ、クラウドを熱く勧めたがる信者のみなさんは、「クラウドによってもたらされる新たなビジネスチャンス」を信じ、
そんなクラウドの知見を人より早く深めていることに、ちょっぴり優越感を抱いていると言えるでしょう。
どう見ても熱が入りすぎている人の中には、クラウドに過大な望みを託して、
いまいち不本意な会社の現状から自分達を救い出してくれる救世主のように見ているように思えるケースもあります。
いや、あくまで極端な例をあげているだけなので、「俺は違う!」とムキにならないでください。
もちろん、私の周囲のクラウド好きの経営層やCIOや上司に対して、私がそういう目を向けているわけでもありません。
今後の人間関係を考慮した言い訳で話がそれましたが、クラウドを熱く勧めてくる人にとって、
クラウドにはまっていることが誇りであることは確か。何はさておき、そこを見逃さないようにしましょう。
たとえば、最近クラウドにはまっている経営層や上司に、「うちも取組んだほうがいいだろう」と熱心に勧められたとします。
自分の会社がクラウド事業に参入する必要性を説かれても、いまいちピンと来ないからといって、
「うーん、よくわかんないですねえ。コアコンピタンスなシステムをみんなが勝手にリソースを食い合いしている共用環境に置くなんて
なんか気持ち悪い世界のようにも思えるんですが」
「柔軟にリソースを拡充できるっていっても、ハードを跨って分散処理できるシステムならともかく、
結局リソースプ-ルの上限内の話ですよね。なんか嘘っぽいですね」
などと、偉大なる「クラウド様」の仕組みを否定する言い方をしてしまうのは危険すぎます。
ムキになってさらに熱く語ってくるぐらいならまだしも、「ハァ~」と深いため息をつきながら、
救いがたいダメ社員を見るような目を向けてくるかもしれません。
まあ、わかり合えなくてもべつにいいといえばいいんですけど、経営層や上司に悪い感情を抱かれたり、
異動のきっかけになるのは避けたいところです。
向こうだって、今の時期たまたまクラウドにはまっているだけで、けっして悪気があるわけじゃないし、
SOAのことを忘れてしまったわけでも、人間として何かを失ってしまったわけでもありません。
一生懸命にクラウドの魅力を語ってくれたら、たとえピンと来なくても、
「なるほど、そういうふうにインフラ環境を意識せずにインターネットでつながるっていうのも、ユニークな考え方ですね」
と、独自性に衝撃を受けたかのような反応をしておくのが、大人の包容力であり相手をそれなりに満足させるマナーです。
そういうふうに言えば喜ぶのはわかっていても、まるでその相手までホメるみたいで抵抗がある場合は、質問に逃げましょう。
「仮想化によるサーバ統合とか、ホスティングとか、WEB2.0とか、データセンターにアウトソーシングするのとはどう違うんですか?」
と、クラウドの旧称を持ち出してきて、クラウドの優位性をさらに語らせるもよし、
「なんか利用分だけ請求する従量制課金にして、結果、利益率の低くなるのをスケールメリットで吸収しないといけないんですよね?」
そんな歪んだ先入観丸出しの誤解(じゃないけどな)をわざとぶつけて、ひとしきり説明させるもよし。
いずれにせよ、無理無理と思っている気持ちを覆い隠したまま、相手にそれなりの満足を覚えてもらうことができます。
まったくクラウドに興味がないわけではなく、ちょっと前に自社製品をSaaSやASP化してやってみたけど、
全然受注できなくて放置してあるケースも、けっこう多そうです。
そういう状態にあるあなたに、はまっている上司や経営層が例によって熱い口調で、
「まずは、機能限定の無償版をいろんなユーザーに提供してみると、フリーミアムの凄さがわかるよ」
「何でもいいからどんどん無償提供すれば、そのうち有償版にアップグレードする客がでてきて利益がでるよ」
とフリーミアム教、じゃなかった、クラウド教、じゃなかった、クラウド界における定番の説得フレーズを説いてきたとします。
「ほお、そうなんですね。今期の研究課題として取組んでみます」
と適当に納得しておくのはいいとして、つい勢いで、
「しかし、ずっぽりはまってますねー。クラウドの話をするときは生き生きされてますし」
などと冷やかしてしまわないように気をつけましょう。
はまっている上司や経営層は、誇らしさの裏側に、多くは無自覚にですけど、
「自社の戦略に自信がなくてクラウドにすがっているように見えるんじゃないか」
「競争力が欠如した製品をクラウドの冠で紛らわそうとしているように見えるんじゃないか」
といった不安を抱えています。
何気ない冷やかしが引き金になって、心の奥の地雷を踏んでしまいかねません。
そこまでややこしい話じゃなくても、はまりっぷりを感心するセリフの裏側に、
「よっぽどヒマなんだな」
「丸投げばっかりで、手動かしてるの外注ばっかりで、Hello Worldぐらいしかプログラム作れないうちの生産部隊が
どうやってフレームワーク備えたPaaSなんか構築するんだよ」
なんせ今までビジネスセンスではなく社内の空気を読む根回しセンスで出世してきた経営層や上司だけに、
仮にビジネスセンスのないことに対してカケラも自覚がなかったとしても
(カケラも思っていないケースは稀ですがビジネスセンスがないことは稀ではないでしょう)、
相手はそう受け取るでしょう。
はまりっぷりに対しては、ひたすら、
と前向きな返事をすることが無難であり、相手に対する大人のやさしさ。単なるおためごかしではなく、
そのセリフを聞いたときの上司の満足そうな表情を見ることで、社畜としての深い喜びも味わえるでしょう。
仮に、クラウドの話題をきっかけに経営層や上司との距離を縮めたいなら、その場の口先だけではなく、次に顔を合わせたときに、
「あれから、SalesForceとかGoogle AppsとかAzureとかAmazon WSとか、試験導入してPythonやJavaでHello World作ってみましたよ」
と具体的な実績を話せばバッチリです。
熱く勧めてきた上司や経営層が、特に自分の進級昇格を左右する人物だったりした場合は、
とりあえず勧められたとおりにやってみて、クラウドの魔力に魅せられたフリをしましょう。
「やってみると使えますねー。勧めてもらってよかったです」
とまで言っておけば、さらに完璧。
たとえ動機が不純でも、それをきっかけに部内から企画をあげたという実績ができればこっちのものだし、
上司としてはこの上ない喜びを……おっと、結局、経営層へのご機嫌取りという本音が出てしまいました。
曖昧な立場で書いてきましたが、私は何を隠そう、嫌々クラウド事業に取組んでいる社畜のひとりです。
スケールメリットなんか出せねえんだから競争力ある価格設定なんか無理、
無理矢理仮想化しなくても安いサーバで提供すりゃいいんじゃねーの?
そもそも高い人件費のプロパー使ってレンタルサーバ屋と競争してどうすんのよ?
とかいう会社じゃ言えない本音に悶々としながら、仕事中にこっそり書かせていただきました。
そんなことを踏まえつつ、それぞれの立場や環境に応じてお役立ていただければ幸いです。
※
次回も、引き続きクラウドをテーマにしてみたいと思います。(嘘)
今期の事業戦略などで、「クラウド事業への取組み」なんつーキーワードが出始めた場合の対処法や、
自分に企画立案を振られた場合の振る舞い方について考えてみましょう。
■今回のマナー
「クラウド信者」が抱える誇らしさと不安――その両方を見逃すべからず
全然かわせてねー!なんか立案しないとマズい
明日から本気出す
pypy速すぎ
あとIronPythonとJRubyの差が気になる
JRubyはyarvより速いのにIronPythonはCPythonや3000より遅いとか
Python PyPy 12.69 12.69 20.31 30.65 41.66 73.69 118.86
Ruby JRuby 14.21 14.21 20.00 37.56 76.59 161.48 295.72
Python 3 2.27 2.27 14.21 53.01 100.11 149.65 149.65
Ruby 1.9 9.39 9.39 19.80 58.50 130.45 296.42 404.99
Python CPython 2.24 2.24 13.14 61.67 80.65 130.62 130.62
Python IronPython 48.19 48.19 50.62 76.98 174.71 223.45 223.45
Perl 2.58 2.58 13.80 81.72 117.79 240.24 240.24
PHP 6.40 6.40 41.85 134.00 179.84 250.72 250.72
規制されてた。規制中でも書ける板で代行スレ使おうと思ったらBBQ焼かれてた。BBQ解除してもらおうと思ったら規制されてて書けない。なにこれ。
もういい。ここでレスする。どうせきづかれねーだろうが。
http://pc12.2ch.net/test/read.cgi/tech/1264745386/
俺が>>936なわけだが、単に俺はQtでのPythonとC++の相互利用を知りたかっただけなのだが、明後日の方向にレスが伸びてて残念だ。
コンパイル速度以外の観点からも、そうできたらうれしいと思ってるんだけど、コンパイルしなくていいってだけで十分じゃないの。
>>952
Pythonでも他の言語でも、速度面でシビアなところだけをC/C++で書くというのは一般的に行われている。
それを無視して最初から全部C++で、とか言ってる方がよほど偏愛だと思うけどねぇ。
| インタープリタ言語にはインタープリタ言語の得意分野がある。
何でもとりあえず手軽に書いてみて、後で必要ならC/C++に移植ってのも、インタープリタ言語の得意分野だよ。
実行の遅さも、C++より重いことは確かだが、そうはいっても特に重い処理の入ってない部品だと人が使ってて分かるほどの違いなんてないよ。
そこまで速度にシビアな局面ならQt使うってのが間違ってるんじゃない?例えばQtのウリの1つのシグナルとスロット機能は公式ドキュメントには、
普通に呼び出すよりも遅い。とはいえ普通の用途では気にならないから有益って書いてあるよ。これはインタプリタ言語使いがよくする言い訳と同じものだね。
http://doc.trolltech.com/4.6/signalsandslots.html
| だいたいあんたC++や本格的なRADツールの体験はどれだけあるの?
| いままで書いた最も大きなプログラムってどんなもの?
これはあまりにも愚問。それを必要としてない人にそれを要求してどうする。
ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明
win32apiを学ぶ 多すぎて?状態で挫折
ゲーム作るのはあきらめよう!チートだ! アセンブリが面倒で挫折
向き不向きってあるよね・・・。もう勉強したくない・・・。
俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん
俺の読んだ本
明快C言語 ダイテルC言語(例題飛ばしたのでほとんど意味なし) やさしいC 独習C
windowsゲームプログラミング(最後のテトリスとブロック崩しが面倒で飛ばした)
独習java(ガベージあたりで挫折) windows32api徹底理解 ホームページ作成の本(名前失念)
アセンブリ言語の教科書(100ページあたりでソースを読み解くのが・・・以下略)
何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う
じゃあweb関連や初心者用言語(php,ruby,pythonとか)学べばいいじゃんってネットで指摘されたんだけどさ
そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし
今roboformのようなもの作りたいんだけどどうつくったらいいんだろ(guiは無理なのでコンソールで)
perlとかruby,phpで記述して通信プロトコルの勉強すればできるんだと思うんだけど俺にはもう体力が残ってない
あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリもごまんとあるうえに通信プロトコルも勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて
最初 Python で、Haskell における dropWhile のような関数があるかを調べようとした。
これはたまたま、Pythonにも同名の関数があるので (itertools.dropwhile) google で検索すればよかった。
しかし一般に「述語関数が真になるまで、リストの先頭から順番に要素を捨てていく」関数はどうやって探せばいいのだろうか?
Haskell なら、述語関数とリストからリストへの関数なので、(a -> Bool) -> [a] -> [a] を hoogle (http://www.haskell.org/hoogle/) で検索する。takeWhile dropWhile filter の3つが見付かり、それぞれ説明を見ればいい。
Python ではどうやって探すのがはやいのか?Javaなら?C++なら?
ちょっとしたプログラムを Python で書くとこんなところでイライラしてしまって結局 Haskell を使ってしまう。
Perl基礎文法最速マスター - Perl入門〜サンプルコードによるPerl入門〜
http://d.hatena.ne.jp/perlcodesample/20091226/1264257759]
Route 477 - Ruby基礎文法最速マスター - , 1. 基礎 , 2. 数値 , 3. 文字列 , 4. 配列 , 5. ハッシュ , 6. 制御文 , 7. サブルーチン , 8. ファイル入出力 , 知っておいた方がよい文法 , 余談 , (おまけ)Ruby書籍紹介
http://route477.net/d/?date=20100125]
http://www.1x1.jp/blog/2010/01/php-basic-syntax.html]
http://d.hatena.ne.jp/dplusplus/20100126/p1]
昔勤めてた会社の人が「年にひとつぐらいは(仕事以外で)新しい言語、フレームワークに触れるといいよ」みたいなことを言っていたのでこれを機に(正直好きではなかった)Perlもはじめてみようかなと。
Java基礎文法最速マスター - 何かしらの言語による記述を解析する日記
http://d.hatena.ne.jp/nattou_curry_2/20100130/1264821094]
LLじゃないのも出てきたので改題。このへんいっぱつで Mece になるようにできないのがしょぼいなー。
ところで増田ではカギ括弧でくくってもリンクが正しく認識されないしhttp記法のタイトルもリンクにならないしイケてないのなんとかできないのかな。
google app engineに繋がらない。
signinすら出来ない。
googleにメールを送っても返事が無い。金曜の夜から24時間ぶっとおしで、もう30通は送ったはずだ。仕事してんのか?
ハードが目の前にありさえすれば、なんとかやりくりできるのによ。最期の時には、全部俺様の過ちだと納得もできようよ。しかしクラウドはどうだ。何だこのざまは!何もかもが雲の中だ!誰が何を間違ったのかさっぱり分からない!俺様の目の前でバックアップをとっていないHitachiのHDDがガチャンと音を立ててクラッシュしてくれる方がまだマシだ!!!!!
くそくそくそくそくそくそくそjそうkすおl¥くdさくldfggoogleappengineの た め だ け に 携帯を買ったんだぞ畜生!!!!!金返せ!!!!!1もうだめだ!!!!!クラウドはクソだ!!!クソの山だ!!!!!こんなものを良い方向に評価できなくたって、俺様は天才プログラマなんだよ!!!!!!!!ああああああああおhんwzそえfどい:@-2s;
今後!!!!!俺え様の目の前でクラウドとうう言葉を使った奴はぶん殴る!!!いいな!!!!!!!!えろいsdfgzjlk;あd
まあpythonはgoogle公認だから本質的にウンコ程度の価値しかないから俺様はこいつとおさらばできてせいせいする。javaはまともだから、本腰を入れて何か作ってみるか。しかしやはり俺様に合っているのはネイティブコードを吐くコンパイラの揃っている言語、C++やDだ。何でもできる。OSをぶっ壊すことすらできる。OSは一度壊してからが美味い。googleappengineとは全く対照的だ。googleappをいくらグズグズとファックしようとしても、所詮はpyだ。せいぜい砂場の上でウンコするだけだ。他には何もできやしない。gccは無いのかとまさぐろうとしたが、さっぱりまさぐれない。ISPのCGI鯖ならこっそりgcc使える所もあったのに。そういう点でもgoogleはウンコだ。ユーザーの要望をまったく理解していない。googleappengiんで動いてる有名なサービスってあったっけ?wwどれもこれもただのチンポコだろtukau使う価値もないwしかし携帯もかってみたけどクソだなemacsもうごかないマシンもちあるいてみんな楽しいか?こんなちいいさい画面でこーど書きたいのか?こんなのただのうんこじゃんwwwほりえもんもiphonにむちゅうらしいけどていどがしれるなwwうんこしながらめーるかけるからべんりwwwうんこうんこww
!という、コンパイルできなくても
!あん