WordPressでテンプレートからショートコードの引数を変数で実行する
なんだかわかりづらいタイトルになってしまったが、ハマっていたことがあったので備忘録として残す。
やりたかったこと
- カスタムフィールドで設定した緯度経度の情報から、各記事にGoogleMapを追加したい
- 特定のカテゴリーの全ての記事にGoogleMapを入れたい為、テンプレートファイルに地図表示処理を書きたい
対策
functions.phpにGoogleMap出力の関数を書き、テンプレートファイルからカスタムフィールドの緯度経度を引数として呼び出すことを検討。
ただ、Google Mapの埋め込みコードって意外と面倒だったりする。エンジニア失格なのかもだけど。
そこで今回はSimple Mapsを使うことに。
これを使うことで、ショートコードのみでGoogle Mapを呼び出すことができる。
こんな感じ。
[map lat="37.77493" lng="-122.41942"]
これでカスタムフィールドの値をlat,lngに入れればOK。
ハマったこと
下記コードでGoogle Mapが出力されない！
<?php
// カスタムフィールドの緯度経度を変数に格納
$lat = post_custom("lat");
$long = post_custom("long");
// 変数を引数にしてSimpleMapsのショートコードを実行
echo do_shortcode('[map lat="$lat" lng="$long"]');
?>
うーむ、なぜだろうと小一時間。むしろ細切れの時間でやっていた案件なので悩むこと数日。 超簡単なミスをしていた。
正解はこれ。
<?php
$lat = post_custom("lat");
$long = post_custom("long");
echo do_shortcode("[map lat=\"$lat\" lng=\"$long\"]");
?>
そう、''でショートコードを囲んでいたので変数展開がされなかった。
エスケープしとかないとね。
ちなみに今回、「Rails側のCGMで作成されたデータをWordPressにDB連携し、記事化する」という要件を設計した。
マスターであるRails側のDBを日次バッチ処理でWP側に連携し、そこから各項目をカスタムフィールドに格納し、テンプレートで記事として展開するということをしている。
少し冗長な気はするが、昔COBOLで生保システムをつくっていたときのオンラインホストの連携処理からヒントを得た。
経験が役にたってよかった。
Fintechのスタートアップイベントに参加してきた
Fintechのイベントに参加してきた。
Fintechスタートアップ最新トレンド2016 on everevo
アメリカやロンドン、イスラエル、またアフリカなどのFintech事情や三大銀行の話などを聞くことができた。 中でもいくつか印象的だった話を自分の意見も交え紹介する。
なぜ今Fintechなのか
今までもシステム会社が金融機関に向けて新しいシステムを提案したり、金融機関が独自システムを作ったり、他業種が銀行業を始めるなど金融×ITの切り口での話は多くあった。
そもそもFintechという言葉の定義にもよるのだが、金融機関×システム会社では生み出せないような価値をスタートアップが提供できるようになってきた為、今盛り上がっているといえる。
※皮肉っぽくいえば欧米で流行っているからともいえる。
では、なぜスタートアップがFintechで価値を生み出せるようになったのか。
大きく3点あると考えている。
参入障壁が下がった
やはりこれが一番大きい。
カンファレンスの中でも話されていたが、15年前ほどにも金融×ITが盛り上がった。
そして他業種の例えばソニーがソニー銀行に参入するなど、他業種での大手プレイヤーがその莫大な資本を持って金融業界に参入していった。
当時は参入障壁が高かったのだ。
今は時代が変わった。
システム開発費用も下がり開発機関も短くなった。
もちろん本丸である預金・融資といったところは今でも難しいが、周辺の会計、口座管理などはSaasによるFintechスタートアップが台頭してきており、金融機関も当然無視できなくなっている。
マネーフォワードとみずほ銀行が連携 | 株式会社マネーフォワード
あとはベンチャーへの投資環境が変わったことも影響を及ぼしている。
資本金が大してなくても今はエンジェル投資家から資金調達でき、特にアーリーステージの調達も増えている。
スマホやIoTによる新しいユーザー体験が生まれた
今までもガラケーへの対応など、新しいユーザー体験に金融機関は一応対応してきた。
それでも、スマホアプリや他のIoT機器を使うことで今までと全く異なるサービスが可能となり、このスピード感に追いつけていない部分が金融機関にはある。
そしてスマホアプリはリリースの障壁が低く、小さな企業でも例えば家計簿アプリをリリースし一気に流行らせることができる。
特にスマホのような日常で接点が多いデバイスだと、1画面目に置かれるようなアプリとユーザーの接触回数は非常に多く、金融機関がこれと提携するだけの価値があるのだ。
どうしても特定の金融機関が出しているアプリでは、なかなか多く使われることが無い為、ここは外部の力を借りるのがベストという判断になってきているようだ。
ブロックチェーンの躍進
ブロックチェーンがなんたるかはここらへんの記事を見ておくとわかりやすい。
大々的にブロックチェーンによるソリューションをSIerに依頼しても、なかなか革新的なものは生まれないだろう。
大手SIerは旧来の技術、開発手法を踏襲して新規サービスを作ることはできるが、どうしてもそもそもの金融業界の価値観を変えてしまうようなことには手を出しづらい。
リスクも当然ある。
いやらしい言い方をするとここはスタートアップにリスクを取ってもらいましょうということだ。
まとめ
つまり、今は障壁も低いし投資環境もあるし新しい技術に金融機関もついていけていないからチャンスだよーということ。
とはいえ規制うんぬんもある為、まずは預金→投資となるようなもの（この話何十年してるんだ）や会計や口座管理などが中心になってくるんじゃないかなと思う。
個人的にはコールセンターやヘルプを機械で代替していくなど、ユーザーサポート周りはけっこう可能性あるとは思う。
あとこういったイベントに行くたびに、スタートアップにつばをつけておきたい証券会社の営業員がたくさんくる。
頑張っているのはわかるけど、こういった営業員を何か自動化できる仕組みとかつくってくれませんかね。
ActiveHashで静的データの格納がべんりべんり！
開発をしていると固定のデータ値を持たせたいことがよくある。
例えば固定の商品カテゴリー名、国名など。
つまりデータベースの更新がないもの。
あえてテーブルを作るほどでもない。
そんなときに使えるのがActiveHash。
ActiveHashとは
静的データをhashで持たせ、ActiveRecordのように使うことができる。 今までseedデータなどでマスターデータなどを持たせる、言語ファイルに持たせるなどをしてきたことをシンプルに実装できる。
使い方
まずgemをインストールする。
gem 'active_hash' でbundle installすればOK。
そしてmodelでActiveHashで定義する。
class ReserveStatus < ActiveHash::Base
self.data = [
{id: 1, name: '未予約'},
{id: 2, name: '予約済み'},
{id: 3, name: '返送待ち'},
{id: 4, name: 'キャンセル'},
]
end
self.dataでハッシュを入れる。
これで準備は完了。
ActiveRecordと同じようなことができる。
全件取得はこう。
ReserveStatus.all
当然findやwhereなどActiveRecordのメソッドも使える。
しかもbelongs_toやhas_manyなどの関連付けもできる。
これはべんりべんり！
はじめてのハッカソンに参加してきた
はじめてのハッカソンというイベントに参加してきた。
はじめてのハッカソン ～デザイナーからプログラマーまで～ | Doorkeeper
ハッカソン自体は何回か出たことがあるが、友人がスタッフとして参加していたので参加してみた。
内容
場所は品川のマイクロソフトだった。
SVSなどで何回か行ったことがあった。
参加者
参加者の8割以上がハッカソン参加自体はじめての人だった。
更にいわゆるWebやっています、フリーランスやっていますという人は少数で、業務系の固めの仕事をしているエンジニアが多かった。
これは意外だし「はじめての」という冠がついている効果だと感じた。
個人的にこういった方たちを集客したいときの参考になった。
また、よくある「アイデアだけ持っています！開発もデザインもできません！」みたいな人がかなり少なかったことも良かった。
「当方ボーカル、ギター、ベース、ドラム募集！」みたいな人ばかりでエンジニアの負担がものすごいハッカソンもあったが、そんなことは無かった。
チーム決め
チームは事前アンケートをもとに、バランスを考慮してあらかじめ決められていた。
ハッカソンでなんだかんだ揉めるのがこのチーム決め。
多くが最初からチームでの参加か、プレゼンで決めていくケースが多いように感じるが、どうしても時間がかかってしまう。
今回は事前に決まっていた為、そこらへんがスムーズなのは良かった。
デザイナーさんが少ないなどはあったが、多くのチームが何とかなっていたようだった。
開発
いきなり開発に入ったのも驚いた。
よくあるアイデア発表や中間発表も無かった為、開発に集中できた。
賛否両論あるとは思うが、個人的にはすごくやりやすかった。
感想
何とか簡単なサービスを作ることができた。
個人的には満足だったのでまた参加したい。
ハッカソンに行くと毎回、もうちょっと技術力を身につけなくてはと思わされる。
すごい人はやっぱりすごい。
また、異なるバックグラウンドを持つエンジニアさんと話せるのは楽しい。
もっと頑張ろう。
Marionett.jsでBackbone.jsを快適にする
はじめに
Backbone.jsを使っていると、特にViewのコードが読みづらくなる、コード量が多くなるといった問題が発生することがある。
この原因として、Backbone.jsが高機能ゆえにどのような書き方でも動くっちゃ動くということがある。
また、ベストプラクティスがあまり浸透していないことも原因だと思う。
Marionette.jsとは
Marionette.jsはBackbone.jsに便利な機能を追加したフレームワーク。
誤解を恐れずに言えば、Backbone.jsのベストプラクティスを集めて実装できるようにしたものと言えるので、コードがきれいになる。
特にView周りは同じ処理を何回も書いてたものを共通化してくれるのでありがたい。
Marionette.jsでできること
いくつかあるが、今回はViewの拡張について紹介する。
Marionette.View
他の3つのViewの基底クラスとなるもの。 Requirejsとの組み合わせの場合、このようになる。
define([ 'jquery', 'marionette' ], function ($, Marionette) { var AppView = Marionette.View.extend({ }); });
このMarionette.Viewをそのまま書くことはあまりない。
Marionette.ItemView
これは1つのModelやCollectionをViewとして扱う。
後のCollectionViewやCompositeViewを親として複数設定することができる。
Marionette.CollectionView
ViewのCollection版。
ItemViewを子Viewとして管理する。
Marionette.CompositeView
CollectionViewを更に継承している。
特徴としてtemplateが指定できたり再帰的に子供のrenderを設定できる。
また記事は書きたいけどtemplateは便利。うん。
Railsでバッチ処理を1回だけ実行する
Wheneverでcronを定期的に実施する方法はよくやるが、一回だけのバッチ処理は忘れてしまうことがあるのでメモ。
例えばfoodテーブルのカロリー（calorie）未設定のレコードに対し、未設定フラグ(not_set)をたてる処理を１回のみ行うとする。
lib/tasks/calorie_set.rb
def self.test result = Food.where(:calorie => nil) result.each do |i| i.not_set = true i.save end end
本当はエラーケースなども用意したほうが良い。
バリデーションエラーなどで更新されないケースがあるからだ。
既にDBに入っているということはバリデーションにかからないのでは？と思う方もいるかもしれないが、バリデーションチェックをデータ挿入後に追加したなどの理由で不整合データがあることも考えられる。
そしてタスクが設定できたらこのコマンドを実行する。
bundle exec rails runner Tasks::RunnerTest.test
定期的に行う場合はwheneverでcron設定しよう。
Railsで複数テーブルをフォームから更新する
たくさん記事はあるのだけど、フォームから複数のモデルオブジェクトを更新する方法をいつも忘れるのでメモ。
結論からいうと fields_for を使う。
_form.html.erb
<%= form_for(@store) do |f| %>
<%= f.text_field :name %>
<%= f.fields_for :items do |itme| %>
<%= item.text_field :name %>
<% end %>
<%= f.submit "送信" %>
<% end %>
当然、Modelも関連付けてある。
store.rb
class Store < ActiveRecord::Base has_many :items end
item.rb
class Item < ActiveRecord::Base belongs_to :store end
ちなみにfields_forは何層もネストすることができる。
つまり、store > item > color のような形。（例えが微妙かも）
ここまでいくとファイルを分けてしまったほうが楽。
_form.html.erb
<%= f.fields_for :items do |item| %>
<%= render 'item_fields', {f: item} %>
<% end %>
こうしてあげると_item_fields.html.erbの中でitemがfに置き換わるので、またf.fieldsからcolorのフォームをレンダリングするなどできる。
