輝々凛々

ガンバるってことは、素晴らしい事だ。

仕事のやり方

仕事をしていると、複数の案件(作業)を同時期にやらなければならないときがある。

そんなときは、優先順位をつけて案件を1つずつ片付けたり、あるいは時分割して、細かく両方の仕事をちょっとずつこなしていく。

こういうやり方は、まぁ、いい。

でも、ふと思ったのは、このやり方だと、多数の案件が一度にやってきた場合に、すべての案件を片付けるまでに時間がかかってしまう。まぁ、当たり前の話だけど。

ならば、先手を打つしかないんじゃないだろうか。

人間は、CPUではないけれど、CPUのように「投機実行」すべきなんじゃないだろうか。

つまり、先んじて、案件になる前から作業を開始する。これなら無駄は出るかもしれないが、案件自体は早く片付く。

あるいは人間だからできることだが、その「投機実行」している作業自体を案件にしてしまったら、いいんじゃないだろうか。

ようわ、自分ではじめた作業を、自分で仕事にして、会社の仕事にするってことだ。

まぁ、もちろん、こういったことができない業種もあるが、プログラマという職業では有効だと思う。

けど、もちろん、会社の方針に合わない仕事を作っても仕様がない。

抽象的すぎるプログラムは悪だ

プログラムは、目的を達成するための道具で、具体的なものだ。

そこにピカソのような抽象的なプログラムは必要ない。

いや、ピカソというと語弊があるな。

抽象的を履き違えた「曖昧な」プログラムは必要ない、だ。

Do()

たとえば、よく見かけるのだけど、「Do()」という関数。抽象的を通り越して、中身を想像できないという意味で、かなり曖昧だ。まったく理解できない。中身を想像させたくない理由でもあるのか?

汎用的にする目的で抽象化するのであれば「Build()」とか「Compile()」とか「Read()」とか「Write()」とか「Fetch()」とかまでの抽象化で留めておくべきだ。

デバッグしにくい

想像できないほどの抽象化は、中身を想像できないだけでなく、デバッグもしにくい。だいたい何をやっているかわからないし、バグがあるであろう関数を見つけにくくなる。

ファイル読み込みに何らかのバグがあったとする(32ビット長のファイルしか読めないとか、日本語パスを読めないとか)。このとき、「Read()」のような関数があれば、すぐに検索して目的の関数を見つけられるし、関数名から関数の仕様を想像する事もできる。だけど「Do()」じゃわからない。

もちろん「fread()」や「ReadFile()」とかをキーに検索して関数を見つけられるかもしれないので、この例は不適切であるが。

あと「コメントがあればいい」というかもしれないが、コメントはなるべく書かない方がいい。重要なのはコメントを書く事ではなくて、わかりやすいコードを書く事。その上で、わかりにくい所やトリッキーな所、全体的な構造についてはコメントやドキュメンテーションすればいい。プログラマの時間は限りなく限られているのだ。残業しているうちはダメなんだ。

結論

ま、そんなわけで、結論。

美しい抽象化は何か、それを問え。

中国マネー?

最近「中国マネー」という言葉をよく聞く。

日本は「中国マネー」を利用しきれていない、とかとも。

日本人は、中国人を信用していない、とかも。

でもさ、確かに信用していない感じはあるけれど(現在30歳以上の人が特に)、でもさ、別に信用したとしても、買収されるいわれはないぜ。

別にそれは中国人だからじゃなくて、何人でも関係ない。日本人に買収されるのだって嫌だ。

たぶん、自分でノシアガリたいんだ。

楽するために生まれてきました。

まさか、楽するために生まれてきたんじゃあるまいな

伊坂幸太郎「重力ピエロ」

ごまかさずに

もう少しだけ先へ。

事件

何か凶悪な事件が起きた時、なぜか「怖い世間になった」と思う。

でも、存外、世間は相変わらずだ。

怖い世間に急転直下で変化するわけもなく、緩やかに遷移していっているわけでもない。

ただ、因果の誤謬なだけだと思う。

ようわ、「怖い世間になっている」は、ただの勘違いだ。

凶悪な事件が伝わりやすくなっただけで、怖い世間になったわけではない。

と、少なくとも、そう信じたい。

生きたがる

人は、ひとりでは命を大切にしない。

一緒にいたい。悲しませたくないっていう人がいるから、人は自分の命を大切にする。

コード・ブルー ドクターヘリ緊急救命 セカンドシーズン

春と桜

春になったら桜が咲くのか、桜が咲くために春を呼ぶのか。

きっと菜の花が梅や桜の目をさまし、梅や桜が春を呼んでいるのだ。

だって、そのほうがロマンチックでしょう。

良い人生って何でしょう?

良い人生を送るには、どうしたら良いんでしょう。

そもそも良い人生って何だろう。

・・何でしょう・・・。

良い人生だって、思うことだと思うよ。

つまり、良い人生を送るには、良い人生だって思えばいい、ということですか。

そう。そうやって問うことは、少なくとも悪い人生ではない。

えぇ、そうですね。少なくとも、悪くはないってことが良い人生の条件でしょうね。

心の傷

心の傷を癒す簡単な方法はない。

ただ、こうも思う。

心の傷は、きっと必要なものだ。

なぜなら、心に傷を負う事で、他人の痛みに気付けるようになれるから。

コード・ブルー ドクターヘリ緊急救命 セカンドシーズン

SQL命令の分類

データベースといえば、SQL。でもよく知らない。だって、仕事には使わないもの。

だもんで、勉強中。ま、自分もアウトプットしつつ覚えていこうっていう魂胆。

命令の分類

命令とは、ようわ「SELECT」とか「CREATE VIEW」とかのアレ。述語のようなもの。

そんな命令には、大きく3種類の命令がある。

  • データ操作言語 (DML=Data Manipulation Language)
  • データ定義言語 (DDL=Data Definition Language)
  • データ制御言語 (DCL=Data Control Language)

各種の詳細を見ていく。

データ操作言語 (DML=Data Manipulation Language)

データ操作言語は、データ(「表」って呼ぶ)に対して、参照、修正(変更)、追加、削除の操作を行うものである。

SELECT
データを参照する。
UPDATE
データを修正変更する。
INSERT
データを追加する。
DELETE
データを削除する。

各命令の詳細については、また後述。

データ定義言語 (DDL=Data Definition Language)

データ定義言語は、データ(「表」ね)を作る操作を行う物です。

CREATE TABLE
データ・テーブルを作成する。
CREATE VIEW
データ・ビューを作成する。

テーブルとビューの違いについては、後述します。

あと各命令の詳細についても後述します。

データ制御言語 (DCL=Data Control Language)

データ制御言語は、先に述べた2つの操作を行えるかどうかを、許す、許さないを決めます。つまり、権限(アクセス権)を定義します。

GRANT
権限を付与する。
REVOKE
権限を取消す、取り下げる。

各命令の詳細については後述します。

命令の分類を覚える意義

最終的には、命令の分類は覚えていなくて構わないと思います。ただ、SQLを覚え始めたときには、各分類ごとに覚えるのが楽なので、強く意識して、各命令を覚えていくのが良いと思います。

ひとまず、以上