[Some n00b players] would rather spend time, which is money, practicing than tuning.
As a data point, I own an Epiphone Les Paul. I would consider it an easy purchase for any middle-class slashdotter, or even a dedicated teenager ($400 new at Musician's Friend). I keep it in a hard case, and the only temperature/humidity swings it really has to deal with are car rides to practice (3 hours away). It is very good at staying in tune, even with weeks in between practice (1 string seriously out, everything else still ok). I've been considering getting new tuning pegs ($50), which would improve the issue.
Point is, tuning really doesn't take that much time, and you don't have to shell out very much to get equipment that is "good enough". The only n00bs that should buy this are the ones with money burning holes in their pockets.
You just hold it, it reads your mind and plays what you want flawlessly!
You know, there's always this annoyance of hum/noise when a guitar is plugged in (probably due to bad grounding, I'm not positive). What I'd really like is a guitar that somehow replaces that hum with the constant sound of wicked Dream Theater harmonized leads.
Why can't the guitar just tune itself, but without tightening the strings. If the guitar has a pick-up for each string, then it knows which string is being plucked. Then all you would have to do is pluck each string, so it would have a reference point. Then a small computer inside the guitar changes the sounds to the proper tune and then they are sent to the amp.
I prefer the small computer inside my head. It's way less likely to fail; and more fun, to boot.
Given time and development, I see no reason that a computer shouldn't be able to handle this problem any worse than it could jpeg compress a photo into a file 1 tenth of the original size, with little noticeable difference
As other people have said, object-boundary detection is much more complex than color manipulation. There's more to it, though. Surface simplification has always been based around a basic model:
Determine an error metric to use on the mesh
Come up with an algorithm that reduces vertex count while minimizing that error metric
For high-poly-count models, this works great. You can take a 3D scanner, massage it into a manifold surface, and then simplify it from millions of points down to 10,000. The location of a single vertex has such a miniscule effect, because the relative vertex density is still so high. A surface-simplification algorithm can use simple error metrics like displaced volume.
The problem comes in when we talk about error metrics for low-polygon models, which have orders of magnitude less vertices. For a video game character, a nose may be defined by a handful of vertices. Leaving the simplification up to an algorithmic error metric will undoubtably result in a funny-looking nose, at least in some cases. That's where the artist comes in; tweaking a few things here or there until the model subjectively looks right (instead of being mathematically right). Even if appropriate error metrics could be defined, they would still tend to be viewpoint-sensitive (if the model is facing away from you, shoulders need many vertices to look round; if it's sideways, shoulder geometry can be simplified using bump maps).
Recent work has been done on mesh salience, which does a pretty good job by itself, but it still produces a model with too many polygons for some applications. Even as GPUs get faster, studios still choose to go with low-polygon models when possible, because it means overall scene complexity can increase.
Whenever the first computer algorithm was devised to parse HTML. Just because your computer's font system can't differentiate between italics and emphasized text doesn't mean a machine reader can't.
Of course, this is largely academic, since most markup is ignored by bots. However, it's only a matter of time before Google starts incorporating "good authorship" trust-levels in their heuristics (so documents that match expected "good" tag distributions are considered more trustworthy w.r.t. keyword weighting).
Probably a bad idea, but it is the ultimate in flexibility and platform independence.
had their on memory management
Any OS's default malloc implementation is optimized for general usage. If you have specialized needs, memory management is not that rare to override. Google for Doug Lea's malloc.
special logging and tracing routines
Depending on the language used and the corporate infrastructure, this might not be a terrible idea. If you can log via reliable multicast on several channels, why not? If you have a logging system based on C macros that removes debug-logging in release mode, you've shaved off microseconds from every function call.
and even time zone conversion
Now *this* is hard to justify. Time zone conversion absolutely sucks, because it's nothing but a long list of gotchas.
You should be happy they didn't even try threading, judging by your opinion of their general skill level. Anyways, "single-threaded" by itself isn't strictly a bad thing. The best I/O throughput can be done with single-threaded asynchronous-I/O apps, where you can completely avoid context switches from threads and mutices (mutexes?). Though I doubt this was the case in your example (^:
Elegant but inefficient code is rare outside books.
I think the entire Ruby on Rails movement would disagree with you, especially those with the attitude of "add servers if performance isn't sufficient". It all depends on the industry you're in: whether time-to-market is more important than performance.
...under example.mobi users can have some confidence that appropriate mobile-friendly standards will be externally enforced...
Is that true, or is that just hypothetical? If it's anything like.org or any of the country codes (.tv in particular), I have exactly 0 confidence in.mobi "mobile-friendly" enforcement. How would a standards committee even enforce such a loose concept as "mobile-friendly"? Does it mean "smaller than the desktop page"? What percentage size difference is necessary? Does it mean "does not include Flash/Java/whatever-plugins"? Who decides the mobile-friendly plugins? Aside from bandwidth, most mobile-friendly design is rated emotionally based on its intuitiveness... we don't have the models necessary to quantify that, so we're still back to "what some uber-designer with CSS and Flash on the brain decides" because of the lack of measurability and enforcability..
So... this only broke websites where programmers blindly accepted user input and trusted it, right?
This is a bit different from your average user-input problem. Saying "don't trust that the user agent is accurate" is like saying "don't trust that the name this person entered in the form is accurate". Sure, you may assume it's BS data, but there's nothing you can do about it. If the user wants to say their name is "John Q Public", you have to take it at face value. If the user insist that their browser is KHTML, you have to take it at face value. If they say KHTML and they're lying, too bad. It's either their fault for lying (no sympathy), or it's their provider's fault for screwing with data (sucks for the user).
This problem is orthogonal to the security issues caused by taking arbitrary inputs and passing them to arbitrary external data sinks (SQL/shell commands).
That's why I set up my.mobi site alongside my main one, to present a more appropriate (read: smaller, faster, search box at the bottom) view for mobile browsers.
Not that it's your fault for creating it, but the.mobi TLD is an abomination of all that is good in this world. If your organization is example.com, it's much more logical to use subdomains (e.g. mobile.example.com or m.example.com) than to create a different TLD (and thus imply a different organization).
This in turn enables me to, say, scale images to an optimal width server side. It saves a lot of bandwidth and makes full use of a larger screen.
That's what SVG is for.
Too bad reliable SVG display doesn't work without either UA sniffing (either explicitly on the server, or using Javascript heuristics on the client), thanks to the most popular browser in the world. Nor are many people interested in downloading Adobe's SVG viewer (which is required to view SVG in IE, AFAIK). Nor is SVG even remotely useful for raster images (whodathunkit?), which is what most of the world's images are.
Assuming you're using iptables, you could simply add this rule (typed offhand, not sure if syntax is correct):
iptables -A OUTPUT -m owner -uid-owner apache -p tcp -d 72.232.101.0/24 -dport 80 -j DROP
You'd have to change this if/when wordpress.com changes hosts, but it'll block traffic from the apache user destined towards *.wordpress.com:80. That should be sufficient to avoid screwing other outbound connections.
XML is an easy to parse and validate fragment of SGML
XML and SGML are not interchangeable. <foo/> is a self-closing tag in XML. <foo/ is a self-closing tag in SGML (full SGML really has weird syntax to anyone used to HTML or XML). XML is easier to parse than SGML, specifically because it is not SGML.
If you can't correctly manage memory in C++, it's pretty much guaranteed you can't write a sychronization correct multithreaded application.
Amen!
To add to that: If you can't correctly manage memory in C++, you probably can't correctly manage any other resources an average program has to deal with:
open file handles (close when you're done)
open network connections (close when you're done)
database connections (close when you're done) or transactions (always commit or rollback, regardless of exit path)
external temporary files (unlink when you're done)
external configuration files (more complex, because you need transactional programming: what if your program crashes while you're re-writing the config file?)
Python and C++ (and probably Perl), make these tasks easy by using deterministic object destruction (RAII FTW!). In Java, this is about the same level of complexity as malloc/new and free/delete, so you're back to square one on resource management.
...most computers spend most of their time idle anyways, and most application are idle waiting for inputs...
So in the once in a while heavy processing moment say in this case an HTML Render adding 1 second to the load in real life most people wont notice unless they are going back and forward button crazy
Actually, it's fairly well accepted that making a computer "feel" responsive is far more important to desktop users than increasing its throughput. For example, Ubuntu's desktop and server distributions have different kernel parameters targetted respectively to improve UI latency and throughput. For specifics on the web, check out Jacob Nielsen's site (he lists further references for HCI studies). The quickest way to make an application feel unusably slow is to block the UI while processing, so it is crucial that UI interaction either be very fast, or delegate its work to another thread/process.
It's perfectly fine to trade efficiency for simplicity, but UI latency is not the place to do that trade.
$db->execute(sprintf("INSERT INTO users VALUES(NULL, %s)", $db->quote($_GET['user'])))
...writing "very quick PHP functions" 90 times for 30 different tables and 3 different applications quickly become tiresome
There's an alternative. You could write a function once, instead of once per your 30 tables. Write it as a portable library script for your 3 applications. You're still "writing biolerplate", but I think you're overestimating the amount required:
(as a part of $db class, or a $db subclass)
function insert($table, $records) {
$columns = array();
$values = array();
foreach ($records as $column => $value) {
$columns[] = $column;// assuming your literals are always safe
$values[] = $this->quote($value);
}
$sql = sprintf('INSERT INTO %s(%s) VALUES(%s)', $table,
join(',', $columns), join(',',$values));
$this->execute($sql);
}
This should work for any table (well if a column name has spaces in it, you'll need a $db->escapeLiteral() function, or a better column naming scheme!). If you ever work on more than one PHP project, it makes sense to try to carry around a common codebase between them for this.
Everything's on a continuous scale, anyways. The less RoR you use, the more boilerplate you have to write yourself (because RoR has done all of the boilerplate for you, for basic CRUD operations). But the upside is the increase in freedom, if that is important to you.
Ok... you wanted one good reason to write that boilerplate function. It doesn't require as drastic of a change as switching your entire web server platform. Most software developers are working on existing projects, rather than new projects. Or maybe you're working with an existing talent pool that will be difficult to migrate, or you have to interface with existing legacy PHP. Sure, use RoR for your next project, but for whatever projects that are in production, incremental change rules the day.
Because I took the time to wear an ironed shirt, and maybe add some accessories like a belt or a necklace, that means it's appropriate to for male co-workers to "gently rib" me about my clothing? But what is the joke? Why say anything? I really don't get it.
You also have to consider recent history in sexual harassment lawsuits/rules/"training" in corporate environments. If a male coworker says "I like your skirt today", you could feasibly take him/the company to court and win a sexual harassment suit.
A male co-worker who may be afraid of that issue, or simply intimidated by a female (esp. if you are attractive), has the potential to covertly bring up the issue of your clothing by spinning it into a joke. Giving you a gentle ribbing may simply be a way of acknowledging that you dressed up nice while completely avoiding the sexual-harassment minefield, or without giving an outright complement. I'm not saying it's the right thing, but (to rephrase) "do not attribute to malice what can be attributed to shyness".
All of this goes along with what others were saying - many groups of guys get along and show welcomeness by giving each other a "playfully hard time". Your co-workers could just be treating you as one of the boys.
Just like installing a datacenter is plugging the cords into the holes they fit in, right bro?
If by "installing a datacenter" you mean "installing a Mac Pro into my living room", then yes. Server admins and bodybuilders alike have to start with baby steps.
PMS is real, it's not some secret male propoganda or anything. Most girls I've dated have knowingly acted less rationally during their periods. Calling it insanity should be clearly recognized as hyperbole, and (IMHO) is no worse than saying I'm starving when I'm really just mildly hungry.
Slashdot Mirror
As a data point, I own an Epiphone Les Paul. I would consider it an easy purchase for any middle-class slashdotter, or even a dedicated teenager ($400 new at Musician's Friend). I keep it in a hard case, and the only temperature/humidity swings it really has to deal with are car rides to practice (3 hours away). It is very good at staying in tune, even with weeks in between practice (1 string seriously out, everything else still ok). I've been considering getting new tuning pegs ($50), which would improve the issue.
Point is, tuning really doesn't take that much time, and you don't have to shell out very much to get equipment that is "good enough". The only n00bs that should buy this are the ones with money burning holes in their pockets.
You know, there's always this annoyance of hum/noise when a guitar is plugged in (probably due to bad grounding, I'm not positive). What I'd really like is a guitar that somehow replaces that hum with the constant sound of wicked Dream Theater harmonized leads.
I am interested in purchasing one of these guitars you speak about. Preferably one with 88 keys^H^H^H^Hstrings.
I prefer the small computer inside my head. It's way less likely to fail; and more fun, to boot.
As a software engineer, surely you know that malloc() is nondeterministic.
As other people have said, object-boundary detection is much more complex than color manipulation. There's more to it, though. Surface simplification has always been based around a basic model:
For high-poly-count models, this works great. You can take a 3D scanner, massage it into a manifold surface, and then simplify it from millions of points down to 10,000. The location of a single vertex has such a miniscule effect, because the relative vertex density is still so high. A surface-simplification algorithm can use simple error metrics like displaced volume.
The problem comes in when we talk about error metrics for low-polygon models, which have orders of magnitude less vertices. For a video game character, a nose may be defined by a handful of vertices. Leaving the simplification up to an algorithmic error metric will undoubtably result in a funny-looking nose, at least in some cases. That's where the artist comes in; tweaking a few things here or there until the model subjectively looks right (instead of being mathematically right). Even if appropriate error metrics could be defined, they would still tend to be viewpoint-sensitive (if the model is facing away from you, shoulders need many vertices to look round; if it's sideways, shoulder geometry can be simplified using bump maps).
Recent work has been done on mesh salience, which does a pretty good job by itself, but it still produces a model with too many polygons for some applications. Even as GPUs get faster, studios still choose to go with low-polygon models when possible, because it means overall scene complexity can increase.
Whenever the first computer algorithm was devised to parse HTML. Just because your computer's font system can't differentiate between italics and emphasized text doesn't mean a machine reader can't.
Of course, this is largely academic, since most markup is ignored by bots. However, it's only a matter of time before Google starts incorporating "good authorship" trust-levels in their heuristics (so documents that match expected "good" tag distributions are considered more trustworthy w.r.t. keyword weighting).
Probably a bad idea, but it is the ultimate in flexibility and platform independence.
Any OS's default malloc implementation is optimized for general usage. If you have specialized needs, memory management is not that rare to override. Google for Doug Lea's malloc.
Depending on the language used and the corporate infrastructure, this might not be a terrible idea. If you can log via reliable multicast on several channels, why not? If you have a logging system based on C macros that removes debug-logging in release mode, you've shaved off microseconds from every function call.
Now *this* is hard to justify. Time zone conversion absolutely sucks, because it's nothing but a long list of gotchas.
You should be happy they didn't even try threading, judging by your opinion of their general skill level. Anyways, "single-threaded" by itself isn't strictly a bad thing. The best I/O throughput can be done with single-threaded asynchronous-I/O apps, where you can completely avoid context switches from threads and mutices (mutexes?). Though I doubt this was the case in your example (^:
I think the entire Ruby on Rails movement would disagree with you, especially those with the attitude of "add servers if performance isn't sufficient". It all depends on the industry you're in: whether time-to-market is more important than performance.
Is that true, or is that just hypothetical? If it's anything like .org or any of the country codes (.tv in particular), I have exactly 0 confidence in .mobi "mobile-friendly" enforcement. How would a standards committee even enforce such a loose concept as "mobile-friendly"? Does it mean "smaller than the desktop page"? What percentage size difference is necessary? Does it mean "does not include Flash/Java/whatever-plugins"? Who decides the mobile-friendly plugins? Aside from bandwidth, most mobile-friendly design is rated emotionally based on its intuitiveness... we don't have the models necessary to quantify that, so we're still back to "what some uber-designer with CSS and Flash on the brain decides" because of the lack of measurability and enforcability..
This is a bit different from your average user-input problem. Saying "don't trust that the user agent is accurate" is like saying "don't trust that the name this person entered in the form is accurate". Sure, you may assume it's BS data, but there's nothing you can do about it. If the user wants to say their name is "John Q Public", you have to take it at face value. If the user insist that their browser is KHTML, you have to take it at face value. If they say KHTML and they're lying, too bad. It's either their fault for lying (no sympathy), or it's their provider's fault for screwing with data (sucks for the user).
This problem is orthogonal to the security issues caused by taking arbitrary inputs and passing them to arbitrary external data sinks (SQL/shell commands).
Not that it's your fault for creating it, but the .mobi TLD is an abomination of all that is good in this world. If your organization is example.com, it's much more logical to use subdomains (e.g. mobile.example.com or m.example.com) than to create a different TLD (and thus imply a different organization).
Too bad reliable SVG display doesn't work without either UA sniffing (either explicitly on the server, or using Javascript heuristics on the client), thanks to the most popular browser in the world. Nor are many people interested in downloading Adobe's SVG viewer (which is required to view SVG in IE, AFAIK). Nor is SVG even remotely useful for raster images (whodathunkit?), which is what most of the world's images are.
Assuming you're using iptables, you could simply add this rule (typed offhand, not sure if syntax is correct):
iptables -A OUTPUT -m owner -uid-owner apache -p tcp -d 72.232.101.0/24 -dport 80 -j DROP
You'd have to change this if/when wordpress.com changes hosts, but it'll block traffic from the apache user destined towards *.wordpress.com:80. That should be sufficient to avoid screwing other outbound connections.
XML and SGML are not interchangeable. <foo/> is a self-closing tag in XML. <foo/ is a self-closing tag in SGML (full SGML really has weird syntax to anyone used to HTML or XML). XML is easier to parse than SGML, specifically because it is not SGML.
Amen!
To add to that: If you can't correctly manage memory in C++, you probably can't correctly manage any other resources an average program has to deal with:
Python and C++ (and probably Perl), make these tasks easy by using deterministic object destruction (RAII FTW!). In Java, this is about the same level of complexity as malloc/new and free/delete, so you're back to square one on resource management.
Actually, it's fairly well accepted that making a computer "feel" responsive is far more important to desktop users than increasing its throughput. For example, Ubuntu's desktop and server distributions have different kernel parameters targetted respectively to improve UI latency and throughput. For specifics on the web, check out Jacob Nielsen's site (he lists further references for HCI studies). The quickest way to make an application feel unusably slow is to block the UI while processing, so it is crucial that UI interaction either be very fast, or delegate its work to another thread/process.
It's perfectly fine to trade efficiency for simplicity, but UI latency is not the place to do that trade.
There's an alternative. You could write a function once, instead of once per your 30 tables. Write it as a portable library script for your 3 applications. You're still "writing biolerplate", but I think you're overestimating the amount required:
(as a part of $db class, or a $db subclass)
function insert($table, $records) {
$columns = array();
$values = array();
foreach ($records as $column => $value) {
$columns[] = $column;
$values[] = $this->quote($value);
}
$sql = sprintf('INSERT INTO %s(%s) VALUES(%s)', $table,
join(',', $columns), join(',',$values));
$this->execute($sql);
}
$db->insert('users', array('user' => $_GET['user']));
This should work for any table (well if a column name has spaces in it, you'll need a $db->escapeLiteral() function, or a better column naming scheme!). If you ever work on more than one PHP project, it makes sense to try to carry around a common codebase between them for this.
Everything's on a continuous scale, anyways. The less RoR you use, the more boilerplate you have to write yourself (because RoR has done all of the boilerplate for you, for basic CRUD operations). But the upside is the increase in freedom, if that is important to you.
Ok... you wanted one good reason to write that boilerplate function. It doesn't require as drastic of a change as switching your entire web server platform. Most software developers are working on existing projects, rather than new projects. Or maybe you're working with an existing talent pool that will be difficult to migrate, or you have to interface with existing legacy PHP. Sure, use RoR for your next project, but for whatever projects that are in production, incremental change rules the day.
Feathers don't fossilize as well as bones do. It takes very lucky conditions for most things besides bones to show up in any fossil record.
You also have to consider recent history in sexual harassment lawsuits/rules/"training" in corporate environments. If a male coworker says "I like your skirt today", you could feasibly take him/the company to court and win a sexual harassment suit.
A male co-worker who may be afraid of that issue, or simply intimidated by a female (esp. if you are attractive), has the potential to covertly bring up the issue of your clothing by spinning it into a joke. Giving you a gentle ribbing may simply be a way of acknowledging that you dressed up nice while completely avoiding the sexual-harassment minefield, or without giving an outright complement. I'm not saying it's the right thing, but (to rephrase) "do not attribute to malice what can be attributed to shyness".
All of this goes along with what others were saying - many groups of guys get along and show welcomeness by giving each other a "playfully hard time". Your co-workers could just be treating you as one of the boys.
I'll see your finger and raise you one mount.
While we're at it, I always thought man dump was a humorous command (for the curious, dump is a filesystem backup mechanism).
If by "installing a datacenter" you mean "installing a Mac Pro into my living room", then yes. Server admins and bodybuilders alike have to start with baby steps.
PMS is real, it's not some secret male propoganda or anything. Most girls I've dated have knowingly acted less rationally during their periods. Calling it insanity should be clearly recognized as hyperbole, and (IMHO) is no worse than saying I'm starving when I'm really just mildly hungry.