サカナ未遂

プログラミング、筋トレ、子育て

リーン・スタートアップを読んだ

ソニックガーデンの倉貫さんのブログが好きでよく読んでいてリーンスタートアップというものに興味を持ったのでエリック・リース著のリーン・スタートアップを読みました。

 

新しいことを始める場合に、成功させるために何をするべきか、どのようにすれば失敗する確率を下げることができるか、また失敗しても被害を最少にできるかなど、サブタイトルの通り、ムダのない企業プロセスについて書かれた本です。

 

顧客の本当に望むものを作るため、小さくはじめて検証しフィードバックをもらいながら製造していく。

そうして出来上がったものが本当に顧客の欲しいものであり、顧客が求めてないものは全て無駄な機能であり、時間とお金の無駄であると。

 

事業を進めるために、仮説を検証し、事業が成功しているかどうか定期的に調査し、正しければそのまま続け、誤っていれば方向転換(ピボット)を行うことが必要。

 

また色々な起業家たちの成功した背景を探り、そこから何が成功の秘訣になったかも書いてあります。

また成功談の裏にはそれより遥かに多い数の失敗した起業家たちがいることにも言及しています。

 

起業家だけでなく、社内での新しいプロジェクトを立ち上げる場合にも有効な手段だとも書かれています。

最初にガチガチに仕様と工数を決めてしまうウォーターフォールの開発に従事している自分としては、このような顧客ファーストな開発手法に憧れますね。

 

 

 

RubyでStruct.newを使って構造を包み隠す

今日読んでたオブジェクト指向設計実践ガイドでStruct.newについて学んだのでメモのつもりで記録しておきます。

以下のコードは時価総額を計算する簡単なものとします。

class MarketCapitalization
  attr_reader :data
  # 初期化
  def initialize(data)
    @data = data
  end

  # 時価総額計算
  def calc_market_capitalization
    data.collect do |cell|
      # 株価 * 株数
      cell[0].to_i * cell[1].to_i
    end
  end
end

# [0]に株価、[1]に株数とする
data = [[100,500],[200,1000],[300,320]]

mc = MarketCapitalization.new(data)
puts mc.calc_market_capitalization

このコードの場合、calc_market_capitalizationメソッドが、配列の構造を知っている前提になっているので、例えばdataの[0]に銘柄コードなどを差し込んだ場合、メソッド内の配列の要素数を変更する必要が出てきます。 メソッドが一つだけなら修正も容易ですが、このdataを多岐に渡って使用している場合、あちらこちらを修正する必要があります。

そこで、Struct.newを使い、以下のように修正します。

class MarketCapitalization
  attr_reader :stocks
  # 初期化
  def initialize(data)
    @stocks = stock_assign(data)
  end

  # 時価総額計算
  def calc_market_capitalization
    stocks.collect do |stock|
      # 株価 * 株数
      stock.price.to_i * stock.num.to_i
    end
  end

  StockInfo = Struct.new(:price,:num)
  def stock_assign(data)
    data.collect do |cell|
      StockInfo.new(cell[0],cell[1])
    end
  end
end

# [0]に株価、[1]に株数とする
data = [[100,500],[200,1000],[300,320]]

mc = MarketCapitalization.new(data)
puts mc.calc_market_capitalization

Structクラスを使い、stock_assignメソッドの中でArray配列をStruct配列に変換しています。 これによって、calc_market_capitalizationメソッドでは配列の要素数を気にすることはなくなりました。 dataの要素数が増えた場合、このstock_assignメソッドのみを修正すれば、他の処理に影響することはなくなります。

学びを結果に変えるアウトプット大全を読んだ

ブログを始めたものの、アプトプットが難しいと感じていたので(前にブログにも書きましたが)、樺沢紫苑さんの

学びを結果に変えるアウトプット大全 (Sanctuary books)

を読みました。

 

何か良いアウトプットするための教科書みたいなもは無いものかと探していて、この本を見つけました。

 

精神科医の先生が、自身の体験や論文などのエビデンスをもとに書いた、アウトプットの王道的なテクニックの本となります。

 

アウトプットが上手くなるにはとにかく続けることが大事。

また企画書の書き方、読書感想の書き方、日記の書き方など、それぞれケースごとに使えるテクニックを紹介してくれています。

 

とにかく実践すべきと思ったのは、アウトプットのスピードです。

インプットしたらすぐにアウトプットすることで脳に定着し、記憶として残るとのことです。

この本を参考に私ももっとアウトプットを増やし、質を高めて行こうと思いました。

 

VagrantでUbuntu操作してRailsアプリに接続する方法

ふとLinuxRailsアプリでも開発しようと思い、Linux環境を構築してみました。 Vagrantを使ってVM上にUbuntuを入れてみました。

