account_web に携わるにあたって必要になるとのことで、 OAuth2.0 について調べたことのまとめです。
今回のまとめで触れるもの、触れないもの。 今回のまとめにおいて、主に触れるのはOAuth2.0のプロトコルフローについてです。 なお、プロトコルフローは下記のような6ステップに分けることができますが、今回触れるのは1 ~ 4 までとなります ( 5以降は accout_web の仕事ではないため ) 。 1. クライアントが認可を要求 1. クライアントが認可グラントを受け取る 1. クライアントが認可グラントを提示 ( アクセストークンの要求 ) 1. 認可サーバーがクライアントを認証 ( アクセストークンの付与 ) 1. クライアントが保護リソースへアクセス ( アクセストークンでの認証 ) 1. リソースサーバーがアクセストークンを確認 ( リクエストの受け入れ )
中でも、認可グラントの受け取り ( 2 ) については認可コードフローのみについてまとめています。
従来のクライアントサーバー型認証やOAuth1.0, クライアントクレデンシャル、インプリシット、リソースオーナーパスワードクレデンシャルについては今回触れません。
登場人物紹介 ( 用語集 ) もうすでに重要な登場人物が出てきていますが、ここで改めて登場人物の紹介を行います。 仕様書を読んだ個人の主観に基づいたざっくりな説明です。 ##リソースオーナー ( Resource Owner ) 保護リソースへのアクセスを許可するエンティティ ( 人間だったらエンドユーザーと呼ばれる ) 。 この人がリソースを持っているので、それがほしい人はみんなこの人に直接「ちょうだい！」って言う ( 認可要求する ) のかと思いきやそうではない ( できるけど望ましくない ) 。
当時の記録をそのまま転記 やったこと 以前 Wantedly で行われたイベントに参加した関係でご縁が生まれ、Wantedly で短期インターン ( なんと5日間 ) を行うことになりました。
配属されたのは Wantedly feed チームです。5日間このチームで何をやるのかを決めるところからスタートしました。
「何やりたい？」と聞かれて、私は1ユーザーとして Wantedly, 特にフィードにどうなってほしいかを考えました。 そこで私が注目したのは「フィードを長い間投稿していない企業には応募しづらいなあ。」という自分自身の感想です。 フィードを長い間、例えば1年以上更新していないと、
「フィードにあるような魅力的な事柄は1年経った今はもうなくなっているかもしれない」
「そもそも本気で採用活動していないのかも」
などと考えて応募ボタンを押すのを躊躇ってしまうのです。
そこで今回のインターンでは、この意見が多数のユーザーの意見であることをデータからきちんと数字として出し、一定期間フィードを投稿していない企業に対して投稿を勧めるような施策を行うことになりました。
課題に感じたこと データを集計してグラフにする。
実は、私にとって数学の授業以外では初めての経験でした。
集計対象のデータベースは PostgreSQL と BigQuery の二種類ありましたがどちらも今まで目の前にした中では飛び抜けて巨大なもので、欲しい情報を正確に取得するためのクエリの組み立てにかなりの時間を要しました。
さらに、「どのくらいのNがあればデータとして成り立つのか」「どういうグラフを作るのか」「そもそもどうやってグラフにするの」などとかなり基本的かつ根本的な問題に悩まされました。
収穫できたこと 5日間という短期間でしたがなんとかやりきることはできました。
新しい技術、知識に触れることももちろんできました ( 毎日触れすぎてやばかった ) が、収穫できたことの中で一番大きなことは「仕事」で実装するものが出す「数字」に少しでも触れられたことだと思います。
Wantedly の社員の方が仰っていたことをそのまま書かせていただきますが、どんなにきれいなコードで書かれていても、その機能がユーザーにとって良いものでなければ意味はありません。時には膨大な時間と労力を割いて実装した機能が売り上げに全く貢献しないこともあるかもしれません。
「仕事」でコードを書く以上、「数字」がついてこないとどうしようもない。
そんな世界に少しでも触れさせてもらえたことで、これからその世界に入って行こうとしている自分に足りないものは何なのか、これからどうするべきなのかを真剣に考えることができるようになりました。
繰り返しますが、5日間という短期間。けれど、この期間は非常に濃密で、得た経験は貴重なものでした。
このようにまとめると勘違いされてしまうかもしれないと思ったので最後に言っておきます。
私は怖気付いたわけではありません。結果の出せる、やってやれるエンジニアに、必ずなります！
当時の記録をそのまま転記 やったこと ちょっとしたご縁から、クラウドワークスさんで二週間の短期インターンを行うことになりました。
WoW!me という比較的新しいプロダクトの開発メンバーに加わり、希望通りサーバーサイド ( Rails ) を書かせてもらいました ( 下記 WoW!me URL )。
https://wowme.jp/
業務内容としては管理画面の機能追加などが主でした。
課題に感じたこと データベースに psql を使っていたのですが Rails チュートリアルでなんとなく使ったっきりだったのでコマンドなど調べる時間が多くなってしまっていました。
収穫できたこと 技術的な面では、単純に Rails, PostgrSQL の力が身についたと思っています。二週間という短期でしたが一緒に開発をしたエンジニアの方々の丁寧なレビューなどのおかげで Rails らしい書き方や、長くウェブサービスを保守するために避けなくてはならない書き方などを学ぶことができました。
また、OAuth を使ったタスクを担当したのですが OAuth を使った開発は初めてだったのでその辺りの知識についても深めることができたと思います。
WoW!me はモデル及びデータベースのテーブルの数が非常に多く、初めて見たときにはとても驚きましたが、ウェブサービスを長く運営し保守していく上で似て非なるものを一緒にしない細かな正規化は重要だと身を以て学びました ( 下記WoW!me のデータモデリングを行ったエンジニアの方のQiita記事 )。
http://qiita.com/suzan2go/items/445e8428a209892b521d
ここまで技術的なことについて書いてきましたがこの二週間で私が一番得られたと思っているのは「自分らしく働く」とはどういうことかだと思っています。
クラウドワークスのオフィスでは常に社員の方々の笑顔があって、会社の掲げる「働くを通して人々に笑顔を」という言葉を裏切らない会社だと思いました。
笑顔に溢れた環境でリラックスして仕事ができたのでコーディングする上での効率も良かったと感じています。
また、チーム全員が「さすが俺のプロダクト」と言わんばかりに誇りを持って仕事をしていることがうかがえました。
ユーザーの方をお招きした座談会を催すなどユーザーの意見によく耳を傾けるための施策についても積極的で自分たちのサービスがどのような形で今社会に貢献しているのか、これからどうなる事が望まれているのかが直接的に伝わってとてもやりがいを感じる事ができました。
二週間という短期間でしたがとても楽しかったですし、将来はこんな風に働きたいと心の底から思いました。
クラウドワークスの皆さんのように自分のプロダクトに誇り持って開発ができるエンジニアになれるようにこれからも精進していこうと思います！
就職してから当時を振り返って Ruby や Rails が好きになった 二週間という短い期間のインターンでしたが、この期間の間に Rails が好きになりました。
「それまで好きじゃなかったの？」という問いに答えると、答えは YES です。
当時の記録をそのまま転記 やったこと 動画配信サービスアニメイトチャンネルの開発、保守に携わるエンジニアチームの一員としてアルバイトを始めました。
学校で得たバックエンドの知識を実務経験を通じてさらに伸ばしていきたいと思い、アルバイトに応募しました。
面接などでは自分のサーバーサイドプログラミングの知識について重点的にアピールしたため、サーバーサイドのタスクが多く割り振られることを予想していましたが、少人数のチームであることもあってフロントエンドのSlim, Sass, JS も担当しました。
バックエンドからフロントエンドまで様々なタスクをこなし、ステージングデプロイや本番デプロイも行うようになりました。
課題に感じたこと 学校でのチーム開発などでは自分がバックエンドが得意ということでサーバーサイドを中心に書いており、フロントを他のメンバーに任せることが多かったです。
そのため、フロントエンドに関する圧倒的な知識不足を感じました。
特に、端末によって生じる細かな挙動の違いなどに悩まされました。
これらはある程度は調べて身につく知識だとは思いますが、実務レベルでの対応技術は実際に自分で踏んでみて初めて身につくものだと思いますので、今後もっともっと経験を積んでいきたいです。
「バックエンドのほうが得意、好き、やりたい」という思いは今でも変わりませんが、突然何らかの関係でフロントのタスクを担当することはあると思いますので、その辺りの力も身につけていきたいです。
収穫できたこと GitFlowでの実務レベルでの開発経験を積めたことから、PRの精度が格段に上がったと思います。
Jenkinsを使ったデプロイの経験は初めてのものでしたが、今ではスムーズに行えます。
上司の方からのレビューを通じて自分のコードの書き方の問題点などを認識し、改善につなげることができました。
また、エンジニアとしてディレクター陣に伝えなくてはならないこと、問題はどこにあるのか、などエンジニアとしてのものの考え方についてもさらに学ぶことができました。
今後もさらに経験を積んで、様々な問題を問題の本質を見極めつつ解決することのできるエンジニアに成長していきたいです。
就職してから当時を振り返って。 とにかく必死だった。 なんといってもこれについきます。
なにせ初めての実務経験、初めてのアルバイトです。しかも使用する言語は今まであまり触れていなかった Ruby でした。学校では得意としたサーバーサイドであっても、よく知らない言語、よく知らないフレームワーク ( Rails ) を使うということから自信を持ってタスクに取り組むことが難しかったように思います。
結果として、本当にやりたいサーバーサイドのタスクがあった時に積極的に声をあげることができず、自分の中ではあまり好ましくないフロントエンドのタスクばかり回されるようになってしまいました。
個人的な趣味趣向の問題でフロントエンドはあまり好きではないのですが、気づいた時にはチーム内でのフロント担当になっていました。学校では好きじゃないからと疎かにしてきたフロントエンドの技術ですが、仕事を任されてしまえばやらないわけにはいきません。
今までは極力避けてきた CSS ( Sass ) もゴリゴリ書きました。ブラウザ特有の挙動の違いはもちろん、端末特有の挙動の違いなどにもぶち当たり、フロントエンドの辛さを垣間見たと思っています。
実務経験自体が初めてだったので、毎日必死にタスクをこなしていました。フロントエンドのタスクも、最初は夢中でこなしていたのです。
そもそも何をしに来た？ しかし、アルバイトを始めて1ヶ月半ほど経つと、「そもそも、私はここに何をしに来たんだっけ？」などと考える余裕が出てきます。
「お金を稼ぎに来た」
確かにそれもあります。当時の私は一人暮らしを始めたばかりで、楽な暮らしではありませんでした。けど、それだけでしょうか？もちろん違います。
「エンジニアとして成長するために来た」
この要素は大きいでしょう。では、この エンジニアとして成長 というのは、どのようなエンジニアへの成長のことだったのでしょうか。
サーバーサイドを極める コードを書くことを純粋に楽しむ これが目標だったはずなのです。
どうしてこうなった？ やりたいことがあって、それを面接でもアピールしてアルバイト採用されたはずなのに、いつの間に目標とやっていることがずれてしまっていたのでしょう。
実際に業務が始まってから、しばらく経つまで自分の目標を見失っていた。 目の前の仕事に必死になっていた。 自分の目標を具体的なレベルまで落とし込めていなかった。 やりたいタスクがあっても「自分がやります」「やりたいです」「やらせてください」という声をあげることができなかった。 職場という環境に不慣れだった。 過度な遠慮をしていた。 上記にあげていることが原因だと思っています。
会社で働くということ。 いろいろとマイナスにも取れることについて書いましたが、もちろんこのアルバイトを通して得られたことはとても大きかったです。
本日のTIL ぶつかったこと 仕事でコードを書いてレビューをお願いしたら、上司から二つ前のコミットを変えるように言われました。 「--fixup を使うといいよ！」と言われたのですが、そのオプションを知らなかったのでググってみました。
解決法 普通にコミットするときに既存のコミットを下のように指定します。
git commit --fixup HEAD~1 こうすると指定されたコミットメッセージの先頭に “fixup! ” がついたコミットになります。
そして、この状態で --autosquash というオプションをつけて rebase -i します。
git rebase -i --autosquash HEAD~2 すると、エディタが開きますが、とりあえず何も考えず内容を保存して終了してみましょう ( エディタが開いた段階で指定したコミットと”fixup!” がついたコミットがまとめられるようになっています )。 これで、 “fixup!” のついたコミットと指定したコミットが一つにまとまります ( コミットメッセージには “fixup!” はつきません ) 。
ちなみに、 --autosquash というのは長いですね。いちいちオプションをつけるのは面倒です。 エイリアスを設定してもいいのですが、下記のように設定するといつでも rebase をするときに --autosquash をつけたのと同じことになります。--autosquash オプションをつけて頻繁に rebase する場合はぜひ下記のコマンドを叩きましょう。
git config --global rebase.autosquash true まとめ 便利なオプションがあったんだなあ。というお気持ちです。はい。
本日のTIL ぶつかったこと 新規アグリコードを書いていたら、CSVを編集しなければならなくなり、Mac で CSV をいい感じに編集できるものを探すことになりました。 一応、前提として私は以下のような状況でした。 - excel は持ってない。高い。 - Numbers で編集すると拡張子が .numbers になったものを編集してることになってややこしいし、なぜか Numbers で開くと空白とか書式が勝手に Numbers 的によしなにされてしまうらしく、余計な差分が出まくる。 - 普段 atom を使っている ( やっぱり atom が一番だよね！ )
解決法 結論 tablr というパッケージを atom にインストール 自分なりに解説 解説というか、一応使い方みたいなところを書いておきます。
インストール apm install tablr 使い方 tablr がインストールされた状態で csv ファイルを開くと下のような画面が出てきます。
「Open Table Editor」で表になった状態で編集できる画面が、「Open Text Editor」で通常のテキストベースでの編集ができます。
OpenTableEditor OpenTableEditor を選択するとこんな感じに表示されます。 セルの編集はもちろん複数選択やコピペなどができて、普通の表を編集する時に求めるような機能はだいたいあると思います。 一応 こちら がチートシートになっているので、あの機能はどうやったら使えるんだ？という時には覗くときっと見つかると思います。 基本的な編集は直感的に行えますので、あまり複雑なことをしなければ導入にあたっては苦労しない気がします。
まとめ やはり普段使っているエディタを使うのが慣れるのも早く、導入もスムーズでいいですね。 atom は新しい言語のシンタックスハイライトやリンターなどに代表されるように、様々なパッケージが常に作られていて、それを手軽にインストールすることができるので便利です。 まともなエディタならみんなそうだと言われてしまうとその通りだと思いますが、私はやっぱり atom が一番慣れているのでw
本日のTIL 今日は 前回 予告した通り Java の抽象クラスとインターフェイスについてまとめます。
抽象クラス abstract という修飾子をつけることで 抽象クラス を作ることができます。
特徴 オブジェクトを作成することができない new して作れないってこと。 抽象クラスの変数や配列は準備してサブクラスのオブジェクトをさすことはできる。 処理内容が定義されていないメソッド ( 抽象メソッド – abstract method )を持っている。 abstract というキーワードをつけてメソッドを定義すると抽象メソッドに。 サブクラスを拡張することができる。 ただし、 抽象クラスから継承した抽象メソッドの内容をサブクラスで定義、オーバーライドしなければならない 。 サブクラスは必ずその抽象クラスのメソッドを持っているので、まとめて簡単に扱える。 インターフェイス 宣言 こんな感じ↓
interface iVehicle { void show(); // 抽象メソッド } 特徴 interface を使って宣言する。 フィールドとメソッドを持つことができる。 コンストラクタは持たない。 フィールドは必ず初期化する。 メソッドの処理は定義しない。 メンバには何も修飾子をつけない。 何もつけなくても、フィールドには public static final, メソッドには abstract がついているのと同じことに。 つまりフィールドは絶対定数で、メソッドは抽象メソッド。 オブジェクトを作成することはできません。 変数・配列を宣言することはできる。 クラスと組み合わせて使うことになっている。 クラスと組み合わせることを インターフェイスを実装する という。 使い方 インターフェイスの実装 class <クラス名> implements <インターフェイス名> { /* hogehoge fugafuga piyopiyo */ } さて、このようなクラスを作ったら、インターフェイスのメソッドをすべて定義する という作業が必要になります。 インターフェイス型の配列は、そのインターフェイスを実装しているサブクラスのオブジェクトを指すことができます。インンターフェイスも、上で見た抽象kルアスと同じように サブクラスをまとめて扱うことができます 。
本日のTIL 今回は「やさしいJava」を読んで Java のクラスについて学んだ中で今まで意識できていなかった考え方や馴染みのなかった書き方、概念などについて書きます。
クラスの機能 カプセル化 カプセル化についてはもちろん Java を学び始める前もなるべく意識してコードを書いてきたので詳しくは書きませんが、全てのメソッドの先頭に public private とついているとわかりやすいなと思いました。 ( Ruby で private 以下が長くなって「結局これ private メソッドなの？」みたいになること、うーん、あるのか……？)
メソッドのオーバーロード Java では 同じクラスの中に、同じ名前を持つメソッドを複数定義すること ができ、これを メソッドのオーバーロード といいます。 ちなみに、コンストラクタもオーバーロードすることができます。
効果 似たような複数の処理を、1つのメソッド名を覚えて使うだけで自動的に型や個数に応じた処理が行われる。 似たような処理について同じメソッド名を利用することができる。 1つの名前が別々の働きを持つことを多様性というが、これが生まれる。 注意点 オーバーロードするメソッドは引数の型もしくは個数が異なってなければならない。 余談 Ruby にはないものですね ( そうですよね？ ) 。 これができるのはやはり静的型言語の強みなのかなと思います。 今まで JS や Ruby しか書いていなかったので、同じ名前のメソッドを同じクラス内に定義するというとびっくりしますが、考えてみればとても便利ですね。 Ruby だと、個数の違いに対応するために引数にデフォルト値を入れたり配列やハッシュを引数にしたり、引数の型で処理を分けるためにメソッドの中で調べたりすると思いますが、 Java だとその必要がなくて、一つのメソッドが無駄に長くならなくて嬉しいですね！
インスタンス変数・インスタンスメソッド オブジェクトに関連づけられているフィールドをインスタンス変数 オブジェクトに関連づけられているメソッドをインスタンスメソッド と言います。
インスタンス変数・インスタンスメソッドはオブジェクトが作成された時にアクセスできるものです。
クラス変数・クラスメソッド クラスに関連づけられているフィールドを クラス変数 、メソッドを クラスメソッド と言います。 これらはインスタンス変数とは異なり、クラス全体に関連づけられます。 クラス全体で扱うデータを格納しておくフィールド がクラス変数、 クラス変数を出力するなど、 クラス全体に関わる処理を行う のがクラスメソッドです。 クラスメソッドはオブジェクトが作成されていなくても呼び出せます。 代表的なクラスメソッドとして main() メソッドがあります。
本日のTIL 前提として。 Java 書いたことないんじゃあ！ Java どころか静的型言語をまともに書いたことがありませんでした。 今までやってきたのは JS ( 主にサーバーサイドNode.js ) と Ruby ( Rails ) でした。 しかもやってきたと言ってもたかだか一年間で、エンジニアとしてのバイトやインターンは複数の会社でやっていましたがまだまだひよっこです。 そんな私がマネーフォワードに入社するにあたり Java を書くことになって、インターン期間中は Java の勉強をしていました。
この記事を読むときは一応前提として上記のことを頭においていただければなと思います。
Java のコレクション Java には様々な種類のコレクションがあるのですが、そのうち私がこの一週間半で使ってみたコレクションについてまとめます。
配列 配列という言葉はお馴染みのものですが、Java の配列は私が知っている JS や Ruby の配列とは決定的に違うことが一つありました。 長さが変えられない ということです。
また、初期化の方法も少し馴染みのない感じでした。
// 例えばこんな感じとか int array[] = new int[5]; // こんな感じ int array[] = { 1, 2, 3, 4, 5 }; # 例えばこんな感じとか array = Array.new(5) # こんな感じ array = [1, 2, 3, 4, 5] array[] という書き方や { } で囲うのは新鮮だなあと感じました ( だからと言ってどうというわけでもないのですがw )。
本日のTIL ぶつかった問題 QuickRex というパッケージを Eclipse にインストールしてみたところ、 Eclipse で Emacs キーバインドが使えなくなってしまいました……。
慌ててパッケージをアンインストール、 Eclipse の再起動を行うも Emacs キーバインドは使えず。
宮坂さんに EclipseのClean起動 を教わって試してみるも効果なく。
こうなればやむを得まいと Eclipse の再インストール を行っても効果がなく。
Eclipse の keys 設定を見に行くと scheme は Emacs になっているし実際によく使うショートカットを検索するときちんと設定されている……。
正直、もうだめだ！と思いましたw
解決法 Eclipse の [環境設定] -> [General] -> [keys] で使いたい Emacs キーバインドを探し、 when を In windows に変更。
自分なりに解説 なぜだかわかりませんが ( タイミング的にインストールしたパッケージの影響と思われる ) ショートカットキーの多くの when が Editing Text になっていました。 Editing Text と言うといかにも正しい気がしますが、実はこれ「 全角入力の変換中 ( 変換の確定をする前で文字に下線が付いている時 ) 」のことなんです……。
つまりコードを書いている時のほとんどは Editing Textではないということですね……。なんじゃそりゃ。