MySQL might be the right answer, as long as you don't need to use more sofisticated stuff, like triggers or transactions.
Or complex joins, multi-level joins, or functions that return recordsets (essentially "efficiently-parametrized views"). My last attempt at creating views within views resulted in a LEFT OUTER JOIN somehow transforming itself into an INNER JOIN, forcing me to "inline" the entire SQL query into a single view. Oh yeah, and the performance wasn't so great, and the MySQL "query explanation" capabilities suck, so I had a much harder time improving said performance.
Nope. Certain features of C++ have a lot of overhead. That's part of the reason it's so complex in the first place—it follows the principle of "if you don't use it, it won't cost you anything." And in many of those cases, the power granted by those features comes at the same cost as it would to handle the same level of complexity in C.
Everything light does is a combination of reflections and refractions (shadows are an artifact of those).
So, yeah, what you are in effect saying is that raytracing only provides realistic rendering of things that light actually does.
More accurately, raytracing is only "good" at specular reflection/refraction and hard shadows. Diffuse reflection is terrible with traditional raytracing, because it requires so many samples in order to get a good result with low variance. This applies to shadow rays as well, because a sufficiently large light source requires the same computation power for sampling as diffuse reflection.
Think about it this way. I can use x86 assembly to write a web app, but it's far more productive to use a language that makes rapid prototyping and high-level design easier. Just because something is possible (bidirectional path tracing, the "gold standard" of photorealism last I checked) doesn't mean it's a good idea, if it takes orders of magnitude more effort to succeed.
But still, let's look at something like cars then. Marketed to project an emotion because they essentially an emotional purchase. That's what people actually want from their cars. You can't provide much in the way of a full description of features in a 30 second ad, so you focus one or two and explain how that will make someone feel (leather seats make you feel comfortable, high performance makes you excited, hybrid engine makes you feel environmentally conscious), because at the end of the day, you can get the feeling across more quickly than you can make the argument. But then you go to the dealership get a pamphlet that explains all the features of the car and lists things in a point-by-point fashion for people to make their rational choices with.
If that's all there was to marketing, I think a lot of slashdotters would be more accepting of marketing. I'll toss out a few examples of things that actually anger me:
Ditech commercials that open with, "People are smart." Really? Is Ditech marketing their services because they think people are smart? Because my thought is that if people were smart, less of them would have a use for debt-consolidation services in the first place. Thus, the conclusion I come to is that Ditech knows that people aren't smart, and is thus intentionally lying to viewers to make them feel good. Bullshit.
Any hygenic product that uses the phrase "essential oils". An essential oil is simply an oil created by the "essence" of some solid material. This is an unfortunate technical term that happens to overlap with the nontechnical meaning, "an oil that I require". In this case, the marketing department is deliberately using technical terms with the expectation that they will have an unrelated emotional impact on viewers.
Any health-related product that claims it is "clinically proven to help". To help? How much? Who does it apply to? What if some diet drug is clinically proven to help incredibly obese people who begin a strict 3-hours-daily exercise regimen, to reduce their weight an additional 2%? Technically, the marketers are right. It's clinically proven to help... in extreme cases... a tiny amount. But all of the sleazy diet-pill commercials that I see all sound the same, so I (quite possibly erroneously) write them all off because of their inability to convince me of their expected efficacy.
Transitions lenses commercials. They've always bugged me. I had a pair once, and discovered the suckitude for myself. They take about 15 minutes to go from "dark" to "light". Also, their "dark" scale is nowhere near what is necessary on a very bright day. I notice that the lenses in commercials always looked significantly darker than my lenses ever got. Prescription lenses are particularly difficult for experimentation, so I had to waste my money on them in order to know that they are ineffective outdoors and annoying indoors. But now that damned photographer commercial is showing, and all I can think is, "I would NEVER want inconsistent tint on my lenses if I were a professional photographer. My eyes are too important to depend upon transitions lenses."
Car commercials that focus entirely on emotions. A car is an emotional purchase? Really? That's an awful lot of money to be spending on emotions. I understand brand recognition, but I'd like for a commercial to actually give me some information about the car, rather than just trying to tell me that I want it. Don't tell me what I should want. Tell me why I should care.
Ok, so we have pandering, abuse of vocabulary, technical omissions, general omission of weaknesses, and noninformation/noise. That all sounds like lying to me, though omission of weakness is probably the most "acceptable".
To be fair, here's some work of marketing that doesn't bother me...
Commercials for local food services (e.g. late night pizza delivery). They sa
In this case, the freeloaders are taking bandwidth, which won't be available to customers that need it. Usually, I would say "copyright infringement", but this is an actual theft of service. If someone left their house door open, then it's "unlocked" and "freely accessible", but no one would argue that walking in and taking something without the owner's knowledge was wrong. There is no difference in this case.
I fail to see how using someone's bandwidth constitutes theft... even a DDoS would seem to fall more under harassment than actual theft. So really, your analogy makes much more sense as, "I left my front door unlocked so my friends could get in, but now so many strangers are going in and out of my door that my friends are stuck out on the porch!" As a bonus, it's more entertaining to imagine about a denial-of-service attack on a doorway.
A better analogy would be, a company has poor security policies and the account numbers for their corporate holdings fall into every employee's inbox. If employees make withdrawels, are they stealing? Yes they are.
Leave your car unlocked in parts of St. Louis, someobody will take your car stereo.
Both of these analogies involve physical theft. If I take your radio, or if I withdraw money from your account, you no longer have that item/money. While bandwidth is not free, using the WWW the way it was intended by downloading the content available at a publicly-accessible URL is not in the same ballpark. Morally, if those people knew the URL was intended to be private, they are guilty of freeloading, but it's certainly not equatable to theft.
Kind of like how if I find boxes of books in front of a bookstore in a public area, I can take it so long as there aren't any signs saying not to?
I always get the feeling that when bookstores put out those boxes of books on the sidewalk, there's a big invisible sign saying "please take these". It's always the crap that nobody cares about! After all, it is indeed possible for something to have such a low value that the shopkeeper would rather give it away (thereby generating goodwill and maybe a bonus sale in the future) than attempt to sell it for a nickel (thereby sending the message, "hi, we sell crappy stuff").
Not that I've ever taken any books out of those piles myself, but I wouldn't consider it such a travesty as you describe.
Second the previous sibling. Artists generate models out of subdivision surfaces (a curved "limit surface" in space that is approximated by subdividing into many small triangles). The triangles are subdivided small enough to fit into a single pixel, making scanline rendering trivial. So the bulk of the work being done is still essentially rasterizing, with the actual triangles being generated on-the-fly to match the level of detail required.
Raytracing itself is done only where needed... in general, that would be for reflective and refractive surfaces; either mirror/glass or some sort of glossy/blurry material. Photon mapping (which is similar but not identical to reverse raytracing) handles diffuse interreflection and caustics. All of those effects add quite a bit to the overall effect of an image, but they are only used when the rasterizing engine is insufficient.
In short, it's the 80/20 rule all over again. 80% of the rendering is cheap rasterization, the last 20% is expensive ray casting (ray tracing + photon mapping).
Ignoring C++ developers simply because one has a Java web platform...is just plain ignorant
Ironically, it is exactly my experience in C++ that makes me unhappy with a Java platform. Though developers who don't want to work with any particular piece of technology will self-select themselves away from it. On the other hand... while a platform as large as Java or as "tricky" as C++ may be easy to initially pick up, it will still take years to master. Some shops are willing to pay top dollar to attract those platform masters.
I mean, hey, it's how everybody does "web-scale computing", but since you've seen it fail once, it must be a terrible idea, right?
Ease up on the sass!
HTTP is stateless, which makes it basically an "embarassingly parallel" problem, similar to raytracing, or batch multimedia processing. Renderfarms are very common, too. Plus, if any given node a render/HTTP-farm fails, it is easy to recover (just retry the operation).
You don't know the details about the problem that was being solved, so it's hardly fair to say "easily-parallelizable problems are good to put on clusters, so your problem should also be good to put on a cluster!" Something like an write-heavy database server probably just isn't going to get the same benefit of being on a PC cluster, unless you spend a massive amount of effort on data partitioning and distributed failover mechanisms.
What do those idiots at google know, anyway?
They know how to implement their solutions to benefit from parallism (MapReduce). They know how to use the right tool for the job. Anything they can throw MapReduce at is ideal for clustering; that definitely includes search.
The way to avoid this in the future is to remain low-tech. Don't tie yourself to deeply into solutions crafted onto solutions. For instance use PHP, not bloody frameworks build on that. If you then use a software suit, build on a framework, build on a language, build on a platform, well you are going to have problems finding someone with those exact skills.
Having been there myself, I can see three possible results from following that advice:
You consistently write low-level code, and your code is full of duplication. If it's not full of duplication, it's because it doesn't have many useful features, like the necessary security precautions on top of vanilla PHP. It takes a lot of effort to change fundamental patterns (because of the duplication).
You use someone else's framework. It mostly fits the bill, but not entirely. You still have to write plenty of your own code to extend the framework as necessary (or modify it, but that's another whole can of worms). You ignore it for the purpose of hiring, since anyone worth hiring can be taught how to use the tools.
You end up crafting your own framework (or toolkit). It fits your particular tasks better than any other popular (and thus overly general) framework. It also has a lot more bugs than the others, and a higher learning curve because it has more poorly-thought-out idiosyncracies.
I'm personally a fan of #2 when you're starting from scratch, or #3 if you are willing to bet on the skill/experience of your developer(s) and you have a lot of legacy components to interface with. Just don't fool yourself into thinking that avoiding canned solutions will keep you "free"... you'll just be chained by your own creations, instead of someone else's. And of course, this applies to any language; not just PHP.
In computer science, it's either the Microsoft suite...
Only one class I was in ever allowed Visual Studio building. Everything else was either Sun or Redhat Linux, due to the command-line handin program for machine problems.
... or specific open source products like MySQL (why not PostgreSQL?)
I don't remember ever using MySQL in a single computer science. We used Oracle/JDBC for a databases course (MySQL probably wouldn't cut it, from a technical "look at the guts" point of view). The graduate level course involved students adding features to PostgreSQL, though I don't know how often those features were accepted by the maintainers.
Indoctrination of corporate branding? Maybe in a vocational curriculum (where it makes sense, since the goal is producing marketable skills), but certainly not in a good computer science curriculum (where the goal is advancing the theoretical state-of-the-art and producing researching skills).
I don't know ruby, so I may not totally understand that snippet, but here's a few python equivalents:
# ruby myList = [] 10.times do |i| mList.push(i) end myList.each do |l| puts l end
# python (normal loop, more straightforward) for l in range(0, 10): print i # or sys.stdout.print("%d\n", l)
# python (list comprehensions, more direct analogy) import sys myList = range(0, 10) [ sys.stdout.print("%d\n", l) for l in myList ] # note this is a bit wasteful, since list comprehension is a "map" operation, giving us a list that we immediately discard afterwards
Regarding python counting your spaces... if you don't already have consistent whitespace for indentation, your code probably looks like crap. The whitespace "requirement" in Python is a non-issue, since 99% of the sane world already indents by blocks.
From what I've seen, anonymous blocks in ruby have more lightweight syntax than Python (which requires either a lambda function, which can only have expressions but not statements; or a locally-defined and named function). Other than that, there's not a great deal I've seen different between the languages.
I heard somewhere the recommendation that "mission critical" only be used for systems where lives hang in the balance... flight/space control systems, certain medical technology, etc. Put another way... if the ramifications of 1 week of payroll downtime result in people being unable to pay bills, suing the company, putting the company out of business... it wasn't that the mission was critical, it was just that there was no margin for error external to the system.
Of course, lots of business executives tend to overvalue the worth of their own business (probably not a bad thing by itself), resulting in lots of stupid "mission critical" labels, and devaluing the term in the long run.
Would you expect your grocery store to pay for your chiwawa when he starves to death because the store is out of dog food?
Amusingly, I would expect my chihuahua to gnaw on my hand until I got the picture and gave him something else to eat. Because that's what he does when I forget to feed him after work.
And if you want to scare off the lesser programmers, mention "scary" algorithms that might come in handy—"familiarity with Q-learning a plus" or something like that.
Just be careful with that. I've become the main "tech filter" for potential candidates at my company, and one of my new pet peeves is people name-dropping uncommon data structures without having the cojones to back it up. Though, it is cool to find someone who mentions L-systems or Hough Transforms and really means it.
I haven't watched TV in years. I did manage to catch a bit at my gf's parents house the other day, and it was shocking to see how much were actually ads. I completely agree with lack of content.
It's even worse than that. Most of the cable stations show mini-ads for their moneymakers during other programs. I can't watch anything without seeing tiny little men and women walking around the bottom of my TV! It sure makes it hard to watch something like Crouching Tiger, Hidden Dragon or Amelie, where the little people cover up the subtitles.
Man, I know what you need! I saw an ad for an "idiot filter" when I was watching chess on tv.
I was watching that, too! Only, since I already had the idiot filter installed, the tv (which I don't even own!) was showing a much deeper game of Go. And also, PHP is better than your language of choice in every way imaginable.
Usually, I find that PHP makes for unmaintainable code. Simple websites don't have this problem, but then, simple websites sometimes grow up to be large ones.
Think about it like a math word problem:
Small PHP websites are significantly easier to develop than small Java websites
Large/complex PHP websites are significantly harder to develop than large/complex Java websites
Some small percentage of all small websites grow up into larger websites. The others remain small or disappear entirely.
If you operate on the basis that most websites stay small (maybe 95-99%), the it's more useful to do the crappy solution first, and simply accept the cost of upgrading it to a good solution when it's already "proven" itself in on the Internet.
Slashdot Mirror
Or complex joins, multi-level joins, or functions that return recordsets (essentially "efficiently-parametrized views"). My last attempt at creating views within views resulted in a LEFT OUTER JOIN somehow transforming itself into an INNER JOIN, forcing me to "inline" the entire SQL query into a single view. Oh yeah, and the performance wasn't so great, and the MySQL "query explanation" capabilities suck, so I had a much harder time improving said performance.
Nope. Certain features of C++ have a lot of overhead. That's part of the reason it's so complex in the first place—it follows the principle of "if you don't use it, it won't cost you anything." And in many of those cases, the power granted by those features comes at the same cost as it would to handle the same level of complexity in C.
More accurately, raytracing is only "good" at specular reflection/refraction and hard shadows. Diffuse reflection is terrible with traditional raytracing, because it requires so many samples in order to get a good result with low variance. This applies to shadow rays as well, because a sufficiently large light source requires the same computation power for sampling as diffuse reflection.
Think about it this way. I can use x86 assembly to write a web app, but it's far more productive to use a language that makes rapid prototyping and high-level design easier. Just because something is possible (bidirectional path tracing, the "gold standard" of photorealism last I checked) doesn't mean it's a good idea, if it takes orders of magnitude more effort to succeed.
If that's all there was to marketing, I think a lot of slashdotters would be more accepting of marketing. I'll toss out a few examples of things that actually anger me:
Ok, so we have pandering, abuse of vocabulary, technical omissions, general omission of weaknesses, and noninformation/noise. That all sounds like lying to me, though omission of weakness is probably the most "acceptable".
To be fair, here's some work of marketing that doesn't bother me...
without the ads. http://www.tgdaily.com/index2.php?option=com_content&task=view&id=36390&pop=1&page=0&Itemid=118
I fail to see how using someone's bandwidth constitutes theft... even a DDoS would seem to fall more under harassment than actual theft. So really, your analogy makes much more sense as, "I left my front door unlocked so my friends could get in, but now so many strangers are going in and out of my door that my friends are stuck out on the porch!" As a bonus, it's more entertaining to imagine about a denial-of-service attack on a doorway.
Stop, Thief!
Both of these analogies involve physical theft. If I take your radio, or if I withdraw money from your account, you no longer have that item/money. While bandwidth is not free, using the WWW the way it was intended by downloading the content available at a publicly-accessible URL is not in the same ballpark. Morally, if those people knew the URL was intended to be private, they are guilty of freeloading, but it's certainly not equatable to theft.
I always get the feeling that when bookstores put out those boxes of books on the sidewalk, there's a big invisible sign saying "please take these". It's always the crap that nobody cares about! After all, it is indeed possible for something to have such a low value that the shopkeeper would rather give it away (thereby generating goodwill and maybe a bonus sale in the future) than attempt to sell it for a nickel (thereby sending the message, "hi, we sell crappy stuff").
Not that I've ever taken any books out of those piles myself, but I wouldn't consider it such a travesty as you describe.
A likely story! Next you'll claim that the Smurfs weren't animated in real time, either.
Second the previous sibling. Artists generate models out of subdivision surfaces (a curved "limit surface" in space that is approximated by subdividing into many small triangles). The triangles are subdivided small enough to fit into a single pixel, making scanline rendering trivial. So the bulk of the work being done is still essentially rasterizing, with the actual triangles being generated on-the-fly to match the level of detail required.
Raytracing itself is done only where needed... in general, that would be for reflective and refractive surfaces; either mirror/glass or some sort of glossy/blurry material. Photon mapping (which is similar but not identical to reverse raytracing) handles diffuse interreflection and caustics. All of those effects add quite a bit to the overall effect of an image, but they are only used when the rasterizing engine is insufficient.
In short, it's the 80/20 rule all over again. 80% of the rendering is cheap rasterization, the last 20% is expensive ray casting (ray tracing + photon mapping).
Ironically, it is exactly my experience in C++ that makes me unhappy with a Java platform. Though developers who don't want to work with any particular piece of technology will self-select themselves away from it. On the other hand... while a platform as large as Java or as "tricky" as C++ may be easy to initially pick up, it will still take years to master. Some shops are willing to pay top dollar to attract those platform masters.
Seriously? That's like hunting in a forest for 7-leaf clovers and leprechauns!
Ease up on the sass!
They know how to implement their solutions to benefit from parallism (MapReduce). They know how to use the right tool for the job. Anything they can throw MapReduce at is ideal for clustering; that definitely includes search.
Having been there myself, I can see three possible results from following that advice:
- You consistently write low-level code, and your code is full of duplication. If it's not full of duplication, it's because it doesn't have many useful features, like the necessary security precautions on top of vanilla PHP. It takes a lot of effort to change fundamental patterns (because of the duplication).
- You use someone else's framework. It mostly fits the bill, but not entirely. You still have to write plenty of your own code to extend the framework as necessary (or modify it, but that's another whole can of worms). You ignore it for the purpose of hiring, since anyone worth hiring can be taught how to use the tools.
- You end up crafting your own framework (or toolkit). It fits your particular tasks better than any other popular (and thus overly general) framework. It also has a lot more bugs than the others, and a higher learning curve because it has more poorly-thought-out idiosyncracies.
I'm personally a fan of #2 when you're starting from scratch, or #3 if you are willing to bet on the skill/experience of your developer(s) and you have a lot of legacy components to interface with. Just don't fool yourself into thinking that avoiding canned solutions will keep you "free"... you'll just be chained by your own creations, instead of someone else's. And of course, this applies to any language; not just PHP.I don't remember ever using MySQL in a single computer science. We used Oracle/JDBC for a databases course (MySQL probably wouldn't cut it, from a technical "look at the guts" point of view). The graduate level course involved students adding features to PostgreSQL, though I don't know how often those features were accepted by the maintainers.
Indoctrination of corporate branding? Maybe in a vocational curriculum (where it makes sense, since the goal is producing marketable skills), but certainly not in a good computer science curriculum (where the goal is advancing the theoretical state-of-the-art and producing researching skills).
I don't know ruby, so I may not totally understand that snippet, but here's a few python equivalents:
# ruby
myList = []
10.times do |i|
mList.push(i)
end
myList.each do |l|
puts l
end
# python (normal loop, more straightforward)
for l in range(0, 10):
print i # or sys.stdout.print("%d\n", l)
# python (list comprehensions, more direct analogy)
import sys
myList = range(0, 10)
[ sys.stdout.print("%d\n", l) for l in myList ]
# note this is a bit wasteful, since list comprehension is a "map" operation, giving us a list that we immediately discard afterwards
Regarding python counting your spaces... if you don't already have consistent whitespace for indentation, your code probably looks like crap. The whitespace
"requirement" in Python is a non-issue, since 99% of the sane world already indents by blocks.
From what I've seen, anonymous blocks in ruby have more lightweight syntax than Python (which requires either a lambda function, which can only have expressions but not statements; or a locally-defined and named function). Other than that, there's not a great deal I've seen different between the languages.
I heard somewhere the recommendation that "mission critical" only be used for systems where lives hang in the balance... flight/space control systems, certain medical technology, etc. Put another way... if the ramifications of 1 week of payroll downtime result in people being unable to pay bills, suing the company, putting the company out of business... it wasn't that the mission was critical, it was just that there was no margin for error external to the system.
Of course, lots of business executives tend to overvalue the worth of their own business (probably not a bad thing by itself), resulting in lots of stupid "mission critical" labels, and devaluing the term in the long run.
Amusingly, I would expect my chihuahua to gnaw on my hand until I got the picture and gave him something else to eat. Because that's what he does when I forget to feed him after work.
Just be careful with that. I've become the main "tech filter" for potential candidates at my company, and one of my new pet peeves is people name-dropping uncommon data structures without having the cojones to back it up. Though, it is cool to find someone who mentions L-systems or Hough Transforms and really means it.
#1 reason why IMAP access from Google is awesome. No more gmail.com sitting in my web browser.
It's even worse than that. Most of the cable stations show mini-ads for their moneymakers during other programs. I can't watch anything without seeing tiny little men and women walking around the bottom of my TV! It sure makes it hard to watch something like Crouching Tiger, Hidden Dragon or Amelie, where the little people cover up the subtitles.
I was watching that, too! Only, since I already had the idiot filter installed, the tv (which I don't even own!) was showing a much deeper game of Go. And also, PHP is better than your language of choice in every way imaginable.
Think about it like a math word problem:
- Small PHP websites are significantly easier to develop than small Java websites
- Large/complex PHP websites are significantly harder to develop than large/complex Java websites
- Some small percentage of all small websites grow up into larger websites. The others remain small or disappear entirely.
If you operate on the basis that most websites stay small (maybe 95-99%), the it's more useful to do the crappy solution first, and simply accept the cost of upgrading it to a good solution when it's already "proven" itself in on the Internet.