頭の中は異空間

ものづくり中心

いつ買ったか分からないレターパックを使うときの罠について

ちょっと最近問題が起きたので。

日本では19年10月に消費税が10%になりました。そのため、増税前に購入したレターパックを今になって使って届け物をする場合、レターパックが10円値上がりしているのでそのまま送ると料金不足のハガキも一緒に相手に届いてしまいます。
当然、受取側に10円の支払いが発生してしまいます。このとき、発送側が10円切手を貼っていれば問題ないのですが思考の外にあったためまさにこの状態になりました。

いつ買ったかわからないレターパックを使うときはポストに投函するのでなく郵便局に出向いて窓口から発送してもらった方が賢明です。料金等で何か問題があればこの時点で忠告されるので、後でトラブルを招く可能性はなくなるでしょう。

Chromeで複数タブを開きがちな人にとって便利なOneTabをタスクリストのように使ってみる

最近知った便利なタブ管理ツールについて。
chrome.google.com

ネットサーフィンをし続けていると気づいたらタブがめちゃくちゃ増殖していてどれがどれだかわからなくなることが結構多いように感じたので入れてみたら問題が解消されました。あと、chromeはメモリ使用量が多いです。タスクマネージャーを開いてみると一目瞭然です。それも解消されます。
そんなOneTabについて、このextensionの使いみちとしては、タスクリストのように使うのが一番なんじゃないかと思ったので一応備忘録として書いておきます。

早速使ってみると、以下のようになります。
f:id:notwo:20190928122015p:plain

OneTabを使うと複数のchromeのタブを一箇所にまとめてくれるのでメモリ節約&見やすさ向上の面で大いに役立ちます。しかしただそこにまとめただけでは本当に”ただまとめただけ”で終わってしまってもったいない。
一箇所にまとめたリンク先のリストを作ってくれるので、それを1つずつ消化していく、という使い方で、せっかく読む気になった記事なのだから、しっかり目を通して満足したら閉じる、何度も読み返す必要があるならブックマークしておく、とするだけで何度も同じ記事をググり直す無駄を省けます。ゲームで言う積みゲー状態になってしまわないように、興味関心が薄れないうちに目を通すのって本当に大事だと思います。ソッチのほうが読んでいても頭に入ってきます。「鉄は熱いうちに打て」と言いますしね。
それと、extensionのレビューにもあったとおりこれはブックマーク機能として使うのは違うかな、と思います。ブックマーク機能ならどのブラウザにも標準で入っているから、新たにextensionを追加する必要はあまりないでしょう。

使い方に関して書きましたが、ただこれが当てはまらないパターンもあると思います。
例えば毎日見るyoutube動画のシリーズが5つあるとするならば、その動画はタブ5つ分を常に開きっぱなしにしておきたいでしょう。これをわざわざOneTabでまとめたままにするといちいちタブとして開きに行かないといけない(その分手間がかかる)ため、普段のブラウザの使い方がそればっかりの人にとってはOneTabはむしろマイナスになると思います。
またプログラミング学習中に何度も文法を見直すなど必要がある場合も、タブにずっと開きっぱなしで残しておいたほうがましだと思いますし、他にもエンジニアが職場でこれを使うのは必ずしもプラスにはならないかな、と思います。仕事中は勤怠管理とかjenkinsとかgithubとかdev、本番環境のトップページのような何度も開くことがわかっているサイトは固定タブにしたほうが良いですしね。

というわけで読みたい記事が沢山あるけどタブ多すぎて辛い、な人におすすめなextensionです。

Chrome拡張機能追加時に出る「アクセスしたウェブサイト上にある自分の全データの読み取りと変更」って何?

google extensionを追加するとき、ちょっと怖い警告が出てくることが多いです。今更ですが気になってちょっと調べてみたら以下の記事が見つかりました。
英語版だと「it can Read and change all your data~」と出るのでそっちでググってます。
www.howtogeek.com
これによると、

  1. google extension storeではその警告を出すことがレギュレーションになってる=>この警告自体を気にしても仕方ない
  2. ただし、一部警告が出ない滅茶苦茶シンプルなextensionもあるらしい(上記記事だとGoogle Hangouts)=>extensionがサイトの情報を閲覧しないことが明確な場合は警告を出す必要がない
  3. 警告が出るのはあくまで、特定のサイトのデータをextensionが閲覧する場合。例としてSave to Google Driveが挙げられている

このような解釈になると思われます。


ブラウザメーカーがすべてのextensionについて検証しているわけではないとあるので、おそらくメーカー側としては保険として出している、という意味合いもあるでしょう(問題の原因がextensionだったとしてもブラウザメーカーにケチをつける人が出てくる恐れがある)。


