Skip to content

djangoに入門したので、特徴をざっくりまとめ。

ウェブサービスを作ることになって、さて何を使おうかと考えて、最終的にdjangoを使ってみよう、ということにした。

なぜdjangoにしたかというと、キャリアとしてPythonを知っていることが今後重要になると感じたから。PythonはWeb、ロボット、機械学習、スタンドアロン、なんにでも使えるしPython3を使うのにもいい感じになってきているらしいので。

とりあえず最新版の1.11.x系を触った。

djangoの特徴

MVT

MVT(Model, View, Template)になっている。言葉が違うだけでだいたいMVCと同じ。
Mは同じくModelだけど、ViewはMVCで言うControllerの役目。TemplateがMVCのViewを担う感じ。

ある程度の規約はあるが、比較的自由に書ける。Templateの命名ルールもデフォルト値はあるが簡単に書き換えも可能。しかし規約どおりに作るとコードがどんどん減っていく作りになっている。

form・modelクラス

modelクラスはDBとのつなぎ役をやってくれるわけだけど、formクラスはウェブフォームを定義するクラス。テンプレートで使用するフォームを定義し、テンプレートの読み込ませるとその定義どおりのフォームを自動生成してくれる。

そしてそのformクラスとmodelクラスを組み合わせた、ModelFormというクラスが有り、これを定義すると、モデルとフォームのヒモ付が完了したフォームが自動生成される。

汎用ビュークラス(generic view)

よく使う機能をまるっと集めたクラス。

各CRUDやList、Detail、Redirectなどよく使う機能をお手軽に生成できる。
これを定義する時に、先に紹介したFormやModelを変数に入れるだけで画面ができてしまう。とても簡略的に書くと

class xxxcreateview(CreateView) :
model = XXXX
form = XXXX
template = XXXX

こんなかんじ。手っ取り早く機能だけをズバーっと作りたいときにとても便利。

adminページ

DBをコントロールすることの出来る管理ページが自動生成される。
開発用にDBいじりたいわーとか、テスト用のデータ作りたいわーなんて言う時に便利。
テスターの人に「こういうデータ作って」なんて言われることが減ります。ユーザ発行して作ってもらえば良いんだし。

python manager.py runserver

開発用サーバ立ち上げコマンド。このコマンドを実行すると開発用サーバが立ち上がり、プレビューが可能になる。このコマンドの場合、コードが一部変更されると自動的にサーバが再起動するので、確認が楽。

ちなみに、python manage.pyにはいろんなコマンドがあり、マイグレーションやアプリケーションの作成なども含まれる。

djangoのやりにくさ

利用実績&最新バージョンの日本語情報は少ない

採用しているサービスが少ないがゆえの宿命だと思う。機械学習が流行ってるから、ぼちぼちdjango使ってみたよーって人は増えてくると思うけど、やっぱり情報が少ない。書籍もほぼ見かけない。公式ドキュメントとstackoverflowと友だちになろう。

プロジェクトの構造どうするのが最適なんだろう?

django-admin のコマンドでプロジェクト生成すると、なーんか気持ちの良くない構造が最初に生成される。VisualStudioでDjangoのプロジェクトを生成するとまた違うプロジェクト構造が生まれてくる。どれがベストプラクティスなん?っていうのも明確にないし、公式が発行しているプロジェクト構造もなんかなーという感じ。ここは模索していくことになるだろう。

エディタ

多分pycharmが最強なんだろうけど、高いし、visual studio codeで書いてるけどいまいち補完が役に立たなかったりする。インポートとかも結構めんどくさかったりもするので、そのへん、いい感じのないのかなー。とおもうと pycharmなんだよなー…。という感じに。

VisualStudioはどうなんだろう。使ってみなければ。

ライブラリ

PHPとかRailsとかに比べればライブラリの数は少ないと思う。なければ作る!の気概がある程度必要。

まとめ

概ね気に入ってます。

初めて触ったWebフレームワークはRailsだったけど、正直肌に合わなかった。理由は使い方以前に規約が多すぎて覚えらんなかったから。djangoは規約はあれどもそこまで強いものではないし、書きやすい。

特に汎用ビューの使い方がわかってくると、どんどん機能を作っていけるようになるから学んでいて楽しいしね。

次からは使い方周りとかをまとめていこうと思います。

フロントばっかりやってた人だけどNode-REDでなんとかAPI作った

(Node-REDアドベントカレンダー 12/6分)

この前、iOSコンソーシアムという集まりのハッカソンに参加してきました。

そこで、雰囲気メガネをビーコンとiOSを組み合わせたものを作ったのですが、その中でふと「サーバーサイドってまともにやったこと無いし、やってみようかな」と思って「サーバーサイドやりまーす」と手を挙げ、APIを作ってみることにしました。

