B5ノートの右の方

ゲームが好きなエンジニアのブログ

VSCodeでJavaの開発環境を整える

はじめに

勉強のため、自宅でJava17の開発環境を整えましたので、メモしておきます。

使用ツール

Gitの準備

  • Githubで学習用のリポジトリを作成しておく
  • WindowsにGitをインストール gitforwindows.org
  • git init
  • 作成したリポジトリをclone

    VSCodeのプラグインセットアップ

  • Extension Pack for Javaをインストール
  • Welcomeページに書いてあることを順に実施
    • Get your runtime ready 画面下部のTERMINALを使用してpathが通っていることを確認。通ってなければ、Windows環境変数のJAVA_HOMEにpathを設定し、VSCodeを再起動。
    • Explore your project 画面左のEXPLORERから「Create Java Project」をクリック。今回はGradle Projectを作成する。
      • Gradle for JavaのInstallポップアップが出るので、クリックしてインストール。
      • いつもならDSLはGroovyですが、学習用なので未経験のKotlinにしてみます。
      • "settings.gradle.kts"ファイルを開くと、「Kotlin Language」のインストールを促されるので、そのままインストール。
  • github push
    • .gitignoreに「.vscode」を追加
    • READMEに好きなように追記
    • commit + push

      おわりに

      これでひととおり開発環境が出来ました。 あとは好きにセッティングします。

1位思考を読んだ

読書感想文

1位思考――後発でも圧倒的速さで成長できるシンプルな習慣

1位思考――後発でも圧倒的速さで成長できるシンプルな習慣

Amazon

読書にかかった時間：3時間
結構読み飛ばしました。詳細は後述します。

自分の業務内容・考え方と違うな、と思ったのですが、あえて違う考え方を知りたくて、読みました。

おすすめポイント

レッドオーシャンで製品を売り出していき、1位を取るためにどうすればよいのか、 恐らく商品開発やマーケティングの分野で基本とされていることが書かれている。
気持ちを作るには良いと思った。

学びポイント

  • アンラーニングが大事：前に成功した方法で、次も成功するとは限らない。
  • 幅広い知識と、1つ、あるいは2つ以上の専門性を掛け合わせると、自分だけの専門分野を作り出せる。
  • 自分の働いている部署は1次受けのSIerで、自分で製品を作り出すわけではないが、 顧客がその業界でどのように優位性を保とうとしているのかは理解する必要があると感じた。

所感

  • 製品でどう優位性を取っていくか？という話が主体でした。（看板に偽りなし） また、成長したいという気持ちのあふれた人しか採用しない、一緒に働く人はみんな同じようなタイプにするという方針が語られていました。
  • 自分の業務状況とは違う環境だと感じたので、マーケ、企画あたりの話は読み飛ばしています。 また、自分の業務は「いろいろな立場のひとと最良の結果をできるだけ早く出す」点に集約されると思うので、この本の「1位をとる」という点とはやはり開きがありました。（予想通り）
  • しかし、1次請けである以上、顧客はこのような考え方も存在していると思うので、考えの一助になりました。
  • 自己啓発本によくある「昔がむしゃらに働いたおかげで今の私がある」系のことが書かれていてその点は少し残念でした。結局、睡眠時間やプライベートを犠牲にしてがむしゃらに働かないと経験が得られないの？と感じるからです。

STREANGTH FINDERを受けてみた

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

Amazon

テストにかかった時間：40分くらい

結果を確認した時間：30分くらい

備忘も兼ねて、自分の強みを晒していくスタイルで行きます。 弱みなどを更に知るには6000円くらい課金が必要でしたが、そこまではやってないです。。

ポイント

34の特性の中から、自分の強みを1位～5位まで知れる。 また、その強みを持つ人がどのような行動をとったらよいかのアドバイスが書いてある。

自分の強み

1. 学習欲

自分の知らないことを知る、できなかったことが出来るようになることが好き。学習プロセスが好き。 学習分野の専門家になりたいとか、達人になりたいという、結果を目的としていない。 流し読みや要点をまとめたものを読むことに意味を感じない。 短期間で新しい技術を身につけ、すぐにまた新しい技術を身につけるような環境が得意。

