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

以上です。

AWS Summit Tokyo 2017に行ってきました。

f:id:yasay:20170604220500j:plain:w350
5月30日(火) ~ 6月2日(金)に行われたAWS Summitに参加してきました。
日本で行われるAWSイベントの中では最も大きな規模です。
www.awssummit.tokyo

場所は品川プリンスホテルで行われました。
f:id:yasay:20170604221009j:plain
↑飛天の間の噴水にそびえるAWSロゴ
AWSさん、どんだけ凝ってるんですかw

今回、私は業務の合間にDay2の午前とDay3の午後に参加してきましたので、
以下にレポートを書いていきます。

5/31 (Day 2)

基調講演レポート

f:id:yasay:20170604230321j:plain

  • 基調講演①
    • 16分野のコンピテンシーというのがあるので、これに沿ってAWSの分野を学習していけばいいかも。
    • Enterprise JAWS-UGというものもあるらしい。

  • アップデートトピック①
    • 日本準拠法を選択可能に
    • 支払い通過を日本円で請求できるように
    • サービスコンソールの完全日本語化を目指す。

  • Digital/IT Transformationの流れが日本にもきている。

  • Digital/IT Transformationの紹介:UFJの例
    • ビジネス基盤を強化することについて
      • 設定の素早さ+経営の俊敏さが要求される

  • 基調講演②
    • 画像認識を使ってルービックキューブをミリ秒で解く動画がとても面白かった。
      • ↓例えばこんなの

www.youtube.com

  • アップデートトピック②
    • Lightsail 本日より東京で使用可能に。
    • PostgreSQL Aurora
      • オープンなデータベースが復旧してきていることは、確かに実感できる。
      • Oracleに追いついてきた感。
      • PostgreSQL AuroraのパフォーマンスはMAX2倍

  • Digital/IT Transformationの紹介:EPSONの例
    • Oracleのラックで動いていたんだが、データベースが高トラフィックだった。
      • これをどうにかしなきゃいけない。
      • そこで選んだのがAurora。全面的にMySQLを採用。

    • 可用性の心配→Auroraは止まらないよね?→やってみないと分からない。
    • 結果、運用工数0→DBAの作業を開発チームに移管可能に
      • ライセンス費用0
      • 障害0!すごい!

  • Digital/IT Transformationの紹介:レコチョクの例
    • VRの取り組みいいね。
      • 配信方法や端末負荷、画質・音質の問題など課題はある。
      • スマホ向けVR映像を横展開とか、VRライブ映像をお届けとか。
      • 世界中に配信環境を提供するためにはどうすればいいのかとか。

  • 基調講演③

  • IOT→クラウドがないと実現が難しい?
    • 意味のあるIOTを実践→ホームセンターのGooDayもIOTやってる(すごいなーw)

  • アップデートトピック③
    • パリ、中国(地名忘れた)、ストックホルムにリージョンを追加予定。
      • リージョンは物理的な拠点。
    • Osaka Local Regionを解説予定
      • 特定の顧客に限定したローカルリージョン

6/1 (Day 3)

AWSで実現するセキュリティ・オートメーション」レポート

  • セキュリティオートメーションという言葉を聞いたことがあるか?→ない
  • なぜクラウドを使わないかアンケート取った
    • →一番の理由はセキュリティ
  • なぜクラウドに移行したのかアンケート取った
    • →一番の理由はセキュリティ
  • セッションのポイント
    • オートメーションは戦略策定の礎
    • セキュリティ・オートメーションを前提に設計されたAWSサービス
    • セキュリティ戦略基盤となるAWSクラウド環境

オートメーションは戦略策定の礎

  • 「やること」と「やらないこと」を決められる = 戦略
    • 多種多様なデータ集約→可視化と効果測定→分析による意思決定
    • →この土台になっているのがオートメーション

セキュリティ・オートメーションを前提に設計されたAWSサービス
  • 対策主体
  • 対策対象
  • 対策場所

  • 防御
    • →SG, NACL, WAF, CloudFront
  • 検知
    • VPC flow logs, Auto Scaling
  • 予測
  • 対応
  • 監視
    • →CloudWatch, CloudTrail

  • IPリストに反映されていない悪いIPを遮断する対策が必要
    • →オートスケールによるトラフィック分散による問題の抑制(吸収)
    • →スケーリングイベントの通知をAmazon SNS
    • →イベント通知をきっかけでLambdaを起動しセキュリティ評価を実行
    • Amazon InspectorのAPIをキックして、脆弱性診断
    • →診断結果をSNSに通知→Lambda起動してNACL/SGのポートブロックによる端末隔離
    • VPC Flow Logsにブロックログを残す。→EC2インスタンスの状態をS3に保存する
    • →CloudTrailにバックアップログ保存
