ひよっこエンジニアの雑多な日記

なんとかWeb系のエンジニアをやっています。

2018年の目標(野望)

年が明けて早3日ですが、あけましておめでとうございます。
今年もよろしくおねがいいたします!!

年も明けたということで今年の目標を書いて行こうかなと!!

今年の目標

  1. 個人的にサービスを10個作ってリリースする
  2. 使える技術の幅を広げる
  3. 現在の会社で収益の柱になるサービスを立ち上げる
  4. 自分のブランディングを考える・土台を築き始める
  5. 人との繋がりを広げる
  6. 副収入を今の3~5倍にあげる

大きな項目としては上記の5つです!
一つずつ紐解いていきます!

個人的にサービスを10個作ってリリースする

去年はサービス作ろうと友人なんかとやってみたりしましたが、結局個人的なもので形になったものは0だったので今年こそはということで!
10個というのはスピード感を持ってものを作るという意味合いも込めてです!(あとは期間を短くすることで変に大きなものを作ろうとなるのが防げるかなと)
世の中に公開して使ってもらうためにはどうすればいいかという観点も磨きたいのでマーケティング周りも学習していきたいです。

使える技術の幅を広げる

これはエンジニアとして手を出せる領域を広げていきたいという意気込みですね!
今はRailsとVue.jsでアプリケーションを作ったり、VPSAWSを使ってアプリを公開するというWebアプリケーションを作るための最低限の基礎を持っているつもりですが、これだけだとこれからの世の中的に弱いかなあと思ったりしています。
第4次産業革命と言われている昨今で活躍するためにはWeb技術+αが求められるのかなと感じているのでの部分をつけたいと思います!
データ解析あたりが世の中のニーズともマッチしていそうな気がするのでその辺りに足を伸ばそうかと!
RailsAWS、フロントエンドの技術もしっかり深めていきたい!

現在の会社で収益の柱になるサービスを立ち上げる

現在所属している会社が新しい収益の柱を作れるように開発側からサービス企画を促していきたいと思います。
去年は既存サービスの改善提案などは行ってきていたのですが、新規で何かを始めるということはできていませんでした。
一応スタートアップといわれる部類の会社なのでスピード感を持って構築・改善をして行くことを目標にサービス立ち上げを先頭に立って行います!
2018年は新規で教育 × テクノロジーを促進していけるようなサービスを構築していきたい思います。

自分のブランディングを考える・土台を築き始める

これは自分が何を成し遂げたくて、何ができる人間なのかを自分の人生を振り返って構築していきたいと考えているので目標としました。
自分というブランドを確立して行くためには今の年齢から思考、行動をして行く必要があると最近人と話して思いました。
今後は何かしらの形で独立していきたいと考えているので、自分のブランドを作ることが近々では重要な事項だと考えています。
もしかしたら傲慢なことかもしれませんが、将来的に自分に関わってくれた人たちを幸せにできることを行いたいを考えています。
自分自身の力を大きくすることで、より世の中に働きかけやすくなると考えているので自分のブランドを構築することはとても重要だと思います。
2018年はこのブランド構築の土台を作っていきたいと思います!そのために自己分析や様々な知識を身につけていきたいです!

人との繋がりを広げる

これは結構課題感に感じているものの、苦手意識から今まで全然できていなかった事項ですね。。。 ブランディングのところで自分のやりたいことを明確にして、何かを起こしていくとなったら間違いなく人との繋がりが重要になると感じています。。。
その時になってから作るのもありかもしれませんが、やはり早めに動くにこしたことはないと思いますし、人との繋がりを作る訓練もしておいた方がいいと思いますし。。。
あとはエンジニアとして見識を広めるために色々なエンジニアに繋がることも大事だとも思っています。。。
ということで去年までは消極的だった勉強会やコミュニティ、イベント参加などを最低月2くらいのペースでやっていきたいと思います!

副収入を今の3~5倍にあげる

去年からちらほら個人的にお仕事の話をもらって副業するようになったのですが、まだまだ収入としてはお小遣いレベルなのでこれを本業がなくてもなんとかなっちゃうよというレベルまで持っていきたいと思います!
副業は開発を請け負ったりするだけでなく、もっとそれ以外の領域にも手を出してみたいなと!
何がともあれ先立つものは必要ですしね!笑
副業だけと言わず収入が上がることがあれば積極的に挑戦してみたいと思います!

最後に

