20191129のJavaに関する記事は11件です。

生成したjarファイルをEclipseでデバッグする方法

※Eclipse英語版が前提です。Pleiadesなど使っている場合は、適宜日本語に読み替えてください

jarファイルをブレークポイントを使ってデバッグしたい場合の方法

Eclipse側の設定

プロジェクトのフォルダ上で右クリックして、
Debug As > Debug Configurations...を選択

スクリーンショット (1).png

Remote Java Applicationsでダブルクリック
設定画面が開くので、Host:localhost port:任意のポートで設定を保存
スクリーンショット (2).png

jarファイル側の起動設定

java -Xdebug -Xrunjdwp:transport=dt_socket,address=[上記設定で指定したポート],server=y,suspend=y -jar [JAR名]

でjavaファイルを起動
すると、jarファイル側が待機状態になる

再び、先ほどのDebug Configurationsを開き、「Debug」のボタンを押下
スクリーンショット (2).png

すると、jarファイルがデバッグ起動されてブレークポイントも自由自在に扱えるように!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS LambdaでJavaのフレームワークを使うには!?

TL;DR

AWS LambdaでJavaのフレームワーク、たとえばSpringBootなどを使いたいって思ったことありませんか?

結論としては、AWS Lambdaの上に、aws-serverless-java-containerフレームワークというプロキシフレームワークを入れれば比較的簡単に実現可能です。

今日は、そのあたりを、このAWSブログを軽く意訳しつつ書いていきたいと思います。

AWS Open Source Blog Running APIs Written in Java on AWS Lambda

背景

Java開発者は、SpringやSpring BootからJersey、Sparkといった慣れ親しんだフレームワークで開発していることが多いのではないでしょうか。

これらのフレームワークは、Tomcatなどのサーブレットコンテナを用いて、ビルドされたWarやJarをデプロイするか、アプリケーションを内包した実行可能なJarとして利用することができます。

AWSのサーバーレスでは、AWS LambdaとAmazon API GatewayでWEBのバックエンドが構築できますが、Lambdaがコンピュートを担い、API GatewayがRESTの管理を担います。

この記事では、Lambdaで使える、aws-serverless-java-containerフレームワークをご紹介します。

仕組み

簡単に言うと、aws-serverless-java-containerは、Spring、Spring Boot、Jersey、Sparkなどのフレームワークで作られたアプリケーションを、簡単に、最小限のコード変更でAWS Lambda内で実行できるようにするものです。

フレームワーク間のプロキシ

aws-serverless-java-containerは、Lambdaランタイムと選択したフレームワーク間のプロキシとして機能し、サーブレットエンジンのふりをして、API GatewayからのEventをフレームワークが理解できるリクエストオブジェクトに変換し、アプリケーションからのレスポンスオブジェクトをAPI Gatewayの理解できる形式に変換します。

Spring Boot2をLambdaにのせて独自アプリを構築したい場合は、こちらに詳しい導入方法が紹介されています。
Quick start Spring Boot2

サンプルアプリダウンロード

awslabからaws-serverless-java-containerをcloneしてきましょう。この中に様々なJavaフレームワークのプロキシとサンプルコードが含まれています。

$ git clone https://github.com/awslabs/aws-serverless-java-container.git

独自アプリケーション用のプロキシはこちら

独自アプリを構築するにはこれらを使えばいいのですが、この記事では簡単のために、Spring Boot2のサンプルを利用したいと思います。

Spring Boot2のLambdaへの導入

Spring Boot2 ペットショップサンプル

まず、以下の前提条件を満たしておきましょう。

まず、mvnコマンドを使って、Javaアプリケーションをビルドしましょう。

$ cd aws-serverless-java-container/samples/springboot2/pet-store/
$ mvn package

mvnコマンドが成功すると、serverless-spring-boot-example-1.0-SNAPSHOT.jar が、targetディレクトリにできているはずです。

つぎに、AWS SAMを使って、Lambdaにデプロイするpackageを作ります。<YOUR S3 BUCKET NAME>には、適当なS3バケット名を指定しておきます。

$ aws cloudformation package --template-file sam.yaml --output-template-file output-sam.yaml --s3-bucket <YOUR S3 BUCKET NAME>

デプロイ用のパッケージができたら、次はいよいよLambdaへのデプロイです。このデプロイによってロジックを処理するAWS Lambdaと、HTTPSリクエストを受け取ってLambdaを呼び出すAPI Gatewayがデプロイされます。

$ aws cloudformation deploy --template-file output-sam.yaml --stack-name ServerlessSpringBootSample --capabilities CAPABILITY_IAM

デプロイが成功すると、以下のコマンドで実際に作られた、APIのエンドポイントを知ることができます。

$ aws cloudformation describe-stacks --stack-name ServerlessSpringBootSample
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:us-west-2:xxxxxxxx:stack/JerseySample/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx", 
            "Description": "Example Pet Store API written with spark with the aws-serverless-java-container library", 
            "Tags": [], 
            "Outputs": [
                {
                    "Description": "URL for application", 
                    "OutputKey": "SpringBootPetStoreApi", 
                    "OutputValue": "https://xxxxxxx.execute-api.us-west-2.amazonaws.com/Prod/pets"
                }
            ], 
            "CreationTime": "2016-12-13T22:59:31.552Z", 
            "Capabilities": [
                "CAPABILITY_IAM"
            ], 
            "StackName": "JerseySample", 
            "NotificationARNs": [], 
            "StackStatus": "UPDATE_COMPLETE"
        }
    ]
}

OutputValueに指定されているAPIエンドポイントが、今回デプロイされ起動したAPIのURIになります。

動作確認してみましょう。

$ curl https://xxxxxxx.execute-api.us-west-2.amazonaws.com/Prod/pets

結果のJSONが返ってきたら成功です!

いかがだったでしょうか?サンプルアプリの導入がこんなに簡単にできました。


次のステップに進むには?

Spring Boot2は素晴らしいフレームワークで上の手順に従うことでLambdaにのせて実行させることは簡単にできるのですが、もっと小回りの効く、小さなフレームワークを導入したいといった場合SparkMicronautにも挑戦してみてください。

また、Lambdaの初回起動時のLatencyが気になるワークロードについてはOracle社が提供しているGraalVMを利用したNative実行も可能です。

MicronautとGraalVMを使ったNative化のサンプルはこちら
Micronaut X GraalVMサンプルペットショップ

