There's something new coming in Ruby 3.2 this Christmas that I can't wait to
start using in all my projects:
Ruby 3.1 [sic] adds a new core class called Data to represent simple immutable
value objects. The Data class helps define simple classes for value-alike
objects that can be extended with custom methods.
While the Data class is not meant to be used directly, it can be used as a
base class for creating custom value objects. The Data class is similar to
Struct, but the key difference being that it is immutable.
It'd be easy to look at this and conclude that this is just the same
Struct we've been using for
decades, with the added constraint that it's immutable. On the other hand,
that's a pretty important constraint!
But if you read the pull request,
there are some serious quality of life improvements over Struct, like built-in
translation of positional arguments to keyword arguments, which allows for
easy-to-define default values:
Measure = Data.define(:amount, :unit)
Measure.new(1, 'km') # => OK
Measure.new(amount: 1, unit: 'km') # => OK
Measure = Data.define(:amount, :unit) do
def initialize(amount: 0, unit: 'cm')
super
end
# imagine other elucidative methods here
def metric?
# …
end
end
This is great news for people who go out of their way to separate their code
into two categories: units that implement feature logic and things that
represent values. The units implementing application behavior have no state and
the values they receive and return are nothing but state. Adopting this
approach rigorously transformed my programming practice, allowing for clearer
thinking and making progress more predictable.
It's exciting to see Ruby core continue to make consistent iterative progress
year after year!
I've been a VR gaming enthusiast for years (having owned the Rift DK1, the HTC Vive and Vive Pro, and the Valve Index before settling on a Quest 2), so I preordered the Meta Quest Pro to see what all the fuss was about.
The Quest Pro’s resolution is 1800 x 1920 pixels per eye, roughly the same as the Quest 2’s 1832 x 1920 pixels. In theory, it provides better contrast and a very slightly higher pixel density per eye, but comparing both devices head-to-head, I was hard-pressed to tell the difference. It’s still grainy enough that images look all right, but small text is fuzzy.
I, for one, decided to return this thing within 5 minutes of unboxing it.
The $1500 Quest Pro makes trade-offs that add up to a significantly worse headset than its (until recently) $299 predecessor. The Pro's pancake lenses improve the field-of-view slightly, but they also magnify each pixel more, reducing the sharpness of the image. Placing the battery on the back helps balance the Pro's weight distribution, but it also forecloses the possibility of 3rd-party straps—which matters, because the Pro is much less comfortable than my Quest 2 with this excellent $35 strap. The Pro's open design (it barely obstructs the user's peripheral vision) makes it a statement piece that VR doesn't have to be antisocial, but its "wings" let in so much ambient light that it makes most games instantly nausea-inducing.
Do not buy the Meta Quest Pro.
Worlds and Workrooms are available for the Quest 2 and Quest Pro alike, but Workrooms is particularly aimed at Pro users. And—there’s just no nice way to put it—it’s one of the worst apps I’ve ever used.
This is what really kills me about this product, though. The hardware is pitched as one's entry point to "the metaverse", but there is no metaverse! Just a couple broken apps. They're so bad that management can't even force the programmers making the apps to try using them.
Superficially, sure, Horizon Worlds is a worse version of RecRoom and Horizon Workrooms is a much worse version of BigScreen VR. On a deeper level, though, this failure is emblematic of what large companies often get wrong when they undertake greenfield software projects. They dream big, staff big, and then start building.
Ready. Fire. Aim.
One way I think about this is that almost every stimuli that a very small team building a very small thing encounters amounts to direct product feedback in some form or another. Even if the team members themselves are the only users, the feedback loop couldn't be tighter. Change a thing. Try it out. Repeat.
The larger a human organization surrounding a product grows—especially when it outpaces the maturation of the product—the less attention will be paid to the product itself. That attention will instead be diverted to the superlinearly-growing needs of all the humans (logistics, consensus-building, rework) and the affordances they demand of the product to accommodate so many people (modularized design patterns, internal tooling, service orchestration).
Big teams don't result in successful products, but successful products sometimes result in big teams.