がるの健忘録 このページをアンテナに追加 RSSフィード

2017-01-20

[]ini_set()どうすっかねぇ…

色々とテストを作っていてふと「ini_set()のテストも組まないとなぁ」が、面倒の始まりでした。


当初の思惑としては「多分、noticeなりwarningが出るだろうから、その辺のエラーうまいこと拾えばよいかねぇ」とか思ってたのですが。

戻り値にfalse返してくるけど、それ以外はうんともすんとも言わない」のですよ…うんまぁわからんでもないが…


…あれでもおかしいなぁなんか警告出てた記憶があるなぁ、と思ったのですが。

「新しいバージョンで非推奨になったものについてはDeprecatedが出る」のですが「根本的に綴り間違い」だとfalse returnしか出てこないのです……

実際に

<?php

ini_set('display_errors', '1');
error_reporting(-1);

$r = ini_set('hoge', 'on');
var_dump($r);

こんなコードを書いても。

false returnは確認できるのですが、それ以外はうんともすんともにゃんともかんとも。


ここで気になるのが、過去の記憶。

「それPHP_INI_SYSTEMだからini_setで変更できねぇから!!」から「ini_setで渡す文字列間違えてるぢゃん!!」まで、問題挙動を結構見ている記憶がモリモリと出てくるのでございます。

…正直「ini_setで戻り値チェック」とか、今まで見た記憶もねぇしなぁ。


…と、ここまでで現時点。

「一枚ラップかまそう」かとは思ってるのですが…「関数callのコスト」が微妙に気になって…でもまぁ「ンなコストよりも面倒をつぶすほうがいい」かなぁ、とも思っていて、揺れるおいちゃん心でございます。


多分、ラップはこんな関数になると予想。

function mw_ini_set(string $varname, string $newvalue) {
    // ini_set発行
    $r = ini_set($varname, $newvalue);
    // エラーチェック
    if (false === $r) {
        // 「動きとめる」くらいの強硬手段でよかんべさ
        trigger_error("ini_set error!!({$varname})", E_USER_ERROR);
    }
    // else
    return $r;
}

もうチョイと煩悶してみます。

……どっかで「腑に落ちた」ら、MagicWeaponには追加して、ついでにmw_ini_set.incとかを書きなおそうかと思います。


まだちょっと煩悶してるので、ご意見などありましたら、ぜひ。

2017-01-19

[][]「言語の仕組み」とかを学ぶのによい書籍群

うちの生徒さんから

最近プログラムの言語(言語の仕組み)やアセンブラとかに興味が向いて来てるんですけどオススメの書籍とかってあったりしますか?