記事の下の方でextensionが契約番号等を収集できてしまう可能性がある点が危険という風なことを言っていますが、それを危惧するのであれば、拡張機能管理からサイトへのアクセス項目を、「クリックされた場合のみ」もしくは「特定のサイト」にしておけば不意にデータを取られる心配はなくなります。


評価基準としては

  1. Googleなど良く知られている会社が作っている場合=>まあ安全
  2. 全く知らない第三者が値作っている場合はちょっと危険
  3. 利用者が多くstoreで高評価されている場合(レビュー含む)、かつchrome extension store以外のブログで評価されている場合なんかは安全

とあります。私はレビューの中身もサクッと読んでみて明らかにこれは危険だと判断するに足る情報が見つかれば断念しますが、上記基準で何ら問題ないかなと考えます。また、できたばかりでなく長く使われているか、も選択基準としては大事だと思います。

【Django】ローカルでキャッシュバスティングをして、staticファイルを即時反映させよう

もうwebで開発をするのなら当たり前ですがjsやcssの修正を反映させるにはキャッシュをどうにかしないといけません。
Django初心者の私が軽く調べてみたところ、Djangoには最初からその機能が備わっているとのこと。
blog.xoxzo.com
Djangoでは本番にデプロイするときに一箇所にstaticファイルを集める仕様になっており、そのときに機能する機能(激寒ギャグ)ということだと思います。じゃあローカルではどうやるのと。

django-static-md5urlを使ってみたところローカルだとどうもうまく機能してくれないので、仕方なくキャッシュバスティングの部分は自作することにしました。
早速コードから。


views.py

import random, hashlib

これも同じくviews.pyに

def get(self, request, *args, **kwargs):
    ...
    hash = hashlib.sha256(str(random.random()).encode()).hexdigest()
    ...
    return render(request, 'myapp/index.html', {'form': form, 'hash': hash})

hash値を保存し、
sha256の部分はお好みで(sha224, sha512など。値の長さが違ったりするけど)。

{% block extrahead %}
    <link href="{% static 'myapp/css/app.css' %}?v={{ hash }}" rel="stylesheet" type="text/css">
    <script type="text/javascript" src="{% static 'myapp/js/app.js' %}?v={{ hash }}"></script>
{% endblock %}

こんな感じで書けば?v=の先が毎回ランダムなhash値となり、十分なhashの長さならhashの衝突もまず起こらないので不自由なく修正直後に反映させることができます。

【Django】何もしてないのに急にコードが動かなくなったらバージョンを疑えという話

Djangoでログイン、ログアウトを実装中のあるとき、logoutを読み込もうとするともうないのでエラーが返されるようになりました。なんでじゃ。

    from django.contrib.auth.views import logout, LoginView
ImportError: cannot import name 'logout'

それまで正常動作していたのが急に落ちるなんてありません、が直近で何かしたかなと思い返すとselect2をpip installしただけなのですがそれによってDjangoのバージョンまで勝手にアップグレードされてました。
f:id:notwo:20190920083640p:plain
(Collecting django >= 2.0のあたり)
こんな感じのログが出てました。よく見ると、たしかに既存の古いDjangoがアンスコ&要件を満たす新バージョンのDjangoがインストールされているじゃあーりませんかー。この機能、便利っちゃ便利です、しかし結果的にDjango1系で動作していたコードが2系で動かなくなってしまいました。

私の手元の環境のDjangoのバージョンが1.11.1→2.2.5となっていたせいで、1系で使えたlogoutを読み込めなくなっていたのが原因だったわけですが、これpipの仕様を知らないと結構引っかかりやすい罠じゃないかなあと思います。知らないほうが悪い、となりそうですが。

Djangoは1系と2系で一部書き方が違うことがあるので、他のサイトを参考にするときも、Djangoのバージョンが何かを絶対に見るようにしよう、ということになります。まぁこれはDjangoに限った話ではないですね。

【Django】heroku local実行時にstaticファイルが必ず404になる件

今回からはてな記法に変えてみました。コードにシンタックスハイライトを楽につけるにはこうするしかなかったのです。

Djangoでstaticファイルをただ読み込ませるというだけの単純なはずの作業で数日間大苦戦したので、このような邪悪は処罰しようと思い、後学のために残しておきます。

環境(執筆時)

Djangoのファイル構成

f:id:notwo:20190907160308p:plain
白枠はプロジェクト名の箇所です。アプリ名をuser_authとしています。

python manage.py startapp user_auth

