can I get a summary of the review. Too long to read.
Let's try to condense:
brothke immediately liked the book, but only later truly appreciated it.
The main message of the book is to talk simply and succinctly, or no one cares. But business people usually fail to do so. The introduction asks why, and says it's because their talks are not to the point and too long, and they ignore the audience. Asher's answer is to make short talks and to interact with the audience.
The book has 3 sections. Part 1 says to talk only seven minutes, to not give unnecessary information, and that your slides should follow your story, not the other way round.
Part 2 tells you to plan for Q&A in order to fill in missing information and better communicate. Asher uncovers that the main problem often is sales persons selling obtuse solutions to clueless customers without caring for their needs. Q&A forces the salesperson to be clear about the product and the customer to be clear about his problems.
Part 3 speaks about things like eye contact, voice energy and rehearsal, which are critical for a good presentation.
The title may border on hyperbole, but the problem is real, and the book gives a solution on 104 pages. It is well written and gives the reader important insights. Asher's message isn't really limited to PowerPoint presentations, but can be applied universally.
The book only costs $7.95 and is a must-read for everyone. Scott Leslie suggests to carry a copy with you and smuggle it into the briefcase of anyone giving a bad talk.
Unless you're showing a screenshot, listing some code, or pulling a quote, the magic number is seven.
Seven words? Seriously? How many slides per minute are you doing?
Or maybe you don't have the relevant information on the slides. But then, why have slides at all? They are not helpful then.
More than that, and the presenter is usually just reading the Powerpoint deck. And in that case, why are you wasting my time, when you could have just emailed it to me in the first place?
Well, that assumes a whiteboard and marker are available. Also, the nice thing with slides is that you can make nice pictures which would be quite time-consuming to draw by hand (and unless you are very good in drawing, might end up quite messed up).
As someone else suggested, they could tightly control the trademark instead. Just deny the phone makers calling their OS Android, or using the terms Android or Google in their advertising, if the derived code doesn't have Google's blessing. That way phone makers have the choice whether they sell an "Android phone" and comply with Google, or if they just use the code, but don't mention Android in their advertising.
That would help Google, because it would make sure that everything sold as Android phone follows their guidelines, but it would still allow phone makers to make any change they want - they just cannot call the result an Android phone. And since the modified phones cannot draw popularity from the Android name, they cannot simply add crap, because no one would buy that. If they cannot sell it through the Android name, they have to sell it via an improvement for the user.
AFAIU at the time the hardware is on sale, Google will also allow access to honeycomb. Before that time, you'll not be able to get a device running honeycomb. Of course, the manufacturers should in principle be allowed to already distribute the code they got. However, I don't think it's in their best interest to do so, because they would lose their early-access advantage.
Well, if the goal is only keeping the manufacturers from closing it further, then a "non-closing" clause would be sufficient (e.g. demand that every phone running Android-derived code must give the option to change to an unmodified version of Android without voiding the warranty).
About not releasing before it's ready: They are doing closed development. That's actually the mode the FSF has traditionally worked in (note that this was one of the reasons for the egcs fork of gcc), therefore it quite obviously doesn't make the code less open source (or even less free software), although it makes for a less open development model.
However the restrictions to approved modifications might indeed make the code less open source, however it depends on how they are doing it. If they say "OK, you can get the code early, but then you may not make arbitrary modifications" then AFAICT the phone makers don't get open source (because they get it with restrictions which are incompatible with open source). However if the restriction is "if you make any unapproved changes, the next time we will not give you the code early" it certainly doesn't interfere with the code being open source (because they can change anything they want for the code they get), despite the net effect being almost the same.
There are many aspects of open, and open source is only one of them.
Actually, I've moved the bookmarks menu into the bookmarks toolbar with some FF extension (it's the only toolbar apart from the standard one with the address line I didn't remove). I'm using the menu for the history/recently closed tabs, for the site navigation (yes, that fundamental functionality which is even part of the HTML standard has to be added to FF with an extension!), for the web developer toolbar (I've eliminated the actual toolbar because the menu entries are sufficient) and for the print preview.
Yes, most of those things would be accessible through toolbars, but then, several toolbars use more space than one menu bar. And there's the history window, but if the old stuff is still in the menu, it's much easier to go there.
Actually there are things I miss in the main menu. Mainly tab related entries (especially those which make sense when only one tab is open; I don't show the tab bar in that case, so accessing its context menu is not possible).
I use the menus frequently. Indeed, I'd say a better way to save space would be to replace the tab bar with yet another menu which allows you to switch tabs from the menu bar. Since menus are vertical, it also could easily handle lots of tabs without scrolling.
Also I hope that home tab can be disabled. I've just put my start page into the bookmarks and disabled the home button. I don't need to replace the space waste of a home button with an even larger space waste of a home tab.
But when Firefox gets its own PDF rendering, it will definitively not be Adobe's. Indeed, I would consider it a security boon if add-ons like NoScript could also control JavaScript and other active content inside PDFs.
So I guess there's only one predictable set of operations you can do in C++, work with the primitive types. Except, you can't really predict the size or range of the primitive types until runtime, unless you know the specifics of the platform the code will be compiled on.
Well, there are guaranteed minimal sizes, and rarely you need the exact size (unless you are doing very low-level stuff, but then you should better know your platform anyway).
Say you do read through the stdint.h and discover that uint23_t is an alias for int... ON YOUR SYSTEM. Who knows what stdint.h will define uint32_t as on anyone else's system
Given that stdint.h is a C header, it will of course define it to whatever it is defined to be in C. Of course if using a compiler you always need to put faith in the provider that he doesn't do stupid things, or have glaring bugs in the compiler or associated library.
Now, quick, say you're on a 32 bit system. Without looking in the stdint.h file, prove that uint32_t is not really a class that implements all the int operators, has an internal state 4 bytes in size, and can cause the following statements to do any arbitrary operation.
stdint.h is a standard C header, and therefore cannot use any operator overloading.
But even if it were a user-defined type, unless the programmer writing it was a complete moron who should not have been let closer than ten miles to a compiler (of whatever language), you can expect that any operator works exactly as expected.
Is it really so hard to give a C++ programmer even the most basic tools, such as a few guaranteed size integer types?
The original C89 didn't have it either. And the next version of C++ will adopt it from C. But as I said, if you need specific sizes, you obviously do low-level programming, in which case you better know your platform (which defines the sizes of C integer types) anyway. Therefore a header with pre-defined specific-size integer types, while certainly useful, is not really essential.
Conversely, in languages that don't allow operator overrides, I can be sure that +, --, ++, and other mathematical operators operate on numbers, or at least perform defined operations given a set of parameter types.
And in languages that don't allow user-defined functions I can be sure that multiply(a,b), if defined, does indeed multiply a and b. We really should disallow user-defined functions; they can completely mislead you!
Unless someone has overloaded the global ++ operator for int types... Your "certainty" assumptions amuse me.
You cannot overload the global operator++ for int types. It is explicitly forbidden by the C++ standard, and if your compiler really allows it (I strongly doubt it), it's time to get a better compiler.
there are these concepts called "less" and "more".
they can be used like this:
Some people are killed by A Some people are killed by B but less people are(or could be) killed by B if we replaced B with A.
There's also that concept called "fewer"...:-)
Oh, and if we replaced B by A, no people would be killed by B, because there would be no B, only A. However most likely more people would be killed by A (because there are both the original As and those which replace the Bs).
Yeah, your employer will love it if you open internal company documents (and the document posed as internal company document) through a server of another company... </sarcasm>
Well, if it ends up in your junk folder, you simply should ask yourself why it went there. And take a closer look at the email before opening any attachments. I'm pretty sure that a quick look at the headers would have revealed that the originator isn't part of the company.
Of course if they have a collaborator inside the company network (or maybe can send the mail from another compromised company computer) that precaution measure probably won't help.
Five flaky backups are still better than nothing. I'm sure the Zodiac Island makers would be glad if, after the offsite backup failed, they could at least reassemble some of the episodes from flaky backups, even if some of them would not reflect the latest version.
No. It would have been unfortunate if I had experienced any negative consequences due to this. However, it's just the whateverony (you still didn't give an appropriate replacement word!) that the post which is intended to tell me about the backup day just comes so late that it is pointless.
No, I didn't mean coincidentally. Coincidentally it appeared on March 31 in my time zone (it was a coincidence because (a) it was about March 31, and appeared on March 31, abd (b) due to the time zones, it wasn't a given that it appeared on the right day). However that it appeared less than one hour before that day ended was not a coincidence (what would it have coincided with?). Also "coincidentally" doesn't include a valuation. The irony (or whatever; if you don't like "irony" in that context, provide a suitable replacement) in the situation is that due to the the time when it appeared, it was quite unlikely to be read in time to actually make a backup at that day in response to seeing that article (indeed, when I saw the article, the day was almost over, so making a backup in the remaining time of the day was basically impossible).
Slashdot Mirror
PP shrinks the font size by itself? Man, I'm glad that I'm using LaTeX with the beamer package for my talks ...
Three letters.
Ah, I see you're trying to avoid four-letter words.
can I get a summary of the review. Too long to read.
Let's try to condense:
brothke immediately liked the book, but only later truly appreciated it.
The main message of the book is to talk simply and succinctly, or no one cares. But business people usually fail to do so. The introduction asks why, and says it's because their talks are not to the point and too long, and they ignore the audience. Asher's answer is to make short talks and to interact with the audience.
The book has 3 sections. Part 1 says to talk only seven minutes, to not give unnecessary information, and that your slides should follow your story, not the other way round.
Part 2 tells you to plan for Q&A in order to fill in missing information and better communicate. Asher uncovers that the main problem often is sales persons selling obtuse solutions to clueless customers without caring for their needs. Q&A forces the salesperson to be clear about the product and the customer to be clear about his problems.
Part 3 speaks about things like eye contact, voice energy and rehearsal, which are critical for a good presentation.
The title may border on hyperbole, but the problem is real, and the book gives a solution on 104 pages. It is well written and gives the reader important insights.
Asher's message isn't really limited to PowerPoint presentations, but can be applied universally.
The book only costs $7.95 and is a must-read for everyone. Scott Leslie suggests to carry a copy with you and smuggle it into the briefcase of anyone giving a bad talk.
Seven words? Seriously? How many slides per minute are you doing?
Or maybe you don't have the relevant information on the slides. But then, why have slides at all? They are not helpful then.
Because I was asked to do a presentation :-)
Well, that assumes a whiteboard and marker are available.
Also, the nice thing with slides is that you can make nice pictures which would be quite time-consuming to draw by hand (and unless you are very good in drawing, might end up quite messed up).
As someone else suggested, they could tightly control the trademark instead. Just deny the phone makers calling their OS Android, or using the terms Android or Google in their advertising, if the derived code doesn't have Google's blessing. That way phone makers have the choice whether they sell an "Android phone" and comply with Google, or if they just use the code, but don't mention Android in their advertising.
That would help Google, because it would make sure that everything sold as Android phone follows their guidelines, but it would still allow phone makers to make any change they want - they just cannot call the result an Android phone. And since the modified phones cannot draw popularity from the Android name, they cannot simply add crap, because no one would buy that. If they cannot sell it through the Android name, they have to sell it via an improvement for the user.
AFAIU at the time the hardware is on sale, Google will also allow access to honeycomb. Before that time, you'll not be able to get a device running honeycomb.
Of course, the manufacturers should in principle be allowed to already distribute the code they got. However, I don't think it's in their best interest to do so, because they would lose their early-access advantage.
Well, if the goal is only keeping the manufacturers from closing it further, then a "non-closing" clause would be sufficient (e.g. demand that every phone running Android-derived code must give the option to change to an unmodified version of Android without voiding the warranty).
About not releasing before it's ready: They are doing closed development. That's actually the mode the FSF has traditionally worked in (note that this was one of the reasons for the egcs fork of gcc), therefore it quite obviously doesn't make the code less open source (or even less free software), although it makes for a less open development model.
However the restrictions to approved modifications might indeed make the code less open source, however it depends on how they are doing it. If they say "OK, you can get the code early, but then you may not make arbitrary modifications" then AFAICT the phone makers don't get open source (because they get it with restrictions which are incompatible with open source). However if the restriction is "if you make any unapproved changes, the next time we will not give you the code early" it certainly doesn't interfere with the code being open source (because they can change anything they want for the code they get), despite the net effect being almost the same.
There are many aspects of open, and open source is only one of them.
Actually, I've moved the bookmarks menu into the bookmarks toolbar with some FF extension (it's the only toolbar apart from the standard one with the address line I didn't remove). I'm using the menu for the history/recently closed tabs, for the site navigation (yes, that fundamental functionality which is even part of the HTML standard has to be added to FF with an extension!), for the web developer toolbar (I've eliminated the actual toolbar because the menu entries are sufficient) and for the print preview.
Yes, most of those things would be accessible through toolbars, but then, several toolbars use more space than one menu bar. And there's the history window, but if the old stuff is still in the menu, it's much easier to go there.
Actually there are things I miss in the main menu. Mainly tab related entries (especially those which make sense when only one tab is open; I don't show the tab bar in that case, so accessing its context menu is not possible).
I use the menus frequently. Indeed, I'd say a better way to save space would be to replace the tab bar with yet another menu which allows you to switch tabs from the menu bar. Since menus are vertical, it also could easily handle lots of tabs without scrolling.
Also I hope that home tab can be disabled. I've just put my start page into the bookmarks and disabled the home button. I don't need to replace the space waste of a home button with an even larger space waste of a home tab.
What? So slow? I expect them to release a major version every week! ;-)
But when Firefox gets its own PDF rendering, it will definitively not be Adobe's.
Indeed, I would consider it a security boon if add-ons like NoScript could also control JavaScript and other active content inside PDFs.
Well, there are guaranteed minimal sizes, and rarely you need the exact size (unless you are doing very low-level stuff, but then you should better know your platform anyway).
Given that stdint.h is a C header, it will of course define it to whatever it is defined to be in C. Of course if using a compiler you always need to put faith in the provider that he doesn't do stupid things, or have glaring bugs in the compiler or associated library.
stdint.h is a standard C header, and therefore cannot use any operator overloading.
But even if it were a user-defined type, unless the programmer writing it was a complete moron who should not have been let closer than ten miles to a compiler (of whatever language), you can expect that any operator works exactly as expected.
The original C89 didn't have it either. And the next version of C++ will adopt it from C. But as I said, if you need specific sizes, you obviously do low-level programming, in which case you better know your platform (which defines the sizes of C integer types) anyway. Therefore a header with pre-defined specific-size integer types, while certainly useful, is not really essential.
And in languages that don't allow user-defined functions I can be sure that multiply(a,b), if defined, does indeed multiply a and b. We really should disallow user-defined functions; they can completely mislead you!
You cannot overload the global operator++ for int types. It is explicitly forbidden by the C++ standard, and if your compiler really allows it (I strongly doubt it), it's time to get a better compiler.
there are these concepts called "less" and "more".
they can be used like this:
Some people are killed by A
Some people are killed by B
but less people are(or could be) killed by B if we replaced B with A.
There's also that concept called "fewer" ... :-)
Oh, and if we replaced B by A, no people would be killed by B, because there would be no B, only A. However most likely more people would be killed by A (because there are both the original As and those which replace the Bs).
Yeah, your employer will love it if you open internal company documents (and the document posed as internal company document) through a server of another company ...
</sarcasm>
Usually as employee you cannot decide that.
Well, if it ends up in your junk folder, you simply should ask yourself why it went there. And take a closer look at the email before opening any attachments. I'm pretty sure that a quick look at the headers would have revealed that the originator isn't part of the company.
Of course if they have a collaborator inside the company network (or maybe can send the mail from another compromised company computer) that precaution measure probably won't help.
You mean:
[Why|When|How|Where] [should|would|could|might] [you|I|anyone|CowboyNeal] [get|deserve|imagine|give] [a +1 Funny|a -1 Troll|a Beowulf cluster|a blowjob]?
Five flaky backups are still better than nothing. I'm sure the Zodiac Island makers would be glad if, after the offsite backup failed, they could at least reassemble some of the episodes from flaky backups, even if some of them would not reflect the latest version.
No. It would have been unfortunate if I had experienced any negative consequences due to this. However, it's just the whateverony (you still didn't give an appropriate replacement word!) that the post which is intended to tell me about the backup day just comes so late that it is pointless.
No, I didn't mean coincidentally. Coincidentally it appeared on March 31 in my time zone (it was a coincidence because (a) it was about March 31, and appeared on March 31, abd (b) due to the time zones, it wasn't a given that it appeared on the right day). However that it appeared less than one hour before that day ended was not a coincidence (what would it have coincided with?). Also "coincidentally" doesn't include a valuation. The irony (or whatever; if you don't like "irony" in that context, provide a suitable replacement) in the situation is that due to the the time when it appeared, it was quite unlikely to be read in time to actually make a backup at that day in response to seeing that article (indeed, when I saw the article, the day was almost over, so making a backup in the remaining time of the day was basically impossible).
When the data is worth something, you don't rely on only one backup. Especially if it's done by another company.
Maybe someone made a "backup" but is afraid to admit it ...