コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『セイチョウのための一歩 ブログ習慣化のあゆみ』という内容で登壇してきました。

Everyone Outputer#1 「ぼくのわたしのセイチョウ・ジャーニー」 で話してきたのでメモです。

発表したスライド

speakerdeck.com

まさにこのブログのことを喋ってきました。

スライド中のワード補遺編

スライドで引用風に説明していたワードたちをこちらでご紹介します。

基本的にはその日やってきたことを書く

自分はぼんやり始めたんですが、自分のやっていき方間違ってないかもなと自信的なものが割と明確に補強されたのが以下のカックさんの記事とスライド。

kakakakakku.hatenablog.com

中でも「業務のネタは書ける!」というのもここでだいぶ補強された

休み宣言

一回記事ににもしたけどRubyで有名な koic さんのブログが元ネタ

shinkufencer.hateblo.jp

本人にも補足されビビる

三日坊主を繰り返す

ドメイン駆動設計で有名な 増田さん の下記発表の一コマ

www.slideshare.net

三日坊主でよい、飽きたら別のことをやる。続かないことを卑下することはない。みんなできていない。 思いついたらいつでも再開すればよい、それでまた三日坊主でよい 三日坊主を繰り返せば、量が生み出せる。ある時、量が質になり、隠れた関係性が見える

スライドを見ないとピンと来ないワードもあるので、ぜひお時間ある方はご一読を。

Kata

元ネタは CodeKata

型は毎日やることでその動きを覚えられて、実践のときもとっさにそれが出せるとかの意味で使われる。

今回は毎日やることでそれが常態動作化するので、一念発起しなくてもスラスラできるようになるよ!!みたいな意図で使いました。

未来の自分のための外部記憶装置

上記取り上げた記事の中にも書いてあるカックさんのTweetが元ネタ

スライド作ってみて感想

  • イチョウジャーニーに触発されて、LTしたい!!!ってなったので応募したけど当日までいろいろと不安だらけだった
  • 忙殺されすぎてて全然書く時間がなかったのでもうちょいブラッシュアップすればよかった
  • Googleスライド内で絵文字を使ってみたがpdf化すると化ける。今度からいらすとやを使おうと思った。
  • いってきたメモは別口で書く予定です!

Google日本語入力で :bow: を出したいときは「ごめんなさい」で変換すると出る

「えもじ」から連打するの無理ゲーだと思っていたので、備忘録としてのメモ

環境

Google日本語入力のバージョンは以下

2.24.3250.1 f:id:shinkufencer:20181118175613p:plain

変換ワード

ビールとかケーキとかわかりやすいのを除き、使いそうでわからないやつを

絵文字 Slack上などでの表現 変換ワード
🙇 :bow: ごめんなさい
🙏 :pray: いのり
💪 :muscle: ちからこぶ

ちなみに😇( :innocent: )は見つからなかった…

参考リンク

【Google日本語入力】で出せるUnicode絵文字とひらがなの対応表 - パソコン修理のエヌシステムBLOG

都道府県のenumを保つ場合はJIS X 0401:1973 都道府県コードを使うと良い

そういや正式名称なんなんだろうっていうところでメモ

規格名

JIS X 0401:1973 都道府県コード

実データ

01:北海道
02:青森県
03:岩手県
04:宮城県
05:秋田県
06:山形県
07:福島県
08:茨城県
09:栃木県
10:群馬県
11:埼玉県
12:千葉県
13:東京都
14:神奈川県
15:新潟県
16:富山県
17:石川県
18:福井県
19:山梨県
20:長野県
21:岐阜県
22:静岡県
23:愛知県
24:三重県
25:滋賀県
26:京都府
27:大阪府
28:兵庫県
29:奈良県
30:和歌山県
31:鳥取県
32:島根県
33:岡山県
34:広島県
35:山口県
36:徳島県
37:香川県
38:愛媛県
39:高知県
40:福岡県
41:佐賀県
42:長崎県
43:熊本県
44:大分県
45:宮崎県
46:鹿児島県
47:沖縄県

