おからの日記

最近,おからに改名しました

Dockerfileとdocekr-compose.ymlの書き方

Dockerfileとdocekr-compose.yml,どっちが先に読まれるのか,どっちもコマンドを使えるがどこまでをどっちのファイルに書くのか,調べてみても様々な書き方が出てきて迷いました...
正解かわかりませんが現時点での自分の理解を載せておきます.



Dockerfileには一つのコンテナを立ち上げるプロセスを書きます.
例としてpython3を使う場合の公式のコードをあげます.

Dockerfile

1   FROM python:3  
2
3   WORKDIR /usr/src/app
4
5   COPY requirements.txt  ./         
6
7   RUN pip install --no-cache-dir -r requirements.txt 
8
9
10  COPY . .                         
11
12  CMD [ "python", "./main.py" ]    

やってること
5行目  ./ 配下 にある requirements.txtをdockerコンテナの中にコピー
7行目  requirements.txtに書かれたライブラリをインストール.
10行目  ./ 配下 にあるディレクトリとファイル全てをdockerコンテナの中にコピー.
12行目 $ python main.pyを実行.このとき$ python3 main.pyとしなくていいのは,python3のイメージのみを使っているため.


docker-compose.ymlにはどのDockerfileを読んで使うかを書きます. このファイルでは複数のコンテナを同時に立てることができます. Dockerfileを選んでイメージを作る仕事だけをさせるのでここにはcommand:はあまり書かない,はずです...
command:を使う場合は,あとで説明する,Dockerfileを自分で書かない場合です. 上のDockerfileを使う場合,最低限のコードを書くとこうなりました.

docker-compose.yml

1  version: '3'   
2  services:  
3    webapp:     
4      build: . 

やってること
1行目  docker-composeのバージョンを指定.
2行目  コンテナの集まりの名前を定義.この名前はよく使われています.
3行目  一つのコンテナの名前を定義.
4行目  ./ にあるDockerfileを使う.という意味



二つのファイルを保存したら,

$ docker-compose build
$ docker-compose up

と叩くと,以下2つのコマンドを叩いたことと同じになります.

$ pip3 -install -no-cache-dir -r requirements.txt
$ python3 main.py

なんだこれだけかという感じですね.これだったらpip3 ooo くらいなら叩くけどなあと思ってしまいますが,コンテナをいくつも建てるとなるとありがたさがわかってきます.

複数のコンテナを建てる場合はこうなります.

1  version: '3'   
2  services:  
3    webapp:     
4      build: . 
5    server:
6      image: redis
7      command: redis-server
8    test:
9      image: minio/minio

webapp, server, test の3つのコンテナを建てました. image : redisでは,Docker Hub に上がっているDockerfileを読み込んで使えます.

https://hub.docker.com/r/minio/minio
https://hub.docker.com/_/redis

これが先ほど言った「自分で書かないDockerfile」です.この場合,打ちたいコマンドをDockerfile内で指定できないのでcommand:を使うことになります.
ここでは「イメージを決める」,「コマンドを叩く」の二種類しかやらせていませんが,ポートの指定や,データ,環境変数の指定もできます.

参考
* Dockerfile Docker Hub
* docekr-compose.yml Compose file version 3 reference | Docker Documentation

Flaskのrequestの仕様でわかったこと

flaskのrequestの仕様ではリクエストのcontent typejson型を設定してpostするとrequest.jsonjsonデータがそのまま入るようです.request.dataにはバイナリで保存されました.

from flask import Flask,request
import json

app=Flask(__name__)

@app.route('/',methods=['POST'])
def index():
    if request.method == 'POST':
        jsondata=request.json
        binary=request.data
        print("request :",request)
        print("request.json :",jsondata)
        print("request.data :",binary)
        return json.dumps(jsondata)
 
def main():
    print('')

if __name__ == '__main__':
    app.run(port=8000)

{'name': 'hanako'} をpost リクエストで送るとこんな感じになります.

request : <Request 'http://localhost:8000/' [POST]>
request.json : {'name': 'hanako'}
request.data : '{\n\t"name" : "hanako"\n}'



リクエストの送信にはコマンドで
$ curl -X POST -H "Content-Type: application/json" -d '{"name":"hanako"}' localhost:8000

