ナルミヤの備忘録(仮)

ナルミヤが学んだことなどを書き記していくブログ(方向性模索中。)

gitリモートブランチの削除

メモがわりに

コマンド

端的にいうとこれ

git push origin :hoge

これでリモートブランチが消せるのには理由がある。
では、なぜこれで消せるのか見て行ってみよー。

理由

まずはpushから

上のコマンドにはpushが使われてるが、pushの使い方といえば、

git push origin hoge

これで、ローカルブランチのhogeがリモートのorigin/hogeにpushされる。

git pushのちゃんとした?記法

だけど、これは実は省略表現で、ちゃんとかくと

  • ちゃんとした書き方 git push origin hoge:hoge

つまり、ちゃんとした表現は

git push ローカルブランチ名:リモートブランチ名

となる。

そしてリモートリブランチの削除へ

上を踏まえると、リモートブランチを削除するコマンド、

git push origin :hoge

は空のブランチをリモートのhogeに押し付けてる→hogeの中身が空になる→hogeブランチが削除される、という仕組み

これで原理?から理解できたね、よかったね

参考

今さら聞けないgit pushコマンド

リーダブルコードを読む

「リーダブルコード」を読んでまとめたもの
読むページが進んだら更新(予定)

1章 理解しやすいコード

読みやすさの基本定理

  • コードは他人が最短時間で理解できるように書かなければならない。

この定理が基本的な考えかた。詳しくいうと

  • 他人とは、数週間後の自分だったりする
  • コードが短いだけが正義ではない
  • 「このコードは理解しやすいだろうか?」というのを念頭にコードを書いたり修正したりする。

2章 名前に情報を詰め込む

情報の詰め込んだ名前のつけるpointは以下の6つ

  • 明確な単語を選ぶ
    getなどの「空虚な」言葉ではなく、ページを取ってくるならdownloadPageなどの方が良い。他にも類語辞典を使って「豊かな」単語を使う。しかし、気取った言い回しをするよりは明確で正確な名前を。
  • 汎用的な名前を避ける(あるいは使う状況を選ぶ) tmpやretvalなどの「空虚な名前」よりも、エンティティうあ値の目的を表した名前を選ぶ。 例えば、2乗の和を返す関数の戻り値なら、sum_squaresにするなど。
    こうするとバグも見つけやすくなる。

    • tmpについて 目的が情報の一時的な保管でかつ生存期間がわずか数行であるときはtmpで。「この変数には他に役割がない」という明確な意味が伝わる。
    • ループイテレータについて(for i in list のiのこと) イテレータが複数ある時には、インデックスにfor member_i in membersなどのなまえをつける。miでもいい。
  • 抽象的な名前よりも具体的な名前を使う

    • 名前は具体的なものにする。
  • 接尾辞や接頭辞を使って情報を追加する

    • 名前は短いコメントのようなもの。絶対に知らせなきゃいけない大切な情報は名前に込める。
  • 名前の長さを決める

  • 名前のフォーマットで情報を伝える

PythonでCSVファイルを読み込んでグラフ化する

実験レポートで、実験結果をcsvファイルでまとめて、それをグラフ化するという作業をしたため、おば描きとしてまとめておく。

使用するパッケージ?

  • pandas
  • matplotlib
  • matplotlib.pyplot
  • numpy

手順

  1. pandasでcsvを読み込む
  2. 読み込んだもののデータ型を確認。(データ型がintかfloatでなかったら、intかfloatに変更)(pandasのastypeメゾット)
  3. パラメータに対して昇順にそーと(pandasのsort_valueメゾット)
  4. pyplotでグラフを描写
  5. pyplotをpngファイルで保存

+α - 対数をとる(numpy)

なお今回は、Jupyter上で実行した。
以下のものがソースコードの一例。

import pandas as pd
import numpy as np
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
%matplotlib inline


data = pd.read_csv("a2.csv")

lux = data['LUX'].astype('int64')
data = data.sort_values(by="LUX", ascending=True)

log_data = np.log(data)

# グラフ作成
plt.figure(1)
plt.plot(log_data['LUX'],log_data['resistance(o-mu)'],marker="o")

#グラフの軸
plt.xlabel('$\log L(\log \mathrm{Lux})$')
plt.ylabel('$\log R(\log \mathrm{\Omega})$')

