nikkie-ftnextの日記

イベントレポートや読書メモを発信

イベントレポート | (第91回)Python mini Hack-a-thon ~Django Girls Tutorial翻訳レビュー~ #pyhack

はじめに

いつも心は虹色に! nikkieです。
8/11はpyhackで翻訳レビュー進めてきました。
レビューもだいたい終わったということで、Django2.0.x系対応日本語版がつい先日ベータリリースされています。
https://tutorial.djangogirls.org/ja/

勉強会の概要

(第91回)Python mini Hack-a-thon - connpass

スプリントのゆるい版みたいな感じで各自自分でやりたいことを持ってきて、勝手に開発を進めています。参加費は無料です。 初めての方も常連さんもぜひご参加ください。

pyhackの特徴の一つは床枠だと思いますが、今回は机が増えていて、机がだいぶ行き渡っていた印象です。

取り組んだこと

Django Girls Tutorialの翻訳レビュー

DockerでDjangoを動かしてみて

Dockerを仮想環境の代わりに使えば、Pythonを入れなくてもDjangoが動く環境が作れると気づいたので、
Quickstart: Compose and Django | Docker Documentationを参考に試してみました。

Dockerfile(ブログのソースコードディレクトリに配置)

FROM python:3.6
ENV APP_DIR /code
EXPOSE 8000
RUN mkdir $APP_DIR
WORKDIR $APP_DIR
COPY requirements.txt $APP_DIR
RUN pip install --upgrade pip
RUN pip install -r requirements.txt

buildしてから
$ docker run -it -p 8000:8000 -v "$(pwd)":/code --rm django_girls:1.1 bash
(ブログのソースコードディレクトリをコンテナにマウント)
以降はdocker execでコンテナに接続してコマンド実行します。

まっさらな環境なので

  • migrate
  • createsuperuser

が必要。1回やるとsqliteのDBが作られるため、コンテナ再起動時は不要なようです。

コンテナ内でrunserverするときのポイントは0.0.0.0:8000指定でした。
python manage.py runserver 0.0.0.0:8000
Flaskの場合と同じなのかなと捉えています。参考:Flaskのサーバーはデフォルトだと公開されてない
これを忘れるとDockerfileで8000番ポートをEXPOSEしているにもかかわらず、ブラウザでアクセスできなくなってしまいます。

翻訳レビュー

手を動かしながら翻訳レビューを進めていきます。

CSSでカワイくしてから、テンプレート1を導入。
f:id:nikkie-ftnext:20180813233401p:plain

アプリケーションを拡張して、ブログ記事の詳細画面も追加。
f:id:nikkie-ftnext:20180813233518p:plain
公開していない記事についても詳細画面は確認できます。(URI直打ちでしか対応していませんが) f:id:nikkie-ftnext:20180813233552p:plain

ブログ詳細画面のURIの指定が1.11.x系ではr'^post/(?P<pk>[0-9]+)/$'正規表現のようだったのですが、
2.0.x系ではFlaskでも使われているような書き方('post/<int:pk>/')になっていました。
こんなところも変わっているんですねー。

原文を読んでの気づき

すごく共感できる箇所があったので紹介。こういうのに気付けたとき、翻訳面白いなって思います。

CSS(Bootstrap紹介)

But we don't want to start from scratch again, right? Once more, we'll use something that programmers released on the Internet for free. Reinventing the wheel is no fun, you know.

車輪の再発明(Reinventing the wheel)への言及がありました!
CSSを一から書くのは大変なので、Bootstrapを使いましょうという文脈です。
ただ、車輪の再発明という訳語は学習者に通じにくそうなので、わかりやすい訳にするのが難しい箇所ですね。。

404ページをカスタマイズしない

But it's not super important right now, so we will skip it.

「super importantじゃないから、今はやらない」に現れている最優先のものにだけ集中する姿勢がいいなと思います。
スクラムの考え方(優先度の高いプロダクトバックログアイテムから取り組む)に通じるんじゃないでしょうか。

他の方の取り組みから

グローバルスコープとローカルスコープについて

質問されて曖昧と気づいたので調べました。
pythonのグローバル変数覚書 · GitHub

  • 前提:jupyter notebook使用(事象の確認ではインタラクティブシェル使用)
  • 関数のローカルスコープで変数をタイポ(numのつもりがmun)
  • グローバルスコープでnumを定義してあったので関数は何事もなく動いた(グローバルスコープのnumを参照するので変数未定義扱いにはならない)

