`外部リンクへの遷移なので target="_blank" , rel="noopener" にしましょう。 href の所で指摘を受けた。
target="blank" で別ページのサイトを開くと その遷移先のサイトに元のサイトを参照する為のObjectが渡ってしまう。
これによってもし、遷移先のサイトが悪意のあるサイトだった場合、元のサイトを色々操作する事が出来てしまう、という話だった。
という事でそれを防止する為に rel="nooppener" をつける事が推奨（といっていいものか）されている。
なるほど、勉強になった。
SPAの時に使える、って聞いて。
作ってみたいんよね、SPA。とても興味がある。
書いてた。 （いじりすぎか。。）
これぐらいのボリューム感なら Railsチャレンジしても良いのかな、とも思った。まあ、Djangoなれる為にも頑張ろう。
普段は主にDjangoをAPIの為に使用しているので、viewのテンプレートを定義する方法はやった事がない。
意外と知ってない事があっておもしろい。
例えば、Djangoの urls.py という URLのパスを定義するファイルについて
from django.urls import path from . import views urlpatterns = [ path('', views.index, name='index'), path('<int:user_id>', views.detail, name='detail'), ]
こういう時、Viewのテンプレートでこんな感じで書いてるとすると・・・
{% if user_list %}
<ul>
{% for user in user_list %}
<li><a href="/user/{{ user.id }}">{{ user.name }}</a></li>
{% endfor %}
</ul>
{% else %}
<p>No user.</p>
{% endif %}
ユーザーの詳細URLを 変更したい時、 template をすべて変更しないといけない。
こういう時 Djangoの仕組みで 以下のように書く事で自動生成してくれる。
{% if user_list %}
<ul>
{% for user in user_list %}
<li><a href="{% url 'detail' user.id %}">{{ user.name }}</a></li>
{% endfor %}
</ul>
{% else %}
<p>No user.</p>
{% endif %}
文字列結合してたのを url 'urls.pyに定義したname' パラメータ と定義すれば 自動でURLが生成してくれるようになる、という学びがありました。
ちなみに、detail みたいにめちゃくちゃ目的範囲が強い場合、すぐにコンフリクトの懸念がある。
そういう場合はこんな感じで namespace みたいな事をして切り分けが出来る。
まずは urls.py で以下のように app_name を定義します。
from django.urls import path from . import views app_name = 'user' urlpatterns = [ path('', views.index, name='index'), path('<int:user_id>', views.detail, name='detail'), ]
そうすると template では user:detail として namespace を区切る事が出来るようになります。
{% if user_list %}
<ul>
{% for user in user_list %}
<li><a href="{% url 'user:detail' user.id %}">{{ user.name }}</a></li>
{% endfor %}
</ul>
{% else %}
<p>No user.</p>
{% endif %}
学び〜。
来週一週間で仕事納めですね。頑張ってこ。
取り敢えず、雑な感じでやってる。
最初、 ブログを保存するテーブルを blog にしてたけど、 何か違うかな？ って思って、 entry に変えた。
その仮定で DjangoのMigrationがこんな感じになった。
・ 0001_initial （ blog を create table ） ・ 0002_entry （ entry を create table ） ・ 0003_delete_blog （ blog を drop table ）
ださいなー、と思って 調整をした。
やったのはこれ。 squashmigrations のコマンドを実行した。
例えば、今回は blog という app について 上の3つのMigrationがあったんだけど、それらをいい感じにまとめる事が出来る。
実際に流したものはこんな感じ。
python manage.py squashmigrations blog 0001 0003 --squashed-name entry
そうすると 一個にまとまった。
・ 0001_entry
ちなみに showmigrations とかで見てみるとこんな表記になる。
blog [X] 0001_entry (3 squashed migrations)
3 squashed migrations という表記になって 一個のMigrationだけになる。
んで、 元の 3つのMigrationファイルは 削除をして問題なさそうだったので削除という流れで きれいなMigrationになった。
本番運用とかはまだなので本番で実行される時は 1個だけが実行されるのできれい。
Gitから消えるのもいいよね。
弊社もDjangoが結構Migration溜まってるからやってもいいな、って思った。
パーティー考えた。
相性診断的には 100% で役割がちゃんと持ててるんだけど、型を考えた所 物理型に寄ってて、どうすっかなー？
みたいな所なので 今後改良の余地はありそう。
とりあえず、ルカリオを物理特殊の両刀アタッカーにする事にした。
後、ダメ計算とかずっとやってたんだけど、 ミミッキュが化け物ってのと、 ドラパルトが化け物って事が分かった。
ま、ランク戦をやってみて改良、って感じかなー。
という事で ときには こんな趣味の話も書くのよ、という感じでした。
マンガでわかる Builder についてを書いてみた。
今回は SQL を ビルドしてくれるロボが居る、っていう前提なので 以下の構成。
今回はBuilder を作る所に観点を置いたので SQLインジェクションとか全然起こってる。危ないですね。
前の Abstract Factory よりも向き合いやすかったかな？って気はする。 まあ、毎日のように触ってるしね。
Benrida〜Builder。
ゆる〜〜り、とやっております。
いずれはこの https://ripple.ikkitang1211.site/ のブログも AWSとかでホスティングしたくて。
まず、フロントを勉強して 以下までざっくり作成しました。
ので、バックエンドを調整していってる。
Djangoをプロダクトで触ってるのでDjangoを採用した。
Ruby on Rails とか Laravelとか めっちゃやりたかったんだけど・・・・！！！！！
とはいっても、フロントの所で 知らない技術を導入するから 切り分けがむずいな、と思ったので そこは慣れてるDjangoで行くことにしました。
まあハマった所だったりやった事は雑にまとめておきます。
とても丁寧にまとまっててよかったです！！！
docker-compose run の所で docker-compose build してから動かした。
no module psycopg2 って出て最初の migration が動きませんでした。
こちら参考にさせていただきました。
pip install psycopg2 psycopg2-binary で解決
docker の初期処理を適当にやっちゃったのがまずかったっぽい。
./postgres └ /data -- ポスグレのデータ
って構成だったので /data の下のデータを削除して再起動で治った。
動くようになったのでやってくぞ〜〜〜。
SPA とかやりたいんだよなー。 でも、色々知見がない。 取り敢えず、BFFとかでやってみるかも、って思ったりした。
2ヶ月ぐらいのビッグタスクが終わった♪
ユーザーが遊ぶときに 操作するたびにラジコンとリモコンのインスタンス作っちゃうところがイマイチな感じがしますね。組み立てる人と遊ぶ人を分けると良さそう。
— えいる@補助人工心臓で子育て🔥🌇 (@eielh) 2019年12月18日
確かに。
リモコンの操作でいうとこれです。 前進の処理。
public function send_forward()
{
$this->get_relate_radio_control_car()->forward();
}
また、 get_relate_radio_control_car は こんな定義でした。
public function get_relate_radio_control_car()
{
return new TakaraTommyRadioControlCar();
}
つまり send_forward を呼ぶ度に TakaraTommyRadioControlCar() のインスタンスが生成されてしまいます。
public function __construct() { $this->radio_controller = new TakaraTommyRadioControlCar(); } public function send_forward() { $this->radio_controller->forward(); }
シングルトンてきな感じで実装を行いました。
create_radio_controllerつかってないのがなんとも言えないっすなぁ。(これをなおすのはちょっと説明しづらい
— えいる@補助人工心臓で子育て🔥🌇 (@eielh) 2019年12月18日
interface で定義を強制するけど使ってなかった。
DI的な感じで リモコンのコンストラクタに ラジコンのインスタンスを差し込むようにした。
class TakaraTommyRemoteController implements RemoteControllerInterface
{
/** @var TakaraTommyRadioControlCar */
private $radio_controller;
public function __construct($radio_controller) {
$this->radio_controller = $radio_controller;
}
/* 略 */
}
class TakaraTommyRadioControllerFactory implements RadioControllerFactoryInterface
{
public function create_remote_controller()
{
return new TakaraTommyRemoteController($this->create_radio_controller());
}
public function create_radio_controller()
{
return new TakaraTommyRadioControlCar();
}
}
これやったら、大分依存が減って良くなった感がある。
よりよい感じになったけどTakaraTommyRadioControllerFactory にリモコンとラジコンの関係が記述されてしまってますね。createXXXなメソッドが2つしかなくて、実質1つしかpublicとしてつかわれてないのもちょっとぐぬぬぬ。ですな
— えいる@補助人工心臓で子育て🔥🌇 (@eielh) 2019年12月18日
ここがなー、結構難しくて 未だに 「お、これだ！！」 ってのに至ってない。
「リモコンとラジコンをどうやって対応付けるか」という話をどこまで現実に即してコード化するかという話になりかねないけど、AbstractFatoryと例としてはリモコンにラジコンを対応付けするsetterがあればよくて、リモコンにラジコンをsetするのを責務にしたクラスを用意すると良いかもしれない。
— えいる@補助人工心臓で子育て🔥🌇 (@eielh) 2019年12月18日
setterがださいと思うなら手はあるんだけどまあ、そこは目的外の話になりそうなので、とりあえず、忘れることにした。
— えいる@補助人工心臓で子育て🔥🌇 (@eielh) 2019年12月18日
> リモコンにラジコンをsetするのを責務にしたクラス
— イルカ＠JPUG & 岡山swift (@ikkitang) 2019年12月18日
よもや こいつも Factory なのでは？
リモコンにラジコンを setするのを責務にしたクラス を作ってみた。
class TakaraTommyRemoteController implements RemoteControllerInterface
{
private $radio_controller;
public function __construct($remote_communicate_tip_factory)
{
$this->radio_controller = $remote_communicate_tip_factory->create_relate_radio_controller();
}
/* 略 */
}
/**
* リモコンとラジコンとの通信用のチップ
* Interface RemoteCommunicateTipFactoryInterface
*/
interface RemoteCommunicateTipFactoryInterface
{
/**
* @return RadioControlCarInterface
*/
public function create_relate_radio_controller();
}
class TakaraTommyRemoteCommunicateTipFactory implements RemoteCommunicateTipFactoryInterface
{
public function create_relate_radio_controller()
{
return new TakaraTommyRadioControlCar();
}
}
これで正しいのか・・？
むずいなー。 これは経験を積んでく、いわゆる 量が質に転換する、って所だとは思うけれど。。 でも、本当フィードバックありがたすぎた。
最終型はこれです。
今日は IAM の role , policy をTerraformを自分で作るみたいな事した。
雰囲気つかめた。
ざっくり PostgreSQLについて触れた所まで作った。
今後は 12について深堀りをしていく。