この記事の関連情報としてJJUG CCC 2019 Fallの登壇資料がありますので、参考にしてください。

サーバーレス時代のJavaについて
サーバーレス時代のJavaについて

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JJUG CCC 2019 Fall スライド一覧

スライド一覧

JJUG CCC 2019 Fallのスライド一覧です。

スライド 10:00 - 10:45

試して学ぼう、Java EE アプリケーションをOpenShift(Minishift)でデプロイ!

Head toward Java 13 and Java 14

All people are VIP~Disney哲学から考えるDiversity

Gradle を完全に理解した人が、何も分からなくなるための第一歩 @opengl-8080(@opengl_8080)さん | Twitter

JavaとGraalVMとPicocliで、ときめくネイティブコマンドラインアプリを作ろう

Coding That Sparks Joy with Quarkus

BigQueryを用いたデータ分析基盤作成入門 @西山(@westmountain37)さん | Twitter

スライド 11:00 - 11:45

Javaで学ぶオブジェクト指向プログラミングの基礎知識 @増田 亨.(@masuda220)さん | Twitter

入門 例外 @石◯王 もちだ(@mike_neck)さん | Twitter

Rethinking Runtime Efficiency with GraalVM

Javaプログラマのための頑張らないGo入門 @yank shaving(@yy_yank)さん | Twitter

Jakarta EE: today and tomorrow @Dmitry Kornilov(@m0mus)さん | Twitter

Gradle Ex Machina

Spring Cloud AWSをクラウドエンジニアがいじってみた

スライド 12:00 - 12:45

(初参加弁当付)JJUG初心者のためのJavaコミュニティのススメ

Java によるクラウドネイティブの実現に向けて

スライド 13:30 - 14:15

最新:Azure Spring Cloud のご紹介 @寺田佳央@クラウド・アドボケイト(@yoshioterada)さん | Twitter

Reliability Engineering Behind The Most Trusted Kafka Platform at LINE

開け!ドメイン駆動設計の扉 @nrs(@nrslib)さん | Twitter

ref

Mavenの真実とウソ @:craftsman/kawasima(@kawasima)さん | Twitter

Javaで学ぶネットワークプログラミングの基礎

Modern Identity Management (in the Era of Serverless and Microservices)

運用を支えるためのログを出すにはどうするか? @wreulicke(@wreulicke)さん | Twitter

スライド 14:30 - 15:15

Spring Update 2019

CLRのValueTypeを起点にProject Valhallaを覗いてみる @Aki / Logico@Ignite Tour Tokyo (Dec 4-5, 2019)(@Logico_jp)さん | Twitter

長く続くサービスがモダンであり続けるには @chan_kaku(@chan_kakuz)さん | Twitter

まだまだ間に合うJUnit(再)入門

Micronaut と始めるサーバーサイドKotlin @ポール(@bulbulpaul)さん | Twitter

ref

JavaオンプレシステムをAKS + Quarkusに移行した話 @Tomoaki Takaichi(@takaichi00)さん | Twitter

元インフラエンジニアがSpringBoot2を用いてFW開発を学んでいる話

スライド 15:45 - 16:30

【仮】Java における乱数 (生成器) とのつき合い方 @KOMIYA Atsushi(@komiya_atsushi)さん | Twitter

ref

Use Kotlin scripts and custom DSL in your web apps

こわくないソースコードリーディング生活 @Ryo Shindo(@shindo_ryo)さん | Twitter

AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション - 開発ツールやプロジェクト構成も含めて45分で丸わかり - @Masatoshi Tada(@suke_masa)さん | Twitter

ref

Javaの起動速度といかに戦うか

Where is my cache? Architectural patterns for caching microservices by example

How to adapt MicroProfile API for general Web applications

スライド 16:45 - 17:30

新卒3年目が立ち向かった、お名前.comでの超巨大レガシーシステム脱却の事例 @t-takamichi(@ttakamichi1)さん | Twitter

オレ流OpenJDK「の」開発環境

JavaでTracing

JVM入門 -Javaプログラムが動く仕組み- @きの子@就活GeekHub 2020/1/25(土) 大阪開催(@aa7th)さん | Twitter

Evaluating ZGC with HBase

Serverless時代のJavaについて

多言語対応の仮想マシンGraalVMが照らす未来 @Koichi Sakata (じゅくちょー)(@jyukutyo)さん | Twitter

スライド 17:45 - 18:30

分散トレーシングの技術選定・OSS 貢献と Stackdriver Tracer での性能可視化・改善 @Seiya Yazaki(@saiya_moebius)さん | Twitter

Swagger ではない OpenAPI Specification 3.0 による API サーバー開発

DIコンテナ入門

JVMs in Containers: Best Practices

Oops-Less Operation

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GitHub Actionsでコードレビュー前にフォーマッタをかける

突然ですがJavaのコード、なにで書いてますか?

私見ですが、ショートカットキーが手に馴染んだIDEとそうでないIDEでは明らかに作業効率が変わる気がします。
「IDEが選べる」「PCが選べる」はエンジニア採用の現場でも売りとして扱われているようですし、実際選べない会社より選べる会社の方が嬉しい。
ただ、実際選べる環境に入ってみると、それはそれでこんな状況が起こりがち。

  1. Eclipseで書かれたコードをIntelliJ愛用者が編集(逆もまたしかり)
  2. 手癖でフォーマッタをかける
  3. コードの差分が大変なことになる
  4. レビューつらみ

フォーマッタはできれば統一したいところ。
一方で「ソースコードプッシュするときは、ビルドツールでフォーマットしてからにしましょう」とかルール化するのもそれはそれで面倒。
pre-commitのセッティングを各人にお願いしてもいいのですが、GitHub使ってるならそっちで勝手にやってくれれば楽なはず!

というわけで、設定してみました。
ビルドツールやフォーマッタはプロジェクトによって色々かとは思いますが、本記事ではGradle+Google Java Formatを扱います。

結論

  1. google-java-format-gradle-pluginを導入
    https://github.com/sherter/google-java-format-gradle-plugin
  2. GitHub Actionsのworkflowを設定
    https://github.com/tom-myz/shelffy/blob/master/.github/workflows/gradle.yml
  3. アクセストークンを発行してリポジトリのシークレットに登録

これでフォーマッタバラバラでレビューしづらい問題とはおさらばできるかも!

気をつけるべきポイント

追加commitはコマンドで

実行結果をcommitする、みたいな機能は見つかりませんでした。
まじめにgitコマンドを書くほかなさそうです。