plt.savefig('A2result.png')  #pngファイルとして保存
plt.show()

以下具体的に、一つ一つの手順を見ていく。

1. pandasでcsvを読み込む

import pandas as pd
data = pd.read_csv("a2.csv")

csvファイルを読み込む。

f:id:buddasls54:20180508224545p:plain

2. 読み込んだもののデータ型を確認。(データ型がintかfloatでなかったら、intかfloatに変更)

データ型の確認は、

data.columns

でデータラベルを確認して、 f:id:buddasls54:20180508225510p:plain

data['LUX']

もしくは

data.LUX

で確認する。 f:id:buddasls54:20180508225515p:plain もしくは

data_col = data.columns
data[data_col[0]] #data[data_col[ラベル番号]]

でデータ型は確認できる
データ型の変更は以下のコマンド

data['LUX'].astype('int64')

データ型の指定はdata['LUX'].astype('int')やdata['LUX'].astype('float')でも可能

3. パラメータに対して昇順にソート

data.sort_values(by="LUX", ascending=True)

で、LUXについて、昇順でソートされる。降順にしたければ、ascending=Flaseにすれば良い(多分) f:id:buddasls54:20180508231036p:plain

4. pyplotでグラフを描写

import matplotlib.pyplot as plt
%matplotlib inline

data_col = data.columns

#グラフの作成
plt.figure(1)
plt.plot(data[data_col[0]],data[data_col[1]],marker="o")

#グラフの軸
plt.xlabel(data[data_col[0]].name)
plt.ylabel(data[data_col[1]].name)

#グラフ表示
plt.show()

f:id:buddasls54:20180508233133p:plain

5. pyplotをpngファイルで保存

import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
%matplotlib inline

data_col = data.columns

#グラフの作成
plt.figure(1)
plt.plot(data[data_col[0]],data[data_col[1]],marker="o")

#グラフの軸
plt.xlabel(data[data_col[0]].name)
plt.ylabel(data[data_col[1]].name)

#グラフ保存
plt.savefig('A2result.png')

f:id:buddasls54:20180508234124p:plain

参考にしたページ

pandasについて

pyplotについて

numpyについて - 【Python入門】numpyで計算をしてみよう - NumPyの数学関数・定数まとめ

numpy×pandasについて

[プラス]lamda式について

SQLインジェクションについて

ば先メモをこちらの方で。
学習内容が進むたびに随時追加予定(必ず追加するとは言ってない)。

1. SQLインジェクションの原因

1.1 SQLクエリの構成

SELECT a,b,c FROM atable WHERE name='YAMADA' and age>=20

この文の中には、

がある。

1.2 リテラルとは

リテラルとは、定数のこと。リテラルには、

がある

1.3 SQLインジェクションに対する脆弱性の原因

安全なSQLの呼び出し方曰く、

SQL 文の文字列リテラルをパラメータ化しているときに、そこに別の SQL 文の断片を含ませることで、元の SQL 文の意味を変更できる場合がある。これが SQL インジェクションの脆弱性である

1.4 文字列リテラルに対するSQLインジェクション

例えば、SQLクエリにPHPの変数$idを使って以下のようにSQLを呼び出す時、

$q = "SELECT * FROM atable WHERE id='$id'";

この時、$idを以下のようにしてみる。

';DELETE FROM atable--

そうすると、実行されるクエリは、

SELECT * FROM atable WHERE id='';DELETE FROM atable--'

となり、SELECT 文の後ろに DELETE 文が追加され、データベースの内容がすべて削除される結果となる。(SQLでは--以降はコメントとして無視される)

1.5 数値リテラルに対するSQLインジェクション

先ほどと同様に、

$q = "SELECT * FROM atable WHERE id=$id";

とした時、

0;DELETE FROM atable

とすると、

SELECT * FROM atable WHERE id=0;DELETE FROM atable

となり、テーブルからデータが消える。

1.6 SQLインジェクションの例

  • エラーメッセージによる漏洩(リテラルにcastを入れる)
  • UNION SELECTによる漏洩(リテラルにUNION SELECTを入れる)
  • SQLインジェクションによる認証回避

    $id = $_POST['id']; $pwd = $_POST['pwd']; $sql = "SELECT * FROM users WHERE id='$id' and pwd='$pwd'";

    において、

    $_POST['pwd'] = ' or 'a' ='a

    とすると、クエリは、

    SELECT * FROM users WHERE id='[入力した任意のID]' and pwd='' or 'a' ='a'

    となり、WHERE句が常に成立するためにログインできてしまう。

  • SQLインジェクション攻撃によるデータ改ざん(リテラルにupdate文を入れる)

