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アプリを作っていると時々ソーシャルログインをやることがあります。 要件によってはユーザーのメールアドレスを取得することもあります。
FacebookやTwitterだと、コールバックで飛んできた内容にそのままメールアドレスが含まれているのでそれを使えばいいんですがLINEだと含まれていません。 どこにあるかというと、IDトークンの中にひっそりと入っています。
Rubyだとominiauth-lineというgemがあるんですが、オリジナルだとid_tokenを取得できないのでfolkしてコードを1行追加しました。
こんな感じで調整しました。
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機能に微妙な制限がかかっています。
最初からの設定だと国外のリクエストののみ、アクセスできないんですね。 これに気づかず、半日くらいハマってしまいました・・・
自分の新しいサーバーが国外にあったので、APIを実行しても正しく結果が返ってきませんでした・・
設定の解除はサーバーパネルから「WordPressセキュリティ設定」を選択して 「REST API アクセス制限」をオフにすると、APIがフルオープンになります。
もちろんAPIを利用したい、かつ、利用元のサーバーが国外の場合は この設定を変えないといけないです。
それにしても国内とか国外問わずに、デフォルトはブロックするべきではないだろうか・・ 禁止、国内のみ、フルオープンくらいに3段階で選択できたらいいと思うんですけどね。
エンジニアの採用活動は新卒と中途で分けなくていい
春を迎えて、学生の採用活動も活発になってきているこの頃。 採用の端くれを担うものとして、近頃思うことがある。
ITエンジニアの採用は新卒と中途で分けなくていい。 そして少し細かくいくと、次のような感じで是非一度やってみたい。
- 新卒と中途で採用活動を分けない
- 応募受付は通年でやっている
- 中途採用の場合もインターンしてよい
- 接待みたいなサマーインターンは不要だ
- 現在の能力よりも、一緒に働きたいかを重視をする
- 現場の人たちのOKがすべて
新卒と中途で採用活動を分けない
特に技術的なところ、たとえば、プログラミングスキルやITリテラシー的なところでいうと、もはや新卒と中途で差はほとんどない。 「その人が今時点でどのくらいできるか」を判断材料にして決めるほうがいい。
現場の意向として、若手がほしいのか経験者がほしいのか。 そのニーズにマッチした人を採用すればいい。 ほんと、それだけのことなんだ。
新卒の子でも即戦力っぽく働ける人もいるし、逆に中途でもOJTが必要で伸び代を期待して採用するケースもありえる。 会社的にも採用フローが二本あるのは運用しづらいだろう。
まさか、新卒の子には会社へのロイヤリティの高さを期待しているなんて思っている人がいるんだろうか? 彼らは3年も経たずに辞める。
多くの予算を費やして、新卒採用向けのカリキュラムを組む必要などない。 無駄でしかない。
それよりは、新卒も中途もごちゃ混ぜにして回転率を上げることだ。 もちろん、末長く働きたい人は大歓迎だ。
応募受付は通年でやっている
春夏秋冬、いつでも歓迎したほうがいい。その人が働きたいと思ったその瞬間を大事にしたい。 機会を最大化することで、"優秀"な人も採用しやすいのではないだろうか。
常に受け入れている状態にすることで、社内でも変なキックオフミーティングとかが減らせる特典もありそうだ。
中途採用の場合もインターンしてよい
どうして、新卒だけがインターンの対象になるのか。 別に中途の人だってインターンしたっていい。
むしろ、社会生活の経験が多い人ほど、職場環境についてのこだわりもあるだろうし 面接やWEBの情報だけで入社を決めるよりは実際にしばらくのあいだ働いてみて その会社が合うか合わないかを決めるほうがよっぽどいい。
やめたくなった場合も、インターン期間中なら辞めやすい。 逆に採用した側も、実際に働いているところを見て評価した上で、 本採用OKとするのかを判断することもできるだろう。
実際には切り出しにくいこともあるかもしれないが最初に契約書として 不採用もあり得ることを合意してもらうのだ。
接待みたいなサマーインターンは不要だ
実業務を経験してもらうこと以外に何があるのか。 リアルな現場をありのままに体験してもらったほうがいいだろう。
スキルレベルが低い子が来た? 問題ない。一緒に時間を共有することが大事なんだ。 コピーだって掃除だって、仕事はある。 昼飯を一緒に食べよう。 一緒にいて場の空気を知ることが重要なんだ。
サンプルプログラムに毛が生えたようなものを作って何が楽しいんだい?
現在の能力よりも、一緒に働きたいかを重視をする
職場問題の大半は「人間関係」だ。 ITスキルが我が社のクリティカルな課題だ、なんていう会社があるだろうか。
だとすると、その人の今時点の技術力なんて二の次だ。 チームのカルチャーにマッチするかとか、既存のメンバーが今以上に働きやすくなるかが全てだ。
そうして高い士気を維持できるのなら、技術力なんてあとからでもどのようにでもなる。
現場の人たちのOKがすべて
1次面接 > 役員面接 > 社長面接 みたいな順番で進んでいくのが大半だろうけど 一緒に働く人たちの意見を最大限に取り入れたほうがいい。 その代わり、現場のメンバー全員がその人の採用に合意することだ。
もし、どうしても、社長面接をしたいのなら、順番を逆にしてみてはどうだろうか。 もちろん、社長面接の前に現場メンバーの判断で一定のフィルタリングをしてみてもいいだろう。