コマンドプロンプト実行時に自動で実行するコマンドを定義する(.bashrc みたいなやつ)
Windows のコマンドプロンプトでも .bashrc みたいなことを実現する方法。
やりたいこと
コマンドプロンプトを実行した時に C:\github\stakiran\dotfiles\autorun\autorun_comp.bat
が実行されるようにしたい。
手順
(1) 実行させたいバッチファイルを書く
autorun_comp.bat
@echo off prompt $$
ここではプロンプト文字列を $
に変えるだけ、というシンプルな例。
その気になれば doskey でエイリアスを設定したり、set で環境変数いじったりもできる。ただし doskey には環境変数の伝搬が無い(ゆえに更に cmd を立ち上げると引き継がれない)ので 一工夫 必要。
(2) コマンドプロンプト起動時の自動実行を有効にする
レジストリをいじって、1 のバッチファイルを指定してやる。
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Command Processor] "AutoRun"="C:\\github\\stakiran\dotfiles\\autorun\\autorun_comp.bat"
参考
Windows 10 で IME が一切合切動作しなくなった話
1時間くらい格闘した。
現象
- 日本語が打てない
- Google 日本語入力のツールバーが出ない
- 以下を試しても効果無し
- コントロールパネルや設定から言語関連の設定をいじる
- Google 日本語入力を上書きインストールする
なんていうか根本からイカれてるな、という感触。
原因
Task Scheduler サービスが無効(Windows 起動時に起動しない設定)になっていた。
Task Scheduler は Windows の各種サービスやら何やらをスケジューリング実行するサービスなんだけど、IME 関連の機能は全部ここから起動されるようになっている。なので Task Scheduler 自体が起動してないと IME も起動されない。
解決方法
一言で: Task Scheduler を有効にした上で Windows を再起動する
参考: タスクスケジューラの無効状態を戻せません - マイクロソフト コミュニティ
以下、詳細手順。
- 1:
sc sdset schedule D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)(A;;CCLCSWLORC;;;AU)(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLORC;;;BU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
を実行する- これしないと services.msc から Task Scheduler の設定を変更できない
- 2: services.msc から Task Scheduler を有効にする
- 3: Windows 再起動
これで IME も起動して日本語入力も打てるようになるはず。
あとは後始末として必要なら
- 4:
sc sdset schedule D:(A;;CCLCSWLORC;;;AU)(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLORC;;;BU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
も実行しておく(Task Scheduler の設定を変えられないよう元に戻す)。
FAQ
Q: 結局 Task Scheduler が無効になった原因は何?
Ans: 不明
ググってみると「Windows Update のせい」という見解が多い模様。
Q: この呪文みたいなコマンドは何?
アクセス制御エントリという Windows の仕組みらしい。呪文みたいな構文は「セキュリティ記述子定義言語 (SDDL) 構文」と呼ぶのだとか。ガッツリ勉強しないとさっぱりわからないレベル。
Go 言語の遅延実行 defer がピンと来なかったのでわかりやすくまとめた
具体例で段階的に理解を試みるアプローチ。
初期化、処理、後始末をする例
例として初期化、処理、後始末をするコードを考える。
package main import "fmt" func initialize(){ fmt.Println("初期化") } func work(){ fmt.Println("なんか処理する") } func terminate(){ fmt.Println("後始末") } func main() { initialize() work() terminate() }
実行結果は以下のとおり。
初期化 なんか処理する 後始末
処理の途中でエラーが起きたとする
ここで、処理の途中で何かエラーが起きたとしよう。コードでは panic() 関数を使って無理矢理発生させている。
package main import "fmt" func initialize(){ fmt.Println("初期化") } func work(){ fmt.Println("なんか処理する") panic("処理の途中でなんかエラー起きた") // ★ } func terminate(){ fmt.Println("後始末") } func main() { initialize() work() terminate() }
実行結果は以下のとおり。
初期化 なんか処理する panic: 処理の途中でなんかエラー起きた
エラーが起きた時に後処理が実行されてない。後処理は必ず実行するものだ。実行させたい。さてどうするか。
後処理を実行させるために defer を使う
ここで defer が登場する。
package main import "fmt" func initialize(){ fmt.Println("初期化") } func work(){ fmt.Println("なんか処理する") panic("処理の途中でなんかエラー起きた") } func terminate(){ fmt.Println("後始末") } func main() { initialize() defer terminate() // ★defer付けた&順番変えた work() // ★ }
実行結果は以下のようになる。
初期化 なんか処理する 後始末 panic: 処理の途中でなんかエラー起きた
エラーで落ちる前に後処理(後始末)が実行されている。defer を指定し、かつ実行順序を(エラーが発生する)work() の前に書いたおかげだ。
この defer、内部的には何してんの?
ただ、これだけだと defer について、まだピンと来ない。
もう一つ例を出す。
package main import "fmt" func initialize(){ fmt.Println("初期化") } func work(){ fmt.Println("なんか処理する") panic("処理の途中でなんかエラー起きた") } func terminate1(){ fmt.Println("後始末1") } func terminate2(){ fmt.Println("後始末2") } func terminate3(){ fmt.Println("後始末3") } func main() { initialize() defer terminate3() // ★ defer を使った呼び出しを複数定義してみた defer terminate2() // ★ defer terminate1() // ★ work() }
これを実行すると以下結果が出る。
初期化 なんか処理する 後始末1 後始末2 後始末3 panic: 処理の途中でなんかエラー起きた
defer の定義では 3 → 2 → 1 と書いているが、実際は 1 → 2 → 3 の順で実行されている。これはどういうことか。
結論を言うと スタック である。もっと言うと 「スコープから抜ける時に必ず実行するヤツら」スタック だ。
まず defer X
を行うと、内部的には X がスタックに入れられる。で、このスタックだが、(この defer を定義したスコープから抜ける時)に Go 言語がチェックして、中身を全部実行するようになっている。実行順はスタックだから LIFO、つまり後入れ先出しだ。
ここでもう一つ重要なのは エラーが起きた時もスコープを抜ける ということ。
func main(){ work1() work2() // ★ここでエラーが起きたら、ここで main() のスコープを抜ける work3() // work3 以降は実行されない work4() }
ここまで押さえれば defer の挙動についてイメージが湧くと思う。
おわりに
まとめ:
defer X は「スコープから抜ける時に必ず実行するスタック」に X を Push する処理である
TODO: Go言語の実装を見て真実を確かめる(いい線言ってるとは思う) or ご存知の方教えてください。。。
Minio のアクセスキーは最低3文字、シークレットキーは最低8文字必要
最低限の config で Minio を動かしたい場合、アクセスキーやシークレットキーも手抜きするんだけど、 Unable to load the configuration file: invalid credential in conf エラーが出てしまう。具体的に何がおかしいかまでは出ない。
調べてみたところ、たぶん以下が Minumun な config.json だと思う。
{ "version": "26", "credential": { "accessKey": "333", "secretKey": "88888888" } }
アクセスキーは最低3文字、シークレットキーは最低8文字必要みたい。
念の為ソース見てみると、pkg/auth/credentials.go#L28 このあたり。抜粋すると、
const ( // Minimum length for Minio access key. accessKeyMinLen = 3 // Maximum length for Minio access key. // There is no max length enforcement for access keys accessKeyMaxLen = 20 // Minimum length for Minio secret key for both server and gateway mode. secretKeyMinLen = 8 // Maximum secret key length for Minio, this // is used when autogenerating new credentials. // There is no max length enforcement for secret keys secretKeyMaxLen = 40 // Alpha numeric table used for generating access keys. alphaNumericTable = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" // Total length of the alpha numeric table. alphaNumericTableLen = byte(len(alphaNumericTable)) )
うん、間違いなさそう。
オブジェクトストレージサーバー Minio を簡単に試してみた on Windows
前提
- Windows Server 2016
- Minio Verion: 2018-06-29T02:11:29Z
Minio とは?
- オブジェクトストレージサーバー
- 実行ファイル minio.exe 一つで動くシンプルさ
- ブラウザ用 UI も
- Amazon S3 互換のインターフェイス体系(CLIとかREST APIとか)なので S3 勢には使いやすい
動かすまで
ディレクトリ構造
たとえば以下のように配置する。
+ minio - minio.exe + data + config - config.json
実行コマンドライン
$ cd <WORKDIR>\minio $ minio.exe --config-dir config server data
これで「config フォルダ配下の設定ファイルを使って」「data フォルダ配下にデータを格納する」オブジェクトストレージサーバーが立ち上がる。
アクセスする
minio.exe を実行すると、利用に必要な情報が色々アウトプットされる。
$ minio.exe --config-dir minio\config server minio\data Endpoint: http://10.0.0.1:9000 http://127.0.0.1:9000 AccessKey: aaaa SecretKey: aaaaaaaa Browser Access: http://10.0.0.1:9000 http://127.0.0.1:9000 ...
たとえばブラウザで使いたいなら Browser Access 部分の URL を開けばいい。開くとアクセスキーとシークレットキーを訊かれるので、表示されてるのを打つ。
ブラウザ UI
アップロード:
- バケットを作る(Create Bucket)
- バケットの中にファイルをアップする(Upload file)
ダウンロード:
- バケットを開く
- 表示されたファイルを選択して Download object
config.json について
まずは何も作らないで minio.exe を立ち上げる。するとデフォ設定で config.json が生成。これをベースにカスタマイズする。
ガイドは Minio Server config.json Guide - Minio あたりを読む。
最低限の config.json
アクセスキーは最低3文字、シークレットキーは最低8文字あれば動く。
{ "version": "26", "credential": { "accessKey": "333", "secretKey": "88888888" } }
これに満たない場合、 Unable to load the configuration file: invalid credential in conf みたいなエラーが出てしまう。
config の version って何?
ガイドでは
determines the configuration file format. Any older version will be automatically be migrated to the latest version upon startup. [DO NOT EDIT THIS FIELD MANUALLY]
と言っている。要するに「Minio のバージョン毎に微妙に config のフォーマットが異なる」という状況があるのだが、「どのバージョンのフォーマットを使うのか」という指定をこの version フィールドで行う。基本的に minio.exe 側で決めるためユーザーはいじってはならない。
もうちょっと中身を知りたいなら ソースを見る のもアリ。構造体でズラっと定義してある。
data はどのように保存される?
たとえば
$ minio.exe server data
と実行した(data フォルダ配下に保存)上で、バケット bucket1, bucket2 にそれぞれ data1.txt と data2.txt をアップロードした場合。
data ├─.minio.sys │ │ format.json │ │ │ ├─buckets │ │ ├─bucket1 │ │ │ └─data1.txt │ │ │ fs.json │ │ │ │ │ └─bucket2 │ │ └─data2.txt │ │ fs.json │ │ │ ├─multipart │ └─tmp │ └─xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ├─bucket1 │ data1.txt │ └─bucket2 data2.txt
噛み砕くと、こう。
+data +bucket1 -bucket1にアップしたファイル -... +bucket2 -bucket2にアップしたファイル -... +その他内部的な設定情報など
Windows の at コマンドでリマインダーを実現する
Windows にデフォで入ってる at コマンドを使えば、コマンドラインからワンライナーでリマインダ-を実現できる。コマンド派にとっては実用的なリマインダーになるかもしれない。
- 前提
- リマインダーを登録する
- 登録済のリマインダーを確認する
- リマインダーを削除する
- Q: 即座に実行されるリマインダーは登録できますか?
- Q: Win10 以降の OS で使いたいんですがどうすればいいですか?
前提
- Windows 7 Pro
- Home だと本記事の方法は使えません
- Win10 以降でもダメです
リマインダーを登録する
at HH:MM msg console MESSAGE
を実行する。
$ at 11:20 msg console リマインダーです 新しいジョブをジョブ ID = 4 で追加しました。
すると 11:20 になった時に、以下ダイアログが表示される。
登録済のリマインダーを確認する
at
を実行する。
$ at 状態 ID 日付 時刻 コマンド ライン ------------------------------------------------------------------------------- 2 明日 11:20 リマインダーです
リマインダーを削除する
at 2 /delete
で ID=2 のリマインダーを削除。
at /delete
で全てのリマインダーを削除(確認アリ)。
at /delete /yes
で全てのリマインダーを削除(確認無し)。
Q: 即座に実行されるリマインダーは登録できますか?
Ans: できません
たとえば現在時刻が 11:25 の時、at 11:25 msg console リマインダーです
を実行したとしても、このリマインダーは即座に表示されません。翌日の 11:25 に表示される リマインダーとみなされてしまいます。
Q: Win10 以降の OS で使いたいんですがどうすればいいですか?
Ans: schtasks コマンドを使ってください
ただし at コマンドよりもだいぶ引数が煩雑で面倒くさいです。
Markdown を HTML で読む手段として MkDocs と MDwiki を試したので優劣を書く
Markdown は書きやすく、そこそこ読みやすい記法だが、それでも plain text なので不便である。定石は HTML に変換して読むことだと思う。で、その変換手段として色々あるんだけど、今回は MkDocs と MDwiki を比較してみる。
前提
記事のまとめ方
- V.S. の形で「どちらが優れているか or ドローか」を主観でまとめている
- 細かい使い方や拡張方法などは取り上げない
MkDocs とは?
いわゆる静的サイトジェネレータ(ビルドすることで原稿ファイルから HTML ファイルを生成するタイプ)。分かる人向けに言えば「Markdown で書ける Sphinx 」。
MDwiki とは?
mdwiki.html#!index.md
にアクセスすると index.md を HTML に変換して表示してくれるツール。
使い分けについて
「一人用 or チームメンバー間で見るだけ」みたいな小さい単位で、てっとり早く HTML で読みたいなら MDwiki。
ただ MDwiki は読み心地が微妙なのと、カスタマイズの能力にも限界があるのとで、そのうち物足りなくなってくる。そうなったら MkDocs が良いだろう。導入やカスタマイズは難しいが、MDwiki を凌ぐ読み心地とカスタマイズ能力を持っている。
(1) 導入面
Winner: MDwiki
導入ハードル
Winner: MDwiki
MDwiki はダウンロードした MDwiki.html を配置するだけで完了する。MkDocs は Python と pip のインストールが必要。
HTML 変換の手間
Winner: MDwiki
MDwiki はページ読込時に動的に変換するので変換コストはゼロ。MkDocs は事前にビルドが必要。
ライセンス
Winner: MkDocs
- MkDocs: BSD
- MDwiki: GNU AGPLv3 with additional terms
MDwiki には additional terms(追加条項)として「(MDwikiのクレジットが表示された)フッターを消すなよ」等があり、商用ユースでは若干不格好かなという印象。
(2) 見た目
Winner: MkDocs
URL のキレイさ
Winner: MkDocs
- MkDocs:
https://example.com/hoge.html
- MDwiki:
https://example.com/index.html#!hoge.md
CSS カスタマイズ
Draw.
どちらも CSS をいじって見た目をカスタマイズできる。
テーマの変更
Winner: MkDocs
MkDocs はサポートしている。MDwiki はサポートしていない。
(3) 生成サイトの使い心地
Winner: MkDocs
TOC(目次)
Winner: MkDocs
MkDocs は TOC の生成が安定しているし、テーマ次第だが見出し階層をインデントで階層表示してくれたりもして見やすい。
というより MDwiki の TOC は出来が悪い。中見出し(## ...
)しか表示してくれない、目次が長いと見切れたり消えたりするバグがあるなど。
ナビゲーションバー
Draw.
どちらもサポートしている。ネストも可能。
細かいことを書くと、
- MDwiki: navigation.md に書き並べる&表示は画面上部にバーのみ
- MkDocs: mkdocs.yml に書き並べる&表示はテーマ次第(上部にバーだったりサイドバーだったり)
全文検索
Winner: MkDocs
MkDocs は検索できる。それでもデフォルトでは日本語検索できなかったりするが、 material テーマでは設定を追加すればできるようになる みたい。
MDWiki は検索機能がそもそも無い。
見出しのアンカーリンク
Draw.
MkDocs はテーマによって生成したりしなかったり。
MDwiki は生成するが、アンカーマークが見出し行の次行に表示される(そして表示時に行が動的に一つ増えるため表示全体がずれる)のが微妙。
ローカルサイトへのアクセス
Winner: MkDocs
MkDocs だはローカルに置いた index.html も普通に読める。
(2018/08/02 追記) ローカルで読むためには mkdocs.yml
に use_directory_urls: false
の指定が必要です。詳しくは MkDocs で生成したサイトをローカルで開くと index.html が開かれない問題 - stamemo を参照
MDwiki だと IE と Chrome では読めない(Chrome ではコマンドライン引数を付け加えればできる)。これは MDwiki は動的に md ファイルをロードするせいでブラウザ側のセキュリティに引っかかってしまうため。
(4) Markdown 記法
Winner: MDwiki
サブリストのネスト表記
Winner: MDwiki
MDwiki は 2 スペースでも動く。MkDocs では 4 スペースでないと動かない。
URL の自動ハイパーリンク化
Winner: MDwiki
MDwiki はしてくれる。MkDocs はしてくれない。
(5) その他未分類
SEO 効果
Winner: MkDocs
MkDocs は静的サイトなので SEO 対策できる。というより MDwiki がコンテンツを全部動的に生成するために SEO 対策しづらい。
サポート状況
winner: MkDocs
MkDocs は 2018/06/28 現在も活動している。MDwiki は(いつからか知らないけどたぶんここ数ヶ月の間に) Read Only になっている 。
Python boto3 で InsecureRequestWarning を消す方法2つ
方法1: 環境変数を使う
PYTHONWARNINGS
環境変数に "ignore:Unverified HTTPS request"
を書いておく。
以下は Windows の例。"
があると動かないので注意。
$ set PYTHONWARNINGS=ignore:Unverified HTTPS request $ python script_with_boto3.py
方法2: urllib3.disable_warnings() を使う
urllib3.disable_warnings()
を使えば良いことは知っていたが、消えてくれない。なぜだと思ったら、
import botocore.vendored.requests.packages.urllib3 as urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) # 上記コードは boto3 を import する前に実行する必要アリ !! import boto3
これで解決。 「Boto3にバンドルされてるrequests」にバンドルされてる urllib3 に対して disable_warnings() してやる必要があった。
が、これはトリッキーだし、OS によっては使えないらしいので、方法1 が確実だと思う。
参考
suppressing warnings for unverified certificates? · Issue #699 · boto/boto3
秀丸エディタマクロの利用ハードルを下げるために知っておくと良いこと
秀丸エディタのマクロ機能は便利ですが、マクロと聞くと「難しそう」「いまいちよくわからない」「結局マクロを使うために何をすればいいの?」とハードルの高さを感じる方も多いのではないでしょうか。
というわけで、ハードルを下げるために知っておくと良いことをまとめてみます。
マクロの登場人物
まずマクロを語る上で欠かせない登場人物をまとめます。
マクロファイル
秀丸エディタをどう操作するかという命令(スクリプト)を記述したファイル。拡張子は .mac。
スロット
秀丸エディタに用意されている「実行したいマクロを配置する穴」のこと。 この穴に入れたマクロでないと実行できない。一つのスロットには一つの .mac ファイルを入れる。スロットは計80個ある。
マクロを実行するまでの流れ
登場人物を把握したところで、続いてマクロを実行するまでの流れを取り上げます。
- (1) 入手
- .mac ファイルを自分で書く or 誰かが書いたものを入手する
- (2) 登録
- .mac ファイルをスロットに入れる(登録する)
- (3) 呼び出し方法の割り当て
- スロットに入れたマクロをどうやって呼び出すかを決めて設定する
- 例1: スロットに「ショートカットキー」を割り当てる
- 例2: ツールバーに「スロットを呼び出すボタン」を配置する
- 例3: その他メニュー > コマンド一覧 > メニュー/マクロ から直接呼び出す
- (4) 呼び出し
- (3) で割り当てた方法を使って呼び出す
重要なのは .macファイルの準備、スロットへの登録、呼び出し方法の割り当て という 3 ステップが必要という点です。逆を言えば、この 3 ステップさえ抑えておけばマクロを簡単に使えるようになれます。
各ステップについて
以降は、各ステップの手順について画像付きで紹介していきます。
(1) .mac ファイルの入手
入手方法として以下があります。
- 誰かが作ったものをインターネットから入手する
- 例: マクロライブラリ
- 自分で作る
.mac ファイルはどのフォルダに配置しても構いませんが、便宜上「マクロを置く用のフォルダ」を決めて、そこにまとめるのが楽でしょう。
(2) .mac ファイルをスロットに登録
次に .mac ファイルをスロットに登録しましょう。
マクロ > マクロの登録を開きます。
マクロ登録画面が開くので、空いているスロットに「表示名」と「.macファイルのパス」を入力します。
パスは「...ボタン」を使えばファイル選択ダイアログで選べるので楽です。
(3) スロットに入れたマクロに呼び出し方法を割り当てる
スロットに入れたら、呼び出し方法を割り当てます。ここではツールバーにボタンを配置する方法と、ショートカットキーで呼び出せるようにする方法の二つを取り上げます。お好みの方法を使ってください。
3-1: ツールバーに割り当てる
まずはツールバー領域を右クリック > ツールバー詳細を。
するとツールバーカスタマイズ画面が開くので、右ペインに上図のようにスロットを表示させた後、追加ボタンで左ペイン(ツールバー)に追加していきます。
完了すると、ツールバーにボタンが表示されると思います。これをクリックすると当該のマクロ(ここでは change_tabname マクロ)を実行できます。
3-1: ショートカットキーに割り当てる
その他 > キー割り当てを開きます。
キー割り当て画面が開くので、まず左ペインで「割り当てたいショートカットキー」を選びます。上図は Alt + R に割り当てる例です。
続いて、そのショートカットキーに対応する操作を右ペインから選びます。スロットに登録したマクロを選びます。
OK ボタンを押すと、設定したショートカットキーで対応するマクロを呼び出せるようになります。
(余談) 実は割り当てなくても呼び出せる
実はツールバーやショートカットキーに割り当てなくても、スロット内のマクロを呼び出すことができます。
その他 > コマンド一覧を開きます。
すると左上にメニューが出ます。メニュー/マクロ > 開きたいマクロ、と辿って実行することができます。
(4) 呼び出し
あとは割り当てた方法(ショートカットキーを押す、ツールバー上のボタンをクリックする)でマクロを実行するだけです。
おわりに
もう一度まとめると、マクロを実行するまでに必要なことは以下 3 手順です。
- (1) マクロファイル(.mac)を入手する
- (2) 秀丸エディタのスロットにマクロファイルを入れる
- (3) スロットに呼び出し方法を割り当てる
ここさえ抑えておけば混乱はしません。あとは手を動かすだけです。
マクロはとても便利なので、利用を渋っている方も、これを期に利用してみるといかがでしょうか。まずは公式サイトの マクロライブラリ あたりを見てみると、便利なマクロが見つかることでしょう。
DES, AES, TKIP, WEP, WPA, WPA2 の違い
紛らわしいので違いを簡単にまとめた。
DES と AES と TKIP
いずれも暗号化方式(データをどうやって暗号化/復号化するかというアルゴリズム)。
安全度: DES < TKIP < AES
- DES は古い。セキュリティが弱い。使ってると解読される恐れがあるので使わないべき。
- AES は現在の主流。
- TKIP は DES と AES の間くらいの強さ。AES が使えるなら使わなくてもいい。
WEP と WPA と WPA2
いずれも「無線通信のセキュリティに関するプロトコル」。これらプロトコル中には「どの暗号化を使うか」という項目があり、それ次第で WPA/AES(AESを使う)、WPA/TKIP(TKIPを使う) などに分かれる。
安全度: WEP < WPA < WPA2
- WEP は古い。セキュリティが弱い。使ってると通信を乗っ取られる可能性がある。使っちゃダメ。
- WPA は現在の主流。
- WPA2 は WPA よりも更にセキュリティが強い。主流になりつつある。使えるなら使えばいい
Python の xlrd ライブラリを用いて Excel ファイルのシート内容を Markdown に落とす
Excel ファイルは非常に読みづらいので、Markdown に変換して「表ではなくテキストファイルを読む感覚で」読み進めたいなと思った。Python の xlrd ライブラリだと簡単に Excel ファイルを辿れそうだったので、今回試しに作ってみた。
- スクリプトは GitHub にアップした
以下 xlrd の使い方やテクニカルな部分をさらっと解説。
xlsx ファイル全般情報
open_workbook() で読み込んで、nsheets でシート数、sheet_names() でシート名のリストが取れる。
import xlrd
bookobj = xlrd.open_workbook(ファイル名)
sheet_count = bookobj.nsheets
sheet_names = bookobj.sheet_names()
各シートへのアクセス
open_workbook() で手に入れたオブジェクトの sheet_by_index() を呼ぶ。引数に「取得したいシートの番号」を入れる。番号は 0 オリジン。つまり一番左のシートが 0 番で、一つ右は 1 番、次が 2 番……という風に対応付いている。
sheet = bookobj.sheet_by_index(取りたいシートの番号)
あとは、得られた sheet オブジェクトに対してあれこれ操作する。今回はシート中の全セルの内容が欲しいので、
- ncols でシートのカラム(列)数、nrows で行数を取得
- ncols と nrows の値でループして、各セルにアクセスする
というやり方を使った。
xsize = sheet.ncols ysize = sheet.nrows for y in range(ysize): for x in range(xsize): cell = sheet.cell(y, x) value = cell.value
ここで value(セルの値) は以下のように変換される。
- 値が文字列 → string 型
- 値が数字 → int or float 型
セルには文字列も数字も入っていることがあるので、「文字列だったらこうする」「数字だったらこうする」と条件分岐をしっかり書いておいた方がいい。
列番号を列名(0,1,2→A,B,C)に変換する
Excel だと列は A, B, C, ... AA, AB, ... という風にアルファベットで列を識別するが、xlrd 上では番号で識別される。
表示する際、番号よりも列名の方が直感的でわかりやすいので、本スクリプトではついでに変換も行っている。といっても xlrd の機能ではないので自分で頑張って書かねばならない。
def column2alphabet(column_number): div = column_number s = '' temp=0 while div>0: module = (div-1)%26 s = chr(65 + module)+s div = int((div-module)/26) return s
なにやら割り算と剰余が登場しているが、この変換はいうなれば 10 進数を 26 進数に変換するようなものである。26 進数は 26 通りの表現パターン(ここではアルファベットa-z)があるので、元の 10 進数を 26 で割った余りを見ることで「26パターンのうちの何パターン目か」を順に取得していっている……とでも言えばいいか。進数変換はそういうものだ。
参考(というかほぼ流用): python - Convert spreadsheet number to column letter - Stack Overflow
DANCE RUSH (ダンスラッシュ) は音ゲーではなくダンスゲーなのだという話
音ゲーマーから見たダンスラッシュは譜面の難易度が低くて物足りない。2018/06/25 時点の最高難度 FLOWER ふつう LV 10 でさえも、踏みゲー経験者なら一週間くらいで 95% に届くだろうし、私の観測範囲でも 99% 以上を取ってる人が複数人いる。ぬるい。
- 「レベル11以上が欲しい」
- 「 "むずかしい" が欲しい」
といった声もよく聞く。
だけど、そんな未来はたぶん訪れない。
ダンスゲーとしてなら現時点でも相当ムズイ
ダンスラッシュは確かに音ゲーとしてはぬるいけど、ダンスゲーとして遊んでみると相当ムズイことがわかる。
ここで一つリザルトを紹介したい。
ダンスラ界隈で最も有名であろう一人、あっずさんのツイートなんだけど、ツイート先にある画像(選曲画面)を見てほしい。Butterfly ふつうのハイスコアは 93 %だ。
※1 (主にあっずさん) 本リンクに問題があるならコメントください。削除等致します。Twitter は @stakiran2
この数字を見ると、音ゲー勢は「低くね?」と思うだろう。私も思った。ベテランだから 99% くらい軽く取っているのかと思っていた。
でもこれ、全然低いなんてことはない。むしろ高い。 ダンスゲーとして真面目にダンスしながら遊んでみると、その難しさがわかる。私も最近、正しいランニングマンとスポンジボブを取り入れてみたんだけど、Butterfly は 98% から 93-95% にまで落ちた。これでも毎日数十分、そらで練習している。まだまだ追いつける気がしない。
ランニングマンにせよ、スポンジボブにせよ、ステップとはいえダンスの動きだ。その場でホイホイと習得できるほど甘い技術ではない(出来るのならすごく要領が良い)。ましてダンスラッシュでは、そんな動きに加えて、譜面どおりに踏ませようとするのである。ダンス技術とゲーム要素のミックス。二重にムズイ。
あっずさんを始め、ガチのダンス勢はダンスにこだわっている。私みたいにランニングマンとスポンジボブで自己満しているのではなく、ただのステップにも工夫を凝らしている。難しさは比較にならない。私は未だにランニングマンもスポンジボブもマスターできてないというのに。
ダンスラッシュのムズさは、ダンスゲーとして遊んでみて初めてわかるのだ。
たった 90% で ★★★★★ だという意味
ダンスラッシュのスコアは ★ の個数で格付けされ、1個から5個ある。最高が5個だけど、5個の水準は たった 90% だ。また、EXTRA STAGE の進出条件もやはり 平均 90% である。
音ゲー勢として見たら「90%?低くね?」と思ってしまうけど、ダンスゲーとしてはこのライン、前述のとおり、かなりシビアなのである。
90%。この数字の重みは、音ゲー勢とダンス勢とでは全然異なるということだ。そして最初から 90% に 5 個を割り当ててきたダンスラッシュ開発陣が、ダンスゲーとしての難易度を想定していることは明らかだ。
音ゲーみたくムズイ譜面は登場しないと思う
音ゲー勢は DDR や PIU のような高密度高難度譜面を夢見てしまうが、もう一度言う。そんな未来はたぶん来ない。
- ダンスラッシュはダンスゲームであること
- 現状のレベル 9, 10 のふつう譜面でもダンスゲーとしては十分ムズイこと
- DDR や PIU みたいな密度にしたら物理的にダンスができなくなる(人間の体力では追いつけなくなる)こと
したがって音ゲー的な譜面が来ることはない、と私は思っている。
これまでも音ゲー譜面は FLOWER しか出てない
ここまでのダンスラッシュを振り返ってみると、高難度の音ゲー譜面は FLOWER のみだ。
これまでの配信履歴を挙げてみる。
- 2018/03/23 稼働開始
- 2018/04/27 FLOWER 配信
- 2018/06/08 Crazy Shuffle 配信
これだけだ。2018/06/25 現在で音ゲーレベルの高難度譜面は FLOWER しか出てない。Crazy Shuffle もそこそこ難しいので挙げてみたけど、FLOWER には遠く及ばない。
結果を見ると、三ヶ月が経とうとしているのに FLOWER を超える難易度が登場していないのである。これはダンスラッシュ運営側にも、FLOWER 以上の高難度譜面を出す気がないということではなかろうか。一方で、新曲自体はこれまでに 10 を超えて配信されている。
まとめ
ダンスラッシュは音ゲーではない。ダンスゲーだ。踊るための譜面が重要であって、踏みゲーの音ゲーとしてバカスカ叩くための譜面に用は無い。どころかダンス勢にとって邪魔ですらある。
というわけで高難度譜面を待つ音ゲー勢の皆さん、諦めてダンスしましょう!
関連記事
ダンスラネタは下記別ブログの方でたまに取り上げてます。
GitHub の複数テンプレートから選べる機能 Multiple Issue Templates について仕様を調べてみた
Github で日本語を扱うことが多いので、細かい仕様や挙動を一通り調べておいた。
今回試したリポジトリはこちら
- ディレクトリ構成/ファイル構成
- New Issue 時にどう表示されるか
- .github/ISSUE_TEMPLATE 配下を GitHub に作ってもらう
- まとめ
- (余談1) GitHub ブログのアナウンス
- (余談2) multiple issue templates?
ディレクトリ構成/ファイル構成
ディレクトリ構成:
- .github/ISSUE_TEMPLATE/XXXX.md
XXXX.md の中身:
--- name: <テンプレート名> about: <テンプレートの説明> --- <ここからテンプレート本文> ... ...
XXXX.md のファイル名について:
- New Issue 画面での表示順 に影響する(後述)
New Issue 時にどう表示されるか
↓
.github/ISSUE_TEMPLATE/XXXX.md
の内容がファイル名降順(リポジトリのファイル表示順序と同じ)でズラリと並ぶ- XXXX として日本語ファイル名を使うと、New Issue から作ろうとした時に Ooops! 500 エラーページ が出る
500 エラー:
.github/ISSUE_TEMPLATE 配下を GitHub に作ってもらう
一から作るより楽できるかもしれない。
作り方:
- Settings > Features > Get organized with issue templates > Set up templates ボタン
- 下部の Add template から適当に選び、追加された行に対して Preview and edit ボタンを押して中身を編集、終わったら Close preview ボタンで保存
- Name: テンプレート名
- About: テンプレートの説明
- Template content: テンプレートの中身
日本語が絡む注目すべき仕様:
- テンプレート名(Name)に日本語が含まれる 場合、
-
に置換されるテンプレート1.md
→-------.md
- ハイフン置換によりファイル名が被った場合、後の方が優先される
テンプレート.md
とほげほげほげ.md
がある場合、------.md
は「ほげほげほげ.md」の方を指す
まとめ
- New Issue 画面での表示順はファイル名降順
- ISSUE_TEMPLATE 配下に日本語ファイル名を置いちゃいけない
(余談1) GitHub ブログのアナウンス
GUI として提供され始めたのは 2018/05/02 っぽい。
しかし機能自体は 2018/01/25 時点では存在していた模様。 /issues/new?template=bugs.md
みたいに使いたいテンプレートを URL で指定する感じ。
(余談2) multiple issue templates?
この機能の呼び方だけど、 multiple issue templates でいいのかしら。
We recently helped project maintainers set up multiple issue templates as a way to manage contributions,