複数の作業環境を渡り歩いてソースコードを編集することって結構ありますよね？
こんな時、新しく編集した部分だけインデント文字(タブかスペース)やオフセットが変わってしまって、手作業でスタイルを合わせる破目になった経験があるでしょう。
テキストエディタが同じなら作業前に設定ファイルをコピーすればなんとかなりますが、違うエディタだと設定に使った時間の方がコーディング時間より長くなったという悲劇(笑い話？)も聞きます。
そんな時に頼りになる最終兵器 EditorConfig を発見しました。
共通の設定ファイルを用意しておけば、エディタにプラグインを入れるだけで同じスタイルで書けるようにしてくれます。
設定できる項目はインデント文字、オフセット幅、改行文字、文字コード等です。
ディレクトリを遡りながら設定ファイルを探すので、スタイルがプロジェクトごとに違っていても対応できます。
興味がわいた方は、分かりやすい説明がここにあるので参照してみてください。
参考
仕事でファイルをメールする時に、暗号化したファイルを添付したメールと、そのパスワードを書いたメールを別々に送信するケースをよく見かけます。
私はこれを無意味だと思っています。
なぜなら、暗号化ファイルのメールを入手できるならば、パスワードのメールも入手できると考えるのが妥当だからです。
暗号化ファイルとパスワードの両方が揃ってしまえば、元のファイルを(暗号化せずに)そのまま送ったのと同じ事になります。
むしろ『安全に送った』気になる分だけ逆に危険です。
安全な方法で一番簡単なのは『電話する』ことです。
次点としては『SMSで送る』(スマホや携帯で相手の電話番号を使ってメッセージを送る機能)でしょうか。
どちらの場合も『メールとは別の手段』を使って『メールアドレスとは別の方法』で指定した相手に伝わる点が重要です。
どうしてもメールする場合には、せめてパスワード文字列の一部分だけを伝えて、それの【前】と【後ろ】に事前に決めておいた文字列を追加するくらいの用心をすべきです。
例えば【前】には「mae_」を、【後ろ】には「_usiro」を付けると事前に決めておけば、メールで「pass」と送った場合の実際のパスワードは「mae_pass_usiro」になるわけです。
次の機会にパスワードとして「word」とメールしたら、実際のパスワードには「mae_word_usiro」を使えばいいわけです。
これならばメールにパスワード全文が記載されないので、多少はマシになります。
もちろん、前後に追加する文字列はメール以外の手段で伝えるのは言うまでもありません。
ちなみにパスワードの類似品として『パスフレーズ』というものが使える場合もあって、きちんと使えばこちらの方が強度が高いそうです。
以上、知らないと怖いパスワードの話でした。
まずは、ざっくりとした一覧です。
よく使われるのは「アタッシェケース」とか「ED」あたりですかね。
こうしてまとめてみると、思っていたよりも色々ありますね。
特に Windows に certutil コマンドがあって、エンコードとハッシュ計算ができるのには驚きました。
それと、暗号化ファイルを元に戻す時には(大抵の場合)同じソフトが必要になります。 渡す相手には何のソフトで暗号化したか伝えておきましょう。
今回は短いです。ライトニングな感じです。
xargs なんですが、結構 find と組み合わせて使いますね？
…使いますよね？
…ここは空気読んでウソでも「使う」って言う所ですよ？
で、パイプした find の出力が空だった場合でも xargs の部分が実行されてしまうんですよ。
衝撃の事実ですね。ええ、インパクトありますよ。rm -rf とか食わせてると特に…
まあ、今回はテストで echo 付けてあったので死なずに済みましたが。
というわけで、crontab とかのバッチ処理の時は xargs -r の使用を考慮しましょう。
こうすると、入力が空の時には xargs に食わせたコマンドが実行されません。
バッチ利用(大抵は cron)の時は付けた方がいいと思います。
今回はいつになく簡易版でお送りします。
ようは下のようなトリガを書いても期待通りに動かなかった話です。
該当カラムの定義は updatedAt TIMESTAMP DEFAULT current_timestamp NOT NULL です。
MySQL の時は updatedAt DATETIME DEFAULT current_timestamp ON UPDATE current_timestamp NOT NULL と書けばトリガ不要で自動更新してくれますね。
-- UPDATE 文の実行時に updatedAt カラムを
-- 現在時刻に設定してくれるトリガ(PostgreSQL 用)
-- 動作不良版
create or replace function set_updated_at() returns trigger as $function$
begin
if new.updatedAt is null then
new.updatedAt := current_timestamp;
end if;
return new;
end;
$function$ language plpgsql;
create trigger auto_set_updated_at before update on SomeTable for each row
execute procedure set_updated_at();
これで SomeTable の UPDATE 文実行時に updatedAt カラムをその時の時刻で更新してくれるはずでした。
ところが、どうやら SET 句に updatedAt カラムを指定しない場合でも new.updatedAt が NULL になってくれないようです。(例えば UPDATE SomeTable SET OtherCol = 1)
で、色々試して、とりあえず動いたのが次のバージョンです。
ちなみに、明示的に SET 句で値を指定した時(updatedAt = ‘2016-06-06 12:00’ 等)は、そちらを使います。
-- UPDATE 文の実行時に updatedAt カラムを
-- 現在時刻に設定してくれるトリガ(PostgreSQL 用)
-- いちおう動作版
create or replace function set_updated_at() returns trigger as $function$
begin
-- 次の行の条件を変更
if new.updatedAt is null OR new.updatedAt = old.updatedAt then
new.updatedAt := current_timestamp;
end if;
return new;
end;
$function$ language plpgsql;
動いたのはいいんですが、なぜ new.updatedAt が NULL じゃないのか気になって仕方ありません。
どなたか理由をご存知でしたら、ぜひともご教示ください。
どうも。
最近の投稿ペースが速くて自分でも驚きながら書いています。
さて、引き続き caveman2 で何か書いてみようという話です。
が、今回もまた自前のコードを入力する機会は訪れませんでした…
とりあえず目次は以下の通りです。
■Road to qlot:quickload
結論：行ってみた限りでは全部行き止まりでした。
や、色々試したんですよ、ホントに。
qlfile の中身を次のようにして、それぞれコメントアウトしながら全部試しました。
# qlfile
github caveman2 fukamachi/caveman
# git caveman2 https://github.com/fukamachi/caveman.git
# ql caveman2 :latest
インストールコマンドも色々やってみました。
見付けた変数を変えてみたりもしました。
(setq ql-setup:*quicklisp-home* #P"~/myproj1/")
(qlot:quickload :caveman2)
上の色々な組み合わせも試しました。
最終的に挫折しました…(泣)
■穴居人が立ち上がる時
で、qlot を使わずに caveman2 だけでも動かしてみようと試行錯誤して、こちらは何とかサーバを立ち上げる事ができました。
前回で (ql:quickload :caveman2) は通るようになったので、github の README を読みながら進めていきます。
最初のプロジェクト作成は caveman2:make-project で問題無く終了です。
続いて、とりあえずテスト稼動が目的なので、ルーティングとかデータベース操作とかはどんどん飛ばして、サーバの立ち上げに入るわけです。
書いてある通り、おもむろに (myproj1:start :port 8080) を実行… 当然パッケージ myproj1 が無いと怒られます。
そして毎度の如く、苦闘の日々が始まるのです。
まあ、状況としては windows ユーザに linux の bash プロンプト使わせるようなものですね。
やりたい事は分かってるのに、どうやればいいのか分からないというジレンマに陥るわけです。
最終的に動くようになるまで
で悩む事になりました。
パスの指定方法は make-project の引数にあったので、それでいけるはずです。
が、カレントディレクトリが何処なのかとか、うっかり #P を付けずに文字列で書いてしまったりとかで、なかなかうまく行きませんでした。
さらに、読み込むファイルが分からないという点が問題の複雑さに拍車をかけることになります。
コマンドの方は load か require あたりだろうと推測しましたが、ファイルに関しては見当もつかなかったので、考えていても仕方無いと割り切って総当たりして解答に辿り着きました。
誰かの役に立つかどうか怪しいところですが、いちおう最終形を載せておきます。
(ql:quickload :caveman2)
(caveman2:make-project #P"~/myproj1/" :author "myname") ; '#P' を付けないとエラー、ディレクトリは未作成でもよい
(load #P"~/myproj1/myproj1.asd") ; これと次は '#P' 無しでも動いたが、一応付けておく
(load #P"~/myproj1/app.lisp")
(myproj1:start :port 8080)
以上です。
ここ数日、いろいろ躓いてばかりな気がしますが、今度は VirtualBox のお話です。
毎回だらだらと長い文章になってしまうので、簡潔に書いてみます。
問題：ホストオンリーアダプタのネットワークでホストマシンだけ接続できない
結論：以前の設定が悪さをしてる場合があるので、未使用のサブネットアドレスを割り当ててみると改善される事がある
以上… では説明不足ですよね、はい。
まず VirtualBox の仮想マシンでホストオンリーネットワークアダプタを使っていました。
それで、ホストマシン(VirtualBox 自体を実行してる方ですね)をスリープしてから復帰すると、ホストだけが該当のネットワークで通信できない状態になっていました。
その間もゲストマシン(仮想マシンの方です)同士では問題無く通信できていました。
このような状況でも、最近までは仮想マシンを利用しての開発が無かったので特に問題ありませんでした。
ところが、ここ数日で やれDockerだ common lisp だと仮想マシンを使い倒すようになったため、この接続不良による再起動の嵐が非常に面倒になりました。
同じ問題で悩んでいる人がいるかと思い google 先生に検索してもらって幾つか事例を見て回ったのですが、現象が微妙に違っていたり、書いてある通りに試してみても効き目が無かったりと、うまくいきませんでした。
しかも、途中から「コントロールパネルのネットワークアダプタを無効にするとアイコンが消える」という新たな問題も発生したのです。
その後紆余曲折があり、最終的にはクリーンな状態になるよう
という作業をして、接続を試しました。
ところがやっぱり駄目で、途方に暮れかけた時にゲスト側に不自然な点を発見したのです。
この時は VirtualBox の設定で DHCP サーバを OFF にしてあったのですが、何故かゲストが DHCP で IP アドレスを取得していました。
不思議に思って別のサブネットに変更してみたところ、それが大当りだったらしく嘘のように素直に仮想マシンと通信できるようになったのです。
それまでに散々いじったので、最後のサブネット変更が決定打だと言い切ることはできませんが、これが最も有力だと思います。
思い返してみると、確かに以前ホストオンリーアダプタを作成したまま virtualbox をアンインストールしたことがありました。
その後に新バージョンを入れ直した時にも、何故かインストール直後にアダプタが有り、気になった覚えもあります。
このような点から、最初に書いた結論が導きだされた次第です。
この記事が解決事例の一つとして、どなたかの参考になればいいなと思います。
いつもの如く、唐突に common lisp の勉強をしようと思い立ち、色々見ながら環境設定をしたのでメモ。
思い付きで行動したので、あちこちで袋小路に突き当たりまくっているのは相変らずである。
■alpine linux で環境設定してみた
始まる前から後のことを考え、docker コンテナで動かすと面白そうということで virtualbox で新しく VM を作って alpine linux をインストールした。
debian とか ubuntu と違って、ISO 起動でインストーラが走ってくれるわけではなくて、Wiki を見ながら何とか導入。
パッケージは sbcl と clisp があったから「apk add」で簡単に入った。
ちなみに何度も「apt install」と入力してしまったのはご愛嬌。
問題はここからで、common lisp のパッケージ管理ライブラリ quicklisp を入れてみたが動かない。
ライブラリ自体の読み込みはできるけれど、そこから他のライブラリの自動ロードをするとデバッグモードになってしまう。
しばらく格闘してみたが、このまま環境設定で時間を食ってもアレなので、alpine は放置することにした。
■debian GNU/Linux で環境設定してみた
というわけで、愛用の debian GNU/Linux の VM を立ち上げて、こっちで環境設定してみた。
慣れ親しんだ「apt-get install」で、あっと言う間に sbcl のインストールが完了。
cl-quicklisp というパッケージもあったので、それも入れた。
で、プロジェクトごとにパッケージ管理をしてくれる(ruby の bundler みたいな) qlot というのを入れてみた。
これもすんなりと入ったので「よーし、これでコードが書けるぜー」とか思いながら、web フレームワークの caveman2 を入れ「ようとし」てみた。
…入ったよ、うん、結果的には。それだけで 1時間かかったのを気にしなければ。
その経緯
…落ち着け、キーボードは投げるもんじゃない。
近場には HHK2Lite(英語) は売ってないんだ。
それに買ったばかりのディスプレイに当たったらどうする。
とりあえずお茶でも飲んで落ち着くんだ。
(30分経過)…ふぅ、今日の茶菓子は美味かった。
お、よく見たらエラーファイル名あるじゃん。cffi？
とりあえず「apt-cache search」して… cl-cffi …って、そのまんまかい！
駄目元でインストールっと。これで直ったら微妙だなぁ…
(ql:quickload :caveman2) Enter！
え、通るの？原因これだけ？私の30分を返せ！(←責任転嫁：嫁居ないけど)
そうだ、さっきと同じくダイイングメッセージにヒントがあるに違いない。エラーでプロセス死んでるしな。
死体は語る、犯人は現場に戻る(違)
えーと…
error while parsing arguments to DESTRUCTURING-BIND:
invalid number of elements in
("caveman2:latest")」
…待て、google 翻訳に頼るんじゃない。たぶん翻訳しても、そんなに変わらんし。
一つずつ順番に行こう。
まとめると
「DESTRUCTURING-BIND のため(に)引数(を)解釈している間(に)エラー」
「”caveman2:latest” の中の要素の数(が)不正」
…ん？「caveman2:latest」って qlfile の書き間違い？
あー、うん。たしかに違うわ。スペース必要なのね。
よーし、これで動くはず。今日のおやつを賭けてもいい。
(qlot:install :myproj) …エラー？え、おやつ抜き？えぇっ？
くそぅ、この恨み晴らさでおくべきか。(←自業自得)
二度ある事は三度あるのであるからしてヒントはエラーメッセージにあるのである。
というわけでチェック！
Component "myproj" not found
うん、myproj は見付からないよね、今から作ろうと思ってるんだから。
……… もしかして :myproj の部分いらない？
(qlot:install) っと… あー、うん。動いたね。動いちゃったね。
私のおやつ返せ！(←再度の責任転嫁：もちろん嫁は居ない)
補足：没収されたおやつはスタッフ(= 私)がおいしくいただきました。
例によって忘れた時用のメモです。
タイトル通りなんですが、VirtualBox で CentOS 6.7 を使った時に困った話です。
状況としては下のようになります。
この場合、VM を起動しても NAT からインターネットへのアクセスができません。
とりあえず下のように設定したら NAT を通って外へ出られました。
DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp
ちなみに、NAT が動いた時の IP が「10.0.5.15」で、デフォルトルートは「10.0.5.2」でした。
このパラメータを利用して手動設定ができるかもしれません。どなたか試したら教えてください。
今回は短い(当社比)ですが、以上です。
はい、タイトル通り、今回はやらかしてしまった件です。
幸いにも被害は自分だけに留まったので大目玉をくらう前にコッソリ修正できましたが…
で、何をやったかというと、データごとテーブルのコピーを取るのに「CREATE TABLE test_t SELECT * FROM current_t」と叩いて test_t テーブルを作成したわけですよ。
それで、test_t テーブルをいろいろいじってから「RENAME TABLE current_t TO old_t, test_t TO current_t」として現行のテーブルと入れ替えました。
念の為にちょこっと動かしてみて、問題が無いようなのでそのまま利用することにしました。
悲劇はその後に起こったのです！
機能の追加を行った後で動作確認をしようと、テーブルに新規レコードを追加してからそのレコードを検索したところ… 見付からない…？
慌てて同じ条件で SQL コマンドを叩くと、ちゃんと居る…？
まさか幽霊かと思っても、この相手には見て確かめるための足はありません。
首を傾げながらレコードを消しては作り、消しては作り… 何度目かにふと思い立って SELECT * で全カラムを表示させてみました。
するとそこには… ああ、今思い出しても恐しい… プライマリキー値 0 (ゼロ)が居たのです！！
この時の動作は、レコードを探してそのプライマリキーを得るというものでした。その関数はエラー時に FALSE を返します。
ここで親切な PHP さんは、boolean の文脈では空文字列や数値の 0 (ゼロ)も FALSE だと判断してくださいます。
賢明な読者様にはもうお分かりでしょう。上の新規レコードが返すプライマリキー値 0 はエラー処理ルーチンの方へ入ってしまうのです。
まあ、ここまでは比較的よくある話とも言えます。
しかし、今回の真の敵はコイツであるはずが無いのです。何故ならそのカラムには AUTO_INCREMENT 属性が付けてあったのです。
つまり、新規レコードには自動的に新しい ID値が付与されるため、値 0 が設定される事実とは矛盾します。
この矛盾が今回の密室殺人の謎を解くカギになるはずだっ！(違)
と、ここまでが前置きです。
本題は「SHOW CREATE TABLE current_t」を実行した時に発見した驚愕の事実にあります。
コピー元(リネーム後の old_t)では「NOT NULL PRIMARY KEY AUTO_INCREMENT」となっていた部分が「NOT NULL DEFAULT ‘0’」に変わっているではありませんか。
確かにこれならプライマリキー値を指定しない新規レコードで、その値がデフォルトの 0 になるのは納得です。
実はテーブルのコピーを行う SQL 命令はもう一つあります。
こちらはテーブルの形だけコピーし、レコードは拾って来ない「CREATE TABLE new_t LIKE current_t」というものです。
この命令では、上で問題になった部分も元のまま「PRIMARY KEY AUTO_INCREMENT」で引っ張ってくれます。
以上から導き出される結論が「テーブルの全コピーを取るには CREATE TABLE LIKE で定義をコピーしてから INSERT INTO SELECT でレコードをコピーするという二段階で行うべし」というものです。
まあ、それ以前に作業した後にはちゃんと確認しろ(この場合は SHOW CREATE TABLE)という事なんですが…
ということで、今回の(イタい)レポートはこれで終わります。