「雑記」の記事 - Crieit

The Zen of Python 邦訳

2019-10-27T23:39:10+09:00

The Zen of Python

って知ってますか？

知らないっていう人は、Pythonインタプリタを立ち上げて、import thisしましょう。

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

こんな感じのやつ。
何番煎じかわからないけれど、邦訳してみます。

The Zen of Python, by Tim Peters 日本語訳版

醜いよりは美しい方がいい。
暗黙よりは明示の方がいい。
複雑よりも単純な方がいい。それでも、ワケわからなくなるよか複雑な方ががマシ。
ネストするよりフラットな方がいい。
詰め込んであるよりも空白が多い方がいい。
読みやすさは重要だ。
特別な場合であっても、ルールを破るに足る特別な理由にはならない。しかしながら、純粋さよりは実用性の方が大事。
エラーを無視してはいけない。明示的に握り潰すなら別だけれども。
曖昧さを前にして、推測で済まそうとしてはいけない。
あることをする明白な方法が1つあり、しかも1つしかないのが好ましい。あなたがオランダ人でもない限り、はじめは明白には思えないにしても。
やらないよりは今やった方がいい。とはいえ、やらない方が今すぐやるよりもいいことはしばしばある。
実装を説明するのが難しいなら、それは悪いアイデアだろう。もし、実装を説明するのが簡単なら、それは良いアイデアかもしれない。
名前空間は1つのとてもいい考え。そういうのをもっとやろう！

ゆるっとしたコーディングや設計に関する指針で、結構ためになります。The Zen of Pythonという名前ですが、Python以外でもこの考え方は通用します。

初心を忘れないためにも、時々import thisするのはいいアイデアなのではないでしょうか？

そういえば

this.sという変数にこの文章が入っています。

s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

いわゆる換字式暗号ってやつですね。換字表はthis.dで得られます。

d = {'A': 'N', 'B': 'O', 'C': 'P', 'D': 'Q', 'E': 'R', 'F': 'S', 'G': 'T', 'H': 'U', 'I': 'V', 'J': 'W', 'K': 'X', 'L': 'Y', 'M': 'Z', 'N': 'A', 'O': 'B', 'P': 'C', 'Q': 'D', 'R': 'E', 'S': 'F', 'T': 'G', 'U': 'H', 'V': 'I', 'W': 'J', 'X': 'K', 'Y': 'L', 'Z': 'M', 'a': 'n', 'b': 'o', 'c': 'p', 'd': 'q', 'e': 'r', 'f': 's', 'g': 't', 'h': 'u', 'i': 'v', 'j': 'w', 'k': 'x', 'l': 'y', 'm': 'z', 'n': 'a', 'o': 'b', 'p': 'c', 'q': 'd', 'r': 'e', 's': 'f', 't': 'g', 'u': 'h', 'v': 'i', 'w': 'j', 'x': 'k', 'y': 'l', 'z': 'm'}

そこで、この暗号を復号するプログラムをPythonで書いてみてください。
sys.stdoutをio.StringIOとかに差し替えてからimport thisは復号プログラムを書いたとは言いませんよ。

正答例

print(''.join(map(lambda x: this.d.get(x, x), this.s)))

ドメイン殺しにやられた話。SNS時代の外部URL遷移は超キケン

2019-10-22T16:42:46+09:00

先日、長いこと閉鎖していたサービスを復活させました。

OGP changer
https://ogpc.ga/

これは、SNS共有用のURLを発行するサービスです。閉鎖に至ったのには大きな理由がありました。

短縮URLサービスのドメインを殺された

きっかけは弊サイトが管理する別の短縮URLサービス「URL Shortener」(lmp.tw)の悪用でした。

URL Shortenerは純粋な短縮URLサービスです。ユーザー数が少ないため、他よりも短いURLを取得できるのがウリでした。

ところが。

短縮URLサービスでテロられたこんなことあるんか
— ウラル (@barley_ural) April 12, 2019

まさかの事態に。

何が起きたのか？

lmp.twドメインが全てTwitterに弾かれ、一切ツイートできないようになっていました。既にツイートされたリンクを踏むと、全てのページでセキュリティエラーが表示されるようになりました。
一言でいうと、ブラックリストに登録されたのです。

