タイトルの通り。新しいドメインを取ったことだし、せっかくなのでWebサイトを作り直し、そのついでに今まで作ったものをまとめてみた。
裏ではJekyllを使っているので、なにか作る度に新しくページを追加すればOKなのがポイント。
タイトルの通り。新しいドメインを取ったことだし、せっかくなのでWebサイトを作り直し、そのついでに今まで作ったものをまとめてみた。
裏ではJekyllを使っているので、なにか作る度に新しくページを追加すればOKなのがポイント。
高専祭については、去年から専攻科生としての参加なので、学科展も無ければ、クラスの屋台・喫茶も無い。さらに、去年少しだけ手伝ったソフテクのプログラミング体験教室的なやつも、今年は3年生の2人中心に1年生を巻き込みながら自立してやっていけたみたいなので、完全に何もしない人としての参加になる。マインクラフトで例えると、緑の村人だ。
数年前までは、情報出身の専攻科生は情報の学科展を手伝うみたいな風潮があったみたいだけど、僕の1個か2個上の代で消えた気がする。というか、4個上の人達周辺だけの特異な現象だったのかもしれない。
まぁそんなわけで、高専生として参加する最後の高専祭が終わったわけだが、結構楽しかったと思う。他学科の人たちがステージ上でひたすら盛り上がるあの特有のノリは相変わらず苦手だけど、そういうのを遠くから見て一緒に楽しむ心の余裕も生まれてきた。内輪ノリに関しては毎年のように叩かれているけど、逆に体育館にいる全員に通ずるような話をしつつ盛り上げもするというのはかなり難しいことなので、あれはあのままでも良いと思う。
どうやら高専祭は、OB/OGが帰省して教員室参拝をしたり、プチ同窓会が発生したりするキッカケとしても機能しているようなので、来年以降はそういう目的での参加になると思う。
プログラマの端くれとして、ソフトウェアのインストールだったり、開発だったり、そういった物事が滞りなく進むのは良いことだ。良いことなのだけど、他の誰かの環境や、ある状況下でうまくいかなかったときは、原因を探るために、そのうまくいかない状況を作り出す必要がある。そういうのを、再現するとか、再現性があるとかないとかいう。「あの手順を踏むと再現するね」とか、「僕の環境だと再現しないね」みたいな会話をしたりする。
そういう、なにかうまくいかないことの原因を調査するために、同じような状況を作り出して再現するかどうか確かめているのに、どうも再現出来ない、ということがここ最近多い。
ひとつは、僕の専攻科の特別研究に関することで、もうひとつは内定先での開発アルバイトに関することだ。どちらも、だいたいのアタリはついているのだけど、同じ状況を作って再現しようとすると再現しない。後者の方は、若干答えを掴めそうな感じがあるし、最悪無視すればなんとかなるレベルの話なのでどうでもいいのだけど、前者に関してはさっぱりだ。実験室と同じ環境を研究室に作ってみても、なんと再現しない。それに、人によってうまくいったりいかなかったりするとか、何回か試してみるとうまくいくとか、逆にさっきはうまくいったのに今度はうまくいかないとか、そういう感じだ。
もう仕方がないので、回避策を用意することにする。一応、そこは本質では無いっちゃ無いし。
ところで、こういうトラブルシューティング的なことをやるときに、その人の実力を垣間見ることができるのだなぁといつも思う。後輩がRailsで作ったものがうまく動かない、みたいな時は、いろいろヒアリングしつつ、原因を探って解決するという事ができるけど、それは僕がRailsだけやってるわけじゃなくて、Rubyそのものとか、HTTPとかSQLとか、あとはActive Recrodそのものとか、Railsというデカいものを構成する下位の概念についてそれなりに(少なくとも彼ら彼女らよりは)知っているし、それなりに経験も積んできているから出来ることだ。
今回はもっと低いレイヤの話で、ネットワークとか、Linux、パッケージマネージャがどうこうとか、とかそういう話だ。正直そういうのはめんどくさいので僕はHerokuみたいなものが大好きだし、ちょっとインフラ自分で頑張ってみるかってなっても、自前マシンにDebianをインストールして、適当に設定をしつつ、コミュニティがお膳立てしてくれた公式のDockerイメージを適当に構成して立ち上げるくらい。
結局、普段からそういったモノとよく触れ合っている後輩が緩和策を提案してくれて、そのとおりにやるとなんとなくうまくいった感じがする。それでもまだダメな人や、「さっきはうまくいったのに今度はうまくいかない……。」みたいな事が起きているので、ちょっとどうしようという感じなのだけど。正直ここに時間をあまり使いたくないので、次回以降は回避策を試す感じで考えている。
言い訳として、今回は学校の異常なネットワークのせいで二重ルータを強制されていること、それが無かったら驚くほどちゃんと動いてくれるというのがあるのだが、それでも今回は僕の実力不足、知識不足感が否めないなぁ、と思ったのであった。
ブログを新しいドメインに変更したのだけど、Googleの検索結果やTwitterには前のドメインのものがリンクされているので、フォワーディングをしたい。具体的には、以下の2点を実現したいということだ。
ぼくはName ServerとしてCloudflareを使っているので、Page Rulesという機能をうまく使えばこのフォワーディングを実現することが出来る。
Cloudflareのダッシュボードにログインし、旧ドメイン(僕の場合は mktakuya.net )の設定画面へ移動する。
画面上部のタブからDNSを選択し、以下の通りレコードを作成する。
ポイントは、Nameに旧サブドメインが指定されていることと、雲のマークがオレンジ色になっていることだ。それによって、DNSの向き先がCloudflareのサーバになるので、後述するPage Rulesを利用できるようになる。
Cloudflareのダッシュボード上部のPage Rulesを選択し、Create Page Ruleボタンを押して以下の通りPage Ruleを作成する。
Then the settings are: Forwarding URL
Status Code: 301(どっちでもいいと思うけど気にする人はこの辺参照)
destination URL: blog.m6a.jp/$1
こうすることで、 blog.mktakuya.net へのアクセスは当然 blog.m6a.jp にフォワーディングされるし、 https://blog.mktakuya.net/entry/2018/10/09/230943 へのアクセスも、 https://blog.m6a.jp/entry/2018/10/09/230943 へとフォワーディングされる。
待つ。すぐに反映されることもあれば、1日待たされることもある。
試しに古い方にアクセスしてみたりして、フォワーディングが行われることを確認する。
こんな感じでフォワーディングを設定すると、旧ドメインからアクセスした人を新ドメインの方に誘導することが出来る。
注意事項としては、どうやらFeedlyはfeedのURLをフォワーディング等によって変更しても追従してくれないということがある。対策としては、URLのmatchを /* ではなく /entry/ とかにしておいて、別途古い方のドメインでフィードを吐き続けるなり、「移転しました」的なフィードを表示しておくことなどが考えられる。
新しいドメイン取った。とりあえず、ブログのURLも変えてみた。
blog.m6a.jp
これfeedlyとかでフィード取ってきてる人は更新してもらわなきゃいけないのかな。
あとで mktakuya.net からのリダイレクトとかもしなきゃなー。
どこの大学にもあるように、高専にもTAという仕組みがある。大学院生が学部の授業に現れて教員の補助をするアレだ。僕の所属している高専では、専攻科生が本科の授業や部活動のお手伝いをするという感じになっている。
1年生の後期にソフテク部のTAを、2年前期では3年生のプログラミングのTAを、そして今回は3年生の実験のTAをやっている。今回のTAは、自分が専攻科の研究で作った実験の様子見も兼ねている。
先ほど総務課人事係に行って、人事異動通知書というのを受け取ってきた。「あなたをTAとして採用します。雇用期間は平成31年何月何日までで、時給は○○円です。」というやつだ。時給は、最低賃金に毛が生えた程度。そして実験のTAをするとだいたい延長戦が開催されるのだけど、その残業代は出ない。
この待遇に対して、先生や事務の人に文句を言っても仕方がなく、もっと上にいるなにかに文句を言うべきなのだけど、こんなんで大丈夫なのかなぁと思う。専門技術を有する人間を輩出し、彼らの地位向上に務めるべき組織が、学生をこんな低賃金・低待遇で買い叩いて良いのかと。
まぁこれで次の日から突然TAが時給2000円になったとしても、それくらいの価値のある技術や知識を持ち、行動できるかと言われれば微妙だし、そもそも嫌ならやらなければ良いじゃん、という話なのだけど、そこは一旦置いておきたい。
いつの間にかWebサイト来てた。
今年も出るぞ!!!
去年僕らが10人チームで殴り込みにいったからか、今年から応募形態に制限が加わってたのがおもしろかった。まぁ今年はデカいチームで1つのアプリをつくるというよりは、少人数チームでたくさん出すさくせんで行くので、大丈夫だけど。