セキュリティ戦略基盤となるAWSクラウド環境
  • AWSインフラ全体のログ取得が可能
    • アクセスログ、S3のアクセス、API操作のログ
    • →オンプレミスだと意外に大変だよね。AWSなら標準で提供されている。

  • 可視化
    • VPC Flow LogsとAmazon Elasticsearch Service/Kibanaによるセキュリティグループの可視化

  • 分析
    • Domain Generation Algorithms
    • CloudFromtのログを見れば、ドメインが分かる。ここでマッチングさせる。
    • AMLで正しいドメインの学習データとして食わせる。
    • AMLの結果を見て、WAFルール更新なんてこともできる。
    • AML起動はLambdaで。ログパーサーAML呼び出し

f:id:yasay:20170604230245j:plain

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS で実現するセキュリティ・オートメーション #AWSSummit | Developers.IO

Amazon Aurora (MySQL-compatible edition) Deep Dive」レポート

Deep Dive
  • データベースサービス
    • AWSが一から作ったデータベースエンジン

  • 一番の特徴はストレージ
    • 一から作った
    • SSDを利用したシームレスにスケールするストレージ
    • 10GBから64TBまでシームレスに自動でスケールアップ
    • 標準で高可用性を実現
    • S3に高速にバックアップする仕組みを備えている。

f:id:yasay:20170604230635j:plain

  • ストレージノードクラスタ
    • Protection Group毎に6つのストレージノードを使用
    • 各ログレコードはLog Sequence Numberを持っており、不足・重複しているレコードを判別可能
    • 6つのストレージノードを使用

f:id:yasay:20170604230738j:plain

  • ディスク障害検知と修復
    • 2つのコピーに障害が起こっても、読み書きに影響はない
    • 3つのコピーに障害が発生しても読み込みは可能。

  • IO traffic in Aurora(ストレージノード)
    • 全てのステップは非同期
    • スループットの影響が起きないように作られている。
    • 6本のうち4本からストレージが帰ってくれば問題ない。(2本はあとで保管。)

  • セキュリティ
    • データの暗号化サポート
    • SSLを利用したデータ通信の保護

  • フェイルオーバーとリカバリ
    • リードレプリカがある場合1分ほどでフェイルオーバー可能
    • リードレプリカが存在しない場合10-15分
    • Multi-AZ配置として別AZで起動可能
    • 高速でより予測可能なフェイルオーバー時間
      • クラッシュリカバリの速度が3病から20病で終わるように設計
      • →Auroraがやるんじゃなくてストレージノードが判別してやっているから早い。
    • Auroraのフェイルオーバータイムの内訳は、一瞬で終わるのが30%。
  • Streaming backupとPITR
    • ストレージに書き込まれた瞬間からS3に継続的にかかれていく仕組み。
    • AuroraはそのままログとしてS3に書き込まれる。
    • 何があってもパフォーマンステストをいつしてもBackupを含んだペナルティの性能になっている。

  • 任意の位置で復元可能。
    • 各セグメントは定期的なSnapshotは並列で行われ、redo logはストリームで継続
    • バックアップのためにS3に送られる。パフォーマンスや可用性に対する影響はなし

  • Writer / Readerノートの識別
    • innodb_read_onlyモードでマウントされている。
    • SHOW GLOBAL VARIABLES LIKE 'innodb_readonly'

  • SQLによるフェイルオーバーのテスト
    • SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
    • ディスク障害、ディスクコンジェスションをシミュレーションが可能
    • →これらSQLはAuroraのみに実装されているクエリ

  • Aurora Driver
    • MariaDB Connector/JにFast failover Auto node discoveryが実装されているので、このDriverを使ってみてほしいとのこと。
      • Fail Over時間が短縮されるよ。
  • パフォーマンスTips
    • Auroraのパフォーマンスは圧倒的
    • チューニング設計
      • MySQLのチューニング戦略がそのまま適用できる。
      • Auroraはマシンリソースを最大限使うような設計になっている。
      • CPU、スループットなど、CloudWatchで監視して確認してほしい。
    • まずはデフォルトのパラメータグループ使用を推奨?。
    • トランザクションで大量の更新や削除を行ったり、大量データのシーケンシャルリードを行う場合、区切れる単位でSQLを分割して並列で投げてくれると、性能が上がりやすい。

