2019-10-19

14週気づきと振り返り

業務こなしての問題・気づき
雑記

業務こなしての問題・気づき

Could not locate device support files

実機にビルド＆インスコしようとしたら、Could not locate device support files と出た。
エラー読む限り、デバイスのサポートファイルがないんだろうな～と思ったけど、どうやって対処したら良いのか分からなかったので調べた。

やることとしては、サポートファイルをAppleの公式サイトからダウンロードして、所定の位置に回答したフォルダを置くだけ。
macだからディレクトリって言うのかな？
どうでもいいけど、統一して欲しいよね、ＯＳごとに名称が違うの。

ファイルを取りにく場所は、下記

GitHub - filsv/iPhoneOSDeviceSupport: Xcode iPhoneOS DeviceSupport files (6.0 - 13.2)

解答したディレクトリを置くは、下記

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/

もしかしたら、Xcodeのアプリ名を変えている人がいるかもなので、そこは、適時読み替えて。
自分は、Xcode_<バージョン名>にしていたので、/Applications/Xcode_<バージョン名>.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/ だった。
現場で使ってるやつは、複数人と共有で使っていて、xcodeのバージョンが複数必要だったので、そうしてる。
オンリーワンなxcodeなら、一番最初に紹介したディレクトリでイケるはず。

参考サイト

【Xcode】実機で動かそうとしたらこんなエラーが出た時 - Qiita

callkitの実装

1ヶ月近く悩んでた。。。
ググってもいい情報が出てこないのがシンドい。
全部、一部分の実装だったりする。

いろいろ試して調べた結果、stack overflowで紹介されていたgithubのページで、サンプル実装していたページに辿り着いた。
それが、下記。

iOS-10-Sampler/CallKit at master · naandonov-mm/iOS-10-Sampler · GitHub

この中にある、CallkitManager.swiftを真似して実装した。
そうすると、すんなり実装できた。。。
たぶん、これを参考にする前は、providerやcontrollerのインスタンスをいっぱい作っていたので、制御できてなかったんだろうなと予想。

ググって情報探すってのがデフォルトだが、githubでサンプルコード探すってのも、視野に入れて探さないとダメな気がしてきた。
とくにサンプル実装となると、ブログに上がっているものより、一連の流れが実装されているコードをgithub内を探して方が、正確で実装しやすいものが見つかりそう。
今度からは、ググるで詰まったら、githubを探す習慣を身につけたい。

迷ったら問題を細分化

分かっているつもりでも、いざ実行ができてない。

初期開発で、callkitを入れ込んでたが、なかなか解決しなかった。
本来なら、callkitだけのサンプルプロジェクト作って、動きを学んでから取り込むように動けば良かった。
開発してたプロジェクトが複雑過ぎて、callkitだけを考えていればいい状態ではなかった。
俺の頭の性能の低さを、もっと自覚すべきだった。

雑記

英語ドキュメント読むようになって

swiftだから、基本英語でAPI読んだりしてる。
Google翻訳を使っているせいか、まったく英語のリーディングが伸びている気がしない。。。
なるべくGoogle翻訳使わないほうがいいのかもしれない。
単語調べるレベルで辞めておけば、英語のリーディングは上がるかな？
時間の成約が厳しくないのなら、試す。

週次の更新が滞った。。。

一回怠けてしまうと、そのままズルズル引きずってしまう。。。
習慣化できてなかったと、怠けてしまってから理解した。
特に、日曜に更新しようとすると、いろいろ言い訳を考えてしまい、結果、書かないになる。
記録を残すという習慣も、なおざりだった。
callkitでハゲそうになってたからかも知れないが、ネタのストックをする気が出なかったのがいたいな。

遊戯王デュエルリンクスでキングに昇格

やっとキングに昇格できた。
パーミ型の運命デスペ使ってたけど、すごい頭を使う。
止め時の見極めが面倒くさい。あと、勝ち急ぐと負ける。