gitの参照先がデフォルトブランチになる

トリガーがpull_requestなのだからマージ元のブランチをローカルに複製して参照してくれてる
……なんてことはなく、ブランチのcheckoutを抜かすとHEADにコミットされます。
originは設定されているようです。

continue-on-errorを設定したstepは終了コードに関わらずsuccessする

後続のstepにif success()をおいても意味が無くなります。
コマンドAが失敗した場合、コマンドBをスキップしてコマンドC以降を実行とかやりたい場合、

  • コマンドA・コマンドBを同一ステップにおいてcontinue-on-error
  • コマンドC以下は次のステップに配置

で実現するのがよさそうです。

その他

何か思い出したら追記するかもしれません。しないかもしれません。

イケてない点

  • 歴史あるリポジトリだと適用した瞬間の差分が大変なことになる
    → それ以前まで遡ろうとすると結局git blameしづらい問題
  • ユーザー名とメールアドレスが具体的すぎる
    → 実プロジェクトでやるなら専用ユーザー用意した方がいいとおもいます
  • フォーマッタかけたあとのコミットにももう一度フォーマッタをかけようとする
    → しかも結構時間がかかる。JDKのインストールからやってることもあり、内容Hello worldレベルでも1分半ほど
  • コミット数が純増してログがきたない
    → squashとかで行けそうな気もしつつ、Gitちからが足りなすぎてモチベーションがつづかなかった

感想

GitHub Actionsはよいものでしたが、肝心のGitの知識がなさすぎてやたらと時間かかりました。
仁義なきコスメティック・レビューから一人でも多くの開発者が解放されますように!

参考文献

https://help.github.com/ja/actions
http://nomadblacky.hatenablog.com/entry/2018/10/27/145451

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

フリーランスになります!

みなさんこんにちは。
12月からSEとしてフリーランスになるたつぞーです。

今回私が書く内容はフリーランスになるまでの話をしていこうと思います。
※長文となる為、お暇な時に読んで頂ければ幸いです。

まず私の経歴から
・大学卒業後、SEとして中小企業に就職。
・2年半して退職。
・その後1年弱、アルバイトの日々。
となります。

・使用言語
  Java、HTML,Javascript,CSS
・ざっくりとした業務内容
 印刷機の画面開発(機能と画面)
 関わったアプリは15個ほど、主にアプリの機能追加。
 検証作業。新規案件に向けて技術調査。

~~~~~~~退職について~~~~~~~

退職理由は日々成長することを期待される職場で、わがままではありますが
毎日プレッシャーに押しつぶされそうになり、やめる1年前までずっとうつに
なるんじゃないかってくらいネガティブになっていました。

そして、転職のことを考えることより「この場から早く逃げないと死んじゃう!」と
思い気づいたら退職をしていました。

退職後は2,3ヶ月SEではなく、インフラ系の仕事を探し、面談を受けて内定もいくつかもらっていました。
しかし、1,2個目の内定をもらった時は「俺ってまだ市場価値があるんだな」と思っていたのですが、
それよりも「前職での職場環境(だれがどう見たって良い環境だが俺には無理だった)と同様だったらどうしよう。」
という考えが一歩踏み出す私を邪魔していました。

結局内定はお断りして、アルバイトをして食いつないでいました。
(ちなみに実家暮らしなのでそこまで生活には困らなかったです。)

アルバイトをしている間、どんな仕事をしようかと考えました。
例えば、バスの運転手、鍵屋、小売業、etc....
そして、接客業で面接を受けていく中で私はフリーランスを目指すきっかけがあったのです。
~~~~~~~~~~~~~~~~~~~~

~~~~~~~フリーランスを目指すきっかけ~~~~~~~

私はパチンコ、スロットをよく友人と打っていました。
そこで安直でしたがパチンコ業界で大手の会社の面接を受けました。
3次面接まであったのですが、最終面接が私の考えを変えたのです。

最終面接の面接官は人事部長でした。
話しを聞くと、心理学の資格を持っている方で、私の一挙一動をくまなく
みて、私をこんな人間だなと話して下さりました。

・メンタルが弱い
・人に興味がない、ロボットみたいだ。
・一つの目標に愚直に努力できる
etc...

まず、素直な感想として、
「これ面接なのか?今後頑張れって意味?」
と思いました。
しかし、面接官は
「だが、あなたはまだ変われる。ダメなところから目を逸らさず
 愚直に努力して改善できる。将来やりたいことをよく考えてみて!」
と励ましてくださりました。

この言葉から私は、正直SEという仕事から逃げてしまいましたが、
自分のやりたいことはなんだろうと考えた時、
「生活が豊かになる。そんなものづくりをしたい。」
と心の底から思い、SEの仕事を探し始めました。
~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~フリーランスになるまでの話~~~~~~~

ここからは私がフリーランスになるまでのお話しをします。
いざ転職活動をしようと思っても、
「経験値がすくないこんな私をどこが雇ってくれるんだ。」
となかなか行動に移さなかった自分がいました。

そんな時、前職の会社の先輩からフリーランスになった
というお話しを聞き、食事に行きました。
話しを聞いていると、
・職歴は長かろうと短かろうと関係ない。
・見られるのは実際に経験した業務の経験年数。
・仕事はいくらでもある。
・自由度が高い。
とのことでした。

そこから
「地団駄踏んでるのはもったいない。会社員と違ってもし仕事内容が
いやだったらやめれるから!試しに3ヶ月くらいやってみない?」
とお誘いを頂きました。ちょうどSEの仕事をどうしていくか考えていた為、
二つ返事でお願いしました。

そこからその先輩がお世話になっているフリーランス紹介エージェントの方を
ご紹介して頂き、お話しを聞いて仕事を紹介してもらいました。

面接は2つしか行っていませんが、そのうちの一社が未経験の私でも
育てると行って下さりました。
業界は金融系で激務必至であろう現場ですが、一から学ばせて頂ける職場が見つかり
安心しました。
~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~最後に~~~~~~~
フリーランスになっていない私がいうのはおこがましいですが、
フリーランスになるメリット、デメリットを感じた中でお伝えしようと思います。

■メリット
 ・案件ごとに仕事の契約を行う為、タイミングがよければ様々な技術に触れ合う
  チャンスがある。
 ・時に職場が転々とすることがある為、交友関係が広がる。
 ・契約期間での業務になる為、人間関係に悩まなくて済む(個人的にここがすごくメリットに感じた)
 ・節税ができる。(当たり前)

