2017年を振り返る

2017年もあと数十分で終わります。
皆さんの今年の目標は何で、どの程度達成できましたか。

「年を忘れる会」というものもありますが、私は回顧癖があるので(笑)、
今年の自分を振り返ってみようと思います。

アジェンダ

  • 今年の目標と達成度
  • 楽しかったこと
  • 辛かったこと
  • 来年の目標
  • まとめ

今年の目標と達成度

今年の目標

  • フリーランスとして働き、成果を上げる
  • 常駐以外の仕事をする

達成度

1つ目は自信をもって「100%」だったかなと。
幸い、独立した月(=1月)から現場も決まっており、そこが現在も続いているため、
仕事が無いというタイミングがありませんでした。
また、有難いことにその現場で評価いただけており、継続に加えて単価UPもありました。

2つ目は20%といったところでしょうか。
独立して副業ができるようになり、広告収入を得られるようになりましたが、
まだ仕事と呼べるほどのものではないので、ひとまずこの達成度にしています。
このあたりは「辛かったこと」にも書いています。

楽しかったこと

とにかく自由だったことですかね。
常駐先では無駄な残業をせず、帰宅後は「別の手段で稼ぐ」ことに集中できるというのが
とにかく楽しかったです。
もちろん決められた労働時間はありますが、その範囲であれば平日も比較的休みやすいので、
そこで事務処理や別の仕事をできました。
また、社内政治とか考課とかを気にしなくて良いのもすごく気が楽でした。

辛かったこと

常駐しているが故に、個人の仕事がなかなか請けられませんでした。
提案しても、「平日の日中でお願いできる方を優先しています」といった返答をいただくことが多かったのです。
ただ、もう少し間口を広げれば請けられる仕事があるという感覚はあるので、このあたりを見極めるのが今後の課題かと思います。

来年の目標

今年の目標が100%ということだったので、来年はもう少し貪欲にいこうと思います。
以下3点です。

  • 月1本以上のOSSへのPR
  • 副業の収入(案件数・広告など)を増やす
  • 健康診断の値をすべて正常範囲におさめる

まず1つ目。
以前の記事にも書いた通り、今年はCakePHPのOSSへPRを出す機会がありました。
ドキュメント側、CakePHPのライブラリであるBakeにも修正PRを出せました。
PRを出すということは、「そのツールについてよく理解する」「修正した経緯・内容を正しく相手に伝える」「英語を学ぶ」といった、仕事でも必要な技術を身に着けられます。
来年はもっと頻度を上げて、自分が使っているライブラリやフレームワークをより良くすることに貢献していきたいと思います。

2つ目は「辛かったこと」に書いた通りです。

3つ目については、就職してからずっと課題だったことです。
研修後、寮生活から実家に戻って飲み歩いているうちに、1年で10kg太ってしまいました。
その結果、新卒2年目から太りすぎ+脂質異常で健康診断に引っかかるようになるという悲しい展開に。
そこから数年、食べる量や種類に注意していた結果、ようやく昨年~今年で体重が10kg減りました。
今年の健康診断では体重も標準範囲内にすることができ、200を超えたLDLが30以上減っていたんです。
来年はこのLDLの値を標準範囲内にして、1つも異常が無い状態を目指します。

まとめ

来年は30歳になります。
エンジニアとしても、人としても1つのターニングポイントかと思っています。
目標を達成することも大切ですが、「無理せずマイペースに」を大事に来年も頑張ります。
それでは皆さんも良いお年をお迎えください。

Djangoを使ってデータベースを持たないAPI認証を行う

この記事は Django Advent Calendar 2017 20日目の記事です。

先日、満を持してバージョン2.0がリリースされました。
ただ、今回は新しい機能の紹介ではなく、1.xでも実装可能な「API認証」について書きます。

アジェンダ

  • この記事を書こうと思ったきっかけ
  • API認証の実装
  • まとめ

この記事を書こうと思ったきっかけ

