コード日進月歩

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

定数を定義をする意味を考える

結構無意識に定数を利用しているが、どういう場面で使われるものなのかというのをちゃんと書き出してみる。

定数を用いるケース

1.マジックナンバーの置き換え

マジックナンバー(意味や意図が記述した本人以外には自明ではないもの)が発生した場合、それを回避するために何か変数に格納して変数名で用途を表現するという方法がある。

ただし、マジックナンバーの大体はプログラムのスコープ上で変化することが少ないので、定数値化するのがベストとなるケースが多いため、定数定義する。

2.重複利用する内容の設定

1の内容とDRYの文脈が合わさると、『使い回すような数値は意味を持たせて挙げればいい』という着想が生まれ、同じような定義を使い回すために代入する機会がない変数として定数を用いることがある。

3.メモリ空間を節約したい(実行環境や言語による)

プログラミング言語によっては、定数として定義することにより、動かない値として定義されるので作りによってはメモリの利用効率があがったりするケースがある。

GCの無いような言語や、組み込みなどのメモリリソース資源の管理がシビアな状態のときなどには響く

あとがき

なんでこんなことを書いたかというとレビューにおいて、定数を定義する意味に関して問われたときに正確に回答できないなと思い、定数のあらましをざっと調べてみたかったという感じです。

それこそプリプロセッサで置き換えてた時の話と考えると、ちょっと今どきは色合いが違っていたりはしますが、突き詰めていくと今のマジックナンバーの撲滅とその延長線上にある意味変数の使い回しという側面につながってくるのかなと思います。

なので、変数定義を勧めるときは「マジックナンバーの回避」というのを念頭において語るとよいのかもしれないなーと思ったのでした。

関連リンク

ActiveStorageでフォーム経由ではなくファイルシステム上のものをattachする

ググると出てくるのはフォームでの利用事例ばかりでふと実githubのReadmeを見たら書いてあったので、日本語情報がてらメモ

環境

rails (5.2.0)
activestorage (5.2.0)

やり方

大前提の内容はRailsガイドに書いてあるとおり、テーブルを作って、has_one_attached のような関連性を定義する。今回はどこの事例にも出てくる以下のようなモデルの場合のケース。

class User < ApplicationRecord
  has_one_attached :avatar
end

ID10の useravatar./text.png みたいのをコンソールで当て込みたい場合は以下のような記述になる。

User.find(10).avatar.attach(io: File.open("./test.png"), filename: "test.png", content_type: "image/png")

関連リンク

OculusGOを買ったり、いろいろ休息にあてたのでおやすみ

いろいろ検証とかしたかったんですが、暑さとゆったりしたい欲に負けたのでおやすみです。

LTとかしてみたいけどできないアレ

昨日の投稿がパワーを使いまくったのと連休中日ということもあり、今日は雑記です。

どっかでLTとか発表とかしたいなーと思いつつもできてないのが私の身の上でして、自己分析すると主に3つぐらいありまして…

  • 基本的に便利屋稼業が多くて、一つの技術どっぷりやることがなく割とパラレルでいろいろな技術を浅く万遍なくやることが多いので深く潜ることによる知見がない
  • 事例という手段もあるのだが、それは仕事でやっていることなので個人のこととしてつらつら書くのは気が引ける。(実はこのブログとQiitaにも自分が調べていない知見はあんまり書いていない)
  • 人を育てているとか、チームを運営するポジションでもない(実質やっていたりしたりもするが)のでなかなかそこら辺に知見もない。

便利屋稼業がひどすぎて、Webマスターツールをポチポチしてレポートつくるお仕事とか、ベルトスクロールアクションのステージをレベルデザイン考えながらひたすら作るとか、Ilustoratorで入稿されたパス画像から不要な頂点を消して最適化する作業とか、おおよそいまの仕事に直接関係ないこともわりかし業務でやってきたりしてました。

というどのジャンルとっても浅い、浅すぎる!というのが悩みの種で、LTするにしたって特定のある程度そのジャンルの人に馴染みのある話しなきゃいけないので、そういうカードそんなに無いな…みたいなっています。

じゃあ私事の時間になんかやっては?みたいのあるのですが、なんせ会社の規模が規模なのであまりそこらへんもできずじまい。

なのでとりあえず、もうやったことの内容の如何はさておき、このブログを初めてみたのですが、なんかそのうち発表できるものができるといいな…。

今日話したいのはそれぐらいです。

『Rails Developers Meetup 2018 Day 3 Extreme』に行ってきたよメモ

