2003-07-29 5384歩

λ 日本語MySQL つづき

データベース管理 のページを見ながら接続アカウントの設定。

TCPで接続しようとするとすぐに接続が切れてしまう。Unixドメイン接続なら問題なし。 TCP接続時のエラーメッセージは

ERROR 2013: Lost connection to MySQL server during query

なのだがそもそもクエリを投げる前なので的を射てない感じ。このエラーメッセージでググっても有用な情報が出てこない。 こんな初っ端のつまづきだったらGoogleで普通はもっと情報が出てくるものだ。

…だめだ、わからねえ。ldd /usr/local/libexec/mysqldを実行したら libwrap.so にリンクしてたから /etc/hosts.allow かとも思ったけど、プライベートIPは全部通してるはずだし。

日本語ドキュメントの整備状況だとPostgreSQLのが若干上という気がする。しばらくMySQLは忘れよう。

λ オブジェクト指向は難しい (Matzにっき)

これでは、つまづいています、という人に向けての説明としてはだめな気がする。 Ruby User's Guide - 入門・オブジェクト指向 の方が多分わかりやすいんではないかな。どっちもMatzさん作だけど日記だと短時間で書き捨てなので、幅広い層に訴える文章を書くのは難しいようだ。

Google 検索: オブジェクト指向 メリット で最上位にでてくるサイトの先にある Object感覚の学びにくさの原因の以下の部分

実際に"動く"言語となるためには、
1つの大きな転換が生じている(と、俺の視点から見れば見える)んです。
それは何かというと、「言語(ソース)で書かれる部分は、(殆ど)全てが「動作」である」という点です。
他の言語にある宣言だのなんだのの類のかなり多くが、Rubyではそれ自体がメソッド呼び出しであったりします。
属性を作るメソッド(笑)とか、そういう奴らです。

はなかなか興味深い。オブジェクトの中身を決定しているのは[手続きのかたまり]でしかない、ということか。

個人的にオブジェクト指向どっぷりになったキッカケはなんだったかなー。 雑誌とかでC++がもてはやされて、MVCがどうとかよく言われていた時代の雰囲気があったような。 NeXTのInterfaceBuilderを触る環境があって「おーすげー」と思ってた割には、 自分で初期に書いた大きめのコードはC++による画面制御システム。

λ TOSHIBA MK6022GAX

昨日先輩からこの型番のHDDがお亡くなりになったけど丁度バックアップとった直後で良かった、という話を聞いていたのだが。

自分のメインマシンのMK6022GAXからさっき「カツンカツン」というよくないシーク音発生。 やはり夏になって暑くなると壊れるんかのう… このHDDの温度を HDDTemp.exe で計ると通常46℃、がんばっている時に48℃。

本日のツッコミ(全3件) [ツッコミを入れる]
λ うねうね (2003-07-29 23:53)

個人的にObject指向はエンタープライズ用途に向かないと思ってます。 だって、エンタープライズレベルのクラス設計って普通のSE||共同作業では無理です。 結局、天才ひとりの作業になります。
クラス設計後なら個別に開発できるので非常に有用なのは経験上判ってますが。

λ 上美谷 (2003-07-30 04:42)

はじめまして(でしょうか?)うねうねさん。
相互に依存度が高いコードとデータを、
「メソッド&プロパティ」という形でひとかたまりにする
カプセル化手法はエンタープライズでも有用だと思います。

一方で継承とポリモルフィズムは、エンタープライズ開発には向かないと私も思います。
時代の流れで要件が変化した場合に、
ある基底クラスが安泰であるという確証はそうそうありませんよね。

Rubyの組み込みクラスで階層を持っているのが NumericとIOだけ、
というのは言語仕様の変更に寛容さがあって実戦的な実装という印象があります。

λ うねうね (2003-07-30 23:47)

某MLでは御会いしているかな?
カプセル化手法はよく使うので大規模システムで有効なのは判ります。 ただ、言語レベルでなく設計レベルでカプセル化してしまうので、オブジェクト指向言語でなくても同じような開発ができます。 
# オートマトン理論というか状態遷移表で管理しています。

そのためか継承とポリモルフィズムの弊害が特に気になるのだと思います。

Ruby の組込みクラスの実装内容は知らなかったので勉強してみます。

[]