でアプリ作成しました。
staticディレクトリがアプリ直下と、project_staticディレクトリがプロジェクト直下にそれぞれ配置されているのがわかると思います。
project_staticディレクトリには本番にデプロイする際にstaticファイルを配置するために必要なので今のうちに作ってしまいます。ここではローカルでの動きについてのみ触れますので、実際には使いませんが。

コード

以下でuser_auth/css/bootstrap.min.cssを読み込もうとしています。

アプリ名/base.html

{% load static %}

...

<link href="{% static 'user_auth/css/bootstrap.min.css' %}" rel="stylesheet">

settings.py

PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
STATIC_ROOT = os.path.join(BASE_DIR, 'project_static')
STATIC_URL = '/static/'
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, 'static'),
]

このように設定してpython manage.py runserverとすると、404が出ずstatic以下のファイルが読み込まれます。実際にChromeで開発者ツール(F12)→Sourceとするとそこに読み込んだファイルが有ることでしょう。
手元で普通にDjangoの開発をするだけならこれで十分です。
ここまでの構造やコードについての解説は以下記事が大変優秀でした。
hideharaaws.hatenablog.com


しかし問題は、herokuと組み合わせる場合。全く同じディレクトリ構成とコードでheroku local web実行後に結果を見て見ると…
f:id:notwo:20190907161514p:plain
なんでじゃ。
heroku local webだと参照している場所が違うのか…?Djangoでは思想?として開発中とデプロイ時では参照の仕方が違うことはわかりました。
↓ここでよく解説されています。
qiita.com

しかし同じローカルで実行しているのに同じことができないのは不思議です。散々探し回っても解決に至る情報にはたどり着きませんでした。というわけで、ローカル開発するならrunserverを実行するのが確実なのでそっちにします。何か変わるわけでもなさそうですしね。というわけでheroku localコマンドには永久にご退場願おうか。

本番にデプロイするときは以下公式サイトを見れば良さそうです。
devcenter.heroku.com
ここによればpython manage.py collectstaticしろと書いてあります。実際にやってみると、各アプリのcssとかjsがproject_static以下に集約されることがわかります。元あるファイルからコピーしただけなので、アプリ直下のstaticの中身はそのままですね。おそらく、static以下のファイルに修正が入ったらこのコマンドを毎回実行する必要がありそうです。



技術系の記事だと最近Qiitaに垢を作ったのでそっちに書こうか迷ったのですが、個人的にはこのブログを盛り上げて行きたい思いがあるので、基本的に今後もここに載せていくつもりです。そもそも更新頻度も高くないし。

【AWS】ACMに登録したSSL証明書の有効期限切れしてしまったときの対策

またまたやらかしてしまいました。

なぜかACMに登録済みのSSL証明書の自動更新がされておらず、前回のような期限切れ注意的なメールも届いていなかったため実際に期限切れになるまで気づきませんでした。

f:id:notwo:20190303085042p:plain
赤字で「期限切れ」というパワーワードが刻まれている...

しかもテストで作った未使用証明書が残存していたという...要らないものは消して整理すべき(戒め)

 

さて、期限が切れてしまったら更新するだけです。ただ、期限が切れる前に更新するのと比べてひと手間かかります。

 

やり方は、ACMの画面、証明書のリクエストボタンからドメイン情報を入力していきます。検証方法は、私はEメールにしました。 

f:id:notwo:20190303090123p:plain
こんな感じになるはず

メールを送ってからの細かなやり方は下記にあります。

notwodaily.hatenablog.com

approveまで終わったら、要らない証明書を削除したいのですが... 

f:id:notwo:20190303084623p:plain

当たり前ですが、期限切れ証明書とはいえなにかのサービスで使用しているわけで、そちらで利用する証明書を変更しないといけません。

例えば私はCloudFrontで利用しています。

notwodaily.hatenablog.com

証明書の変更方法として、CloudFront(おそらく他サービスも)の場合はarnを更新すれば良いです。

下画像のARN(いま発行した証明書の方を選ぶこと!)の部分を丸ごとコピー。

f:id:notwo:20190303084702p:plain

Custom SSL Certificate (example.com):直下のテキストエリアにコピったarnを貼り付け、更新。

これでさっきまで使用不可能だった発行済証明書が選択され、使用可能に変わっていることを確認できます。

f:id:notwo:20190303084506p:plain

そして期限切れの証明書を削除可能になっているので、アクション→削除。発行済みの証明書のみが残っていれば大丈夫です。

これで無事解決です。めでたしめでたし。

 

 

いやあ、久しぶりに記事を書くネタができて本当に良かったです(白目)