  |
はてなキーワード: oopとは
http://mizchi.hatenablog.com/entry/2018/07/31/124354
念の為言っておきますがOOPの呪いについては特に異論はありません。
古いJavaのような、クラスにしかメソッドが所属できないモジュールシステムばかりの時代じゃありません。 クラスは基本的に不要だと思います
Javaは今でも「クラスにしかメソッドが所属できないモジュールシステム」でしょ。クラスに属していないように見えるのは糖衣構文に過ぎない。
https://twitter.com/mizchi/status/1024103868613812225]
オブジェクト指向の呪い、ほとんどの言語のモジュールシステムでは関数参照がそのままexportできるのに、すべての関数を static メソッドまたはクラスメソッドとして表現する人が未だに多く、見るたびに指摘してる…
関数参照ってなんですか?「exportする」ってそんなに一般的ではない気がする。
もしfunctionオブジェクトをimportするのを指しているのならば、所詮オブジェクトなので状態が含まれない保証はない。
https://twitter.com/mizchi/status/1024104303907065856]
そりゃJSみたいに柔軟なインポートができる言語ばかりじゃないし…
https://twitter.com/mizchi/status/1024151165703938048]
JSの似非OOP慣習と向き合うのに class の導入は必要だったと思うけど、それはそれとして class 使わないのは別
これはそう。結果論的にはclassそもそも導入されるべきではなかった気もするけど。
https://twitter.com/mizchi/status/1024155163399876609]
Dijkstraのijkが好き
めちゃくちゃわかる
湧いてきたら追加する
Haskell を書いてるわけではないんだけど Haskell でメモ化したい関数ってどうするんだろう
という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った
純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう
しかしながら
と思ったのですがどうなんでしょう。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず。
まずは、あなた自身がプログラマーになって、見本を見せることが第１歩です。
その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。
鬱病気味になったみたい...。
どうやら、プログラミングという仕事の特徴について、あなたは理解していないようですね？
プログラミングの特徴は、「コンピューターが相手なので、嘘やハッタリが一切通用しない」ということです。
人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。
という3点が必要です。
警察に職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています。
(例)本の虫: 麻布十番で職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html
プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています。
小さな部品がパズルのピースに相当して、大きなシステムがパズルの完成品です。
つまり、大きな問題を小さな問題に分解して、１つずつ順番に問題をつぶして行く姿勢が必要です。
があります。
命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的に鬱病を発症しやすくなるだろうと危惧しています。
上述のように、パズルのピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。
関数型プログラミングを習得するために、今なら「Haskell」または「OCaml」というプログラミング言語をお勧めします。
HaskellやOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。
Haskellを学んでみて、パズルのピースを組み合わせる感覚が理解できたら、あなたはテスト地獄に苦しめられないプログラマーになれるでしょう。
もしも、Haskellが理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。
（例外的に、あなたがマゾで、テスト地獄や残業、徹夜が楽しいと思える性格なら、Haskellが理解できなくても大丈夫かもしれません。）
Haskellの教材（英語）を紹介するので、参考までに読んでみてください。
http://learnyouahaskell.com/chapters
（このサイトの内容は、日本語の書籍「すごいHaskellたのしく学ぼう！」として出版されています。）
Haskellは、順番に学べば必ず理解できるようになっています。
もしも、Haskellが習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事も検討してはいかがでしょうか？
（人生は一度きり。時間の無駄にならないようにお気を付けください。）
あなたと友人が、無事Haskellを習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本のIT産業を牽引されることに期待いたします。
（追記）
自分が作りたいプログラムすら作れない人が、他人が希望するプログラムを作るなんてできっこないからねｗ
（プログラマーが楽で簡単な仕事だと思ったら大間違いですよ？）
（追記 その２）
関数型プログラミングをマスターしておけば、OOPでも役に立つよ。（現実には、関数型もOOPも必要に応じて投入するし）
iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。
別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。
（追記 その３）
他の人が書いてたけど、１人でプログラミングするんじゃなくて、２人（ペアプログラミング）や３人以上（モブプログラミング）から始めたら良いかも。
Googleの「プロジェクト・アリストテレス」で、仕事の生産性を改善するには「心理的安全性」が重要と分かり、プログラミングの仕事もやり方が変わって来ています。
https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html
（追記 その４）
元記事が消えていたのでバックアップしておきます。（この投稿だけ読むと意味が分からなくなるため）
https://anond.hatelabo.jp/20170910205249
2017-09-10
■知り合いをプログラマにさせたいんだけど知恵を貸してくれ
プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。
接客のバイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事は時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。
その知り合いについて。
Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナルの操作はできている。cd, ls あたりは理解している。
趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。
何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。
こちら側からは、プログラマーになれば？と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネットの記事をシェアーしているくらい。(心理的リアクタンス避け)
知恵を貸して欲しい。
師匠「プログラミングとは深淵なる神の御業（みわざ）。あらゆることを可能とし、あらゆることが不可能であると知る。」
師匠「当然だ。」
師匠「ところで弟子よ。お前はプログラミングを覚えて何をしたい？」
弟子「今はIT技術者が少ないといいます。この未曾有の危機にエンジニアとなってこの町を、この世界を自分の手で守りたい」
弟子「師匠のもとでC#プログラミングを学び始めて1年。if文だとかwhile文とかどうでもいいクソ知識を覚えて参りましたがやっぱり何の役にも立ちません。」
師匠「そうであろう。考えてみろ。お前は日本語を話せるが、アナウンサーにも小説家にも程遠いだろう？プログラミング言語を覚えるだけで何かできるようになると本当に思っているのか？」
弟子「そんな・・・だったら英語覚えて、おとといskypeで話しかけてきたカウガールとキャッキャウフフしてた方がマシじゃないか」
一般人はWindows PCとAndroidスマホを使う。*nixだのpicマイコンだのasicだのとは違う。
その時点において、かつて王道だったC言語を学ぶ意義はパンピーには無い。
ひっきりなしに飛んでくる他人からのメッセージに反応することを強要される毎日。
師匠「文字、数字から初めて、基本的な文法を覚えるだけで1年かかるか……そりゃつまんねーよな」
師匠「関数とスコープを覚えて、ようやく構造化プログラミングが学べる」
師匠「だが……学校じゃ文法やって終わりってんだから、CRUDも構造化もやらずに何ができるかってんだ。副作用とかどうでもいいことばかりは教えるくせによ」
師匠「機能の抽象化、モジュールの疎結合が重要だろう。そのためのオブジェクト指向だろう。」
師匠「なぜ抽象化と分割統治をしたいかと言えば、人の短期記憶は5チャンクが限界だからだ。つまりは頭の小さな人間が巨大なシステムを理解するための知恵だ。
師匠「HSPでプログラムを書いていて、500行くらい書いたらもう頭がごちゃごちゃになって限界を感じるあの感じ（個人の乾燥です）」
師匠「HSPの名誉のためにも言っておくが、500行以内であれば簡潔だし、絶大な威力を発揮するツールだ」
師匠「逆にCは3行書いたら、その関数の非力さに頭が痛くなる(個人の乾燥です)」
師匠「アセンブラに至ってはmov 1, $ax とか書いた時点で発狂する。なんでintel構文じゃないんだ！と」
師匠「つまるところ、プログラミングとは自由を勝ち取るために、人間の限界と戦うことだ」
師匠「創意工夫をこらして、今できないことをどうやってできるようにするのか。どんな可能性があるのか」
師匠「構造化プログラミングをすればバグが出なくなるわけじゃない。OOPでプログラミングがうまくなるわけでもない」
弟子「覚悟ｗｗｗｗｗ。少年漫画の見すぎなんだよ。何か奇声あげたら変身してパワーアップてかｗｗｗ？おめでたい奴だな。貴様は師匠として利用価値がなさそうだ。このあたりで成敗してやる。カラオケで女の子とデュエットしてやる」
ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。
Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。
（いやまぁ、タプルとかもあるけど、原則的に）
構造化⇒OOPと来て、プログラミング言語はGo to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。
OOPの大本のsmalltalkはメッセージパッシングの原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。
勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。
この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。
ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。
人間の脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。
上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。
この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。
なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう（Akkaもあるけどあれはオブジェクティブな側面なので）わけで、これは凄く懐かし気持ちいいと思う。
かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。
というか qiita の内容はちゃんちゃらおかしくて臍で茶が沸くレベルなので気にしなくてよし。
hatena のほうは斜め読みしたところ、多分結局オブジェクト指向を十全に理解した上で捨て、さらにその上で手駒のように使えという、初学者にとっては雲の上のレベルなので気にしなくてよし。
関数型を身につけることは大いに推奨するが、オブジェクト指向は理解しとかないと、万が一自分で書かないとしても（このご時世 OOP に全く触らないでプログラマをやるのは多分無理だけど）人の書いた有用なソースを読めなくなるし、未だ必須のスキルじゃないかなと思うけどね。
今月に入ってからJava（ゆくゆくはAndroid）勉強してる素人なんだけど
http://qiita.com/kenokabe/items/13ea8d2da6adce1b3b9a
http://d.hatena.ne.jp/nowokay/20140718
こういうの読むと、別に理解出来てるわけじゃないものの、じゃ今OOPやる意味ってなんなんだろと思う。
地固めというか、それでも基礎力つけるためにひと通りはやったほうがいいのかな。
デザインパターンはUML書きながら、動作と意味を追いながらとりあえず書経してるけど、
周りに相談できる人もいないので、ここで訊いてみた。
昔staticおじさんとか騒動になっていたわけですが、その時は「OOPはそんなに難しいものじゃないのに、なんでこんなのも分からないんだ？」と思っていたわけですよ。
ところがFPをある程度学んで、OOPにふと戻ってみて気づく「OOPって面白いけど、凄い難しいジャンルなんだな」という。
なんでOOPが難しいかと言えば、OOPが多分に「工学的」なモデルだからではないかと。
FPは「数学的」で、ある程度答えの出し方とか、分析の仕方とかが確立されている視点で、プログラムを扱うので、そういう意味では簡単なジャンル(もちろん全てが分かるほど簡単なわけがないけれど)なわけですよ。
プログラムを扱うために役に立ちそうな道具が、数学という世界には沢山転がっているので、色々と使えるわけです。
でも「工学」は難しい。
「工学」を学問として扱うのは、多分「経済」を学問として扱うのと同じくらい難しい。
なんというか、今のところ正解を誰も知らない世界なわけですよ。
もちろんFPでプログラムを書いたところで「これが正解のプログラム」なんてものは出てこないけれど、でも「とりあえずこのツールを使う分には、これが正解」みたいなのは見えやすい。
工学はそれすら難しい。
でもそれゆえ、わくわくする煌きを未だに秘めている。
id:minamiyama1994 さん、反論してくださってありがとうございます。
Haskellファンのご意見がいただけて嬉しいです。元増田です。
記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である
わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。
「関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語が関数型言語かどうかをみても賛否両論にわかれるでしょう。
私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。
その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングをサポートした言語」という言い方をしています。
このスタンスの上で、
”関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、
”関数型プログラミングへのサポートが片手落ちな言語”として、LispやErlangなどを扱いました(それらのファンの皆、ごめんなさい)。
関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。
関数型プログラミングとは何が良いのか、を大雑把に知りたい。
そうなのではと考えて、あえて区別せずに記事を書きました。
「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう
id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります。
現状多くのパーサーがモナディックパーサーとして書かれています。モナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。
モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。
(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)
「テキスト処理」に対して
お前それShellやPerl、RubyやPythonの前でも言えるの？
「GUI」に対して
この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています。
本質的には関数型プログラミングの強みが活かせる分野のはずです。
「個人の技量の話題」
「レシピ」に関しては、関数型プログラミングのスタイルでは、手続きを手続きとして自然に表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、
わかりにくかったですね。
「書きやすい」
(*)関数の例で、関数型プログラミングの無駄の無さを示せた、と思ったのですが…
マヂですか…反論のためのでっち上げとかじゃなくて(失礼)？(追記: Haskellの方が「短く書ける」、のタイポだそうです)
Haskell布教のために有休とって４時間かけて書いたのにーw
撲滅…
ｼｮﾎﾞｰﾝ(´・ω・｀)
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい
最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチの比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます
問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」
まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である
そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解にモナドの知識はあまり関係がないと言っても差し支えないのではないか
「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++とHaskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない
「静的型付け」云々もこれはもう完全にHaskellやOCamlの話である、LispやErlangとは何だったのか
多くの数値計算アルゴリズムは逐次的に定義されている、関数型言語で扱いやすいものではない、簡単にいえば「それFortranの前でも言えるの？」である
遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語でエミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない
「分数や虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない
お前それShellやPerl、RubyやPythonの前でも言えるの？
この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語や特定のライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語の設計など容易だろう
言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない
GUIライブラリの設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
nao0990
設定が十分に練られていないから、一浪で大学入学して大学二年生修了後さらに二年休学の時点で22歳、なんていう基礎的な矛盾が起きるのだ。
普通に凡ミスでした、すみません。その時点で23歳ですね。他にもおかしい点があるかもしれませんが、記憶違いや身バレを恐れての改変が混ざったためと思って下さい。
nekora
一応事実として書いているので、言語だけで見るとショボい経歴ですがそのまま書いています。VB6 については弁護出来ないレベルの古さなので、格好悪いと言われるとその通りですが、それも含めて仕事をしようと思えればできる、と捉えて頂ければ幸いです。もちろん、古い言語の悪い部分に甘んじて低い技術レベルのままで仕事をしてもよいと言っているわけではありません。
htnmiki
語りたい病ですね
augsUK
今が勝ち組なのかよくわからんとか設定が杜撰だとかいろいろあるけど、想定Q&A作ってまで語りたいんだなあということはわかった。もう少し勝ち組設定の方が良かったと思う。
語り寄りになってしまってすいません。事実ベースで書くことにこだわり過ぎました。
大学中退やその他のハンデがあったとしても、場所／労働条件（給与、福利厚生）／企業のブランドなどへのこだわりを必要以上に持たずに捨てて視野を広げ、自分が必要とされるであろう企業に絞ってエントリーすれば数十社もエントリーしなくても内定はもらえます。なので頑張りどころを間違えずに頑張ってほしいです。
以下はこの一言に対する補足説明となる、背景や就職活動の指針についてです。
Twitter / s_suneco: これリクナビのトップだけど、これ私がおかしいというよりは周り ...
https://twitter.com/s_suneco/status/448665586222899201
高校に上がったくらいから就職ということを少しずつ意識するようになり、上記のような何十件もエントリーしなければならない熾烈な就職活動があるという話を聞いて、まだぺーぺーの学生でありながらもそんなのはおかしいと思っていた。学歴は確かに一定の修学を積んだという証明になるかもしれないけれど、企業はそれだけではなく採用希望者の人となりもきちんと見て、共に働くものとして十分な経験、知識、学習意欲などを持ち合わせているものをきちんと採用してくれればいいのにと思っていた。（働いてから採用する側になって、その難しさもまた分かったのだけれど。）
自分の能力は客観的に見て高いのか低いのかは分からないけれども、少なくとも学歴に関しては大学中退という傷物でありピカピカの新卒に比べると人材としての価値は低かったと考えている。そんな自分の足跡をここに記して、一般的な人材像とされている新卒でなくとも、その他諸々の身分であったとしても、落ち着いて丁寧に就職活動をし、こうして就職が出来ているということを知って就職活動の励みとしてもらえればと思う。
結局の所、労働者として働きたい僕らはお金が欲しいというのが企業と同様に前提条件なのであって、そこから
という流れが導き出せると考えています。
自分が学生であった当時もそうですが、そういった流れがあるとこまでは分かっても各点の具体的なイメージは出来ず、企業がどうやって稼いでいるか、従業員はどういった業務を行って給与を得ているかなどを適宜調べたり、諸先輩方に会う時などに質問するなどして一つ一つを自分なりに具体的にしていきました。そうして自分なりの芯となる考えを持っておく事で、無鉄砲に企業に当たるのではなく少しずつ焦点を絞りながら就職活動をし、数社のエントリーのみで内定を頂く事ができたのではないかなと考えています。
うまくまとめられたかは分かりませんが、ここに記した自分の経歴や考え方を見て何かしら参考にしてもらえれば幸いです。
経歴にも書いていますが自分の場合は理系→プログラミングという分野で活動していますので、別の分野（業界、業種、業態）では参考にならないということもあるかもしれません（分野によっては数十社へのエントリーを行った方が確率が上がる、など）。逆に言えば、踏み込む分野によって適切な就職活動の方法というのはあると思うので、それぞれの分野の現職やその周辺の方々の情報をうまく集めて、適切な方法で活動していってもらえれば自分が望む方向に近い所へ向かって行けるのではないでしょうか。
就職活動中の皆さんが無理をせずに向かいたい方向へ努力して向かい、その努力が報われる事を祈りつつ。
HTMLとCSS, JavaScriptはちょっとだけ分かる
dotinstallとか見てブラウザでタイマー作ってわーいって喜んでるくらいのスキル感。
→本を買ってやるのは安上がりだけど途中で挫折しそう
→じゃあお金稼ぎながら学んだらいいんじゃ
バイト始めることになった
バイト始まる
課題を出されて、できたら業務に入れる
誰も教えてくれない
ググってググってググりまくる
ひーひー言いながら2~3週間でなんとか終えた
なんとかなった
このときくらいにパーフェクトPHPを読んだ。FWは、つくれる！
あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね
分かった気になる←分かってない
GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない
FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービスの受託をやる
まあ良い経験になった
フレームワークいくつかやって、web開発のいろんな概念やtipsがたくさん頭に入ってきて、
あーあれかーくらいには思えるようになった
DBのCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインでコード生成,認証周りのプラクティス ...
さて、バイトが本格的？になってくる
一人で開発 責任おもい
でもなんか躓いた。
書いたコードに自信が持てない
これでいいのか不安になって手が進まない
セキュリティで手直しはたくさんもらった
フレームワークにはDB操作のライブラリがちゃんとついてるのにそれ見ずに自分でSQL組み立てて案の定エスケープしてないし、とか
でも、なんとか完成させた
プッシュして、マージされて、できちんと本番環境で動いてる。やったね。
Rubyを知った
PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。
Railsも知った
それからは空いている時間の大半をRubyとRailsにつぎ込んだ
まずはRailsTutorialをやってみた
テスト周りでつまづいたけどなんとか終わらせた
dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ
はじめはRubyを理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた
はじめてのRuby・はじめてのプログラミング・たのしいRuby・プログラミング言語Ruby... 入門系の本を乱読した
PHPでさんざん苦労していたからか、Rubyでオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた
その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra（支那虎じゃなかった）やらについて学んだり、
メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatzの言葉痺れたなー
バイトのほうも何とかこなせるようになってきた 成長すげー
Vagrantをかじる
AWSでいろいろ遊ぶ
webスクレイピングとか検索APIとか使ってムフフな画像をアハーンしたりして遊んでた
Rubyで言語をつくろうだの、スクリプティングを極めようだの、JavaとRubyがどうだの。
メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。
借りられる本は借りて済ませた。全部買ってると破産する
他にもRubyとつかない本もいろいろ。
プログラマが知りたい97の何とか。いい本
Rubyの関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる
OOPと全く違う。
就活はじめるよー
まあ、エンジニア枠で探すことにする
エントリーめんどくさい
ので、1社受けて落ちたら次の会社エントリーするという作戦にした
無計画玉砕作戦
とはいえ、なんとかなると思ってやってく
気を揉む期間
やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない
せめてよく使ってる言語くらいはのっけておいて欲しい。
で、１社選んで応募して、選考が始まった
面接、失敗したなと思ったところもあったが
嘘つかない
知らないことを知ってるように話さない
は通せたので良かったと思う。
で、進んでいって最終面接。これもなんかよく分からないうちに終わってた
相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる
うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。
前から気になってた会社ではあった。勝手にリスペクトしてた会社。
自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる
いろいろと運が良かった。嬉しい
他の会社はどうしようかな。
受けてみたい気もするけれど、エントリーがめんどくさい
続けるかどうかは未定だけど、ひとまず休憩することにする
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
普段Perlを書いているんだけど、言語機能として欲しい機能がライブラリ任せだったりしていろいろしんどい。
何かいいプログラミング言語はないかなーと思っているんだけど、なかなか自分の好みとピタリとくるものがない。まぁ好みにピタリとくるものなんかプログラミング言語に限らずないんだろうけど。
なので夢想してたのを垂れ流してみる。最近OOPディスのエントリとかあったので話題作りになれば。
Web系のエンジニアなのでWebサービス作ることが前提で、範囲広げすぎるとまとまらないので今回はLLを想定してる。
だいたい PHP, Perl, Python, Ruby, JavaScript あたりをイメージしながら、さらにこんな機能があればいいなーと思って書いたよ。
「Cならswitchテーブルを使った再帰関数で実現する必要がある」に対するレスなんだろうけど、飽くまでも「C以外の、継承とオーバーライドの機能がある言語では例題とほぼ同じ形で実装できるのに対してその機能がない言語では『関数内でswitchをして値ごとにdispatch、その後更に再帰』という原始的かつ全てのロジックを詰め込むせいでひとつの関数の行数が膨大になる問題を孕んでいる」という意味しか持たない。
確かにTopCoderで再帰を使ったら撃墜される可能性がある事には同意だけど、今回の例ではプロコンの外側での事であってスタックがオーバーフローしたなら例外をキャッチして後処理を行えば良い。
更に
バイナリツリーを自前で構築して式を表現する例題（expression tree）と、set and mapは用途が違う。
setとmapは本来、順序が定義できる要素をキーにしてそれそのものを保持するか、或いはそれに伴う値を結びつけて保持しておくもの。
例題のexpression treeの構造は「（必ずしもオペランドがふたつとは限らない）式の木を表現して、オーバーライドされたevalで式全体の評価を行う」もの。
は成り立たない主張であるし、
（C言語等のOOPが導入される前の言語で）綺麗に書く事ができないと問題を提供する側がそもそも「綺麗な解を前提とした問題」を出せない。
