ベスパリブ

ベスパもってないです。バイク買いました。

驚異のマジェント・マジェント伝説

なんとなくSBR読み返してたら気づいてしまったので。

1射目

左半身失調状態のジャイロたちをライフル銃で射撃。外す。

f:id:takeg:20180806022237j:plain

※撃つ直前にジョニィに反撃されて焦ったのかもしれない

2射目

ライフル銃で狼を撃つ。実は直撃しておらず、かすり傷。

f:id:takeg:20180806022246j:plain

※直前にジョニィの爪弾でライフル銃が傷ついていたので、そのせいで外したのかもしれない

3射目と4射目

左半身失調状態のジャイロたちをリボルバーで2回射撃。外す。

f:id:takeg:20180806015912j:plain

※逆に適当に投げたジャイロの鉄球が左肩に被弾している。そのせいで外したと思われる

5射目

4射目の直後、左半身失調状態のジャイロに射撃。腹部にヒット。

f:id:takeg:20180806015903j:plain

6射目と7射目

5射目の直後、激昂しながら左半身失調状態のジャイロたちに2回射撃。普通に外す。

f:id:takeg:20180806022303j:plain
本当に普通に外している

8射目(未遂1回目)

7射目の直後、ちゃんと両手で構えて撃とうとするも、ジャイロに反撃され防御する。

f:id:takeg:20180806022308j:plain

8射目(未遂2回目)

ジャイロの反撃を防御した後、悠長に会話していた後トドメを刺そうとするも再度反撃され被弾する。一時リタイア。

f:id:takeg:20180806022314j:plain

8射目と9射目

馬車に乗ってるスティーブン氏を射撃。胸部に2発命中するも、致命傷にはならず殺害に失敗する。

f:id:takeg:20180806022320j:plain

※スティーブン氏にわざわざ定規を持たせて遠近法を使って射撃したにも関わらず急所を外している

※サプレッサーを付けた銃で木製の扉越しに撃ったせいで威力が減衰したせいもあるかもしれない

※そもそも窓は空いていたので扉越しに撃つ必要はまったくないのだが

10射目

馬車の上からウェカピポを待ち伏せするも、射撃直前にバレて反撃される。 なんとかウェカピポの左肩に命中。

f:id:takeg:20180806022331j:plain

※わざと少しはずして撃ったらしい(どう見ても避けられている)。

11射目

水中でウェカピポに向けて発射。左頭部にかする。目を狙ったらしいが、左へ2センチそれる。 この直後リタイア。

f:id:takeg:20180806015827j:plain
なんだこの撃ち方

まとめ

戦闘中に直撃できたのは5射目と10射目のみ(10射目は戦闘前の不意打ちだが)。あとは非戦闘時のスティーブン氏に2発直撃。それ以外は完全に外すか、かすった程度。

驚くべきはジャイロたちが左半身失調状態の圧倒的有利な状況で一発しか当てられていないところ。なんだこいつ~。

こんなのと組まされたウェカピポかわいそう。

state machineの話(あるいはPython3での実装)

Statechart
このような記事を見つけました。
ステートマシン(state machine)実装のための本があることを初めて知りました。

ここで提案されている手法は、[* 状態変数を使うかわりに現在の状態を示す関数を使う]というものである。たとえば「あ」という状態は`あ()`という関数で表現し、「い」という状態は`い()`という関数で表現する。「あ」や「い」という状態の上位階層として「あ行」という状態が存在するので、それは`あ行()`のような関数で表現する。このように、[* あらゆる状態を関数として表現する]ところがミソである。

iPhoneフリック入力はこんな感じらしいです。はぇ~。

そういえば以前にPython3でstate machineを実装したことがあるので、そのときのやり方をメモって置きます。結構悩んで実装した記憶が…。

from enum import Enum

class StateMachine():
    class State(Enum):
        """ state machineの状態 """
        Start = 0 # 状態0(初期状態)
        S1    = 1 # 状態1
        S2    = 2 # 状態2
        S3    = 3 # 状態3
        S4    = 5 # 状態4

    def __init__(self):
        self.state = self.State.Start

    def update_state(self):
        """ state machineを更新する(状態遷移する) """

        if self.state is self.State.Start:
            """ 初期状態 """
            self.state = self.State.S1
            print("State: Start")
            return

        elif self.state is self.State.S1:
            """ 状態1 """
            self.state = self.State.S2
            print("State: S1")
            return

        elif self.state is self.State.S2:
            """ 状態2 """
            self.state = self.State.S3
            print("State: S2")
            return

        elif self.state is self.State.S3:
            """ 状態3 """
            self.state = self.State.S4
            print("State: S3")
            return

        elif self.state is self.State.S4:
            """ 状態4 """
            self.state = self.State.S1
            print("State: S4")
            return

