ラベル プログラミング の投稿を表示しています。 すべての投稿を表示
ラベル プログラミング の投稿を表示しています。 すべての投稿を表示

2013年1月16日水曜日

redmineのインストール

rubyのインストール ソースからインストールするとgemも入るよ^ー^ opensslも必要だよ http://ecpplus.net/weblog/?p=406 http://d.hatena.ne.jp/seiryo/20071213/1197545500 ImageMagick ImageMagickは最新版を入れるとRMagickが入らないよ^ー^ 参考: 'InitializeMagick' is deprecated これで一日ハマったよ^^^^^^^^^^^^^^^^^^ ImageMagick6.5.8でRMagick2.13.1がちゃんとはいったよ。 ついでに.soの共有ライブラリについても学んじゃったよ^ー^ Program Library HOWTO 3.1.2. ファイルシステム配置 共有ライブラリはファイルシステム内のどこかに配置しなければなりません。 ほとんどのオープンソースソフトウェアは、GNU 規約に従う傾向があります。 詳細は info:standards#Directory_Variables にある info ファイルドキュメントを参照してください。 GNU 規約は、ソースコードを配布するとき、デフォルト設定時にはライブラリを全て /usr/local/lib にインストールするよう推奨しています (コマンドを全て /usr/local/bin に配置するようにとも推奨しています)。 また、これらのデフォルト設定をオーバーライドしたり、インストールルーチンを呼び出したりする際の約束ごとも定義しています。 ファイルシステム階層規約 (Filesystem Hierarchy Standard; FHS) は、ディストリビューションにおいて何をどこにインストールすべきかを説明しています (http://www.pathname.com/fhs/ を参照してください)。FHS によると、ほとんどのライブラリは /usr/lib にインストールし、起動時に必要とされるライブラリは /lib に、システムの一部ではないライブラリは /usr/local/lib にインストールするのが良い、ということになります。 実際には、これら二つの規約間に矛盾はありません。 GNU 規約は、ソースコード開発者のためのデフォルト設定を推奨しているのであり、一方で FHS は、ディストリビュータ (通常、システムパッケージ管理システムによりソースコードのデフォルト設定を選択的にオーバーライドする人々) のためのデフォルト設定を推奨しているのです。 実際にこれはうまく機能しています。あなたがダウンロードした「最新の」(おそらくバグだらけの!) ソースコードは、自動的に自分自身を「ローカルな」ディレクトリ (/usr/local) にインストールします。 そしてコードが成熟してきたら、ディストリビューション用の標準的な位置にコードを配置するため、パッケージ管理ツールでデフォルト設定を簡単にオーバーライドできます。 あなたのライブラリが、ライブラリ経由でしか呼び出されることのないプログラムを呼び出しているのならば、それらのプログラムを /usr/local/libexec (あるディストリビューションでは /usr/libexec になります) に配置するべきです。 厄介なのは、Red Hat から派生したシステムがデフォルト設定では /usr/local/lib をライブラリ検索対象に含めていないということです。 /etc/ld.so.conf に関する下記の議論を参照してください。 他の標準的なライブラリ配置場所としては、X Window System 用の /usr/X11R6/lib があります。/lib/security は PAM モジュール用に使われますが、通常、PAM モジュール群は動的ライブラリ (これもあとで説明します) としてロードされるので注意してください。 3.2. ライブラリはどのように使われるか GNU glibc ベースのシステム (全ての Linux システムが含まれます) では、ELF バイナリ実行ファイルを起動すると、自動的にプログラムローダがロードされ、実行されます。 Linux システムでは、このローダは /lib/ld-linux.so.X (X にはバージョン番号が入ります) という名前です。 このローダは、プログラムによって使用されるその他の全ての共有ライブラリを順次探し出し、ロードします。 検索対象となるディレクトリのリストは、/etc/ld.so.conf ファイル内に記述されています。 Red Hat から派生しているディストリビューションの多くは、通常 /etc/ld.so.conf ファイル内に /usr/local/lib を含めていません。私はこれをバグだと考えており、また、/usr/local/lib を /etc/ld.so.conf に追加することは、Red Hat から派生しているシステム上で多くのプログラムを走らせるのに必要な、共通の「修正」だと思っています。 wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz tar zxf yaml-0.1.4.tar.gz cd yaml-0.1.4 ./configure make sudo make install

2011年7月15日金曜日

python:TypeError 継承した親クラスの__init__ 

まずはこーんなエラー
TypeError: Error when calling the metaclass bases
module.__init__() takes at most 2 arguments (3 given)


from module import name1,name2
とするか
module.name1()
として呼び出せとのこと。
pythonで継承(TypeError?)

次にこんな感じのエラー
TypeError: unbound method __init__() must be called with ChilidClass instance as first argument (got ParentClass instance instead)
こんな感じでいいみたい
class ParentClass:
    def __init__(self):
        pass

class ChildClass(ParentClass):
    def __init__(self):
    ParentClass.__init__(self, param)


じゃ、そういうことで。

2011年6月23日木曜日

Zend_LogのFirebugのコンソールへの出力について

 Zend_LogのFirebugのコンソールへの出力ができねぇ。できねぇ。と思ってたら
あれはhttpheaderを使ってるからGreeを介してたら使えねーわけだな!?
はっは~ん。してやられたぜww

2011年3月31日木曜日

Zend_Db_Table における独自の検索メソッドの定義

Zend_Db_Table における独自の検索メソッドの定義

もし特定の条件によるテーブルの検索を頻繁に行うのなら、 独自の検索メソッドをテーブルクラスで実装できます。 大半の問い合わせは fetchAll() を用いて書くことができますが、 アプリケーション内の複数の箇所でクエリを実行する場合には 問い合わせ条件を指定するコードが重複してしまいます。 そんな場合は、テーブルクラスでメソッドを実装し、 よく使う問い合わせを定義しておいたほうが便利です。

Zend_Db_Table

2011年3月28日月曜日

Zend_Db テーブルへの式の挿入

データ配列の中の値を SQL の式として扱い、 クォートしたくない場合もあるかもしれません。 デフォルトでは、文字列として渡した値はすべて文字列リテラルとして扱われます。 その値が SQL の式であること、つまりクォートしてはいけないということを指定するには、 文字列ではなく Zend_Db_Expr 型のオブジェクトをデータ配列に渡します。
  1. $data = array(
  2.     'created_on'      => new Zend_Db_Expr('CURDATE()'),
  3.     'bug_description' => 'Something wrong',
  4.     'bug_status'      => 'NEW'
  5. );
参考リンク
http://framework.zend.com/manual/ja/zend.db.adapter.html

クラスの作り方

クラスの中身を知るために何階層もたどらなきゃいけないようなのは分かりづらいからだめだ。
つまり今つくっってるのはだめな感じだ・・・。

クラスやメソッドは中身がわからなくても使えるようにするべきなんでしょ?
テレビやリモコン