Thanks for setting this up, Alice! Excited to be here. I've been looking for a community like this.
Hello everyone! 👋 I'm Carol, a full-stack developer based in Portland. Looking forward to learning from all of you.
Great initiative! I'll try to share some deployment and DevOps knowledge here.
Love the ground rules. Simple and effective. Happy to be part of this!
Great list! I'd add: "Read the source code." Rails is surprisingly readable, and you learn so much by seeing how things are implemented.
Number 4 is so important. I spent my first year fighting Rails conventions and it was miserable. Once I leaned into them, everything clicked.
I'd add: learn to use `rails console` effectively. It's one of the most powerful debugging and exploration tools available.
As someone just starting out with Rails, this is super helpful. Bookmarked!
Neovim all the way. The initial learning curve is steep, but once you're fluent, nothing else feels as fast. I spend all day in the terminal anyway.
Same here — Neovim with LazyVim. It took me about two weeks to get comfortable, but now I can't imagine going back.
I'm a VS Code person too. The extension ecosystem is unbeatable and the built-in Git integration is great. I've tried switching but always come back.
I use RubyMine. Yes, it's heavy and it's paid, but the refactoring tools and Rails-specific features save me hours every week.
Zed has been my daily driver for the past few months. It's fast, looks great, and the multiplayer editing is handy for pair programming.
Been considering the switch from Heroku. How long did the migration take you overall?
About a week of evenings to get it fully working, including setting up the VPS. Once it's configured, deploys are a single command. Totally worth it.
I've been using Kamal since 1.0 and the 2.0 upgrade was smooth. The proxy replacement for Traefik is much simpler to configure.
Thanks for the writeup! Would you mind sharing your deploy.yml (sanitized of course)? I'm about to set this up for a new project.
I've started treating side projects as learning exercises rather than products. Takes the pressure off finishing and I still learn a ton.
Having an accountability partner helps. My friend and I check in weekly on our side projects. Just knowing someone will ask about it keeps me going.
I build things I actually need. My best finished project is a meal planning app I use every single week. The motivation is built in.
I set a hard rule: no more than 3 active side projects. If I want to start something new, I have to either finish or officially abandon one first.
This is a really clear explanation. I always struggled to articulate the difference. Saving this for the next time someone asks!
One thing I'd add: Turbo Streams over WebSockets with Solid Cable is incredibly powerful for real-time features. It's like having ActionCable but simpler.
I resisted Hotwire for a long time because I was comfortable with React. After giving it a real try, I'm never going back for Rails apps. So much less complexity.
"A Philosophy of Software Design" is criminally underrated. It's short enough to read in a weekend and it genuinely changed how I approach architecture.
I'd add "Staff Engineer" by Will Larson. Essential reading if you're on the IC track and wondering what comes after senior.
Currently reading "Database Internals" by Alex Petrov. Dense but fascinating if you want to understand how databases actually work under the hood.
I've been doing the same for a small internal tool. Zero issues so far. The simplicity of the infrastructure is hard to overstate.
What about concurrent writes? That's always been my concern with SQLite in web apps.
Good question! With WAL mode (which Rails enables by default now), concurrent reads are fine. Writes are serialized but for most apps that's fast enough. I'm seeing ~5ms per write.
This is what we're using for this forum actually! Works great so far.
I'm in the same 'strategic testing' camp. My rule of thumb: if a bug would wake me up at 3 AM, it needs a test.
I've found that writing tests first for bug fixes is the sweet spot. You prove the bug exists, fix it, and prevent regression. No wasted effort.
We use system tests heavily and they've caught so many regressions. Yes, they're slow, but we run them in parallel and it's manageable.
With CSS custom properties, dark mode is much less work than it used to be. Define your colors as variables, swap them with a media query, done.
I'd say it depends on your audience. Developer tools? Dark mode is essential. Recipe blog? Probably not worth the effort.
The `prefers-color-scheme` media query makes it easy to at least support the OS default. I'd call that the minimum viable dark mode.
It's on the roadmap for this forum! Hopefully coming soon.
Love this idea! I've been building a CLI tool in Ruby for managing dotfiles across machines. It's rough but functional.
I've been contributing to the Rails documentation. Not as flashy as a new app, but it's rewarding to help others learn.
Working on a Litestack-powered analytics dashboard. SQLite all the way down. Will share it when it's ready for demo.
Strongly agree. At my last job we adopted a new database, a new message queue, AND a new deployment platform all in the same quarter. It was chaos.
There's a corollary: you get a limited number of 'innovation tokens.' Spend them where they give you a genuine competitive advantage, not on your deployment pipeline.
As someone early in their career, this is reassuring. I always felt behind for not knowing the latest framework.
I pair for about 30% of my work time and it's the sweet spot. Full-time pairing burned me out, but occasional pairing levels up the whole team.
Mob programming is worth trying too. We do it for architecture decisions and it's surprisingly efficient. Everyone walks away aligned.
Async pair programming via detailed PR reviews gives you 80% of the benefits with more scheduling flexibility. Works great for remote teams.
The `undo` alias is going straight into my config. I've been typing out `git reset HEAD~1 --mixed` like a caveman.
Deletes all local branches that have been merged into your current branch.
TIL about `git log --oneline --graph`. I've been using GitKraken for visualizing branches but this is way faster.
Conventional Commits is worth looking into as well. Prefixing with `feat:`, `fix:`, `docs:` etc. makes changelogs and release notes much easier to generate.
The best advice I got: write the commit message before writing the code. It forces you to think about what you're actually trying to do.
Similar to yours but I use WezTerm and fish shell. Fish's autosuggestions are addictive — going back to bash/zsh feels so slow.
I use `mise` too! It replaced rbenv, nvm, and pyenv for me. One tool to rule them all.
Does anyone use Dev Containers? I've been thinking about going that route for guaranteed reproducible environments.
Congrats on the first contribution! Documentation fixes are hugely valuable. Bad docs are one of the biggest barriers to adoption for any project.
This inspired me to finally look for a "good first issue" tag on a project I use. Found one and I'm working on it now!
Pro tip: many projects have a `DEVELOPMENT.md` or similar doc explaining how to set up the project locally. Read it before you start.
Number 1 is so common! I always add `index: true` to my `references` columns in migrations now. Rails should honestly do this by default.
Actually, Rails does add indexes on foreign keys by default now when you use `references` in a migration! But you're right that older apps often have missing ones.
I'd add: not using `EXPLAIN ANALYZE` (as opposed to just `EXPLAIN`). The estimated vs actual row counts can be very different.
We use Flipper and love it. The UI is great for non-developers to toggle features, and the ActiveRecord adapter means no additional infrastructure.
For small projects, I just use a YAML file that gets loaded at boot. Not dynamic, but dead simple and works with SQLite.
Whatever you choose, make sure you have a process for cleaning up old flags. We had over 200 flags at one point and it was a nightmare.
The `:has()` selector alone is revolutionary. I've been waiting for a parent selector since I started writing CSS 15 years ago.
Container queries changed my approach to component design entirely. Components can now be truly self-contained and responsive.
Don't forget `@layer`! Cascade layers finally give us sane control over specificity. No more `!important` hacks.
Looks solid! Maybe add something about giving credit when sharing others' work or ideas?
I'd suggest adding a note about being welcoming to beginners. Nothing kills a community faster than gatekeeping.
Love it. Maybe also mention that it's okay to say "I don't know" — it's better than guessing and giving wrong answers.
blah
Should he able to just click on the entire post, not just the title
Thanks for setting this up, Alice! Excited to be here. I've been looking for a community like this.
Hello everyone! 👋 I'm Carol, a full-stack developer based in Portland. Looking forward to learning from all of you.
Great initiative! I'll try to share some deployment and DevOps knowledge here.
Love the ground rules. Simple and effective. Happy to be part of this!
Great list! I'd add: "Read the source code." Rails is surprisingly readable, and you learn so much by seeing how things are implemented.
Number 4 is so important. I spent my first year fighting Rails conventions and it was miserable. Once I leaned into them, everything clicked.
I'd add: learn to use `rails console` effectively. It's one of the most powerful debugging and exploration tools available.
As someone just starting out with Rails, this is super helpful. Bookmarked!
Neovim all the way. The initial learning curve is steep, but once you're fluent, nothing else feels as fast. I spend all day in the terminal anyway.
Same here — Neovim with LazyVim. It took me about two weeks to get comfortable, but now I can't imagine going back.
I'm a VS Code person too. The extension ecosystem is unbeatable and the built-in Git integration is great. I've tried switching but always come back.
I use RubyMine. Yes, it's heavy and it's paid, but the refactoring tools and Rails-specific features save me hours every week.
Zed has been my daily driver for the past few months. It's fast, looks great, and the multiplayer editing is handy for pair programming.
Been considering the switch from Heroku. How long did the migration take you overall?
About a week of evenings to get it fully working, including setting up the VPS. Once it's configured, deploys are a single command. Totally worth it.
I've been using Kamal since 1.0 and the 2.0 upgrade was smooth. The proxy replacement for Traefik is much simpler to configure.
Thanks for the writeup! Would you mind sharing your deploy.yml (sanitized of course)? I'm about to set this up for a new project.
I've started treating side projects as learning exercises rather than products. Takes the pressure off finishing and I still learn a ton.
Having an accountability partner helps. My friend and I check in weekly on our side projects. Just knowing someone will ask about it keeps me going.
I build things I actually need. My best finished project is a meal planning app I use every single week. The motivation is built in.
I set a hard rule: no more than 3 active side projects. If I want to start something new, I have to either finish or officially abandon one first.
This is a really clear explanation. I always struggled to articulate the difference. Saving this for the next time someone asks!
One thing I'd add: Turbo Streams over WebSockets with Solid Cable is incredibly powerful for real-time features. It's like having ActionCable but simpler.
I resisted Hotwire for a long time because I was comfortable with React. After giving it a real try, I'm never going back for Rails apps. So much less complexity.
"A Philosophy of Software Design" is criminally underrated. It's short enough to read in a weekend and it genuinely changed how I approach architecture.
I'd add "Staff Engineer" by Will Larson. Essential reading if you're on the IC track and wondering what comes after senior.
Currently reading "Database Internals" by Alex Petrov. Dense but fascinating if you want to understand how databases actually work under the hood.
I've been doing the same for a small internal tool. Zero issues so far. The simplicity of the infrastructure is hard to overstate.
What about concurrent writes? That's always been my concern with SQLite in web apps.
Good question! With WAL mode (which Rails enables by default now), concurrent reads are fine. Writes are serialized but for most apps that's fast enough. I'm seeing ~5ms per write.
This is what we're using for this forum actually! Works great so far.
I'm in the same 'strategic testing' camp. My rule of thumb: if a bug would wake me up at 3 AM, it needs a test.
I've found that writing tests first for bug fixes is the sweet spot. You prove the bug exists, fix it, and prevent regression. No wasted effort.
We use system tests heavily and they've caught so many regressions. Yes, they're slow, but we run them in parallel and it's manageable.
With CSS custom properties, dark mode is much less work than it used to be. Define your colors as variables, swap them with a media query, done.
I'd say it depends on your audience. Developer tools? Dark mode is essential. Recipe blog? Probably not worth the effort.
The `prefers-color-scheme` media query makes it easy to at least support the OS default. I'd call that the minimum viable dark mode.
It's on the roadmap for this forum! Hopefully coming soon.
Love this idea! I've been building a CLI tool in Ruby for managing dotfiles across machines. It's rough but functional.
I've been contributing to the Rails documentation. Not as flashy as a new app, but it's rewarding to help others learn.
Working on a Litestack-powered analytics dashboard. SQLite all the way down. Will share it when it's ready for demo.
Strongly agree. At my last job we adopted a new database, a new message queue, AND a new deployment platform all in the same quarter. It was chaos.
There's a corollary: you get a limited number of 'innovation tokens.' Spend them where they give you a genuine competitive advantage, not on your deployment pipeline.
As someone early in their career, this is reassuring. I always felt behind for not knowing the latest framework.
I pair for about 30% of my work time and it's the sweet spot. Full-time pairing burned me out, but occasional pairing levels up the whole team.
Mob programming is worth trying too. We do it for architecture decisions and it's surprisingly efficient. Everyone walks away aligned.
Async pair programming via detailed PR reviews gives you 80% of the benefits with more scheduling flexibility. Works great for remote teams.
The `undo` alias is going straight into my config. I've been typing out `git reset HEAD~1 --mixed` like a caveman.
Here's one I love:
`cleanup = !git branch --merged | grep -v '\*\|main' | xargs -n 1 git branch -d`
Deletes all local branches that have been merged into your current branch.
TIL about `git log --oneline --graph`. I've been using GitKraken for visualizing branches but this is way faster.
Conventional Commits is worth looking into as well. Prefixing with `feat:`, `fix:`, `docs:` etc. makes changelogs and release notes much easier to generate.
The best advice I got: write the commit message before writing the code. It forces you to think about what you're actually trying to do.
Similar to yours but I use WezTerm and fish shell. Fish's autosuggestions are addictive — going back to bash/zsh feels so slow.
I use `mise` too! It replaced rbenv, nvm, and pyenv for me. One tool to rule them all.
Does anyone use Dev Containers? I've been thinking about going that route for guaranteed reproducible environments.
Congrats on the first contribution! Documentation fixes are hugely valuable. Bad docs are one of the biggest barriers to adoption for any project.
This inspired me to finally look for a "good first issue" tag on a project I use. Found one and I'm working on it now!
Pro tip: many projects have a `DEVELOPMENT.md` or similar doc explaining how to set up the project locally. Read it before you start.
Number 1 is so common! I always add `index: true` to my `references` columns in migrations now. Rails should honestly do this by default.
Actually, Rails does add indexes on foreign keys by default now when you use `references` in a migration! But you're right that older apps often have missing ones.
I'd add: not using `EXPLAIN ANALYZE` (as opposed to just `EXPLAIN`). The estimated vs actual row counts can be very different.
We use Flipper and love it. The UI is great for non-developers to toggle features, and the ActiveRecord adapter means no additional infrastructure.
For small projects, I just use a YAML file that gets loaded at boot. Not dynamic, but dead simple and works with SQLite.
Whatever you choose, make sure you have a process for cleaning up old flags. We had over 200 flags at one point and it was a nightmare.
The `:has()` selector alone is revolutionary. I've been waiting for a parent selector since I started writing CSS 15 years ago.
Container queries changed my approach to component design entirely. Components can now be truly self-contained and responsive.
Don't forget `@layer`! Cascade layers finally give us sane control over specificity. No more `!important` hacks.
Looks solid! Maybe add something about giving credit when sharing others' work or ideas?
I'd suggest adding a note about being welcoming to beginners. Nothing kills a community faster than gatekeeping.
Love it. Maybe also mention that it's okay to say "I don't know" — it's better than guessing and giving wrong answers.
blah
Should he able to just click on the entire post, not just the title
Need to be able to edit posts and comments
Order of comments within a post?
I think it should be reversed
adding a comment
test editing the comment
bump
test
test
another test
thx
in app notifications - thanks
ok