AWS 認定ソリューションアーキテクト – アソシエイトに合格したのでやったことを書いていく
先日、名古屋で開催された「ラブライブ!サンシャイン!! Aqours 2nd LoveLive! HAPPY PARTY TRAIN TOUR」 に参加するついでに表題の試験を受けてなんとか合格出来たのでやったこと書いていきます。
合格証はこんな感じかな?
〇受けようと思ったきっかけ
単純におちんぎんが欲しかったのと、自分レベルでも受かりそうだなと思ったのが1番の理由です。
仕事でもAWSは使ってますし、AWS知識はあって損することはないかなと思いました。
筆者はオンプレ経験もないし、webの仕事をちゃんとし始めて1年ちょいで404以外のエラーコードもググらないと知らないし、wellknownポートもsshが22番で httpが80番ということを知ったのも最近というレベルです。
〇試験について
試験会場がとても少なく、NAGANOのような蒙い土地では試験が受けられないので、今回イベント遠征で受けるしかありませんでした。 そのため順延することも、落ちることも許されないし受験料がバカ高いというちょっと厳しい中での受験だったので落ちるわけにはいかないと自分を追い込めたことが功を奏したのかなと思います。
やったこと
1.ラブライブ!サンシャイン!!を視聴する
とても良い内容で前向きな気持ちにもなるし、ライブにも行きたくなりました。 なにか資格を取りたいけどモチベが続かない人は思ってる人はまずはラブライブ!サンシャイン!!を見てください。 ラブライブ!も見てないという人は一期と二期と劇場版をプロットを抑える程度でいいので見てください。(僕もよく憶えてません)
視聴時は序盤の千歌ちゃんの気持ちと目的、あと最終回での母親との会話シーンをしっかり抑えた上で見ると作品理解に繋がると思います。
2.合格対策本を読んだ
電車の中や寝る前はずっとこれを読んでました。4週ぐらいはしたんじゃないでしょうか。 業務ではEC2、S3、CloudFront、SNS、CloudWatch辺りは使ってるのでなんとなく概念が分かりますがGlacierとかDynamoとかSQSとかSWFとか名前すら知らなかったので、こういう本で概念を得るのはとても大事だと思います。
http://www.yodobashi.com/product/100000009002617642/
3.模試を受けた
本を2周した段階で模試を受けました。 2000円ちょいぐらいで受けれます。 問題数は少ないですがこういう感じの問題がでるよって分かるので良いと思います。 苦手分野も分かりますし。 問題は全部スクショに残して見直ししてください
これをやるやらないで大きく違います。 ちなみに自分は45点しか取れませんでした。
もうダメだ諦めようと思いましたが、君の心は輝いているかい?の歌詞の
君は何度も立ち上がれるかい?
の歌詞を思い出して問題を見直すことにしました。
本の内容は分かったつもりでも違う表現で説明されると分からなかったりして、もっと頭を回せば分かるような問題も結構あることに気付きました。 さっぱり分からんと言うのも4問ぐらいありましたが、それ以外が取れれば合格なのでいけると根拠なく確信してました。
4.問題を解きまくったりブラックベルトを読んだ
AWS WEB問題集で学習しよう – 赤本ではなく黒本の問題集から学習する方向け
ここに課金して電車で暇を見つけてはずっとやってました。
やりっぱなしにしないで、時々過去にやった問題に戻ってやったことはできているかどうかを確認しながら進めました。
問題数が多いのでがむしゃらに進むのもいいですが、時々しっかり止まって、理解しているか確認しながら進むことが大事だと思います。
よくホワイトペーパーを読めって意見もありますが、僕は英語読めないのでブラックベルトを読んでました。 slideshareの方ならスマホでも読めるし、pdfをスマホで読むのは厳しいです。
5.模試をもう一回受けた
ライブで遠征する2日前に試験を受けるべきかどうかの最終判断のためにもう一回模試を受けました。 結果は70点の合格、本試験は模試よりも難しいので受けるかどうか悩みましたが、この日に種田梨沙さんのお仕事復帰宣言がでていて、とても前向きな気持ちになれていたし、このビックウェーブに乗って朗報コンボを続けたいという思いで受験を決意しました。
6.最後までベストを尽くした
当日はバスでの移動でしたがバスの中でもずっと黒本サイトの問題を解き続けてました。
また試験中も問題が異様に難しくなんどもあ、これ無理かもって思いましたが、最後まで、見直しとあと問題をよく読み込んで、消去法や文脈理解でぎりぎりまで頭をぶんまわし続けたおかげで
なんと60%台半ばでしたが(恐らく)ギリギリ合格を果たすことができました!
〇まとめ
大事なことはAqours(ラブライブ!サンシャイン!!に出てくる主人公達が結成したスクールアイドル)からもらった諦めない力です。
人間追い込まれれば力を発揮します。
安からぬ受験料捨てたくないじゃないですか?
資格手当でおちんぎん欲しいじゃないですか?
資格欄になんか書きたいじゃないですか?
そういった(灰色の感じすらある)欲求に素直になることだと思います。
後ラブライブ!サンシャイン!!を見ましょう。9月から二期が始まります。
焦燥感に駆られてるエンジニアは高海千歌を目指せ
最近仕事が忙しかったので癒やしを求めてラブライブ!サンシャイン!!を見直してました。
改めて見てみると自分のようになにか焦燥感に追われてるエンジニアを前向きにさせる良い内容だったので色々思うところを書いておこうと思います。
ラブライブ!って何?
ラブライブ!サンシャイン!!はタイトルにもあるようにラブライブ!というスクールアイドル達が競い合う大会の名前から取られています。
1作目のラブライブではμ'sというユニットの9人の女の子達の物語が描かれ、ラブライブ!サンシャイン!!では沼津に住むAqoursというユニットで同じく9人の物語が描かれている。
が、別にラブライブ!での大会の優勝を目指して努力する話でもないし、ラブライブ!自体についてはあまり描写されず、むしろ、メンバーそれぞれの悩みの克服や欲求を叶える場としてスクールアイドルを始め、そして地区予選を突破して東海予選に出場するところで第一期は終了しました。
念のために添えておくとスクールアイドルとして頂上を目指すサクセスストーリーではありません。
高海千歌は何故スクールアイドルを始めたのか?
本作で重要なことは彼女たちがスクールアイドルを始めた動機にあると思ってます。
主人公の高海千歌は「このまま何もしないままだと普通になっちゃう」という焦燥感と
街頭モニターで見たμ'sの映像に衝撃を受けてスクールアイドルを始めることとなりました。
元々「輝きたい」というシンプルな欲求で、それを満たすためスクールアイドルという場が提供されただけで、実は水泳でも、サッカーでもなんでも良かったんじゃないかと思います。
もちろん、アイドルが歌って踊る映像はとても輝いて見えますのでスクールアイドルであることは作品の動機付けを補強することに意味が合ったと思います。
焦燥感にかられたエンジニアは何故スクールアイドルを始められないのか?
スクールアイドルというのは比喩でここではプログラミングスキル向上のための活動と置き換えてください。
掲題の回答としては単純にいうと現実との折り合いが付かないからです。
1日最低8時間働いて通勤で+1時間以上かけて、アニメも見たいし姪っ子とも遊びたい自分としてはプログラムの勉強にかけるコストなんて残っていないというのが本音です。
また、面白そうな分野というのもたくさんあって、AWSもMicrosoftも次々と新サービスを提供してきますし、機械学習、IoT、VR、フロントエンド、バックエンド、インフラ、スマホアプリ・・等々やってみたら面白そうなこと、楽しそうなことで世の中は溢れかえっています。
千歌ちゃんがスクールアイドルを選択出来るぐらい簡単に何かを選ぶことが難しい時代になってきていると思います。
本作で、曜ちゃんが飛び込みかスクールアイドルかを悩むシーンはありませんし、(梨子ちゃんに関してはピアノの大会かラブライブ!地区予選かで悩むシーンがありましたが)3年生組が受験勉強に追われる描写もありません。
作中からそういった現実との折り合いやスクールアイドル以外のタスクに追われる描写の存在を想像することはできません。
しかし、少なくとも彼女たちは夏休み返上で特訓をしています。
持てる時間はすべて練習に当てているのです。
そうです、エンジニアとAqoursの違いはモチベの有無なんじゃないかと思います。
自分のモチベを捧げられる何かを発見出来ていないのが一番なんじゃないでしょうか?
高海千歌も挫折している
本作の最後に少しだけ触れられていますが、千歌ちゃんもスクールアイドルを始める前に何か色々やってみては辞めてるようなことを母親が示唆していたように、千歌ちゃんもまた、スクールアイドルにたどり着く前に多くのことを始めては挫折していたことがうかがえます。
焦燥感に駆られたエンジニアも本を買ってみたり勉強会に出るなどしつつも結局少し手を付けて辞めてしまうことは往々にしてあるのだと思います。
挫折してもそれでいいと、ラブライブ!サンシャイン!!は教えてくれています
そうです、「君のこころは輝いているかい」の歌詞は以下のように挫折しても立ち上がることの重要性を説いています。
君はなんども立ち上がれるかい?
胸に手をあて"Yes!!"と笑うんだよ
まだ出会いにどんな意味があるか
知らないけれどまぶしいね 僕らの夢
この先がどうなるか分からないけど立ち上がることを述べるのは、先が見えず将来が分からない世界や社会の情勢の中で、立ち上がり続けることで状況に対応しようという現代人へのメッセージが込められているようにすら感じます。
色々手を付けては辞めてしまい、結局中途半端だった高海千歌にとって、スクールアイドルを始めて東海大会に進み、九人(地区予選では8人だったため)であの舞台で彼女の輝きたいという物語は達成してしまっているのです。
だから僕は二期は不要だと思います。
二期になってファンアート的にみんながわいわいする話は、ちょっとした後日談的なOVAなどとしては面白いかも知れませんが、すでに完結した物語をそこまでと同じかそれ以上の分量で描くことは物語としていけないと思っています。
もし、二期や劇場版が必要だとするなら、それはAqoursの後継者を作るために彼女達を伝説に仕立て上げるという作業だけでしょう。
最後にもう一つ、Aqoursの歌の中から歌詞を引用して終わりたいと思います。
特に最後の1行が大好きです。
届かない 星だって
手を伸ばす勢い持って
届かないって決めないで
手を伸ばせ それから悩め!
30を超えて普通にすらなれない底辺エンジニアの僕にとって手を動かすこと、挫折しても次を見つけて立ち上がり続けること、Aqoursの九人は本当に大切なことを教えてくれると思います。
しかし、30超えたおっさんが女子高生の生き方に感動するってキモチワルイデスネ
AWSのcentos+nginxでオレオレ証明書〜クライアント証明書+Let'sEncryptに証明してもらうまで
2日ぐらい作業をしたのですが、結構無駄に時間を食ってしまったので詰まりポイント等をメモしていきます
1.各証明書系を作る
4番以降はApacheの設定の話なのでスルーします。
2.作った証明書をnginxに設定する。
/etc/nginx/nginx.confを直します。
server { listen 443 ssl; # ssl on; ではなく、listen に書くのが推奨 server_name domein名を書く!; # server certificate sl_certificate /etc/pki/CA/certs/ドメイン名.crt; # サーバのSSL証明書。 # server privatae key # ssl_certificate_key /etc/pki/CA/private/ドメイン名.key; # サーバの秘密鍵。 ssl_verify_client on; # クライアント認証 # ssl_verify_depth 10; # 中間CA を使う場合のみ # CA certificate ssl_client_certificate /etc/pki/CA/cacert.pem; # プライベートCAの証明書 }
正直、どのファイルをどこに置けば良いのか全然分からないので最初にそこで詰みました。
どれがなんのファイルか理解しないと行けませんね
あと、reloadしたらエラーになって動かないこともあるので事前にチェックができます。
# which nginx /sbin/nginx # /sbin/nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful #
3.Let'sencryptで証明書を無銭で証明してもらおう
オレオレ証明だとchromeさんがこんな感じにエラーを吐きます。(画像は参考です)
ちなみに長野県のサイトは未だに証明書系がおかしいのですが、いつ直るのでしょう・・
とにかくサーバーの証明書をちゃんとしたものにするためにlet'sencryptというものを入れます。
これをやるとレッツエンクリプトさんが認めたサーバーだからOKとchromeさんも怒らないみたいです。
基本的な手順書はこちら tkuchiki.hatenablog.com
4.証明書をnginxさんに教えて上げよう
confをこんな感じに設定を直しましょう。
server { listen 443 ssl; # ssl on; ではなく、listen に書くのが推奨 server_name ドメイン名; # server certificate ssl_certificate /etc/letsencrypt/live/ドメイン名/fullchain.pem; # let's encrypt ★ここを変更 # server privatae key ssl_certificate_key /etc/letsencrypt/live/ドメイン名/privkey.pem; # let's encrypt ★ここを変更 ssl_verify_client on; # クライアント認証 # CA certificate ssl_client_certificate /etc/pki/CA/cacert.pem; # プライベートCAの証明書 }
詰まったポイント
1 t2.microだとメモリーが足りなくて落ちる
./certbot-auto certonly –webroot -w /usr/share/nginx/html -d your.domain –agree-tos -m your@email.address –debug をやった際にmemoryが足りないぞと怒られます。 しかし、それ以外にもgccのインストールで失敗してるとかpip のバージョン上げろとか色々出てるので混乱するんですよね (エラーログはすみません、残ってません)
対策) メモリーを増やそう! swapというのを使えばいいみたいです。 oh-sky.hatenablog.com
2.IP制限をかけていたのでLet'sencryptさんが自分のEC2に繋げられずにエラー
koty.hatenablog.com こちらに書かれてるとおりです
アクセス元の66.133.109.36 は固定されたIPのようなので、次回からはこのIP指定でアクセス制限しても良いかもしれない。
書かれているとおりセキュリティグループに上記を追加したら上手くいきました。
3.well-knownに繋がらない
let'sencryptは/usr/share/nginx/html 配下に .well-known/acme-challenge/ランダム文字列
で何かを作りますがここにアクセス出来なくて困っていたようです。
なのでnginxさんにこちらのlocationを作って上げないと行けませんでした。
server { listen 80; # ssl on; ではなく、listen に書くのが推奨 server_name ドメイン名; location ~ /.well-known { root /usr/share/nginx/html; } }
これを追加します。 正しいのかどうかはよく分かりません(^_^;)
4.chromeだけエラーを出し続ける(T_T)
上記の設定でsafariやfirefoxでは証明書系の警告がなくなりましたがなぜかchromeだけで続けるんですよ!
プライベートブラウズしても!
多分の回答)nginxに中間証明書はないぞ!
# ssl_verify_depth 10; # 中間CA を使う場合のみ
手順書にこういう話があったので上記の1〜3で困ったときに中間証明書の設定をonにしたりoffにしてみたりしてました。
が、よくわかりませんがこの設定がonになってるとchromeさんだけ証明書を更新してくれず?エラーを出し続けます。
これを切ってnginxをreloadすることで無事chromeでも証明書の警告がでなくなりました。
これでひとまずクライアント証明書ができて、クライアント証明書を持った人が警告なしでサイトを開けるようになりました!
問題は期間が短いのでこいつを延ばしてやる必要があります。。(以下次号)
wordpressの記事をDjangoを使って変換してくれるツールがあった
wordpressの記事は表示されるhtmlそのままではなく、何故かpタグがない状態で保存されています。
表示する際はwpautopってツールを通すと上手いことpタグを付与して実際に表示する際のイメージに変えてくれます。
つまりwordpressのデータをそのまま表示してもhtmlとして欠損しまくってて上手く動かないんですね。
で、そのwpautopをDjango用に移植してくれた神ツールがあったので紹介しておきます。
https://gist.github.com/ckelly/7901124
しかし、これ4年前のものとあってpython3系では動きません。
ということでpython3で動くようにforkしたものを上げておきました。
linebreaks_wp.py · GitHub
gistとかよく分からないので書き方の指摘あったら誰か教えてください。
ちなみにこのツールが本当に正しく動くのかどうかも不明。。
体感的には結構ちゃんと動いてる感じがします
MySQLユーザ会会 in 長野 2017に行ってきた
このイベントの参加メモです。
が、自分が無知すぎるので、せっかく東京から凄い人たちが来たのに自分は1割も理解に及んでないので申し訳ないなぁと言う気持ちと罪悪感から当エントリーはスタートしてます。
ちなみに筆者はDjangoのオーアールマッパーに頼り切った生活をしているため、裏側がmysqlなのかpostgresなのかsqlite3なのかすら意識することなくDjangoの処理を書いているため、さすがにそれじゃ不味いだろうなと言うことは頭の片隅に置きつつも今のところあんまり困っていない現状があったりします。
こんな話を聞くと登壇された方々は怒り出すか軽蔑するかも知れませんが、少なくとも2017年5月時点までの仕事でそ辺りの知識が必要になったことがないのです。
極端な話、ニューギニアの狩猟採取民族に向かってスマホも使えない野蛮人だと言ったところで彼らの生活に必要なスキルじゃないんだからしょうがないよねって思ってください。(必死の予防線)
今日のレジュメ("MySQLとは"):https://t.co/V6qSVkKMPc #nseg #mysql_jp
— 坂井 恵(SAKAI Kei) (@sakaik) 2017年5月13日
データベースとは、mysqlとはについて簡潔にまとまっていました。
今のバージョンがいくつで次はこれみたいな基本的な話も聞けました。
(InnoDBとかMyISAMってなんなんだろうという疑問は後で調べてなんとなく分かりました。)
〇MySQL 8 - @RKajiyama
(資料見つからず)
なんとMySQLの中の人による、MySQL8で導入される新機能についての色々な説明です。
色々あるみたいですが、MySQL8はめっちゃ早くなる、デフォルトのエンコーディングがutf8mb4になるので絵文字が使える。ロックの粒度が変わるぐらいしか理解の範囲にありませんでした。
(個人的には昔知らずに標準のママlatin1で建てて、日本語入らないよ〜って泣いた経験があるので世界標準のデータベース製品目指すなら必然じゃないのかなとも思いますし絵文字とかが標準で使えるのはいいですね)
〇 yoku0825を支える技術 @yoku0825
何故か舞奈たんがさかさまになっている本日のスライド #nseg #mysql_jp
— yoku0825 (@yoku0825) 2017年5月13日
わたしを支える技術https://t.co/mz3tNp0rFf
大変恐縮ですがなんの話をしているのか分かりませんでした。
MySQLって”私のSQL”って意味だと勝手に思っていたのですが開発者のお子さんの名前だったんですね。
〇Transactd PHP ORM - BizStation Corp.(@bizstationcorp)
PHPのORMの紹介です。(資料見つからず)
(すみません、PHPを知らないため、ふーんという感じでなんとなくで聞いてました。。いつかこの製品を使う場面に迫られたら思い出します。)
〇 MySQLの文字コード - とみたまさひろ(@tmtms)
当日の資料は見当たりませんでしたが1つ前のバージョンは見つけました。
エンコーディングとキャラクターセットの違いの意味がようやく分かりました。
日本語の厳密な検索は色々とめんどくさいなぁという印象です。
検索はいつでも使うことなので、お客様に検索がおかしいとか突っ込まれたら思い出そうと思います。
〇まとめ
懇親会でも色々と話を伺いましたが、まぁ何だか分からないけど熱いなぁと、最近はAWSのRDSを建てて後は全てamazon様に全てをゆだねているシアトルの植民地的な生き方を選んでいるのですが、やはり、会社に何人か、できればチームに一人とかインフラにめっちゃ詳しい人も必要だなぁと思いました。
そして今のところ、コンソール画面が苦手な僕にはインフラエンジニアとしての生き方はできないなぁとも思いました。
困ったときには今日の資料を思い出せるようにしたいですね。
あとはMySql8は今日聞いた話では超高性能っぽいので使って見たいですね!(postgresとどっちが早いんだろう)
MyNaのシールを頂きました。
mynaって鳥みたいです。
これをmacに貼る覚悟はできていないのでそっと机に閉まっておこうと思います。
Django入門その後に(8)〜TとVを追加してとにかく動かす〜
ここから先は少し複雑で、いくつかのことを同時に直さないと動かすことができません。 まずはやることを図示します。
urlにアクセスしたとき |
---|
最初のMTVモデルではurlについて説明をはしょりましたが、実際にはurlがcontrollという役割を担います。 MTVのViewの前にどのViewを呼ぶかを振り分ける、コントロールという処理があるんですですね。
流れとしては、①プロジェクトのurls.py→②アプリケーションのurls.py→③アプリケーションのViews.pyの指定したメソッド→④取得したデータをtemplateに詰めて返す
処理の順番に従うと①から書くのが良いと思うのですが、①を書くためには呼び出す②が必要で、②を書くには③が・・となるので④番のtemplateから書いていこうと思います。
最終的に何を表示したいか
最終的には先ほど登録したゆきよ様の名前を1行表示します。
④template置き場を作ろう
templateの置き場はまぁ諸説ありますが、seiyuu_info/info/template/に置こうと思います。
- seiyuu_info/info/直下にtemplatesフォルダを追加します。
- その中にlist.htmlを追加します。
- htmlを以下のように修正します。
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>ゆきよ様</title> </head> <body> <p>{{seiyuu.name}}</p> </body> </html>
ここでは{{seiyuu.name}}にデータベースから読み出した声優さんのお名前を表示します。{{ }} 二重の中括弧に括られた中にデータベースから取得したお名前を表示します。 なお、筆者はwebapiばかり作っているhtmlど素人なので、自分の勉強もかねて素のhtmlで行こうと思います。
③Viewを追加しよう
次にView(処理)を書きましょう。
seiyuu_info/views.py from django.shortcuts import render # レスポンス用の関数 from info.models import Seiyuu # データベースを使えるようにする # Create your views here. def get_yukiyo(request): """ゆきよ様のデータを返す""" seiyuu = Seiyuu.objects.get(name='藤井ゆきよ') # 声優さんTBLからゆきよ様のデータだけ取得します。 return render(request, 'seiyuu_list.html', # 使用するテンプレート {'seiyuu': seiyuu}) # テンプレートに渡すデータ
seiyuu = Seiyuu.objects.get(name=‘藤井ゆきよ’)
ここでは名前が'藤井ゆきよ'であるようなレコードをselectしています。 テーブル名.objects.get(条件)とすることで、Seiyuuテーブルの中身を一件だけselectできますが複数件(または0件)来た場合はエラーとなります。 条件の書き方も色々ありますが、今回は field名=‘条件文'という書き方にしました。 ここは感覚的に分かるかなと思います。
レコードを取得したら、次にrequestデータを受け取って、レスポンスデータを返します。 テンプレートは先ほど作成したseiyuu_list.htmlです。 seiyuu_list.htmlでは{{seiyuu.name}}を表示ししようとしていますので、seiyuuというレコードをそのまま渡します。
viewを呼ぶとtemplateにデータを詰めて返すところはできました。 しかし、まだurlにこの処理がどのurlから呼ばれるか書いていないので追加しましょう。
②アプリケーションのurlからlistを呼ぶ処理を書く
アプリケーションinfoでurlとviewを繋げます。 seiyuu_info/info/urls.pyを追加する
``from django.conf.urls import url from info.views import get_yukiyo # ゆきよ様のデータを呼び出す関数を追加
urlpatterns = [ url(r'^get_yukiyo/$‘, get_yukiyo), # http://XXX/info/list にアクセスされたらseiyuu_listの関数を呼び出す ]```
①プロジェクトのurlsからアプリケーションinfoを呼ぶ
webプロジェクト全体とinfoプロジェクトを繋げます。 ここについても、開くと英語でなにか書かれていると思いますが、あそこを参考にすれば大丈夫です。
from django.conf.urls import url, include # includeの追加 from django.contrib import admin urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^info/', include('info.urls')) # 先ほど追加したinfo.urlをinclude(良い翻訳が浮かばない)する ]``` include('info.urls')についてですが、この書き方をすることで、 info/urls.pyに書かれた全てのurlを取り込むことができます。(今回はyukiyoしかありませんが・・)</br> この時点で以下のアドレスにアクセスするとお名前が表示されていると思います。 [http://127.0.0.1:8000/info/yukiyo/:title] まずはこれで最低限の疎通ができました。 これ以降はMVTのそれぞれに絞って細かく見ていこうと思います。
Django入門その後に(7)〜Adminサイトを見てみよう〜
ここではDjangoでGUIGUIデータの投入が行えるadminについて見ていこうと思います。
1.その前にスーパーユーザーを作ろう
adminサイトを作る前にスーパーユーザーを作りましょう。 当たり前の話ですがadminサイトが誰からも見えてしまったらセキュリティ上とんでもないことです。 ログインは必須なのでその権限を持ったスーパーユーザーをつくりましょう
$ python manage.py createsuperuser Username (leave blank to use 'XXXX'): admin Email address: amind@email.com Password: minadminad Password (again): minadminad
こんな風にユーザー名、メールアドレス、パスワード(8文字以上、usernameと似た名前はダメ)を決めると作られます。 もう分かってるかも知れませんが、スーパーユーザーの情報はDjangoで最初にmigrateしたときに自動的に作られたUserテーブルに保存されています。
2.DjangoAdminを書こう
seiyuu_info/info/adminを見てみましょう。
まだこれしか書かれていません
# Register your models here.
さくっとSeiyuuモデルを追加してみましょう。
from django.contrib import admin from info.models import Seiyuu # Seiyuuクラスをimportする # Register your models here. class SeiyuAdmin(admin.ModelAdmin): # 声優アドミンのクラスを宣言 pass admin.site.register(Seiyuu, SeiyuAdmin) # 決まった書き方
# 書き方 class [モデル名]Admin(admin.ModelAdmin): # pass admin.site.register([モデル名], [上記のクラス名]) # 決まった書き方
Djangoを実行して確認してみよう
$ python manage.py runserver
そして、アドミンサイトに入ってみましょう。
ログインするとなにか画面ができてますね!
早速Seiyuusの所を押してみましょう
適当に入力してSAVEを押すと一覧にゆきよ様が追加されましたね! ちなみにこの記事を書いてるときはサカサマのパテマを見てるのですが、普通のヒロイン感あっていいですね。 こういう役もっとやってもいいと思います。
一覧から開くとこんな感じで修正や削除ができます。
後は感覚的にadminサイトを扱えると思います。一旦これでデータをGUIGUI作れるようになりました。 いよいよ。MTVモデルのTとVを一緒に作ろうと思います。次回はちょっと作業が多くて大変かも知れません。