がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

わかりやすい「契約者固有IDの危険性」

セキュリティ 携帯

高木先生のブックマーク経由で見たのですが。
http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/
http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/?SS=imgview&FD=-499245482&ST=keyword
なんてわかりやすい！！
なにがどう危ないかが一目瞭然。


さてbase_model_richクラス*1、そろそろ本気で追加設計するかなぁ。こゆ時、Facadeパターン使ってると本気で楽だわｗ

*1:自作フレームワーク「MagicWeapon」にあるクラス。MVCモデルでいうmodelクラスの、認証用継承もとクラスです

エンジニアをはかる物差しについてのmemo

親方

まぁどこに行っても出る話なのでしょうが。ちと自分内部の整理用memo。


元ネタ
重要なのは「技術が好きかどうか」
「採用で勤続年数・学歴・資格は参考にしない」、ウノウ尾藤氏
http://www.atmarkit.co.jp/news/200810/10/unoh.html

後半では、エンジニア中心のチームや組織について持論を語った。ウノウでのエンジニア採用では、尾藤氏が面接を行う際に、「勤続年数、学歴、資格の3つはあまり参考にしない」という。

まぁごく普通の事だと思うです。…物差しさえ持ってれば。


まず。勤続年数は「ごますりスキルの高さ」とか「社内Tipsへの従順性」の目安になる可能性があるので、あまりみません(とはいえ「全部短期間」だとそれはそれで気になりますが)。
学歴は…まず「高学歴だから地頭がよい」とは限らなくて(パズルがうまいだけの人も少なからず)。次に「実はエンジニアとは関係ない勉強を多々」が次の関門、その次に「習った事を実務に落とせるか？*1。
資格試験は内容が以下略なので以下略。無論例外的に、よいなぁと思う資格試験もあるのですが*2。

逆に、参考にするのは「過去の実績」と尾藤氏は語った。特にプライベートの活動において、「OSSに関わっているか」「勉強会に積極的に参加しているか」「技術系媒体で執筆活動をしているか」「IPAの未踏プロジェクトに参加しているか」などを参考にするという。

実績は…翻って大変に重要ですねぇ。
私はよく面接の時に「自分で作ったプログラムを一つ二つ持ってきて欲しい」とお願いしますが。大体、class(interface)の切り方、コメントの書き方、などで、最低限見える部分ってのはあるので。
勉強会参加の有無は…うん大事ですかねぇやっぱり。私も少しばかりそういった勉強会に顔を出させていただいた事があるのですが。いらっしゃる方は、やはり非常に熱心な方ばかりなので。ぶっちゃけ「今はだめだめちゃん」だとしても、熱意があるので(あとはちゃんとしたメンターにさえ出会えれば)確実に伸びますし。
そういう意味で

「技術が好きかどうかが、エンジニアとしてレベルが高いかどうかに大きな影響を与える」（尾藤氏）

ですねぇうん。


以下、採用基準とは関係ない余談ですが。

さらに尾藤氏は、エンジニアがマネージャに求めることとして「技術力を身につけてほしい」というメッセージを打ち出した。お互いの歩み寄りが必要で、エンジニアもマネジメントを理解する必要があるが、同時にマネージャも技術を理解する必要があるという。

……………え？
マネージャが、最低限エンジニアと「まともに会話出来る程度の技術力がある」のは前提条件っていうか大自然の掟なのでは？
っていうか割と本気で。彼らが「なにをやっているかをちゃんと把握する事すら出来ない技術力」でなにをどうマネジメントする気なんでしょ？
ええ無論「出来てない連中が多すぎるからこういう話になる」ことはわかってますがね。


まぁ…採用現場に最近密接に絡み出して…改めて厄介なものを色々と感じるです。
正直「＊＊の言語経験がｎ年」とか言われても、あんまりにも開きがありすぎて指針どころか参考にすらならないので。
ただ…私は「会話すれば最低限の探りは入れられる」のですが、そのレベルの技術スキルを全ての採用現場とかに持ち込むのもそれはそれでちょっとどんなモンなのかなぁとか思うわけでして。
ってことを考えると。…どこぞのmixiのthreadでも書いたような記憶があるのですが、もうちょっと定量的に「技術者のスキルがはかれる」指針が必要だと思うんですよねぇ。


なんて雑感をつらつら。

*1:「オートマトンは知ってるんだけど業務のどの部分で使えるかがわからない」って人は結構多いですっていうか大多数？

*2:知っているかぎりでは、LPICとかLPICとかLPICとか。…とはいえ「二進数知らない論理演算なにそれ？」とかいう発言を現場で多々耳にすると、情報処理の二種(今は…基本情報技術者試験が該当するのかしらん?)あたりは必要な気もしますが

我が意を得たり!!

その他 親方

元ネタはこちら。
第154回
今まさに瓦解する市場原理主義
http://www.nikkeibp.co.jp/sj/2/column/o/154/index.html


経済アナリストの森永卓郎氏が書いている文章である。
えと…なんていうか。株とかなんとかいう類の物体に対する自分の印象値と全く同じ事がここに書かれていた。

