ためすう

やったこと

Ruby で インスタンス変数へのアクセスについて調べます。

確認環境

$ ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin17]

調査

アクセサを自動的に定義するには、attr_accessor を使います。

test.rb

class Sample
  attr_accessor :hogehoge
end

s = Sample.new
s.hogehoge = 'init'

p s.hogehoge

出力結果

$ ruby test.rb
"init"

ちなみに

• 「参照するためのメソッド」だけを定義: attr_reader
• 「代入するメソッド」だけを定義: attr_writer

を使います。

参考

• パーフェクトRuby

やったこと

Ruby で singleton を使ってみます。

今回は用意されているライブラリを使います。

確認環境

$ ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin17]

調査

test.rb

require 'singleton'

class SingletonSample
  include Singleton

  attr_accessor :count

  def initialize
    @count = 0
  end
end

p 'obj1'
obj1 = SingletonSample.instance
puts obj1.count
obj1.count += 1
puts obj1.count

p 'obj2'
obj2 = SingletonSample.instance
puts obj2.count
obj2.count += 1
puts obj2.count

p 'id'
p obj1.object_id
p obj2.object_id

出力結果

$ ruby test.rb
"obj1"
0
1
"obj2"
1
2
"id"
70354869597880
70354869597880

参考

• シングルトンパターン(Singleton) | Ruby デザインパターン | 酒と涙とRubyとRailsと

「アジャイルソフトウェア開発の奥義」の読書メモです。

時々、個人の見解入りです。

この章は、XPの「計画ゲーム (planning game)」についてです。

流れ

• ユーザーストーリを洗い出す
• 相対的な見積もりをする
  • ある機能を1とした時、他の機能はどれくらいのボリュームとなるかを決める
• 「速度」を掴むため、1 ~ 2つのストーリーを試作してみる
  • かかる時間が見積れる
• イテレーションプランニング（たいていは2週間程度）
• タスクプランニング
  • ストーリーをタスクレベルに分割する

チームの全員が、何を成し遂げるべきか、いつそれを成し遂げるべきかを把握している。

同意。チーム単位でこれを把握していれば、遅れているタスクがあっても手伝ったりできる。

「速度」について

見積もるために「速度」という概念が必要。

これは、例えば1週間ごとにどれくらいこなしたかを実測値として取り、将来の計画も決めていく。

個人的に思うこと

プロジェクトを進める中で予期せぬことはよく発生すると思いますが、

主にその予期せぬことは下記2つの問題に分けられると考えています。

• 技術的課題
• 仕様的課題 (既存システムに組み込むという観点、法律の観点など)

最初のうちに気付ければ良いのですが、気付けなかった場合、計画立て直しになるので、

プロジェクト着手前には慎重に検討したいところです。

Exploratory Data Analysis

学習目標

• Describe the major visualization tools
• Generate hypotheses about data
• Inspect the data and find golden features
• Examine and analyze various plots and other data visualizations

Dataset cleaning and other things to check

• データセットクリーニング

  • 一定の特徴
  • 重複している特徴

• 他にチェックすること

  • 重複レコード
  • データセットがシャッフルされているかどうか

コンペの主催者はデータの一部を提供する（全部ではない）

traintest.nunique(axis=1) == 1

• サンプリングが原因で、全てのデータ（訓練データ、テストデータ）で同じものを取ることがある

特徴の重複

traintest.T.drop_duplicates()

※ 関数はビデオに出てたものを写経しました。動作は確認していません。

参考

• How to Win a Data Science Competition: Learn from Top Kagglers | Coursera

Exploratory Data Analysis

学習目標

• Describe the major visualization tools
• Generate hypotheses about data
• Inspect the data and find golden features
• Examine and analyze various plots and other data visualizations

Visualizations

• 個別の特徴を探索する
  • ヒストグラム
  • プロット
  • 統計
• 特徴の関連を探索する
  • 散布図
  • 相関プロット
  • プロット (インデックスと特徴の統計)

個別の特徴を探索する

ヒストグラム

plt.hist(x)

プロット

plt.plot(x, '.')

散布図

