Tag : Coding

1 - 7 of 17

Pythonを触ってみる(その2:GTK編)

python-logo.png

前回のHelloworldはフォントやボタンの部品の見た目ががしょぼくてイマイチだったので、なんとか出来ないかと調べて、PythonでGTKを使う方法を発見。

インターフェイス部分は「Glade」というソフトを使ってやる、ということなので早速導入して起動。

pygtk-glade.png

ようはMac OS XでいうこところのInterface Builderですね。あっちより少しシンプルでやや「突き放し系」です。Interface BuilderにあるようなクラスやインスタンスをGUIで作ったり関連付けたりというような感じではなく、純粋にGUI部品を作ることにフォーカスする感じです。部品を並べてプロパティやアクションの定義などをしていきます。

チュートリアルを参考にしながら、部分的に日本語にしてカスタマイズ。

#! /usr/bin/env python
#-*- coding:utf-8 -*-

import sys

try:
    import pygtk
    pygtk.require("2.0")
except:
    pass
try:
    import gtk
    import gtk.glade
except:
    sys.exit(1)
    
class HelloWorldGTK:

    # アプリケーションの初期化
    def __init__(self):
    
        # Gladeファイルをセット
        self.gladefile = "gtkhelloworld.glade"
        self.wTree = gtk.glade.XML(self.gladefile)
        
        # dictionaryを作成し、接続
        dic = { "on_buttonHelloWorld_clicked" : self.buttonHelloWorld_clicked,
            "on_MainWindow_destroy" : gtk.main_quit }
        self.wTree.signal_autoconnect(dic)

    # 「こんにちは」ボタンがクリックされた時に呼ばれるメソッド
    def buttonHelloWorld_clicked(self, widget):
        print u'こんにちは!'


if __name__ == "__main__":
    hwg = HelloWorldGTK()
    gtk.main()

$ python gtkhelloworld.py

で起動。

pygtk-helloworld.png

・・・と、こんな感じで上手く起動出来ました。GUI部分がGTKになることでフォントや部品の見た目が綺麗になってGNOMEとの親和性も高くなった感じですね。

関連URI

Pythonを触ってみる

python-logo.png

.to_sとかputsという書き方が気にくわない」という理由でRubyに学習意欲が沸かず放置中の私なのですが、第二言語としてRuby以外の選択肢を物色してみることに。

そんな中、Ubuntuを使い始めてからというもの、あちらこちらで目にする「.py」の拡張子。「なんかLinuxの世界ではPythonが来てるのかな?」と思いつつ、その事を知人と話していると「Python凄いよ。少ないコードで簡単にGUIが出来る」と言われ、試してみることに。

私が言語を始めて勉強する時にまずやることは、

  1. とりあえず自分がやりたそうなことが出来るコードを探し、それをそっくりそのまま真似て書いてみる。
  2. 変数名とメソッド(関数)名をオリジナルに変える。これだけで「自分のコードになった気」になる。ここ大事。
  3. 別のサンプルコードで同じ事をやり、それらを合体させてみる。

という手順です。2.は「なんだそれパクリじゃないか」と言われそうですが、はい、そうです、パクリです。パクリは学びの全ての基本です。・・・ということで、一番大事な部分だと思ってます。

では早速、このセオリーに従ってやってみました。参考にしたのは以下のサイトの「Helloworldチュートリアル」

で、これを真似て書いたのが以下のコード。

#! /usr/bin/env python
# -*- coding:utf-8 -*-

from Tkinter import *
import Tkinter as Tk

# Applicationクラスの定義
class Application(Frame):

    def sayHi(self):
        # 文字を書き出す処理
        aLabel = Tk.Label()
        aLabel["text"] = u'こんにちは'
        aLabel.pack()

    def createWidgets(self):
        # 終了ボタンを作成
        self.quitButton = Button(self)
        self.quitButton["text"] = u'終了'
        self.quitButton["fg"]   = "red"
        self.quitButton["command"] = self.quit
        
        self.quitButton.pack({"side": "left"})
        
        # Helloボタンを作成
        self.sayHiButton = Button(self)
        self.sayHiButton["text"] = "Hello"
        self.sayHiButton["command"] = self.sayHi
        
        self.sayHiButton.pack({"side": "left"})
    
    def __init__(self, master = None):
        Frame.__init__(self, master)
        self.pack()
        self.createWidgets()