■デメリット
 ・会社員とは違い、保険や年金などの公的手続きをすべて自分でやらなくてはならない。
 ・着実にスキルをつけていかなければ紹介される仕事も少なくなる。
 ・契約期間中に企業側が契約を切ることも可能な為、仕事がいきなりなくなる可能性がある。

~~~~~~~~~~~~~~~~

とても長くなりましたが以上、フリーランスを目指すたつぞーのお話しでした。
ここまでご一読して頂いた方、ありがとうございました。
もしこの記事をみてフリーランスを目指すきっかけになったら
嬉しいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Java変数のvolatile修飾子とは?

volatile修飾子の概要

  • 変数に付与する修飾子だよ。場合によってはsynchronizedの代わりに使える。
  • 以下が利用例。
private static volatile int count = 0; 

役割1: キャッシュ値からの読み取りを禁止する

  • マルチスレッドが使われている場合、各スレッドがフィールドの値をキャッシュすることがある。このキャシュの対象外にする役割(パフォーマンス向上のために、各スレッドが変数のコピーを用意するため、メインメモリの値に変更があると、スレッド内の値と乖離が発生する可能性がある)
  • volatileつけるとこの変数はメインメモリから読み込んでねというお願いができる。

役割2: コンパイル時の最適化の対象外にする

  • Javaのコンパイル時には無駄な評価をなくすように最適化が行われる。
# 以下のようなコードは...
boolean flg = true;
while(flg){
    System.out.println("hello!");
}

# 以下のように最適化される... → 別スレッドでflgをfalseに変更する前提だとループが終わらない!
if(flg){
  while(true){
       System.out.println("hello!");
  }
}
  • volatileを付与することで上記のような最適化をおこなわないようにしてね、というお願いができる。

synchronizedとの違いは?

  • synchronizedの方が高機能(volatileはsynchronizedの簡易版的な感じ)
  • volatileは上記の役割を持つが、スレッドセーフというわけではない。
  • volatileはスレッドとメインメモリ間の変数を同期する(=キャッシュせずに値をメインメモリから読みとりますよ)役割であるが、synchronizedはそれに加え、排他制御を行いますよという役割も持つ。
  • volatileが排他制御に使えますよ、っていうのは間違い。

参考文献

[Difference Between Volatile and Synchronized Keywords in Java]
https://dzone.com/articles/difference-between-volatile-and-synchronized-keywo

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Kotlinは何故便利なのか

この投稿をした経緯

https://qiita.com/ngsmvn/items/b74328291d0b5342e407

長すぎ、読みたくないという人は、それぞれの節にまとめを付けているので、それだけでも趣旨は分かると思います。

何故Kotlinは便利なのか

何故Kotlinは便利なのかを一言でまとめると、他の言語のいいとこどりをしているからだと思います。

Kotlin in ActionというKotlinの開発者が書いた本にこうあります。

We aren’t trying to advance the state of the art in programming language design and explore innovative ideas in computer science. Instead, whenever possible, we’re relying on features and solutions that have already appeared in other programming languages and have proven to be successful.

(拙訳)

私たちは、プログラミング言語の技術水準をあげようとか、コンピュータサイエンスの革新的なアイディアについて探求しようとかしているわけではありません。その代わりに、他のプログラミング言語に既にあり、上手くいくことが分かっている機能や解決策に出来る限り頼っています。

実用的であること、既存のプログラミング言語の良い点を積極的に取り入れようとしていることがよく分かると思います。

具体的に便利な点

これ以外にも色々あると思いますが、以下の3点に絞ってまとめてみます。

  1. 静的型付けなのに「柔軟」かつ「簡潔」
  2. 関数型言語から取り入れた「参照透過性」
  3. JVM(後述)で動くので「write once, run everywhere」

動的型付け言語の「簡潔さ」と「柔軟性」

この節のまとめ:静的型付け言語は、プログラムについての情報をたくさんコンピュータにあげるので、プログラムのミスが早く見つかる。その代わりに書くのがめんどくさい。Kotlinは静的型付け言語なのに簡潔かつ柔軟に書ける言語

JavaScriptやPHPで書いたプログラムが動かないと思ったら、タイプミスをしていただけだった、という経験はありませんか?単純なミスは、コンピューターが見つけてくれたら楽ですよね。

スペルミス・データの種類が違うなどのミスを、実行前に見つけてくれる言語を静的型付け言語と言います。逆にJavaScriptやPHPは動的型付け言語と呼ばれます。この二つは型(データの種類)がいつ決まるかが違います。

  • 動的→プログラムを実行する時に決まる
    • データの矛盾を実行前に見つけられない
  • 静的→プログラムを実行する前に決まる
    • データの矛盾を実行前に見つけられる

ミスを見つけてくれるんだったら、いつも静的型付け言語を使えばいいじゃんと思いますよね?ところがそうはいかないんです。文字列を出力するプログラムを比べてみます。

  • JavaScript(動的型付け)
alert("JavaScript");
  • PHP(動的型付け)
echo "PHP";
  • Java(静的型付け)
public class Main {
    public static void main(String[] args){
        System.out.println("Java");
    }
}

単純に文字列を表示するだけなのに、これだけ書く必要があります。
静的型付け言語・動的型付け言語それぞれにメリットとデメリットがあります。

静的型付け

  • メリット
    • コンピュータがミスを見つけてくれる
    • 実行時には型が決まっているので、処理が速い
  • デメリット
    • コンピュータに必要な情報が多い
    • 要件が変わったときに、修正する箇所が多い

動的型付け

  • メリット
    • コンピュータに必要な情報が少ない
    • 要件が変わっても、柔軟に変えられる
  • デメリット
    • コンピュータがミスを見つけてくれない
    • 型に矛盾がないか調べながら実行するので、処理が遅い

簡潔かつ柔軟に書ける静的型付け言語があれば最強ですね。それはつまり、Kotlinが最強ということです。

fun main() = println("Kotlin") //静的型付けなのに簡潔に書ける!!

他のプログラミング言語の失敗に学び、いい点に学んだ結果、既存の動的型付け言語に負けないくらい簡潔に書けるようになっています。

Kotlinには簡潔かつ柔軟に書くための機能がいっぱいあります。紹介しきれないので、ググってください