plt.scatter(range(len(x)), x, c=y)

統計値

df.describe()
x.mean()
x.var()

x.value_count()
x.isnull()

特徴の関連を探索する

単一の特徴で結論を出すのが難しいことが分かる

散布図

plt.scatter(x1, x2)

pd.scatter_matrix(df)

df.corr(), plt.matshow(...)

df.mean().plt(style='.')
df.mean().sort_values().plt(style='.')

※ 関数はビデオに出てたものを写経しました。動作は確認していません。

参考

• How to Win a Data Science Competition: Learn from Top Kagglers | Coursera

Exploratory Data Analysis

学習目標

• Describe the major visualization tools
• Generate hypotheses about data
• Inspect the data and find golden features
• Examine and analyze various plots and other data visualizations

Exploring anonymized data

明らかにしたくない情報などを内容が分からないようにしていることがある。

データはデコード、匿名化解除することができる場合がある。

• 個別の特徴を探索する

  • カラムの意味を推測する
  • カラムの種類を推測する

• 特徴の関連を探索する

  • ペアの関連を見つける
  • 特徴のグループを見つける

役に立つ関数 (Pandas)

-- データの型を予測
df.dtypes

df.info()

-- 値ごとのカウント
x.value_counts()

-- nullかどうかをチェック
x.isnull()

参考

• How to Win a Data Science Competition: Learn from Top Kagglers | Coursera

Exploratory Data Analysis

学習目標

• Describe the major visualization tools
• Generate hypotheses about data
• Inspect the data and find golden features
• Examine and analyze various plots and other data visualizations

Building intuition about the data

• ドメイン知識の取得
  • 深く問題を理解するのに役立つ
• データが直感的に分かるかどうか
  • データがドメイン知識と一致するかどうか
• データがどのように作られたかを理解する
  • 適切なバリデーションを設定することは大切

何を予測するのか、持っているデータは何か、問題に対してどのようにアプローチするかを理解すること

データのカラムの意味を理解する

訓練データ、テストデータに偏りがあると、モデルの適切な評価ができないので注意する

参考

• How to Win a Data Science Competition: Learn from Top Kagglers | Coursera

Exploratory Data Analysis

学習目標

• Describe the major visualization tools
• Generate hypotheses about data
• Inspect the data and find golden features
• Examine and analyze various plots and other data visualizations

Exploratory data analysis

EDA って何？

データを分析すること。

EDAで必要なこと

• データをよく理解すること
• データについての直感を構築する
• 仮説を立てる
• 洞察する

コンペで提供されるデータは、匿名化、暗号化、前処理、難読化されていることがある

リーク

コンペの主催者がデータ準備中の誤り。

まとめ

コンペを始めるときは、モデルを構築する前にEDAからやった方が良い。

参考

• How to Win a Data Science Competition: Learn from Top Kagglers | Coursera

「アジャイルソフトウェア開発の奥義」の読書メモです。

時々、個人の見解入りです。

エクストリームプログラミング (XP) とは

シンプルかつ具体的なプラクティスの集合から構築されているアジャイル開発プロセスである。

実践

実践法について書かれていました。

全部を満たす必要はない（できない）と思ったのと、状況に応じてカスタマイズしていった方が良いと思います。

チームメンバーとしての顧客

XPチームにとっての顧客とは、仕様の定義とその優先順位の決定権を持つ個人またはグループである。

物理的な距離も近い方が理想とのことです。

確認がすぐ出来るので、同意。

ユーザーストーリー

機能として入れるかどうかを検討できるため、同意。

短期間のリリースサイクル

おそらくここでいうリリースは、プロジェクトの成果物としてという意味だと思います。

運用されているサービスにリリースするということではないと思います。

受け入れテスト

本では顧客が提示とあるが、現実的にはエンジニアが顧客と共通認識を持つことになるのかなと思います。

ペアプログラミング

相談しながらやるという意味で同意。

ただ数時間もやる必要性は感じません。

テストファーストの開発

理想だと思いますが、実現できている組織はどれくらいあるのか気になります。