# Applicationクラスからインスタンスを生成し、実行。
app = Application()
app.mainloop()

これを「helloworld.py」というファイル名で保存し、実行してみます。Terminal上で

$ python helloworld.py

と打つと、以下のようなプリミティブなGUIを持ったアプリが立ち上がりました。(おぉっ!と感動)

python-hello1-macosx.png

クリックすると、「こんにちは」の文字が書き出されます。「終了」ボタンで終了。

python-hello2-macosx.png

同じコードをネットワーク経由しているUbuntuのTerminalからも実行してみる。

python-hello2-ubuntu.png

と、同じように実行出来ました。いやはや素晴らしい。

Pythonは、実は以前は「本家サイトのデザインとロゴがダサい」という理由で敬遠していました。「そんな理由で・・・」とお叱りを受けそうですが、私は言語といえどもそういう部分は大事だと思っています。で、最近はロゴもサイトも新しくなって洗練されたものになったのでいい感じになったと思います。LinuxとMac OS Xで同じコードが普通に動くのも気に入りましたし、なによりコードがシンプルに書けて見た目も美しい。見た目的にはPHPより好きかも。・・・ということで次の研究対象言語はRubyではなくPythonにすることにしました。

CakePHPをイジってみた

人気の三大PHPフレームワークの中で最近人気上昇の感がある「CakePHP」を触ってみた。

ダウンロード後、Ubuntu 7.10で動かしているXAMPPの「/opt/lampp/htdocs/」直下に「/opt/lampp/htdocs/CakePHP」と解凍してインストール。

とりあえず初物は何はなくともチュートリアル、ということで、こちら(↓)

を参考に、MySQLのデータを「追加、更新、削除、一覧表示」という基本機能が実装されたブログを作るチュートリアルを一通りやってみた。

うーん、素晴らしい。何が素晴らしいかというと、このチュートリアルが素晴らしい。30分程度で、一通りの使いかたが分かり、きちんと動くアプリが作れました。この「ちゃんと動くチュートリアル」、というのがイイ。当たり前なんですが、チュートリアルでさえこなせないチュートリアルって結構あるんですよね。途中でグダグダになってしまったりとか。私の場合だけかもしれませんが。

で、肝心のCakePHPはどうかというと、Ruby on Railsに似ているなーってのがファーストインプレッション。まぁ私の場合Ruby on Railsも触った程度なんですが、同じ感触を感じました。こういうフレームワークでの開発の好き嫌いは別にして、出来はものすごく良いんじゃないでしょうか。

なんとなく、XCodeとインターフェイスビルダーを使った感覚にも似てます。私が始めてCocoa&Objecitve-Cを触った時に参考にした本は、ウィンドウ一つ表示するのにウィンドウのサイズまでコードで指定する「ゴリゴリ系フルスクラッチ」だったのですが、その後でインターフェイスビルダーを使ったら「あら?こんなに簡単に出来ちゃって。あのコードをゴリゴリ書くテクニックは?」と感じたのですが、それに近いものを感じました。

まぁ、突っ込んだ機能を実装するにはフレームワーク独自のクラスやルールを覚えたりと結構研究しなければならないのはCocoaとかと同じですが、基本的なルールがガチガチに固められている、っていうのはある意味「誰でもある一定レベルまで一気に持っていける」という意味では必要なのかもしれません。

私的に好きか嫌いかと言われると私はHTMLのハンドコーディングに始まってああいう泥臭いコーディングが好きなので、こういうRails系のスマートなフレームワークのテイストはあまり好きじゃないんですが、研究対象としては面白いと思います。

CSSをアップデート

Safari 3でレイアウトが崩れるというご指摘を受けたので修正していたところ、ついでなので半年以上ぶりにCSSをアップデートしてみました。適用されていない場合はスーパーリロード(Safariの場合は+Alt+Eした後にShift+リロードボタンをクリック、Internet Explorerの場合は「インターネット一時ファイル」のキャッシュを削除した後にCtrl+「更新」ボタンをクリック)してみてください。