Qiitaにいい記事があります。(投げやり)

  • 型推論
  • 拡張関数
  • ローカル関数
  • スコープ関数
  • 中置関数(infix)
  • ローカルリターン
  • デフォルト引数
  • 名前付き引数
  • データクラス
  • リストに対する処理(sumBy, groupBy, fold, first, drop...)
  • 高階関数

関数型言語の「参照透過性」

この節のまとめ:色々値が変わると、考えることが増えて大変。関数型言語やその仕組みを真似しているKotlinは値をあえて書き換えられない書き方ができる

参照透過性とは、入力が同じなら、関数の実行結果が同じになるという性質です。当たり前のことだと思いましたか?では、以下の例を考えてみてください。

自動販売機に1000円札を入れて、100円のコーヒーのボタンを押したとします。出てくる商品とおつりは、いつも同じですか?
自販機

売り切れていたらコーヒーは出てきませんし、おつりも500円玉と100円玉だったり、全部100円玉だったりしますよね。この例をプログラムに置き換えると

  • 1000円札を入れる→入力
  • ボタンを押す→関数呼び出し
  • 出てくるおつりと商品→出力
  • 自販機に入っている商品と小銭→状態

この例で伝えたかったのは、状態が変わると、出力が変わってしまうということです。いちいち状態のことを考えながらプログラミングするのはめんどくさいです。そもそも、状態が変わらなければこんなことを考える必要はありません。

なので、純粋な関数型言語では、オブジェクトの状態を書き換えないことで参照透過性を実現しています。

例えばHaskellだとこんなことはできません。(疑似コードなので、ちゃんとしたHaskellではないです。)

--使えるプログラミング言語のリスト
let skillSet = ["JavaScript", "PHP"]
--勉強会に参加したので、Kotlinが使えるようになった
skillSet push "Kotlin" --←リストへの追加はできない
for (let i = 0; i < skillSet size; i++){ --←ループ変数を1ずつ増やすこともできない
    --使えるプログラミング言語の自慢をする
    putStrLn skillSet !! i ++ "が使えるよ!!"
}
--しばらくコードを書かなかったので、全部忘れた
skillSet = [] --←再代入もできない。というか、代入と呼ばずに束縛と呼ぶ
--

Kotlinはこの考え方を部分的に取り入れて、書き換えができるオブジェクト(mutable object)とできないオブジェクト(immutable object)を区別しています。

  • 動く
//使えるプログラミング言語のリスト
var skillSet = mutableListOf("JavaScript", "PHP") //mutableなリストを、再代入ができる変数に代入
//勉強会に参加したので、Kotlinが使えるようになった
skillSet.add("Kotlin")
for (i in 0 until skillSet.size){
    //使えるプログラミング言語の自慢をする
    println("${skillSet[i]}が使えるよ")
}
//しばらくコードを書かなかったので、全部忘れた
skillSet = mutableListOf()
  • 動かない
//使えるプログラミング言語のリスト
val skillSet = listOf("JavaScript", "PHP") //immutableなリストを、再代入ができない変数に代入
//勉強会に参加したので、Kotlinが使えるようになった
skillSet.add("Kotlin") //←これはできない
for (i in 0 until skillSet.size){
    //使えるプログラミング言語の自慢をする
    println("${skillSet[i]}が使えるよ")
}
//しばらくコードを書かなかったので、全部忘れた
skillSet = listOf() //←これもできない

参照透過性以外にも、高階関数やリストに対する操作などで関数型言語の影響を受けているようです。

Javaの「write once, run everywhere(一度書いたら、どこでも動く)」

この節のまとめ:JavaはOSを選ばずに実行できるし、Javaの仕組みを真似しているKotlinも同じ。

コンパイラ言語とインタプレタ言語

KotlinはJavaという言語に強く影響を受けています。どうしてKotlinがすごいのかを説明するためには、Javaがどうしてすごいのかを説明する必要があります。ちょっと遠回りをしますが、最後にはKotlinの話につながるので、ついてきてください。

プログラミング言語には大きく分けて2種類あります。コンパイラ言語とインタプレタ言語です。

どこで聞いた比喩なのか覚えていないのですが、プログラマはコンピュータにお手紙を書くのがお仕事みたいなものです。「Webページを見せてください」「データベースの値を見せてください」「メールをあの人に送ってください」色々なお願い事があると思いますが、そのお願いを手紙に書いてコンピュータに送ります。その手紙がプログラムで、プログラムを書くのに使う言葉がプログラミング言語です。

コンピュータはプログラミング言語が分かりません。コンピュータが分かるのは、電流のON/OFFだけです。ON/OFFを数字の0と1で表した、コンピュータに分かる言葉を機械語と言います。

コンピュータにお手紙を読んでもらう(=プログラムを実行してもらう)には、大きく二つ方法があります。前もってお手紙を全部機械語に翻訳してから送るか、コンピュータが読む隣で、一行ずつ意味を説明してあげるかです。前者でお手紙を書くのがコンパイラ言語、後者がインタプレタ言語です。

前者は実行速度が速い、お手紙を他の人に真似される心配が少ない(人間は機械語が分からないので)などのメリットがありますが、困ったことがあります。

お手紙がOSに依存してしまう

Java以前のコンパイラ言語では、プログラムがOSに依存してしまっていました。OSに依存というのは、OS毎に開発・テストをする必要があったということです。そもそもOSは何のためにあるのでしょうか

コンピュータが処理を行うには、(当然ですが)自分自身のハードを使う必要があります。「ディスクのこの位置に保存しておいたファイルを表示して」みたいに、ハードについて細かくプログラムに書く必要があるとします。コンピュータを買い換えたり、自分のプログラムを友達のコンピュータで実行したりしたいときにどうなるでしょうか。

当然、コンピュータの設計も部品も違うので、プログラムを書き直しです。めんどくさいですよね。

直接プログラマが触る必要がないように、コンピュータのハードへのアクセスを代行してくれるのがOSです。OSがあるおかげでハードに対して直接プログラムする必要がありません。

ソフトが「OS君、ハードに良い感じにアクセスしてよ」というお願いをする窓口をAPIと言います。OS毎にAPIが違うので、OSが違うとプログラムも変わってしまいます。ハードに直接アクセスするよりは楽ですが、OS間の違いに対応するめんどくささは残っています。

そのめんどくささを解決したのがJavaの仮想マシン(JVM)です。

JVM

JVMとは、Java仮想マシンです。Javaの実行環境として動く仮想マシンです。仮想マシンとは、本物のコンピュータのハードを使ってコンピュータの振りをするソフトです。JVM以外にもいろんな種類があります。