『退屈なことはPythonにやらせよう』の3章2を参照しました。

グローバル変数はローカルスコープから読むことができる
同じ名前のローカル変数とグローバル変数を使っても問題ない

今回はnumへの代入文がないためグローバル変数として扱われたと理解しました。
(関数内で代入していたらローカル変数として扱うそうです)

感想

夏山合宿以来1月ぶりでしたが、開発〜懇親会まで非常に楽しい時間でした。
PyConトークの準備をしている方が多い環境なので、自分も目指してみようと思えます。
(懇親会の席で「資産あるんじゃないですか?」と言っていただけて、「そうか、自分もトークできるかも」と思えました!)
1日ありがとうございました!


  1. テンプレートの{% block content %}ってRailsでいうところの<%= yield %>ですね。https://railstutorial.jp/chapters/static_pages?version=5.1#sec-layouts_and_embedded_ruby

  2. 英語版は公開されています:https://automatetheboringstuff.com/chapter3/

イベントレポート | お盆休み KubernetesとRancher講習+もくもく勉強会 #kujiraya

はじめに

いつも心は虹色に! nikkieです。
k8sのハンズオンに行ってきました。
Dockerを独学してdocker-composeでデプロイできるようにはなったのですが、
composeは本番環境向けではないと知ったので、コンテナの本番環境運用が知りたくて参加しました。

勉強会の概要

お盆休み KubernetesとRancher講習+もくもく勉強会 - connpass
上記リンクより抜粋。

普段なかなかDockerやKunernetesの勉強が追いついていない方、ぜひこの機会に初めの一歩を踏み出してください。
この勉強会では、コーチ(「コンテナ・ベース・オーケストレーション」の著者 cyberblack28 こと市川 豊)と共にハンズオン形式で学習していきます。難しいことは一先ずおいて、手を動かしてみましょう!
Rancherでkubernetesクラスタ構築、Guestbookアプリのデプロイ、Weavescopeによる可視化をやってみましょう!

講義部分の資料は先日のDevLOVEでの登壇をもとにされているそうです。

ハンズオンの資料はこちらです。
Introduction of Kubernetes & Rancher2.0

勉強会中にとったメモはこちらです。
scrapbox.io

ハンズオンでやったことを整理

Guestbookアプリをデプロイしました。1
f:id:nikkie-ftnext:20180812191539p:plain

  1. GCPで2台のVMインスタンスを立てる(rancher-server/rancher-host)
  2. 2台ともGCP コンソールからブラウザでSSH接続
  3. 2台ともDockerが使えるように設定(クライアント・サーバともにバージョンは 17.03.2-ce)
    • curl https://releases.rancher.com/install-docker/17.03.2.sh | sh
  4. rancher-serverの稼働(ブラウザからRancher UIにアクセスできるようにする)
    • sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
  5. ブラウザでRancher UIにアクセス
    • GCPコンソールで確認できるVM(rancher-server)の外部IPを使う
    • Chromeがおすすめ(Safariで試みたところ、安全でない扱いでアクセスできなかった)
    • ブラウザからadminユーザのパスワード設定
    • Helmカタログ有効化
  6. クラスタ構築: Rancher UIを操作してrancher-hostで実行するクラスタ構築用コマンドを生成する
    • Rancher UIにてコマンド(dockerコマンド)生成
      • CUSTOM選択
      • Node Roleにetcd, Control Planeを追加
      • GCPコンソールで確認できるrancher-host内部IP、外部IPを設定 f:id:nikkie-ftnext:20180812191632p:plain
    • rancher-host(ssh接続)にてクラスタ構築コマンド実行
    • クラスタ構築後、Rancher UIでクラスタの状況が確認できる
  7. カタログからweavescopeをデプロイ
    • Rancher UIからIngressを作る(外部からアクセスできるようにする) f:id:nikkie-ftnext:20180812191757p:plain
    • 生成されたURLからweavescopeの画面を確認できる
  8. Guestbookアプリケーションデプロイ
    • Rancher UIのクラスタから「Launch kubectl」
    • kubectl apply
      • 構成はredis-masterが1つ、slaveが2つ、frontendが3つ2
    • Rancher UIからIngressを作る(外部からアクセスできるようにする) f:id:nikkie-ftnext:20180812191832p:plain
      • Rancher UIで分けて表示されるのは、Ingress作成時のnamespaceを分けているためか

最終的な状態(Rancher UIのクラスタからLaunch kubectl)

