(no title)
tlear | 3 years ago
It blows my mind.. really it does, how did we not fix this shitshow? We have automated test on top of automated test on top of automated tests but web is so messed up we still can't have shit working reliably.
tlear | 3 years ago
It blows my mind.. really it does, how did we not fix this shitshow? We have automated test on top of automated test on top of automated tests but web is so messed up we still can't have shit working reliably.
emodendroket|3 years ago
magicalhippo|3 years ago
How many are
a) highly nontrivial with hundreds of windows/screens, many with with multiple searchable grids, custom lookups, per-screen user-definable tab-stop order etc etc
b) reliable enough that the users can enter all the data they need without looking at the application (ie no missed keypresses or focus changes etc)
c) being developed, maintained and operated by a team of <10 devs?
Honest question, if you know then do tell! I'd love to hear how they're doing it.
Like, this year changes to gov't systems means we'll have to implement about a dozen new complex windows/screens, along with all the backend logic. We get the specs about 6-9 months before go-live, so it's not like we have a full year either.
cxr|3 years ago
By "web" you mean "professional standards". There's no excuse for not being able to put out something that doesn't result in a blank page in Safari. The Web has not gotten more difficult to publish for. It's not an SDK that forces you to rev your codebase from time to time if you want things to keep working*; the stuff that worked last year and 10 years before that would still work today. The developers chose to make these changes, and the client chose to accept it.
* barring some pathological circumstances like previously having decided to depend on undefined/non-standard behavior, but that's (a) gonna be a problem anywhere and not unique to the Web, and (b) not remotely essential for publishing working stuff that you want to show up in a Web browser