今年1年の振り返り
とりあえず年の瀬なので2017年の棚卸しをして2018年を気持ち新たにむかえようかなということで今年を振りかえります
年始に書いた目標振り返り
2017年の年始に以下の目標を掲げていました
- コミュニケーション
- 興味関心
- 意思決定
目標設定が定量的に測れなさすぎて振り返りが難しいのですが。。。笑
個人的にはコミュニケーションは少し改善したかなあ
去年の正月に読んだ電子書籍が僕の中でバイブルとなりました
一年前と比べて人と話してる時に興味関心を持つようにはなったかなきっと
月ごとに振り返ってみる
目標振り返りはすごく微妙な感じだったので月ごとに振り返っていきます(汗
1月
1月はちょっとした受託案件でGitHub APIと決済APIを使ったシステム開発を行った記憶
このあたりからオブジェクト指向を意識してプログラム書くようになった気がする
2月
2月はチームマネジメント頑張ろうと思って色々試してみようという感じになっていたなあ
結果的にうまい感じにマネジメントはできていなかった気がするけど、コミュニケーションが結局のところ大事だねというのがわかった記憶
Twitter振り返ってみるとこのあたりから現状に疑問を抱き始めてるっぽい
あと2月はRubyのイベントで登壇したなあ。懐かしい
プレゼンは作って録音しながら練習することで客観的に自分のプレゼンが見れるのでおすすめ
あと自分はスライドの資料に喋ることを一字一句漏らさず書くことでうまい感じにプレゼンができる人種なのかもしれないという気づきもあった
資料作りなんかはなかなかストレスフルだったけど成長できた気はする
3月
なんか給料上がった月だったらしい
あとパーマかけた気がする
あと彼女できた
4月
年度明け早々扁桃腺炎のやばいやつにかかって入院した
喉の痛みが微妙な時は内科ではなく耳鼻咽頭科へどうぞ
あとはこのあたりから仮想通貨がすごいことになったなあ
入院しながらドキドキした記憶
5月
XRPとXEMを握りしめることを決意
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をリクエストにのせる
一週間ぶりくらいの更新。週１では更新していくように勤めたい(手抜き記事だったとしても)
今回は完全に手抜き記事かつ備忘録
概要
今回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週間前にすでに壊した)
今日は最近コードをレビューする機会があって、多対多のアソシエーションをうまいこと設定できていなくて指摘したかったものの、どうやって設定するか微妙に調べることになったのでもう忘れないようにブログにしておこうと思った次第。
想定
会員がブログを投稿できる機能があって、他の人が書いたブログをお気に入りできるみたいな機能を作る想定で
以下のような感じのテーブル構成をイメージ
とりあえずわかりやすいところから
各モデルのアソシエーションのとりあえずわかりやすいところから記載
# 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 :blogsをhas_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")
シングルクォーテーションからダブルクォーテーションに変更しました。
すると、なんということでしょう、期待した結果が得られるではありませんか。
シングルクォーテーションだと式展開ができないって言うのは知っていたのですが特殊文字もエスケープされてしまって効かなくなるとは知りませんでした。
つまりヒアドキュメントは何も悪くない。文字列の指定の仕方が悪かったんだ。
めっちゃ細いし初歩的なことなんですが、僕みたいに迷える子羊となってしまう人が現れるかもしれないのでメモメモ。
さいごに
最近仕事をこなしてもこなしても増えるんだよなあ
自分、分裂できないかなあ
AWS CodeDeployを使ってGitHubにあげているリポジトリをデプロイする
AWS CodeDeployを使ってみたら思いの外、簡単に設定できてデプロイができたので覚書きです！
そういえばAWSには結構お世話になってるけど記事を書くのは初めてという事実…
CodeDeployとは
AWS CodeDeployは読んで字のごとくEC2インスタンスなどにコードをデプロイしてくれるサービスです。
デプロイ対象のEC2にエージェントをインストールする
CodeDeployを利用するためにはCodeDeployのエージェントをEC2インスタンスにインストールしておく必要があります。
エージェントのインストールにはaws-cliでS3からエージェントをダウンロードする必要があるのでEC2にS3のread権限のロールを設定してあげる必要があります。
EC2にロールを設定する
まずはIAMにアクセスします。
https://console.aws.amazon.com/iam
ロール＞新しいロールの作成でロールの作成を行う。
作成するロールは以下
| ロールタイプ | ポリシー |
|---|---|
| Amazon EC2 | AmazonS3ReadOnlyAccess |
作成したロールをデプロイ対象のEC2に設定します。
CodeDeployのエージェントをインストールする
EC2にロールを設定後、EC2にSSHログインをします。
以下コマンドを実行していきCodeDeployのエージェントをインストールします。
$ sudo yum install aws-cli $ aws s3 cp s3://aws-codedeploy-ap-northeast-1/latest/install . --region ap-northeast-1 $ chmod +x ./install $ sudo ./install auto
エージェントのインストールはこれで完了です！！
デプロイするアプリケーションにappspec.ymlを作成
CodeDeployでどのようにデプロイを実行するかを設定するファイルappspec.ymlをデプロイするアプリケーションのプロジェクトルートに配置します。
今回はAmazonLinuxを想定しています。
version: 0.0
os: linux
files:
- source: /
destination: /var/www/application
上記の設定はアプリケーションのファイル全体をEC2の/var/wwwapplication配下にデプロイするという設定を行っています。
設定内容は今回は省略しますが、以下の記事がわかりやすかったです。
appspec.ymlを作成したらコミットしてGitHubにプッシュしておきます。
(CodeDeployはGitHubのデフォルトブランチをデプロイするのでプッシュしたブランチがデフォルトブランチではない場合はマージしておきます。)
CodeDeployを使ってデプロイを実行する
いよいよCodeDeployを利用してデプロイしていきます。
CodeDeploy用のロールを作成する
実行する前にCodeDeployのアプリケーションを作成するためにはCodeDeployのロールが必要なので再びIAMのダッシュボードにアクセスします。
作成するロールは以下になります。
| ロールタイプ | ポリシー |
|---|---|
| AWS CodeDeploy | AWSCodeDeployRole |
アプリケーションを作成する
AWSのダッシュボードからCodeDeployにアクセスします。
初めてCodeDeployを利用する際は以下のような画面になるので今すぐ始めるをクリックする。
チュートリアルをやるか問われますが実施しなくても良いのでカスタムデプロイを選択してウォークスルーのスキップをクリックする。
ウォークスルーをスキップするとアプリケーションの作成画面に遷移するので、以下の設定を行う。
| 項目 | 設定内容 |
|---|---|
| アプリケーション名 | 任意 |
| デプロイグループ名 | 任意 |
| デプロイタイプ | インプレースデプロイ |
| 環境設定 | Amazon EC2インスタンス > デプロイしたいインスタンス |
| デプロイ設定 | CodeDeployDefault.OneAtATime |
| サービスロール | CodeDeploy用に作成したロール |
デプロイを実行する
CodeDeployダッシュボードから先ほど作成したアプリケーションのリンクにアクセスします。
デプロイグループを選択して、新しいリビジョンのデプロイをクリックします。
画面遷移したら以下の設定を行います。
| 項目 | 設定内容 |
|---|---|
| リポジトリタイプ | アプリケーションはGitHubに格納されています |
| デプロイメントの説明 | 任意 |
| GitHubアカウント | GitHubの認証を行います |
| リポジトリ名 | GitHubのリポジトリ名(アカウント名/リポジトリ名の形式で) |
| コミットID | デプロイしたいコミットID(省略形のコミットIDではなくフルの方で) |
その他の設定は任意で行いデプロイボタンをクリックします。
するとデプロイが開始され指定したEC2へデプロイが実行されます！
最後に
設定する内容はちょいちょいありますが設定さえ行ってしまえば簡単にデプロイを実行することができるようになります！
さらにGitHubの設定をもう少し行うことでデフォルトブランチに変更が加わったのを検知して自動でデプロイを起動するといったことも可能です！(次の記事はそれかこうかな…笑)
いやー、AWSは本当に便利。設定するだけでなんでもできちゃうんじゃないかな。(ただし財力が必要)