2. ポジティブ

人をよく誉め、どんな状況でもポジティブな面を探す。どんな進歩も祝福する。生きていることはすばらしい、仕事は楽しいものにできる、どのような障害があろうとユーモアを失ってはならないと思っている。皮肉屋や否定的なことを言う人がいると、とたんに引きずられる。

3. 個別化

ひとりひとりの特性に目が行ってしまう。本能的に、人の考え方、動機、性格、関係の築き方を観察している。その人にふさわしいプレゼントが何かを考えるのが好き。（逆に、一般的に喜ばれるものを考えるのは苦手。）チームビルディングでは、方法論よりも、メンバーそのものの特性を活かすことができる。

4. 原点思考

現在を理解するために過去を理解しようとする。元々の考え方を知ることで、適切な判断を下せる。メンバーのことを知るときは、現在ではなく、これまでどのように過ごしてきたかを知ることの方が判断材料として適切。「未来志向」「戦略性」の特性のある人と組むと、過去に埋没しない。「どうしてこうなったのか」を把握するのがうまい。

5. 親密性

多くの人と仲良くなるよりも、今まで仲良くなった人とさらに親密になることを好む。人の職位や地位よりも、性格や人となりに興味がある。

これから

自分の強みが、わかってはいたことですが、あまり「エンジニア」向きではないなと感じます。でも、これを伸ばすことで、物事の調整や、メンターの得意なエンジニアという、希少価値が生みそうな予感がしているので、頑張って強みを伸ばしていきたいです。

こういう話を20代のうちにできとけばなぁ。。とも思いますが、20代は実地経験の時代だったということにしておこうと思います。

アジャイル開発とスクラムを読んだ

読書感想文

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Amazon

読書にかかった時間：4時間くらい（アジャイルについての知識があまりない場合は、もっとかかると思う）

おすすめポイント

  • 実際の企業での導入事例がいくつか記載されている。どのようにスクラムによる開発を実践したか、またそのボトルネックになった事象は何かなどがかなり具体的に書いてあった。

学びポイント

  • スクラムの大規模化
    • 単に大きなプロダクトを作るために大規模化する、組織自体をアジャイルに回していくなど、いくつかのアプローチ方法があることを知った。
    • 今後勉強したい。

これから

  • チームの若手を育成するために、外からと内からの働きかけが必要そう
    • 外：日々の仕事の中に学びのための「ゆとり」を設計し、いつも通りに働き、いつも通りに学ぶことが大事
    • 内：組織をトップ・ミドル・フロントに分けて考える。ミドルはフロントと対話し、トップを教育する必要がある。フロントは言われたことをただやるだけではなく、顧客や他部署と会話する、他社を訪問するなどして、自らが所属するサイロを超えた大きな関係性の中で実体験を積むことが大事。
  • 自分の組織でやりたいことがいろいろ出てきた
    • スクラムの実践
      • プロダクトバックログの優先順をつける
      • バーンダウンチャートをどうにかして作る
    • チームを知る
      • 自分のチームのスクラムでの立ち位置を明らかにする
      • 自分のチームでやらないことを決める
      • LTを実践している組織に、どうやって導入したのか、導入してどうかをヒアリングする
    • メンバーを知る
      • メンバーの特性を理解する機会をつくる

日経コンピュータ2022/5/26を読んだ

読書感想文

xtech.nikkei.com

