夏休みなので波情報アプリを一つ作ってみる。4日目(6日間)

バックエンドの作り込み

Node.jsで作り込んでます。
フロント向けにWebAPIのインターフェースを用意し、
処理としてはOpenWetherMapからデータを取得する。

OpenWetherMapの無料版には取得回数の制限があるため、
Cronで1時間毎にデータを取得してキャッシュ化し、
フロントに返却するように設定しました。

cronでupdateWeather.jsを定期実行し、キャッシュ(Cacheディレクトリ配下)を更新
f:id:furugen098:20170823061202p:plain

フロント向けAPIの返却(main.jsの処理)
6時、9時、12時、18時のデータを返却しています。
f:id:furugen098:20170823061135p:plain

夏休みなので波情報アプリを一つ作ってみる。3日目(6日間)

画面モック

とりあえず初期段階の画面モック。
f:id:furugen098:20170818213003p:plain

選択中の場所を地図上で旗アイコンの色変えたけどさすがに分かりにくいですね…。
ツイッターの情報はハッシュタグを指定して対象地域のツイートを取得予定(期間は約1週間ぐらい)
連携先をインスタグラムに変更するかもしれません。


時間があればやりたいこと。
・ソート/フィルタ機能
 →車でいけるとこ。
・数日の天気情報から海の濁り具合
・風向きからクラゲ注意について表示
・サーフスポットとの切り替え


書いてて気づいたけど風向き表示してないな…。
追加しないと。

夏休みなので波情報アプリを一つ作ってみる。2日目(6日間)

2日目は設計。



▪️アプリ概要
・沖縄特化であること。
シュノーケリングスポット(余裕があればサーフィンも)の紹介と合わせて各スポットの波情報を紹介。
ツイッターで対象スポットのつぶやきを確認。
・1タップでそのスポットへのグーグルマップを開く。


▪️仕組み
各地の天候情報はOpenWetherMapを利用して取得する。
Сurrent weather and forecast - OpenWeatherMap

都市名や緯度軽度を指定すると天候情報を返却してくれるAPI
無料プランがあり商用利用も可能。
今回のアプリ作成は無料プランを利用させてもらう。

ただし、無料プランには制限があり、1分間に60回のコールまでという制限があり、
同時利用者数が多ければ情報がうまく取得出来ない可能性がある。

そのため、アプリから直接OpenWetherMapのAPIを参照するのではなく、
参照回数を最小限に抑えるため、キャッシュの役割を持つサーバを自前で用意する。

フロント … Xamarin
バック  … Node.js
で作りこみ、OpenWetherMapにはNode.jsから参照し、データを蓄積するようにする。

図で書くとこんな感じ
f:id:furugen098:20170817001032p:plain


▪️スケジュール
超ざっくり作業フロー

①モックレイアウト作り込み … 1日
②OpenWetherMap含めたバックエンドの構築 … 1日
③導通 … 0.5日
④フロント/バックの詳細作り込み … 2日
⑤アプリ公開! … 0.5日

夏休みなので波情報アプリを一つ作ってみる。1日目(6日間)

表題通り。

夏休みだしせっかくなので1つアプリを作ってみようかと思い立ち書きました。

沖縄の海の有名どころの風情報や波情報を簡単に表示出来るアプリ。

サーフィンやシュノーケル等の海遊び利用できればと思います(沖縄限定ですが)

自分でも日頃から利用できるようなアプリを目指します。

ソースの公開は包括してるAPI等の都合上で公開するかは悩み中です。

とりあえず作業開始!

最強の防犯対策とは?

最強の防犯対策とは? 最強の防犯グッズは?


当記事では理想の防犯対策とは何か。
ITで解決できる事があるのか?を考えてみたい。

シュチュエーションは
・物理的な防犯対策であること。
・例えば外出中のできごとなど。
を想定して話していく。

まず物理的に外敵から守るためのセキュリティとして
最高レベルの対策はなんだろう?実際の対策の例は?
思い浮かぶのは要人警護(首相や大統領)だろうか。
彼らの行動には外出に常にSPに警護されている。
更に訪問地に対してこれでもかというほど事前のチェックがあったりする。

じゃあ皆安全のためにSPを採用すれば良い…と言いたい所だが、
残念ながら金銭的な事情で現実的ではない。