以前、こちらにも書いたのですが、私は自分がつくったシステムのログイン~ログアウト処理に、これまた自分で作ったGo(Gin)のAPIを利用しています。
※最近はソーシャルログインなど外部サービスとの連携が楽にできるのですが、自分の勉強のためにこのようにしています。

で、以前ASP.NETでつくったレシピ管理ツールを今年Djangoに移行しまして、そこでもAPI認証をすることにしました。
CakePHP3やLaravelでは比較的簡単にできたのですが、Djangoは少し癖があったので、備忘も兼ねて書き残しておこうと思ったのがきっかけです。

API認証の実装

手順は大きく4つです。

  1. 認証用ユーザモデルの作成
  2. 認証ミドルウェアの作成
  3. 認証バックエンドの作成
  4. 設定ファイルの変更

通常、Djangoではマイグレーション時にauth_userテーブルが生成され、そこでユーザ情報を管理します。
グループやバーミッションなど細かい設定もできるのですが、今回はそれらは使用しません。

カスタムユーザモデルの作成

AbstratUserを継承した、独自ユーザーモデルを作成します。

セッションにsigned_cookieを利用しているためJSON変換処理を用意しています。

カスタム認証ミドルウェアの作成

django.contrib.auth.middleware.AuthenticationMiddlewareを参考に、以下のようなカスタムミドルウェアを作成します。

認証バックエンドの作成

Django標準の認証バックエンドとしてModelBackend(データベースを利用)やRemoteUserBackend(ヘッダのユーザー名を利用)が用意されていますが、
今回はAPI認証のため独自のバックエンドファイルを用意します。

設定ファイルの変更

最後に、settings.pyを修正します。

以上で実装完了です。

まとめ

Djangoには標準で管理画面がついてきますが、こちらはDBありきの実装なので、認証・認可をAPIで乗り切ろうと思うとかなり大変です。
標準の管理画面を利用する場合は嫌でもデータベースを使うことになるので、その場合は素直にテーブル管理しましょう。

一応、上記コード上にもコメントで記載していますが、結局のところ認証ユーザとauth_userテーブルを一旦同期させることになりそうです。

主な手順

  • ApiUserauth_userとして利用
  • API認証時、auth_userにレコードがなければ追加
  • リレーションの維持にはその値を利用

この実装を通して、Djangoが認証をどのように行っているかを学べたのは良い経験でした。
まだまだ知らない機能が多いので、これからも機能追加しつつ楽しんで開発出来たらと思います。

一部記事用に修正しましたが、今回利用したソースコードの元はこちらにありますので、良ければご覧ください。

CakePHPバリデーションメッセージにフィールド名を動的に表示させる

※2017/12/21追記
日付フォーマット処理にミスがあったため修正しました。

この記事は CakePHP Advent Calendar 2017 20日目の記事です。

皆さん、CakePHP使ってますか。
私はPHPで初めて触ったフレームワークということもあり、かなり思い入れがあります。
そんなCakePHPのバリデーションについて紹介します。

アジェンダ

  • この記事を書こうと思ったきっかけ
  • 最終的なゴール
  • カスタムバリデーションの実装
  • まとめ

この記事を書こうと思ったきっかけ

そもそもCakePHPを使うきっかけが、「就職してずっと使ってきたJava以外の言語を本格的に学びたい」という思いからでした。
仕事では簡単なツールにPHPを使っていたこともあり、CakePHP導入を決めました。

そして、実装を進めていたとき、

「バリデーションにフィールド名が出ないな…」

と思ったことがきっかけです。

最終的なゴール

以下のようなメッセージを出力します。

  • 「ID」は必須入力です。
  • 「名前」は空欄にできません。
  • 「年」は数値のみで入力してください。
  • 「生年月日」は「y/m/d」形式で入力してください。

上記は、デフォルトの翻訳ファイル(./bin/cake i18nで作成されたもの)を利用すると、以下のように出力されます。

  • このフィールドは必須です
  • このフィールドは空欄にできません
  • 与えられた値は無効です
  • 与えられた値は無効です