キングになったはいいけど、キングで勝利数稼ぐのがシンドい。。。
100勝のウルレアチケットまで、遠いのがツライ。。。

2019-09-30

2019/09/23週気づきと振り返り

チーム開発環境学習日記恥晒し Swift

業務こなしての問題・気づき
雑記
- 新型switchの購入
- ポケモン関連の購入

業務こなしての問題・気づき

githubでpush済みのコミットの修正

git commit --amenda → git push -f

コミットを上書きして、それを強制プッシュするとできる。

IBAction

SwiftLintを適用して、変数名やメソッド名が大文字始まりだったので、リファクタリングした。
参照だけで動きに変更はないだろうと思っていたが、大文字から小文字始まりに変わったら、実行タイミングが変わった。

動きとしては、ボタンが押されたらsegueが動作するようなボタンだった。
大文字始まりのときは、IBAction→segueの実行になっていたが、小文字始まりに変えたら、segue→IBActionになった。

リファクタリングでメソッド名変えただけでも、きちんと動作確認をしないと、ダメなんだなって思ったのと同時に、なんで動作変わるんだ？ってものすごい疑問に思った。

Jenkinsで bundle command not found

Jenkinsでbundler使って pod install を実行しようとしたら、not found エラーになった。
bundlerは入っているから、見つからないはずないと思って見直したら、先頭行に #!/bin/bash -l がなかった。
追加したら動いた。

未だに #!/bin/bash の意味が分からないのだが、覚えたほうがいいのかな？

githubへのアクセス

sshだけかと思ったら、httpsでもアクセス可能。
今の現場は、sshの接続が制限されているらしく、相当悩んで居たが、httpsでgithubからcloneしたら、難なくできた。。。
半日悩んでいたのは何だったんだって思ってしまった。。。

テスト仕様書の作成

開発研究の現場なので、あんまりテスト仕様書を書く文化はない。
だけど、状態を持つようになってテストケースが複雑化したら、作らないと流石にやばい。
いろいろ作って終わらせても、あとで後ろから刺される。

個人的な感覚としては、５ケース以上になるなら、テスト仕様書書いたほうがいいと思う。
僕の脳みそでは、４ケースくらいしか覚えられない。
メソッドの引数と一緒。５個以上になると、途端に、何番目にどの値だったか分からなくなる。

雑記

新型switchの購入

増税前に駆け込み購入。
ゼノブレイド２とセットで購入した。
ホムラ／ヒカリが可愛いなと思って購入したが、いつ出てくるんだ？
出てくる前に挫折してしまいそう。

ポケモン関連の購入

増税前に駆け込み購入その２
６期から３Dになったので、やるのを辞めたけど、やすかったから買ったポケモンＸが面白かったから、ウルトラサン・ピカブイ・時の探検隊を買った。
メガシンカは、敬遠してたけど、リザードンＸで無双するのは、楽しかった。
まだ、ウルトラサンやり途中だけど、メガシンカ並の楽しみはあるのかな？

ピカブイは、処理落ちが酷いとは聞いていたけど、かなり頻発するから、予約した剣盾がものすごく心配。。。
たぶん、エンカウントとあるき始めるとポケモンに乗るってのが処理落ちを発生させているのではないかと思う。
フィールドがでかいトキワの森は、エンカウントによる処理落ちだと思う。

時の探検隊は、１０００円以内で変えるから買った。
不思議のダンジョンは、結構好きで、初代のポケモン不思議のダンジョンが面白かったのを思い出して買った。
まだやり途中。
switchで何か出すのかな？
先にトルネコ４を出して欲しい。

2019-09-22

Vue.js + electron + その他もろもろの環境の構築

JavaScript プログラミングライブラリ情報収集日記学習開発環境

きっかけ
環境
- Visual Studio Code
- npm
前準備
環境構築
感想
参考サイト

きっかけ

