matobaの備忘録

育児しながら働くあるエンジニアの記録

アジャイルサムライをちょっと読みました。2

アジャイルサムライを読み進めました。

blog.mtb-production.info

読み進めて、メモを取っていました。今回もあとで見て思い出せるように少し整形してブログに書きます。

少しおさらいすると、前回のブログで、インセプションデッキの話が出てきました。

今回読んだ箇所には、その中身がもう少し書いてありました。

  • エレベーターピッチ
    • 30秒くらいでアイディアの本質を伝えられるようにする。
    • それをエレベーターピッチとよぶ。
    • エレベーターピッチの枠組みは本を見る
  • パッケージデザイン
    • 他の人が買いたいと思うかどうかを考えておく
    • 効能とかキャッチコピーとかを書く。
    • 詳しくは本を読む
  • やらないことリスト
    • やること、やらないこと、あとで決めること、に分ける。
    • やることに集中する効果がある。
    • プロジェクトの状況がわかるようになる。
  • ご近所さん
  • 問題
    • 成功のために必要だと思うもので足りないものは全て問題
  • 期間の見極め
    • 予測はあくまで予測。
    • 開発サイクルは、6ヶ月を超えないように調整。
  • 何を諦めるか。
    • スコープを諦めてもらう場合があると合意するのが大切
    • 何がどれだけ必要かを判断する人を探す
    • 何が、に相当するストーリーカードを作る
  • ストーリーカードとは
    • 実現したい未来が書いてあるカード
  • いいストーリーカード
    • ワクワクする。
    • 価値が書いてある。
    • エンドツーエンドになっている。
    • 6つの要素が独立している。詳細は本を。
  • ストーリー取集ワークショップ
    • たくさんの図と、たくさんのユーザーストーリー
    • 要求を書き出すより、要求について話し合うのが大切

音楽を作るときの音色の低音バランス

DTMトラック制作術って本を読んでる。

DTMトラック制作術 〜良い音の秘密はトラック数にあり

DTMトラック制作術 〜良い音の秘密はトラック数にあり

  • 作者:永野 光浩
  • 発売日: 2012/09/19
  • メディア: 単行本(ソフトカバー)

そのうち使えそうな話をメモする

  • 音色を選ぶとき、低音感がどれくらいあるのか、に注意して選ぶ。
  • 音源を仕上げていくとき、全体でどれくらいの低音感があるかを考えながら音色を選んだり、加工する。
  • 実際のミックスでは低音感の判断を素早くやる必要がある。ツールを使うのも1つの手だが、実際の現場では間に合わない。低音感を判断するスキルはあげた方が良い。
  • ベースとバスドラは片方の低音感を減らしつつ、もう片方と組み合わさってなることであたかも低音感があるように仕上げる

プログラミング教育の話を聞きました。(CoderDojo?)

BP-Study#122 でプログラミング教育の話を聞いてきました。

bpstudy.connpass.com

その中でもCoderDojoというのを初めて聞いて色々気になりました。 CoderDojoについて色々メモを取っていたので書きます。

CoderDojoについて

発表者

  • CoderDojo JAPANの代表 安川氏

CoderDojoはコミュニティ

  • CoderDojoはオープンソースコミュニティの人が中心のコミュニティ。
  • CoderDojoは子供とテクノロジーをキーワードにしている。
  • CoderDojoは大人も子供楽しんでいるというのが実情。

CoderDojoはどこにあるか

  • どんどん場所が日本全国で増えていて、今は106箇所の道場がある。
  • 日本だけではなく、海外でもある。ヨーロッパの方が多くて、400道場くらいある。
  • アメリカでも西海岸と東海岸でそれぞれ100道場くらいある。

CoderDojoへの支援

  • 国内外の企業からの支援を受けている。
  • 資金だけでなく、プロダクトをタダで使えるような支援をうけている。
    • 日本の企業だと、例えばさくらインターネット
    • 海外だと、オーストラリアのMagikcraft(jsのマインクラフトサーバー)

CodarDojoはどこから始まったか

CoderDojoの進め方

  • クラッチは一つのツール。
  • 子供が何をやりたいかを擦り合わせながらセッションを進めていく
  • カリキュラムが決まっているわけではない
  • ドリルがあるわけでもない。やりたいことから進めていく。

CoderDojoの開催について

  • 単発のワークショップではなくて、定期的に開催している。
  • いわゆるもくもく会のようなスタイルで、いろんな場所で出来上がっていく。
  • Dojoをみて、別の人がまたDojoを開いていく。

CoderDojoはなぜ続いているのか?

  • 正直、よくわからない。
  • 参加者はらくだし、人に聞くことができる。
  • 別のコミュニティの人たちと交流ができる。
  • とりあえず、大人も子供も楽しめているコミュニティ