実際に使うときは、ループを回して使います。

import time

if __name__ == "__main__":
    sm = StateMachine()
    while True:
        sm.update_state()
        time.sleep(1.0)

上記の実装の良いところを挙げると、
・state machineの実装がクラス内で完全に閉じている
・使うときはupdate_state()を呼び出すだけ
・引数を増やしやすい
・シンプル
くらいです。まあ特別なことはしていません。

実際に処理を実装するとわかるのですが、処理が長くなるとif文が長くなり可読性落ちるので、実際の処理はメソッド化するのが無難です。

if文の数が多くなると可読性が落ちたり、無駄な評価がされて遅いというデメリットが考えられるので、if文をディクショナリに書き換えればもっと良くなるかもしれません。試してないですけど。

あと、これはstate machineを実装する上で一般的に言える注意点だと思うのですが、状態を変更した後は(self.stateを変更した後は)すぐにreturnしなければいけません。さもなければ状態を追いかけることが難しくなります。以前、状態が変更された後も処理が続き、条件によってはさらに状態が上書きされ、そしてまた条件によっては上書きされ…というのが続き、最後にreturnされるstate machineを見たことがあるのですが(そしてそのプログラムのバグを追いかけていたのですが)、恐ろしくしんどいです。リーダブルコード7.5章にも書いてありますが、できることなら関数から早く返しましょう。

関数で複数のreturn文を使ってはいけないと思っている人がいる。アホくさ。

ちなみにPythonには既にstate machineを扱うライブラリがあるようです。独自実装で特殊なことする必要がなければこれを使うという手もあります。便利世の中~。
transitionsでステートマシンを扱う [Python]

ゲン、Gitに切れる

addコマンドの名前がむかつくんじゃ

おどりゃクソ森。「ステージする」んだからstageって名前のコマンドにせんか。

resetコマンドの名前がむかつくんじゃ

おどりゃクソ森。 「アンステージする」んだからunstageって名前のコマンドにせんか。
このresetコマンドが「ステージの取り消し」と「コミットの取り消し」を担当してるから初学者(わし)が混乱するんじゃ。--hard --softってなんじゃ。unstageコマンドとresetコマンドにわけんか。

checkoutコマンドで2つの異なった操作ができるのがむかつくんじゃ

・ブランチの切り替え
・ファイルを特定コミットの状態に戻す
この2つの操作が同じcheckoutでできるのが納得いかんのじゃ。
ブランチの切り替えはbranchコマンドでできると思ったんじゃがのう。ちがうんか。
というかgit reset --hard [commit]とgit checkout [commit]は何が違うんじゃ なにっ インデックスに追加したファイルが元に戻るかどうか? バカタレーッ それこそオプションで挙動を変えるべきで、コマンドを変えることないじゃないか 落ち着けあんちゃん 確かに混同しやすいがそもそもcheckoutとresetは別々の意味のコマンドで、たまたま似たような操作ができるだけじゃ やかましいっ! ヒッ おどりゃトサカにきたぞ隆太 わしはもうGitは使わん なにっそれは本当か 正気じゃないんじゃないか アホウわしゃ正気じゃ そもそもGitなんてものはアメリカがわしら日本人から和の心を奪うために戦後に導入した制度なんじゃ バージョン管理は昔ながらのコピーアンドペーストで良かったんじゃ わしはフォルダに日付を付けて管理する方法に戻すぞ よさんかゲン やめてーっ さよならGitまた来てコピペ ジャンジャンジャガイモサツマイモ…

Gitの勉強の仕方

Gitを初めて触ったのが2014年の1月なので、それから4年が経過しました。毎日Gitに触っているわけではないのでGit歴を単純計算できませんが、大体そのくらい触っているというわけです。

その間に、Gitは何回も挫折しました。重要なファイルを何回も消しました。エラーが修正できなくてリポジトリを何回も作り直しました。最近になってようやくGitを人並み程度に扱えるようになりました。

どうしてGitを習得するのにここまで時間がかかったのかと回顧してみると、おそらく勉強の仕方がまずかったのだなと思います。習うより慣れろの精神で使ってたらわかる様になると思っていましたが、そういうわけでもありませんでした。というかわかってないのに使うので、結果ファイルを消したりしてしまうわけです。そしてやる気が無くなるわけです。Gitはクソとか言い始めるわけです。