> kubectl get nodes
NAME           STATUS    ROLES                      AGE       VERSION
rancher-host   Ready     controlplane,etcd,worker   53m       v1.10.5
> kubectl get services
NAME                                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
frontend                                   ClusterIP   10.43.70.55     <none>        80/TCP         41m
ingress-8f292af7be845e4b740a8e031deba7c7   NodePort    10.43.169.177   <none>        80:32513/TCP   38m
kubernetes                                 ClusterIP   10.43.0.1       <none>        443/TCP        54m
redis-master                               ClusterIP   10.43.157.208   <none>        6379/TCP       41m
redis-slave                                ClusterIP   10.43.90.210    <none>        6379/TCP       41m
> kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
frontend-5c548f4769-bhtvt       0/1       Pending   0          48m
frontend-5c548f4769-mzpdc       1/1       Running   0          48m
frontend-5c548f4769-nk7cw       0/1       Pending   0          48m
redis-master-55db5f7567-q25w6   1/1       Running   0          48m
redis-slave-584c66c5b5-8cv5r    1/1       Running   0          48m
redis-slave-584c66c5b5-rq8p6    1/1       Running   0          48m
>

weavescope3
Guestbookのページにアクセスがあると、frontendがslaveからデータ取得し、
f:id:nikkie-ftnext:20180812191900p:plain Guestbookに書き込まれるとflontend→master→slaveとデータが書き込まれる様子が確認できます。 f:id:nikkie-ftnext:20180812191917p:plain

k8sの用語に理解が追いついていないのですが、ハンズオンのケースのノードはrancher-hostと理解しました。
今回は1ノードだから1Pod(Pod=デプロイ単位。中には3種のコンテナ)
f:id:nikkie-ftnext:20180812192737p:plain

感想

k8sは難しそうというイメージでしたが、Rancherのおかげで一歩目を踏み出すことができました。GUIは偉大ですね。
これをベースに黄色本(『コンテナ・ベース・オーケストレーション』)や教えていただいたリンク(katacodaなど)で情報収集続けていきます。
ハンズオンを開催いただき、どうもありがとうございました!


  1. ハンズオンの後、インスタンスは全て削除しています。

  2. yamlファイルのreplicasを確認:https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/guestbook-all-in-one.yaml

  3. 「コンテナ構成をリアルタイム視覚化」するものだそうです。 http://pocketstudio.jp/log3/2015/07/14/weave-scope-container-visualization/

イベントレポート | 【サポーターズ勉強会】はじめての情報推薦 /「あなたにオススメ」の仕組みを理解しよう #spzcolab

はじめに

いつも心は虹色に! nikkieです。
8/10にレコメンドの勉強会に行ってきました。
レコメンドは今年はじめに前職の案件で独学で取り組みました。
もっとうまくやれたんじゃないかという思いがあるので、
レコメンド関連の勉強会で情報収集するようにしています。

勉強会の概要

【サポーターズ勉強会】はじめての情報推薦 /「あなたにオススメ」の仕組みを理解しよう - サポーターズCoLab

今や様々なサービス内で当たり前のように見られる
「おすすめ商品」や「おすすめユーザー」といった記述
この「おすすめ」のシステムを実現している情報推薦について
その概要についてお話しさせていただきます!

走り書きした勉強会メモ(scrapbox)はこちらです。
https://bit.ly/2MkDC4H
以下では、勉強会メモを抜粋し、自分の知識と合わせてまとめてみます。

情報推薦とは

経験からわからないものの中から選択しないといけないことがある。
例えば、彼女が映画を見たいと言ってきた(彼女は恋愛映画が好き)
選ばないといけないが知識がない。そんなときが推薦システムの出番

例: Amazon1

  • 特定ユーザの嗜好・好み
  • 商品に似ているもの・関連しているもの
  • レビュー文も推薦
  • 一般的に買われている商品や新着商品も推薦

推薦手法の分類・比較

今回焦点を当てる以下の2つ以外に
ポピュラリティ(人気順)やハイブリッドがある。

内容(コンテンツ)ベースフィルタリング

ユーザのプロファイルとアイテムの特徴を掛け合わせて推薦する

ユーザプロファイルの取得

  • 明示的獲得:ユーザに選択してもらう
    • 本を5段階評価2 例えば、SFばかり高評価のユーザ
  • 暗黙的獲得:ユーザに見えないところで取得されている
    • 買った、見た、お気に入り登録した 例えば、SFばかり買っていたらSFが好きとみなす

