He's been saying basically the same thing for years: "We have amazing products in the pipeline".
"Really terrific products coming, believe me! Everyone will love 'em; even the Jetsons will be stunned how futuristic they are. Boy Elroy is still floored from the greatness of the prototypes. Bing bing, bong bong, Wham! bigly shocked. I and I alone can invent the future, and #MakeFutureGreatAgain!"
Say something "offensive" in public and watch a wild-eyed mob that makes a witch-burning look tame come after and try to make sure there is "no place in society" for you.
If you shout repeated ethnic slurs to the stranger next to you on the subway; sorry, but you deserve to have your clock cleaned by the crowd.
Predicted response: "Fake bot, totally rigged, believe me! I know more than these bots, I'm a technical expert. They merely echo lyin' CNN, any loser can do that. Build a bigly firewall around those yapping rusted toasters that nobody listens to. Lowest ratings of all machines ever. My desk's diet Coke button has better ratings."
HTML et al is fine for CRUD, unless you want it to be fancy-pantsy. Then you have to use too much JS.
I have to disagree. For one, it lacks common GUI idioms such as tabbed panels, a decent multi-selection (Ctrl-click is awkward), a combo-box (optional pull-down), collapsible trees*, drop-down menus, editable data grids, and others. You can emulate these with JS/DOM/CSS, but that creates the JS-reliance problems I talked about.
The difference is that using JS, you can do smart form validation before submitting, saving the trouble of making irrelevant round-trips to the server.
The problem is you have to duplicate the validation logic on both client and server then because JS validation can be bypassed. DRY sin. My rule of thumb is to do easy validation or common validation on the client side also, but if it has complex logic and is relatively rare, then just have it on the server. Don't waste duplicate code on rare things.
* The branch lined look in File Explorer for Windows 2000 was easier to read. Without the lines it's hard to see levels. I don't know why MS did away with them.
awesome. It was good software that hasn't needed to be "updated" every other day like modern software is.
What could one build it in today that won't be considered obsolete and "really uncool" within 7 years? The clothing fashion industry changes slower.
And it's a lot more coding and fiddling. The same CRUD app done today takes 5x the human work. Our 1 Oracle Forms programmer does the job of 5 MS-MVC'ers, in like 1/5 the time with 1/5 the total typing and 1/5 the total code. It's ugly but efficient and practical. We de-vovled,Yubba Dubba Doo!
Sure, one could tune/factor/trim a modern stack to fit shop conventions tighter, but management is afraid a new hire would then take longer to learn it; so we stick closer to out-of-the-box configurations. Plus, the Web is just clunky for productivity desktop CRUD apps. Faking it with AJAX et. al. just makes a maintenance mess.
I'm waiting for some kind of new standard to come along and rescue us from the bloat and hell of HTML/CSS/JS/DOM. (It's fine for web-pages, but sucks for CRUD.) I've been kicking around using dynamically generated Lazarus GUI's to make a proof-of-concept GUI/CRUD browser. In other words, use Lazarus's dynamism to make a "GUI Browser". A GUI markup language would define an app's GUI and communicate events between the server. (Note it's reinventing Oracle Forms's client "browser" more or less. 5!)
If I give it a hip name, maybe old will be new again? "Rich UIX Productivity-Enhanced Browser++"? "Profitron 9000"? I'll fib to PHB's that it uses quantum parallel deep AI edge cloud blockchain networks.
Browser caching has been a source of many headaches in our org with regard to CMS's and dynamic web applications. You can put header tags that allegedly turn off caching so users always see the latest, but they don't always work right on all content types (HTML, images, CSS, JavaScript, PDF's, etc.). All browser brands we've tested have at least one caching bug.
If browser makers haven't perfected current caching, then this new fancy-ass caching will probably have even more bugs.
I was mostly addressing UI issues, not how to force/encourage people to upgrade timely.
Before I evaluate the UI implications of forcing, we first have to agree on if, how, and when to force upgrades. As working terms, let's consider these categories of updates:
1. Critical security update -- Based on likely or highly dangerous threats. 2. Non-critical security update -- Attack/malware preventions that are deemed to be against rare actual threats or that have mild consequences 3. Feature updates & fixes -- Unrelated to hacking or malware
"Remind me later" or "ask me tomorrow" -- can, and will be pushed infinitely.
I don't think that's very common, but it is the user's prerogative if they really want to keep ignoring updates. Windows should give a decent warning about skipping critical security patches, but ultimately it should be up to the user.
Install upon shutdown / startup -- only updates in the event of a power failure.
Most home users shut down while at work or out. If a few days do go by without a restart, another reminder can pop-up. (I'm assuming Home Edition here. Also, Windows tends to get funky if you go a few weeks without a restart.)
A better solution would be updates that don't need reboots.
That would be nice, but MS would probably have to completely overhaul Windows to bring that about. Not gonna happen in my lifetime.
I agree, I have found the prompts/options confusing. It has end up rebooting on me in the middle of a session. I had thought it would prompt me first if I asked for "install at a later time". Not so. Other systems give you a count-down clock, such as "Starting installation plus a restart in 120 seconds. Click here to cancel install..."
How about a menu such as:
Windows updates are ready, which will require a restart. Estimated install time is 7 minutes. Your options are as follows: - Install now - Remind me later* [brings up dialog to select reminder period] - Install upon shut-down - Install upon next start-up - Install at a specific time* - Specialized options* [for throttled networks etc.] - Help with install timing
I often want "remind me later" because I'm yan... uh, doing something. Therefore, a nice touch would be to have a menu option which echos my prior delay time or selection. Example:
- Install now - Remind me in 24 hours - Remind me at a later time [changes default] - etc...
In this case, it echos my prior delay period selection, "24 hours". People tend to use the same options over again. (If I don't use the PC longer than 24 hours, then it should remind me upon next login.)
Well, I agree that if one settles on a particular set of conventions, R-on-R can eventually be tuned to be productive, but it takes longer to get to that stage.
One problem with data dictionaries is how to override the defaults for specific problems...
Clarification: I meant specific spots or areas of the application, not "problems" in the puzzle sense. An example would be for a particular listing were screen real-estate is at a premium such that I want the column title to be "Emp. No." instead of "Employee Number". A systematic way is needed to locally override the default title.
Also a way is needed to create dummy columns for specific needs that are not necessarily bound for the database. And the sequence of the fields often needs custom re-ordering. I found fairly clean ways to deal with such, but they are too strange to the uninitiated. Others are used to replicate-and-change.
Any skilled developer already has written code that writes code for them based on patterns they use that need repeating. The most common being an ORM. The skilled developer designs the database and then the code generates the code so that the developer does not need to hand code a bunch of repeating patterns.
I don't understand why data-dictionaries are not used more. Automatic code generation speeds up initial development, but is still difficult to maintain, as you have to sift through auto-generated verbosity to change things. Why can't I describe the field "employee number" in one place, with its database name, title, min size, max size, validation type etc.?
You are advocating auto-replication instead of true DRY. To me, that's auto-bloat.
One problem with data dictionaries is how to override the defaults for specific problems: the "delta problem". With auto-bloat, you just change the local copy for variations.
I've found ways to deal with the delta problem of data dictionaries using PHP arrays and some "helper" functions, but this approach isn't mainstream. The rest of the shops are addicted to auto-bloat instead. I don't get it. Habit?
A distinction should be made between easy to learn and easy to use. Easy to learn means the learning curve to decent productivity will be shorter. Easier to use generally means it's less hand and eye movements to get what you want, although it may take longer to learn.
Granted, the terms are often commingled, but I seperate them here at least as a working definition.
To some extent one can achieve both by making the language or tool closer to the domain. The tool's objects/parts then are conceptually closer to the end user's (domain) objects and parts so that there's less translating/converting back and forth between domain usage and tool/language parts. (This includes both the desired UI, and domain entities such as employees, vendors, products, etc.)
Bad frameworks, standards, or languages create artifacts that have nothing to do with the domain. For example, with Web programming one often has to consider a "post-back" stage where the form is redrawn if there is a data entry error, along with error message(s). The logic to redraw is fairly different than the logic for the first draw. This creates an extra "technological artifact" that didn't usually exist with desktop-oriented tools because of their stateful nature. (Sure, you can emulate such with AJAX, but AJAX has its own warts, which I won't go into here. And don't even get me started about "responsive" UI's; I'd rant for days.)
Visual Basic Classic-like tools were on the right track, in my opinion, especially when they began perfecting database interfaces. But we mostly abandoned them and started over with something odd from outer space.
For custom CRUD apps, what used to take one hybrid programmer/analyst in the late 90's with desktop IDE's now often takes 4x the staff. It's a lot of cross-module (re) wiring-together busywork.
Sure, the Web made deployment (mostly) easier, but made development harder. And, MS has improved auto-deployment of Windows apps such that it's almost seamless.
Many shops got fairly close to the 90's with MS Web Forms, but then got spooked MS was going to pull the plug like it did with VB6, leaving them without a migration path. So they switched to MVC, but it's more code cross-wiring busywork. (Division of staff by tech specialty doesn't make sense on a small team.) And it's still makes crappy space-wasting UI's compared to desktop GUI's.
I'm not sure the trade-offs were logically weighed; people just hopped on the Web etc. bandwagon because everyone else was, and everyone fears being stuck on Legacy Island. Something is bigly wrong.
Fear of obsolescence increases the speed of obsolescence.
Slashdot Mirror
"Really terrific products coming, believe me! Everyone will love 'em; even the Jetsons will be stunned how futuristic they are. Boy Elroy is still floored from the greatness of the prototypes. Bing bing, bong bong, Wham! bigly shocked. I and I alone can invent the future, and #MakeFutureGreatAgain!"
(sorry, couldn't resist)
iFan
If you shout repeated ethnic slurs to the stranger next to you on the subway; sorry, but you deserve to have your clock cleaned by the crowd.
Predicted response: "Fake bot, totally rigged, believe me! I know more than these bots, I'm a technical expert. They merely echo lyin' CNN, any loser can do that. Build a bigly firewall around those yapping rusted toasters that nobody listens to. Lowest ratings of all machines ever. My desk's diet Coke button has better ratings."
Now angry RTFM neck-beards will be out of jobs.
I have to disagree. For one, it lacks common GUI idioms such as tabbed panels, a decent multi-selection (Ctrl-click is awkward), a combo-box (optional pull-down), collapsible trees*, drop-down menus, editable data grids, and others. You can emulate these with JS/DOM/CSS, but that creates the JS-reliance problems I talked about.
The problem is you have to duplicate the validation logic on both client and server then because JS validation can be bypassed. DRY sin. My rule of thumb is to do easy validation or common validation on the client side also, but if it has complex logic and is relatively rare, then just have it on the server. Don't waste duplicate code on rare things.
* The branch lined look in File Explorer for Windows 2000 was easier to read. Without the lines it's hard to see levels. I don't know why MS did away with them.
Damn! I always had packed a Dreamliner or two with me on trips.
What could one build it in today that won't be considered obsolete and "really uncool" within 7 years? The clothing fashion industry changes slower.
And it's a lot more coding and fiddling. The same CRUD app done today takes 5x the human work. Our 1 Oracle Forms programmer does the job of 5 MS-MVC'ers, in like 1/5 the time with 1/5 the total typing and 1/5 the total code. It's ugly but efficient and practical. We de-vovled, Yubba Dubba Doo!
Sure, one could tune/factor/trim a modern stack to fit shop conventions tighter, but management is afraid a new hire would then take longer to learn it; so we stick closer to out-of-the-box configurations. Plus, the Web is just clunky for productivity desktop CRUD apps. Faking it with AJAX et. al. just makes a maintenance mess.
I'm waiting for some kind of new standard to come along and rescue us from the bloat and hell of HTML/CSS/JS/DOM. (It's fine for web-pages, but sucks for CRUD.) I've been kicking around using dynamically generated Lazarus GUI's to make a proof-of-concept GUI/CRUD browser. In other words, use Lazarus's dynamism to make a "GUI Browser". A GUI markup language would define an app's GUI and communicate events between the server. (Note it's reinventing Oracle Forms's client "browser" more or less. 5!)
If I give it a hip name, maybe old will be new again? "Rich UIX Productivity-Enhanced Browser++"? "Profitron 9000"? I'll fib to PHB's that it uses quantum parallel deep AI edge cloud blockchain networks.
Knowing how HR "works", they require "100 years or more of production COBOL experience."
USA Made Robots Great Again! Don't let those shithole humans run things.
Browser caching has been a source of many headaches in our org with regard to CMS's and dynamic web applications. You can put header tags that allegedly turn off caching so users always see the latest, but they don't always work right on all content types (HTML, images, CSS, JavaScript, PDF's, etc.). All browser brands we've tested have at least one caching bug.
If browser makers haven't perfected current caching, then this new fancy-ass caching will probably have even more bugs.
I was mostly addressing UI issues, not how to force/encourage people to upgrade timely.
Before I evaluate the UI implications of forcing, we first have to agree on if, how, and when to force upgrades. As working terms, let's consider these categories of updates:
1. Critical security update -- Based on likely or highly dangerous threats.
2. Non-critical security update -- Attack/malware preventions that are deemed to be against rare actual threats or that have mild consequences
3. Feature updates & fixes -- Unrelated to hacking or malware
I don't think that's very common, but it is the user's prerogative if they really want to keep ignoring updates. Windows should give a decent warning about skipping critical security patches, but ultimately it should be up to the user.
Most home users shut down while at work or out. If a few days do go by without a restart, another reminder can pop-up. (I'm assuming Home Edition here. Also,
Windows tends to get funky if you go a few weeks without a restart.)
That would be nice, but MS would probably have to completely overhaul Windows to bring that about. Not gonna happen in my lifetime.
I agree, I have found the prompts/options confusing. It has end up rebooting on me in the middle of a session. I had thought it would prompt me first if I asked for "install at a later time". Not so. Other systems give you a count-down clock, such as "Starting installation plus a restart in 120 seconds. Click here to cancel install..."
How about a menu such as:
Windows updates are ready, which will require a restart. Estimated install time is 7 minutes. Your options are as follows:
- Install now
- Remind me later* [brings up dialog to select reminder period]
- Install upon shut-down
- Install upon next start-up
- Install at a specific time*
- Specialized options* [for throttled networks etc.]
- Help with install timing
I often want "remind me later" because I'm yan... uh, doing something. Therefore, a nice touch would be to have a menu option which echos my prior delay time or selection. Example:
- Install now
- Remind me in 24 hours
- Remind me at a later time [changes default]
- etc...
In this case, it echos my prior delay period selection, "24 hours". People tend to use the same options over again. (If I don't use the PC longer than 24 hours, then it should remind me upon next login.)
Comments?
* Results in additional dialogs or sub-menus
The Orange Guy is accidentally right on occasion. It happens.
Well, I agree that if one settles on a particular set of conventions, R-on-R can eventually be tuned to be productive, but it takes longer to get to that stage.
Clarification: I meant specific spots or areas of the application, not "problems" in the puzzle sense. An example would be for a particular listing were screen real-estate is at a premium such that I want the column title to be "Emp. No." instead of "Employee Number". A systematic way is needed to locally override the default title.
Also a way is needed to create dummy columns for specific needs that are not necessarily bound for the database. And the sequence of the fields often needs custom re-ordering. I found fairly clean ways to deal with such, but they are too strange to the uninitiated. Others are used to replicate-and-change.
I don't understand why data-dictionaries are not used more. Automatic code generation speeds up initial development, but is still difficult to maintain, as you have to sift through auto-generated verbosity to change things. Why can't I describe the field "employee number" in one place, with its database name, title, min size, max size, validation type etc.?
You are advocating auto-replication instead of true DRY. To me, that's auto-bloat.
One problem with data dictionaries is how to override the defaults for specific problems: the "delta problem". With auto-bloat, you just change the local copy for variations.
I've found ways to deal with the delta problem of data dictionaries using PHP arrays and some "helper" functions, but this approach isn't mainstream. The rest of the shops are addicted to auto-bloat instead. I don't get it. Habit?
Thank You, humans; and also thanks for being delicious!
- Bot #847
A distinction should be made between easy to learn and easy to use. Easy to learn means the learning curve to decent productivity will be shorter. Easier to use generally means it's less hand and eye movements to get what you want, although it may take longer to learn.
Granted, the terms are often commingled, but I seperate them here at least as a working definition.
To some extent one can achieve both by making the language or tool closer to the domain. The tool's objects/parts then are conceptually closer to the end user's (domain) objects and parts so that there's less translating/converting back and forth between domain usage and tool/language parts. (This includes both the desired UI, and domain entities such as employees, vendors, products, etc.)
Bad frameworks, standards, or languages create artifacts that have nothing to do with the domain. For example, with Web programming one often has to consider a "post-back" stage where the form is redrawn if there is a data entry error, along with error message(s). The logic to redraw is fairly different than the logic for the first draw. This creates an extra "technological artifact" that didn't usually exist with desktop-oriented tools because of their stateful nature. (Sure, you can emulate such with AJAX, but AJAX has its own warts, which I won't go into here. And don't even get me started about "responsive" UI's; I'd rant for days.)
Visual Basic Classic-like tools were on the right track, in my opinion, especially when they began perfecting database interfaces. But we mostly abandoned them and started over with something odd from outer space.
For custom CRUD apps, what used to take one hybrid programmer/analyst in the late 90's with desktop IDE's now often takes 4x the staff. It's a lot of cross-module (re) wiring-together busywork.
Sure, the Web made deployment (mostly) easier, but made development harder. And, MS has improved auto-deployment of Windows apps such that it's almost seamless.
Many shops got fairly close to the 90's with MS Web Forms, but then got spooked MS was going to pull the plug like it did with VB6, leaving them without a migration path. So they switched to MVC, but it's more code cross-wiring busywork. (Division of staff by tech specialty doesn't make sense on a small team.) And it's still makes crappy space-wasting UI's compared to desktop GUI's.
I'm not sure the trade-offs were logically weighed; people just hopped on the Web etc. bandwagon because everyone else was, and everyone fears being stuck on Legacy Island. Something is bigly wrong.
Fear of obsolescence increases the speed of obsolescence.
It's right next to the Ministry of Silly Typos. (Yes, I know, I go their often.)
You mean foodist. (I've been to a foodist temple.)
Perhaps they let Watson write the job ads. Back to the lab...
Over there it's "Ministry of Silly Woks".