個人的にはユニットテストは、設計のセルフチェックの比重が大きいと思います。

（組織の状況によって変わると思います）

共同所有権

情報を共有するという意味で、同意。

継続的なインテグレーション(統合)

組織がどんなアーキテクチャを使っているかによりそうです。

ちなみには本ではビルド必要そうな言語想定かもしれません。

持続可能なペース

同意。

オープンワークスペース

他のペアの会話も聞こえる程度の環境の方が、作業効率が2倍になる研究もあるようです。

計画ゲーム

特に書くことなし。

シンプルな設計

不具合を発生させる可能性を低くするなら、構造をシンプルに保ち続けるという意味で同意。

• 何とか動くだけの最もシンプルなものを考えよう。
• あとで必要になんてならないよ。
• 同じことは2度しない。

冗長性をなくす最善の方法は、アブストラクション（抽象化）を使うことである。

リファクタリング

コードはすぐに劣化していく。

コードを書いた当時と状況が変わるためだと思います。

リファクタリングは常に考える必要がありますが、作業ボリュームとの相談が必要です。

メタファー

概念の定義（言葉の定義）が大切。

同じ言葉で共通認識を持っていれば、その言葉だけで伝わるので必要と思います。

「アジャイルソフトウェア開発の奥義」の読書メモです。

時々、個人の見解入りです。

アジャイルアライアンス宣言

プロセスやツールよりも、人と人同士の交流を重視する。

開発環境を整えるよりも、開発チームを形成することの方がずっと重要である

同意。開発チームがあれば、開発環境も整えられていきそうです。

包括的なドキュメントよりも、動作するソフトウェアを重視する。

システム全体を見渡すことができるような資料は必要だと思います。

仕様書となると、システムの変更に合わせて保守していく必要があるので難しそうです。

システム改修する -> 関連する資料修正する の資料に関しては、なくても良いものかもしれません。

資料 -> システム改修 に属する資料であれば、必要なものと言えそうです。

契約上の交渉よりも、顧客との協調を重視する。

成功の鍵は、顧客との密接な協調関係を築いたことと、コストや納期をがちがちに決めるような契約書ではなく、相互の協調関係について取り決めた契約書を用意したことにある。

システムの開発であれば、契約前、つまりシステムの開発前に全てを決め切ることは出来ないと思うので、この方針にした方が円滑に進みそうだと思います。

計画に従うことよりも、変化に対応することを重視する。

変更があることは頭に入れておく必要があり、計画と変化を天秤にかけた時、変化の方を優先せよという意味だと捉えました。

変化を優先するとは、ある目的、ゴールに向かって、変化を受け入れることだと思います。

原則

アジャイルアライアンス宣言で掲げている4つの価値を実現するために、以下の12の原則が導き出されました。

最優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する

物事の判断ポイントになるので、プロジェクトを進めていく上での土台になると思います。

要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応をすることで顧客の競争上の優位性を確保する。

これはよく分からないです。

実働可能なソフトウェアの納品を頻繁に行う。できるだけ短い時間で納品することを旨とし、数週間から数ヶ月間隔で納品する。

同意。

顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。

現実的に可能なのかわかりませんが、理想だとは思います。

自社サービスだったら、現実的だと思います。

やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。

同意。

開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。

基本的には同意。関わっている人数が多いときは、チャットなどで話しに参加していない人も見られるようにしておく必要があると思います。

実動するソフトウェアこそが進捗状況の尺度である。

同意。

持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。

同意。しかし、予測していないことは、どこかのタイミングで起こりがちなので、前倒しで進めておきたいという思いもあります。

高度な技術と優れた設計への配慮は、アジャイル性を高める。

開発スピードを保つ鍵は「品質である」

本の中では、あとで書き直すという考えは持たない方が良いという意味合いでした。

シンプルさが肝心 ー やらなくていいことはしない。

このやらないことを決めるというのは難しいのですが、リソースの制約がある以上、意識したいところです。

最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。

プロジェクトにコミットするという意味だと捉えました。

（どんな仕事にも言えそうですが）

チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。

改善策を考え続けろという意味だと捉えました。