アイテムの特徴の取得

  • 本などの製品はジャンル、値段、発売年など
  • 音楽は音声解析3
  • 画像も解析した情報を使う

協調フィルタリング

他のユーザの行動履歴を利用して、好みが似ているユーザが選んだもの・好むものを推薦
本の内容はどうでもいい

「嗜好が似ている」=「似ている行動をとっている」
(本の購買行動が似ている=買った/買っていないが近い)

内容ベースと協調フィルタリングの比較

  • 協調フィルタリングが優れる
    • 多様性・セレンディピティ 「自分が知らないものを他の人が知っている」
    • ドメイン知識 アイテムの特徴のデータを持っていなくても推薦できる
  • 内容ベースフィルタリングが優れる
    • コールドスタート問題 新規ユーザのプロファイルから推薦できる
    • システムの利用者数 少人数でもOK
    • 被覆率(=推薦候補/全アイテム) 検索4できるので全アイテムが候補
    • 類似アイテム 色違い区別できる

協調フィルタリングの仕組み

メモリベース法(蓄積したデータを推薦に直接用いる)

  • 利用者間型:ユーザ間の類似度を使う
  • アイテム間型:アイテム同士の類似度5を使う

※事前に調べておいたデータの規則性を使う「モデルベース法」もある

利用者間型メモリベース協調フィルタリング

  1. 評価済みアイテムへの評価付け傾向が似ているユーザを見つける
    • ユーザ-アイテム評価値行列(列がアイテム、行がユーザ、値が評価値)
    • ピアソンの相関係数 甘口の評価者も入れば辛口の評価者がいることも考慮(各自の平均の評価を加味している)6
  2. 似ているユーザから評価値を予測
    • 各ユーザの評価値をそのまま使うのではなく、各ユーザの評価値の平均からどれだけ離れているかという値を使う
  3. 高い評価値であれば推薦する(低ければ推薦しない)

アイテム間型メモリベース協調フィルタリング

実際のサービスはアイテム数よりユーザ数が多い。
計算量を減らすため、現実にはアイテム間型が採用される。
似ているアイテムを予め計算する。

ユーザ-アイテム評価値行列を行で見るのがユーザ間型、アイテム間型は列で見る。
-> 評価値行列の転置を取って利用者間型と同様に扱うイメージ

感想

情報推薦の説明、簡潔で非常にわかりやすかったです。
独学の中で複雑に捉えすぎていた部分をシンプルに捉えなおす機会になりました!
今回の理解をもとに手を動かすなら夏山合宿で見つけたこのあたりかなと思います。
PySparkで協調フィルタリング

独学では協調フィルタリングを手を動かして理解しようとしました。
2018/03/10 Pythonもくもく自習室 #8 @ Rettyオフィス 成果発表:ユーザベースの協調フィルタリングの例を実装 · GitHub
Kamishima先生の資料が参考になりました。(今回の勉強会と重なる部分が多いという印象です)
GitHub - tkamishima/recsysdoc: Algorithms of Recommender Systems : A survey paper of recommender systems (written in Japanese)

また、参加者の方からもいろいろ教えていただきました。

  • RailsはTutorial(Twitterクローン)と並行して、GitLab(RailsOSS)のソースコードで実際の例を見るとよさそう
    • Rails Tutorialのロックインされる懸念を感じています。Twitterクローンが完璧に作れることよりもRailsを使える(使いこなせる)状態を私は目指しています
  • VueのNuxtはReactのNextに対応。(NextにインスパイアされてNuxtが出てきた)

レコメンドのわかりやすい講義が聞けただけでなく、他のエンジニアの方から刺激もいただきました。
皆さん、どうもありがとうございました!


  1. Amazonがあらゆるレコメンドを駆使しているという話は、『仕事ではじめる機械学習』の7章で読んだ記憶があります。

  2. 食べログは明示的獲得に該当しますね。

  3. Spotifyのレコメンドで使っていると読んだ記憶があります。Spotifyって機械学習をどう活用してるの?⇒元社員がQuoraで回答 | AI4U

  4. 検索も内容ベースフィルタリングというのは驚きでした。ほしいクエリと一致するものを表示するととらえられるそうです。

  5. これがアイテムの特徴による類似度ではなく、購買履歴から判定される類似度ということがポイントだと思います。

  6. 『情報推薦システム入門』 2章で読んだ記憶があります。