気になった記事

  • NTTデータが地銀向けの新ミドルを製品化
    • 実際に導入したらどんな感じになるのだろう？
    • なにもなかったところに導入する場合、ミドルがすり寄るか、アプリがすり寄るかは必須な気がしていて、結局アプリがすり寄ってしっちゃかめっちゃかになるという未来が想像できるが。
    • 銀行系システムに携わったことないのですが、置き換え元となるメインフレーム製のミドルウェアは、独自性はあまりないものなんだろうか？
  • 富士通ってメインフレームから撤退したんですね(今更)
  • MLOpsの話
    • つまり機械学習(ML)の運用(Ops)の話
    • データ更新による再学習などのシステムの例がいろいろ
    • こういった仕組みの提案って、現場のどこがボトルネックかという情報がないと、なかなかできないなと感じた。顧客の情報取得って大事だ。
  • テレワーク会議のコツ
    • 助かる！！
    • チャットツールによる共有と、テレワーク会議を並行する
    • 基本的なモデレータと、モデレータがしゃべってる間にフォローする人を用意しておく。（声をかけておくだけでOK）
    • 共有画面と参加者の顔を映す画面の2画面用意して、参加者の顔から、考え中か、もう意見はないのか、読み取る。
    • 一般的に、画面の上下左右を見つめていたり、顔の一部に手をやっている場合、その人は考えていることが多い。
    • 考え中の人がいるかわからなかったときは、「何か気になる点がありますか？」などとなげかける。

      ほんで

  • テレワーク会議のコツは実践してみる。
  • できるだけ、顧客の業務ボトルネックを探ってみる

はてなブログでGoogle Fontsを使ってみる

はじめに

はてブで趣味ブログをはじめようと思ったのですが、フォントが気に入らない！！と思い、Webフォントを導入してみようと思いました。

Google Fontsでフォントを探す

Google Fonts

手書きフォントが好きなので、Yomogiにします。

選ぶ

Yomogiのページのダウンロードしたいスタイルの右の方に「select this style」というリンクがあるのでクリック。

画面右側にサイドバーが現れまして、Use On Webって書いてあります。

<link>のラジオボタンを選択すると、その下にhtmlコードが表示されるので、コピーします。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Yomogi&display=swap" rel="stylesheet">

ブログにフォントを注入する

はてブの管理画面のデザインから、カスタマイズ→「ヘッダー」を選び、先ほどコピーしたhtmlコードを貼り付けます。

注入って...DIかよ

CSSでフォントを適用する

Google FontsのYomogiのページのサイドバーにCSS rules to specify familiesって書いてあります。 ここにCSSコードが書いてあるので、コピーします。

font-family: 'Yomogi', cursive;

はてブの管理画面のデザインから、カスタマイズ→デザインCSSを選び、下記のような感じでCSSを書きます。

body, #title, .entry-title {
font-family: 'Yomogi', cursive;
}

最初はbodyだけ指定してたのですが、ブログのタイトルと、記事タイトルがうまくフォントが変わらなかったので無理やり指定しました。ちょっと汚い。

以上です。

ほんで

ブログのフォントを変えられました！ が、満足してないのでまた変えるかも。

参考

最新版｜はてなブログでグーグルフォントを使う方法（ブログタイトルのフォントをカスタマイズ） - Simple Life Navi はてなブログにGoogle Fontsで日本語フォントを使ってみよう - つなろっく

AWSでJava開発環境構築する

概要

最近PGする機会がめっきり減ってきたので、コーディング力を維持する(というか成長させる)ために、Javaでも書いてみようと思いました。 せっかくなのでクラウドの統合開発環境の代表格(?)であるAWSを使ってみます。

やること一覧

  1. Gitでリポジトリ作成
  2. Cloud9 の環境作成
  3. READMEをGitにpush
  4. プログラムを一本push

1. Gitでリポジトリ作成

f:id:sudaching:20210227114746p:plain
Create a new repository at github

いつもの画面が出てきます。

f:id:sudaching:20210227114905p:plain
new repository!

2. Cloud9 の環境構築

AWSマネジメントコンソールの検索バーにCloud9と入力

f:id:sudaching:20210227115228p:plain
AWS Management Console
Cloud9が選択肢に出てくるのでクリック
f:id:sudaching:20210227115327p:plain
Input "Cloud9"
「Create environment」をクリック
f:id:sudaching:20210227115446p:plain
Create a new Cloud9 environment
名前と概要を書いて「Next step」をクリック
f:id:sudaching:20210227115859p:plain
Name environment
高性能でなくていいですし、デフォルトからセッティングをいじる必要もなさそうと判断して
そのまま「Next step」をクリック
f:id:sudaching:20210227120050p:plain
Configure setting 1/2
f:id:sudaching:20210227120124p:plain
Configure setting 2/2
確認画面ですね。Cloud9環境を使用するにあたっての注意事項が書いてあるので、
読んでから「Create environment」をクリック

  • 個人でバックアップをとる
  • 環境は自分で最新化する
  • AWSアカウントを「AWS CloudTrail」にする
  • 信頼できるユーザにだけ公開する
    f:id:sudaching:20210227120946p:plain
    Review
    数分待ちます。
    f:id:sudaching:20210227121059p:plain
    waiting
    おまちどーん！できました！
    f:id:sudaching:20210227121158p:plain
    Creating completed!

    3. READMEをGitにpush

    Gitリポジトリに書いてある始め方に沿って進めます。