1.7 その他SQLインジェクション攻撃

  • OSコマンドの実行
  • ファイルの読み出し
  • ファイルの書き出し
  • HTTPリクエストにより他のサーバーを攻撃
  • データベース中の表名・列名の調査方法も...

2. 対策

2.1 対策の基本

対策の基本としては以下の2点をクリアしてるべき。

  • 文字列リテラルに対しては、エスケープすべき文字をエスケープすること
  • 数値リテラルに対しては、数値以外の文字を混入させないこと

そのために、「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」によると、SQLインジェクション対策は以下のよう

  • プレースホルダーにによってSQL文の組み立てる
  • アプリケーション側でSQL文を組み立てる際に、リテラルを正しく構成するなどSQL文が変更されないようにする

後者は全ての場合を対策するのが難しいので前者の対策を強くおすすめするらしい

2.2 プレースホルダーについて

プレースホルダーには以下の2種類ある。

以下、引用

2.2.1 静的プレースホルダ

 静的プレースホルダは、JIS/ISO の規格では「準備された文(Prepared Statement)」と規定されている。これは、プレースホルダのままの SQL 文をデータベースエンジン側にあらかじめ送信して、実行前に、SQL 文の構文解析などの準備をしておく方式である。  セキュリティの観点で、最も安全である。静的プレースホルダでは、SQL を準備する段階で SQL 文の構文が確定し、後から SQL 構文が変化することがないため、パラメータの値がリテラルの外にはみ出す現象が起きない。その結果として、SQL インジェクションの脆弱性は生じない。

2.2.2 動的プレースホルダ

 動的プレースホルダは準備された文(Prepared Statement)とは異なり、プレースホルダを利用するものの、パラメータのバインド処理をデータベースエンジン側で行うのではなく、アプリケーション側のライブラリ内で実行する方式である。  セキュリティの観点では、プレースホルダを用いたバインド処理によってパラメータの値の埋め込みがライブラリで機械的に処理されることから、文字列連結による組み立てに比べてアプリケーション開発者のミスによるエスケープ漏れを防止できると期待される。  ただし、動的プレースホルダは静的プレースホルダとは異なり、バインド処理を実現するライブラリによっては、SQL 構文を変化させるような SQL インジェクションを許してしまう、脆弱な実装のものが存在する可能性は否定できない。

2.3 実際の対応

PHPの言語を用いている。

2.3.1 数値リテラルに対する対処

入力されたものが数字か否かでインジェクションを防ぐ。
なお、POSTやGETで得られた値は、str型なので単に、gettype($_POST['userid'])=="integer"としてもfalseになることに注意。

$id = $_POST['userid'];
if (preg_match("/^[0-9]+$/",$id)) {
    $_SESSION['userId'] = $id;
} else {
    header("Location:http://localhost/lessons/vendingMachine/vendingHome.php?id_err=1");
    exit();
}

リダイレクト先でisset($_GET['id_err'])ならIDエラーであると表示するならびに、そもそも、その際はSQL文を実行しないことでSQLインジェクションを回避する。

2.3.2 文字リテラルに対する対処

プレースホルダー?を使う。

参照

Pandocを用いてMacで数式混じりのmarkdownをpdfやTeXに変換する

動機

最近、ノートをデジタル化したかったので、Markdownでノートを取り始めたのだが、Atommarkdown-pdfでは数式混じりのMarkdownの数式部分が数式になってくれない。
で、「atom markdown 数式 pdf」で検索して出てきたPackage、"markdown preview enhanced"を用いてpdf化しようと思ってもなんか、

Error: Command failed: pandoc -f markdown+tex_math_single_backslash -o /Users/m-narumiya/Desktop/dev/lesson/Computing_system/2018-04-13.pdf --pdf-engine=pdflatex pandoc: unrecognized option `--pdf-engine=pdflatex' Try pandoc --help for more information.

というエラーを吐き出して、pdfになってくれない。ので、terminalで直接pandocをいじってやろうと思いたった。 エラー画面↓
f:id:buddasls54:20180420072601p:plain

環境

macOS 10.13.3 (17D47)

実際の手順

  1. インストールする *事前に、HomebrewとXCodeが必要

brew install lua pandoc pandoc-crossref

  1. Markdownファイルの頭の方に、ヘッダーっぽいものを書き込む(TeX化する人はしなくて良い)
    例、

```