危険なサイトへのリダイレクトを作られてしまって、そのせいで短縮URLサービスのドメイン丸ごとTwitterに弾かれてる他のリンクも全部ブラックリスト扱いされてる…
— ウラル (@barley_ural) April 12, 2019

経緯を説明すると、lmp. tw配下全てのリンクに警告表示が出ることを発見→危険なサイトにリダイレクトさせるツイートが投稿されていた→直ちに該当ツイートのリンクの無効化と管理する全てのURLリダイレクトサービス新規登録を停止 pic.twitter.com/ZsERui2Jp2
— ウラル (@barley_ural) April 12, 2019

この人物は、lmp.twの他にも複数の短縮URLサービスで危険なリンクを作成し、ツイートすることで、サービスを殺しているようでした。悪意があるとしか言いようがありません。

これまでも数多くの短縮URLサービスが出来ては消えていきましたが、このような悪意ある利用がその主な原因だったと言えるでしょう。

私はすぐにサービスを停止せざるを得ませんでした。そして、同様のリスクがある以上、他のURLリダイレクトサービスも動かすわけにはいかず、OGP changer(ogpc.ga)も停止することになったのでした。

ドメインを取り戻すまで

lmp.twがブラックリスト入りしたことで、私のTwitterアカウントのプロフィールのリンクが使えなくなりました。

これでは信用に関わります。泣く泣くリンクを削除しましたが、このまま放置するわけにはいきません。危険なリンクは既に削除したので、まずはドメインを回復させます。

危険なURLと判断された流れは次の通りでしょう。

元々「Google Safe Browsing」（URL安全性確認サービス）によって危険と判断されていたURLを、悪意のあるユーザーが短縮URLサービスに登録し、ツイートする。
GoogleによってURLが認識され、Google Safe Browsingでドメイン全体に危険ステータスが付与される。
Twitterや他のセキュリティサービスがその情報を元にドメイン全体をブロックする。

ですから、まずはGoogle Safe Browsingによるスパム判定を解除する必要があります。

サイトが危険と見なされているかどうかはこのページから確認できます。

Google Safe Browsingに再審査を要求する手順はこちらです。
審査に合格するとステータスが解除されます。

Google Safe Browsingによるステータスが解除され次第、マカフィーなど他のセキュリティサービスの解除申請を送ると良いでしょう。

Twitterでは、「スパムを報告」というページから、「Twitterがスパムと判断したため、リンクをツイートできません。」を選ぶことで、スパム判定を食らったリンクを回復できます。

色々やった結果、lmp.tw自体は数週間で回復しました。
信用を失うのは一瞬だが、取り戻すのは本当に手間と時間がかかる、と実感しました。

対策

OGP changerはそんなわけで、同様のリスクがある以上復活させられないことから、長い間「改修中」と称し閉鎖していました。
ちなみにずっと404を返していたところ、ドメイン管理サービスに「使用実態がない」と見なされ、ドメインを剥奪されるハプニングもありました…。

Safe Browsing APIの利用

Google Safe Browsingによって弾かれたのですから、同じ基準で守ればよいのです。
GoogleのSafe Browsing APIを使うと、そのリンクが安全かどうかを判定できます。

こちらのブログを参考に、PHPでURLの判定を行なうようにしました。

サイトの安全性を確かめるSafe Browsing APIをPHPで試す
https://minory.org/safe-browsing-api.html

APIキーなどはGoogle Cloud Platformでプロジェクトを作成して取得します。

感想

外部へのURL遷移には今後注意していこうと思いました。無意味な遷移はできるだけ控えたほうがよいでしょう。もしサービスの中で外部URL遷移を利用している場合は、何かしらの対策を行うべきです。
Safe Browsing APIの利用の他、HTTPのLocationによる遷移ではなく、HTMLのmetaタグによる遷移や、javascriptによる遷移に変更するのも良いでしょう。
まだまだ自分の知らないセキュリティリスクは多いなと感じました。

最後に、半年ぶりに復活を果たしたOGP changerをよろしくお願いします。

オブジェクト指向とは何だったのか（初心者として）

2019-09-16T00:18:49+09:00