わたしはいま、「まじめに働こうキャンペーン」を一人で始めたところである。人間というものは、汗水たらしてモノやサービスを作りだすことに価値を見いだすべきではないだろうか。少なくとも、金を右から左に動かすことだけで、人の作りあげた付加価値を奪ってはいけないと思うのだ。

すばらしいジャストミートど真ん中。


無論。例えば本来的な意味における「投資」や「株」が不要だとは、無論思わない。
ただ、それは「毒も少量なら薬になるからこそ毒は必要だ」といってるのと多分ニュアンス一緒。
お金を右から左に動かす事で利益を得る事を「本業としてしまう」のは、やはり個人的にはどうも感覚的に違和感を感じまくる。


やっぱり。「現場で手足を動かす」のって、一生涯大切なんじゃないかなぁ。
どの職分に限らず。

「差がない」なんて事はない！！

その他技術 親方

えと。あえて、あえて、声を大にして叫んでみたいです。


受託開発はIT業界の米
http://d.hatena.ne.jp/JavaBlack/20081003/p1

他に技術力とか品質ではなく，イロモノでしか差別化できない所とかも同じ．

*1


整理整頓とか
http://www.developer0000.jp/2008/10/04/2927/

結局、Webシステムの場合、平準化して達成する技術力は大体どこも似たような感じなので、
「これができる」という能力自体はあまり競争要因にならないそうな。


んなこたぁありません！！


まぁがさつな商売している営業には見えにくいところかとは思うのですが。
きちんと「質」は存在していますし、それはいろいろなところで大きな影響を与えてます。…ってのをまぁ、もうちょっと定量化したりした上で声高に叫ばないといかんのだろうなぁとか思うのですが。
一つには「技術者側の、その辺のアピールであるとかなんだとかが必要だなぁ」とは思ったのですが。
奴隷船の乗組員達が「整理整頓でくらいしかアピールできないと考えている」あたり………何て言うか最低という言葉すらもったいないと思うのは私だけでしょうか？


「人の生き血を啜る寄生虫」なお仕事とその人員たち、そろそろ根絶してみたいなぁとか思う今日この頃です。

*1:一応念のために。元記事読むとわかりますが、ちゃんと「ユーザーって，中身の品質とか機能とか操作性より，パッケージなんかの見た目の方にお金を払うよね？ orz」と正しいフォローは入ってます

いくつか雑に突っ込み

セキュリティ

色々締め切りに追われてるので orz
雑にざっくりとmemo。


Cookieを使用したSQLインジェクション
http://www.lac.co.jp/info/rrics_report/csl20081002.html
http://slashdot.jp/security/08/10/06/063250.shtml
えと…「エスケープ処理は出口で用途に合わせて」って原則を守れば、それがpostから入ろうがgetからだろうがcookieからだろうが関係ないはずなのですが。
如何に原則が無視されているかがよくわかります orz


「今までにないタイプのSQLインジェクション」――ゴルフダイジェストへの不正アクセス手口が判明
http://itpro.nikkeibp.co.jp/article/NEWS/20081006/316229/
………で？
ちゃんと「躾けられたエスケープ処理」してれば防げると思うのですが？
それとも「出口で適切なエスケープ処理をしてもかいくぐられる」injectionだったんでしょうか？
だとしたら確かに新機軸ですが。


ゴルフダイジェスト・オンラインに不正アクセス--個人情報漏洩は「事実ない」
http://japan.zdnet.com/news/sec/story/0,2000056194,20381399,00.htm
「個人情報漏洩の事実は確認されていないという。」とか言われても…「漏れてない」のか「漏れたのが認識できてない」のかが不明だしぃ。


いぢょ ノ

久しぶりに雑感など

その他

んと…元ネタはこちら。
今更google叩いてる奴って・・・
http://anond.hatelabo.jp/20081005152802

別に肌に合わないから批判するのは、人間として仕方ないけど、
それはあくまでも、サービスについての批判であって、企業全体に対してじゃないだろ。

えと…「そのサービスを発想し構築し運用し、また批難があってですら迅速な対応が出来ない企業体質に対して」の批判が含まれているんだろう、と思うのですが。
だから「Googleという会社自体の批判」が発生しうる、と。


個人的には。あの会社には「いっそ、嫉妬と怒りすら覚えるくらいに素敵な会社さん」という印象が強いので。今回の騒動は色々と残念だなぁと思うことしきりなのですが。


それはそうとして(ぢつはここからが本題)、ストリートビューは…どうなのかなぁ。
問題や疑問に対するGoogle社の曖昧な返答とか対応の鈍さとか役員の無責任な放言とか、そのあたりは割とストレートに「危険なもの」を感じるのですが。
ストリートビューというサービスそのものの問題については…なんかまだ考察しきれていないというか自分の中ではまだ消化しきれていない感じ。
ただ一つあるとすると。「スコープの広さの問題を基点に」ちょっと嫌かなぁってのはなくもない。