補足

この規格はISO 3166-2地域コードにも採用されています(ISO 3166-2:JP)。 なお、関連する規格として、JIS X 0401との併用を想定したJIS X 0402:2010市区町村コード(3桁)もあります。 - JIS X 0401都道府県コード - CyberLibrarian

ということで他の規格にも使われたりしているが、市区町村系とはコード体系が微妙に違う

参考サイト

Rubyの文字列は * をつかって掛け算のように書くことで繰り返し生成ができるが、注意が必要

あ、そんなこともできるんだというトリビア感と同時に普通にバグが滑り込みそうと思ったのでメモ

環境

$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]

出典

文字列の内容を times 回だけ繰り返した新しい文字列を作成して返します。 -instance method String#* (Ruby 2.5.0)

"huga" * 3
# => "hugahugahuga"

"0" * 20
# => "00000000000000000000"

文字列ならもちろん変数でも動いてしまうので、期待値と沿わない変数名の付け方すると誤認するので気をつけたい

# 間違って価格を文字列で定義してしまう
price = "1000"
# => "1000"

# 消費税的な掛け算をしても反映されない
full_price = price * 1.08
# => "1000"

関連リンク

『Sansan Builders Box』に行ってきたよメモ

11/10にSansan Builders Box というイベントに行ってきたのでその時の行ってきたよメモです。

各発表の感想

3つにセッションが分かれていたので聞いてきたやつのみのメモです。


Keynote:Sharing Knowledge

たぶんスライド的なものはなさそう

感想

  • 今回のイベント経緯と知の共有という側面に関しての話
  • まつもとさんがゲスト公演参加
    • 知の共有ベースの話からOSSコミュニティに関して、そして共有地の悲劇OSSでは起きておらず、それ自体は奇跡であるので守っていくべき、という旨の話があった
  • イベントそのものの豪華さも相まって力の入れようが伺えるオープニングだった

関連リンク


EightにおけるAndroidのリアーキテクチャ

speakerdeck.com

感想

  • Androidアプリの改修の話
  • UseCaseがネットワークリクエストして、自身のストレージに書き込んでそれをView側がSubscribeするというのは、確かにそういうのもありかという発見
  • ネイティブアプリは表示に特化したアプリなので、ドメインオブジェクトもそれ専用にするというのは納得感があった
  • モジュール分割は大変になりますよねそれは…という気持ちに
  • 許可よりも謝罪をで攻めた結果いいものができたのでは、という事例でした。

関連リンク


英訳だけじゃダメ!Eightのグローバル展開のための改善

speakerdeck.com

感想

  • 南アジア方面に展開するときによく耳にする、低速度域でのカバーの話
  • 通信速度の安定ありきの実装だったのでエラー出まくりという悲しみの話だった。
  • ダウンロードサイズが数十MBレベルになると数十分分DLにかかる環境らしくたしかにそれは軽くせざるを得ないなという気持ち。
  • バイナリサイズを分けるために機能を分割して不要なものを入れないとか後でDLっていうのはゲームアプリの発想に近いなというかんじ。
  • NewRelicのモバイル版とかあるんだという学び
  • なんかガラケー時代のソシャゲにしていた気配り(再リクエストの冪等性対策 / コネクション再接続時のレジューム)を想像した

関連リンク


Sansan、Eightの開発マネジメントの実際とこれから

speakerdeck.com

パネルディスカッションメモ

プロダクトマネージャに技術領域が求められているというのは何か背景があるのか

SanSanのビジネスモデルとして競合などが多く出てきており、強みを出していくには膨大なデータをどうやって生かしていくかが大事になっていく、そういうときにR&Dとうまく話ができるかが肝要

技術の知識をもったプロダクトマネージャーに関して

採用とかはしていないのでほぼいない、技術領域をバックグラウンドにもっている人を取りに行かない

