はてなブックマーク

年月の範囲をDateクラスで扱うのがダルい... 2023年1月、2023年2月...と月単位のラベルを持つグラフを作る 2023年1月号、2023年2月号...と月単位で提供される雑誌を扱う といった、年月を扱うケースでは、ただのDateクラスではちょっと役不足ですよね。例えば以下のようなコードを考えてみます。 require 'date' start_year_month = Date.new(2023, 9, 1) today = Date.today latest_year_month = Date.new(today.year, today.month, 1) # # 期間でループしたいとき # tmp_month = start_year_month while tmp_month <= latest_year_month pp tmp_month.strftime('%Y%m

Userモデルにユーザーの平均年齢を計算してもらい、分析テーブルに現在時点のデータを保存するサービスを想定してみました。(実際には平均年齢以外に男女比とか平均課金額とか、そういうデータも一緒に集計すると思いますが、ここでは説明のため省略しています。) このサービスのテストコードを書けと言われて、ぱっと思い浮かびますか? 初心者でも思いつくのは、 Userテーブルのテストフィクスチャを用意して、実際に平均年齢を計算させる Analysisテーブルに保存されたレコードを検索して、実際のレコードの値をアサートする こんな方法でしょう。でも、ちょっと待ってください。Railsのテストでも操作しやすいリレーショナルデータベースに値を保存しているから「簡単じゃん」と思うかもしれませんが、、、 例えば保存する先がリレーショナルデータベースでなくredisなら...? 例えば保存するのではなくチャットサー

技術記事を書いたほうがいいの? 書かなくても技術は身につくの? きのこたけのこ戦争と同じく、技術記事を書いたほうが良いvs書かなくてもいい論争は議論が平行線になることが多い。 一方は「技術記事を書くと理解が深まる感覚があるから書いたほうがいいんじゃないか」と主張し、一方は「技術記事を書かなくてもつよつよなエンジニアは沢山いるから書かなくてもいい」と主張する。1 どちらもひろゆき氏に言わせれば「それってあなたの感想ですよね?」と棄却されてしまうこと請け合いなので、技術記事を書く学習効果について実験研究の結果をもとに科学してみたいというのがこの記事のテーマだ。 また、調査の結果や私の個人的なこれまでのアウトプット方法を踏まえて、どのように技術記事を書けば学習効果が高いのか、あるいはどんな技術記事は学習効果が低いのかについて考えてみたい。 技術記事を書くメリット1：記憶定着 まずは、「技術記事を

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 材料 オブジェクト指向※1に詳しく経験のあるリーダー：1人 オブジェクト指向で書かせたいメンバー※2：少々(1〜4人) イチからチームで作れる大きさのプロジェクト※3：1つ ※1 オブジェクト指向でなくDDDでもデザパタでも代用可能 ※2 「オブジェクト指向って美味しいの?」レベルのメンバーでも十分可能。設計に興味があるメンバーがいると仕上がりが速くなります。 ※3 既存の設計にあまり依存せず、設計の自由度が高い案件だとよりよく仕上がります レシピ 1.「今回のプロジェクトはオブジェクト指向で書きます。異論は認めん」とリーダーが高らかに

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 20代で圧倒的に成長する人とパッとしない人の決定的な違い 2人の新入社員がいた。 同じ学歴レベル。 同じプログラミングの技術力。 同じ採用基準に合格。 それでも、入社から1年後、2年後、5年後になると、一人はバリバリ成長してチームリーダーを任されている一方、もうひとりはいつまで経っても大きな仕事を任せてもらえない…。 これはフィクションだが、こんなことはエンジニア業界に限らず日本中いたるところで発生している。 二人を分けた違いはなんだろうか?それは、、、 高い仕事の基準を自分に課していたかどうか。 君が20代で圧倒的に成長したいと本気で

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事の目的 「テーブル設計、ほんとにこれがベストなのかな...?」 と思うことありますよね。シンプルなテーブル構造だと普通に正規化すれば問題なく運用できるんですが、ビジネスルールが複雑だったりするとあえて正規化を崩した設計を行うこともあります。ですが、「正規化を崩して何が嬉しいのか?」を論理的に考え、メリット・デメリットを考慮することによって、うまくトレードオフスライダーを調整することができるようになります。本記事では正規化も含めて、それぞれの正規化崩しがどのような目的のもと行われるのかを整理してみました。(なので、RAIDなどの物理

前編(こちらを読まなくても問題ないです) サンプル See the Pen 漢気割り勘ツール by terao takumi (@teraotakumi) on CodePen. 金額と参加者を入力し、計算モードを選んで「計算する」をクリックすると、アラートウィンドウが表示されてそれぞれの参加者がいくら支払うのか表示されるようになっています。これを、バニラjavascriptを使ってオブジェクト指向で書いてみた、というのがこの記事の趣旨になります。 登場オブジェクト まずは全体感を理解するため、ざっくり登場オブジェクトとその役割について見ていきます。 ・漢気計算機(OtokogiCalculator) 入力された内容を元に計算を行うオブジェクト。constructorで支払金額と参加者名簿のインスタンスをもらう。 ・支払金額(PaymentAmmount) 入力された支払金額を司る。 ・参

javascriptはオブジェクト指向言語なのに、手続き型で書いてしまいがち... javascriptはオブジェクト指向言語であるものの、ちょっと特殊な言語です。Java、C++、C#、Rubyといったクラスベースの言語とは違い、プロトタイプベースのオブジェクト指向言語であるというのがオブジェクト指向で書きづらい要因になっているように思います。 クラスベースの言語であれば、まずはともあれクラスを作ってインスタンス化する...という一連の流れが自然と書ける一方で、javascriptでは「DOMを操作する」という任務を任されることが多いために、要素を取得して、計算して、要素を書き換えて、ということを手続き的に書いてしまう。 そして、記述量が多くなればなるほど待ち受けるのは、、、 「このjsはどこで何をやってるんだ...」 「同じようなコードがいろんなところでコピペされてる...」 「この処

値オブジェクトは以下の3つの要素を持ったオブジェクトだとされている。 1)不変である(一度インスタンスが作られたら、それが保有する属性の値は変化してはいけない) 2)交換が可能である(再代入=交換によってのみ値を変更することができる) 3)等価性によって比較される このうち、3)は絶対に必要なんだろうか? 例えば、Date型にかなり近い、YearMonth(年と月をもったオブジェクト)を定義してみよう。 class YearMonth attr_reader :date def initialize(year, month) @date = Date.new(year, month, 1) end end 一応値オブジェクトとして定義しているものの、「日付が1日のDate型オブジェクト」」としても外部から認識できる。なら、YearMonthそのものを比較できなくても、保有しているDate型