目次
2020-01-16 mysql で varchar を int に alter table する。
2020-01-14 忙しい
2020-01-03 あけましておめでとうございます
2019-12-28 【訃報】6502 の開発責任者、チャック・ぺドル
2019-12-25 メリークリスマス
2019-12-13 やっちましました。
2019-12-09 なんだか忙しいので
今月の日記
興味ない人には、なんのこっちゃわからないタイトル。
仕事で複数人数、複数のマシンで開発を行っているので、それらのマシンを同期しないといけない。
プログラムなんかは github 使って管理しているのだけど、DB 構造なんかの問題もある。
で、mysql (実際には mariadb だけど）のテーブル構造を、ファイル化してある。
このファイルは github で管理し、新しいサーバーを建てるときには、ファイルを mysql コマンドで
流し込めば完了する。
そして、開発中に「変更」になったものについては、alter table を列記したファイルを作る。
github から最新のデータを得たときなどは、このファイルを mysql に流し込めば完了する。
…というつもりで作業していたら、そう単純じゃない問題があったよ、という話。
もともと技術者でないとわからない話なので、ついてこれる人だけ読み進めてほしい。
alter table でテーブル構造の変更はできるが、alter table には IF NOT EXISTS というオプションがある。
「もし、その構造が存在していないなら」新しく追加する、などという動作を行う。
だから、先に書いたように、プログラム更新のたびに、必ずこの「 DB 構造差分データ」を DB に流し込めば、構造がすでにあれば無視され、なければ正しく追加される。
でも、「varchar(4) を tinyint に変えたい」で詰まったんだ。
設計段階ではいろいろあって varchar(4) してあったけど、事実上小さな数値しか入らない、と分かったため。
直接 alter table で変換しようとすると、「文字列を数値に変えられない」とエラーが出て失敗する。
これは、何もデータがない時に、NULL 文字列が入っていたため。
数値になった際も、0 は使わないとわかっている。だから、NULL 文字列は 0 に変換してほしい。
というわけで、事前に
UPDATE [table] SET [col]='0' where [col]=''
という感じで、'' を 0 に変える。それから alter table すればうまくいく。
…というわけでもなかった。
上の UPDATE 文、[col] が varchar の時は動いた。
でも、tinyint になると、エラーになって止まる。
先に書いた通り、このファイルはプログラム更新のたびに読み込まれるのだ。
すでに tinyint の時には、何もせずにスルーしてほしい。
エラーの理由はわかっている。
[col]は数値なので、where 句に書かれた比較は数値で行おうとする。
しかし、NULL 文字列は数値ではないので、「文字列を数値に変えられない」とエラーが出て失敗する。
…最初の問題に戻ってきた。
んぎぎぎぎ…どうすればよいのだ。
仕方がない。IF 文を使ってみよう。
僕は mysql を「単に使っていた」歴は長いのだけど、php や javascript と組み合わせていたことが多いため、sql のみで記述するファイルとして、IF を使ったことがない。
やりたいのは、「[col] の型が varchar の時だけ、各種処理を行う」だ。
[col]の型を調べるには、
show columns [table] like '[col]'
とすればよい。これで、画面上に型が表示される。
…いやいや、それはダメだ。画面上に出ただけでは、IF 文で判断できないじゃないか。
しかし、どうすればこれを基に IF の判断につなげられるのかわからない。
ところで、mysql はデータベースだ。データの扱いに長けている。
どれくらい長けているかというと、「自ら作成するデータベースの構造も、データベースとして格納されている」のだ。
つまり、先ほど show columns で見た内容も、実はデータベースに入っている。
データベース名 INFORMAION_SCHEMA の中に、テーブル名を示すテーブルや、カラム名を示すテーブルがある。
SELECT data_type FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name=[table]' AND column_name='[col]'
とすれば、目的のカラムのデータ型を得られる。
…が、これもまだ、表示されるだけだ。
また、サーバー内に複数のデータベースが入っており、同じテーブル・カラムがそれぞれにある場合、全てが表示されてしまう。
そのためさらに現在接続しているデータベース名で絞り込む必要がある。
「表示しかできない」という問題に対しては、show columns は名前の通り本当に表示だけだが、select は sql の中心的な構造なので、素敵なオプションがある。
先のコマンドの冒頭を
SELECT data_type INTO @type FROM ～
と変えてやる。 INTO @type が挟まっただけだ。
しかし、これで「表示」するのではなく、@type という変数に格納されるようになる。
もう一つ、目的外のデータベースも検索対象になることについては、WHERE の直後を変えてやる。
～ WHERE table_schema=database() AND tabel_name～
これで、データベースを絞り込める。
ここで、@type には varchar か、tinyint が入っているはずだ。
目的は、varchar の時だけ、tinyint に alter table することなので、
IF @type='varchar' THEN
UPDATE [table] SET [col]='0' WHERE [col]='';
ALTER TABLE [table] MODIFY [col] tinyint DEFAULT 0 NOT NULL;
END IF;
みたいな感じで処理してやればよい。
ただし、このまま mysql クライアントで流し込むとエラーになる。
; は「mysql サーバー的には」コマンドの区切りなのだが、「mysql クライアント的には」命令の終わりを兼ねるためだ。
DELIMITER で命令の終わりを変えられる。
なので、最初に DELIMITER で // を命令の終わりに変え、全てが終わった後で元の ; に戻してやるといい。
最初の SELECT から含めて全部を書くと、次のような感じになる。
SELECT data_type INTO @type FROM INFORMATION_SCHEMA.COLUMNS
WHERE table_schema=database() AND table_name=[table]' AND column_name='[col]';
DELIMITER //
IF @type='varchar' THEN
UPDATE [table] SET [col]='0' WHERE [col]='';
ALTER TABLE [table] MODIFY [col] tinyint DEFAULT 0 NOT NULL;
END IF;
//
DELIMITER ;
同じことで悩んでいる人、結構多そうだと思うのだけど、探してもそういう記事を見かけなかった。
ただ、「show columns の結果を変数に入れたい」とか、「文字列から数値のキャストの癖が強すぎる」とか、悩んで解決できていない記事は多数見つけた。
それらがすべて、僕と同じ悩みで書かれたわけではないだろう。
でも、同じ悩みの人の解決の手立てになれれば、幸いである。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
日記を全然書いてないし、正月にかろうじて書いた日記を読めばわかることなのだけど、
仕事が忙しい。
日記を書く暇もない。
より正確に言えば、仕事ばかりしているので、日記に書くようなネタがない。
本当は書きたいネタもある（12月頭に草稿を書いている）のだけど、詰めが甘くてアップできない。
詰めている時間はない。
とはいえ、日記だから…いや、もともと日々書いてはいないのだけど、あまり間が空きすぎないようにしたい。
箇条書きでも最近の出来事を。
長男、高校受験で精神的に不安定。
急に泣き出したりしたこともある。
塾に行っているが、ハードスケジュールだ。
塾は平日と土曜日に合計3日。
平日は午後7時から9時40分まで。
土曜日は午後1時30から6時半まで。
これが、年明けからさらに増えた。
土曜日に追加で、午前中10時から11時50分まで授業。
日曜日に、朝 8時50分から午後 5時までに模擬テスト。
僕が高校受験していた時はこんなにハードではなかったが、今はこれが「標準的」なようだ。
そして、模試を見せてもらったが、昔よりもずっと問題数が多い。
ちょっとでも悩んだら全体の時間が足りなくなるような分量で、昔みたいな時間配分で「見直し時間を確保しておき、迷ったら後回し」みたいな戦略は使えないようだ。
見直しの時間などなく、迷ったら捨てる、という感じなのだろう。
…これ、自分たちの世代が時間配分などのテクニックを駆使して「本来の勉学の成績とは関係なく、受験テクニックがあるやつが点数を取る」という風潮を作り出してしまったため、封じてきたのかもしれない。
でも、ルールがあれば対策も必ずある。
今のやり方だと、ダメと感じたときに潔く捨てられるやつが高得点を取りそうだ。
地道にコツコツ積み上げるタイプが低く見られ、すぐに派手な成果を出せるタイプがもてはやされる…
そんな時代が求める受験形式なのかもしれない。
神奈川県では特色試験、というものがあって、幅広い知識を必要とされる試験形式だ。
長男が模試を受けて「よくわからない問題があった」と見せてきたので、少しやってみた。
英語で、円周率が小数点以下何桁まで解き明かせたか、という歴史を説明した問題文。
これに対し、「この時代に、ヨーロッパと日本ではそれぞれどのような事件が起きたか」とか、「円周率の小数点以下の桁数を、横軸を西暦、縦軸を桁数の対数としたグラフに折れ線で示せ」とか、設問がある。
このうち一問が、円周率のような、ある程度の桁数以上を求めることに全く意味がない数学分野が、なぜこれほど重視されるのか、という説明に引き続き、その応用としての「公開鍵暗号」の仕組みを説明するものだった。
最初にざっくりと、公開鍵暗号の基礎の一つである、電子署名の仕組みを説明してある。
それを理解したうえで、小さな問いにいくつか答える形式だった。
しかし、長男は限られた時間内で電子署名の仕組みを十分に理解できず、正しい回答ができたかわからないという。
そーですか。最近の高校受験は、公開鍵暗号くらいは知ってないとだめでしたか。
（これはあくまでも模試なのだけど、この程度の問題は出てくるということだな）
電子署名のアルゴリズムは、問題文の中で説明されているので、知っている必要はない。
でも、「電子署名」というものが何なのか、という程度の知識はないと、アルゴリズムを示されても何をしたいのか理解できない。
そんなわけで、長男には電子署名というものが何か教えておいた。
「Alice と Bob が通信しようとしているところに、これを盗み聞きしようという Charlieがいて…」という定番説明をしたら、ウケた。
（この名前を出しただけで面白がった長男は、筋がいい。名前でありながら、単に A B C という区別記号にすぎないことを理解できたのだから。
暗号の教科書を見ると、たいていはこの3人が登場人物です）
昨年秋に台風で壊れたウッドデッキは、無事修復された。
昨年の末までに、大まかな工事は終わっていたが、白木だった。
今年に入ってから塗装が行われ、つい数日前に、物干しざおなどを支える金具が取り付けられた。
しかし、雨樋はまだ壊れたまま。
台風の後、雨樋の業者さんが一番忙しいらしい。
ウッドデッキは、基本的に「新築時の状態」に修復された。
時代の流れもあり、多少の部材変更はあるし、それに伴う設計変更もあるのだけど。
で、SWH では、ウッドデッキの床面は「塗装しないで引き渡し。家主が自分で塗装する」ことになっている。
SWH は木部が多い住宅で、メンテナンスは家主の責任だから。
ウッドデッキは比較的メンテナンスしやすいところで、最初に白木を塗ることから練習してもらう、という意図だ。
もう練習いらないから、塗ってもらえると楽できるのだけどな…と思うのだけど、白木での引き渡し。
今は寒いから、春になったら塗ろう。
小６の長女はスプラトゥーン２が大好きでずっと遊んでいるが、年末についに念願の「ウデマエＸ」に到達した。
スプラトゥーン２の中には、初心者向けの「ナワバリバトル」と、より難しいゲームである「ガチバトル」がある。
このうちガチバトルは、下から順に、Ｃ、Ｂ、Ａ、Ｓ、Ｘという「ウデマエ」分けがなされている。
厳密には、ＡＢＣの上下には－と＋があるし、Ｓの上にはＳ＋０～Ｓ＋９という10段階がある。
勝ち続ければウデマエは上がるし、負け続ければ落ちる。
大抵は、自分に合ったウデマエのあたりで上がったり下がったり、になる。
Ｘに到達できるのは、ほんの一握りだ。
さらに細かくは、ガチバトルは4つのルールに分かれる。ウデマエはそれぞれで別だ。
長女は、冬休みに入ってすぐに一つのルールでＸに達し、さらに大みそか直前にもう一つのルールでＸになった。
そして、「毎月頭に、評価が低い人は自動的に降格」というのがＸの特別ルールで、大みそかのぎりぎりの時間で残留を決めた。
（Ｘ以外は、勝敗で昇降格が決まる。しかし、Ｘは戦績で評価される数値があり、この数値によって降格が決まる）
さらに、年を挙げてすぐにまた別のルールでＸに。３つのルールでＸになった。
残る一つのルールは「もう少し」なのだけど、苦手でまだＸになれていないようだ。
僕はもう、スプラトゥーンは「諦めて」いる。
というか、最初から FPS はそんなに好きではない、とこの日記でも公言している。
今でも熱心なのは、長女と妻。妻は現在ウデマエＳ。
長女は、我が家の中で間違いなく一番強い。
この年末、我が家は急に「ジュエルペットてぃんくる」がリバイバルブームとなった。
長女が保育園のころに大好きだったアニメ。
その頃の次女は赤ちゃんだったため、見ていたことも覚えていない。
で、先日話をしていた時に、次女が「見たい」と言い出した。
当時の CATV での再放送を DVD に撮ったものならあるよ…と言っていたら、YouTube に公式に全話が公開されているのを次女が見つけてきた。
じゃぁ、こちらの方が画質が良い。
CATV は、SD 画質で、ハイビジョン放送の全体を収めるために、上下に黒い帯を入れて放送していたんだよね。
つまり、現在のテレビで見ると、上下左右に枠がある「額縁」状態になる。
ただ、YouTube での全話公開は、オープニングとエンディングはカットだった。
最終話だけ「特別編の」 OP・ED があるのだけど…
これ、放送時は「いつもと違う」からこそ、特別感があったのね。
YouTube でも最終話は OP・ED ちゃんとついていたけど、特別感が感じられないのがちょっと残念。
冬休み中に少しづつ見て、もう見終わったのだけど、長女・次女は ED の歌が好きで時々歌ってる。
歌い始めると、長男も一緒に歌ってたりするのが仲の良い兄弟でほのぼのする。
（あの歌は、僕もいい歌だと思う。
以前公言したが、僕はてぃんくるは好きなアニメ。久しぶりに見てもよかった。）
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今年は新年のあいさつエントリが遅めです。
まずは例年通り、今年のお節料理から。
栗きんとん、鶏ハム、伊達巻、煮卵。
…作ったのは、以上。今年は少なめ。
一応、かずのこ入り松前漬けは、半完成品を購入してきて作ったもの。
（封を開けて、材料を付属のたれで付けるだけ。かずのこは既製品を入れた）
いくらの醤油漬けは、秋のうちに作って冷凍していたもの。
その他、既製品で買ってきて入れただけのものは、
昆布巻き、きゃらぶき、うぐいす豆、ハム、伊達巻、紅白かまぼこ、さくらんぼの練り切り。
栗きんとんは特筆事項アリ。
長男が中学の科学部の畑で収穫した薩摩芋を使用し、長女と次女が２度裏ごしして作ったもので、非常に美味でした。
親戚の集まりで披露しても、すごくおいしいと大評判。
さて、おせち料理の手作りが少ない理由は、昨年暮れの仕事がぎりぎりまで忙しかったため。
１２月頭に、年内に作っておきたい、と頼まれた部分がそもそもボリューム多め。
それでも、なんとかほぼ作り上げています。
これに加え、２５日ごろになってから「この仕事もお願い」と頼まれたものが１つ。
まぁ、これは半日程度の仕事でした。
しかし、一番問題なのは、２７日…昨年の仕事納めと決めた日の、午後４時ごろに急遽入った仕事。
これが丸２日ほどかかる仕事になり、２８・２９の土日がつぶれました。
３０日は大掃除。
小４の次女はまだ私物を「捨てる」技術が身についていなくて、ガラクタの山を前に途方に暮れている始末。
一つ一つ聞き取りをして、本人が本当に置いておきたいものと、なんとなく捨てられないだけのものを分別しないとならない。
これがシャレにならない大仕事で、これをこなしつつもおせち料理の買い出し。
いつもより買い出しが遅いので、正月価格の高い材料しかない。
なんでタケノコの水煮一本で 800円もするのだ。（普段は 100円。結局捜し歩いて、250円で購入したけど）
この時点で、時間がないので作るものを大幅に絞り込む。
料理が少ないと寂しいので、豆やハム、昆布巻きなど、既製品を買いそろえる。
で、３１日に、大掃除の残りをやりつつ、少ない料理を完成させた、という次第。
今年は長男は高校受験を控えており、年末年始も塾があった。
こんな時まで塾で勉強する必要があるのか。
「気合を入れれば何とかなる」という非科学的主義の、本人がやった気になる、というだけの勉強ではないのか。
とはいえ、その「本人が満足する」ことこそが大切なのかもしれない。
受験生にとって、ライバルに後れを取る、というのが一番の恐怖だし、恐怖を感じながらでは正月気分も味わえないだろう。
というわけで、上に書いたようなおせち料理を作っている最中にも、長男の塾の送り迎えが発生する。
元日も、あさ８時過ぎには家を出て塾へ。夕方には帰れるのが「正月らしくのんびりできる」ところ。
（日曜日など、１２時間くらい塾に行っている）
昨日２日、親戚一同の集まりがあった。
毎年、母が同居している、長男（僕から見ての兄。上に書いた、僕の子の長男ではない）の家に行く。
今年は、兄弟の子供たち（僕から見て、甥姪）の集まりが悪い。
すでに多くが仕事を持っていたり、今年は大学受験だったりで、何かと忙しいそうだ。
というわけで、我が家の子供たちと、長男の子（長女）だけが、いとこの集まり。
いつもより寂しいかというと、あまりそういう感じではなく、むしろ人が少なめでスペースがあったため、持って行ったボードゲームをゆっくり遊べた。
昨年のクリスマスプレゼントから、「ラブレター」は、簡単なルールで楽しいので人気があった。
さらに以前のクリスマスプレゼントだが、タイムボムも人気。
「こんなにのんびり遊べるなら、街コロも持ってくればよかった」というのが子供の意見。
（あれは場所を取るゲームなので、遊べないだろうと思ってもっていかなかった。
しかし、我が家の子供たちの一番のお気に入りのボードゲーム）
我が家の長男、先述の通り、塾で忙しいため夕方から参加。
主な参加理由は「寿司とカニが食いたい」だった。毎年、用意してくれているから。
今年ももちろんあり、食べさせてもらった。忙しくて正月気分を味わえてなかったが、満足したようだ。
そして今日。
大みそかから３日間は、塾は「特訓」で忙しかったのだけど、今日だけは休み。
（また明日から通常授業）
長男ものんびり過ごし、やっと正月な気がする、と言っていた。
次女は宿題の書初めをやる、というので、先ほどまで指導していました。
（僕はとても字が汚いのですが、習字を習っていたことがあって、一応筆遣いなどは教えられます。）
これで、やっと僕も日記を書けているわけです。
明日は土曜日なのですが、仕事始め。
年末ぎりぎりまでやっていた仕事の続きをやらねば…
「年末までに終わらせたかったぶん」は終わっていますが、年始早々に使いたい部分は、まだ終わっていないのです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
6502 の開発責任者、チャック・ぺドル氏が、2019年12月15日に亡くなられたそうです。
…すみません。せっかく情報を得たので書いていますが、僕は訃報を聞くまで、氏のことを知りませんでした。
（正確に言えば、名前は知っていたが、何をした人かちゃんと認識してなかった）
6502の開発メンバーで、16bit 版の 65816 を作った、ビル・メンズチ氏のことは、過去に話を書いたのですが。
ぺドルも、メンズチも、モトローラで 6800 を作成し、スピンアウトして創業したモステクノロジーで 6502 を作っています。
その後、モステクノロジーはコモドール社に買収され、ぺドルは PET 2001 の開発を行っています。
メンズチがどこで袂を分かったのかは知りませんが、のちに独立して、6502 の改良版を作っています。
これは、Apple II シリーズに採用されています。
さらに、ほぼ一人で 65816 を作っています。
Apple II の 16bit 版を作りたい、という Apple からの要望で作られた、6502 と互換性を保った 16bit CPU です。
6502 は、8bit CPU で一番売れたのだそうです。
…訃報関連で読んだ記事にあったので、信憑性は定かではありません。
コンピューターとしては Z80 が大ベストセラーだったように思うのですが、Apple II や Commodore 64 などが 6502 を搭載していました。
Z80 は「多くの機種で採用された」のですが、Apple II シリーズは大ベストセラーマシンで、それに対抗できるのは Commodore 64 くらい…
という２強でしたから、CPU の数で行けば 6502 はかなり多かったかも。
そして、パソコンだけでなくゲーム機に目を移せば、ファミコンと PC エンジンが 6502 でした。
「一番売れた CPU」というのも、信憑性があります。
ぺドルのことは、忘れなければ来年の１周忌にはちゃんと記事にしたいところ。
今は忙しいので、駄文のみで、訃報を伝えるとともに記録しておく次第です。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今年は忙しくて、全然クリスマス気分が盛り上がらないまま、クリスマスを迎えてしまった。
とはいえ、クリスマスのお祝いはする。
子供たちに料理は何がいいかと聞くと「ローストチキン」とのことだったが、丸鶏はやめておき、骨付きもも肉４パック入りの袋を２袋用意。
丸鶏は盛り上がるし、子供が小さいうちは良かったのだけど、子供が大きくなると家族で１羽が微妙に足りないのだよね。
当日は、仕事の合間を見ながら、前日から冷蔵庫で回答してあった肉に、下味を染み込ませる。
夕方になってからオーブンに入れて１時間ほど焼くが、この間も仕事をしていた。
毎年リンゴを一緒に焼くのだが、今年は買い忘れてしまった。
代わりに、プチトマトがあったので半分に割って一緒に焼く。トマトも焼くと結構うまい。
あとは、ジャガイモと玉ねぎも一緒に焼く。ゆっくり１時間焼いた玉ねぎは甘くて美味しかった。
料理ができたが、年末の銀行処理に行った妻が帰ってこない。
当然だが、混んでいたらしい。その後買い物に行ったが、こちらも混んでいたらしい。
わかっていたのだけど、仕事上処理しないといけないものはあるのだ。
妻を待つ間、まだ時間があるから何か作ろう…と、オニオンスープを作る。
オニオンソテーは冷凍ものだ。一度使ってみようと思って買ってあったのだけど、冷凍でも結構高いから使い時を待っていた。
しかし、酒やジュースも飲むのにスープは余計だった。
もも肉だけで満足するか不安だったが、必要なら適当に出すことにする。
パーティ開始は７時過ぎになった。
毎年、料理だけで腹いっぱいになってケーキを食べれないのを知っているので、ケーキはこの日は買っていない。
とはいえ、全くデザートがないのも寂しいので、シュトーレンを出す。
シュトーレンは薄く切って食べるものなので、満腹でも大丈夫。
翌朝、つまり今朝。
サンタさんのプレゼントが、子供部屋に布をかけておかれている。
長男が前日遅くまで起きていて、８時過ぎまで起きてこなかった。
長女・次女は、みんなで開けようと長男が起きてくるまで待っていた。
今年のサンタさんのプレゼントは、
・ニンテンドープリペイドカード 9000円分
・カルカソンヌＪ
・ラブレター
だった。
カルカソンヌ、有名ゲームだけど僕は遊んだことなくて、遊んでみたかったんだよね。
ありがとう、サンタさん。（マッチポンプ感）
最近長男は忙しいので、短い時間でできるゲームもあるといいな、と思っていたところに、ラブレター。
こちらも遊んだことなかったのだけど、楽しいと聞いている。
プリペイドカードは、長女・次女が「Switch で春に出るどうぶつの森を買いたい」と言っていたので、それまで置いておくことになるだろう。
任天堂のゲームなら、２本購入の権利が 9980円、というお得チケットもあるので、少しお小遣いを足してそれを買うといいと思う。
短時間で遊べるので、という理由で、まずはラブレターを次女とやってみた。
（長男・長女は別のことをやっていて参加しなかった）
非常に単純なゲーム。
２人で遊んでいると、場合によっては、最初にめくったカードでゲームが終了する。
何回か遊んだが、気軽に遊べる割には、しっかり考えないといけないところもある。
これは名作だと評価されているのがよくわかる。
１プレイ 10秒から、最大でも３分程度だったので、７～８回遊んで終了。
カルカソンヌの方もやってみよう。
ここで、こちらには興味がある、と長女も寄ってきた。
初プレイ。
カルカソンヌＪには、拡張ルールも入っているが、拡張なしで遊ぶ。
さらに、少しややこしい「草原」ルールはなし。つまり、標準ルールよりも単純化。
カタンみたいなゲームなのかな、と思っていたのだが、もっと気軽だった。
気軽だけど、しっかり考えるところはあるし、楽しい。
もう一度。今度は草原ルールも入れる。
１度目と違い、ルールが理解できたので、激しい攻防が増える。１度目ほど単純にゲームが進まない。
楽しいゲームだったが、２回目を終わったところで、１０時近くになったので終了。
子供たちは冬休みだけど、今日は平日で、僕は仕事があります。
また夜にでも遊ぶことにしよう。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
自分が三流プログラマーだと告白するシリーズ。
たびたび大きなミスをしでかしては日記に書いている。
懲りずにまたやっちまいました…
今回のやっちまった事例は、ssh でしか接続できないサーバーの ssh キーを壊してしまった、ということ。
つまり、サーバーに入れなくなってしまった。
自分で立てたサーバーならそういうことはしないだろうけど、ほかの人に設定してもらったサーバーだった。
AWS EC2 上の ubuntu サーバーで、ユーザー名 ubuntu でログインするようになっていた。
開発サーバーとして用意されたので、sudo bash して root で使ってください、と言われていた。
ところで、これは開発の都合で「開発サーバーを移行する」ための措置だった。
以前のサーバーも AWS EC2 上の ubuntu サーバーだったのだけど、その上に docker 環境が作ってあり、その docker に root でログインして使うことになっていた。
しかし、本番サーバーでは docker は使っておらず、環境の微妙な違いが問題になっていた。
そこで、本番と同等の環境に移行する、というのが今回の目的だった。
旧サーバーでは、git が使えた。github と連携して管理していた。
しかし、新サーバーでは git が使えなかった。使えるようにしないと開発ができない。
そこで、git が使えるように設定した。
ここまでは何も問題ない。
さらに、github に接続するため、旧サーバーから rsa 暗号鍵のファイルを持ってくる。
root のホームディレクトリ下に .ssh を作り、そこに鍵を置けばよい。
ところが、うまく github に接続できなかった。
ファイルのパーミッションを確認し、置いた箇所を確認し、あっているはずだけど…と pwd して気づいた。
置いた場所、root のホームではなく、ubuntu のホームだ。
旧サーバーでは、root でログインするので、ホームに移動すると root だった。
しかし、新サーバーで推奨された sudo bash は、bash を root 権限で起動するだけのコマンドで、ホームディレクトリは ubuntu のままだった。
そこで、root のホームディレクトリに鍵を移動する。
これで、github に接続できるようになった。
まぁ、そんな作業を昨日は行って、一通り環境構築は終わった。
で、今朝入ろうとしたら、入れないんだ。
最初は何で入れないのかわからず、管理者の人に「入れないんですけどー」とか気軽に聞いていた。
でも、そのうち自分がしでかしてしまったことに気づいた。
普通、root 権限では ssh ログインはさせない。
だから、root は ssh 鍵を持たない。
root で作業を行い、github に接続する際にも、root に ssh 鍵を持たせることに問題はない。
以前のサーバーはそうした設定で運用していた。
しかし、僕は新サーバーで、 root ディレクトリのつもりで ubuntu ディレクトリに鍵をコピーしてしまった。
ここで、ubuntu の鍵を壊してしまっているのだ。
じゃぁ、鍵が書き換わったのだから、github で使っている鍵で入れるはず…
しかし、試しても入れない。
その鍵で、root に入ろうとしたら、接続できた。
接続はできたのだけど、「root では入れないよ。ubuntu を使ってね」ってメッセージが出て切断される。
つまり、root のログインシェルが、メッセージを表示して切断するものに変えられているのだ。
先に、鍵を入れる箇所を間違えたので「移動して」と書いた。
これは状況証拠から自分がそうしたのだろう…と思っているだけで、記憶は確かではない。
しかし、移動ではなくコピーだったら、ubuntu でも入れたはずだ。
だから、無意識のうちに最悪の選択をしてしまったのだろう、と推察している。
そんなわけで、管理者の人に多大な迷惑をかけることになってしまった。
あとで、ボリュームを切り外して別のマシンに接続し、鍵を書き戻してくれるそうだ。
そうすればとりあえず使えるが、非常に面倒な操作をお願いすることになった。
とりあえず、旧サーバーがあるので開発はそちらで続けられる。
問題はないのだが、しでかしてしまったことの大きさに、申し訳ない気分でいっぱいである。
言い訳：
僕はプログラマーではあるが、サーバー技術者ではない。
ただ、なまじサーバーがわかるものだから、設定書き換えて面倒を起こしていることが度々ある。
翌日追記
自分がキーファイルを消してしまったのだろう…という想定で書いたが、復旧してくれた管理者さんによれば、キーファイルの上書きはさすがにやっていなかったらしい。
しかし、「authorized_keys の owner が root:rootでした」とのこと。ubuntu:ubuntu でないといけない。
あれぇ？
自分で何の操作をしたかちゃんと覚えていないのだが、キーファイルのコピーなどはやっていたが、authorized_keys のパーミッション変更なんてした覚えがないのだが。
もっとも、「してはならない」ことなので、やった覚えがあったらそちらの方が問題ではある。
いつの間にかやってしまったからこそ、事故なのだ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
忙しいと、すぐに日記を書かなくなってしまう。
ほんの３週間前にもそんなことを書いて、だらだらと身辺記だけ記したのだけど、またそうした身辺記です。
そろそろ長男の高校受験が本格化してきて、それも日記を書かない理由になっている。
土日も朝から晩まで塾があって、家族でちょっとしたお出かけもできないのだよね。
必然的に、日記に書くようなネタも起こりにくくなる。
どうも、自分が高校受験したころ（３０年ほど前だ）に比べると、常識にあたるものが全然違っている。
自分の時だって受験勉強は大変だったけど、休みもなく毎日朝から晩まで勉強…ということはなかったよな。
台風で壊れたウッドデッキ、工事が始まった。
来年になる、と聞いていたが、それは完成の話で、取り合えずできることから始めるそうだ。
先週木曜日に壊れた部分を解体し、土曜日に基礎作り…の予定が、雨が降ったので基礎の枠だけ作成。
今日、基礎のコンクリートを流し込んだ。
もう１週間ほど前になるか、キャンプ用の充電電源と、折り畳み太陽電池を購入した。
災害時に電源が欲しい、という、以前からの妻の希望による。
電源は 400wh の容量を持ち、200w の電力を引き出せるもの。
色々調べて買ったが、この手の製品としては中堅どころのようだ。
（もっと安くて容量が低いものもあるし、もっと大容量で高いものもある、という意味で）
太陽電池は、折り畳み式で 100w 出力可能なもの。
とはいえ、これは理論最大値で、良く晴れた日に試したが、冬の日差しでは正午ごろでも 65w 程度だった。
電源は購入時に 30% 程度の充電になっていたが、太陽電池で１日では 70% 程度までしか充電できなかった。
翌日も引き続き充電してみたところ、100% に達した。
充電してから気づいたが、非常用に長期保存を前提とするなら、満充電より少し少ないくらい…70% 程度で保存しておくのが良かったようだ。
まぁ、数か月置いたら自然放電でどこら辺まで減っているか確認しよう。
合計で６万円ほど。
災害がいつ来るかはわからないし、充電池は置いとくだけでも劣化するので、最悪の場合６万円で「安心」を買っただけ、ということになるかもしれない。
しかし、その安心感が何よりも大切だとも思う。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |