聞こえないJavaエンジニアが適当に書き連ねていく

つらつらとメモしたり日頃の溜まっている想いを吐き出す場所です。

”Javaが有償化される”という誤解を解くための資料

これは何?

Javaが有償化される!という誤解を解くために読むのをお勧めする雑誌だったりWeb記事のメモ。 この辺りを読めば、大部分の方の誤解は解けるのではないかな?と思っているが、さてはて…。

一覧

Software Design 2019年1月号

gihyo.jp

特集「リリースモデルの変更にどう対処する?Javaのバージョン問題に前向きに取り組む方法」を読むとよい。 好評だったようで雑誌現物はもう残っていないと見かけたが、電子版で購入は可能。

GlassFish勉強会レポート】各JDKベンダの動向を知ってJava 11に備えよう

gihyo.jp

GlassFishユーザ会が2018年9月18日に開催した勉強会のレポート記事。各ベンダがどうするのか?がまとまっている。

2019年のJava

gihyo.jp

Javaチャンピオンの一人、寺田佳央氏の寄稿記事。日本のシステム開発の実情も踏まえた内容になっていてわかりやすい。

Java is Still Free」――Javaのサポート問題へ終止符、迎える4つの進化【Oracle Code One 2018 Java Keynote

codezine.jp

Oracle Code One 2018(2017年まではJavaOneだったイベント)の参加レポート。 イベントでどのようなお話があったかまとまっている。

Javaは今も無償です

docs.google.com

Javaコミュニティから出された声明、「Java Is Still Free」の日本語版。

受託開発をやるときに考慮すべき環境面の事柄を色々

受託開発をやるときに、最初に考慮しておかないと後々大変そうな環境面を2018/12時点の心境でつらつらと。

バージョン管理

成果物全てのバージョン管理は何で行うべきか、と考えた時 バージョン管理はGitが今は主流だが、Subversionでも特に問題はないと考える。 その代り、Subversionのバージョンは最新にしておきたい。

Gitを使うなら、理想はGithubにお金を払ってprivateリポジトリでの作業だと思うが、 こんなこと書いている会社では厳しいと思うのでGitlabを開発環境のサーバーに入れるのが無難だろうと思う。

モック作成

ブラウザとJavaScript周りの制約が厳しくなっており、 htmlファイルをダブルクリックでただ開くだけでは見栄えが確認出来ない。

基本、Chromeベースで動作確認するのがよいが、お客様が実際に使っているブラウザを事前に確認しておくこと。

  • html5ベースで作る。
  • JavaScriptのライブラリは最新のものを使う。
  • jQueryなど、ローカルファイルだと正常に起動しないことが増えたのでVSCodeLive Serverを使うのもよさそう。
    • htmlファイルがあるフォルダを開いて、htmlを右クリックするとメニューに"Open with Live Server"が出てくるからクリックでサーバーが立ち上がる。
  • ユーザーレビュー時は専用のサーバーを一時的に用意する?

開発

タスク管理

GitHubまたはGitlabのissue、Redmine、Backlog辺りが選択肢に入る。お客様と一緒に使うかどうかで変わってくる。 お客様にも書き込んでいただくのであればBacklogが無難かもしれない。

開発端末

いい端末を手配してもらう。

開発サーバー(データベースサーバー、APサーバーなど)

スペックは多少落ちてもやむを得ないので、OSは本番環境と出来るだけ合わせる。

負荷テストなどは実際のお客様の環境同等でないと行えないが、開発環境をそこまで整備できるか?というと厳しいと思われる。

Java

本番環境のOSに合わせる。

  • お客様がOracleと契約するのであれば、Oracleを使う。
  • RedHatならRedHat社のOpenJDK
  • IBM系列ならAdoptOpenJDK with OpenJ9を使う
  • それ以外ならAdoptOpenJDKでよさそう?

出来るだけ本番リリース時点の最新LTSバージョンを用いたいが(Java11、Java17、・・・) お客様の環境を最初に確認しておくこと。

載せるサーバーによっては既に動いているシステムがあってJavaのバージョンが変えられないかもしれない。

データベース

契約先が契約しているデータベースがあればそれを使う。 ライセンスを購入する必要が生じた場合は、お客様にライセンスを分けてもらうように交渉する。

何でもいい場合はMySQLPostgreSQLかどちらかになると思うが、それぞれの違いをちゃんと見極めること。 本番リリース後に維持も引き続き行う場合は、本番のデータが全部入れられる容量のものを開発環境に入れること。

Webサーバー

無難なのはTomcatだと思うが、お客様の環境に合わせて検討する。

フレームワーク

現時点ではSpring Bootの一強だが、開発時点での状況を見極めて選択する。 他のプロジェクトでこれを使っていたから、とそのまま流用せずに見極めたい。

テスト

  • Excelへのスクショ貼付けは出来るだけ減らしてJUnitを活用していく。
  • 目視チェックしないと気づけない部分も多いので気を付ける。

開発ツール

  • ビルドツールはMaven、またはGradleを使って使うライブラリの管理も含めて行う。
  • 統合開発環境ツールはeclipseがどうしても標準になるが、統一はしなくてよいと思う。
  • Jenkinsも導入しておきたい。

他に何があるかなぁ

プログラミングと執筆

プログラミング言語とあるのだからJavaCOBOLC言語も日本語や英語と同じ言語と言える。文法が違うだけ。

言語なので、プログラミングイコール執筆、または作文と同一なのではないか。

文章にするときは起承転結や全体の構成が大事。それはプログラミングでも同様で、まず処理全体の構成を考えて、それから内容を詰めていく。

変数名イコール文章内での言葉の使い方であり、適切な言葉を使うことでその文書全体の読みやすさ、伝わりやすさが変わってくる。

プログラマーイコールインタビュー、または編集者と考えられる。プログラミングは相手が伝えたいことを形にするもの、インタビュー記事は相手が伝えたいことを文章にするもの、出来上がるものは違うけどやりたいことは同じなのでは。

パッケージング&クラス名イコール索引であり、目的のところにたどり着くための手がかりである。適当にパッケージングして、適切なクラス名をつけると、書いている時は覚えているかもしれないが、後から読む人にとっては手掛かりがないので読めない。

コメントイコール注釈であり、仕様説明用のコメントイコール図解である。注釈が多い文書は読みにくいし、図解がない文書は読みにくい。

フォーマットイコール段落であり、段落がガタガタな文書は読みにくい。

 

一人で書くプログラミングでも、今プログラムを書いている時に読めていたコードが数日後の自分も読めるかは非常に怪しいものがある。

チーム開発は赤の他人が集まって行うものなので、他人が読みやすいものになっているかを充分に意識して書かないといけない。

 

 

 

Effective Java 第3版を買いました

Effective Java 第3版を溜まってた楽天ポイントで買ったので実質無料でゲットなのです。

f:id:su_zu_ki_1010:20181030143926j:image

1ページめくるたびに、わかるような、わからないような、そんな気分を味わう。でも、それでいいのです。載っている90個全てがすぐに完全に理解できるわけがないので、実務と読書を繰り返してある日ストンと腑に落ちる日が来ればいいんだろうなー、と思いながら睡魔に耐えてまたページをめくる、そんな日々。

第2版も出版されてからかなり時間が経っているのに、今でも読み返すと新しい気づきがある。

第3版も一度、通して読み終えたら気になる部分を再度読み返して行くことで理解を深める、そんな本ですね。

Java初学者にはオススメ出来なくて、むしろ、Javaは完全にマスターしました!という人が読むべき本。

Spring Boot 2.0.6で日時を固定したテストを書きたいとき

断り書き

個人的な覚書です。 バージョンアップで動かなくなる可能性があるので検索でヒットして、真似る時は気を付けてください。

前提

以下に書かれている記述が動いた時のバージョンは以下の通り。

  • Java 1.8
  • Spring boot 2.0.6
  • JUnit Platform 1.3.1
  • JUnit Jupiter 5.1.1 (Spring boot のtesterデフォルト)
  • JUnit Vintage 5.1.1 (Spring boot のtesterデフォルト)
  • Jmockit 1.43

やりたいこと

