※ パクレゼルヴではWeb開発エンジニアを大募集中!詳細はこちら

Archive

Archive for the ‘その他’ Category

アルゴリズムのちょいメモ  

2008/8/4 月曜日 17:56:30

またまた登場。かーつんです。

今回はちょっとしたメモをば。
基本中の基本なので、学生さんは覚えておくと良いかも。

例えば、
a==bとなる確率1/6
b==cとなる確率1/3
c==dとなる確率1/2
のような条件がある場合、

if(a==b && b==c && C==d){
	処理;
}

と書くのと、

if(a==b){
		if(b==c){
			if(c==d){
			処理;
		}
	}
}

と書くのは同じです。

このとき、後者の書き方をしていると、
確率の小さいものから比較した方が良いというのが直ぐわかりますが、
前者のような書き方をしていると、
ついつい確率を無視して例えば

if(b==c && a==b && c==d){
	処理;
}

なんて風に書きがちです。

やってること同じじゃん。なんて思わないでください。
このif分が100回とか10000回繰り返す処理だと、
if分で比較される回数が比較にならないほど違ってきます。

些細な書き方の違いですが、
2個目の比較、3個目の比較をするかしないか、比較する必要があるかないか、
大量データを処理するとき等は気をつけて、
自分の書いている処理を見直してみてください。

以上、か-∇-つんがお送りしました。

かーつん PHP, その他

コードの保守  

2008/7/31 木曜日 23:48:23

最近(最近じゃないとも言う)おなかのお肉が気になるのびーにょです。
コンバンハ

さて、本題。

最近OSSのものを触っています。

色々内部変更してやってますけども、マジックナンバーが多すぎて解析に時間がかかります。
マジックナンバーだけが原因ではないですが。
マジックナンバーとは

コードを保守する必要がある場合や、追加、メンテ等を行う場合には、誰が見ても分かるように書くべきだと思います。
常に、何年も、何十年も自分が保守するつもりなら自分だけがわかるように書いても問題ないと思いますが、
仕事とはそうではありません。

担当が変わった、別の仕事してるから別の人に頼む、仕事を辞めた 等など

色々な理由で自身がずーーっと保守し続けることは難しいです。

でも、作ったものはそれなりに長い時間残ります。
自分の手を離れてしまっても、誰かが面倒みているわけです。

そんな人達に迷惑をかけないよう、笑われないように、誰が見ても分かるように書いておくべきだと思います。

どれだけエレガントに書こうとも、その物を保守する人達が見てわからない物だとその人達は苦労しますよね。

ソースのエレガントさ等は別に否定するつもりもありませんが、万人が見てわかる状態が一番望ましいと思います。

レベルが低く見える書き方でも問題ない、むしろ推奨すべきではないかと。

そんな感じで、僕はこれからも誰が見ても分かりやすいようにコードを書き続けたいと思います。

のびーにょ その他

システム運用は障害を未然に防ぐのだ  

2008/7/3 木曜日 16:11:30

サロン系の服着てます。姜子牙です。そのせいか年齢相応に見られません。
若作りじゃないですよ?

システム運用って暇そうだなあ、そう考えていた時期が私にもありました。
しかし、それは最も理想的な形でありつつ、決して何もしていないわけではないというのが分かってきました。

運用者が忙しそうというのは、決して良いシステムではないのです。
定常的に行うような手作業が発生しているのは、それだけオペレーションミスの機会が多いということですし
「定型的な作業を自動化する」というシステム化そのものの目的を全う出来てない可能性もあるからです。

また、技術者のスキルという側面から見た場合、それは起こり得る障害に対して未然の防止が出来ていない可能性も高いのです。
(偉そうに言えるほど自分が出来ているわけでもないですが・・・)

とは言っても、全体をとても幅広く把握しつつ、且つその中で1つのミスを許されないなんて場合もあります。
物理面で言えば、サーバの機械部分、設置場所の温度などの環境、各種ケーブル類が抜けないようになっているかなど。
ソフト面では、OS・M/Wから開発されたアプリまで。それぞれが個々に不具合がないことと、組み合わせた場合にも
それぞれがかみ合わずに不具合にならないかなど、枚挙に暇がありません。
他にも外的要因としてセキュリティの甘さによるクラックとかとか。

一度全て想定しうる全てを書き起こそうとして、目次に当たる項目を列挙したことがあるのですが
項目だけで300行近くにまで達して断念したことがあります。
(仮に1システム用の運用資料として、1項目平均4ページとしたら1200ページに達する)
まあ、重複項目・不足項目がどれだけあるかは不明なため参考にすらならないかもしれませんが・・・。

これらを全ての対策を全て事前に施せば・・・と考えることはありますが
それをするほどの予算や時間があることはなく、またそんな想定を超えたことでシステムが止まることもあったりするのです。
聞いた話であればlsコマンドでサーバが停止したこともあるとのこと。(かなり特殊なケースだと思いますが)

大小様々なシステムが、社会インフラとして当然になりつつ・・・いや、もうなっているのかな。
それらの停止によるダメージは日に日に上がっていっているように思います。
しかし、それに対してシステムを止めずに動かし続けることを考えられる人が追いついていない、そんなことを感じます。

問題提起に留まってしまいますが、ほんの微力でもそれを改善できればなあ、と思い本エントリは書いてみました。

