ADHDエンジニアのL2キャッシュ

ADHDの能力を駆使して自由な発想を落としていくよ

Amazonアソシエイトの審査に落ちました

アフィリエイトの一種でAmazonアソシエイトというサービスがあります。
Amazonのリンク辿って商品を買ったら、リンクを張った人に収入が入るというアレです。

そんなわけで何の気はなしにアカウントを作ってこのブログを紐付けたところ審査に蹴られました。
サクッと通るかと思っていたら意外と審査は厳しくされているようです。

まだまだ駆け出しのブログですし、一日一桁アクセスなので収益化とかは全然考えていないのですが、やっぱり落ちるとショックなものです。

一体何がダメだったのか

というわけでブログ全体を見返してみると、まぁ全然ダメですね。

  • テーマがあやふや
  • 記事少なすぎ
  • 文章下手すぎ
  • 適当に紹介リンク貼りすぎ

特に記事少な過ぎが根本的にダメですね。
そもそも審査なんて真面目にやってるとは知らなかったので全然メンテせずに申請を出したわけですが、色々ぐぐってみると記事はある程度ないとダメなようです。

俺たちの戦いはこれからだ!

落ちたと言っても別にアダルトコンテンツやネットワークビジネスなどの怪しげな内容を扱っているわけではないので、記事数さえ増やして戯言記事を削って行けばそのうち通るんじゃないかなぁと楽観視しています。

Amazonさんがどんな基準で審査しているのか気になるので今後も定期的に申請を出して様子見ていきたいと思います。

Bitcoinの技術について調べてみました

大変有名な仮想通貨であるBitcoinについて少し調べてみたのでまとめます。

以下のサイトを参考にしました。

bitcoin.peryaudo.org

はじめに

このシステムを思いついたサトシ・ナカモトと言われる人物は間違いなく本物の天才でしょう。

Bitcoinが高度な技術を使用しているからではありません。
お金の本質を完璧に理解し、過不足なくシステム化してあるからです。

Bitcoinとは簡単に言うと「全員が複写している署名付き台帳」のことです。

コインはどこで管理されているのか

Bitcoinのコインは一体どこにあるのか?

答え:「どこにもない」

まぁ強いて言うなら口座残高の数字がそれだといえるかもしれません。

日本円であれば紙幣1枚1枚にIDが振ってありますが、Bitcoinは紙幣や硬貨に相当するデータがありません。
有るのは取引履歴だけです。

これはまさしくお金の本質を射ています。

紙幣は元々は貴金属などの価値のある物品の預り証が起源と言われています。 近代まで時代が下ると、金と交換できることを前提に広くやり取りされるようになりました。 つまり、本来の紙幣の役割は以下の2つです。

  • 金と1対1で対応していること
  • 他人と取引できること

しかし、ニクソンショック以降は紙幣と金の交換は保証されなくなりました。 即ちお金の本質は以下の一点に集約されます。

  • 他人と取引できること

つまり取引の記録さえ正しく取れば通貨として成立するわけです。

Bitcoinによる送金の記録

Bitcoinの送金の記録は非常にシンプルです。 一回の送金記録はトランザクションと言われます。 トランザクションは以下のデータの集合です。

  • 宛先口座番号(=受け手の公開鍵)
  • 直前の取引のハッシュ値
  • 送金者のデジタル署名

要は「いつどこに送ったか」という情報に送金者のサインが有るだけです。

ちょっと工夫しているなと思うのが以下の点です。
まさに無駄がないといった感じでとても好きです。

  • 前後関係の管理に取引時間ではなく直前取引のハッシュ値を利用している。
  • 口座番号はデジタル署名に使う公開鍵を使用している。

不正を考慮しなければこれで通貨としては成り立ちます。

Bitcoinにおける不正監視

Bitcoinは送金記録の集まりなので起こりうる問題があるとすれば、次のような感じ。

  1. 勝手に過去のトランザクションを書き換える
  2. 矛盾したトランザクションを作る
  3. 勝手に新規発行する
  4. 持っている金額以上の送金を行う

1に関しては前回取引の記録をハッシュ値にして取り込んでいるので、ハッシュ機構とデジタル署名がまともに機能していれば防げます。
2〜3に関しては結局どの取引を信用するのかという問題になります。
4に関しても残高がマイナスになるような取引を信用せず、受け取り手が後にトランザクションを繋げなければいいだけの話です。 (逆に信用してトランザクションを繋げれば信用貸状態になるということです)

