「OOP」を含む日記 RSS

はてなキーワード: OOPとは

2020-03-11

anond:20200311070137

オブジェクト指向の本。質の悪いブログだと「動物スーパークラスで犬がクラス・・」系の解説なっちゃうよ。ていうかOOPじゃないコードOOPコードに書き直す教則本的なの、ない?

2020-03-08

日曜日の朝だ

coffee

やっとこさ起床した。コーヒーを淹れた。飲んだ。十分な濃さ。録画してあったテレビ番組を見る。見たことある内容だった。高島礼子じゃないか?懐かしい。

wife's present condition

妻の体調が悪い。昨日は確定申告を一部分肩代わりしてあげた。今日妻の体調は回復するのだろうか?お出かけや家族サービスの予定は入ってないはずだ。

object-oriented programming?

ここ2,3日、たまたまUMLだのOOPだのについて調べた。そういうことに全く無関係に生きられる環境にあるのだ!数年前いよいよVB6から乗り換えなくてはならなくなって、ドットネット学習した。クラスだの承継だの・・・ああそんなもの使わなくても俺が必要としているプログラムなら書けるんだけど・・・って思いながら眺めていた。結局ドットネットに乗り換えたが、そのあたりの機能は使ってないはずだ。

listof

ドットネットらしい機能採用した記憶があるのは「ListOf」だけだ。こいつは後から後付けで取得値を追加できるので、便利。昔ながらのbasicだと「uboundで配列の要素数を取得→要素数を1つ増す→最後の要素に新しい取得値を代入」ってな感じで面倒だった。その点くらいだな。ご利益は。

inferring their impressions

最近部下に当該プログラム保守というか拡張変更を委嘱しているが、きっと「読みにくいコード書いてるなぁ」って思われているのか?部下もOOPなんて知らないだろうけど・・すでに一部の大学では設置済みなんだろうけど OOPにメインフォーカスした科目とか作ればいいのにね。

open-source softwarez

OSSだけしか使わないと誓い「総OSS化」を進めていたはずだが、ここ数日商ソフトに戻ってしまった( ^ω^)・・・

mail check result

メールチェックしたけどたいしたメール来てない。良かった。日曜の朝にメールがいっぱい来てて要即返とかだったら精神的にダメージ大だよな

2019-06-26

HTTPってシンプルプロトコルなのに

OOP言語で扱うと台無しになってる感ある気がする

気のせいか

2019-06-25

anond:20190624140926

✕
if(肉に火が通っている)火を止める;
else if (3分たった)火を止める;

○
火が通った肉 = 炒める(肉, 3 * 60);

OOPだとbuilderパターンうまいことハマる気がする

2019-02-03

anond:20190203182834

OOPが古いってのは分かるけど

POPは単なるfinal classinterfaceなのでいつものApple信者ウリジナルかぁ~と思ったわ

2018-11-25

PHPerのコンプレックスは異常

ぼく「OOP…」

