ゼットコードログ

コード的な何かを書いていきます。

activerecordのモデルからカラムの設定情報を取得する

.columns というメソッドを実行するとカラムごとの定義情報が配列に入って返ってくる。

{モデルクラス名}.columns
[#<ActiveRecord::ConnectionAdapters::MySQL::Column:0x00007fcb1e348758
  @collation=nil,
  @comment=nil,
  @default=nil,
  @default_function=nil,
  @name="{カラム名}",
  @null=false,
  @sql_type_metadata=#<ActiveRecord::ConnectionAdapters::SqlTypeMetadata:0x00007fcb1e348870 @limit=8, @precision=nil, @scale=nil, @sql_type="bigint(20)", @type=:integer>,
  @table_name="{テーブル名}">,
 #<ActiveRecord::ConnectionAdapters::MySQL::Column:0x00007fcb1e348168
  @collation=nil,
  @comment="",
  @default=nil,
  @default_function=nil,
  @name="{カラム名}",
  @null=false,
  @sql_type_metadata=#<ActiveRecord::ConnectionAdapters::SqlTypeMetadata:0x00007fcb1e348410 @limit=8, @precision=nil, @scale=nil, @sql_type="bigint(20)", @type=:integer>,
  @table_name="#{テーブル名}">,

カラムの設定情報によって、表示する情報を動的に変えたいときなどに役に立つ。 自分はカラムのnull許可設定に応じてフォームの項目ごとに入力必須か任意かを出し分けるということがしたかった。 その場合は @null の部分を見るといい。

application_recordにこんな感じでメソッドを入れておくと、各modelごとにメソッドが使えるのでいい感じ。

  class << self
    def nullable_column?(name)
      column = columns.find { |c| c.name == name || c.name == "#{name}_id" }
      column.present? ? column.null.present? : true
    end
  end

kubectl コマンド一覧

kubectlの多岐にわたるコマンドのメモ書きを残すためのページ

状況確認

クラスタ内のリソースを一括で表示する

$ kubectl -n default get all

現在のアクティブなクラスタを確認する

$ kubectl config current-context

ネームスペースを確認する

$ kubectl config view | grep namespace:

ノードのリソース使用状況を見る

$ kubectl top node

ポッドのリソース使用状況を見る

$ kubectl top top

pod

ポッドのリソースを詳細を確認する

$ kubectl describe pod {pod name}

namespace

今存在するネームスペースを確認する

$ kubectl get namespaces

ネームスペースを作る

$ kubectl create namespace staging

LINEのソーシャルログインでメールアドレスを取得する

Webアプリを作っていると時々ソーシャルログインをやることがあります。 要件によってはユーザーのメールアドレスを取得することもあります。

FacebookTwitterだと、コールバックで飛んできた内容にそのままメールアドレスが含まれているのでそれを使えばいいんですがLINEだと含まれていません。 どこにあるかというと、IDトークンの中にひっそりと入っています。

Rubyだとominiauth-lineというgemがあるんですが、オリジナルだとid_tokenを取得できないのでfolkしてコードを1行追加しました。

github.com

こんな感じで調整しました。

  info do
    {
      name:        raw_info['displayName'],
      image:       raw_info['pictureUrl'],
      description: raw_info['statusMessage'],
      id_token:    access_token.params['id_token'] # これを追記
    }
  end

こうやって調整したgemを使えば、コールバック時に含まれているid_tokenを解析して、メールアドレスが取得できます。 もちろん、APIでemailを受け取れる設定にしておく必要があるのと、そもそもユーザーが了承しないとダメです。

コールバックの処理のところでこんな感じで使う。

payload = JWT.decode(id_token, your_secret_key, true, algorithm: 'HS256').first
email = payload['email']

WordPress REST API をindex.phpを指定して使用する

通常、WordPress REST APIは末尾が *.phpで終わらない。

本来のAPIのURLではこうですが

http://example.com/wp-json/wp/v2/posts

実はこれでも同じことになります。

http://example.com/index.php?rest_route=/wp/v2/posts

やんごとない理由でリバースプロキシとかで 〜*.phpを基準に制御していて扱いづらい場合などの回避策に使えますね。

API用のリクエストを担当するフロントのPHPファイルがない、ということはなんらかのルーティングをしていることになるわけですが、 やっぱりindex.phpでリクエストを受けつけて適宜APIとしての返り値を返している模様です。

WordPressのバージョンが上がる過程で変わるかもしんないのでその辺のリスクを取る取らないの判断は必要です。

WordPress REST API と XServer

WordPress REST APIhttps://ja.wp-api.org は大変便利な機能です。 やむなくWordPressを取り扱うことになった開発者からすると希望の光です。

これを使えば、WordPressの管理画面を使って記事を作成する運用を維持しつつ、ユーザーに見せる画面はWordPressではない方法で作ることができます。 例えば、PVも上がってきたから本腰を入れて途中からサイトを作り直す、みたいなときに記事のデータはそのまま使ってリニューアルするみたいなときに有効ですね。

ところでXServerのレンタルサーバーでは、このAPI機能に微妙な制限がかかっています。

REST API」に対する国外IPアドレスからの接続を制限します。

最初からの設定だと国外のリクエストののみ、アクセスできないんですね。 これに気づかず、半日くらいハマってしまいました・・・

自分の新しいサーバーが国外にあったので、APIを実行しても正しく結果が返ってきませんでした・・

設定の解除はサーバーパネルから「WordPressセキュリティ設定」を選択して 「REST API アクセス制限」をオフにすると、APIがフルオープンになります。

もちろんAPIを利用したい、かつ、利用元のサーバーが国外の場合は この設定を変えないといけないです。

それにしても国内とか国外問わずに、デフォルトはブロックするべきではないだろうか・・ 禁止、国内のみ、フルオープンくらいに3段階で選択できたらいいと思うんですけどね。

エンジニアの採用活動は新卒と中途で分けなくていい

春を迎えて、学生の採用活動も活発になってきているこの頃。 採用の端くれを担うものとして、近頃思うことがある。

ITエンジニアの採用は新卒と中途で分けなくていい。 そして少し細かくいくと、次のような感じで是非一度やってみたい。

  • 新卒と中途で採用活動を分けない
  • 応募受付は通年でやっている
  • 中途採用の場合もインターンしてよい
  • 接待みたいなサマーインターンは不要だ
  • 現在の能力よりも、一緒に働きたいかを重視をする
  • 現場の人たちのOKがすべて

新卒と中途で採用活動を分けない

特に技術的なところ、たとえば、プログラミングスキルやITリテラシー的なところでいうと、もはや新卒と中途で差はほとんどない。 「その人が今時点でどのくらいできるか」を判断材料にして決めるほうがいい。

現場の意向として、若手がほしいのか経験者がほしいのか。 そのニーズにマッチした人を採用すればいい。 ほんと、それだけのことなんだ。

新卒の子でも即戦力っぽく働ける人もいるし、逆に中途でもOJTが必要で伸び代を期待して採用するケースもありえる。 会社的にも採用フローが二本あるのは運用しづらいだろう。

まさか、新卒の子には会社へのロイヤリティの高さを期待しているなんて思っている人がいるんだろうか? 彼らは3年も経たずに辞める。

多くの予算を費やして、新卒採用向けのカリキュラムを組む必要などない。 無駄でしかない。

それよりは、新卒も中途もごちゃ混ぜにして回転率を上げることだ。 もちろん、末長く働きたい人は大歓迎だ。

応募受付は通年でやっている

春夏秋冬、いつでも歓迎したほうがいい。その人が働きたいと思ったその瞬間を大事にしたい。 機会を最大化することで、"優秀"な人も採用しやすいのではないだろうか。

常に受け入れている状態にすることで、社内でも変なキックオフミーティングとかが減らせる特典もありそうだ。

中途採用の場合もインターンしてよい

どうして、新卒だけがインターンの対象になるのか。 別に中途の人だってインターンしたっていい。

むしろ、社会生活の経験が多い人ほど、職場環境についてのこだわりもあるだろうし 面接やWEBの情報だけで入社を決めるよりは実際にしばらくのあいだ働いてみて その会社が合うか合わないかを決めるほうがよっぽどいい。

やめたくなった場合も、インターン期間中なら辞めやすい。 逆に採用した側も、実際に働いているところを見て評価した上で、 本採用OKとするのかを判断することもできるだろう。

実際には切り出しにくいこともあるかもしれないが最初に契約書として 不採用もあり得ることを合意してもらうのだ。

接待みたいなサマーインターンは不要だ

実業務を経験してもらうこと以外に何があるのか。 リアルな現場をありのままに体験してもらったほうがいいだろう。

スキルレベルが低い子が来た? 問題ない。一緒に時間を共有することが大事なんだ。 コピーだって掃除だって、仕事はある。 昼飯を一緒に食べよう。 一緒にいて場の空気を知ることが重要なんだ。

サンプルプログラムに毛が生えたようなものを作って何が楽しいんだい?

現在の能力よりも、一緒に働きたいかを重視をする

職場問題の大半は「人間関係」だ。 ITスキルが我が社のクリティカルな課題だ、なんていう会社があるだろうか。

だとすると、その人の今時点の技術力なんて二の次だ。 チームのカルチャーにマッチするかとか、既存のメンバーが今以上に働きやすくなるかが全てだ。

そうして高い士気を維持できるのなら、技術力なんてあとからでもどのようにでもなる。

現場の人たちのOKがすべて

1次面接 > 役員面接 > 社長面接 みたいな順番で進んでいくのが大半だろうけど 一緒に働く人たちの意見を最大限に取り入れたほうがいい。 その代わり、現場のメンバー全員がその人の採用に合意することだ。

もし、どうしても、社長面接をしたいのなら、順番を逆にしてみてはどうだろうか。 もちろん、社長面接の前に現場メンバーの判断で一定のフィルタリングをしてみてもいいだろう。

それも、上記の通年かつ中途もOKインターンを実践したあとなら ほぼ現場の判断に狂いはないはずだ。

Circle CIのJobで任意の環境変数を設定するには

Circle CI(version 2)でJobを実行するときに、環境変数を設定するには BASH_ENV変数に追加するとよい。 「BASH_ENVの中」に>>で追加するのがミソ。

たとえば、gitのリポジトリで最新のタグ名をTAG_NAMEという環境変数として定義したい場合はこんな感じ。

echo 'export TAG_NAME=`git describe --tags`' >> $BASH_ENV

そうすると、jobs実行時のコマンドで普通に環境変数として参照できる。

    steps:
      - checkout
      - run: gcloud container builds submit --config=cloudbuild.yaml --substitutions REVISION_ID=$TAG_NAME .

最初、BASH_ENVというのはあくまでも例のひとつで、そこに自分の都合に合わせて環境変数を定義する感じかと思っていたらそんなことはなかった。