重要なのはその余った時間で成したものがどうなるかということではないでしょうかね。

（答えは、このエントリにも書かれていることなんですが）自分の考えはこんな感じです。

担当外のことに手を出す

周りで業務に追われている人の手助けをする時間にあてるというのも一つではないかと。

ただ、基本的に自分に間接的にかかわる業務に絞ったほうが、自分にとっても相手にとっても都合がよいという具合に、やるべき仕事の対象をよ～く選んだほうがよいかと思います。

あまりにもあちこちに手を出しすぎると、それこそ都合のよい人となってしまいますし、それが評価に結びつかなければ、その分をただ働きをしたことと同じになってしまいます。

仕事ができる人ではなく、単なる「いい人」となってしまわないように注意が必要かと。

自分がやることで周りの人の評価を落とすことにもなりかねませんしね。

仕事ができるのに評価されないの人を見かけますが、この辺のことに手を出しすぎているような気もします。

同僚や後輩が困っている時にそれを手助けすることは良いことなのですが、そこにどっぷりつかるとせっかくできた空きの時間を食いつぶされかねません。

なので、基本的には自分の仕事の延長線上にあることに手を出すことが無難かと思います。

自分がレベルアップする時間にあてる

自分がより高いパフォーマンスを発揮できる人となれば、より短期に仕事をこなすことができて、会社的にもいいことになります。

給料泥棒なんて言葉がありますけど、それって「その人」に対する給与が問題ではなくて、その人がするべき仕事の時間単価に対しての言葉だと思います。

なので、その仕事がどれだけ効率的にできたのかということが重要で、その人への1ヶ月の給与が問題となっているわけではないかと。

同じ給料を支払っている2人の人がいて、一方が1ヶ月でする仕事を他方が2週間ででき、残りの時間をほかのことをしていても、1ヶ月に支払う給与は同じですが、仕事に対する単価は倍違うことになります。

社会的貢献にあてる

会社の雰囲気や文化によっては、そういうのを否定的に捉えられたりする場合もありますから注意が必要だったりもしますが、自分のやりたいこととそれがマッチするならこれも一つの時間の使い方だと思います。

1つの戦略としては、その社会的貢献がきちんと認められるようにするということではないでしょうか。

自分は、こういうことをやっていると社会的に認められれば、会社としてもそれを否定することが企業的なマイナスイメージともなりかねません。

そういうことだけで飯を食っていくのは厳しいようですが、一定の知名度が上がればそのことにマッチする企業が拾ってくれることも考えられますしね。

要は、その余った時間でその人が成したことが会社的にも都合がよければいいわけで、その同じベクトルを向いた範囲の中で自分がしたいことを見つけるのがベストなんだろうと。

自分のためだけの時間にあてて、それが会社的に何ももたらさないものであれば、評価もされないでしょうし。

自分は少しそういう感じの時間の使い方が多いので、少しこのエントリを書きながら反省していたりしますが・・・。

システムが淘汰する職業 - ITが人を幸せにするか -

プチ・ギークの作り方

エンジニアで何をあきらめ、何を拾っていくか

PostgreSQL8 外部からのアクセス制御あれこれ。

PostgreSQLは、インストール後の状態では、そのサーバー内からしかアクセスできません。

ユーザークライアント、またはアプリケーションサーバーからアクセスさせるためには、それらのサーバー（またはネットワーク）からの接続許可の設定をする必要があります。

接続を許可するネットワークインターフェースを開放する

まずは、そのサーバーとの通信の際に使用されるネットワークインターフェースを指定します。

指定の方法は、設定ファイルのpostgresql.confを編集します。

#listen_addresses = 'localhost' # what IP address(es) to listen on;
listen_addresses = '192.168.0.100'

上記の場合は、そのサーバーのネットワークインターフェースのうち、「192.168.0.100」のIPが設定されているほうのインターフェースでのリッスンを許可しています。

つまりは、複数のネットワークインターフェースを持っていない限りは、下記のように全てのインターフェースを許可してしまっても問題ありません。（もちろん、外部からの接続を許可する場合を除きます）

- 全てのネットワークインターフェースへの接続を許可する

#listen_addresses = '*'

複数のネットワークインターフェースを持っていて、そのサーバーのPostgreSQLのDBに接続するのが一方のN/Wセグメントからと決まっている場合、そちらの方だけのインターフェースを許可しておけばよいでしょう。

こうすることで、他のインターフェースからの接続要求を拒否することができます。

listen_addressesのパラメータのデフォルト値は「localhost」で、自分自身のサーバーからしか接続を許可しません。

なので、先に書いたように特定のインターフェースのみを指定してしまうと、そのサーバー内でのlocalhost指定の接続ができなくなってしまいます。

$ psql -h localhost testdb
psql: could not connect to server: 接続を拒否されました
Is the server running on host "localhost" and accepting
TCP/IP connections on port 5432?

listen_addressesは、カンマ区切りで複数指定することもできますので、localhost（またはループバックアドレス）と併せて記載しておいたほうがよいでしょう。

