サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
gallu.hatenadiary.jp
おおむねこんな感じを想定。 ベースになるのは /dev/urandom なので。「環境ノイズが以下略」的な話は、きっとなんとかなるだろうしてくれるだろうだからある程度暗号的に安全な擬似乱数であろう、ことを、期待(笑 shaが1ぢゃなくて512なのは、おおむね、おいちゃんの癖。長いほうが推測しにくいっしょ? で、ハッシュにはどうしても「ハッシュのbit数よりもでかいのを渡しておきたい」ほうなので、少し大きめに。 「処理にかかるCPUコスト」は、比較的軽視の方向で。 というような思考回路を経て作った、超ざっくりなトークン生成。 $token = hash('sha512', file_get_contents('/dev/urandom', false, NULL, 0, 128), false); var_dump($token); でもまぁ、ワンタイムトークン用で、かつ「ンなに長い寿命を持
躊躇も脈絡も無く、start。 まずはinstall。 gitで引っ張ってこれるので大変においちゃん好み。 適当なディレクトリにおいておきましょう。 clone git://github.com/mlively/Phake.git phake今回は「phake」ってディレクトリにしておいた。素直というよりは単純。 まず「使える」ようにする。 インストールディレクトリん中のsrcにパスが通ってる必要があるっぽいので、最低限が、こんな感じ。 $dir = "./phake/src/"; set_include_path(get_include_path() . ':' . $dir); require_once('Phake.php');面倒だからdirは相対パスだけど、本当は絶対パスのほうがよいと思う。 MagicWeaponだと、configのlib_pathに追加する感じかねぇ。 これで
なんか色々と資料散らかってるわ忘れてるわで、散々と面倒だったので。 後で付け足す前提で、手元にある「散らかった資料」を整理してまとめておきます的なmemo。 …あぁ先に。set globalとかは「すげぇ激しいパーミッション」が要求されるのでご注意のほどを。 具体的には「SUPER」っちゅぅのが必要です。GRANTで適当に設定しといてちょ。 まず、ログ系の状況の確認。 show variables like 'log%'; 特に「重いクエリ」周りの確認。 show global variables like 'slow_query_log'; -- slow_query_log出す? 出さない? show global variables like 'long_query_time'; -- 何秒以上を「遅い」とする? show global variables like 'min_exa
攻撃付近については http://www.ipa.go.jp/security/ciadr/vul/20120106-web.html PHP, Tomcat などを利用して開発されたウェブアプリケーションにおけるサービス運用妨害 (DoS) の脆弱性(CVE-2011-4885等) ウェブアプリケーション等で使用されている言語 (PHP, Ruby 等) やウェブアプリケーションフレームワーク (Apache Tomcat 等) のハッシュテーブルの実装方法に問題があり、サービス運用妨害 (DoS) の脆弱性が存在します。この脆弱性が悪用されると、運用中のウェブサービスを提供できなくなるなどの被害にあう可能性があります。 あたりを。後は適宜「ググレカス*1」。 とりあえずパッチを覗いて、なんとなく欲しい情報を見つけてみました。 max_input_vars PHP_INI_SYSTEM
ものっそ大雑把に説明をしていきます。 「わかりやすさ」中心なので、「現在(ここほんの40〜50年くらい)の素晴らしい技術(アルゴリズム考え方アーキテクチャその他)」には大分と背を向けている可能性がありますのでご注意ください B-p 真面目にSQLのパースあたりとかを知りたかったら、是非具体的なソースコードを読んでみてくださいませ。 さて。 ざっくりと解説をするために、SQL文を非常に「簡単に」してみます。あちこち漏れてますが、その辺は適宜脳内補完をお願いいたします。 とりあえず、SQLには「以下の機能がある」と仮定します。 ・読み書きどっち? SELECTなのかINSERTなのかUPDATEなのか ・対象テーブル どのテーブルに対する操作要求なのか ・対象カラムとか値とか SELECTならナニを読みたいのか? insertとupdateならどこにナニを書きたいのか? ・レコードに対する制限
端的に一言で表してみてから、つらつらと雑感というか思考を並べてみたいかなぁ、と。 現場において「技術を独善的に"仕切ってる人"」は、必要だと思う。それも、可能な限り一人。 & 多分、一般的には「CTO」とかいう立ち位置の人が、それに一番ふさわしいんだろうなぁ、って思う。 言い方を変えると「その会社の技術は、CTOの色に染まっている」って感じ。 …以下、なんか「濃縮した毒を蒸留した毒で割った」ような、ものすごく濃ゆい状態になってるので。 相応に覚悟のある方だけご覧ください(苦笑 「技術を独善的に"仕切ってる人"」を存在させること、に対する反証は山盛りにあるんだけど…うん結局、その反証に「じゃぁ沿ったとして」、まともにまわるとは、正直あんまり思えないっていうかまともにまわってるのを見たことがない B-p 一番よくあるのは「技術者の個性を大切に」とかいう話なんだけど、正直「大切にしてあげたいほど
いやまぁ何カ所かで偶然「ほぼ同じ話」をしていたので、ちと自分の脳内整理を兼ねて。 一言で結論を書くと「ようは割れ窓理論」って話です。 とりあえず、お題は「XSSは非常にまずい」と。 その辺の「おいちゃん的思考」を、だらりんこんと書いていきたいと思います。 …って、細かく書くとすげぇ長くなったので(文章支離滅裂になったので全部消したw)、割と端的に。 かみ砕いて。 「セキュリティホールがある」ってのはまぁそもそもとして「知識不足の可能性」を疑うべきではあるのですが、まぁそのあたりは適宜「学んでいただく」として。 そこから先、少なくとも「実務」の場合、「costその他との天秤」が待っているですだよ。 えと…具体的に。 「そこそこしゃれになっていない」セキュリティホールがあると仮定します。 もしそれが「10分程度で修正可能」であれば、これをやらないケースというのは、あんまりないと思います(あんま
勉強の仕方について。 「スキルの深広練」の話ではないですが、多分、3つあるのかなぁ、と。 まず「広げる」。 これは「新しいほにゃららを学ぶ」で、多分エンジニアさんが「学ぶ」っていうと、まずここをやっている人が多いと思う。 本来的には「技術の新旧」は無関係なんだけど、まぁ多くの場合に「最近出てきた新しいほにゃらら」を学ぶことが多いんじゃないか、と。 次に「深める」。 これは「知っていると思っている技術」の、より根っこの部分を掘り下げていくところです。 ここをやる人は、「広げる」人と比較すると、めっきりと減るのですが、おいちゃん的には「とても大切」だと思ってます。 C言語を学ぶ過程でマシン語にたどり着くのは、きっと、この辺です。 ただ「TCP/IPのパケットの流れ」を調べていくうちに「オシロスコープの波形が載っている書籍にたどり着く」のは、少々やりすぎ感が漂います。 閑話休題 最後に「馴染ませ
元ネタ 新人プログラマーが使えない理由 http://jp.techcrunch.com/archives/20110507why-the-new-guy-cant-code/ んと…まずはトマホークな一言からstart。 「スキルが低いから安値で雇ってるんでしょ? 安値で雇った上で実力だけは高値相当にしろとか、おかしくない?」 で、本文を、今回はわりと「心ゆくまでdisってみる」。 # 単純に。この手の論調が「死ぬほどキライ」なのよ。なぜキライなのかは、後述。 彼はこちらのペースについてこられないようだ 指導、って単語知ってます? 教えるでも教育でもトレーニングでもどれでもよいのだけど。 彼の発する質問からは根本的無知が暴かれ、ようやく出来あがった作品は、ひどすぎて、結局経験者が一から書き直すことになる。 そこで「書き直して終わり」が、どれだけ発展性に乏しいか…まぁ理解してないんだろうな
毒危険。 さて、早速w まぁあちこちで散見されることではあるのですが。いわゆる「残業」に対して、とても強い関心をお持ちな現場とか個人(マネージャもどきさん)とか、がいらっさいます。 一言で迎撃するのは比較的たやすいのですが、少しそこに考察をいれて「丁寧に」迎撃してみよう、というのがこの文章の趣旨です。 「結局迎撃するんぢゃん」とか言わないように B-p とはいえ。先に「要約」しておきますと。 とどのつまり ・管理者が、現場を認識する能力に対して致命的な欠落があり ・故に、現場管理が根本的に出来ていない上で ・そもそもとして、ソフトウェア開発って物を理解しておらず ・故に、「負の生産性」とか「生産性の逆噴射」( http://d.hatena.ne.jp/gallu/20090315/p2 )とか「マイナスの要員」とか、その結果発生する「技術的負債」とかって単語に対して無知に過ぎる のが根本
時々(あるいはしょっちゅう)あるのですが、バッチファイルが「二重に動くと吾妻しくねぇなぁ」な状況があります。 よくロックファイルによる二重起動防止とかを見るのですが…もうちょっと楽な手段があるので、まぁ「カードの一枚」程度に。 機構としては、至極一般的な「セマフォ」を使います。 セマフォは「プロセス間通信」の一環になります。…それ以上を知りたかったら、C言語系の書籍を適宜あたってくださいませ。 …そのうち解説するかもしんまい。リクエストはコメントもしくはリアルで直接どんぞ。 閑話休題 サンプルコードから、早速かつとっとと実装をまなんでみませう。 まずは「ロックされていない」状態を体感して確認。 バッチファイルはこんな感じ。ファイル名は「t.php」という、素晴らしく投げたネーミング。 // 処理 $pid = posix_getpid(); // print "start({$pid})
割とあちこちで書かれてる気はするんだけど、ざっくりまとめてみる。 1. クォリティを浅い部分でしか認識していない 「認識しやすい」クォリティ部分でだめなケースはまぁ論外として(正常系が動いてない:露骨にバグがある)。 「セキュリティ的に問題がある」「メンテナンス性が悪い」など、目に見えにくい部分でのクォリティで、割と露骨に差がでます。 具体的には「今問題が出ていないんだからいいじゃないですか」。ハインリッヒの法則とかヒヤリハットとかって単語を、二度と忘れられなくなるまで調べつくしてください。 あなたが見つけ出し潰し尽くすべきは「1件の重大な事故」ではありません。「300件の(危うく大惨事になる)傷害のない災害」なんです。 まずはその300件を「認識することが出来る」程度のスキルと知識と経験をつみましょう。 2. 速度を意識していない 同一機能、同一クォリティである以上「早く組みあがるほうが
元ネタ 典型的PHPerの13の悪癖 http://anlyznews.blogspot.com/2011/03/phper13.html これの元ネタの「典型的PHPerの13の悪癖 http://anond.hatelabo.jp/20110329150439 」のほうも見ていたんだけど…ちょっと気になったので、突っ込み。 いつもながら当然ながら、以下、すべて「私見」です。 序文。 …おいちゃんは、はたしてPHPerなのだらうか? 仮説1:Yes 最近扱っている(っつか書いている)言語としては、PHPが一番多い。したがってこの瞬間という時間軸において、PHPerであると考えられる。 仮説2:No PHPerとは「PHP言語のみを扱うプログラマ」のことである(要出典)。C、C++、Perl、Java、C#、VB、JavaScript、ActionScript、Objective-C、CO
職業プログラマを前提として。 なんだかんだ、やっぱり「誰にでもわかる」ような書き方をすることは大切です。「今は」あなたがメンテナンスをするとしても、いつかはそれを「引き継ぐ」必要があるし、その引き継ぐ人が必ずしも「高スキルである」とは限らないわけですから。 そういったことを考えると「優れた技術力で書かれた難易度の高いコード」よりも「平均的な技術力で書かれたわかりやすくて平坦なコード」のほうがよりよい、ということは、すぐにでも理解できるんじゃないかと思います。 趣味ならいざ知らず、お仕事でプログラムを組むのであれば、できるだけ「難易度の低い、平坦でわかりやすいコード」を書くようにしましょう。 なんてセリフを、まぁ実際わりとよく耳にもしますし、うなずく人も0ではないかと思うのですが。 上述のセリフを噛み砕いてみもふたもなくすると「俺は勉強する気もないし今に固執していたいから、俺がわからないもの
元ネタ群 ゼネラリストは待望されているか http://el.jibun.atmarkit.co.jp/ahf/2011/01/post-01ac.html 「もう専門家はいらない」 これからの時代はスーパージェネラリストが必要だ http://blogs.itmedia.co.jp/nagaichika/2011/01/post-1c19.html スペシャリストかゼネラリストか http://blogs.itmedia.co.jp/business20/2011/02/post-ee8a.html で。おいちゃんが提唱するのは「ゼネラルスペシャリスト」。 定義としては「ひとつ以上の専門性をもつスペシャリストであると同時に、さまざまな分野を浅く広くかじり知識と思考を横断させることができるゼネラリストでもある」こと。 大分昔からおいちゃんは使っている「個人的な造語」…かと思いきや、案外にあ
いやまぁそのまんまなのですが。 「"上"司と部"下"」とか「"上"流工程と"下"流工程」とか、ことさらに、何とか「上下を付けたがるような」名前が多いのですが、現実問題としてなにも上下はないというかむしろある意味「管理/経営側よりも現場のほうが圧倒的に上なんだよ?」というお話です。 管理とかマネジメントとか、後は経営とか人事とか営業とかってのは。 ひとつの職分としてはとても-*本*来*は*-重要なのですが、ただ、それは「現場が重要なのと同じ程度に重要」でしかないんですね。 あるいはもうちょっと現状を踏まえた上で踏みつけると「現場ほどではないけど重要」。 管理とか経営とかマネジメントとかが「重要であること」自体は、くどいようではありますが繰り返しますが、当然論を俟ちません。 現場だけだと。混乱もするし統率も乱れるしで、全体としてのパフォーマンスはたぶん徹底的に叩き落ちます。割とマジで「1/10
久しぶり(?)の暴論シリーズ。タイトルが微妙に「俺の妹が〜」に似ているのはきっと気のせい(断言)。 「いつも暴論ばっかりぢゃん」とかいう突っ込み禁止。 …そろそろ「毒」とかいうタグ付けてみようかしらん? とか思案中w んと、とりあえず「プロジェクトマネジメント」の、まずはざっくりした定義を。 「プロジェクトを予定通りに完了させるために主として陣頭指揮管理にまつわる方々がなすべきエトセトラ」。 基本そんなに間違ってないと思うですがどでしょ? んで、上述のために必要とされていることからいくつかを抜粋。 おおむね ・ちゃんとした計画(スケジュール)を立てて ・作業者に適切に作業を振り分けて ・進捗をちゃんと管理して ってのが、大まかによくあるパターンなのではないかと。 先にちょっと余談。 上述のために「各作業員間の(特にコミュニケーションレベルの)調整」を、熱心に行うマネージャさんが、ごく極めて
「師の跡を求めず、師の求めたるところを求めよ」。 「古人の跡を求めず、古人の求めしところを求めよ」ってのもあるけど、たぶん、 上のほうがより古いんじゃないかと思われ。思ってるだけなんだけど。 跡を、しかも「粗雑に上っ面だけ」もとめるのが、パクリ。 真摯に敬意をこめて、でも「跡を求めてしまう」のが、二番煎じ。 「求めたるところを求めるために、まずは跡をなぞらってみる」のが、本歌取り。 そんな事を考える今日この頃。
最近見えてきた境地の一つなのですが。 すべからく。プログラムには「隙間」が必要です。 より具体的には「少々の変更修正追加」に対して「あぁそれならここに入れればよいですよ」という、なんだか「整理上手な奥様」のような発言がさらりと出来る必要があります。 無理矢理に押し入れに押し込んだりすると後で自重崩壊しますよねぇってのは先日も話をした内容。 そんな感じで「適度な隙間」は、生活をする上でもプログラミングにおいても、とても大切なものである事がわかります。 一方で。全体構造に「隙がある」のは、それは激しく「如何なものか」感が漂うと思われます。 具体的には。 客「こんな機能を追加したいんだけど」 エ「え…あ…はい…(どうしよう(汗))」 とか 客「項目追加をいくつかしたいんだ」 エ「え…あ…はい…(どうしよう(汗))」 とか 客「ちょっと不信なログがあるらしくて。プログラム側でもロギングしてみてくれ
メタファーとか暗喩とか隠喩とかアレゴリーとか寓意とか。まぁそんな系列のもにょもにょを念頭によぎらせてくださいませ。 お題は「料理」です*1。わかりやすいので、調味料と調理手順に焦点を当てたいと思います。 初手。 「調味料」というカテゴリに、例えば、塩、砂糖、醤油、味噌、などが含まれている事を知らない人はあんまりいないと思うのですが。 ただ、じゃぁ例えば「一般的な日本のお総菜のあの味を出すのには、例えばお煮染めなんかを作るのにはどんな調味料を使う?」って聞かれてド固まりするってぇのは、料理に不慣れな人だとわりとありがちな光景です(概ね、醤油+[ミリン or 砂糖]。これにお酒が入ったり入らなかったり。比率としては1:1:1が、身も蓋もないですがとりあえずベースにしやすい配合ですんで後はお好みで)。 でまぁ、多少慣れてくると、どうにか組み合わせを覚えたりあんちょこ作ったりしはじめまして。 んで
PerlのDBD::mysqlのインストール関連のお話です。 基本は http://y-kit.jp/saba/xp/cpan.htm を参照していただくのがぐっどなのですが…ちょいとはまったところなどを軽くメモ。 そうそう。私は /opt/db/mysql-バージョン番号 にインストールしてますんであしからず。 とりあえず ln -s /opt/db/mysql-4.0.24/bin/mysql_config /usr/local/bin/mysql_config しておきます。 んで… まず最大のポイントは
刺激的なタイトルでお送りいたします(笑 (追記:テーブルがみずらいなぁ…あとで書き直します〜 ノ) (さらに追記:簡単に切り直してみました〜 ノ) んと。 今回お題にするのは、いわゆる「常駐派遣」の交々。 とりあえず「危険すぎる」営業さんは省きたいので。えと…「請負と契約のいいとこ取り」をされるような状況は、とりあえず想定していません。 最低限「派遣契約」と「請負契約」はきちんと切り分けませう。 http://ja.wikipedia.org/wiki/%E5%8A%B4%E5%83%8D%E8%80%85%E6%B4%BE%E9%81%A3 http://ja.wikipedia.org/wiki/%E8%AB%8B%E8%B2%A0 http://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E6%B4%BE%E9%81%A3 http://ja.w
一般に、プロジェクトには4つの変数がある、と言われています。 コスト、スコープ、時間、品質の4つがそれです。 相も変わらず「Webアプリなら」を前提に、ちと考察をしてみましょう。 まず前提として。 コストは「御予算」。スコープは「どこまでやってどこからやらなくていいのか」。時間は「作成時間」。品質は…通常「真っ当に動くかどうか」とかそのあたりなのですが、Webの場合、例えば「100%落ちない」とか「ん万アクセスに耐えられる」とか。「後で機能を修正/追加できるか」なんてのも私は品質に含まれると考えています。 んで。 困った方向に動かす時に、ほかの変数にどう影響するのかを考えてみましょう。 まずいっちゃん多いのが、お値段を安くしたい「コスト」の低下。 ここを下げると「スコープの減少」「品質の低下」を招く事が多いです。作成時間には基本あんまり影響しないですね。 次に多いのが「やりたい事が増えちゃ
パターン名:三つ目のまんじゅう 元ネタなのですが。こんな話を、ずいぶんと昔に聞きました*1。 ある男が腹を空かせていた。 そこで、まんじゅうを一つ食べた。でもまだ空腹は満たされない。 二つ目のまんじゅうを食べた。でもまだ空腹は満たされない。 三つ目まんじゅうを一つ食べた。ようやく空腹は満たされて、男は言った。 「なんだ。はじめから三つ目のまんじゅう1つだけを食べればよかった。 これがどれほど愚かな話かはわかると思うのですが…本当に理解できているのでしょうか? 使っているフレームワークの、関数の、システムの裏側はブラックボックスのままでよいです。 別に普段、HTTPやSMTPやその他プロトコルについて考え思いを馳せる必要もないです。 メモリとかCPUコストとかを意識する必要もありません。 ちゃんと学び理解しているのなら。 ブラックボックスは必要なら開いてホワイトボックスに出来るからこそ「必要
んと…ちょいと気付いたりした小枝ぢゃなくて小技各種。 いち。 ぶっちゃけ、奇妙なライブラリやOSSの類の「ムダなエラー抑止演算子」が最近邪魔でたまりません(とかいうMWにもあるので…消さないとねぇ)。 だって。出力はあとで error_reporting( http://d.hatena.ne.jp/gallu/20090423/p1 )で制御すりゃいいっしょ? っつわけで、これ。 http://jp.php.net/manual/ja/scream.examples-simple.php ini_set('scream.enabled', false);「エラー抑制演算子の無効化」という、ど真ん中クリティカルヒットな感じのものがありますw 上手に使いましょう。特に面倒な現場で orz に。 gc_collect_cycles。 すべての既存ガベージサイクルを強制的に収集するって事で…危な
いや解って使ってるならよいのですが。結構「無考察で」使っているケースを見るので。 さて。まずマニュアルをちゃんと読んで見ませう。 http://jp.php.net/manual/ja/function.split.php split ― 正規表現により文字列を分割し、配列に格納する 正規表現により文字列を分割し 正規表現により 正規表現 大切なところをちょっと繰り返してみました。 えとですね。しょっちゅう言ってるのと、近日書きますが。正規表現はおいちゃん的には「基本禁じ手」です。 理由は簡単で。「重い」上に「大抵の場合、別手段での実装が比較的容易に可能」だから。 んで、ここ。 Perl 互換の正規表現構文を使用する preg_split() は、往々にして split() よりも速い代替案となります。 正規表現の威力が必要ないのであれば、explode() を使用するほうがより高速です。
んっと…まぁ「デザイナがなれてるからSmartyよろ」と言われると…後メンテ考えて「やだい」とは言いにくく。 今後も延々保守やりまくるならともかくとして、以降どうなるかわからないだけに余計にねぇ…。 ってなわけで。かなり嫌々ながらSmarty叩いてみたです。 ………なんじゃこりゃぁ!!(ジーパン風) キャッシュファイルすごいですぅ。 多分これって from templatefile to PHP source code generate engine の略なんじゃなかろうか…って感じですねはい。 Hello, {$name}! が Hello, <?php echo $this->_tpl_vars['name']; ?> !になるくらいはまぁいいとしませう。 Hello, {$name|nl2br}!は <?php require_once(SMARTY_CORE_DIR . 'core
元ネタはこちら。 王様の仕立て屋―サルト・フィニート (8) (ジャンプ・コミックスデラックス) 作者: 大河原遁出版社/メーカー: 集英社発売日: 2005/11/04メディア: コミック購入: 1人 クリック: 7回この商品を含むブログ (43件) を見るの、P152 本格や正統が 盤石であればこそ 柔軟な変革も できるのだと 解りましたよ このままだと、素直に「名言」ですむのですが…文言の前後をかえて これを「柔軟な変革に耐えられるだけの"本格"や"正統"を身につけているの?」とすると…とたんに、とても怖い自問自答になります orz それでもなお。 千変万化に耐えうる「基礎」を身につけるべく、日々努力と修行と訓練を積み重ねていきたいものです。
なんかご大層なタイトルにしてみましたが。 元ネタはこちらです。 携帯電話向けWebアプリのセッション管理はどうなっているか http://d.hatena.ne.jp/ockeghem/20090714/p1 ちなみに、会話対象になっているのは、この書籍 PHP×携帯サイト 実践アプリケーション集 作者: 株式会社マイネット・ジャパン,平島浩一郎,伊藤祐策,中元正也出版社/メーカー: ソフトバンククリエイティブ発売日: 2009/06/27メディア: 大型本購入: 5人 クリック: 155回この商品を含むブログ (10件) を見る 最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。 えと…正直、PHPのセッション関連の関
次のページ
このページを最初にブックマークしてみませんか?
『gallu’s blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く