「dump」を含む日記 RSS

はてなキーワード: dumpとは

2019-02-28

不正アクセスnetgeekリダイレクトしよう

Webサーバ管理してるとこんな不正アクセスログを見ることがあるけど

 - - [06/Oct/2016:20:27:30 +0900] "GET /admin/fckeditor
 - - [06/Oct/2016:20:27:39 +0900] "GET /admin_manage/fckeditor
 - - [06/Oct/2016:20:27:41 +0900] "GET /admin_manage/fckeditor/t0phackteam/webfuck.shell
 - - [06/Oct/2016:20:27:44 +0900] "GET /administrator/
 - - [06/Oct/2016:20:27:46 +0900] "GET dump.sql

こうやってみんなnetgeekリダイレクトしよう(Apache場合

Redirect /admin/ http://netgeek.biz
Redirect /admin/fckeditor http://netgeek.biz
Redirect /admin/fckeditor/t0phackteam/webfuck.shell http://netgeek.biz
Redirect /administrator/ http://netgeek.biz
Redirect /dump.sql http://netgeek.biz

2017-01-10

エビデンスって何のために取るの?

転職して参画した案件PHPWeb業務システム構築)が、ネットで聞いてた「SIerあるある」まんまだった。

その中でも結合テストが謎。

1000項目以上あるテストケースの一つ一つ、心を込めてエビデンスを取っている。

・WinShotでログインから動作ずつキャプチャとる(ボタンのところにカーソル合わせて「ここ押す」感まで出す)

Apacheログアプリログ試験前後DBdumpをとる

これ、誰が見るんだ。何のために取るんだ。

お客に対して「ちゃんとテストしたよ!証拠もあるよ!」くらいの意味しか見出せない(お客だってマリーくらいしか見ないだろう)。

メンバー曰く、「不具合があった時にどういう状況でテストたか確認するため」とのこと。

どういうテストたか、なんてテスターの不備を追求してる暇があるなら、さっさとバグを直せばいいじゃん。

そんなに吊るし上げしたいのか。

一番怖いのは誰も文句わず黙々とキャプチャとってること(自分もだけど)。

キャプチャとる方が試験するよりも時間かかる。

その時間テストコード書くなり、モンキーテストでもした方がよっぽど品質高まると思うのだが。

これだからSIerは(ブツブツ...)

有意義理由存在するなら教えてほしい。

2016-12-01

大半のブクマカは知らない、俺だけが知ってるはてブの謎のバグ

1,はてブエクスポートしま

2,はてブを全削除しま

3,0ブクマになりましたね?カップヌードルにお湯を入れ10分ほど待ちます

4,0ブクマ状態はてブエクスポートし、そのファイルExcelで開きます※1のファイルを上書きしないように

5,あら不思議!0ブクマのはずが、何件かエクスポートファイルには残ってるではありませんか!?

(6,元のデータを戻したいときは、1でできたdumpファイルインポートし私に中村静香ちゃんの画像を送れば元に戻ります。)

どういう基準バグが起こるのかは不明だが、削除して一見ブクマになった後も、中のデータにはなんらかの基準ブクマが残っている?

5のエクセルファイルに残ってるブクマを見ると、1年くらい前のものから数日前のものがある。時系列でバラけているので、タイムラグでの消え忘れということは考えにくい。

4でエクスポートしたデータインポートし、マイページから作業はてブ削除をすると完全に消えてくれるようだ。

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2015-10-30

いきなりSEGV

揚げ足取りをしたいわけではなく、単に思い出しただけで、要するにネタなんだけど。

http://blog.practical-scheme.net/shiro/20141013-translation-checklist

オープンソースコードにも質は色々あるけれど、 コンパイルがそもそも通らないとか、実行したらいきなりSEGVするコードを 出してきて「叩き台です」という人はいないと思うんだ。 やりたいことの一部機能まがりなりにも動いて、何をしたいか 客観的にわかコードがあってはじめて、改善案も出せるというもの

「実行したらいきなりSEGVする」のが「やりたいこと」ってケースはあるんですよね。core dumpするコードを書いて最も短かった人が優勝とか定期的に誰かが思いついてはブログに書いたりしてるようですし。

2015-05-25

初めてデリヘルを呼んだら橋本環奈が来た

性欲を持て余していた。31歳独身風俗なんて行ったこと無いし、キャバクラでさえも行ったことなかった。

数年前別れた彼女はもうすぐ結婚するし、一昨日焼肉に連れて行った女子大生は「先週彼氏出来た」とのたまう。ハッ◯ーメールには2万円を要求する女しか居ないし、Yahooパートナーもさっぱり返信がない。FC2動画に有料登録し、俺のマイページは「ニーソ」「マッサージ」「黒髪ストレート」「色白スレンダー」「貧乳」「乳首桜色」「ロリ体型」…などと細かく分類されていつでもオンデマンドで楽しめるようになっていた。

