391–400 of 490 posts
Earlier quoted context omitted.
Did you learn English by reading the dictionary top to bottom? I’m gonna go ahead and guess that no, you didn’t. You learned English by being surrounded in it and practicing.
Programming language is not natural language, think more how did you learn math?
Not once did I read a textbook front to back.
Earlier quoted context omitted.
What are some specific “magical things” that are not mentioned in the rails guides? There’s always room for improvement and the documentation is an important part of the framework.
I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly. https://github.com/heartcombo/devise#getting-started
Earlier quoted context omitted.
I've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…
Want to know what’s available somewhere? Write “public_methods - {}.public_methods” to stdout.
Working in a Rails based startup that took the same approach as OP, then at one point understood that we need React in the frontend, and a few years later the development process is a pain: * Weird pockets of react everywhere (data-something-something) with tons of JSON just being interpolated into attributes. * Webpacker and other rails magic is required for building the frontend * Frontend and backend are tightly c…
Can you elaborate on this a bit? Are you saying that an SPA with React (+ other server-side pieces in NodeJS?) would have been the better choice than the Rails + some React mess you wound up with? What about sticking with just Rails, no React?
Thanks for your time.
I enjoy building SPAs, but I often wonder if my joy comes from having built something, or is it just seeing the little virtual ball make it's way to the end of the overly-complex Rube Goldberg-like contraption of cloud services, NPM packages, bundlers and frameworks my product is built upon.
Ui state managegent has to live somewhere. All of the solutions that try to do it server side I tried eventually smear it all over the place.
Earlier quoted context omitted.
I was going to say the same thing and figured someone else already had. People would often ask how I knew so much about rails and, ya, the answer is that I read the guides. They are extremely readable and it doesn't take that long. Like a couple of days. You might be surprised how much is retained by just reading through them, even without actually trying things out as you go. I would like to stress: read the guides,…
I've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…
Call me cynical, but the problem with this argument is that professional software development is about making something that fulfills a set of requirements, and ideally is modular+generalized enough in its design that it can be reused in the future to reduce future development time+costs.
With this in mind, I can see why the Rails documentation wouldn't really care if you learn how Rails works- all they care about is that you know how to use it.
This isn't to say that the desire for greater understanding is bad, just that it's not an effective way to keep an aging, tried-and-true web framework relevant.
Earlier quoted context omitted.
Junior dev here (but a career changer at aged 35), I initially learned Ruby/Rails at bootcamp 80% of the market is looking for some React + backend and there's a huge pressure to learn such an SPA framework but I've steadfastly refused and have stuck to 'full-stack' Rails. Luckily there's a resurgence going on for Rails and I think it's going to last. Boring always wins in the end
I'm your polar inverse: I'm 33 but started coding when I was 4, I've just never worked as a developer (at least not on a team; I've done freelance), and I'm debating making the jump as inflation starts creeping up. I run into the opposite problem: I've played around in frameworks but I don't have the 'years of experience' with them so I worry my resume is going straight in the trash.
SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs). SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects…
Have you tried to implement interaction-rich applications such as calendars or text editors with server-side rendering? You won't be able to recreate the UX an SPA can afford, regardless of revenue.
Slight offtopic, but is Rails again on the rise? I see a lot of startups using it. Can someone who is more into startups share insights?