121–130 of 264 posts
Earlier quoted context omitted.
Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.
better than postgresql? and what would that be?
Like any language/framework, it has its warts and its weirdness. There are times when it can be very frustrating to deal with it all. But I've felt that feeling working across multiple paradigms, and I'm convinced it's just a reality of software development.
If you're deep into microservices, Rails can be a tough choice, I'll admit. It really depends on your use case. A small-medium sized startup can get a lot done with just a Rails app if your workload is primarily IO based.
I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was…
Earlier quoted context omitted.
If you haven't used JSF then you haven't truly suffered yet. There are worse things in the Java ecosystem than Spring Boot.
I know all too well ); Only three years ago I contracted for an insurance company for JSF, and worse, using portlets under Websfear. Well, it payed the bills.
I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was…
Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.
Because every web app is the same CRUD app, right?
Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.
Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress. Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just…
Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB
Groovy is a great language, with the best from dynamic languages and yet still very similar to Java. I would say there is no learning curve for Java developers with Groovy.
Grails has also been highly optimized the last few years and runs great on systems with 1 vcpu and 256MB RAM. Grails also has a great and friendly community, come and say hello in our Slack channel https://grails-slack.cfapps.io/
I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was…
Earlier quoted context omitted.
I recommend to not use an ORM. Really, with a modern language, an ORM is mostly redundant. If on Spring boot, simply use JDBCTemplate and TransactionTemplate to deal with raw SQL queries and transactionality. Get rid of all the annotation magic around this. Then you need a bare minimum of mapping code. Mostly this boils down to a single line of code to call the relevant constructors while you extract columns from you…
I have dynamically generated queries that span over 200 lines. Doing this without a query builder is pure madness. It doesn't matter how modern your language is, manually concatenating SQL shouldn't happen in 2019.
Often long queries with convoluted joins are a good sign something is wrong with your table layout. ORM lets you get away with some bad design but it always catches up with you eventually.
Earlier quoted context omitted.
Young developers (as one myself), tend to be overly focused on what makes them attractive as a developer. Kinda like an overly insecure teenager. So they pounce on any framework or tech that makes them desirable to an employer. Rails isn't hot, so it won't get them a job so they won't learn it.
That's flat out wrong. As a Rails developer, I have a weekly stream of recruiters trying to get my attention.