イベントレポート | カイゼン・ジャーニー 著者による本読みの会 第10話「完成の基準をチームであわせる」再放送 #kaizenJ

はじめに

いつも心は虹色に! nikkieです。
昨夜放送されたカイゼン・ジャーニー本読みの会10話の聴講メモです。

勉強会の概要

カイゼン・ジャーニー 著者による本読みの会 第10話「完成の基準をチームであわせる」再放送 - DevLOVE | Doorkeeper

「著者による本読みの会」では、著者2人がカイゼン・ジャーニーを1話ずつとりあげて、内容を解説したり、深掘りしたり、脱線したりします。

予定している内容
・第10話 「完成の基準をチームであわせる」
下記の公開収録イベントの再放送になります
07-12(木)再始動・公開収録イベント:カイゼン・ジャーニー 著者による本読みの会 第2部 第09話「一人からチームへ」と第10話「完成の基準をチームであわせる」

感想

この章は完成の定義と受け入れ条件の違いの理解になかなか苦労した章です。

改めて読むと、スプリントプランニングを経て、プロダクトバックログからスプリントバックログが作られるというわかりやすい図がありました。

「お客にとって」無駄なものを作らないんですね。
自分たちが作りたくないからドキュメントを作らないんじゃなくて、お客様が必要としていないから作らないという論理なんですね。

インクリメントを届けること(利用者のゴール)から逆算するという考え方、直近の業務に取り入れたらよさそうです。

音読のSiriさん、ナナサトじゃなくて七里(シチリ)さんでしたよ。

一人で読むだけじゃ気づいていなかったことに気づかされました。今回もありがとうございました。

本読みの会メモ

  • 元の9話を2つに分けて9話と10話
    • 9話後編は「バックログと格闘する」->10話「完成の基準をチームであわせる」
  • 「事前調査」スプリント01 どんなリスクがあるかわからないので、スプリントを開始する前にチームでやる
    • スプリント0はチームビルディングの目的も持つ
    • このあとのインセプションデッキなどもスプリント0でやる
  • 何を作ってもらうかは執筆中悩んだ
    • プロダクトについてはあまり説明したくない(本題と外れる)
    • 「品質管理ツール、地味やなー 笑」
    • このプロダクトにどんな機能があるかは著者も答えられない 笑
  • 失敗経験、リスクの経験から品質管理ツールの必要性がわかる2
  • 完成アイテムのイメージがついているとコンバートするだけなので簡単
    • イメージをつけるまでは霧の中。開発者とお客の間で洗練させる
    • お客にとって無駄なものを作りたくない」のがスクラム
  • 完成のイメージがついていないで思い出そうとしたのは、第1部の神戸橋さんのところ(<-おそらく4話。仕様を詰めきれていない問題)
  • イメージをつける=直近のプロダクトバックログは詳細化。数スプリント先は粗い
  • プランニング=スプリント計画会議でプロダクトバックログを作る

第1フェーズ=Whatのフェーズ

  • プロダクトバックログを濃く、優先順位を決める、Readyにする(=開発者が全力疾走できる)
  • 数スプリント先のプロダクトバックログをReadyにするために「リファインメント」
    • イベントではなくて「アクティビティ」なので、やらなくてもいい
    • バックロググルーミングとも呼ばれる(グルーミング=毛繕い)
  • 誰でも見える=透明性 確保するためにはアナログツールがおすすめ
    • 新井さん「付箋紙を使いましょう」
  • スプリントゴールを決める <- スクラムの練度が上がらないとできない
    • チームのゴールを簡潔に明確化
    • スプリント間でメリハリをつけたくなる
    • 新井さん「インクリメントを届けることが重要で、そこから逆算していく」

第2フェーズ=Howのフェーズ

  • 【気づき】Howのフェーズを経て最終的にスプリントバックログができる
  • どんな作業が発生するか、開発チームがタスクを洗い出していく
  • タスクを時間見積もり3
  • 市谷さん: 最大見積もりは6時間にしていた(8時間中使えるのが6時間)

    • 社内イベントでスクラムから離れることも加味する
    • 見積もりの最大の時間単位は人によっては4時間
  • スプリントボードはカイゼン・ジャーニーオリジナル。管理の仕方の例

    • リーンのカンバンとは違うということを伝えたかった

