Yep, short is better when every byte counts. The point was though, that OP was comparing oranges to apples. Following that argument and filling in the blanks doesn't lead to the conclusion that he would like.
What exactly is your point? That because the HTML is shorter it is somehow better or easier to maintain? That XML style definitions are bad cause there is too much fluff for your brain to comprehend? Actually, what the Hell are you saying?
"Short != Better" (TM) Plain old HTML fails miserably, since that hard-codes what to do into every instance of the list element. That's akin to writing a separate class for every instance of Foo, defining the exact same operations for each one. It might look shorter when you have one instance, not so much when you have 1000. Yeah, you could auto-generate the Plain old HTML from a back-end, but for your argument to work, you'd have to show that code too. Plus the code needed to bring it all together.
There are lots of eyes on the keys with which my RedHat distros are signed, especially since they were social-engineered once. When [$bogeyman] can compromise those, I'll worry.
Per your own reply, you should start worrying right now. You actually should have been worrying for a while. As you point out, even the securest of secrets can be compromised, all it takes is dedication; Well that and knowing that there is a secret to know.
Well, as the FOSS community would say: "shut the fuck up and fix the problem yourself". Here's a link to get you started OGRE. Here's another Blender. And another learncpp.com When you're done with your masterpiece, feel free to give it away and support it forever.
How about a contest where the submitted code does exactly what the specs say, every time, on any hardware. The victor will be the one who writes a piece of code to spec, sits an untrained user in front of the app, and it behaves exactly as expected. Extra points if the user is successfully able to decipher any and all error messages and correct input without interference from anyone. Once you have a grip on that shit, then you can start doing cute/useless shit like this.
Every time you post a comment to his fucking nonsense, you're giving him food. Check out the links directly below the top paragraph, the bolded one liners. Some of those are posts from a few days ago. Flag it, hide it and move on, he's obviously in pain.
It is better... In an ideal world, every tiny change would get it's own unique version number. Fix->Test->Release
If you have a fix, why sit on it till 999 other issues have cropped up and are (supposedly) fixed? And no, a version number plus a list of KB articles for updates is not the same thing. It doesn't matter if all you change is the font, if that one thing is what breaks it for someone. But it makes it a hell of a lot easier to figure out why it's not working anymore, as opposed to a mammoth 1000 item changelog.
My thoughts too. What the fuck is submitter talking about? And more importantly, why should I care? This sounds like the local news, blowing some turned over trafic sign way out of proportion cause they have 30 mins on prime time to fill and 1 story to run. And like posted below, stop the goddamn *gate shit already, it was appropriate exactly once in history.
Well, I use my phone much like you describe, yet I fail to see how 2) applies to your situation.
The size of the screen (barring screens that are too small) has nothing to do with the usability of the virtual keyboard. The placement and size of the keyboard on said screen does impact usability. On too small a screen you would have to do something like the old phone keyboards, with multiple letters on each button. Once a screen reaches a certain size you can use a full qwerty-type keyboard always, as long as you (the developer) do not assume that it needs to span the entire screen width at all times. The assumption that a keyboard needs to span the entire width of the screen is what is breaking usability for one handed typers, not the size of the screen.
Can you hold the device in one hand and 1) unlock the phone, 2) type out a text message with your thumb, and 3) adjust the volume with the rocker without using your other hand? If not, you might need a smaller phone.
None of the above points are arguments for/against screens of any size. All of those "problems" can be solved without even thinking about the size of the screen on a device.
1) unlocking schemes for phones can take on any number of different forms, not all requiring you to swipe from edge to edge to unlock.
2) usability of the virtual keyboard has nothing to do with screen size, but a matter of placing it in the correct location on the screen
3) adjusting the volume on a phone has nothing to do with screen size, and everything to do with placement of the rocker button.
Even controlling the entire hardware and software stack is not enough. I agree that it would be a signifacant obstacle, but no more than that. You're still outputting un-DRMed content to the end user, and even if Google produced a TV that supported whatever scheme they cooked up, you'd still have to output pictures on it. And if you do that, you've lost the battle.
Correct, in the case of an MMO, where the game engine never leaves the software company's server, there is a significant delay in working "duplicates". They do appear in most cases however. Any other game or interactive content suffer from the same problems as video or music: unencrypted content is placed inside a domain the user controls.
That only moves the point in the pipeline where you need to insert code to do the ripping. No matter what scheme is thought up, the end result will always be breakable, simply because you need to output unencrypted content to the end user. You don't even need to break the encryption or do anything at all, all that is needed is to intercept the unencrypted signal before it is presented to the end user. This has been shown time and time again.
I am a developer, and happen to speak english as a second language. As much as I find it's helpful to my users to have the program's text information presented to the user in their native tongue, I really hate it if the tools I use speak to me in my native language.
Some vital parts of exceptions tend to get mangled when being translated, and you can't search for relevant information regarding whatever obscure failure you're experiencing unless you translate it back. And Google Translate doesn't do very well with technical terms.
It is especially unhelpful when the exception has been re-thrown from somewhere deep down, and is being presented with some parts translated, some parts not (I'm looking at YOU Microsoft; "Was this exception text helpful to you?" ( ) No ( ) No (x) Hell No!)
It's a document formatting specification, that nobody can seem to agree on, making it an unecessarily complex choice of "language" to begin with. And what would that teach anybody about encapsulation? Coupling and cohesion? Not to mention loops, recursion and simple stuff like flow of control?
Slashdot Mirror
Yep, short is better when every byte counts. The point was though, that OP was comparing oranges to apples. Following that argument and filling in the blanks doesn't lead to the conclusion that he would like.
What exactly is your point? That because the HTML is shorter it is somehow better or easier to maintain? That XML style definitions are bad cause there is too much fluff for your brain to comprehend? Actually, what the Hell are you saying?
"Short != Better" (TM)
Plain old HTML fails miserably, since that hard-codes what to do into every instance of the list element. That's akin to writing a separate class for every instance of Foo, defining the exact same operations for each one. It might look shorter when you have one instance, not so much when you have 1000. Yeah, you could auto-generate the Plain old HTML from a back-end, but for your argument to work, you'd have to show that code too. Plus the code needed to bring it all together.
There are lots of eyes on the keys with which my RedHat distros are signed, especially since they were social-engineered once. When [$bogeyman] can compromise those, I'll worry.
Per your own reply, you should start worrying right now. You actually should have been worrying for a while. As you point out, even the securest of secrets can be compromised, all it takes is dedication; Well that and knowing that there is a secret to know.
Well, as the FOSS community would say: "shut the fuck up and fix the problem yourself".
Here's a link to get you started OGRE. Here's another Blender. And another learncpp.com
When you're done with your masterpiece, feel free to give it away and support it forever.
That has got to be the lousiest Markov chain yet posted. Put some effort in.
I'm sure it's a super idea, transmitting your mental state over Bluetooth, what could possibly go wrong?
Agreed.
How about a contest where the submitted code does exactly what the specs say, every time, on any hardware. The victor will be the one who writes a piece of code to spec, sits an untrained user in front of the app, and it behaves exactly as expected. Extra points if the user is successfully able to decipher any and all error messages and correct input without interference from anyone. Once you have a grip on that shit, then you can start doing cute/useless shit like this.
Every time you post a comment to his fucking nonsense, you're giving him food. Check out the links directly below the top paragraph, the bolded one liners. Some of those are posts from a few days ago. Flag it, hide it and move on, he's obviously in pain.
Who cares? It's a number that distinguishes one incarnation from another. Only a moron would think they are comparable between distinct applications.
It is better... In an ideal world, every tiny change would get it's own unique version number. Fix->Test->Release
If you have a fix, why sit on it till 999 other issues have cropped up and are (supposedly) fixed? And no, a version number plus a list of KB articles for updates is not the same thing. It doesn't matter if all you change is the font, if that one thing is what breaks it for someone. But it makes it a hell of a lot easier to figure out why it's not working anymore, as opposed to a mammoth 1000 item changelog.
My thoughts too. What the fuck is submitter talking about? And more importantly, why should I care? This sounds like the local news, blowing some turned over trafic sign way out of proportion cause they have 30 mins on prime time to fill and 1 story to run. And like posted below, stop the goddamn *gate shit already, it was appropriate exactly once in history.
Fanbois are abundant in every camp. Smartwatches remains idiotic.
You can't really patch the kernel while it's running
Diesel causes cancer. Diesel particles could raise heart attack risks. And I'm sure there are tons of other stuff Diesel is good for, by all means let's have some more.
And yet it isn't closer.
634976802060943180
while(!done) {
string usIPAddress = addressList[random.Next(addressList.Length)];
logFile.WriteLine(usIPAddress + ": connection established.. blah blah blah");
done = logFile.Length == 144000;
}
PresentLogFileAsProof(logFile);
Well, I use my phone much like you describe, yet I fail to see how 2) applies to your situation.
The size of the screen (barring screens that are too small) has nothing to do with the usability of the virtual keyboard. The placement and size of the keyboard on said screen does impact usability. On too small a screen you would have to do something like the old phone keyboards, with multiple letters on each button. Once a screen reaches a certain size you can use a full qwerty-type keyboard always, as long as you (the developer) do not assume that it needs to span the entire screen width at all times. The assumption that a keyboard needs to span the entire width of the screen is what is breaking usability for one handed typers, not the size of the screen.
Can you hold the device in one hand and 1) unlock the phone, 2) type out a text message with your thumb, and 3) adjust the volume with the rocker without using your other hand? If not, you might need a smaller phone.
None of the above points are arguments for/against screens of any size. All of those "problems" can be solved without even thinking about the size of the screen on a device.
1) unlocking schemes for phones can take on any number of different forms, not all requiring you to swipe from edge to edge to unlock.
2) usability of the virtual keyboard has nothing to do with screen size, but a matter of placing it in the correct location on the screen
3) adjusting the volume on a phone has nothing to do with screen size, and everything to do with placement of the rocker button.
Road deaths happen mostly to idiots and whomever they hit, and this is cleaning the gene
There fixed.
On another note, how about we start this cleansing with you?
Even controlling the entire hardware and software stack is not enough. I agree that it would be a signifacant obstacle, but no more than that. You're still outputting un-DRMed content to the end user, and even if Google produced a TV that supported whatever scheme they cooked up, you'd still have to output pictures on it. And if you do that, you've lost the battle.
Correct, in the case of an MMO, where the game engine never leaves the software company's server, there is a significant delay in working "duplicates". They do appear in most cases however. Any other game or interactive content suffer from the same problems as video or music: unencrypted content is placed inside a domain the user controls.
That only moves the point in the pipeline where you need to insert code to do the ripping. No matter what scheme is thought up, the end result will always be breakable, simply because you need to output unencrypted content to the end user. You don't even need to break the encryption or do anything at all, all that is needed is to intercept the unencrypted signal before it is presented to the end user. This has been shown time and time again.
I am a developer, and happen to speak english as a second language. As much as I find it's helpful to my users to have the program's text information presented to the user in their native tongue, I really hate it if the tools I use speak to me in my native language.
Some vital parts of exceptions tend to get mangled when being translated, and you can't search for relevant information regarding whatever obscure failure you're experiencing unless you translate it back. And Google Translate doesn't do very well with technical terms.
It is especially unhelpful when the exception has been re-thrown from somewhere deep down, and is being presented with some parts translated, some parts not (I'm looking at YOU Microsoft; "Was this exception text helpful to you?" ( ) No ( ) No (x) Hell No!)
HTML for new programmers? That's a horrible idea.
It's a document formatting specification, that nobody can seem to agree on, making it an unecessarily complex choice of "language" to begin with. And what would that teach anybody about encapsulation? Coupling and cohesion? Not to mention loops, recursion and simple stuff like flow of control?