I had to do dual income taxes the first year because I spent a partial year in both countries.
Wha? There are tax treaties, dude. If you actually paid twice on the same income, either you have a very unique situation or you did it wrong. Usually you pay one and get a foreign taxes paid credit for the other.
For me it wasn't standard curriculum, but we did have around 5 Commodore 64s in grades 5 and 6, and probably about half the class took the opportunity to learn C64 BASIC. It helped that we could to some degree control our learning in that class... not everyone is so lucky.
Do the publishers get a cut if you rent the game from Family Video?
They get the price that Family Video paid for the game, no? I didn't think they got any further revenue from rentals unless there's a law forcing it of which I'm not aware.
Using information culled from the public timelines of 40,000 randomly selected members...
Google deserves this sort of report given that 95%+ of their Google+ "members" were effectively forced into the system when they made Google Accounts require a Google+ profile.
Of course there is little activity among this group... most of them don't actually use Google+.
So far, the only values I see from noSQL solutions is to sacrifice ACID for horizontal scalability to fit the user scenarios where ACID is not that critical.
Bingo. There are a few of those use cases though (like the example I mentioned earlier, internal logging), especially when a lot of data is being generated / stored.
In NoSQL systems such as MongoDB and CouchDB, what do you call the operation where you retrieve one document, pull an identifier out of that document, and use that identifier as the key to retrieve another document?
A badly architected system that should probably be an RDBMS. If you're using a NoSQL database that way, you don't understand the use case for NoSQL (or RDBMS, for that matter).
Imagine doing the same thing against MySQL. Now you're making two trips to the database where only one is necessary. See the problem? Multiply that delay by several queries and it adds up.
If you're a software developer and you haven't read Ward's Wiki, I strongly advise doing so now. It has a lot of content from some very smart people you won't get elsewhere. Primarily it focuses on software design patterns, but even outside of that subject I've learned a lot just by reading random pages there.
Starting with a database avoids the pain of migrating flat files to a database later when the database is needed (and if your app gets at all popular, it will be).
Sure, if you're only ever expecting 10k rows of data with very little concurrent access, go nuts with your flat files.
The real key is for the person doing the hiring to understand which of those of methodologies fits their application.
This is insighful. I've worked extensively with RDBMS solutions and now quite a bit with NoSQL technologies. They each have their place. An entire article could be written on where each fits most naturally, but in general if you don't need to join between tables, need to throw data to your store at a high velocity (e.g. logging), and/or need a loose schema, a NoSQL solution works best. If what you're doing can be naturally modeled (i.e. users HAVE AND BELONG TO stations, stations HAVE MANY playlists, etc. etc.), use an RDBMS.
One can see in the subtext of the GP that they may not get this, with their comment that people using RDBMS solutions are "stuck in old ways". It seems like they are saying that NoSQL is effectively always best. I'm curious why they think that. Nail, hammer, etc...
Oh. If this is the case, they were, well, actually stealing service. In that case, fuck em.
Course, I'd want to see evidence first.
I had to do dual income taxes the first year because I spent a partial year in both countries.
Wha? There are tax treaties, dude. If you actually paid twice on the same income, either you have a very unique situation or you did it wrong. Usually you pay one and get a foreign taxes paid credit for the other.
Hey! Police! This startup is messing with my city-guaranteed monopoly! Take em down, officers!
I'm from there, nice city :^)
They should market this as a once-a-day pay-MUCH-extra ride at an amusement park.
It's only a crime if the people in power say it's a crime. Right now, the people in power are the MPAA.
gay marriage
Arizona
(in other words, not likely)
'Tenenbaum is just entering the job market and can't pay the penalty.'
That's what garnishments-for-life are for. Talk to some divorced fathers.
For me it wasn't standard curriculum, but we did have around 5 Commodore 64s in grades 5 and 6, and probably about half the class took the opportunity to learn C64 BASIC. It helped that we could to some degree control our learning in that class... not everyone is so lucky.
The reality is that most reasonable people here don't care, and are thus not commenting.
Mod parent up, I was thinking the same thing. This is political grandstanding.
Do the publishers get a cut if you rent the game from Family Video?
They get the price that Family Video paid for the game, no? I didn't think they got any further revenue from rentals unless there's a law forcing it of which I'm not aware.
Using information culled from the public timelines of 40,000 randomly selected members...
Google deserves this sort of report given that 95%+ of their Google+ "members" were effectively forced into the system when they made Google Accounts require a Google+ profile.
Of course there is little activity among this group... most of them don't actually use Google+.
including SSL connections to my email etc
So, bets on whether they were doing MitM logging of SSL connections?
most users feel little ownership of the content.
This is probably because the admins are very quick to remind editors that they are the real owners, with a revert.
So far, the only values I see from noSQL solutions is to sacrifice ACID for horizontal scalability to fit the user scenarios where ACID is not that critical.
Bingo. There are a few of those use cases though (like the example I mentioned earlier, internal logging), especially when a lot of data is being generated / stored.
In NoSQL systems such as MongoDB and CouchDB, what do you call the operation where you retrieve one document, pull an identifier out of that document, and use that identifier as the key to retrieve another document?
A badly architected system that should probably be an RDBMS. If you're using a NoSQL database that way, you don't understand the use case for NoSQL (or RDBMS, for that matter).
Imagine doing the same thing against MySQL. Now you're making two trips to the database where only one is necessary. See the problem? Multiply that delay by several queries and it adds up.
If you're a software developer and you haven't read Ward's Wiki, I strongly advise doing so now. It has a lot of content from some very smart people you won't get elsewhere. Primarily it focuses on software design patterns, but even outside of that subject I've learned a lot just by reading random pages there.
Fair enough, sorry if I misunderstood.
Starting with a database avoids the pain of migrating flat files to a database later when the database is needed (and if your app gets at all popular, it will be).
Sure, if you're only ever expecting 10k rows of data with very little concurrent access, go nuts with your flat files.
I hadn't read the article this was based on before, thanks for the laugh. I encourage others to Google "webscale" :^)
The real key is for the person doing the hiring to understand which of those of methodologies fits their application.
This is insighful. I've worked extensively with RDBMS solutions and now quite a bit with NoSQL technologies. They each have their place. An entire article could be written on where each fits most naturally, but in general if you don't need to join between tables, need to throw data to your store at a high velocity (e.g. logging), and/or need a loose schema, a NoSQL solution works best. If what you're doing can be naturally modeled (i.e. users HAVE AND BELONG TO stations, stations HAVE MANY playlists, etc. etc.), use an RDBMS.
One can see in the subtext of the GP that they may not get this, with their comment that people using RDBMS solutions are "stuck in old ways". It seems like they are saying that NoSQL is effectively always best. I'm curious why they think that. Nail, hammer, etc...
we're looking to build some sort of wall-mounted monitor + webcam thingy
So, um, grab a monitor and a webcam, and mount them to the wall...
This is innovative and brilliant, and so the movie industry will find some reason that they can't do it because it would take too much effort.
Indeed, I have often wondered why they don't fucking use ATMs for voting machines.
Diebold's primary business is ATMs. Effectively, we already are.