MVのプロジェクトをリポジトリ管理する時は.gitignoreを意識しよう

MVのプロジェクトをリポジトリ管理してみたので、
備忘録も兼ねて残しておきます。

パブリックリポジトリで公開することのリスク

https://tkool.jp/support/guideline
こちらの利用規約にある通り、
画像や音声ファイルは同シリーズでのみ利用できます。

ですので、誰かがパブリックリポジトリに公開している
MV標準の画像や音声を第三者がダウンロードして勝手に違うプログラム作品で
利用するようなことは、制作者自身で自衛するべきだと思います。

巷にはGitHubページで作品を公開するような手法もありますが、
あの手法自体、危険だと思っています。
ファイルが暗号化されていればまだマシだとは思います。

そもそも画像や音声ファイルをリポジトリ管理してどうなる

画像や音声ファイルはバイナリファイルなので
コードの差分も見れないしですし、ファイルサイズも大きいんです。
あまり知られていないかもしれないですが、GitHubリポジトリサイズは
1GB以上使うと警告がくる可能性があるみたいなんです。

1GBなんて、動画やPSDファイルなんて置こうものなら、
一瞬でなくなることでしょう。
コード管理することが主目的のGitHubでサイズの大きい画像や音声ファイルを
管理すること自体が望ましくないことです。

それならどうする?

.gitignoreでリポジトリ管理から除外しよう。

.gitignoreファイルに除外対象ファイルを記載すれば、
対象ファイルを無視した形でコミットされます。
MV用の.gitignoreファイルを作ってみたので下記に記載します。

# .DS_Store
.DS_Store