なんか書いてみて思ったけど、今年は結構欲張っていく必要がありそうだなーと思いました。笑
ただ2018年は自分が今後どう生きていくかを決める第一歩となる年だと考えているので、貪欲に活動していきたいと思います!
これを全部達成できたらかなりの成長を遂げられそうなので頑張ろう!やってやれないことはない!

今年1年の振り返り

とりあえず年の瀬なので2017年の棚卸しをして2018年を気持ち新たにむかえようかなということで今年を振りかえります

年始に書いた目標振り返り

2017年の年始に以下の目標を掲げていました

  • コミュニケーション
  • 興味関心
  • 意思決定

目標設定が定量的に測れなさすぎて振り返りが難しいのですが。。。笑
個人的にはコミュニケーションは少し改善したかなあ
去年の正月に読んだ電子書籍が僕の中でバイブルとなりました

一年前と比べて人と話してる時に興味関心を持つようにはなったかなきっと

月ごとに振り返ってみる

目標振り返りはすごく微妙な感じだったので月ごとに振り返っていきます(汗

1月

1月はちょっとした受託案件でGitHub APIと決済APIを使ったシステム開発を行った記憶
このあたりからオブジェクト指向を意識してプログラム書くようになった気がする

2月

2月はチームマネジメント頑張ろうと思って色々試してみようという感じになっていたなあ
結果的にうまい感じにマネジメントはできていなかった気がするけど、コミュニケーションが結局のところ大事だねというのがわかった記憶
Twitter振り返ってみるとこのあたりから現状に疑問を抱き始めてるっぽい
あと2月はRubyのイベントで登壇したなあ。懐かしい

プレゼンは作って録音しながら練習することで客観的に自分のプレゼンが見れるのでおすすめ
あと自分はスライドの資料に喋ることを一字一句漏らさず書くことでうまい感じにプレゼンができる人種なのかもしれないという気づきもあった
資料作りなんかはなかなかストレスフルだったけど成長できた気はする

3月

なんか給料上がった月だったらしい
あとパーマかけた気がする
あと彼女できた

4月

年度明け早々扁桃腺炎のやばいやつにかかって入院した
喉の痛みが微妙な時は内科ではなく耳鼻咽頭科へどうぞ
あとはこのあたりから仮想通貨がすごいことになったなあ
入院しながらドキドキした記憶

5月

XRPXEMを握りしめることを決意
5月あたりから会社のシステム再構築を本格的に着手しはじめたな
この開発は自分の開発力を結構向上させる開発で自信つけることができたなあ
あとは社内調整に失敗してWebサイト更改に失敗
外注費50万弱をドブに捨ててしまいました。。。

6月

長野に旅行へ
上高地いいところでした
6月でも涼しくて過ごしやすかった
あと旅館がめっちゃよかった

副業として友達がやっている事業のweb周りをお手伝いすることになった

7月

データ移行スクリプトを作るのにくるしんだ記憶
バルクインサートの速さに感動した
このブログの月間アクセスが1000になった笑

8月

開発してたシステムをリリース
1週間ぐらいバグ報告多すぎて死ぬかと思った(テストめっちゃ大事)
あとはPS4買った
後輩と恒例のコミケに行くという儀式を行った

元受講生が新事業やるって行っていたのでインフラを用意する副業やった
めっちゃ安請負してしまった

9月

北海道に旅に出た
めっちゃ楽しかった(小並感)
転職ドラフトに出場したっけ
4件ぐらい指名がきたし、自分の相場感もなんとなくわかった
このあたりから自分の価値をそこそこ気にするようになった気がするな

10月

セルフブランディングとか言い始めた時期
友達とサービス作ろうぜといってまた頓挫した
何がダメなんだろうなあ。。。時間が投資できてない?熱し易く冷め易い?
副業の方で結構真面目に決済APIを使った実装を行うようになった

相当やばい便秘にかかって2週間お通じがこなかった。。。
人生初イチジク浣腸を使った
まじで速攻でて浣腸すごいってなった

11月

彼女と喧嘩?した
価値観のズレとかそういうのは違う人間である以上しょうがないからきちんと話し合って行くことが大事だと思った
ストレスがある時は紙とかに書き出すと何にイライラしてるのか明確になったり、気づいてない事象に気付けたりするのでおすすめ

あとフリーランスに興味持ち始めた

12月

続・仮想通貨がやばいことに
クリスマスをリア充っぽく過ごせた

自分のブランドつくっていくことを決意

ざっくり書いてみたけど、意外と毎月何かあったな
来年はもっと充実した年にできるようにしよう

とりあえず長くなったから来年の目標は明日書こう

【Rails】Modelでlink_to使いたいときにincludeするもの

概要

URL生成してaタグを載せたようなメッセージをModelで作りたくなり、何をincludeすれば良いのかわからんかったのでメモ
(結局link_to使わなかったけど)

対応内容

include ActionView::Helpers::UrlHelper

こやつをincludeすればモデルでもlink_to使えるようになります(使わんかったけど)

その他

とりあえず記事書かないといけない気がした

【CentOS7】firewallで特定のポートに特定のホストからのみアクセスさせる設定

気がついたら最終更新から1週間以上立っていました(驚愕)
先週北海道に旅だったり、無駄に副業に忙しかったり、PS4買ったりしたからしょうがない!!。。。。しょうがないんや(反省)

さて一週間記事更新してなかったから今回はとりあえず更新したいという思いもあり、軽めの記事。

概要

冗長構成を組んでいるインフラ環境で特定のミドルウェアへのアクセスはアプリケーションサーバーからのみのものを受け付けたいとなった時にfirewallで設定してやるということを行いました。
ちょっとコマンド長くて、またやるとき忘れそうなんで書き留めとく感じ。

今回は7777ポートに特定のIPアドレスからのみアクセスを受け付けたかったという想定。

方法

まずは7777へのアクセスさせていた設定を消しておく

$ firewall-cmd --permanent --remove-port=7777/tcp

特定のIPアドレスを通す設定を行う

 $ firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="IPアドレス" port protocol="tcp" port="7777" accept"

firewallをリロード

$ firewall-cmd --reload

設定確認

$ firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: dhcpv6-client mysql ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  sourceports: 
  icmp-blocks: 
  rich rules: 
        rule family="ipv4" source address="IPアドレス" port port="7777" protocol="tcp" accept

rich rulesが設定されていればOK
複数ホストを設定したい場合はIPアドレスを変えてrich ruleの設定コマンドをもう一度叩けばOK

最後に

そういやCodeDeployの書きかけの記事がある
早く書いて世に出さないと(やり方忘れかけ)

【Nginx】ELBを通して認証用tokenをリクエストにのせる

一週間ぶりくらいの更新。週1では更新していくように勤めたい(手抜き記事だったとしても)

今回は完全に手抜き記事かつ備忘録

概要

今回Railsで簡単なToken認証をできるようにして無駄にAPIを叩かれないように対処したのですがEC2一台構成の環境では認証をパスすることができたものの、ELBを使って冗長な構成になっている環境ではうまく実行されなかった。

実行したかったのはAPIにリクエストをかけるような感じのcurl

curl https://example.com/api/v1/hoge -H 'Authorization: Token token' -X PUT

ELBを通してリクエストをかけるとAuthorizationの情報が抜け落ちてしまって認証が通らなくなっていた。

対応内容

NginxでリクエストヘッダーにAuthorizationの情報を乗せるようにすればうまくいきました。 設定は以下の感じ(locationのティレクティブに設定する感じ)

proxy_set_header Authorization $http_authorization;

一行入れれば解決でした。 $http_authorizationにリクエストに乗せたAuthorizationの情報が入っているのでそれをheaderに設定すればいけるって感じっぽいですね!

さいごに

最近開発のモチベはあるものの、その他雑務のせいでモチベが削られるという微妙な状態になっている…

【Rails】多対多のアソシエーションに別名をつけたいあなたに

最近涼しくなってきましたねー…と思ったら次の日は暑かったりで体を壊しそうになります。(2週間前にすでに壊した)

今日は最近コードをレビューする機会があって、多対多のアソシエーションをうまいこと設定できていなくて指摘したかったものの、どうやって設定するか微妙に調べることになったのでもう忘れないようにブログにしておこうと思った次第。

想定

会員がブログを投稿できる機能があって、他の人が書いたブログをお気に入りできるみたいな機能を作る想定で
以下のような感じのテーブル構成をイメージ

f:id:kimuraysp:20170905230916p:plain

とりあえずわかりやすいところから

各モデルのアソシエーションのとりあえずわかりやすいところから記載

# user.rb
class User < ApplicationRecord
  has_many :blogs
  has_many :favorites
end

# blog.rb
class Blog < ApplicationRecord
  belongs_to :user
  has_many :favorites
  has_many :users, through: :favorites
end

# favorite.rb
class Favorite < ApplicationRecord
  belongs_to :user
  belongs_to :blog
end

多対多の関連がある時はthroughオプションをつけてあげると中間テーブルを経由して関連先のモデルを取得できるようになります。
throughをつけないと中間テーブルの先のレコードを取得するのが一手間必要になり微妙なので設定するのが吉です。

# blogからuserを取得する例

# through設定した場合
blog.users

# through設定しない場合
 blog.favorites.map { |favorite| favorite.user } 

設定しない場合の取得方法はあくまで例ですが何かしら下処理が必要になってしまいます…

で、それならuserにもthroughを設定してblogを取得できるようにしたらいーじゃん!ってなりますよね。
ただ今回はblogとuserにはすでにアソシエーションが存在します。
こんな時は別名をつけてあげれば良いのです!

多対多で中間テーブルの先のモデルとアソシエーションする

こんな感じで実現できます。

# user.rb
class User < ApplicationRecord
  has_many :blogs
  has_many :favorites
  has_many :favorite_blogs, through: :favorites, source: :blog
end

sourceオプションを設定することでuser.favorite_blogsでuserがお気に入りしたブログを一気に取得することができます。

Railsは外部キーの名前などでアソシエーションの判断をしていますが、アソシエーションの名前を外部キーの名前から外れた名前にする場合はそれをオプションをつけて教えてあげる必要があります。
sourceオプションがthroughする際にアクセスすべきモデルを教えるオプションとなります。
source: :blogとすることでfavorite.rbで設定しているbelongs_to :blogを参照するようになり、favorite_blogsというblog_idに紐づくという判断ができない名前であってもblog.rbに辿り着けるようになるといった感じです!(説明わかりづらい説)

なのでこのようなアソシエーションを作成したいとなった場合はsourceオプションを活用しましょう!

ちなみに1対多で違った名前を付ける際の対処

たとえば何らかの理由でhas_many :blogshas_many :write_blogsにしなければいけなくなった際は

class User
  has_many :write_blogs, class_name: 'Blog', foreign_key: :user_id
  # 以下省略
end

みたいな感じで、このアソシエーションはどこのモデルとのアソシエーションなのか、どの外部キーを用いるのかをオプションで明示する必要があります。

最後に

NEW GAMEを見てるとみんな才能があって素敵に思う。
ねねっちを弊社にスカウトしたいのだけどどこで出会えるのかしら

Rubyのヒアドキュメントで改行文字が認識されなくて戸惑った話

できるだけ気づきがあったらブログを更新しようと努力したいきむらです。
今回の記事はめっちゃ初歩的かつ、なんならヒアドキュメント関係ない記事です…笑

概要

SlackBotに通知を投げさせるような処理を作っていて文面をヒアドキュメントで作成しようとしていました。
配列に値を格納してヒアドキュメント上でjoinを使って改行文字(\n)で連結表示させようとしていた時のことです。 joinの引数にもたせた改行文字がうんともすんともいわないホラー的な現象がおきていました。

書いていたプログラムは下のような感じです。

str_ary = ['hoge', 'fuga', 'piyo']

<<~EOS
  文字列一覧です
  #{str_ary.join('\n')}
EOS

これで

文字列一覧です
hoge
fuga
piyo

という結果を期待していたのですが実際に帰ってきた結果は以下

文字列一覧です
hoge\nfuga\npiyo

これは無情ですね。悲しみしかありません。
ヒアドキュメント上だと改行文字が認識されないのかな?とか思ってしまって無駄に調べ物して時間を潰してしまいました。

原因

調べたと言うより途中で気づいてしまいました。真犯人に。

結果的に言うとヒアドキュメントは1mmも悪いことはしていませんでした…

何が原因だったのかと言うと

str_ary.join('\n')

こいつでした。セパレート文字の指定の仕方が悪かったのです。

解決法

犯人であるセパレート文字の指定の方法を

str_ary.join("\n")

シングルクォーテーションからダブルクォーテーションに変更しました。
すると、なんということでしょう、期待した結果が得られるではありませんか。

シングルクォーテーションだと式展開ができないって言うのは知っていたのですが特殊文字エスケープされてしまって効かなくなるとは知りませんでした。

つまりヒアドキュメントは何も悪くない。文字列の指定の仕方が悪かったんだ。
めっちゃ細いし初歩的なことなんですが、僕みたいに迷える子羊となってしまう人が現れるかもしれないのでメモメモ。

さいごに

最近仕事をこなしてもこなしても増えるんだよなあ
自分、分裂できないかなあ