のように叩いてもできますが, postman( https://www.getpostman.com/apps )を使いました.UIはこんな感じです.使い方としてはまずrequestのbodyに送るデータを書き,

f:id:akari000:20181223095122p:plain

ヘッダーにデータの種類 Content type : application/json を書きます. f:id:akari000:20181223095222p:plain

return json.dumps(jsondata) としているのでresのbodyにはjsonデータが帰ってきます.
f:id:akari000:20181223095236p:plain

わかったことや詰まったことなどgoogle keepに保存していますがkeepの拡張機能をchromに入れたら気になったことは全部keepに投げてしまってそろそろ整理が必要になってきました...
とりあえず埋もれてしまわないように空いてる時間にここにあげようと思ってるのですがかなり爆速であげていかないと追いつかなそうです笑

並列処理,並行処理

よくどっちがどっちかわからなくなるのでまとめました.

非同期処理 並行処理 いくつかのCPUで処理する
本当に同時に処理をしている
pythonのmultiprocessing
並列処理 待ち時間に他の処理をする
CPUは一つのみ
javascript
pythonのthreading
同期処理 上から一つづつ処理する C, Python, Ruby..(javasqript以外ほぼ全部)

並列処理と並行処理,どちらもいくつかの処理を同時に行うものです.
この二つの違いは簡単にいうと本当に同時に処理しているか.

「並行処理」は実際に複数のCPUを使って同時にプログラムを処理します.一方で「並列処理」は,処理が順不同になるだけで,実際には同時に処理を行なっていません. この場合同期処理でいい気がしてしまいますが一つのプログラムが待ち状態の時に他の処理を行なっているので, 無駄な時間を減らせるメリットがあります.
例としてよくあげられるのは,のライブラリにあるthreadingmultiprocessingですね.
doc↓
threading https://docs.python.org/3/library/threading.html#module-threading
multiprocessing https://docs.python.org/3/library/multiprocessing.html


javascriptは非同期処理と言われますが,実際に同時に処理をしているわけではなく並列処理です.front側の言語では,全て読み込みが終わるまで画面に何も表示されなかったりするのは見る側からするとストレスになるので同期処理ではなく非同期処理が使えるという理解です...
他にも一部だけ見た目を変えたりアニメーションをつけたりするときに毎回処理をしなおさなくてもいいようなプログラムがかけます.

新しいmacを買ったら最初に入れるものたち

ここ最近新しいmacの環境構築を何回もやって自分が最初に何を入れるかだいたい決まってきたので覚書も兼ねて書き出してみました. 完全に私流です.

目次

  • app storeから
  • web から
  • コマンドから
  • 環境設定
  • その他に使ってみてよかったもの

app store から

  • slack これは説明は必要なさそう
  • Notebook メモ帳として使っています.綺麗なのにそんなに重くないです.アカウントでログインできるので複数のパソコンで使えます. f:id:akari000:20181219104012p:plain

webから

コマンドから

  • Home brew 
  • fish
    予測がかなり強いです.あとはデザインを変えたりブランチを表示したりする設定が割と簡単にできます.
  • fisherman
    fishを使うなら入れておきたいやつです.よく開くワークスペースを覚えてくれるので作業が早くなります.
  • vim
    これは使い始めたばかりです.作業がキーボードだけでほぼ完結できます.黒い画面だけのイメージでしたが,かなり拡張性があって綺麗になりました.今はこんな感じで表示できるようにしています.
    f:id:akari000:20181223073755p:plain

  • Git hub
    ソース管理だけだと最初は思っていましたがプロジェクトのタスク管理もできるのを知って学校の開発組に広めたら好評でした.自分のページも近々作りたい..

環境設定

日本語切り替え

「control」+「spase」の切り替えはめんどくさいので 「caps lock」で切り替えられるようにします.

「環境設定」→「キーボード」→「入力ソース」→ caps lock の設定を変更 f:id:akari000:20181219085100p:plain オフ→英語 オン→日本語 に設定

トラックパッドの設定

三本指でドラックができるようにします.
「環境設定」→「アクセシビリティ」→「マウスとトラックパッド」  →「トラックパッドオプション」→ドラッグを有効にするにチェック f:id:akari000:20181219085419p:plain

他にも使ってみてよかったもの

この辺はまた今度説明を入れるつもりです.

  • Wonderlist 
  • Source tree
  • brakets

class passが無いと言われる

vscodejavaデバッグ環境を作った話の続きです。 vascde 拡張機能Java Extension Pack を使ってデバッグができるようにしました。 f:id:akari000:20181101110340p:plain

この過程で
"filename isn't on the classpass."
というエラーが出ました。
f:id:akari000:20181101105736p:plain

classpathって何..

どうやらvscodeでは project/.classpath の中に書いてあるパスを参照してクラスを探しているようです。
.classpass

f:id:akari000:20181101111658p:plain

path="src" という記述があるように,src配下に置いたファイルのクラスは参照できるようになります。
それ以外の場所にファイルを置きたい場合は
<classpathentry kind="src" path="folder name"/>
と記述すると folder name 配下のファイルのデバッグができるようになりました。

VSCでJavaのデバッグをする(mac)

学校でjavaを使う課題があるためよく使っているvscでデバッグができるようにしてみました。

1.JDKのインストール

まずはjava自体のインストール。

$ java -version

これで何も出てこなかったらJDK ( java development kit )をインストールする必要があります。 ここから今回は Java SE Development Kit 8u191 の Mac OS X x64 をインストール。

Java SE Development Kit 8 - Downloads

インストールが終わったら,$JAVA_HOME の設定をします。 まずはJAVA_HOMEに設定する場所(使うjavaのパス)を調べます。

$ /usr/libexec/java_home

$ export JAVA_HOME=さっき出てきたパス

これでJAVA_HOMEの設定完了です。 設定できているかは以下のコマンドで確認できます。

$ echo $JAVA_HOME

2.VSCの設定

まず ⌘ + , で設定画面を開き,「設定の検索」に javahomeと入力。 「settings.jsonで編集」を選択します。 f:id:akari000:20181023215741p:plain f:id:akari000:20181023215920p:plain このような記述があるとと思うので,「ペンのアイコン」→「設定にコピー」を選択し設定を書きかえます。

"java.home": "さっき出てきたパス"

メニューバー →「ターミナル」→「タスクの構成..」 → 「テンプレートから tasks.json を生成」→「others」(これは任意)  を選択。 作られた vscode/task.json の中身を以下のように書き換えます。

{
    
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "shell",
            "command": "mvn compile"
        }
    ]
}