CoderDojo 藤沢の話

発表者の向井アリーさんの自己紹介

  • 去年の12月からCoderDojo始めた。
  • 普段は、イラストレーターをしている。グッズを作っている。

CoderDojoについて

  • CoderDojoは助け合いの社会。
  • 藤沢でやるときに、調布のメンターが助けてくれる。
  • 現役のプログラマーやエンジニアが手伝ってくれるので、運営できている。

プログラミングは遊びか、学びか

  • 遊びでもあるし、学びでもある。
  • プログラミングは、楽しい。
    • すぐに答えが返って来るから
    • 問題を自分で解決できるから
    • シェアできるから
  • 親がそばにいない方がうまくいく
    • 親が指摘しすぎる。
    • 親が代わりにやってしまう。
    • 子供がやる気を失う。
  • 早い子は、小学校1年2年でキーボードを使ってプログラミングしている。
  • ichigojamとかラズパイとかマイクロビットは安く始められるのでいい

CoderDojoと教育行政

発表者

  • CoderDojo 柏の代表 宮島衣瑛氏
  • 高校1年からCoderDojoやってる
  • 大学生。会社も経営している。

CoderDojo 柏

  • 小学校から子供も教えていたりする。
  • 市内のどこでもプログラミングを学べるようにしようとしている。
  • 柏市に4つの道場をつくった。
  • 週末にだいたいどこかでやっているような状況になっている。

プログラミング教育を柏市と連携

  • 市内42の小学校でプログラミング教育をはじめた
  • カリキュラムの相談とかしている
  • 教育委員会と共催をさしてもらった。

CoderDojoと柏市の教育

  • あくまで学校の教育は、入門するところ
  • CoderDojoで学びを深めてほしい。

2020年に国の教育方針が変わる

  • 学校の中でクローズドな教育から社会を巻き込んだオープンな教育に変わっていく

子供すごい

  • 子供がスクラッチでマインクラフトを作っている。
    • マインクラフトをスクラッチで動かしているのではない
  • すごい

プログラマがたどり着いたプログラミングコミュニティ

発表者

  • マデールという会社をやっている土屋健一氏
  • CoderDojoで千葉の子供にプログラミング教育をしている

私とプログラミング

  • 35年くらい前にマイコンを買ってもらった
  • ベーマガで写経していた。
  • 写経はすごい
  • やりきった感がすごい
  • やってたらかけるようになる
  • いつの時代でも写経は大切

CoderDojoではなにをやっているのか

  • CoderDojo 市川でやっている
  • イベントで連携している
  • プレゼンとかワークショップしている
  • チュートリアルを写経している
  • サポートしたりアイディア出ししている

なぜ始めたのか

  • CoderDojoはなんでやっているのかわからないと思っていた
  • CoderDojoの他のコミュニティの人と話して、子供と大人で学び合える関係だとわかった。
  • モチベーションが湧いてきた。
  • 簡単に道場を開けてみた

始めて思うこと

  • モノが立地によって違う。(会場があるかどうか、とか)
  • Googleフォームで出欠管理している。
  • カネについては寄付とか。

はじめてうれしいこと

  • いろんな人が手伝ってくれる
  • 知り合いが増えて、スーパーで声をかけてもらえる
  • 終わった後の人も、きてもらえたりする
  • メンターさんと話を喜んでもらえる

やった方がいいこと

  • ミニマムでやる。
  • 小さい規模にしておいて、一人でできるようにする
  • 参加者の人と価値を確認する

感想

  • 全体的にCoderDojoの話は楽しそうでいいなあと思った。
    • プログラミングは、常に新しいことが出てくるから、常にいろんな世代の人が同じ目線で話をできるのがいいよなあと改めて思った。
    • 2年前にPyConJPで子供向けワークショップを企画したのを思い出した。そして技評に載せてもらったの思い出した。(そして探して久しぶりに見た)

gihyo.jp

  • プログラミングは、遊びか学びか、という話が気になった。個人的には、遊びと学びって分けなきゃいけないの?って思った。遊びながら学んだらいいんじゃないかなーと思った。

初めてのAnsibleプレイブック作成

先日、Ansibleに関するふわっとした理解を書きたした。

blog.mtb-production.info

今回は、Ansibleの簡単なプレイブックを作ってみました。

そもそも、Ansibleのチュートリアルは色々ネットに出てるんですけど、結局なんか長くて、気になることが多くてモヤモヤしてしまう感じがありました。

というわけで、とりあえず今の理解で、簡単にプレイブックを作ってみようと思います。

