目次
2021-02-23 Lenovo Ideapad due 購入
2021-02-22 全然日記書いてない
2021-02-02 節分
2021-01-29 微分積分いい気分
2021-01-26 ノートパソコン修理
2021-01-23 100倍規模
2021-01-14 カセットポン
今月の日記
昨年８月に、Ideapad C340 を購入している。
今度は Ideapad due を購入。
C340 は 14inch の普通の Windows ノートパソコンだ。
で、due は 10inch タブレットの Chromebook 。
いままで Android 10inch タブレットを使っていて、その買い替え。
といっても、今までのマシンも性能上の不満はない。
妻が性能が良いタブレットがほしいといったので、僕が買い替えて今まで僕が使っていたものを渡すことにしたのだ。
今まで使っていたのは Huawei Mediapad T5。
その前には旧 Amazon kindle Fire HD 10 を使っていた。Kindle は安いからね。
でも、旧Kindle は性能も低くて、本来の使用用途である Prime Video の閲覧ですら、重いことがあった。
そこで Mediapad を購入した。
（注：今の Kindle は性能が上がっているので、重くないと思う）
で、動作が軽くなったら便利なので、時々キーボードをつなげてドキュメント作成などもする。
あと、Web ブラウジング。
便利に使っていたら、先に書いたように妻がうらやましがるので、もう一台買うことにした。
そこで、今度は Chromebook を選んでみたわけだ。
昔 Chromebook を使っていたことはあるのだけど、その頃は本当に Chrome が使えるだけだった。
今は、一部制限はあるが、Android のアプリや Linux が動く。
一方、普段は当然のように Windows を使っているし、仕事で Web アプリ開発をしているのだけど、Android の Chrome だと、PC のものとは若干動作が違っていて、やりたいことができないこともあった。
僕は仕事柄 Linux 端末はよく使うし、先に書いたように Android アプリは Amazon 関係が動けば、まぁいい。
Chromebook は、Android 版ではなく、PC 版の Chrome と同じものが動作している。
そんなわけで、Chromebook でもいいんじゃないかな、という興味で購入してみたわけだ。
due にはタブレットと言いつつ、キーボードが付属する。取り外し可能だし、10inch に合わせた狭いキー配置なので、使い勝手はそれなり。
じつは、この日記もそのキーボードで書いてみている。
HP200LXとか、Linux Zaurus、Netwalker を使っていたことを考えると、ずっとまともなキーボードだ。
（比較対象がひどすぎる気はするが）
まだ届いてから数時間しか立っておらず、使い勝手は十分確認できていない。
でも、とりあえず普段づかいにできそうなことは確認済み。
またしばらく使ってみてからレポート書くかもしれないけど、何も書かなかった場合は「書くことがないほど普通に使えている」ということだと思ってほしい。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
２月の日記が、「今年の節分は１日ずれた」という短い記事だけだ。
これではいかん。何か書かねば。
…といったところで、書くようなことがないから書いていないのだ。
寂しいから近況報告など。
コロナの緊急事態宣言で外出を控えるように言われているため、どこにも行けない。
どこも行かないのでネタがなくて日記書いてない、という側面もある。
仕事で作成している WEB サービスは、現状ではコロナが追い風となる形で順調に行っている。
ちょうど、集会ができないときにネット上で使いやすいサービスだったんだな。
もっとも、これは当初の使い方の予定とは異なる。
元々は「集会で」使うことを想定したサービスだったんだ。
集会で、集まった人が手元のスマホで意見を出し、それを即座に集計したものをグラフとして示す。
そういうサービスだった。
でも、Zoom などを使った、パネルカンファレンスなどが行われるようになると、それらに使われるようになった。
パネルカンファレンスって、普通なら壇上に数人の「有識者」がいて、その人たちの意見を聴衆みんなで聞くような形式ね。
公開インタビューだと思っていい。
Zoom では、数名の参加者による「会議」を、参加はしないが聴講だけできる多数のユーザーに配信する機能がある。
コロナ禍に於いて、従来予定されていたカンファレンスを、Zoom での配信に切り替える例も多い。
でも、Zoom だと、聴衆はただ聞いているだけなんだ。
従来の形なら、「ちょっと皆さんにもお伺いしたいのですが」と挙手をお願いしたりできたのが、Zoom ではやりづらい。
そこで、仕事で作成している WEB サービスの出番となる。
スマホで応えて即座に集計する、というのは、集会で使うことを想定していた機能だったのだけど、全員が離れた場所にいても使える。
しかし、想定していなかった使い方をすると、問題はいろいろと出てくる。
プロジェクターなどで投影することを考慮していた画面デザインは、Zoom で見せるには文字サイズなどの面でバランスが良くはなかった。
スマホで答えてもらうための URL の共有方法にも難点があったし、従来考えていた「以上」の人が同時に配信を受けるなんてこともある。
集会に集まれるのなんて、せいぜい 1000 人程度だと思っていたんだ。でも、ネット配信ならそれ以上でも参加可能だ。
ここのところ、ずっとこれらの問題を解消するための作業をしていた。
というか、まだ続いている。
現場から使い勝手の悪い部分について、どうにかできないかと要望があがってきて、ブラッシュアップの日々だ。
こういうサイクルは嫌いじゃない。作りごたえを感じるから。
まぁ、忙しいのはそんな理由。
作っていて面白いのだけど、企業秘密もあるのであまり詳しくは書けない。
書いていいレベルのことは、これまでにも小出しで書いているけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今年の節分は2月2日。
20年前に、400年に一度のうるう年調整が入った関係で、遅くなりがちだった立春がもとの状態に戻った影響だ。
まあ、生活には関係ないし、今後は時々あるのだけど、めずらしいので記録。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
このタイトル、すでに分からない人の方が多そうだな。
急に思い出話。
まだ僕が大学１年生だったころのこと。
PCルームがあって、放課後は入り浸っていた。
その場にいる人の多くは、僕も所属していたコンピューターサークルのメンバー。
でも、そうではない常連の人もいて、学科もサークルも違うのに知人、という人もいた。
そのうちの一人…同じく１年生で、簡単なプログラムは組めるが本格的なゲームなどは作れない、というくらいの知人が、ゲームによくある、ジャンプの動きを作ろうと頑張っていた。
その知人は「ジャンプは放物線なのだから」と、何かの二乗を使って書こうとしてたんだ。
（二乗のグラフとして描かれる線を、放物線と呼ぶ）
でも、そうじゃない。ゲームならジャンプは次のように書く。
（当時は BASIC を使っていたので、BASIC 風に）
10 X=X+1
20 IF INKEY$=" " THEN JUMP=1:Y1=-5
30 IF JUMP=1 THEN Y=Y+Y1:Y1=Y1+1
40 IF Y1>5 THEN JUMP=0
50 PUT SPRITE 0,(X,Y),8,0
60 GOTO 10
このプログラムはサンプルなので、初期設定を省いているので、雰囲気で読んで欲しい。
ともかく、こんな感じのプログラムを作って、こうやるんだよ、と見せてあげた。
そうしたら、返ってきた反応は、「なんかずるい」だったんだ。
動きを見ると放物線っぽく見えるけど、プログラム中には二乗どころか、掛け算もない。
それは放物線ではない、というのだ。
いや、別にずるくないよ、と言い返したが、その時の自分には「ずる」ではないという明確な根拠を示せなかった。
今なら明確に示せる。
これは、放物線の式に対し、一階微分した導関数を導き出し、その導関数を再び積分することで放物線を再構築しているんだ。
なぜ微分するかというと、ゲームは時間によって微分された世界で動いているから。
テレビ画面は、連続した「時間」を、1/60 秒ごとに区切って表示する。
このわずかな時間の動きは、時間で微分されている、ということになる。
そして、その微分したものを積み重ねていく。
テレビで言えば、一連の「コマ」を連続させて動かすことが、積分にあたる。
…厳密にいえば、微分ではなく差分だし、積分ではなく積算なのだけど。
これを言い出すと離散数学というややこしい数学の話になるので、今は微分積分という呼び名で話を進める。
僕のプログラムを見た知人は、「プログラム中に二乗がないので、放物線ではない」と言った。
しかし、プログラム上は微分したことで二乗が消えている。
そして、プログラムを動かすと時間変化によって積分され、正しい放物線が描かれる。
これを「ずる」だというのは、微分積分を理解していない残念な人間だというのを、自ら明かしたに過ぎない。
（もっとも、すぐに言い返せなかった自分も、その時には十分理解できていなかったわけだけど）
本当に足し算だけで二乗になるのか、まだ疑う人がいるかもしれないので、わかりやすい例を挙げよう。
まずは、単純なルールで作りだせる、次の数値の表を示そう。
| 0 | 1 | 4 | 9 | 16 | 25 | 36 | 49 | 64 | 81 |
| 1 | 3 | 5 | 7 | 9 | 11 | 13 | 15 | 17 | 19 |
この表のルールはこうだ。
・上に書かれた数値は、その左側の列の上下の数値を足したもの。
・下に書かれた数値は、その左側の列の下の数値に、2を足したもの。
足し算しか使っていない、非常に単純なルールだ。
おかしいところがないか検算してもらってもよい。
ここで、上の数値は、もう一つの意味を持つ。
0,1,2…と続く数値の「二乗」になっているのだ。
日本人なら 9*9=81 まではわかるだろうから、上の表は 81 で止めてある。
でも、もっと長く続けても大丈夫。これも試してもらってよい。
「ずる」と言われたのが悔しくて、根拠を考えていたら、数日後にはこの答えに行きついた。
でも、サークルも違うし学科も違ったので会う機会はそれほどなく、言い返すタイミングは永久に失われた。
それを思い出して急にここに書いたのは、ネットで「微分積分なんて実生活でどう役に立つのか」なんていう…まぁ、よくありがちな学生の愚痴を見たから。
微分積分、生活で超役立つ。
上に書いたように、テレビゲームは微分積分の世界の中にある。
そもそもテレビが微分積分の世界だし、デジタルテレビなんかフーリエ変換（微分積分の親玉みたいなやつ）を駆使して作られている。
ただし、役立てられるかどうかは、自分次第。
ゲームやテレビの中に微分積分が駆使されている、なんていうのは知らない人は全く気付かない世界だ。
それでも生活はできるのだから、知らずに生活している限りは、高校で習った微分積分は「役立てられていない」。
役に立たないのではなく、役立てられないのだ。
なんでかといえば、勉強が浅かったから。「どうせ役立たない」なんて思ってるから。
世界最初のコンピューター、と呼ばれる ENIAC は、実のところ「ひたすら足し算する機械」にすぎない。
それでも、数学的に正しい…どころか、空気抵抗なども考慮した「弾道計算」ができた。
先に書いたように、足し算だけで数学的に正しい放物線は求まる。
しかし、それは空気抵抗や風などがない理想状態での弾道にすぎない。
ENIAC では時間で「微分」した方程式を使い、繰り返し計算して「積分」することで、弾の速度の関数となる空気抵抗や、風の影響なども考慮に入れ、物理現象としての「弾道」を描き出すことができた。
空気抵抗が弾の速度の関数になる、なんていうのは、瞬間ごとの速度を見ながら抵抗を導き、それによって速度を調整する、というのを繰り返しながら積分する方法でないと計算できない。
そうした計算が複雑すぎて人の手に負えないから、ENIAC を建造したわけだけど。
ともかく、ここで重要なのは、どんなに複雑な数式であっても、微分を繰り返せばただの足し算になるということだ。
そして、足し算をひたすら繰り返せば、元の複雑な数式の答えを導き出せる。
（ここでいう答えとは数値演算であり、式の変形ではない）
ENIAC は弾道計算よりももっと複雑な、水爆の内部圧力の計算なども行っている。
使われた計算は全部足し算のみだ。それが微分積分の威力だ。
今回、この話を書こうと思ってネットを調べていたら、以下のようなことを書いている人がいた。
（一連のツイートだが、特定人物を批判したいわけではないため、検索されないよう文面は変えている。）
・ファミコンで三角関数を使うと遅くなるので、スーパーマリオのジャンプは掛け算だけで作られている。
・掛け算だけなので本当は放物線ではないのだが、ゲームを作るうえでのうまいごまかし方だと言える
…まぁ、プログラマーでない人がうろ覚えの知識を披露しただけだと思う。
しかし、どこから突っ込んでよいかわからないほど違っている。
まず、ジャンプを表現する放物線に、三角関数は必要ない。掛け算だけでよい。
そして、ファミコンは掛け算すら遅いので、足し算だけで作られている。
さらにいえば、先に書いたように足し算だけで書いてもごまかしではなく、数学的に正しい放物線が描ける。
ただ、スーパーマリオのジャンプは、放物線ですらない。
放物線にすると、操作が難しくてゲームにならないから。
それでも放物線っぽく感じられるようにしている。
これが「うまいごまかし方」だというのは同意だが、計算できなかったからではなく、ゲームを面白くするためだ。
背景が全く違う。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨年８月に購入したノートパソコンが壊れた。
壊れたといっても、起動はできるし普通に使える。
ペンコンピューティング可能なマシンだが、ペンも使える。
でも、指で直接ディスプレイにタッチした際の操作が効かなくなった。
それ以外の症状はない。
最初は、ペンは使えるがタッチは使えない、というので、タッチパネル自体は壊れてないんだよね？
と思ってドライバ不具合などを疑った。
調べると、Windows アップデートなどでドライバが不具合を起こすことがある、という情報があったし、うまく動かなくなった直前に Windows のアップデートを行っていた。
じゃぁこれかな、と思って、メーカーのページに書かれていたトラブルシューティングの方法に従ってドライバを入れなおす。でも治らず。
さらにネットの情報を探す。
我が家の機種とは違うが、同じシリーズの以前の機種で、同様の問題を発見。
タッチディスプレイのケーブルが内部基板から外れやすくて、ペンは使えるのにタッチのみ使えなくなりやすい、という。
後継機で前の機種のトラブルが対応されていないことは無いと思うのだけど、症状的に似通っている。
ケーブルが外れているだけなら自分で治せるかもしれないけど、保証期間内だったので素直に修理に出すことにした。
まず、メーカーのページで修理申込する。
不具合のある機種を使って申し込みをすると、自動的に機種を判別し、保証期間内であることが示される。
そして、自己診断プログラムのダウンロードを促される。
このプログラムを入れると、自動的に自己診断が始まり、その情報とともに修理申込ができる。
その際、マシンのシリアルナンバーなども自動判別される。
我が家の機械の場合、故障個所はない、という診断だったが、申し込みはできた。
自己診断の限界もあるのだろう。
住所氏名や電話番号などの連絡情報を入れたのち、不具合について記入。
タッチパネルが反応しないがペンは動くこと、公式の方法でドライバの入れ直しも試みたことなど書く。
で、翌日にはメールで返事が来た。ハードウェア故障の可能性が高いので引き取り修理をするという。
引き取り日の希望などを返信するが、最短で翌日。で、翌日には佐川急便が引き取りに来たので本体を渡す。
梱包などは佐川の方でやってくれる。
当日のうちに到着連絡が来たが、この日が金曜日だったため、週末の間は修理は進まなかった。
そして、昨日月曜日に修理完了の連絡があり、今日には手元に戻ってきた。
一応、メーカーのページには「到着から１週間から１０日で修理完了します」とあったし、さらに「コロナ禍で修理依頼が増えており、少し時間がかかるかもしれません」とお詫びがあった。
しかし、メーカー到着の次の営業日には修理を行い、翌日こちらに届くというスピード修理。
まぁ、本当にハードウェア的な故障で、部品交換で済んだからすぐ終わったのだろうけど。
ソフトウェアのコンフリクトなどを「不具合」として修理に出す人もいるみたいだし、そういう問題はすぐには解決できない。
同じテーマの日記(最近の一覧)
別年同日の日記
14年 iOS の position:fixed バグ回避方法
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
お仕事の話。ほぼ愚痴。
100名程度の使用を想定して作ったシステムがあり、開発をお手伝いしている。
ありがたいことに人気が出て、人気が出ると想定外の使われ方をし始める。
特に、多人数で使いたいという要望が多く、1000人規模でも使えるように1年ほど前に大規模改修を行っている。
僕はこの改修の途中から参加させていただいた形だが、システムのスループットは上がり、1000名でも使えるようにはなった。
この際に、さらに人数を増やすこともできるような設計にはしていたが、それは「設計」だけで、実際には対応できていなかった。
それが、今回1万人で使いたいという依頼が来て…
いや、依頼はしばらく前から来ていたのだ。というか、依頼は1万人とも限定していなかった。
最大5万人くらいということだったが、それはさすがに難しそうなので、1万人に制限してもらったのだ。
システムはいくつかのパーツに分かれているが、サーバー部分は改修の際に、node.js で作り替えられていた。
node.js はサーバー側で動作する javascript 環境だ。
細かな話を書くと長くなるが、もともと javascript はブラウザ向けの技術だった。
そのため、非常に癖の強い特徴を持つ。
一番重要なのが「ノンブロッキング」であるということだ。
ブラウザはユーザーが操作するものなので、その操作を阻害…「ブロック」してはならない。
これがノンブロッキングという思想。
言語が動いているときは、ユーザーの操作を受け付けられない。
そう仮定すると、ユーザーの操作を阻害しないため、言語は無駄な実行時間をかけてはならない。
とはいえ、普通のプログラム言語にはたいてい「何かを待つ」処理が入るものだ。
ファイルを読んだり、ネットで通信をすると、CPU よりもはるかに遅いディスク装置やネットワークのデータを待つ。
プログラムをしていると、ごく当たり前のことだ。
javascript では、これらのことは「行えない」。
待たせてはならない、という設計思想だからだ。
とはいえ、ディスクを読んだり通信をしたり、というのは当たり前のことで、もちろんできる。
どうやるかというと、待つのではなく、いったん終了してしまうのだ。
「通信してね」って頼んだら、終了する。
そして、通信が終わると、「通信終わったよ」ともう一度処理を起動してもらう。
javascript では、一事が万事この調子。プログラムを組んでいると、非常に組みづらい。
まぁ、最近では昔より環境が整えられ、かなりマシになったのだけど。
そして、あえてこの使いにくい環境をサーバーで使うと、「待ち時間のない」プログラム環境を実現できる。
待ち時間がないということは、常にプログラムが動いているし、リクエストに応えられるということだ。
従来…というとちょっと古いのだが、Wordpress などに使われる PHP では、1秒間にせいぜい 10リクエスト
くらいしか答えられない。
でも、同じことを node.js で実装すると、1000リクエストくらいは答えられるのだ。
＃PHP はインタプリタだが、node.js は即時コンパイルだ、とか、PHP はプロセスフォークで動く Apache 上で動作するが、node.js はシングルプロセスなのでタスクスイッチのオーバーヘッドがないとか、他の要因も多分にあるのだけど。
それでも期待できるのは 1000人レベルだ。
大規模改修で node.js を使って 1000人規模に対応した、というのがこの段階。
今回1万人規模のリクエストなので、node.js をクラスタ化して対応することにした。
node.js は、シングルプロセスで動作する。
たった一つのプログラムで、1000以上の接続に対応するのだ。
しかし、これは CPU がマルチコアだったとしても、１コアしか使わないという意味でもある。
CPU のコアの数だけプロセスを増やせば、理論上はもっと多くの接続を処理できる。
もちろん、そのための制約はいろいろとあるのだが、最初から「マルチプロセスで動かすことができるように」という設計をしていた。
そして、pm2 という node.js 対応のプロセス管理ツールを使うと、プログラムは無改造のまま、マルチプロセス化できる。
（通常、プロセスが増えると、それぞれが別の通信ポートなどを用意しないといけなくなる。
通信ポートが増えれば、アクセスするクライアント側もそれに対応しなくてはならなくなる。
しかし、pm2 は代表して１つの通信ポートを作り、配下のプロセスのポートに適切にデータを流してくれるので、外部から見るとそれまでのプログラムと何ら変わらないように見える）
というわけで、処理性能は何倍かに跳ね上がった。
…でももちろん、話はそんなに単純ではなかった。
接続が増えたら、当たり前だがそれらの接続ごとに、データを収めた DB へのアクセスが発生する。
１プロセスで 1000 人程度をさばいているときには問題にならなかったが、１万人規模になると接続ができなくなった。
DB の接続数の上限設定があるのだ。これは、 DB の設定を書き換えて解消する。
これに伴い、適切なワークメモリの割り当てなども変える必要があるが、とにかく設定した。
DB が接続を受け付けられるようになっても、その接続のための通信ポートが十分作れない。
OS 側に、通信ポートをいくつ作れるか、という設定があるのだ。
それらも設定する必要がある。
UNIX では、すべてのリソースがファイルとして扱われる。
通信ポートも１種のファイルだ。そして、UNIX には、プロセスごとに開けるファイル数の制限がある。
この制限も増やす必要がある。
100 人程度なら問題なし、1000人でも大丈夫だったとしても、１万人規模になるとそれまで気にしていなかった設定が問題になるので、問題発生のたびに何が悪いのか調べ、設定をチューニングする必要が出る。
それまでは問題にならなかった DB の Query が、突如として slow query になる、というのもあった。
DB へのアクセスが激しすぎると、特に問題がなかった部分がボトルネックになりだすのだ。
…これらは、上に書いたような順序で、理路整然と起こったわけではない。
とにかく不具合が続出し、原因を切り分け、考えられる要素をひとつづつ潰していく必要があった。
上に書いたのは、「結果としてそういうことだった」というだけで、原因がわからないので見当違いの設定に手を出して、何も変わらないので元に戻す、というようなこともやっている。
問題はサーバー側だけではなかった。
１万人規模、と書いたが、その規模の人たちがサーバーに接続し、操作した結果を集計して表示する画面がある。
普通の WEB ページとして作られているので、PC さえあればインストール作業などなしで表示できる。
この画面自体は、サーバーと接続しているだけだ。接続が増えるようなことは無い。
だから特に問題は出ないだろうと思っていたら、１万人分…１人についてのデータが複数あるため、数万件のデータになると通信に支障が出た。
特に、何らかの不具合が起こって画面のリロード…と考えたとき、数万件のデータ再送信はそれだけで１分程度の時間がかかる。
通信したデータを、ローカルにキャッシュして持つように改良した。
再起動が行われた際は、まずキャッシュからデータを読み込み、続きのデータの送信をサーバーに依頼する。
５秒程度で表示が行えるようになった。
この表示も１万件あると遅くなった。
全部を表示したいのだが、ただ１万行の HTML というだけで、重くてスクロールもままならないのだ。
これはプログラムテクニックで乗り切った。
どこかに詳細なテクニック紹介をしたいのだけど、忙しくて概要説明だけ行ったままだ。
100人を想定して作ったものを、１万人向けに提供する…となると、思わぬことがいろいろと発生する。
同じテーマの日記(最近の一覧)
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
割とどうでもよい話なのだけど。
今朝、NHK ニュースを見ていたら、タイのサトウキビ栽培の話をしていた。
サトウキビは収穫時に尖った葉がかなり邪魔で、茎の部分は十分水分を含んでいるため、火をつけてしまうと葉だけが燃えて、収穫が楽になるのだそうだ。
でも、これで出る煙が公害で、社会問題化しているらしい。
そこで日本の大手砂糖メーカーが技術提携して、社会貢献している…という話。
このニュースで気になったのは、内容ではなくて出てきた会社。
インタビューに答えた会社員の所属が「砂糖メーカー カセットポン社」となっていたのだ。
カセットポン…PC-6001 を思い出す。
ジャンケンポン、カセットポン
というキャッチコピーで売り出した 8bit PC だ。
当時は家庭用にパソコンを売り出した黎明期。
第一陣となった PC-8001 / MZ-80 あたりは、カセットテープからプログラムを読み込む必要があり、非常に遅かった。
ちょっと使うのにいちいち待たされるのでは家庭用に向かない、というので、プログラムを ROM カートリッジに収めて、挿せばすぐ使える、というのが、家庭用への普及には必要だと考えられていた。
PC-6001 は、その最初期のものだが、のちには IBM Jr. や MSX など、カートリッジを搭載して家庭向けの普及を狙った機種は多い。
（もっとも、ATARI 社が出したゲーム機が ROM カートリッジのアイディアの先駆だろう。それを PC にも取り入れよう、という動きは世界的なものだった）
ちなみに、今では「カートリッジ」と呼ばれるが、当時は「カセット」と呼ばれた。
カセットテープはメディアとして普及していたので、簡単に交換できるものを「カセット」と呼んだのだ。
（今でも、カセット式ガスコンロとかある）
話を戻す。
ニュースに出てきた「カセットポン社」の名前を見て、僕は上のように交換式の何かを連想したのだ。
何で砂糖メーカーでカセットポン？
元は名前にふさわしい別の事業をやっていたが、仕事の幅を広げて砂糖も作っている？
気になったので調べたら、カセットポン社は三井物産と、子会社の三井製糖が共同出資するタイの現地法人だった。
三井製糖、と書いてもよくわからないかもしれないが「スプーン印」と書いたら誰もが知っているだろう。
で、答えは三井製糖の CSR 報告書に書いてあった。
（CSR 報告書とは、企業として社会的にどのような貢献を行っているかの情報をまとめたもの）
タイの言葉で、カセット (เกษตร:Kaset) は農地、ポン (ผล:phol) は実り、利益、収穫を意味するそうだ。
（CSR報告書７ページ右下）
そんなわけで、「なぜ砂糖の会社でカセットポン？」と疑問に思っていたのだが、農業法人らしい非常に良い名前だった。
しかし、日本語的にも非常に面白かったので、ここに記しておく次第。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |