mochikoAsTechのdig日記

当方好きなコマンドはdigです!お友達から!!よろしくお願いします!!!

本のタイトル(DNSをはじめよう)と表紙案と配置場所(か-07)が決まりました #技術書典

タイトルと表紙案

今うっきうきで原稿書いてるDNS本ですが、
協力してくれているデザイナーさんが表紙案を3つも出してくれました。

案1
案2
案3
表紙案(左から案1, 案2, 案3)

すごい・・・なんていうか・・・・ちゃんとした「本」だ・・・!
なんなの・・・?デザイナーさま、天才なの・・・?

タイトルも私の初案だと「DNS超入門」だったんだけど、モサいので「DNSをはじめよう」にしてくれたのです。表紙見たらもう圧倒的説得力で一も二もなく同意した。

いちばん左の案1がいいです!とお伝えしたところ、ここからさらにブラッシュアップしてくれるらしい。焼き肉ランチと焼き魚ランチしかご馳走してないのに、面白いからやりますよとあれこれやってくださる・・・いい人すぎる・・・!

餅は餅屋という言葉がものすごく身に沁みました。
これに恥じない中身にせねば、とテンション上がりました。

配置場所

そして4月22日(日)の技術書典4での配置場所が決まりました!
サークル名「好きなコマンドはdigです」の配置場所は「か-07」で、
比較的入り口に近い方となりました。

配置場所は「か-07」

初めて作った「DNSをはじめよう ~基礎からトラブルシューティングまで~」を100冊抱えて「これ売れるのかな・・・」と震えている予定ですので、皆さまぜひ秋葉原UDXまでどれくらい震えているのか見にいらしてください><

ハッシュタグ#DNSをはじめよう です!よろしくお願いします!

twitter.com

4月にはシマンテックの証明書が死亡し始めるけど、うちのサイトは大丈夫かChrome Canaryで事前確認できるよ

シマンテックがあれこれやらかして、Chromeに「もうシマンテック(グループ内のRapidSSLやジオトラスト含む)の証明書使ってるサイトは表示しない*1から」と言われてから早数ヶ月。 

www.atmarkit.co.jp

2016年5月以前に発行された証明書は→Chrome バージョン66から表示しない
それ以外のすべての証明書は→Chrome バージョン70から表示しない

というスケジュールなんだけど、とうとうChrome バージョン66のリリースが再来月(2018年4月)辺りにはやってきそうな予感。

Chrome Canary (通常のChromeより2~3ほど先のバージョンを利用できる開発者向けブラウザ)では、既にChrome バージョン66がリリースされていて、こんな発言も出てる。

 (意訳:2018年4月18日にリリースされるChrome バージョン66からは、2016年6月1日より前に発行されたシマンテックの証明書が信頼されなくなるね。僕すでにバージョン66のChrome Canary使ってるけど、すごくすごくたくさんのウェブサイトがエラーになってるよ)

4月に突然サイトが見られなくなって、あばばばばとならないように、「うちのサイトは大丈夫?」をChrome Canaryで事前確認しておくのがお勧めです。

ちなみにFirefoxは最近基本的に「Chrome兄さんについていきます!」という感じなので、Chromeでサイト見られなくなったら、ほぼ同時にFirefoxでも見られなくなるんだろうな、と予想している。

そしてシマンテック的にはもうDigiCertに証明書事業売ったし、過去に売った証明書がどうなろうと、もはや救済のために奮闘する意思はないんだろうな・・・。

*1:正確にはシマンテックルート証明書を「信頼しない」だけど、ここは分かりやすく表示しない、としておく

技術書典4に当選したのでDNS本を書くよ

技術書典4、明らかに申し込みサークル数が多そうな気配をただよわせていたので、
これは落選かなーと思っていたんだけど・・・なんと・・・当選したー!

当選したら考えよう、と先延ばしにしていたので、
まだ本のタイトルも目次もサークルカットも決まってないよ。

慌ててこの本を読んでいます。

booth.pm