JVMはJavaプログラムにAPIを提供しています。このAPIはあえて各種OSに共通する機能のみに絞ってあります。

前述のお手紙の例えでいうと、Javaでお手紙を書くと機械語ではなく中間言語というJVMが分かる言語に置き換わります。JVMが搭載されているOSに応じて良い感じに機械語に直してくれます。

ソフトが直接ハードに触るのではなく、OSを経由することでハードの違いを吸収することができました。それと同じように、直接OSにアクセスするのではなくJVMを経由することで、OSの違いを吸収することができます。

これがJavaを作ったSun Microsystemsが提唱していた「write once, run everywhere(一度書いたらどこでも動く)」です。一度書いたら、OSの違いを意識する必要なしでプログラムを使えます。これでもう、めんどくさくないですね...とはなりませんでした。

実行環境としてのJavaは優れていますが、プログラミング言語としてのJavaは長ったらしい構文でとてもめんどくさいものでした。

「こんなんでIDE作れるか!」と嫌になったチェコにある会社がJVMで動く近代的なプログラミング言語を作りました。それがKotlinです。「write once, run everywhere」を実現するJVMのいいとこどりをしたわけです。


以上!Kotlinが何故便利なのか自分なりの言葉でまとめてみました。

参考資料

Kotlin In Action
Javaでなぜつくるのか

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Javadocを書こう

javadocの重要性

コード上にコメントが書いてあると、すぐに何の処理が書いてあるのかわかりますよね
javadocを書いた場合、参照した先でもそのコメントがみられるので
javadocだけでどんな処理のものなのか把握でき、使えるというわけです

逆に、javadocを適当に書くと
そのクラスだったりメソッドが何をしてくれるのか把握できず、いちいちコードを解読しに行かなければならないので
シンプルに効率が悪いわけですね

複数人で開発するのが当たり前な現状、自分でない誰かが
自分の作ったものを使うことが当たり前なわけで
すなわち思いやりの心をもって書きましょうってことですね

どこに書くのか

classとpublicメソッドには必須でしょうね
privateやprotectedはなんだろう、離れた場所で使うことあんまないならいらないのかも?って感じですかね
最終的にわかりやすければおーけーなのでは

つまり何を書けばいいのか

あまり多く書きすぎても逆に見づらいでしょうし
少なかったら処理わかんないしで

何を参考にしましょうかと

公式でしょ

みんな大好きSystem.out.printlnでおなじみ、Systemクラスさんです

System.java
/**
 * The <code>System</code> class contains several useful class fields
 * and methods. It cannot be instantiated.
 *
 * <p>Among the facilities provided by the <code>System</code> class
 * are standard input, standard output, and error output streams;
 * access to externally defined properties and environment
 * variables; a means of loading files and libraries; and a utility
 * method for quickly copying a portion of an array.
 *
 * @author  unascribed
 * @since   JDK1.0
 */
public final class System {

実際の見え方はこう

java.lang.System

Systemクラスには有用なクラス・フィールドおよびメソッドがあります。インスタンス化することはできません。

Systemクラスによって得られる機能には、標準入力、標準出力、およびエラー出力ストリーム、外部的に定義されたプロパティお
よび環境変数へのアクセス、ファイルおよびライブラリのローディング方法、配列の一部をすばやくコピーするユーティリティ・メソッドがあ
ります。
導入されたバージョン:
      JDK1.0

クラス説明なので、


  • なにをするクラスなのか
  • インスタンスできない旨を明記
  • 全体的にざっくりどんなメソッドとかがあるのか
  • 導入されたバージョン

を記載していますね

注目したいのは段落分けの<p>タグやコードを記載する際の<code>タグだと思います
しっかりHTMLで書くことによって、たいへん見やすくなりますね
codeタグは{@code null}のようにしてもいいでしょうし、{@linkplain メソッド名 表示テキスト}のようにして
参照先に飛べるようにしてもいいですね
<ul>
<li>
</ul>
での箇条書きや、<br>での改行などで、しっかりjavadoc参照されたときを見ながら編集していくと
直書きのjavadocは多少長くなりますけど、参照先での説明がめっちゃ見やすくなりますね!

メソッドはというと

System.java
    /**
     * Reassigns the "standard" output stream.
     *
     * <p>First, if there is a security manager, its <code>checkPermission</code>
     * method is called with a <code>RuntimePermission("setIO")</code> permission
     *  to see if it's ok to reassign the "standard" output stream.
     *
     * @param out the new standard output stream
     *
     * @throws SecurityException
     *        if a security manager exists and its
     *        <code>checkPermission</code> method doesn't allow
     *        reassigning of the standard output stream.
     *
     * @see SecurityManager#checkPermission
     * @see java.lang.RuntimePermission
     *
     * @since   JDK1.1
     */
    public static void setOut(PrintStream out) {
        checkIO();
        setOut0(out);
    }

実際の見え方は

void java.lang.System.setOut(PrintStream out)

setOut
 public static void setOut(PrintStream out)

「標準」出力ストリームを割り当てし直します。 
セキュリティ・マネージャが存在する場合は、標準出力ストリームを割り当てし直してよいかどうかを確認するために、RuntimePermission("setIO")アクセス権を使ってcheckPermissionメソッドが呼び出されます。
パラメータ:
      out - 新しい標準出力ストリーム
例外:
      SecurityException - セキュリティ・マネージャが存在し、そのcheckPermissionメソッドが標準出力ストリームの再割り当てを許可しない場合。
導入されたバージョン:
      JDK1.1
関連項目:
      SecurityManager.checkPermission(java.security.Permission), RuntimePermission

ということで、やはり
@param引数(out アウト とか翻訳しただけでなく、どんな引数が入るのかしっかりと情報を)
@return戻り値(取得結果 とかざっくりせずに、何を返してくれるのか具体的かつ簡潔に)
@throws例外(どんな場合に起こるのかを漏れなく簡潔に)
@see参照
@since導入バージョン
などが重要みたいですね
ドキュメントで重要そうに見えるのは


