kenn

Experienced solo Rails dev here.

I'm on Remix / Drizzle ORM / Render.com / Render Postgres / Cloudflare R2 / DaisyUI + shadcn/ui these days.

Drizzle can be a bit tricky if you're coming from ActiveRecord but once you have your own helpers with a base class that implements common method such as find_by({ key: value}) / create({ data }) / update(id, { data }) / delete(id), things get better.

Render is really good - you don't need any specific configs, just set env vars on their dashboard and git push to deploy. Simpler and better than Heroku workflow.

You can take a look at https://github.com/remix-run/blues-stack to learn how you'd manually implement cookie-based auth on this framework.

Remix is the closest thing to Rails in the JS ecosystem IMO

It would be slow on MySQL, though.

If you EXPLAIN that query, it's a DEPENDENT SUBQUERY which has to fetch N*M records. It would be mitigated if the columns are property indexed, but two separate queries (N+M) just as eager loading would be faster and more predictable than nested scans in terms of IOPS.

That works, but what if there are thousands of comments? Initializing N*M AR objects could be even slower than N+1 queries.

I wish if we could do something like:

has_one :approved_comments_count, -> { select(:post_id, 'COUNT(comments.post_id) as comment_count').group(:post_id) }, class_name: 'Comment'

and

posts.includes(:approved_comments_count).map(&:comment_count)

This is actually like JSON, but with better parse-ability and aggregate-ability by UNIX commands.

Thank you. I think you made a good point - by not charging I may be actually making people skeptical. We even have a vibrant developer community on bots and extensions, but it's barely known (shit, I realized that it's not even mentioned on the top page). I'll have to come up with some turnaround ideas.

As a founder of http://lingr.com, I know firsthand how hard to build a chat app and make it sustainable. I've been working on it since 2006, first as a startup, then as my personal side project.

I've learned to not invest too much on the project, staying with the minimum server cost, and that's the only sustainable way for me. In fact it costs me almost nothing and users have built trust on me for running it for 6 years.

I'd give her tons of credit for trying to turn it into a real business. That's what I've been failing so far, or maybe I just don't even have the guts to do. I admire her courage and thus feel really sorry.

Hopefully I'll find another course, who knows.

The title is misleading. They will no longer accept new signups, but continue to work.

SaaS. http://dumper.io/ and http://uptimer.at/

Validate if he/she's a good fit for your team first. Usually it takes time. Equity has a permanent effect and you don't want to make a decision in haste.

I wanted an easy-to-use backup service that just works, but everything I was able to find sucked. So I created one myself. :)

As to MongoDB, in case you only have two members in a replica set, you add an arbiter, not strictly three members.

An arbiter is indeed a lightweight mongod process that doesn't have storage, and should be added to break the tie when you have even number of members. I like the MongoDB's design, and it is probably optimal for 99% of use cases.

There are three key concepts: Split-brain, Quorum, and Fencing. I find this article fascinating.

http://techthoughts.typepad.com/managing_computers/2007/10/s...

I wanted a website monitoring tool that just works, but every tool I could find sucked. So I created one myself. :)

Randomness is an interesting topic indeed.

For instance, up until 2012 introduced with Ivy Bridge, a true hardware-based random number generator hasn't been available to the masses. (http://en.wikipedia.org/wiki/RdRand)

what we believe to be random may not be, and I've seen UUIDs generated on cheap mobile devices can easily collide when their clock battery is dead.