プログラム内で行っている、システム日付取得の部分をJUnitでのテストの時は固定の日時にしたい。 ※時間に応じて挙動が変わる個所があるため。

試したこと

ダメだったもの

最初はここに書かれている内容を真似して書いたらうまくいった。

JMockit を使用して LocalDateTime.now() で指定した日時を取得する. · GitHub

しかし、実はJmockitのバージョンがかなり古いものを使っていた。(どこかの記述をコピペしたのが原因)
諸事情でIDEを変えた時に、JMockitのバージョンも上げたら java.lang.ExceptionInInitializerError を吐いてしまった…。
調べると、JMockitのバージョンアップで今まで書けていた内容がNGになった模様。

うまくいったもの

仕方ないので再度調べ直したら、以下のサイトがヒットした。

sebastiankoltun-blog.com

ここに書かれていることを参考に、書き直したら日時を固定できるようになった。

現在日時を返すだけのfactoryクラスを作る。

import java.time.LocalDateTime;

import org.springframework.stereotype.Component;

@Component
public class TimeFactory {

    public LocalDateTime now() {
        return LocalDateTime.now();
    }

}

呼び出す側は、TimeFactory.java をインジェクションする。

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

import org.springframework.stereotype.Component;

@Component
public class TimeFactoryCall {

    private TimeFactory clock;
    
    public TimeFactoryCall(TimeFactory factory) {
        this.clock = factory;
    }
    
    public String get() {
        
        LocalDateTime date = clock.now();
        return date.format(DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss"));
        
    }
    
}

テストプログラムはこんな感じ。

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;

import java.time.LocalDateTime;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.test.context.junit.jupiter.SpringExtension;

@ExtendWith(SpringExtension.class)
@SpringBootTest
class TimeFactoryCallTest {

    @MockBean
    private TimeFactory clock;

    @Test
    void test() {

        LocalDateTime TEST = LocalDateTime.of(2018, 10, 16, 14, 23, 59);
        when(clock.now()).thenReturn(TEST);

        TimeFactoryCall call = new TimeFactoryCall(clock);

        assertEquals(call.get(), "2018/10/16 14:23:59");

    }
}

他に参考にしたサイト

qiita.com

“ゴミ記事” について考えてみた

最近、エンジニアはブログを書けとかゴミ記事は書くな、という話題をシステム開発界隈で見かけるので個人的に思うことを書いてみる。

 

まず、ブログを書けという論調、これには同意する。個人的なメモでも、1ヶ月後の自分、1年後の自分にとって役にたつことがある。

ただし、その場合は未来の自分が検索ワードに使いそうな言葉を必ず書いておくこと。今は自明な言葉でも、未来の自分は忘れている可能性が大だから。

それに、やってみたときのバージョン情報も必ず載せること。バージョンによって動いたり動かなかったりすることがあるので、このバージョンで動いたという事実を載せることは大事。

 

次に、ゴミ記事は書くなという論調。これも気持ちとしては分からなくも無い。自分も検索してヒットしたものが求めていなかった内容だった時は一瞬空を仰ぐし、ため息も出てしまうかもしれない。

でも、自分にとってゴミ記事でも、他の人にとってはお宝かもしれない。

やってみた記事であれば、自分は動かなかった内容がその人は動いているわけで、何が違うのか?を確認することが出来る。逆に、もしかしたら当時は動いたけどバージョンアップで動かなくなった、ということがわかるかもしれない。

やってみたけど動かなかった、という記事もゴミ扱いされるが、ちょっと待ってほしい。

まず、動かなかった、をそのまま信じてしまうのは勿体ない。バージョンアップで動くようになっているかもしれないから。

同じバージョンだとしたら、あなたがやろうとしていることは今のバージョンでは出来ない、という事実がわかるので諦めるきっかけになるのではないか?

 

あとは、その記事を書く場所は適切な場所なのか?を考えてみる必要があると思っている。

自分のブログなら何を書いてもいいと思うが、情報共有系のサイトに書く時はそのサイトの指針にあっているかをちゃんと考えないといけない。

 

まぁそんなことをポンコツエンジニアはいろいろ読みながら考えたよ、っていうね。