いい加減セックスがしたい。裸で抱き合ってキスをしたい。朝から前立腺が泡立つような感触が続いている。

Google先生で「府中 デリヘル」と検索する。府中は隣町だ。きっとすぐに来てくれる。俺は基本的に一発しか出せない。60分もあれば大丈夫だ。

出てきた風俗情報サイトを上から眺める。やがて一件のダサめのサイトに辿り着く。ロゴ解像度ガバガバやな。今日の出勤に、黒髪ロングストレートニーソ女の子が映る。顔はぼかされている。プロフCカップだがもっと無いだろう。でも、これだ。俺の11cm電探(仮性)に感あり。

20分後、女の子デリバリーされてきた。ドミノ・ピザより早い。インターホンが鳴る。甘ったるいアニメ声だ。期待が高まるオートロックを解除する。ドアを開ける。橋本環奈似の美少女がいきなり抱きついてきてディープキスを迫ってくる。大当たりだ。今までの彼女よりも美少女が来てしまった。夏らしいさわやかな花がらのワンピース。残念ながらニーソではないがそんなことどうでもいい。女の子がお店に到着連絡をし、再び抱き合ってベロチュー。混乱してきて童貞並みにどうすればいいかわからなくなってしまった。今までの彼女は何だったんだろう。シャワーを浴びベッドに向かう。

ベッドの上で裸で抱き合って橋本環奈似の美少女ロチュー。発射なしでももう充分満足してしまっている。やばい彼女つくるより全然良くないか、これ。アップル並みのユーザーエクスペリエンスだ。店長ジョブスなのか?彼女の脇腹をスワイプし、綺麗な桜色のホームボタンの外周をなぞり、口に含む。実物の桜色を目にするなんて初めてある。彼女は僕の性体験をことごとくiOSアップデートしていく。「Hey,Siri.ノーハンドでしてくれ」僕が指示を出すとSiriは嬉しそうに僕のLightningコネクタを口に加える。やがて彼女は僕の足を持ち上げ僕のSiriをむき出しにし、舐め始める。彼女にも舐められたこと無いのに!童貞みたいな声を上げる。僕のセキュリティ・ホール突いた彼女は再びLightningコネクタを咥えroot権限の奪取を試みる。今度は手でしごきながらだ。やがて僕は橋本環奈の口内にめいっぱいcoredumpした。dumpが終わっても彼女アタックし続けた。彼女はまた僕の性体験をiOSアップデートしていった。コアダンプを口にしたまま動かなくなる彼女。「あ、ティッシュいるよね」頷く彼女デバッグは追加料金である

まだ時間はある。再び橋本環奈を抱き寄せベロチュー。何これ、すごい幸せ。ひとしきり腕の中で彼女の体温を感じ、再び咥えてもらう。「こんな短時間に2回とかしたことないんだよね」「がんばれ♡がんばれ♡」急に伊藤ライフがやってきた。口の中柔らかいし上手い。今度はスマタだ。ローションを塗り彼女の股間に当てる。幼い顔から想像できない大きめの赤貝。へイラシャイ築地久兵衛感覚赤貝人差し指中指で覆い握る。あっ、彼女全然濡れてない。仕事でやってるんだなということに気付くもそれ以上の体験がそこにはあり、もはやどうでもいい事であった。なので気兼ねなく思いっきサービスしてもらおう。その後、上になってもらって下からちっぱいをながめたり自分が上になって赤貝に擦りつけたりした後に口で。こんな短時間で2発目はちょっとしかったが、どうしてそこでやめるんだ、そこで!!もう少し頑張ってみろよ!大丈夫かな、あはぁ~ん。不安になってくるでしょ?ならば、一所懸命、一つの所に命を懸ける!そうだ!今ここを生きていけば、みんなイキイキするぞ!!「もっと熱くなれよ!」僕は心で叫びから字通りイキイキした。

再びシャワーを浴びて服を着る。別れ際に抱き合い、またキスし、彼女を送り出す。とても1.5万円とは思えない満足度であった。酒を飲み、fue先生の「フエラハメりっぷす」(巻頭作品アンドロイドがひたすら口でしてくれるもの)で抜いて寝た。月一回くらいだったらいいかも。

枕には橋本環奈匂いが染み付いていた。「彼女いたら呼べないな、これ。」

なんだこの長文。

2013-03-23

プロテクト強化後のもふったーも予想以上に酷かった件(追記あり)