という質問が来たので、ちょいとDMだと長くなりそうなのもあって、Blog私信を書いてみます(笑


んと…まず「言語の仕組み」って意味では「コーディングを支える技術」がとてもお勧め。

「さまざまな言語を縦櫛で貫く」あたりのこの書き方は、本当に今でもしびれるほど素晴らしいと思ってるざんす。


また、最近出てきた「まつもとゆきひろ 言語のしくみ」も、これは「言語を開発する」って観点から書かれてるので、ちょっとだけ横道かもしれないけど、面白いざます。


「言語を作る」の延長線としての「コンパイラ」に興味があったら、とりあえずは

スモールコンパイラ の制作で学ぶ プログラムのしくみ

スモールコンパイラ の制作で学ぶ プログラムのしくみ

が、ライトだと思う。

この後は「レッドドラゴン」とか、撲殺できる書籍に向かう方面になる(笑


この辺を踏まえた上で…アセンブラの本、になると「ど真ん中」にお勧めなのは少ないので、ちょっと脇道にいきながら。


初めに読んでおくとよいなぁと思うのが「コンピュータアーキテクチャエッセンス」。

アセンブラを理解するための基礎体力」が見につくので、強くお勧め。

ハード周りに興味が出たら

に寄り道するのも、ありw


この後は色々散らかるんだけど…アセンブラの書き方そのものであれば、手元にある書籍的には「熱血!アセンブラ入門」が割とお勧めかなぁ。

熱血!アセンブラ入門

熱血!アセンブラ入門

鈍器だけど(笑)、基本的な「アセンブラでの記述の仕方」が色々と書いてあるので、よいと思う。

で、これを読んだうえで。興味があったら、おいちゃんが(某人物とタッグ組んで)仕様を作った「terakoya_cpu( http://www.m-fr.net/tane/study/learn_c/terakoya_cpu_20070722.pdf )」を見てみると、面白いかも。

シンプルなセットだけど、一応これだけで「一通りあらゆる事が出来る」ように設計をしてあるので。

元々「学習用途を想定して作った」ものではあるんだけど、それだけに「本当に最低限」しかない言語仕様なので、シンプルに色々とまとまってるつもり。


Binary Hacks ―ハッカー秘伝のテクニック100選

Binary Hacks ―ハッカー秘伝のテクニック100選

あたりも、一度は目を通しておくと面白い。


ちょっと横道だけど

なんてのも「バイナリレイヤーを知る」って意味ではやはり面白い。


この辺が、今の所すっと浮かぶ「おいちゃん手持ちの中からのお勧めの書籍」かなぁ。

2017-01-14

[]大根サラダ

かなり備忘録的に。


大根10cmくらい

[たれ]

・醤油:大さじ1

・お酢:大さじ1

・ごま油:大さじ1

・みりん:小さじ1/2

・砂糖:小さじ1/2

・お好みで、ゆず粉末とかゆず胡椒とか


大根は「ツマ」くらいの感じのでスライサー。10秒〜1分ほど軽く水につけて、水を切る。

たれは適宜混ぜ合わせて。

ノリ、鰹節なんかを合わせつつ、大根とたれとを混ぜて終わり。


概ね「たれの比率」を備忘録したいためのレシピw

[]ブリの照り焼き

簡単バージョン。


・ぶり2切れ

・醤油、みりん、酒、砂糖:各大さじ1くらい

・お好みで、しょうが、ゆず系調味料など


1. ブリを軽く(30分くらい)漬け込んで

2. ブリを焼いて片面に焼き色つけて

3. ひっくり返してたれ入れて煮詰める

2017-01-01

[]「正しさハラスメント」ねぇ……

元ネタ

不寛容社会とエンジニアの「正しさハラスメント」

http://emokuaritai.hatenablog.jp/entry/2016/12/28/115401


色々と「言ってることがわかる部分」も多々あるんだけど、気を付けないと割と「ダークサイドに堕ちやすい部分」もあって、おいちゃん的にはどちらかというとその「堕ちそうなダークサイド」のほうがとても気になったので、些か突っ込み。


上述Blogをものすごくざっくりと、かつ「幾分」好意的に解釈すると、以下のようなもんじゃないかなぁ、と認識している。

・特に初学者などで「とりあえずとっかかりとしての成功体験」を重ねることは多い

・その"成功体験を折りに来る人が存在する"

−→そういった初学者のコードは"拙いものであることも多い"が、一部の"エンジニアは、それを許さない"

・上述について"もう少し配慮ができないものかと思っている"


このあたりから想起されるもののひとつに「間違っていることを指摘するために"攻撃する"がごとき怒声を繰り出す」タイプがあって、これは割と明確に「やめとけ」って、おいちゃんもなるざんす。

「愛語はよく回天の力あり」なんて申します言葉があったり、或いは「丸い卵も切り様で四角、物も言い様で角が立つ」なんて言葉もございます。

初学者がたとえ間違えたとはいっても、だからと言って汚い言葉でののしる必要はないので。

そのあたりは「適切に説明をすれば」事足りるものでございます。


…ってまではいいんですがね。

気になるのは、ここから。


元ネタのほうでも「設計」がお題に挙がってたので、後輩Bさんの設計を先輩Aさんが見て、の発言と仮定しましょう。

ここでAさんが「てめぇは馬鹿か! こんなクソみてぇな設計でどうにかなるわけねぇだろ!!」とのたまわったら、多分これは確実に「物も言い様で角が立つ」ごとき発言かと思われます。

ただ一方で「じゃぁどれくらい気を使って発言をすればよいのか」って問題があって、それが「普通の言葉であれば」の普通ってどの程度? ってあたりに個人差があるよねぇ…ってあたりから、この辺の論調が幾分怪しくなってきます。

で、もうちょっと片方の極にふると「自分の設計を否定されたら、たとえそれがどんな物言いであっても不寛容でありよくない物言いとなる」というタイプも、後輩Bの側に、いらっしゃるのがこれ自体は事実です*1


で、もしお話をする相手が「自分への肯定以外は許容しない」タイプが「あなたのその物言いは不寛容だ!」と言ってくるとすると、それは些か面倒だなぁ、と思います。なにせ前提として「後輩Bの設計には、幾分ならざる問題がある」状況、なので。

これってつまり「問題はあるけどそれを指摘するな」って言っているのと同様なので。これが「よいのか?」と問われると、大変に疑問です。

いや「プライベートなら(設計上のスケーラビリティとかメンテナンス性とかは)気にスンナ」って一言で切ってもよいとは思うのですが、お仕事でそれをされると、後で尻拭いをするほうに苦労が回りますので、大変に困ります。


で…元ネタのBlogを見ると、より一層気になる事が書いてあります具体的にはセキュリティのあたりで。

勿論、全くセキュリティ対策をしていないプログラムというのは、Production環境で使うには危ういものではあるし、当然推奨されるものではないが、その「正しくない」状態でも、別にセキュリティ対策がプログラムの本質ではないのだから、先により本質的な成功体験を積ませてやるべきである。

正直に申し上げると「ンな成功モドキ体験を積まれて変な癖がつくほうが困る」というのが本音でございます。

端的に実例を頭ん中でリプレイするだけでも……正直「セキュリティは後でどうにかすればいいしどうにかなる」って妄想している駄目ジニアな方々の暴挙は、少なからず目にしているので。

じゃぁ実際に「後でどうにかしたりするか出来るか」っていうと「しないしそもそも出来ない」ので。

程度問題もあるのですが、基本的なWebセキュリティの場合「初めにちゃんと意識をしておけ」としか言えないものでございます。


んで。

Qiitaなどを見ていると、初学者が作った簡単なフォームによるリクエストとそれに対してのレスポンスを行うプログラムに対して、「こういった書き方はセキュリティ上問題があるからまず最低限このようにXSS対策をしましょう。また、現在のモダンなコードとしてはこのような記述のされかたが一般的であり……」といったコメントをしている人をたびたびみかける。

に対して

彼らにとっては「はじめてのプログラムが思い通りに動いた」という事実がベースとなっているわけであり、わざわざその成功体験の「気持ちいい」状態を阻害する行為には、正直疑問を覚える。

とあるのは…正直「それに疑問を覚える事」に疑問を覚える感じでございます。


もちろん初学者なので「原理を理解してから書け」とまでは言いませんが。

ただ「とりあえずおまじない、としてって理解でいいから、こういう風に書きましょうね」というのは、むしろ「教えてくれる優しさ」であって、不寛容とはむしろ真逆なんじゃないかと思うんですけどそのあたりどうなんでしょうねぇ?


ついでに

学んでいく中で、セキュリティ対策というものはいずれ得る知識ではあるだろう。

甘い。甘すぎる。正直「実情しってる?」って聞きたくなる感じでございます。

「意識しないでよい」まま育ったエンジニアは、たとえ齢とキャリアを10年以上重ねようとも「セキュリティ対策という知識を得ないまま」になります。


で、同じような、気になる内容が、他にも。

もう少し工夫して、本人と近ければ、そっと少しずつ、必要な時に教えてやれば良いし、そうでなくとも、例えばQiitaが媒体なら編集リクエストがあるうえ、コメントならブログにもあり、ひとことふたことと参考URLあたりを書いておくだけでも十分だと思う。

そういった、小さな小さな配慮によって、当人は自身が学ぶべきタイミングでそれらを身につける機会を逃さず、また、リアルタイムで駆け抜けている学びを阻害されることもないと思う。

そもそも「いつもあっているわけではない」Webという世界で「教えてやるべき必要な時」なんて見計らえない…そもそもとして、そーゆーのは「卒啄同時(そったくどうきorさいたくどうき:卒の字は正しくは口+卒)」なんて言葉が存在するくらい「近くで見守っていてもなお難しい」ものです。

で、じゃぁ「本人が必要と気づくときに学べばよい」については「知らなければ、必要であることがわからない」で片付きます。

つまり「本人が必要であると気づくタイミングがないのでいつまでたっても学ばない」というのが、実例ごろごろしてます。

「極寒の地で全裸で凍えながらなぜつらいのかわかっていないようなもの」というヒソカ氏の発言の重みを、しみじみと感じるところです。


なので、元ネタBlogの人の言う「正直、もう少し配慮ができないものかと思っている」については、「言う側が出来る部分もあるけど言われる側が考慮すべき部分もある」んじゃないかなぁ、と思うざます。


ざっくりまとめると。

指摘の仕方について「あんまり汚い言葉や人格を攻撃するような物言い」については、NGだと思う。なので、言う側として、ある程度は「言い方」について配慮をしてみる、というのはそれこそ「より正しい」と思われる努力の方向だと思う(そもそも「他人に何かを指摘する事自体に心理ハードルがある」系の御仁もいらっしゃるのである程度の無理を承知での物言いではあるのだが、おいといて)。


ただ一方でそもそも技術職である以上「より正しい知識を教わりながら育つ」ものだと思うので…というか大概どこの世界にいっても「間違いを指摘されて修正する」という繰り返しは幾度となくめぐり合うものだと思うので。

「誤りの指摘=嫌がらせや人格攻撃やハラスメントの類である」といった妄想は、早いタイミングでとっとと/dev/nullにリダイレクトしたほうがいいと思う。


……って感じの内容は他所でも拝見したのですが、ちょいと気になった年末の文書だったので、ざっくりと。

*1:おいちゃんの観測範囲内ですら存在するので、頻度はともかくとして、存在はします

2016-12-12

[]やっぱり「型に厳格なのは大事だなぁ」という雑感

大本のネタは

https://twitter.com/ndxbn/status/808159644874993664

「in_array の第3引数にtrue必須」っていうコーディング規約をCIで回したい人生だった。

https://twitter.com/gallu/status/808161595578662912

@ndxbn in_array()、色々と気になるから使わない一派所属。線形検索とか、イクナイ!、って思うの。


ってあたりからほんのり調べ物をして見つけた、某所でみたコード。

コード自体は一通り引用、別にさらしたりするのが目的ではないので、引用元は一端オミット。

<?php
header('Content-Type: text/plain; charset=utf-8');
$secret_password = 'This is very secret password';
$input_password  = isset($_POST['password'])    ? $_POST['password']    : '';
$shell_input     = isset($_POST['shell_input']) ? $_POST['shell_input'] : '';
if (!strcmp($password, $input_password)) {
    - 中略:認証が通った時にさせたい処理 -
} else {
    - 中略:認証NGの時にさせたい処理 -
}

論調としては「配列が帰ってくる事があるから上述そのままだと(パスワードがわからなくても「認証が通った時」のロジックが通るから)危ない」って話なんだけど…微妙な違和感が2か所ほど。


シンプルなところは「$_POSTの戻り値、なんでstringでキャストしないん?」ってあたり。まぁこの辺は賛否あってもいい所ではあるのでそんなに強く言わないのだけど、おいちゃん的には気になる違和感。


if文の「$passwordって、多分、$secret_passwordだよねぇtypoじゃない?」って細かい話はおいといて。


もうちょっと気になるのが、if文の中の条件式。

if (!strcmp($password, $input_password)) {

って書いてあるんだけど、おいちゃんなら間違いなく

if (0 !== strcmp($password, $input_password)) {

って書く。記法ヨーダなのは「おいちゃんの癖」なので気にするなw


で…簡単なテストコードを書くと、===で「厳格なチェック」すると、配列がわたってきても「とりあえず認証が(誤って)通る事はない」事が、ほんのりわかる(Warningがうざいので、エラー出力一端消し)。

ini_set('display_errors', 1);
ini_set('display_errors', 0);
error_reporting(-1);

$password = 'hoge';
$input_password = array();

var_dump( !strcmp($password, $input_password) );
var_dump( 0 === strcmp($password, $input_password) );
var_dump( strcmp($password, $input_password) );

bool(true)

bool(false)

NULL

…へぇ「引数配列だと戻り値NULLになる」のか。

マニュアルには書いてない挙動だw


まぁ、いずれにしても。

おいちゃん的に、なんとなし「!(なんかの値)」は、この手の自動変換もあるので、割合と好まないのだよねぇ。

なので、この辺の「!(なんかの値)」で判定しちゃってるところが、おいちゃんの違和感で、気になるところ。


おまけで、strcmpの挙動を少しみてみた。

ini_set('display_errors', 1);
ini_set('display_errors', 0);
error_reporting(-1);

function hoge($p1, $p2) {
  var_dump($p2);
  var_dump(strcmp($p1, $p2));
  echo "\n";
}

hoge('hoge', 'hoge');
hoge('0', 0);
hoge('2a', 2);
hoge('0', 0.0);
hoge('1', 1.0);
hoge('2a', 2.0);
hoge('hoge', true);
hoge('hoge', array());
hoge('hoge', new stdClass());
hoge('hoge', fopen(__FILE__, "r"));
hoge('hoge', NULL);

string(4) "hoge"

int(0)

int(0)

int(0)

int(2)

int(1)

float(0)

int(0)

float(1)

int(0)

float(2)

int(1)

bool(true)

int(55)

array(0) {

}

NULL

object(stdClass)#1 (0) {

}

NULL

resource(5) of type (stream)

NULL

NULL

int(4)

まぁWebアプリから入ってくる経路だと「文字列または配列」だからよいのだけど、むしろ怖いのは数値だわintにしてもfloatにしても。

booleanの時の値が謎なんだけどとりあえず「不一致」にはなるし。NULLも謎くさいけど、同じく「不一致」になるので気にしない*1

あと、配列インスタンスリソース型を渡した時にNULLになる、ってのは覚えておくと色々と便利な気がする。


しばらくこの手の「調査系/技術系」のネタを書いてなかったので、ちょろり。

*1:NULLは多分「もう片方の比較する文字列の長さ」が帰ってくるぽ