PHPer「PHPはもはや5系の頃とは違う!別言語と言っても良い!(フンガー!」

ぼく「お、おう。。どの辺が変わったの?」

PHPer「致命的エラー例外投げるようになった!戻り値の型を指定できる!匿名型が使えるようになった!」

ぼく「へ、へえ〜。。結構OOPやすくなってそうだねえ。。(他のOOP言語にはふつうにありそうな機能ばかりだけどな...)」

PHPer「だからRubyはクソ!」

ぼく「???

2018-08-01

オブジェクト指向呪いと、その避け方」と、その読み方

http://mizchi.hatenablog.com/entry/2018/07/31/124354

念の為言っておきますOOP呪いについては特に異論はありません。

クラスしかメソッド所属できないモジュールシステム

古いJavaのような、クラスしかメソッド所属できないモジュールシステムばかりの時代じゃありません。 クラス基本的不要だと思います

Javaは今でも「クラスしかメソッド所属できないモジュールシステム」でしょ。クラスに属していないように見えるのは糖衣構文に過ぎない。

関数参照

https://twitter.com/mizchi/status/1024103868613812225]

オブジェクト指向呪いほとんどの言語モジュールシステムでは関数参照がそのままexportできるのに、すべての関数を static メソッドまたはクラスメソッドとして表現する人が未だに多く、見るたびに指摘してる…

関数参照ってなんですか?「exportする」ってそんなに一般的ではない気がする。

もしfunctionオブジェクトをimportするのを指しているのならば、所詮オブジェクトなので状態が含まれない保証はない。

関数参照 2

https://twitter.com/mizchi/status/1024104303907065856]

RubyJavaPHP でみたので一般的なアレなんだと思う

そりゃJSみたいに柔軟なインポートができる言語ばかりじゃないし…

classの導入

https://twitter.com/mizchi/status/1024151165703938048]

JS似非OOP慣習と向き合うのに class の導入は必要だったと思うけど、それはそれとして class 使わないのは別

これはそう。結果論的にはclassそもそも導入されるべきではなかった気もするけど。

ijk

https://twitter.com/mizchi/status/1024155163399876609]

Dijkstraのijkが好き

めちゃくちゃわかる

記事とは関係ない思い

湧いてきたら追加する

2018-07-07

Haskell を書いてるわけではないんだけど Haskellメモ化したい関数ってどうするんだろう

OOP言語で書いてて

 

 

という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った

純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう

 

しかしながら

 

  1. メモ化は単なる最適化なので無限計算リソースがあれば不要。IOと違い、副作用自体を扱いたいわけではない。最適化の結果として副作用になるだけ。
  2. コンパイラに任せて低レイヤー隠蔽できるならその方がよい。上層レイヤー関数を書く人間が直接扱うようなものではない。
  3. メモ化できるのは参照透過性ゆえなのでむしろ関数純粋性が保証されてる Haskell とかの方が標準の言語機能として当然のごとく提供できるのでは。

 

と思ったのですがどうなんでしょう。

2018-06-06

anond:20180606185209

横だけど、こういうのを多重継承っていうんだね。(OOPの)

勉強になりました。ありがとう。(これからOOP勉強するところです)

2018-05-17

anond:20180517155505

原理主義に陥るとやべえけどなんだかんだでクラス志向OOP的な機能は欲しい時が多い

2017-09-11

まずは自分がプログラマーになってみよう!

山本五十六名言「やってみせ」

やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。

話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。

やっている、姿を感謝で見守って、信頼せねば、人は実らず。

まずは、あなた自身プログラマーになって、見本を見せることが第1歩です。

プログラマーに向いている性格

その後受託系の会社就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。

鬱病気味になったみたい...。

どうやら、プログラミングという仕事の特徴について、あなた理解していないようですね?

 

プログラミングの特徴は、「コンピューター相手なので、嘘やハッタリが一切通用しない」ということです。

人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。

 

従って、プログラマーに向いている性格は、

  1. 嘘をつかない
  2. 几帳面
  3. パズルを解くのが好き

という3点が必要です。

 

警察職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています

(例)本の虫: 麻布十番職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html

関数型プログラミング

プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています

さな部品パズルピースに相当して、大きなシステムパズルの完成品です。

まり、大きな問題を小さな問題に分解して、1つずつ順番に問題をつぶして行く姿勢必要です。

 

プログラミングパラダイム(考え方)には、

  1. 命令
    1. 手続き型(Java等)
  2. 宣言
    1. 問合せ型(SQL等)
    2. 関数型(Haskell等)
    3. 論理型(Prolog等)

があります

 

命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的鬱病発症やすくなるだろうと危惧しています

上述のように、パズルピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。

Haskell

関数型プログラミング習得するために、今なら「Haskell」または「OCaml」というプログラミング言語お勧めします。

HaskellOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。

 

Haskellを学んでみて、パズルピースを組み合わせる感覚理解できたら、あなたテスト地獄に苦しめられないプログラマーになれるでしょう。

もしも、Haskell理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。

例外的に、あなたマゾで、テスト地獄残業徹夜楽しいと思える性格なら、Haskell理解できなくても大丈夫かもしれません。)

 

Haskellの教材(英語)を紹介するので、参考までに読んでみてください。

http://learnyouahaskell.com/chapters

(このサイトの内容は、日本語書籍「すごいHaskellのしく学ぼう!」として出版されています。)

 

Haskellは、順番に学べば必ず理解できるようになっています

もしも、Haskell習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事検討してはいかがでしょうか?

人生は一度きり。時間無駄にならないようにお気を付けください。)

 

あなたと友人が、無事Haskell習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本IT産業を牽引されることに期待いたします。

 

(追記)

まずは、自分が作りたいアプリサービスを作ってみよう。

自分が作りたいプログラムすら作れない人が、他人希望するプログラムを作るなんてできっこいからねw

プログラマーが楽で簡単仕事だと思ったら大間違いですよ?)

 

(追記 その2)

関数型プログラミングマスターしておけば、OOPでも役に立つよ。(現実には、関数型もOOP必要に応じて投入するし)

iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。

別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。

 

(追記 その3)

他の人が書いてたけど、1人でプログラミングするんじゃなくて、2人(ペアプログラミング)や3人以上(モブプログラミングから始めたら良いかも。

Googleの「プロジェクトアリストテレス」で、仕事生産性改善するには「心理的安全性」が重要と分かり、プログラミング仕事もやり方が変わって来ています

ソニックガーデン倉貫さんの働き方が参考になると思います

https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html

 

(追記 その4)

記事が消えていたのでバックアップしておきます。(この投稿だけ読むと意味が分からなくなるため)

https://anond.hatelabo.jp/20170910205249

2017-09-10

■知り合いをプログラマにさせたいんだけど知恵を貸してくれ

プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。

接客バイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。

その知り合いについて。

Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナル操作はできている。cd, ls あたりは理解している。

趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。

何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。

こちら側からは、プログラマーになれば?と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネット記事シェアーしているくらい。(心理的リアクタンス避け)

知恵を貸して欲しい。

2016-05-13

プログラミングの極意

師匠プログラミングとは深淵なる神の御業(みわざ)。あらゆることを可能とし、あらゆることが不可能であると知る。」

弟子「さすが師匠っす。私にはまだまだ理解できないっす」

師匠「当然だ。」

師匠「ところで弟子よ。お前はプログラミングを覚えて何をしたい?」

弟子「今はIT技術者が少ないといいます。この未曾有の危機エンジニアとなってこの町を、この世界自分の手で守りたい」

師匠「ふむ。良い心がけだ。精進したまえ」

弟子「ところで師匠

師匠「なんだ弟子よ」

弟子師匠のもとでC#プログラミングを学び始めて1年。if文だとかwhile文とかどうでもいいクソ知識を覚えて参りましたがやっぱり何の役にも立ちません。」

師匠「そうであろう。考えてみろ。お前は日本語を話せるが、アナウンサーにも小説家にも程遠いだろう?プログラミング言語を覚えるだけで何かできるようになると本当に思っているのか?」

弟子「そんな・・・だったら英語覚えて、おとといskypeで話しかけてきたカウガールキャッキャウフフしてた方がマシじゃないか

師匠「ちょ、おま、それアカンやつや」

弟子師匠バカ。もう知らない!」

世界コンピュータ端末があふれるようになって数年。

一般人Windows PCAndroidスマホを使う。*nixだのpicマイコンだのasicだのとは違う。

その時点において、かつて王道だったC言語を学ぶ意義はパンピーには無い。

ベーマガ失われた世界で、人々はプログラミングを見失い、

人が使ってるからという理由自分の使うアプリを決められ、

ひっきりなしに飛んでくる他人からメッセージに反応することを強要される毎日

師匠文字数字から初めて、基本的文法を覚えるだけで1年かかるか……そりゃつまんねーよな」

師匠ファイル入出力やってようやくCRUDが学べる」

師匠関数スコープを覚えて、ようやく構造プログラミングが学べる」

師匠「だが……学校じゃ文法やって終わりってんだからCRUD構造化もやらずに何ができるかってんだ。副作用とかどうでもいいことばかりは教えるくせによ」

師匠機能抽象化モジュール疎結合重要だろう。そのためのオブジェクト指向だろう。」

師匠「なぜ抽象化疎結合かといえば分割統治をしたいからだ」

師匠「なぜ抽象化分割統治をしたいかと言えば、人の短期記憶は5チャンクが限界からだ。つまりは頭の小さな人間が巨大なシステム理解するための知恵だ。

師匠HSPプログラムを書いていて、500行くらい書いたらもう頭がごちゃごちゃになって限界を感じるあの感じ(個人の乾燥です)」

師匠HSP名誉のためにも言っておくが、500行以内であれば簡潔だし、絶大な威力を発揮するツールだ」

師匠「逆にCは3行書いたら、その関数の非力さに頭が痛くなる(個人の乾燥です)」

師匠アセンブラに至ってはmov 1, $ax とか書いた時点で発狂する。なんでintel構文じゃないんだ!と」

師匠「つまるところ、プログラミングとは自由を勝ち取るために、人間限界と戦うことだ」

師匠「創意工夫をこらして、今できないことをどうやってできるようにするのか。どんな可能性があるのか」

師匠構造プログラミングをすればバグが出なくなるわけじゃない。OOPプログラミングがうまくなるわけでもない」

師匠プログラミングの極意とは現実と戦うという覚悟だ」


弟子覚悟wwwww。少年漫画の見すぎなんだよ。何か奇声あげたら変身してパワーアップてかwww?おめでたい奴だな。貴様師匠として利用価値がなさそうだ。このあたりで成敗してやる。カラオケ女の子デュエットしてやる」

師匠「本性を現しおったなぁぁっ!このバカ弟子がぁぁっ!!」

2015-06-28

http://anond.hatelabo.jp/20150628084955

Webサービス事業化する場合プロセス検討(仮説)

 

(1)企画 → 何を作るか? アイデアマーケティング

(2)制作 → アイデアを具体的な形にする技術

(3)営業 → 作ったサービスを売り込む。 宣伝運営サポート等。

 

(2)の課題

・2-1 Webデザイン → IllustratorPhotoshop勉強中。CSSスキルもショボいので復習しないといけない。

・2-2 Webプログラミング → PHPよりも生産性の高い手段を得たい。サーバーサイドもJSNode.js)への一本化を要検討。

