コード日進月歩

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

2019年の個人アクションざっくり振り返り

2019年ラストも今年の振り返り記事を書きます。まぁ今年は個人的な活動するのがしんどいぐらい振り回されていたのが明らかに…

月別サマリ

1月

2018年12月にやったことの残り物整理で追われた1ヶ月。ただこの月にLT枠で登壇したりもしている。

行った勉強会

意外と行っている。

2月

品質管理的なサムシングやチームマネジメント的なサムシングを調べる機会が増えるも、仕事がトラブルが多くバタバタし始める。トラブルシュートに追われる日々。初めての長尺登壇もしたが、これ以降2019年の登壇は絶えるという…

行った勉強会

振り返ると行き過ぎですね!?

3月

開発的なことはあんまりしておらずだったので品質管理的な話題でブログが賑わう。

行った勉強会

RailsDMであの伝説のスライド爆誕した月

4月

ここらへんからえらくスケジュールがタイトな話にぶちこまれる。そのためブログの内容の遅延が多く、割と薄めな話が増えるのもこの時期から。

行った勉強会

わかりやすくいった勉強会が減る

5月

GW?知らない子ですね…といわんばかりのスケジュールだったの私事に取れる時間がなくなり基本的にてんてこ舞い。組織としても結構いろんなことが立て続けに起きてメンタルもお豆腐に。

行った勉強会

6月

「一難去ってまた一難、ぶっちゃけありえない」という感じでめちゃくちゃな案件終わったらまたハチャメチャな案件が始まる。お豆腐割れずになんとか保つ。

行った勉強会

7月

でかい騒動の荒波が過ぎ去り、なんとか通常運転に戻るも、プロジェクト自体はバタバタしてるので時間を取られまくる。実はコードを書くことよりも調整ばっかしてたので記事ネタもソレが反映されてくる

行った勉強会

Rails6もこの頃か…

8月

プロジェクトが都度都度ジャンルの違うトラブルに見舞われる。それでもなんとか収めつつ進める。7月の頃以上にコード書かなくなる。

行った勉強会

9月

やっと忙しさに終わりが見えてきた頃。とはいえ社外の相手のコミュニケーションでバタバタはしていた。コード書かない日々が続く。

行った勉強会

ゲーム開発全然関係ない仕事してるので、有給でUnite行ったらドン引きされた

10月

10月終わりのプロジェクトの締めで、インフラ基盤のリプレース作業の一部担当を担う。同時並行でめちゃくちゃしんどい。特段新しいことではなく調整に追われてたので、10月のブログが用語解説系増えてきたのはそのせいもある。

行った勉強会

11月

基本的に10月までのプロジェクトの残作業と別プロジェクトの窓口業務などとりまとめなどを行う。ビジネスメール力とスプレッドシート力が上がる。おかげで緊急度が高い仕事ばかり増え結果整合性ブログの色が濃くなる。

行った勉強会

12月

師走。何故か連続で障害にかなり見舞われる。(しかも何故かすべての話でトラブルシュートの主担当になる)

全然毛色の違うチームに混ざることとなり、めちゃくちゃ時間取られて年始にやっていた業務が復活してくるなど品質改善やらアーキテクトやらコーディングやらを同時並行して行うこと担ったっ結果、コンテキストスイッチ切り替えまくらなきゃいけなくて忙殺される。

行った勉強会

振り返り

年始に目標を立てていたことがどれだけできてたかの確認。

ほぼ1日1記事ブログの継続

リアル毎日更新ができてないが、一日一技術記事のテイストは保ててるので、年末年始でリセットしたい。

登壇をできれば1Qに1回必ずする

1Q目は順調だったが、2Q目からまぁ精神的にもキツい事態になったのでなかなかはかどらず登壇もできず…でした。

英語の勉強を1月中に何かしら方向性を見つけて2月から何かしら取り組む

これが一切できてない、本当にひどい。2020年は本気出す。

