古い物件をIoTハウスに変える【開拓編】

こんちわ!

新卒iOSエンジニアのよっしーです。

会社から近くてそこそこ広いという理由だけで、築50年のリノベーション物件を借りて住んでいます。

「エンジニアたるもの、生活環境を自動化しないでどうする!」と思いたったのですが、 家が古くて解決しなければいけない問題が山積み...。

そんな僕がIoTハウスを実現するに至った方法を紹介します。 今回は自宅開拓編です。

1. 圏外の自宅で携帯の電波を受信できるようにする

物件によっては、立地、構造、キャリアの影響でスマホで電波が一本も立たないような場合があります。 それがうちです。

僕も含めて、最近の若者は固定電話を家に引かない人が多いと思うので、スマホで電話受けられないと不便な事が多いです。(入居時のガス・水道などのインフラ系契約とか)

僕はauスマホ契約しているのですが、常に電波一本。トイレ付近は圏外でした。 しかし、安心してください!

各キャリア電波改善機器を出しているので、こいつを申し込みましょう!

これで、僕のiPhoneは常に3~4本電波が立つようになりました。(4本中) f:id:thunder-runner:20180707234717p:plain:w300

以下がキャリアの電波改善機器申し込みページです。

auの場合

softbankの場合

docomoの場合

電話かネットで「通信困難住宅です!」と申し込むと日程が決まります。

当日になると設置員の方が来て、電波改善機器を設置してくれます。 これには料金の必要がなく、電気代の支払いだけでいいです。しかも月数百円程度。 電波状態が悪いご家庭にお住みの方には、基本的にオススメします!!!

機器のサイズはうちの場合、目測で 45 x 10 x 30(高さ、横幅、奥行き)ぐらいです。

モバイル回線の開拓に成功!

2. 古い住宅に光ケーブルを通す

建物によっては、ずさんなリノベーションで光ケーブルが室内に届かないような場合があります。 それがうちです。

物件情報には、「光ケーブルが通っててネットが使えるよ!」と書いてあったので、このような時は

オーナーに依頼して電気工事をしてもらい、穴を開けたりして光ケーブルが室内に通るようにしましょう。

うちの家は天井に穴を開けて、雲の糸のように天井から光ケーブルがぶら下がっています。 f:id:thunder-runner:20180707234722p:plain:w300

物件情報にネット有りと書いてあるのに通ってない場合は、オーナー持ちでなんとかしてもらえます。 穴開けるのもやむなし。って感じなので、ここではあまり気にしなくても良いです。

光ケーブルの開拓に成功!

3. 古い住宅にネットを通す

物件によっては、構造上の問題や回線業者の適当な取り付けの影響で、既存の回線以外への拡張性がゼロの場合があります。 それがうちです。

エンジニアとしては 「多少高くても速い回線がいいから、NURO光申し込もう!」というテンションで工事を申し込んだのですが、ダメでした。

というのが、光コラボ回線しか利用できないような制約をマンションが抱え込んでおり、特殊な工事や設置を要する回線は絶対に通せない。 という状況だったからです。

どうにもなりません! 既存の回線を申し込みました! f:id:thunder-runner:20180707234718p:plain:w300

ちなみにADSL使えばいいじゃね?みたいな話をオーナーがネット業者にしていて泡吹きそうになりました。 「すでに全部光になってるので無理ですねー」って業者が言っていたので安心した...。

ネット環境の開拓に成功!

ちな前述の光ケーブル開通うんぬん込みで、家にネットが通るまでに4ヶ月かかりました。 (窓際においたiPhoneの電波2本テザリングと近所のカフェのau wifiで耐え忍んだ。)

まとめ

このように、築年数の古い物件に住む場合は、さまざまな制約や問題が立ちはだかります。 特に楽をして快適な環境作りをしたいエンジニアにとっては大問題になります。

基本的には下調べをしっかりして、このような家には契約しないようにしましょう。

ネット環境バッチリあって、爆速で、電波がマックス立ってる家を最初から選んだ方がいいです。

ただ、僕のように「契約後に不具合に気づいたけど、これどうしよう...。ケテスタ」って時は、参考にしてみてください。

iOSのレイアウトサイクル勉強した

会社の先輩の記事と、Appleのドキュメントを読みながら学習した。 speakerdeck.com

iOSのレイアウトサイクルをなぜ知らなければいけないか。

1. 重たいから

意図しない描画を引き起こさないために。

2. 思い通りにレイアウトさせるため

設定はしたもののサイクルが回らなかったせいで見た目が想定と違うことを防ぎたい。

レイアウトサイクル

1. loadView()

viewプロパティが必要になった時に呼ばれる。viewがIUO型で宣言されているので、viewがアクセスされる前に初期化させるものと思う。 IB使ってる時はオーバーライドしてはいけない。 コードレイアウトの時など、Viewを自分で作るときはオーバライドする。 そこで、ViewControllerのviewプロパティを設定する。

2. viewDidLoad()

VCがViewヒエラルキーをメモリにロードした後に呼ばれる。 Viewヒエラルキーがnibから読まれたか、コードでloadView()をオーバライドしたかは気にしない。

nibから読み込んだviewsのAttributes設定などによく使う。

3. viewWillAppear()

自身のviewがviewヒエラルキーに追加される直前なのを通知する。

4. viewWillLayoutSubviews()

VCが自身の子viewsを描画する直前に呼ばれる。 子Viewのboundsが変わった時、VCのviewがsubviewsの位置を調整する。 VCが子Viewsをレイアウトする前に処理をはさみたいならここをオーバライドする。デフォルトでは何もしない。

5. layoutSubviews()

サブビューを描画する。 より精密な子viewsのレイアウトをするためにオーバーライドする。 このメソッドはautoresizingと制約ベースの挙動が自分の意図した動きを提供しないときのみオーバーライドすべき。 frameの設定は直にしろ。

6. viewDidLayoutSubviews()

VCが自身の子viewsを描画した直後に呼ばれる。 ビューコントローラのビューのboundsが変更されると、そのビューはサブビューの位置を調整し、システムはこのメソッドを呼び出す。

7. viewDidAppear()

自身のviewがviewヒエラルキーに追加される直後なのを通知する。 super絶対呼べ。 ポップオーバーなどでVC表示をしていて、前面のVCをdissmisしても後面のVCのviewDidAppear()は呼ばれない。

8. viewWillDisappear()

Viewヒエラルキーから自分が取り除かれる直前に呼び出される。

9. viewDidDisappear()

iewヒエラルキーから自分が取り除かれた直後に呼び出される。

レイアウトループ

以下のようなレイアウトループがずっと走ってる。 f:id:thunder-runner:20180610213712p:plain

レイアウトが必要かどうかのフラグが立つ条件

  • setNeedsLayout()を呼び出す
  • バイスが回転した
  • 子ビューが追加や削除をした
  • 子ビューがスクロールした
  • 子ビューのframeやtransformが変化した などなど。らしい

setNeedsLayout()はフラグを立てるだけなので、レイアウト自体は次のレイアウトループ

レイアウト関連のメソッド

setNeedsDisplay()

UIViewにレイアウトフラグを設定する。

setNeedsLayout()

UIViewのサブビュー全てにレイアウトフラグを設定する。

layoutIfNeeded()

呼ばれた時に、viewとviewをルートとしたサブビューに画面更新の必要があった場合に全て即座に配置する。 フラグの設定でなくて、強制再描画なので処理が重い。

土曜のNIPPOU【6/9】

JIRAとGitHub連携

とりあえずJIRAとGitHub、納得行くところまで連携させることが出来たー。

この辺を参考にして頑張った。設定時の注意はJIRA側からDVCSの設定をするときに(OK押す前に)、「新規レポジトリの自動同期」「新規レポジトリのスマートコミット」みたいなチェックボックスを切っとかないと、全レポジトリが同期されてしまうこと。

JIRAとGitHubを連携させてsmart commitsを利用してみよう!

GitHubのIssue・Pull Requestのテンプレート機能を使おう

開発作業で課題を参照する - アトラシアン製品ドキュメント

Smart Commit で課題を処理する - アトラシアン製品ドキュメント

GitLabとの連携みたいに、PRのタイトルにJIRAのチケット番号書いとけば自動リンクしてくれる。ってことがないのが残念やけど、PULL_REQUEST_TEMPLETE.mdでURLのひな形を作っといて、チケット番号をコピペするだけでリンクできるようには出来た。   JIRA側のチケットからは、PRのタイトルにチケット番号含めることでGitHub参照可能。というかコミットもブランチもPRも全部紐づく。    GitHub側でレビュー出したらJIRA側でフックしてステータスをレビュー中に変えたりも出来た。

WindowsApple keyboardを利用するように

AutoHotKeyというソフトで、Win上でMacキーバインド(風)を再現できた。

コードベースで管理できるのが良い。 autohotkey-for-applekeyboard/applekeybind.ahk at master · syatyo/autohotkey-for-applekeyboard · GitHub

けど、挙動が良く分からないところがいくつもあったりするので、左のWinキーをCtrlに割り振って、ctrl + hでバックスペースさせる。みたいな最低限のMacキーバインド

ゲーム

FPS買って遊んでる。むずかしいけどたのしい。 (ダークソウルリマスターやってるけど、リマスター作品ってどうしても「一回やったやんこれ...」が来てしまうと、再開することがないのよね...)

晩御飯

今から飲みに行ってきまーす!!!

感想

