ソニックガーデンのプログラマーの伊藤淳一さんのブログで、サイドバーにGitHubの草を載せた記事を読んで真似してみました。
とはいえ以前作ったゴミリポジトリがたくさん入ったアカウントとは別に、最近新しく作ったアカウントを載せたため、全然草が生えてない状態ですが、、、
だた公開したことで、もっとアウトプットしなくちゃという意識にもなるので、プログラムを書き続ける一つのモチベーションにもなります。
と言うことで、来年の今頃には草ボーボーになってるよう頑張ります。
最近発売され、話題になっていたエンジニアのためのマネジメントキャリアパスを読みました。
エンジニアとしてまだまだ技術的に未熟なので、ソフトウェアよりの勉強ばかりしているのですが、自分の年齢を考えたときに、マネジメントについても知見が必要になってくると思い、購入しました。
この本は、題名の通り、エンジニアのマネジメントキャリアパスについて書かれています。
メンターから始まりテックリード、人の管理、チームの管理、管理者の管理、経営幹部、文化構築と、各職責ごとにどのように振舞うべきかを教えてくれます。
あくまでエンジニアのキャリアパスであって、他の業種のマネジメントとは異なりとにかくどの職責でも技術に関しては、おざなりにしてはいけないことを強調しています。
特に印象的だったのはブリリアントジャークについてです。
ブリリアントジャークとは、
自己中心的で周りから恐れと嫌悪の入り混じった気持ちを抱かせる。
技術力は高いがそれにしがみつき、技術力以外は認めない
仕事はできるのでやめさせるのは至難
こう言うエンジニアってたまにいる気がしますね。
これの解決策は、第一に雇わないこと、だそうです。
(しっかり対応策も書いてありますよ)
なかなかのボリュームなので、全部読むのはそれなりに時間もかかりましたが、とにかくマネジメントは最初から誰でもできることではなく、向上させる必要があることがわかりました。いきなりできる人なんでそりゃいませんよね。
とても実践的な内容が書かれているため、昇進することがあれば、また読むことになりそうです。
最近、試してみたい技術が多くなってきて収集がつかなくなってきました。
積読本も多く、消化しなくちゃと思いつつ、良さそうな本があれば買ってしまします。
今はRubyとRuby on Railsを中心に勉強していますが、フロントエンドも面白そうなのでTypeScriptとReactも少しずつ勉強しています。
Reactの次はVue.jsもやりたいし、またGoはこれからも需要が伸びるはずなのでそろそろやりたいと思いつつ、DockerやAWSLamda、Firebaseなども押さえておきたいと思う今日この頃。(CIツールやwebpackもまだまだ未着手)
時間がいくらあっても足りないです。
ウチは妻もフルタイムで働いているため、家事は折半しています。
私の一日は
・朝5時半起床
・6時に子供を起こし、家族分の朝食を用意する。
・自分の昼食の弁当を作る
・子供を着替えさせ、保育園に送り出す。
・出勤
・17時半定時なので、18時半ころ帰宅(残業はほぼないためだいたいこの時間)
・子供をお風呂に入れる
・晩御飯作る(妻と半々)
・食器洗う(妻と半々)
・洗濯(妻と半々)
・子供の寝かしつけ(パパとじゃないと寝てくれない)
ちょっと家事が多い気が、、、、
まあこれ全部終わって、だいたい21時くらいから自分の時間になります。
起床が早いので23時半には寝たいので、だいたい2時間くらいがパソコンに向かえる時間となります。
で2時間あっても、妻と会話することもあるし、SNSみたりして、結構集中できない場合もあり、思うように進まないことが多いです。
そこでポモドーロテクニックを試してみることにしました。
ポモドーロテクニックは以下のサイトを参考にしました。
25分集中、休憩を繰り返すことで、短いダッシュを繰り返し生産性をあげるテクニックとのこと。
今週から始めてみたのですが、結構いいですね。
25分タイマーをセットし、その間は対象の勉強以外のことはしなよう意識するだけで集中力が上がるような気がします。
また今まで1〜2時間技術書読んでたりしてましたが、時間を区切ることで、25分で自分がだいたいどれくらい技術書を読めるのか、コードはどれくらい書けるのかわかるようになってきました。
なので、30分くらい暇があれば、どれくらい作業を進められるか感覚的に掴めるようになるので、簡単な工数見積もりの精度が上がるような気がします。
まずはこのテクニックを使い、1日に2つの技術書を読んでいくようにしています。
25分、2セットで1つの技術書を読んで、次の2セットで別の技術書を読む。
これで集中して2冊を進めていっています。
しばらくはこのまま進めてみようと思います。
ソニックガーデンの倉貫さんのブログが好きでよく読んでいてリーンスタートアップというものに興味を持ったのでエリック・リース著のリーン・スタートアップを読みました。
新しいことを始める場合に、成功させるために何をするべきか、どのようにすれば失敗する確率を下げることができるか、また失敗しても被害を最少にできるかなど、サブタイトルの通り、ムダのない企業プロセスについて書かれた本です。
顧客の本当に望むものを作るため、小さくはじめて検証しフィードバックをもらいながら製造していく。
そうして出来上がったものが本当に顧客の欲しいものであり、顧客が求めてないものは全て無駄な機能であり、時間とお金の無駄であると。
事業を進めるために、仮説を検証し、事業が成功しているかどうか定期的に調査し、正しければそのまま続け、誤っていれば方向転換(ピボット)を行うことが必要。
また色々な起業家たちの成功した背景を探り、そこから何が成功の秘訣になったかも書いてあります。
また成功談の裏にはそれより遥かに多い数の失敗した起業家たちがいることにも言及しています。
起業家だけでなく、社内での新しいプロジェクトを立ち上げる場合にも有効な手段だとも書かれています。
最初にガチガチに仕様と工数を決めてしまうウォーターフォールの開発に従事している自分としては、このような顧客ファーストな開発手法に憧れますね。
今日読んでたオブジェクト指向設計実践ガイドで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)
を読みました。
何か良いアウトプットするための教科書みたいなもは無いものかと探していて、この本を見つけました。
精神科医の先生が、自身の体験や論文などのエビデンスをもとに書いた、アウトプットの王道的なテクニックの本となります。
アウトプットが上手くなるにはとにかく続けることが大事。
また企画書の書き方、読書感想の書き方、日記の書き方など、それぞれケースごとに使えるテクニックを紹介してくれています。
とにかく実践すべきと思ったのは、アウトプットのスピードです。
インプットしたらすぐにアウトプットすることで脳に定着し、記憶として残るとのことです。
この本を参考に私ももっとアウトプットを増やし、質を高めて行こうと思いました。
ふとLinuxでRailsアプリでも開発しようと思い、Linux環境を構築してみました。 Vagrantを使ってVM上にUbuntuを入れてみました。
VagrantFileにはローカル側のアプリとポートが被らないように
config.vm.network "forwarded_port", guest:8000, host: 8000↲
と記載しておきました。
rails new
でアプリを使って、
rails s --port=8000
としましたがローカル側からはいつもの Yay! You’re on Rails!が出てくれません。
色々調べると、どうやらIPアドレスの指定も必要だったので、
rails s -b 0.0.0.0 --port=8000
とオプションつけてやると動きました。
環境構築の類は、いつもハマるので備忘録です。 細かいVagrantとかの設定はまたいつか書きたいです。