完成の定義と受け入れ条件

  • 混同しやすい概念
  • 完成の定義
    • スクラムガイドに結構書かれている
    • チェックリスト
      • チェックリストを満たすことを確認することで、手戻りを減らしたい
    • 全体的なこと 「ユニットテストをパス、ステージング環境でエラーなく動く」
  • 受け入れ条件

    • スクラムガイドにはあまり書いていない
    • 要件を満たしているか確認する
    • 項目ごとに定義される
    • 実際のところ定義しているか?
      • 新井さん「バックログに対する完成の定義に受け入れ条件も含めている」
    • プロダクトの領域によって、受け入れ条件がかっちり決められるか変わる
  • 江島:タスクを消化しているだけのチームという気づき システムの全体像が腹落ちしない

  • 「試行錯誤をしなくなると消化試合のように感じる」

メモは以上です。注釈は感想です。


  1. こんな手法があるのかと驚きました!たしかによさそうですし、今回の本読みの回の収穫です。

  2. 経験を重ねると品質管理ツールの必要性がわかるようになるという話、実体験から同意です。

  3. 認定スクラムマスター講習で案内されたポイント見積もりでないんですねー。私はポイント見積もり派です(バーンダウンチャート併用) 関連:フィボナッチ数でポイント見積もり https://scrum.esm.co.jp/blog/123/

イベントレポート | カイゼン・ジャーニー 著者による本読みの会 第09話「一人からチームへ」再放送 (7/21) #kaizenJ

はじめに

いつも心は虹色に! nikkieです。
今日の夜はカイゼン・ジャーニー本読みの会10話の放送ですね。
7月に放送された9話本読みの会のメモと感想を公開します。

勉強会の概要

カイゼン・ジャーニー 著者による本読みの会 第09話「一人からチームへ」再放送 - DevLOVE | Doorkeeper

「著者による本読みの会」では、著者2人がカイゼン・ジャーニーを1話ずつとりあげて、内容を解説したり、深掘りしたり、脱線したりします。

予定している内容
・第09話 「一人からチームへ」
下記の公開収録イベントの再放送になります
07-12(木)再始動・公開収録イベント:カイゼン・ジャーニー 著者による本読みの会 第2部 第09話「一人からチームへ」と第10話「完成の基準をチームであわせる」

感想

この章はスクラムについて学んだ章です。
改めて読むと、スクラムの基本が凝縮されているという印象です。(5つのイベント、3つの役割、3つの成果物)

今年の春、前職でアジャイルで開発することになり、私は『カイゼン・ジャーニー』を手に取りました。
最初は私も同僚もアジャイルスクラムの区別がつかない状態でしたが、2部を参考に職場にスクラムを導入していきました。

移動時間にSiriさんに音読してもらっていたのですが、
ツチハシじゃなくてドバシさん、サイホウじゃなくてニシカタさんでしたよ、Siriさん。。

間が空いたのでこのエントリで振り返って、今晩の10話の会に臨みます。