ただ、エンジニアとしてのコンバートを考えた場合でもエンジニアがPdMになっていく仕組みがない 社内ではAPM(AssosiateProductManager)を経てプロダクトマネージャになる仕組みは存在している。

技術の素養が必要なプロダクトマネージャーは技術畑出身であるほうが良いと考えており、プロダクトマネージャーをやってきた人があとから技術を身につけるほうが難易度が高い。

プロダクトマネージャーの適正というのはビジネスであることを意識して、利益を出すということに考えが行くことが必要なので、それをできるかが必要になる。

プロダクトマネージャーとチームワーク

開発チームが成長しきれてないと、プロダクトマネージャーにめちゃくちゃ聞いてくる 開発チームが自分で考えて、どう動かすかを考えられていければ、問い合わせは減るはず。そうすれば仕組みづくりのほうに注力が可能になる。

開発チームと連携するときも、スクラムマスターの資格をお互いにもっているので、意識合わせは楽だった。

自分らしさを引き出すためにどういうコミュニケーション

ストレングスファインダーなどで自分らしさを引き出してもらったりしながら、自分らしさについて考えてもらう。

中途の人などは環境の変化などで本来のパフォーマンスを取り戻すまでに時間がかかったりする、その場合も自分の価値を問いながら取り組んでもらっている

チャレンジできる環境じゃないと成長できないけれど、チャレンジするときは大変な部分も伴うので、そのときに個人の軸となる部分が心の拠り所のようなところになるので、軸はなにかという部分も問いかける。

会社の要求に関して、自分の個性や自分のやり方と併せて発揮できそうな部分考えてもらう。

リーダーとしては1on1などで問いかけを行う。

質疑応答

Q.自分らしく働く、自分らしさの発見のためにどういう言葉や考え方をしてもらうのがいいのか?

信頼できる第三者(嫁さんとか、長い友人とか)から「私らしいことって何?」みたいな感じで問いかけてみる

Q.個人の問題に関してどうやって伝えたり、メンタリングしているのか

マイナスのフィードバックをすることする文化があればいいのかなという感じ、やっていることとしてはリーダーとメンバーの1on1だけではなく、メンバー同士でフィードバックをする。メンバー同士のはフィードバックはリーダーも知らない。

気をつけないといけないポイントとしては相手のキャラクターに応じてコミュニケーションのやり方を考えること。ストレートに言うのが良い人もいればそうでもない人もいる。

Q.1on1の頻度はどれくらい

チームメンバーが決めているケースと月1というケースに分かれた。

Q.マネージャーが管理していないよという自己意識を芽生えさせるためにどうしているか

デリゲーションポーカー のような感じで意識合わせをする。またその際に「as is(現状)」と「to be(未来)」として権限状態をどうするかも考える

Q.ビジネス的にやらなければいけない案件に対しての取捨選択する際の基準はあるか。

数値的に判断できるようにする。またチーム内にもビジネス的にやらなければいけないもの(別会社のための機能、のような話)があるときも

Q.スケジュールマネジメントはどうしているか?

スケジュールの見える化をしている。スケジュールが見えていれば遅れの状況などが自明になるので良い。

感想

  • プロダクトマネージャー側と開発チームの運用の仕方、知見に関してのパネルディスカッションで学びが多かった
  • プロダクトマネージャーが100%のパワーでスクラムやれている現場というのは体感できていないので、ちゃんと回す人と知識をもって実践をできる人がいればこんな感じで回せるのかなという気になった。
  • 「マネージャー的な立場の人が問いかける」というのはすごい納得感があったというか、個人個人の生活のなかだと考え始めるきっかけが無いのでそれを提供するのって大事だなと思った。
  • ストレングスファインダーは自分自信も社会人なりたてのときぐらいにやって今見直してもある程度納得感のある結果だったので、会社側がそれを支援してくれるのはいいなーという感じ。

関連リンク


ビジネスを加速するためにAIで実現したこと、したいこと

speakerdeck.com

