GitHub Pages でカスタムドメインを設定したら身に覚えのない重複で弾かれた話
概要
だいたいタイトル通りです。自分のリポジトリ上では使っていないはずのドメインをカスタムドメインとして設定しようとしたら、もう使われているよ(cname-already-taken)と弾かれてしまった際の対応についてです。
流れ
問題発覚
1, 2年ぶりにポートフォリオを復活させようとした時の出来事でした。実装が一通り終わり、GitHub Pagesとしての公開作業に入った時、カスタムドメイン sasurai-usagi3.jp を設定しようとしたら、The CNAME sasurai-usagi3.jp is already taken. Check out https://help.github.com/articles/troubleshooting-custom-domains/#cname-already-taken for more information.と言われて弾かれてしまいました。
昔のポートフォリオのリポジトリは残ってないはずだし、どこかで間違えて使ったかなと思い自分のリポジトリを見ても見当たらず...。
一応、 sasurai-usagi3.jp にアクセスしても 404 が返ってきました(DNSの設定は残ったままだった)。
www.sasurai-usagi3.jp がカスタムドメインとして設定されていたとしても、 sasurai-usagi3.jp が使えないので、状況的にどうやら www.sasurai-usagi3.jp の方が設定されてしまっている可能性が高いと思いました。 www.sasurai-usagi3.jp に至っては設定した記憶がなく、やはり自分のリポジトリにはありませんでした。 www.sasurai-usagi3.jp が使われているか見ようにもこちらは使用している人がわからないとDNSが設定できないので確認取れませんでした (CNAMEレコードでアカウント名が入るため)。
GitHub Pagesの仕様上、自分がそのドメインの所有者じゃないとしてもカスタムドメインの設定ができてしまうので他のアカウントでなんか知らないけど設定されているのだろう、もしくは消したはずのポートフォリオのリポジトリの設定だけがなんか生き残ってしまったのだろうと予測が経ちました。
がどちらにしても自分でどうにかできる内容ではないので問い合わせフォームから拙い英語で質問しました。
対応編
すぐにメールが返ってきました。曰く、以前のドメイン所有者の設定が残っているのか、誰かが間違えて登録したんじゃない?って返ってきました。
DNSのTXTレコードに指定した値入れて所有者であること確認できたら、カスタムドメインの設定解放するよって言われたので早速対応しました。
にしても、問題のドメインのここ数年の所有者自分だし、そんなtypoとかで間違ってなってしまうようなドメインでもないから謎ですね...。他の人のリポジトリだとすると検索引っかからないから多分プライベートリポジトリ。ミスったまま無限に放置するものなのかなぁ...。まぁ謎は残ったまま解決という感じです。
多少面倒だけど、カスタムドメイン設定する時にTXTレコードか何かで所有者であるかの確認してほしい気持ち。
一応メール全文
英語下手で恥ずかしい...
まとめ
身に覚えのないカスタムドメインの重複で詰まったら、自力解決はまず無理なので、すぐにお問い合わせしよう!
あとどうでもいいですが、ポートフォリオ(と呼んでいいのか...?)の方も是非是非見てくださいー
参考
読書めも はじめてのUIデザイン
「はじめてのUIデザイン」 著: 吉竹 遼, 池田 拓司, 上ノ郷谷 太一, 元山 和之, 宇野 雄, 坪田 朋
概要
UIデザインをどのようにつくるかの流れがわかる本。個々の事例を見て理解していくというよりは、考え方を学ぶのに近い気がしました。
めも
第1章 はじめに
- スキューモーフィックデザイン(古いiOS)
- 見たまま質感まで再現したデザイン
- フラットデザイン(最近のiOS)
- 平たくシンプルにした感じのデザイン
- マテリアルデザイン (最近のAndroid)
- フラットデザイン + 物理的な特性(奥行きの関係とかアニメーション)
第2章 UIの見える部分を学ぶ
- ブランドカラー
- メインカラーとアクセントカラーの2色 or 1色ぐらいにしておく。
- サービスの目的やユーザ層を意識して決める
- タイポグラフィー
- フォントの種類は多すぎてはいけない
- 文字色は見やすく・わかりやすく
- ジャンプ率を意識しよう
- レイアウト
- よく言われる近接・反復・整列・対比を守る。
- アイコンは言語に非依存で視覚的に機能を表せるが、間違えて扱うと誤認されてしまう。
第3章 UIの見えない部分を学ぶ
- (ユーザにとっての)わかりやすさを設計する (情報設計)
- ペルソナがサービスで達成したい目標を成し遂げるまでの流れを丁寧に書いていく。(シナリオ）
- そうしてユーザ全体の行動パターンを探る。
- サービスを使う背景からサービス内での行動まで細かく自由に
- シナリオから必要そうな要素を抽出する
- フロー図(ユーザが見てるもの、操作した先にあるもの)を書いてみる
- 画面構成を考えてみる
- この辺はペーパープロトタイプの方が細かいこと気にしなくてすむから良いよ
第4章 UIが機能する環境を学ぶ
UIButtonとか普段見てるUIパーツの紹介でした。
第5章 UIデザインを作ってみよう
- アプリ内で一貫性を保ちながら得られた情報を形にしていく
第6章 UIデザインができたら
- 使ってもらうユーザ層のことを考えよう
- 背景など
第7章 UIをデザインする前の心得
感想
UIデザインって言われると難しく感じるけど、そのサービスを使ってもらうユーザ層のことを考えての設計って言われてピンときました。
読書めも 統計思考入門
「統計思考学入門」著: 水越 孝
概要
統計という文字がタイトルに含まれていますが、数式はあまり出てきません。統計学の考え方を元にして意思決定をしていくことについて知れる本です。
めも
第1章 数字で考えることのおもしろさ
感覚で物事言っても説得力がないから、根拠のある数字を出していこうというところから始まります。 全体的に分析をしてから個々の違いを見出し、グルーピングをして同グループの差異を見つけていこうという感じでした。
第2章 「同じもの」のなかに違いを見つけ出す
- 第1章に出てくる主成分分析についての詳細な説明
- 軸を変えていくことで新しい発見が得られる、その解釈は分析者に委ねられる
第3章 「違うもの」のなかに同じところを見つける
- 第1章に出てくるクラスター分析についての詳細な説明
- 分析対象の背景を考え検証と修正を繰り返すことが必要。
第4章 「全体」から「小さい全体」をつくる
- 統計でおなじみ?の母集団と標本のお話です。
- いかに母集団と同じ比率を保つかについて
- 基本はランダム。しかし条件次第ではばらつきが生まれる場合があって標本としてよくない
- だから比率を保てるように、グルーピングしてからサンプルを抽出するなど工夫する
第5章 「事実」は「真実」と一致するか
- 得られた標本って正しいのってお話です。(カイ二乗検定)
- もし標本として間違っていたとしても、統計学である程度リカバーできる
- 本来証明したい仮説の真逆の仮説を反対することで本来証明したいことを示すことができる(帰無仮説)
第6章 「迷い」から抜け出すための手法
- モデリングのお話でした。
第7章 数字に現れた現実にいかに対処するか
- 出てきた結果に向き合う。その上で議論を展開することが必要
第8章 自然公園がもたらす経済効果は?
- 市場価値のつけられないものに対する、価値の算出方法について
- そのものと同等のサービスや事例から算出したり、関係者にアンケートしてどの程度支払って良いか聞くなどを元にする
第9章 統計的アプローチで発想するということ
- 統計的アプローチとは普段何気なくやっている判断を科学的に再現したもの
- 算出した結果は同じだとしても、その解釈や扱いは分析者によるし、いずれも正しいものと言える
- 大切なのはプロセスよりも、その結果の受け止め方と、その後の意思決定
感想
数学的な内容が少なく読みやすいのと要点はわかりやすいと思いました。標本を得て分析するまでのざっくりとした流れを知ることができたという点ではよかったと思います。 が時折出てくる数式の説明が足りてないので深掘りしたい場合には調べながら読み進める必要があると思います。
Write Code Every Dayを1年取り組んでみて
Write Code Every Day (原義とは異なる) を始めて記録上ちょうど本日2019-04-16で1年経ったのでまとめます。正直個人差が激しいと思うので参考までに
Write Code Every Dayとは
John Resigさんが提案した習慣です。詳細はこちら
背景と目的
自分がWrite Code Every Dayを開始したのは、社会人になって間も無くの時でした。以前からWebエンジニア(Rails/HTML/CSS/JavaScript)としては活動していましたが、今後のキャリアを考えるとアプリや他言語もできたらいいなと思っていて、ちょうど研修でWrite Code Every Dayというキーワードを聞き実践してみました。
オリジナルの規則では厳格に思えたので毎日コードを書いて学びがあると状態を保てる様に独自の規則を立てて進めました。
まとめるとWrite Code Every Day始めた当初の目的は、自分の専門外の言語・プラットフォームも扱える様に毎日書きながら学ぶことでした。
規則など
どういう規則で実践していたかまとめます。実際にやってみてうまく行かなかった箇所は本来の目的が崩れない範囲で途中で変更することもありました。
- 毎日masterブランチにコミットする
- しかし途中からmaster以外のブランチでもOKに変更(1つの機能作成に時間がかかる様になったため)
- 原則パブリックレポジトリにする (なんでだっけ。大元のルールにあった気がしたから?)
- あとからpublicにするリポジトリはprivateでOKとした
- 業務・副業は含めない
- 意味のないコミットは対象外(コメントの追加とか変数名リネームみたいな)
- 大元のルールではリファクタも対象外だが今回はリファクタはOKとした
- 日替わりで言語を変える(スイッチングが厳しすぎて途中で廃止)
- 後半は作りたいものベースで進めた(ただし慣れない言語などを選択するようにはした)
- 要件定義などの練習も兼ねていた
要は何かしら学びがあればOKというのが原則でした。 取れた時間としては1日30分(平日)から6時間(ほんとに暇な時)ぐらいでした。始めは比較的時間にゆとりがもてる夜にコードを書いていましたが、仕事終わりだと体力と集中力がもたなかったので、朝進めるようにしました。時間に大幅な制約が生まれましたが、集中して進めることを意識するようになったので結果的によかったと思います。
達成率
publicリポジトリに生えた草の日数を集計しただけなので多少前後してそうですが参考値ですが
347/365 とほぼ毎日続けることができました。(多少抜けてるのはPCが故障したりとか病気になったりとか)
成果
ある程度できる様になった言語など
- iOS開発
- 仕事で少しいじる様にあったのもあるかも
- Android開発(Kotlin)
- ざっくり理解
- VueJS/NuxtJS
- まぁ書ける様になった
- FireBase
- DBとAuthだけだけど理解
- Go lang
- 基本は押さえた
- TypeScript
触れたものの忘れかけ
成果物(主要なもののみ)
感想とか
- Web(特にサーバ)しかできなかったところからWebもJSのフレームワークが使える様になり、アプリも開発できる様になったという点で成果は大きかったと思います
- 習慣化すると言う点についてはあまり苦戦しませんでした。時間が取れるかがポイントだと思います。
- 30分だと結構キツキツなので1時間は確保したいところ
- いくらキャリアのためとは言っても使うか際どい技術は頭に入って行きづらいのとモチベーションが保てませんでした
- 作りたいものを不慣れな環境で作るというぐらいがちょうど良さそう。勉強のためによくわからないものを作るのは継続性と言う意味で厳しく思えました
- 検索が難しい。ノウハウだったり言語化しづらいものは調べづらいので人に聞ける環境が必要かなと感じました
- 1日ごとに言語を変えるのはスイッチングコストが高いのと学んだ内容がごちゃごちゃになるのと次やるまでに忘れてしまい定着しないのでオススメできません
- 自分の場合あまり長時間取れなかったので特にそうなのかもしれない
- 病気だったり旅行だったりでコミットできない時があり習慣化しても毎日続けるのは結構厳しく感じました
- デザインのスキルをこの枠で磨こうとするとコミットが残せないのでコミットを残すことにこだわらなくても良いのかもしれないです
Write Code Every Day 2年目に向けて
- 作りたいサービスベースでやっていくのが効果的に思えたので今後も続けます。
- アイデアを考えたりする力も地味に身に付く
- やはりネットに落ちていない、あるいは検索しづらいものをどう習得してくかが今後の課題です
一言
2年目もやっていき
FirebaseのorderByChildの仕様について
2019-04-06現在の情報
orderByChild 使ってもレスポンスが並び替え済みで返ってこないと思い、 お試しで limitToFirst 使って絞ったところ、並び替えた結果に基づいて絞り込みが行われていることがわかった(しかしレスポンスは作成順)。
以上から orderByChild はレスポンスについて並べ替えを行うものではなく、 limitTo~ で絞り込みを行う際の前提条件として機能している様子。