極度の面倒くさがりにより、漠然とオブジェクト指向から距離を置いてきたが、最近初めて触れ、やっと理解できた気がするので書く。

世の人間はオブジェクト指向を説明するとき、たい焼きだの設計図だの何だのと言い始める。
そうじゃないんだ。読めるようになりたいんだ。

ということで、自分なりにまとめてみる。PHPを例にする。誰かの役に立てたら嬉しい。

オブジェクトって何

まず、「オブジェクト指向」とはそもそも何かと言うと、設計思想の1つのことだ。
そしてこのオブジェクト指向を実現するため、「クラス構文」という書式がある。要はこれが使えればいいのだ。

「オブジェクト」とは関数と変数のカタマリの事である。関数と変数が梱包された状態だと思ってほしい。

このオブジェクトのことを「クラス」とも呼ぶ。「クラス構文」とは、つまりオブジェクトを定義する書式だと思えばいい。

※わかりやすくするため、ここでは「オブジェクト」＝「クラス」とする。後述する「インスタンス」はオブジェクトと呼ばれやすいが、クラスとは別物。「オブジェクト」＝関数と変数のカタマリの総称、「クラス」＝オブジェクトを定義したもの、「インスタンス」＝クラスをインスタンス化したもの、なんだなーと思っておけば大丈夫。

オブジェクトを使っていく流れ

オブジェクトは定義して呼び出すのが基本で、こういう流れになる。

【定義する】

空っぽのオブジェクトを用意する。
⇓
オブジェクトの中に変数や関数を入れていく。
⇓
オブジェクトが定義できた！（オブジェクト完成！）

【呼び出す】

定義されたオブジェクトを読み込む。
⇓
オブジェクトから変数や関数を引っ張りだして使う。

オブジェクトの中身を呼び出すには

オブジェクトは、中身の呼び出し方を考えてから定義することが多いので、先に呼び出し方を確認しておこう。

例

例として、引数に与えた文字をそのまま表示するユーザー定義関数foo()を用意した。

function foo($str)
{
    echo $str;
}

この関数を、どんな名前でもいいが、ここではMyProjectという名前のオブジェクトに入れることにする。（「オブジェクトを定義するには」で手順は後述）
早速オブジェクトMyProjectからfoo()を呼び出してみる。

// 事前にオブジェクトが定義されているとする
$obj = new MyProject;

$obj->foo('おはよう！');  // おはよう！が表示される

最初の行を見てほしい。
$objという変数の中に、オブジェクトが代入されている。

そう、オブジェクトはnew 〇〇という書式で、変数に一度代入することで使えるようになる。これを「インスタンス化」と呼び、このとき、変数は「オブジェクト型」という状態になっている。

つまり、上記の例ではオブジェクト型の変数$objに、事前に定義したオブジェクトMyProjectの中身がそのまま入っているのだ。

この代入された変数のことを「インスタンス」という。インスタンス＝オブジェクト型の変数のことである。

続きを見てほしい。
$obj->foo('おはよう！')とある。これは、オブジェクトのインスタンスからfoo()というユーザー定義関数を呼び出している。

このとき、普通の関数とは呼び出し方が異なるので、この関数のことを特別に「メソッド」と呼ぶ。

やたら用語ばかり出てきて申し訳ない。先ほどのコードはこういうことである。

オブジェクトを定義するには

さて、ここで先ほどの例で使ったオブジェクトMyProjectを定義する手順だ。

最初に空っぽのオブジェクトを用意する。こう書く。

class MyProject
{
}

この中にさっき作ったユーザー定義関数foo()を入れてみると…

class MyProject
{
    function foo($str)
    {
        echo $str;
    }
}

オブジェクトが完成！
これだけ？これだけ！
これで、MyProjectというオブジェクトの中にfoo()というメソッドが定義されたことになる。

さっき呼び出しの部分で書いたものと組み合わせてみよう。

class MyProject
{
    function foo($str)
    {
        echo $str;
    }
}

$obj = new MyProject;

$obj->foo('おはよう！');  // おはよう！が表示される

これで一段落。これが理解できたあなたは、とても基本的なクラス構文をマスターしたことになる。

オブジェクトにしかできないこと…プロパティ