f:id:yasay:20170604230935j:plain

  • 拡張モニタリング
    • Elastic Service連携も可能

  • Auroraへの移行は?
    • InnoDBのみサポートしているので、マイグレーション時に自動でコンバートされるが、手動で対応ストレージエンジンに変換しておくのがよい。

  • RDSからの移行は、
    • Aurora Read Replicaを自動生成する機能があるので、最新のデータによる移行が可能。

  • Percona Xtrabackupを利用してAuroraへ移行可能
    • mysqldumpと比較したテストで20倍高速に移行可能

改善を行ってきた機能(前回のサミットから追加された機能の一部を紹介)
  • Reader Endpoint
    • →ロードバランサみたいなエンドポイントがあって、ラウンドロビンで振り分けられる。
    • →Readerが一瞬でも消えた場合はフェイルバックが起こり、Writerを指す場合がある。

  • IAM Authentication Integration
    • Amazon Auroraへログインするための認証にIAMが利用可能に
    • →credentialを配布する必要がないので、開発だけアクセスできる本番だけアクセスできるような使い方が可能。
    • IAMポリシーで矯正が可能?

  • Lambda Function Integration
    • ストアド・プロシージャとして実行

  • Load Data From S3
    • S3バケットに保存されたデータを直接Auroraにインポート可能
    • テキスト形式、XML形式

  • 空間インデックスサポート
    • Auroraに入れる時に性能の改善が行われているので、ベンチマークで2倍の性能差が出てる。
    • インデックスの持ち方を変えたことで、性能向上。
    • 同じメソッド、関数を持っているけど内部的にはインデックスの持ち方が変わっている。

f:id:yasay:20170604231007j:plain

  • 監査の機能
    • Aurora native audit supportは15%程度の性能ダウンでいける。
    • ログファイルに出力するところを、パラレルに書き込むできるようにすることで、性能を向上させた。
    • mariadb server_audit pluginとの比較です。

  • Zero downtime patch(ZDP)
    • コネクションを切断することなくオンラインでパッチを適用できる
    • 5秒程度スループットの低下が起こるが、接続を維持したままパッチを適用可能に。
    • ベストエフォートなので、この機能を期待してアプリを作るのはやめたほうがいい。

f:id:yasay:20170604231050j:plain

  • 性能面
    • Cached read performanceの改善
    • →性能はどんどん挙がっている。
    • Insert Performance→地道なパフォーマンス改善を続けている。

f:id:yasay:20170604231212j:plain

  • Fasted Index build

  • Lab Modeがある。
    • FAST DDL
      • add columnが1秒もかからない処理になる

さらなる改善に向けて
  • データベースバックトラック
    • オペミスの内容を一瞬で特定の状態に戻す機能
    • データは残っているんだけど、シーケンスNo的なものを巻き戻すことで、戻す
    • 超高速に巻き戻す
    • →バックアップから別のクラスを立ち上げるのではないので、リカバリが早い。

  • Databse cloning
    • ストレージコストを増やすことなくデータベースのコピーを作成
    • 1分か2分くらいでCloningできる。
    • その↑にインスタンスを立てればいい。
    • 料金はコピーしただけだとストレージ料金はかからない。
    • cloneに書きこんだ分の料金はかかるかも?。

  • Auroraは高いクエリ実行並列度、データサイズが大きい環境で性能を発揮
  • コネクション数やテーブル数が多い環境で優位

  • AuroraとRDSでパフォーマンステストをして、試してほしい。
  • データの堅牢性はAuroraに軍配。

「【AWS Tech 再演】AWS のコンテナ管理入門(Amazon EC2 Container Service)」レポート

なぜコンテナなのか
  • DevOpsのために再発見された
  • 開発に専念したい→インフラの運用管理を効率化した
  • 可搬性→不変なイメージ
  • イメージを本番環境にそのままリリースできるのっていいよね。
  • 柔軟性、速度

  • ベスト・プラクティス
    • アプリをコンテナに適応させる(12 factor apps)
    • 複雑さを避ける→シンプルに保つ

  • タスクに集中する
    • タスク = ジョブの単位

  • そこで登場する課題:クラスタ管理
    • 1台のサーバ上でコンテナを扱うのは簡単
    • 複数ホスト上でのコンテナ管理は非常に難しい
    • アプリケーションの開発に専念したいはず