JIRAとGitHub連携の事、だいぶ分かって良かった! スクショもいっぱいとったし、手順書作れるやろ!

今日はいい日だったー。

「超AI時代の生存戦略」 読書感想文

  • 読んだ本

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

 

 twitterのプロフから引用した紹介文がこちら

博士/筑波大准教授・学長補佐・デジタルネイチャー推進戦略研究基盤長/ピクシーダストテクノロジーズCEO/JST CREST研究代表/大阪芸大客員教授デジハリ客員教授 / 未踏スパクリ・総務省異能/VRC理事/未踏理事/電通イノラボ/博報堂/30歳/一児の父/メディア藝術家

経歴多すぎてどんな人かむしろわかりづらい...(笑)

基本的にはメディア・アーティスト/研究者/起業家っていう認識でいます。

  • 要約

AIが中間管理を行うようになり、コンピューターが生活のありとあらゆる場面に存在する。そのようなパラダイムの中で、古い「生き方観」のようなものがフィットしなくなってきている。仕事とプライベートは、もはや二分できなくなっており「ワークライフバランス」ではなく「ワークアズライフ」を基本に生きたほうが良い、という考え方をベースにして、古い価値観をアップデートするための方法を34紹介している。

  • 面白かった章

第一章「超AI時代の生き方」

ギャンブルと報酬

「どきどきしてたまに報酬がある。」というのが物事にハマっていくロジックで、毎日の勉強や作業のなかに、「ちょっとヤマを張った提案を上司にしてみる。」などのギャンブル的要素を入れたりすると、テンションが上がるかもしれない。物事をテンション高く楽しんでいくためには、適切な報酬設計。つまりは、自分にとって何が報酬かをよく考える必要がある。(かいつまみ)

 

これは大いに納得した考え方で、エンジニアっぽく新しいことにはいろいろ挑戦してみるのだが「なーんかテンション上がらねーな。」と思いながら勉強していたりすることが自分自身多かった。どうやらそれは、「適切な報酬設計ができてなかったからだ。」と、考えることが出来た。この考え方で自分をアップデートしていけば、何を取り組むにもけっこう楽しめそうな気がする。

 

第二章「超AI時代の働き方」

一度覚えて一度忘れ

あらゆるものをググれば分かるというレベルで頭の中に保存しておく知識のつけ方が大事。「自分で一度解いてみたことがある。」というのが大事で、そこでフックをつけておく。それから自分が専門的に使いだせば2,3日で出来るようになるし、基礎数理さえ身に着けておけば、細かい数式は後で調べながら論文を読めば、すぐ追いつく。というようにしている。(かいつまみ)

 

高校生までロクに勉強してなかったくせに、謎に完ぺき症で「これが完ぺきに出来なければ次に進むことが出来ない」という考えがすごく強く、学習がうまくいかないことがあった。そんな自分には天啓が下りたような考え方で、今後の学習効率が劇的に上がるような期待をしている。確かに、人は全知全能になれないし「何も完ぺきに出来ないと。」は無理な話で、全知全能はインターネットに任せればいいのだ。っていう。

  • 理解できなかった章

とくに感じなかった。前著「魔法の世紀」よりもだいぶ易しく執筆されており、いきなり話が飛んだりするようなこともなかったと思う。

  • 仕事に活かせそうな知識

いつリストラされても、「業界がこう変わっているから、今度はこっちに賭けてみよう。」という態勢を全員がとれるようになっているのが望ましい。

 転職などについては柔軟な考えを持っているほうだと思っていたが、うまく考えていたことと一致していた。会社の寿命は昔と比べて圧倒的に短いし、このように「次はこっちがおもしろそうだから、こっちに就職してみる。」ぐらいの就職観を持つと良さそう。

 

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

 

 

読書感想文のクセをつけようと思う

いろいろと本を読むのですが、まとめ作業をしないと頭に入った気がしないので読書感想文をきっちり書いていきたいと思います。

 

以下の記事を参考にして書いていこう。

ledsun.hatenablog.com

  • 概要(著作、著者、著者経歴)
  • 要約(150文字)
  • 面白かった章とその理由(400文字)
  • 理解できなかった章とその理由(200文字)
  • 仕事に活かせそうな知識、活かせそうな状況と活かし方(400文字)

読書感想文ってカテゴリつけて、そのカテゴリで文章を書き始めようとすると、作っておいた読書感想文のテンプレ構成が出てきて、大枠の下に文章書いていけばいいだけ。みたいにならないかな...。

 

そのへんはコピペとかめんどくさいし、自動化したい...。

JRA-VAN Datalabで得られるデータ数と特徴数

前回はPC-KEIBAを利用してエラーを回避しながらフルセットアップを終えたので、今回はそのテーブルを見ていこうと思います。

DLをやるかそうでないかを判断するときに、重要な指標が特徴数とデータ数だと思います。