ことのあらまし
  1. Twitterクライアントもふったーの作者「TweetDeckのconsumer secret簡単に抜ける、終わってる」(http://blog.livedoor.jp/blackwingcat/archives/1760823.html)
  2. 別の誰か「もふったーのconsumer secretも簡単に抜ける」(http://d.hatena.ne.jp/kusano_k/20130318/1363640368)
  3. もふったーの作者「プロテクト強化した」(http://blog.livedoor.jp/blackwingcat/archives/1762970.html)

プロテクトかけたアルゴリズムを実装したバージョン差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。

手順

動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。

からリバースエンジニアリングはいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。

この場合も同様だ。TwitterGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。

OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。

HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))

ここで

である

まずはこのあたりから攻めようと思った。SHA-1計算はいくつか特徴的な定数が使われるので、そこからSHA-1計算に使われているであろう関数444190を特定する。この関数エントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザ認証ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。

CPU Disasm
Address   Hex dump          Command                                      Comments
00401311  |.  33F6          xor     esi, esi
00401313  |   8D8C24 A40000 /lea     ecx, [local.54]
0040131A  |.  394C24 14     |cmp     dword ptr ss:[local.90], ecx
0040131E  |.  75 0E         |jne     short 0040132E
00401320  |.  3BF5          |cmp     esi, ebp
00401322  |.  73 29         |jae     short 0040134D
00401324  |.  0FB68434 A400 |movzx   eax, byte ptr ss:[esi+esp+0A4]
0040132C  |.  EB 21         |jmp     short 0040134F
0040132E  |   3BF5          |cmp     esi, ebp
00401330  |.  73 1B         |jae     short 0040134D
00401332  |.  8B5424 18     |mov     edx, dword ptr ss:[local.89]
00401336  |.  52            |push    edx                                 ; /Arg1 =  [LOCAL.89]
00401337  |.  8D8C24 FC0000 |lea     ecx, [local.33]                     ; |
0040133E  |.  8BD6          |mov     edx, esi                            ; |
00401340  |.  E8 CB4D0000   |call    00406110                            ; \mofooter.00406110
00401345  |.  83C4 04       |add     esp, 4
00401348  |.  0FB6C0        |movzx   eax, al
0040134B  |.  EB 02         |jmp     short 0040134F
0040134D  |   33C0          |xor     eax, eax
0040134F  |   34 5C         |xor     al, 5C
00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al
00401358  |.  83C6 01       |add     esi, 1
0040135B  |.  83FE 40       |cmp     esi, 40
0040135E  |.^ 72 B3         \jb      short 00401313
00401360  |.  895C24 3C     mov     dword ptr ss:[local.80], ebx
0040134F  |   34 5C         |xor     al, 5C

が注意を引く。もしかしてこれはopadとのxorではないか?

00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al

xorした結果を格納している。

先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。

Hex dump
64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|
18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E|
05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|
5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|

あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。

追伸

はてな増田スーパーpre記法で半角の<>が含まれていると投稿が出来ないのを早く直してください。

3/23 18:45追記

もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。

CPU Disasm
Address   Hex dump          Command                                  Comments
00401324  |.  8D4424 20     |lea     eax, [local.102]
00401328  |.  50            |push    eax                             ; /Arg1 = 
00401329  |.  E8 623A0400   |call    00444D90                        ; \mofooter.00444D90

ここでeaxが指すメモリーを見ると以下のようになっている。

01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10|
F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00|
40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|
61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|
79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36|
36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|

先頭32バイトゴミ無視して0x36とxorすればconsumer secretが得られる。

2011-03-20

より良いPHPerにならないための20Tips

http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/

良いPHPerだって?そんなものは丸めゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。

つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。

それじゃ、始めよう。

1. ?>を使うな

?>なんて使っちゃいけない。そう俺たちはBAD PHPer。

無駄ホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。

2. 設定ファイルPHPで書くな

require_once("config.php");

未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。

ダメだ、早く何とかしないと。

大抵このconfig.phpの中身はこうなっている。見て絶望だ。

$hoge_path = '';
if (!LOCAL) {
    define('FOO_FLAG', 1);
    if (HONBAN) {
        define('HOGE_FLAG', 1);
    }
    else if (TEST) {
        define('HOGE_FLAG', 2);
    }
}
else {
    $hoge_path = '/local';
    define('FOO_FLAG', 2);
    define('HOGE_FLAG', 3);
}

define('HOGE_URL', $hoge_path.'/hoge/');

こういうのが延々と続くわけだ。もういやだ。もう見たくない。

本番環境テスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。

なまじPHPな設定ファイルのせいで処理をついつい書いてしまう。そしてどんどん複雑になってしまう。

やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである

そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。

# 本番環境設定ファイル
foo_flag: 1
hoge_flag: 1
hoge_url: '/hoge/'
# テスト環境設定ファイル
foo_flag: 1
hoge_flag: 2
hoge_url: '/hoge/'
# ローカル環境設定ファイル
foo_flag: 2
hoge_flag: 3
hoge_url: '/local/hoge/'

3. コメントを信用するな

そう、あなたはこんな状況に遭遇したことがあるんじゃ?

// ここで後の処理のためにhogeメソッドを呼び出しておく
$q->foo();

// $a['foo']はここに来る時点で真のはず
// 2010-03-10 判定がおかしいので修正
// 2010-06-21 やっぱり値が入ってる方が正しい
if ( !isset($hoge[0]) ) {
}

コメント保守されない。そう、それは真実。こんなコメント発見したら即効削除しよう。コメントは基本信じるな。

俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。

4. タブとうまく付き合うしかない

わかる。いいたいはとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。

タブを画面上で認識しにくいエディタが世の中には存在する(何とは言わないが)

そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。

この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。

私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。

5. 変数名に時間をかけるな

われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。

御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。

そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。

コンパイラ様に保証されてない状態での

$iNumber = 'aaa';

になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。

6. 変数初期化場所

変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。

$foo = null;
$foo = $q->foo();

こんな初期化意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう

$foo = null;
if ( $hoge ) {
    $foo = 1;
}
else if ( $bar ) {
    $foo = 2;
}

このとき初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。

7. 不正なら常に死ね

function getStatus() {
    $bReturn = false;
    if ($i == 2) $bReturn = true;
    return $bReturn;
}

(中略)

もし、何かしらの理由で、あなたの書いたif文が間違っていたら?

この書き方をしていれば、間違った値に対して、常にfalseが返る。

私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータ入力されるまでは、動かないコードを書くべきだ。

trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ

function getStatus() {
    $bReturn = false;
    if ($i == 2) $bReturn = true;
    else if ($i == 1) $bReturn = false;
    else throw new Exception("bad status! $i");
    return $bReturn;
}

中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね

8. 連想配列キーアクセスする場合

単なる配列に対して数値をクオートで囲う必要はない。

連想配列キーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。

更に後世のプログラマ処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にした場合はconstantを使うと良い。

// 定数のFOOを使うよということが明確になる
print $a[constant('FOO')];

9. echoよりもprintfを使え

もし、文字列変数の値と一緒に出力するときPHPではコンマの代わりにprintfを使うことが使える。

なぜ?コンマを使うよりも可読性がグッとあがるから

printf( “Hello, my name is %s“, $sName);

以下の代わりに上記のコードを使う。

echoHello, my name is “, $sName;

出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。

10. 三項演算子は一回まで

三項演算子はとても有効だ。しか優先順位に難があるせいで三項演算子ネストしようとすると以下のようなコードになってしま

$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));