やることは以下のような感じ。

  • ansibleのクライアントはMac OS Xにする。(楽なので)
  • ansibleのサーバーは、vagrantで用意する。(楽なので)
  • ansibleでやることは、ユーザー作成だけにする。(とりあえず動かせることを確認したいので。)

まずは、Ansibleをインストールする。 そのために、venvでPythonのローカル環境を作って、pipでインストールしよう。

$ python3 -m venv ansible
$ . ansible/bin/activate
(ansible)$ pip install ansible
...(略)
Successfully installed MarkupSafe-1.0 PyYAML-3.12 ansible-2.4.0.0 asn1crypto-0.23.0 bcrypt-3.1.4 cffi-1.11.2 cryptography-2.1.1 idna-2.6 jinja2-2.9.6 paramiko-2.3.1 pyasn1-0.3.7 pycparser-2.18 pynacl-1.1.2 six-1.11.0
(ansible)$ ansible --version
ansible 2.4.0.0
  config file = None
  configured module search path = ['/Users/myuser/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/myuser/work/ansible/lib/python3.6/site-packages/ansible
  executable location = /Users/myuser/work/ansible/bin/ansible
  python version = 3.6.1 (default, Apr  4 2017, 09:40:21) [GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.38)]

なんかインストールできた様子。

よし、次に行こう。

vagrantで接続するサーバーを用意する。

(ansible) $ vagrant init ubuntu/trusty64
...略

(ansible) $ vagrant up
...略

(ansible) $ vagrant ssh
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)
...略

vagrant@vagrant-ubuntu-trusty-64:~$

とりあえず、構築するゲストOSが用意できた。

ここから、vagrantで立ち上げたゲストOSにsshで接続する。

まずは、vagrantで立ち上げたゲストOSにIPアドレスを付与するために、 Vagrantfile 設定を修正。(デフォルトの設定ファイルの中でコメントアウトされてるので解除する。)

config.vm.network "private_network", ip: "192.168.33.10"

そして、sshで接続するために、sshの設定を追記する。

~/.ssh/config に以下を追加した。 (鍵のパスは、 vagrant init したフォルダから見て .vagrant/machines/default/virtualbox/private_key にあったので、そこに通した)

Host 192.168.33.10
    IdentityFile /path/to/vagrant/private_key
    User vagrant

なお、設定はこの辺りを参考にさせてもらった。 VagrantでAnsibleのPlaybookを作るためのローカル環境を作る - Qiita

とりあえず、Ansibleで接続する前にターミナルからssh接続してみる。

$ ssh 192.168.33.10
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)

....
vagrant@vagrant-ubuntu-trusty-64:~$

接続できた。

次に、このゲストOSにansibleから接続できるようにする。 ansibleの場合、接続先は、inventryというファイルに書くらしいので、書いてみた。

(ansible) $ cat inventory
192.168.33.10

そのあと、Ansibleから疎通確認を行う。

(ansible) $ ansible all -i inventory -m ping
192.168.33.10 | SUCCESS => {
    "changed": false,
    "failed": false,
    "ping": "pong"
}

成功した様子。

よし。 プレイブックを作っていく。今回は、userを作りたいのでこのあたりを参考にする。

user - Manage user accounts — Ansible Documentation

ansibleのプレイブックの形式は、yamlというフォーマット。user.ymlを作った。

- hosts: all
  become: yes
  tasks:
    - name: make user
      user:
        name: sample_user

全てのホスト (hosts: all) で、sudo して(become)、sample_user を作るというymlのつもり。(少しこの辺りで試行錯誤した。)

これを実行する。

(ansible) $ ansible-playbook user.yml -i inventory

PLAY [all] *****************************************************************************************

TASK [Gathering Facts] *****************************************************************************
ok: [192.168.33.10]

TASK [make user] ***********************************************************************************
ok: [192.168.33.10]

PLAY RECAP *****************************************************************************************
192.168.33.10              : ok=2    changed=0    unreachable=0    failed=0

成功した様子。

ok=2 となっているのが気になる。 何回か試行錯誤してる中で、 ok=1 と出ている箇所もあるので、何かしらのOKの個数なのだと思うけど、何が2なのかは、わかっていない。

きちんとユーザができているか確認してみよう。

(ansible) $ vagrant ssh
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-110-generic x86_64)
....

vagrant@vagrant-ubuntu-trusty-64:~$ sudo su sample_user
sample_user@vagrant-ubuntu-trusty-64:/home/vagrant$

ユーザはできている様子だった。

とりあえず、Ansibleで動かすことができるようになった。 次は、もうちょっと詳しいことをやりたい。

アジャイルサムライをちょっと読みました。1

アジャイルサムライを読んでいます。

今のところは、全体の5分の一くらいを読み進めています。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

今回も本を読んでいて個人的に後で見返したいことを箇条書きで書き出しておきました。