平日と朝の時間をしっかり活用できるようなリズムを取り戻す。それを読書タイムなどに充てる。

忙しすぎて逆にリズムが崩壊しました。

趣味の開発/休息を兼ねてかならず土日はしっかり休めるように業務調整をちゃんとする

自分が責任の主体となり、スケジュールドリブンの話が持ち出されると色々私事の時間を削って捻出することがまぁまぁ多くてセルフマネジメントの敗北を感じました…。

ある意味ブログが趣味の主戦場となっていたので、それで調べて学ぶ時間を強制的につくれていたのが唯一の救い。

総括

目標達成率のひどさもさることながら、このブログも結果整合性マジックにより年明けに書いており、ブログネタの枯渇と私何やってたんだろうか…が深刻化している。

実際やりたかったことの10%もできてない気がするので年始編のブログで舵切りを考え直す。

anyenvで入れられるenvをざっくり調べてみた

そういや何があるんだろ…的なメモ

出典

GitHub - anyenv/anyenv-install: Default anyenv install manifests

リスト

名称 対応言語/ツール Github
Renv R言語 GitHub - rstudio/renv: renv: Project environments for R.
crenv Crystal GitHub - pine/crenv: Crystal version manager like rbenv.
denv D言語 GitHub - repeatedly/denv: D version of rbenv
erlenv Erlang GitHub - talentdeficit/erlenv: simple erlang release management
exenv Elixir GitHub - exenv/exenv: Elixir version manager
goenv Go GitHub - syndbg/goenv: Like pyenv and rbenv, but for Go.
hsenv Haskell GitHub - tmhedberg/hsenv: Virtual Haskell Environment builder
jenv Java GitHub - jenv/jenv: Manage your Java environment
luaenv Lua GitHub - cehoffman/luaenv: Groom your app's Lua environment
nodenv node GitHub - nodenv/nodenv: Manage multiple NodeJS versions.
phpenv PHP GitHub - phpenv/phpenv: Simple PHP version management
plenv Perl GitHub - tokuhirom/plenv: Perl binary manager
pyenv Python GitHub - pyenv/pyenv: Simple Python version management
rbenv Ruby GitHub - rbenv/rbenv: Groom your app’s Ruby environment
sbtenv sbt GitHub - sbtenv/sbtenv: Groom your sbt environment.
scalaenv Scala GitHub - scalaenv/scalaenv: Groom your app’s Scala environment
swiftenv Swift GitHub - kylef/swiftenv: Swift Version Manager
tfenv Terraform GitHub - tfutils/tfenv: Terraform version manager

Terraformもあるんだという学び

関連リンク

Stranglerパターンに関してざっとまとめる

ストレングラーパターン、直訳すると「絞め殺しパターン」。物騒。

出典