通常の通貨であれば銀行がこのあたりの責任を負うのですが、Bitcoinには中央銀行が存在しないP2Pシステムです。
Bitcoinの結論は「コストのかかっている取引を総意とする」ということです。

ブロックチェーンによる総意の決定

トランザクションはブロックという単位でアーカイブされ、これまたチェーン構造を取ります。(ブロックチェーン
このブロックチェーンはネットワーク全体に公開され、参加者なら誰でも継ぎ足すことができます。

そして、ここがBitcoinの肝なのですが、このブロックを作るには膨大な計算リソースを消費するように設計されています。
つまりブロックチェーンの長い取引ほどコストがかかっているわけです。

ブロックチェーンが競合した場合は最も長いブロックチェーンBitcoinネットワーク全体のブロックチェーンとして信用します。

自由競争市場ではモノの価値はいずれコストに落ち着く仕組みを上手く利用して、コストにより価値を維持しているのです。

通常の通貨が政府によりコントロールされているのに対して、競争の仕組みで通貨価値をコントロールしているのは、本当に経済というものをよく理解しているなと思いました。

Bitcoinの新規発行

Bitcoinは基本的には壊れたりなくしたりしないので、新規発行しなくても問題内容に思います。
通貨価値は市場原理でコントロールされますし。

ですがBitcoinは新規発行通貨をブロックチェーンに追記した者(通称マイナー)に報酬として付与しています。

これは本当に感嘆したのですが、ネットワーク維持コストをインフレによって贖っているということです。

現在Bitcoinは注目が高まっているため需要が高まり価格があがり続けていますが、一般には通貨というのは発行量が増えると価値が下がっていきます。
つまり、新規発行が増えれば増えるほど既存のBitcoin保有者は損をするということになります。
そしてその損失分はマイナーの利益として供給されます。

つまりBitcoinの新規発行の仕組みは、全Bitcoin保持者からネットワーク維持者への資金移動を実現しているのです。

この仕組みに気づいた時は「遊戯の奴そこまで考えて・・・」と驚きました。

まとめ

OSS Gateに参加してきました

8/12に大阪で開催されたOSS Gateに参加してきたのでその話をまとめます。

どんな会

オープンソースに携わっていない人を主にターゲットとした、チュートリアルのようなものです。
各地で継続的に活動しているいるようです。

OSS Gate | Doorkeeper

圧倒的Mac

15人ぐらい参加してたんですが8割がMacでした。
やっぱUnix系使いたいよね…

gitのMLに投函

どのプロジェクトに参加してもいいということで普段お世話になっているgitさんにちょっかいを出すことにしました。
gitはLinusさんのテリトリーなのでMLでやり取りされています 。 そのMLに参加して「ドキュメントが酷いぞ」という私的を春巻きに包んで指摘しておきました。

感想

非常にゆったりしたペースで司会が進行して特に難しさなどは感じなかったです。
今後も気軽にCommit出来るようになればいいなぁと思います。
会場に使わせてもらったさくらインターネットさんのカフェテリア?がとてもオシャレでした。

ブラック企業一覧が完成したようです

知らない間に厚労省のデータをいい感じに見やすくした『ブラック・ブラック企業』というサイトができたようです。

地味な黒ベースのサイトですがデザインがスッキリしていて個人的には好きです。

地域別に調べることが出来るので就活生は是非参考にしてください。

http://structure-and-representation.com/works/blackCorporate/

まだまだ有名ではなく「ブラック・ブラック企業」で検索しても全然見つからず。

以下のニュース記事からリンクを辿って閲覧しました。 structure-and-representation.com

※ちなみに「ブラック・ブラック企業 Structure and Representation」までいれると検索にかかりました。 ブラック・ブラック企業 Structure and Representation - Google 検索

ブラック企業ネタは最近地味に盛り上がって来てるので、その辺でビジネスできたら儲かりそうな気がしますね。

前職にいた頃のサービス残業を暗に指示するメールも密かに保管したままなので、どこか買い取ってくれませんかね?笑

ついでにいうと希望して取得できなかった約20日分の有給も買い取ってほしいですね。

まぁ過ぎたことは仕方ないとして、なにか楽しいことをビジネスにできたらなぁと思う今日このごろです。

といってもそう簡単にうまい話は転がってるわけがないのですが。

なんでも良いからやってみる、と言うのは大事かなぁと思って色々思索しています。

PyCharmでunittestが実行できない

Python3をインストールしたので早速IDEでTDD回して気前よく開発を始めようと思ったのですが、派手にころんだのでまとめます。

迷子の迷子のテストさん

まず始めに作った階層はJavaに似せてこんな感じ。

auto-trade/
+- main
    +- __init__.py
    +- DailyPrice.py
+- tests
    +- __init__.py
    +- TestDailyDrice.py

__init__.pyというファイルを置くとパッケージとして認識されるそうな

その結果こんなエラーが

ModuleNotFoundError: No module named '/Users/ksilver/PycharmProjects/auto-trade/test/TestDailyDrice'

なんだこれは、テストでコケるならまだしもモジュールが見つからない???

実行環境おかしいんじゃね?

とりあえずIDEの設定を確認しようそうしよう。

Projectの設定はProjectを右クリックしたメニューから……無いじゃん!!!

仕方なくPrefereneceから辿って設定に行き着きました。

もうちょっとマシな辿り着き方ないんですかね。。。。

設定を見ても正しくPython3.6が指定されている模様。

コマンドで叩いてみる

ググったら良い記事が合ったので採用

adtech-blog.united.jp

これをもとにコマンドを叩いてみます。(たんたかたーん)

kMBA:auto-trade ksilver$ python3 -m unittest tests.TestDailyPrice
E
======================================================================
ERROR: TestDailyPrice (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: TestDailyPrice
Traceback (most recent call last):
  File "/usr/local/Cellar/python3/3.6.2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/unittest/loader.py", line 153, in loadTestsFromName
    module = __import__(module_name)
ModuleNotFoundError: No module named 'tests.TestDailyPrice'


----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

なんだろう、怒られてしまいましたぞ。

そんなモジュールねぇってさ。わけがわからないよ

本家を参照してみる

これは一旦本家ドキュメントに立ち返るしか無い

26.4. unittest — ユニットテストフレームワーク — Python 3.6.1 ドキュメント

ファイルもルート直下に移動してテストコードをコピーして実行

kMBA:auto-trade ksilver$ python3 -m unittest TestDailyDrice.py 
...
----------------------------------------------------------------------
Ran 3 tests in 0.000s

OK

おおお動いた!!!

しかしPyCharmでは相変わらず動かない。

PyCharmで動かないのはなぜ?

実行ログをを良く確認する。

FAILED (errors=1)
Launching unittests with arguments python -m unittest /Users/ksilver/PycharmProjects/auto-trade/TestDailyDrice.py in /Users/ksilver/PycharmProjects/auto-trade/main

ん?実行ディレクトリがなんかおかしくね?なんでmainで実行してるんだ?

一旦全てのディレクトリを消し去って構成をフラットにしてリトライすると実行すらできませんでした。

Error running Unittests in TestDailyDrice.py: Cannot start process, the working directory '/Users/ksilver/PycharmProjects/auto-trade/main' does not exist

なんか勝手にworking directoryと言うものが設定されているようです。

しゃーなしなので全ファイルをmain直下に移して実行するとうまくいきました。

結論

PyCharmではプロジェクト直下にソースコードを置いてはいけないようです。

次のような構成にしたらうまく動きますよ。というお話

root/
+- main/
    +- product.py
    +- test/
        +- test_code.py

Python3をインストールしてみました

技術メモ

Macにpyenvでpython3を入れようとしたら失敗しました。

色々やってみましたが全然うまく行かなかったので記録に残しておきます。

pyenvを入れようとして失敗

kMBA:work ksilver$ pyenv install 3.6.2
Downloading Python-3.6.2.tar.xz...
-> https://www.python.org/ftp/python/3.6.2/Python-3.6.2.tar.xz
Installing Python-3.6.2...

BUILD FAILED (OS X 10.12.5 using python-build 20160602)

Inspect or clean up the working tree at /var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068
Results logged to /var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068.log

Last 10 log lines:
  File "/private/var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068/Python-3.6.2/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/private/var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068/Python-3.6.2/Lib/ensurepip/__init__.py", line 189, in _main
    default_pip=args.default_pip,
  File "/private/var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068/Python-3.6.2/Lib/ensurepip/__init__.py", line 102, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/private/var/folders/b2/s70h2rk10q3g959t0y6mwdnm0000gn/T/python-build.20170722122727.33068/Python-3.6.2/Lib/ensurepip/__init__.py", line 27, in _run_pip
    import pip
zipimport.ZipImportError: can't decompress data; zlib not available
make: *** [install] Error 1

記事があったのでリンクを張っておきます qiita.com

上記の記事で試してもうまくいかなかったためpyenvは一旦忘れることにしました。

homebrewでpython3をインストール

brew installであっさりインストール完了

ここまでの苦労は何だったのか。。。

PIPが動かない

続いてPIPを動かそうとしたら

kMBA:~ ksilver$ pip
-bash: pip: command not found

なるほど、ちゃんとインストールしないとね

kMBA:~ ksilver$ brew install pip
Error: No available formula with the name "pip" 
Homebrew provides pip via: `brew install python`. However you will then
have two Pythons installed on your Mac, so alternatively you can install
pip via the instructions at:
  https://pip.readthedocs.io/en/stable/installing/
kMBA:~ ksilver$ 

Macには既存のPython2が入っているためbrewではなくインストールガイドに従えとのこと。

リンク先のインストーラwgetしていざ実行!

kMBA:~ ksilver$ python3 get-pip.py
Requirement already up-to-date: pip in /usr/local/lib/python3.6/site-packages
kMBA:~ ksilver$ 

・・・・・えーなんでーあるって言われる事件

犯人探し

Pythonの情報を確認

kMBA:~ ksilver$ which python3
/usr/local/bin/python3
kMBA:~ ksilver$ python3 --version
Python 3.6.2

/usr/local/lib/python3.6/site-packages の参照は正しそうな気がする。。。

kMBA:~ ksilver$ ls /usr/local/lib/python3.6/site-packages/pip
__init__.py     _vendor         cmdoptions.py   download.py     locations.py    pep425tags.py   utils
__main__.py     basecommand.py  commands        exceptions.py   models          req             vcs
__pycache__     baseparser.py   compat          index.py        operations      status_codes.py wheel.py
kMBA:~ ksilver$ 

おるやん。。。。
何故かパスが通ってないのかなぁ

ここで閃き

kMBA:~ ksilver$ pip3

Usage:   
  pip <command> [options]

Commands:
...

しょうもないミスでした。

いやぁお騒がせしました。

TDD bootcampに行ってきました

TDD、なんて甘美で素晴らしい響きなんでしょうか。 というわけで7/1に大阪で開催されたTDD Bootcampの感想を書きたいと思います。

TDDとは

テスト駆動開発のこと….わからん まずテストコードを書いてから、プロダクトコードを書きましょうという思想。 テストファーストだとか言わます。 詳細はぐぐってください。

TDD Bootcampは座学と実習を通してTDDの入門学習を行う集まりです。

TDD Boot Camp(TDDBC) - TDDBC

品質テスト≠開発テスト

テストと聞くとプロダクトのリリース前に行うテストをイメージします。
しかし、これら品質の確認の為のテストとTDDで扱うテストは別物のようです。
ここを勘違いするとTDDの説明を聞いてもしっくりこないと思います。

TDDで扱うテストはプログラマが安心してコーディングを行うためのものです。
プログラマが安心するためにテストコードは2つの役割があるのだなと思いました。

テストコード=ゴールへの道標

TDDはRed → Green → Refancoringのサイクルで回します。
TDDの最大の特徴は、まず失敗するテストを追加して(Red)からプロダクトコードを追加/修正する(Green)という点です。
『Assert First』などとも呼ばれるこの原則はテストコードは道標の役割を持ちます。

作りたい製品にたいして、さしあたって達成すべきチェックポイント、それをテストコードという明確な形で見える化する。
目標達成におけるKPIに近い考え方だと私は思います。

遠すぎるゴールに対してチェックポイントを置いていくことで道を見失わないようにする。
様々な分野で見受けられるこのベストプラクティスはコーディングの世界にも通じるようです。

進むべき道先を照らすことでプログラマは安心して機能を追加する(攻める)事ができます。

テストコード=デグレ検出器

プログラマにとってシステムダウンの次に怖いのはデグレ
即ち、プログラムの変更により今まで使えていた他の機能が使えなくなること。

そもそもゴミコードがゴミのまま放置されるのは、

  • 「動いてるコードを触って壊れたら心配」
  • 「ゴミだけどとりあえず動いてるからそっとしておこう」

という保守的な考えによるもの。

TDDのテストコードは一度書くとユーザーが消すまでこまめに実行され続けます。
これによりデグレを起こしたら直ちに検出できる(守れる)ようになります。

デグレにすぐに気付ける体制があって初めて安心してリファクタリングをすることができます。

まとめ

TDDはテスト駆動と銘打っていますが、動くチェックリストという方が近い感覚です。
高度な自動化技術やJUnitなどのライブラリが目立ちますが、それは手間を省く周辺技術で、本質的には誰でも導入できるものです。
高度な技術的手法というより堅実な仕事の進め方と考えたほうが良いでしょう。

ちょっと気軽にTDD始めてみませんか?