タグ

論とprogrammingに関するch1248のブックマーク (242)

  • オブジェクト指向は禁止するべき - きしだのHatena

    プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムのに、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

    オブジェクト指向は禁止するべき - きしだのHatena
  • プログラミング言語の基礎概念を学んでる - はこべにっき ♨

    プログラミング言語の基礎概念 (ライブラリ情報学コア・テキスト) 作者: 五十嵐淳出版社/メーカー: サイエンス社発売日: 2011/07メディア: 単行購入: 6人 クリック: 60回この商品を含むブログ (12件) を見る このを読んで学んでる。まだ半分くらいで関数の定義とかについて勉強してる。 プログラミング言語の動作を数学的に厳密に記述する方法を順番に教えてくれるという内容で、記述には導出システムが用いられてる。基的な算術式からはじまって、変数の定義や関数の定義、パターンマッチや型システムなど、様々な言語の機能を推論規則によって定義する方法を教えてくれる。与えられた規則が意味的に意図したものを表しているかの証明だけでなく、証明のやり方もくわしく説明されていて丁寧でたすかる。 おもしろいのはこののためのオンラインの演習システムというのがあって、の中で与えられた導出システムに

    プログラミング言語の基礎概念を学んでる - はこべにっき ♨
  • プログラマーは文系の仕事か、理系の仕事か - 愛と勇気と缶ビール

    というような大きく構えたタイトルにしてみたが、デジタルな結論を持った記事ではない。 教育制度として文系とか理系とか分ける意味あんのか、というような議論はさておき、現行でそういう制度が存在している以上は僕の身の周りにも文系学部からプログラマーになった人、理系学部からプログラマーになった人がいて、僕の知る限りでは両者にプログラマーとしての能力の差は見受けられない。 世間では、どうやらプログラムを書くのには数学的な能力が必要だと思われているせいか、あるいはいわゆる情報システム系の学部が理系学部に分類されているせいか、理由は全員に聞いてみたことがあるわけじゃないのでよく分からないが、どうやらプログラマーといえば理系だと思っている人が多いようだ。 僕個人で言うと、大学・大学院と数学の点数の低さを英語の点数でカバーしてきた(これは実際には点数の照会なんてしてないので実際には不明なのだが、明らかに手応え

    プログラマーは文系の仕事か、理系の仕事か - 愛と勇気と缶ビール
  • エンジニアを定量化なんてしてはいけない - smellman's Broken Diary

    ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること,またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし

    エンジニアを定量化なんてしてはいけない - smellman's Broken Diary
  • Boost勉強会 #15 札幌に参加した

    Boost.勉強会 #15 札幌が、下記のとおり行われた。 Boost.勉強会 #15 札幌 - boostjp Boost.勉強会 #15 札幌 : ATND 5月22日 「あたし、ガールズバーのホームページ作ってるんだよね」と、三十路過ぎの女が言った。「とにかく、可愛い女の子がいっぱいいますってことにしなくちゃいけなくて、当大変」 「悲惨だな」と筆者は答えた。悲惨としか言いようがない。「そもそも、何故人と話すのに金を払わねばならないのだ。今、私がここでお前に金を払って、会話してくれと頼むのは、おかしいだろう」 「でも、あたしみたいな三十路過ぎの女じゃなくて、二十代だし」 謎だ。筆者には、女の魅力というものを、世間一般が評価するように、正しく評価できない。人の魅力の評価というのは、筆者に欠如した能力であるらしいのだ。この三十路過ぎの女は、その年齢と、そして鍛えていない肥満した体躯から考

    Boost勉強会 #15 札幌に参加した
  • TechCrunch

    [A version of this piece first appeared in TechCrunch’s robotics newsletter, Actuator. Subscribe here.] Earlier this month, Google’s DeepMind team debuted Open X-Embodiment, a database of robotic

    TechCrunch
  • プログラマとお金

    https://note.mu/whynotgetrich/n/nd71f86a3e0cb に移行しました。

    プログラマとお金
  • プログラミングの生産性を上げるには - 聞かれてもいないことを喋る

    Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に当に(長期的にみて)効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで

    プログラミングの生産性を上げるには - 聞かれてもいないことを喋る
  • デザイナーのわたしがプログラミングの基礎をだいたい3日で覚えた1つの方法

    works デザイナーのわたしがプログラミングの基礎をだいたい3日で覚えた1つの方法 Posted by Miki Ishijima on May 20, 2014. フルスタックエンジニア!フルスタックエンジニア! 最近なんでもかんでも出来る人が求められていますね。Webデザイナーの人でも簡単なプログラムに触れる機会は以前より格段に増えています。 わたしもプログラムを覚えたいと思い、勉強していました。しかしそれは、禁煙と同じようなもので触ってはやめて、触ってはやめて、飽きてしまうの繰り返しでした。 身につかない原因 プログラムの勉強会や、、ブログなどを読んでもなぜ身につかないのか。難しいというのは理由ではありません。 むしろ、基礎の「き」くらいであればコーディングと同じくらい簡単です。 わたしが一番の原因だと考えるのは作りたいものがないというコトです。 子供向けプログラム学習アプリケー

    デザイナーのわたしがプログラミングの基礎をだいたい3日で覚えた1つの方法
    ch1248
    ch1248 2014/05/20
    ComputerCraft、Lua使えたのね。
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
  • ボカロ(作るところから)はじめました - やねうらおブログ(移転しました)

    今日からボカロを始めることにした。もちろん、ボカロを作るところからだ。ボカロを含めて音源も自作する。楽器(ハード)も自作する。 音楽理論も自分で構築しなおす。自動作曲のためのプログラムも作る。そうして、やっと自分だけの音楽が完成する。とりあえず、目標はそこだ。 ■ ボカロを作るとは? 初音ミクに代表されるようなボーカロイドは、「あ」「い」「う」など、人間がそれぞれの文字を発声したものを録音しておき再生しているだけである。つながりが不自然なところは二文字、ときとして三文字つなげたファイルも持っている。ただそれだけである。私はそういうことをしたいわけではない。声を一から作るところからだ。 ■ スーパーファミコンのDSP 順序立てて話そう。 私は高校生のときにアーケードの麻雀の移植のために音声合成の処理を書いたことがある。*1 このプログラムは実際には世に出なかったわけであるが、私はそれ以前から

    ボカロ(作るところから)はじめました - やねうらおブログ(移転しました)
  • Scalaは関数型プログラミング言語ではない - みどりねこ日記

    面白い記事があったので翻訳してみました。 ライセンスはCreative Commonsです。 しばらくScala仕事をして、疑う余地なく以下のことが断言できるようになりました。 ”Scalaは関数型言語ではありません。クロージャを持ち、静的な型を持つオブジェクト指向言語です。” なので、みんなが嘘の売り文句を延々と言うのをやめてくれないかなと思っています。 これがどういうことなのかを理解するためには、ScalaのメーリングリストにJon Harropが流した挑発的な文を見てみてください。そのスレッドで、Martin O.が ”オブジェクト指向こそが唯一の”美しい”解である” と主張しています。のちにMLで、もう少し丁寧にこのことについて述べていて、それによると、アプリケーションの基幹のデータ構造を何度も変更しなくてはならないようなとき、オブジェクト指向が最適な解であると述べてみます。最終

    Scalaは関数型プログラミング言語ではない - みどりねこ日記
  • 【書評】思考の道筋――平山尚『プログラムはこうして作られる プログラマの頭の中をのぞいてみよう』 - Interdisciplinary

    数年に一冊読めるかどうか、という良書を読ませてもらいました。 プログラムはこうして作られるプログラマの頭の中をのぞいてみよう 作者: 平山尚(株式会社セガ)出版社/メーカー: 秀和システム発売日: 2013/09/25メディア: 単行この商品を含むブログ (5件) を見る書は、ブロックを積み重ねていって消していく「あのゲーム」を題材に、ゲーム作りを通してプログラミングを学ぶ、というです。 プログラミングのというと、初心者向けと標榜していても、既にある程度解っている人向けではないかと思わされる物にしばしば出会う事があります。そもそもプログラムとは何か、どういう流れで作っていけば良いのだろうか、を知りたいのに、その辺りを端折って文法の解説などにいきなり入る、というような。元々知っている人であればその方が良い場合もあるでしょうけれど、もっと根の所から知りたい、どこから手をつけたら良いの

    【書評】思考の道筋――平山尚『プログラムはこうして作られる プログラマの頭の中をのぞいてみよう』 - Interdisciplinary
    ch1248
    ch1248 2014/03/09
    欲しいものリストに入れてた本だ。近いコンセプトの本としては、「ふつうのLinuxプログラミング」「プログラマの考え方が面白いほど身につく本」辺りがあるけど、現場向きだしここまで取っ付きやすくは無い感じ。
  • ドメイン駆動設計読んだ - hitode909の日記

    ドメイン駆動設計というのはソフトウェア工学のおしゃれなで,Kindleで買えたので読んだ.ドメインを軸に戦略的に設計しましょうという.2週間くらいで読めて良い体験できてよかった. ソフトウェアを,ユーザーインタフェース,アプリケーション,ドメイン,インフラストラクチャという4つの層に分けて,一番重要なのがドメイン層で,ドメイン層にアプリケーションが存在し得る理由がある.銀行システムだったら,口座とか利子みたなやつがドメイン層で,口座がよくできてると銀行としてうまくいく.ATMのタッチパネルというのはユーザーインタフェースで,どんなにATM押しやすくても,ドメイン層に,口座という概念がなくて,ただのハッシュだったりすると,銀行を運営して金を儲けるとか,新たな金融商品とか作るのが困難になる.インフラ層は永続化とかするのだけど,インフラ層がいかによくても,意味ないデータを保存していては銀行倒

    ドメイン駆動設計読んだ - hitode909の日記
  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • ブログで色々公開したら、恥をかいたけどすごく勉強になった。 - 感謝のプログラミング

    http://b.hatena.ne.jp/entry/d.hatena.ne.jp/dropdb/20080115/p1 @raf00 「ブロガーなら公開して恥をかけ、バカめ」公開しなければ始まらないですよ!— 加野瀬未友 (@kanose) 2012, 12月 4 2日前にsetInterval()を使って、JavaScriptでタイマーで設定した一定時間ごとに動作を繰り返す(定期更新/実行する)サンプルという記事を書きました。 これはsetInterval()が動けばいいや、というかなり稚拙なサンプルだったのですが、たくさんのブックマークをいただきました。 しかし、やはり稚拙は稚拙・・・。 いくつかの「これ、おかしいやろ!」というツッコミをいただきました。 鋭い指摘に唇をかみ、一瞬、「これは恥ずかしい!・・・いっそ消してしまおうか・・・」なんて思ってたんですが、よくよく考えると、プロ

    ブログで色々公開したら、恥をかいたけどすごく勉強になった。 - 感謝のプログラミング
  • プログラム=データ=遺伝子? Lispは無慈悲な言語の女王 - masatoi’s blog

    (Lisp Advent Calendar 2013 18日目の記事) しばしばLispの特徴として「プログラムを生成するプログラムを書ける」ということが言われるわけだが、普通の人はこれを聞いてどう解釈したらよいものか悩むと思う。字面通りに受け取ると、あたかも勝手に世の中の問題を把握してそれを解決するプログラムを出力してくれる真の人工知能のようなものを想像してしまうかもしれない。しかし残念ながら、そうした所謂「強いAI」は人工知能研究における聖杯であり、いまだにSFの範疇から出るものではない。 LISPerの言う「プログラムを生成するプログラム」とは普通もっと限定された意味である。そしてそれはほとんどの場合マクロによって実現される。 evalとマクロ Lispではプログラムとデータが同じ形をしているので、それまでプログラムとして扱っていたものを突如データとみなして操作することができる。逆に

    プログラム=データ=遺伝子? Lispは無慈悲な言語の女王 - masatoi’s blog
  • RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー

    RubyMotion Advent Calendar 2013 に何か書こう、ということでエントリ。 ご存知のように iPhone アプリの HBFav は RubyMotion で作っています。Objective-C ではなく。以前は Titanium Mobile で作っていましたが、去年にバージョン2として作り直すにあたって RubyMotion に移行しました。 RubyMotion に関しては以前、以下のエントリで概要を説明しています。 RubyMotion - naoyaのはてなダイアリー それから、今年 5月に開催した RubyMotion カンファレンスのスライドなどもあります。 実践RubyMotion - Speaker Deck RubyMotion が発表されたのは 2012 年の5月 とかで、それからずっと使い続けているので1年半近くが経ったことになります。App

    RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー
  • 関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由(1) - Programmer’s Log

    前記事で「メソッドが持っている数学性と文学性という二重性」に気がつくきっかけが別にあった、と書きました。ここらへんはだいぶ後に書こうと思っていたことなのですが、流れ上先に書いちゃいます。 そのきっかけとは、多態性(ポリモーフィズム)の意味を理解したことで、この記事のタイトルにあるように「どうみても関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由」、呼ばなければならない理由に気がついた、というきっかけです。 「メソッドはどうみても関数にしか見えない」 この素朴な感想は、オブジェクト指向を学び始めた頃に誰もが思ったことだと思います。ぼくも、オブジェクト指向を学びはじめた時に真っ先に思いました。 「どうみても関数にしか見えないのに、なぜメソッドなどと言い換えているのか?」 という素朴な疑問。 その当時は無知だったので「オブジェクト指向信者とやらは、ただの関数を"メソッド"なぞという

    関数にしか見えないものが「メソッド」と新たな名前で呼ばれる理由(1) - Programmer’s Log
  • 開発時に出会いたくないパターン - Perl日記

    悩んだりうまくいかなかったり解決したり。だらだら書いた。 手作業症候群 とにかくなんでもかんでも手で確認・作業する必要があると思い込んでしまう病。 そりゃiOSアプリとかAndroidアプリとか最終的には実機確認は必須だけれども。 その前にやれることは多々あるはず。リグレとか。 あと「デプロイ職人」も不要にするべき。わかってる。 自動化できない要素を突っ込んでる方が悪いのだ。なんとかする。 masterブランチぶっこみ志向 masterブランチに直接コミットを重ねていくことにより開発速度をアップさせることができる。 ただし孤独な背水の陣を構えることになる諸刃の剣。 おとなしくtopic branchを切って作業するのが安心への近道であり王道である、 とか言ってたらみんなちゃんと切ってくれるようになった。めでたし。 チケットそっ閉じ症候群 来はリリースしたりデータを修正したりしてチケットと

    開発時に出会いたくないパターン - Perl日記