VagrantFileにはローカル側のアプリとポートが被らないように

config.vm.network "forwarded_port", guest:8000, host: 8000↲

と記載しておきました。

Ubuntuで、Rubyなど諸々インストールし

rails new

でアプリを使って、

rails s --port=8000

としましたがローカル側からはいつもの Yay! You’re on Rails!が出てくれません。

色々調べると、どうやらIPアドレスの指定も必要だったので、

rails s -b 0.0.0.0 --port=8000

とオプションつけてやると動きました。

f:id:tera_chan3700:20181016211031p:plain

環境構築の類は、いつもハマるので備忘録です。 細かいVagrantとかの設定はまたいつか書きたいです。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版を読んだ

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版を読了しました。

 

前から読もうと思っていたのですが、紙は辞書並だし、電子媒体は固定フォーマットだったので二の足を踏んでいたのですが、9月の終わりころにリフロー版が出たので、即買いました。

 

通勤中に読んでいたのですが、3週間くらいかかりました。

またサンプルのコードがPHPで書かれているのですが、通勤中のため動かすことはなくとにかく読むことに徹しました。

 

SQLインジェクションXSSなどメジャーなものから、セッションを使った攻撃、OSコマンドインジェクションなど、ありとあらゆる攻撃についての解説とその対処法が記載されていました。

タイトル通りセキュリティについてを体系的に学べるため、Webアプリケーションを開発するなら一度は目を通す必要があると思われます。

 

ただ内容がとにかく多く、私は全てを暗記できるわけではないので、攻撃手法と概要はしっかり読み、対処法は流し読みし、必要になったら読み直そうと思います。

 

アウトプットの難しさ

アウトプットって難しくて悩みますね。

 

ブログを書くのもなかなか捗らない日々です。

 

プログラミングに関しても、勉強した技術とか、

今までの知見とか、もっと書いていけばいいのに、

他のブログで書いてある技術をここで書いてもしょうがなくね?

とか思うと、なかなか筆が進みません。

 

でも、結局自分のブログ何だし、新しい技術習得でつまづいたところを、メモのように残していけば、いつか自分の役に立つのでやはり何かしら書いて行こうと思う今日この頃。

 

Ruby on Railsについて、もっとスキルアップを望むべく、

7月よりポテパンキャンプというプログラミングスクールに通っています。

(通ってるっていうかほぼオンラインで、週一にレビュー会)

3ヶ月間のスクールなので、あと1週間で終了となります。

スクールの内容に関しては別の機会にブログに書こうと思います。

 

で、スクールも終わりなので、そろそろ本格的に転職活動を開始します。

スクールからも紹介してもらえるらしいし、自分でも転職エージェントに登録し

探し始めています。

来年までには、良い会社を見つけたいと思います。

 

最近読んだ本では独習Gitがよかったです。 

githubではなくgitの本です。githubのことも書いてますが)

独習Git

独習Git

 

 git自体は何となくgithubからcloneして、commitしてpushして使ってただけですが、

思った以上に沢山の便利な機能がありとても勉強になります。

※あぁ、この辺もちゃんとまとめてアウトプットしたい、、、読書感想苦手、、

 

次はRubyをもっと深く知るため

改訂2版 パーフェクトRuby

を読みます。(現在積読中)

 

 

 

gemの選定方法について

 

railsを使用していてgemを入れる時、どういう基準で選べばいいか悩んでいました。

今日は、勉強会であった、ある企業のCTOから教えてもらったgemの選定方法について書いていきます。

 

star数が100以上ある

まあこれは当然の指標だと思いますが、やはり人気があるかどうかはここを見ると思うのでまずはstarを見るとのことです。

 

contoributorsの数が20〜30以上ある

 外部から貢献する人数が多ければ、活発に修正、改良が行われてる可能性が高いため、最低でも20以上ある方が安心できるそうです。

 

Fork数が多くない

どれくらいが多いとするかを聞くのを失念していましたが、Forkが多いということは、gem自体に修正の余地があるのに対応されないため、各々がforkして修正している可能性が高いと取れるそうです。

 

Issuesが放置されいない

Issuesに対してキチンと対応していると、アクティブなgemと判断できるそうです。

 

最終更新が1年以内

モジュールの修正があまり古いと、やはり開発が止まって放置されている可能性が高いそうです。だいたい目安は1年以内に更新されているものを選びたいとのことです。

ただ、いい意味で枯れてて修正の余地のないものもあるので、ソースコードを読んで判断する必要があるとのこと。

 

ActiveRecordに対してモンキーパッチを当てていない

これをやっていたらまず避けるそうです。

確かに危険な匂いがしますね。

 

以上です。

また他のエンジニアにも聞いてみて、自分なりの基準を見つけたいと思います。