listen_addresses = 'localhost,192.168.0.100'

予断ですが、PostgreSQL7ではlisten_addressesのパラメータは無く、tcpip_socketというパラメータでした。

- PostgreSQLバージョン7でのN/W越しの接続許可の設定

tcpip_socket = true

上記のように、許可する（true）か許可しない（false）の指定しか方法が無く、どのインターフェースで接続を受け付けるかの設定はできませんでした。

アクセスを許可するネットワークを指定する

接続を受け付けるインターフェースの指定が終わったら、どのN/Wセグメントから接続を許可するかを指定します。

この指定は、pg_hba.confという設定ファイルに記載します。

一番最後の行にデフォルトの設定が記載されていますが、例えば

host all all 192.168.0.0 255.255.0.0 password

のように指定すると、192.168.x.xのN/Wセグメントからは、パスワード認証で接続を許可することになります。

DB名や接続ユーザーによる制限もできて、

host testdb hoge 192.168.0.0 255.255.0.0 password

のように指定すると、192.168.x.xのセグメントから、testdbに対して、ユーザーhogeでのパスワード認証を許可するようになります。

もちろん、サーバー側でリッスンしているインターフェースと通信できるN/Wセグメントで無ければ意味がありませんが。

条件に合致しない接続要求はサーバー側で拒否されます。

- エラーメッセージの例

FATAL: no pg_hba.conf entry for host "192.168.0.200", user "foo", database "hogedb"

必要があれば（多くの場合は必要でしょうが）、そのサーバー自身（localhost）からの接続許可も指定しなくてはなりません。

local all all trust

localhostからの接続を許可する場合は、先頭に「local」を指定します。

最後にしていている（上記の場合はtrust）のは、認証方式となります。

「trust」を指定していた場合、その他の条件が合えば無条件に接続されます。

一方で「password」を指定していると、接続時にパスワード認証が行われます。

その他にも、PAMやLDAPを使った認証方式も指定できたりします。詳細はマニュアル書かれているので、そちらも併せて確認してください。

PostgreSQL 8.3.5文章 21.1 pg_hba.confファイル

最後に、postgresql.confやpg_hba.confの設定ファイルを編集した場合は、デーモンに設定ファイルの内容を再読み込みさせます。

$ pg_ctl reload

[PR]★ロリポップ！★WordPressやMovableTypeの簡単インストール、cron、共有SSL対応！

[PR]格安固定IPが【５分で発行】＋【初期無料】＋【２ヶ月無料体験】

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

PostgreSQLの障害対策 - WAL編 -

PostgreSQLの障害対策 - Point In Time Recovery編 -

PostgreSQLバックアップ3分クッキング

JmeterでDB負荷テストをやってみよう！

ゼロから始められる幸せ

以前に書いた「悩む力」というエントリで紹介した本ですが、その中にこんな一文があります。

悩む力 (集英社新書 444C) P.51 末流意識という「あきらめ」

時代をゼロから創っていった世代には、「オレたちが頑張ったから、この国は発展したのだ」という満足感のようなものがあります。社会に多少の矛盾が生じても、当事者であるだけにさほど疑問を感じません。
（略）
しかし、すでにできあがってしまっている時代の中で生まれたものには、そのような充実感はありません。むしろ、世の中の矛盾ばかり目につき、それを創った世代に対して不満を感じます。

思い返せば、私はインターネットが企業内に深く浸透しだした2000年に入社して、社内のシステムもWebアプリに移行する変革の時にいました。

しかも、私が配属になった部署は、立ち上げの段階にあり、周りはほとんど同期という状態。

その中で、企業内の色々なシステムの立ち上げに携われて、今思えばかなりラッキーだったなぁと感じたりします。

以前に書いた「減っていく失敗できる環境、増えていく失敗できない環境」というエントリの中でも書いたことですが、今はそんなゼロから始められる環境というのはほとんどないのではないでしょうか。

自分たちの知恵を振り絞って何かをやろうという環境。

あるのは、そこにいる先人たちが築き上げたノウハウや経験からできた制約やルール。

後からそこに入ってくる人にとって見れば、紹介した文章に書いてあるような、そんな環境でも「俺たちが新しい時代を築く」という前向きな動機などではなく、今あるものへの疑問や先人たちとの間にある見えない壁による疎外感の方が強いような気もします。

この本を読んでふと自分の立場と、その後に入ってきた人の間には大きな壁があるのかな、と感じたりしました。

そういう人たちには「好きな方法でやっていいよ」とか「もっと若い世代が頑張らないと」って言ったところでそのような壁を感じ取っているのかもしれません。

SIerなどは、プロジェクトごとにゼロからのスタートとなることも多いでしょうが、やはりそこにも先人がいて、妙なルールも存在しているのではないかと思います。

また、特に私がいるような情報システム部門は、システムのライフサイクルとともに業務を組み立てるので、かなり息が長い業務が出来上がります。

そこには長年面倒を見てきたことによるシステムへの愛着なんかで、新しい人たちを知らず知らずのうちに追いやるような格好になっていたりしないでしょうか。