本読みの会メモ

  • 片瀬にはモデルがいる(同じようにしゃべる)
  • 神戸橋さんと改善に取り組んだが、チームでやることに慣れていないからダメでしたという立ち上がり
  • アジャイルサムライかスクラムブートキャンプ -> 「本のタイトルにスクラム」後者か 西村さん?1
  • 江島・蔵屋敷さんの信頼関係 無茶振りでも引き受ける
  • 西方さんは別のプロジェクト炎上で遅れてくる
    • 片瀬のアナザーストーリーに西方さんが登場。その後江島のところへ
  • (西村さん)スクラムマスターはジェダイ・マスターのようにとらえられると強すぎる。プロダクトオーナーと同様に役割にすぎない
  • 関西弁キャラ賛否両論
  • 解説は結構な期間標準語だったが、最後の最後でキャラに喋らせる解説になった。1つの段落の中で感情を込めたところを関西弁で、他は関西弁を薄くする
  • 図2-1: 当たり前と思っていたことだが、スクラムガイドには書いていなかった(カスタマイズ)
    • スクラムのことを調べ直した。スクラムガイドにはアジャイル開発の深みがあった
    • 「書くというアウトプットは自分たちの学びにもなる」
    • 丸の位置が等間隔だとおかしい。デイリースクラムは何回もある。デザイナーさんとの意思疎通の難しさ
    • 実はデザイナーさんとはFace to Faceで進められていない
    • リファインメントが書いてあるが、説明が少ない(先の章)
  • 理論と精神: 透明性、検査、適応 イベントに取り込まれている
  • カイゼン」どこからカタカナにするか悩んだ。カタカナ表記は日本語としては一般的ではない(-> KPT本!2)
  • 経験主義
    • やったことないからできないはスクラムでは通用しない。わからないからこそやってみて次に活かす
    • 計画を否定しているわけでもない。計画できることは計画したい。計画が頭でっかちになって進まないなら経験主義で
    • やる前にやめるように言うのではなく、やってみて振り返る機会を提供するのがスクラムマスターやアジャイルコーチの仕事(あえて失敗させるという選択もある)
    • スクラムマスターはプロジェクトマネージャーとは違う。プロジェクトマネージャーはチームが転ばないように先にリスクを排除。スクラムマスターはチームが転んでもよいという姿勢
  • ウォーターフォールスクラムはVSという関係ではない
  • スクラムは開発工程の管理(プロジェクトマネジメントの手段)だけではない。人の感情面に焦点を当てる -> 「疲弊しきっているプロジェクトを救う」(新井さん)
  • スプリントの長さ
    • スクラムガイドでは「1ヶ月以下」
    • 新井さんは2週間or1週間。早く失敗する。
    • 市谷さんは1週間
  • スクラムチームにリーダーは存在しない。リーダーは日本の現場の話(この会社ではリーダーが必要)
  • チーム内ではリーダーはスクラムマスターという位置づけ。スクラムをチームに導入する江島がリーダー
  • 9話と10話は最初は一緒だった。長かったので分割

  1. SCRUM BOOT CAMP THE BOOKの著者 西村 直人 さんと思われます

  2. カイゼン・ジャーニーでも参照されている『これだけ!KPT』には「漢字の『改善』は、単発の改善、カタカナの『カイゼン』は、継続的な改善と捉えているのです」という一文があり(p.48)、なるほどと思いました。

週末ログ | Rails ActiveAdmin の素振りと Django Girls Tutorial 翻訳レビュー

はじめに

いつも心は虹色に! nikkieです。
8/4-5に手を動かした内容をまとめておきます。

取り組んだこと

  • Railsで管理者機能に使われるgem ActiveAdminを触る(8/4)
  • Django Girls Tutorial 翻訳のレビュー(8/5)

ActiveAdminを触る

業務で取り組んでいるRailsは経験が少ないので、手を動かして経験値をためていこうと考えています。
以下のQiita記事を参考にActiveAdminを触ってみました。
Railsで最速で管理画面を作る!

Authorの管理まで進みました。
https://github.com/ftnext/rails_active_admin_practice
こんな簡単に管理画面作れるなんて。。1

  • 開発環境ではseeds.rbに用意されたAdminを使う
  • モデル作成時に入力する属性をpermit_paramsに指定しないと、管理画面からデータの作成ができない

ActiveAdminはGitHubのドキュメントが充実しているようなので、そちらも確認していきたいです。
activeadmin/docs at master · activeadmin/activeadmin · GitHub

Django Girls Tutorial 翻訳レビュー

ブログポストをテンプレートに渡して表示するところ(Django templates · Django Girls Tutorial)まで手を動かして確認しました。
GitHub - ftnext/my-first-blog: Repository for Django Girls Tutorial
文の訳としては適切と思っていた訳が、手を動かす中で混乱を招くと気づき、いくつか修正提案をしました。

PythonAnywhereにも慣れてきました。
Bashを立ち上げた後、以下のようにするとよさそうです。

  • 仮想環境の起動: source .virtualenvs/$USER.pythonanywhere.com/bin/activate
  • GitHubのコードのあるディレクトリへの移動: cd $USER.pythonanywhere.com2

今回手を動かした箇所は以下のとおりです。

  • Djangoのバージョンの指定の仕方が変わったようなので対応
    • Django~=2.0.6と2.0.x系の最新を指定していた3ので、upgradeしました。
    • PythonAnywhereではソースコードgit pullで最新にした後、以下のコマンドを実行
      • pip install --upgrade -r requirements.txt
      • 前提1: 仮想環境を起動している
      • 前提2: ソースコードをおいたフォルダ/home/$USER/$USER.pythonanywhere.comにいる
    • PythonAnywhereってローカルの仮想環境と同じように扱えるのでいいですね。(AzureのWebAppsは経験少ないWindows OSなので、PythonAnywhereほど自在に扱えません)
  • 静的なページを作ってデプロイ Introduction to HTML · Django Girls Tutorial f:id:nikkie-ftnext:20180805231023p:plain
  • 動的なページに変えてデプロイ(DBからポストを取得する) Django templates · Django Girls Tutorial f:id:nikkie-ftnext:20180805230945p:plain

