« 2007年12月 | メイン | 2008年02月 »

2008年01月 アーカイブ

2008年01月01日

検見川浜、幕張の浜




2008年01月02日

富士山のようにどーんとでっかくいこう

今朝りんたろうの散歩にいったら北の空は真っ青で快晴。
北風が冷たく、富士山がくっきりと見えるのではと思い、
早速家に戻ってからカメラをもって海浜幕張までいってみました。
案の定、みえました。
マリンスタジアム裏から撮りました。







2008年01月06日

HDR

2008-01-05 T16:27:27 HDR海浜幕張 Vol.9



2008-01-05 T15:32:44 HDR海浜幕張 Vol.8


2008-01-05 T16:09:39 HDR海浜幕張 Vol.7


2008-01-05 T15:59:04 HDR海浜幕張 Vol.6


2008-01-05 T15:19:17 HDR海浜幕張 Vol.5


2008-01-05 T15:29:43 HDR海浜幕張 Vol.4


2008-01-05 T16:11:15 HDR海浜幕張 Vol.3


2008-01-05 T16:25:20 HDR海浜幕張 Vol.2


2008-01-05 T15:30:04 HDR海浜幕張 Vol.1

2008年01月12日

全国の路線・駅一覧とgoogle mapのコラボ

全国の路線・駅一覧とgoogle mapを組み合わせてみました。

http://www.iplusone.co.jp/service/STATION/station_map5.php

社内Fedora7環境で作っていたものを
弊社ホスティングサイトへ移行したときのメモを残しておきます。

基本的に、文字コードのお話

Fedora7からutf8になり、PHPも、MySQLもutf8と楽チンになったのだけれど
ほかの環境ではそうはいきません。

まだまだEUCなサイトは多いです。
移行の手順は次の通りです。

(1) mysqldumpでutf8でダンプする。
(2)ダンプしたファイルをEUCに変換
(3)移行先に、テーブルをEUCで作成&データも文字コードEUCで流し込む

これで、データは完成。

次にプログラムの変更

(1)PHPも、EUCにコード変換
(2)テーブルから取得した文字コードは、EUCなので、EUC→utf-8へ変換が必要

 mb_convert_encoding(変数,"UTF-8","EUC-JP")


(3)google map APIは、utf-8でないと使えないのでscriptで文字コードを指定する

<script src="http://maps.google.com/maps?file=api&v=2&key=....." type="text/javascript"></script>

ここの部分に、次のようにcharasetを指定する。


<script src="http://maps.google.com/maps?file=api&v=2&key=....."
type="text/javascript" charset="utf-8"></script>

2008年01月13日

vi V.S. emacs

UNIX上でのエディタといえばviとemacsがあり
設定ファイルやデータなどの編集にはvi
プログラムの作成にはemacsを利用している。

昔から、vi派、emacs派がいて、両者の不毛な討論は耐えなかったのだが
わたしから言わせれば、適材適所で両方使えるようにしておけ。だ。

viを使い倒そう

GNU Emacs Manual

2008年01月16日

一方のテーブルに存在して、一方のテーブルには存在しないレコードの確認

一方のテーブルに存在して、一方のテーブルには存在しないレコードの確認。

これをOUTER JOINでやってみる。
どれくらい時間がかかるのか。

mysql> select t1.CODE from M_RAIL t1 LEFT OUTER JOIN M_STATION t2 ON t1.CODE = t2.CODE WHERE t2.CODE IS NULL ;
+---------+
| CODE |
+---------+
| 0101032 |
| 0101033 |
| 0101081 |
| 0101091 |
| 0101101 |
| 0101111 |
| 0101121 |
| 0103021 |
| 0103031 |
| 0103041 |
| 0104011 |
| 0104021 |
| 0201011 |
| 0403011 |
| 2104011 |
| 2701093 |
| 2104011 |
+---------+
17 rows in set (1 min 17.40 sec)

OUTER JOINは INNER JOINと違い、条件に一致しなかったレコードも含めて結合します。
LEFT OUTER JOINは、左外部結合なので、左を基準に、右オペランドのテーブルから
一致するレコードがない部分はNULL値で埋められます。
上のSQLでは、路線テーブル(M_RAIL)にあって、駅テーブル(M_STATION)にないレコードの路線コードを表示しています。

路線名も出力します。

mysql> select t1.CODE, t1.NAME_KANJI from M_RAIL t1 LEFT OUTER JOIN M_STATION t2 ON t1.CODE = t2.CODE WHERE t2.CODE IS NULL ;
+---------+-------------------------------------+
| CODE | NAME_KANJI |
+---------+-------------------------------------+
| 0101032 | [JR]根室本線 |
| 0101033 | [JR]根室本線 |
| 0101081 | [JR]留萌本線 |
| 0101091 | [JR]富良野線 |
| 0101101 | [JR]宗谷本線 |
| 0101111 | [JR]石北本線 |
| 0101121 | [JR]釧網本線 |
| 0103021 | [札幌市営]南北線 |
| 0103031 | [札幌市営]東豊線 |
| 0103041 | [札幌市電]山鼻線 |
| 0104011 | [函館市電]2系統 |
| 0104021 | [函館市電]5系統 |
| 0201011 | 津軽鉄道 |
| 0403011 | [仙台空港鉄道]仙台空港線 |
| 2104011 | 神岡鉄道 |
| 2701093 | [JR]北陸本線 |
| 2104011 | 神岡鉄道 |
+---------+-------------------------------------+
17 rows in set (1 min 17.28 sec)