CourseraのAndrew Ng先生もMachineLearningの授業で

「NNやるときは特徴数増やして過学習気味のモデルをビッグデータでちょうどいいところに持っていくのが一番精度が出る。」

というような事を仰っていました。

馬毎レース情報のデータ数

 

mysql> select count(*) from jvd_umagoto_race_joho;
+----------+
| count(*) |
+----------+
| 2244591 |
+----------+

224万4591件!

だいたいDLやるときには100万件以上のデータがあると好ましいとNg先生が仰っていたのですが、これだけのデータ数があれば十分ではないでしょうか。

DB全体でのカラム数

カラム数計測は、以下のメタフィールドを各テーブルの検索から除外の上で行いました。
・レコード種別ID
・データ区分
・データ作成年月日
・開催年
・開催月日
・競馬場コード
・開催回
・開催日目
・レース番号
・レコード作成時のタイムスタンプ
・レコード更新時のタイムスタンプ

SQLはこちら

select
table_name, 
column_name, 
column_type, 
is_nullable, 
column_key, 
column_default, 
extra
from
information_schema.columns
where
table_schema='pckeiba'
and
column_name not in ('INSERT_TIMESTAMP',
'UPDATE_TIMESTAMP',
'RECORD_SHUBETSU_ID',
'DATA_KUBUN',
'DATA_SAKUSEI_NENGAPPI',
'RACE_CODE',
'KAISAI_NENGAPPI',
'KEIBAJO_CODE',
'KAISAI_KAIJI',
'KAISAI_NICHIJI',
'RACE_BANGO');

2857 rows in set (0.01 sec)

3000弱の特徴数でした!

Windows10でも、PC-KEIBAでMySQLにデータ蓄積できた件

 

f:id:thunder-runner:20180202225435j:plain

要旨

System.OutOfMemoryExceptionはアプリを落として立ち上げなおすと治る。

 

筆者環境

  •  Windows10 Pro
  • CPU i7 32GB RAM
  • JRA-VAN Data Labのトライアルキットを利用したフルセットアップ

既存ソフトのOS対応にWin10がない

ほとんどのSQLデータ蓄積系ソフトの対応OSがWindows7, Vista, 8ぐらいまでで、唯一 JVData to SQLiteというソフトだけはWin10対応なのですが、まだバージョンが1.0.2で、実装されていないテーブル(マスタ)があるので出来れば完全なデータのものを利用したいと考えました。

(開発は陰ながら応援しております。)

 

そこで、Every-DBPC-KEIBAをWindows10環境でも利用できないかと試したところ、普通にやると途中でエラー

System.OutOfMemoryException

が出て続行不可能になりました。

 

原因は?

System.OutOfMemoryExceptionはメモリ割り当てに失敗するとスローされるエラーなので、SQLで大量に大きい処理を行うことでのメモリ不足が考えられます。

 

例外のトラブルシューティング : System.OutOfMemoryException

 

票数1の取得で起きやすいような気がします。

解決法は?

僕がとった解決法としては、単純にアプリをいったん閉じて再起動する。という手法です。すると強制的にメモリ解放されるので、再取得するとエラーが出たところをうまくパスしました。

 

成功時のキャプチャ画像。フルセットアップの最後のテーブルが馬名の由来

f:id:thunder-runner:20180209003605p:plain

 

PC-KEIBAの掲示板では、「プログラム互換性を利用することで何とか進みました。」みたいな投稿があるのですが、プログラム互換性を変更する際に再起動をしなければいけないので、それで結果的にメモリが解放されて上手くいったのでは。と考えられます。

 

時間はどれくらいかかるの?

約一週間程度

計測期間: 2018/2/3 ~ 2018/2/9

注意点

  • 結構頻繁にメモリ不足エラーが起きる。

ちょくちょく見ないとエラーで止まってました。みたいなのが結構あります。PowerShellからAutomationElementを使って再起動かけて取得を再開するスクリプトを作って自動化しようと思ったのですが、APIのクセの強さとドキュメントの少なさでうまくいかずに諦めました。なので、PCを時々確認するというアナログ手法で対応したました。基本的にはスクリプト対応が望ましいです。(確認するのがめんどくさいので)

 

  • SQLへの蓄積がうまくいく事と、データ欠損があることは違う

そもそも5年ほどアップデートが行われていないソフトなので、JRA-VAN Datalabの仕様変更などによる問題。ソフトそのものに生じた問題はそのままなので、データ欠損があったりして結局使えない可能性はあります。

 

  •  出走別着度数のセットアップ中に別のエラーに遭遇

同様に再起動によって解決しました。

最後に

どうしてもダメならスクラッチSQL保存ソフトを作る計画まで立てていたのですが、とりあえずは何とかなりそうな感じです。データの中身を見た結果をまた記事にしてみます。