オンデマンド・・・オフセット・・・・サークルカット・・・・?
本のサイズってそもそもいくつ・・・何部刷ればいいの?
ていうか何使って書いてどういう形式で出力して印刷会社さんへ渡すの・・・?

という、頭の上に「???」しかない同人誌初心者の疑問にすべて答えてくれる安心本。

親切な人に

と教えていただいたのだけど、GitHubリポジトリあるね、うん、リポジトリあるし見られるけど原稿はこの中のどこですか・・・どういう形式で書いてあるのか全然分からぬ・・・となったのでそっ閉じして、大人しく電子書籍を買いました。

買ってよかったよー。
技術書典4で初めて技術同人誌作る人は、みんなこれ読むとよいと思います。

あとサークルカットとか表紙とか挿絵とかどうしたらいいの、どう頼んだらいいかも分からないし死ぬ、と思ってたんだけど、幸い一緒に面白がってやってくれるデザイナーさんが現れました。なにこれ奇跡。

という訳で、スケジュール引いて、タスクごとの〆切を決めてがんばります!

IT系でエンジニアやってるけど、DNSとかのインフラ周りは実はあんまり分かってなくて、それがちょっとコンプレックス・・・そんなエンジニア向けにドメインDNSを分かりやすく教える一冊を作る(予定)です!

サークル名は「好きなコマンドはdigです」です。

あ!あと誰か、これ教えてください。

 いつなのー!

技術書典4に申し込んでみたー

2018年4月22日 (日) に秋葉原UDX アキバ・スクエアで開催される「技術書典4」にサークル参加で申し込んでみたー。 

techbookfest.org

過去にやってた技術書典3とか、行きたいなーと思いつつ行けなかったので、えいやーで「本を作る側」として申し込んでみた。
作ったことないのに!本って何使って書くの?製本とかどうやんの?!

申し込みフォームすら「サークル名?サークル名ってなに?みんなどんなのにしてるの?」状態だったよ。結局サークル名は「好きなコマンドはdigです」にしました。

本の内容は大好きなドメインとかDNSとかのことにしようと思っている。

サイトリニューアル時、DNSの変更をしたのにいわゆる「浸透に時間がかかって」なかなかリニューアル後のサイトに切り替わらない、みたいな事例を題材にして、あのなRRにはTTLがあってな・・・とか、あるいはDNS設定されたかなーって確認してしまったがためにネガティブキャッシュで死ぬ話とか、そういう「悩み」と「解決策&解説」のセットがいっぱいある本が書きたいなー。

2月4日 (日) が当落通知日だそうで、当選しないとそもそも参加できないんだね。なるほど。当選したらサークル参加費の7,000円を入金して、それでようやく参加確定になる模様。わー、当選するといいなー。

取り合えず「本の作り方」を学ぶべく、どっちか読もうと思うんだが、どっち買うか迷ってる。こっちの方がお勧め、みたいなのあればどなたか教えて>< 

booth.pm

booth.pm

ステージング環境のテストユーザで「test@test.co.jp」みたいなメアド使っていませんか?

たとえばあなたが宅配ピザのサイトリニューアルを担当していて、ステージングサイトで「ログインして注文する」というテストをするため、テスト用のユーザを作ったとします。

名前は適当に田中一郎にして、誕生日も適当に2010年10月10日、メアドも適当に「tanaka@test.co.jp」にしとこう!

ちょっと待ったー!

名前と誕生日はいいとして、そのメアドは待ったー!

昨日のエントリでも書いたけど、自分が買っていない=持っていないドメインを勝手に使うのは、トラブルの元なのでやめましょう。

こういう場合に使うべきなのは、

のどちらかです。

あまり知られていませんが、実はインターネットでは「例示やテストで使っていいドメイン」というものがあります。

こういうケースではRFC2606で定められている「example.com」や「example.net」、もしくはJPRSが定めている「example.jp」「example.co.jp」などを使いましょう。

ところで先ほど「自分が買っていない=持っていないドメインを勝手に使うのはトラブルの元」と書きましたが、具体的にどんなトラブルが起きるのでしょう?

たとえば「test.com」というドメインは(恐らく)DOSarrestというサービスをやっている Internet Security LTD,という会社が所有者ですし、「test.co.jp」というドメイン有限会社教育評価研究所という会社が所有者です。(Whoisを見れば分かる)

そのため最初に書いた宅配ピザのステージングサイトで、仮に「tanaka@test.co.jp」というメアドの登録したユーザでテストを行うと、実際に有限会社教育評価研究所という会社に会員登録完了メールや注文完了メールが飛んでいってしまい、相手方にご迷惑であると共に、情報漏洩の恐れもあります。

誰かがアンケートに適当な住所を書いたせいで、全然関係ない自分の家にダイレクトメールが届いたら迷惑ですよね。実在する他人の住所を勝手に書かないのと同じように、他人のドメインも勝手に使わないようにしましょう。

じゃあ「誰のものでないドメイン」ならいいのでは?と思うかも知れませんが、現時点で誰のものでもなくても、明日には誰かが取得するかも知れないので、これもやはりお勧めしません。

Chromeで.devのドメインがHTTPだと見られない件の解説

glatchdesign.com

本件、あちこちで悲鳴が上がってたけど、色々調べたら面白かったので解説。

元々はgTLDは.comとか.netとかの22種類しかなかったので、各社が組織内のネットワーク(開発環境とか)でオレオレTLDとして勝手に.devを使ってた。

でもgTLDがわんさか増えて、とうとう.devというTLDもできてしまい、色んなところで「やばい名前衝突(Name Collision)するわ・・・」という話題が出たのが2014年ごろ。

ちなみにICANNWikiによると、この.devは元々AmazonGoogleで「俺がレジストリになる!」と奪い合ってたけど、youとtalkAmazonに譲って、代わりにdevをGoogleがゲット、みたいな経緯があった模様。

レジストリってのはあれな、そのTLDの唯一の卸元というか、生産元みたいなもの。だからあちこちで「Googleが.devを買った」って言ってるのは、この「Googleが.devのレジストリになったこと」を指してるんだと思う。

んで今回Googleが「Chromeで.devを開くと強制的にHTTPSにリダイレクトされる」という暴挙に出たのは「Googleは2014年にdevのレジストリ(生産元)になった。でもまだ.devのドメインは一般発売していない。ってことは今.dev使ってるやつは、全部買わずに勝手に使ってるやつなので何してもいいよね。強制リダイレクトさせるわ」っていう考えなのかなと推測してる。

.devだけじゃなくて.appもみたいだし、このドメインがもうHTTPSでしか使えないってことは、Googleは.devを普通に売るんじゃなくて、何か特別な用途で使わせるつもりなのかなー?

で「.devが使えなくなったからとりあえず.testにした!解決!」みたいなのも見るんだけど、なんで.testにしたらいいのか?.testでいいなら.dev2とかでもいいのか?という疑問は浮かばないでしょうか?浮かびますよね?きっと。

ざっくり言うと、.testはいいけど.dev2はだめです。

社内ネットワークにしろ、テスト用のメアドにしろ、「例示として使っていいドメイン」や「テストとして使っていいドメイン」はRFCで定められているので、基本的にはそれを使いましょう。

自分が買ってない=持ってないドメインを勝手に使うのは、今回みたいなトラブルの元なので控えた方がいいよ、という話でした。

blog.jxck.io

sudoとsuで聞かれるパスワードは違う

sudoは「他のユーザとしてコマンドを実行する」ためのコマンド、 suは「他のユーザになる」ためのコマンド。

sudoのとき聞かれるのは、「自分(今のユーザ)のパスワード」で、 suのとき聞かれるのは、「なろうとしている他のユーザ」のパスワード。

たとえば、mochikoユーザでログインして、 sudo cat /root/.ssh/authorized_keys を叩こうとしたら、mochikoユーザのパスワードを聞かれるし、 su - でrootになろうとしたら、rootのパスワードを聞かれる。

今となっては当たり前なんだけど、分かるまでは結構混乱するよね。