Completely aside from testing, the obvious advantage to this approach is that it will make your project automatable and scriptable. If I'm able to send command-line commands to a program, I can write up a script to perform complicated tasks much more easily (and more reliably!) than I could create a macro to automate the same thing on a GUI.
Whether or not ...
It's not extra work, just different work. If you do it right, not only will it not make it more complex, it will make it simpler because it will force you to decouple your design. Whether or not you actually implement the CLI, your design will be better off for making it possible to do so.
1. UX: message boxes are mostly evil
You can read About Face 3 by Alan Cooper¹ if you want to know why; it explains very well how does this interrupt the workflow and annoys the user, and how nearly every alert box ...
One key advantage that doesn't seem to have been mentioned is that being able to do this pretty much enforces strict decoupling of the UI from the underlying code. One key advantage of this is that it means that if you need to significantly change the GUI (say iOS standards to OSX standards, or one graphical engine to another), that's all you need to change, ...
Being able to reuse functionality under different interfaces (e.g. GUI vs CLI vs REST) is not always necessary but nice to have and enable serendipitous reuse for a system, as other people find new ways to interact with it.
This has a few drawbacks that need to be weighted:
It'll require additional abstraction layers (sometimes even tiers). While having ...
First of all, the example you provided is not incredibly inefficient; its only slightly inefficient; its inefficiency is below the perceptible level. But, in any case, let's move on with the question.
The way I understand it, when we speak of separation of UI and Logic, we mean avoidance of close coupling.
Close coupling refers to the situation in which ...
what to show to the user.
Should this also be hidden from the user?
You show the user what is actionable for them.
For example, if you have an error which is caused because of some null pointer exception and more of a bug than user error you don't want full explanation because they can't do anything different.
Or should we show this anyway? Or should ...
It depends: You need a tight feedback loop around your most important piece of functionality
If the core of what you do, the risky and scary part, is some internal engine, then get the core part working in say the console or through unit testing. For example, a protocol parser doesn't need a UI to know whether its operating correctly.
If your cool thing ...
I don't think it's at all crazy. It all depends on who your target audience is. If you write an app and expect an average user to use it, you are probably better off with a GUI.
If your app is a for developers, especially those that are used to CLI. Or if your app is targeting a sys admin who sits at his workstation and SSH's into 30+ other machines on a ...
Because making the GUI lib thread safe is a massive headache and a bottleneck.
Control flow in GUIs often goes in 2 directions from the event queue to root window to the gui widgets and from the application code to the widget propagated up to the root window.
Devising a locking strategy that isn't lock the root window (will cause a lot of contention) is ...
This might be down voted for not answering your question directly, but the debate you had with your colleague was a waste of time.
You should have spoken to 3 (mid level, hands on) lab technicians - given them the two options and asked them what they would do.
Toward the end of his failed dream essay, Graham Hamilton (a major Java architect) mentions if developers "are to preserve the equivalence
with an event queue model, they will need to follow various
non-obvious rules," and having a visible and explicit event queue model "seems to help people to more reliably follow the model and thus construct GUI programs ...
I think a big part of it is reducing visual noise. The less "Stuff" there is on the screen, the less complicated the program feels, and users' sense of confidence in their ability to grasp the software increases. This was as true in the 90's as it is today, but the reason you're noticing it now is that we are starting to re-evaluate our assumptions about ...
In most IDEs, you may choose whatever font you like. If you find an oldstyle font more readable, pick it.
Note that all (nearly all?) oldstyle fonts are proportional, while proportional fonts have some issues when using them in programming context.
Aside that, let's test and compare some oldstyle fonts to the fonts usually used in IDEs. I have only Windows ...
Yes it's almost always a good idea.
If you follow this approach you will not likely have a business logic or data access in a same thread as GUI, and behind some GUI handler. This reason alone is worth investing in.
Threadedness (in a shared memory model) is a property that tends to defy abstraction efforts. A simple example is a Set-type: while Contains(..) and Add(...) and Update(...) is a perfectly valid API in a single threaded scenario, the multi-threaded scenario needs a AddOrUpdate.
The same thing applies to the UI - if you want to display a list of items with a ...
They have released a UI framework that supports ribbons -- it's just supported in MFC instead of .NET.
There's probably room for quite a bit of debate as to why they did things that way, but it is what they did anyway.
A common reason for this "feature" is that a site tries to keep some state of the current session on the server side.
That desire to track "conversation" state on the server side often comes from trying to write a Desktop-like "rich client" on the web (as opposed to embracing the web as the chaos it is). To be fair, this mostly happened in a time when the ...
As a user, I don't expect the whitespace on either side of the equals sign to change the value of the key or the value. See this related question on unix.SE as too how confusing the situation can be.
Don't make it harder on your users, trim whitespace from both the key and the value. If leading whitespace has a real use case for either, then let the user ...
I was reading about gzip program and I found the official website of the gzip software.
No, you didn't. You found the website that used to be the official website back when the original authors were still the maintainers. Now, GNU Gzip is maintained by different people, and the website is https://www.gnu.org/software/gzip/ .
First of all the site looks ...
Take it iteratively. You're working directly with the users, right? So it should never really be a mess.
First do the search page. You and the users should keep in mind that they'll want to be able to do actions on the results. Do the users like it? OK, you've got your search.
Now add the "Change Password" (or whatever is next in priority). Oops, we ...
The problem is that a password should appear in plain text as rarely as possible.
In your case, the password appears in plain text in an e-mail. This has several drawbacks:
If the account of the person is compromised, the hacker gets access to your website as well.
If there is a malicious man in the middle, he can access the password with ease.
Immediately show some feedback: change the visual state of the button, display an animated throbber.
If the app logic allows, disable the button once it has been pressed, enable it back when the answer arrives.
Once the answer has arrived, show the real feedback: update the controls, remove the throbber.
It depends on who the user is, and what they can do with the information.
Generally, try to show them only useful information about things they can resolve themselves. A 40 line stack trace with a regular expression error at the top is not very useful. Much better would be a message that says Date must be formatted as "yyyy-mm-dd". Anything else, and the ...
I implement responsive design by viewing width, not device or browser type. This way it's future-proof and useful in unexpected scenarios. For example, when a new phone comes out with a huge screen and resolution my sites will still be optimized to use it well.
Also, my HTML is identical for every device / resolution. In the MVC architecture only my CSS ...
It's up to you to define the rules for your app.
For instance, you may define that:
Whitespace before or after the equality sign is ignored,
Whitespace inside the key is forbidden,
Whitespace inside the value can be used only if the value is enclosed in quotes, so:
say-hello = Hello, World!
is forbidden, while:
say-hello = "Hello, World!"
is allowed, ...