前に書いたDockerでJavaの環境構築について。
alias用意して、bash起動する方式だったけど、
そもそもコンパイルをbuild時点で終わらせておきたい。
Dockerの思想的には、イメージの時点で動くものが用意されているべきなので、
コンパイルを済ませておいた方が良さげ。
で、どう実装するか迷い中。
コンパイルの手順をDockerfileに用意するのは、プログラムに応じてDockerfile書き換えることになるのでナンセンス。
ということで、Makefile。
Dockerfileには、Makefileを動かす記述だけする。
これで、Dockerfileはそのままに、Makefileだけユーザーに書かせれば良い。
Makefileも生成ファイル名を固定してやれば、ビルド後にランするコマンドも固定出来そう。
もう少し環境考えてみよう。
それっぽくなったらgithubにあげよう。
自分が所属しているコミュニティで、
私が前書いた『コメントの二重管理』の記事から、派生した雑談で生まれた記事。
この記事、本当に勉強になります。
でも、なぜこの記事が生まれたんだろう。
ブログを書いていなければ、この雑談は生まれなかったので、
アウトプット大切。
結果、ブログ書いていただけて、新しいインプットが行われました。
ただ吐き出すだけだと、何も生まれませんが、
お互いに意見を言い合える仲間がいるって大切。
コミュニティに属するか、友人とたまに技術のお話するといいと思います。
アウトプットするだけじゃ生まれない、
内容についてお話出来る仲間がいてこそなので、
今回話に乗っかってくれたコミュニティの皆さんに感謝。
これからもアウトプットと、コミュニティ広げるの頑張っていきます。
こちらを参考に、公式イメージを使えるようにする
javaのエンコードを打ち込むの面倒だったので.bash_profileに無理やりalias。
あとでヒアドキュメント構文とかで書き直したい。
FROM store/oracle/serverjre:8 RUN echo -e "alias javac='javac -J-Dfile.encoding=UTF-8'\nalias java='java -Dfile.encoding=UTF-8'" > ~/.bash_profile WORKDIR /home/app COPY . /home/app
ビルドとログイン
docker build . -t java_bash docker run -ti java_bash bash --login
コンテナ内
javac Osero.java java Osero
とりあえず、これでJavaがコンテナで動かせる。 でも、これもっといいやり方ありそうですし、また環境整ったら作り直す予定。
初心者の友人向け
function Osero {
showBoard();
putPiece();
turnPiece();
judgeEnd();
}
function showBoard() {
....
}
function putPiece() {
....
}
...
...
...
ゲームは正しく終われるのに、コマがうまく置けない、コマがひっくり返らない！
プログラムなんで動かないんだわーーーー！
って初心者陥りがち。
ちょっとまってくれと。
作れそうなものから作って、全体を同時に作ろうとするなと。
とかいろいろデメリットが・・・
いろいろやり方はありますが、ひとまず私のやり方を。
function Osero {
}
これだけ。中身考えちゃだめ。
まずは、『これを作ります！』って、プログラミングがわからない人にもわかるレベルで、考える。
とか、作らなきゃいけない機能を考える。
この時も、プログラミングわからない人でも、どんな機能かな？ってわかるレベルで考える。
だから、データベースに保存する、とかまで考えちゃダメだよ。
入力をする・・・は微妙だけどセーフ。
ちなみに、紙に図を書くとかでも良い。
function Osero {
// ボードを表示させる
// コマを置く
// コマをひっくり返す
// ゲームが終了するかを判断する
}
こんなレベル。
// ボードを表示させる
// ・1行目として、8マス表示させる
// ・8マスを8つ表示させる
// ・真ん中に初期のコマを置く
// コマを置く
// ・ユーザーに置く場所を入力させる
// ・コマがおける場所か確認する
// ・コマを表示させる
こんな感じ。細かくしていくと、それぞれ作れるような気がしない？
大量の関数を同時に作り始めないこと。
『あ。この機能も作らなきゃ！こっちの方が簡単だし、先につーくろ！』
とかで全部、中途半端に作るは絶対にダメだからね。
『動かない！なんで動かないんだ！どこが悪いんだ！』とかなるので。
「Aの機能ないと、Bの機能作れないや。Aの作業を止めて、Bを作ろう」
はセーフ。ただし、Aの機能は、後で再開する時に『このコード、何書こうとしてるんだろう・・・』ってなったりするので、ちゃんとキリいいようにね。
覚えてほしいのが、
『オセロは小さなプログラムの集まり』
『大きなプログラムは、小さなプログラムの集まり』
ということ。
歯車を一つ一つ組み合わせて、大きな車があるのです。
大きな車をいきなり作れるのがエンジニアじゃないです。
歯車を少しずつ作って、それを少しずつ組み立てていってください。
じゃあ実際にどう作るの？
っていうのは、前回のgitのブランチと絡めて、今度一緒にやりましょう。
友人用。ざっくり説明。
ダウンロードしたいコードの画面中央右側、緑色の『clone or download』をクリックして、
出てきたURLをコピー。
git clone コピーしたURL
でOK。 git clone https://github.com/klack710/for_beginner.gitみたいになる。
以下はおまけ
以下のコードの[user_name]のところにユーザー名を使うと git clone https://[user_name]@github.com/klack710/for_beginner.git どのアカウントでそのgitをcloneするかを決めることが出来る。 特定のユーザーしかclone出来ないような、privateなリポジトリに有効。
ブランチを正しく説明出来る気がしないので、他のサイトにそこをお願いして、
『誤解をしてもいいから、ざっくり説明すると』
『今のコードをコピーして、別な作業場所を作る』
この後やりたいことは、
git branchでブランチの確認。緑が今いるブランチ。
git checkout -b new_branch_nameで、新しくブランチを作る
あ、new_branch_nameのところは別な名前自分で考えてつけてね。
コマンドの説明としては、
git checkoutで、ブランチの切り替え-b で、ブランチがなかったら新しく作るnew_branch_nameで、切り替え先のブランチ名なので、masterに戻る時は
git checkout master
になる。
さあ！コーディングだ！
ってことで、git checkout -b new_branchってした後は思いっきりいろいろコード書いてみてね。
コードを書いたら、次は合体するための作業だ。
コミットを簡単に言うと、変更点のセーブをする。ゲームのセーブみたいに。
ゲームのセーブと違うのは、『一部だけセーブしたり』『過去のセーブデータにも戻れる』みたいな感じ。
git add some_file.html git add some_file2.css git commit -m "セーブデータにコメント。変更点とか書く" git push origin new_branch_name
コマンドの説明
1. セーブするファイルを決定。 git add some_file.html git add some_file2.css 2. データをセーブ git commit -m "セーブデータにコメント。変更点とか書く" 3. セーブしたデータを、githubに送信する git push origin new_branch_name
pushしたら『これをmasterと合体したいです！』って報告するために、githubに行こう。
1.New pull requestか、pushしたばかりなら、Compare & pull requestを選ぶ。
2.baseに合体先、compareに今回作ったブランチを選択して、Create pull requestする。
これでプルリク完成。
『『他の人が見て、このコードが良さそう！って言ってもらえたら』』
2.この緑の Merge pull requestで合体。
っていうのが、ざっくりとした流れ。
1人でやるか、一緒にやるかはおまかせ！
時間合わせられそうなら、さくっと一緒にやろう。
先にやりたければ、私のgitをcloneして、4番までやってみよう。
$ ls index.html
この状態で、このindex.htmlをgithubで管理したい
これは単純に、git initをして送るだけでいい。
マイページから、リポジトリの作成をする
リポジトリの名前を用意する
出来たら、そこに書かれているコマンドの通りにやれば良い。
echo "## for_beginner" >> README.md git init git add README.md git commit -m "first commit" git remote add origin https://github.com/klack710/for_beginner.git git push -u origin master
私の例だと以下。
(1.gitに上げたいファイルを作る。すでにあるなら省略) echo "## for_beginner" >> README.md (2.gitの初期設定) git init (3.git管理するファイルを指定。この場合README.mdをgitに上げたい) git add README.md (4.今回行った作業を登録する。今回は、README.mdを作ったことを登録する) git commit -m "first commit" (5. 手元の環境に、`origin`は`https://github.com/klack710/for_beginner.git`ですよと登録) git remote add origin https://github.com/klack710/for_beginner.git (6. originのURLに向けて、masterブランチにデータを送る) git push -u origin master
// おすすめ商品を5個表示する $this->recommendItems();
こんなコメント。なぜダメか。
例えば元コードに
// おすすめ商品を5個表示する
function recommendItems() {
....
}
なんて書いてたら、同じコメントを2つ書いていることになる。
2.recommendItemsの仕様が変わったら？
// おすすめ商品を10個表示する
function recommendItems() {
....
}
もしrecommendItemsの仕様が変わって、10個表示することになったら？
// おすすめ商品を5個表示する $this->recommendItems();
こちらのコメントも書き換えないといけない。
後で見た人があれ？ってなってしまう。
recommendItemsの仕様変更なのに、別の場所のコメントまで書き換えないといけない。
コメントを書く時も、そのコメントがどこに影響するか。
今後見る人が本当に理解しやすいかなど、
結構神経を使うべきものなので、
コメントを書く時も、さらさらっと書かずに、これで本当にいいかな？と立ち止まってみてみましょう。
LTとは、ライトニングトークの略で、3-5分程度のプレゼンをする文化です。
エンジニアの交流会とかで盛んに行われるあれですね。
ということで、今日あったエンジニア交流会で初LTしました。
他社の方もいらっしゃって、初LTということでかなり緊張しました。
タイトルは
『新卒一年目がブログ書き続けて得た3つのこと』
それは、勉強の習慣、他者との交流、そして自信です。
新卒一年目に不足しがちな3つを手に入れれました。
詳しくは、またどこかでLTするかもしれません。
他者との交流の点でもいいましたが、他の方とLTの話題で話せたのがいい。
また、他の方から声かけられたり、話しかけたら、あのLTの子と認識してくださって話しやすい。
コミュニケーションが上手ではない私には本当にありがたいことです。
お世辞でも、LT良かったと言っていただけると嬉しいですね。
ちょっと早口だった。
時間に余裕があったので、もう少し焦らなくても良かったかも。
あと、『アウトプットして得たこと』より、『アウトプットする習慣をつけること』が知りたいという方がいらっしゃいました。
たしかになるほど、アウトプットの習慣が大切なのを知ってる人は多いですが、それをどうやって始めてもらうか、それを課題にしている人の方が多そうです。
次にLTすることがあれば、『なぜブログを続けられたか』をまとめようと思います。
ただ、『落ち込むところまで落ち込んで、開き直った』というのもそこそこモチベーションではあるので、なかなか難しいですね。
ってことで、新卒一年目の内にLTするという裏目標は達成したので、この第一歩を大切に、どんどんアウトプットしていきます。
頑張るぞー！
これからも応援していただけると嬉しいです！