以下に書いてある内容に気になることがあった人は、実際の本を読むといいと思います。

  • アジャイルの前提について
    • 完了とは、リリースして価値を届けること。作業を完了することではない。
    • 要求はプロジェクトの進行中に集めていくもの。
    • どうすれば要求を固定できるかではなく、どうすれば変化に対応できるか。
    • やるべきことは、常にリリースできることよりも多い。
    • やり方はたくさんあって、どれか一つを使えばいいという話ではない。
  • アジャイルなプロジェクト
    • 役割が曖昧であり、肩書きも役割も関係がない状態になっている。
    • チームが成果に責任を負っている。
    • すべての工程が途切れずに連続する
  • チームのアジャイル化について
    • 全員同じ仕事場に集めることはチームのアジャイル化を促進する
    • 顧客に積極的に関わってもらうことは、チームはアジャイル化を促進する
    • 顧客に積極的に関わってもらうために、問題を解決して、こまめに報告すること。
    • そして信頼の貯金を貯めること
  • アジャイルプロジェクトの役割
    • 役割に人を合わせるのではなく、人に役割を合わせていくこと。
    • チームメンバーにソフトウェアを顧客に説明させること
    • 役割分担は、ざっくりいうと「何を作るか決める人」と「どうやって作るか決める人」に分かれる
  • アジャイルプロジェクトを始めるにあたって
    • プロジェクトの最初の方で手強い質問をすること
    • 手強い質問をするために、インセプションデッキを構築すること
    • インセプションデッキは、プロジェクトがなんであるかを説明するものである。
    • インセプションデッキには、10個の課題がある

今日はここまで。

djangoでjsonのレスポンスを返す方法

djangojsonのレスポンスを返す方法を探した。

同じことを今後もググるように思うので、ここに書いておきます。

なお、djangoのバージョンは、1.11.6です。古いと、ちょっと違ったような。

views.py に以下のように書く。

from django.http.response import JsonResponse

def json_view(request):
    return JsonResponse({"key":"value"})

すると、以下のように結果が返る。

{"key":"value"}

便利ですねえ。

アジャイルプラクティスを読んで得た教訓

アジャイルプラクティスと言う本を読んだ。ザッと。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

この本、2007年の本なんですね。

開発方法論、プロセス、プラクティス、システムとか、戦術的な話に興味があります。 で、アジャイルプラクティスという本を読みました。

読んでいて、雑多に個人的なメモをとっていたので、あとで自分が見返すために文章に整形して書いておきます。

前置きですが、他の人が読むとわかりにくいかもしれません。

以下が個人的に本に書いてある達人開発者の習慣を読んで僕が得た教訓です。

  • 時間がかかっても正しいことをすること。
  • 古い習慣があることに気づくこと。また、習慣という理由で採用しないこと。ただし、古いという理由で不採用にしないこと。
  • 問題の根本を理解するまで質問すること。質問をする前に、その質問に意味のある根拠を考えておくこと。
  • 設計は様々な選択肢を考えて話し合う場であることを理解すること。やったことのないことを厳密に定義しても意味がないことに気づくこと。コーディングに入ったら設計は白紙に戻ったと考えること。
  • どんな設計になったか、どんな計画になったか、より、設計や計画をメンバーとともに行ったことが大切であることに気づくこと。
  • 必要になるまで実装しないこと。作る前からどう使うかを考えること。
  • 複雑さは、努力の成果ではないことに気付こう。良い設計は見ていて気持ちが安らぐものであることを知ろう。
  • コードは少しずつ書くこと。常にコーディングをきれいにできないか考えること。
  • オブジェクト指向は、オブジェクトに処理を命ずる、というのを理解すること。
  • アーキテクトもコーディングをすること。設計はコーディングの段階で成長していく。アーキテクトがコーディングしないというのは成長機会を失っていることに気付こう。
  • アーキテクトの仕事は、ソフトウェアから不可逆性を排除する方法を見つけて、アーキテクチャを取り除くということを理解すること
  • コードを共有するときは段取りがあることを理解しよう。まず、週単位や月単位にコミットするのはおかしい。コミットは意味のあるまとまりですること。
  • 人を責めても成果は出ないし、プロセスに従えば成果が出るわけでもないことに気付こう。そして、仕事は、人を責めることでもプロセスに従うことでもなく、成果をあげることであると気付こう。
  • 自分が学んだことをチームに共有しよう。チームの身の丈にあった方法で情報教諭しよう。ほんとうにパワポが必要かを考えよう。

よし、書いた。

2007年の本だし、ちょっと話が古いなと思う部分もあると思うけど書いた。

ここに書いてあることなんて当たり前でしょ。と思うように成長していきたい気持ち。