TrackRで迷子対策
我が家の次男氏（4歳）は、遊園地で唐突に「とーちゃんバイバイ！」と走り出して迷子になったり（しかも親側が迷子になったと思っている）割とたちの悪い息子でして。
世間的に叩かれているハーネスとかも考えたのですが、流石に4歳にハーネスというのもなぁ、ということで別のツールを利用して割といい感じなのでご紹介。
TrackR bravoって何？
最近、bluetoothでスマホとペアリングして失くしたものを見つける系のガジェットがいくつか出ています。
TrackR bravoもその一つ。
![TrackR bravo Item Tracker ブラボーアイテムトラッカー シルバー[並行輸入品]](https://images-fe.ssl-images-amazon.com/images/I/31PNnhelsrL._SL160_.jpg "TrackR bravo Item Tracker ブラボーアイテムトラッカー シルバー[並行輸入品]")
TrackR bravo Item Tracker ブラボーアイテムトラッカー シルバー[並行輸入品]
- 出版社/メーカー: TrackR Inc
- メディア: エレクトロニクス
- この商品を含むブログを見る
機能としてはシンプルで、以下のようなもの。
- スマホとbluetoothで繋がっているいると、スマホのGPS＋専用アプリで凡その位置情報を記憶しておける。
- bluetoothでつながっていると専用アプリから端末の音が鳴らせる。
- bluetoothでつながっていると端末のボタンを押すと、スマホの音が鳴らせる。
- bluetooth接続が切れるとアラートを鳴らせる。(設定次第、バッテリー消費増える)
- bluetoothで繋がっていない時に探索モードにしておくと、他のTrackR利用者のスマホが端末を検知すると場所が通知される。
1-4が基本機能で5はまだ利用者が少ないんでおまけな機能ですね。
鍵とかにキーホルダー代わりにつけて、見当たらない時に探す、というのが基本的な使い方かと。
迷子対策に使える？
子供のリュックにつけてみました。
基本的にはbluetoothで繋がっている必要があるので、つながっているかどうかで近くにいるかどうかを判断できます。
アプリの画面はこんなイメージ。
スピーカーボタンの周りのがbluetoothの接続状態の強さを表していて、どこで場所が確認されたかが上の地図で確認できます。
（場所の更新がアプリ立ち上げ都度では無いようなので、接続されていても場所が更新されないケースも。その場合はアプリを再起動すると最新化されます）
スピーカーボタンを押すと、端末の音がなる感じですね。
実際に使ってみた
次男氏には
「この丸っこいやつの音がなったら、とーちゃんが探してるってことだから立ち止まれ」
と教えた上で二週間ほど運用してみました。
結果、2度ほど行方不明になったのですが、割りといい感じ。
ショッピングモールで居なくなったときには、bluetoothでつながっているかで近くにいるかどうか分かるので、闇雲に探す、という感じではなくなりました。
端末から出る音はさほど大きくないので人混みでは聞こえませんが、音を鳴らすと
「とーちゃーん！ここだよー！」
と叫んでくれたので、すぐに見つけられたり。
接続が切れたときのアラートは今のところ設定していないのですが、お出かけの時だけ有効にする等すればより便利かも。
子供用のケータイを持たせるにはまだ早いけど、迷子が心配、と言った同じようなお悩みを持たれている人はお試しにどうぞ。
読書感想文ってなんやねん
先日、長男氏（小1）の小学校の面談で、
「感想を言ったり書いたりがあまり上手にできないですねー。」
と言われて、自分も昔そうだったし、それはそれでいいんじゃないか、と思っていたのですが、以下の五味太郎さんの記事を見てふと思ったこと。
そもそも、読書感想文って、以下2つの大きな壁があるんじゃないかと。
- そもそも文章を読まされている
- 感想を求められていない
そもそも文章を読まされている
読書感想文ってそのきっかけが強制的なんですよね。
例えば国語の教科書に乗っている文章であったり、宿題として本を読んで感想文を書いてこい、と言われたり。
与えられた課題に答えないと、とは思うけど、求められていることが理解できていないので、「別に読みたい文章でも無いのに、感想なんて無い」「ふーん」「別に」というのが小さい頃に思っていた記憶。
感想を求められていない
読書感想文で求められているのは感想ではなく、人にオススメする紹介文なんだと思うのです。
「私はこの本を読んでこう思いました。なぜなら、こういうところが素晴らしいと思ったからです。ほら、みんなも読みたいでしょう？」
みたいなことを求められているのではないかと。
Amazonのトップレビューをコピペすれば非常に良い感想文が出来そうですね！（ダメ
読書感想文の意義
結局、読書感想文で養われるのは
「大きくなって、別に好きでもないなんの思い入れもない商品を人に売り込まないとイケない時に役立つスキル」
なんだと思う。
長男に本や文章を読ませて感想を聞いても以下のような感じ。
自分 「その文章読んでどう思った？」
長男氏「おもしろかった。」
自分 「どこが？」
長男氏「主人公がxxしたところー。(文章後半の覚えてる所)」
自分 「なんで？」
長男氏「……」
全くもって興味ないんだろうなー。
別に読書感想文をうまく書け、とは思わないけど、まずは興味のある事や話に出会わせてやる所からだ。
N+1問題
N+1問題ってご存知でしょうか？
N+1問題 / Eager Loading とは - Rails Webook
N件のデータをSelectした後に取得してきた1件ずつをfor文で回して再度Select処理して、N件が大きくなればなるほどパフォーマンスに影響を及ぼすやつですね。
1+n問題って言ったほうがわかり易くないか？と心の底から思っていますが。
SQLレベルだとJoinとかINとかサブクエリでSelectするとかっていうので対応できるので、まぁ作る時にきちんと気にしましょうね、という話。
ではこれがどんな時に問題になるのか、というと、ここのところAPIエコノミーみたいに流行り言葉になっていますが、APIが固定されていると問題起きがち。
一覧取得系のAPIと、詳細取得系のAPIが分かれて実装されていたりすると、クライアント側の実装によってはすごい負荷になります。
APIをリリースする側が大量アクセスで負荷が高くなったり、クライアント側で大量のアクセスが発生してブラックリスト入りしたりするので、結局公開側とクライアント側の双方で気をつけるべき話なんですが。
なんでこんな話をしているかというと、某S社のCRMの標準APIってgetlistとgetdetailを分けて実装になっており、先日Multi Thread Programmingのブログが上がっていて、そもそもの解決策ってそんなとこじゃないよなぁ、と思った次第。
Use ABAP Multi-“Thread” programming to deal with a real performance issue | SAP Blogs
コンウェイの法則と企業情報システムアーキテクチャ
コンウェイの法則とは
The organization of the software and the organization of the software team will be congruent, (中略)If you have four groups working on a compiler, you’ll get a 4-pass compiler
訳すと、
『ソフトウェアとチームの構成は一致する。4つのグループでコンパイラーを作れば4つのコンパイラーができる。』
もうちょっと意訳すると
「アーキテクチャは組織に依存する」
という話ですね。
以下の記事ではOSを例に挙げており、なるほどなぁ、と思ったり。
コンウェイの法則（Conway's Law） - Plan9日記
3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。
ソフトウェア開発においては、
開発チームの構成に依存してアーキテクチャが決まる為
逆に
アーキテクチャに応じて開発チームを構成すべき
とも言われたりします。
コンウェイの法則と企業情報システムアーキテクチャ
よくソフトウェア構成や開発について言及されるのですが、企業情報システムアーキテクチャにおいても同様だと思っています。
というかそういう例をクソほど見てきました。
旧来の企業情報システムは組織ごとにシステム化が進んできました。
財務会計、出納、外貨管理、人事、在庫管理、生産計画、生産管理、設計、受発注などなど。
1990年台後半からERPが流行り始め、システム統合が進みました。
ERPといえば
「ベストプラクティスがー」とか「BPRがー」とか言われますが個人的にはどうでもよくて、
アーキテクチャ観点での本質は
「組織間のデータの共用化」
だと思っています。
本来的に企業の組織は相互に影響し合う振る舞いが必要で、これまでバッチでインターフェース連携していたのが、ERPになって、データの連携が自動化・リアルタイム化されて、また、領域をまたいでデータが見られるようになった。
が、最近はSaasやSoEやSoRといった考え方で、部門ごとにシステムを切り出す方向にトレンドが流れている。
多分その流れは止められないのですが、これをIT部門が弱い企業で進めると、かなりカオスになります。（というか、なっています。まじで。）
システムを分ける、というものの、一度ERPで実現したシステム間の相互連携は必要で、個別システム化にあたってのポリシーがないと、ツギハギだらけの増築を繰り返したいびつな旅館みたいなシステムが出来上がります。
利用言語、OS、MW、基盤の乱立、システム間連携のトポロジー複雑化、言われるがままに仕様追加してスパゲッティ化した仕様やコード、再利用なんてとんでもない。
企業の場合、アーキテクチャに応じて組織を設計する、というのは難しい話。
組織毎のシステム構築の流れが進む今、全体を俯瞰して計画する従来のEAを推進するような役割とアーキテクチャに対する原則やデザインルールなんかを整備できない企業は、気がついたら90年代以前の手がつけられない情報システムの状態の再来を招くことになりそうです。
slackのSAPとの提携
周りの人何人かからコメントを求められたのでメモ。
SlackがEnterprise Gridのリリースと合わせてSAPとの提携を発表しました。
Enterpsise Grid自体は期待できますね。
BIツール連携みたいのも考えているみたいでエンプラIT屋として、Sharepointや糞手組みポータルに変わる社内コミュニケーション手段として胸躍るものが有ります。
記事中にも有りますが、企業知識ベースを意識したFacebookのWorkplace、MicrosoftのTeams、Jive、CiscoのSparkといった最近新たに出てきているトレンドかと。
ただSAPとの提携の話を合わせてリリースしたのはEnterprise Gridリリースの釣り感があります。
SAPとの提携とは
Enterprise Grid、関係ありません。
SAP的には、経費精算のConcur、人事管理のSuccess Factors(SF), PaasのHANA Cloud Platformの3クラウドサービスに係るchat botをリリースしたよ、という話。
Enterprise Gridと関係なく利用可能です。
botの詳細は以下参照。
まだベータ版のようですが、旅程の確認や経費精算のレシートアップロード、経費精算申請に対応しているよう。
Driving Conversational HR with the New SAP SuccessFactors Slack Bot | SAP Blogs
SF上でのアクティビティやアチーブメントの登録やフィードバック、レビューなんかができるそうな。
HCPに関する情報はまだなさそう。
Slack提携へのSAP屋としての期待
SAPとしてはSAP Jamやワークフロー関連のタスクリストなど、コラボレーション系のツールはあるものの統合は進んでいない印象。
ビジネスソリューションというよりもプラットフォーム型のソリューションで、既にFacebookやMicrosoftなんかはSNSで培ったノウハウを持っておりSAPが新たに入り込むのはどうかなぁ、というのが個人的見解。
餅は餅屋というか、SAPとしてSlackやそMicrosoft、Facebook等のソリューションと連携してワークフローやコラボレーションを実現していくような形にすすんでほしいなぁ、などと。
【Memo】ABAP CDSビューについての雑記
ABAP CDSとは
S4HANAがリリースされて冗長テーブルが排されて、テーブル構造がシンプルになった代わりにABAP CDSビューという、アノテーションで計算処理とか色々できるView機能がABAP CDSビュー。
ABAPの移送機能が使えるのでHANA単体のCDSよりも推奨される。
このあたりが参考によさそう。
Getting Started with ABAP Core Data Services | SAP Blogs
SAPエンジニアがABAP CDS取り組むべき理由
非正規化されてた集計テーブルとか多数の冗長テーブルを無くせたのは、CDS Viewで従来のDBでは重くてできなかった処理をDBにpushdownできたから。
それ故、標準を触る上でCDS Viewの理解は必須。
さらに、従来ABAP の内部テーブルでぶん回してたアドオン処理もDBに寄せれてアドオンも楽になるし、ついでにOdata化とかAnnotationでできるようになってるよ。
CDSビューとUIの関連
CDSは単にビューを作るものではなく、データモデリングを行うもの。
エンティティ間の関係性をCDSでモデリングし、そこにくっついてるAnnotationを元に、UIはFiori Smart Templateで自動生成しちゃう。
更新系だとBusiness Logicの実装にBOPFも必要。
参照系も更新系も（分析系も）同じモデルをベースに作ることになるイメージ
BOPF関連リンク
https://archive.sap.com/documents/docs/DOC-45425
https://blogs.sap.com/2018/05/01/where-to-find-learning-material-about-bopf/
https://sapyard.com/bopf-for-beginners-part-1-introduction/
データマネジメント観点でのCDS View
データの利活用って観点を入れた時に、上記の自動生成系UIとデータモデルが密結合になるアーキテクチャが良いのか、っていうのは正直疑問だなー。
非正規化してCDSで加工して見せるというのは大賛成だけど、CDSやUI生成ツールの特性に合わせて、データモデルが制約を受けるようなケースが有ると望ましくない。
DAとアプリケーションは切り離されるべき。
このあたりは検証しながら考えていきたい。