StranglerFigApplication(日本語訳:ストラングラーアプリケーション

元ネタはオーストラリアにあるという「ストラングラーフィグ

意味

古くからあるシステムに対して、そこに対して追加していくのではなく、新しいシステムを別に作ってそのシステムと並行運用して成長させていき、徐々に新しいシステムに載せ替えていく。という考え方。

実際の開発において

旧システムと入れ替われるように一部システム機能だけ別システムで動かすという考えは広義のマイクロサービスアーキテクチャでもあるし、カナリアリリースも近い考え方ではなるので、言葉違えど、考え方は似てる部分が多いものかと思われる。

参考リンク

RSpec(rspec-rails)のrails_helperの初期設定は「RAILS_ENVがなければtestにする」という設定なので気をつける

RAILS_ENVを意図的に設定しているとRSpecが動かない場面に遭遇するので気をつける、というメモ。

環境

rspec-rails (3.8.1)

該当記述

rails g rspec:install で生成されるファイルのテンプレートは以下のような記述になっている

ENV['RAILS_ENV'] ||= 'test'

rspec-rails/rails_helper.rb at master · rspec/rspec-rails

そのため、能動的に環境変数を書いているときに bundle exec rspec をしてもうまく動かないときがあるので注意すること。

RAILS_ENVがある状態でRSpecを実行するとどうなるか

一番ありうるケースとしてはtest用のgemが入っておらず該当するクラスがありません!と言うエラーで落ちる。

例えば以下のような感じ

group :test do
  gem 'hogehogetestsupport'
end
bundler: failed to load command: rspec (/usr/local/bundle/bin/rspec)
NameError: uninitialized constant HogeHogeTestSupport

対応方法

RSpec走らせたいときはどのみちRAILS_ENVをtestにしたいはずなので、記述を以下のようにする。

ENV['RAILS_ENV'] = 'test'

関連リンク

ヘッダービッティングとは何なのかをざっくりまとめる

実装はかなり泥臭いっぽいので、あくまで意味だけの話で。

背景と意味

広告掲載側のプラットフォームであるSSPが各社DSPからの広告で最高値のものを取得することになるが、適当な広告をSSPが取得できない場合は別のSSPに順繰り聞いていくという形式がある。その場合にSSPの問い合わせ順が定められた方式、いわゆるウォーターフォール方式で問い合わせているため、後続に高価な広告があっても採用されないケースがある。

そのため、SSP同士を全部みて一番高値のものを出すというのが「Header Bidding」という考え方

参考リンク

Web広告のz-indexにはガイドラインが存在する。

z-indexって自由すぎるやんか…という話

ガイドライン

IABがガイドラインを出している。(ただしQuickGuideがExcel

原典

Z-Index Range Content Type Details
< 0 Background Elements None
0 - 4,999 Main Content, Standard Ads Standard ad tags in place with regular content. Includes IBA Self-Regulation Message (CLEAR Ad Notice)
5,000 - 1,999,999 Expanding Advertising The entire expandable ad unit should be set within this range
5,000,000 - 5,999,999 Expanding Site Navigation Elements Drop down navigation, site warnings, etc. Only the expanding portion of navigation elements should be included on this level.

ざっくり和訳

Z-Indexの値 コンテンツの種類 説明
0未満 バックグラウンド要素 特に特記事項なし
0〜4,999 メインコンテンツ, 一般的な広告 通常のコンテンツを含む標準の広告タグ。 IBA自主規制メッセージを含む
5,000〜1,999,999 エキスパンド広告 エキスパンド広告ユニット全体をこの範囲内に設定する必要があります
5,000,000〜5,999,999 サイトナビゲーションの要素 ドロップダウンナビゲーション、サイトのアラートなど。

サイトの要素は4,999までで設定して、「大事なお知らせ」みたいなモーダルメニューは 5,000,000 以上を設定するのが良さそう。

仕様としての上限値はあるのか

z-indexの値はintegerなのでintegerの最大値が上限値と考えることができるが、CSSとしてはintegerの範囲を定義していない。

公式には、有効な 値の範囲は決められていません。 (中略)最新の仕様書では範囲を定めなくなりました。 - - CSS: カスケーディングスタイルシート | MDN

ただ通説的にはint最大値とされる2の31乗-1の 2,147,483,647 がよく登場する。が、これもブラウザの実装に依存する部分なのでまちまちな感じ。

参考リンク

2019年現在でWebフォントと付き合う場合に見たいスライド「ウェブフォント今昔物語」

クリスマスでオシャレなフォントが並ぶ昨今、という感じのスライド回顧録です

speakerdeck.com

「ウェブサイトにおしゃれなフォントってつかえるんでしょ?」と言われると、「いやいやライセンスが…」とか「いやいや通信のオーバーヘッドが…」とか言ってしまって使う気力を削ぐコミュニケーションばっかりしてて、現実的に使えるかってあんまり考えることがありませんでした。

そんな中でこの資料が大変まとまっており、企画者、実装者にとっても一読しておくことで知識の均しができる資料だと想いました。

関連リンク