同人誌とレーザープリンタ
素直にレーザープリンタが欲しくなる記事だわ
いや同人誌とか作ってないけど
インクジェットだと時間で3冊だったところ、レーザーなら1時間で30冊印刷できる圧倒的な高性能がすごい（消費電力もすごいけどｗｗ）
30部とかの少量頒布コピー本なら、会場で足りない分を印刷するのもアリなんじゃないかな？と一瞬思ったが、 会場のブレーカーが飛びそうだから印刷していくのはやっぱ必須か・・・。
京葉線で警戒すべきは荒川河口にある京葉線の鉄橋に直接風が当たる南風・南西の風。
オレ予想では明日の京葉線は火曜日の1600あたりから間引き運転はじまるかもしれん。
火曜日の1800にはかなりアウトっぽい感じ。
京葉線の場合、房総特急わかしおの運休が目安となる。わかしおが運休になったらもう数時間以内に運転見合わせする気満々ということ。
明日の朝またwindyサイトで様子を見てみよう。さらに予測精度が上がってるはず。
p.s.
予想より悪化が早い...。京葉線は15時台にはもうだいぶダメになっとる...。 京葉線や東西線の運転見合わせも予想より早い。17時台に逝くとは...。
まだこの時間のついったー民は台風なんだからしばらく待てば回復・・・と考えているようだが、南風が弱くなる予報は水曜日の午前３時とかである。 つまり火曜日はもう終日運休なんだよぉぉぉと伝えたい。
京葉線を使うものは風と共に生きる。風速予報から目を離すな。風を甘く見れば即ち死ゾ。
東西線が19:02に運転再開してて驚いた。風読みを誤ったか？ でも風速予想によれば23時ごろにもう一回運転見合わせする可能性あり。油断してはならない。
京葉線が21:30ごろ運転再開見込みとしている。風速だけで言えばまだまだ強いが、台風が遠ざかったので問題なしという判断か。
京葉線、21:44ごろ、やっぱり運転再開ナシにしやがったｗ そう。風速と風向だけ見るならまだ弱まる見込みは無い。おそらく水曜日の午前２時までは無理。
京葉線、23:01ごろ、運転再開をアナウンス。江戸川臨海での風速は16m/sまで落ちて安定しそうなので帰宅難民を運ぶため運転再開か。
京葉線の動向を占うなら、江戸川臨海のアメダスが参考になる。
9/4の風速と、風向に注目。 南〜南西の風、アメダスの風速15m以上で台風接近中(今より悪くなりそう)という条件で運転見合わせが発動すると想像できる。 京葉線の停止条件の風速は25m/sなのだが、荒川の鉄橋で測定しているので、地上に設置されているアメダスよりも風速が高くなる。 地上で南風で15m/sならだいたい京葉線はアウトと考えていい。17m/sを超えたらもう運転見合わせとなる。
| 時刻 | 気温(度) | 降水量(mm) | 風向(16方位) | 風速(m/s) | 日照時間(分) | 積雪深(cm) |
| 29:00 | 23.4 | 4.5 | 南南西 | 14.3 | 0 | --- |
| 28:00 | 24.6 | 3.0 | 南西 | 11.6 | 0 | --- |
| 27:00 | 27.5 | 0.0 | 南南西 | 15.7 | 0 | --- |
| 26:00 | 27.6 | 0.0 | 南南西 | 15.6 | 0 | --- |
| 25:00 | 27.6 | 0.0 | 南南西 | 17.1 | 0 | --- |
| 24:00 | 27.8 | 0.0 | 南南西 | 15.5 | 0 | --- |
| 23:00 | 28.0 | 0.0 | 南南西 | 16.4 | 0 | --- |
| 22:00 | 28.0 | 0.0 | 南南西 | 17.3 | 0 | --- |
| 21:00 | 28.0 | 0.0 | 南南西 | 17.3 | 0 | --- |
| 20:00 | 28.0 | 0.5 | 南 | 19.4 | 0 | --- |
| 19:00 | 28.1 | 0.0 | 南 | 19.7 | 0 | --- |
| 18:00 | 28.5 | 0.0 | 南 | 18.8 | 0 | --- |
| 17:00 | 28.6 | 0.0 | 南 | 17.0 | 0 | --- |
| 16:00 | 28.6 | 0.0 | 南 | 16.7 | 0 | --- |
| 15:00 | 29.1 | 0.0 | 南 | 14.9 | 0 | --- |
| 14:00 | 28.8 | 0.0 | 南 | 13.7 | 0 | --- |
| 13:00 | 29.5 | 0.0 | 南 | 9.5 | 43 | --- |
| 12:00 | 29.5 | 0.0 | 南 | 11.8 | 34 | --- |
| 11:00 | 29.7 | 0.0 | 南 | 10.7 | 50 | --- |
| 10:00 | 27.8 | 0.0 | 南 | 8.2 | 0 | --- |
| 09:00 | 26.4 | 3.0 | 東 | 3.5 | 0 | --- |
| 08:00 | 25.2 | 4.5 | 南南東 | 0.9 | 0 | --- |
| 07:00 | 25.6 | 0.0 | 南南東 | 2.3 | 0 | --- |
| 06:00 | 25.0 | 0.0 | 東南東 | 2.1 | 0 | --- |
| 05:00 | 25.1 | 0.0 | 東 | 2.9 | 0 | --- |
| 04:00 | 25.1 | 0.0 | 南南東 | 1.6 | 0 | --- |
| 03:00 | 25.1 | 0.0 | 南南東 | 2.5 | 0 | --- |
| 02:00 | 25.0 | 0.0 | 南南東 | 2.0 | 0 | --- |
| 01:00 | 24.8 | 0.0 | 南南西 | 2.1 | 0 | --- |
長期間（〜１週間）停電
停電期間１週間ともなると、さすがに対応してるところ無いだろうと思ったが、セイコーマートが強すぎてワロタｗ
個人用装備だと以下かな。
毎日持ち歩くのにはちと重いけど、大容量モバイルバッテリー(10,000mAh以上)が1〜2個あれば、バッテリータイプ基地局が停波するよりも長持ちしそうだ。
スマホの省電力設定の方法がたくさんリツイートされていたけど、バッテリータイプ基地局の方はせいぜい24時間なので、スマホ本体電池を普通に使っていても十分な気もする。 ここら辺は後学のため実際にどうだったのか聞いてみたい。 結局は地域の基地局によるって話だろうけども。
p.s.
p.p.s
マキタ用語で言うと、マキタのバッテリーのUSB変換器って「バッテリーホルダー」って言うらしい。ベルトに装着できるクリップがあるからかな？ Amazonとかで検索するときは「マキタ バッテリーホルダー」で検索すること。
葛西臨海公園の近くの鉄橋上で線路が燃えたらしい。漏電かしら？復旧の目途は立っていない模様。
p.s.
なんと、京葉線は9/10始発から通常運転をしてのけた。いや、ちょっと期待してたｗｗｗ
自家消費型の太陽光発電とな
その後正確を期すため、家庭・企業が自家消費する太陽光発電分を除いて節電率を算出し直した。この結果、11日の節電率（午前8時半〜午後8時半）は当初発表の13．6〜25．7％が13．6〜17．2％に、12日は10．4〜20．2％が10．3〜19．7％に、それぞれ低下した。
北海道では最大10%くらい家庭・企業が自家消費する太陽光発電分があるのか。いつの間にそんなに普及してたんだ・・・。
今は売電価格(固定買取価格)が下がり続ける予定だったり、電気代が上がり続ける傾向が予想されていたり、ソーラーパネルのために野山を乱開発する事業者が絶えなかったりするせいで、 売電よりも自家消費太陽光発電が推されているらしい。
自家消費型の太陽光発電導入なら自治体から補助金が出るところもあるようだ。
（つか、自家消費なのになんで北海道電力は発電量把握できたんだろ？）
ソーラー業界的には固定価格買取制度が崩壊しそうなので、自家消費型に避難してるのね。
大容量モバイルバッテリーの類を常備している人なら、スマホだけは数日間耐えられる感じやね。
停電が数日を超えてくると、スマホだけ充電できても風呂とか色々困るけど、これ以上の対応は個人レベルだと難しいね。 充電池はコスト的にあわないから、燃料を備蓄した自家発電機とかになってしまう。
オレのAWSにLet's Encrypt設定 part2 (Ubuntu LTS 1804)
tag: ubuntu,letsencrypt
Amazon AWS Lightsailで使っているUbuntu LTS 1604 LTSから1804 LTS Bionicにアップグレードしたら Let's Encrypt 関連のプログラムが消えたようなので再設定。
# インストール。 https://certbot.eff.org/ に従う。 sudo apt-get update sudo apt-get install software-properties-common sudo add-apt-repository ppa:certbot/certbot sudo apt-get update sudo apt-get install python-certbot-apache # certbot --apache の場合、apacheの設定ファイルなどを自動的に変更する。 # 凝ったapacheの設定をしている場合は、sudo certbot --apache certonly とし、httpdの設定ファイルは手で変更した方が良いらしい # 実行すると、いくつか質問されるので、答えていくと設定完了。 # 今回は更新だけ行う。 sudo certbot --apache
自動更新設定
以下のシェルを作成。Ubuntu 1804版のcertbotは、apacheの停止、起動もやってくれる。
cat > ~/bin/certbot-renew.sh << "EOF" #!/usr/bin/env bash # # apacheの停止と起動はcertbot側で可能 # export LANG=C # 起動メッセージ echo "$( date ) certbot-renew.sh: started" # 証明書の更新。 sudo certbot renew RC=$? echo "$( date ) certbot-renew.sh: certbot renew first trial status: $RC" EOF chmod +x ~/bin/certbot-renew.sh
crontab -e で登録する内容。
毎週木曜日の5時17分にシェルを実行する。
PATH=/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin 17 5 * * 4 /home/ubuntu/bin/certbot-renew.sh
tag: gradle
オレのwikiは、これまでeclipseの動的Webプロジェクト(通称wtp)で作成していたが、これだとビルドの自動化とか依存ライブラリ自動取得とかやりにくいのでgradle化してみた。
wtpとgradleでは想定するディレクトリ構成が違うので色々手動でコピーする。
やっぱりというか、前回もそうだったけど jdk10 で FreeBSD機向けのjdk8用バイナリを作るには、--release 8 オプションが必須だった。（指定しないと動作しない）
gradle.buildファイルは以下のようになった。
plugins {
id 'war'
id 'eclipse'
id 'eclipse-wtp'
id 'org.gretty' version '2.2.0'
id 'java'
id 'application'
}
repositories {
jcenter()
}
// providedCompileは、tomcatとかから提供されるのでwarに含めないライブラリ
// compileはコンパイル時に必要なライブラリ
// testCompileは単体テストコンパイル時に必要なライブラリ
// runtimeは実行時に必要なライブラリ
// fileTree(dir: 'lib', include: '*.jar')は、lib/*.jarを探索して使うという意味。
// ただし、gradleのeclipse-wtp pluginはこれを理解できない。
// このため、eclipse-wtp pluginで作ったecilpse設定ファイルで動くeclipse J2EEセットに標準で入っている動的Webプロジェクト用のtomcatサーバとかは、実行時にこのライブラリの存在を認識できない。
dependencies {
providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
compile fileTree(dir: 'lib', include: '*.jar')
compile 'commons-io:commons-io:2.6'
compile 'commons-fileupload:commons-fileupload:1.3.3'
compile 'org.jsoup:jsoup:1.11.3'
testCompile 'junit:junit:4.12'
testCompile 'org.mockito:mockito-core:2.7.19'
runtime fileTree(dir: 'lib', include: '*.jar')
runtime 'commons-io:commons-io:2.6'
runtime 'commons-fileupload:commons-fileupload:1.3.3'
runtime 'org.jsoup:jsoup:1.11.3'
}
// Java Compiler Version 1.8 を指定する。
// openjdk9,10,11以前の書き方。openjdk9以降は、コンパイル時に --release 8 と書かないと動作しないケースがある。
// gradle の eclipse plugin, eclipse-wtp pluginは、この設定を見て eclipse 用の .project ファイルのコンパイラ準拠レベルを設定する
def javaVersion = JavaVersion.VERSION_1_8;
sourceCompatibility = javaVersion;
targetCompatibility = javaVersion; // defaults to sourceCompatibility
// Javaのコンパイル時オプション。
// ソースコードのエンコーディングは UTF-8
// jdk10を使っていて jdk8 向けのバイナリを作るなら --release 8 が必須
tasks.withType(JavaCompile) {
options.encoding = 'UTF-8'
options.compilerArgs.addAll(['--release', '8'])
}
// Javaコンパイルオプションの表示。 Test時と本番時の２回表示される。
tasks.withType(JavaCompile) {
println 'Compiler args: ' + options.compilerArgs
}
// ここでは、gradle run で動作する際のメインクラスを指定。
mainClassName = 'jp.co.tripod.javaballista.kjwiki.cmd.CmdLineMain'
// jarの内部のmanifestファイルにもメインクラスを指定。これで java -jar KJWikiG.jar を実行可能になる。
jar {
manifest {
attributes 'Main-Class': 'jp.co.tripod.javaballista.kjwiki.cmd.CmdLineMain'
}
}
// gradle appRun 時に使うコンテナを指定。このアプリはjettyでは動作しない。(JSPがあるので)
// use tomcat8 container
// https://github.com/gretty-gradle-plugin
// see https://gretty-gradle-plugin.github.io/gretty-doc/ Gretty documentation
// see https://gretty-gradle-plugin.github.io/gretty-doc/Gretty-configuration.html Gretty configuration
gretty {
servletContainer = 'tomcat8'
}
// Unitテスト中のstdout/stderrを表示する場合は以下
// gradle clean test --debug でも良いけど
//test {
// testLogging {
// outputs.upToDateWhen {false}
// showStandardStreams = true
// }
//}
使い方メモ
# ビルドと（テストと）起動 gradle clean build distZip tomcatRun # 単体テストがコケた場合は、単体テストだけ実行。--debugをつけて、単体テスト時のメッセージを表示。 # gradle test --debug # 初回や、外部ライブラリを追加した場合などは、eclipseの設定ファイルを作り直す gradle clean cleanEclipse cleanEclipseWtp eclipse eclipseWtp
eclipse J2EEでwarを作るなら、eclipse側からGUIで使用ライブラリを追加したり指定したりするが、gradleでコンパイルするのがメインの場合はeclipse GUIからは操作しない。gradleのプラグインからeclipseの設定ファイルを作らせる。
tag: gradle
オレ専用のgradle.buildファイルを作る時に参考にしたサイトを紹介。
Docker for Windows 18.06-ce 付属の kubernetes で Ingress Controller を作成
tag: docker-for-windows-18.06,kubernetes
Docker for Windows CE にも 18.03以降は Kubernetes サポートが入ったけど、Ingressとか無いとminikubeより不便な感じはある。
ぐーぐる先生に聞いてみたところ以下の記事がヒット。
こちらでもやってみる。
まずはIngressの準備。
# 一応内容見物 # curl -v https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml # curl -v https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml # nginx-ingress-controllerをkubernetesにインストール # ネットに落ちてる設定ファイルを指定してインストールできるのは便利と言えば便利だなぁ... # なお、docker for windows 18.06-ceで実行した場合、Windows PCのポート80,443が使用されるので、PC上でhttpdとか動作させていないことが前提。 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml
オレwikiをhost名で振り分けするため、管理者権限で起動したメモ帳(notepad.exe)で、C:\Windows\System32\drivers\etc\hostsに以下を追加。
# docker for windows ingress controller 127.0.0.1 kjwikigdocker.minikube.local
オレのwikiをkubernetesにインストールする呪文を唱える。
cat > kjwikigdocker.yaml << "EOF"
---
# Source: kjwikigdocker/templates/pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: kjwikigdocker
labels:
app: kjwikigdocker
chart: "kjwikigdocker-0.1.0"
release: "kjwikigdocker"
heritage: "Tiller"
spec:
accessModes:
- "ReadWriteOnce"
resources:
requests:
storage: "3Gi"
---
# Source: kjwikigdocker/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: kjwikigdocker
labels:
app: kjwikigdocker
chart: kjwikigdocker-0.1.0
release: kjwikigdocker
heritage: Tiller
spec:
type: ClusterIP
ports:
- name: kjwikigdocker
port: 8080
targetPort: kjwikigdocker
protocol: TCP
selector:
app: kjwikigdocker
release: kjwikigdocker
---
# Source: kjwikigdocker/templates/deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: kjwikigdocker
labels:
app: kjwikigdocker
chart: kjwikigdocker-0.1.0
release: kjwikigdocker
heritage: Tiller
spec:
replicas: 1
selector:
matchLabels:
app: kjwikigdocker
release: kjwikigdocker
template:
metadata:
labels:
app: kjwikigdocker
release: kjwikigdocker
spec:
containers:
- name: kjwikigdocker-container
image: "georgesan/kjwikigdocker:latest"
imagePullPolicy:
ports:
- name: kjwikigdocker
containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /
port: kjwikigdocker
readinessProbe:
httpGet:
path: /
port: kjwikigdocker
volumeMounts:
- name: data
mountPath: /var/lib/kjwikigdocker
subPath:
resources:
{}
volumes:
- name: data
persistentVolumeClaim:
claimName: kjwikigdocker
---
# Source: kjwikigdocker/templates/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kjwikigdocker
labels:
app: kjwikigdocker
chart: kjwikigdocker-0.1.0
release: kjwikigdocker
heritage: Tiller
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 1560m
spec:
rules:
- host: kjwikigdocker.minikube.local
http:
paths:
- path: /
backend:
serviceName: kjwikigdocker
servicePort: kjwikigdocker
EOF
kubectl apply -f kjwikigdocker.yaml
ingressの設定確認。
george@KabyLakeS /c/home/git/kjwikigdocker/helm-chart $ kubectl get ingress NAME HOSTS ADDRESS PORTS AGE kjwikigdocker kjwikigdocker.minikube.local localhost 80 22m george@KabyLakeS /c/home/git/kjwikigdocker/helm-chart $
動作チェック
curl -v http://kjwikigdocker.minikube.local/ curl -v http://kjwikigdocker.minikube.local/kjwikigdocker/ # これは HTTP 302 リダイレクトが返却されればOK
おお。動いてる。
docker for windows 18.06-ce の場合、 謎のテクノロジーで Windows PC の port 80,443 への通信を Hyper-V上で動作している MobyLinuxVM の中の nginx-ingress-controller の port 80,443 に転送してくれているようだ。
apacheのバーチャルホスト設定とか、nginxのバーチャルホスト設定みたいに、ホスト名だけ変えれば色々なサービスに振り分けを行ってくれるので、 kubernetes上に複数のサービスを起動して使うことも可能になった。 (NodePortはポート番号を覚えるのが面倒くさい...)
mstdn.jp きぼうソフトに譲渡
jp鯖創設当時はバカ騒ぎしてて結構楽しかったゾ
なお、追悼（？）タグが続いててちょっと衝撃。（ハッシュタグが長続きしない鯖だったので）
京葉線は１８時以降運転見合わせ。
首都圏のＪＲ東日本の電車は全路線で２０時以降運転見合わせ。
東京メトロ東西線の地上区間は２１時以降運転見合わせ。
何やら大変なことになってきました。
NHKは大河ドラマの放送止めて台風２４号ニュース流してる。
アメダスの江戸川臨海地点の風速。１０分単位でモリモリ上がっていくのはやはり台風ならでは。
| 日時 | 気温(℃) | 降水量(mm) | 風向(16方位) | 風速(m/s) | 日照時間(分) | 積雪深(cm) |
| 22:00 | 26.3 | 0 | 南南東 | 15.2 | 0 | --- |
| 21:50 | 26.1 | 0 | 南南東 | 14.7 | 0 | --- |
| 21:40 | 25.8 | 0 | 南南東 | 13.2 | 0 | --- |
| 21:30 | 25.8 | 0 | 南南東 | 13.2 | 0 | --- |
| 21:20 | 25.5 | 0 | 南南東 | 12.6 | 0 | --- |
| 21:10 | 25.6 | 0 | 南南東 | 12.8 | 0 | --- |
| 21:00 | 25.5 | 0 | 南南東 | 13 | 0 | --- |
| 20:50 | 25.6 | 0 | 南南東 | 13.1 | 0 | --- |
| 20:40 | 25.1 | 0 | 南南東 | 12.3 | 0 | --- |
| 20:30 | 25.1 | 0 | 南南東 | 12.4 | 0 | --- |
| 20:20 | 24.9 | 0 | 南南東 | 11.9 | 0 | --- |
| 20:10 | 24.6 | 0 | 南南東 | 11.2 | 0 | --- |
| 20:00 | 24.6 | 0 | 南南東 | 10.3 | 0 | --- |
| 19:50 | 24.2 | 0 | 南南東 | 9.4 | 0 | --- |
| 19:40 | 24.2 | 0 | 南南東 | 8.8 | 0 | --- |
| 19:30 | 23.8 | 0 | 南東 | 5.6 | 0 | --- |
| 19:20 | 23.9 | 0 | 東南東 | 5.7 | 0 | --- |
| 19:10 | 24 | 0.5 | 東南東 | 5.7 | 0 | --- |
| 19:00 | 23.4 | 0 | 東 | 3.5 | 0 | --- |
オレの経験則では、江戸川臨海地点で風速10m超えると京葉線は徐行運転になり、風速15mを超えると運転見合わせとなる。今日は19時あたりで最終電車になってたけど。
NHKは22時ごろから昔のニュースのリピート放送になってる。働き方改革で夜の時間帯は新しい情報を仕入れない模様。
p.s.
台風一過の翌日、始発から通常運転の予定とか言ってた鉄道各社は壊滅してた。
417,717bytes
日曜日の夜２０時から首都圏の鉄道をあらかじめ一斉に止めるというのは過去に例がないことで、これはまあ上手くハマったけど、 台風の翌日の対処は微妙だったｗ
非常に強い台風が通過した場合、がけ崩れ、電柱が折れる、倒木、倒竹、ブロック塀が線路内に倒れ込み、 架線にビニールが引っかかる、大規模停電のため電車動けず、などなど色々あるんだな。
横須賀線の武蔵小杉駅ではドア点検＋急病人４人連続発生で４５分停車とか、急病人わんこそば状態だったらしい。 台風一過で気温が上がった状態でのすし詰め電車は意外に危険だ。
日本列島を西からなぞる台風の場合、東海道線が深刻なダメージを受けて沈み、 東京〜品川あたりで並走する京浜東北線、山手線、横須賀線、京浜急行線は振替輸送による混雑のため沈む。
東海道線と横須賀線は台風の翌日も終日gdgdだったのも教訓にして良いかもしれない。
今回は沖縄、静岡、神奈川で大規模停電が発生、長い所だと３〜４日は停電が続きそうというのも台風の教訓かな。
変わったところでは海から10kmくらいまでの電柱では、海から飛ばされた塩で通電後に火災になるケースもあるとか。
非常に強い台風(風速44m/s〜54m/s)は本当に強かった。
p.p.s.