時々見る反論の一つに「いいじゃんそも普通に見られるものなんだし」という類のがあったように記憶しているのですが。
ストリートビューを通すと「場所の制限」と「時間の制限」という二つのスコープがわりと思いっきり破壊されてるように感じるです。
つまり「その場所でその時間に見る事が出来る」ものを「IPリーチャブルであればどこでも、起きていればいつでも見る事が出来る」わけで。そのあたりの「スコープの差異」って、結構でかいのかなぁと思うわけです。
でその結果として…個人的かつ極端に感覚的な主観的印象値として「なんとなくやだなぁ」という感情が導き出されてたりします。
…人とか車とか、そういうものを一切うつさない。それこそ「TOKYO NOBODY ( ISBN-13: 978-4898150313 )」のような(車ってどうだったっけ？忘れた(苦笑) )写真なら、また全然違う評価になったんでしょうけどねぇ、と。


あと。
「私道からしか写せない写真でってことは私道に入ってるからNG」ってのは…うんすごくよくわかるんだけど全然解らない(苦笑
なんていうか…自分は根本的にある種の倫理観が欠落しまくってるので。「駄目だから駄目」という理論がまったく理解できないので。
「なぜ私道に入ってはいけないのか」が…あ、「自分の庭に他人に勝手に入られちゃ嫌だ」と同じ理由なのかなぁ？ だとしたらわからんでもないけど。ただ…うんやっぱり、もう一つピンと来てない。「私道」ってものそのものが自分の価値観に多分存在していない(苦笑 *1


グーグル社曰く「撮影作業員は公道私道を区別するデータを持たずに走行している」
http://takagi-hiromitsu.jp/diary/20081004.html#p01
の

情報提供者によると、集合住宅でグーグルの撮影車が駐車していたため、運転手に「公道私道の区別はついているのか」と問い質したところ、答えずに図1の文書を手渡され、会社に問い合わせるよう言われたのだそうだ。その際、運転手は逃げようとして急発進し、あやうく轢かれそうになったとか。

という、端的にいうと「慌てた」対応を見るに。私道を走るってのは、それなりに「まずい行為」なんだろうなぁ、とは予想するんだけど。
………うんやっぱりなんか自分の頭に浸透してこない(苦笑


まぁ。
「まずいと思ったらまずいと主張する」のは、一定の条件を満たした場合にかぎり*2、非常に良い事だと思うので。
でまぁ、当然といってしまえば当然ながら。個人的には、高木先生の行動は、その条件から踏み外れていないので。
しばらくはこの辺のストリートビューの議論を色々と見守ってみたいなぁとか思ってみたり。


とはいえ…Googleさんに、是非どんでん返しに「素敵な」対応をお願いしたいところなのですが；；

*1:根本的且つ致命的にハイレベルで「方向音痴」＆「迷子属性持ち」なので。ある程度大きな道路以下は可能な限り忌避する傾向にあるのでｗ …多分「２車線ある私道」ってそんなにないですよねぇ？ 多分。

*2:ちなみに「まずいと主張するための一定の条件」は非常に簡単で「会話が出来る事」。言い方を変えると「きちんと相手の発言を耳に入れてかみ砕いて不明部分は質問しながら理解した上で次の言葉を述べる事」。相手の発言を無視したり曲解したり理解を深めようとしなかったりするやり取りは、個人的には「会話」とは呼びません。

URIについて

ネットワーク

えと…すみません考察してないメモ書きです。
んと。発端は「domain名だけのURIのおけつに/(スラッシュ)は必須なのか？」って話。
いわゆる「ちょいと口うるさい方」が割とこの辺を突っ込むのですが(URIでdomainのみのケース 例えばhttp://domain.com でも、最後に/がないのはおかしい)。
RFCを見てみると………なんか違うような。


RFC 3986のABNFを見てみると

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty

URI-reference = URI / relative-ref

absolute-URI = scheme ":" hier-part [ "?" query ]

relative-ref = relative-part [ "?" query ] [ "#" fragment ]

relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty

scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
port = *DIGIT

IP-literal = "[" ( IPv6address / IPvFuture ) "]"

IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"

h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet

dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255

reg-name = *( unreserved / pct-encoded / sub-delims )

path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters

path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0

segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

query = *( pchar / "/" / "?" )

fragment = *( pchar / "/" / "?" )

pct-encoded = "%" HEXDIG HEXDIG

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

とありまして。
…きっちり紐解いてはいないのですが。


ド端的に、
hier-part = "//" authority path-abempty
authority = [ userinfo "@" ] host [ ":" port ]
path-abempty = *( "/" segment )
から見るに。
path-abemptyがemptyなら、必然的に先頭にある/(スラッシュ)も無くなるんじゃないかなぁと思うのですが。
つまり「http://domain.com」は「RFC的に正しい」と思われるのですが…なんかABNF読み間違えてますかねぇ？


最近割と気になってるので、ちと「後で考察しよう」と思いつつ、memoり。