止まるな、攻めろ！留まるな、攻めろ！
落ち込む暇など１秒たりとも無い！
ミスはないか？
漏れはないか？
上だけではなく、周りをよく見ろ、だれか困っていないか？
何がベクトルか！？
t.nagata@arksoft.co.jp
JavaScriptでアップロードした画像を正しく回転して表示する方法
show case の画像アップロードで、iPhoneで取得した画像のOrientationを正しく補正して表示する方法を調べていて、JavaScript側でExifをパースして補正するここの解説が一番わかりやすかったので備忘録。
ただ、どうも傾きの判定が間違っているようで、元画像から90度回転している画像はOrientationが6、270度が8ではないかと思われます。いずれにしろ、iOS11から、画像がjpeg→HEIFに変更されたし、jpeg以外ではこのロジックは使えないので、jpeg限定で参照していただければ、画像の構造から解説されているため、同じように悩んでいる方は一読をお勧めします。
ただし、iOS11からはheif方式で画像が保存されるようになりました。
引き続きheifでのexif対応を調べたいと思います。
ExcelVBAdeで少数点以下あれば表示
以外にも、小数点以下があれば小数点を表示するというVBAが中々うまくいかなかったので備忘録。（A1が対象セルです）
結論として、入力規則を２つ定義するイメージです。
1つ目は小数点ありの場合、２つ目は小数点がない場合の入力規則です。
Dim xlFormatCondition As FormatCondition, xlFormatConditions As FormatConditions
Dim r As Range: Set r = Range(“A1”)
If r.FormatConditions.Count > 0 Then
For Each xlFormatCondition In r.FormatConditions
xlFormatCondition.Delete
Next
End If
Set xlFormatConditions = r.FormatConditions
‘小数点ありの場合の入力規則
Set xlFormatCondition = xlFormatConditions.Add(Type:=xlExpression, Operator:=xlLess, Formula1:=”=IF(RIGHT(TEXT(A1,””0.#””),1)=””.””,FALSE,TRUE)”)
xlFormatCondition.NumberFormat = “#,##0.#;[赤]-#,##0.##”
xlFormatCondition.SetFirstPriority
xlFormatCondition.StopIfTrue = True
‘小数点無しの場合の入力規則
Set xlFormatCondition = xlFormatConditions.Add(Type:=xlExpression, Operator:=xlLess, Formula1:=”=IF(RIGHT(TEXT(A1,””0.#””),1)=””.””,TRUE,FALSE)”)
xlFormatCondition.NumberFormat = “#,##0;[赤]-#,##0”
xlFormatCondition.SetFirstPriority
xlFormatCondition.StopIfTrue = True
蛇足
入力規則で制限する場合
With Selection.Validation
.Delete
.Add Type:=xlValidateCustom, AlertStyle:=xlValidAlertInformation, Operator:= _
xlBetween, Formula1:=”=A1*100=INT(A1*100)”
.IgnoreBlank = True
.InCellDropdown = True
.InputTitle = “”
.ErrorTitle = “小数点以下入力桁数エラー”
.InputMessage = “”
.ErrorMessage = “小数点以下は２桁まで入力可能です。”
.IMEMode = xlIMEModeAlpha
.ShowInput = True
.ShowError = True
End With
・Type 必ず指定します。入力規則の種類を指定します。
xlValidateInputOnly：すべての値
xlValidateWholeNumber：整数
xlValidateDecimal：小数点
xlValidateTextLength：文字列（長さ指定）
xlValidateList：リスト
xlValidateDate：日付
xlValidateTime：時刻
xlValidateCuestcm：ユーザー設定
・AlertStyle 省略可能です。入力規則でのエラーのスタイルを指定します。
xlValidAlertStop：停止
xlValidAlertWarning： 注意
xlValidAlertInformation：情報
・Operator 省略可能です。入力規則での演算子を指定します。
xlBetween：Formula1とFormula2の間
xlEqual：Formula1と等しい
xlGreater：Formula1より大きい
xlGreaterEqual：Formula1以上
xlLess：Formula1より小さい
xlLessEqual：Formula1以下
xlNotBetween：Formula1とFormula2の間以外
xlNotEqual：Formula1と異なる
・Formula1 省略可能です。データの入力規則での条件式の最初の部分を指定します。
・Formula2 省略可能です。データの入力規則での条件式の 2 番目の部分を指定します。
引数OperatorがxlBetweenまたはxlNotBetween以外の場合、この引数は無視されます。
参考
https://qiita.com/Q11Q/items/f035b383620eb308bc2b
https://excel-ubara.com/excelvba1/EXCELVBA391.html
https://hipstergate.jp/column/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E5%BF%8D%E6%B3%95%E5%B8%96%EF%BD%9E%E5%B0%8F%E6%95%B0%E7%82%B9%E4%BB%A5%E4%B8%8B%E3%81%8C%E3%81%82%E3%82%8B%E6%99%82%E3%81%A0%E3%81%91%E8%A1%A8%E7%A4%BA%E3%81%99/
この接続ではプライバシーが保護できません。
ShowCase.siteの証明書にLet’s Encryptを使用しているのだが、90日を過ぎた時点で「この接続ではプライバシーが保護できません。」(NET:ERR_CERT_DATE_INVALID)と表示され、サイトが開けない状態に。
証明書発行の更新はcrontabで自動更新しているので、問題ないはずなのに。
>sudo certbot renew
で手動更新してもかわらず。
試行錯誤後、nginxをリスタートしたら、無事サイトが開けた。
>sudo systemctl restart nginx
crontabは
00 09 1 * * /usr/bin/certbot renew -q –renew-hook “/bin/systemctl reload nginx”
reloadが間違ってたってことか．．．
ValueError: Related model ” cannot be resolved
クライアント環境で新たに追加したテーブルを既存テーブルの項目として外部キーを指定して追加した後、デプロイ先のクラウド環境へ同様の作業を行おうとして、躓いたので備忘録。
新たに追加したテーブルを既存のテーブルの項目として追加し、外部キーとして追加した。
作業手順としては、
・新しいテーブルを作成
・新しいテーブルにデータを追加
・既存テーブルの項目に新しいテーブルの外部キーを追加
ところが、デプロイ先ではこの手順で作業しようとすると、
>python manage.py makemigrations
を実行した時点で、
ValueError: The field [既存テーブルの項目名] was declared with a lazy reference to ‘[アプリ名.追加テーブル名]’, but app ‘[アプリ名]’ doesn’t provide model ‘追加テーブル名’.
と怒られた。
そこで、どうやら、手で追加したテーブルがmigrationとして認識されていないなと思い、手作業で追加したテーブルをdropして、magrationsフォルダの下の最新のmigration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)の追加したテーブル部分だけを残してそのほかを削除し、
>python manage.py migrate
を実行して、データを管理画面から手で追加。
再度、最新のファイルの内容を既存テーブルの項目（migrations.Addfield(…)）だけ残して実行すると、今度は
ValueError: Related model ‘[アプリ名.追加テーブル名]’ cannot be resolved
と怒られた。
結論から言うと、migration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)内の
dependencies = [
(‘[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF’),
]
のアンダーライン部分をそのまま実行したため、migration処理が直前の処理を認識できず、エラーを吐いていたと思われる。
新たにmigration実行用ファイルを追加して、そこに既存テーブルへの外部キーを追加する処理部分を記載し、dependenciesに先ほどテーブル作成したファイル名（.pyを除く）を指定して
>python manage.py migrate
を実行したら、無事作成できた。
当然と言えば、当然だけれど、エラーだけ見るとさっぱりわからないし、ググっても同じような事例は見当たらなかった。
わかったことは、migrationという仕組みが、実テーブルだけではなく、前回実行履歴を参照して実行されるということと、外部キー参照している項目を追加する場合、元のテーブルは作成しているだけではなく、実データも入力していないと、外部キーとして項目追加するとき、デフォルト設定した値の参照先がないというエラーとなり、migrateできなくなる。
この場合は、上記のように、最初に参照先のテーブルを作成するようmigration実行用ファイルを修正して、migarateし、データをinsert後、外部キーの項目追加をおこなう必要がある。
その時参照される履歴とは、[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF.pyであり、000n_auto_YYYYMMDD_HHFF.cpython-99.pycということだ。
このことを知っていれば、同エラーが発生した場合、全テーブルをdropして、maigarationsフォルダ配下のファイルを__init__.py以外すべて削除して再度作成しなおしたらうまくいったなどという解決策を平然とのせている回答例よりはましな解決策がみつかるのではないか？
imagekitでサムネイルが作られない
サムネイルを作成するには欠かせないdjangoのツールといえばimagekitかと思われますが、インストールは
pip install django-imagekit
settings.pyのINSTALLED_APPSに’imagekit’を追加して、
model.pyを↓のようにすればよいのですが、簡単には言うことをきいてくれないのがDjangoです。（だいぶ慣れてきました）
origin = models.ImageField(upload_to=getPhotoUploadPath, default=’defo’,
verbose_name=’画像’)
big = ImageSpecField(source=”origin”,
processors=[ResizeToFill(1280, 1024)],
format=’JPEG’
)
thumbnail = ImageSpecField(source=’origin’,
processors=[ResizeToFill(250,250)],
format=”JPEG”,
options={‘quality’: 60}
)
middle = ImageSpecField(source=’origin’,
processors=[ResizeToFill(600, 400)],
format=”JPEG”,
options={‘quality’: 75}
)
small = ImageSpecField(source=’origin’,
processors=[ResizeToFill(75,75)],
format=”JPEG”,
options={‘quality’: 50}
)
アプリ動かしてもsettings.pyのMIDIA_ROOTのCACHEにできるはずのサムネイルができていない。
そこで、魔法の呪文の
python manage.py generateimages
を実行すると、あれよあれよとサムネイルができました。
どこに隠れてたのかな？
migrateでテーブルが追加されない
Djangoで新規に追加したテーブルがmakemigrationsで認識されない現象が発生したのでググって解決しようとして、うまくいかなかったので備忘録。
まず最初に躓いたのが、AttributeError: ‘NoneType’ object has no attribute ‘is_relation’というわけのわからないエラー。
これはクライアント側でテストしたソースをgitでデプロイ環境へアップした際に発生。
この現象はdjango-reset-maigrationsをインストールし、INSTALLED_APPSに’reset_migrations’,を追加して、python manage.py reset_migrations appを実行して解決しましたが、次にテーブルを追加した後に同じようにデプロイした後、makemigrationsすると何も更新するものないよと言われました。
それで、デプロイ先のテーブルを覗くとやはり、該当するテーブルが存在しないので、ググって、app/migratesの下の__pycache__と、__init__.py以外を削除すればいいのかと思いおもいきり削除した結果、django.db.utils.ProgrammingError: relation “app_xxxxxxxxxx” already existsというのが出るようになってしまいました。
今思えば当然のことですが、仕方ないので、データベースから、”app_*”をdrop。
ようやく、makemaigrationsからmigrateまで、無事実行できました。
本番ではデータのバックアップ／戻しなど手間のかかる作業となりそうです。
一つのアプリだけテーブル削除して、やり直したければ（通常のmigrateがスルーしてしまう場合）以下の方法が有効のようです。
python manage.py migrate –fake app_xxxxxxxxxx zero
を実行する
python manage.py showmigrationsで確認
～
app_xxxxxxxxxx
[ ] 0001_initial
～
※スルーする場合だいたい、[X]0001_initialとなっているはずなので、XがはずれていればOK
python manage.py migrate
を実行する。
Djangoで直接SQLを実行した値をTemplateに表示する
例えば、viewsで直接SQLを実行した場合、結果を表示するにはどうするのでしょうか？
from django.db import connection
views側
SQL = ‘SELECT A.id,B.name,C.dept_id ‘ \
‘ FROM exhibitinfo A LEFT JOIN dapartment B’ \
‘ ON A.dept_id = B.id AND B.syain_id = {}’ \
‘ INNER JOIN customuser C’ \
‘ ON A.user_id = C.id’ \
‘ WHERE A.is_display=True ORDER BY A.id DESC;’.format(request.user.id)
with connection.cursor() as cursor:
cursor.execute(SQL)
exhibit = cursor.fetchall()
for history in connection.queries:
logger.info(‘****** history:’ + str(history))
context = {
‘exhibit’: exhibit,
}
…
template側
{% for item in exhibit %}
<div>{{ item.0}}</div> ← id
<div>{{ item.1}}</div> ←name
<div>{{ item.2}}</div> ←dept_id
{% endfor %}
…
となります。
例が悪くすみません。
(というか、躓きそうなところをできるだけ網羅しました。)
allauthのLoginカスタマイズ
all-authをインストールした仮想環境（以下の場合”venv”）のall-authのテンプレートをすべて、自作アプリのテンプレートフォルダにコピーします。
venv/lib/python3.x/site-packages/allauth/templates/account
→ templates/allauth/account
次に、settings.pyの”TEMPLATES”に以下の☆を加えます。
TEMPLATES = [
{
‘BACKEND’: ‘django.template.backends.django.DjangoTemplates’,
‘DIRS’: [
os.path.join(BASE_DIR, ‘templates’, ‘allauth’), ☆追加
os.path.join(BASE_DIR, ‘templates’),
],
…
あとは、templates/allauth/account配下のlogin.htmlを修正すればカスタマイズ可能です。
DegitalOceanでのVSCode
degitaloceanでVSCode使おうとしてはまったので備忘録。
最初のイメージとしては、ターミナルの中から起動するイメージだったのですがクライアントのVSCodeを起動してアクセスする方式にしました。
（この方式だとPUTTYのターミナルはあまり必要なくなりました。）
躓いたのは、公開鍵の持ち方です。
・普通のフォルダに鍵ファイルを置いて指定すると怒られる。
（ユーザフォルダなどに置くと良い）
・PUTTYGenで作成した公開鍵をOpen形式に変換したファイルを指定する必要がある。
（PUTTYGenに変換機能あり）
の２点です。
詳しくは後程追記します。
Ubuntuのmigrateで失敗する
Windows10の環境で作成した、ユーザ認証用のDjangoライブラリ(django-allauth)を使用したプロジェクトをDegitalOceanにデプロイする際にはまったので備忘録です。
まず、
>python manage.py makemigrations
を実行すると
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration account.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
などのエラーが表示されます。
どうもallauthで作成されるモデルが作成されていないため、作成さていないテーブルへカスタマイズ用の定義を追加しようとしたため、順番が違うよと言われているようだったので、再実行すると基本のテーブルが作成されているにも関わらず、カスタマイズ用のテーブルが作成されなくなりました。
>python manage.py showmakemigrations
でスケジュールを見てみると
account
[X] 0001_initial
[X] 0002_email_max_length
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[X] 0003_logentry_add_action_flag_choices
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
[X] 0007_alter_validators_add_error_messages
[X] 0008_alter_user_username_max_length
[X] 0009_alter_user_last_name_max_length
[X] 0010_alter_group_name_max_length
[X] 0011_update_proxy_permissions
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
sessions
[X] 0001_initial
sites
[X] 0001_initial
[X] 0002_alter_domain_unique
socialaccount
[X] 0001_initial
[X] 0002_token_max_lengths
[X] 0003_extra_data_default_dict
と表示され、カスタマイズテーブルは無視されています。
そこで個別にmigrateしようとおもい、
>python manage.py makemigrations xxxx
(xxxx はアプリ名)
を実行すると、今度は
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration socialaccount.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
と怒られます。
仕方ないので、env/lib/python3.8/…/socialaccount/migrationsの下を__init__.py以外を削除して実行すると今度は
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration account.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
と怒られたので、同様にaccount/migrationsの下も__init__.py以外を削除。
これでやっと
>python manage.py makemigration xxxx
が成功しました。
書いてみると単純そうだけど、試行錯誤してる最中はもう直接create tableしちゃおうかとも思ったけれど、migrateの恩恵にあずかると、楽したくなるなあと思う今日この頃です。
Djangoのチュートリアルにあるchoice_set
これはQuestionテーブルが外部参照しているChoiceテーブルのデータ、という意味のようです。
これは、はじめてこのチュートリアルを実行する人はなやむかもなあ。
まず、抽出して表示するのがなんでChoiseデータなの？
ってところからおかしくない？
Questionテーブルの内容を表示させるところじゃないかなあ？？？
ところで、またも勝手な備忘録
Djangoの新しいプロジェクトを作るコマンド
>django-admin startproject mysite
Djangoの新しいアプリを作るコマンド
>python manage.py startapp myapp
セールスフォース・ドットコム
クラウド型のシステム開発基盤としては、Azure、Googleクラウド、AWSといったところが主なものかと思っていましたが、セールスフォース・ドットコムという会社のFource.com、Herokuというのがあるんですね。
なんと、持続化給付金の申請サイトはこの会社が手掛けたそうですし、トヨタ自動車、KDDI、みずほフィナンシャルグループ、三菱UFJフィナンシャル・グループ、損害保険ジャパン、日立グループ、ジョンソン・エンド・ジョンソン、ファーストリテイリング、ローソン、株式会社日本総合研究所、小田急電鉄、楽天など、規模・業種を問わず多数の企業がこの会社のクラウドコンピューティング・サービスを導入しているそうです。
2009年には環境省・経済産業省・総務省が所管するエコポイントのインターネット申請システムを経済産業省から打診を受けてからわずか3週間でシステム開発を完了・稼働させたそうで、この会社、２０１９年度版日本の「働きがいのある会社」ランキング１位に選出されているそうで、クラウド＝AWSと思っていましたが、Herokuもありかな？
Herokuはサーバーがアメリカにあるのでアクセスが難ありと聞いていましたが…
AWSで.Net CLiサンプル動かず？
AWSの.NetCoreのサンプルのコンソールアプリを動かしてみました。
結果、bash: line 1: hello/obj/project.assets.json: No such file or directory
と怒られました。
確かにobjフォルダの下にDebugフォルダも、exeもdllもできていません。
で、色々とネットで調べてみるとどうやらAWSで動かすために必要なファイルがサンプルのインストール手順だと不足していたようです。
コマンドプロンプトから
>dotnet restore
を実行したら、正常に実行されました。
Django3おすすめ本（+Kindleで検索できない）
kindleを以前購入したんですが、文字検索でちっとも目的の本が検索できないと思っていたら、問い合わせしようと思ってWi-Fiに繋げたら検索できました。
あほすぎて笑ってしまった。
ところで、↑のようなことやってる人が言うのもなんですが、Djangoやるなら、「現場で使えるDjango の教科書（基礎編）」横瀬明仁著は目を通した方が良いと思います。
AWS Summit Online 開催のお知らせ
クラウドの最新技術を “実際に手を動かして楽しみながら学ぶ” 23日間
開催期間 2020 年 9 月 8 日 (火) ～ 9 月 30 日 (水)
◎詳細:
http://rd.itmedia.jp/33DW
これはちょっと参加してみたい！
話は違いますが、知り合いがアマゾンを騙ったメールにうっかり返信してしまったそうですが、アマゾンに問い合わせたところ、とても親切に対応して頂けたそうです。
勢いのある企業は、働き手も違う？
Cloud9とDjangoとWebサーバー起動と
Cloud9でPythonベースのWebシステムを構築する場合に使用するWebフレームワークですが、DjangoとFlaskが主なフレームワークのようです。
どちらを採用しようかググった結果、日本語環境が比較的整備されているDjangoにしようと思います。(;’∀’)
cloud9のコンソール画面でPythonのバージョンを確認します。
3.6.10ですね。2.x.系の方は3.x.系にアップグレードしてください。
Djangoの特徴としてプロジェクトごとに仮想環境を作成していくことが一般的な開発手順のようです。
次のコマンドで仮想環境を構築します。
コマンドの先頭に(venv)が表示されている場合、仮想環境に居るようです。
ではインストールしてみましょう。
pipが古いよって警告が出ていますが、Djangoは無事インストールされたようです。
Cloud9には既にMySqlがインストール済のようです。
起動／停止してみます。
はじめての起動時はパスワードなしで起動してください。
文字コードを確認します。
character_set_databaseとcharacter_set_serverがlatin1ですね。
このままだと日本語を書き込もうとしたときにエラーで落ちるので、/etc/my.cnfに設定を追加します。
character-set-server=utf8mb4
mysqlを再起動します
再度キャラクタセットを確認します。
Django用のユーザーとDBを作成します。
権限を付与します。
以上でmysql側の設定は終了です。
ちょっと横道にそれちゃいますが、
仮想環境は複数の開発を行う場合、それぞれのプロジェクトによって必要となってくるライブラリなどが異なってくるため、環境の競合がが発生しないためにプロジェクトごとに仮想環境を作って管理していこうというものですが、Pythonの標準ツールとしてvenvがあります。
venv以外にもvirtualenvなどのサードパーティ製のツールを使用しても仮想環境を作成することは可能です。ちなみに、venvで作成した仮想環境から抜けるには、
>deactivate
を実行します。
では、Djangoのサンプルを起動するところまで頑張ってみたいと思います。
任意のフォルダを作成し、gitからDjangoのサンプルアプリを取得します。
仮想環境を起動します。
サンプルの起動準備をします。
マイグレーションでサンプルアプリのデータベースを作成します。
サーバーを起動します。
ただし、アプリサーバは起動していますが、まだAWSのファイアーウォールとdjangoのホスト制限のせいで外部からアクセスできません。
これからその設定をしていきます。
Cloud9のメニューバーから’Go To Your Dashboard’を選択します。
サービスをクリックし表示画面から、’EC2’を選択します。
EC2のダッシュボードが表示されるので、「実行中のインスタンス」をクリックします。
EC2インスタンスの一覧が表示され、1つしかない場合、選択状態になっています。
画面下部にはその詳細が表示されていますが、そのうち「パブリック DNS (IPv4)」の欄に表示されているのが、URLの中央部(ホスト)になります。
この前に”http://”を、後に”:8000″をつけてアクセスしてください。
次に、セキュリティグループの欄をクリックします。
インバウンドルールを設定するダイアログが表示されるので、「ルールの追加」をクリックし、TCPカスタムを選択し、ポートの欄に8000を入力します。最後に、追加をクリックします。これで、ファイアーウォールの設定画変更され、8000番ポートのアクセスが許可されます。
上記の、「パブリック DNS (IPv4)」の欄に表示されている内容に、前に”http://”を、後に”:8000″をつけてアクセスしてください。
この時点で、Djangoのアプリにアクセスすることができます。
ただし、ホスト制限に引っかかり、下記のようなエラーが表示されます。
DjangoのALLOWED_HOSTSを設定する
まず、開きっぱなしのCloud9のIDEで、アプリケーションのディレクトリにあるconfig/settings.pyを開きます。
その中ほどまでスクロールし、ALLOWED_HOSTSというリストに、先程の「パブリック DNS (IPv4)」の欄に表示されている内容を追加します。
もう一度、:8000で終わるURLにアクセスして下さい。
サンプルアプリが起動しました。
次回は、このサンプルのDBをSQLiteからMySqlに変更したいと思います。
Gitのリモートリポジトリの移動
リモートリポジトリの移動は色々とあるようですが、簡単そうな方法で。
移動先のフォルダを初期化します。
ローカル側に一度リモートリポジトリのクローンを作成し、カレントフォルダをクローン作成先に変更します。
初期化した新しいリモートリポジトリへPushします。
以上です。
動的に読み込んだJavaScriptのソースがデバッグで表示されない
これはそう言われればなんとなく理解できるのですが、最初なんでPF12押しててソースでないんだ？？？
しゃーないconsole.logでだすか・・・
なんて思ってましたが、debugger;っていれるとデバッグモードであればそこで止まってくれます。
単純に止めたい行の前にdebugger;って入れてください。
そこでブレークします。
本番モードだとブレークしません。
IEでも、chromeでも大丈夫でした。
chromeだとその後ブレーク設定するとそこでブレークしました。
IEだとスルーするような？