boboroshi · HackerTrans

vor 3 Jahrendiscuss

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.

boboroshi

vor 3 Jahrendiscuss

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.

boboroshi

vor 3 Jahrendiscuss

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.

boboroshi

vor 3 Jahrendiscuss

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.

boboroshi

vor 3 Jahrendiscuss

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

boboroshi

vor 4 Jahrendiscuss

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.

boboroshi

vor 4 Jahrendiscuss

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.

comments