$ mvn --version

でmvnがインストールされているか確認し,されていない場合以下のコマンドでインストール

$ brew install maven mvn -v (確認用)

ここまでで実行ができるようになります。 次にデバッグ関係の設定をしていきます。

メニューバー →「デバッグ」→ 「タスクの構成を開く」 すでにクラスが定義されているjavaファイルがあればaunch.jsonに自動で書き込まれているはずです。

{
            "type": "java",
            "name": "デバッグの種類を選択するときに表示する名前",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "console": "internalConsole",
            "stopOnEntry": false,
            "mainClass": "クラス名",
            "args": "",
            "projectName": "プロジェクトの名前(プロジェクト一番上のフォルダ名)"
        }

これで,画面左上の三角ボタンをクリックすると先ほど設定した"name"の一覧が表示され,対象を選択したらデバッグが始まるようになります。 src/ の配下に javaファイルを置けばうまく行きますが,他の場所に置く場合はまた別の設定が必要。これについては近々書こうと思います。

参考にした記事

Java開発環境をVisual Studio Code で整える | Solutionware開発ブログ

JAVA_HOMEについて

株式会社ビルディットでのサマーインターン

 

5月から2ヶ月半、株式会ビルディットのインターンシップに参加させていただきました!
株式会社ビルディット

圧倒的に成長したい

そもそも私がビルディットのインターンシップに参加したのは,学校での勉強だけで自分が技術者になれる気がしないと思ったことがきっかけです.学校で学ぶことは専門的な内容が多いですが,これが実際にどうサービスに活かされるのか,今まであまり実感がわきませんでした.実戦を通して今まで勉強したこととリークさせらたらと考えていました.
また理数系が好きで高専に入ったのですが入学後吹奏楽にどっぷりハマり,プログラムは授業でしか書いていませんでした.この差を取り返したい,という思いでした.

最初の面接

インターンで何をやるか社長の富田さんと相談. この時の私のプログラム歴が