Rails Developers Meetup 2018 Day 3 Extreme]に行ってきたので見たセッションに関してのメモ。メッチャ多いのでひとつひとつの感想に雑味があるのは許してほしい…。

各発表の感想

※資料スライドは見つけたら貼ります。


曖昧さを受け入れて開発をしていく方法

感想

  • 仕様がしっかり固まって降りてこないウォーターフォールではない開発に関しての構えの話
  • 前に違うところでも語られていたが、足回り見たい部分が結構重要になるなという気持ち
  • GraphQLを使うことで画面の仕様変更に強くするというのは知見だった

関連リンク


Octocatは技術的負債の夢を見るか?

感想

  • 実際にあった怖いコードの話を交えながらの技術負債の話
  • 地図があればそれに従い、地図がなければ布教するというのはとても共感できた
  • 設計レビューやってます、みたいな話があったので質問したら丁寧に答えていただけた…ありがたい…(無断転載するのもアレなのでこちら

ちゃんとやっている…非常に参考になる話だった

関連リンク


pixiv Sketch Live: WebRTC配信サービスの裏側

スライドは公開された貼ります

感想

  • リアルタイムチャットとWebRTCを使った配信ノウハウの話
  • 結構門外漢なので、はーそうなのかーみたいな感じの知見が多かった
  • あとここでも時雨堂さんの名前を聴くとは思わなんだ…

関連リンク


Ruby でつくるデータ分析基盤 - Rails アプリケーションにおけるデータ処理の変遷

感想

  • データ分析基盤をどう作っているかという話
  • 「WebUI上に用意してしまうと間違いに来づけない」というのは確かにそうだし、BigQueryをカジュアルに触れると普通に起こりうる問題だなと思った。
  • BigQueryのクエリ組み立てが独自DSLっぽいのつくると管理がツラミなのでバランス大事かもなっていう所感

GCPをフル活用したゲームログ収集基盤の構築

感想

  • イベントログデータとかをどう扱うかという観点の話
  • fluentdだと欠損が…みたいな話があったので使ってないのかと思いきやRailsからの吸い上げは普通に使っているんだという気持ち
  • 技術比較の部分は普通に参考になった

関連リンク


IKUSEI on Rails

感想

  • みんなのウェディングのRuby人材を育てるという意気込み毎度すごいなと思う。
  • 新人教育しっかりしてるけど中途はどうなんだろうとかは思ったりした
  • エッセンスとは見習いたい部分多分にあるので参考にしたい

関連リンク


esmメンバーの関心事〜開発手法と開発環境編

感想

  • アジャイルとは何か…みたいな気持ちにさせられたので原典をちゃんと読もうと思った気持ち
  • dotsファイルは結構人によって色出るよね、とは思った。

関連リンク


技術顧問という働き方

感想

  • 外部の人が入って技術を牽引していくトライアンドエラーの話
  • レビューとかはやっぱドメイン要素が入ってきちゃうのでバランス間隔難しそうだなと思った
  • 読書会は結構実りが多いとのことだったので、輪読形式でやってみようかなという心持ち

関連リンク


enzaプラットフォームのアーキテクチャ

感想

  • 技術選定の背景から、パフォーマンス、運用周りまで結構実りの多い資料(話が途中だったのすごく残念)
  • Elixirの事例や定常的な負荷試験など普通のサイトとは切り口が違うところが学び

関連リンク


Rails経験者が万葉の新人研修を受けて得られたこと

感想

  • 中途でもちゃんとランディング期間を設けてるとてもいい会社の話
  • 新人研修のカリキュラム非常に良さそうなので読みたい

関連リンク


Rails + TypeScript + React + Hypernovaで始めるSSRライフ

感想

  • GoogleBotがちゃんと来てるかをメトリクスする、というのはなんかなるほどというか、ギリギリを活きてるサービスなんだなという感想
  • それとは別にhypernova結構いいなという気持ちになったのでちょっと業務で導入検討したくなった
  • あとBulmaは癖がなくて使いやすいと思う

関連リンク


Railsと考えるデータベースのインデックス戦略

感想

  • カーディナリティに注目したパフォーマンスの話
  • こういう部分って大切だと思うし、そもそも我々実行計画の読み方を覚えてちゃんと見るべきだよねという気持ちになる…(割とAcitiveRecordにおんぶにだっこになってしまっているので改めたい)

関連リンク


リフォーム Rails app

感想

  • おかしなコードを事例を交えて紹介
  • ガード節を一個間違って消すだけでおかしくなるようなコードを書いてはいけない場面もあるよね、みたいのはもうちょっと掘り下げて聞きたかった
  • スライド公開されると思ってメモがあまり取れてなかったのが残念… 公開された、やったー!
  • デカいコードを切り出すときに利用していない変数が生まれるとかはちゃんとテスト書こうねみたいな事案ですね…

関連リンク


RSpecでBDDをしよう

speakerdeck.com

感想

  • TDDとはBDDとはみたいな付録C的な話
  • テスト技法じゃなくて、開発技法なんだよ!という叫びを伝えていきたい

関連リンク


RailsWayの再考

感想

関連リンク


Wantedlyにおけるプロダクト、技術、組織、7年間の進化

感想

  • 歴史資料。
  • モノリシックなアプリと増えていく新機能とどう向き合うかの一例
  • ある程度で方向性を見極めていくべきところ多いのかなーと思うなど

関連リンク


Attributes API実践

感想

  • ActiveRecordに型を意識させたり、オブジェクトを初期値として仕込む事例などの話
  • 機能的には便利そうだなーと思う半面、しっかり理解するさせないと沼になりそうな機能

関連リンク


GraphQL on Rails 2018

感想

  • 実際に導入した感想としての資料
  • 使い手のメリットが見えないが、やっぱりデータを検索する系は使ってみたいなと思ったりした。

関連リンク


RuboCop Headqurters 2018

感想

  • rubocopの現状ってこういう感じなんだ、というのが体感できた
  • 1.0に向けて整備されてきているので、そのタイミングが襟を正すよいタイミングかなと思ったり。

関連リンク


Rails 6 に向けた ActiveRecord の改善

kamipoさんによるフリートークセッション

感想

  • ActiveRecord闇多いなという感想。
  • 新機能がパフォーマンス検証されてないので遅くなっているという話もあったりして、この話って普通の開発にも当てはまるので怖いなと。
  • ARを過信せず、ちゃんとテストケースは書かねばと思ったり…

全体を通しての感想

  • コード・全体設計、チーム運用、Rails的な話、いろいろ聞けて楽しい1日でした。
  • 広く浅くマンの私としてはRailsの強みみたいな部分を活かしつつも技術選択の幅を増やしていきたいなとLaravelの話を聞きながら思いました。
  • ActionCableに関しては、各々使い方が微妙に違う話なのに、全員難色を示す/示さざるを得ない結果を得てる感じがあった。
  • あとみんなわりとカジュアルに「ドメインが〜」みたいな話をするので、それらの用語って割とRails開発者間では一般化してきたのだろうかと思ったりした。

時刻を文字列からParseするときはTime.zone.parseが一番オススメ

ローカルマシンでは露見せず、アップすると露見する系なので、思わぬ事故を防ぐために。

環境

rails (5.2.0)

何故オススメなのか

原理としては Time.zone.now と同じなのですが、 Time.parse を使うとRailsに設定されているタイムゾーンは配慮されないので、Time.zone.parse を使ったほうが間違いがないよねという話。

# タイムゾーンの確認
Time.zone.name
#=> "Tokyo"

# 設定したい時間をセット
set_time = "2017-10-01 12:30:45"
#=> "2017-10-01 12:30:45"

Time.parse(set_time)
#=> 2017-10-01 12:30:45 +0000
Time.zone.parse(set_time)
#=> Sun, 01 Oct 2017 12:30:45 JST +09:00

関連リンク

負荷試験をやりたいけどやれてないという思い

実はソフトウェアエンジニア歴約8年ですが、まっとうな負荷試験というのを経験したことがない。

というのも、サーバーサイドエンジニアマンやってた時間よりもネイティブアプリとかフロントアプリとか書いていた時間が長かったりするのと…

  • 自社サービスばかりで、納品するような話もなかったので非機能要件としてそれを満たす課題が設定させるような案件をやってこなかった
  • 負荷試験を行うほどの予算がない or そんなのが必要のないアクセスのもの
  • Jmeter とか gatling 使いたい!とか思ったけど、他の実装が大変でそれどころではないというところで見送り
  • 負荷試験的なことをしたがマクロを組んでただただgetリクエストをするだけとかのもの

などなどいろいろな要因があり、負荷試験に長けている人や経験者とも出会うことがあまりかなった。

といはいえ大切なモノという認識はあるので…

これを読んでみたいなと思った。

関連リンク