Oh…。

バリデーション機構の拡張

モデル・翻訳ファイルの定義

モデル・翻訳ファイルは以下のように定義します。
今回、翻訳ファイルはバリデーション用に切り出しました。

カスタムバリデータクラス追加

基本的な方針として、requiredempty以外のバリデーションルールはValidator::add()メソッドを利用するので、それを継承して調整します。
コードを見ていただければわかるとおり、requiredemptyは別途実装しています。
※もう少し良い実装方法があるはずなので、引き続き検討します…。

利用するモデル・フォームに定義

作成したバリデーションを利用するよう、TableおよびFormで定義します。

  • Table

  • Form

以上で実装完了です。

まとめ

ErrorHelperなどは、規約に則っていれば特定ディレクトリにファイルを生成するだけで利用できます。
今回のバリデーションはこれができず、少し手間に感じました。
ただ、フレームワークのコードはわかりやすく、特に問題なく理解できたので、
自分でカスタマイズするのもそこまで難しくはありませんでした。

CakePHPは個人開発で一番使っているフレームワークで、先日出した初PRも無事マージされました。

これからも内容を理解しながらぼちぼち貢献していけたらなと思っています。
それでは、皆さんも良いCakePHPライフを!

一部記事用に修正しましたが、今回利用したソースコードの元はこちらにありますので、良ければご覧ください。

文系エンジニアが目指したきっかけを振り返ってみる

この記事は文系プログラマ Advent Calendar 2017 18日目の記事です。

アジェンダ

  • エンジニアを目指したきっかけ
  • 文系でエンジニアを目指す人へ
  • 自分の経験から、新人・若手に伝えたいこと
  • 最近やっていること
  • まとめ

エンジニアを目指したきっかけ

合同企業説明会(ドームとかでやるアレです)で気になったためです。

高校は普通科、大学は心理学を専攻していたので、正直プログラマがどういうことをする人かは全く知りませんでした。
また、まわりに影響されてようやく就職活動を始めた状況で、特に何かやりたいことがあったわけでもありませんでした。

そんな中、いくつかのブースをまわっていると「IT」というワードが目に留まりました。

「普段使っている改札とか自動販売機の内部ってどうやって動いてるんやろ」

と気になり、IT企業のブースをいくつか回ってみることに。
結果、「興味」が「目標」に変わったというわけです。
今になって思えば、以下のような要因も影響していたかもしれませんね。

  • 中学2年生からWebサイトの更新を続けていたこともあり、興味を持ちやすかった
  • コンピュータを使った大学の講義が面白かった(この講義はExcelやWordを駆使するものがほとんどでしたが)

IT業界を目指すにあたり、自分に何も情報が無い状態だったので、とりあえず基礎的なことを学ぼうと中古の参考書を購入しました。
自分のノートPC上にCとJavaの実行環境をつくって、コンソールに文字を出力する日々が続きました。
月並みな表現ですが、「自分がつくったものが動く」というのがとても嬉しかったですね。

文系でエンジニアを目指す人へ

エンジニアには向き・不向きがある。
誰でもなれるとか謳ってる会社には気をつけろ!!

これですね。
私の場合、そういった謳い文句に誘われるがまま新卒で入った会社がとにかく合わなかったんです。

  • 体育会系(飲み会の頻度や営業ノリ)
  • 技術(者)が大切にされていない(PCスペックがしょぼい、技術を極めるキャリアが無い、営業色が強すぎる)
  • 残業しすぎ(一定年数以降はみなし残業になるが定時後の集まりが多すぎる。しかも22時ぐらいから飲みに行ったりする)

入る会社はしっかり選んでくださいってことですね(当たり前ですが)。

あと、若いうちは資格の勉強をしたほうが良いと思います。
取れる・取れないはあまり問題ではなく、資格取得に向けて幅広く知識を仕入れることは絶対に無駄にならないです。
大学や大学院でがっつりコードを書いてきた人には、スタートラインではどうやっても勝てないので、コツコツ積み重ねていくことが一番です。
とにかくコードを書いてみる(もしくは何かサービスを作ってみる)。
最近はインターネットでスキルチェックできるサービスも多いので、是非有効活用してください。

