boboroshi

Excellent debrief and thanks to Systen76 for showing how it’s done. The SSR thing may be a JS ecosystem but I feel that’s a weird cop out at the end of an otherwise great AAR. We’ve been rendering results on the server for decades with caching. Can someone provide some insight on the difference here as I feel this is a knowledge gap on my part.

This is a big mess. I'm sure this is probably the goal for really large companies to amortize expenditures over multiple years. But for a smaller shop, this will just reduce the amount I can spend on development.

Yes, it would balance out eventually in 5-6 years, but this would be painful for the near future and require a change up in what we're capable of doing, since so much more "revenue" is going to tax payments.

These really are the precursor to design systems of today. It's not just a brand guideline, but it's an implementation guide to be used across various platforms (Dodge, GM, Ram, etc) to create a unified visual experience.

There is also an element of how government purchases services from vendors. There is some weird setup where an honest estimate often will not be awarded the contract, as it is too high. A vendor will intentionally bid low, and then change order the job to way over the "honest estimate" price.

Vendors need to be rated and penalized for this kind of bait and switch, but unfortunately there is no downside to low ball the bid, and they often win and continue to win contracts.

This looks amazing. Definitely something I'm going to dive into and level up on my SQL skills.

Location: Charlottesville, VA Remote: Yes; Have worked remote for most of my career Willing to relocate: No, occasional travel/on-sites okay. Technologies: UX, Rails, HTML/CSS/SCSS (by hand), some experience in Stimulus/Turbo, React, Angular Résumé/CV:https://www.linkedin.com/in/johnathayde/ Email: john at athayde dot com

I'm a broad-based Senior IC UX/Visual Designer, Mid-level Rails dev, and long term brand/marcom designer. I've build cross functional design/dev teams (InPhonic, LivingSocial) and can work between design, product, and engineering comfortably.

Co-Authored "The Rails View" for Pragmatic Programmers, and have spoken widely in the Rails and JS/React spaces on UX for Developers, Pattern Languages, Design Systems, and Product Development concepts.

Immediate availability (31 Aug 2022) due to a restructuring.

Monoliths can be great or a disaster, as can total services setups. We took a monolith built by a small team into scores of services across 4 teams of 150 engineers, even implementing some of them in Scala (this was 2012ish). On the internal tools side, we created a gem and later a bower package (so vintage) that was a bootstrap-derived design system that worked across almost all 30 internal tools apps & services. I know other teams did the same (at least consumer and merchant), but I didn't work on those projects so I can't speak to them.

I've seen great ruby/rails code and I've seen abysmal ruby/rails code. A lot comes down to who wrote it and if they ever refactored the smelly parts.

After 20+ years, I often see that no one likes to refactor the smelly stuff until they're forced to, and we often end up working with a cool racketball of code covered in 2' of duct tape patches.

Go is the new hotness, as was Rails at one point, and in the near future it will be something else. There's a strong neophillic bent to most developers. It's a lot more fun to work in something that's new and evolving and solving crazy problems than something that is stable.

These are all tools in the tool kit. Use what lets you ship.

Compass Rails could use some help: https://github.com/Compass/compass-rails

There's also some issues with Ruby 2.0 support in it and in Compass itself, if memory serves...

Good design starts with good usability. There are no tech shortcuts (bootstrap or otherwise) to this. Your application's interactions are probably unique. There may be some design patterns (God, I hate the abuse of that phrase) that apply.

Bootstrap, etc are simply tools used to implement interfaces. They are not magic bullets. Design, like programming, takes time. It's not about gradients or drop shadows, but those are tools used in design.

It's often an iterative and collaborative process. It is not, however, "Agile". You can't design the interaction for a piece without looking at the whole.

Find someone who cares about interface, interaction, and usability. Ideally they can do graphics, html, and css. Ideally they've done some user testing before or are just really good at getting users. If you find someone like that, be prepared to pay. The good ones are few and far between and all that I know are gainfully employed or have hourly rates exceeding $200USD/hr.

If you want to learn more about this, there's a library of stuff out there. But just reading a bunch of books won't suddenly make your UIs prettier. But if you implement what you learn, it may improve their functionality. And that's far more important.