サービス終了のお知らせサービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
プログラミングはそれ自体が目的であっていい - mizchi log
これ読んで思ったこと。 プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思
動物実験って、よく考えたら微妙な問題だよな
たいてい動物実験が話題になるときって過激な団体が無茶したときだから、「動物実験反対派」の主張が肯定的に報道されることって少ない気がする。 http://b.hatena.ne.jp/entry/togetter.com/li/493443 たとえばこれが「穏便に申し入れて」「高校側が拒否した」とかなら、ニュースバリューも無いしね。 ただ、ブコメとか見てると、たまに妙な意見が書いてあることがある。 ・この団体事務所の近くの水たまりという水たまりにボウフラを投げ込んでやりたい ・「アカムシの解剖」は、少なくとも、「ゴキブリに殺虫剤をかける」より残酷な行為ではないはず。学校での動物実験に反対する前に、まず殺虫剤の不買を呼び掛けてみろよ。 別に彼らがほんとにそう思ってるってこともないだろうし、単なるレトリックなんだろうけど、やっぱり気になる。 Aを反対するときに、Bも反対しないのはダブルスタンダー
4 月にエンジニアとなった人たちに知っておいてもらいたいこと
個人的な経験を書きますが、ぼくはエンジニア生活 10 数年で 5 社を転職して渡り歩いています。そして、その 5 社すべてでなにかしらの勉強会なり研修なりといったものをやってきました。 そして、それが仕事であろうとなんだろうと自分がエンジニアに研修なり説明会なりをするときは、自分がもらったものを返すつもりでやってきました。そのときそのときは当然所属している会社があるわけですが、その会社のため (だけ) にやったことは一度もありません。プロジェクトによって参加している人の立場も発注元だったり受託開発の常駐エンジニアだったり様々だったので、あくまで一人のエンジニア同士として自分が伝えられることをなるべく伝わるような言い方で伝えるということをやってきました。その中では所属会社へ都合の悪い話も出たりしますが、これは所属会社へのコミットメントとは別の話です (PHP 使ってる会社で PHP の悪い点
彼女と愛とセックスと結婚について
（2010/11/22 22：00 おまけ追記） 「結婚はいくつでしたい？」 「結婚ですか？」 「うん」 「結婚願望は、特にありません。」 「したくないってこと？」 「特別、絶対したくない、というわけではないんですが。どちらでもいい、どうでもいいという意見に近いです。」 「なんで？結婚って人生においてもっと重要なことじゃない？どうでもいいことはないでしょ？」 「そうですね。結婚したい人にとっては重要かもしれませんし、いずれ結婚する人にとっては重要でしょうね。」 「じゃあ結婚しないの？」 「おそらく。」 「なんで？」 「なんで、と言われましても。結婚するのに理由はあっても結婚しないのに理由はないでしょう。ただ今のままというだけです。」 「だって普通結婚するじゃん？」 「する人は多いかもしれませんね。」 「じゃあ結婚するのが普通じゃん？」 「一般的にはそういう認識が強いかも知れません。」 「じ
フローチャートを復権させよう -- 2020年代のプログラミングへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。 この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。 ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。 これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、
OOとはなにか - みねこあ
自分の中でひっかがりを感じることを整理するため、なんとなく、こんな図を書いてみて、それからそれに文章を付けてみます。 マルが OOPやOOの名前、四角がそれを構成する要素･･･みたいな感じの適当な図です。また、赤の四角がプログラムの構造についての考え方、青の四角が型チェックについての考え方。用語や関係は適当です。（ご容赦） クラスには「型」と「モジュール」の、二つのとらえ方があります。メイヤー先生の「オブジェクト指向入門」から(artonさんをパクって）引用すると、 繰り返しになるが、クラスを型と見るか、またはモジュールと見るかによってすべては決まる。型として見る場合、継承はis-a（……は……の一種である）という関係であり、明らかに特殊化である。"犬"は"動物"よりも特殊な概念であり、"長方形"は"多角形"よりも特殊化されている。この関係はすでに述べた部分集合の関係に対応する。（中略）
二つのオブジェクト指向とそれぞれのメリット - Smalltalkのtは小文字です
似たような話の繰り返しで恐縮ですが、現時点での自分の理解の整理のためのメモ。 前後しますが、こうして改めてまとめてみると、純粋な抽象データ型のオブジェクト指向プログラミングは、メッセージングのオブジェクト指向の影響も多分に受けている OOAD（分析・設計）のテコ入れ無しには、ちょっと弱っちく＆古くさい感じが否めませんね（何をいまさら…ですが）。^^; とはいえ、OOAD は OOP とはまた別のものなので、同じ「抽象データ型の〜」あるいは「メッセージングの〜」だからといって対応する OOP とひとくくりにしてよいかというとそういうわけでもないので（整理・分類上は）難しいところです。 ▼ 抽象データ型のオブジェクト指向プログラミング 端的には、「ユーザー定義型（抽象データ型）」を、当初は「クラス」、今はそれに加えて「インタフェース」に準ずる言語機能によるサポートを前提として実践するプログラミ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
layer8.sh