これはGitが苦手な人のための記事です。私は今でもGitが苦手なので偉そうなことは書けませんが、ここに書いてあることを意識して勉強しています、という自戒を込めての文章です。

Gitは難しいことを認める

Gitは難しい。
Gitは便利ではありますが、簡単ではない。

Gitチートシートの図を覚える

「習うより慣れろ」は大事ですが、最低限の知識は必要です。
最低限の知識とは何かを具体的に言うと、Gitチートシートに載っているものすべてです。
GitチートシートというのはGit Commands and Best Practices Cheat SheetAtlassian Git コマンド チートシート の日本語版をダウンロードしようなどです。私はGit ポケットリファレンスチートシートを使っています(改訂新版より以前のものはチートシート載ってない?)。

「共有リポジトリ」「ローカルリポジトリ」「インデックス」「作業ツリー」は必須の知識です。これらの用語と意味は覚えます。図のフローはしっかり覚えます。

代表的なコマンドが何をするものなのかも覚えます。addコマンドなら「作業ツリーの変更をインデックスに保存する」といったような理解です。当然ですが、自分が打ったコマンドが何をしているのか頭の中でイメージできるようになる必要があります。イメージしながらコマンドを打つ必要があります。慣れないうちはチートシートを見ながら、「今自分はここの操作をしてるんだ」とイメージしながらコマンドを打ちます。さもなければ、ファイルは雲散霧消するものと心得ます。

ブランチを切ったらどういう流れになるのか。mergeやrebaseしたらどういうコミット状態になるのか。これも最低限把握します。細かいfast-forwardやNon-fast-forwardなどは後で良いと思います。
チートシートに掲載されているコマンドは全て理解しているようになりましょう。

暗記するのは大変です。なので実際に手を動かして覚えるのが重要です。適当なリポジトリを作成し、消えても困らないファイルに対して思う存分addしてcommitしてbranch切ってfetchしてmergeまたはrebaseしてpushしましょう。イメージしたとおりのファイルの状態になっているか、コミットの流れになっているかを確認しながらやります。

本を買う

適当なサイトを参考にするのも良いですが、個人的にはGitポケットリファレンスをおすすめします。序文で「私はGitが嫌いでした」で始まる本書は私に合っていた気がします。技術評論社の回し者みたいですが、ポケットリファレンスの良いところを以下に示します。

ポケットリファレンスの良いところはコマンドの説明が充実しているので、「このコマンドって何するコマンドなの」「どんな書き方すればいいの」「こういうとき何のコマンド使えばいいの」というときに辞書的に参照しやすく、非常に便利です。

もうひとつ良いところは、情報ソースが統一されているということです。つまり、わからないときにポケットリファレンスを参照するようにすれば、以前参照した情報と、今回参照した情報が一致するので、記憶に残りやすいという点です。適当にググってもコマンドの使い方は出てきますが、人によってコマンドの書き方は様々だったり、以前参照したサイトがヒットしなかったりします。「以前となんかやり方違うような?まいっか」だとあまり記憶に残らないので、そういう「情報ソースを統一する」という意味で適当な本を買うというのは有用でした。

自分でまとめる

ポケットリファレンスがあれば良いかというとそうでもなくて、例えばド忘れしたときに毎回ポケットリファレンスを参照するのは面倒くさく感じます。まれによく使うコマンドなどは、自分なりにQiitaなりブログなりGmailの下書きなりにまとめておくと良いです。「こういうとき何のコマンド使うんだっけ」というとき、都度ググるよりかは、自分のやり方をメモしたものを参照したほうが、頭に残りやすくて良いです。


以上です。

Raspbian, Apache2でダイジェスト認証

Raspbian 8.0
Apache 2.4.10(Raspbian)

ダイジェスト認証に必要なモジュールを有効化する

$ sudo a2enmod auth_digest
$ sudo a2enmod authn_file
$ sudo a2enmod authz_user

Apache2の設定をする

$ sudo vi /etc/apache2/apache2.conf

(以下を適当なところに追加)

# Digest Authentication

<Directory /myproject/www/>

        AuthType Digest

        AuthName "DigestZone"

        AuthUserFile /myproject/www/.htdigest

        Require valid-user

</Directory>

ダイジェスト認証のファイルを作成する

$ sudo htdigest -c /myproject/www/.htdigest "DigestZone" root

Adding password for root in realm DigestZone.

New password:root

Re-type new password:root

Apache2の再起動

$ sudo service apache2 restart
$ sudo systemctl daemon-reload

