目次
03日 令和
03日 ServiceWorker と indexedDB
04日 Minit
05日 パソコン壊れた
08日 続：Minit
14日 パソコンは買ったのだが…
17日 洗濯機壊れた
20日 Nexus7 (2012) 復活
21日 あーすフェスタ
23日 洗濯機来ました
27日 Huawei
27日 qmail 入れ直し
28日 ビートウォッシュ 追加レポート
29日 Alexa Wunderlist 連携
30日 久しぶりの飲み会
31日 契約解消
タイトルは内容と無関係。
とりあえず、天皇が代替わりして元号が変わりましたよ、という記録として。
そして、記録なので、多くの人が知っているあたりまえのことの説明から始める。
さて、長すぎるゴールデンウィーク。
今年は代替わりの影響で、天皇誕生日がない。
そこで、即位の日である５月１日が祝日に設定された。
４月２９日は昭和の日で、５月３日は憲法記念日で祝日だ。
ここで、５月１日が祝日になると、「前後を祝日に挟まれた日は休日」というオセロのようなルール（国民の祝日に関する法律 第三項第三条）によって、４月３０日と５月２日は休日となる。
このオセロルール、もともとは憲法記念日の５月３日と、こどもの日の５月５日に挟まれた５月４日を休日にするために作られた。
1985年、バブルのころに作られた法律だ。
当時は、日本人は働きすぎだ、と思われていた。一方で、バブル景気で長期休みを取って旅行する人も多かった。
そこで、休日を増やせば旅行などで消費が増え、一石二鳥！ と作られた法律だ。
その後、同じような考えで連休を作り出すためにいくつかの祝日が、日付固定から「月曜日」に移動され（いわゆるハッピーマンデー法案：1998年成立）、その結果、本来は離れていた敬老の日と秋分の日が近くなり、上に書いた「祝日に挟まれた日は祝日」ルールが不意に発動したりするようになった。
ちなみに、日本は世界的に見ても祝日が多い、「平日」が少ない国だそうだ。
働きすぎだと言われるのは、休日がないからではなく、休日でも働いたり残業するのが当たり前だったりする雰囲気が作られているからだ。
休日を増やしたからと言って働きすぎが解消されるわけではない。
いきなり話がそれ気味だが、毎年ゴールデンウィークには有給休暇を混ぜて長い連休を作る人がいる。
しかし、今年はそんなことをせずとも、カレンダー通りで１０連休となった。
…休みが長すぎて、「そんなに休んでいるわけにはいかない」と働いている人・働かざるを得ない業界続出だけどな。
通常のゴールデンウィークなら、有休を使って連休に「する人もいる」だけなのである程度緩急があり対応しやすいが、今年はみんな連休だから。
かくいう僕も、２４時間稼働しているサーバー関連のお仕事もしているために、ゆるく仕事を頼まれていたりする。
管理をお手伝いしているあるサービスでは、５月１日に内容更新があった。
プログラム変更を伴ったので、僕も作業した。
そしたら、管理担当者は、いつも西暦で書いている「更新情報」に、いきなり「令和元年５月１日更新」って書きやがった。
まぁ、書きたくなる気持ちはわかる。次回からはまた西暦に戻すそうだ。
こんなゴールデンウィーク中に出かけたら、混みすぎていて楽しめないだろう…と、我が家ではどこにもいかないよ、と子供にあらかじめ宣言してあった。
その代わり、家の中で楽しめそうなことはする。
一応、「どこか行きたい」という気持ちの対策として、４月２１日の次女の誕生日にはキッザニアに行ってあるしね。
２６日には、長女の誕生日パーティも家でやっている。
２９日は、妻が家の庭の手入れなどしつつ、庭でバーベキュー。
焼き鳥 50本と、ハーブ入りフランクフルトを買ってきた。買いに行ったら、スーパーがいつもより混んでいて驚いた。
３０日、出かけないといいつつ、陽光台にある子供宇宙科学館へ。
この日は雨だったし、祝日ではなく「休日」だったので、多少人出が少ないだろうと思ったんだ。
でも、朝早くから出て、１０時過ぎには到着した。
科学館は９時半オープンなのだけど、入り口前に行列ができていた。
科学館に行ったのは、以前から長女が行きたがっていたから。
また、次女が小学校でもらってきた科学館のチラシに、「暦」をテーマにした小さなイベントをやると書いてあったから。
（僕は暦好きです。チラシを見ただけで内容はだいたい想像できたけど、知らないこともあるかもしれないので見てみたかった）
行列が長くて入れそうにないし、雨も降っているので、すぐ近くのどんぐりハウスへ。
小学生の向けの無料施設で、本来は両親共働きの小学生が、放課後に大人の保護下で遊んで待つことができる施設だ。
実は、長女が「科学館に行きたい」と言っていた理由の半分は、こちらに来たかったからだ。
すぐ隣の施設なので、行くときはセットで考えていたのだな。
子供が遊んでいる間に、妻が科学館の様子を見に行ってくれた。
人が多すぎて入場制限をしているようで、列はさらに伸びた、と報告。
２時間弱遊んだが、あきらめて帰ることにする。
子供の洋服が少し足りない感じなので、デパートに行って買い物して帰ろう。
…というわけで港南台に行ったら、駐車場が混んでいてなかなか入れない。
みんなで車に乗っているのは無駄なので、妻と子供にはおりてもらい、先に昼ご飯を食べててもらう。
30分ほどかけてやっと駐車し、合流。僕も軽く食べて買い物へ。
ユニクロに行ったら、スプラトゥーンＴシャツを売っていた。
子供も欲しがるので、良し買うか！ と子供コーナーに行ったら、売り切れていた。
あるのは大人用のみ。
ネットで調べたら、ネット店舗ではまだあるようだ。ネットで買うことにする。
（夜、家族全員分を買った。５千円分買わないと送料かかるから。）
それ以外に、長男の服が足りないので数着購入。
この日は、以上。どこ行っても混んでいる、と分かったので家に帰って夕食食べました。
夕食は、パーティー気分で…残っていた焼き鳥などを適当に。
５月１日は、先に書いたように僕の仕事があったのでどこも出かけず。
５月２日は、長女・次女が歯医者に行かねばならなかったので、歯医者以外出かけず。
鎌倉の歯医者に行くのは、きっと道が大渋滞だろう、と恐怖でしかなかったのだが、案外空いていた。
でも、人混みはすごかった。
鎌倉だから、多くの人は車で来るのではなく、東京から電車で来るのだね、と行ってから気づいた。
以上、昨日分までの日記でした。
このほかに、隙間時間を見ながら仕事のプログラムをしていて新しい知見を得たので、次にそのことなど書く。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
「ゴールデンウィーク明けにはリリースしたいので、その前までにお願いね」
と言われていたプログラム改良があった。
その改良は、ちゃんと四月半ばまでに仕上げた。
WEB ブラウザ側で動く Javascript のプログラムだったのだけど、同時にサーバー側も変更することになっていた。
サーバー変更は僕の仕事ではなかったのだけど、そちらが間に合っていない。
急遽、Javascript 側で何とかできないかと、ゴールデンウィーク直前に ねじ込まれた。
目的は、URL の一部隠蔽だ。
ブラウザ側プログラムの改良により、画面遷移が一段階へり、目的画面の URL が変わることになった。
この URL にはセッション情報が含まれており、見えているのが好ましくない。
そこで、セッション情報を URL に入れるのではなく、POST にするか、Cookie にするなどして、消すことになっていた。
つまり、これらはサーバー側の改良だ。
それができなくなったので、Javascript 側でどうにかならないか、というのが、追加の依頼だった。
セッション情報はややこしい文字列になっているので、長い時間表示されているのでなければ、一瞬なら出てもよいという。
つまり、セッション情報付きの URL でアクセスしてから、取得したページの Javascript の中ですぐに URL を変更し、消せればいいということだ。
ただし、該当ページは都合上、時々リロードする場合がある。
セッション情報なしではサーバーにアクセスできないので、リロードする際にはすぐに URL を元に戻したい。
URL を変更するのは簡単だ。history.replaceState 関数を使うと、現在アクセス中として表示されている URL を変更することができる。
いわゆる ajax …画面遷移を伴わないサーバーアクセスを行うようなプログラムで多用されているテクニックだ。
だから、セッション情報がない URL にすることはできる。
この時に、本来の URL を変数に保存しておいて、リロードの際に元に戻せればいいだろう。
しかし、javascript に「リロードイベント」というのは存在しない。
＃イベントとは、「何かが起きた」とプログラムが知ることができる、概念上の存在。
Javascript では、特定のイベントに対してプログラムを紐づけることができ、紐づいたプログラムは、イベントが起きると自動的に実行される。
これにより、イベントが生じたらプログラムを動かす、ということが可能になっている。
リロードされたかどうかを知る方法はあるのだが、それはリロードされた「あと」のページで検知できるだけだ。
そして、リロードの際には表示している URL にアクセスが行くので、そのままではセッション情報がないためにサーバーから拒否される。
リロード「あと」のページの表示自体が行えない状態で、リロードに伴う不都合をこの方法で解消することはできない。
「ページが終了した」というイベントはある。unload イベントだ。
しかし、Javascript プログラムの寿命は、そのページが終了するまでだ。
そのため、unload イベントにプログラムをセットしておいても、実行されることはない。
実行されないんじゃ意味ないじゃん、ってことで、beforeunload というイベントもある。
「unload の直前」というイベントだ。
よく、「ページを離れてもいいですか？」というダイアログが表示されるのは、このイベントの時に動くプログラムによるものだ。
このイベントは、次にアクセスする URL が決定し、新しいページの取得準備が整うと呼び出される。
つまり、このイベントの中で URL を書き換えても、すでに URL は決定していて意味がない。
このイベントでできることは、新しいページへの移行を中断し、今のページに居続けるかどうかをユーザーに問いかける、ということのみだ。
そんなわけで、ブラウザ側の Javascript で解決するのは無理とわかった。
でも、まだ最後の望みがあった。
一般に「ブラウザ側の Javascript」というのは、WEB ページに付随するものだ。
しかし、最近のブラウザには、WEB ページではなく「ブラウザに」Javascript を登録し、動かす方法があるのだ。
ServiceWorker という。
Chrome/FireFox では早くから実装され、便利なので使いたいプログラマも多かったのだけど、Safari ではなかなか実装されなくて使いどころが限られていた。
昨年、やっと Safari も対応したので、使われる局面が増えてきている。
これを使うと、WEB ページがサーバーに問い合わせた瞬間に、そのリクエストを横取りして、Javascript がサーバーの「ふりをして」返事を返したりできる。
だから、オフラインなのにキャッシュしておいたデータを渡したり、逆にサーバーにデータを送ろうとしたときにキャッシュしておいて、あとでオンラインになった時にこっそり送信したりできる。
Google Docs がオフラインでも使えるのはこの仕組みを使っているからだ。
Android では、この仕組みを使って WEB ページを「アプリ化」することもできる。
WEB ページに行くと「このページをインストールしますか？」と促され、インストールを選ぶとホーム画面にアイコンが現れる。
このアイコンをタップすれば、いつでも WEB ページが提供する機能を使える。
Google Docs の例と同じように、適切に処理されていれば、オフラインでだって使える。
Service Worker の利用例は、多くは「WEB を オフラインでも使えるようにする」のと、それをさらに拡張した「アプリ化」だ。
だけど、先に書いたように、サーバーへのリクエストを横取りして、いろいろなことができる。
キャッシュデータを渡してオフラインでも動くようにする、というのは代表的な応用例にすぎない。
これなら、リロードの問題を解決できそうに思えた。
…一筋縄ではいかなかったのだけど、実際解決できた。
基本戦略はこうだ。
・WEB ページ側で、history.replaceState を使って URL を一部削除。
同時に、削除前の URL を ServiceWorker に渡して、データ保持。
・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、
保持していた本来の URL にアクセスし、そのデータを WEB ページ側に渡す。
実験過程を端折るが、実際にこの流れを作ったらうまく動かなかった。
WEB ページ側で動いている Javascript は、内部でセッションデータを使用していたのだ。
（僕は途中から参加して改良してきただけなので、そうした部分があるのを知らなかった）
だから、サーバーアクセスの際の流れを少し変えることにした。
・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、
保持していた本来の URL にリダイレクトする指示を作り出し、WEB ページ側に渡す。
リダイレクトが挟まるので、WEB ページ側としては少し動作が遅くなってしまう。
しかし、一度本来の URL に戻ってからリロードすることになるので、内部で動作するプログラムでも
URL に入れたセッションデータを使えることになり、問題は出なくなる。
さて、実際に作る上では、いくつか問題があった。
一番重要なのが、Javascript の生存期間だ。
WEB ページでは、そのページが存在する間、Javascript が生存する。
変数などもこの間は保持されるので、データ保持も変数に入れればよい。
しかし、ServiceWorker では、生存期間の考え方が二つあるのだ。
先に書いたように、ServiceWorker はブラウザ側で動き、WEB ページが閉じられても残り続ける。
しかし、それは「残っている」だけで、生きているわけではない。
じつは、必要な時に動作し、動作を終わるとすぐに終了してしまうのだ。
「データを渡す」という動作があったとしたら、その動作が終わった瞬間に終了し、変数は消える。
その後、「サーバーアクセス」という動作があり、動き始めたときには変数は存在していない。
だから、変数ではない方法でデータを保持しないといけない。
ServiceWorker は非常に強力な仕組みなので、悪さができないように厳しい制限が課されている。
データ保持方法としては、indexedDB しか使えない。
古くから知られるデータ保持方法には、Cookie や webStorage があるが、それらよりも新しい仕組みだ。
まぁ、それしか使えないのであれば、それを使おう。
…これが、イベントで動作する仕組みになっていて使いにくい。
DB に接続する、という指示を出すと、少し後で「接続成功」というイベントが起きる。
だから、接続成功イベントに、接続後のプログラムを登録しておく。
接続後には、アクセスしたい対象を指定してから「データ取り出し」を指示する。
しかし、データはすぐ取り出されるわけではない。少し後で「取り出し成功」イベントが起きる。
だから、ここでもイベントに対してプログラムを登録しておく必要がある。
非常に面倒くさい。
しかし、他に方法はないのでその方法でプログラムを組む。
ところが、もう一つ問題があるのだ。
ServiceWorker 自体は、こうしたイベントによって動くモデルではないのだ。
いや、先に書いたように「サーバーへのアクセスが生じた」などのイベントはある。
でも、Javascript ってとにかく「何かしたら後で呼び出して」という書き方が多くて、ここ数年で新しい書き方が取り入れたのだ。
そして、ServiceWorker は、基本的にその書き方で書かれないといけないようになっている。
この書き方は Promise というやつで…
この概念の歴史から入ろうと思ったが、無駄に長いのでやめた。
同時に、概念だけ説明するのも同じくらい長くなるのでやめた。
ともかく、概念自体は古いとはいえ、10年たっていないのではないかな。
Javascript の言語仕様に取り入れられたのは、2015年なので、４年程度しかたっていない。
しかし、便利なので、これまでイベントモデルで作られていた Javascript が、最近は Promise モデルで機能追加されるようになってきている。
上に書いたが、ちゃんと理解していないと混ぜて使えない。
ちなみに、Promise の概念の前に Deferred があり、こちらのことは以前に書いたことがある。
微妙に違うとはいえ、概念的に慣れていたのですぐに…でもないけど、１日程度で理解できた。
そんなわけで、同じことで悩んでいる人にとっての「答え」を示そう。
ServiceWorker では、fetch （URL アクセス）イベントに対して、最終的な「返事」を event.respondWith として返せばよい。
ここで、返す内容は Promise でなくてはならない。
Promise は、resolve を引数とする関数として定義される。
resolve はコールバック関数であり、Promise の処理終了時には、resolve を呼び出してやらなくてはならない。
この時、resolve には、「結果」を引数として渡す。
通常の関数における、return と同じような感じで、何が結果になるのかはその時の処理内容による。
respondWith は、URL アクセスに対する答えを返す関数なので、答えは http の Response となる。
これは Response クラスとして定義でき、リダイレクトしたいなら headers の Location に URL を渡せばよい。
（http と同じだ）
以上の「きまりごと」さえ守れば、あとはどんな書き方をしようとも自由だ。
関数内部で indexedDB のイベント呼び出しをたくさん定義しても構わない。
僕が仕事で必要だった関数の場合、次のようになった。
self.addEventListener('fetch',function(event){
let url = event.request.url;
let param = url.match(/targetDirectory\/([0-9]+)(\?session=)?/);
if(!event.isReload || !param || param[2])return;
event.respondWith(new Promise(function(resolve){
let openReq = indexedDB.open('targetDB');
openReq.onsuccess = function(event){
let db = event.target.result;
let trans = db.transaction('fullURL','readonly');
let store = trans.objectStore('fullURL');
let getReq = store.get(param[1]);
db.close();
getReq.onsuccess = function(event){
let redirectResponse = new Response('',{
status: 302,
statusText: 'Found',
headers: {
Location: event.target.result.url
}
});
resolve(redirectResponse);
}
}
}));
});
説明しておくと、/targetDirectory/123?session=**** というような URL が隠蔽対象だ。
リロードにより fetch イベントが起きているときは、すでに隠蔽されて ?session= 以降はなくなっている。
しかし、初回アクセス時や、リダイレクト直後は ?session= 以降もついているので、判別して処理を変える必要がある。
そして、123 の部分の数値はページの分類を示していて、ブラウザの複数のタブで開かれる可能性がある。
それぞれでリロードしたときに混乱しないように、123 を DB のキーとして、元の URL を格納してある。
＃格納部分のプログラムは別途必要。そちらは Promise と無関係に書けるので、それほど難しくない。
…というわけで、URL を検査して、隠蔽されていない場合はそのままアクセスを通す。
隠蔽されている場合は、123 にあたる部分をキーとして DB を検索し、得られた URL へのリダイレクトを生成する。
ちなみに、僕の要件ではリダイレクトが必要だったが、URL を差し替えてそのままサーバーにアクセスしたい、という場合もあるだろう。
実はそちらの方がプログラムは簡単で、redirectResponse を生成せずに、
resolve(fetch(event.target.result.url));
としてしまえばよい。
ここで重要なのは、
・fetch イベントに対する反応は、すぐに返さないといけない。
・event.respondWith が呼び出されれば、そこで帰ってくる反応を待つ。
・呼び出されなければ、本来の URL に対してアクセスを行う。
ということだろう。
respondWith は「結果を返す関数」ではなく、「結果を返すと約束する関数」だ。
結果を返すものだと思って、結果が出てから呼び出そうとすると、「fetch に対して respondWith が返されなかった」ことになり、本来のサーバーにアクセスが行ってしまう。
そして、結果を返すと約束するのだから、返すのは Promise （約束）だ。
Promise は、最終的に resolve として渡される関数を呼び出しさえすれば、その内部でどれほどの時間がかかっても構わない。
だから、時間がかかる indexedDB の処理は、この Promise 内部で行うようにする。
…ただこれだけのことだ。
プログラム例を示したら、なんてことのない、当たり前に見えるコードだろう。
けど、こういう例がネットを探してもなかなか見つからないんだ。
ServiceWorker というと、「キャッシュを使ってオフラインでも動作するようにしましょう」ってお決まりのパターンばかりで。
＃ちょっと気が利いた例では、簡単な文字列を「WEB ページ」として生成して返したりする実験をしていた。
しかし、indexedDB を使って何かのデータを返すような処理を見つけることはできなかった。
この日記が、同じような処理をしようとしている人の助けになれば幸いである。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ゴールデンウィーク前の話なのだけど、ニンテンドーポイント（ゴールド）が４月末に失効するよ、というお知らせが来た。
何か買ったりすると付くポイントで、ゴールドは１ポイント＝１円で任天堂商品の購入などに使うことができる。
ちなみに、プラチナポイントというのもあるのだけど、こちらはゲーム内でバンバン配布し、ゲーム内以外ではあまり使い道がないゴミみたいなものだ。
で、失効するゴールドポイントは 150ポイントだったのだけど、せっかくなので全保有ポイントを調べたら 937ポイントあった。
500円程度のダウンロード販売のゲームを買ってもよいかも。いや、少しお金出して 1000円くらいのものを買った方が楽しめるか。
というわけで、いろいろと悩みながら「Minit」というゲームを買った。
Switch 版は昨年夏に発売になっているし、それ以前に PC 版で販売されている。
だから「今更」感のあるゲームだろう。
しかし、なかなか面白かった。
というか、一通り解き終わった後で「これからが本番だ」と気づき、今一生懸命遊んでいる。
まずはゲームの説明だ。
ネットを探せば宣伝動画などもあるので、そちらを見たほうがわかりやすいけど。
まぁ、初代ゼルダの伝説タイプのアクション RPG だと思いねぇ。
ただし、主人公は呪われていて、６０秒たつと死んでしまう。
死ぬとセーブポイントから再スタートになるが、死ぬ直前までに「世界に影響を及ぼす」行為をしていた場合は、その影響は残ったままになる。
以上。シンプルだが、それだけのゲームだ。
ゼルダと同じように、画面切り替え型で広い世界を探検する。
ゼルダと同じように、剣を前に突き出して敵を倒したり、障害物を壊したりできる。
ゲーム画面は白黒のドット絵だ。ゲームボーイみたい、というとほめすぎ。
ゲームボーイは白黒４階調だったから、このゲームの画面よりももっと美しい。
しかし、この白黒画面が、ゲームを面白くするためによく考えられているのだ。
６０秒で死ぬまでに、世界に影響を及ぼせばいい。
だから、ひたすらいろいろなことを試してみて、何が起きるのか探す必要がある。
洞窟を見つけて入ってみるが、真っ暗で何もわからない。
どうやらライトが必要なようだが、どこにあるのかわからない。
灯台を見つけたが、鍵がなくて入れない。冒険していたら鍵を手に入れ、灯台に上ってみたらライトが置いてあった。
世界に影響があるのは、上の例でいえば「鍵を手に入れる」「ライトを手に入れる」など。
基本的に得たアイテムは死んでもなくならないし、切り開いた道などもそのままになる。
一方で、倒した敵などは死ぬと復活する。動かせるものも、死ぬと元の位置に戻ることが多い。
何よりも一番影響があるのは、「セーブポイントに入る」ことだ。
基本的には、ベッドが用意された家がセーブポイントになっていて、死んだときは「最後に入った」セーブポイントに復活する。
世界には何カ所かのセーブポイントがあり、そこを中継地点とすることで広い世界をくまなく冒険することができる。
このゲームの中にはパズルが多く、障害物の動かし方などに失敗すると詰んでしまうことがある。
また、袋小路の行き止まりもあり、そういう場所にはアイテムが置かれているのだけど、アイテムを取った後脱出することができない場合がる。
まぁ、時間切れになれば死んでセーブポイントに戻るのだけど、B ボタンを押せばいつでも自殺できる。
この「自殺」は、遊び方によっては非常に重要なポイントになる。…ようだ。
さて、先に「白黒画面がゲームを面白くする」と書いたのだけど、白黒でも古臭い感じはしない。
アニメーションがやたらと滑らかだからだ。ファミコンやゲームボーイの時代なら、こんな滑らかなアニメーションは作れなかった。
しかし、色がない、ドットも荒いというのは、情報が極端に少ない。
…ここが重要だ。世界を冒険するときに、初めて見たものの意味が分からないのだ。
もしくは、意味が分からないがゆえに、「そこにあるものが見えていない」ともいえる。
意味が分かるのは、それが重要アイテムだと認識されて以降だ。
つまり、このゲームは世界に影響を及ぼすためにアイテムを捜し歩くゲームなのに、そのアイテムは入手するまで「見えていても気づかない」ことが多い。
なんて巧妙な隠し方だろう。
ちゃんとヒントを見せているにも関わらず、それがヒントだったとわかるのは謎を解いた後なのだ。
「こんな隠し方、わかるわけないよ！ 不条理だ！」と怒りたくなるのはクソゲーの条件だし、そう怒りたくなる場所が随所にある。
しかし、あとで見直してみると、明らかにわかるように置いてあるのだ。気づかなかった自分が悪い、と納得するより他にあるまい。
ちなみに、もし気づかなかったとしても、あまり問題はない。
必須アイテムは比較的楽に入手できるようになっていて、巧妙に隠されているのはコンプリートを楽しむオマケ要素だから。
ところで、このゲームのとあるところに、謎のメッセージが置かれている。
???
???
???
と、ハテナマークが並んでいるだけなのだ。
一度クリアした後、続きを遊び始めた。
アイテムのコンプリート要素があるので、ゲームをクリアした後でも、そのセーブデータで遊び続けることができる。
そこで気づいた。一番上の ??? に、「ノーマル：243」って入っている。
ん？ これはなんだ？ その時は気にせず遊んでいた。
そして、アイテムコンプリートが難しいので、気を取り直してもう一度最初から遊んでみた。
最初から遊びなおした理由は、設定画面の中に「スピードラン」という項目があるからだ。
初期設定では OFF になっているが、ON にしてゲームを始めると、ゲーム開始からの1/100秒単位の通算時間カウントが画面上に表示される。
つまり、これはやるべきことを効率よくやって、タイムアタックをするゲームなのだな、と認識したのだ。
２回目は、謎を全部知っているので３５分ほどで終了することができた。
（ちなみに、最初のプレイは１日１～２時間で１週間程度、通算では５～６時間くらいかかっていると思う）
で、そのあと気づいた。??? に書かれていた 243 が、44 に減っている。
この 44 というのは、クリアまでに「死んだ回数」だ。
ここでやっと気づいた。
このゲーム、スピードランもできるけどそれはオマケ要素で、作者が一番やってほしいのは「少ない死に回数でクリア」なんだ。
現在死に回数を減らすべく、冒険の手順を組み立てている。
１分間にできるだけ多くのことを詰め込まなくてはならない。
最初の一分は何度もやったので、もう動きが確定している。
先ほど書いた例の「灯台に上ってライトを取る」ところまでは、最初の１分で可能だ。
ちなみに、初回プレイではそこまでに１０回以上は死んでいたと思う。
それ以降は、大まかにやることは決まっているのだけど、まだ無駄のない動きというのがわかっていない。
現時点でのベストスコアは２１回だけど、まだ無駄が多いので２０回を切るのは余裕だろう。
最終的にどのくらいまで切り詰められるのかはまだ見えていない。
そして思った。
この作業、ピクミン１の楽しかった部分だ。
やるべきことはわかっている。
でも、手順の一部には前後の入れ替えが可能な部分がある。
そうした部分を調整しながら、区切られた時間を最大限に使う方法を考える。
小さなパズルを解き、その答えを大きなパズルの一部としながら、大きなパズルを完成させていく。
状況次第では、小さなパズルの答えを一度壊し、再度組みなおすことで大きなパズルがより完成に近づく場合もある。
ピクミンと違い、途中までできたところでセーブデータをコピーして保存して次に挑む、ということができない。
最後まで通しでやらないといけない「一発勝負」なので、解き方は再現性が高い、偶発性を排除した方法であるのが望ましい。
一方で、ピクミンと違い、全部通してやっても３０分以内だ。
気軽にチャレンジしやすい。何度も繰り返すことで見えてくる攻略もあるだろう。
実はこのゲーム、ハードモードもあるのだけど、まだハードモードはクリアしていない。
ハードモードは、名前の通りハードだ。難しい。
ノーマルモードの徹底攻略と、ハードモードのクリアのどちらを優先すべきかわからないのだけど、とりあえず「楽しい方」を遊んでいる。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
パソコン壊れました。
とりあえず修復できたからこの日記を書いているのだけど…
僕は現在町内会の役員をやっていて、今日は町内会の総会がある日です。
これを書いているのは午前で、先ほど会場設営をしてきました。
総会自体は午後にあります。
そこでちょっと書類仕事を頼まれてきたので、PCを起動しようとしたら…
え？ 起動できないって言って自動修復フェーズに入ったよ？
そして、「修復できません」ってさじを投げられたよ？
どうしてこういうタイミングで壊れるのか。
…いや、わかっている。自分のせいではある。
もう７年も使い続けているマシンで、「そろそろ（壊れる前に）買いなおさなきゃ」と言ってから半年以上たっている。
それにしたって、このタイミングで。
マシンは７年前のものだが、昨年の１２月に、Windows再インストールをしている。
新しいサーバーを購入し、古いサーバーの SSD が余ったのでメイン PC につなぎ、そこに Windows を入れてみたんだ。
これが結構快適だったのも、新マシンをいまだに買っていない理由になっている。
しかし、中古の SSD って、だめだよね。壊れやすいよね。
きっと、自動修復できない理由もそれだよね。
しかし、「新しいストレージに新しい OS を入れた」ということは、古いストレージに古い OS が残っているということでもある。
そちらから起動してみたら、ちゃんと起動できた。
そして、SSD のエラーチェック。やっぱりエラーが出た。
「修復」を試みる。…あら、ちゃんと修復できた。
これで再起動。問題なく再起動できた。
そんなわけで、一安心してこれを書いている。
しかし、いよいよ新マシン買わないとなぁ。
まだ、昨年１２月に始めたサーバー設定も終わっていないので、そちらが終わってからにしようと思ったいたのだけど。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
MINIT 最小プレイ回数クリアチャレンジ
— wizforest (@wizforest) 2019年5月7日
まだ減らせそうだけど､とりあえず満足｡
#NintendoSwitch pic.twitter.com/s5N0A2YReR
先日、Nintendo Switch 用ゲーム Minit の話題を書いた。
ゲーム的には「初代ゼルダの伝説のような」ゲームなのだけど、クリアしてみて、これはピクミンのように「ゲーム中での最短時間を目指すものだ」と思った。
ピクミンは、「１日」の概念があるゲームで、その日の終わりにはすべてを終了して撤収する必要があった。
その状況下で、できるだけ少ない日数でクリアを目指すゲームだった。
それに対し、Minit は「１分」で強制的に作業が中断され、スタート地点に戻されてしまう。
ゲーム終了時に、スタート地点から出発した「スタート回数」が表示されるので、この回数を減らすことを考える。
まずはヒントなしで…と頑張って、冒頭に書いたスクリーンショットを得た。
１２回。もっと減らすことができるポイントはわかっているのだが、それをやるのはかなり難しそうに思う。
ひとまずはこんなところだろう。
じゃぁ、答え合わせをしよう。
すでに発売されて半年たつゲームだから、そういう攻略記事もあるだろう、とネットを探してみる。
…全然見当たらない。この遊び方、誰もしていないのか？
スクリーンショットにもわかるように、下に所要時間がかかれている。
こちらの時間を競う RTA （Real Time Attack）の方が盛り上がっているようだ。
現時点では、エンディングに表示されるゲーム内時間で 6分53秒43、というのが最高記録のようだ。
RTA では、時間短縮のために自殺するのはかまわないので、回数は 14回。
動画も見てみたが、これはこれですごいのだけど、回数短縮の参考にはなりにくい。
ただ、知らない時間短縮テクニックを知ったので、これを使えばもう少し時間短縮できそうだ。
＃砂漠のオアシスって、ずっと遠くにあるのだと思っていた…
砂漠での「画面切り替え回数」が重要で、距離ではないのね。
さらに探してみると、やはり回数記録に挑んでいる人はいるようで、「１０回」でのクリア方法解説を見つけた。
この解説で見る限り、上に書いた時間短縮テクニックを使っているようだ。
＃そのオアシスが遠いので、そこにいる敵を倒して戻る、は不可能だっと思っていた。
それだけでスタート１回分を使っていたのだけど、それを減らせれば大きい。
そして、この解説では「最低９回でクリアできるけど、難しいので１０回を目指そう」という形で書かれている。
なかなかこういう記事が見当たらないと思ったら、もう発売から１年近いゲームなので、みんなこの段階は通り過ぎて RTA に行っているのだな。
まずは１０回を目指すか…。
難しそうではあるが、独力でも１２回を達成できたのだから、無理ではない気がする。
しかし、疲れたのでいったんハードモードをのんびり遊んだ。
ハードモード難しい。でも、何度死んでもいいや、というつもりでやっていれば、何とかなる。
クリアできた。
そして、「マリーモード」が現れた。
マリーは、ゲーム中にヒントをくれる幽霊の名前。マリーモードでは、主人公がこの幽霊になっている。
そして、幽霊なので死なない。自殺はできるけど、１分の時間制限はない。
そこで「最短スタート回数」を目指してプレーした。当然、１回のスタートで最後までクリアできた。
＃時間制限がないとはいえ、敵との戦闘はある。
普通は死んだらダメージ回復になるので、マリーの１回クリアはミスが許されない、という意味でもある。
ハードモードのアイテムをまだコンプリートしていないので、それをやってから１０回に挑戦…かな？
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、パソコン壊れた、と書いた。
７年も使っていたマシンで、以前から時々調子が悪かった。
さすがに仕事のメインマシンが壊れるのは困る。完全に壊れる前に買っておこう、と早速注文。
今使っているマシンは DELL だが、７年前は DELL はダントツにコストパフォーマンスが良かった。
しかし、今調べると DELL も悪くないが、HP もいい感じ。
実は、半年前には妻がメインマシンを買い替えていて、調べた結果 HP にしている。
僕も HP に決定。
CPU 性能は低くてもいいが、メモリは多くほしい。
仕事柄、サーバーに接続して使う端末になりがちなので、CPU 性能はそれほどいらないのだ。
しかし、Chrome で同時に何ページも開いたりするので、メモリは食う。
あと、メインストレージは SSD がいいのだけど、SSD だけではさすがに足りない。
HDD と同時搭載がいい。
DELL の安いマシンは、SSD のみでメモリ増設もできない、というものが多かった。
少し高級機種になると、SSD+HDD でメモリも増設可能、というのがある。
しかし、それは高級機種なので CPU も i7 で、高い。
これに対し、HP は CPU が i5 のまま、SSD+HDD メモリ増設が選べた。
そんなわけでそちらを選ぶ。
「令和改元セール」を銘打って安かったのも後押しした。
ところが、だ。
さんざん比較してよいマシンというのは、他にも良いと感じる人が多いようで、注文殺到だそうだ。
５月７日に注文してすぐに「在庫がなくなってしまい、出荷時期のめどが立っていない。もう少し待ってほしい」というお詫びのメールが来た。
それから２日置いた５月９日、再び「納期に関するご案内」というメールが来た。
納期が決まったか、と思って開くと、「出荷のめどが立たない」というお詫びだった。
まぁ、仕方がない。
今のマシンは調子が悪いというだけでまだ使える。気長に待とう。
…とおもっていたら、スリープして再起動したときに、回復不可能なエラーが出て止まった。
再起動したらちゃんと動いたのだけど、やっぱりこのマシン不安だ。速く新しいマシン来ないかな。
で、先ほど、またメールが来ていた。
「納期に関するご案内」…やはり「出荷のめどが立たない」だった。
前のメールから５日、注文からは１週間たったので、現在の状況を報告ということだろう。
ただ、文面は少し変わっていて、「納期が決まり次第メール連絡、また、納期が決まらないまま４営業日立った場合もメール連絡」と確約している。
人気があって商品がない、というのは仕方がない。
その際の対応として、現在の状況を逐一知らせるというのは、対応としては及第点だろう。
一応、前のメールから、まだキャンセルは可能であること、急ぎの場合は即出荷モデルも提供できることも書かれている。
僕としては、また７年くらい使ってしまうだろうから、ここで妥協して別モデルにしようとも思っていない。
今のパソコンは調子悪いとはいえ十分使えているので、気長に待つことにしよう。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
最近いろいろと壊れてばかりで、買い替えや修理で金がかさむ…
今回は、表題通り洗濯機が壊れた、という話だ。
我が家で一番古い家電品だった。
妻と同棲を始めたときに買ったものだ。
（結婚するつもりだったが、諸般の事情ですぐに結婚とはならず、しばらく同棲していた）
記録調べたら２０００年に買ってたよ。前世紀に買ったものだったのだな。
しばらく前から、調子が悪いことは気づいていた。
というか、５年位前にいったん買い替えるつもりで検討したりしていたんだ。
そのころに、一度調子が悪くなった…と思ったから。
でも、このときは排水溝が詰まっているだけだった。
排水溝が詰まったので、脱水ができない、というのがその時の症状だった。
掃除したら治った。
で、今朝。排水ができずにエラーになった。
あぁ、また排水溝が詰まったか。…これは、すぐに掃除して、ちゃんと脱水できるようになったんだ。
排水後、すすぎ動作に入るはず…のところで、またエラーになった。
確認すると、給水がおかしい。水がちょろちょろとしか流れない。
＃後日追記：「排水できずにエラー」だと思ったのは、おそらく勘違い。
エラー時点ですすぎ動作中で、洗濯槽に中途半端に水が入っていた。
そのため「排水できなかったのだな」と考えたのだが、排水後に中途半端に水が入ったところで、「貯水できない」エラーが出たのだろう。
さて、問題はどこにあるだろう。切り分けを試みる。
洗濯機に給水するホースを外し、蛇口をひねると、普通に水が出た。
再び洗濯機につなぐと、水が出ない。
洗濯機の中の止水栓がおかしいようだ。
うーん、どうするか。
しばらく考えて、洗濯機を「すすぎ」動作にしてから、外したホースから水を入れて動かした。
「全自動」ではなく、水を入れる所は人がやらないといけないけど、とりあえず洗濯はできる。
とはいえ、このままでは生活が不便だ。
早速ネットで洗濯機について調べる。
…２０年の進化ってすごい。今の洗濯機、昔とは全然違うのね。
５年位前に調べたときに「あこがれの機能」だった、簡易乾燥機能とかは、安い機種でも当たり前についている。
２万５千円追加で出せば、ちゃんとした乾燥機能も付くのだけど…
これはしばらく考え、いらないと判断。乾燥機能は電気代が結構かかるようなので、「もったいない」とケチってつかわない自分しか想像できない。
現在、洗濯には風呂の残り湯を使っていて、汲み上げるポンプを使っている。
以前は、このためのポンプを内蔵した機種というのもあったのだけど…と調べると、今時どの機種でもついているのが当たり前で、当たり前すぎて売り文句にならないので、宣伝ページを見てもどこにも書いていない。
ドラム式か、縦型槽かは少し悩んだが、値段が全然違うので縦型で。
これには妻の好みも反映されている。僕自身はどちらでも構わない。
（洗濯はいつも僕がやっているので、本当は妻の好みを考慮する必要は、あまりない）
そのほか、いろいろ調べて、日立ビートウォッシュの、乾燥機能はないやつ（簡易乾燥はついている）の、8.0kg を買うことにした。
６月に新型が発売されるようで、旧型が安くなっていたから。
先ほどネットで頼んだが、設置は来週半ばの予定。
それまでは、少し不便だけど、給水は手動で行う全自動洗濯機を使うことになる。
ところで、最近頻繁にものが壊れるので、日記の中から拾い出してみた。
パソコン（２０１９年５月仮復旧しているが調子悪い。代替機購入済み）
クレジットカード（２０１９年２月不正利用が発覚し再発行）
冷蔵庫（２０１９年２月買い替え）
エアコン（２０１９年２月修理）
布団（２０１９年２月買い替え）
自動車パンク（２０１９年２月）
サーバー（２０１８年１２月買い替え）
エアコン（２０１８年１２月買い替え・子供部屋に増設）
ノートパソコン（２０１８年１１月 HDD不調で交換修理）
無停電電源装置（２０１８年１０月買い替え）
自動車（２０１８年１０月車検１８年目を前に買い替え）
電話機（２０１８年８月買い替え）
テレビ（２０１８年７月買い替え）
食洗器（２０１８年３月修理）
加湿器（２０１７年１１月買い替え）
ＩＨキッチンヒーター（２０１７年９月修理）
給湯器（２０１７年８月修理）
ネットワークルータ（２０１７年３月買い替え）
家（２０１７年１月～２月メンテナンス）
まぁ、２年前まででとどめておこう。
ここに「家のメンテナンス」が入っている。建築後１０年で行うように、ハウスメーカーが推奨しているものだ。
つまり、ものが壊れる理由は、家を購入したときに併せて買ったものが、１０年たって寿命を迎えてきているという、多くはそれが理由だ。
実は、日記に書いていないが、１月ほど前に庭の修理もやっている。
家を建てたとき、金がなくて外構は自分たちで（というか、主に妻が）やった。
歩道を枕木で作ったら、１０年で朽ちてボロボロになり、先日業者を入れて枕木風のコンクリート製のブロックを入れてもらったのだ。
業者さんは綺麗に入れてくれていたのだけど、妻はしばらくして「どうも、思っていたレイアウトと違った」と言って、コンクリート枕木を大幅に並べなおした。
最初の枕木も自分で並べたのだから、材料さえあればできるだろう、という算段で。
しかし、上に車が乗っても割れないような、中空ではないしっかりとした枕木なので、かなり重かったらしい。
幅20cm 、厚さ15cm、長さ最大 90cm…かな。標準的なコンクリートの密度で計算すると、１本 60kg くらいだね。
（標準的なコンクリートの密度は、2.3t/m^3 らしい）
完全に持ち上げるわけではないので、60kgなら「移動できる」重さではあるが、なん十本という単位で動かす必要があった。
作業後、２日くらい体中が筋肉痛だと言っていた。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
２度目の復活。不死鳥のように甦る。
Nexus7 (2012) は、2012年発売の 7inch Android 端末だ。
さすがに８年も前の端末なので、今時使い物にならない…
と思って、先日代替機として Amazon FireHD 10 を購入したのだ。
そして、代替機が手に入ったので、Nexus7 はお役御免、「捨てても構わない」機械になった。
じゃぁ、捨てる前にダメもとで遊んでみよう。
…そうしたら、使える端末に復活してしまった。
ちなみに、「２度目」と書いたが、１度目の復活は１年前だ。
一度は、遅すぎて使い物にならない、と思ってほったらかしになっていた機械を、ダメもとで復活させたら案外使えていた。
しかし、１年使っていたら、やっぱり使い物にならなくて、代替機を購入した、という流れだ。
１度目までの経緯を説明しよう。
Android は現在広く使われている OS だが、最初は「スマホ用」の OS だった。
タブレット端末で使うことは想定されていなかったのだ。
当時、スマホ用には Android 2 系列が使われていた。
これに対し、Google はタブレット用の「別バージョン」として、Android 3 を作る。
3 は 2 の後継ではなく、違う機能を持つ別バージョンだった。
しかし、Android 4 では、2 と 3 の両方の機能を持つ形で統合される。
ここに、現在のように幅広く使われる Android の基礎が出来上がる。
そして、これを広く宣伝するように Google が販売した「戦略機種」が Nexus7 だった。
世界初の Android 4 搭載端末で、当時の一般的なタブレット価格から見ても、驚くような低価格設定だった。
Nexus7 は大ヒットとなり、翌年には改良機種が出る。
僕は初代を買ったので、Nexus7 (2012) と書くが、この書き方は (2013) もあるためだ。
さて、「世界初の Android 4」は、初物であるがゆえにバグが多かった。
頻繁にバージョンアップされ、最終バージョンの 4.4.4 まで進み、さらに 5 系列も提供された。
しかし、5系列も真っ先に投入されたため、またバグだらけだった。
これがひどいもので、まともに使えないほど動作が緩慢だった。
頻繁にバグ修正が行われ、5.1.1 まで行ったのだが、Nexus7 (2012)のバージョンアップはこれで終了。
使い物にならないほど緩慢なままだったので、我が家では使わなくなってしまった。
そして１年前。
5 系列が緩慢なら、4 系列に戻して使ってみよう、ということで 4.4.4 に入れなおした。
ちなみに、Android の宿命として、「バージョンアップ」を提供する仕組みはあるが、バージョンダウンは難しい。
Nexus は Google 製で、開発にも使われることを想定しているため、それなりの知識があれば好きなバージョンに戻すことができる。
4.4.4 にしたら、動作が軽快になった。
古い機械なのでパワー不足は感じるが、それなりに使える状況に戻ったので使ってきた。
ところが、１年使ったある日、急によく使っていた Radiko アプリの動作が遅くなった。
やはりパワー不足か、とあきらめて代替機を先日買ったのだ。
代替機購入の際の日記には、「Radiko のアプリ動作が緩慢になったのは、Radiko のシステム更新が原因ではないか」と書いた。
しかし、これは今はちょっと違ったかな、と思っている。後で詳細書く。
さて、今回やったこと。
僕が知らなかっただけで、１年前に「復活」させた時点では、今回の方法がすでにトレンドになっていたようだ。
Nexus 7 (2012)をAOSP 7.1.2にアップグレード
今回は、上に書かれた２つのページを参考にして、ほぼ同じことをした。
１ページ目は、Nexus7 が Android 4.0 だったころのバグの影響が後まで残り、速度低下の原因になっている…
という指摘。ただ、あとで考えると事実誤認が含まれるように思う。これは後で説明する。
事実誤認があっても、１ページ目は２ページ目の作業を行うための「事前準備」のやり方を、懇切丁寧に教えてくれる。
目は通すべき。最終結論である「Trimmer アプリの実行」も、おまじないとしてやっておいて損はないと思う。
（多分、まったく無関係なのだけど、害はない。やって何か改善したら儲けもの）
２ページ目は、非公式ではあるが、Android 7.1.2 を入れてしまおう、というもの。
非公式とはいっても、もともと Android はオープンソース…プログラムが公開され、誰でも改造できるものだ。
そこで、正式な 7.1.2 を元にして、有志が Nexus7 (2012) に対応したバージョンを公開しているので、それを入れる。
7 は、5 よりも「最適化」が進んでいる。つまり、プログラムの無駄が省かれている。
そのため、５よりも軽快に動く。
これが非公式版で、Google が著作権を持つアプリは入っていない、ということも大きいと思う。
一般に、Android 端末を購入すると、Google 製のアプリがたくさん入っている。
場合によっては、それと同等の機能を持つ、端末メーカー製のアプリもたくさん入っている。
そして、それらは消すことができない。
場合によっては動作を止めることすらできず、CPU の速度とメモリを無駄食いする。
しかし、非公式な Android には、Google が著作権を持つアプリを同梱することが禁じられている。
…いや、Google アプリが入れられないわけではない。禁じられているのは「同梱」だけで、再配布は許可されているから。
逆に言えば、非公式 Android なら、公式なものと違って、必要最低限のアプリだけ入れるようにできる。
すると、不要な機能が動かないので動作が軽快になる。
もっとも、何が不要かは人によるだろう。
僕が軽快だと感じていても、他の人には「機能不足で使えない」と思う可能性もある。
２ページ目として紹介したページ、そのページが書かれた時点での「最新版」の 7.1.2 を使用している。
しかし、現在ではもっと新しいものがある。
紹介ページでは「2018/12/05 ～の掲示板」となっている箇所のリンク、実は掲示板の名前は、時々更新される。
現在は、日付部分が 2019/05/05 となっている。
そして、その掲示板の一番上に、最新バージョンのバイナリが置かれているので、それを取得しよう。
バージョンが違っても、どれも 7.1.2 だ。これは、「Google がつけた Android の」バージョン番号。
日付の違いは、それを Nexus 7 で動くように移植作業をした際のバージョン違いだ。
どうも、バグ取りも行われているが、セキュリティアップデートに追随するのが目的のようだ。
Nexus7 (2012) には、WiFi 版と 3G 対応版の２機種があり、名前は同じだがハードウェアが違う。
WiFi 版は Grouper 、3G 版は Tilapia というコード名がついている。どちらも魚の名前だ。
僕は Grouper の OTA-Package バイナリを選ぶ。WiFi 機種だからだ。
そして、Open GApps のバイナリも必要とする。
GApps とは Google Apps 、つまりは Gmail や Chrome などの Google 製アプリこのことだ。
Nexus7 は ARM なので、ARM - 7.1.2 - pico を選ぶ。
pico の部分は好みで変えてもいい。pico は最小セットだ。不要なものが一切入らないので動作が軽い。
その後、必要なものがあれば Google Play Store で入手すればいい。
これで、特に問題もなく、7.1.2 にすることができた。快適に動作する。
…いや、さすがに８年前のマシンなので、反応がちょっと遅い感じはあるよ？
インタラクティブに使うのは、ちょっと辛いかも。
でも、Youtube 見たり、Radiko 聞いたりといった「ストリーム再生」には問題がない。
Chrome 検索して、静的な（ゲームとかではない）ページを閲覧するのにも問題はない。
ところで、Radiko は最新版だと動かない。
旧バージョンがあるので、5.0.6 を入れると動く。
…なんか怪しげなサイトだけど、合法だと書いてあるのだから、大丈夫なのだろう。
Radiko はバージョン 6 以降でないと、タイムフリー（１週間以内ならいつでも聞ける）に対応していない。
と同時に、この機能が強力なので、放送データを録音したりできないように、動作する OS 環境がおかしなものでないかなど、厳しいチェックが入るようになったようだ。
Nexus7 (2012) で 7.1.2 なんて、「おかしい」以外の何物でもない。
最新の Radiko が動かないのは仕方がないところだろう。
＃でも、先日買った Amazon Fire HD には Radiko 最新版入れられたな…
Amazon Fire で Google Play Store アプリを入れるとか、おかしいのだけど。
さて、途中で書き逃していることを説明する。
まず、先に書いた「Trimmer には意味がなさそう」について。
SSD には TRIM という仕組みがある。
なぜ必要かは長くなるので自分で勉強してもらおう。
ただ、この仕組みは最初からあったわけではないと知っておいてほしい。
当初、SSD は HDD の互換品として作られ、後に性能を上げるために TRIM という独自の仕組みが取り入れられた。
ところで、Linux という OS がある。
HDD で運用する前提で作成された OS で、いまは SSD でも使えるようになっている。
ここで、TRIM は OS そのものの仕組みとしては提供されていない。
OS 上で動作する別アプリケーションとして TRIM 動作を行うだけのものがあり、それを定期的に動かす仕組みだ。
このように機能を分離することで、OS 本体の方に HDD と SSD の違いなどを入れる必要がなくなり、プログラムが複雑になるのを避けられる。
そして、Android の中身は Linux だ。
Android は HDD を搭載しない… SSD 運用が普通なので、定期的に TRIM する必要がある。
しかし、Android 4.0 は、この「定期的な TRIM 」が動かないというバグがあったそうだ。
OS 本体が対応しないなら、アプリとして対応してやればよい。
Trimmer はそのためのアプリで、OS 内部にちゃんと持っている TRIM アプリ (fstrim という）を起動してくれる。
でも、4.0 でなければ fstrim はちゃんと起動される、らしい。
先のページがさらに参照しているページでは、「4.0 の時におかしくなったセクタが戻らない」と説明しているのだけど、fstrim の仕組みでは、そんなことにもならない。
だから、4.0 でなければ Trimmer はいらないと思う。
じゃぁ、なんで 4.4.4 を使っていても、１年の間にだんだん遅くなってきたのか、について。
Radiko のせいだと思っていたが、どうも冤罪だという件だな。
単純な話で、１年使う間にキャッシュがたまってしまったのではないか、と思っている。
前回も今回も、OS を入れなおしてすぐは、「快適動作」と感じている。
前回は、それから１年かけてだんだん遅くなっていった。
これは、入れ直しによって自然にキャッシュはクリアされてしまい、使うことで溜まっていったからではないか、という推論だ。
またしばらく使ってみて、また重くなることがあれば、まずはキャッシュクリアを試してみよう。
そうなった時には、またお知らせしたいと思う。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
１９日（日曜日）に、毎年恒例の「あーすフェスタ」に行ってきた。
本郷台駅前の「あーすぷらざ」で行われるお祭り。
「あーすぷらざ」は、異文化交流を目的とする施設で、あーすフェスタもそうしたお祭り。
なので、世界中の屋台料理が食べられる。珍しいビールが飲める。
変わった輸入雑貨なども売っている。
しかし、毎年恒例なので、子供はもうそれほど興味持ってないのね…
長男（中３）は、前日の土曜日がオープンスクール（参観日）だったこともあって「疲れたから家にいたい」。
長女（小６）も、友達とテレビゲームの通信対戦する約束した、とかで家にいたい。
次女（小４）が行きたがったのと、妻も行きたいというので、僕を含めた３人だけで出かけた。
３人で、というのは、実は去年と同じだ。
…今年は長女は来ると思ったんだけどな。
長男が自炊能力が怪しいので、一人だったら「昼ご飯勝手に作って食べな」というつもりだったのだが、最近料理好きの長女が昼ご飯作ってしまった。
さて、あーすフェスタでは、まずチャナダルを買いに行く。
一昨年買って、すごくおいしかった。
去年買おうとしたら、最後に行ったので売り切れていた。だから、今年は最初に行くのだ。
チニーズ、というスパイス屋さんの出店。
チャナダル 900g で 450円。今過去の日記読んだら、２年前から 50円値上げになっているな。
しかし、それでも激安。
他の商品を見ていたら、次女が「シナモンパウダー」に興味を示した。
サンリオキャラクターのシナモンが好きだから。
そして、隣にある「シナモンホール」を見て「なにこれ？」と不思議がる。
次女の知識では、シナモンはパウダーかスティックのようだ。しかし、シナモンホールはどう見ても木片。
シナモンって何だと思う？ と聞いたら、果物か何かだと思っている様子だったので、いい香りのする木の皮の部分だ、と教えてあげる。
じゃぁ、ホールってなに？ というのが次の質問。
他にもペッパーホールとか、バジルシードホールとか商品が並んでいるけど…
「丸ごと」って意味だと教えて、納得。
面白そうなので、シナモンホールを買ってみることにする。
さらに、妻が、バジルシードホールと、マスタードホールに興味を示した。それも買う。
ほかにガラムマサラと、次女が「前に食べておいしかった」というフェンネルの砂糖掛け。
結構買った。
昼ご飯時間帯なので、各国ご飯食べ歩き。
次女がケバブ食べたいという。
ケバブは人気あって、数店で出している。ちょうど焼きあがってそぎ落としている店があったので、そこでマヨネーズ味のケバブサンド（千切りキャベツと一緒にピタに詰めたもの）を購入。
アフリカ料理を出しているところで、アフリカ風のピラフ購入。
あと、アフリカンビール。「フルーツ＆ハーブ」というのがあったので買ってみたが、ビールじゃなくてカクテルだった。
＃原材料みたら、スピリッツにフルーツとアフリカンハーブを漬け込んだものを、炭酸水で割った、と英語で書いてあった。
アフリカンハーブの正体が知りたいところ。
まぁ、おいしかったからいいのだけど。
親だけビール飲んでずるい、何か飲み物ほしい、と次女が言うので、すぐ近くにあったタピオカドリンク購入。
味がいくつかあったので、マンゴー味にした。
家族でケバブとピラフを食べていたら、近くに中華の歩き売りが来る。
うまそうだったので、角煮・味付けゆで卵丼を購入。
…で、食べ終わって一息。
屋台を全部見てないので見てみよう、と少し歩くが、とりあえず追加で食べたいほどのものはなかった。
次女がフライドポテト欲しがったので、それだけ購入。
次女はフライドポテト大好きで、体の半分はフライドポテトでできているのではないか、というほど。
じつは、食い歩きを始める前から、呼び込みをやっていて気になっていたものがある。
「世界のお茶・コーヒー」を紹介する催しをやっているという。
ちょっと興味ある、と言ったら、妻も興味があるというので、見に行くことにした。
５つの国のテーブルがあり、それぞれ先着５０名だという。
１１時からやっているというが、すでに時間は１３時近く。まだ大丈夫かな…
会議室でイベントをやっていて、入り口で食券を買う方式。すでにいくつかは売り切れたという。
売り切れは、トルココーヒーと中国茶と、インドのチャイ。
しかし、それは幸いだった。その３つは飲んだことがある。
残りは、ベトナムと韓国のお茶。
…ここで、詳細を知り、「え？ ベトナム飲みたい！」となる。
ベトナムには、蓮茶があった。いつか飲んでみたいと思っていたあこがれのお茶。
ベトナムにはもう一つ、アーティチョーク茶もあった。
こちらは妻が興味を示す。実は、庭でアーティチョークを育てていて、「お茶にできる」と聞いて過去にやったことがあるのだ。
だけど、苦いばかりでおいしくなかった。ちゃんとしたものを飲んでみたい。
そしてもう一つ、韓国のお茶はトングレ茶。ユリ科の花の根のお茶、とのことだった。
３つあるんだから、３人で１杯づつ買って、全部味わおう…と思ったら、ベトナムは１回分の料金で２杯だという。
じゃぁ、ベトナムと韓国両方1杯づつで。
まずベトナムのテーブルに着く。
1杯分しかお金払ってないけど、どうぞ座ってくださいと3つの椅子を出していただけた。
さらに、お茶菓子は1つ分だけど、どうぞ飲んでくださいと、僕と妻の両方にお茶をくれるという。
どちらから飲みますか？ といわれ、まずはあこがれの蓮茶を、と頼む。
そうしたら、淹れている間、どうぞ蓮茶の茶葉の香りをかいでみてください、と器に入れた茶葉を出してくれた。
ここで、次女からの疑問。蓮茶って何？
蓮茶は、蓮の花の香りを茶葉に移した高級茶だ。
蓮の花は、開いてしまえば急速に香りが逃げてしまう。しかし、開く前のつぼみは固い。
そこで、花が開く直前の夜明けごろに池の上に船を出し、今から開きそうなつぼみを収穫する。
そして、つぼみを少し開いて茶葉を詰め込み、先端を縛って蓮の花の香りを移す。
手間がかかるので、もちろん高級茶。
そもそも、こんな手間をかけるのだから、茶葉の時点でも高級な良いものしか使わず、とても高価なものになる。
＃…という認識だったのだが、今調べたところ、つぼみに入れて縛る、というのは本当に高級な、王族が飲むようなものだけのようだ。
普通のものは、香りの元である花粉をたっぷりとつけたおしべと混ぜる。とはいえ、これでも高級品。
…と説明していたら「詳しいですねぇ。もしかして、奥さんベトナム人？」と聞かれる。
妻は生粋の日本人だが、肌が浅黒いので時々東南アジア系に間違われる。
今回いただいた蓮茶は、ティーバッグの安いもの。人工香料で香りをつけてあるようだ。
とはいえ、蓮の香りのお茶を初めて飲んだ。なかなかおいしい。
感激していると「今は、日本でも簡単に手に入りますよ。カルディで売ってます」と言われた。
カルディ、時々行って買い物してる。憧れのお茶を売っていたのに気づかないなんて。
お茶を飲みながらお茶菓子をいただく。
リンク先のベトナム菓子店のものを出してくれた。
豚の皮のお菓子、という意味だそうだが、豚肉が入っているわけではない。
見た目が美しい層になっていて、豚の三枚肉のようだ、ということらしい。
おいしい。独特の食感で、間に何かクリーミーなものを挟んでいる感じ。
…食感は、ういろうだな。
クリーミーに感じているものも、薄く焼いた生地を挟んであって、それが水分で柔らかくなっている感じ。
ベトナムだし、米粉を蒸したようなお菓子ですか？ と聞いてみたところ、タピオカ粉とのこと。
当たらずとも遠からず。間の生地はココナツミルクの香りだ。
とてもおいしかった。
「豚皮のお菓子」というのは、見た目が三枚肉に似ているから、とその場では聞いたし、今見つけたお菓子屋さんのページによれば、食感が豚皮に似ているからではないか、とのこと。
でも、饅頭とか羊羹と同じような由来ではないのかな。
両方とも、もともとは肉を使った料理で、後に肉を使わないおやつに変わったものだ。
アーティチョーク茶もおいしかった。
蓮茶は緑茶に蓮の香りを付けたものだけど、アーティチョーク茶はお茶の葉は入っていない。
ノンカフェインの…薄めの麦茶のような味わいだ。とてもやさしい味でおいしい。
ありがとうございました、おいしかったです、と伝え、次は韓国のテーブルへ。
韓国のテーブルは、ちょうどお客さんが多くて座席が１つしかなかった。
しかし、隣にフリースペースであるテーブルがあったので、そちらに座らせてもらい、いただく。
お茶を入れてもらっている間に、韓国のお茶文化を説明しているファイルがあったので読ませてもらう。
トングレ茶は、ユリ科のアマドコロの根を使ったお茶だそうだ。
今日いただくものは、トングレだけでなく、クコの実を一緒に入れて煮出しているそうだ。
それを読んで妻が言う。アマドコロなら、近所の森林公園に自生してるよ、と。
百合の根って、毒がある種類もなかったっけ？ と聞くと、「毒があるのと無いのが激しいので、素人がゆり根だとか言って適当に食べてはならない」とのこと。
まぁ、お茶として飲むのだから毒はないか、熱で壊れる種類の毒か、あっても「薬効成分」になるくらい弱いのだろう。
今調べたらたしかにこの花見たことある。
そして、実は有毒だそうだ。
お茶としては、こちらも麦茶のような風味。
お茶の葉が入っていないので、カフェインレスの優しい風味。
いただいたお茶菓子は、ヨモギ餅に少し乾燥させた感じの餡子をまぶしたようなお菓子。
こちらもおいしく…僕と妻は一口もらったが、次女が気に入って残り全部食べた。
以上で終了。
あーすフェスタの終了時刻まではまだ時間があったのだが、この日は夕方から長男の塾があったので、早めに切り上げた。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日洗濯機が壊れたので、すぐ買い替えた。
昨日到着した。
洗濯機というのは、入手したからと言って「すぐ使ってみよう」という性質のものではない。
そのため、わくわくしながら（？）マニュアルを読み、今朝になってやっと使った。
うん。なかなか良い。満足。
以下、以前の…１９年前の、今は亡き（吸収合併された）三洋製の洗濯機との比較なので、たぶん何の参考にもならないが書いてみよう。
サイズ。
記憶では、前の洗濯機を買ったときには、少し大きめの高価な機種を購入した。
これが「容量 7kg」だった。
今は、容量 8kg が標準的で、一番安い価格設定帯。
7kg で使っていて特に問題はなかったので、一番安い 8kg を購入した。
洗濯機を置くスペースというのは、どの家でも大体決まっていて、作りつけてあるものだ。
そのため、容量が増えてもあまり幅を広げることができない。必然的に高さが高くなる。
ところで、今の洗濯機の流行として「蓋の掃除がしやすい」という点がある。
今回購入したのは日立ビートウォッシュなのだけど、ふたがガラス製になっている。
先日購入した冷蔵庫でもそうだけど、汚れやすい部分をガラスにするのが最近の白物家電のはやりのようだ。
（白物家電、という言い方も古くて、白くないのが流行だ）
ガラスは腐食に強く、汚れても拭けば基に戻るから。
そして、「掃除のしやすさ」でいえば、継ぎ目のない大きな板であるほうが掃除しやすい。
そのため、昔の洗濯機に比べて、ふたが大きな一枚板になっているのが普通になっている。
前の洗濯機は、ふたがちょうど真ん中で折れるように畳む形で開けられた。
ビートウォッシュも２枚の板になっていて折れるのだけど、8:2 くらいのバランスになっている。
それで結局何が言いたいかというと、ふたを上にはね上げると、以前の洗濯機よりずっと上まで届いてしまうのだ。
背が高くなっているうえに、ふたを跳ね上げるときに使う空間が大きい。
「今までよりも、占有する空間が高くなっている」
そして、ここからは我が家の都合だ。
洗濯機って、その上の空間はデッドスペースになりやすく、我が家では洗濯機上ラックを使っていた。
この洗濯機ラックは、１９年前に前の洗濯機を購入したときに、かなり吟味して購入したものだ。
大きめの洗濯籠をちょうど入れられるスペースがあり、洗剤などの洗濯小物も置ける。
さらに上にも棚があり、もう捨てるぼろ布などを袋に入れておいてある。
あまり溜まると布ゴミとして捨てるが、必要に応じて雑巾などとして再利用する。
洗濯機の前側にも、バスタオルを掛けられるバーがある。
実は、洗濯機購入時点で、このラックの棚がふたを開ける際にぶつかってしまうことには気づいていた。
まぁ、仕方がない。ラックを買いなおそう…と思ったら、今ではこうしたラック自体が入手困難だとわかった。
最近はドラム洗濯機も多いので、前にバーを付けると邪魔になるため、バーはついていない洗濯機ラックが多いのだ。
また、ドラム洗濯機は上側にふたが開くことはないので、上部占有空間が少ない。
このため、棚を低めに作ってある洗濯機ラックも多く、高さ問題が解消しない。
もちろん、縦型洗濯機対応で、棚の位置が高くできる（組み立て時に選べる）構造のものもある。
その場合、上部に２段ある棚の下の段の高さを変える結果、洗濯籠が収まらないほど低いスペースになってしまうのだった。
もしかしたら、腰を据えてじっくり探せばいいものもあるかもしれない。
でも、古い棚をそのまま再利用する方法を選んだ。
話は簡単で、ラックが低いから問題なのだ。
洗濯機の横にレンガを置き、その上にラックの足を乗せた。これで 10cm ほどラックの背を高くしたら解決した。
洗濯動作。
静かで速い。
標準選択コースで、洗い時間が８分、脱水が６分になっていたかな。
以前の洗濯機は、12分 - 10分だった。
＃すすぎなどは時間不明。
汚れ落ちが同程度か、というのは１回しか洗っていないのでわからない。
でも、メーカーが自信をもって「標準」としている時間は、普通にきれいに洗える時間なのだろう。
モーターが良いものになっているようで、モーター音が静かになっている。
じゃぁ洗濯動作自体が静かなのかというと、以前よりも水音がする。
縦型槽洗濯機というのは、水流は基本的に「横方向に」回るものだ。
しかし、それでは上にある洗濯物が浮いてしまい、ちゃんと洗えないかもしれない。
そこで、昔から各社とも、横向きの水流でありながら、上下に水を攪拌する方法を工夫していた。
ビートウォッシュは、攪拌板を大きくうねらせることで、強い上下動を作り出している。
水音がするのは、この上下動で水面が強く動くためだと思われる。
…思われる、というのは、ふたを開けたまま洗濯できないから。
前の洗濯機は、洗濯動作だけならふたを開けたままできた。
そのまま排水まではできて、すすぎ前の脱水工程でふたが開いているとエラーになった。
脱水は、高速回転するために危ないからだ。
しかし、最近の洗濯機は洗い工程からふたを閉めていないとエラーになるようだ。
ふたはガラスだ、と書いたけど、それは表面がガラスだというだけで、透明なわけではない。
そのため中の水流とか、現在どのような状況で洗っているかなどは見ることができない。
湯取機能。
今時の洗濯機には、お風呂の残り湯をくみ上げる機能が、当たり前についている。
昔はあこがれの機能だったのに、今時は当然すぎて宣伝にも使われない。
我が家では、風呂の残り湯を洗濯に使っている。
まぁ、単純に水がもったいないからだけど、残り湯の方が水温が高いので洗濯効果が高い、というのもある。
今まではお風呂ポンプを使っていた。
スイッチ兼用になっているゼンマイ式のタイマーを回して、一定時間お湯が汲める奴だ。
使い勝手に慣れていて、だいたい必要量入れられる。とはいえ、アナログの時間設定なので、あくまでも「だいたい」だ。
これが、洗濯機自体にポンプ機能が付き、必要なだけ自動で汲んでくれるので適正量を入れられるようになる。
一方で、今までとは違う使い勝手の問題も出るだろうと思う。
…まだ１回しか洗濯していないので、この問題は出ていないのだが。
お風呂のお湯を捨てて洗うときには、先に洗濯機に水を汲んでいたんだ。
だいたいいつもの洗濯ものの量、という前提で水を入れてしまう。
洗い始めてから、実際の洗濯ものの量を目分量で測り、水位を調整する。
これ、先に書いたけど洗濯中にふたを開けられないので、「目分量で調整」ができなくなる。
夜の間に温かいお湯を入れ、洗剤を溶かしてしまい、タイマーで洗うのは翌朝、というのもよくやる。
こちらはできるようだが、夜お湯を入れていた理由は、先に書いたお風呂ポンプが手動だから、という理由も大きかった。
朝は、朝ご飯の支度などで忙しいので、同時に洗濯を行う際にお風呂ポンプを使いにくいんだ。
お湯を入れる都合上ふたは閉められず、ふたを閉めないまま洗濯をしていると、脱水工程でエラーになるから。
しかし、こちらの悩みは洗濯機自体にポンプ機能が付き、全自動でやってくれるために問題はなくなる。
タイマーを使うにしても、ホースをふろに突っ込んでタイマーセットしたら、お湯を汲む段階から翌朝やってくれる、ということでいいのだろう。
そして、全自動の利点として、すすぎにも風呂の水を使える。
手動でポンプを動かしていると、これはできなかった。
風呂の残り湯では水自体が汚れていて、完全な意味での「すすぎ」ができないため、ふろ水を使った場合は最後に少しの水道水ですすぎ洗いをしてくれるそうだ。
こちらの機能は、今朝は試していない。
今朝の段階では、いつも通りふろ水で洗って、水道水ですすいだだけだ。
また今度、すすぎもふろ水を使い、最後にわずかな水道水ですすぐ、というのも試してみよう。
湯取機能用のホースは、洗濯機横に掛けるためのフックが付属する。
しかし、完全に我が家の場合の話になるが、先に書いた洗濯機ラックを周りに設置するために、このフックが使えない。
以前から使っていた風呂水ポンプ用のホースフックがあり、これも一般的な洗濯機の横につけられるようになっているのだけど、汎用品であるがゆえに、今回ついていた「専用品」よりも取り付け部分の形状に余裕があった。
＃形状に余裕、ってわかりにくいのだけど、フック自体をどこかに掛けるためのフック部分が、より太いものに掛けられるような形になっていた。
このため、ふろ水ポンプ用フックは洗濯機ラックのフレームに引っ掛けることができ、いままでそのようにして使ってきた。
というわけで、洗濯機についてきた専用品は使わず、今後もふろ水ポンプ付属のフックを使うことにする。
風呂水ポンプ自体は…もう不要なので、次の家電ゴミの日に捨てよう。
糸くず取り。
地味な話だけど、前の機種は「高級機種だったから」糸くず取りのフィルタ機能がついていた。
今時、どの機種でも当たり前についている。
２０年前は、アイディア商品としての「洗濯物糸くず取りネット」というものが流行していた。
…あ、調べたら今でもありますね。あえて「２槽式専用」として売っているようです。
これは、洗濯機の中に吸盤で張り付けて、水流に逆らうように網を設置、洗濯物から出た糸くずなどを取ろうというものです。
で、話を戻すと前の洗濯機には、標準で糸くず取の機能がついていた。
洗う時の水流によって水が洗濯槽内部を駆け上り、上から洗濯槽に戻るようになっていて、そこに「ネット」が設置してあるという、単純な仕組みだった。
月に一度くらいは掃除するようにしていたけど、その程度の掃除で済む程度にしか糸くずは取れていない。
新しい洗濯機では、もっと直接的に、洗濯槽の横の水没する位置に専用の「糸取り」のための器具が取り付けてある。
虫取り網のようなネットではなく、網戸のように平らなネットで、しっかりと洗濯槽内部に取り付けられる。
そして、これはカプセル状のトラップにもなっていて、取り外して掃除しないと内部のごみが逆流するようなことがないようにしてある。
洗濯のたびに掃除するように指示があるので、１度の洗濯で開けてみたところ、結構糸くずが取れていた。
２０年前は「アイディア商品」レベルのものだったけど、２０年でしっかり役に立つレベルに洗練されているのだろう。
脱水。
ビートウォッシュでは、脱水時に洗濯物が絡まないように「ほぐして」脱水してくれる。
まだ１度しか洗濯していないわけだが、実際ほぐれていて感心した。
脱水時間が３０分伸びていいのであれば、洗濯物をかき回しながら空気を送り、ある程度乾かすという動作もできる。
乾燥機ではないので完全には乾かないが、部屋干しの際には良い、ということになっている。
（部屋干し脱水という名称になっている）
とりあえず我が家的には、この機能は不要。
夏は外に干すし、冬は部屋が乾燥しすぎるため、加湿器代わりに部屋干ししているので。
でも、面白そうなので今度試してみたいとは思っている。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
あまり政治的な話は書きたくないし、政治的な話にするつもりもないのだけど。
アメリカが Huawei への包囲陣を固めている。
僕個人としては、Honor6 plus から使い始めて、P10、P10 plus と３機種、３年半ほど使ってきた。
良い端末を作る良いメーカーだと思うし、当初言われていたような「疑惑」は、ほぼ言いがかりであることも各種証拠からわかってきている。
しかし、何も問題がないことと、アメリカが Huawei を潰したいのは別の話だ。
それで構わない。このことに文句を言いたいわけではない。
今回の話は、Huawei の事件がらみで、過去に書いた日記へのアクセスが伸びている、ということなのだ。
アメリカが日本製のパソコンに100%関税をかけた日(1987)
「今日は何の日」…パソコン関係の記念日とか、関係者の誕生日とか、そういうことを書いた記事の一環。
1987年に、日米半導体摩擦と呼ばれる問題の一環として、アメリカが日本からの輸入品に 100%関税をかけた…事実上輸入禁止にした問題。
この禁輸措置は、高品質で安価な日本製部品が入手できなくなったことにより、アメリカ中の産業が困って、たった２か月で解除された。
そもそも、この記事を書いたのが、トランプさんの就任直後だった。
Make America Great Again をスローガンとし、中国・日本・メキシコからの輸入…つまりは、それらの国に富みを奪われるのを阻止しようとしていた。
だから、記事の最後も「中国に対し、アメリカが強硬姿勢で臨もうとしている」というような文章で終わっている。
どうも、この文章が「予言だ」として話題になっているのだけど、書いた時点で強硬姿勢を取っていた。
今の Huawei への包囲陣はそのころから準備してきたものが現実になり始めただけで、予言ではない。
で、今回はもう一つの、当時の「日米間の問題」を書きたいんだ。
リンク先は Wikipedia なので鵜呑みにするのは危険だけど、僕も子供のころの事件だったので、これを読んで初めて全貌を理解した。
いままでの自分の理解では、東西冷戦時代に東側陣営に輸出禁止にされていた高精度な工作機械を、東芝の子会社がソ連に売ってしまった、というものだった。
これにより、ソ連製潜水艦のスクリューが静音化され、発見が難しくなったのでアメリカの、ひいては世界の国防上非常に問題がある、と。
まぁ、大体理解はあっていたし、多少の違いは今は問題ではない。
日米半導体摩擦と同時期だったような気がして調べたら、1987年だった。同じ年だ。
そして、この時期のアメリカ大統領は、というと…ロナルド・レーガン。
日本の中曽根康弘総理大臣と密接に連絡を取り合い、お互いを重要なパートナーだとして、ロン・ヤスとあだ名で呼びあった。
政策上重要なパートナーであることと、経済的な産業保護は別問題だ。
このころのアメリカは、経済的に少し陰りが見え、再び強いアメリカを取り戻そう、という熱望があった。
Make America Great Again は、レーガン大統領が大統領選の際に使った標語だ。
そして、経済的に急成長し、アメリカを抜かす勢いだった日本に標的を定めた。
日本企業が、アメリカが定めた「敵国」に対して輸出を行っていた、という事実を見つけ出して、罰則を科した。
これが、３月末のこと。
そのショックが冷めやらないうちに、今度は事実がない…しかし、アメリカは不利益を被っている「RAM のダンピング」を言い出した。
言いがかりであったとしても、その直前に国際的な事件が明るみに出て、国際問題を恐れている日本としては強く出られない。
そういう、２段構えの方法で日本に対する「禁輸措置」を強制的に発動した。
さて、今回の話。
まず、ＺＴＥが、アメリカの「敵国」であるイランと北朝鮮に対し、禁輸措置を破って輸出を行っていたという事実がある。
問題の輸出は 2010年に行われていたそうだ。
これが 2016年に発覚し、すでに制裁を受けて解決していた。
しかし、2017年にトランプ大統領が就任してから、急に問題が大きくされ、多大な罰金と、「同じ問題を繰り返さないため」アメリカの査察を今後１０年間受け入れる、という条件を付せられた。
ＺＴＥは中国の国営企業だ。
査察を受け入れる、ということは、経済状況が筒抜けになるということだ。
すでに解決したはずの問題に対して、大統領が変わってからわざわざ再燃させて、こんな条件を飲まさせたのだ。
そして、ＺＴＥとセットで Huawei を問題にし始めた。
ＺＴＥが問題のある企業だったから、同じ中国企業である Huawei も同じだろう、という、言いがかりに近いものだ。
あまりにも言いがかりなので、世界中のハッカーが Huawei 製スマホのプログラムを解析した。
怪しげなプログラムが仕掛けられている、というような事実は皆無だった。
しかし、そんなことはこの際どうでもいい。
事実があろうとなかろうと、アメリカが国防上問題がある「かもしれない」と感じたのであれば他人が口を出せる問題ではないし、可能性として問題があるのであれば取引はしない、というのは正常な判断だから。
ここにあるのは、東芝ココム違反で揺さぶりをかけ、動揺している間に半導体摩擦で一方的な制裁を科す、というのと同じ手法だ。
レーガン大統領と同じ、Make America Great Again という標語を使ったトランプ大統領が、レーガン大統領が日本に対して使ったのと同じ戦略で、中国に対して経済的な追い落としを狙っている…というのが現状に見える。
以上、最初に書いたように政治的な話が書きたいのではない。
政治というより、どちらかというと「歴史」だな。過去に同じような状況がありました、と書きたいだけ。
政治的な話にするのであれば、「中国製造2025」とかをヒントに検索してみるといいかもしれない。
今、アメリカが Huawei を標的にしたい理由がわかってくる。
でも、繰り返しになるが、今回は政治的な話を書きたいのではないので、ここまででやめておく。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
久しぶりにやっちまいました案件。
現在、家庭内サーバーで、外部とのメールのやり取りには qmail を使用している。
「過去においては」 qmail は悪くないメールサーバーであった。
初めて家にサーバーを建てたのが 2002年５月。
この時点の日記に、すでに qmail をインストールしたと書いてある。
前回サーバーを大幅に変えたのが2015年12月
この時にも、qmail を入れている。
ただ、どうもこの時に入れ方を失敗していたようなのだな。
そのまま、４年近く気づかないまま運用していた。
qmail は既にかなり古いメールサーバーだ。
次のサーバーを現在作っている…といったまま半年たっているが、次は qmail でないサーバーにしようと思っている。
しかしまぁ、qmail は古くて、長期運用実績も多く、安定している。
バージョンアップもほぼされないと思っていいので、細かくメンテナンスするような手間がかからない。
家庭用サーバーとしては理想的だ。
一方で、qmail はセキュリティを重視した作りになっており、プログラムは公開されているが「勝手に改変してはならない」ことになっていた。
「いた」というのは過去形で、今は配布条件が変わって改変してもいいから。
でも、もう十分に枯れている（技術用語で、安定していて手を加えない方がいい、という意味）ので、あまり改変する人はいない。
セキュリティは、十分に研ぎ澄まされたプログラムだから守られている。
ここに機能追加などの改変を加えると、セキュリティが保証されなくなる。
当初の改変してはならない、というのは、保証の意味合いを持っていた。
とはいえ、技術というのは日進月歩だ。
qmail が作られた当初と、現在ではネット環境も違う。
昔のままの qmail で今でも使えるのかといえば、そうではない。
そこで、バージョンアップは、有志の手で差分プログラム…パッチとして作られ、配布されている。
パッチであれば、その小さな部分のみを見て、「セキュリティ的に問題がないだろう」とか判断がしやすいから。
でね、このパッチがすごい量なの。
全部パッチ当てればいいのか、というと、セキュリティ重視の qmail に、誰が作ったのかわからないものをいろいろ入れ込むのも意味がなくなってしまう。
各自が必要なものを選択し、パッチを当てて運用する、ということになる。
で、前回のパッチの選択にミスがあったようなのだ。
今回、入れなおそうと思ったが、当時のコンパイルを行った作業ディレクトリを消してしまっていたようで、新たに作業した。
…つまり、今回が「前回＋必要パッチ」にできたという保証もない。
とはいえ、慎重に作業したから問題は出ないと思うし、今回起きていた問題も解消した。
今回起きていた、「恥ずかしい」ミスは、DNS 512byte の壁を打破するパッチが当たっていなかったこと。
DNS は、元々 512byte 以内に情報を収める、という前提で設計された。
qmail は、この設計に従って作られているため、DNS からの情報が 512byte 以内であると決め打ちして動く。
今の DNS は、512byte に収まらない場合に、もっと大きなデータを再送することになっている。
qmail はパッチを当てないとこれに対応できず、相手の DNS 情報によっては正しい送信先を見つけることができず、送信に失敗してしまう。
４月まではメールを送れていた仕事先があり、ここがゴールデンウィーク前に新たなサーバーを設置し、DNS を公開したことを知っていた。
なぜなら、そのサーバー設置を僕が行ったからだ。DNS 設定は僕ではなかったのだけど。
で、５月に入ってから送ったメールが届かない、と分かった。
普段はメール以外のメディアで連絡を取っていて、時々メールを使うだけなので気づいていなかった。
原因を調査したところ、手元の qmail-send のログに、
CNAME_lookup_failed_temporarily._(#4.4.3).
と出ていた。この原因を調べて、DNS 512バイトの壁問題を知った。
問題が特定できれば、あとは話が速い。
先に書いたように、過去にコンパイルした作業ディレクトリはなくなっていたので、新たに必要なものを集めて展開する。
必要そうなパッチも持ってきて、あてまくる。
で、コンパイル、インストール。
…おっと、qmail 動作中なので、プログラムの書き換えができなかった。
qmail を一旦停止し、再度インストール。
そして、qmail 再開。
家の中から、自分の gmail アドレスにメールを送る。届いた。
gamil から、家のメールアドレスにメールを送る。届いた。
あとは、今回送れなくなっていた相手先だけど…
キューに溜まっているだろうから、しばらくしたら再送されるよな。
そう思ってサーバーのログを見たら、ちょうど送信された後だった。
うん。問題解消したようだ。
一応、「どうもメールが届かないようだ」と気づいたメールは、送信してから１週間たっていなかった。
…と書くのは、qmail は再送ができない場合に、７日たつとエラーメールを送信元に返すからだ。
過去にも、こうしたエラーメールが戻ってきたことはない、と思う。
つまりは、今回が初めての問題だと…思う。
もし、僕から返事が来ない、と思っていた人がいたら申し訳なく思う。
一応、先ほど書いたように DNS のデータは普通 512byte 以下に収まるのだ。
今回、送信先はサーバーの増加で DNS データが 512byte に収まらなくなり、問題が生じた。
ただ、今後は DNSSEC を使うサーバーも増えるだろうし、そうなると 512byte に収まらない場合も増えるだろう。
DNSSEC を使うことの良し悪しはともかく、対応はしておかないといけない。
…そもそも、もう qmail に固執する必要はないんだよね。
最初に書いたけど、次は qmail やめよう、と思っているくらいなので。
１５年前は悪くない選択だったのだけど、今は良くない選択に思う。
今回は、やめようと思っているところに問題が起き、すぐに別のサーバーに移行はできないので、サーバープログラムを更新する形で乗り切っただけで。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
まだ１週間も使ってないのだけど、大体わかってきたところでレポート。
一回使ってみたところでレポート書いているので、買い物の参考にしたい人はそちらも読んでほしい。
まず、購入機種。
東芝ビートウォッシュ。BW-V80C。
ビートウォッシュは今一番売れている洗濯機のようで、売れているネームバリューがあるので東芝もシリーズ展開している。
大雑把に分けて、乾燥機能付きと無しの２つがあり、それぞれが洗濯物の容量で数機種ある。
BW-V80C は、乾燥機能がついていない「安い方」の、一番普及している容量…つまりは「安いやつ」だ。
しかも、末尾の C は 2018年度モデル。今年モデルではないので、安くなっていた。
徹底的に安いやつを買った、ということだな。
で、ビートウォッシュは名前の通り「ビートで洗う」…はずだったのだけど、買ってみたらその機能はなかった。
ドラム式洗濯機は、洗濯物を上に持ち上げて落とし、衝撃力で洗濯物から水と汚れを一緒に押し出す、という洗い方をする。
それに対し、縦洗濯槽（日本では昔からなじみの形）の洗濯機では、水流によって汚れを落とす。
一時期、ドラム式が急にもてはやされた時期があった。
叩き洗いだと水流は不要なので、少ない水で洗えて経済的だ、というのが理由だった。
ビートウォッシュは、これに対するカウンターとして東芝が開発した機種だ。
縦洗濯槽であるにもかかわらず、下部の水流を作り出す羽を大きく曲がった形状にし、洗濯物を上下動させる。
これなら、ドラムでなくても叩き洗いができる、というわけだ。
叩き洗いだから、ビートウォッシュ。わかりやすいネーミングだし、ドラム式と縦洗濯槽のいいとこどり、という感じで洗濯機のシェアを塗り替えた。
で、先に書いた通り、今のモデルではこの「叩き洗い」の機能はなくなっていた。
安いモデルだからない、というわけではなく、今は全モデルからなくなっているようだ。
どうやら、少ない水で洗うとどうしても汚れ落ちが悪く、評判がよくなかったらしい。
代わりと言っては何だが、風呂の残り湯を使って洗濯をする機能が充実している。
節水という意味では、残り湯を使うという方向に切り替えたということだろう。
Wikipedia を調べたら、現在の機種では、風呂の残り湯を使う機能はなくなった、と読み取れる記述になっている。
昔は「湯効利用」という名称で機能を宣伝していたようだが、あるころを境にこの名前をやめたようだ。
Wikipedia の記述は「残り湯を使う機能」と「湯効利用」を同一視する書き方で、2011年以降は湯効利用非搭載、となっている。
これではお湯取機能がなくなったように読める。
実際には、その後も改良されているようでかなり充実した機能がついている。
どう充実しているかというと、洗濯はもちろん、すすぎにもお風呂のお湯が使える。
我が家では節水の意図もあってすすぎは１回にしているのだけど、２回すすぎの２回目まで、お風呂のお湯でできる。
お風呂のお湯って雑菌も多いのに、洗濯物が汚れるだけでは…と心配する人も多いようだ。
価格.com の掲示板とか見たら、使うやつは馬鹿だ、みたいな書き込みもあった。
でも、一度使ってみればわかる。雑菌など残さない。
雑菌が残っていれば、部屋干しすれば匂いが出てしまうのでわかる。
風呂の水ですすいで部屋干ししても全く匂いなど出なかったので、この機能はありがたく使うことにした。
これにはもちろんからくりがあって、最終すすぎを風呂の水にすると、最終すすぎ後にわずかな水道水でもう一度すすぎをする。
この時使う水道水は、６リットルだけだそうだ。
それだけの水で綺麗にすすげる…ということはないと思うけど、汚れなんて程度問題でもある。
一番問題となるのは残った洗剤で、これは風呂水のすすぎで十分落ちている。
風呂水にはもちろん雑菌もいるだろうが、雑菌だらけで悪臭がする、ということはないはずだ。
前日普通に入っているからね。
ならば、最後に水道水で、脱水しても残った残り湯由来の「なにか」を薄める程度でも十分だろう。
水道水自体にも殺菌力があるしね。
乾燥機能も使ってみた。
脱水後に、洗濯物をほぐして風を通し、完全ではないがある程度乾かす、という機能。
乾燥時間も選べるけど、試しなので一番短い 30分で。
…これ、乾燥したといえるのかなぁ？ まぁ、脱水しただけよりは乾いているかもしれないけど。
どの程度乾いたかといえば、部屋干しして 30分置いたくらい乾いた、というところかな。
十分に風にさらしながら 30分置いといたんだから、計算は合っているね。
じゃぁ、電気代は使わず、部屋干しすればいいのではないかな、という結論。
先に書いたけど、部屋干しすると雑菌が繁殖して匂う…というのは実際にある話。
どうしても洗濯する時間が取れない人にとっては、洗濯だけしておいて外出し、帰ってから干す…ということもあるかも。
そういう時に、洗濯槽の中に入れたままだとなかなか乾かず、雑菌が増えて匂いが出てしまうだろう。
それを抑えるためにある程度乾かすのだ、とすれば、そういう人にはありがたい機能かもしれない。
でも、それなら帰る時間の少し前に洗い上がるように、予約洗濯すればいいような気もする。
ビートウォッシュには、ナイアガラすすぎとか、自動お掃除という機能もある。
ナイアガラすすぎは、じゃんじゃん水を使ってすすぎをする機能。
残った洗剤も徹底的に洗い流す、そうだ。
ということは、洗剤に一般的に含まれている、白さを際立たせる蛍光剤なども落としてしまうのだろう。
そこまでやる必要はない、と個人的に思うし、水がもったいないから使わない。
というか、これは「特別な時に使う機能」扱いのようで、選択コースに覚え込ませることもできない。
季節もの衣類をしまう前とかに、徹底的にきれいにしたい…という人が使うものだろう。
（僕はそういう思想を持っていない）
自動お掃除は、洗濯終了後に水道水を使い、洗濯槽の裏側を自動的に洗ってくれる機能。
こちらも、毎回やるのは水がもったいないから使わない。
たとえ洗っていたとしても、半年に一回は洗濯槽の洗浄を、と呼び掛けているので、機能がどれほど役立つのかもわからない。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日買った Fire HD 10 、Alexa が使えるのが思った以上に便利だった。
声で操作するって、最初は恥ずかしくて抵抗があったけど、料理中などには便利なものだな。
Alexa には「お買い物リスト」という機能がある。Amazon の買い物リストとは別物。
料理中に、ソーセージ使い切っちゃったな、と思ったら「アレクサ、買い物リストにソーセージ入れといて」って頼むと、すぐに入れてくれる。
でも、この買い物リストを家族で共有できない。
Alexa のお買い物リストは、Amazon のアカウントに紐づいていて、本人しか見られないのだ。
Wunderlist は、スマホで作ったリストを家族などで共有できるサービス。
類似サービスはほかにもあるのだけど、我が家ではこれを使っている。
類似サービスには、Alexa に対応していて、そのまま声でリスト追加できるものもある。
でも、Wunderlist は対応していない。
しかし、Wunderlist はメールに対応していて、メールを送ることでリストに追加できる。
さて、IFTTT というサービスがある。
技術的なことはさておき、「いろんな WEB サービスをつなぎ合わせるサービス」だ。
これを使って、Alexa の買い物リストに追加があったら、Gmail を使って Wunderlist にメールを出し、Wunderlist の買い物リストに登録する、という方法があることを知った。
この手法は結構古いらしいのだけど、上のページが丁寧に説明しており、そのまま設定すれば同じことができる。
…とおもったのだけど、やってみたがうまく動かない。
Gmail がエラーで送信できないよ、というエラーメッセージ。
このメッセージで検索すると、設定をこう変えればよい…などの情報が見つかるのだけど、どれを試してもうまくいかない。
IFTTT、3月31日からGmailのトリガーと下書き作成が利用不可に
それで見つけたのが、上のページ。
今はサービス終了した Google+ は、顧客情報が流出する可能性があるバグがあった、というのがサービス終了の決定打だった。
その後、Google はセキュリティを強化する取り組みを行う中で、Gmail を外部から操作できるようにしていたのを見直す、そのため IFTTT でも使えなくなる、という内容。
でも、ここでは「トリガー」が使えなくなるとしているだけ。
トリガーというのは、「メールが届いた」とか、状態変化を伝える機能のことで、「メールを送る」などの実際の動作を行う機能とは違う。
今回は、Gmail を使ってメールを送りたいだけなので、これとは関係ないはず。
さらに調べていたら、ちゃんと IFTTT のサイト内でこんなメッセージを発見。
Gmail actions may fail for some users.
Identified - The issue has been identified and a fix is being worked on. It will require a large rework in how Gmail is implemented, we appreciate your patience as we get Gmail up and running for everyone.
May 15, 16:51 PDT
意訳：
一部ユーザーで、Gmail でエラー
認識 - 問題は認識され、修正中です。Gmail の実装に大きな変更が必要なので、誰もが Gmail を使えるようになるまで、しばらくお待ちください。
つまり、僕のせいではなくて IFTTT 側の問題だったわけだな。
どんなに設定を見直しても無駄なわけだ。
「しばらくお待ちください」となっているが、もう２週間もこの状態のままのようだ。
いつ復帰するのかわからない。
上記調査中に、他にも気になることを見つけた。
IFTTT と Gmail と「日本語」の組み合わせを使うと、頻繁に文字化けするようなのだ。
IFTTT は基本的に英語サービスであり、日本語は「使える」が「保証されない」。
ここに、先に書いた Gmail 側の大変更なども加わり、日本語が化けるようになっては修正される、というのを時々繰り返している。
先に書いた、現在動かない件も含め、今後もこういうことがたびたびあるのかもしれない。
というわけで、不安定な Gmail に頼るのはやめよう。
幸い、Gmail 以外にも、普通の Email を使うこともできる。
ただ、Gmail では「誰にでも」送れるのに対し、Email は「自分にだけ」送れる。
Email の仕組み上、誰にでも送れてしまうと SPAM の発生源となるからだ。
自分にだけ送る、というのも、一度 Email でシステムがランダムな数値を送り、その数値を答えて認証を通さないといけない。
確実に自分向けの Email だと証明できた時だけ、自分宛の Email を自由に送れるようになる、ということだな。
そうなると、wunderlist 宛にメールすることはできないわけだが、幸い僕は自分のメールサーバを持っている。
届いたメールを、wunderlist 宛に転送しよう。
現在僕はサーバーで qmail を使っている。
qmail には、拡張メールアドレスと呼ばれる機能がある。
たとえば、ユーザー nobody のメールアドレスが nobody@example.com だったとしよう。
このとき、qmail では、nobody の後ろにハイフンと文字列を付けた nobody-ifttt@example.com もユーザー nobody に届くのだ。
しかも、この「届く」というのは、単にユーザーのメールボックスに届くのとは意味が違う。
同じメールボックスに入れる指示もできるけど、別のメールボックスに入れたり、片方だけプログラム処理したりもできる。
サーバーの時点で、ちゃんとメールを仕訳けてくれている。
自分のサーバーに qmail を入れている人には説明するまでもないのだけど、自分のホームディレクトリに
.qmail
というファイルを置くと、その内容によって自分宛のメールをどのように扱うか指定できる。
.qmail-ifttt
というファイルを置けば、自分のアカウントの後ろに -ifttt を付けたアドレス宛てのメールを処理できる。
ここに、次のように書く。
|sed 's/^From:.*$/From: nobody@example.com/' | /var/qmail/bin/qmail-inject me@wunderlist.com
メールボックスに入れるのではなく、このプログラムにメールを渡せ、という指示だ。
ここで、簡単なフィルタプログラムを書いている。
まず、From 行を書き換える。そしてそれを me@wunderlist.com に送る。
このままでは、実はヘッダに書かれた To: が自分のアドレスのままだ。
でも、wunderlist.com の方では、To: は気にしないようだ。
＃メールは、「ヘッダ」と「封筒」に宛先を書ける。配信は封筒のアドレス宛てに行われるので、
ヘッダのアドレスと配信アドレスが違うことはあり得る。
wunderlist.com の方には、僕のメールアドレスが確かに自分のものであることを事前に認証させてある。
このアドレスはヘッダの From: に書かれたものを認識するようなので、こちらは書き換える必要がある。
これで、IFTTT からのメールは、無事 wunderlist に転送され、リスト項目が追加された。
海外では、個人が作った alexa スキルで、wunder shopping というものがあるようだ。
IFTTT で Gmail が使えないのであれば、自分で Oauth 認証を通して連携させられないか…と方法を探す中で発見した。
これが日本語対応してくれれば、ややこしいことなしで wunderlist と連携できる。
でも、個人の制作物だから、対応は望めないだろう。
しかし、wunderlist との連携スキルを作ることは可能だ、と示されているわけでもある。
いっそのこと自分で作ってみるか…とまで考えた。
その時に、ふと「自分にメール送れるなら、転送すればいいんじゃん」と気づいて、上のような設定になった。
alexa スキル作成は、面倒くさいのでやらない。
でも、誰か作ったら使いたい（β版で人柱やってもいい）ので、教えてください。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
一昨日の夜のこと。
久しぶりに、会社員時代の友達に誘われて飲みに出た。
東京まで、家から１時間かかっちゃうので、夕方から飲みに出て、２～３時間の飲み会に出席して帰宅、というのは普段はやらない。
誘ってくれたのは、過去に一緒にゲームを作った時の企画だった同期。
その時に音楽を作ってくれたサウンドの先輩も呼んである、ということだった。
それともう一人、同期が時々仕事を頼むという、フリーのデザイナーの方。
デザイナーの方を除けば、このメンバーは以前にも集まったことがある。
その中に初めて入ったデザイナーの方も、同期が連れてきて良いと考えただけあって、すぐに気さくに打ち解けられる人だった。
まぁ、単に飲んだだけなので特に書くことはないのだけど、半分は仕事の話だったりする。
だからわざわざ出かけたのだ。
企画の同期、プログラマーの僕、サウンドの先輩、デザイナーの人。
同期が企んでいることがあり、飲みながらその話をしたわけだな。
サウンドの先輩がまだ会社員なので、昼間に会議をすることができなかったから夜になっただけなのだ。
＃先輩の会社は副職が認められているので、ちょっと仕事を頼むのは問題ない。
とはいえ、仕事の話なんて 10分で終わる。
後はどうでもいい話をして、久しぶりの近況報告など伝え合い、おいしく飲んだだけ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
本日をもって、５年ほど一緒に仕事していた会社との契約を終了した。
まぁ、まだ今日の夕方１７時までは仕事をしているのだけど、引継ぎも終わったし、今やる仕事が何もない。
なのでこんな日記を書いている。
たしか、この会社（Ａ社としよう）と契約したのは 2013年の末ごろだったと思う。
そのころ、それまで一緒にやっていた会社（Ｂ社としよう）の業績が急に悪化し、生活に困窮するほど収入が減った。
Ｂ社の仕事はまだ続けていたのだけど、生活ができないのでは仕方がない。
Ｂ社の仕事を打ち切らせてもらって、家族を養うためにもどこかで働こう、と思った。
この場合、Ｂ社の業務は停止し、その場でＢ社も倒産するだろう、と予想された。
しかし、Ｂ社の社長は僕ではない。社長がうまくやれば生き残れるかもしれないし、僕がそこまで面倒を見る義理もない。
その覚悟を決めて、どこかの会社を見つけて就職しようと思う、と妻に相談したら、それはもったいないと言われた。
フリーで働けるように家に環境を整えているのだから、別の仕事を探すにしても家でできるようにするのが良いのではないか。
いろいろ考えてそれは難しそうだと思っていたのだけど、もし家で働ければＢ社の仕事も続けられる。
その線で、もう一度仕事を探してみることにした。
それで見つけたのが、Ａ社の１か月短期の仕事だった。
ソーシャルゲームを作っていて、公開までの追い込み作業で Javascript を使える人を探していた。
…これ、あとでわかったが求人条件があいまいだった。
Javascript を使える人を求めていたはずなのだけど、実際の仕事の多くは HTML + CSS のコーディング作業で、主に必要だった技能は CSS Animation ができること。
加えて、Javascript も「少し」できる方が望ましかった。
僕は CSS は専門外だったが、必要だったのですぐに覚えた。
で、１か月バリバリ働いたが、１か月では終わらなかった。
締め切りはずるずると延び、公開まで３か月くらいかかったのではないかな。
で、無事公開にこぎつけたら、短期作業で参加した皆様お疲れさまでした…
となるのだけど、「できればこの後の運用にも参加してもらえないか」と打診された。
その時に、短期の時よりもずっと良い条件を提示され、そのまま今日まで契約を続けてきた。
この時のソシャゲは２年くらい参加していた。
その後売り上げが落ちたようで、チーム縮小に伴って作業を外れた。
しかし、その後売り上げも回復したのだろう。
現在も、このゲームは大型アップデートを経て「２」として続いている。
Ａ社の本業は WEB デザイン会社で、プログラマーは不足していた。
そこで、僕はいろいろな WEB ページの作成を技術面からサポートしてきた。
ひどい案件では、１ページごとに１つのプログラムと、１つのテンプレートファイルと、１つのコンテンツファイル（それに加えて画像などのファイル）で管理している、なんていうのもあった。
本来１ファイルで済むものを、なぜかわざわざ３ファイルに分けてある。それでいて、メリットは全くない。
この状態から、WEB ページ全体のデザイン改定をしたいというのだが…
少しづつ違うプログラムを、１つのプログラムで動くようにうまくまとめ、ページの数だけあったテンプレートも１つにまとめ、コンテンツファイル以外は集約できる形に直した。
そのうえで、テンプレートのデザインを変更して完了。
それまで、ページ追加ごとに、コンテンツとテンプレートとプログラムをコピペ・改造して作っていたというのだけど、これ以降はコンテンツファイルだけ用意すれば動くようになった。
作業が楽になったと喜ばれたが、コンテンツがファイル管理で FTP で置く、という旧態依然としたシステムなのは変わらない。
この時だって、DB を使った管理に変えることだってできただろうけど、それまでの作業フローを大きく変えない、というのが重要な場合だってある。
多くの仕事をさせてもらったので、Smarty も使ったし、PHP も使った。
ECcube や Wordpress といった CMS を使っているサイトも管理した。
基本的には「すでにあるページの維持やリニューアル」が多かったので、相手先の都合に合わせてなんでもできること、が求められた。
おかげで、多くのシステム環境を見ることができた。
どうしようもなく使いにくいシステムも多かったけど…
Wordpress を使いながら、もう１から作った方がいいんじゃない？ ってくらいに Wordpress 向きではないサイト作っていたりとか、普通にある。
それでも、要望されればプログラムをどこまででも書いて乗り切った。
Wordpress は、最悪の場合「システムを全然活用しない」ところまで改変できてしまうからね。
後の保守を任される人は大変だと思うけど、要望を出されれば作らざるを得ないのだ。
（保守のためにソース中にコメントをたっぷり残す流儀なので、あとの人はそれを参考にしてもらうしかない）
Web ページの持ち主の会社としては、大きめの有名どころが多かった。
Ａ社の営業手腕が良くてそういう会社の案件を取ってこれる、ということもあるだろうし、そもそも有名どころの会社じゃないと、外部委託してまで WEB 作成をしていないというのもあるだろう。
まぁ、そんなこんなで５年と半年くらいかな。
Ａ社とは仲良くしてもらい、感謝している。
Ｂ社は、ちょうど１年ほど前についに立ち行かなくなり、活動を停止した。
Ｂ社の社長は、会社を休眠させるが倒産にはしない、と言っていた。その後どうなっているかは知らない。
Ａ社との仕事を始めたとき、Ｂ社には正直に他の会社との契約を行ったこと、そのためＢ社に割ける仕事時間が減ることを伝えた。
Ｂ社のプログラマーは事実上僕のみだったので、仕事の遅れによる損失が出る可能性が高かったためだ。
これが同時に、僕が辞めたらすぐに倒産するだろう、と先に書いていた理由でもある。
必要なら別の人を雇ってもらう道もあったと思うが、Ｂ社の社長はそうはしなかった。
そのまま、仕事の進行ペースが遅れたまま活動停止に至ったわけだが、いっそのこと僕が辞めると言ってその場で倒産していた方が傷は浅かったかもしれない、とは思う。
この判断は僕がやるわけにいかなかったので、社長に判断を任せたつもりだった。
でも、社長も判断するのを嫌がってずるずると悪い状態が続いた感じ。
そんなわけで、Ｂ社はなくなり、Ａ社の仕事も今日で終わるので仕事無くなるよ…
ということでもあるのだが、実はＣ社というのもあったりする。
Ｂ社と同じくらい付き合いが古いのだけど、こちらの会社は時々しか仕事が来ない。
はるか昔に、この会社に依頼されて、ちょっと変わった CMS システムを作った。
（今、この WEB ページを動かしている自作 CMS があり、それを要望に合わせてカスタマイズしたものだ）
もう 10年以上前の話で、この CMS システムも、しばらく前に運用を終了している。
…のだが、このシステムを使っていた方で、どうしてもこのシステムを使い続けたいという人がいるため、１サイトだけまだ運用を続けている。
（まぁ、その一人のためにシステム維持しようと思う程度には、大物の人だ）
この CMS 作成の後は、バージョンアップやメンテナンス仕事も時々来た。
でも、その後は５年位何の仕事もなかったのではなかったかな、と思う。いや、年に一度くらい、単発の仕事はもらっていたかな。
そして、別のシステムの一部のメンテナンスを頼まれるようになった。
最初は「手が足りないから手伝ってもらえないか」から始まったのだけど、徐々に仕事を増やしている。
Ｂ社がなくなった後は、Ｂ社に割り振る予定で確保していた時間のいくばくかを、Ｃ社に割り振っていた。
で、しばらく前にＣ社から「もう少し時間を増やせないか」と打診を受けた。
Ｃ社は古い付き合いなので何とかしてあげたいなー、と思いつつ、Ａ社に「少し時間減らせますでしょうか？」と問い合わせた。
…で、いろいろ調整したのだが条件が折り合わず、今回はＡ社との契約解消、ということになったのだ。
とはいえ、別に喧嘩別れではないし、Ａ社としても僕の腕は買ってくれている。
今後も単発仕事などあったらご一緒できるかもしれない、という感じでの解消。
当面は、Ｃ社からの収入で生活していくことになるのだけど、先に書いた通り、Ｃ社はもともと単発仕事が多かった。
Ａ社はそれほど割が良かったわけではないのだけど、持続的な安定収入だった。失ったのはちょっと残念ではある。
というわけで、唐突ではありますが、お仕事ありましたらお声がけください。
先に書いた通り、一通りの作業経験ありです。
LAMP 環境 (Linux + Apache + Mysql + PHP) は基本として、Nginx / Redis なんかも扱います。
言語部分に関しては Javascript / node.js / Java / smarty / perl などなど。
元々は業務用テレビゲームを作っていたので、C やアセンブラなども。
先に書いた通り、CSS 使ってアニメーション作成、なんかもできますが、デザイン能力はありません。
お問い合わせはメールでお願いします。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
11年 Smalltalk,Squeak, Etoys, and Scratch!
申し訳ありませんが、現在意見投稿をできない状態にしています。 |