デザイン的な基本であるブラック+ホワイトという基調やカラーリングは殆ど変えずに継承しましたが、最近ボックスレイアウトデザイン(というのが正式名称かどうかは知りませんが、私が勝手に命名した、blog普及とともに急増した感のある箱枠のあるレイアウトデザイン)に飽きてきたので取っ払ってみました。

この私が言うところのボックスレイアウトデザイン、やるだけで見た目がカワイイ感じでオシャレに見えたりするので嫌いではないんですが、有名CSSデザイナーがこのタイプのblog用テンプレートを配布したりした頃からどこもかしこも箱庭デザインだらけになってしまった気がするのと「これやればなんとなーくblogっぽいデザインになる」感が漂う(あくまでも私感です)のでちょっと脱却してみようかと。

その代わり、ボックス外側の背景にとっていた分のスペースを各セクションのマージン取りに活用して、フォントも大きめにして、テキスト部のコントラストも高めにして、「様々な解像度のモニター環境でもテキストが読みやすいデザイン」という部分に意識して注力してみることにしました。Webデザインの目指すところは結局は「テキストが読まれてなんぼ」という至極当たり前の結論になると思うので。

細かいところでは、CSSを「default.css(コアになる部分」「modules.css(パーツ部分)」「text.css(テキスト部分)」に分離してみることにしました。

jamstyle-mid2007-css-structure.png

まぁ、古いコードを沢山継承しているのでまだ完全に分離出来てない箇所もあるんですが、この辺は追々。

あと、これまでモチーフにしていたタイトル部分のMacBookアイコンを外してみました。もうMacBookはあのような普通のノートスタイルで開いて使っていない&今後も恐らく使わないので私のMacBookスタイルじゃないというのと、最近の私の考える快適なMac環境は「Macが全面にあるのではなくコアにある」というスタイルに行き着いてきたので、こよなく愛用しているEIZOのモニタとHappy Hacking Keyboardをインターフェイスに、画面(コア)にMac OS Xが映っている、というアイコンで表現してみました。

まぁ、そんな他愛もないことを考えながら「ちょいリデザイン」してみました。

「たのしいCocoaプログラミング」が届いた

Amazonに予約発注していたHMDTの木下さん著の「たのしいCocoaプログラミング」が到着。

たのしいCocoaプログラミング

Amazon.co.jp: たのしいCocoaプログラミング: 本: 木下誠

プレゼントキャンペーン(たのしいCocoaプログラミング ‹ HMDT)もやっているみたいです。私はキャンペーン知る前にすでに発注していたので参加出来ませんが、Blog持ってる人は明日までだそうなので申し込んでみるといいかもしれません。

ざっと見た感想ですが...まず、タイトルのフォントの力の抜け具合が良いですね。気軽にやってみよう、って気にさせます。あと、ブックカバーが半透明の薄いカバーになっていて、なかなか新しくてオシャレです。プログラミング系の本というとどうも教科書っぽく堅苦しい見た目が多いのでこれはGOOD。

中身は「プログラミング初心者向け」というより「Mac OS Xプログラミングの初心者向け」という印象を持ちました。口調が「です・ます」調でなく、HMDTのサイトで見られる木下さんの口調で書かれていて砕けた感じで親しみやすいです。それでいて変に説明を端折ってないところが良いですね。

木下さんのアップルのサイトで手に入るアップルジャパンでのセミナーのCocoaチュートリアルをやった事がある人は分かると思いますが、あのチュートリアルが分かりやすくて素晴らしい。私も初級から最後までやってみましたが、「Mac OS X上でのCocoaプログラミングとは何ぞや?」というものの「コアな部分」が理解出来ます。それをさらに補完するサイドテキストとしてもこの本は優れていると思います。

システムを更新、その他

中味をアップデート

当サイトのバックエンドを支えるオリジナルWeblogエンジン「LOGGiX」をローカルで開発中の最新ビルド版に更新。見た目は殆ど変わらないですが、中味は色々と手を加え中です。

「Permalink」の表記を廃止(及びローカライズの考察)

これまで記事の下に「コメント」「トラックバック」と並んでいわゆるPermalinkである「恒久URI」というリンクを表示していましたが、これを廃止し、記事タイトルをクリックする事によってパーマリンクにナビゲートされるスタイルに変更しました。これはリンクタイトルが記事を指し示す方が良いと考えたのが理由です。あと、フッターをシンプルにしたかった、というのもあります。

CSS Nite公式ブログ: Permlinkを「固定リンク」に変更しましたという記事も見つけたので「Permalinkのローカライズの標準化」についてもどうしたものかなーと考えていました。

私はこれまで私自身が使っていた「恒久URI」という名称が一番気に入ってます。このほうが「Permalink」の本質を指していると思うんですがどうでしょう? その次の候補としてはちょっとしたメモ - The Web KANZAKIで使われている「恒久ページ」かな。もし「URI」というのが一般的でないというなら「恒久リンク」の方が良いですね。

どうもCSS Niteの推奨する「固定リンク」というのはしっくりきません。何を「固定」するのか。「リンク」なのか、ターゲット先のPermalinkなのか。「Perma」は「Permanent (恒久)」の略であり、永続的なURIにナビゲートするための「リンク」であるわけで、「アンカーのタイトルがターゲット自体を指していない」と思うわけです。

なんとなくその方面の方々に影響力の大きそうなサイトが採用して日本での記述やローカライズのデファクトとなっていくと昔の「ホームページ」のように本質を表していない訳が蔓延するとイヤだな、と思ったので書いてみました。

テンプレートエンジン「Loggix_View」をアップデート(及び考察)

このサイトのシステムを支える自前テンプレートエンジン「Loggix_View」をちょっとコーディングし直してアップデート。ここのところZend Frameworkのソースを眺めていてテンプレート変数の適用メソッドであるassign()の実装(参照:Zend Framework:15.2.1. Assigning Variables)が面白いというか便利だなと思ったので同じような使い方が出来るように実装してみました。

ただ、Zend_Viewのassign()は私の使用方法での変数にオブジェクトを入れるような使い方が出来ないので、それではちょっと柔軟さに欠けるかなと思い変数にもテンプレートオブジェクトを入れることが出来るような仕様にしてみました。これで大抵のテンプレートの使い方は殆どカバー出来るようになったのでViewクラス周りは一段落です。

Loggix_Viewの実装にあたっては、Smarty、Ethna、Savant、Zend FrameworkのZend_Viewなどなど、色々なテンプレートエンジンのソースを読んだり使ったりして研究しましたが、私が一番気に入ったのはRaw Template Engineでした。

作者のkomagataさんのサイトでは後ろ向きなライブラリと謙虚に語られていますが、実際PHPのテンプレートエンジンはこのような「PHP自体がテンプレート言語」という方向性が一番良いと思っています。Zend FrameworkもPHP自体をテンプレート語として使用出来る仕様になっていますし、Loggix_ViewもZend_ViewとRaw Template Engineのエッセンスを取り入れた仕様にしています。(メソッド名はZend_ViewとSmartyユーザーにも馴染めるように変数適用にはassign()、テンプレートを取り込んで変数を適用するメソッドにはrender()を使用。)

結局「モデル(M)&コントローラー(C)からのビュー(V)の分離」というのは「(X)HTMLファイルからPHPコードを追い出す事」ではなく、「プレゼンテーションロジックをVへ纏め、ビジネスロジックをCに纏める」、ということなんですよね。つまり、「言語の分離」ではなく「ロジックの分離」である、と。そこに別の「オレ仕様・独自仕様の言語」が入る余地も理由もないと思う訳です。

私がアンチSmartyなのは結局Smartyは同じ事を独自言語(オレ言語)で再実装している仕様だと感じるからなんです。メリットは「PHP変数を(X)HTMLテンプレートファイルに{$var}と書く事が出来る=PHPっぽく見えないのでPHP分からない人に心理的にちょっと楽」というのと「キャッシング機能が出来る」というだけだと思っています。

そういう点からもSmartyよりもZend_Viewが方向的にPHPの本質を分かった実装になっていてずっと良いと思いますし、ZendやRaw Template Engineのようなテンプレートエンジンを使ったWebアプリがもっと増えると良いと思ってます。

1 2 3 次へ