react + electronにしようか、angular + electronにしようか、いろいろ悩んだけど、一番楽に始められたvue + electron + element-ui に落ち着いたので、まとめる。
なお、自分向けなので、端折ってあるところがある。

環境

Visual Studio Code

バージョン: 1.38.1 (system setup)
コミット: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
日付: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

npm

$ npm -v
6.4.1

前準備

vueの環境構築として提供されているCLIを導入する。
自分で１から構築すると面倒なので、楽な手段に頼る。

$ npm install -g @vue/cli

自分は、v3.11.0が入った。

$ npm -g ls --depth=0
C:\Program Files (x86)\Nodist\bin
…
+-- @vue/cli@3.11.0
+-- @vue/cli-init@3.7.0
…

環境構築

プロジェクト作成

$ vue create my-app

いろいろ聞かれるので、お好みで入れる。
僕は、manualでjs形式のプロジェクトを作成した。
前はtypescriptだったけど、最近は、環境構築面倒だからjsでいいやって感じになってる。
jsに慣れてしまうと、typescriptに戻ろうという気が起きないから不思議。

electron-builderの追加

このままだと、ただのvueプロジェクトなので、electronを追加する。
具体的には、下記のコマンド。

$ cd my-app
$ vue add electron-builder

動作確認

ここまでやると、とりあえずデモアプリが動かせるようになる。
なので、テストを兼ねて動かしてみる。

$ npm run electron:serve

コマンドが長いので、毎回打つのが億劫な人は、package.json の scripts に、"start": "npm run electron:serve",を追加すると、次からnpm start で動かせるので楽かも

その他オススメの設定

element-uiの導入

element-uiは、高機能なUIパーツが使えるようになるコンポーネント詰め合わせライブラリ。
ちまちまコンポーネント作る手間が省けて、かつ、いい感じのコンポーネントが使えるようになるのがいい。

$ npm install element-ui -S

インストールが終わったら、main.jsにelement-uiのコンポーネントを読み込ませる設定を追加する。

import ElementUI from "element-ui";
import locale from "element-ui/lib/locale/lang/ja";
import "element-ui/lib/theme-chalk/index.css";

Vue.use(ElementUI, { locale });

あとは、vueファイルにコンポーネントを追加すれば、使えるはず。

設定ファイルを導入したい

electron-store を導入する。

https://github.com/sindresorhus/electron-store

設定ファイルは、デフォルトだと、C:\Users\<ユーザ名>\AppData\Roaming\<プロジェクト名>直下に、config.jsonができる。

プロジェクト直下にファイルを作って読み書きさせたいのだが、できないのかな？

感想

router.jsが、最初に見たときは、意味分からなかったけど、strutsで言うところのstruts-config.xmlかと思うと、結構、納得した。

element-uiが、意外とデザインが良くて気に入ってる。
最初作り始めると、デザインのダサさで四苦八苦してたけど、これ使えばそこそこの見た目でできるから、不要なところで悩む必要ないなと感じた。

参考サイト

Vue.jsのコンポーネント詰め合わせ「Element」がスゴかった | 綺麗に死ぬITエンジニア

Electron+Vue.jsを使ったデスクトップアプリ開発を始める手順

Electronで設定ファイルを導入 - Qiita

2019-09-21

【読書ノート】プログラミング作法

学習書評

きっかけ
まとめも
感想

きっかけ

どこかでオススメ書籍として紹介されていたから、ぱら見で良さそうだったので購読することに。

まとめも

スタイル

名前

グローバルには分かりやすい名前を、ローカルには短い名前を
- 命名の統一性を重視
- 関数には能動的な名前を
- 名前は明確に

【個人の感想】
重要そうなところを抜き出したけど、ローカル変数名の命名には、若干反対である。
使っていいのは、慣例的に短いのを使うところだけだと思う。（for文のiとか）
ローカル変数でも、ある程度の分かりやすさは必要だと思う。
スコープ範囲にもよるが、だいたいコードは肥大化するものなので、短すぎる名前をつけて後々公開するようなら、最初から明瞭さを重視した方がいいと思ってる。