---
title: "計算システム論第一"
author: "narumiya"
date: 2018/04/13
output: pdf_document
---

```

  1. pdf化もしくはtex化したいファイルのあるディレクトリまで移動して、
  2. pdf化したい人は以下のコマンドを実行

    pandoc -F pandoc-crossref 2018-04-13.md -o 2018-04-13.pdf -V documentclass=ltjsarticle --latex-engine=lualatex --template=mytemplate.tex --highlight-style zenburn --toc -N

  3. TeX化したい人は以下のコマンドを実行。

    pandoc 2018-04-13.md -o 2018-04-13a.tex

    なおこれで生成されるのは \begin{document}\end{document}の中身のみなので、以下のmanuscript.texファイルを作ってそれにinputする形の対応を取る。

\documentclass[11pt,a4paper]{jarticle}
\usepackage{amsmath,amssymb}
\usepackage{bm}
\usepackage{graphicx}
\usepackage{ascmac}

\title {計算システム論第一}
\author {narumiya}
\date{2018/04/13}

\begin {document}
\maketitle
\input {2018-04-13a}
\end{document}

以上!pandocのオプションの意味?知らん!ググれ!!!()

参考にしたページ

追記 2018/12/04

上記の設定だけだと、html記法も含んだmarkdownがPDF化できなかったので、html記法も含んだmarkdownがPDF化についてここにまとめる。
こちらは、ちょっとしたmarkdownをPDFに直すときに使える。

参考にしたページ

PDFにするmarkdownファイルの例

次のようなplan.mdというmarkdownファイルをpdfにしたいとする。(これは、実際に自分たちの実験で用いた計画書)

# 知覚の計測と解析 『色と重さの知覚』
## 目的
視覚刺激に寄って重さの知覚にどのような影響が及ぼされるかを測定,解析する.
人は色に対して重さのイメージを持つことがあるため,同じ形状の物体を持ってもその物体の色が異なると知覚する重さは異なってくるかもしれない.

今回の実験では明度が重さの知覚に与える影響を測定することに焦点を絞って,グレースケールで色を変化させる.明度が低くなればなるほど(黒に近づくほど),実際の重さより重く感じると仮説を立てる.

## 実験方法
### 準備
同一の形状のペットボトルを5本用意し,少しずつ異なる水の量を入れそれぞれで重さを変える.ペットボトル外側に中身が見えないように紙を巻きつける.5枚の紙はそれぞれ白から黒までグレースケールで明度を変えたものとする.

---
<div style="background: #000000;">
a
</div>
<div style="background: #444444;">
a
</div>
<div style="background: #888888;">
a
</div>
<div style="background: #BBBBBB;">
a
</div>
<div style="background: #FFFFFFF;">
a
</div>
---

↑グレースケールのイメージ

5本のペットボトルはをランダムにあらかじめ配置しておく。

### 実験
被験者に配置された5本のペットボトルを、左か順にそれぞれ持たせ,ペットボトルの知覚した重さで順位をつけさせる.


### 解析
実際の重さより軽く知覚される色と、重く知覚される色との分類をする.手法としては、知覚された順位から実際の順位を引いて得られたデータの正負によって分類を行う.  
色によって、重さ知覚が、実際の重さよりも軽く感じるのか、もしくは重く感じるのかを解析する.

実際の手順

では、これをPDFにしていく。(ちなみに今までのようになると、エラーは出ないが、グレースケールの図が出てこない)

  1. homebrewでwkhtmltopdfのインストール。(デフォルトで数式交じりじゃなければこうするらしい。)

brew cask install wkhtmltopdf

  1. そして、次を実行

pandoc plan.md -f markdown -t html5 -o plan.pdf --from markdown-yaml_metadata_block

なぜか、

pandoc plan.md -f markdown -t html5 -o plan.pdf

とやっても

[pandoc warning] Could not parse YAML header: could not find expected ':' "source" (line 16, column 1)

とワーニングが出るだけで、変換できなかった。オプションの意味なぞ知らん!!()