自分の経験から、新人・若手に伝えたいこと

以下のようなことができると一目置かれるかなと思っています。

開発視点

  • 新規開発では中心メンバーになる(アーキテクチャ選定に関われると尚良い)
  • 保守・運用では既存のコードにある「背景・経緯」を考える

業務視点

  • 顧客の業務(登場人物・利用部門やフローなど)を抑える
  • 利用する立場になって「本当に望むものは何なのか」を考える

今やっていること

ここは色々書くより最近の記事をリンクしておきます。
興味のある方はご覧ください。

リポジトリ

ブログ

Twitterつぶやき

まとめ

文系・理系関係なく、出来る奴は出来るし、向いているやつはとことん向いている

色々書きましたが、結局上記の通りかと思います。
というと身も蓋もないので(笑)、もう少し思うところを。

私の場合、興味を持って「まずはやってみた」ことが、今でもエンジニアを続けられている原点だったのかなと思います。
何をするにも、よく知らないうちから評価できるはずがありません。
周りの意見はほどほどに、「まずはやってみる」ということが重要ですね。
その結果、辛くて仕方ないのであれば「向いていない」と割り切るのも大切です。
「まずはやってみる」→「今は理解できないけど続けてみよう」→「楽しくなってきた」というスルメ状態になればしめたもの。
これを読んでいただいた方がエンジニアになり、共に働けることを楽しみにしています。

CakePHPでステータスコード204がOK扱いにならなかった話

今年のQiita Advent Calendarに投稿予定です(CakePHPとDjango)。
いずれも12/20ですので、興味があればご覧ください。

CakePHP
Django

さて、今回はCakePHPに関する記事です。
結論から言うと、PRがマージされましたというお話です。

背景

私は自作アプリのログイン・ログアウトにGoの外部API(これも自作したやつです)を使っており、
それぞれ以下のように処理しています。

ログイン

  1. アプリ:ユーザ・パスワードで認証APIをコール(POSTメソッド)
  2. API:処理成功時、ステータスコード200とアクセストークン返却
  3. アプリ:アクセストークンを利用してユーザ取得APIをコール(GETメソッド)
  4. API:処理成功時、ステータスコード200とユーザ情報を返却
  5. アプリ:取得したユーザ情報をセッションに格納してログイン成功

ログアウト

  1. アプリ:アクセストークンを利用して認証解除APIをコール(DELETEメソッド)
  2. API:処理成功時、ステータスコード204を返却

ある時、CakePHP3を使ったアプリで、正常にログアウトした場合でもエラーログが出ていることに気づきました。

「エラーのくせに詳細が何も出力されないだと…」

という衝撃を隠しきれませんでしたが(笑)、一旦落ち着いて発生箇所を調査することに。

原因

コメントに書いた通りなのですが、上記コードをもとに説明します。

  • ログアウト時の処理2でステータスコード204が返ってくる(5行目)
  • isOk()の対象でないためif文に入らない(12行目)
  • レスポンスボディもないため、CakePHP側16行目Log::error()で出力する$bodyも空(17行目)

という流れで、何も情報が無いエラーログが出力されてしまっていたということです。
これだけなら「あえて204をOKしてないのかな」とも思えたのですが。

CakePHP3側の基底テストケースではまさかのOK対象内。

修正~PR

CakePHP側のコード修正・テストコードの修正および実施を行い、
それらのPRを出したところ、5時間ほどで無事マージされました。

ドキュメントは以前PRがマージされたのですが、コード側は初めてです。
「PRは内容に問題なければサクッとマージしてもらえるんだな」ということがわかりました。

とはいえ、IssueやPR作成時の説明にもあるように、注意する点もいくつかありますので、詳細は以下をご覧ください。
CakePHP コミュニティセンター

それでは、良いCakePHPライフを。