式と文

構造が分かるようにインデントする
- インデントがあることで構造が分かりやすくなる
自然な形で式を使う
- 条件式に否定を使うと、間違いが分かりにくくなる
括弧を使って曖昧さを解消する
- 演算子の優先度の迷いを断ち切る
複雑な式は分割
- 演算子が大量にあると、意図が分かりづらくなる
明確に書く
- 小賢いコードを書くやつはド三流
副作用に注意

【個人の感想】
俺流に味付けしてまとめた。
小賢いコードを書くやつはド三流 は、なかなかのネーミングだと思ってる。
ハガレンの１話の神父に対して言った降りて来いよド三流から発想を得た。
たまに、小賢しいコードをマジで書くやつが居るから、困ったもんだ。
俺は、学生のときにそうなりかけたけど、小賢しいコードのせいでコードが読みづらいことに気づいて辞めた。

一貫性と慣用句

インデントとブレースのスタイルを統一する
- ブレース＝波括弧。ここでいいたいのは、if ~ else で、波括弧の位置をどうするかって意味
慣用句を使って一貫性を保つ

【個人の感想】
慣用句って、何をもって慣用句とするのだろうな？
それは、お前の中の常識であって、他の人は違うよ？って言われたら、何を信じていいのか分からなくなりそうな気がしないでもない。
こういうのは考えるのが面倒くさいから、フォーマッタを導入して機械的にやるほうが楽だと思う。

関数マクロ

Cの記述ばっかりだったので、スルー

マジックナンバー

マジックナンバー＝プログラム中に登場する数値

マジックナンバーには名前をつける
- 用途を明確にする
マジックナンバーは定数化

【個人の感想】
マジックナンバーは、マジで有害だから、存在させないようにするほうが吉。
あと、マジックナンバーを定数化するときに、two = 2 みたいに命名するアホを見たときは、絶句した。
定数化する意味がないから、名前のところを読めって言いたくなる。

当たり前のことは書かない
- プログラムの理解を助長するものを書く
関数とグローバルデータにはコメント
可読性の悪いコードは、コメントで補完するより書き直す
コードとの矛盾を避ける

【個人の感想】
日本だと、可読性の悪いコードは、コメントで補完するより書き直す は許されない傾向にある気がする。
必要最低限の改修だけしろとよく言われる。
その流れになったのは、無能なコーダーが上位の役職についているからだと思うんだよね。
もしくは、その可読性最悪のコードの影響を理解していないとか。
どっちにしろ、無能が上にいるってことは変わらないな。

アルゴリズムとデータ構造

データ量が少ない→単純なテクニックでやる
データ量が増大する→スケールアップ可能な設計にする
高度なテクニックは、実際に計測するまで使わない方が無難

設計と実装

設計＝言語によらない

インタフェース

サービスを提供するコードと、利用するコードの境界にある
実装の詳細を隠蔽する
- 利用者への影響を少なくする
- 実装の交換が容易になる
直行性のある小さな単位を選択する
- 必要以上の機能を提供するのはＮＧ
  - 管理が面倒になる
  - 使いこなすのが難しくなる
- 必要十分なものを規定する

デバッグ

バグを埋め込みやすいパターンを探してみる
バグ対応は、横展開とセットで
スタックトレースをよく読み、原因を特定するまでは、修正してはいけない
他人に説明してデバック

バグへの対応

再現させる
ログファイルを出力
UML書いてみる
printデバッグ

テスト

デバッグ＝テストではない
- デバッグ＝コードに問題があるときにすること
- テスト＝プログラムを破綻させるためにする作業

コーディング時のテスト

境界条件テスト
実行前後の変化を検証する
アサーション
ありえないケースへの対応も考えておく（防御的プログラミング）

系統的なテスト

テストは１個ずつ段階的にやる
- ビッグバンテスト→破綻する
単純な部品からテストする
- 複雑な箇所からやると、バグの修正が難しくなる
期待値は明確にする