感想

  • わかりやすいAIの歴史、チューリング・テストとか名前は聞いたことあったけど、どういう経緯で使われるようになったとかはしらなかったので学びがあった
  • Sansan社がどうやって機械学習に取り組んでいるのかというのも知れたし、わかりやすい機械学習テーマで面白いことやっているなーという印象。

関連リンク


全体を通しての感想

  • 会場が表参道ヒルズ、こんな商業ビルみたいなところでどうやって…と思ったらすごい豪華な会場だった。オープニングトークでも「違和感を楽しんでほしい」とあったので意図したものだったみたい。
  • サイレントセッション、話者の声をスピーカーで拡散するのではなくレシーバーに流して、チャンネルを切り替えて効くという形式。部屋が別れていない会場では理にかなったやりかただなーと思った。ただレシーバーって大体ロストして費用がアカンことになる事例を毎度聞くので主催者側はヒヤヒヤしそう。
  • キャンプチェアの見本市みたいになっていたが、座り心地は抜群だった。むしろうっかり寝そうになった。
  • プロダクトマネージャー寄りのセッションが盛況だったので、あとでスライドをみたいなという感じに。
  • 時間の関係で懇親会出れなかったのは残念だったけれど、セッションを聞く雰囲気としてはすごい良い場でした。

関連リンク

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Railsのcallbackは事前にメソッドを呼び出すだけなので、raiseしたExceptionはshowなどのメソッドのrescueでキャッチしてくれない

よくよく考えたら当たり前なんだけど、もしかしたらやってくれるのでは!?みたいな淡い期待を打ち砕いてくれたので、やってみたメモ

環境

rails (5.2.0)

処理例

仕様

/sample/1 を指定したときは {sample: true}jsonが返却され、それ以外のときは {sample: false} が返ってくる

コード例

class SampleController < ApplicationController
  def show
    # パラメータは文字列なので数値に
    response_bool = params[:id].to_i == 1 ? true : false
    render json: {sample: response_bool}
  end
end
Rails.application.routes.draw do
  resources :sample
  #... (以下略)....
require "rails_helper"

RSpec.describe "SampleController", type: :request do
  describe "GET /sample" do
    subject { get sample_path(id), params: {}, headers:{} }
    context "idが1でリクエストしたとき" do
      let(:id) {1}
      it "trueが返ってくる" do
        subject
        request_response = JSON.parse(response.body)
        expect(request_response["sample"]).to eq(true)
      end
    end
    context "idが2でリクエストしたとき" do
      let(:id) {2}
      it "falseが返ってくる" do
        subject
        request_response = JSON.parse(response.body)
        expect(request_response["sample"]).to eq(false)
      end
    end
  end
end

改変案

before_actionでエラーチェックして false をrenderすればいいのでは…?

class SampleController < ApplicationController
  before_action :check_param
  def show
    render json: {sample: true}
  rescue ArgumentError
    render json: {sample: false}
  end

  private

    def check_param
      # 独自Exceptionが望ましいけど例示なのでArgumentError
      raise ArgumentError unless params[:id].to_i == 1
    end
end

こんなふうに書けばいけるのでは!?とか思ったが盛大にコケる

$ bundle exec rspec spec/request/sample_spec.rb 
.F

Failures:

  1) SampleController GET /sample idが2でリクエストしたとき falseが返ってくる
     Failure/Error: raise ArgumentError unless params[:id].to_i == 1
     
     ArgumentError:
       ArgumentError

ですよねーって感じです。

やるべきだったやり方

class SampleController < ApplicationController
  def show
    check_param
    render json: {sample: true}
  rescue ArgumentError
    render json: {sample: false}
  end

  private

    def check_param
      # 独自Exceptionが望ましいけど例示なのでArgumentError
      raise ArgumentError unless params[:id].to_i == 1
    end
end
$ bundle exec rspec spec/request/sample_spec.rb 
..

Finished in 0.44626 seconds (files took 9.61 seconds to load)
2 examples, 0 failures

意図通りに行きました。