I have some new projects to share with you! The quick summary is:
Unclear! I'm a human being after all, complete with a diverse set of motivations. I want to live a pleasant life, take part in our grand social conversation, find interesting people to talk to, fiddle with fun toys, follow my curiosities, make lots of money, gain respect from peers, etc, etc.
More singular, perhaps, is my motivation for publishing red pear now: I want to share as many interesting or useful ideas I've had during this process with as wide an audience as possible. And I'm hoping that real, instantiated software can help facilitate this discussion. So red pear!
red pear is an online editor and platform for building ruby/sinatra apps. The target audience is either experienced developers who have a couple of hours on a weekend to build an app and don't want to spend that time setting up dev & prod environments, or brand new developers for whom this setup process is a serious obstacle to actually coding.
red pear is simple:
GET /about or POST /users/:id/edit.Each app gets compiled into a sinatra webserver hosted and running under redpear.dev: one subdomain for the dev instance and one for the prod instance.
People have been surprised by how fast this deploy is. Most function-as-a-service companies use VMs to sandbox users' code. VMs take a while to spin up, even the fast ones. Instead I'm using a user-space sand-boxing tool called bubblewrap, which only adds a few milliseconds. I highly recommend it.
Aside from that, there isn't too much to say feature-wise — give it a try!
I'm proud and happy that red pear exists, both at redpear.dev and in whatever very niche zeitgeist it happens to contribute to. But I don't think it's something that I can or want to make money extending and improving. Aside from bug fixes and server maintenance, I won't be focusing on it in the future. It's open source if people want to run with that!
stream as a server-side ruby value that you can embed directly into a template: stream = Stream.new
return MyTemplate(messages: stream)
{{#messages}}
<p>• {{content}}</p>
{{/messages}}
... and many more ideas! Talk to me if you are thinking of building something similar.
walnut (github) is a ruby DSL made for storing data in red pear. The goal is to make interacting with persistent, relational data much easier. It works like so:
We can create a walnut object by "calling" a ruby symbol:
def a_function_in_red_pear()
# ...
alice = :person.(name: "Alice")
# ...
end
We don't have to define a schema for :person ahead of time; we could have used any other tag, :dog, :plant, etc, and it would have worked just fine. In addition to being stored as a variable alice, this :person is immediately written to disk.
We can query all the people:
irb> :person.all
=> [:person.(name: "Alice"),
:person.(name: "Bob")]
We can get a reference to a person by indexing into this array:
irb> alice = :person.all[0]
=> :person.(name: "Alice")
or by filtering first:
irb> bob = :person.findmany(name: "Bob")[1]
=> :person.(name: "Bob")
We can update a person as you would a normal ruby object:
irb> alice.friends = [ bob ]
...and this is instantly reflected on disk, no "save" step needed. We can then re-query all the people and see an updated result:
irb> person.all
=> [:person.(name: "Alice", friends: [:person.(name: "Bob")]),
:person.(name: "Bob"),
Bob is stored in Alice's friends as a reference, so if we change Bob's name, it'll change everywhere:
irb> bob.name += ' Ross'
=> "Bob Ross"
irb> :person.all
=> [:person.(name: "Alice", friends: [:person.(name: "Bob Ross")]),
:person.(name: "Bob Ross"),
That's pretty much everything. Fun fact: I use walnut as the storage API for red pear itself. It's been really easy to work with! Though it should be said, red pear has just grown large enough that I am feeling the need for a standardized schema, instead of the ad-hoc dynamic data walnut gives you.
This dynamism was a motivation for creating walnut in the first place; it's much nicer not to have to write a schema upfront if you're only writing a small app.
Okay but traditional nosql databases like mongo don't require schemas, right? And what about key-value stores? Well, joins in mongo are super verbose. (Sql too for that matter.) And joining across prefixes in a key-value store is a dreadfully manual process.
This is what walnut does best: it makes joins very easy. You can quickly traverse relationships to get your friend's friend's dog's name, and you can do that without having to learn another language or syntax. It's all just mapping, indexing, and filtering in ruby.
Thanks for reading! Try out red pear if you like; I'll be sure to address any questions or errors you might have.
And I've got some more fun projects in the works! Subscribe if you'd like to keep up to date:
See you next time!