テストの自動化

大量のテストは、注意力が散漫になり、労力もかかる。
テストを自動化して、いつでも気軽に頻繁にテストできるようにすることは、十分に価値がある。

性能

測定→検証のサイクルが基本
ベンチマークの結果は、政治的意図があるので、結果は割り引いて考えておく

移植性

環境に依存することなく動作させる理想のこと

移植性が必要な理由

動作環境が決まっていることが少ない
環境は変化する
移植性があるものは優れたものが多い
- やりすぎは厳禁

言語

標準にこだわる
- 移植性を高くしてくれる
王道プログラミング
- 専門用語が出てくるのは、王道ではない
- 確率されたスタイルをなるべく使う
言語のトラブルスポットに注意する
- 演算子の評価順
- 算術／論理シフト

【個人の感想】
「王」って単語に反応しちゃう

隔離

システム依存は別ファイルに移動し、インタフェースで隠蔽

データ交換

なるべくテキスト
- 扱いやすい
- 見やすい
- 手作業で変更可能
- バイナリ使う際は、固定バイト順にする

移植性とバージョンアップ

仕様を変えるなら名前を変える
- 解釈が変わる→意図的に別のソフトウェアが生まれるようなもの
- 仕様が変わる＝意図しない移植上の問題が発生する可能性が高い
後方互換を維持する
- 手段が変わる＝影響範囲大
- 非互換性は、コストと相談

国際化

英語を前提にしない
- 漢字等が入れば、文字サイズも変わる
- エラーメッセージに業界用語や特定言語のスラングはやめる

感想

ところどころ端折ったが、既存の考えと大筋変わらない。
古典っぽい内容だったな～というのが正直な感想。
リーダブルコードで事足りそうな気がしないでもない。

2019-09-16

Angular + electron の環境構築

HTML/CSS FW プログラミング情報収集学習開発環境

きっかけ
環境
実証
参考サイト

きっかけ

electronでUIフレームワークで何かいいものないかと探して、react／vueにたどり着いた。
しかし、さっぱり動きが分からない。
理解し難い。
それなら、以前使ったAngularならイケるだろうと思い、調査して、とりあえず連携させるまでできたので晒す。

環境

VisualStudioCodeのバージョン情報で事足りそうだったので、逐一コマンドは打って貼付はしない。

バージョン: 1.38.1 (system setup)
コミット: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
日付: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

実証

流れ

angularの実行環境準備
electornのインストール
main.jsの作成
Angularの設定変更
実行スクリプトの準備
実行

angularの実行環境準備

下記のコマンドを実行

npm install @angular/cli -g

プロジェクト毎にインストールメリットを感じなかったので、グローバルインストール。

インストールが終わったら、Angular用のプロジェクトを下記コマンドで作成する。

$ ng new angular-electron-demo

electornのインストール

Angularのもろもろの準備が終わったので、作成したプロジェクトに移動して、electronを入れる。
セキュリティを考慮して最新版を入れたが、何か特定のバージョンに思い入れがあれば、指定する。
※動作確認はしてないので、問題は各自で解決してね。

$ cd angular-electron-demo
$ npm install --save-dev electron@latest

自分の実行環境では、6.0.9が入ってきた

main.jsの作成

プロジェクトディレクトリ直下（package.jsonがあるディレクトリ）に、main.jsを作成する。

中身は、electronのquick-startからパクったやつ。

const { app, BrowserWindow } = require("electron");
const url = require("url");
const path = require("path");

let mainWindow;

function createWindow() {
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true
    }
  });

  mainWindow.loadURL(
    url.format({
      pathname: path.join(__dirname, `/dist/index.html`),
      protocol: "file:",
      slashes: true
    })
  );
  // Open the DevTools.
  mainWindow.webContents.openDevTools();

  mainWindow.on("closed", function() {
    mainWindow = null;
  });
}

app.on("ready", createWindow);

app.on("window-all-closed", function() {
  if (process.platform !== "darwin") app.quit();
});

app.on("activate", function() {
  if (mainWindow === null) createWindow();
});

Angularの設定変更

angular.jsonを開いて、出力先のパスを合わせる。

projects → angular-electron-demo → architect → build → options → outputPath の値を、dist/angular-electron-demo から dist に変える

  "projects": {
    "angular-electron-demo": {
      "projectType": "application",
      "schematics": {},
      "root": "",
      "sourceRoot": "src",
      "prefix": "app",
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist",

次に、package.json を開いて、実行するjsファイルを指定する。
"main": "main.js", を追記して終わり。

{
  "name": "angular-electron-demo",
  "version": "0.0.0",
  "main": "main.js",

実行スクリプトの準備

Angularのビルド→electornの実行の順で実行するためのスクリプトを下記の通り追加。
※start:electronを追記する

  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e",
    "start:electron": "ng build --base-href ./ && electron ."
  },

実行

さっき追加したスクリプトを下記の通りに実行する。

$ npm run start:electron

そうすると、下記の画面が出てくるはず。

f:id:suzaku0914:20190916180350p:plain

今回のソース

GitHub - suzaku-tec/angular-electron-demo

雑記

react、vueより扱いが簡単だといいな。。。

windows10って、print screen使えなくなった？
キーを叩いてもスクショがとれてなくて、結構、焦った。
snipping toolに移管していくつもりなのだろうか？

参考サイト

Electron with Angular 8|7 Tutorial | Techiediaries

Build Electron Desktop App with Angular 8 | Electron Angular Tutorial

2019-09-15

2019/09/09週気づきと振り返り

思ひ出日記愚痴 Swift UI/UX

業務こなしての問題・気づき
- callkit の CXProvideDelegate
- stack viewで表示しきれない
その他雑記

業務こなしての問題・気づき

callkit の CXProvideDelegate

すべてのイベントがハンドリングできるわけではない。

CXCallObserverDelegateで監視してやる必要がある。
着信画面の応答・拒否は、CXCallObserverDelegateでしかハンドリングできない。

CXCallObserverDelegate → call（CXProvideに状態の変化を伝えるメソッドを叩く） → CXProvideDelegate の流れがcallkitを開発した人が目論んでる流れだと思う。

stack viewで表示しきれない

stack viewで表示しきれない場合、scrollviewを使って、スクロールで表示できるようにする。

scroll -> stack -> ~ で実装すると、いい感じにできる。
iphone XRだと問題ないのだが、SEで表示ができず、レイアウト配置で相当悩んだ。
逆に考えるんだ、「出せなきゃ出さなきゃいいのさ」と考えて、この対応を考えた。
やっぱり、ジョジョは偉大。

その他雑記

カフェイン

最近分かったが、俺は、どうやらカフェインに過剰反応するらしい。

コーラを飲んだだけで、眠れなくなる。
夕食のときにコーラを飲んでしまうと、２時位まで寝付けないという事象が発生するのが、最近になって分かった。

ちなみに、コーヒーを飲むと、過剰反応で頭痛と下痢になる。
たぶん、血管が収縮して、血液が周りにくくなって酸素が回ってないから頭痛になるんじゃないかと予想。
下痢は、分からん。

腕時計

昔、腕時計を買ったのだが、全然身につける習慣がなくて、もったいないから、最近なるべくつけるようにしている。
そしたら、腕時計を付けたところが青ざめるんですけど、アレルギー反応なのかな？
出社するまでの１時間くらいで、うっすら青ざめてムッチャ怖いんですけど。。。
痒くなるし、変色するし、汗でベタつくから不快なんだよね。。。

仕事中は外してる。
使うのは、資格試験のときの時間確認くらいでしか利用したことがない。

これは、俺にアップルウォッチを買えというお告げなのうだろうか？
スマホは、Androidなんだけど。。。。