読み込もうとするHTMLがないから起こってるっぽい。
原因がよく分からないが、Android Studioのインスタントランが原因っぽい。
おそらくだが、ビルド後に配置される場所に、何らかの操作で消したが、Android Studioが差分を検知できなかったため、再配置されず、起動時にエラーになったと思われる。
たぶんね、ファイル移動をしたような、しなかったような記憶がある。
インスタントランを停止して再ビルドしたら、動作した。
これで半日悩み続けましたわ。。。
縦長ディスプレイが現場に欲しい。
ピボットできるディスプレイでも可。
ドキュメント見るときに、多くの情報が見れる縦長の方が、楽チン。
ワイド１縦長１のデュアルディスプレイが、開発には最適だと個人的に思ってる。
win8.1で、以下のコマンドで確認できる。
gradlew app:dependencies
別プロジェクトで作られたサンプルを、今のプロジェクトに適用させようとした際に、依存関係がぶつかり会いすぎて、一覧にしないと分からないから使った。
もう、依存関係をスルッと解決する方法はないのかな？
このコマンド実行する場合は、プラグインが必要になる。
com.android.support が競合する。
これは、しょうがないものらしい。。。。
基底のＦＷだからだろうか？
いまいち、腑に落ちなかった。
ＴＴＳを再生する機能を作っているのだが、前日まで音声が出てたのに、当日使えなくなって焦った。
単純にミュートになっていただけだった。。。
こんなしょうもないことで、半日潰してしまった。。。
俺が何かソースを変えてしまったか？ってかなり疑ってた。
ちゃんと動いた時点でGit管理しておけば、もっと早くに疑念を持ったかも知れない。。。
ローカルでいろいろやるにしても、何かが確定した時点で、ＶＣＳにツッコむべきだと思いました。
先週の続き。
手順書に書いてないと思ったら、情報が散らばっているだけだった。。。
よくよく読むと、解決できないこともない。
でもさ、こういうのって、読み手に優しく書くものじゃないの？
情報が分散するのは、手順書としてはダメな方だと思うわ。
ガンプラの組み立て説明書を手本にしなさいと言いたい。
ミニ四駆でも可。
もう、頭ハゲそう。。。
あっちを解決したと思ったら、こんどは別の場所で衝突したり、モグラたたきやっているようだった。
全部解決して、いざ動かすと、動かないという仕打ちを受けると、心が砕けそう。。。
先週は、書くネタが思いつかなかった。。。
androidで社外で開発されたプロジェクトを開いた際、プロキシを設定する必要があることを忘れていて、半日潰してしまった。。。
リポジトリに存在していることや、ping打ってみたりして、ネットワークの設定がおかしいのは気付いたのだが、プロキシまで考えが及ばなかった。。。
気づかなかった要因は、gradle.propertyだったかが存在してないから、プロキシの設定のことを失念していた。
まぁ、言い訳ですけど。。。
手順書で、「適時」って書くの、マジでヤメろ！
何が必要なのか、さっぱり分からない。
書いたやつは、クレーム入れて欲しいマゾヒストなのか？
手順書なのだから、判断を読み手に与えるように書いちゃダメでしょう。
クレームの入れ先が社外になるので、安易に入れられないのが腹立たしかった。 もう、適時って書いてあったら、次は発狂するかもしれない。
書いてて思ったが、もしかして、俺ってヒステリック？？
普通のことだと思いたい。
backgraound-imageで、urlにタイポで存在しないURLを打った。
実行時にエラーがでないから、なんでロードされないのか、かなり悩んだ。
キャッシュのせい？とか思っていろいろ調べたが、最終的にタイポだって気付いた。。。
まず最初に、タイポを疑うべきだったな。
というか、エラー吐かれないから、タイポの可能性を排除してしまった。
実行時にcssで不正があったらエラー吐くようにする機構はないものだろうか？
gitで修正を入れて、submoduleの参照先を別コミットIDにした時、完了したらコミット前にお花を摘みに行った。
戻ってきたら、コミット＆プッシュを実行したが、「gerritにレビューが上がってない？なんで？」って思って、コンソールを徐々に上に辿って行ってかなり焦った。
submodule内のプロジェクトに移動してコミット＆プッシュしていた。。。
全然関係ないプロジェクトにプッシュしてしまったという事実をしったときの怖さは、半端ない。
gerritに上がっただけなので、取り消しができたのでよかったが、gerritない環境でやっていたら、いろんな人に頭を下げなければいけないところだった。。。
謝ることに抵抗があるので、次からは、マジで気をつける。
twitterの俳句バージョンあればワンチャンいける？
ノートにボールペンを使って書いていると、インク出なかったりしてイライラする。
調べてみたが、ボールペンの構造と書く環境に問題がありそう。
ボールペンの先は、ボールが回転することでインクが出ている。
そのため、柔らかい場所に書く際、ボールが回転せずにインクがでないことがあるらしい。
そういえば、メモ帳をテーブルのうえで書く時、かすれたことはないな。
ということは、下敷きをすれば、万事解決になるのだろうか？
なんか、小学生っぽい気はするが。。。
家に下敷きあるんだけど、だいたいアニメのキャラが書かれてるんだよね。。。
無地のやつを１００均で買うしかないかな？
もしくは、万年筆に移行か。。。
試しに万年筆を使ったのだが、インクが滲む。。。
あれって、俺の筆圧が強すぎるせい？？
こう見えても、チームの長なもので。。。
メンバーのスキル評価を実施した。
話を聞いていると、漠然と作業をしているなって感じる。
話を聞いていると、かなり抽象的で、知見が溜まってないんだろうなって感じる。
おそらく、会社がワーカー（作業者）として働くことを評価してしまっているせいだろうなって思った。
作業者として優秀かもしれないが、エンジニアとしては良くない傾向だと思う。
そもそも、ＩＴ業界って、ワーカーみたいなのが多い気がする。
たぶん、下請け構造がワーカーには住みやすいのだろうと思う。
とりあえず、当面の目標は、このワーカー体質を脱却させて、ちゃんとエンジニアとして働くように意識を変えてやる必要があると思いました。
workerからenginerへのジョブチェンジを促すしかない。
少なくとも、何か作業をしたら、知識だけではなく、何か知見・知恵となるように考えを巡らせる方向に持っていきたい。
だから、評価時に具体的な考えが見えてくるまで、質問を深掘りするしかないなと思いました。
会社もワーカーを評価する体質から脱却させないと、いつかはダメになる気がする。
提案？提言？みたいなことをするべきだろうか？
俺は、あんまり自社が好きじゃないんだけど、どうすべきかな？
論文みたいなのを書いて提出してみようか？
もう、嫌。
いろんなところでストレスを感じる。
まず、ペンが持ちにくい。使ってると、ものすごい手が痛い。
インク切れが早いのもストレスを感じる。インク売るために、ワザと減りを早くしてない？とすら感じる。
消せるボールペンって売れこみで愛用してきたが、最近、使うことにかなり疑問を感じるようになった。
よくよく考えたら、俺って文字を消すケースがほとんどないじゃんって最近気付いた。
消えないボールペンで問題ない気がしているんだよね。
そろそろリリースだなと思い、リリース前に予習したくなったから
JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
JEP 325: Switch Expressions (Preview)
JEP 340: One AArch64 Port, Not Two
JEP 344: Abortable Mixed Collections for G1
JEP 346: Promptly Return Unused Committed Memory from G1
google翻訳かけてサマっただけですが。。。
開発者として影響がありそうなのは、JEP 325かな？
switch文死ねマンからすると、あまり気にならないが。。。
Docker使って試しました。
Kitematic使って、Java12環境を構築した。手っ取り早くやれるので、かなり便利
docker version Client: Version: 18.03.0-ce API version: 1.37 Go version: go1.9.4 Git commit: 0520e24302 Built: Fri Mar 23 08:31:36 2018 OS/Arch: windows/amd64 Experimental: false Orchestrator: swarm
つかったコンテナは、alpine-java12 ってやつ。
https://hub.docker.com/r/pwittchen/alpine-java12
# java -version openjdk version "12-ea" 2019-03-19 OpenJDK Runtime Environment (build 12-ea+29) OpenJDK 64-Bit Server VM (build 12-ea+29, mixed mode, sharing)
とりあえず、公式にあるやつをパクって試す。
import java.util.Calendar;
import static java.util.Calendar.*;
public class JEP325 {
public static void main(String[] args) {
int day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);
switch (day) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
case TUESDAY -> System.out.println(7);
case THURSDAY, SATURDAY -> System.out.println(8);
case WEDNESDAY -> System.out.println(9);
}
}
}
曜日の定数を作るのが面倒だったので、Calendarクラスをstaticインポートした。
実行は、下記の手順で実施
$ java --enable-preview --release 12 JEP325.java $ java --enable-preview JEP325 6
実行したのが、日曜なので、ちゃんと動いているっぽい。
肝は、break要らないってところだな。
breakで泣かされたことがある身としては、進歩したなとは感じるが、やっぱり、利用する気にはなれない。
公式サイトを読み進めると、「値も返せるぜ！」的なサンプルあったので、ついでに試す。
import java.util.Calendar;
import static java.util.Calendar.*;
public class JEP325_2 {
public static void main(String[] args) {
Integer day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);
int j = switch (day) {
case MONDAY -> 0;
case TUESDAY -> 1;
default -> {
int k = day.toString().length();
int result = f(k);
break result;
}
};
System.out.println("switch result. j:" + j);
}
private static int f(int k) {
return k + 100;
}
}
$ java --enable-preview --release 12 JEP325_2.java $ java --enable-preview JEP325_2 switch result. j:101
普通に動作する。
当然の動き。
Java12のリリースでは、特に注目している機能はないが、リリースは予定通り行われそう。
直近のリリースで、switch文の改修がかなり入ってくるのは、switch文に熱心な人がコミッターにいるのかな？
switch文押しが強いことに驚く。
GC周りの知識不足が否めない。。。
どうやって学習したら良いのだろうか？
試してみて、Docker&Kitematecが便利だったってのが印象に残りました。
あと、久しぶりにstaticインポート使ったなって思った。
webアプリで開発した資産を、Androidへ簡易的に移植するためwebviewを使っている。
いい案かも知れないと思ったが、パフォーマンス計測していると、省メモリがかなりネックだというのが分かってきた。。。
併用はできるが、メモリの制約が問題になってくる。
実は、簡単そうに見えて、あとあとコストが高く付きそうな気がする。。。
chromeでPerformanceのタイムラインを取っていたのだが、１時間位でアプリがよくクラッシュする。
どうも、メモリを結構逼迫させるみたい。
なので、短時間の計測に使うが良さそう。
長時間稼働させて計測するのなら、スナップショットをチマチマ取るしかない。
ただ、chromeのスナップショットって、どこに問題があるのか、分かりづらいんだよね。。。
開発環境で使ってるサーバーが落ちて、２～３時間、開発がストップした。。。
本当は、開発環境も冗長化する必要があるのだろうか？
ipadを最近落として、画面に盛大にひび割れが入ってしまった。。。
電子書籍見るのをスマホにしたのだが、かなり見づらい。
やっぱり、タブレットが電子書籍読むのに適していると感じた。
デスクトップだと、場所を選ぶから、やっぱり、タブレットがいい。
近々、新型のipadが公開されるみたいな話があるから、買うのは、それまで待とうかな？
あと、ゲームするのも、タブレットがいい。
スマホだと小さすぎる。
デュエルリンクスやってると、カード操作を間違うのが痛い。
簡単にできるだろうと思ってたことで、結構つまづいたので、晒す。
普段、仕事でJavaScript使ってるけど、どっちかというとネットワーク関連のことばっかりやっている。
プロキシ食わしたり、リトライ処理やったり、Oauth認証したり。。。
ファイル入出力は苦手なんだなって、今になって気づいた。
使ってるとこだけ抜粋
const fs = require('fs');
// 省略
fs.readFile(path, "UTF-8", (err, data) => {
if (err) {
console.log("read err.", err);
return;
}
console.log(data)
})
調べるとたいしたことはなかったんですけどね。。。
一番ハマったのは、文字コード指定してなくて、予期しない文字が出てきてビックリしたことくらい。
require使って読み込むことも考えたけど、以前にキャッシュされるような話を聞いて、今回のケースだとキャッシュ使わせたくなかったから、fs使った。
想定外のことがおこると、やっぱりビックリしちゃうのは、初心者のころも今も変わらないな。
いろいろ計測しているのだが、なぜかmajor gcが起こらない。
おそらく、メモリの割当が、ブラウザで見るのと違っているのだろうと思われる。
たぶん、Java側が割り当てたメモリを使ってるんじゃないかな？
Javaのメモリ使用量見ても、全然増えてなかったし。
メモリの割当が小さすぎて、newの領域がすぐ満杯になり、mainor gc が頻発して、major gcが起こりにくいと勝手に妄想してる。
API見る限り、とくにメモリの設定はないな。
もう、どうしたらいいんじゃ。。。
はぁ。。。
今週も成果ゼロですわ。。。
どこかで、「大豆腐ってる」って文章を見たとき、「おおどうふってる」って読んでしまった。
正解は、「だいずくさってる」だって気づくのに、かなり時間を要した。
句読点って大事だろう。
句読点をちゃんと打っていれば、読み間違えずに済んだはずなんだ。
文章もろくに書けないやつの文章を読むのは、苦労する。
