Apache2.2の設定
久しぶりにやったので、CentOS6.9でやりました... ipもよしなにお願いします。 2017年にApache2.2で申し訳ない
Apache2.2の設定
CentOS6系の設定を想定なのでApache2.2です。(古いね)
- 以下内容
VirtualHostの設定をしてドメインにアクセスできること 名前ベースの仮想ホストで複数のホスト名をつける SSL通信ができること
Apacheインストール
インストール
# yum install httpd # httpd -version Server version: Apache/2.2.15 (Unix)
自動起動の設定
# chkconfig --list |grep httpd httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig httpd on # chkconfig --list |grep httpd httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Apache設定ファイル
全体の設定と範囲を指定した設定の2つあります。 この範囲を「セクションコンテナ」といいます。 セクションコンテナの中で設定した項目はセクションコンテナ内だけの設定になるのです。
セクションコンテナの種類
〜 - ディレクトリを示す
〜 - ファイルを示す
〜 - URLを示す
Apacheの設定ファイルは、行毎に「ディレクティブ」と呼ばれる設定内容を記述します。 Apache2.2と2.4では記述の仕方が違うので設定ミスに注意が必要。 2.4使うならNginxを使ったほうがいいかも。。
ディレクティブの大文字小文字の区別はされません。
優先順位は
編集が終わったら設定ファイルの書式が間違っていないかを確認するようにしましょう。
# service httpd configtest Syntax OK
名前ベースの仮想ホスト
リクエストヘッダ内で指定されているHost:ヘッダーの情報からアクセス先のホストを識別できる
VirtualHostの設定
設定をスッキリさせたいので、conf.d配下に vhosts.confというVirtualHost専用の設定ファイルを作りました。 VirtualHostで指定したIPアドレスに一致した場合のみ設定が適用されます。
# cat conf.d/vhosts.conf # 仮想ホストのIPアドレスを指定(Apache2.4では不要) NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin sysadmin@test1.jp DocumentRoot /var/www/vhosts/www.apachetest1.jp ServerName www.apachetest1.jp </VirtualHost> <VirtualHost *:80> ServerAdmin sysadmin@test1.jp DocumentRoot /var/www/vhosts/www.apachetest2.jp ServerName www.apachetest2.jp </VirtualHost>
DocumentRootも作っておくます。 index.htmlも置いておきました。
# mkdir /var/www/vhosts/www.apachetest1.jp/ # cat /var/www/vhosts/www.apachetest1.jp/index.html apachetest1 is OK # mkdir /var/www/vhosts/www.apachetest2.jp # cat /var/www/vhosts/www.apachetest2.jp/index.html apachetest2 is OK
動作確認してみましょう。 Hostヘッダーを指定してcurlコマンドを実行すると見事index.htmlの情報をとってこれました;-)
# curl -H 'Host: www.apachetest1.jp' 192.168.33.111 apachetest1 # curl -H 'Host: www.apachetest2.jp' 192.168.33.111 apachetest2
Apache再起動時に以下のメッセージが出たので、hostsに記載。localhostで名前解決させればよさそう。
[root@www ~]# service httpd restart
Stopping httpd: [ OK ]
Starting httpd: httpd: apr_sockaddr_info_get() failed for www.apachetest1.jp
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[ OK ]
# vim /etc/hosts
# cat /etc/hosts
127.0.0.1 www.apachetest1.jp localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 www.apachetest1.jp localhost localhost.localdomain localhost6 localhost6.localdomain6
[root@www ~]# service httpd restart
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
QUIZ:ブラウザでindex.htmlの中身を確認したい場合はどうすればいいでしょうか?
SSL通信
let's encryptはローカルドメインには使えんので、今回はおれおれ証明書で！ 本番環境ではlet's encryptもしくはverisignやcybertrustやrapid-sslなど商用のCAを使ってください！
商用CAもCSRをCAに送って、入金して、証明書がもらえたら、よしなに設定の流れです。
SSL化する理由はなんでしょうか
- データの改竄防止
- データ盗聴防止
- CA(認証局)による認証によって、本物であることを証明する
何が必要でしょうか
てなわけでインストール
# yum install -y mod_ssl openssl # httpd -M | grep ssl Syntax OK ssl_module (shared)
OpenSSLコマンドで以下のファイルを用意します。 複数ドメインを持つ場合は命名規則を立てたほうがよいですね。 CommonName.作成日.ファイルタイプなど
鍵の置き場所はmod_sslをインストールしたらデフォルトはconf.d/ssl.confになると思います。 また、443ポートで受けます。
# grep SSLCert conf.d/ssl.conf # Point SSLCertificateFile at a PEM encoded certificate. If SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key # grep Listen conf.d/ssl.conf Listen 443
今回はvhosts.confに設置場所を以下に指定してそこに置いてみましょう。
mkdir /etc/httpd/conf/ssl # vim vhosts.conf <VirtualHost *:443> ServerName www.apachetest1.jp DocumentRoot /var/www/test1 SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key </VirtualHost>
デフォルトのssl.confでSSLEngine onはコメントアウトしておきましょう~~
# grep SSLEngine /etc/httpd/conf.d/ssl.conf # SSLEngine on
上のコメントアウトをしなかったら、以下のエラーメッセージが出てApacheが起動しなくなりました..
[error] Illegal attempt to re-initialise SSL for server (theoretically shouldn't happen!)
秘密鍵の作成
# openssl genrsa -out server.key 2048
genrsa: RSA形式の秘密鍵を作成 -out 秘密鍵: 秘密鍵の名前指定 2048: 2048バイト長の鍵を作成
CSR作成
今回はwww.apachetest1.jpだけHTTPS化
# openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus .........................................+++ ...+++ e is 65537 (0x10001) [root@localhost ssl]# openssl req -new -sha256 -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:JP State or Province Name (full name) []:Tokyo Locality Name (eg, city) [Default City]:Shinjuku-ku Organization Name (eg, company) [Default Company Ltd]:Default Company Ltd Organizational Unit Name (eg, section) []:section Common Name (eg, your name or your server's hostname) []:www.apachetest1.jp Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
CommonNameとbit長など間違いないか確認
# openssl req -in server.csr -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=JP, ST=Tokyo, L=Shinjuku-ku, O=Default Company Ltd, OU=Technology, CN=www.apachetest1.jp
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ca:d9:de:81:97:43:ff:21:d9:4b:7c:26:50:e1:
- CSR作成の前に以下の項目を確認しておくといいです。
| DN フィールド | 説明 | 例 |
|---|---|---|
| Country Name (2 letter code) | 二文字の国名 | JP |
| State or Province Name (full name) | 都道府県 | Tokyo, Tokyo-to |
| Locality Name (eg, city) | 市区町村 | Shinjuku-ku |
| Organization Name (eg, company) | 会社名・組織名 | Default Company Ltd |
| Organizational Unit Name(eg, section) | 部署名 | Technology |
| Common Name (eg, YOUR name) | ドメイン名と同。間違えるとサイトみれなくなるので注意!!! | 「http://」や「https://」は入力不要 |
| www有りの場合 | www.example.com | |
| wwwなしの場合 | example.com | |
| サブドメインの場合 | japan.example.com | |
| サブドメイン無制限の場合 | *.example.com | |
| Email Address | メールアドレス | test@example.jp(値なしでも可) |
| A challenge password | 値なし | |
| An optional company name | 値なし |
証明書を作成し自己署名する
# openssl x509 -in server.csr -days 365 -req -signkey server.key -out server.crt Signature ok subject=/C=JP/ST=Tokyo/L=Shinjuku-ku/O=Default Company Ltd/OU=Technology/CN=www.apachetest1.jp Getting Private key
-req: 入力ファイルがCSRファイルであることを指定 -days: 証明書の有効期限 x509: X.509形式の証明書を作成 -signkey 秘密鍵ファイル: 自己証明書作成時に使用するオプション。秘密鍵ファイルを指定
iptablesの設定を行う
iptablesがインストールされていることを確認
# which iptables /sbin/iptables
iptablesのポリシー
以下の基本ポリシーを”DROP”(拒否)、”ACCEPT”(許可)のどちらかに設定します。
INPUT:サーバーに入ってくる通信のポリシー。基本ポリシーを”DROP”にして、あとで個別のポートに対して許可する設定にする。 OUTPUT:サーバーから出て行く通信のポリシー。基本ポリシーは”ACCEPT“にする。 FORWARD:受信したデータを他のサーバーへ転送する際に適用される設定。ここでは、特に転送するサーバーは無いので”DROP”。
現状設定されていないです。
# iptables -nvL --line Chain INPUT (policy ACCEPT 6332 packets, 472K bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 3243 packets, 254K bytes) num pkts bytes target prot opt in out source destination
以下の設定ファイルを作成していきます。 記載内容はさくらインターネットさんの記事を参照で
# vim /etc/sysconfig/iptables
設定を反映させます。
# service iptables restart iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: [ OK ]
22,53,80,443ポートが開放されていることが確認できました。
# iptables -nvL --line Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 2 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 3 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW 4 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F 5 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: up to 1/min burst 10 mode srcip htable-expire 120000 6 11 576 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 7 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 8 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 flags:0x17/0x02 limit: up to 1/min burst 10 mode srcip htable-expire 120000 9 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 10 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6 packets, 448 bytes) num pkts bytes target prot opt in out source destination
コマンドなら以下ですね
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
graceful再起動で反映
/etc/init.d/httpd graceful
https://www.apachetest1.jpにアクセスできることを確認
シェルスクリプト①
シェルスクリプトまとめ
一行目のおまじない
1行目にシェバンと呼ぶ、bashで動作しますよというおまじないがある。
#!/bin/bash
変数
変数宣言では空白文字列は入れてはだめ
変数=値
declareで宣言していない場合は値は文字列とされる。
値にスペースやタブを含みたい場合はシングル[ダブル]クォートでくくる
test='test test'
空白文字も格納できる
empty1=
or
empty2=''
変数を参照する場合は変数名の前に$をつける
$test
宣言していない変数を参照してもエラーにならず、空白文字として実行されてしまうので注意
環境変数
環境変数は親プロセスから子プロセスに引き継がれるもので、親プロセスのシェルで設定されていた環境変数の値は子プロセスにコピーされコマンドから参照可能。
printenvコマンドで環境変数の一覧を表示可能
環境変数の定義
exportコマンドで環境変数の定義が可能
CONFIG_NAME=test #変数CONFIG_NAMEを宣言 export CONFIG_NAME #exportで環境変数にする
or
export CONFIG_NAME=test #一行で変数定義と環境変数にするのもできる
特殊なシェル変数
ホームディレクトリの表示
- $HOME
カレントディレクトリの表示
- $PWD
ログインユーザーのログインシェル
- $SHELL
現在動作しているbashコマンドのフルパス
- $BASH
現在動作しているbashのバージョン情報
- $BASH_VERSION
現在実行しているシェルスクリプトの行番号を格納している。 いま何行目なのか出力できるのでデバックなどに使える。
- $LINENO
ロケールを指定
- $LANG
localeコマンドで現在設定されているロケールが確認できる
PATHは、シェルがコマンドを探すディレクトリを指定するための変数 ディレクトリは:で区切る コマンド検索パスと呼ばれ、左から順に探していく
- $PATH
コマンドを配置するためのディレクトリを作成した場合、コマンドを探すパスを追加したい場合、このPATHを使う。 以下は現在のパスに加えてホームディレクトリ配下のbinディレクトリからもコマンドを探すように指定
PATH=$HOME/bin:$PATH
IFSはシェルの区切り文字を指定するための変数 bashは文字列を単語に分割する必要があるときは、ここの文字列を区切り文字として使う。 通常はスペース、タブ、改行が設定されている。
$ echo "$IFS" |od -a 0000000 sp ht nl nl 0000004
odコマンドはファイルの内容を8進数で表示しますが、-aをつけると、制御文字などが文字の名前で出力される sp=スペース、ht=タブ、nlは改行
位置パラメータ
$1,$2のように1から始まる数値を名前に持つ変数で、 引数を参照することができる。
位置パラメータをすべて参照する場合は、$*や$@で可能
ダブルクォートでくくると動作が変わるので注意 "$@"=位置パラメータそれぞれが文字列として展開される "$*"=連結した一つの文字パラメータとして展開されてしまう。
なので$@を使ったほうが意図しない動作を起こさない。
特殊パラメータ
| 変数名 | 内容 |
|---|---|
| $# | 位置パラメータの個数 |
| $? | 直前に実行したコマンドの終了ステータス値 |
| $$ | 現在のプロセスのプロセスID |
| $! | 最後に実行したバックグラウンドコマンドのプロセスID |
シェルスクリプトに与えられた引数の個数
- $#
コマンド終了ステータス値 0は成功,0以外は失敗
- $?
現在のプロセスIDを表示
- $$
ユニークなファイル名を作る時にも使える
tempfile=/tmp/tempfile$$
バックグラウンドのプロセスIDを表示
- $!
バックグラウンドで実行したプロセスをkillするときに使える
データベース①
データベースについて必要なキーワードをまとめていきます。
トランザクションと同時実行制御
トランザクションについて
- 複数のクエリをひとまとまりにした処理で、commit時に処理を確定する
ACID
特性について、各頭文字それぞれ
Atomicity(原子性)
- データ操作が全部成功or全部失敗のどちらかになることを保証
Consistency(一貫性)
- データ操作での整合性が守られていること
Isolation(分離性もしくは隔離性、独立性)
- それぞれの処理が矛盾なく実行されること
Durability(持続性) * トランザクション処理が完了し、完了通知をユーザが受けた時点で、その操作が永続的となり結果が失われないこと
ANSI/ISO SQL標準
- アンシーは米国内の工業分野の標準化組織で、ベンダーに依存しないSQLのこと
ANSI/ISO SQL標準 が定義する分離レベルについて
非コミット読み取り(リードアンコミッテッド)
- 読込 のタイミングによっては読込がブロックされる場合がある時に選ぶとブロックしない
コミット済み読み取り(リードコミッテッド)
- 初回クエリ発行時にコミットされているデータを読み込み、その後は最新のクエリの実行開始時点でコミットされたデータを読む
再読み込み可能読み込み(リピータブルリード)
- 初回クエリ発行時にコミットされているデータを読み込み、その後も同じ結果セットが返され他のトランザクションがコミットしても、反映されない
直列化可能(シリアライザブル)
- 複数のトランザクション処理を順次実行させる
分離レベルの緩和によって起こる 3 つの現象について
ダーティリード
曖昧な読み取り
- あるトランザクションが以前読み込んだデータを再度読み込んだ時、2回目以降の結果が1回目と異なる現象
ファントムリード
- あるトランザクションを読み込んだ時、選択できるデータが現れたり、消えたりする現象
ロックタイムアウトとデッドロック
ロックタイムアウトについて
デッドロックについて
- ロックを保持したまま、お互いにロック済みのリソースに対してロックが必要な処理を行っても、状況が変わらない状態
テーブル設計の基礎
ルール
主キーについて説明できる
- 必ずレコードを一行に特定できる情報
識別子
- データを一意に特定できるID
正規形について
第1正規形について
- テーブルのセルに複合的な値を含んでいない
第2正規形について
- 全ての列が主キーのみに関数従属をもち、主キーの一部にだけ従属するという列は存在しない
第3正規形について
- 推移関数従属がある場合はテーブルを分ける。
ER 図
ER 図について
エンティティ
- 現実世界にある特定の型(クラス)
リレーションシップ
- エンティティ間に成立する1:多、多:1, 多:多の写像
バックアップとリカバリ
DBMS が持つ 3 つの仕組み
WAL について
DBのデータファイルへの変更を直接行わず、「ログ」として変更内容を記述した「ログレコード」を書き込み、同期する仕組み * ディスクに連続的に書き込むため、ランダムに書き込むよりパフォーマンスがいい * ディスクへの書き込み容量、回数を減らすことができる * データベースバッファを利用して、データベースのデータファイルへの変更を効率よく行える * MySQLではInnoDBログ
データベースバッファについて
データファイルへの入出力をデータベースバッファ経由に一本化 MySQLの場合
- 更新対象のデータを含むページが、バッファプールにあるかどうか確認され、なければデータファイルからバッファプールに読み込まれる
- 更新がバッファプールの当該ページに対して行われる
- 上記2の更新内容が、コミットとともにログに記録される。バッファプールで変更されたが、まだデータファイルに書き込まれていないページは、ダーティページとしてバッファプール内で扱われる
- ダーティページは後から適当なタイミングでまとめてデータファイルに書き込まれる(チェックポイント)
- チェックポイント以前のログファイルは不要になる。また、更新とともに手順が繰り返される
クラッシュリカバリについて
- WAL: 最後にコミットしたトランザクションの更新情報をもつ
- データベースバッファ:クラッシュにより内容はすべて失われる
- データベースファイル:最後のチェックポイントまでの更新情報を待つ
- ロールフォワード
リカバリ
PITR(Point-in-time recovery) について
- MySQL(バイナリログ)
- PostgreSQL(WALログ)
バックアップ 3 つの観点
ホットバックアップとコールドバックアップ
- ホットバックアップについて
- オンラインバックアップとも呼ばれ、バックアップ対象のデータベースを停止せず、稼働したままバックアップデータを取得する
- mysqldump
- コールドバックアップについて
論理バックアップと物理バックアップ
- 論理バックアップについて
- SQLベースのバックアップで、テキスト形式に準じるフォーマットでバックアップ
- 物理バックアップについて
- データ領域をダンプして、バイナリなどバックアップ
ISUCON7に参加〜そして敗北へ〜
ISUCON初参加しました。
敗北
お題は「isutaba」というチャットツール
画像はファイルに書き出して参照させるぞ！！ →できんな？
やったこと
当日まで
- 社内ISUCON(復習)
当日(まずはじめに)
- 複数台サーバまじ？構成確認
- DBのスキーマ情報確認
- show create table hoge;
- SELECT * FROM hoge LIMIT 10;
- myprofilerを入れる
- pt-query-digest (percona-toolkit)
- アクセスログ集計
Nginx
- worker_connections
- proxy_pass
- expires
MySQL
- INDEX追加
- (user.name)
- (message.user_id)
- (message.channel_id, message.created_at)
- (haveread.user_id, haveread.channel_id)
- (image.name)
アプリ改修
画像はファイルに書き出して参照させるぞ！！ → できんな？
やればよかった(忘れていた)
- ソケット通信化
やりたかったけど、できなかった
- 画像の脱DB化
- /icons/* を倒す
- N+1撲滅
きづけない(次回は気づけるようにしような)
- SELECT *の撲滅
- Cache-Control
- If-None-Match、If-Modified-Since、eTag
- 304
- /fetch
- JSONレスポンス
感想
FlaskとMySQLdbを使ってアプリかこうな やるべきこと気づいて、実装できず悶々して無力だった
PyCon2017 一日目のれぽーと
PyCon2017 一日目
後日に動画とslideがまとまってくれると嬉しい。
英語のセッションばかり聴いていたらとっても難しかった。 VOES 稼働後 after VOES launchが一番おもしろかったです。 VOESという音ゲーを開発している台湾の人のセッションで ゲームのbackend開発でDB周りやCDN、キャッシュ周りの話をしてくれました。 メンテナンスの話ではF○Oの48時間メンテナンスをネタにしたりもしていました。
Industrial Test Automation with Asyncioでは asyncioの実装例周りを実際に書いておきたいと思います。 3.6系を勉強するならnon-blockingIOとか使いたい。。 以外とpyramid使いがいた気がします。人数としてはすくないですが。 Tornadoの話は特に聞かなかったです。
そういえばアンケートではPythonでWEBアプリを書いている人は3割ほどでした。 PyConはデータサイエンティストの集まりと化しているようです。 そもそもプロダクション環境でPythonでアプリをリリースしている企業が少ないということなんでしょう。 PHPかRubyでアプリを書いて、分析基盤をPythonを使うという使い分けなのが多そう。
Keynote
Pythonは教育として使われる言語で、いろんな分野の人が使う共通言語になる データサイエンスはソフトウェア開発ではない。 解析に使うのはsoftware(ソフトウェア)なく、thoughtware(思考)である。 予測できることはほとんどない。「未来を予測する最もよい方法は、それを発明すること」byアランケイ ビジネスがオープンソースを好む理由。ベンダーロックインを防ぐ(特にデータ)。 また、自分たちの都合に合わせて変更、機能追加できる。 Pythonはレゴのようなもので組み立てていろんなものを作り上げることができる。
- Peter Wang
- Anacondaデータサイエンスエコシステムの製品エンジニアリングチームを率いている人。
- Over 20 Million Downloards
- Other Problebms in 2012
- Pythonは人気がある
- イブサンローランの香水のCMでIPython のプロンプトが出てくる
- Why Python for Data
- not system language but intended to teaching language for prototype
- Pythonにはいくつかの部族がある
- Analyst,Data Developer,programmerも使える共通言語
- Data Science ！＝Software Development
- Era of Data Literacy
- A Few Predictions
- 未来を予測する最もよい方法は、それを発明すること
- Open Source and Developers
- Pythonはレゴのようなもの
- ビジネスがオープンソースを好む理由。ベンダーロックインを防ぐ(特にデータ)。また、自分たちの都合に合わせて変更、機能追加できる。
- 解析に使う言語は'thoughtware'で'software'ではない
セッション
Industrial Test Automation with Asyncio
asyncio
- Industry use
- How to talk to N computers at the same time?
- Trying without Asyncio
- import socket
- とても長い、
- Since the network is the bottleneck
- and we only talk to
- The Splution
- socketモジュール使うより短く書けるよ
import asyncio
tasks - {
machine.sya("Hello, hoe are you?")
for maching is machines
}
await asyncio.wait(tasks)
- The difference
- In the second ecample ,there is no immediate ececution
- Only promise creates"please
- Calling asyncio,wait forces runtime ri ewaolce taskas
- How do N things at the same time
Python asyncio sockets
reader, wtiter = loop.open_connvtion()
writer.senf(b'Hello, World)
awsit wruterr,drain(
anser - await reader,read(199)
)
- Test Usage
- シナリオ例
- ABCからDへ同じパケットを送る
- DhaAkaradakeケットを受け取るか、
- slow and incorrect eith blocking I/O
- In the eqal world
- network devices do not wait
- Now with non-blockingI/O
- 正しい振る舞いだけでなく、テスト実行が3倍早くなった
- Ecaluation
- think about use cascadefind tools,and learng about best practices
- apply,improce,share
- Synchronoously
- Code is easy to understand
- No mental overhead for locking/transactions
- Easy oo interface with existing
- Asynchtronously
- Specian sysntax needed asunc awaot
- locking always necesary,even though single threaded
- necessary for teatm to learn new programmin paradigm
- What you should avoid
- Using asyncio because It is fast I/ve been thereSpeedup onluy observable in I/O biund
- If you mix COU and I/O bound rasks and need adcice taks to me
- Why I like asyncio
- If you create something aweasome write a blof post
- Got o your local python meetio and tals aavuoit Asynip
- Contribute back to ppen souece :Rreport Bugs,Help Beginners,Write
Pythonで大量データ処理！PySparkを用いたデータ処理と分析のきほん
- Apache Sparkの紹介
- PythonといえばPyDataというくらいライブラリがそろっている
- 大規模データを扱いたい、データ量がスケールしても動く仕組みがほしい
- SparkはOSSの並列分散処理フレームワーク
- Hadoopクラスタ上で動作する、Amazon EMRやGoogle DataProcなどのマネージドサービスを使うと楽
- Sparkの３つのプログラミングモデル
- RDDとDataframe
- RDD
- ワーカーノードでの処理ではPythonプロセスで行われる
- Dataframe
- ワーカーノードでの処理はJVM上で行われる
- ただしUDHはPytohonプロセスで実行される
- パフォーマンス上の問題点
- RDDPythonは遅い
- DFだったらScalaと同じくらい
- RDDの中でNumpyやScipyを使う
- 集計結果をPandas DataFrameに変換してMatplitlibで可視化する
PySParkではppandas DataFrameとDparkDataFtaneの相互変換可能
Apache Arrow
- データフォーマットの仕様とそれをりようするためのライブラリ
- 異なる言語プロダクト感でのデータ連携コストを下げる
- Apache Zeppelom
- レコメンデーション、異常検知とか
- DAたFrameをつかう
- 処理するデータ量を減らす
- ストレージの利用
- D3,HDFA
- データフォーマットはParwuetを利用
- メモリ
- yarnによってコンテナが きっｌareruera-ga
- okiyasui
VOES 稼働後 after VOES launch
Hsueh-Tsung Kuo
how to resolve problems of mobile game server development and service maintenance
- VOES
- DBのアトミックを守る
- トランザクションが終わってからアップデートする処理
- database chache mechanism
- redis or memchached in RAM:fast
- AからBへのサーバへデータを移すとき
- Aのトランザクション処理が完了してからBへ
- database server reliableを保つ
- def gacha
- FGOメンテナンス48時間突破
- Python is so slow
- from database to static failures
- statistics
- crontabでBigQueryを叩いて結果を初滅
- 結果はGoogle Cloug Storageなどに突っ込む
- Server operation with CSB
- service downtime and update
- timezone
Why you should do text analysis in python
Bhargav Srinivasa Desikan
https://github.com/hari-allamraju/pycon-talk-taxidata/tree/master/slides
- why python
- ease of use
- regex,parsing, adn generators(pipeline text)
- incredible suport in form of libraries
- awesome community
- why text proxessing
- data everywhere
- with machine learning,deep insights
- fun - from a personal point of view
- employability - from a progessinal point of view
- so what can you do?
- glean insights from your own text
- chatbots
- language translation
- machine learning,deep learnings,tenserflow
- research - especially in the humanities
- where is the data
- free, open source, research sources
- scrape data off the internet
- whatsapp,FB,Hike,Line - any messageing app!
- ebooks
- pre-processing
- garbage in , garbage out
- ease of reading and writing to files
- also - libraried for pre-processing
- machine learnng in text
- gensim
- トピック分析できるライブラリ
- scikit- learn
- keras/tensorflow
- gensim
- world embeddings
- king - man + woman = Queen
- computational linguitstics
- Part of Speech tagging
- Named Entity Recognition
- Japanse relevance
- spaCy has started alpha suppprt for Japanese
- you can contribute and help expand it
- as for ML, it is largely language agnostic
- so now
- python is great at quick and dirty text pre-processing
- and has a great ,great library support
- and woth data everywhere
PythonでOauthサーバを構築した話
設定やパラメータの話 規約があるので、規約どおりに実装しようという話
- Tech bureau Coap.で働いている
- APIの話
- secret & key を利用する場合
- OAuth(token)を利用する場合
- OAuthサーバの作り方
- OAuthとは
- OAuth2.0の話
- 日本語で規約がある
- 全て規約が決まっている
- 使ったもの
- Python3
- Pyramid
- SQLArchemy
- Nginx
- トークン発行、利用、再発行
- 名称、サービス名称
- cliend_id
- どのサーバに紐付ければいいのか
- responce_type
- state
- なりすまし対策
- redirect_url
- リダイレクト用のURL必須ではない
- 認証が通ったあと
How (and Why) We speak in Unicord
Devon Peticolas
- Morse
- Encording
- Baudot
- パンチカード
- ASCⅡ
- The 8th bit
- Latin-1
- Hebrew
- Meanwhile in Japan
- Kanji
- Katakarna
- AA
- Japanese Encodeiisa
- Unicodeはどの言語でもつかる
- utf-8
- utf-16
- utf-32
Secrets of a WSGI master
Graham Dumpletonさん
- WGSI == Web Server Gateway Interfaces
- Webサーバとアプリをつなぐもの
- WSGI is a specification for an Application Programming Interface
- Friends don’t let friends use raw WSGI
- django,Flask,Bottle,などなど
- You still need a way to host a WSGI Application
- The development servers builtin to a framework are not good enough
- Installing mod_wsgi the easy way
- pip install mod_wsgi
- Run mod_wsgi from the command Line
- Automatic code reloading
- python manage.pu runmodwsgi –reload-on-changes
- Friends don’t let friends use Python without a Python virtual enviroment
- warpdrive
- Same tools for development
- warpdrive project mypyapp
- warpdrive build
- warpdrive start
- Generate image with no Dockerfile
- warpdrive image mypyapp
- docker run –rm -p 80:8080 mypyapp
- Source-to-Image
- Embedded mode
- Daemon mode
- Request monitoring
- Openshift
- Friends don’t let friends use Windows for running Python web Applications
- Friends don’t let friends use the mod_wsgi which comes packaged with the operating system
- Friends don’t let friends use those other WSGI servers
- Friends don’t let friends make things too complicated,simple is good
LT
ギャル語翻訳
- pyladiesの人たちのプロジェクト
- hack-a-thon
- ニュースサイトをギャル語にした
- Mecab,Tornado,Azure,Data ScirnceVM,Azure Redis cache
- 辞書は手書き
- Cheomeの拡張機能で設定
- 辞書をディープラーニング化したい
- ギャル語の情報を取得したい
ymyzk
Respect is built-in names
誰でも簡単に暗号取引botができるライブラリを作った
- Zaifbot
OSSFriday
- OSSに貢献しよう
ローカル環境でもDockerをドカドカ使う
- builderscon来年もやるらしい
- テスト環境でも使うのはよい
Pythonの実装をみる
カラオケおじさん
- 英日中の歌詞判別
ジョブフェア
- モノタロウ
- 東京オフィス作る
- データ分析に基づき仕事をしている
- Line
- サーバレスでLINE botつくれる
- Retty
- もくもく会とかやっているらしい
- iRidge
- 何やっているかよくわからない会社
Closing
Pyconのスタッフ多い。40人ぐらい? 1クラス分以上いた気がする。
Y8 2017で登壇デビューしました
Y8 2017 Spring in Shibuyaで登壇デビューしたので振り返りのブログ記事です。
発表資料はこれです。
発表資料です https://t.co/c9nWL3IKGg #y8spring
— トトス (@oza_shu) 2017年5月27日
動画もまとめられたみたいですね。
今回は初心者枠というものが設けられていて、 登壇デビューしたい人には良い発表する機会だったと思います。 そんな場を設けて頂いて皆様感謝でございます。
発表のいきさつ
去年のY8の発表でkoudaiiiさんの発表をみて自分のインフラエンジニアとして危機感を覚えたり、 懇親会でfujiwaraさんに勉強会にきても勉強にはならない、新しいことを知ることができるだけで、 発表したほうがいいよ。聴く人たちも発表している人に悪く言わないから恐れることはないみたいなことを言っていただいたり、 koemuさんにも発表しないとダメだ！死ぬぞ！みたいなことを言われたので絶対発表するぞ！！！とずっと思ってました。 今回それを実行できて満足です。
今回の発表はしてよかったと思うので、反省点とかまとめて、 次回の発表できるよう知見を貯めようと思います。
伝えたかったこと
プログラミング楽しい！技術をおうの楽しい！ってことです。
プログラミングの勉強がしたいってだけの人いますよね。 特にプログラミングできなくても仕事できてしまっている人や、 プログラミングできるようになりたいけど、作りたいものがない人。 中には増田でプログラミングできなくて辛いみたいなことを書く人もいると思うのですが、 そんな人たちに、そもそもプログラミングを書くの単純に面白いので、 まずは面白いってことを実感できるところからスタートするといいよって話をしたかったのです。
伝えられなかったこと
時間が20分だったので発表できなかったことは以下です。
- プログラミングを毎日書く仕組みづくり
- 仲間を作る
- 師匠を作る
- slackチャンネルでコミュニティを形成する
- おすすめの本
- おすすめのスライド発表
これらは好みがあると思うので略にしました。
戦略
アプリ開発を始めてプログラミング入門の話をしようと思ったのですが、 アプリが完成しなかったので、それだけの話は断念させ、 プログラミングができるとUNIXプログラミングやネットワークプログラミングができるようになり OSやプロセス、TCPサーバの実装やHTTPプロトコルの話などインフラよりの話も内容に盛り込むことにしました。 なので5月頭からはアプリ開発と並行してネットワークプログラミングやなるほどUNIXの本を読みました。 あとはchibicodeさんのスライドを使うことを許可いただき、虎の威を借ることにして 発表に説得力をつけるようにしました。
発表してよかったこと
発表したあとは恐怖でハッシュタグを見れなかったのですが、 少し冷静さを取り戻したあとに観たら、意外といい話と言っていただいたりしたので みなさん優しいって思いました。 僕もハッシュタグに感想を書くとき、いい話っていう感想をたくさんつぶやきました。 初心者枠を設けて頂いて助かった〜〜発表してよかった〜〜 100人規模の会場で話すのはどういうことなのかを知れたのは良かったです。
反省点
LTじゃないので、自己紹介をもう少し詳しくした方がよかったなあと思いました。 緊張してPCの画面をみて発表してしまし、 常に下を向いて、マイクに声が通らなかった。 ターミナル拡大に手間取ったので、 練習するか、スライドにコードを抜粋すればよかったです。 みんなコードをスライドに埋め込む人が多かった。 特にだれとも話さなかったのは只管後悔です。 知り合い作りたかった〜〜 あとは一発目で10:00からだったので、遅刻しないように緊張して寝れなかったので ちゃんと寝れるようにしたほうがよかったです。
次回にむけて
マイクを手に持って聴衆とスライド画面を見れるように発表することが大事で、 PCには触らない見ないをできるように発表の練習が必要だと思いました。 (PCに触るときはターミナル操作やデモを入れるときだけ) そのためには黒曜石を買って使おうと思います。 あとはDecksetの使い方にもなれようと思います。
コクヨ パワポ操作用 フィンガープレゼンター 黒曜石 ELA-FP1
- 出版社/メーカー: コクヨ(KOKUYO)
- 発売日: 2013/06/12
- メディア: オフィス用品
- この商品を含むブログ (6件) を見る
これならわかるGit/Github入門
git/githubについてよくわかっていないので、
簡単に調べてまとめました。
だいたいGithub実践入門のまとめですが。。
これシュタインズゲートのルートを例にしてまとめたら楽しかったろうなあ後で思った。
Git初期設定
gitの初期設定をしていきます
git config --global user.name "(your name)" git config --global user.email "(your email)" git config --global color.ui true $ git config --global alias.co checkout $ git config --global alias.st status $ git config --global alias.br branch $ git config --global alias.ci commit git config -l
Githubの設定とチュートリアル
公式サイトのガイドでrepository作成、branchを切って,commit,pull request,mergeの一通りができます。
Githubのアカウント作成、設定とSSH鍵の設定もしておきましょう。
SSH鍵を作成してfingerprintの内容をGithubのSSH鍵に登録します。
$ ssh-keygen -t rsa -C メールアドレス
SSH接続できれば完了！
$ ssh -T git@github.com
githubにpushしてみる
チュートリアルで作成したリポジトリにpushしてみる
git cloneしてリポジトリを持ってきます。
$ git clone git@github.com:hogehoge/hello-world.git
リポジトリを持ってこれていることを確認
$ cd hello-world/ $ ll total 8 -rw-r--r-- 1 hoge hoge xx xx xx xx:xx README.md
かんたんなスクリプトを上げてみます。
スクリプトはリポジトリに登録されていないので
untracked filesとなり、git addしてねと言われています。
親切ですね。
$ vim hello_world.php $ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # hello_world.php nothing added to commit but untracked files present (use "git add" to track)
git addしてステージ領域登録してあげます。
git add .で全てのファイルをステージ領域にあげることができますが、
上げたくないファイルはどうすればよいでしょうか。
.gitignoreファイルを作成して*.logとかすればよいです。
$ git add hello_world.php
commitしましょう。
$ git commit -m "Add hello world script by php" create mode 100644 hello_world.php
git logでコミット内容を確認しましょう。
- pオプションを付ければコミットメッセージの後ろにファイルの差分が表示されます。
--pretty=shortではコミットメッセージの1行目のみを表示します。
--onelineで一行のみ表示させます。
--statで、どこが変更されたかではなく、どのファイルが何箇所変更されたかをみることができます。
$ git log
Add hello world script by php
commitできているのでGithubにあげます。
Githubに登録されていれば完了。
$ git push
変更差分の表示
git diffでワークツリー、ステージ領域、最新コミット間の差分を確認できます。
差分がないと表示されません。
README.mdという空ファイルを編集して確認してみます。
$ git diff $ ll total 0 -rw-r--r-- 1 hoge hoge 0 xx xx xx:xx README.md
# Gitチュートリアルと編集してみるとワークツリーとステージ領域の差分が表示されました。
$ vim README.md $ git diff diff --git a/README.md b/README.md index e69de29..cb5dc9f 100644 --- a/README.md +++ b/README.md @@ -0,0 +1 @@ +# Gitチュートリアル
git addでステージ領域に追加すると差分がないので、表示されません。
最新コミットとの差分の確認はどうやるのでしょうか。
git diff HEADで確認できます。
あとは問題なければコミットしてみましょう。
HEADは作業しているブランチの最新コミットを参照するポインタです
git diff --cachedでもステージ領域に上がっていないけど、
コミットされていないファイルの「どこがどう次のコミットで変更されるか」がわかります。
$ git add README.md $ git diff $ git diff HEAD diff --git a/README.md b/README.md index e69de29..cb5dc9f 100644 --- a/README.md +++ b/README.md @@ -0,0 +1 @@ +# Gitチュートリアル
ちなみにgit addなどして、gitが管理したファイルはrmやmvを使うのでなく
git rmやgit mvでないといけませんので、ご注意を。
ブランチの操作
ブランチができると複数人で作業ができるようになる便利概念です
現在のブランチを確認すると、masterブランチにいます。
$ git branch * master
ブランチを作成して、移動しましょう。
$ git checkout -b feature-A Switched to a new branch 'feature-A' $ git branch * feature-A master
ちなみに上のコマンドは以下のコマンドを1行でやりました。
$ git branch feature-A $ git checkout feature-A
今、コミットするとfeature-Aブランチにコミットされて、ブランチを育てることになります。
以下の内容でコミットしてみます。
$ vim README.md $ cat README.md # Gitチュートリアル - feature-A $ git add README.md $ git commit -m "Add feature-A" [feature-A 4948954] Add feature-A 1 file changed, 2 insertions(+) ``` masterブランチには反映されていないことを確認 ``` $ git checkout master Switched to branch 'master' $ cat README.md # Gitチュートリアル $ git checkout - Switched to branch 'feature-A'
feature-Aブランチを統合ブランチであるmasterにマージしてみます。
masterブランチに移動してgit merge –no-ff ブランチ名
--no-offオプションを付けるとマージコミットのメッセージを記入するためにエディタが立ち上がります。
$ git checkout - Switched to branch 'master' $ git merge --no-ff feature-A Merge made by the 'recursive' strategy. README.md | 2 ++ 1 file changed, 2 insertions(+)
git log –graphで視覚的にみると、トピックブランチ(feature-A)で
コミットされた内容がマージされていることがわかります。
$ git log --graph * commit HASH値 |\ Merge: 1a433cc 4948954 | | Author: | | Date: | | | | Merge branch 'feature-A' | | | * commit HASH値 |/ Author: | Date: | | Add feature-A |
コミット変更操作
feature-Aブランチを分岐させる前に戻ってfix-bブランチを作成させるとします。
git reset --hart 戻りたい場所のハッシュ値
$ git reset --hard 1a433ccb5a6acebe742234de5
fix-Bというブランチを切ってファイルを編集してcommitします。
$ git checkout -b fix-B Switched to a new branch 'fix-B' $ vim README.md $ cat README.md # Gitチュートリアル - fix-B $ git add . $ git commit -m "Fix B" [fix-B 01ee7fc] Fix B 1 file changed, 2 insertions(+)
feature-Aブランチをmergeした後の状態に進み、fix-Bのブランチをmergeさせます。
git relogでfeature-Aブランチをmergeしたハッシュ値を
masterブランチに戻り、git reset –hardで選択して戻ります。
$ git reflog
01ee7fc HEAD@{0}: commit: Fix B
1a433cc HEAD@{1}: checkout: moving from master to fix-B
1a433cc HEAD@{2}: reset: moving to 1a433ccb5a6acebe742234de5
0165311 HEAD@{3}: merge feature-A: Merge made by the 'recursive' strategy.
$ git checkout -
Switched to branch 'master'
$ git reset --hard 0165311
HEAD is now at 0165311 Merge branch 'feature-A'
fix-Bの内容をマージさせるとCONFLICTが発生しました。
$ git merge --no-ff fix-B Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.
ファイルを編集してCONFLICTを解消させましょう。
$ vim README.md # Gitチュートリアル <<<<<<< HEAD - feature-A ======= - fix-B >>>>>>> fix-B
今回は以下の内容に編集しました。
$ cat README.md # Gitチュートリアル - feature-A - fix-B
この状態でmergeさせることができるようになりました。
$ git add . $ git commit -m "Fix conflict" [master 30b1cb4] Fix conflict
コミットメッセージの編集もしてみましょう。
$ git commit --amend [master 38ffc4c] Merge branch 'fix-b'
視覚的にみるとわかりやすいですね。
$ git log --graph * commit ハッシュ値 |\ Merge: | | Author: | | Date: | | | | Merge branch 'fix-b' | | | * commit ハッシュ値 | | Author: | | Date: | | | | Fix B | | * | commit ハッシュ値 |\ \ Merge: | |/ Author: |/| Date: | | | | Merge branch 'feature-A' | | | * commit ハッシュ値 |/ Author: | Date: | | Add feature-A |
歴史改変
トピックブランチをマージする前に、すでにコミットした内容にちょっとしたミスを見つけたら、
修正のコミットをして、改変しましょう。
featture-Cブランチを作成して試してみます。
タイポをしたままcommitしてしまいました。
これをマージする前に修正したい。
$ git checkout -b feature-C Switched to a new branch 'feature-C' $ vim README.md $ cat README.md # Gitチュートリアル - feature-A - fix-B - feaaature-C $ git commit -am "Add feature-C" [feature-C 02f4faf] Add feature-C 1 file changed, 1 insertion(+), 1 deletion(-)
Gitの歴史を改ざんしてしまいましょう。
タイポしなかった世界線へと移動させます。
今回は現在のブランチのHEADを含めた2つまでのcommitを対象にしてエディタを立ち上げさせます。
$ git rebase -i HEAD~2 pick 02f4faf Add feature-C pick 7e0f931 Fix Typo # Rebase 95aeef1..7e0f931 onto 95aeef1 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
下のように修正しましょう。
fix-up 7e0f931 Fix Typo
git logで確認するとtypoのコミットメッセージがなくなり、
Add feature-Cのコミットが書き換わっています。
後はmasterブランチにマージします。
$ git checkout master Switched to branch 'master' $ git merge --no-ff feature-C Merge made by the 'recursive' strategy. README.md | 1 + 1 file changed, 1 insertion(+)
Gitで育てたリポジトリをGithubに登録する
Github上でgit-tutorialというリポジトリを作成します。
リポジトリのパスが表示されるので、git remote addコマンドで指定します。
$ git remote add origin git@github.com:user-name/git-tutorial.git
git pushコマンドで現在のブランチのローカルリポジトリの内容を
リモートリポジトリに送信します。
今回はmaster => master
- uでローカルリポジトリの現在のブランチの上流はoriginリポジトリのmastertブランチであると設定したことになります。
これをつけるとリモートリポジトリの内容をgit pullするときに、
このローカルリポジトリのブランチはoriginのmasterブランチから取得することになります。
$ git push -u origin master
pushが終わったら、Githubで内容を確認してみましょう。
masterブランチ以外のブランチへ送信
リモートリポジトリにはmaster以外のブランチも作成できるのでpushしてみます。
$ git checkout -b feature-D $ git push -u origin feature-D
リモートリポジトリのGithubにfeature-Dブランチが確認できました。
リモートリポジトリから取得
別のディレクトリにローカルリポジトリを用意して
リモートリポジトリのfeature-Dを取得して変更してみましょう。
$ mkdir git-tutorial2 $ cd git-tutorial2/ $ ll $ git config -l user.name= user.email= color.ui=true $ git clone git@github.com:user-name/git-tutorial.git $ cd git-tutorial/
-aをつけてリモートリポジトリを含むブランチ情報を確認します。
リモートリポジトリにfeature-Dがあることを確認できました。
$ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/feature-D remotes/origin/master
feature-Dブランチをローカルリポジトリにチェックアウトしてみます。
git checkout -b 作成するブランチ名 リモートリポジトリにあるブランチ名
修正してcommitして、pushします。
$ git checkout -b feature-D origin/feature-D Branch feature-D set up to track remote branch feature-D from origin. Switched to a new branch 'feature-D' $ git diff $ vim README.md $ git diff diff --git a/README.md b/README.md index 50de722..125f990 100644 --- a/README.md +++ b/README.md @@ -3,3 +3,4 @@ - feature-A - fix-B - feature-C +- feature-D $ git commit -am "Add feature-D" [feature-D 4a5676c] Add feature-D 1 file changed, 1 insertion(+) $ git push feature-D -> feature-D
Github上のfeature-Dブランチが修正されていることを確認
最新のリモートリポジトリブランチを取得
ローカルリポジトリのfeature-Dブランチはcommitしていないので、
リモートリポジトリからgit pullでコードを取得してみましょう。
$ git pull origin feature-D $ cat README.md # Gitチュートリアル - feature-A - fix-B - feature-C - feature-D $ git branch feature-A feature-C * feature-D fix-B master
取得できました。
git push/pull を競合が起きないように気をつければ開発に便利ですね。
タグ機能
git logのコミットIDではわかりずらいとき、タグを付けると便利です。
git logの最近のコミットにタグを付けるときは、タグ名を指定すればよいです。
$ git tag v1.0 $ git tag
git showはコミットの内容を表示しますが、IDを指定せずともタグ名で表示できます。
$ git show v1.0
他のコミットにタグを付けたいときはタグ名の後ろにコミットIDを指定すればよいです。
また-dでタグを削除できます。
$ git tag v0.9 abb3e8e5440be9ef819aae3d3d10de3 $ git show v0.9 $ git tag -d v0.9 Deleted tag 'v0.9' (was abb3e8e)
とりあえず基本はこれぐらいで。
