大変遅ればせながら、 なのですが、東海道線は、東京駅を通過するようになったのですね。知りませんでした。
先日、久しぶりに東京駅を利用する機会があり、ホームに並びました。
いつもだと、始発で座るために行列ができていることがしばしば。
でも、その日はそれほど並んでいないではありませんか。
ラッキーと思ったのもつかの間。到着した電車で、誰も降りない。
これまでだと、常に終点なので、全員降りて、車内清掃。そして、誰もいない電車に乗り込む・・という流れだったので、ビックリです。
あちこちの電車・路線が相互に乗り入れたりつながったり。。
複雑で難しくなる反面、事故の際のリカバリなどが柔軟になることを期待したいと思いました。
2015年4月3日金曜日
2015年4月1日水曜日
2014年2月24日月曜日
僧侶というジョブは普通にあるらしい
お寺を横切ったとき、「第○○回 青年僧侶評議会会場」みたいな立て看板を見た。
僧侶という職業はあったのだ。
衝撃。
もし自分が僧侶だったら、SNSのプロフィールに、
「ホイミもケアルも使えませんが、職業は僧侶です!みなさまの幸せなら祈れます」
とか書くだろうなぁと思った。
僧侶という職業はあったのだ。
衝撃。
もし自分が僧侶だったら、SNSのプロフィールに、
「ホイミもケアルも使えませんが、職業は僧侶です!みなさまの幸せなら祈れます」
とか書くだろうなぁと思った。
どうしてReadyBoostは流行らないか
重いアプリをたくさん起動する必要があり、コンピュータの処理が目に見えて遅い。。
そういうわけで、思いつきだったけれど、Windowsで、「ReadyBoost」というやつを試してみたら、体感的に効果があった。
素晴らしい。
どうして流行らないんだろうと考えた。
そうか
USBメモリって、IT業界では忌み嫌われているからか。
もったいない。
そういうわけで、思いつきだったけれど、Windowsで、「ReadyBoost」というやつを試してみたら、体感的に効果があった。
素晴らしい。
どうして流行らないんだろうと考えた。
そうか
USBメモリって、IT業界では忌み嫌われているからか。
もったいない。
そういえば、USBメモリって、出始めの頃は、超便利で、みんなが使っていた気がする。
どんなものも、使い方を誤ると、お互い残念な結果になるものだと思った。
2014年2月19日水曜日
DB2はパラメータに指定する文字列が長すぎるとエラーにするのが仕様らしい
他の主要DBは正常終了なのに、DB2だけエラー。
↓偉い人の実験結果
http://d.hatena.ne.jp/hhelibex/20090616/1245181281
IBMの方の言い分によると、ANSIだか何だかに正しく準拠されているのがコッチらしい。
(人から聞いた話なので、詳細不明)
うん、そうかもしれないけれど、絶対使いにくいです。
百歩譲って、設定でON/OFFできると素晴らしかったのに。
(ついでにデフォルトはオフ)
そういうわけで、次のバージョンでは、ぜひお願いします。
↓偉い人の実験結果
http://d.hatena.ne.jp/hhelibex/20090616/1245181281
IBMの方の言い分によると、ANSIだか何だかに正しく準拠されているのがコッチらしい。
(人から聞いた話なので、詳細不明)
うん、そうかもしれないけれど、絶対使いにくいです。
百歩譲って、設定でON/OFFできると素晴らしかったのに。
(ついでにデフォルトはオフ)
そういうわけで、次のバージョンでは、ぜひお願いします。
お仕事の進捗遅れの解決方法
ここ1年ちょいは、仕事の流れが、これまでにないくらい順調かつ平穏に流れていた。
もちろん、自分でもがんばったつもりだけれど、リーダーとして取りまとめてくれているひとの力量によるものが大きかったと思う。
学ぶことも大きかった。
で、1月から入ったプロジェクトが火を吹きはじめている。。
最近は毎日終電に近い。
まわりの人たちがいいひとであり、
やっている作業も新しく、面白いので、その辺でモチベーションを保っているけれど、それほど長く続きそうな気がしない。
スケジュールはタイトで、とても回復できる見込みがない。
もともとそれはわかっていたけれど、エンドが決まっているから決まったスケジュール。
まずはやってみようと始めたけれど、やっぱり無理。
現在のリーダーはイマイチ頼りがいがない。
残念ながら、昔私が失敗した案件の状況を思い出す。。
これまでの経験では、
案1.機能を絞って段階リリースを提案。
案2.予算オーバー覚悟で増員。
しかない。と思っていた。
で、PMにあたる人が介入。
その人の判断は。
現状の設計書精度を上げて、外部に発注する、というもの。
目に鱗。
その方法が最良なのかどうかはまったくもってわからないけれど、解決策というのは、たくさんあるものだなということに、ちょっと感動。
もっと視野を広く持ちたい。
もちろん、自分でもがんばったつもりだけれど、リーダーとして取りまとめてくれているひとの力量によるものが大きかったと思う。
学ぶことも大きかった。
で、1月から入ったプロジェクトが火を吹きはじめている。。
最近は毎日終電に近い。
まわりの人たちがいいひとであり、
やっている作業も新しく、面白いので、その辺でモチベーションを保っているけれど、それほど長く続きそうな気がしない。
スケジュールはタイトで、とても回復できる見込みがない。
もともとそれはわかっていたけれど、エンドが決まっているから決まったスケジュール。
まずはやってみようと始めたけれど、やっぱり無理。
現在のリーダーはイマイチ頼りがいがない。
残念ながら、昔私が失敗した案件の状況を思い出す。。
これまでの経験では、
案1.機能を絞って段階リリースを提案。
案2.予算オーバー覚悟で増員。
しかない。と思っていた。
で、PMにあたる人が介入。
その人の判断は。
現状の設計書精度を上げて、外部に発注する、というもの。
目に鱗。
その方法が最良なのかどうかはまったくもってわからないけれど、解決策というのは、たくさんあるものだなということに、ちょっと感動。
もっと視野を広く持ちたい。
2013年11月25日月曜日
PostgreSQL:out of memory で pg_dumpに失敗するとき
そんなとき、
原因は、large object(lo)にあるかもしれません。
もし、各テーブルのレコードをあらかた削除して、vacuumしても再現するなら、可能性は高いです。
手っ取り早く原因を切り分けるには、vacuumloを導入し実行してみて、再度 pg_dumpを試して再現しなければビンゴです。
(参考:vacuumlo -- PostgreSQLデータベースから孤児となったラージオブジェクトを削除する)
http://www.postgresql.jp/document/9.3/html/vacuumlo.html
原因は、large object(lo)にあるかもしれません。
もし、各テーブルのレコードをあらかた削除して、vacuumしても再現するなら、可能性は高いです。
手っ取り早く原因を切り分けるには、vacuumloを導入し実行してみて、再度 pg_dumpを試して再現しなければビンゴです。
(参考:vacuumlo -- PostgreSQLデータベースから孤児となったラージオブジェクトを削除する)
http://www.postgresql.jp/document/9.3/html/vacuumlo.html
登録:
投稿 (Atom)