  • 何をするメソッドか
  • 場合によって違う動きをするならその旨
  • (書いてないけど)引数にnullはいいのか
  • 戻り値にnullがあり得ないとかどうとか

みたいなこと書いてあったらうれしくないですか

だからといって

たいした処理でもないやつに100万行の説明文あっても無駄なように、書きすぎもよくなくて
程よくわかりやすく、シンプルに明確に
めっちゃむずくねそれ...

そもそも命名が正しければおおむね何してくれるのかわかるわけで、その上javadocがあればもう完璧って感じだと思うので
命名とjavadocが重要ですよねやっぱ

ということでjavadocをしっかりと書いていこうと思いました

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

人生最後に学ぶプログラム言語とは? (生涯給与3億円クラブに追いつきたい場合)

序 毎年、新しいプログラム言語を学んでますか?

javaアドベント・カレンダーの場をお借りしての、ポエムのお時間です。Javaは、数年前にAndroid案件で書いたことがあります。今どきのIDEの補完は偉大だね。
今日は、みんな大好き、どのプログラム言語を学ぶべきかというお話です。ただしアダルト(大人)版の。

さてさて、けっこうな年数を何かしらの言語でコードを書いている皆さん。当然のごとくJavaは学んだことかあり仕事でも書いたことがある、というか大抵Javaしか書かんといった方も多いのではないかと思われます。そんな皆さんは、どこかしこで言われているように、毎年新しい言語を学んでますか?
僕は毎年、中途半端に学んでいます。

しかし、たぶん、ですが、多くの皆さんにとって、年の数ほどに学ぶ価値のあるプログラム言語ってないのでは、と思います。特に、いい年したおっさんの場合、学ぶ価値がありそうなプログラム言語の数って、年の数の半分以下なのではと思われます。

Javaを学んだのは23年前(JDK1.0の出た年)である私は、これまで、いくつの言語を学んだのだろうか?
私の場合、一応コードを書いたもので名前を覚えているものを列挙してみると:

>>> A="Basic,Z80,6809,C,C++,Object-Pascal,Java,Ruby,Perl,Scala,R,Go,Haskel,F#,Kotlin,Swift,Objective-C,Groovy,Python,Dart,Nim,Elm,Julia".split(",")
>>> len(A)
23

となる。覚えているものだけだと23。あと数個はあるはずなので、年の数の半分は超えているかな。i386のアセンブラは挫折しましたが。あ、JavaScriptも書いていたのだった。。

さて、プログラミングスクールのSEOが効いてる昨今、『最初に学ぶべきプログラミング言語』の話はいくらでも目にするのだが、『人生最後に学ぶべきプログラム言語』の話はあまり目にしない(ボケ防止といった文脈で目にした事はあるが)。
ということで、誰かが書いてみるべきな気がする『人生最後に学ぶべきプログラム言語』、私の場合を書いておく。

我々は、長期的にはみな死んでいる(ケインズ)。ということで、数個プログラム言語を学んだくらいの方にも参考になるかも(...かなぁ?)。

人生後半とか最後とか言うと、年金経済学っぽいゼミで、赤ちゃんの多様性より、老人の多様性のほうがはるかに大きい、とか言うことを聞いたことを思い出される。大人の事情を抱えたりしている皆さんの人生はそれぞれだろうから、『人生最後に学ぶべきプログラム言語』はたぶん人それぞれ。

『人生最後に学ぶべきプログラム言語』、私の場合を無理やり三行で。