ec2-user:~/environment $ git init
Initialized empty Git repository in /home/ec2-user/environment/.git/
ec2-user:~/environment (master) $ git add README.md 
ec2-user:~/environment (master) $ git commit -m "first commit"
[master (root-commit) 66bbe65] first commit
 Committer: EC2 Default User <ec2-user@ip-172-31-32-251.us-east-2.compute.internal>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

 1 file changed, 14 insertions(+)
 create mode 100644 README.md
ec2-user:~/environment (master) $

ユーザ登録していないので怒られました。ユーザ登録して引き続きpush 。

ec2-user:~/environment (master) $ git config --global user.name "Mick Danjoh"
ec2-user:~/environment (master) $ git config --global user.email *****@gmail.com
ec2-user:~/environment (master) $ git branch -M main
ec2-user:~/environment (main) $ git branch
* main
ec2-user:~/environment (main) $ git branch -a
* main
ec2-user:~/environment (main) $ git remote add origin https://github.com/danjo-m/lemon.git
ec2-user:~/environment (main) $ git push -u origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 511 bytes | 255.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/danjo-m/lemon.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
ec2-user:~/environment (main) $

リポジトリにpushできました。

f:id:sudaching:20210227123710p:plain
push README to lemon

4. プログラムを一本push

まじで何でもないプログラムを作ってpushします。

あらかじめJDKが入っていることを確認。

ec2-user:~/environment (main) $ java -version
openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode)
ec2-user:~/environment (main) $

いつものHello World

f:id:sudaching:20210227124303p:plain
Sample1

ec2-user:~/environment (main) $ ls
README.md  Sample1.java
ec2-user:~/environment (main) $ javac Sample1.java 
ec2-user:~/environment (main) $ java Sample1
Hello World!
ec2-user:~/environment (main) $

Hello Worldできました。
こいつをpushしておきます。

ec2-user:~/environment (main) $ git add Sample1.java
ec2-user:~/environment (main) $ git commit -m "Create first pg"
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:
        .c9/
        Sample1.class

nothing added to commit but untracked files present
ec2-user:~/environment (main) $ git push origin main
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 409 bytes | 204.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/danjo-m/lemon.git
   66bbe65..3b9fb5f  main -> main
ec2-user:~/environment (main) $

gitignoreやクラスファイルの整理はおいおい。

おまけ：Gitコマンド

Githubで情報提供されていたコマンドのオプションをすっかり忘れていたので、
使ったものだけでも整理。

  • git commit -m "comment"
    -mで単一コメントを記述する。
    対象ファイルを書かない場合はステージされている(addした)全ファイルをコミット。
  • git branch -M <branch_name> 「branch_name」のカレントブランチの名前を変更。
    -mだと上書き禁止。-Mだと強制上書き。
  • git push -u <remote_path> <local_branch>:<remote_branch>
    「remote_path」へ「local_branch」を「remote_branch」へpush。
    ブランチ名はローカルとリモートが同じ場合は1つに省略可。
    -uオプションで、次回からgit pushだけで今回と同じ操作ができる。
    「remote_path」は省略名で指定可能。省略名はgit remote -vで確認。
ec2-user:~/environment (main) $ git remote -v
origin  https://github.com/danjo-m/lemon.git (fetch)
origin  https://github.com/danjo-m/lemon.git (push)
ec2-user:~/environment (main) $

参考リンク

Gitチートシート
[Git]git branch コマンドの -m と -M オプションの違い
git pushのオプション -u とは

以上！