はてなブックマーク

年月の範囲を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

テストが実装に依存する... 詳細な手続きを一箇所に羅列せず、オブジェクトのコミュニケーションで表現されたコードは見ていて美しいものです。例えばこんなサービスを考えてみましょう。 class SaveUserAverageAgeService def self.call average_age = User.average(:age) Analysis.create_record(average_age, Date.today) end end Userモデルにユーザーの平均年齢を計算してもらい、分析テーブルに現在時点のデータを保存するサービスを想定してみました。(実際には平均年齢以外に男女比とか平均課金額とか、そういうデータも一緒に集計すると思いますが、ここでは説明のため省略しています。) このサービスのテストコードを書けと言われて、ぱっと思い浮かびますか? 初心者でも思いつくのは、 U

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

材料 オブジェクト指向※1に詳しく経験のあるリーダー：1人 オブジェクト指向で書かせたいメンバー※2：少々(1〜4人) イチからチームで作れる大きさのプロジェクト※3：1つ ※1 オブジェクト指向でなくDDDでもデザパタでも代用可能 ※2 「オブジェクト指向って美味しいの?」レベルのメンバーでも十分可能。設計に興味があるメンバーがいると仕上がりが速くなります。 ※3 既存の設計にあまり依存せず、設計の自由度が高い案件だとよりよく仕上がります レシピ 1.「今回のプロジェクトはオブジェクト指向で書きます。異論は認めん」とリーダーが高らかに宣言する すべてはここから始まります。ポイントは、リーダーの絶対王政であること。 プログラムを手続きでしか書いたことないメンバーは、そもそもオブジェクト指向で書くと何がいいのか体験していません。なので、理論を教えて事前に納得してもらうより実際に見せたほうが圧

20代で圧倒的に成長する人とパッとしない人の決定的な違い 2人の新入社員がいた。 同じ学歴レベル。 同じプログラミングの技術力。 同じ採用基準に合格。 それでも、入社から1年後、2年後、5年後になると、一人はバリバリ成長してチームリーダーを任されている一方、もうひとりはいつまで経っても大きな仕事を任せてもらえない…。 これはフィクションだが、こんなことはエンジニア業界に限らず日本中いたるところで発生している。 二人を分けた違いはなんだろうか?それは、、、 高い仕事の基準を自分に課していたかどうか。 君が20代で圧倒的に成長したいと本気で考えているなら、心して続きを読んで欲しい…。 仕事の基準を高く持つとは? いきなり抽象的な精神論を繰り出しても仕方ないので、具体的なシチュエーションを置いてみる。 例えば、明日からあるタスクを先輩社員と一緒にペアプログラミングでやることになったとしよう。凡人

本記事の目的 「テーブル設計、ほんとにこれがベストなのかな...?」 と思うことありますよね。シンプルなテーブル構造だと普通に正規化すれば問題なく運用できるんですが、ビジネスルールが複雑だったりするとあえて正規化を崩した設計を行うこともあります。ですが、「正規化を崩して何が嬉しいのか?」を論理的に考え、メリット・デメリットを考慮することによって、うまくトレードオフスライダーを調整することができるようになります。本記事では正規化も含めて、それぞれの正規化崩しがどのような目的のもと行われるのかを整理してみました。(なので、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型