この記事はこたつ記事です、内容はないです。
こんにちは、現在2022年12月24日23:20分です。
この記事は東京高専SPC同好会/プロコンゼミ老人会 Advent Calendar 2022 の18日目の記事です。
今年新たに訪れた飲食店を一覧で出したい、みたいなことってありますよね。
googleタイムラインの情報を解析すればできるはず！というわけでやってみた(やる予定ということを宣言します)
google データエクスポート にいってgoogel タイムラインのデータをエクスポートします。
ダウンロードしたjsonファイルを開いてい見るとそれっぽい感じで訪れた場所が保存されています。
訪れていた時間とか保存されているので、適当にあたりをつけて適当なAPIに投げれば適当な感じになるんじゃないですかね、やってないですけど。
とりあえずnameの頻度だけでsortしてみると、それっぽいけどあんまうれしくない感じの結果が出てきました。
飲食店っぽいのはzeyoと中華第一麺
以上、気が向いたらやる
こんばんは、ただいま日本時間2022年12月24日22時48分です。
この記事は、東京高専SPC同好会/プロコンゼミ老人会 Advent Calendar 2022の13日目の記事です、どうぞよろしく。
先週17日におこなわれた情報工学科学科講演会にて編入生枠で発表したので、(一部編集した)発表資料を公開します。
bar {
bindsym button4 workspace prev_on_output
bindsym button5 workspace next_on_output
}button4, button5はマウスのスクロール, 1画面しかない場合はprev/nextだけで良いが複数画面あるときはprev_on_output, next_on_outputだと嬉しい
この記事はこの記事は”東京高専プロコンゼミ① Advent Calendar 2019” 24日目の記事です．
おはようございます, 記事を書いてる現在12/25 0時20分です.もう遅刻が当たり前になってきました. さて今日はようやくクリスマス・イブです,が アドベントカレンダーの枠を取ってしまったので記事を書いて行きます. 別にアドベントカレンダーを書いてるからクリボッチをしてるわけではないんですが
今回の記事は前回のDjangoでtestsを書くはなしの続きです, まだ読んでないかたは適当に読み流してきてからこの記事を読むとわかりやすいかもしれません.
https://github.co.jp/features/actions
GitHub Actionsってなんぞやって人のために一応説明しておくと, GitHub Actionsは設計図共有サイトであるGitHubが2019/11/13にリリースしたワークフロー自動化サービスです, これまではCircle CI などの外部サービスを使わないとできなかった高度なワークフローの自動化がGitHub内でできるようになりました. MSがGitHubを買収してからGitHubの新機能がすごい増えた気がします.
基本的に無料で使えます. しかもLinuxだけじゃなくWindows, Macとかも動かせます. これまでWindowやmacOSが無料で使えるサービスはなかった気がするので, 結構大盤振る舞いです.
設定はymlファイルでおこないます, β版のときはGUIエディターが用意されてたんですが, リリース版では廃止されています. 設定の書き方はCircle CIにすごい似てるらしいです.
各Pushごとに前回の記事で書いたテストコードを自動で実行するようにします. そのためにはPythonの環境を揃えるのと, データベース(Postgresql)を立ち上げる必要があります.
公式でtemplateが用意されてたのでそのファイルに書き込む形で作りました.
Pythonのコンフィグはこんな感じになりました, 上の方で Pythonのパッケージをインストールしていて, 下の方で実際にテストを実行しています.
DjangoのtestはDBにアクセスするものもあるためDBを立てる必要があります, Exampleが公開されていたのでそれを流用しました.
https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml
動きました, 各pushごとにちゃんとテストを実行してくれます.
PRを出すとそのPRでテストが通ってるかわかりやすく表示してくれます. 嬉しい!!
GitHub Actions, 無料だし簡単に使えるので是非使いましょう. 毎回のPRでコーディング規約を守っているか, ビルドが通るかとかの確認くらいは来年のプロコンの開発で回せると(ある程度)安全な開発ができると思います.
この記事は東京高専プロコンゼミアドベントカレンダー②16日目の記事です。①の10日目の記事をまだ書いていない気がしますがきっと気の所為です、ええ。
Djangoでtestsを書いてみたので記事にします。
去年のadvent calendarのネタとして作ったto2.pwをまだ動かしているのですがバグを直したり機能を追加するたびに全ての機能が問題なく動くか確認するという作業が発生して実際何度かインシデントを起こしたりしたのと、自分がメインの開発でテストコードを書くという経験をしたことがなかったので書いてみました。決してadvent calendarのための記事を書かないといけないからではない
記事中で出てくるコードは大体ここにあるので全体が見たかったらどうぞ。
ここで言うtestsはソフトウェアテストのことです、ソースコード本体とは別にソースコードを”テスト”するためのコードを書き、自動で実行してバグの発生を防ぎます。最近では(？)ソースコード本体を書く前に仕様として満たすべき内容のテストを書き、その後開発するTDD(Test-Driven Development, テスト駆動開発)なる概念もあったりします。
日本語でtestsと”s”を付けて書いたら学校の定期テストなどではなくソフトウェアの自動テストを指すことが多い気がします、Googleも”tests”を”ソフトウェアテスト”と認識してるっぽいです。
Pythonで書けるweb frameworkです、全てのweb frameworkの中で一番高機能(or 高レイヤー)な気がします。初めから管理画面がユーザー認証が用意されていたりします。去年の課題部門ではDjangoを使った開発をしていたはずです、あと最近は使われてませんが(そもそも物をおいてないですが) 部内のpossysもDjangoを使って書かれてます。
ちなみにDjangoは”ジャンゴ”と発音します、ディジャンゴとか発音すると大変恥ずかしいので気をつけましょう。。
正直Djangoのドキュメントぐう有能なのでドキュメントを参照してほしいんですが、なんとなくこんなことができるよ的なノリで参考程度にtestsの書き方を書いていきます。
.
├── manage.py
└── app
├── init.py
├── admin.py
├── apps.py
├── migrations
├── models.py
├── tests.py
├── urls.py
└── views.py
Djangoでプロジェクトを作ったらだいたいこんな感じだと思いますが、tests.pyにテストを書き込んでいく、もしくは tests ディレクトリを作ってその中に test_hogehoge.pyを作っていくのが一般的っぽいです。ただ実行されるファイルはプロジェクト内のtest*.pyなのでそれさえ満たしてればなんでも良さそう。
実行は
python3 manage.py testで行います結果は
“`
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
..
----------------------------------------------------------------------
Ran 5 tests in 0.083s
OK
Destroying test database for alias 'default'...みたいな感じで帰ってきます。
下の例では割り算をする関数division
test_zero_divisionは0除算をしたとき-1を返すというdivisiontest_divisionは割り算が正しく行われるか調べています。asertEqual(a,b) というのはa=bのときテストが成功したと判断します。逆にa!=bだった場合テストに失敗したことを知らせてくれます。
上の例でもあった通りテストは assert を使って書いていきます、assertは一致を確認するassertEqual 以外にも不一致を確認するassertNotEqual , Trueであることを確認するassertTrueなど色々な種類があります。もっと見たい人はunittestの公式ドキュメントを参照してください。
testsを実行するのは実環境ではないのでどうしても実環境と違いがでてしまいうまくテストできない事が発生します。そんなときmockを使うと特定の関数の機能を上書きすることができます。実際 to2.pwではGoogleのrecaptchaを使っているのですがrecaptchaはunit testsでは再現できません、なのでmockを使いrecaptcha認証をしてるように見せ、テストコードを書きました。
↑ブラウザ上で発行されるtokenをgoogleに送信して認証するのでtestsでは実行できない
@mock.patch('urlshortner.views._verifyRecaptcha', dummy_return_true) でurlshortner.views._verifyRecaptcha 関数を常にTrueを返すdummy_return_true 関数に置き換えて実行しています。
ちゃっかり上の例でも使ってたんですがtestClientを使うとAPIへのリクエストを再現できます。
上の例だと/api/urls/に意図しないパラメータのリクエストが投げられたときのステータスコードとエラーメッセージを確認しています。
いかがでしたか testsの概念となんとなくの書き方を知ってもらえたら幸いです。大体どの言語にもtests用のフレームワークがあると思うので個人で開発するときにテストを導入したり、今年はできなかったですがプロコンの開発にテストを導入することを検討して貰えればと思います(まあ半年間 or 一人開発のプロジェクトでどこまでテストを書く効果があるかわかりませんが…)
この記事は東京高専プロコンゼミアドベントカレンダー②2日目の記事です。
ちなみに記事を書き始めた現在(2019/12/02 23:37 JST)です
追記: 内容が薄い気がするので気が向いたら内容増やします。。。
毎年プロコンゼミではアドベントカレンダーをやってるのですが、去年その日の記事を毎日Twitterに上げてました
手動で。なので今年は自動でツイートするようにしたいと思います。
ウェブサイトなどの更新情報をいい感じにまとめてくれるやつです、Adventar.orgの場合は adverntar.org/calendars/{id}.rss とつけると取得できます。普通は人間が直接読むものではなくRSSリーダーに定期的に読ませて更新があったら知らせてもらいます。なのでxmlで書かれていて、プログラムでのパースがしやすいようになっています。
TwitterはAPIを公開していて誰でも(英語の作文をする必要がありますが)Twitterの機能をソフトウェアから触れるようになってます。
Google Apps Script, Googleが出してる(本来は)Googleのアプリとかの連携を高度にできるなんらか、Javascriptで書けて定期的に実行したり特定のイベントで実行させたりできる。外部と通信ができるのでなんでもやれる(例えばTwitter APIを使ってtweetしたり)
とりあえず動いてます、更新があったら4時間以内に下のツイートのreply treeに入っていくはずです。コードは汚いのできれいにしてから後で公開します…
追記: なんかバグっててウケた、あとで直します…
おわり
この記事は東京高専プロコンゼミアドベントカレンダー②1日目の記事です.
ごめんなさい、明日提出の物理の課題をやっていたら時間が無くなったので後で追記します。ハワイ時間には間に合うようにします…–
追記: UTC -12 を仮定すると現在12/01 23:52です、ハウランド島とベーカー島の標準時です、ちなみにハウランド島とベーカー島は現在無人島らしいです。
ee.sbというドメインを取得しました、
SEDO.comで売ってるので興味ある人は買ってください、当分は to2.pwに使おうと思っています(まだ使えるようにしていません…) 追記, 使えるようにしました。
URLのgoogle.comgoogle.co.jplog.u-t.me
このドメインの一番右の部分(com, jp, me)はTLD(top-level domains)と呼ばれています。TLDはIPアドレスやドメインを管理しているICANN(リンク)が管理していて、日本ではJPRSが.jpを管理しています。
TLDは.jp(日本)や.us(アメリカ)など、国ごとに発行されているccTLD(country-code TLD)とそれ以外の.comや.org, .shop などのgTLD(generic TLD)に分類されます。
最近ではGMOが新TLD.shopを49億円で落札したり、Googleが.devを開放したりして話題になりました
で、これが重要なんですがccTLDは2文字, gTLDは3文字以上と決まっています。.me取ってるやんとかツッコミがきそうですが、.meはモンテネグロのccTLDです。
で、ふと短いドメインが取りたくなりました。←
ドメインは欲しかったら何でも取れるわけではなく当然既に他の人に取られていたら取れませんし, TLDによってドメインの取得条件を定めている場合があります(例えば.jpは日本国内の法人, 個人. .ac.jpは高等教育機関など)。
で2文字.ccTLD(2文字)の空いてるドメインをgoddady(リンク)のAPIとか使って探したんですが条件に合致するようなドメインはなく、無理かなーとか思って 2文字.2文字 ドメイン 取得
.sbドメインの存在を知り調べたら色々面白くて、気がついたらドメイン取得してました？？？ 5859円/yでした。(買ったとき7000円だと思ってたんだけど思ったより安かった??)
このドメイン、やばい点がいっぱいあってICCANのページに貼られてる管理者のページ(http://www.nic.net.sb/)のdnsがwixに向けられてて、それなのにwixではページが作られてなかったり。
公式のwhoisのページで無効な証明書を使ってたりします。ロック！！
レジストラがまともに活動してるかも怪しいので取得できるか怪しかったのですが4日後無事取得することができました(そもそもドメインの取得に数日かかるとか全く思ってなかったけど…)
ちなみにGandi.netで取得しました、他のドメインはGoogle Domainsで取得してるのでGoogleDomainsで取りたかったんですがGoogle Domainsでは.sbなんてドメイン扱っていませんでした…
それまで.com.sb, .net.sb, .org.sbでしか取得できなかったものが2016/12に直接取得できるようになったぽいです、まだかなり余ってそうなので2文字.2文字ドメインが欲しい人は今のうちに取っておくのがいいんじゃないんですかね
https://web.archive.org/web/20171020075812/https://nic.sb/
とりあえずto2.pwで使えるようにしておきます(まだしてません…)学生に6000/yはきついので売れたらなぁと思ってSEDO.comに出しています、誰か買ってください。。。
終わってから10日以上たってますがprocon30こと第30回 全国高等専門学校プログラミングコンテストに参加したので参加記を書いていきたいと思います。
今年は自由部門のリーダー && 東京高専プロコンゼミの代表として参加しました。
GulliverBlocskという「VRでLEGO作品の中に入り込める」ことをコンセプトにした作品で自由部門に出場しました。
開発リポジトリ
デモンストレーション(動画)
プレゼンテーション(動画)
5月初めにアイディアを確定させた気がします、アイディア出しは自由、課題含めかなり難航しました。”LEGOを3DスキャンしてVRで中に入る”というアイディアは先生にかなり難色を示されました、まずスキャン自体が難しい、ブロックを一つずつ置かないといけない、それでは楽しめないのではないか、初めからコンピュータの中で組み立てればいいじゃん。みたいな感じだったと思います、完全にその通りなので一度諦めました、が、他にいいアイディアが出なかったので結局無理やり通すことになりました。予選結果はB通過(10～20位)でした、課題がA通過(1～10位)だったので結構モチベーション削られたんですが、通ったことは通ったので開発できることになりました。
移動部門は大部分を先輩に任せていたのですが、台風が来たので振替とか色々対応してもらいました、結果として東京高専は移動日を土曜日から金曜日に変更する対応を取りました。
ポスターや配布用パンフレットなど金曜日に印刷する予定だったのを木曜日中に印刷しなければならなくなり、木曜日中に急遽原稿を完成させ、何とか印刷までこぎつけました。(あらかじめ完成させとけという話ですが…)
この日は帰宅して2時間で準備を終わらせすぐに始発で出発みたいな限界をしました。
移動日です、前日に限界をしてたので飛行機では離陸してから着陸するまでの記憶がありません。
この日はまだまともな食事をする余裕があったよう、昼食に宮崎県発祥の(?)チキン南蛮を食べています。
この日は何をやってたか記憶がありあませんが宿にこもって開発をしてた気がします、あと夜は先生方に宿に来てもらってプレゼンの練習をしていたはず。
この日trelloに 当日までにかならずやらないといけない リストを作りました。
昼ごはんは鳥そばを食べてます、このご飯を最後にプロコンが終わるまでずっとコンビニ飯でした、別に食べに行っても問題なかったはずなんですが。。。
プレゼンがある日です、プレゼンはプレゼン担当に任せてブースで展示をしてました。
12時ごろ、サーバーが落ちました。
15時ごろ(?)、太陽の位置が変わったからなのか、急に認識の精度が落ちました。
この他にも色々バグが見つかりました、当日までにかならずやらないといけないリストの内容がかなり増えました、もう当日なのに。次の日にデモンストレーション審査が待ってたのでこの日の夜ほぼ徹夜をして半分くらいは直しました。
デモンストレーション審査の日です、1回目のデモ審査はさんざんでした、できると言っていた機能が実際には動かなかったり(自分が夜直したはずの部分)しました、2回目3回目のデモは問題の機能紹介を削除しておおむね満足なデモが出来た気がします。
マニュアル審査は時間内に操作できた部分はほぼ完璧に動作したので、おそらく満点評価をとれたと思います。
結果発表の順番として 競技 => 課題 => 自由だったので他の部門が優勝, 最優秀賞が確定してる状態で自由部門が最優秀賞だと発表するまでかなり厳しかったです、ゼミの代表なので打ち上げのときに競技, 課題の最優秀賞で乾杯の音頭とるのか、最悪じゃんとか考えてました。最優秀賞が発表されたとき変な声がでました。
最終的に最優秀賞 文部科学大臣賞
フォーラムエイト企業賞
アバナード企業賞をいただくことができました
さらに競技部門, 課題部門でも優勝, 最優秀賞を頂くことができ、東京高専として 高専プロコン史上初の3冠となりました。
地元ケーブルテレビの取材を受けて放送事故レベルの日本語的にガバガバなことを言った覚えがあります。
この日の夜は焼き肉を食べました、かなり気分がハイになってた気がします。
観光をしました。
コードを一切書かずにプロジェクトマネージャをやるはずだったのですが途中からめんどくさくなりコードを書き始めてしまいました。バグが多く残っていたのも、通信のみで各モジュールごとには正しく動いてるからと統合テストを最後の1週間でやったからみたいなことがあり、ちゃんとPMしてたら防げた案件でした。
3冠を獲得できたのは、言うまでもないですがこれまでサポートしていただいた先輩方、後援会の方々、顧問の先生方、その他様々な方々のおかげだと思っています、ありがとうございました。
今後も強豪校としてプロコンに出場できるよう頑張りますので、どうぞよろしくお願いします。
来年のプロコンは苫小牧で開かれるみたいです、自分は直接は開発にかかわらないと思いますが応援メンバーとして会場には行こうと思っています。
この記事はプロコンゼミ(SPC同好会) その1 advent Calendar 2018 12日目の記事です
直前まで何を書くか決まっておらず迷走した結果sqlインジェクションが通るウェブサイトを作ることにしました()
とりあえずSQL,SQLインジェクションについて軽く触れます、SQLが何だがわかってる人は適当に読み流してもらえると。
SQLは、関係データベース管理システム (RDBMS) において、データの操作や定義を行うためのデータベース言語（問い合わせ言語）、ドメイン固有言語である。エドガー・F・コッドによって考案された関係データベースの関係モデルにおける演算体系である、関係代数と関係論理（関係計算）にある程度基づいている。 データベース言語の国際標準としてのSQLは何かの略語ではない。
by wikipedia
らしいです、はい
データベースにアクセスするための言語というかそのようなものです、基本情報の午後試験で選択できたりします、
ただ最近(?)は直接人間がsqlを書くことは少なくrailsのactiverecordやDjangoのそれなどORM(Object-relational mapping)を使うことが多いです、実際今年度のプロコンでも自由はSequerize,課題はDjangoのORMを使っていました。
SQLが直接使われなくなった原因は単純に書きにくいというのもありますが”SQLインジェクション”を引き起こしやすくなることが大きいのではないでしょうか
SQLインジェクションの説明をする前にSQL自体について説明したいと思います、私自身SQL初心者と言っても良い部類だと思うので間違っているかもしれません、あくまで参考程度に…
SQL系データベース(RDB)ではデータを表のように管理します。
Users
| id | name | password |
|---|---|---|
| 1 | Tarou | adfskj |
| 2 | Hanako | asdffjf |
| 3 | saitou | asdfhsA |
| 4 | tanaka | ASdsf |
一つの表のことをテーブル,列のことをカラムといいます
この場合はusers テーブル, name カラムみたいな感じです
# users テーブルから idカラムとnameカラムを取得
select id,name from users;
出力 =>
| id | name |
|---|---|
| 1 | Tarou |
| 2 | Hanako |
| 3 | saitou |
| 4 | tanaka |
# users テーブルから idカラムが1である要素のnameカラムを取得
select name from users where id=1;
出力 =>
| name |
|---|
| Tarou |
まあなんかこんな感じでSQLを使うと任意のデータを取り出したりデータを追加したり、上書きしたりすることができます
やっとSQLインジェクションの解説まで到達しました、
SQLインジェクションとはその名の通りSQLにinject(注入する)攻撃です。
先程まではSQLを手で打っている想定でしたが実際はアプリケーションの中で実行します、すると次のようなコードを書きたくなります
(sqlは仮定上の関数です、実際には色々なライブラリがあります)
result = sql('select name from users where id ="' + $id + '" and password="'+ $password + '";')
(usersテーブルからidが”変数id”でpasswordが”変数password”であるものの名前を取得)
一見うまく行きそうに見えますがこのコードはSQLインジェクション攻撃を受ける余地があります
変数 passwordにユーザから入力された文字列をそのまま代入している場合、次のようなsql文が発行される可能性があります
$id に 1 , $passwordに 1" or "1"="1が代入された場合
select name from users where id="1" and password ="1" or "1" = "1";
これでは本来はpasswordの値が合わないとアクセスできないデータに "1" = "1"である限りアクセスされてしまいます、これがSQLインジェクションです、SQLに悪意のある文字列を”注入”しているわけです。
通常はユーザーが入力した文字列の中にSQLで意味を持つ(記号,文)が入っていないか確認をします、railsのActiverecordやほとんどのORMがこれを自動でやってくれます。
https://sql-injection.u-t.me
さてやっと本題(?)です、現在ではほぼ全てのサイトでSQLインジェクションに対して対策が取られています(少なくとも自分はそう信じたいです)なのであえてSQLインジェクション攻撃が通用するウェブサイトを作ったわけです(?)。
もちろん実際に運用しているわけではなく、データベースも本来はサーバーで動かすのですがフロントで動かしていて、リロードするたびにデータはリセットされます。
また、SQLインジェクションがわかりやすいように()発行されたSQL文が確認できるようになっています。
SQLインジェクション攻撃の仕方は少なくとも先程説明した 1" or "1" and "1では通るようになっています。user名はadminとnormaluserです、ウェブサイトと言ってもログイン機能しかないんですけどね…
流石にサーバーで動かしてるsqlを脆弱にするのは気が引けるのでフロントでsqlを実行しています、内部ではsqliteが動いてるらしいです、はじめはweb splというブラウザ標準の機能を使う予定だったのですが、どうやらwebsqlは非推奨になったらしいです、なのでsql.jsを使っています、人類なんでも.jsつければいいとおもってるでしょ。
フロントはNuxtを使っています、プロコン期間中はあまり気にしなかったけどNuxtとても良い、フロントのコードをガンガンかけて気持ちがいい。
なにぶん全然ネタが思いつかなくて短時間で作ったのでクオリティは察してください。
ホスティングは我らがGitHubPagesを使っています。超楽、便利
あとGitHub Pagesでデプロイしてるので当然リポジトリも公開しています
github
なんというか、完全にAdventarのためのネタですが、まあ強制的にアウトプットしないといけない良い機会だと考えましょう。
最後にadventartのリンク色々
この記事はプロコンゼミ(SPC同好会) その2 Advent Calendar 2018二日目の記事です
なんか調子乗って(その1,1日目),(その２,2日目)を抑えてしまったので記事を書きます
ちなみの1日目の記事はこちら
アドベントカレンダー、人類割と0時近くに出すんだなぁ(自分の二日目の記事は朝6時までに出したいと思っている、まだ手を付けていないけど)
— たむ (@yuto_tamur) December 1, 2018
“今日”のアドベントカレンダーを書き始める
— たむ (@yuto_tamur) 2018年12月2日
はい、察してください
最後まで開発できずにベータ版として公開することにしました。
明日もテストだししょうがないね
あと世界一かどうかちゃんと調べたわけではないです(同じことをやってる人がいそう)
短縮URL作成サービスto2.pw(β)を作りました、
最短でドメインン + 2文字の短縮urlを作成できます
有効時間によって生成するURLの長さを変えています、有効時間を3時間にすると2文字の短縮URLを作成することができます。
自分が短縮URLを使うタイミングって黒板に書いたり、目の前のPCに入力したり…etcという、どんなに長くても数時間くらいしか同じURLをつかわないシーンがほとんどなので短いURLを生成できる短縮サービスを作ったわけです、あと正直ほとんど使われないと思っていて、その分強気にURLを短くしています。
あと当然自分はAdminなので専用のドメインを使って
u-t.me/任意のリンクを発行できます、具体的には
u-t.me/twitter
u-t.me/git
みたいなリンクをサービスを運用している限り使い続けることができます、
独自ドメイン、機能としてつけたいと思っているのですが、ssl証明書の発行がだるそうだなぁとか思ってます。
夏休みごろ、
=> Djangoの勉強をしたい
=> webサービス作ろう
=> 自分が使えるやつ
=> URL短縮サービス
=> なんか特徴がほしい
=> 生成されるURLを短くする
こんな感じのフローで短縮urlサービスを作ることにしました
そのときに途中までつくってたのですが、中途半端に開発を投げ出していました、
(残骸 Herokuでホストしていてまだ残ってた)
プロコンが終わり、アドベントカレンダーを書くということで、いい機会なので開発を再開することにしました,多少なりともWEBに対する知見も増えたはずなので最初から作り直しました.
で、完成した(β)のがto2.pwです
https-porta
簡単にssl化できるやつ、これまではsslかするのに色々してssl証明書を取得してnginxでssl化、３ヶ月に一回再度証明書発行、みたいなことをやっていたのですがhttps-portalを使うとdocker-composeに数行書くだけでめんどくさいこと全部やってくれます。
Django、最初からuser管理の仕組みがついてくるのですがそこに乗っける形でOAuthログインを実装してくれる、自分がやったことと言ったら設定ファイルに数行追加しただけ、費やした時間の95%がAPIキーの取得だった、SNSログインを実装するだけでDjangoを使いたくなるレベルで簡単。
上記の通りDjango使ったことはまあ良かったのですがちょっと冗長だったかもしれない、Django、テンプレート(railsでいうview)があるのですが一切使わなかった
実際にかけた時間は多分一週間にも満たないと思うのですが間が空いてしまった、モチベーションを維持する何らかのソリューションを使えばよかった（まあ今回はアドベントカレンダーがあったわけですが）
to2.pw、domains.google.comで取ってますなんかなるべく短いドメインを取ろうと思って合計2時間くらいずっと文字列を入力してた気がする、実際には個人が取得できる(現実的に)のは3文字までらしいです、ちなみに.pwはとても安かった(千円/年)SEOがとても悪いらしいです、まあ検索からの流入が見込めるものでもないからね…
ちなみにまだgoogleにindexされていない、なんかちょっと前まで匿名で(recaptchaは有り)urlを登録できた気がするのだけどなんかsearch consoleというものになったみたい
時間がなくてベータ版だみたいなことをうるさくいってきましたが具体的にこれから実装したいこと
ベータ版ですが機能としては十分に使えるはずなのでぜひ使ってください、使っていただけると泣いて喜びます。
=> to2.pw
>>
追記
何か気がついたことなどあったら気軽に連絡していただけるとうれしいです=> twitter
すみません今日も内容が薄い気がしますが明日試験なので勘弁してください
to2.pwが完成したらqiitaにも~~つよつよSEOで流入を増やすため~~記事を書くかもしれないです。
あとはじめにも触れましたがこの記事はプロコンゼミ(SPC同好会) その2 Advent Calendar 2018二日目の記事です
その1 => https://adventar.org/calendars/3129
今日(12/2)のその1担当 => @stop_pattern
明日(12/3)の担当は
その1 => @shibh308
その2 => @kapipara
です
ああもう19時だよ…:wq