# audio
/audio/*

# audio -> bgm
!/audio/bgm/
/audio/bgm/*.m4a
/audio/bgm/*.ogg
!/audio/bgm/.gitkeep

# audio -> bgs
!/audio/bgs/
/audio/bgs/*.m4a
/audio/bgs/*.ogg
!/audio/bgs/.gitkeep

# audio -> me
!/audio/me/
/audio/me/*.m4a
/audio/me/*.ogg
!/audio/me/.gitkeep

# audio -> se
!/audio/se/
/audio/se/*.m4a
/audio/se/*.ogg
!/audio/se/.gitkeep

# fonts
/fonts/*.ttf
!/fonts/.gitkeep
/fonts/bk/

# img
/img/*

# img -> animations
!/img/animations/
/img/animations/*.png
!/img/animations/.gitkeep

# img -> battlebacks1
!/img/battlebacks1/
/img/battlebacks1/*.png
!/img/battlebacks1/.gitkeep

# img -> battlebacks2
!/img/battlebacks2/
/img/battlebacks2/*.png
!/img/battlebacks2/.gitkeep

# img -> characters
!/img/characters/
/img/characters/*.png
!/img/characters/.gitkeep
/img/characters/bk/

# img -> enemies
!/img/enemies/
/img/enemies/*.png
!/img/enemies/.gitkeep

# img -> faces
!/img/faces/
/img/faces/*.png
!/img/faces/.gitkeep
/img/faces/bk/

# img -> parallaxes
!/img/parallaxes/
/img/parallaxes/*.png
!/img/parallaxes/.gitkeep
/img/parallaxes/bk/

# img -> pictures
!/img/pictures/
/img/pictures/*.png
!/img/pictures/.gitkeep

# img -> sv_actors
!/img/sv_actors/
/img/sv_actors/*.png
!/img/sv_actors/.gitkeep
/img/sv_actors/bk/

# img -> sv_enemies
!/img/sv_enemies/
/img/sv_enemies/*.png
!/img/sv_enemies/.gitkeep

# img -> system
!/img/system/
/img/system/*.png
!/img/system/.gitkeep
/img/system/bk/

# img -> tilesets
!/img/tilesets/
/img/tilesets/*.png
/img/tilesets/*.txt
!/img/tilesets/.gitkeep

# img -> titles1
!/img/titles1/
/img/titles1/*.png
!/img/titles1/.gitkeep

# img -> titles2
!/img/titles2/
/img/titles2/*.png
!/img/titles2/.gitkeep

# movies
/movies/*
!/movies/.gitkeep

# save
/save/*
/save/*.rpgsave
!/save/.gitkeep

pushするとこんな感じで管理される。

f:id:yasay:20170808142222p:plain いい感じですね。

もちろん、imgディレクトリには何も入ってません。

f:id:yasay:20170808142326p:plain .gitignoreによる除外設定の目的は達成しました!

プラグインはライセンスの確認を!

PluginはMITライセンスで改変が可能なモノが多いですが、
使用するPluginのライセンスを確認した後にコミットすることをオススメします。

画像や音声ファイルなどは、管理手法を明記する。

README.mdに記載すると良いでしょう。
必要ならコピースクリプトを作成してもよいですね。

プライベートリポジトリも考慮しよう

MVで複数人で作業すること自体が
レアケースだと思いますが、そういったことも可能かもしれません。

今回のケースはどちらかというと、自動ビルドの起点だったり、
一人で複数環境で作業するようなことを前提としてリポジトリ管理について書いています。

ですので、もし他の人に自分のprojectファイルを見られたくない時は、
リポジトリをプライベートにして参照できないようにしましょう。

GitHubではできませんが、
Bitbucketなら5人までならプライベートリポジトリを無料で作成できます。
bitbucket.org

以上、参考になれば幸いです。
よい制作活動を!私はそろそろサーバーサイドに着手しますw

「ファーストリテイリング × クラスメソッド勉強会」に行ってきたよ!レポート

マイクロサービスとAIについての勉強会ということで、
わくわくしながら行ってきました。場所はSAPオフィスです。
dev.classmethod.jp

ユニクロなど大手衣料品店を経営するファーストリテイリング様と、
クラスメソッド様の合同勉強会です。
採用活動も目的としてあるようでしたが、私はエントリーする予定ありません(笑)
マイクロサービスの苦労話が本当に参考になる勉強会でした。
また、パネルディスカッションは私の価値観を大きく変える可能性のあるものでした。

まずは、レポートしていきます!

レポート

FRが取り組むmicroservicesとアーキテクチャ変革

  • FRの取り組み
    • 技術力の長期的な確保と選定
    • 日本から世界に向けてチャレンジを
    • グローバルチームの構築
  • IT内製の実態
    • AWS4000台、マルチリージョン利用
    • AzureやGCPも使っている。
    • CDNにはAkamai
    • JavascriptJavaがメインになる。
  • マルチブランド・マルチリージョン
    • 店舗・EC含めてビジネスが十分に複雑
    • 変化のスピードが非常に早い→通常の会社より5倍くらいのスピードがある会社。
  • Queueにkafkaを利用してたりする。
  • Microservice 良い点
    • 技術負債は返しやすいので技術選定の心理的負担が比較的低い
    • 障害の局所化。全死のリスクが低い
    • 開発が平行でできやすい
    • クラウドで力技回避が比較的しやすい
    • 責任分界がわかりやすい
    • FR様のような複雑な環境下では、逆に他の方法ではうまくいかない。
  • Microservice 課題
    • 技術的に統制効きにくい
    • 運用は自動化込みじゃないと難易度があがる
    • 各サービスでのプロダクトマネージメントの観点が必要
    • 各サービスでオーナーをしっかりたてていく必要がある
  • プリミティブなビルディングブロック探しが大事(最初のキーとなるコンポーネントがあるから、上のサービスができる)
  • ビジネスバリューを出すための最小粒度が大切(ビジネスドメインとWillが重要)
  • 大事なのはビジネスを支える最小単位のコンポーネントは何かを考える必要がある
  • Microservices for data
    • 実績データ
    • 計画領域
    • IoT
    • 各種マイクロサービス
    • イメージ管理
    • アナリティクスなど
  • →データプラットフォームに格納して、あとからどうやって活用するかを考える。
    • データの長期の保存と、データの利活用を分ける。すごいなー。
  • Microserviceを支えるDevOps
    • インフラの自動化+デプロイの自動化が基本。
    • 課題は標準化・大きな粒度での自動化などがまだ
    • ツールだけから、組織で広域な自動あの取り組みへ
  • 自動化していくにあたり、問題にぶちあたる
    • 大量の技術負債
    • 組織的な問題や仕事の分量そのものの見直し
    • プロセスの見直しや役割がおかしい部分が明らかに
    • 全員がちょっとづつコンフォートゾーンから出る必要性
  • 自動化そのものよりも、その過程でのプロセスや組織体制・チームの分担などの変化が大事に思える。
    • ツール選びで何か変わったわけではない。
    • 呼び水となったのは運用不可を劇的に下げたいなど
  • ビジネスのバリューストリームへの貢献度は低い
    • 今品質が大事なのか、タイムラインが大事なのか、
    • それに応じて自動化の仕組みが変わってくる。
  • みんなで取り組まないと定着しない・・。
    • ツールだけで達成できるものじゃない。
  • これからのアーキテクチャを考える。
    • 基本的にはone way(大きなものを適切な粒度に分界)で、これは避けられない
    • SoR的なことだけが求められているわけでもなく、顧客同行により常に変化していく必要がある
  • KISS
  • YAGNI
  • 関心事の分離
  • リスコフの置換
  • Microservice.ioを見れば、どのようなデザインパターンや黄金律があるのか、大体まとまっている。
    • すごいな。microservices.io/patterns/index.html
  • まとめ
    • Microserviceは総合力。技術だけでなくて、チーム編成からDevOpsまで含めてやらないと効果はでない
    • 足回りのDevOpsは当たり前に強化する必要がある
    • チーム編成も大事。色々なタイプの人が必要。
    • 全体の相互理解・底上げ、普通の話だが大事
    • 世の中の複雑さをいかにシンプルに解決するか
    • ビジネスを成立させるための最小粒度のコンポーネントが大事

Amazon Alexa の衝撃と新たなエコシステム

  • Alexaを使った音声インターフェースの事業部について
    • クラスメソッドってデカイんだなー・・。
    • 700社から1000社と取引
    • 世界にまたがるオフィス
    • セルフマネジメントとアウトプットを重視する会社
    • 子供が生まれたら半強制的に休ませる
  • Alexa事業部について
    • 設立の経緯は、一言でいうと面白そうだから。
    • iPhoneが出てきた頃の黎明期に似ている!?
    • 新しいUIが出てくる頃には世の中は激変する傾向にある?
  • 世代別の利用サービスから見る音声の需要
    • シニア層は音声インターフェースを必要とするはず
    • 国による違いはなくなってきているけど、世代間のギャップのほうが大きい
  • 働く人が必要なのに減る。
    • 人が少なくなっていくなかで、付加価値の高い業務に注力して、付加価値の低い業務は自動化などを推し進めていく必要がある
  • 裏側のシステムが重要(カスタムスキルはOAuthを利用する必要ある的な)
  • カスタムスキルの例
    • スタバ - 直近10店舗で注文したドリンクの再注文やスタバカードの残額確認
  • クラスメソッドのカスタムスキル、20個くらいある。
  • 帳票の仕組み+音声サービスでユーザーエクスペリエンスを目指す→それがEcho Show
  • dash wand→バーコードリーダーがついていて、Amazonで注文できる。さらに音声操作できる。
  • VUIによる個人ではなく企業への問題解決のために、事業部署を設立的な。
  • まとめ
    • 音声はすべての人々にリーチする
    • その技術を使って、事業の価値を高める。

所感

たまに、このような魅力的な勉強会があるから、勉強会は本当に行くべきだと思う。
今回は、自分自身のITの価値観が変わる出来事だったかもしれない。

それはパネルディスカッションで起きました。

レガシーになることを意識する

私はここ最近、様々な技術知識の吸収を行ってきましたが、
これらの技術も最終的にレガシーになりえるわけなんですよね。
つまり、技術を追い求める上で、その知識はどれもレガシーになりえることを覚悟しておかなければならないわけですね。
これはAWSも同じことなんだと思います。。私はAWSの認定資格を取得しましたが、
この認定資格すら、レガシーになりえるわけですね。

そして、AWSは100以上のサービスがあるわけですが、
実際に主流として使われているサービスが100以上あるわけではないということも、
理解しなければいけませんでした。
AWSなどのパブリックIaasは非常に魅力的ですが、その全てのサービスが
ITベンダーに受け入れられているわけではない、ということなんだと思います。

主催会社様の意外な印象

個人的に意外な印象を受けたのが主催会社様の運用保守メンバーが
全社員の3分の1近くを占めていることでした。
私は今まで散々運用保守はやってきたので、
最近はもっと違うことをやってみたいと考えています。
しかし、お客様と取引する関係上、
やはり簡単に今の案件を抜けることは難しいのでしょう。
システム屋、とくにサーバ屋は運用保守とは切っても切れない関係にあるのでしょうね。

「分からない」ということを正確に伝えることのリスク

それと、自分が今持っている引き出し知識以上のことが分かっていないことを
ちゃんと伝えられることは重要という話がありましたが、これってリスクもあると思っています。

私は上記のことを実践しています。なぜなら、嘘をつくよりはわからないと伝えたほうがいいから。
でもこれが、たまに舐められることがあるんですよ。見下されるんです。
個人のバックグランドや得意技術はそれぞれ異なるはずなので、一緒に知識を補って補完してくれる
メンバーと一緒に仕事したいですよね。と、心底思います。

ITエンジニアの出せるパフォーマンス

ITエンジニアが一人で出せるパフォーマンスの現実を、
私はもっと理解しなければいけないと思います。

一人のスーパーエンジニアが10のパフォーマンスを出せるとして、
他のエンジニアが5しかパフォーマンスが出せないとしても二人いることで
スーパーエンジニアのパフォーマンスに届く可能性があります。
そういったエンジニアの集まりでチームを形成し、一人では長時間かかる案件を
短時間で作り上げていく。
私たちは一人では出来ない事をチームで実現することが多いのです。

チームで仕事をするとなると、どうしても技術レベルの低い人に合わせることがあるし、
全員にスーパーエンジニア並みのパフォーマンスを求めるのは不可能です。

技術勉強会では登壇者が主役となり、アウトプットを見せることがありますが、
もしそれがチームで行った成果なら、そのアウトプットの背後には
チームメンバーが出した成果も含まれていることもありえると思います。

一人で仕事をしたいなら、フリーランスになって
自分自身のやりたい仕事をマネジメントしてみたほうがいいかもしれない。

会社が個人のアウトプットを重視するのか、チームのよる成果を重視するのかによりますが、
どちらにしても本当に自分自身が居心地のいい職場が存在するかというと、
どうなんだろうと思ってしまいます。

参加した皆さん、お疲れ様でした!
以上、かなり長文になりましたが、レポート終わります!

JQuery Sortableで子要素が完全になくなった場合でも再設定させる小技

備忘録的なエントリーになります。

本エントリーは下記バージョンで動作確認しています。

JQuery 1.9.1
JQuery UI 1.9.2

JQuery Sortableって面白いですよね。
jqueryui.com
以前担当していた案件で、連携先のシステムが使用していたんですが、
座標のことを気にしないでドラッグアンドドロップで移動できるところが
気軽に使える感じでいいと思いました。

そんなJQuery Sortableなんですが、
実は要素を全て移動してしまうと、元に戻せないという
ケースがありました。

例えば、こちらのページで要素を全て移動してしまうと、
元に戻せません。
jqueryui.com

ですので、要素が全部なくなってしまった時に、
移動できない固定の要素を挿入するようコーディングしてみました。
こうすることで、要素を元の場所に戻すことができます。

JSFiddleはこちら↓
jsfiddle.net

JQuery Sortableは活用する機会があれば、
ガンガン使っていきたいですね!

以上です。

JAWS-UG CLI専門支部で「AWS CLIでEC2の利用料金を節約してみた」というタイトルでLTしてきました

遅くなりましたが、LTしてきたので報告的なエントリーです。
勉強会はJAWS-UG CLI専門支部です!主に茅場町を拠点としているようです。
jawsug-cli.doorkeeper.jp CLIの使い方を学習し活用方法を議論する勉強会です。
開催される頻度が高く、ハンズオンはついていけないくらいのボリュームがあるので、
何度か足を運んでみたいと思います。

上記勉強会にて、
AWS CLIでEC2の利用料金を節約してみた」というタイトルで、LTしてきました。

www.slideshare.net 内容的には大したことないんですが(本当に)、
CLI使ってこんなことできるよー的な、AWS初心者の方にとっては
そこそこ面白い内容なのではと思います。

GitHubページはこちら github.com 引き続き、LTできるようなアウトプットを目指して日々精進していきます!
以上です

「JSUG勉強会 Spring I/O報告会」に行ってきたよ!レポート

f:id:yasay:20170710131153j:plain
Springは他のフレームワークの開発終了やJava EEの開発遅延などによって
より進化の早いフレームワークを求める人達が活用している印象があります。

開発者からしてみればデファクトスタンダードだろうがなんだろうが
今現場で使用しているフレームワークをないがしろにできないのが正直な所です。

個人的にはSpring Boot大好きです。
そんな中、今年もSpringの大規模なイベントがバルセロナで開催されました。
Spring I/O 2017 – 18-19 May, Barcelona

その報告会が六本木で行われました。行ってきたのでレポートや所感など書いていきます!
jsug.doorkeeper.jp

レポート

キーノート

  • Spring IO 2017年が6回目
    • 今年からチケットの入手が大変になった。
    • 43セッション
    • ReactiveやMicroserviceなどキーワードを絡めて幅広く技術要素が扱われた
  • 基調講演の内容
    • The Only Constant Is Change 唯一変わらないことは、変わり続けるということ
    • leon megginson 唯一生き残るのは変化できる者
    • 変化する世界の中有益で有り続けることだ。 @jessitron
    • J2EEのアンチテーゼからSpring Initializrへ
    • Thymeleafのシェアが圧倒的に多い

Spring 5.0 Reactive関連

  • http://lanyrd.com/2017/spring-io/
  • @Java Day Tokyo 2017のキーノート資料が参考になる
  • Reactiveのおさらい(誤解を恐れない表現)
    • blockしない処理の塊を細切れにする
    • エンジンは細切れ処理をいつでも実行可能なよう管理
  • Reactive Stream
    • JDK9に取り込まれる予定
    • back pressureにより合理的に処理を実行
  • MonoとFlux
    • ReactorにおけるPublisherの実装
    • Reactive StreamsをStream API風に記述できる
    • Monoは0/1個、Fluxは0個以上の値を発行可能
  • Spring5でのReactive
    • spring-webflux
    • MonoやFluxが使えるController的な
    • 無限ストリームの返却
      • 一定間隔毎にデータを作っていくような
      • SSEのStreamとして解釈される機能←いいねこれ!
  • Functional Framework
    • 関数スタイル記述によるフレームワーク
    • framework << library(明示的かつカスタムが容易)
    • spring-webflux向け限定
  • RouterFunctionとHandlerFunctionの組み合わせ
  • Router Function
    • URLやリクエスト内容に応じて、呼び出す処理の振り分けルールを定義
  • Handler Function
    • ルーターで条件にマッチした場合に呼び出される処理を定義
  • HandlerFilterFunction
  • 様々な選択肢があることが重要的な。
  • Spring DataのReactive対応
    • 2.0になる。Reactive対応する。
    • APIの破壊的変更も含まれる
    • 対応しているデータソースが限られる。JPAはNG
    • JDBCドライバがblockするので意味がない的な

ThymeleafのWebflux対応

www.slideshare.net

  • Getting Thymeleaf Ready for Spring 5 and Reactive
  • TemplateとResponseがBlockingになっているから
  • ResponseをPublisherに
  • FULLモード
    • HTMLを一括生成して一括出力
  • CHUNKED
    • HTMLを一定のバイト数毎に区切って生成
  • FULL/CHUNKEDの共通の課題
    • resolveAsyncAttributeのリスト変換をMonoにするので、待ちが発生する的な
  • DATA-DRIVENモード
    • wrapすることでresolutionを回避
    • ThymeleafがProcessorのように振る舞う
  • DATA-DRIVEN & SSE
    • DATA-DRIVENモードの場合はデータ1件ごとに部分的なHTMLをSSEで送信可能
  • まとめ
    • ReactiveなView出力
    • 見どころ満載のデモ

Spring I/O 2017 行ってみてわかったSpringBoot

www.slideshare.net

  • SpringBootApplication
    • 別のパッケージにあるクラスファイルを使いたい場合は@ComponentScan
    • @ConditionalOn
  • WebMvcTest, DataJpaTest, RestClientTest

Spring I/O 2017での拡張のお話

www.slideshare.net

  • Spring Cloud Function
    • lamdaみたいなもの。
    • SpringでFunctionを書いてサーバレスな環境を実行できる?
    • →話を聞いている限りだとLambdaで動かすSpringみたいな印象を受けましたが・・どうなの
  • Spring Auto REST Docsの拡張
    • Spring REST Docs テストを通った内容がドキュメント化される
    • つまり、正確なドキュメントが作れる

Re:ゼロから始めるオープンソース生活

www.slideshare.net

  • コントリビュートはソースコードの追加・修正だけではない
    • コミュニティ活動、不具合の報告、ドキュメント周り(整備、翻訳とか)
  • コントリビュータになるために
    • Gitの知識と、GitHubのお作法
    • 修正内容の議論、推敲、反映
    • CLA(ライセンス条項)への同意
    • 忍耐
  • spring.ioで情報収集
    • READMEとか読む、プロジェクトの好みを知る(Merge vs Rebase, Code Style)
    • 自分だけのForkの中で自由にコードをいじってみることが大事
  • よいPull Requestのために
    • Issueに自分が作業していることを明記
    • 簡潔明瞭のコミットメッセージ
    • 機能追加の場合は、単体テストも追加
    • ビルドが正しく完了することを確認
    • PR先のbranchを間違えないように確認
  • PRのライフサイクル
    • CLA -> CI -> PR議論 -> PR内容修正 ->反応なしの場合忍耐
    • リジェクトの場合もめげずに次がある!受理はおめでとう!
    • PRを上手に引き継ぐことが大事?
  • まとめ
    • 始めるなら今がチャンス
    • Spring5に向けて改善点がたくさんあるから

所感

ピザおいしかったです。ありがとうございました。

f:id:yasay:20170710131246j:plain
OSSに貢献するチャンスではあるようなんですが、
自分のやりたいことがまだ消化できていない状況なので、
片付いたら貢献したい気持ち。サーバレスアーキテクチャとかやってます。

あと、リアクティブに関する説明はとても分かりやすかったと思っています。
登壇者の方は"誤解を恐れないで"という言葉を使っていましたが、
私も"誤解を恐れないで"言うと昨年のSpring Day 2016当時の私よりは
今回の話を聞くことでそこそこ理解できレベルアップしたと思います(笑)。

リアクティブなフレームワークも一つの選択肢ということなんだと思っています。
個人的にはリアクティブなフレームワークが主流になるのかが気になっていますが、
主流になった時に学習できていないと追いついていないということになるので、
やはり継続的な学習とアウトプットが大事かと。

久しぶりの六本木は新鮮な気分になれました。また行くぞ!
以上です。

IntelliJ IDEAのPostfix Code Completionは便利!生産性が上がりそうなオススメPCCをピックアップ!

本エントリーは下記バージョンで動作確認しています。

Java 1.8.0_112
IntelliJ IDEA Ultimate 2017.1.3


Postfix Code Completion(以下PCC)、皆さん使っていますか?
IntelliJ IDEA 13.1のPostfixコード補完 | JetBrains ブログ

Postfix Code Completionは追記方式による補完と
カーソル移動軽減による生産性向上のための機能です。
IDEによくあるスニペット機能とは違って、
自分自身でアセットを追加することはできませんが、
標準で便利なアセットが揃っているので充分活用できると思います。
何よりPCC後のカーソル位置の自動移動が便利!

IntelliJ IDEAのPCCは、補完候補として出てくるので、
PCCの内容を全て記述する必要がないのがポイントです!

例:".el"と入力するだけで"else"のPCCを補完できる
f:id:yasay:20170619061910p:plain


ですので、使ってみると分かるのですが、
実際はPCCの文言を全て入れる必要がないので
よりスピード感を持ってコーディングできます!

個人的によく使うPCCをピックアップしていきます。

記述量が減るタイプ

.var

個人的に一番使っているのがこちら。
記述量が大幅に短縮できると思います。

下記のように入力したら・・・
f:id:yasay:20170619063140p:plain
こうなる!インスタンス名の候補まで挙げてくれる!
f:id:yasay:20170619063227p:plain

.nn

最近はNULLチェックなんか書きたくないとひしひしと思っていますが、
そうはいきません。PCCでサクッと書きましょう。

Not Nullは下記のように入力したら・・・
f:id:yasay:20170619063918p:plain
こうなる!
f:id:yasay:20170619063948p:plain

.null

もちろんNullだって・・・
f:id:yasay:20170619064022p:plain
こうなる!便利ですね!
f:id:yasay:20170619064100p:plain

.for(拡張for文)

個人的には最近はstream APIの利用が多くなってきているので
拡張for文を利用する機会自体が少なくなってきていますが、
PCCを利用することで記述量を大幅に減らすことができます。

こうやってforを入力すると・・・
f:id:yasay:20170619051035p:plain
こうなる!早い!
f:id:yasay:20170619051324p:plain

.fori(index型for文)

index型のfor文だとより出番が少ないと思いますが、
こちらのほうが記述量が多いので、PCCの効果がより発揮できます!

これが・・
f:id:yasay:20170619051556p:plain
こうなる!覚えれば楽!
f:id:yasay:20170619051647p:plain

.if(boolean型用)

boolean型の真偽値判定もよく使うと思います。

boolean型(ラッパクラスでも可)に.ifと入力するだけで・・
f:id:yasay:20170619051956p:plain
こうなる!
f:id:yasay:20170619052045p:plain

.else(boolean型用)

elseを使えば真偽値の判定に
わざわざアスタリスクを追記する必要もないです。

こうすれば・・
f:id:yasay:20170619061910p:plain
こうなる!
f:id:yasay:20170619062425p:plain

PCCの一覧は設定から確認できます。

「Preferences」の
「Editor」→「General」→「Postfix Completion」から参照できます。
他のPCCに興味がある方は、参照してみてください。
f:id:yasay:20170607133237p:plain

Scala, Javascript, KotlinのPCCもあるよ。

ScalaとKotlinはもっと使っていきたい言語なので、
PCCも活用できればと思います!

Kotlin

f:id:yasay:20170607134125p:plain

以上です!

IntelliJ IDEAの自動保存の無効化と、変更中ファイルのタブにアスタリスクを表示するように設定を変更する

かゆいところに手が届くIntelliJ IDEAのTipsになります。

自動保存をオフに設定する

自動保存を有効にしている場合、
ローカルのアプリケーションサーバが自動保存を検知し
意図しない修正がコンパイルされてコンパイルエラーになる時があります。
若干不便です。ですので、自動保存をオフにしてみます。

「Appearance & Behavior」→「System Settings」
Synchronizationの「Save files on frame deactivation」をオフにする。
f:id:yasay:20170606163527p:plain
本設定は、アプリケーションを切り替えた時に自動保存する機能のようです。

変更中ファイルのタブにアスタリスクを表示する

Eclipseではデフォルトで有効なんですが、IntelliJ IDEAではなぜか無効になってます。

「Editor」→「General」→「Editor Tabs」
Tab Appearanceの「Mark modified tabs with asterisk」をオンにする
f:id:yasay:20170606163559p:plain

おまけ:エディターのタブを複数行で表示する

タブの複数行表示はわざわざタブ一覧を展開する必要がなくなるので、
個人的によく変更するオプションです。Eclipseでも同じことができますね。
もちろん、タブを100とか200とか開くと視認性が下がるので一長一短あります。

「Editor」→「General」→「Editor Tabs」
Tab Appearanceの「Show tabs in single row」をオフにする。
f:id:yasay:20170619095446p:plain

以上です。