2008年01月26日

Delphiな日々

Delphiは1から使いはじめて
2,3,3.1,4,5,6と使ってきたが
7は買わず
8は買ったがインストールせず
2005,2006は買わずと。
そして、ひさしぶりに昨年2007をかったけど
もう2008年になってしまった。

Borland製品はTurbo Cから使っているので
やはりBorlandには格別な愛着がある。
開発ツールで金を出して購入してきたのはBorlandだけだ。
ああVisual Studioを一度大金を出して購入したことがあるか。

さて、今ではCodeGearである。
まあ、Borlandというブランド名は残っているので
どんな会社がやっていこうと消えなければよいであろう。


さて、せっかく買ったツールなので
久しぶりに何か作ってみようと、ようやくインストールをしてみた。

しばらくは、Delphiについて書いてみる。

MessageDlgでメッセージを出してみる

リハビリをかねて、書き出してみたが
やはり、しばらく使っていない言語、開発ツールは
スムーズに事が進まない。

曖昧ながら記憶を辿りながら進めてはいるが
勘違いも多いので、なんてことのないコードを書くだけでも時間がかかる。

さて、メッセージダイアログを表示するだけで、結構な時間をくってしまったので
そのあたりをあとめておく。

DelphiのMessageDlgを通して、マニュアルの読み方を考えてみる

メッセージダイアログ関数は、メッセージ以外に、ダイアログの種類と、ボタン、ヘルプコンテキスト番号を指定する必要がある。
ダイアログの種類というのは、警告かエラーか、インフォーメーション、確認かといった
以下の定数の中から1つ指定する。

で、次のボタンは、ダイアログに表示するボタンなのだが、
TMsgDlgBtnを直接指定してはいけない。


ここは、TMsgDlgButtons、つまり set of TMsgDlgBtnである。
TMsgDlgBtnの集合である。

仮に1つのボタンだけの場合でも、mbYesと書くのではなく、[mbYes]となる。


良く利用するボタンの集合型は、以下のように定義されている。

さて、実際書いてみる。

1.jpg


w.jpg


e.jpg


i.jpg

c.jpg

2008年01月27日

ソフトウエア開発の歴史

コンピュータの歴史はまだまだ浅い。しかもビジネス向けにソフトウエアを開発するように
なってからまだ・・・

モークリー、エッカートのENIACが、1946年だから、62年前。
これが真空管 18,800本 リレー 1,500個で弾道計算用につかわれ、
10進演算方式で乗算2.8msecだそうだ。

この2年後に、ノイマン型コンピュータEDVACだから丁度60年前。
商用としての初のプログラム内蔵方式は、UNIVAC-1 これも同じ年。

IBMがFORTRANをつくったのが、この4年後の1956年。
言語があれこれ沢山出てはいるが、
昔は限られた資源を利用して、目的が明確であった。

しかい、コンピュータの性能があがってくると、
より人間の高い要求にこたえられるようになってきた。

長らくは、手続き型プログラミングが主流であり
理論としてのオブジェクト指向はあったがビジネスで使われだしてきたのは
この10年くらいまえからだ。

今の時代は、言語に左右されるのではなく、
まずは理論をきちんとつかんで、さまざまな言語を適材適所で使えるというのが理想だ。

データ構造とアルゴリズムが理解できれば、
それをもとに構造化したプログラムをかいてみればよい。

オブジェクト指向になれてみたければ、理論を学び、じっさいクラスを書いてみればよい。

2008年01月28日

オブジェクト指向を選ぶ理由

わたしが、開発を始めた頃、手続き型からオブジェクト指向への
パラダイムシフトが盛んに記事になりだして
オブジェクト指向全盛時代が到来すると書かれていました。
わたしも、Borland C++でC++を覚えてからは、仕事でC++を書きたくて
うずうずしていました。
パソコンレベルでは、まだまだ環境が貧弱で、それを有効に使えるというわけでは
ありませんでした。

UNIX環境の交換機保守システムではじめてC++案件をやったとき、
そのプロジェクトのでかさと、設計工数の大きさに驚いきました。

当時、クラス定義書はX上で、tgifを使って書いていました。
クラス定義も、結局、人によるところが大きく、
沢山の外注が集まって開発しているため
良いクラス、悪いクラスの差もあったように思います。

ただ、明らかに、各人が作っている「もの」がクラスに閉じていること、
つまりカプセル化されていることによるメリットを感じました。

About 2008年01月

2008年01月にブログ「iPLUSONE Blog」に投稿されたすべてのエントリーです。過去のものから新しいものへ順番に並んでいます。

前のアーカイブは2007年12月です。

次のアーカイブは2008年02月です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.34