プログラムのコメントについて
いい加減、Djangoの話も書かないといけないのですが、
あんまりやっていませんorz
理由は、Ｅ資格の勉強をはじめちゃったからw
人間の時間がいかに有限か実感できる瞬間です。
（ボウリングする時間減らせばもう少しできる気もするが、
大事な運動なのでダメですｗ）
さて、今回は資格の勉強は置いておいて
少し難しい論争が職場であったのでみなさんにも共有したく書いています。
それは、
「プログラムにコメントをどれだけ書くか？」
です。
これはある意味永遠の課題なのではないか？
と感じている問題なのですが、あえて書こうと思いました。
まぁ、ここでは私の持論を書きます。
私は、
メソッドに関しては原則書くようにしています。
（ただし、JAVAにあるgetやputメソッドに書かないことはある）
途中のコーディングに関してはまちまちです。
大きな分岐だったりしたら書くことが多いと思っていますが、
コードの途中でしょっちゅうコメントがあるのも気持ちが悪いと思っているので
多くの頻度はないとかなって感じです。
メソッドにコメントを書く理由
理由としては、
メソッド自体は、コードをすべて読まないとどういったものか説明できないから
書くようにしています。
このコメント書く、書かないに関しては、読めばわかるからいらない！
みたいな意見がよくあると思います。
（私の職場もありました）
こんなことは当然です。むしろ読んでわからないコードがあったほうが問題です。
ですが、読めばわかるから書かないけど、全部読まないと理解できないという
ことは問題にはならないのでしょうか？
プログラムだけでなく、いかなる資料、読み物を考えていても
100％を理解するには読むしかありません。
ですが、50％を理解するために概要があったり、見出しがあるものです。
興味を引くためにあるケースもあるでしょう。
コードも同じであるべきです。
コードも私たちプログラマーがいる以上、「読み物」だと思っています。
コメントがなくても当然読めるし、作った人なら大体ここら辺にあるかな？
といった感じで触れるでしょう。
一般的な開発現場は複数人にかかわっていることもあるし、
大型改修のために臨時で人が入ってきているということもあるでしょう。
このときにコメントがある程度あるだけでも読む人の補佐する役割としては、
十分役割を果たせると思います。
コメントがあることでメンテナンス性があがる期待をして書くようにしています。
デメリット
いいことばかり書きましたが、当然面倒な点もあります。
それは、ちゃんと更新しないと意味がないことです。
いろんなことが重なって当初とは違うことになっているメソッドがあったり、
実は使われていないっていうことがあるでしょう。
改修するときにしっかりとコメントも更新しないと
一気に役にたたないものになります。
こういうのがたくさんあるとコメントを頼りにしなくなり、
どんどん書かなくなるんだなっと感じています。
（私の現場もたまにある）
最後に
コメントについて自論を書かせてもらいました。
gitに上げているコードはまだあまり書いてないから少しずつ書いていこうかな
と思っています。
みなさんも一度メンバーと突き合わせて話してみるとコメントに困らなくなると思いますよ！
Djangoはいろいろあって業務で使うようになったので
仕事しながら新しい知識をいれてこのブログに書こうかなと思っています。
次の資格を何にしよう
前回ご報告しましたがＧ検定は無事に合格でき、
次に何の資格などを勉強するかをゆっくりと考えてました。
いろいろ費用面などでも考えましたが
「Ｅ資格」
を中心に頑張ろうかと思っています。
Ｅ資格は、Ｇ検定と同じく日本ディープラーニング協会が主催している。
資格です。
ＥはエンジニアのＥを指しています。
Ｇ検定が知識を問う試験に対して、
Ｅ資格は実装などエンジニアとして能力を問われる試験になります。
Ｅ資格はＧ検定と異なる点がいくつかあります。
・受験するためにはセミナー受験が必要になる。
応募資格を得るのには認定プログラムのセミナーもしくは講義
を受ける必要があります。
値段はさまざまですが、大体10万円近くします。
種類はそこそこあるので好きなものを受けるといいと思います。
・オンライン受験ではなく、試験会場での受験が必要
大きな点としては、こんな感じです。
一応2021年の2月ごろに試験を予定されているようですが、
世の中の情勢を踏まえた対応になると思います。
（2020年の２回目は中止となっています）
今はどのプログラムを受けようか考え中ですｗ
ＡＩ実装検定というのもあるのでこちらも受けつつ自力をつけていくのも
ありかなと考えています。
こちらは、9月なのでなるべく早く決断する必要がありそうです。
今、仕事が繁忙期でもないのでチャンスといえばチャンスなんですけどねｗ
受験に思い立ったのは理由は、
自分がどこを目指したいかを考えた結論から来ています。
私は、エンジニアですので、Ｇ検定で知識を認められただけでは満足できません。
知識を使いこなせるという証明が必要です。
そういった能力の証明までできてエンジニアとして
評価されるポイントだからと思ったからです。
あと気になっているのは
「ローコードプログラミング」です。
どんなものなのか？すら把握していないですが、
世界では流行ってきているそうなので調べたいですね。
私は、今はＷｅｂエンジニアとしていろいろやっていますが、
１機能に対してコーディングがシンプルになるように心がけています。
複雑な仕様だから複雑に作るというのは普通ですので、
物事をシンプルに、でも必要な要件を満たしてを気を付けています。
これは、後のメンテナンス性にも直結してきますので
大事なことだと思っています。
JavaやRuby、Pythonもそうですが、どの部分を共通処理として扱うのか？
フレームワークでできることはどこまで？を意識しながらコーディングを考えています。
「ローコードプログラミング」とはどういったものなのか？
今エンジニアが試行錯誤しながらやっていることがやりやすいなら日本でも
多分流行ってくるのか？と思っています。
何事も知ることは大切ですよね！
ではでは！！
G検定の結果
しばらく記事をかいていませんでしたが、
Ｇ検定の勉強に集中していました。
結果は
合格
でした。
合格できたことは素直に喜びたいですが、
いろいろ心中は複雑です。
今回は複雑な理由などをＧ検定を受けた感想などを書いていきたいと思います。
感想
受けた感想ですが、難しかったというより
シラバスや公式テキストとは何なのか？という疑念が一番強かったです。
200問中60問も出された法律や世界の動向関連の問題
公式テキストをしっかり覚えても３割程度しかとれないといわれる問題
今までの問題が公開されていないので何とも言えませんが、
様々なテキストに偏った勉強では簡単に取れなくしたい意図を感じました。
一方で、合格率は今まで通りときたので本当に価値がある資格なのかと
感じました。
私個人的には、そろそろ合格率を絞るための出題傾向の変化だと思っていました。
新しくできた資格の最初のころは合格率が高いことが多いのです。
これは、資格の存在を広めるためにも合格者をだし、認識されたあたりから
合格者を出さなくする。（有名なのは宅健かな）
今まで6割以上の合格者を出し続けていたのでこういった動きがあっておかしくない
と思っていました。
こうなってくれたほうが、今回の合格者も価値があるときに合格できたと思えた
気もします。
ツイッターとかで試験がうまくいかなかった人が自分は「過学習」状態であった！
とつぶやいているのを見てうまいなと思っていました。
さて、悪いことばかり言っても仕方ないので、良いことを書こうと思います。
試験を受けてではなかったのですが、勉強はとっても楽しかったです。
この分野の歴史を感じながら、どういった流れで今日まで至ったのか？
知れば知るほど興味が尽きないで勉強できた印象でした。
今後
Ｅ資格もいろいろ勉強して受験しようと思っています。
どちらかというとこちらが本命です。
エンジニアとしてもつことで自分の価値を高めることができるし、
勉強の過程でも自分を成長させてくれると思っています。
Ｇ検定のためのしたことに関しては記事にする気はありません。
理由は、今回の試験が大きく出題傾向が変わったので、
勉強法を大きく見直しが必要なので役に立たないと思っているからです。
一つ望むなら、公式テキストを改版してください。
以上！！！
DjangoでRESTful APIを作る
今回はDjangoでRESTfull APIを作りたいと思います。
今回のブランチはこちら
https://github.com/dsrice/base-django/tree/API/users
概要
今回はユーザ一覧を取得できるAPIを用意することを目指します。
また、RESTful APIとして簡単に用意できるもの内容のみとします。
RESTful APIとは？
そもそもRESTとはREpresentational State Transferの略です。
分散システムにおける複数のソフトウェアを連携させるのに適した設計原則の
集合、考え方になります。
2000年にRoy Fielding氏によって提唱されています。
RESTful APIとは、パラメータを指定して特定のURLにアクセスすると、XMLやJSONなどで記述されたメッセージが送られてくるようなシステム、および、そのような呼び出し規約のことをさします。
ボヤっとしている表現になっていますが、RESTには原則とよばれるものが４つあります。
・セッションなどの状態管理を行わず、やり取りされる情報はそれ自体で完結して解釈することができる
ーWebではHTTP自体にはセッション管理の機構はない
・情報を操作する命令の体系が予め定義・共有されている
ーWebではHTTPメソッドに相当
・すべての情報は汎用的な構文で一意に識別される
－URL/URIに相当
・情報の一部として、別の状態や別の情報への参照を含めることができる（ハイパーメディア的な書式で情報を表現する）
－HTMLやXMLに相当
特に注意すべきことは最初の「セッションなどの状態管理を行わず」ですね
Webサービスを作っていて、認証後のという状態を取り扱う必要性がでてきます。
セッションにいれて扱うといったことをしている方も少なくないと思いますが、
RESTの考え方ではセッションでログイン情報を管理すると原則が壊れてしまします。
Tokenなどをheaderに入れたりして扱うようにしましょう
今回は認証問題はいったん置いておいてAPIを作ることにします。
このような段階を踏むようにしたのは、
とどちらの設定がおかしいかが、切り分けるのが大変だと考えたからです。
なので。APIを作っておき、その後認証が必要になるようにすれば
どちらがおかしいのかがわかりやすいと考えたからです。
APIを作る
前置きが長くなりましたが、やり方を書いていきます。
方法は以下のSTEPを記述します。
STEP1 Serializerを作る
STEP2 Viewを作る
STEP3 routingを設定する
の3段階です。
今回はあくまでも簡単なものの用意というスタンスです。
実際の開発時はもっと複雑なことが必要になってきますが、
今回は触れません。
STEP1 Serializerをつくる
Serializerとは、データの入出力を扱い、モデルへの橋渡しをするものです。
DjangoにはSirializerにはいろいろなタイプが用意されています。
今回は、扱いやすいModelSerializerを使います。
今回は「v1」アプリケーションにAPIを追加したいので
この中に「serializers」フォルダを作成して、この中にusers.pyファイルを作成して
以下の内容記述します。
v1/serializers/user.py
from ..models import User
class UserSerializer(serializers.ModelSerializer):
class Meta:
model = User
fields = ('email' , 'first_name' , 'last_name')
このSerializerに関してはまだまだ使い方に余地がありますが、
今回はこれだけで行きます。
ModelSerializerですが、このMetaクラスは必須です。
記述を忘れないようにしましょう。
詳細を知りたい方は、こちらからどうぞ
https://note.crohaco.net/2018/django-rest-framework-serializer/
STEP2 Viewを作る
views.pyというファイルがすでにv1アプリケーション内にありますので
こちらを以下の内容に書き換えます。
v1/views.py
from rest_framework import viewsets, filters
from .models import User
from .serializers.users import UserSerializer
class UserViewSet(viewsets.ModelViewSet):
queryset = User.objects.all()
serializer_class = UserSerializer
Djangoではviewsetでviewを用意したりするのですが、
今回はModelViewsetを選択しました。
当然ほかにも使い方があるのですが、今回は割愛します。
STEP3 routingを設定する。
v1アプリケーションにurls.pyを用意します。
以下の内容を記述します。
v1/urls.py
# coding: utf-8
from rest_framework import routers
from .views import UserViewSet
router = routers.DefaultRouter()
router.register(r'users', UserViewSet)
この設定で
「http://localhost:8000/v1/users」にGETメソッドでアクセスすると
ユーザ一覧を取得することができます。
ですが、大元のbaseapiプロジェクトにv1へのroutingを設定指定なしので
こちらを設定します。
設定はここまでです。
ここまでできたら、
にブラウザからアクセスしてみましょう
すでにユーザを作っていればDBのuserにあるレコードがすべて出力されているはずです。
APIはこれで完成です！！！
ちょっとした解説
今回は簡単にAPIを作るということをテーマに書いたので細かい説明はせずに
方法に徹していました。
少しだけ解説をすると、今回の肝になっているのでModelViewSetです。
このViewSetを選択するとCRUD操作とメソッドと紐づける形で用意されます。
本来はユーザ情報を管理するには安易な手段ではありますが、
今回は解説用ということで、そこはノー突っ込みで行きたいと思います。
さて、メソッドとCRUD操作が紐づくというこですが、以下のようになっています。
GETメソッド → Read URL:http://localhost:8000/v1/users
POSTメソッド → Create URL:http://localhost:8000/v1/users
PUTメソッド → Update（全部） URL:http://localhost:8000/v1/users/:id
PATCHメソッド → Update（一部）URL:http://localhost:8000/v1/users/:id
DELETEメソッド → Delete URL:http://localhost:8000/v1/users/:id
となっています。
/:idは対象のidになります。
また、GETメソッド時の結果を見ていただければわかりますが、
返信内容を決めているのはSerializerです。
ViewSetはURLなどの情報を管理し、対象モデルから取得した結果を
Serializerを通ってレスポンスとして返す仕組みとなっています。
細かい解説はまた後日にします。（すでに3500文字を超えているし・・・）
次は認証を必要になるようにJWTを使う解説です！
今回のブランチはこちら
G検定
しばらく書いていませんでしたが、
今回はプログラミングではないですが、検定のお話
私も今回受験することにしたのですが、
G検定
です。
G検定は、日本ディープラーニング協会（以後JDLA）の認定試験です。
ちなみにG検定のGはジェネラリスト（Generalist)からとられているそうです。
G検定は、ディープラーニングに関する基本知識を有していて、
的確な活用方針を決定し、事業活用する能力や知識を有しているかを検定するもの
となっています。（HPから抜粋 https://www.jdla.org/certificate/general/）
わかりやすく表現すると、ディープラーニングを活用できる知識を有している
ということですね。
決して、ディープラーニングを活用したものが作れるというわけではありません。
こういったのは、JDLAが「E検定」とよばれる検定で認定しています。
（EはエンジニアのEです）
G検定は、知識を問う検定ですので、誰でも受けることが可能です。
合格率６割程度のようです。
問題は220問程度を２時間で回答するものとなっています。
時間にすると1問30秒程度で回答していく必要があるので、
しっかりと知識をつけておく必要がありますね。
今回、なぜ受けようかと思ったかなのですが、理由を列挙すると
１．今回の受験は半額だから
こちらに出ていますが、今回の受験料は半額になります。
しかも、受験会場に赴くのではなく、自宅です。
PCとネットワーク、家庭がある方は家族の協力があれば問題ないかと
思います。
コロナの自粛に左右されない検定です
半額の情報サイト
https://www.jdla.org/news/20200424001/
２．この資格が転職などする際に優位に働く
今転職を考えているわけではないですが、
この手人材は欲している企業は多いのも事実です。
ディープラーニングを使ったものを提供したいと考えている企業は
多いですが、それを作れているか？活用できているか？
となってくるとまだまだです。
一時期ほどの熱がないような感覚ではいますが、
それでも、おもしろ分野であることは個人的に強く思っています。
AIエンジニアやデータサイエンティストの求人では「G検定保持者」
が求めている人材欄などに書かれていることがあります。
また、最初に言いました知識があることが認められる検定ですので、
AIを活用している企業の営業職でももっていると優位に働くことは
間違いないでしょう。
３．自分の持つ技術力、知識の証明のため
開発をやっているとどれだけコードをかけるのか、
どのような考えをしているのか？
を見て転職する際に来た人がふさわしい人なのかどうかを見られます。
ですが、技術力の証明というのは難しい問題です。
課題を提出することもあれば、Gitアカウントを教えてpublicのものを見せる
などなどやり方が存在しています。
そういった意味では、
資格をもっているということはシンプルな証明手段です。
資格がたくさんあればいい、というわけではないのですが、
資格をもっているということは、しっかりと努力できる人、努力してきた人
という意味にとらえることができます。
こんなことを書いている私ですが、
社会人5年目までは、資格はあまりとろうと考えていない人間でした。
考え方の契機は、最初の転職の時です。
当時は、Robotの制御系をやっていたのですが、
言語が独自言語ということもあり、
転職するときにどうアピールするべきに四苦八苦した記憶があります。
当時は、考え方で勝負したものです・・・
（制御ができる→物事を正しい順番で考えられる、的な発想です）
これを機に自分の証明のために資格をとるということを
考えるようになりました。
勉強をしています！はだれでも言えます。
（少し参考書を読んでも勉強してるですから）
資格があります！は努力したからとれるものですので、
誰でも言えることではありません。
資格がとることを考えてみてはいかがでしょうか？
最後のほうは、私の考えか語ってしましましたが、
興味がある方は受験してみてはいかがでしょうか？
docker-compose
はじめに
今回は、Docker Composeについて話そうと思います。
Dockerについてはすでに一度記事にしましたので、
そもそもDockerってという方はそちらを読んでいただければとおもいます。
https://ds-ricekun.hatenablog.com/entry/2020/05/05/173047
Docker Composeとは？
複数のコンテナから構成される環境について、Dockerイメージのビルドや
各コンテナの起動、停止を簡単に行えるようにするツールです。
今回の私が用意した環境で説明するならば、
フロントコンテナ、APIコンテナ、DBコンテナ
の３つはセットで扱うべきものです。
これらをバラバラに起動しても互いに関係しているものなので
コンテナが起動したとしても、提供すべきアプリケーションとしてはNGです。
アプリケーションとして環境をつくるためのようなものだと思っていただいて問題ないと思います。
Docker Composeを使う
Docker Desktop on Windowsではdocker-composeがインストール済みになるので
インストールしていませんが、Dockerとは別なのでインストールが必要になる
ケースもあると思います。
ツールがインストール済みならば、
次にdocker-compose.ymlを用意する必要があります。
docker-compose.ymlは、Dockerビルドやコンテナ起動のオプションなどを含め、
複数のコンテナの定義をかきます。
それを利用してDockerビルドやコンテナ起動をすることができます。一つの簡単なコマンドで複数のコンテナを管理できるようになります。
docker-compose.ymlの書き方
今回利用した書き方に関して記述します。
ここで記載した内容以外にも書き方はあります。
興味がありましたら調べてみてください。
説明用にAPIコンテナのところのみにします。
背景が黒がymlファイル内の記述です。
説明を挟んでいきます。
version: '3'
利用するDocker ComposeのVersionになります。
現在は、３系が最新です。下げることも可能ですが、
書き方が変わってきますので注意してください。
services:
以下はコンテナ情報になります。
Dockerのイメージ名になります。
Dockerイメージをビルドするときのパスになります。
Dockerコンテナ名になります。
この記述がない場合は、ビルドした際に自動で名称がつきます。
restart: always
コンテナの再起動設定になります。
異常終了した際などにコンテナが落ちた時に記述があると自動で再起動します。
- "8000:8000"
ホストOSとのポート転送設定になります。ホストOS：ゲストOSの順番に記述します。
この記述がないとホストOSとゲストOS間の通信ができません。
Webアプリとかの開発のときは必要になるので注意しましょう。
コンテナ起動時に実行するコマンド設定になります。
もちろん不要の場合は、記述する必要がありません。
depends_on:
- db
依存性の注入設定になります。
この記述があるとDBコンテナ起動後にAPIコンテナが
起動することになります。
ただし、DBコンテナの起動 ＝ MySQLの起動後ではありません。
DBコンテナが起動後にMySQLの起動になります。
このため、APIコンテナが起動してコマンドが実行されたときに
MySQLが立ち上がり途中があるのはそのためです。
tty: true
起動したコンテナを起動したままにする宣言になります。
ないと起動後にコンテナが終了しますので注意してください。
今回、開発環境に使用したdocker-compose.ymlの内容説明としてはこんな内容です。
ネットワークの設定があったりします。
ネットワークを設定するとIPアドレスを指定できたりします。
予定
今日はGW最終日なので今後の予定をまとめるだけにします。
毎日そこそこ書き続けるのは、下準備もふくめて大変ですので
プログラム関連ですが、
以下の順番で書こうかと
１．docker-composeについて
２．Django RESTfull APIによるAPIの用意
３．JWTの実装
４．フロントとの連携（多分2回に分かれるかと）
認証回りが終わったら何を書こうかな～
と悩んでします。
一覧表示とか、検索条件まわりとか
書きたいの内容はあるのですが、順番が未定です。
ネタ的にDjango回りが多いですが、
Angular回りが少ないのでいろいろ調べて残していきたいと思っています。
しばらくはWebアプリケーション関連の話を書いていきます。
Pythonですので、機械学習の話も少しくらいかけたらな～と
思っています。
プログラム関連を中心に話でブログを書いています。
自粛が解除されていったらボウリングのことも書きたいです。
現在は、自粛していて筋トレしかやってないです。
あと柔軟もやっています。
あまり外出しないようにしているので
緊急事態宣言が延長されることになりましたが、
うまい付き合い方を探して頑張りましょう。
