Hacker Newsnew | past | comments | ask | show | jobs | submit | kenn's commentslogin

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.


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.


Looks pretty good actually (from the screenshot), you even have an iPhone app and everything. Why not just charge a small something, even if it's only to get you a nice side income? Somebody mentioned $5/month as a reasonable price for something like this. For me personally that would make me less hesitant to sign up as currently it would seem you could pull the plug any moment. Unless you like the idea of being able to pull the plug at any moment of course, which of course is your prerogative.


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.


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



Nice. I really like the UI for both of your sites. Good luck.


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.


Ok, let me drill down into to a little bit. You say, "equity has a peramanent effect". But don't most equity contracts have a vesting period, and thus if you fire the engineer before the vesting period is up well the person forfeits that equity?

... seems like this is not so peramanent. Unless I'm misunderstanding something and need some education in this (and if I am, please let me know, as I've had this happen to me on at least one occasion and maybe I'm owed some compensation after all)


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...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: