エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

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

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

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

git commit --amendagit 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の接続が制限されているらしく、相当悩んで居たが、httpsgithubからcloneしたら、難なくできた。。。
半日悩んでいたのは何だったんだって思ってしまった。。。

テスト仕様書の作成

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

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

雑記

新型switchの購入

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

ポケモン関連の購入

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

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

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

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

きっかけ

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を導入する。
自分で1から構築すると面倒なので、楽な手段に頼る。

$ 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.jsonscripts に、"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

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

きっかけ

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

まとめも

スタイル

名前

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

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

式と文

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

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

一貫性と慣用句

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

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

関数マクロ

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

マジックナンバー

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

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

コメント

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

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

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

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

設計と実装

  • 設計=言語によらない

インタフェース

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

デバッグ

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

バグへの対応

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

テスト

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

コーディング時のテスト

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

系統的なテスト

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

テストの自動化

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

性能

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

移植性

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

移植性が必要な理由

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

言語

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

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

隔離

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

データ交換

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

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

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

国際化

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

感想

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

Angular + electron の環境構築

きっかけ

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

実証

流れ

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

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/09週 気づきと振り返り

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

callkit の CXProvideDelegate

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

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

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

stack viewで表示しきれない

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

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

その他雑記

カフェイン

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

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

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

腕時計

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

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

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

また増えた

今週で、とうとう32歳ですわ。
来年でゾロ目だな。

2019/08/26週 気づきと振り返り

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

Swiftのlazy

クラス変数をOptionalにしたくないときに使う。
singletonみたいな使い方ができる。
遅延実行の方が近いかもしれない。

参考サイト

【Swift4.1】lazyプロパティの使い所 - Qiita

【Swift】レイジ―プロパティ(lazy)の使い方。最初にアクセスされたときに初期値が決まる。 | はじはじアプリ体験記

複数人開発でのStoryboardの使い方

複数人で開発する場合、画面ごとに分けたほうがいい。
競合が多くなり、開発効率が悪化するので、人数が増えてきたら考慮の余地がある。

参考サイト

【Xcode】Storyboardを複数に分割して管理する方法 - Qiita

多人数でのiOS開発におけるStoryboardとの向き合い方(1画面1Storyboard) - machio Development Diary

[iOS] チーム開発するなら Storyboard を分割セヨ | DevelopersIO

swiftのtableviewで、storyboardとコードの住み分け

コード回避可能なものは、なるべくコードで定義。
storyboardで何でも解決しようとすると、黒魔術化して、自分があとで分らなくなる。 見た目は、storyboard、ロジックはコードで実装するのが、一番分りやすいと思う。

Java13リリース前の予習(Text Blocks深堀)

きっかけ

前回記事でJava13の調査したけど、後々になってTextBlocksに疑問が湧いてきたので調査した

過去記事は、書きを参照

suzaku-tec.hatenadiary.jp

355: Text Blocks (Preview)

JEP 355: Text Blocks (Preview)

ダブルクォートだけを表示させたらどうなるか?

テストコード

public class Jep355Sample2 {
  public static void main(String[] args) throws Exception {
    String str = """"""";
    System.out.println(str);
  }
}

期待値

「"」だけが表示される。

答え

$ javac --enable-preview --release 13 Jep355Sample2.java 
Jep355Sample2.java:3: エラー: テキスト・ブロックの開始区切り文字のシーケンスが無効です。行の終了文字がありません
    String str = """"""";
                    ^    
Jep355Sample2.java:3: エラー: テキスト・ブロックの開始区切り文字のシーケンスが無効です。行の終了文字がありません
    String str = """"""";
                       ^

コンパイル時に怒られた。。。

Descriptionをよく読むと、The opening delimiter is a sequence of three double quote characters (""") followed by zero or more white spaces followed by a line terminator. とある。

Google翻訳よ、おらに力を分けてくれ~」と思いながら翻訳すると、「開始区切り文字は、3つの二重引用符( "" ")の後にゼロ個以上の空白が続き、行終端文字が続くシーケンスです。」となる。

期待値通りの出力をするには、下記に変えると行ける。

public class Jep355Sample2 {
  public static void main(String[] args) throws Exception {
    String str = """ 
    " 
    """;
    System.out.println(str);
  }
}

テキストブロックに\nを入れたらどうなるか?

public class Jep355Sample3 {
  public static void main(String[] args) throws Exception {
    String str = """
    hello\nSaga!!
    """;
    System.out.println(str);
  }
}

何を表示させようかと迷ったら、とりあえず佐賀。

期待値

そのまま、「hello\nSaga!!」が表示される

答え

$ java --enable-preview Jep355Sample3
hello
Saga!!

改行されるだと。。。

Descriptionをよく読むと、たしかになんか書いてある。

The content may include line terminators directly, unlike the characters in a string literal. The use of \n in a text block is permitted, but not necessary or recommended. For example, the text block:

"""
line 1
line 2
line 3
"""

is equivalent to the string literal:

"line 1\nline 2\nline 3\n"

or a concatenation of string literals:

"line 1\n" +
"line 2\n" +
"line 3\n"

If a line terminator is not required at the end of the string, then the closing delimiter can be placed on the last line of content. For example, the text block:

"""
line 1
line 2
line 3"""

is equivalent to the string literal:

"line 1\nline 2\nline 3"

ざっくり読むと、「書くこともできるけど、非推奨」的な感じだと思う。
わざわざ「\n」入れるより、改行したほうが楽だろうってことだろうね。。。

たぶん、ほかのエスケープ系の文字も同様の扱いになっている気がする。

疑問

どこでインデントがきまるの?

    String str = """
    hello Saga!!
    """;

上記の実行結果は、下記になる。

$ java --enable-preview Jep355Sample4
hello Saga!!

本来なら、文字列の前にインデントようの空白があるのだが、なぜか表示されない。
意図通りだからいいんだけど、どういうルールなのか気になった。

さっきよりインデントを増やしたら、どうなるのか試したら、今度は、追加したインデントが表示された。

    String str = """
      hello Saga!!
    """;
$ java --enable-preview Jep355Sample4
  hello Saga!!

インデントの位置は、たぶん、もっともインデントが少ないところがベースになるのだろうと予想。

dependenciesをよく読んでいると、2. Incidental white space に、なんかそれっぽい記述がある。
どうも、インデントの決定は、開始の"""以降の最小のインデントで決まるっぽい。

タブ文字は、1文字とカウントされるっぽいので、インデントに使う文字列を統一してないと、予期せぬレイアウト崩れになりそう。
TextBlocksのところだけインデントが1行ごとに違うとかは、面倒くさいから誰もやらないとは思うが、Javaのユーザ数は多いから、居そうだな。。。