読み込もうとするHTMLがないから起こってるっぽい。
原因がよく分からないが、Android Studioのインスタントランが原因っぽい。
おそらくだが、ビルド後に配置される場所に、何らかの操作で消したが、Android Studioが差分を検知できなかったため、再配置されず、起動時にエラーになったと思われる。
たぶんね、ファイル移動をしたような、しなかったような記憶がある。
インスタントランを停止して再ビルドしたら、動作した。
これで半日悩み続けましたわ。。。
縦長ディスプレイが現場に欲しい。
ピボットできるディスプレイでも可。
ドキュメント見るときに、多くの情報が見れる縦長の方が、楽チン。
ワイド１縦長１のデュアルディスプレイが、開発には最適だと個人的に思ってる。
先週は、書くネタが思いつかなかった。。。
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インポート使ったなって思った。
.git/configの参照パスが壊れてたみたい。
パスを直したらコミットできるようになった。
具体的な対応内容は、忘れちゃった。。。
たしか、下記のstackoverflow見てた気がする。
git submodules - How to "resolve fatal: Not a git repository"? - Stack Overflow
なぜ起きたのか考えたが、多分、submoduleを別ブランチで動かしたりしたときに壊れた気がする。
レビューしてもらう機会があったのだが、ただどうすればいいかだけ指摘するの、やめてもらえませんかね？
それ、指摘じゃなくて指示だから。
もしくは、独り言か小言。
指摘をするなら、なぜこれがダメなのか述べないと、ダメだと思うんですよね。
あきらかなイージーミスとか、理由が推測できるのならいいんですけど、指摘理由が分らないのは、奴隷扱いされているようでムカつく。
そういう指摘があったら、理由を述べよって返すようにしてる。
俺は、何にでもJavaDoc書く派なのだが、書いたら消せと言われた。
それって正しいのだろうか？
そこまで書いちゃダメなものなのだろうか？
前提条件ありのメソッドだったので、前提条件を書いたのだが、それ書かなくていいの？って思ったわ。
JavaDocって、書くほうを推奨すべきだと思うんだよね。
JavaDocを極力書いて、インラインコメントは極力書かないってポリシーでいる。
Toggle Viewを押せば、エラーの詳細内容を見れる。
デフォルトビューで、エラー起きた時に、「詳細を見ろ」的なことを言われたが、「どこに詳細があるねん！」って思ってた。
もうちょい早く気づいてたら、エラー対応は早くできただろうな。。。
DL4Jの使い方を学ぼうと思ったが、難易度のレベルが違いすぎて、時間がかかり過ぎると判断。
まずは、Mahotから習得する。
学習の道筋は、Hadoop→Mahot→DL4J
まわり道になってしまうが、しょうがない。
安かったので買ってみたSpringBootの本に、Groovyで動かしている内容を見て、興味が湧いたので真似てみた。
$sw_vers ProductName: Mac OS X ProductVersion: 10.14.2 BuildVersion: 18C54
$spring --version Spring CLI v2.1.2.RELEASE
homebrewで入れようとしたんだが、xcodeのバージョンが古いからダメですと言われて、かなり萎えた。。。
xcodeって、サイズが大きいから、アップデートするのシンドいんだよね。。。
ちなみに、homebrewでの入れ方は、下記。
$ brew tap pivotal/tap $ brew install springboot
Groovy Version: 2.5.5 JVM: 11.0.1 Vendor: Oracle Corporation OS: Mac OS X
作るのは１クラスだけ。
@RestController
class App {
@RequestMapping("/")
def saga() {
"Hello Saga!"
}
}
Groovyだと、直後にメソッドから抜けることが確定してる式は、returnを省略できるので、"Hello Saga!"だけでいい。
実行は、spring run app.groovyでOK
しばらくすると、お馴染みのSpringBoot起動のコンソールが流れるはず。
俺の環境では、実行までにかなり時間がかかった。
こんなに遅かったか？と思って、Javaで書いたのを実行したら、ものすごい速かった。
groovyファイルをコンパイルするにしては長かった。
メッセージの内容をみていると、依存関係の解決が長かったので、groovyのコンパイルにひきづられて、何かの依存関係の解決もやり直しになってるんだろうなって推測。
詳しく調べるとハゲそうなので、とりあえず保留。
実行して、ブラウザでアクセスすると、Hello Saga!って出るはず。
App.java
@RestController
class App {
@RequestMapping("/")
public String saga() {
return "Hello Saga!"
}
}
groovyは、java特有の宣言記述が省略されてるのがよくわかる。
年を跨いで対応していたが、いろいろひどい目にあった。
いじっていたが、何がダメなのか、袋小路に入って、ひたすら悩んでいた。
progaurdが無効のまま、progaurd.proに修正入れても反映されないでいろいろ悩んでいたりした。
もう、今となっては些細な問題だと思う。
仕組みをなんとなく覚えられたので、もう同じ轍を踏むことはないと信じたい。
uninstallで消しましょう。
記述を削除すると、インストール済みのものが残ったままになり、間違って使ってしまって、他人がビルドしたとき、もしくは、ＣＩかかったときに慌てるハメになる。
前にも書いた気がするな。。。
タグは、パッケージ名を参考にしたほうがいいのではないかと思いました。
なぜなら、フィルタリングが楽になると思うから。
現場のタグ名が、クラス名になっているのだが、実装したクラスのログすべてをフィルタリングしたいってときに、どうすればいいのかかなり迷った。
結局、いい方法が思いつかなかったので、全出力で皿目で見るという作業になってしまった。
マジでタグ名をどうするかは、真剣に考えたほうがいい。
俺は必要ないと思う派。
それなら、ただのpublicフィールドでいいじゃんって感じる。
カプセル化って言う人をたまに見るが、「ロジックが必要ない箇所に適用して、何か意味があるの？」って思う。
ロジックがないなら、普通にそのフィールドにアクセスしているのとなんら変わらないじゃんって思うんですよ。
JavaだとLombokが一時期話題になっていたが、そもそも単純getter/setterは必要ないと思っていたので、熱は早めに冷めた。
１ヶ月くらい、成果物を作ってない気がするのだが。。。
調査した結果、対応を見送る、難易度高すぎて諦めたタスクがいっぱいある。。。
存在意義とか、自分の能力を疑いたくなっちゃうよね。。。
他の人はタスクこなしているのに、俺だけ取れ高ゼロだもんな。。。
年始が暇だから、何か作ろうと思い立った。
springbootでちゃっちゃと作ろうと思ったが、micronautで挫折したことを思い出し、再度チャレンジ。
とりあえず、動いたので、まとめる。
挫折したらそのままってのが、いつものパターンだったが、ゾンビランドサガを全話通して見て、再度チャレンジしたくなった。
$sw_vers ProductName: Mac OS X ProductVersion: 10.14.2 BuildVersion: 18C54
$java -version openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.1+13) OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
Intellij IDEA 2018.2.6 Community Edition
お金ないっす。。。
金がなくても、開発はできる。ちょっと手間が増えるだけ。
$mn -V | Micronaut Version: 1.0.2 | JVM Version: 11.0.1
インストールは、sdkmanを利用。
sdkmanは、Java関連の開発環境を用意するためのツール。
macのhomebrewみたいなもの。
前に調べたもののリンクを貼っておく。
インストールは、sdk install micronaut
$sqlite3 -version 3.24.0 2018-06-04 14:10:15 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl
SqliteManager Version 4.8.1
まずは、micronautのプロジェクト作成から。
コマンドは、下記の通り
mn create-app {プロジェクト名}
このコマンドを打つと、カレントディレクトリにプロジェクト名のディレクトリが掘られて、gradle関連のソースが格納される。
今回は、mn create-app murakumoで作成
叢雲を選んだのは、個人のセンスです。
intellij を起動して、初期画面から import Project を選択してインポート。
インポートする際は、gradleのプロジェクトとしてインポートさせる。
じゃないと、いろいろエラーが出て挫折する。
たぶん、前回は、next連打してたから、気づかなかったのかも。。。
もしかしたら、import じゃなくて、openを選んで開いていたのかもしれない。
まずは、作ったら、goodmorning Saga!でしょ。
Hello Worldは、古い。
package murakumo.controller;
import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
@Controller("/hello")
public class HelloController {
@Get("/")
public String index() {
return "Goodmorning Saga!!";
}
}
下記コマンドで動かす。
$ ./gradlew run
そうすると、なんかビルドして動き出すはず。
自分の環境では、進捗が75%で止まるのだが、75%で localhost:8080/hello でアクセスすると、Goodmorning Saga!!が表示されるはず。
たぶんだが、75%のやつは、描画が更新されてないだけで、100%なんじゃなかろうか？
今回は、いろいろORマッパーを探したけど、良さげなのがなかったので、Spring jdbcを使う。
本当は、脱springでやりたかったのだが、しょうがない。
まずは、DBの用意。
Sqliteは、DB作ると同時にtableも作らないとダメなので、ちょっとやっかい。
sqlite3 murakumo.db
カレントディレクトリは、murakumo直下
打つと、sqliteのCLIに入るので、テーブルを作成する。
適当に、下create table sample(id, name)で、sampleテーブルを作る。
きちんとできているか確認するため、.tableを打つ。
そうすると、sampleって表示されるはず。
そしたら、一旦、sqliteのCLIを抜けるため、.exitを打つ。
テーブルへのテストデータ投入は、sqlitemangerからやる。
sql文を打つのが早い人は、そっちでもいい。
テストデータは用意できたので、今度はsqliteを利用するためのライブラリを追加する。
build.gradleのdependenciesに下記を追加。
compile "io.micronaut.configuration:micronaut-jdbc-tomcat"
compile 'org.springframework:org.springframework.jdbc:3.2.2.RELEASE'
compile "io.micronaut:micronaut-spring"
compile group: 'org.xerial', name: 'sqlite-jdbc', version: '3.25.2'
保存したら、勝手にライブラリのダウンロードが走るはず。
そしたら、今度は、jdbc接続用の設定を、application.ymlに追加する。
datasourcesが、今回追加した箇所。
micronaut:
application:
name: murakumo
datasources:
default:
url: jdbc:sqlite:murakumo.db
driverClassName: org.sqlite.JDBC
今度は、jdbcアクセスようのDatasourceを生成するクラスを書く。
俺はよく知らないが、spring-jdbcは、こうやるものらしい。
package murakumo.factory;
import io.micronaut.context.annotation.Factory;
import org.springframework.context.annotation.Bean;
import org.springframework.jdbc.core.JdbcTemplate;
import javax.inject.Inject;
import javax.inject.Singleton;
import javax.sql.DataSource;
@Factory
public class JdbcTemplateFactory {
@Inject
DataSource dataSource;
@Bean
@Singleton
JdbcTemplate jdbcTemplate() {
return new JdbcTemplate(dataSource);
}
}
JdbcTemplateを生成して返すだけ。
今度は、テーブルからデータを引っこ抜いてくるクラスを作る。
package murakumo.service;
import io.micronaut.context.annotation.Requires;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.transaction.annotation.Transactional;
import javax.inject.Singleton;
@Singleton
@Requires(beans = JdbcTemplate.class)
public class TestService {
private final JdbcTemplate jdbcTemplate;
public TestService(JdbcTemplate jdbcTemplate) {
this.jdbcTemplate = jdbcTemplate;
}
@Transactional
public void printSampleTable() {
jdbcTemplate.query("select * from sample", (rs) -> {
System.out.println(rs.getString("id"));
System.out.println(rs.getString("name"));
});
}
}
printSampleTableが実際にDBアクセスしている箇所。
ResultSetをLambda使って処理できるのは、今っぽい。
昔だと、resultSet取ってきたら、ぐるぐる回して結果を見るのが多かった。
当然、アクセスは、DIしたものを使ってやる。
アノテーションは、@Injection でできるらしい。
Springは、たしか、@Autowired だったかな？
@Controllerや@Getは、Springに近い動きをするので、なんとなくわかる。
package murakumo.controller;
import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
import murakumo.service.TestService;
import javax.inject.Inject;
@Controller("/hello")
public class HelloController {
@Inject
private TestService testService;
@Get("/")
public String index() {
testService.printSampleTable();
return "Goodmorning Saga!!";
}
}
TestServiceをDIして、indexで使ってるだけ。
./gradlew run で起動して、localhost:8080/helloにアクセス。
すると、ターミナルに、登録したデータが表示されるはず。
なんでだ。。。
何に苦戦してたんだ、俺は。
すんなりできすぎて、逆に怖いんですけど。
あとは、spring-jdbcの知識がつけば、いろいろできそう。
組み込み系のDBは、もうsqlite一択な気がしてきたな。
mysqlやpostgressも考えたけど、環境準備するのが面倒くさいんだよね。
手軽に永続化できるのが、魅力だと思う。
docker使えば、mysqlとかの準備も楽そうな気もするが、dockerの習熟度がまだ足りない。
javaからsqliteに素早く書き込みたい - Qiita
Using Spring's JDBCTemplate with Micronaut