  • 私は老後にあと数千万円は稼ぐ必要があるが、時間単価をあまり落としたくはない。
  • 60歳を超えても時間単価が良さそうなのは、プロマネか新人プログラミング教育の場。
  • となるとJavaなのだが、Javaは老眼に辛そうなので、ほぼ互換であろうGroovy3.0をちきんと人生最後に学ぶプログラム言語としたい。

あくまで、2019年末時点での考え、ね。

(付記)生涯給与3億円クラブに追いつきたいがために、もう一言語を学ぶ。

さて、私は、コードを書いてそれなりに稼いで、それなりに投資をして、老後を迎えたい。
それには定年まで務めた後に数千万円必要となる。

ということで、社会人としてコードを書くと、だいたいいくらくらい稼げるものなのだろうか?といったあたりの算段を少し書いておこう。

少し参考になる資料が以下の『生涯給料「東京都トップ500社」最新ランキング』だ。
https://toyokeizai.net/articles/-/313934?page=5
ずらずら並ぶ、名前は知っているであろう企業の中で注目していただきたいのは、生涯給料ジャスト3億円と推定されているIT企業だ。キラキラなんたらのサイバーエージェント、英語公用語化がネタにされることが多い楽天といったあたり。
こうした企業に仮に新卒から定年まで勤め上げたくらいで正社員としての給与で3億円もらえる、と(...そんな人はごくごく少数だろうが)。フリーランスエンジニアで換算すると、その1+1/3倍である4億円を生涯で稼げればよし、といったところなのだろう。
私はそもそも新卒で就職してないし、途中でブラックな職場で壊れたりしているので、後半追い上げても正社員換算で2.5億円くらいしかいかない計算となる。すなわち、後、数千万円がほしいところ。

なぜ、人生最後に学ぶのは《言語X》ではないのか?

人生最後に学ぶべきはrustでは?

私は社会人人生をおそらくscalaを書き続けて終えることとなる。
ScalaのようなJVM言語を学んでいると、時としてネイティブコンパイルできる言語がうらやましくなる。
特に現代風なrustは、なんかかっこよさそう。
...だが、下回りの言語であるrustを定年後のおっさんがガリガリ業務で書くのは、何か違う気がする。
(もちろん、そんなおっさんがいたらカッコいいが)
ということで、私の場合、年齢上の理由で却下。
あ、若い人はrustちゃんとやっておくと稼げると思うよ~

人生最後に学ぶべきはelmでは?

rustとは真逆と言えよう立ち位置のフロントエンド界隈言語elmにはかなり惹かれる。
(elmって何という人は、最初にここを読むようにしよう。)
webフロントエンドに特化した分、記述は簡潔、そんな一方で自然に型安全に書ける。
elmなら認知症が迫りくる年になってもセキュリティ大丈夫なコードがかけそうな気がして、素晴らしい。
ただ、惜しいことに、UXに弱い私の場合、定年後にelmで数千万円稼ぐ未来が見えなかった。
フロントエンドよりの若い方は、elmをきちんとやっておくと間違いなく幸せになれると思う。

人生最後に学ぶべきは...では?

その他flutterで存在感を取り戻したdartや、マイクロサービスの実務言語となったGoなどを実務で使えるようにする、といったものもありえようが、
老人向けではない気がするので、いったん却下。
ボケ防止にHaskell極めるとかいうのも、なんか寂しい気がしたので却下しておく。

なぜ、人生最後にgroovy3.xを学ぼうと考えているのか?

さて、groovy3である。注目している人は少ないと思う。
何しろ、Alt-Javaとしてのgroovyの歴史は、他のJVM言語より長いため、groovy自体が、今更、あまり話題とならないためだ。

注目に値するのは、Scala/Kotlinをはじめとする他のJVM言語と決定的に違うのは、rubyばりのスクリプト言語である一方で、Javaとの表記上の互換性の高さである。
このあたりは、groovyを実務に使ってらっしゃるNTTテクノクロスさんの紹介記事を読んでもらえば良いだろう。
https://www.ntt-tx.co.jp/column/tec/java_01/
(...つまりは、Springベースのフレームワークで固く開発しますといった案件で、
開発生産性を上げるためにgroovyも併用しますといった提案が行いやすいといった意味合いがある。)

そんな古くからあるgroovyだが、Java8以降のJava自体の進化に対応したGroovy3.0がリリース間近である。...Java自体の言語仕様が大きいこともあってか、かなり長いこと間近のまま、だが。
http://groovy-lang.org/releasenotes/groovy-3.0.html

ちなみに、Javaのバージョン管理でSDKMAN入れてる人は、Groovy3.0のrcがすぐに試せるからね。

$ sdk list groovy

==== BROADCAST =================================================================
* 2019-12-08: Groovy 3.0.0-rc-2 released on SDKMAN! #groovylang
* 2019-12-06: Springboot 2.2.2.RELEASE released on SDKMAN! #springboot
* 2019-12-06: Springboot 2.1.11.RELEASE released on SDKMAN! #springboot

要するに、groovy3.0を学ぶと、今風のJavaのキャッチアップもできるということ。
Javaもrubyもscalaも学んだことがある者が、それらを合わせたようなgroovyを今更学び直すだと?
覇気のないこと、この上ない。

だが、そんな華麗でない選択が、加齢を考慮に入れた選択というもの。
人は忘れる。そして、だんだんボケていく。
そんなおっさんが化石にならないためには、教育言語としては有用であるJavaの10年前、20年前しか知らないようではいけない(私はandroid Javaを書いたのが最後なので 10年前のJavaであろうJava6相当の実務知識しかない)。

とはいえ、今更仕事でもないのに、Java8をとかいっても、あまり気が入らない。そんなおっさんの私でも、スクリプト言語として楽できるgroovy3ならば、そこそこ楽しんで学べるかな、と。

そう、まぁ、人生最後についての考えは、人それぞれであるとして、(というか、最後に学ぶ言語はプログラム言語でない人の方が多いか?)
わたしの場合、人生最後に学ぶプログラム言語もコスパで選ぶ、それがgroovy3だということである。今風のJavaに業務上触れられない人は、人生最後でなくてもいいからgroovy3を週末にでもちょっと学んで置くのが吉だと思うよ。

私のgroovy3学習記は、groovy3の正式リリース後に書くとしよう。

最後に。人生最後にプログラム言語を学ぶ使命感を書いておく。

最後に、人生最後もなぜプログラム言語を学ぶのか、だけ書いておこう(数千万円稼ぐだけなら、他の選択肢もあるだろうし)。
それは、プログラムを書く若い人に、なるべく早くにオブジェクト指向言語の勘所を伝えたいと思うから。わかりやすいところで言うと、『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法』に近いレベルをSIerの新人教育などの場で伝えておきたいと思うから。オブジェクト指向なきwater fall開発の現場で炎上して洪水に流されて去っていく若者をもう見たくないから、なんてね。
今はドメイン駆動設計を淡々と学ぶ我が身の、ちょっとした社会貢献ともなればいいなと思ったりして。

ということで、人生いろいろ。
おっさんもそうでない人も、年末年始は、来年学ぶプログラム言語、そして、人生最後に学ぶプログラム言語を考えてみよう。

ポエムの時間は、以上♪


...ぁあ,graalVMとnim1.0についても書く予定だったのだったが、出勤時間となったので、時間切れ。...SIer の世界でなくて、ゲーム業界とかに向けたお話。
graalVMについては、後ほど書いてリンクをここに貼ろう。。JVM資産が使えるgraalvmが活きるのは、低レベルながら簡潔な記述に特化したnimのような言語だと思うと、といったお話。
ちなみに、pythonでgraalvmは辛かった。。
実は、老後をゲーム&eスポーツ業界で過ごして数千万円稼ぐのもいいかなとも思ったりしているんだけど、その場合、人生最後に学ぶことになるのはgraalvmと、nimかalt-pythonかな ;-)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Eclipseプロジェクト(Maven)のアプリのURLを変更する。

もともとあったEclipseプロジェクトをMavenに変更したときに適当な名前を付けてしまったため、元のURLが変わってしまいました。
おかげでアプリがうまく動かない事象が発生したので:sweat_smile:、その解決策を備忘録として残してあります。

今回やりたいこと。

スクリーンショット (12).png

↑アプリを開いた際のトップページのURLが「localhost:8080/test1/」となっているところを「localhost:8080/docoTsubu2/」に直したい↓。

スクリーンショット (11).png

  • プロジェクト配下にある、pom.xmlを書き換える。

    • < artifactId >xxx< /artifactId >の中身を書き換える。 スクリーンショット (8).png
  • コンテキストルートの変更

    • プロジェクト「右クリック」→「プロパティ」→「Webプロジェクトの設定」→「コンテキスト・ルート:」の中身を変更し「適応」をして閉じる。 スクリーンショット (6).png
  • Tomcatに保存されている、コンテキストルートパスの変更

    • 「Serversプロジェクト」を開く
    • 「Server.xml」を開く
    • 「ノード」の欄から、「Server」→「Service」→「Engine」→「Host」→「Context」の順で開いていく。
    • ノード欄の「Path」のコンテンツ部分を変更する。 スクリーンショット (9).png
  • 最後に変更を保存してアプリを実行しURLが変更されていることを確認します。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Mediatorパターン

オブジェクト間のやり取りを集中化するパターン。

Mediator …「仲介者」。

Mediatorの働き

密結合 → 疎結合。
 ∟ Mediatorを介して、オブジェクトを完全に分離する。

利点

  • Mediatorがサポートするオブジェクトをシステムから分離することにより、そのオブジェクトの再利用性が向上する。

  • 制御を集中化することで、システムの保守性が向上。オブジェクトのやり取りが簡素化。

欠点

  • 設計を間違うと、Mediatorオブジェクト自体が複雑になる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む