そのイベントの中で「Node-RED」の説明があり、同じチーム人から「簡単にAPI作れるよ」と言われて「簡単ならそれを使うに決まってんじゃん!」とそれを使うことにしました。

そこでNode-REDの説明をして、「どこで困ったか」という点と「ここが良かった」という点、そして「ここがこうなるといいのになー」という点をまとめて書こうと思います。

そもそもNode-REDってなんだ?

Node-REDは、IBMのBluemixで使えるフロー式のロジック作成ツールのようなもので、ノードを繋いでロジックを作り、コードを書かなくてもそこそこ動くものが作れちゃうツールです。

↓こんなの

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-11-30-12-53-20

サーバーサイドのサの字くらいは知ってる、っていう僕でもなんとなーくで使えるツールです。

以前UnrealEngine4のBluePrintを使っていたので、なんとなーく使い方はわかる感じでした。

APIをどんな風に作るのか?

上の絵で説明すると、左上に[get]/user_new ってのがありますが、あんな風にアクセスのURLを指定して、そこにアクセスがあったらどのように動作させるか?というのを、ノードで処理を繋いでいくという感じです。

使ってみてどう思ったか?

困った所

Cloudantを使うとAPIネタがぐっと減る

データベースを、とりあえずそこにあったCloudantを使いました。そしてNode-REDのAPIについて調べていくと、大体がMySQLを使ってるんですよね。「CloudantってJsonで保存してくれるんでしょ?だったらそれに突っ込めばいいや」ってかんじでCloudantを使ったんですが、もうちょっと考えるべきだったかな、と思いました。

JSを書いた場合、どこでデバッグすればいいの?

中身はnode.jsなので、コードはJSで書くわけですが、そうすると「あれ?このオブジェクトの構造みたいけどどうしたら良いんだ?」とか「ここのロジックのconsole.logとかどうやって見るの?」とか分からなくって、でもハッカソンだから時間がなくて、とりあえずエイヤーで動かしたんですが、実際の所どうするのが効率的なのか分からなかった。

フォーム送信した後の送信完了画面の出し方

ある程度の最低限機能ができて、完了画面くらい出すかー、と思ってノードを繋いでたら思った以上にできなくって、チューターの人に聞いてもわかんなくて、、と結構時間を食った。
結局、ノードをつなぐポイントが誤っていた、というのが原因だったんだけど、ノードを繋いでいても実行されない、ということが起こるとは思わなくて混乱した。

ちなみに、コレだと動いて
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-11-30-13-55-26

コレだと動かなかった
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-11-30-13-55-38

クエリのあとにDoneをやろうとすると動作しないんです「クエリ完了したからDone出すだろ!」ってイメージだったんだけど、その常識は通じなかった。

良かった所

楽!

環境つくって、コードの種類を覚えて、書き方覚えて…と考える必要なく、手順を作っていけばとりあえずはなんとかなるのが良いところ。
最初のその学習ハードルを超えて、とりあえずサクッと動かせるのは「作りたい」の気持ちを満たせるという点でとても良い。

先の興味へつながる

ただ、動かしていると「ここでエラーが出た場合は分岐したくて」とかの気持ちが出てくる。
頭のなかで「ここでswitchなりifが使えれば…」と思うけど、それってどう作るんだ?そもそもエラーコードはどう返ってくる??とかその辺が想像がつきにくくなっている。

それ故に「やっぱちゃんとコードで書けるようになりたい」という、知る動機付けにもなるなーと感じた。

これらをNode-RED上で実装できないのは僕がNode-REDのことをちゃんと知らないからかもしれないけど「全部コレでいいや」にならない分、良い影響を持っていると思う。

コピペしやすい

UnrealEngine4を使っていた頃は、ウェブ上で実装方法を調べても、そのノード構成をコピペで持ってくることは不可能でした(今はどうか知らないけど)。

それに対してNode-REDはノードの配置や内容をJsonデータをエクスポート・インポートが可能になっていることから、とても他の人のノードを参考にしやすい。これは良い。

こう改善されるといいなー

JSの実行コンソールがほしい

上でも書いたけど、js部分の動作が見えないから確認できるようになって欲しい

HTML部分でもifとかforとか使いたい

せっかく変数を受け取れるんだから、それを利用してhtmlの表示の制御がやりたい。手軽に。
チューターの人に聞いたら「JSでなんとかするしか無い」って言われて「えー」って思った。

Macの場合、カーソルがずれてて使いにくい

使った人みんな思っただろうけど、これほんと困る。

まとめ

学びはじめのハードルを低く、手軽に実装できるところはとっても良いと思います。
これって最終的に何を目指すものなんだろ?プロトタイピングツール?サービス実装までのレベルを目指すものなのかな?それによって今後の期待も変わるけど、モックを作るとか、とりあえず見せるものを作るのにいいなーって思います。

 