Amazon EC2 Container Service 概要
  • メリット
    • 簡単に、どんなスケールのクラスタも管理できる
    • 状態管理、操作、監視、スケーラブル
    • 柔軟なコンテナの配置
      • アプリケーション、バッチジョブ、複数のスケジューラ
    • 他のAWSサービとの連携がデザインされている
    • 拡張性の高さ -> 分かりやすいAPI

f:id:yasay:20170604231315j:plain

  • コンテナ
    • ECS AGENT
    • MANAGER
      • CLUSTERのリソースとTASKの状態を管理
      • 変化を追跡
    • TASK DEFINITIONS
      • コンテナ情報とボリューム情報に分割

  • Task
    • コンテナ実行の1単位
    • 関連するコンテナでグループされる

  • スケジューラ
    • Run Task←バッチに最適
    • Service←Web/APIに最適


クラスタに対してマネージャーを介してスケジューラからタスク定義的な

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS Summit Tokyo 2017:AWS のコンテナ管理入門(Amazon EC2 Conatainer Service) #AWSSummit | Developers.IO

「【AWS Tech 再演】Machine Learning on AWS」レポート

  • 解決したいビジネス課題から出発したほうがいい。
  • ツールなので、それ自体を使うことが目的ではない。
    • もっとシンプルで簡単なやり方のほうがいいということはよくある。
    • それでも上手くいかないケースで活用するべき

  • 大量の良質なデータでモデルの精度が向上
    • →(良質なデータが)継続的に手に入るかどうかが重要
  • 判断や予測を自動化することが可能
    • →自動化する価値のあるクリティカルな予測か?
  • 大規模に展開するほどコストが下がる
    • →費用対効果に見合うか?

  • AI Engines
    • インストールがものすごくめんどくさい
    • AMIイメージで簡単に利用できる
    • MXNetを全面的にサポート
      • →スケーラビリティに優れている。

  • AI Platform
    • AML マネージドサービス
    • EMR

  • AI Service
    • アプリケーションサービス
    • Right tools for the job
    • Managed services first

  • ゴールを明確にする
    • モデル
    • トレーニング
    • 予測

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS Summit Tokyo 2017: Machine Learning on AWS #AWSSummit | Developers.IO

参加した感想

私は今回AWS Summitに参加するのは初めてだったのですが、
その圧倒的なイベント規模に驚かされるばかりでした。
ユーザイベント規模ではなし得ないことばかりです。
AWSがお金持っているということなんでしょうけどw

タイミングがいいのか悪いのか夏日並みの気温だったので、
品川プリンスホテルまでの道中が暑いこと・・
会場の人の多さにも圧倒され気疲れが大きかったです。

この雰囲気の中1日中勉強のためにTechトラックを見るのは
かなり大変なんじゃないでしょうか。幸いなことに1トラック40分なので
集中力は持続できると思いますが。

私は今回Day2の午前中とDay3の午後のみ参加したので、
丸一日いたら普段の業務よりしんどかったんじゃないかとw

もちろん、Techトラックで勉強した収穫は大きいので、
参加できたことには大きな意味がありました。

