リモートワークのために買ってみたモノ（キーボード/マウス編）
ノートPCを使っていると下を向くことになって首によくない気がしたので、ノートPCを正面に置きつつキーボードを手元に置いた方がいいんでは？と思いつつ、キーボードだけだとカーソル移動とかに困るしなと思ったのでキーボードとタッチパッドがセットになってるMS All-in-One Media Keyboardを購入してみることに。
（ノートPCのキーボードが微妙に取りこぼす感じがあった、というのもある）
キーボードとタッチパッドそのものは特に問題ない感じだったのだけど「膝の上で使う」とタッチパッドが右にあるゆえにキーボードが左寄りになり非常に使いづらい。普通に机やテーブルの上で使うなら問題なかったのかもしれないけど、膝の上で使うのが必須だったので…。
というわけで、残念ながらお蔵入りに。
2回目の緊急事態宣言の時には大人しくワイヤレスのキーボード＋マウスにしようと思いつつ、ドングルを付けるのもイヤだったのでbluetoothのものを色々探してみたところ、適当に安価なものが意外にない。
いや、安価なbluetoothキーボードはあるのだけどそれらは基本的にスマホ向けであって普通のPC向けなのがないと言うべきか。
メカニカルキーがいいとか贅沢言わなきゃなんとかなるだろと思ってたけど、メンブランタイプはエレコムのくらいしか見つからず。
（探せば他にもあったのかもだけど）
値段的には手頃だったのでこれを購入。特に気になる点はなく、割といい感じ。
（そういやペアリング切り換えボタンは普通のキーに割り当ててあるけど、Fn+でペアリングにしたほうがよかったんでは？と思わなくもない。が、それで特に困ったりはしていない）
マウスはbluetoothのならどれでも適当に買えばいいだろと思ってたけど、キーボードがマルチペアリングだったのでマウスもそうしようと思ったら、マルチペアリング対応のbluetoothマウスが意外にない。
色々探していたらサンワサプライの折りたたみマウスがマルチペアリングに対応してるっぽい。昔使ってたMSの変形マウスは割と気に入ってたし、多少作りは安っぽいけどこれもアリでは？と思い購入。
使ってみた感じはなかなかよい。
気になる点があるとすれは乾電池ではなく充電池である点と、PCに表示されるバッテリ残量がどうにもあてにならない点。満充電にしてるつもりでも55%と表示されたり、頻繁に「バッテリ残量が少ないです」とアラートが出るんだよね…。本当にバッテリーが切れる前に充電できるんだろうか。
リモートワークのために買ってみたモノ（座布団/クッション編）
自宅は椅子がなく、座りっぱなしだとお尻が痛くなったので最初の緊急事態宣言の時に色々買ってみたけどどれもイマイチだった。
2回目の時にテレビ通販でハニカムクッションの宣伝をしていて「そーいや先日ドスパラで似たようなの見かけたな」と思い試しに購入。
（買ったのは「フィットハニカムジェルクッション」）
最初に見かけたときに触ってみたところ硬い感じがしてどーなんじゃろと思ってたけど、これがなかなか具合がいい。前に買ったクッションは柔らかすぎて潰れてしまいクッション効果があまりなかったんだから、触ったときに多少硬いくらいがいいんだろう。
テレビ通販で「2枚重ねるとより効果がある」的なことを言ってたので、追加で購入してみたり。
価格.comを見たら似たようなのが色々あるみたいなので、もっと安いのでもいいのかもしんない。
なお、最初に買ったクッション色々については、背中のクッションとして利用している。
あまりに洗濯できないので『梅雨どきどき洗濯』ゲームを考えた。
ここんとこあまりに天気が不安定で洗濯するのが大変なのでゲームを作ってみた。
概要
- 雨が降ってないタイミングを狙って洗濯物を乾かそう！
- 洗濯物を干すタイミングは夜と昼の1日2回
- 夜はちょっと乾きにくいぞ
- 洗濯物は毎日1つ溜まっていくぞ
- 乾かせずに8日分溜まると着替えがなくなってそこで終了だ
必要なもの
用語など
「天気」
- 1: 晴天
- 2: 薄曇り
- 3: 曇り
- 4: 小雨
- 5: 雨
- 6: 土砂降り
「カード」の種類と効果
- A: 必ず晴天になる
- J: 「天気」が晴天の時は土砂降りに、土砂降りの時は晴天になる。他の時は変わらない
- Q: さいころを振って出た目の「天気」になる
- K: 必ず雨になる
- ジョーカー: ターン終了後に今まで使ったカードを全て混ぜてシャッフルしなおし、新しい山札にする。「天気」は変わらない
- 上記以外の数字札（赤）: 数字札のハートとダイヤは、「天気」が1段階よくなる（1減る）。ただし、晴天の時は晴天のまま
- 上記以外の数字札（黒）: 数字札のハートとダイヤは、「天気」が1段階悪くなる（1増える）。ただし、土砂降りの時は雨になる
- 土砂降りのままでもいいかもしれない。要検証
「チップ」
- 溜まっている洗濯物をあらわす
プレイ方法
準備
- カードをシャッフルし、山札を作る
- プレイヤーはチップを1枚取る
- さいころを振って最初の「天気」を決める
ターン進行
- プレイヤーは各人チップ（洗濯物）を1枚取る
- 8枚になったらそのプレイヤーは終了
- カードの山札から4枚取って伏せて並べる
- 夜1→夜2→昼1→昼2 としてめくり、それに合わせて「天気」が変化する（後述）
- 「予報」として3枚目（昼1）をめくる
- 何枚目をめくるかはさいころで決めてもいいかもしれない
- 天気予報を参考にしつつ、洗濯をいつどれくらい干すかを決め、その数のチップを出す
- 夜に干す（最大3つ）、昼に干す（最大3つ）、干さない、を選ぶ。手持ちのチップ以上は干せない（出せない）
- 対戦の場合、全員同じ干し方ができないように制限/上限を付ける
- 例: 洗濯物の合計数を「プレイヤー人数 ×3 +3」を上限にする（プレイヤー2人なら9つまで、プレイヤー3人なら12まで）
- 干すタイミング（夜/昼）と数を全員決めたら、「カード」を順に 夜1→夜2→昼1→昼2 としてめくる
- 「カード」効果に合わせて変化した「天気」をメモしていく
- 「夜1夜2」の「天気」に1つでも「小雨」「雨」「土砂降り」があれば洗濯失敗でチップがプレイヤーに戻る。
- 「昼1昼2」の「天気」に1つでも「雨」「土砂降り」があれば洗濯失敗でチップがプレイヤーに戻る。「小雨」が2つの時は洗濯失敗、「小雨」が1つの時は洗濯成功
- 洗濯が成功した時は、洗濯の数に応じてスコアになる
- 3つ→6pt、2つ→3pt、1つ→1pt
- ※このあたりは要調整かも
- 以上でターン終了
- これを15ターン（半月）とか30ターン（1ヶ月）とか繰り返し、スコアを競う
対戦ルール
- 複数人でプレイする場合は、親を決める
- 親はターン毎に右回りで次の人に移る
- 「天気予報」のさいころは親が振る
- 「洗濯」は親から順番に決める
拡張ルール
布団干し
- 1ゲーム中1回チャレンジ可能
- 昼のみ干せ、「小雨」1つでも失敗になる
- 成功するとスコア+10pt
- 失敗時はスコアを-3ptにし、成功するまでチャレンジ可能にするのもアリかも
- 対戦時は、誰かが「布団干し」した時は他の人は「布団干し」できない
天気予測（主に対戦向け）
- 準備の時、各プレイヤーに「カード」を数枚配る
- 「予報」のあと、親は好きな位置に1枚、手持ちのカードを置くことができる（その効果が現れる）。
- 「予報」を上書きしてもよい
- NGなルールにするのもアリかもしれない
- カードを使わなくてもよい
- 親が使わなかった時に、次の人が「天気予測」できてもいいかもしれない
明日・明後日の予報
- ターンの最初に4枚ではなく、4枚×3セット並べる
- 2セット目は明日、3セット目は明後日のものとして使われる
- 「予報」は明日（2セット目）と明後日（3セット目）も1枚ずつ開く
- 拡張ルール「天気予測」は当日（1セット目）にのみ適用可能
- ターン終了時は当日（1セット目）を破棄し、2セット目以降が繰り上がる。翌ターンは3セット目を追加して「予報」を開く
- ジョーカーが出た場合、2セット目以降も破棄される。翌ターンは3セット分カードを並べ、「予報」を開く
- ※3セットではなく、2セットや5セット使うのもありかもしれない
洗濯は大変なので1日1回
- 夜3つ昼3つではなく、夜か昼に4つまでにする
- 1日の最大数が6→4になるので、溜めるとリカバリーしにくくなる感じ
- 4つで成功した場合は9pt
FreeBSDのHASTを触ってみた。
FreeBSDのHASTを触ってみた。
こういうのは最近ならQiitaあたりに書いた方がいいんだろうけど。
特徴など
- ストレージをBlock Deviceレベルで同期
- 実際にファイルを扱うにはBlock Deviceに対してufsやZFSでフォーマット/マウントする
- PrimaryからSecondaryへの同期
- 同時利用はできない
- 基本的にはActive-Standbyとして利用
- 同期対象サーバの変更は可能
- /etc/hast.confを修正し、service hastd reload で無停止で変更可能と思われる
- サイズの拡張はできない
- FreeBSD 11.0では標準で利用可能
- マニュアルなど
- https://www.freebsd.org/doc/handbook/disks-hast.html
- http://www.jp.freebsd.org/cgi/mroff.cgi?sect=8&cmd=&lc=1&subdir=man&dir=jpman-11.0.2%2Fman&subdir=man&man=hastd
- http://www.jp.freebsd.org/cgi/mroff.cgi?sect=5&cmd=&lc=1&subdir=man&dir=jpman-11.0.2%2Fman&subdir=man&man=hast.conf
- http://www.jp.freebsd.org/cgi/mroff.cgi?sect=8&cmd=&lc=1&subdir=man&dir=jpman-11.0.2%2Fman&subdir=man&man=hastctl
インストール・設定
- インストールは特に必要なし（FreeBSD 11.0）
- 設定ファイル: /etc/hast.conf
replication memsync
resource shared1 {
local /dev/vtbd1p1
on host1 {
remote 192.168.0.102
}
on host2 {
remote 192.168.0.101
}
}
resource shared2 {
local /var/hast/shared.img
on host1 {
remote 192.168.0.102
}
on host2 {
remote 192.168.0.101
}
}
- replicationはmemsyncがデフォルト、fullsyncが安全で遅い
- execでイベント発生時にプログラムの実行が可能
- ブロックデバイスを利用する場合はそのまま指定する
- パーティションは切っておいたほうがよいと思われる
- サイズを一致させるため
- ストレージのサイズが大きくなった時（仮想環境など）に後ろのブロックを利用するため
- パーティションは切っておいたほうがよいと思われる
# gpart create -s gpt vtbd1 # gpart add -t freebsd-ufs -s 10G vtbd1 # gpart show vtbd1
- ファイルを使う場合は必要なサイズのファイルを作る
# mkdir /var/hast # dd if=/dev/zero of=/var/hast/shared.img bs=10m count=1024
- ※ただし、ファイルを使った場合に問題が生じるケースがある模様
- ブロックデバイスにしろファイルにしろ、サイズが不一致の場合は同期できない
- /var/log/messagesにエラーが残る
- 逆にサイズさえ合っていればブロックデバイスとファイルとの同期もされる模様
hastctl による操作
- 初期化
# hastctl create shared1
- create でリソースを初期化する
- 初めてアクセスする前に実行する
- 問題が生じて再初期化時にも利用
- 状態変更
# hastctl role primary shared1
- role primary 時に /dev/hast/{リソース名} にアクセス可能になる
- 同時に両方primaryにできる（排他制御などはしてない模様）
# hastctl role secondary shared1
- role secondary にすることで、primaryと同期される
- hastd起動時はrole init なので、secondaryにする必要がある
- 状態確認
# hastctl status shared1 # hastctl list shared1
- 同期の状態などを確認可能
- Split-brainになった場合
- /var/log/messages にSplit-brainを検知した旨と対象のリソース名が残る（Primary Secondary共）
- Split-brain時にconfのexecで指定したものが起動されるので、そこで対応は可能（ただしSplit-brain時以外にも呼ばれる）
- セカンダリ側で下記を実行すると復旧する：
- /var/log/messages にSplit-brainを検知した旨と対象のリソース名が残る（Primary Secondary共）
# hastctrl role init {リソース名} # hastctrl create {リソース名} # hastctrl role secondary {リソース名}
状態について
- roleはinit, primary, secondaryの3種類
- role initの時は動作していない
- role primaryの時に /dev/hast/{リソース名} として参照可能になる
- role secondaryの時にprimaryからの同期データを受信している
- role primaryの排他制御などはしていないらしく、同時にprimaryにしてしまうことができる
- これを回避する方法は特にない？（primaryに変えるときに注意するしかない？）
- 切替え時には両方をsecondaryにしてから、片方をprimaryにする必要がある
- 両方primaryにするとhastdが刺さった状態になる模様。プロセスをkillする必要がある。
# kill -KILL `cat /var/run/hastd.pid`
- hastctl statusでcompleteになっていても、同期は完了していない模様
- hastctl listで表示されるdirtyが0になった時に完了している？
- HASTデバイスを利用するサービスはrc.confで有効にしないほうがよい
- role primary ＆ mount後にアクセスする必要があるため
- 上記でアクセス可能になったあとでservice {サービス名} onestart で起動
- 起動時はrole initのため、なんらかの方法でrole secondaryにする必要がある
- CARPを使った事例ではcarpの状態変更に合わせてroleを変更する
- pacemaker + corosyncでの対応もおそらく可能
- ※corosyncのports/pkgが動かなくて未検証
ファイルシステムについて
ufsで利用する場合
- 初期化
# newfs -U -j /dev/hast/shared1
# hastctl role primary shared1 # fsck -y -t ufs /dev/hast/shared1 # mount -o noatime /dev/hast/shared1 /mnt/shared # application_start
ZFSで利用する場合
- 初期化
# zpool create hast-zfs /dev/hast/shared2 # zfs create -o mountpoint=/mnt/shared hast-zfs/shared
- role prymary以外にする時にzpool exportしておかないと問題が生じる
- また、zpool exportしておかないとshutdownに失敗する（どこかで刺さっている？）
# zpool export hast-zfs # hastctl role secondary shared2
- zpool import時は正常にexportされていない可能性があるため（ダウン時のリカバリ等）、-fオプションを常に付けたほうがよいかもしれない
# hastctl role primary shared2 # zpool import -f -d /dev/hast/ hast-zfs
- 異常終了時はzpool exportされていないため、zpool statusを見るとstate:UNAVAILになっている
- この時はzpool exportしておいたほうがよいかもしれない
- exportしていないときにrole primaryになると自動的にONLINEになる（mountはされない）
簡易ツール
dirtry値のチェック
#!/bin/sh # check options while getopts aq opt do case $opt in a) option_all=1 ;; q) option_quiet=1 ;; esac done # target resources shift $(($OPTIND - 1)) if [ "$*" ]; then resources="$*" else resources=$(/sbin/hastctl dump | /usr/bin/awk '/^ *resource: / {print $2}') fi # view dirty dirtycount=0 for res in $resources; do dirty=$(/sbin/hastctl list $res | /usr/bin/awk '/^ *dirty: / {print $2}') [ $dirty -ne 0 ] && dirtycount=$(($dirtycount + 1)) [ $option_quiet ] && continue if [ $dirty -ne 0 -o "$option_all" ]; then echo "$res $dirty" fi done exit $dirtycount
- オプションなしの場合、dirty値があるリソースとそのdirty値が表示される
- オプション-aでdirty値がないリソース（とそのdirty値）も表示される
- オプション-qで何も表示しない
- リソース名を渡すと、そのリソースのみチェックする
- 終了ステータスにdirty値があるリソースの数を返す
Sprit-brain時の同期状態リセット
#!/bin/sh syslog_facility="user.notice" syslog_tag="hast-event" logger="/usr/bin/logger -p $syslog_facility -t $syslog_tag" resource=$1 [ $resource ] || exit 1 # check role secondaryj roletype=$( /sbin/hastctl list $resource | /usr/bin/awk '/^[\t ]*role:[\t ]+/ {print $2}' ) [ "$roletype" = "primary" ] && exit # recover $logger "HAST [$resource] recover" /sbin/hastctl role init $resource /sbin/hastctl create $resource /sbin/hastctl role $roletype $resource
- リソース名を渡すと、そのリソースの同期状態をリセットする
- ただし、role primaryの時は何もしない
- role init の時はrole secondaryに変更しないため、そのままでは同期されない（role secondaryに変更する必要がある）
そもそも「広いメディア」ってそんなにあるのかな？
そもそも「広いメディア」ってそんなにあるのかな？
この記事を読んで違和感があって気になってたのですが、そもそもこの記事で言う「広いメディア」ってかなり特殊な存在のような気がします。
例えばテレビを「広いメディア」としているけれど、ほとんどの番組はターゲティングされている＝「狭い」ような気がしますし、ここで言われている「広いメディア」に該当するのは「テレビ・ラジオのニュース番組」くらいじゃないでしょうか。
（新聞＝広いメディアというのは一般紙のみしか念頭にない思考でしょう）
そういう意味では「広いメディア」「深いメディア」という区分けをしてもあまり意味がない気がするんですよ。
あの記事で分けるべきはおそらく広い/深いではなく「ニュース（速報性・時事性があるもの）」と「ニュース以外」なんじゃないでしょうか。
ニュースサイトは比較的記事の量産が可能なため、「狭い」ニュースサイトは昔から沢山成立しているわけです（例えばImpress Watch等）。対して、ニュース以外で記事を量産しようとした結果がまとめ（キュレーション）サイトだったように見えるんですよね。
（なので、僕は広さよりも時事性で分けた方がしっくりきます）
またあの記事では雑誌を「深い」としていますが、実際の雑誌はターゲッティングしている（＝狭い）うえで、雑誌によって「浅い」ものもあれば「深い」ものもあるわけです。
（深い/浅いという言い方よりも「軽い」「重い」と言った方が通じるかもしれません）
そういう意味では「MERY」が（狭い）ターゲットにちゃんと刺さっていたのは間違いないものの、別に「深い」メディアにはなってはいなかったんじゃないかと思うんですよね。雑誌として見た場合にはおそらく「軽い」に分類される雑誌だったんじゃないかという気がしますし。
（実際にMERYの記事を分析できてはいないので、実際にどうだったのか分からないのは残念なところです）
そんなわけで徳力さんが今後も「広い」「深い」という方向性で分析を進めていくのであれば、おそらく全然役に立たない分析になるんじゃないかな？という気がしています。
「雑誌」ってなんだ？
「雑誌」ってなんだ？
雑誌にまつわるネタをいくつか見つけて「そういや以前雑誌について書きかけてなかったっけ？」と思い確認してみたら、4年前（2013年）じゃないですか。しかも当時も「3年前（2010年）に書きかけて」とか書いてて、本当に酷い（笑）。
そんなわけで改めて「雑誌」について書いてみよう。
雑誌の要件
そもそも「雑誌」に求めるものってなんだろう？ と改めて考えてみたところ、下記が揃っていて欲しいと感じました。
- 定期刊行されていること
- 特定ジャンルに特化していること
- 連載があること
- 特集があること
- 複数の著者がいること
これらの要素が揃っていないとあまり「雑誌」のような感じがしません。例えば『群雛』を雑誌的に思えず、（昔からの意味での）「同人誌」のように感じたのは、上記要件のいくつかが欠けていたからのような気がします。
（そういう意味では著者達の作るネットワークをまとめたものは同人誌的であり雑誌のようになる気があまりしません）
（つづく）