括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めゴミ箱にでも捨てちまえ。

11. 真偽値のチェックは生でいけ

if ( $flag ) {
}

仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。

もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。

12. ++と--の演算子を見極めろ

インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい

けがからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。

13. 代入演算子を使え

文句なしだ。これは文句がない。

他にも色々あるので覚えておこう

$a %=  1;
$a &=  1;
$a |=  1;
$a ^=  1;
$a <<= 1;
$a >>= 1;

14. 変数dump関数はより便利に

てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。

なのでdivを使って以下のようにしとくと便利だろう。

function p($var) {
    echo "<div align='left' style='background-color:white;color:black;'><pre>";
    print_r($var);
    echo "</pre></div>";
}

15. 定数から手を洗え

君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ!

大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがからなくなってるパターンが多い。

貴様たいなもんに、定数は制御できん。いいか設定ファイルYAML等のデータで持つようにし、その連想配列データ構造を一つ持ってるだけで定数の変わりになる。

このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めゴミ箱へ捨ててしまうといい。

認識を改めろ。俺たちはより良いPHPerにならないために努力している。

16. $_GETと$_POSTを生で使うな

できれば何かしら簡単なクラスでもいいのでラップしろ。

class Request {
    private $parameters;
    private $method;
    function __construct () {
        $this->method = $_SERVER['REQUEST_METHOD'];
        if ( strtoupper($this->method) === 'POST' ) {
            $this->parameters = $_POST;
        }
        else {
            $this->parameters = $_GET;
        }
    }
    function param ($key) {
        return isset($this->parameters[$key]) ? $this->parameters[$key] : null;
    }
}

これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ!