もとの英文側の問題?

Django URLsのソースコード(mysite/urls.py)が、2.0.x系のDjangoで生成されたものとは違うようです。 https://tutorial.djangogirls.org/en/django_urls/#how-do-urls-work-in-django

from django.urls import path, include
from django.contrib import admin

urlpatterns = [
    path('admin/', admin.site.urls),
]

2.0.x系で作られたmysite/urls.py4

from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]

Django urls · Django Girls Tutorialと違うのはdjango.urlsからincludeimportしていないことです。
urlpatternsのリストにpath('', include('blog.urls')),を追加するだけでなくincludeimportする必要があります

git push -u origin master5の-uの意味

気になっていたので少し調べました。
【Git】リモートにブランチを push してそのままトラックする

"git push" に "-u" あるいは "--set-upstream" を付けると、push 先のブランチをトラック (デフォルトで push や pull の対象に) するように設定されます。

なるほど。道理で初回だけgit push -u origin masterと-uをつけていて、後はgit pushだけだったんですね〜。
ProGitのサイトでもう少し詳しい説明探してみよう(宿題事項)

以上です。
そして次の1週間が始まるのです。

退職エントリ | 新卒入社した受託開発の会社を2年で転職して、自社サービス開発に従事します

はじめに

いつも心は虹色に! nikkieです。
月初からお騒がせして大変恐縮ですが、本日より新しい職場に移ります。

何が変わるか

  • 前職: 受託開発の会社でソフトウェア開発
    • Webアプリ(PHP)、モバイルアプリ(Swift、Kotlin)と広く浅く触る
    • 言語の縛りがなかったので、独学したPythonを2018年は業務利用できた(感謝!)
  • 今後: 自社サービスのソフトウェア開発
    • 直近はRails
    • ゆくゆくはフロントエンド(JS)も必要になるとのこと
    • Pythonは趣味に戻りそう

なぜ転職するか

一番の理由は「声がかかるはずがないと思っていた会社からお声がけいただいた」からです。

働いてみたいと強く思う会社ほど門前払いされるのを就職活動で繰り返しました。
その結果、自分が入社したいと思ってもやすやすと入れるものではないと思うようになりました。
そんな考えだったので、次の会社にそもそもお声がけいただけたことが嬉しく、
やろうとしていることやビジョンに共感して加わることを決めました。

次の環境は自分が一番下という環境ですので、
自身のスキルアップにつなげるチャンスと考えています。
声をかけていただいたということは期待していただけたということだと思うので、
早期にその期待に答えられるよう日々を積み重ねていきます。
Python関連の活動とのバランスの取り方が難しそうですが、いろいろ試してみます)

転職の背中を押してくれた言葉

「別にすごくないよ。ただがむしゃらにひたすら前に進んでた。やりたいことをやり続けていた。そして、気がつくとこの歳になってた。それだけさ。」
「目の前の面白そうなこと、必死にやってただけだよ」
「俺さ、自分の進む先が最初から見えてたわけじゃないんだ。気がつくと今ここにいる。それだけ」

振り返ってこう言えるような生き方をしたいと思います。
興味を持ったことをがむしゃらにやることを繰り返す生き方が理想です。

「チャンスにはドアノブがついていない。開いたら飛び込め」

お声がけいただいて扉開いたんだなと直感しました。
この言葉に飛び込む勇気もらいました。

いまだ全く不完全なころから、上手い人の中に交じって、けなされ笑われるにも恥じず、平然と押し通して稽古する人が、(略)最終的には名人の境地に到り、長所も伸び、人に認められて、ならびなき名を得る事である。

この部分はたしかTwitterで知りました。
まだまだ勉強中の身ですが、周りにどう思われてもがむしゃらにやるだけです。

終わりに

不安はないといえば嘘になりますが、折角のチャンスですし、がむしゃらにやってみます。
前職を1社目に選んだことに後悔は微塵もなく、数年後に同じことが言えるよう取り組みたいと思います。

退職エントリにはほしいものリストがセットだそうなので、
直近で読もうと思っている技術書リスト貼っておきます。
(読んでブログ書きます)
https://www.amazon.co.jp/gp/registry/wishlist/5SQ86XW6RTQB/

ここまでお読みいただきありがとうございました。
「それぞれの持ち場で頑張」りましょう(『カイゼン・ジャーニー』より)