では一般家庭でよく気をつける事例をあげると
・1人で出歩かないように。
・誰かに送ってもらう。
あたりではないかと思う。

要人介護、一般家庭で気をつけてる事の、
どちらも共通しているのは決して1人で行動しない事が最善の対策に思える。

現行の防犯グッズで考える

少し話題を変えるが、現状世に出ている防犯グッズはたくさんある。
だが、共通てし幾つか致命的欠陥があると思う。
 ①自分から行動しないといけないということ。
 ②常に持ち歩かないといけないこと。
この2点が非常に大きいと思う、特に①はどうしようもない。
①の事例で防犯ブザーで例えると、もし本人が身動きがとれない。
または、突然の事で対処できない場合などだ。

致命的欠陥に対する対処

自分から行動しないといけない

最善の対策法で話した二人で行動することが対策になる。
だが、現実的な対応ではない。

常に持ち歩かないといけない

持ちあるかないと機能しない。
現代人が常に持ち歩いているものは何だろうか?
家の鍵、携帯(スマホ)、財布などか。

ITでのアプローチを考える

結論からいうと
”持ち主と常に一緒いるロボットを作ってしまえ”
となる。
ロボホンが僕の中でかなりイメージに近い。

自分から行動しないといけない の対策

まず本人以外の第三者の目が必要不可欠になる。
それを人間ではなくロボットに託してしまおうという考えだ。
今やIoTが盛んになっておりセンサー類がかなり安価で揃える事ができる。
たとえば外出中に心拍数の異常などを感知してGPS発信したり
大音量でアラートを流す事が可能になってきている。

常に持ち歩かないといけない の対策

スマホに組み込めるならそれが最善ではある。
だがスマホに今回の目的であるセンサーをつけるのは難しい…。
とはいえ何故ロボット? の疑問についてだが
常に持ち歩かせるために愛着を持たせるためだ。
それにロボット形式にしてしまえば安価で監視(センサー)機能などを
拡張しやすい点もある。

まとめ

この記事を書いた目的としてIotを勉強するうえで
僕の理想の防犯グッズが作れたらなーという妄想をまとめるために書いてみました。
ロボットという話にしたのはネタっぽい部分もあるが
人工知能の制度があがっていくと1人に対して1ロボットがお世話する。という
未来はわりと現実味があると思う。
※某ネコ型ロボットアニメみたいに。

勿論、僕がどうのこうのやってるうちに
企業が素晴らしい製品を出す可能性の方がよっぽど高いでしょう。
IoTを勉強する上での1つのモチベーションに繋げられたらとこの記事は十分役になったと言えるかな。
人生勉強、まだまだ頑張ろう。

ItemsSource を使用する前に、Items コレクションが空である必要があります。

表題のエラーについて意味が分からないので調べてみた。

条件としては

コンボボックス(ItemsControl継承パーツしてるやつ)などで

XAMLでも要素書いているにも関わらず

バインドでItemsSorceに値を設定する場合に発生する。

CombBoxData.ItemsSorce = combData;

CombBoxDataはデータクラスだ、中身はこんな感じ。

/// <summary>
/// データリストを取得または設定します。
/// </summary>
public ObservableCollection<IItemsDataObject> ItemsSource
{
    get
    {
        return this.DatasField;
    }
set
    {
        this.DatasField = value;
        this.OnPropertyChanged("ItemsSource");
    }
}

SourceReference Source
を確認、今回のエラーにかかわる部分を見つけた。

        // This puts the ItemCollection into ItemsSource mode.
        internal void SetItemsSource(IEnumerable value, Func<object, object> GetSourceItem = null)
        {
            // Allow this while refresh is deferred.
 
            // If we're switching from Normal mode, first make sure it's legal.
            if (!IsUsingItemsSource && (_internalView != null) && (_internalView.RawCount > 0))
            {
                throw new InvalidOperationException(SR.Get(SRID.CannotUseItemsSource));
            }
 
            _itemsSource = value;
            _isUsingItemsSource = true;


_internalViewにはXAMLで設定されている子要素が設定されている。

IsUsingItemsSourceは一度Bindingで設定するとtrueになるのだが、

今回は初期設定のためFalseのままエラー判定が有効になってしまい例外が発生する。

自分でクリアしてくれても良いのになー。と思わなくもないが

XAMLでも書かれてバインドもされている参照元が複数ある状態になってしまうので禁止しているのだろう。