C言語  ...2年半くらい(学校でやってた)
python  ...1ヵ月
ruby   ...2週間

ほぼC言語しか書いたことがなく,できることも具体的に
イメージできてない状態でかなり助言をもらったと思います.

もう一人のインターン生 

github.com

sakakendo0321.hatenablog.jp

同い年ですが彼はjavascriptpythonの技術スタックがありかなり助けられました. 彼もインターンのブログ書いてると思うので見てあげてくださいー

やったこと

本記事には技術的なことよりは,どうプロジェクトを進めていったかについて書いていこうと思います.

まず勉強

まずは4日ほど,会社の人に教えてもらいながらjavascriptの勉強.

↓使った教材
progate (公式HP)
nodeschool (公式HP)

 

Diggerプロジェクト

インターンの課題として,sakakendoとチームを組んでDiggerというサービスを製作しました.

リリースしたやつです.→Digger
簡単に説明すると、ツイッターからファボした投稿の分析をして興味のありそうな投稿を通知します.通知する投稿のフィルターには感情分析も使ったのでポジティブな投稿だけ見ることもできるようになっています.詳しくは新しく記事を書こうと思います.

プロジェクトの進め方

  1. プレスリリースとインセプションデッキを書く
    誰のために作るのか、どんな機能があるか書きます. 難しかったのが,やらないことを決めるところですね.本当に欲しい機能が何なのか考えるきっかけになりました. 2ヶ月半の中でもこれを見返すと方向性がずれてることがあったので優先順位の指針にしたり軌道修正 ができたり後々にも役立ちました.これは学校でやる開発でも書くようにするべきだと思います.

  2. 1日の終わりに進捗と明日のタスクを共有
    これは優先順位が二人でずれてきたと感じて途中から足しました. ここで分担を細かく調整したりしていました. 全体的にsakakendoは環境構築や全体設計,私は分析系と個々の機能実装をすることが多かったです.

  3. スプリントを切る
    プロジェクトを進める時の小さな区切りをスプリントと呼ぶらしいです. 今回はだいたい一週間ごとにスプリントを切って, 最初に次のスプリントまでのタスクを考えます. 終わった後の振り返りでは Keep, Problem, Tly を書き出しました. 最初はあーなんか学校のレポートみたいだなと思っていたのですが,例えばgithubのissueの粒度について言及するところなど,目をつけるところが違いました.

  4. 必須な機能を明確にする
    これはリリースの前にやったことです.改めて残タスクをみると,これ必須ではないなーと思う機能がかなりありました...

  5. 成果発表
    digger-1 最後に社内プレゼンという形でどんなものを作ったか発表しました. 質疑応答ではもっと良い分析の仕方や,サービスの使いかたの広がりなど,前向きな意見をいただきました.

得られたこと

細かいスパンで振り返りと進め方の見直しをしていたので、前に自分が書いた振り返りを読んでみるとかなり変わっていて成長を実感できました. 例えば,issueの開始条件と終了条件が曖昧になって一回のプルリクエストでの変更にまとまりがなくなったことがあり,特にissueをどう作るかはインターンの前と後で大きく変わりました. が,まだまだ自分が納得のいく粒度で作るのは難しいです..

サーチ力に関しても,ビルディットの方々やsakakendoが何か調べるときにどういうプロセスを踏むのか盗もうとしてるんですが,なかなかものにできないですね. 英語のドキュメントの苦手意識は軽減しましたが調べる力をもっとつけたいです.

他には環境の統一の仕方を色々試してみたり,チーム開発をしたことも良い経験になったと思います. ビルディットの人たちに機能や設計、デザインなど色々な方面からアドバイスを貰えたことで知見を広められ,考え方も変わりました.

終わりに

インターンでの課題はひと段落しましたが,その中でこれもっと深くやりたいなあと思うことがたくさん出てきて,それにとりかかるのが楽しくもあります. ビルディットの方々は,忙しいのにも関わらず個々のレベルに合わせて丁寧に説明してくださるので質問しやすい良い環境なのが素直にすごいなあと思います.

今後はアルバイトとしてビルディットで働かせてもらえることになりました. 足りないところが山ほどあるので,早く戦力になれるように勉強します.


この夏,本当に良い経験ができました. ビルディットの方々とsakakendo,ありがとうございました!