17. 関数だのオブジェクトだのの問題ではな

例が良くない。こんなのは引数20個ある関数からset20回呼ぶオブジェクトに変わっただけではないか

そもそもこの20個の引数はなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし20個も引数取る時点設計が間違えている。

何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。

そんなことで悩んでる暇があったら設計を見直せ。

18. メソッドチェインを愛用せよ

スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。

ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。

19. コードの汎用化は慎重に

どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。

・・・と、いうのはやめなさい。

一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。

まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。

かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ!

20. 結合度は適切に減らし、適切に結合せよ

あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。

気を抜いて。そう気を抜いて。所詮あなたコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。

結合度を減らすというのは非常に難しい何度何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。

まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。

そしてその後に、一部分使いましたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。

何事も経験が必要である経験を積まないプログラマ丸めゴミ箱に捨ててしまえ。

さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だってaddとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか

function add_result_output ($iVar, $iVar2) {
    $r = add($iVar, $iVar2);
    echo result($r);
}

もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう!

最後

このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。

しかしもう一度タイトルを確認してほしい

あくまでも「より良いPHPerにならないための20Tips」なのだ。

君はこの記事を鵜呑みにしてはならない。PHPPHPと見抜けないPHPerはPHPを使うのは難しい

おまけ

もし、あなたPHPプログラマなら、公式のPHPドキュメントあなたのケツの穴を拭くための紙になるだろう。

私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。

あなたは、PHPで用意された既製関数で多くのことが実現できることに、(俺の仕事を減らすなと)驚くはずだ。

この記事があなたの役に立たない事を。

どんなコメントでも待ってます

ふざけんな!

個人的な感想

この記事に書かれている内容は、丸めゴミ箱に捨てた方が良いレベルです

もしここまで読んでしまったら、丸めゴミ箱に捨てましょう。

プログラ増田のあなぐら

2009-02-13

[][]

出力関数無限ループを簡単に仕込める仕組みを使ってやるのが良いんでしょうね。

スタックレジスタを簡単に dump できる仕組みを用意すると楽です。




GDB の方では割りとそんな感じのことをやってます(スタックレジスタコードを毎回表示)。ただ、どうしても1インストラクション単位の実行になるので、なんともチマチマした時間のかかる作業です。

# あー、そうか。ソースプログラムからデバッグ情報ダンプできる関数に触れるようにすればいいのか……。つーか、インラインアセンブリを使えばいいのか……。

2007-02-17

rimo.tv.screensaver

>http://www.geocities.co.jp/SiliconValley/8916/Macintosh/rimo.tv.screensaver.html>

rimo.tv.screensaverは、YouTube に掲載されている人気の動画から約1日おきに新しい番組プログラムを生成・配信する はてなサービスである http://rimo.tvを表示するMacOSXスクリーンセーバです。

<<

勝手class-dumpとstringsとotoolで調べたよ。概ね間違っていないと思う。

  • 単一のクラスrimo_tv_screensaverViewで構成され、それをPrincipalClassとするバンドル
  • rimo_tv_screensaverViewはScreenSaverView(/System/Library/Frameworks/ScreenSaver.framework/Headers/ScreenSaverView.h)のサブクラス
  • rimo_tv_screensaverViewは一つのWebView(/System/Library/Frameworks/WebKit.framework/Headers/WebView.h)オブジェクトインスタンス変数に(そしておそらくsubviewとしても)持つ。
  • ページの読み込みはWebFrameクラスの-loadHTMLString:baseURL:で実行。URLは固定(http://rimo.tv/)
  • rimo_tv_screensaverViewは上のWebViewオブジェクトのframeLoadDelegateになっていて、ロード時に-webView:didFinishLoadForFrame:が呼ばれるようになっている(おそらくscale設定をおこなうため)
  • -awakefromNibって何やってるんだろう。

URLとかチャンネルオプション設定で変えられると便利そうだけど、今の超シンプルの方がカッコイイかも。

2007-01-21

ここが変だよコンピュータ用語

ドサッとそのまま落す意から転じて、加工せずそのまま全部出力する的な意味で使われたのかな?

引っかく、こするという意味のほか走り書きする、消す、かき集めたという意味もある。0から自分で作っちゃう事をスクラッチと言うことがあり英語の"from scratch"という慣用表現からきてると思われる。なお、消すと言う意味からテンポラリの意味で使われる事もあったらしい。宝くじなどのスクラッチは銀の部分をこすって落すからこうよぶのだろう。

いや、違う言葉なんだけどね。

昔は思いでの意味でよく歌詞に使われてたなーと。いまじゃ携帯電話帳の事だよなーと。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん