I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.
Why is it at all sad that, after 20 years, I've forgotten the implementation details of a specific algorithm that I've NEVER had to implement (other than as part of the learning process back then) since it's already been implemented in the standard library of just about every language or API that I've ever worked with (and that implementation has probably been done better than I could do it, because it has likely been done by someone who has studied sorting algorithms in much more detail than I ever did)? What does that have to do with forgetting how to program? I rebuilt an engine in high school, but I don't remember how to do it now. Does that mean I've forgotten how to repair my car, too?
And how does it work? Well, I could tell you now, since the curious part of me went and looked it up on wikipedia to refresh my memory the second I finished making that post. And you might think that's fine, since that proves I can actually do it, except for the fact that, had I first ran into Jane Q. Public in an interview rather than on slashdot, I would have failed that requirement at the time.
But to answer your question with the knowledge I had at that time, the only part of it I could remember is that divide and conquer is part of it. But I couldn't remember how it dealt with getting values sorted between the left and right halves (doing a rough sort before dividing), nor anything about the pivot point or how to select it.
"I agree with the anon poster. You are an idiot. A computer scientist better be able to write a QS in their sleep, but a programmer better know how to find a suitable implementation already written."
That's not a programmer, that's a hack just out of high school.... But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
Or, maybe you're just really bad at expressing yourself.
Nobody should intend to film in portrait mode except in rare conditions that do not apply here with phones. The reason people do it is because it is the natural way to hold the phone, not because it is the natural way to watch the video.
Why should nobody intend to do it? I do it from time to time, and I intend it. If the subject I'm capturing is naturally vertical, and I don't intend to view it full screen on an HDTV, why should I waste all that space and resolution capturing stuff I don't care about on each side? I'll shoot it portrait and capture the subject that I am actually interested in with as much detail as possible.
The phone should fix their mistake by cropping the image down to landscape or square.
Then you end up with a much lower resolution, which is very undesirable.
I don't understand what you mean by "sensor space that would rarely be used". With a square sensor, the recording would ALWAYS be square regardless of portrait or landscape orientation. It might be different than what users expect, so the cropped area on the display could show application icons for various features that are often hidden in pie menus.
But to use a square sensor, you give up a lot of resolution. A lens is circular. People generally prefer photos that are rectangular rather than square. Well, for a given circle diameter, you can fit a wider 2:3 rectangle in it than you can a sqaure. That means for a given lens size, your 2:3 sensor will capture more detail than a square sensor which you crop down.
Because it would be sensor space that would rarely be used. It's not that common that people would hold in portrait but intend to shoot in landscape. And then on top of that, I don't know that it is technically possible to manufacture a plus-shaped sensor. If not, then that would mean either there would be a lot of the sensor that is completely unused (which means wasted cost of manufacturing, and possibly wasted battery life if it's not possible to keep portions of the sensor powered down), or you'd have to shrink the square sensor down to fit inside the circular lens (which means your effective sensor would be lower resolution). Neither of those are ideal trade-offs for somethings that might be used 5% of the time.
How about I beat your finger with a hammer until you give me your password?
Not that much harder.
A violent assault sure seems a hell of a lot harder to me than simply following someone around and wait until they touch something you can pull a print from without the person even realizing it.
There can't be a run time error. A run time error would require that there is code that actually calls the method. That on the other hand would mean: the method already existed in the old code. And that means the behaviour of the class is unchanged. (interface changed and added the same method the class is already implementing, regardless whether there is a default implementation or not, it would work fine).
But it's not problem free. So you have class X, which implements interfaces A and B. Interface A has function Foo, so class X implements function Foo. Everything is fine and dandy. Now it's the future. Interface B has been upgraded to also have function Foo, and given a default method so as not to break existing code. If you recompile it, as you said, it will work just fine since you've got an implemented method, thus no conflict. So now you pass an object of X to a function called DoSomethingWithB that expects a B object as a parameter. In the upgraded library, that method takes advantage of the fact that B objects now have a Foo function, so it calls it. Except that the implementation of Foo in X that gets called is one that was designed to only deal with calls intended for objects of type A. Unless A.Foo and B.Foo have the same intended purpose, it's gonna fail until class X is upgraded to deal with the new B.Foo. And like I said, how does the code even know if the caller is trying to call Foo on an A or a B object? That's important because, if the purpose is different and the naming similarity is just coincidence, then you are going to need to do different things in each case.
Currently (build 106), if you have two interfaces with with default methods with the same signature, the class implementing the two interfaces won't compile.
You'll get:
class {ClassName] inherits unrelated defaults from [methodName] from types [interface1] and [interface2]
To fix the class, you need to implement the method.
So, first of all, that means that default methods doesn't 100% fix the problem it was intended to fix. Namely that existing code would break if new methods were later added to interfaces, as that existing code would not have an implementation. It's still possible that adding new methods to an interface could break existing code, but probably a lot less likely. I assume they'll take care in future releases to make sure they don't modify existing interfaces in such a way as to break anything using the standard library, but that may not hold true if you use any code libraries from a 3rd party.
The other thing is, I don't see how this is a whole lot different from just allowing multiple inheritance but requiring the derived class to override to resolve the ambiguity up front (rather than the C++ method of letting the caller resolve the ambiguity). And I'm actually curious how Java will allow this to be resolved in the derived class. If you implement interfaces A and B, which are completely different from each other and both implement method Foo for completely different purposes, then using the C++ method, it's easy to call object.A::Foo when you are trying to treat the object as an A, and likewise for B. But with java, will the overridden function C.Foo be able to know when the caller was treating the object as an A vs a B? If not, then it's sort of difficult for the class to know how to properly resolve these sorts of conflicts.
So java now supports default methods for interfaces? In other words "we now support multiple inheritance". Or at least that's pretty close to it. I thought the logic was that multiple inheritance is messy when you have diamond shaped inheritance, or two parent classes that have the same method names, so java only did single inheritance, but then allowed you to do interfaces to sort of simulate multiple inheritance (except you had to write all the code). But with this change, it seems the same as multiple inheritance, with the exception that interfaces cannot include (non-static) variables, only methods. Am I correct here, or am I overlooking something?
For a moment, I wanted to tell you I think you are totally wrong, but then I remembered...I'm only up to episode 3 so far. Up to this point, it seems like a really good show, to me at least. Hopefully I don't agree with you once I'm caught up, but unfortunately I could see you being right. The show reminds me quite a bit of Jericho. I loved that show initially. I loved how it showed people being isolated and falling back to low tech, and how the people come together to survive the emergency. That was really nicely done, but then they worked in the conspiracy theory part and made that a bigger and bigger part of Jericho. That really ruined the show for me. I would have been happier if Jericho left it as a mystery how everything happend.
So far (after 3 episodes), the conspiracy theory in Under the Dome is sort of small. I'm praying it doesn't take over this show too.
Although I haven't yet researched the answer online, I wish Android would provide a little better explanation of just how the backup feature works. I've got an android tablet and an android phone. I've installed different software on each one. I'm unclear on how the backup/restore works with multiple devices. When restoring to a brand new device, does it prompt you as to which old device's backup you want to restore from?
The reason GameFly pays more is because their mailers weigh more. Netflix keeps the mailer at 1 ounce and pays 44 cents each. GameFly's mailer is 2 ounces and they pay the two ounce price. The big giant clue in the linked article is that the USPS is considering changing the price of the 2 ounce mailer to the price of a 1 ounce mailer.
So the real story is that GameFly wants a discount with zero actual justification.
The packaging for GameFly costs more. Work it into your business model or reduce the packaging weight.
I don't do business with GameFly but if I did, I'd cancel. They actually have the nerve to pretend Netflix is getting some kind of special treatment while they are the ones seeking it.
There is nothing unfair about what the USPS is doing. The rest of us have to pay by the ounce for our mail.
Just read the article you linked. While interesting, it does kinda support Gamefly's case. A 2-ounce mailer cost $1.05, whereas a 1-ounce mailer cost $0.44. In other words Gamefly pays ~238% of what Netflix pays, 38% above any differences in weight. Further, at these weights, the majority of the cost of delivery is a flat cost, rather than an increase in fuel consumption due to weight. The cost of fuel to transport 1 ounce of additional weight is certainly less than a penny; the vehicle, occupant, and other cargo make up the vast majority of the weight (and the occupant's time is no small factor on the cost). Just basing numbers on the weight of the packages alone, charging ~$0.10 extra for the additional ounce will more than make up for the added costs.
There are other factors you haven't considered. Perhaps larger, thicker, or heavier packages tend to jamb in the automatic processing machines more often, requiring more manual intervention and slowing everything down. And even if that doesn't apply to gamefly's specific case, it may apply to packages greater than 1 ounce in general. And if that's the case, it would justify the post office making a special exception for gamefly since they wouldn't actually be costing more.
I really do appreciate a good framework... My favorite one currently is Vanilla-js http://vanilla-js.com/
Check it out. Amazing performance.
That's funny and cute. I thought it was a real framework for a moment. But that aside, the website is dishonest in their comparisons. They try to make the complexity of the "vanilla.js" code look much smaller by unnecessarily mentioning you have to include the jquery library (even though you only do it once per page regardless of you many times you use it in that page), and they include the script tags on the jquery example but not the vanilla.js example (or does vanilla.js somehow magically not need script tags to denote that it's script?). So to give a more honest comparison, lets look at their fading example. here's the real comparison:
vanilla.js: var s = document.getElementById('thing').style; s.opacity = 1; (function fade(){(s.opacity-=.1)0?s.display="none":setTimeout(fade,40)})();
jquery: $('#thing').fadeOut();
uhhhhhhhhh.....you know, I think I'll take the jquery one, thank you. Same thing with the ajax example...not as drastic as the fade example, but the jquery example is MUCH cleaner looking to me.
But oh yeah, there is the performance issue. 12,137,211 ops/sec with vanilla.js, vs only 350,557 with jquery. Yeah, that is quite compelling....except that I'm generally only doing a handful of operations per second, not 12 million, and the difference between a few nanoseconds and a few more nanoseconds really isn't that big of a deal. In the VERY rare case where I'm doing something where performance becomes an issue, I'll optimize where needed, but I don't waste my time prematurely optimizing.
You know what I like to actually optimize? Getting things working correctly. Think jquery is a waste? Well, lets look at that fading example above. Pretty darn simple, isn't it? Surely nothing tricky there. So lets see. jQuery seems to work fine. How about that more monstrous vanilla.js version they posted. ok, it's working fine in firefox. How about chromium. Oh interesting. Look at that. It fades out almost all the way, but never totally disappears and gets hidden. Why is that? The code LOOKS to be correct (though perhaps that < 0 should be <= 0...nope, that wasn't it). Ok lets do some debugging of the opacity value on each iteration:
1 0.9 0.8 0.7000000000000001 (uh oh, I see where this is going) 0.6000000000000001 0.5000000000000001 0.40000000000000013 0.30000000000000016 0.20000000000000015 0.10000000000000014 0.10000000000000014 0.10000000000000014
oh, hey. look at that. chromium never lets the value get below 0, so that function keeps getting called forever, but never actually finishes and hides it. OK, so that's one stike against it.
Here's another thought...what happens if the element with id 'thing' doesn't actually exist? Oops, he forgot to check for null, so anything after his.style in the first line of code line will never get executed because the javascript will abort with an error at that line. OK, 2 strikes.
OK, now what about when it is time to reshow the block we just hid. Hmmmm...now was that #thing object set to block or inline display? Oops, he forgot to save the state. We can set it to blank to go back to the default, but what if it was already overridden before we got to the value? Ooops. Strike 3.
Yes, his example could be adjusted to fix all of these issues, but that's the point. The code looks horrendous and it has at least 3 bugs in that simple example so you are going to have to make it even more complex. Meanwhile my jquery example simply worked and I'm already on to the next thing.
Actually, there is now a 6 tuner ceton, and while I haven't seen any reports on anyone buying it yet, we're pretty hopeful that it will work with mythtv just the same with no code changes. There is evidence in the 4-tuner version that the same code it uses was designed to work with 6 tuners.
As for the 4 tuner version, I've been happily running my mythtv with the 4 tuner ceton for over 2 years. If you can't get it working, then I'm sorry you have a shitty cable provider that locks down their content.
The last time, I had to explain to them what a cablecard even was, go through about six different people before they finally put on a tech who knew wtf he was talking about, and then deal with hours of installation hassles (thought I could just go pick it up and install it myself--nope, gotta have a tech come do it, and it's going to take him forever to get it working too).
Now I've got to try to explain to them what a "M" cablecard is. Great.
Nope, you don't have to explain anything to them. Just say "I want a cablecard". The new FCC regulations require that all cable companies only give out M-cards unless you specifically ask for a single stream card.
I hate apple products as much as the next guy, but I'm not sure I can agree with this. I see my coworkers typing on their ipads all the time with a dock-like keyboard that attaches to act like a cover when not in use (not sure what it's called or if it's an official apple product or 3rd party).
You are right...it MOSTLY works flawlessly, but there are subtle issues you need to pay attention to. The All Mail thing usually would not be such a concern I would think. If you were migrating to a server that is fully imap compliant, then yes, those deleted messages would show up in an additional folder called '[Gmail]/All Mail' on the destination server, and you could just promptly delete that folder and you'd be back to what you would have expected.
However, the fact that these messages are showing up in people's inbox leads me to beleive they didn't do a full folder migration, and instead only copied the All Mail folder to the new inbox. Why would you do that? Well, as I mentioned in another post, my recollection of hotmail is that it supports INBOX access to imap, but doesn't support other folders. I don't know if Yahoo does a similar thing or not, but to me, that seems like the only excuse I could think of for copying All Mail to the inbox. Though even that isn't a good excuse...I don't see how they could justify letting their users lose their entire folder structure in the migration process.
A faster way would be to delete all in All Mail, then recurse through the other folders creating a duplicate tag in All Mail. Messages that only existed in All Mail before will be gone. All others are preserved.
You would think so, wouldn't you. And that would probably work if this were a fully imap compliant system, but that's exactly the point (and why they got into this mess to begin with)...it isn't.
For gmail, the message in "All Mail" is the sole existence of the actual message in the system. The copies of the message in other "folders" are really just references to the copy in "All Mail". So deleting it from All Mail is not really a choice. I can't remember from my testing back then what would happen if you DID delete it from All Mail. Either google would reject the delete, or the message would disappear from every folder it was in and not even leave a copy in the trash (you had to move it to trash if you wanted that). I know google rejects deletes of the entire All Mail folder, but I don't recall the result for trying to delete individual messages.
Yes, for migrating off of google, that's also an option (which I thought of right after clicking submit), assuming the recipient system supports folders. I don't know about yahoo. I was messing with hotmail a few months back before our migration, and I think my reccollection was that they support IMAP to the inbox, but no arbitrary folders. In a case like that, you'd have to collapse all the mail down to 1 folder (the INBOX), so pulling All Mail would be the easiest way.
In my case, we had a similar sort of issue while moving onto google, so ignoring "All Mail" wasn't an option, so I resolved as indicated in my other post.
Actually, I doubt it was Yahoo's fault either. This can't be the first time Yahoo has done an import from Google, can it (assuming they even handle the importintg for you...google doesn't)? If they had done this before, they'd have known about this problem with IMAP and the All Mail folder. So I'm guessing it Sky itself that made the mistake (or whatever consultant they hired to to do it) because of their unfamiliarity with Google's system.
Google does delete stuff (at least from our view...who can say what they really do behind the scenes). This is just a case of Google only being a pseudo-imap system. It's compatible with imap clients, but it's got some oddities in how they expose their internal system to imap. See my post above for more info.
Actually, I'm pretty certain I know exactly what happened, because I just handled a major migration to google and dealt with an issue like this. It's due to the way google uses labels instead of folders, and how they (mostly-transparently) expose them as folder via imap (though this is one of the few non-transparent side effects).
In google, when you "delete" a message via imap, it doesn't get deleted. Instead, google just removes the label. That message still exist with all of the other labels, and it also exists in "All Mail" (which is exposed via IMAP through the "[Gmail]/All Mail" folder). So, if you have new mail come it, it is by default in your INBOX and your "[Gmail]/All Mail" folders. When you then delete it from the INBOX via imap, it's still in All Mail.
The way to deal with this is to move the message into "[Gmail]/Trash" instead of deleting it. That will truely delete it. However, since that wasn't done all along, those "deleted" messages are now orphaned in "[Gmail]/All Mail". There is a potential way to resolve even this problem, but it depends on how the account has been used. If users have logged into Gmail directly and taken advantage of the "Archive" feature to remove a message from the inbox (without truely deleting it) then all bets are off. There is no way to differentiate intentionally saved messages from deleted-via-imap messages. However, if it has only been accessed via imap (and users haven't intentionally been trying to take advantage of the All Mail folder), then you can do the following via a script:
Go through every message in "[Gmail]/All Mail". For each message, try to find that same message in another folder. If you don't find it in another folder, then that message only exists in "[Gmail]/All Mail". You can then move it to "[Gmail]/Trash" to get rid of it.
Searching for messages 1 at a time is a bit slow, so you can optimize this by first building a list of all messages in other folders. If you just retrieve a few headers from every message, it's actually fairly fast. The "Message-ID" field is usually sufficient for this, but there may be messages here and there that don't have that header, so you'll have to have other headers to fall back on.
Yes, but it's like the old tale of wind and sun competing who gets the guy to take off his jacket. Wind blew and blew and all that accomplished was him to tighten his grasp on the jacket, sun instead shined and the guy took off the jacket voluntarily.
If you try to FORCE me to do something, expect me to resist. Give me what I want and you may expect me to cooperate.
Except that argument is BS. To put it in terms of your old tale, it's like the sun shined and shined and shined for years, but more and more people just put on their jackets. Then finally the wind starts blowing, and people get upset and say "if you'd just give me some sun instead of the wind, maybe I'd voluntarily take off my jacket".
Slashdot Mirror
I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
That is kind of sad. Could you describe how quicksort works, at least? Does divide and conquer ring a bell? How about a pivot element? I'm not going to require you to do it in-place or anything. If you've forgotten how to program I'm not sure what to say, except that you have my condolences.
Why is it at all sad that, after 20 years, I've forgotten the implementation details of a specific algorithm that I've NEVER had to implement (other than as part of the learning process back then) since it's already been implemented in the standard library of just about every language or API that I've ever worked with (and that implementation has probably been done better than I could do it, because it has likely been done by someone who has studied sorting algorithms in much more detail than I ever did)? What does that have to do with forgetting how to program? I rebuilt an engine in high school, but I don't remember how to do it now. Does that mean I've forgotten how to repair my car, too?
And how does it work? Well, I could tell you now, since the curious part of me went and looked it up on wikipedia to refresh my memory the second I finished making that post. And you might think that's fine, since that proves I can actually do it, except for the fact that, had I first ran into Jane Q. Public in an interview rather than on slashdot, I would have failed that requirement at the time.
But to answer your question with the knowledge I had at that time, the only part of it I could remember is that divide and conquer is part of it. But I couldn't remember how it dealt with getting values sorted between the left and right halves (doing a rough sort before dividing), nor anything about the pivot point or how to select it.
"I agree with the anon poster. You are an idiot. A computer scientist better be able to write a QS in their sleep, but a programmer better know how to find a suitable implementation already written."
That's not a programmer, that's a hack just out of high school. ...
But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
I'm sad to learn that, by your standards, I'm not currently a programmer, but merely a hack just out of high school, as I couldn't write a quicksort to save my life. Ironically, though, 20 years ago, when I WAS just out of high school (and WAY less experienced/skilled), I apparently was a programmer back then because I could and did write a quicksort at that time.
Or, maybe you're just really bad at expressing yourself.
Nobody should intend to film in portrait mode except in rare conditions that do not apply here with phones. The reason people do it is because it is the natural way to hold the phone, not because it is the natural way to watch the video.
Why should nobody intend to do it? I do it from time to time, and I intend it. If the subject I'm capturing is naturally vertical, and I don't intend to view it full screen on an HDTV, why should I waste all that space and resolution capturing stuff I don't care about on each side? I'll shoot it portrait and capture the subject that I am actually interested in with as much detail as possible.
The phone should fix their mistake by cropping the image down to landscape or square.
Then you end up with a much lower resolution, which is very undesirable.
I don't understand what you mean by "sensor space that would rarely be used". With a square sensor, the recording would ALWAYS be square regardless of portrait or landscape orientation. It might be different than what users expect, so the cropped area on the display could show application icons for various features that are often hidden in pie menus.
But to use a square sensor, you give up a lot of resolution. A lens is circular. People generally prefer photos that are rectangular rather than square. Well, for a given circle diameter, you can fit a wider 2:3 rectangle in it than you can a sqaure. That means for a given lens size, your 2:3 sensor will capture more detail than a square sensor which you crop down.
Why not use a square sensor?
Because it would be sensor space that would rarely be used. It's not that common that people would hold in portrait but intend to shoot in landscape. And then on top of that, I don't know that it is technically possible to manufacture a plus-shaped sensor. If not, then that would mean either there would be a lot of the sensor that is completely unused (which means wasted cost of manufacturing, and possibly wasted battery life if it's not possible to keep portions of the sensor powered down), or you'd have to shrink the square sensor down to fit inside the circular lens (which means your effective sensor would be lower resolution). Neither of those are ideal trade-offs for somethings that might be used 5% of the time.
Harder to get?
How about I beat your finger with a hammer until you give me your password?
Not that much harder.
A violent assault sure seems a hell of a lot harder to me than simply following someone around and wait until they touch something you can pull a print from without the person even realizing it.
There can't be a run time error.
A run time error would require that there is code that actually calls the method.
That on the other hand would mean: the method already existed in the old code. And that means the behaviour of the class is unchanged. (interface changed and added the same method the class is already implementing, regardless whether there is a default implementation or not, it would work fine).
But it's not problem free. So you have class X, which implements interfaces A and B. Interface A has function Foo, so class X implements function Foo. Everything is fine and dandy. Now it's the future. Interface B has been upgraded to also have function Foo, and given a default method so as not to break existing code. If you recompile it, as you said, it will work just fine since you've got an implemented method, thus no conflict. So now you pass an object of X to a function called DoSomethingWithB that expects a B object as a parameter. In the upgraded library, that method takes advantage of the fact that B objects now have a Foo function, so it calls it. Except that the implementation of Foo in X that gets called is one that was designed to only deal with calls intended for objects of type A. Unless A.Foo and B.Foo have the same intended purpose, it's gonna fail until class X is upgraded to deal with the new B.Foo. And like I said, how does the code even know if the caller is trying to call Foo on an A or a B object? That's important because, if the purpose is different and the naming similarity is just coincidence, then you are going to need to do different things in each case.
Currently (build 106), if you have two interfaces with with default methods with the same signature, the class implementing the two interfaces won't compile.
You'll get:
class {ClassName] inherits unrelated defaults from [methodName] from types [interface1] and [interface2]
To fix the class, you need to implement the method.
So, first of all, that means that default methods doesn't 100% fix the problem it was intended to fix. Namely that existing code would break if new methods were later added to interfaces, as that existing code would not have an implementation. It's still possible that adding new methods to an interface could break existing code, but probably a lot less likely. I assume they'll take care in future releases to make sure they don't modify existing interfaces in such a way as to break anything using the standard library, but that may not hold true if you use any code libraries from a 3rd party.
The other thing is, I don't see how this is a whole lot different from just allowing multiple inheritance but requiring the derived class to override to resolve the ambiguity up front (rather than the C++ method of letting the caller resolve the ambiguity). And I'm actually curious how Java will allow this to be resolved in the derived class. If you implement interfaces A and B, which are completely different from each other and both implement method Foo for completely different purposes, then using the C++ method, it's easy to call object.A::Foo when you are trying to treat the object as an A, and likewise for B. But with java, will the overridden function C.Foo be able to know when the caller was treating the object as an A vs a B? If not, then it's sort of difficult for the class to know how to properly resolve these sorts of conflicts.
So java now supports default methods for interfaces? In other words "we now support multiple inheritance". Or at least that's pretty close to it. I thought the logic was that multiple inheritance is messy when you have diamond shaped inheritance, or two parent classes that have the same method names, so java only did single inheritance, but then allowed you to do interfaces to sort of simulate multiple inheritance (except you had to write all the code). But with this change, it seems the same as multiple inheritance, with the exception that interfaces cannot include (non-static) variables, only methods. Am I correct here, or am I overlooking something?
We came up with the modern national park (Yosemite was the first);
You misspelled Yellowstone
For a moment, I wanted to tell you I think you are totally wrong, but then I remembered...I'm only up to episode 3 so far. Up to this point, it seems like a really good show, to me at least. Hopefully I don't agree with you once I'm caught up, but unfortunately I could see you being right. The show reminds me quite a bit of Jericho. I loved that show initially. I loved how it showed people being isolated and falling back to low tech, and how the people come together to survive the emergency. That was really nicely done, but then they worked in the conspiracy theory part and made that a bigger and bigger part of Jericho. That really ruined the show for me. I would have been happier if Jericho left it as a mystery how everything happend.
So far (after 3 episodes), the conspiracy theory in Under the Dome is sort of small. I'm praying it doesn't take over this show too.
Although I haven't yet researched the answer online, I wish Android would provide a little better explanation of just how the backup feature works. I've got an android tablet and an android phone. I've installed different software on each one. I'm unclear on how the backup/restore works with multiple devices. When restoring to a brand new device, does it prompt you as to which old device's backup you want to restore from?
http://arstechnica.com/gaming/2011/03/the-cost-difference-in-mailing-netflx-vs-gamefly-all-of-gameflys-profits/
The reason GameFly pays more is because their mailers weigh more. Netflix keeps the mailer at 1 ounce and pays 44 cents each. GameFly's mailer is 2 ounces and they pay the two ounce price. The big giant clue in the linked article is that the USPS is considering changing the price of the 2 ounce mailer to the price of a 1 ounce mailer.
So the real story is that GameFly wants a discount with zero actual justification.
The packaging for GameFly costs more. Work it into your business model or reduce the packaging weight.
I don't do business with GameFly but if I did, I'd cancel. They actually have the nerve to pretend Netflix is getting some kind of special treatment while they are the ones seeking it.
There is nothing unfair about what the USPS is doing. The rest of us have to pay by the ounce for our mail.
Just read the article you linked. While interesting, it does kinda support Gamefly's case. A 2-ounce mailer cost $1.05, whereas a 1-ounce mailer cost $0.44. In other words Gamefly pays ~238% of what Netflix pays, 38% above any differences in weight. Further, at these weights, the majority of the cost of delivery is a flat cost, rather than an increase in fuel consumption due to weight. The cost of fuel to transport 1 ounce of additional weight is certainly less than a penny; the vehicle, occupant, and other cargo make up the vast majority of the weight (and the occupant's time is no small factor on the cost). Just basing numbers on the weight of the packages alone, charging ~$0.10 extra for the additional ounce will more than make up for the added costs.
There are other factors you haven't considered. Perhaps larger, thicker, or heavier packages tend to jamb in the automatic processing machines more often, requiring more manual intervention and slowing everything down. And even if that doesn't apply to gamefly's specific case, it may apply to packages greater than 1 ounce in general. And if that's the case, it would justify the post office making a special exception for gamefly since they wouldn't actually be costing more.
I really do appreciate a good framework... My favorite one currently is Vanilla-js http://vanilla-js.com/
Check it out. Amazing performance.
That's funny and cute. I thought it was a real framework for a moment. But that aside, the website is dishonest in their comparisons. They try to make the complexity of the "vanilla.js" code look much smaller by unnecessarily mentioning you have to include the jquery library (even though you only do it once per page regardless of you many times you use it in that page), and they include the script tags on the jquery example but not the vanilla.js example (or does vanilla.js somehow magically not need script tags to denote that it's script?). So to give a more honest comparison, lets look at their fading example. here's the real comparison:
vanilla.js:
var s = document.getElementById('thing').style;
s.opacity = 1;
(function fade(){(s.opacity-=.1)0?s.display="none":setTimeout(fade,40)})();
jquery:
$('#thing').fadeOut();
uhhhhhhhhh.....you know, I think I'll take the jquery one, thank you. Same thing with the ajax example...not as drastic as the fade example, but the jquery example is MUCH cleaner looking to me.
But oh yeah, there is the performance issue. 12,137,211 ops/sec with vanilla.js, vs only 350,557 with jquery. Yeah, that is quite compelling....except that I'm generally only doing a handful of operations per second, not 12 million, and the difference between a few nanoseconds and a few more nanoseconds really isn't that big of a deal. In the VERY rare case where I'm doing something where performance becomes an issue, I'll optimize where needed, but I don't waste my time prematurely optimizing.
You know what I like to actually optimize? Getting things working correctly. Think jquery is a waste? Well, lets look at that fading example above. Pretty darn simple, isn't it? Surely nothing tricky there. So lets see. jQuery seems to work fine. How about that more monstrous vanilla.js version they posted. ok, it's working fine in firefox. How about chromium. Oh interesting. Look at that. It fades out almost all the way, but never totally disappears and gets hidden. Why is that? The code LOOKS to be correct (though perhaps that < 0 should be <= 0 ...nope, that wasn't it). Ok lets do some debugging of the opacity value on each iteration:
1
0.9
0.8
0.7000000000000001 (uh oh, I see where this is going)
0.6000000000000001
0.5000000000000001
0.40000000000000013
0.30000000000000016
0.20000000000000015
0.10000000000000014
0.10000000000000014
0.10000000000000014
oh, hey. look at that. chromium never lets the value get below 0, so that function keeps getting called forever, but never actually finishes and hides it. OK, so that's one stike against it.
Here's another thought...what happens if the element with id 'thing' doesn't actually exist? Oops, he forgot to check for null, so anything after his .style in the first line of code line will never get executed because the javascript will abort with an error at that line. OK, 2 strikes.
OK, now what about when it is time to reshow the block we just hid. Hmmmm...now was that #thing object set to block or inline display? Oops, he forgot to save the state. We can set it to blank to go back to the default, but what if it was already overridden before we got to the value? Ooops. Strike 3.
Yes, his example could be adjusted to fix all of these issues, but that's the point. The code looks horrendous and it has at least 3 bugs in that simple example so you are going to have to make it even more complex. Meanwhile my jquery example simply worked and I'm already on to the next thing.
Actually, there is now a 6 tuner ceton, and while I haven't seen any reports on anyone buying it yet, we're pretty hopeful that it will work with mythtv just the same with no code changes. There is evidence in the 4-tuner version that the same code it uses was designed to work with 6 tuners.
As for the 4 tuner version, I've been happily running my mythtv with the 4 tuner ceton for over 2 years. If you can't get it working, then I'm sorry you have a shitty cable provider that locks down their content.
The last time, I had to explain to them what a cablecard even was, go through about six different people before they finally put on a tech who knew wtf he was talking about, and then deal with hours of installation hassles (thought I could just go pick it up and install it myself--nope, gotta have a tech come do it, and it's going to take him forever to get it working too).
Now I've got to try to explain to them what a "M" cablecard is. Great.
Nope, you don't have to explain anything to them. Just say "I want a cablecard". The new FCC regulations require that all cable companies only give out M-cards unless you specifically ask for a single stream card.
Why didn't they just go with XMPP? What their protocol have that XMPP doesn't, or couldn't be extended to support?
http://xkcd.com/927/
OK, did a quick look, and this is what I think they use:
http://store.apple.com/us/product/HA500VC/A/logitech-ultrathin-keyboard-cover-for-ipad?fnode=3e
I hate apple products as much as the next guy, but I'm not sure I can agree with this. I see my coworkers typing on their ipads all the time with a dock-like keyboard that attaches to act like a cover when not in use (not sure what it's called or if it's an official apple product or 3rd party).
You are right...it MOSTLY works flawlessly, but there are subtle issues you need to pay attention to. The All Mail thing usually would not be such a concern I would think. If you were migrating to a server that is fully imap compliant, then yes, those deleted messages would show up in an additional folder called '[Gmail]/All Mail' on the destination server, and you could just promptly delete that folder and you'd be back to what you would have expected.
However, the fact that these messages are showing up in people's inbox leads me to beleive they didn't do a full folder migration, and instead only copied the All Mail folder to the new inbox. Why would you do that? Well, as I mentioned in another post, my recollection of hotmail is that it supports INBOX access to imap, but doesn't support other folders. I don't know if Yahoo does a similar thing or not, but to me, that seems like the only excuse I could think of for copying All Mail to the inbox. Though even that isn't a good excuse...I don't see how they could justify letting their users lose their entire folder structure in the migration process.
A faster way would be to delete all in All Mail, then recurse through the other folders creating a duplicate tag in All Mail. Messages that only existed in All Mail before will be gone. All others are preserved.
You would think so, wouldn't you. And that would probably work if this were a fully imap compliant system, but that's exactly the point (and why they got into this mess to begin with)...it isn't.
For gmail, the message in "All Mail" is the sole existence of the actual message in the system. The copies of the message in other "folders" are really just references to the copy in "All Mail". So deleting it from All Mail is not really a choice. I can't remember from my testing back then what would happen if you DID delete it from All Mail. Either google would reject the delete, or the message would disappear from every folder it was in and not even leave a copy in the trash (you had to move it to trash if you wanted that). I know google rejects deletes of the entire All Mail folder, but I don't recall the result for trying to delete individual messages.
Yes, for migrating off of google, that's also an option (which I thought of right after clicking submit), assuming the recipient system supports folders. I don't know about yahoo. I was messing with hotmail a few months back before our migration, and I think my reccollection was that they support IMAP to the inbox, but no arbitrary folders. In a case like that, you'd have to collapse all the mail down to 1 folder (the INBOX), so pulling All Mail would be the easiest way.
In my case, we had a similar sort of issue while moving onto google, so ignoring "All Mail" wasn't an option, so I resolved as indicated in my other post.
Actually, I doubt it was Yahoo's fault either. This can't be the first time Yahoo has done an import from Google, can it (assuming they even handle the importintg for you...google doesn't)? If they had done this before, they'd have known about this problem with IMAP and the All Mail folder. So I'm guessing it Sky itself that made the mistake (or whatever consultant they hired to to do it) because of their unfamiliarity with Google's system.
Google does delete stuff (at least from our view...who can say what they really do behind the scenes). This is just a case of Google only being a pseudo-imap system. It's compatible with imap clients, but it's got some oddities in how they expose their internal system to imap. See my post above for more info.
Actually, I'm pretty certain I know exactly what happened, because I just handled a major migration to google and dealt with an issue like this. It's due to the way google uses labels instead of folders, and how they (mostly-transparently) expose them as folder via imap (though this is one of the few non-transparent side effects).
In google, when you "delete" a message via imap, it doesn't get deleted. Instead, google just removes the label. That message still exist with all of the other labels, and it also exists in "All Mail" (which is exposed via IMAP through the "[Gmail]/All Mail" folder). So, if you have new mail come it, it is by default in your INBOX and your "[Gmail]/All Mail" folders. When you then delete it from the INBOX via imap, it's still in All Mail.
The way to deal with this is to move the message into "[Gmail]/Trash" instead of deleting it. That will truely delete it. However, since that wasn't done all along, those "deleted" messages are now orphaned in "[Gmail]/All Mail". There is a potential way to resolve even this problem, but it depends on how the account has been used. If users have logged into Gmail directly and taken advantage of the "Archive" feature to remove a message from the inbox (without truely deleting it) then all bets are off. There is no way to differentiate intentionally saved messages from deleted-via-imap messages. However, if it has only been accessed via imap (and users haven't intentionally been trying to take advantage of the All Mail folder), then you can do the following via a script:
Go through every message in "[Gmail]/All Mail".
For each message, try to find that same message in another folder.
If you don't find it in another folder, then that message only exists in "[Gmail]/All Mail". You can then move it to "[Gmail]/Trash" to get rid of it.
Searching for messages 1 at a time is a bit slow, so you can optimize this by first building a list of all messages in other folders. If you just retrieve a few headers from every message, it's actually fairly fast. The "Message-ID" field is usually sufficient for this, but there may be messages here and there that don't have that header, so you'll have to have other headers to fall back on.
Yes, but it's like the old tale of wind and sun competing who gets the guy to take off his jacket. Wind blew and blew and all that accomplished was him to tighten his grasp on the jacket, sun instead shined and the guy took off the jacket voluntarily.
If you try to FORCE me to do something, expect me to resist. Give me what I want and you may expect me to cooperate.
Except that argument is BS. To put it in terms of your old tale, it's like the sun shined and shined and shined for years, but more and more people just put on their jackets. Then finally the wind starts blowing, and people get upset and say "if you'd just give me some sun instead of the wind, maybe I'd voluntarily take off my jacket".