・2-3 インフラ → 貧乏なので、とりあえずVPSクラウドオンプレミス構成ノウハウを得たい。

 

PHP手続き型、OOPから関数型言語への移行を検討しているのだが、候補や学習コスト調査、導入テストができていない。

Node.js+Underscore.js等のJSライブラリFPを試してみるか?

・JavaVM上で動く関数型言語Clojure等)を試してみるか?

テスト地獄比較手続OOPRails)/関数型(JSClojure

 

ここが今の課題だな。順番に解決していくしかない。

2015-02-26

関数型言語使ってる時の気持ちよさは、ベーシックべた書きの頃と同じ

ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。

Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。

(いやまぁ、タプルとかもあるけど、原則的に)

構造化⇒OOPと来て、プログラミング言語Go to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。

OOP大本smalltalkメッセージパッシング原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。

勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。

この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。

ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。

人間脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。

上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。

この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。

なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう(Akkaもあるけどあれはオブジェクティブな側面なので)わけで、これは凄く懐かし気持ちいいと思う。

かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。

2014-07-23

http://anond.hatelabo.jp/20140722110416

というか qiita の内容はちゃんちゃらおかしくて臍で茶が沸くレベルなので気にしなくてよし。

hatena のほうは斜め読みしたところ、多分結局オブジェクト指向を十全に理解した上で捨て、さらにその上で手駒のように使えという、初学者にとっては雲の上のレベルなので気にしなくてよし。

関数型を身につけることは大いに推奨するが、オブジェクト指向理解しとかないと、万が一自分で書かないとしても(このご時世 OOP に全く触らないでプログラマをやるのは多分無理だけど)人の書いた有用ソースを読めなくなるし、未だ必須スキルじゃないかなと思うけどね。

2014-07-22

オブジェクト指向を学ぶ意味とは

今月に入ってからJava(ゆくゆくはAndroid勉強してる素人なんだけど

http://qiita.com/kenokabe/items/13ea8d2da6adce1b3b9a

http://d.hatena.ne.jp/nowokay/20140718

こういうの読むと、別に理解出来てるわけじゃないものの、じゃ今OOPやる意味ってなんなんだろと思う。

地固めというか、それでも基礎力つけるためにひと通りはやったほうがいいのかな。

デザインパターンUML書きながら、動作と意味を追いながらとりあえず書経してるけど、

周りに相談できる人もいないので、ここで訊いてみた。

初めてはてなダイアリー書いてみたら、記法からなくてアメブロみたくなったので死にたい

2014-06-23

OOPは難しい

昔staticおじさんとか騒動になっていたわけですが、その時は「OOPはそんなに難しいものじゃないのに、なんでこんなのも分からないんだ?」と思っていたわけですよ。

ところがFPをある程度学んで、OOPにふと戻ってみて気づく「OOPって面白いけど、凄い難しいジャンルなんだな」という。

なんでOOPが難しいかと言えば、OOPが多分に「工学的」なモデルからではないかと。

FPは「数学的」で、ある程度答えの出し方とか、分析の仕方とかが確立されている視点で、プログラムを扱うので、そういう意味では簡単なジャンル(もちろん全てが分かるほど簡単なわけがないけれど)なわけですよ。

プログラムを扱うために役に立ちそうな道具が、数学という世界には沢山転がっているので、色々と使えるわけです。

でも「工学」は難しい。

工学」を学問として扱うのは、多分「経済」を学問として扱うのと同じくらい難しい。

なんというか、今のところ正解を誰も知らない世界なわけですよ。

もちろんFPプログラムを書いたところで「これが正解のプログラム」なんてものは出てこないけれど、でも「とりあえずこのツールを使う分には、これが正解」みたいなのは見えやすい。

工学はそれすら難しい。

からOOPは凄く難しい。

でもそれゆえ、わくわくする煌きを未だに秘めている。

2014-04-10

http://anond.hatelabo.jp/20140410134501

id:minamiyama1994 さん、反論してくださってありがとうございます

Haskellファンのご意見がいただけて嬉しいです。元増田です。

記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である

わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。

関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語関数型言語かどうかをみても賛否両論にわかれるでしょう。

私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。

その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングサポートした言語」という言い方をしています

このスタンスの上で、

関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、

関数型プログラミングへのサポート片手落ち言語”として、LispErlangなどを扱いました(それらのファンの皆、ごめんなさい)。

言語パラダイムの話題」と「言語の話題」と「ライブラリの話題」と... を混同している

関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。

関数型プログラミングとは何が良いのか、を大雑把に知りたい。

そうなのではと考えて、あえて区別せずに記事を書きました。

「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう

id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります

現状多くのパーサーがモナディックパーサーとして書かれていますモナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。

モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。

(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています

本質的には関数型プログラミングの強みが活かせる分野のはずです。

「個人の技量の話題」

レシピ」に関しては、関数型プログラミングスタイルでは、手続きを手続きとして自然表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、

わかりにくかったですね。

「書きやすい」

(*)関数の例で、関数型プログラミング無駄の無さを示せた、と思ったのですが…

僕自身はC++Haskellの両方を書く人間で、確かにC++の方が「短く書ける」と「感じる」ことは多い

マヂですか…反論のためのでっち上げとかじゃなくて(失礼)?(追記: Haskellの方が「短く書ける」、のタイポだそうです)

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

Haskell布教のために有休とって4時間かけて書いたのにーw

撲滅…

ショボーン(´・ω・`)

http://anond.hatelabo.jp/20140409010816

いくつかまとめて反論したい

まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい

最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチ比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます

問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」

関数型プログラミングの利点」に対して

まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である

そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解モナドの知識はあまり関係がないと言っても差し支えないのではないか

「書きやすい」に対して

「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++Haskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない

「静的型付け云々」に対して

「静的型付け」云々もこれはもう完全にHaskellOCamlの話であるLispErlangとは何だったのか

関数型プログラミングの得意分野はなにか」に対して

数値計算」に対して

多くの数値計算アルゴリズム逐次的に定義されている、関数型言語で扱いやすものではない、簡単にいえば「それFortranの前でも言えるの?」である

遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語エミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない

分数虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

「並行処理」に対して

この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語特定ライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語設計など容易だろう

レシピ」に対して

言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

まとめ

最後に要点をまとめると

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

2014-03-27

大学中退負け組だったけど数社で内定出てる俺が一言いっておくか

追記 2014-04-07

nao0990

設定が十分に練られていないから一浪大学入学して大学二年生修了後さらに二年休学の時点で22歳、なんていう基礎的な矛盾が起きるのだ。

普通にミスでした、すみません。その時点で23歳ですね。他にもおかしい点があるかもしれませんが、記憶違いや身バレを恐れての改変が混ざったためと思って下さい。

nekora

VBer→PHPerのジョブホッパーPGの中では最弱。もうちょっと格好良い設定は思いつかなかったのか

一応事実として書いているので、言語だけで見るとショボい経歴ですがそのまま書いていますVB6 については弁護出来ないレベルの古さなので、格好悪いと言われるとその通りですが、それも含めて仕事をしようと思えればできる、と捉えて頂ければ幸いです。もちろん、古い言語の悪い部分に甘んじて低い技術レベルのままで仕事をしてもよいと言っているわけではありません。

htnmiki

語りたい病ですね

augsUK

今が勝ち組なのかよくわからんとか設定が杜撰だとかいろいろあるけど、想定Q&A作ってまで語りたいんだなあということはわかった。もう少し勝ち組設定の方が良かったと思う。

語り寄りになってしまってすいません。事実ベースで書くことにこだわり過ぎました。

一言

大学中退やその他のハンデがあったとしても、場所労働条件給与福利厚生)/企業ブランドなどへのこだわりを必要以上に持たずに捨てて視野を広げ、自分必要とされるであろう企業に絞ってエントリーすれば数十社もエントリーしなくても内定はもらえます。なので頑張りどころを間違えずに頑張ってほしいです。

以下はこの一言に対する補足説明となる、背景や就職活動の指針についてです。

これを書くきっか

Twitter / s_suneco: これリクナビトップだけど、これ私がおかしいというよりは周り ...

https://twitter.com/s_suneco/status/448665586222899201

高校に上がったくらいから就職ということを少しずつ意識するようになり、上記のような何十件もエントリーしなければならない熾烈な就職活動があるという話を聞いて、まだぺーぺーの学生でありながらもそんなのはおかしいと思っていた。学歴は確かに一定の修学を積んだという証明になるかもしれないけれど、企業はそれだけではなく採用希望者の人となりもきちんと見て、共に働くものとして十分な経験、知識、学習意欲などを持ち合わせているものをきちんと採用してくれればいいのにと思っていた。(働いてから採用する側になって、その難しさもまた分かったのだけれど。)

自分能力客観的に見て高いのか低いのかは分からないけれども、少なくとも学歴に関しては大学中退という傷物でありピカピカの新卒に比べると人材としての価値は低かったと考えている。そんな自分足跡をここに記して、一般的人材像とされている新卒でなくとも、その他諸々の身分であったとしても、落ち着いて丁寧に就職活動をし、こうして就職が出来ているということを知って就職活動の励みとしてもらえればと思う。

スペック及び経歴

大学中退〜1社目
〜2社目
〜3社目
〜4社目
〜5社目

就職活動するときに考えていた事


まとめ

結局の所、労働者として働きたい僕らはお金が欲しいというのが企業と同様に前提条件なのであって、そこから

お金もらって生活したい→就職したい→給与払って人雇いたい→利益を得たい(→経営者企業)の理念を達成したい)

という流れが導き出せると考えています

自分学生であった当時もそうですが、そういった流れがあるとこまでは分かっても各点の具体的なイメージは出来ず、企業がどうやって稼いでいるか従業員はどういった業務を行って給与を得ているかなどを適宜調べたり、諸先輩方に会う時などに質問するなどして一つ一つを自分なりに具体的にしていきました。そうして自分なりの芯となる考えを持っておく事で、無鉄砲企業に当たるのではなく少しずつ焦点を絞りながら就職活動をし、数社のエントリーのみで内定を頂く事ができたのではないかなと考えています

うまくまとめられたかは分かりませんが、ここに記した自分の経歴や考え方を見て何かしら参考にしてもらえれば幸いです。

終わりに

経歴にも書いています自分場合理系プログラミングという分野で活動していますので、別の分野(業界、業種、業態)では参考にならないということもあるかもしれません(分野によっては数十社へのエントリーを行った方が確率が上がる、など)。逆に言えば、踏み込む分野によって適切な就職活動方法というのはあると思うので、それぞれの分野の現職やその周辺の方々の情報をうまく集めて、適切な方法で活動していってもらえれば自分が望む方向に近い所へ向かって行けるのではないでしょうか。

就職活動中の皆さんが無理をせずに向かいたい方向へ努力して向かい、その努力が報われる事を祈りつつ。

想定Q&A

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2014-02-12

何でソフトウェア開発の手法って上手くいかないの?

私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールシリコンバレー会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。

( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法プログラミング工学風のプロセス提供してくれる。しかし、上記の理由でそれだけでは不十分だ )

ソフトウェア開発手法が上手くいってる」っていつ言うことが出来るの?

チーム生産性幸福度メンバーのつながり・1日あたりのコード量・人月コード品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか?

もちろんどんな手法だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題  ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。

上記は私の経験則だけど、僕の知ってる殆どプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」

こんな思考実験をしてみよう、

つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。

この思考実験にはもちろん意味がない。メンバー一人ひとりのスキル性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。

アリスター・コッバーンが2003年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。

" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "

私達の最大の敵

私がプログラミングを始めた1970年当時、開発体制プロジェクトマネージャービジネスアナリストシニアプログラマと言った階層構造ガッチリ管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。

今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマ監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。

ガントチャートスケジュールドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルコーディングを放っておいてるのに、彼らは自分好きな手法適用するか作るかさせて、1980年代以上に決め事・儀式だらけだ。 

実際、今のプログラマは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 まだ半分しか翻訳してません。(明日完成予定)

注2 '14/02/12 翻訳完了しました。コメントの指摘に対応して文章を一部直しました。ありがとうございます

ログイン ユーザー登録
ようこそ ゲスト さん