Reactの勉強がてらチュートリアルのコードを読んだ

kyokomi.hatenablog.com こちらのサイトも参考にしました。

同時に github.com も確認しました。

React全然わからない状態でとりあえず動かしてみよう！と思って、 ブログの方のコードを書きながら動きを理解してました(特にReact的なところはない)。

React部分はすでに書いてあるんだろう、と思って

$ go run main.go

を実行しました。

localhost:8000に接続して確認してみたところ… f:id:tdall12:20171230064508p:plain …そのままじゃ動きませんでした！( ^ω^ )

あれぇぇぇえ、api/commentsってPathどっから出てきたんだ？状態。

ずーっとgoのコードとにらめっこしてました(３０分くらいにらめっこ)。 どうみても、これで動くはずなんだ！と思っていたので… 禁忌事項”コピペ”をやってみました。→動かない(｀・ω・´)

ここで、もしかして：Reactの方に違いがある？？？と思い、Reactのコード読みました。

ReactDOM.render(
  <CommentBox url="/api/comments" pollInterval={2000} />,
  document.getElementById('content')
);

あったああああああ。

ここでした。 これを、jsonになるように、

ReactDOM.render(
  <CommentBox url="/comments.json" pollInterval={2000} />,
  document.getElementById('content')
);

に変更して、再度実行です。 f:id:tdall12:20171230065707p:plain ちゃんと送信できました！

要素検証したら、なんやら、まだエラー出てましたが、当初の目的は達成しましたので、OKとします。 エラー内容はこちら。

Warning: Each child in an array or iterator should have a unique "key" prop. Check the render method of `CommentList`. See https://fb.me/react-warning-keys for more information.
    in Comment (created by CommentList)
    in CommentList (created by CommentBox)
    in div (created by CommentBox)
    in CommentBox

もっとReactに詳しくなったら、このエラーも解消します。

お疲れ様でした！

Laravelはじめました

備忘録 PHP

qiita.com

こちらの記事を参考に進めていました． しかし，最後のところまで言っても，Not Foundから逃れることができませんでした...

# php artisan --version
Could not open input file: artisan

と出ますね．

ということで最初からやり直しました． .envとdocker-compose.ymlの編集をします．

# ./.env
APPLICATION=../laravel
# 略
# nginxの起動ポートの指定
NGINX_HOST_HTTP_PORT=8080

# docker-compose.yml
applications:
  image: tianon/true
  volumes:
    - ${APPLICATION}:/var/www/laravel

$ cd ./nginx/sites
$ cp laravel.conf.example laravel.conf
$ vim laravel.conf

# server_nameを好きなものに変更
server_name laravel.test;
root /var/www/laravel/public;

sudo /etc/hostsのところに，127.0.0.1 laravel.testを追加することで名前解決できるようにする．

アプリケーションを動かしていく

$ docker-compose up -d workspace
## これは時間がかかる

$ docker-compose ps
## コンテナ名を確認
         Name                Command      State           Ports
-----------------------------------------------------------------------
laradock_applications_1   /true           Exit 0
laradock_workspace_1      /sbin/my_init   Up       0.0.0.0:2222->22/tcp

$ docker-compose exec workspace bash
${#} composer create-project laravel/laravel laravel --prefer-dist

${#} exit
$ docker-compose stop
docker-compose up -d nginx mysql
# 変更と再構築をする場合は↓↓
$ docker-compose up -d --build nginx mysql

http://laravel.test:8080に接続したら，無事成功画面出てきました〜〜 f:id:tdall12:20171225162531p:plain

いや〜長かった... 結局どこが悪かったんだ...

再インストールなどしたらうまくいったから，どっか間違ってたんだなぁ．

研究室にSlackを導入した話

こんにちは。

今年の4月に研究室に配属されてから正式な活動が始まりました。 それまではメールもしくは直接の会話で連絡を取っていたようです。

ソフトウェア系の研究室ということでどうしてもそこをもっと効率化させたいと思い、 思い切ってSlackの導入を提案しました。 導入を決めた僕だけでは、決行できないと考え、まずは先生に相談しました。 すると意外なことにすっと導入に賛成していただけました。 もちろん、Slackのメリットを伝えた上で、ですが。

なぜSlackなのか

もちろん、Slackですべてのことをこなすつもりはありません。 ケースバイケースでメールと使い分けて行くつもりです。その上で、なぜChatWorkとかではなくSlackなのか、という話ですが、 それは、「僕自身が使い慣れているから」です。 便利、というのもありますが、やはり1番の理由は使い慣れているからですね。 ツールを導入する上で誰かが全く知らないものを導入するのはリスキーで、時間と手間がかかります。

しかし、1人でも知っているツールならどうでしょうか。 導入するコストが格段に減りますよね。そういう理由から、導入しました。

Slackを導入した当初

Slackを導入したての時はなかなかSlackをみんな見ないんですよ笑 でも、重要な連絡をSlackでし始めると、みんな見始めるんですよね。 そうしたことを続けていると、「あれ、Slackって便利なんじゃないか」と思い始めてくるんですよ。 もう今では必須ツールになってますね笑

どう使っているか

こちらが現在のチャンネルです。

f:id:tdall12:20171206152944p:plain
Slackのチャンネル

全部は言いませんが、

  • wantedチャンネル：先生に新しい本とかお願いするときに使ってます。
  • Scheduleのチャンネル：その日の予定と、毎週月曜日になると、その週にある予定のサマリーを送ってくれます。
  • Shared：最新の記事とか共有したほうがいいなぁって思ってることとかを載せたりしてます。
  • コーヒーブレーク：Slack怖くないよ！ってことを伝えるために毎日何かしら呟いてます。←返信が来ない日もある。

基本は全体向けで連絡事項の時に使ってることが多かったりします。

さいごに

今ではもう、Slackのない研究室ライフは考えられませんね！

最初の記事

TDD 備忘録

最初の内容は何を書こうか，と考えてるうちに開設から結構時間が経ちました．
自分の備忘録として書くのでなんでもいいんだけど， 最初に変なの書くと，ずーっと変なの書きそうなので，最初だけでも真面目に書こうと思います！

それと，せっかくだから研究に関係していることを書こう．

今回は「テスト駆動開発」についてです．
発表のときもTDDを知らない人は少なくとも1人はいると思うので，その前のアウトプットとして...

テスト駆動開発(TDD)ってなんだ

ソフトウェア開発技法の一つです．
1. 実装を書く前に，失敗するユニットテストを書く
2. テストに成功するような最低限度のコードを書く
3. リファクタリング
というサイクルを回しながらソフトウェアを開発していきます．
また，テストを先に書いてコーディングをすすめることを「テストファースト」と呼びます．

なぜTDDを使うのか

テスト駆動開発では先程述べたように実装を書く前にテストを書きます．その後にテストに成功するコードを実際に書いていきます． 「もう実際に動くコードはできている」と想定しながら，テストを書くので， 動くものを呼び出して使うのに必要な最低限のコードをテストコードとして表現すればいい． テストコードができれば，テストと実装を繰り返すだけです． こうすることで，ほんとうに必要な実装だけを構築できるようになります． それに，実装が完成した段階でテストコードもすでに作成されているので，より良いソフトウェアが完成します．

これくらいなら背景の中で説明しても，時間は余るはず...