ここまで来た人は疑問に思うかもしれない。
「関数をメソッドにする意味って何なの？」「それ、ユーザー定義関数で良くね？」と。

ここからは、オブジェクト指向だからできること、プロパティの仕組みを説明する。

「オブジェクトって何？」で説明した図を思い出してほしい。

そう、梱包されてるのは関数（メソッド）だけじゃなかった。変数もいた。
このオブジェクトの中で定義された変数のことを、「プロパティ」と呼ぶ。

プロパティの基本的な定義の仕方と呼び出し方は次の通り。

class MyProject
{
    public $text = 'おはよう！';  // これがプロパティ
}

$obj = new MyProject;

echo $obj->text;  // プロパティの呼び出し

メソッドと似ていることがわかるだろうか？
そう、プロパティとメソッドは扱い方がとてもよく似ている。

今回は、最初に少し見慣れないキーワード「public」について説明しよう。
これは、メソッド（関数）やプロパティ（変数）のアクセス権を示している。
PHPではpublic, protected, privateの３つがある。

アクセス権	範囲
public	オブジェクトの外部から呼び出せる。継承されたオブジェクトから呼び出せる。オブジェクト内のメソッドから呼び出せる。
protected	オブジェクトの外部から呼び出せない。継承されたオブジェクトから呼び出せる。オブジェクト内のメソッドから呼び出せる。
private	オブジェクトの外部から呼び出せない。継承されたオブジェクトから呼び出せない。オブジェクト内のメソッドから呼び出せる。

プロパティではこれらのアクセス権を必ず明示する必要がある。メソッドでは、省略した場合publicとしてみなされる。
つまり、前項の例で作ったメソッドは、publicを省略していたということだ。省略できるのだが、アクセス権はちゃんと書いておいたほうが喜ばれるだろう。

さて、プロパティで注意してほしいのは、メソッドの外でないと宣言できないということだ。
例えば、以下のようなことはできない。

class MyProject
{
    // publicなメソッドを宣言
    public function foo()
    {
        public $text = 'おはよう！';  // メソッド内なのでエラー
        echo $text;
    }
}

$obj = new MyProject;

echo $obj->foo();

これは、ユーザー定義関数の特性上、その中で使われる変数はローカルスコープでないといけないからだ。
もしメソッドの中でプロパティを使いたいのなら、$obj->textみたいな感じで変数を呼び出さなければならない。だが、自分のオブジェクトの中で自分のオブジェクトを指定するのもおかしいよな…ということで、擬似変数$thisが登場する。

class MyProject
{
    public $text = 'おはよう！';

    public function foo()
    {
        echo $this->text;  // $thisは自分自身を表す
    }
}

$obj = new MyProject;

echo $obj->foo();  // おはよう！

$thisを使うと、プロパティを活かして、例えばこんなことができる。

カートに商品を追加する例

class Cart
{
    protected $quantities = [];  // 商品ごとの量が入る

    public function add($product, $quantity)
    {
        $this->quantities[$product] = $quantity;
    }

    public function get_quantity($product)
    {
        return $product . 'は' . $this->quantities[$product] . '個';
    }
}

$my_cart = new Cart;
$my_cart->add('バター', 1);
$my_cart->add('牛乳', 3);
$my_cart->add('卵', 6);

echo $my_cart->get_quantity('牛乳');  // 牛乳は3個

合計金額を表示するメソッドも作れる。

class Cart
{
    protected $prices = [
        'バター' => 600,
        '牛乳' => 180,
        '卵' => 200,
        'アイス' => 100
    ];
    protected $quantities = [];

    public function add($product, $quantity)
    {
        if(isset($this->prices[$product]))
        {
            $this->quantities[$product] = $quantity;
        }
    }

    public function get_quantity($product)
    {
        return $product . 'は' . $this->quantities[$product] . '個';
    }

    public function get_total_price()
    {
        $total_price = 0;
        foreach($this->quantities as $key => $quantity)
        {
            $total_price += $this->prices[$key] * $quantity;
        }
        return $total_price;
    }
}

$my_cart = new Cart;
$my_cart->add('バター', 1);
$my_cart->add('牛乳', 3);
$my_cart->add('卵', 6);