ニコニコプレミアムを解約して2週間経ったらいつの間にかリアル充実してた

2007年から登録していたニコニコプレミアムを解約した。
僕はニコニコは見る専なんだけど、理由はあんまり見てて面白くなくなってきたなーとぼんやり思ったからだ。

そこで、ニコニコプレミアムを解約した。

そして解約して2週間くらいは経ったけど、解約してからかなり動画を見る数が減った。
理由のひとつとして、

「動画を見るのがさっぱり快適ではない」

というのがある。

プレミアムじゃないとニコニコ動画は
・シーク出来ない
・回線速度が遅い
という利用制限が発生するんだけど、

その「シーク出来ない」がクッッッッッソすぎる。

前まではそれなりに面白くない動画でも、シークさせながら最後までなんとなーく見ていたんだけど、プレミアムじゃなくなりそれが出来ないとなると、つまんなくなってきたらソッコーで動画を閉じる、ということが起きる。

そしてそれを繰り返していると、気づくのが
「ほんとに面白いと思ってるモノしか見なくなる」ってことが起きる。

快適じゃないから「とりあえず見てみるかー」が発生しないんですね。

おかげでぼんやりなんとなく動画を見る時間が減り、
何か行動する時間が増え、
部屋を掃除し、
ご飯を作り、
洗濯をし、
出かけて、
本を読むようになった。

あれ?
動画見てた時間ってほんとに時間の無駄だったんじゃねーか?

ニコニコが好きだったから2007年から9年間毎月500円を払ってきた。
6000円 * 9 = 54000円を払ってきたわけだけど、
実は時間とお金を浪費しただけだったのでは、と思い始めてきた。

この状況を振り返ると、小中学生たちがYoutubeを見るという気持ちは凄くよく分かる。
ニコニコは月額を払うことの出来る大人たちのメディアになり、
Youtubeは無料ながらも広告を見ることで快適な動画環境で動画を見ることができる。

だってニコニコユーザーチャンネルは更に月額払わないと見れないしさ。
そんなのを子どもたちはどうやって見るのさ。

ニコニコが古いのではなく、ニコニコが新しい子どもたちを拒絶しているのではないか?
という気がする。

その月額500円で儲けてきたから今更離れられないのかもしれないけど、ニコニコが廃れていくのはしょうがないのかなーと思った。

CouchbaseLiteとRealmを比較してみた

CouchbaseMeetUpで発表してきました。
簡単にまとめると
・SyncするならCBL
・しないならRealm

って結論に至った。

pepperは「~」を使うと読みあげなくなる。

ちょっとハマったからメモ。

「~」
Unicode (UTF-8) – utf-8
判定詳細
キリル言語 (Windows) – windows-1251
→読み上げない

「〜」
Unicode (UTF-8) – utf-8
判定詳細
OEM キリル – IBM855
→「から」と読み上げる

後者でやる分には全く問題ないんだけど、前者は文字列に1文字でも入っていると、文章全体を読み上げないという事態になります。

pythonのreplaceで適当な文字列に変換してあげると良いです。

Oculus RiftのOVRPlayerControllerをXBox360コントローラで動かした時、下ボタン押下時に震えるのを消す

OVRPlayerControllerをWindowsで360コントローラ使用時、下ボタンを押すと震えます。
これは、XBox360コントローラの下ボタンに、向きをリセットする機能が割り当てられているためです。

メニューを動かすためにこの360コントローラの十字ボタンを使っていたんだけど、動かすたびに震えるので抜くことにしました。

対処する場所は、
OVR > Scripts > OVRMainMenu.cs
の1042行目をコメントアウトするとこの機能を消すことが出来る。

↓ここ
スクリーンショット 2014-01-17 17.34.16

正直ココを消すことで何か問題になるかどうかまだちゃんと調べきれていないけど、今のところ何ら問題なく動いてます。

何か問題が出た場合は修正します。
もしくは問題があるよとご存じの方はコメントくれたりすると嬉しいです。

ともかく今のところこれで対処しておる。

Unity3Dで、カメラを複数使ってレイヤー表示みたいにする方法

こちらのページを参考にしました。
http://naichilab.blogspot.jp/2013/07/unity.html

カメラを複数配置して、上に重ねたいサブカメラのdepthを、メインカメラより大きくする。
(メインカメラが0なら、重ねるカメラは1以上にする)

そしたら、サブカメラのClearFlagsをDepthOnlyに変更することで可能になる。

GUIを最前面に常においておきたいときなどにとっても便利。

ちなみにOculusRiftを利用時、OVRCameraControllerを使ってでも利用可能。
SkyboxMesh.csを利用している場合は、OVRCameraControllerのカメラがMainCameraタグになっているとバグるので、別のタグにしてやる必要がある。