ランチが出る無料の大規模イベントがあるらしい(It's AWS Summit 2017 Tokyo!)

f:id:yasay:20170604230427j:plain
カツサンドうまかったです。ありがとうございます。

認定者ラウンジで傘を頂きました。ありがとうございます。

f:id:yasay:20170604224415j:plain
もったいなくて使えないですわ・・

一時の癒やし:品川プリンスホテルの日本庭園

f:id:yasay:20170604222416j:plain
来年も日本庭園を拝めますように・・

晩御飯:一日分の野菜が採れるカレー

f:id:yasay:20170604222820j:plain
一日分の野菜って思った以上に量が多いw
栄養バランスを取るって大変ですね・・

AWSおみくじ(by クラスメソッド様)

f:id:yasay:20170604222859j:plain
Athena使うぜ!うひょー!

以上、レポート&感想でした!
参加した皆さん、お疲れ様でした!

JJUG CCC 2017 Springに行ってきました。

f:id:yasay:20170601095510j:plain:w350
今年もきたぜ、JJUG CCC。
去年のFallはボランティアとして参加しました。
今年はがっつりセッションを聞きたいので一般参加です!

このエントリーの体裁を整えている時に、
AWS Summit 2017 Tokyoに参加していました。
ベントラッシュと業務で忙しいこの頃、皆さんお元気ですか。
7月1日はDevelopers IOに参加したいとも思っています。
classmethod.jp

最近ブログのエントリーが遅れがちなことについて

(コーディングの)アウトプットを最近優先しています。
ですので、インプットの内容をブログに残すことが
遅れがちになっていると思います。
ですので、行ってきたレポートはなるべく
その場で書いていき、スピードを上げていきたいと思います。

今回の内容は試しに、が重要なインプット、を所感で記述してます。

レポート

非機能要件とSpring Boot

speakerdeck.com

  • 「機能要件」以外の要件が「非機能要件」
  • 「非機能要求グレード」←IPAの資料がまとめられていて便利

  • Spring Boot Actuator → 運用・保守性に貢献
    • 運用監視、活性保守
    • JSonViewプラグインなどで整形すると見やすい
    • 運用中のログレベルの変更が可能なのはすごく便利だなぁ。最高じゃん。→でもこれActuatorが必要なの?
    • メモリは圧迫するかも
    • pull型基盤なので、自分からデータを取り出すような仕組み

  • Spring Security & Others
    • PassayというパスワードポリシーをBeanValidationで使うのが便利らしい。
    • SHA*ではなくBcryptまたはScryptを使うべきなのかー!
    • jasyptでプロパティファイルを暗号化することもできるのか。本当に勉強になる。
    • 復号化のキーは環境変数などに隠しておく。これはいいな!

  • Spring Data JPAによる監査ログ便利だなー。
    • Spring Securityのログイン情報を登録することができるんだな!
    • JPAの@MappedSuperclassも忘れずに覚えておこう。


IPAの非機能要件グレードは参考になりすぎた。
業務でも活用していきます!

www.ipa.go.jp

Vue + Spring Bootで楽しくフルスタック開発やってみた

Vue.js + Spring Bootで楽しくフルスタック開発やってみた

  • 登壇者が担当した業務の要件
    • AndroidiOSの両方に対応する
    • 機能的にはWebアプリの域を脱しない
    • なのでCordovaを選択→Webビューを使ったフレームワーク

  • Vue.jsを使うと双方向バインディングができる。
    • ネイティブアプリっぽさを出すためにSPAを目指した
    • vue-router 2 → ルーティング
    • Vudex → Flux実装 → SPAで、状態を保持するのにかなり便利だったらしい。
    • axios → HTTPクライアント → ajaxの機能のため

  • npmとwebpackの導入
    • npm → JavaでいうMavenやGradle
    • webpack → build.jsを生成するためのツール的な。プラガブルなコンパイラ
    • webpack dev serverが便利らしい。 → コード変更を検知してビルドや、ブラウザの自動リロードなど。

  • Vueの便利なもの:Chrome拡張
    • Virtual DOMの状態や、バインドされている値を確認できたりするので便利。使うべし。

CSS Grid Layoutはかなりすごいらしいので、触ってみたい。
spring boot devtoolsとwebpack dev toolsでのHot Reloadingな開発面白そう!

Javaエンジニアに知って欲しいRDBアンチパターン

  • データベースの寿命はアプリケーションより長い。

  • アンチパターン2:
    • memo, memo2, memo3
      • 不適切な名前ではデータベースのテーブルの関連性や意図が理解できない。

  • アンチパターン3:
    • 論理ID(途中2桁は都道府県コードを表すような例) → データにロジック埋め込むな。
    • アプリケーションを変えずにRDBのトリガという機能を用いて移行させることができる。
    • 理想のViewを作って、参照はこっちとか進めていく。

  • アンチパターン4:強すぎる制約
    • 変更が大変→時間が経てば立つほど状況が悪化
    • データベースほっておいても直らない。
    • そのためにRDBの機能を活用する。→ しかしそれが裏目に出ることも。
    • RDBの機能に依存しすぎると裏目になることがある。
    • (※ストアドは更新する時にデータベースの停止が必要になる! -> だからあまりストアドにロジックを持ちすぎないほうがいい。)
    • 成功体験のバイアスや、失敗体験のバイアスが、最適な手法の選定を妨げる。正しい設計を学ぶ方法とは?

  • 一度作ったDBは消せない → だからこそ設計が大事
    • データベースの死はサービスの死 → 解決できる人は英雄

  • DBの問題は忘れた頃にやってくる。
  • サーバーの問題は休日にやってくる。
  • アプリケーションの問題は納期前にやってくる。
  • 脆弱性の発見は連休中にやってくる<- New!!


SQLアンチパターンを読むことを登壇者の方がおすすめしていたので、
読みたい。会社にあった!

www.oreilly.co.jp

Introduction of Project Jigsaw

www.slideshare.net
f:id:yasay:20170601105602j:plain

  • Moduleに依存性と公開範囲を書いていく。
    • メタ情報があるのがModule.それ以外がjar。
    • module-info.javamavenみたいにがんがん書いていく。

  • 依存性

module net.jitb.hello {
// 依存性の追記
requires javafx.controls;
}

  • 公開範囲

// puckage export
exports net.jitb.hello;

  • 新しいものを作るのは簡単。
    • 古いものを混ぜるのは大変。
    • export書かないと、publicにならない。
    • なので、java9で使えなくなったライブラリがある。
    • class.getInstanceとか。

  • javaコマンドに、--オプションがたくさん増えた。
    • ※javac生で打つことはほぼないよね。
    • IntelliJ IDEAは既にJava9に対応している。

execution( --module-path mod ~

  • 標準モジュールの確認
    • java --list-modules 現在73個くらいらしい
    • java., jdk., javafx.ではじまるものがある。java.で始まるものが使えるもの。

  • カスタムJRE
    • jlinkを使って自分が欲しいモジュールだけを定義できる。
    • 自分が持ってるモジュールもパッケージング化してカスタムJREの作成ができる。

  • マイグレーションをどうするか
    • ただのJarファイルをモジュールにしたい場合に、ライブラリが何に依存しているかをjdepsコマンドで確認できる。

  • Automatic Module
    • モジュールパスに置くだけで、Automatic Moduleとして扱ってくれる。


JigSawはJava9リリースまでに変わる可能性がまだまだあるので、
今後の動向を見張っておく必要があります。
個人的には依存性が分かりやすくなるのは便利だと思うので大変興味があります。

Engineers can change the world ~ "世界"で活躍するエンジニアになるために

f:id:yasay:20170601105707j:plain
docs.com

  • 自分の中に本能的に発生している差別(血液型や性格などで人を判断するような偏見)というのはよくない。
    • それが、"my unconscious bias"(自分の無意識の偏見)

  • 登壇者の方は、富士ソフトABC→SUN→OracleMicrosoftというすごい経歴を持つ人。
    • 中学時代とか、高校時代とかに英語は全くダメだったらしい。
    • 逆に日本語の文章を翻訳して見ている外国のエンジニアだっている。
    • 今は自分たちが思っている以上にグローバル化している。

  • 39歳でJavaを作った生みの親を見れば、35歳定年説なんて関係ない!というかありえない。
    • 学び続ける姿勢が大事
    • クリント・シャンク
    • 年齢関係ない
    • やはり英語は重要。

  • 自分が持っているバイアスをいかに取り除くか。
    • そうすれば、もっと他人と話しやすくなる。みんなをリスペクトしていく姿勢が大事。

  • 目が不自由なマイクロソフトエンジニアの話がすごい。感動した。
    • これを見ると、本当にITが世界を変えると思える。

www.youtube.com

  • love your self
  • love your peers
  • love your work
  • 自分を変えられのは自分だけ。

  • inputが多い人はアウトプットをしていこう。
    • ブログやSNSから、登壇へ。
    • OSSへのコントリビューションだったり。
    • 日本人であっても世界で活躍できる場所は、たくさんある。
    • 夢は必ず叶います。
    • 夢を持って成長すれば、世界は決して遠くないと思う。

  • embrace community
  • embrace diversity
  • embrace inclusion

ハックで生きる:オープンソースで会社を興すには

www.slideshare.net

  • オープンソースのビジネスモデル
    • プロフェッショナル・サービス
      • 正しい使い方の指南
      • 個別企業向けに追加機能の請負開発\
    • 製品版
      • 作れば勝手に売れるものではない。
      • OSS版で十分だと思っている人が大半。
      • 企業のサイズ、ポジショニング、営業が必要

  • SaaS
    • 価値の上限や、顧客個別事情への対応など

  • サポート
    • それなりの体制・規模・仕組みが必要
    • 知識のある技術者を雇わないといけない

  • コミュニティから人を雇える魅力がある。
    • 優秀な雇うべき人を探すのは簡単
    • 働き方も癖も性格もわかっている

  • OSSの貢献にも限界が
    • 趣味の細切れの時間や本業の片割れの時間で出来ることには限界がある
    • 複数のコミュニティ開発者が共同作業するのは難しい
    • 時々即売上になる?→おまけとして引き抜き前の会社から売上もらうとか(笑)

  • 欠点もある、
    • 開発者の中に葛藤が。
    • 自分の時間?仕事の時間?
    • 会社がやりたいことと、自分がやりたいこと

  • プロジェクトを横取りしようとしていると映る危険性?
    • 主要開発者がみな同じ会社の従業員になってしまったら?

  • プロジェクトの開発者が目減りする
    • 製品開発に回ってもらうとその分OSSに穴ができる

  • ブランド・商標・法律関係
    • 商標が誰のものになっているのか、確認が大事
      • 昔HUDSON問題とかもあった。

  • お金持ちになりたいんだったら、オープンソースの会社なんか作っちゃいけない😁
  • オープンソースは無双
  • 開発手法が最強
  • 組織が力を結集しないとできないこともある。
    • 一人でできる仕事と一人ではできない仕事との違い。
    • 開発者だけでは実現できない仕事。

  • 企業の参加で初めて得られるリーチがある。
    • 他の企業の参加も促せる。

  • Blue Oceanすげぇ!


結構ぶっちゃけ話が多かった気がしますが(笑)。その度に笑いをさそってました。
Jenkins生みの親の方が登壇していたこともあり、その一つ一つの言葉に説得力がありました。

個人的に見たかったセッション

Javaで実践して学ぶOAuth2.0!

speakerdeck.com

コーヒーカップワロタw

f:id:yasay:20170601100159j:plain
Google I/O 2017でKotlinがAndroidの開発言語として公式にサポートされるようになって、
自称エヴァンジェリストの方が調子に乗っているようですw
こういうの好きw

懇親会で回転寿司が出たw

f:id:yasay:20170601105737j:plain
無料で参加できるイベント(もちろん懇親会も)で
寿司が出るイベントというのはなかなか、ないですよね!
スポンサーのLINE様に感謝したいところです。
あっという間に売り切れてステッカーが回っていた模様w

成子天神社

f:id:yasay:20170601105811j:plain
ベルサール新宿のすぐ近くにある神社。相変わらずピンキーなピンク色してるなw
冬にまた来るから、その時にまた拝みにきたいと思います!


以上、JJUG CCC 2017 Springのレポートでした!
参加者の皆さん、お疲れ様でした!

(AWS)AWS SDKを使用してS3にファイルをアップロードする際に、Content-Typeを指定する

自分用の備忘録です。
ObjectMetadaクラスを使用することで、
S3へアップロードするファイルにメタデータを指定できる。
画像ファイルに"image/png"などのContent-Typeを指定したい場合に
メタデータ指定を利用する。
正しいContent-Typeを指定しないとブラウザが
おかしな判定しちゃう時があるらしい。

プログラミング言語 Java
AWS SDK Version 1.11.89

PutObjectRequest request = new PutObjectRequest(bucketName, path, file);
ObjectMetadata objectMetadata = new ObjectMetadata();
objectMetadata.setContentType("image/png"); //pngファイルの例
s3client.putObject(request);

(AWS)EC2のWebApplicationからS3の署名付きURLを取得する方法

自分用の備忘録です。
EC2からS3バケットの画像ファイルなどを取得したい時に便利。
バケットポリシーを変更することなくアクセスできる♪

プログラミング言語 Java
AWS SDK Version 1.11.89

Date expiration = new Date();
long msec = expiration.getTime();
msec += 1000 * 60 * 60; // 1 hour.
// 有効期限の設定(デフォルトは15分らしい)
expiration.setTime(msec);

GeneratePresignedUrlRequest generatePresignedUrlRequest =
                new GeneratePresignedUrlRequest(bucketName, path);

// GET Request(POSTもできる)
generatePresignedUrlRequest.setMethod(HttpMethod.GET);
URL url = client.generatePresignedUrl(generatePresignedUrlRequest);

return url.toString();

「AWS認定ソリューションアーキテクト-アソシエイトレベル試験」に合格したよ!

AWS認定ソリューションアーキテクト-アソシエイトレベル試験に合格しました!
aws.amazon.com

試験を受けた動機

2017年の調査会社による報告によれば、
クラウドインフラ市場の3割以上のシェアを占めているらしい
Amazon Web Services

そんなAWSに魅力を感じられずにはいられません。
なので私はより深くAWSを理解するためにも、
認定試験に合格することを目標にAWSの知識を深めました。

受験までを振り返る。どんな勉強をしてきたか。

勉強した内容を書いていきます。

実務による開発経験を積みました。

2017年1月から3ヶ月間、AWSを用いたウェブアプリケーション開発をひたすら
行っておりました。実務経験により様々なAWSサービスを利用できましたが、
この経験は次に受ける「デベロッパー-アソシエイト」で
主に役に立つと思います。

Blackbeltのオンラインセミナーの資料を全て読みました。

今思えば、試験範囲の内容に絞って見ておけばよかったのですが、
160近くあるドキュメント全てに目を通したことにより
試験範囲外のAWSサービスまで理解できたのでまぁよしとします!

ホワイトペーパーを読みました。

BluePrintに記載があるホワイトペーパーを探すのは面倒でした。
リンクをまとめてくれると助かる。なので下記にまとめます。↓
リンク切れになる可能性があります。ご了承下さい。

■アマゾン ウェブ サービスの概要

https://media.amazonwebservices.com/jp/wp/AWS_Overview.pdf

■障害復旧を目的としたAWSの使用

https://media.amazonwebservices.com/jp/AWS_Disaster_Recovery_01242012.pdf

上記ドキュメントは付録を覗いて全て読了しましたが、
正直かなりキツかった。特にセキュリティプロセスの概要が80ページ程あり、
内容も濃いので気合を入れて読むことをオススメします・・。

サンプル問題を解く

基本的に後述するWEB問題集や模擬試験を含め、
間違った箇所の再学習が重要です。

WEB問題集のフリープランで腕試し

AWS WEB問題集で学習しよう – 赤本ではなく黒本の問題集から学習する方向け
独自の問題集らしいのですが、内容的には模擬試験にかなり似ています。
ただ、あまりこのサイトを頼らないほうがいいと思います。
なぜならば、ソリューションアーキテクト-アソシエイトレベルの内容は
充実していますが、他のレベルの内容は足りていないからです。
問題の雰囲気を掴む程度に利用したほうがいいと思います。

模擬試験を受けました。模擬試験の結果は合格!

模擬試験は有料ですが、試験に合格したいのなら
受けるべきです。模擬試験は自宅で受けることができるので
問題のコピーも可能です。回答は表示されないので、
どこを間違ったのか自力で調べて、回答を導き出す必要があります。
自分は模擬試験は合格しました!

そして本試験!結果は合格!

本試験は試験会場で行われます。
模擬試験と比べて難易度が高く、
受験料も高いので慌てそうになりますが、冷静に問題を解いていきます。
無事に合格できました。

個人的に、認定試験を受けるなら抑えておきたいAWSナレッジを共有します。

Active Directoryを活用したAWS Management ConsoleへのSSO(AD Connector編)

Active Directory関連は抑えておいたほうがいいと思います。
特にAD Connectorが何なのかとか。
dev.classmethod.jp

プレイスメントグループ

プレイスメントグループは個人的に影が薄くて忘れていた存在!(ぉぃ
認定試験ではとても重要な内容です。完全に理解しておくことをオススメします。
docs.aws.amazon.com
dev.classmethod.jp

CloudFormationでStackを削除した時にリソースを消さない設定

こんなのCloudFormation使ってないと絶対分からん!的な内容。
これまた、認定試験では重要な内容です。
dev.classmethod.jp

S3への保存に成功したことを確認する方法とは

MD5チェックサムを確認する方法を抑えておいたほうがいいと思います。
qiita.com

EC2セキュリティグループの反映タイミング

EC2クラシックとVPC内で反映のタイミングが異なるのは理解しておきたい。
即時反映はVPC内のみ。
docs.aws.amazon.com

OLTPとは何か

このような用語を覚えておかないと、認定試験でつまづきます。
OLTP、OLAP、DWHそれぞれの特徴や違いを把握しておくことをオススメします。
www.imkk.jp
http://www2.gssm.otsuka.tsukuba.ac.jp/staff/kuno/lectures/11/2011-10-InfosysTech2.pdf


次は「認定デベロッパー-アソシエイト」を目指します!
とりあえずAWS Summit 2017 Tokyoに参加する!
www.awssummit.tokyo