echo $my_cart->get_total_price() . '円';  // 2340円

オブジェクト指向の便利さはここからだ。上の例の後半だけ次のように書き換える。

$cart1 = new Cart;
$cart1->add('バター', 1);
$cart1->add('バター', 3);
$cart1->add('卵', 6);
$cart1->add('卵', -3);

$cart2 = new Cart;
$cart2->add('アイス', 2);
$cart2->add('牛乳', 1);

echo $cart1->get_total_price() . '円';  // 1200円
echo $cart2->get_total_price() . '円';  // 380円

インスタンス$cart1, $cart2が別々のものとして計算されている。つまり、2つのオブジェクトは独立して動作しているのだ。

これがインスタンス化の最大のメリットである。もしこの処理をユーザー定義関数で無理やり実現しようとすると、それぞれの処理が複雑に干渉してしまい、たちまち地獄が訪れるだろう。

処理をいい感じに独立させることは、プログラミングをする上でとても大切だ。また、プログラムに将来への拡張性があることも、どれほど大切かわかる人は多いだろう。

オブジェクト指向はこれを実現するためにある。
インスタンス化で複数の機能をいい感じに独立させられる。またクラスの中にメソッドを追加しても他の処理に影響を与えないため、将来への拡張性も確保できる。

おわりに

オブジェクト指向はプログラマの「あったらいいな」が詰め込まれているため、機能が多すぎて面食らってしまいやすいが、本質的な部分はとても簡単なものである。
継承や無名関数、コンストラクタなど、面白い機能が他にもたくさんあるので、興味があるものから一つずつ調べてみるのがいいだろう。

PHPマニュアルおすすめ部分

障害が起きたときに誰が謝るのかという問題（社内サービス編）

2019-04-12T23:52:08+09:00

今は社内の開発者向けにサービス開発をしていて、まぁまぁの人数に使ってもらっている。で、サービスはまだまだ発展途上なので、リリースしてからもたまにシステムメンテナンスなどを行うことがある。まぁそんな感じでちょいちょい本番系をイジることがあるわけだけど、今日はそのメンテナンスをきっかけに障害が発生した。

ここで問題なのは障害が発生したことではなくて（もちろん障害それ自体は問題なのだけど）、障害をどうハンドリングするかっていうこと。ここで言うハンドリングというのは、

障害を調査し、解決すること
障害を拡大させないために作業を指示すること
障害の内容を利用者に説明すること

通常、これらをすべてうまくこなせるのは障害を起こした本人だったりする（もちろんそれなりに技術や知識があることを必要とする）。であるならば、障害を起こした人はどの作業に専念すべきだろうか？これは当然#1である。次に#2で、#3。ということで、対応の優先度は上から順番に行うべき。

とはいえ、実際のところ、それなりにいるユーザーたちからは苦情が上がってくるわけで、障害内容を説明しなければならない。で、この説明を考えるのはそれなりに難しい。もちろん嘘をつくのはダメだけど、とはいえ、どこまで内容を詳らかにするか。そして、正確に問題を説明できるのも障害を起こした本人。そして、なぜ#2を行わなければならないのかを説明できるのも障害を起こした本人。

こんな感じであらゆることが障害を起こした本人にのしかかってくる。ここでようやく本題に入るわけなんだけど、一番やりたくない（というか、やる必要性が無い）し、面倒なのは、問題を説明し謝ることじゃないかなと思う。それに、当事者が謝るべきという考え方だと失敗を責める文化ができてしまって挑戦的な試みができなくなる組織になる。

で、じゃあ他に誰が謝るのかということになる。謝るためには事態を正確に把握し、理解する必要があるけど、実際には無理。解決しようとする人を捕まえて、理解できるまで逐一説明させるとか自己満足でしかない。なので、（良い意味で）ごまかしが出来るセンスが必要になる。自分にはそういった感じのセンスがあるかなと思ってたけど、結局最後には障害を起こした本人に謝らせることになってしまった。まぁそれは本人が自主的にそうしたから、そうなったんだけど最後までちゃんと謝ることができなくて、ふがいないなーと思ったっていう、ただそれだけのために1000文字ぐらいをここに書いた。