Intellij IDEAとTomcatとコンソールの文字化け
はじめに
すごくちょっとしたことなのだけど、5分以上はまったのでメモ。
解決方法
以下のファイルに「-Dfile.encoding=UTF-8」と追記する。
C:\Users\<ユーザ名>\.IntelliJIdea2019.2\config\idea64.exe.vmoptions
はまったこと
以下のファイル記載しても、設定は有効にならない。
C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin\idea64.exe.vmoptions
おそらく、読み込まれるファイルに優先順位があるのでしょう。
2019年7月現在CentOS 6.4をEC2で新規に使おうとしたら意外と大変だった。
作業前に決めておくこと
HVM AMIs (GRUB)を作成するか、Paravirtual AMIs (PV-GRUB)を作成するか
両者の解説は、User Provided Kernels - Amazon Elastic Compute Cloud に記載されています。
主な違いは以下の通りです。
| 種類 | 作成したAMIを起動できるインスタンスタイプ | AMI構築時のポイント |
|---|---|---|
| HVM AMIs (GRUB) | 現行世代のインスタンスと旧世代のインスタンスタイプ(全部の旧世代で起動するかは不明)。 | Partition Tableの設定が必要(parted等のコマンドで設定する)。 |
| Paravirtual AMIs (PV-GRUB) | t1等旧世代のインスタンスタイプのみ。*1 | Partition Tableを設定しなくていい。 |
作業前に知っておくべきこと
ISOイメージからOSを(多分)起動できないという事実
結構調べたんですが、方法がさっぱり分からず。
私はISOイメージを使わずにセットアップしました。
どこのサイトでCentOS 6.4を配布しているのか
「何を当たり前な」と思うかと思いますが、古いディストリビューションはミラーサイトではもう配布していないことがあります。
日本のミラーでは、もう、CentOS 6.4は配布していませんでした。
私はhttp://vault.centos.org/から入手しました。
インストール方法を解説したサイト
| 種類 | サイト |
|---|---|
| HVM AMIs (GRUB) | EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita |
| Paravirtual AMIs (PV-GRUB) | EC2でCentOS6のEBS-Backed AMIをゼロから作る - SEEDS Creator's Blog *2 |
今回私は、EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita のサイトを参考に作成しました。
インストール方法を解説したサイト(EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita)に対する補足
前述のサイトを見ながら作業していく中で、気づいた点があったので、僭越なのは承知なのですがメモしていきます。
OSはCentOS 6.xでも良い
「作業用インスタンスを作成」ではAmazon Linux 64bitを使っていますが、私はCentOS 6.10にしました。
特別な根拠はないのですが、まあ、バージョンが近いOSの方で作業した方が良いかと思っての、験担ぎ的判断です。
ただし、途中で使うツールが時々インストールされていないので、適宜yum installでインストールする必要がありました。
「EBSのパーティション作成。フォーマット。マウント」のデバイスの名前(/dev/xvdf)について
当然なのですが、AWSコンソール上から/dev/sdf以外でマウントした場合は別の名前になります。
lsblk*3コマンドを使用して、自分の環境ではどういう名前になっているか確認してから作業します。
私が作業したインスタンスではlsblkは以下の結果になりました。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part / xvdb 202:16 0 30G 0 disk └─xvdb1 202:17 0 30G 0 part
ですので、私の環境ではdev/xvdbを使用することになります。
「EBSのパーティション作成。フォーマット。マウント」のフォーマットで指定するデバイス名は末尾に1がついている方
ちゃんと記事を読めば失敗しないのですが、デバイス名は末尾に1がついている方を使用してください。
私の場合は以下の通りですね。
mkfs.ext4 /dev/xvdb1
うっかり、末尾に1がついてない方を指定してもコマンドは成功してしまうのですが、Partition Tableが変になってしまい、grubの設定ではまります。
間違った場合、parted -lで確認した際にloopというみたことないPartition Tableになります。
以下に間違った場合の例を示します。
# parted -l Model: Xen Virtual Block Device (xvd) Disk /dev/xvda: 8590MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 8590MB 8589MB primary ext4 boot Model: Xen Virtual Block Device (xvd) Disk /dev/xvdb: 32.2GB Sector size (logical/physical): 512B/512B Partition Table: loop Number Start End Size File system Flags 1 0.00B 32.2GB 32.2GB ext4
インストール用の yum.conf を作成で前提としているrikenさんのmirrorが無い
http://vault.centos.org/のみでどうにかします。
鍵のダウンロード
cd /mnt wget -O ../RPM-GPG-KEY-CentOS-6 http://vault.centos.org/6.4/os/x86_64/RPM-GPG-KEY-CentOS-6
repos.confの作成の内容は以下のようにします。
vi ../repos.conf
[ami-base]
name=CentOS-6 - Base
mirrorlist=file://${PWD}/../mirrorlist.centos
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6
[ami-updates]
name=CentOS-6 - Updates
mirrorlist=file://${PWD}/../mirrorlist.centos.updates
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6||<repos.confから参照するmirrorlist.centosは以下のように作成します。
vi ../mirrorlist.centos
http://vault.centos.org/6.4/os/x86_64/
repos.confから参照するmirrorlist.centos.updatesは以下のように作成します。
vi ../mirrorlist.centos.updates
http://vault.centos.org/6.4/updates/x86_64/
あとは記事通りでＯＫ
うっかり手順を飛ばさないように気を付けて行いましょう。
さいごに
こうやって整理して書くと大半は参考記事通りなんですが、HVM AMIs (GRUB)とParavirtual AMIs (PV-GRUB)の違いをちゃんと理解しておらず、やたら時間が掛りました。
Paravirtual AMIs (PV-GRUB)の手順で途中までやって、「あれ。なんか使いたいインスタンスタイプで起動できない？？」となって、あーだこーだして時間を浪費する結果に。
*1:これが実は結構な制約で、東京リージョンの場合、GUIから選べるインスタンスがあんまり無いです。Linux AMI 仮想化タイプ - Amazon Elastic Compute Cloudに載っているものは選べてよさそうなんですが、実際に選べるのはもっと少ないという。
*2:明確にはParavirtual AMIs (PV-GRUB)と記載されていないのですが、「作成したEBSをAMI化する」のところでHVM AMIs (GRUB)作成時には選べないカーネルを選択しているので、区別がつきます。
*3:Linux で Amazon EBS ボリュームを使用できるようにする - Amazon Elastic Compute Cloud
Apache Maven Site PluginでArtifactResolutionExceptionが出力されて困ることがある。
はじめに
件名通りのことが発生して、地味に困ったのでメモ。
解決方法
以下の記事に記載されています。
tcollignon.github.io
解決方法の補足
私は「Tell maven-site-plugin to not using inheritence」の部分を読んで解決したのですが、ちょっと苦労したので補足。
前述の記事は閉じタグが書いてない
忘れずにprojectを閉じる必要があります。
<project name="test" combine.self="override"> </project>
上記は何にかく？
以下のファイルに書きます。
前述のproject要素だけでもOKです。
/src/site/site.xml
Jenkins 2.5以降のDeclarative PipelineでCheckstyle PluginとFindBugs Pluginを使いたい
はじめに
Jenkins 2.5以降のDeclarative PipelineでCheckstyle PluginとFindBugs Pluginを使おうとしたら、やたら苦労したのでメモ。
環境
- Jenkins ver. 2.60.3
したかったこと
- Declarative Pipeline*1でPipelineを書く。
- Maven で出力したCheckstyleとSpotbugsの結果をJenkinsに表示する。
- parallelとか凝ったことはせず、シンプルにまずはやりたい。
Pipelineの書き方の例
mvnがBUILD FAILUREになっても後続が実行されるようにcatchErrorで囲みます。
pipeline {
//中略
stage('checkstyle and spotbugs') {
when {
branch 'develop'
}
steps {
catchError{
sh 'mvn checkstyle:check spotbugs:check'
}
checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: ''
}
}
//中略
}
checkstyleおよびfindbugsのプラグインは先に書いても結果を収集してくれるので、これでもいけます。
pipeline {
//中略
stage('checkstyle and spotbugs') {
when {
branch 'develop'
}
steps {
checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: ''
sh 'mvn checkstyle:check spotbugs:check'
}
}
//中略
}
はまったこと
pluginの解説をみると全部のパラメータにoptionalと書いてあるが、省略するとpipeline実行時にエラーが発生する。
首記のとおりです。以下のリファレンスを読むと全部のパラメータにoptionalと書いてあるのに……。
リファレンスを見てもさっぱりわからないので、【Jenkins】Declarative Pipeline入門 - Qiita で解説されている「コードスニペットを自動で生成してくれる機能」を使用して生成したコードを貼りつけました。
Mavenの実行結果がBUILD FAILUREになると後続処理が実行されない
首記の仕様があるため、以下のように記述すると結果がJenkinsに表示ません。
mvn checkstyle:check、mvn spotbugs:checkともに指摘を検知するとBUILD FAILUREになりますものね。
//中略 steps { sh 'mvn checkstyle:check' checkstyle canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', healthy: '', pattern: '', unHealthy: '' sh 'mvn spotbugs:check' findbugs canComputeNew: false, canRunOnFailed: true, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', pattern: '', unHealthy: '' } //中略
さいごに
苦労してpiplelineを書いたのですが、Checkstyle PluginとFindBugs PluginはDeprecatedです。
Warnings Next Generation Pluginが後継のpluginのようです。
余談ですが、最初、この名前みても後継のpluginであることが分からなかったです。
この記事書いている途中に復習していて気づいた。
*1:余談ですが、Scripted Pipelinesという別の書き方が存在することを知らず、「なんか書き方複数あるっぽい？？」と混乱しながら調査してた
CSSフレームワークの使いやすさについて「えっ。そこがそんなに大事だったの？」と思った話
起きたこと
Bulmaを使って画面デザインを頼んだところ、進捗が思わしくなかったのです。
で、チームのメンバーから「Semantic UIに変えてみたら？」と提案があり変更したら、進捗が劇的に改善されました。
そこで私はびっくりです。
何がそんなに違うか分からなかったためです。
ヒアリングして分かったこと
「使いやすさの違いはどこにあるのです？」と、画面デザインをしている人にヒアリングしました。
曰く「コピー＆ペーストのし易さが違う」と。
どういうことなのかもう少し聞いたところ…。
Semantic UIは、Button | Semantic UIの左側から要素を簡単に選んで、コード例のページに遷移できる。
これが大きかったらしいです。
BulmaはDocumentation | Bulma: Free, open source, & modern CSS framework based on Flexboxからドリルダウンしていく必要があり、確かにちょっと使いにくいとは思います。
軽くヒアリングしたので言わなかった理由もあるのだと想像していますが、予想外の理由でした。
@Betaが付与されているクラス使用時の警告を抑止したい
はじめに
GitHub - google/guava: Google core libraries for Javaのクラスに@Betaが付与されているものがあります。
@Betaが付与されているクラスを使用すると警告がでます。
「抑止したいなー」と思ったのですが、抑止方法探すのに5分ぐらい掛ったので、将来の自分のためにメモ。
抑止方法
クラスの使用箇所に以下のように記載すると抑止できます。
@SuppressWarnings("UnstableApiUsage")
以下のページに記載されておりました。
stackoverflow.com
さいごに
Guavaの公式ページで見つけられると本当はよかったんですけどね。
アプリケーションの挙動に影響を与える部分でもないし、公式ページのどこに載っているかは気にしないことにします。