Raspberry Pi のSDカードを縮小する方法

32GBから16GBのSDカードに縮小したかった。
たくさん記事はあり色々試しましたが、結局以下の方法でうまくいきました。

raspberry piのイメージファイルを小さな容量のメモリーカードにコピーする方法

EaseUS ToDo Backup Freeを使う方法も試しましたが、不良セクタの書き込み失敗エラーが解消できませんでした。

Gitコマンド備忘録

この記事は都度更新します。

branch

ブランチを確認する
*が付いているものが現在のブランチ

ブランチの確認

git branch
* master
  branchA
  branchB

clone

git clone [リポジトリのURL]

で、リポジトリのフォルダをダウンロードできる。
cloneとダウンロードって何が違うの?と思っていたが、おそらく何も違わない。

checkout

checkoutでできることは大きく2つ。
・ブランチの切り替え
・ファイルを特定の状態に戻す
上2つがなんで同じコマンドなのかは不明。Gitのむかつきどころ。

ブランチの切り替え系

ブランチを切り替える
git checkout [ブランチ名]

ブランチ名の確認の仕方は、branchコマンドの項目を参照。

・例1

git checkout branchA

ブランチをbranchAに切り替える

・例2

git checkout -f branchA

ブランチを強制的にbranchAに切り替える
作業ツリーとインデックスの変更は破棄される

ブランチ作成と切り替えを同時に行う
git checkout -b branchC

あんまり使ったことない

ファイルを特定の状態に戻す系

ファイルを特定のcommitの状態に戻す

https://qiita.com/ritukiii/items/5bc8f74dbf4dc5d1384c

git checkout [コミット番号] [ファイルパス]

この操作は非常に使える。
例えばバグが発生したとき、どこのコミットからバグが発生したか調べるときに、ひとつひとつコミット番号を戻しながら使ったりする。

・コミット番号の調べ方
GitHubのページでファイルを開けばコミット番号が書いてある。
あるいはlogコマンドの項目を参照。

・例1

git checkout [コミット番号] hoge.txt

hoge.txtが[コミット番号]のときの状態に戻る

・例2

git checkout [コミット番号] .

全てのファイルが[コミット番号]のときの状態に戻る

・ 例3

git checkout HEAD hoge.txt

hoge.txtの現在の変更を破棄して、最新状態に戻す。

・例4

git checkout HEAD^ hoge.txt

hoge.txtを1つ前のコミットの状態に戻す。

log

コミット履歴を確認する

> git log
commit c4adc034f65a53d85b3fa8270e0e8239e4d45518
...

commit 8601edcfa95c72bf10c3b4479b59f1ffe488c5a0
...

ファイルのコミット履歴を確認する

$ git log --oneline hoge.txt
13aed9b (HEAD -> master, origin/master) updated
c4adc03 fix: 
8601edc fix: coding: utf-8

checkoutでファイルを特定のコミット状態に戻すときに便利

全体のコミット履歴を確認する

$ git log --oneline
13aed9b (HEAD -> master, origin/master) updated
c4adc03 fix:
ce5dd9d Update

stash

作業ツリー(とインデックス)の変更を、コミットせずに一時的に保存する。
スタッシュと呼ばれる領域に一時的に保存する。

作業ツリーとインデックスを一時的に保存する

$ git stash

作業ツリーを一時的に保存する(インデックスは保存しない)

$ git stash --no-keep-index

メッセージ付きで一時的に保存する

$ git stash save "message"

$ git stash save "fix: Change version"

スタッシュに保存したものの一覧

$ git stash list
stash@{0}: On master: fix: Change version
stash@{1}: WIP on master: 37c38ad fix: バグを修正

上に行くほど直近のスタッシュ。

スタッシュに保存した内容を作業ツリーに戻す

$ git stash apply <stash>
(例)
$ git stash apply stash@{0} 

スタッシュを指定しない場合、直近のスタッシュに戻る
技術評論社の ポケットリファレンス には「スタッシュを指定しない場合、直近のスタッシュが削除される」と書いてあるが、実際にはそのような動作はしなかった)

スタッシュに保存した内容を作業ツリーに戻した後、そのスタッシュを削除する

$ git stash pop <stash>
(例)
$ git stash pop stash@{0} 

使い方はapplyと同様。どちらか覚えれば良い。

スタッシュの削除

$ git stash drop <stash>
(例)
$ git stash drop stash@{0}

スタッシュを指定しない場合、直近のものが削除される

スタッシュの全削除

$ git stash clear