[姜子牙](*’-') < 「まだまだ勉強が足りないですねっ。」

はい、行ってきます。

姜子牙 その他, 未分類

サーバ維持に必要なもの  

2008/6/17 火曜日 17:56:00

ガム食べ過ぎです。姜子牙です。700円くらいの大きいサイズのボトルガムが2,3日で無くなります。
ガムは無くなったらコンビニへ行き買って補充します。常にガムがあることが重要。

[Mr.マカー](#゚Д゚) < 「業務時間中に行くんじゃない。」
[姜子牙](;’-') < 「あ、すいません・・・。」

で、私のガムは我慢すればいいのですが、サーバは必要な物が無くなるとそれまでと同じ動きをしてくれなくなります。
車に使うガソリンほど目に見えて減る物は無いのですが、サーバでも消耗して放って置くと無くなってしまうものもあります。

一つは摩耗するハードウェアや物理媒体。バックアップメディアとして使用されるDAT・LTOであったり、定常的に使うようであればCD-Rやプリンタのインク・紙なんかが該当します。
無くなった際には速やかに補充できるように予備なんかを準備する必要がありますし、それらの発注や在庫管理なんかが必要になります。

[姜子牙](*’▽’) < 「ガムもここに・・・」
[べきこ] (´ー`) < 「入らないですね。」
[SELLCA]( ̄ o ̄) < 「どんだけガム好きなんですか。」

もう一つは期限付きの申請・ライセンス。ウイルス対策ソフトのアップデートライセンスであったり、サーバ証明書、ドメインなんかが該当します。
こちらは補充というより更新手続きなのですが、良くあるのが構築時点と担当者が変わり必要な更新手続きがなされなかったり、期限切れで使用できなくなってても気づかなかったりすることがあります。特にドメインなんかは、下手をすると余所に使われたりしてしまうことがあるので、何の申請をいつまでにしなければならないのかを構築時点で明確にしておくと、いざその時になって慌てずに済みます。

[チョコボール](o・。・o) < 「SUICAの定期が切れてて、気づいたらチャージが減ってるとか。」
[姜子牙](;’-') < 「定期切れてるのわかってるけど朝急いでると買えないんだよね・・・。」

期限切れなんてわかることじゃん、とは良く言われたりするのですが、申請スパンが年単位だったりするとその当時の担当者がいなくなっていて、わからなくなってしまうことが多いのですね。
(担当者が健在でも忘却の彼方になっていることもありますが・・・)

単にシステムを維持することは出来て当たり前ではあるのですが、その当たり前も案外大変だったりするのです。一つ一つは大した作業ではないものの、その全体に関連なく散らばっていることが多いため気づいたらあっちもこっちもなんてことが起こり得たりするのです。

[姜子牙](*’▽’) < 「継続は力なり。」
[かーつん](#゚Д゚)  / 「意味が
[のびーにょ](#゚Д゚) \     違う!」

はい、行ってきます。

姜子牙 Tips, その他

初心に立ち還る【報連相】  

2008/6/11 水曜日 17:30:01

こんぬつわ。かーつんです。

皆さん報連相ってご存じですよね。
報告・連絡・相談のビジネス基本3原則みたいなものです。

大きく言うと企業レベル、小さく言うとプロジェクトの各チームレベルで
これらがまともに機能しているのと、そうでないのとでは運営や進行に雲泥の差が出ます。

まぁ報連相それぞれタイミング的なものがあるんで、
報連相を行う相手次第で間を考える必要があり、
いきなり完璧を求めても無理だと思われるわけですが、
報連相を行うときに自分で意識して行っているか。というのがポイントです。

以下にどういうときに行うべきなのか、抜粋して書いてみたいと思います。 

【報告】「主に部下が上長に対して行う」
・(決定事項に対し)変更が生じたとき。
  ⇒ これを怠ると、上長の現状把握が遅れ、結果的には
     自分にその遅れた分の時間短縮が求められることが常です。
・結果報告(長期場合は中間報告)
  ⇒ 現在までの作業が終わり、次の作業指示を仰ぐ場合や、
     現状の進捗具合を知らせることでアドバイスを聞き出す時などに使います。

【連絡】「主に上長から部下に対して行う」
・情報共有
  ⇒ 企業又はプロジェクトの決定事項などを端的に伝える。
     「~だと思います。」とか、「~だったはずです。」と伝えるくらいなら
     伝えるのを控えた方がよいです。
     曖昧な連絡は誤解を生み、
     後々「あのときこういった。」とか、「こんな風に受け取ったんだけど。」という
     トラブルの温床になります。

【相談】「相手はまちまち」
  一番タイミングを計るのが難しいと思います。
  しかし、一番重要ともいえます。
  自分が詰まったとき、問題が発生してしまったとき、
  定義が曖昧なだけに行いにくいとも思いますが、
  自己解決したと思いこむこと程恐ろしいことはありません。

  人の動きから学ぶのが一番だと思いますが、
  適度に取り入れることにより自分の間違い・勘違いに
  気づくことが出来たり、情報の精度を高めることが出来ると思います。

  但し、忙しそうな相手にちょっとしたことを頻繁に聞くと
  確実に嫌われたり怒られたりするので、
  ある程度まとめて一度に質問したり、
  一度聞いたことは二度聞かずにすむようにメモを取りましょう。

とまぁ、こんな感じで、報連相を実施することで、
運営や進行をスムーズに進める事が出来ると思います。
細かい方法は企業やチームで風土があると思いますので、
臨機応変に。と言わざるを得ないですが、
「明らかに間違ってる!」という風土が出来ているようなら、
容赦なくブチ壊してしまいましょう。

基本に忠実に且つ臨機応変に、
自分たちに合った報連相を策定していくことが、
成功の秘訣ともいえると思います。

報連相。何それ?みたいな企業は、
早々に辞めてしまうのが得策かもしれませんね。

以上。か^-^つんがおおくりしました。

かーつん Tips, その他