...implying that it's expected for guys to stink, but unusual for girls to stink.
Have you ever been to a coed college dorm? The girls don't like walking through the guys' hall because of the stink. I had to fight awful hard to keep my own room smelling decent, if only because of the dirty clothes in the hamper in a small space. I may not expect a girl to smell nice in the "because that's the way things should be" manner, but I certainly do predict that an average girl will smell nicer than an average guy; There's no implication necessary. Most guys sweat more, and thus smell muskier (or just plain worse), than most girls.
With raytracing, there are lots of new possibilities. For one thing, reflection and refraction actually work like they do in real life.
Single-bounce reflections and refractions can be done without raytracing. Now, reflection through a glass sphere is more interesting than a single bounce (and embarassingly easy with raytracing), but if you look at NVidia SDK Samples, you'll see plenty of non-raytraced examples that do use single-pass traces (in a pixel shader, usually).
Lights can work accurately if you want them to
Area lights? Or point lights? Light maps are (in general) a good and simple solution to dynamic lighting, but they suffer from pixelation problems in some situations. Thus, care is required to prevent lights from getting into "bad situations", but the rendering is still faster using cache-friendly rasterizating. Dynamic area lights are more difficult for raytracing and rasterizing alike, so the general trick is to use static (precomputed) area lights and dynamic point lights.
...and radiosity can be precomputed for static scenes.
This can be done regardless of the rendering method. Now, realtime radiosity, that would be sweet, because it can be combined with either raytracing or rasterizing. I don't have a link handy, but Henrik Jenssen (sp?) has a GPU-based photon-mapping solution, which would add caustics. I doubt that would scale up to an appropriate quality for gaming right now, but sooner or later someone will figure out a hack that's close enough.
Most of it (except good lenses) has been faked before with rasterization, but raytracing will actually let you set up a series of mirrors and telescopes to peek around corners in a FPS for instance. I can imagine a true hall of mirrors in an FPS would be at least a little more interesting than what we have now, too.
That certainly would be cool. I betcha a hybrid solution would be the fastest, though. Raytrace just the dynamic objects in a scene through the mirrors, as a CPU-based vertex processor... but still render by rasterizing. After all, dynamics systems for collisions are already similar to raytracing... aside from having a physics subsystem, maybe some games could start implementiong a raytracing subsystem prior to rendering.
Raytracing is O(log n) versus O(n) for rasterization, which means that even though raytracing is currently slower (the constants involved in raytracing are higher), after the break even point is passed much less of the available computational power will be needed to render the scene and can instead be used for physics and AI.
The thing is, even as raytracing gets faster, rasterizing gets faster, and people are still pushing new research into rasterizing, and GPUs are continually speeding up. Rasterizing algorithms are much more cache-friendly, which is one of the biggest weaknesses of raytracing that will never go away. GPUs presently blow CPUs out of the water, performance-wise, so you're at the point of waiting for N-way processor machines to be on desktop machines. NVidia and ATI aren't going to sit around with their thumbs up their asses while they wait for CPUs to put them out of business, which means anything that can run on a GPU is still going to outpace the multicore CPU systems.
No matter how fast someone makes a raytracing solution, someone else is going to jump through whatever hoops are necessary to have a faster rasterizing solution, given the current trends in hardware. I suppose this all goes out the window if a GPU is developed that is better at raytracing than rasterizing, though.
Except if you're smaller than a bank (like most individuals are), in which case you have to pay through the nose for someone else to handle the actual currency exchange for you. Then you have to weight the cost of a single currency transaction with the potential future gain from it, and... now you're a trader. And most traders don't make money.
And the Java API + 3rd party libs knock them all into a cocked hat.
Ah, yes, the standard library the redefines data structures (ArrayList vs. Vector) but can never remove them due to backwards compatibility. But since Vector is so ubiquitous in other languages, and ArrayList is... erm... two similar words put together... most beginners use the wrong tool to begin with. Same issue with Hashtable vs HashMap. Or the decision that Properties "is-a" Hashtable instead of "has-a", which again can never ever be replaced with the proper relationship (a private member instead of inheritance) because somewhere, someone depends on that dynamic typing, for no good reason, and we don't want it to break. Yeah the Java API is awesome. At least they added autoboxing so basic data types aren't incredibly annoying to use with basic data structures.
Me, I'll take x = dict(foo=[1, 2, 3]) and the Python file metaphor (if it has fileno(), you can stream to/from it) any day over Java's megalomaniac collections API.
Java's still better off than C++ in that regard. Every C++ unit-testing framework I've seen either jumps through template-metaprogramming-hell hoops to get compile-time reflection, or uses some sort of preprocessor to do out-of-band reflection (e.g. perl/python script that roughly parses the unit tests and generates a skeleton). So while Java's reflection mechanisms may be weak (I don't know the extent of it), it's certainly not the weakest of the lot.
It helps though if you try to keep the style of the API consistent, and the number of API patterns small.
The wonderful thing is that Python's typing system allows APIs to become standardized simply through function naming, syntax, and a little bit of semantics. People complain that database modules like psycopg and pypgsql (both database access layers) aren't well-documented. But since they both more-or-less follow the DB-API 2.0 spec, they can more-or-less be interchanged without screwing things up. Plus, the developers don't have to document everything; just the parts that differ from the spec.
Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re...
I don't think I've ever heard of anyone confusing re with string. Though I've never met anyone who approached Python without first knowing what a regular expression is. I can see my girlfriend (who knows neither Python nor regular expressions) being confused about why basic substring and replacement functionality is in string, but more "sensible" substring and replacement functionality is anywhere else. But really, for anyone adept at using Linux from the command line, figuring out Python modules is usually a walk in the part, eating a piece of cake. pydoc and the plethora of good online resources should be more than enough for someone who learned ps from the man pages.
Ok... I'll give you os and sys. I have a tendency to forget some of the obscure parts; I blame naming. It's somewhat misleading to have "system" and "operating system". Maybe runtime.argv and runtime.stdin would be more obvious than sys, but I'm sure 50% of the Python-using population would vehemently oppose that (for whatever reason).
For that matter, maybe/etc would be better named/config, but backwards-compatibility rules all (including being backwards-compatible with the ideas in the developers' heads, regardless of how correct or good those ideas are). So just think of sys as secretly being runtime or whatever else tickles your pickle, and the module division should make more sense.
It's just that building a studio isn't as expensive as it used to be, so no point paying $200/h when you could get your own adequate one for couple of grand.
My positive references to local studios is probably biased towards a college town, where there's a wealth of young musicians who are already in debt to the school. Plenty of them are willing to pay $50-$75/hr for a bit of recording time (there's always someone reaching down to that market, since $50 is better than nothing), because a "couple of grand" is what it costs to have a bed to sleep in for a year. Plenty of them also want live recordings from their existing performances, which is where the "recording service" model becomes even more attractive.
Not if you're serious about reducing your noise floor while keeping your levels high. None of the post-processing in the world will fix a noisy recording without damaging the "good" parts of the signal as well.
Mind you, I'm not defending the advertised costs of recording studios from the big corporations. Signing with a major label as a small player is generally a bad idea due the numerous ways they screw you over. But local studios do have controlled sonic environments and access to a lot of gear such as microphones, amps, and processors that would cost much more to own than to rent. Generally, these studios started as people who accumulated gear and discovered they could recoup their costs by renting it (plus associated services).
If your home recording setup is good enough that you couldn't benefit from recording at a local studio... you should consider offering services yourself, since at that point you've become a studio.
but can someone tell me what the "next gen" windows manager does for me, productivity-wise?
Just one step closer to the hand-wavey-fingery interfaces you see in Minority Report (or any other number of sci-fi movies). Granted, our input device is still mostly limited to the mouse and keyboard, which is rather limiting, there are plenty of opportunities to improve a visual interface:
OS X uses drop shadows as a visual cue for which applications are on top of others (particularly important for OS X, since many of its apps have multiple windows). This makes it a bit more obvious as to which application currently has focus.
Minimizing a window and having a visual cue for "where it goes" makes it easier for at least newer users to know where to click to un-minimize it.
Making a menu pop up immediately, but then fade out upon selection, produces a desirable result. The immediate pop-up effect draws attention, and then the fade-out is easy to ignore (which theoretically matches up with our cognitive processes better). Ironically, Microsoft takes the opposite approach of fading menus in and then immediately clearing them, which can be mentally disruptive (especially when the fade stutters, as is common) if you begin to pay attention to it.
Visually organizing multiple desktops into a cube or cylindrical prism (with all the glitz of 3D rotations) provides a physical analogy that makes the multi-desktop metaphor more applicable to reality.
Providing fast methods for viewing "all applications" (OS X expose, beryl does something similar IIRC) makes application switching faster than alt-tabbing in some cases.
Previously infeasable effects can be explored. Take a look at Focus and Context Taken Literally. Hardware convolution filters can be used to blur background elements in a desktop. To my knowledge, this hasn't been applied to any real project yet, but I don't see why it can't (think about a visual "search" interface where unrelated items are blurred). Treemaps are an example of something like this that have gained popularity. KCacheGrind uses treemaps for call graph visualization, and it's awesome. It would be even better with hardware acceleration, where it would have the opportunity for additional visual cues while still being less resource-intensive.
Overall, a thousand tiny differences in the visual interface add up to a less stressful experience. You may not pay attention to it most of the time, but tiny differences like this do add up.
Plus, there are technical benefits to offloading work onto the GPU:
Transparent windows (or alpha-culled windows) are essentially free
window contents can be rendered into a texture buffer, so resizes and moves are all hardware-accelerated, and OS X-like expose effects can be very fast
Not sure if this actually has a noticable impact, but a little bit of math can be offloaded onto the GPU by replacing window-coordinate transformations with hardware matrix operations
i run confluence at home on a p3 733 machine with 512 megs of ram, which also does several other java web apps, postgres, mysql, sendmail, dovecot, spamassassin, ldap, smb/nfs, and of course apache with a few php apps for good measure. confluence returns responses every bit as fast as squirrelmail and orders of magnitude faster than that pig slop sugar CRM.
That's cool, but you didn't answer the one productive question I have about Java, so let me be more specific. I've installed stock Tomcat on Windows, Debian, an Ubuntu, and every time, the "Hello World" application is dog-slow compared to PHP apps that I've written myself (I don't doubt you that sugarCRM is crap... most popular PHP projects are). I don't care about caching solutions, because any dynamic content can be cached. I care about latency going through a single request on an unloaded server. What is so wrong with the default setup that I experience lag going to http://127.0.0.1:8080/?
Since multithreading is a real requirement for performance and scalability these days, (threads scale for performance better than processes, and you can always have more processes too)
No! General multithreading is not the solution for extreme performance, especially on web applications. Multithreaded applications have too many locks and context-switching. You want something like a libevent driver or Python Twisted that does single-threaded event dispatching with asynchronous I/O, so you can avoid locking and context switches.
What's more, thread concurrency is really a red herring here. You only want enough threads to keep a single CPU busy without thrashing... server farms get more concurrency simply by adding CPUs, and that is far more effective than throwing 10,000 threads onto a single server (take Google, for example). If you're writing multithreaded PHP scripts that are accessed from the web, I am sorry for whoever has to come maintain it. Much cleaner to multithread by using object, iframe, or other client-side methods of invoking multiple server-side scripts concurrently.
PHP + Memcache for object caching + APC for script-parse caching + some sort of distributed-session mechanism (dunno what's out there, never had to do it). Assuming you're talking about cluster-wise scaling. But there's about 10 definitions of "scalability" so I'm not sure what you mean here.
speed,
I don't have a lot of Java experience, but In My Experience Java servlets run at hampster-wheel speed on anything but the biggest iron machines you can get. I can make PHP scripts that use spartan database access functions that scream even on small machines. It may take longer to get something working, but it'll be faster and use less resources. If you have any tips on reducing latency for Java Servlets, let me know, because that's always been my #1 turnoff for Java.
and available pool of talented developers...
You definitely have a point there. Talented PHP developers cost more money, because they're so rare!
why on earth would anyone go php? ( case in point.. how many bank web systems are php based? )
Banks aren't exactly known for technological innovation. They tend to cluster together on some "best practices" solution regardless of whether or not it's the best choice. Banks use Java because lots of other people have used Java, and it's hard to make an argument against it (from their perspective). PLus, they'd have to pay more for a PHP solution simply on the basis that competent PHP developers are much rarer than competent Java developers.
class DoStuff(object):
def DoStuff(self):
self.somenumber = 0 # or whatever default you want
Then you do this: > o = DoStuff() > o.somenumber = 15 > print o.somenumber
Then if you want to add instrumentation to it later (validation for setter, tracking for getter), you just turn it into a property and hide the bald data:
class DoStuff(object):
def DoStuff(self):
self.__somenumber = 0
A simple IF statement running for every single $_GET[] variable or $_POST[] variables.
If a regex on SELECT, ALTER, DROP, INSERT, etc is true, then the script dies.
Many PHP tutorials focus on the wrong side of database security. You don't want to blacklist certain content; you really want to make any content safe for the database. PDO (or other drivers that support prepared statements) gets around this by having the driver handle content escaping. No blanket loop will work for all inputs; you need to trace every input variable and individually handle it.
You might want to re-approach your experiment with the methodology of treating every input as a dedicated datatype, where you deserialize-or-die. Something like this:
// define these functions yourself... one function for every datatype
$id = toId($_GET['id']);
$ip = toIPv4($_GET['ip']);
$macaddr = toMacAddr($_GET['mac']); // or make a function to wrap all of this
$safe = cleanInputs($_GET, array('id' => 'toId', 'ip' => 'toIPv4', 'mac' => 'toMacAddr'));
extract($safe);// $id, $ip4, $macaddr are now defined
If you're working in PHP 5, you can use objects with constructors that perform the deserialization, and throw exceptions on failure. With PHP 4, you can at least continue using native PHP variables with normalized contents, making the functions call trigger_error() or just die on failure.
Then, when you need to send your data to the database, then you perform whatever database escaping is necessary (again... use prepared statements if possible). While you're at it, you can do the same thing with all of the variables that you print to the screen, so a variable of '& and NULL IS NULL <script will work like a charm in SQL and HTML.
MDB2 is probably preferable to PDO in at least some situations
I don't think I would ever recommend MDB2 over PDO, specifically, because it's PECL instead of PEAR. Granted I've only used PEAR::DB and not PEAR::MDB2, I can state with certainty that the PHP-land driver ended up being my old company's main performance bottleneck (even the time executing SQL queries was less). PDO doesn't suffer from the same bloat issues because it spends more time in C-land instead of PHP-land. If lightweight isn't a priority, I'd go with something like ADOdb that actually does database abstraction, instead of database access abstraction.
If your host doesn't provide you with PDO (or PHP 5), get a new host.
I've seen too much "light code" that is under-tested and riddled with security holes because all of that checking makes the code inelegant.
Checking inputs for security's sake shouldn't ever be inelegant. It's a very normal part of taking HTTP-land inputs (GET/POST/cookies/session/URL/...) and transforming it into domain-land input, and anyone who'se doing it inelegantly is probably doing so mostly out of inexperience.
I know it's not what you mean, but the idea of Visual Basic running in some sort of homebrew VB Interpreter Servlet running inside the Servlet Container makes me weep.
the second one is actually LONGER and more characters and why do you even need that top line...umm are we not using a font tag in our body?
Whoa, calm down! This was a pretty limited example... If you follow the spirit of the article, you would probably be able to skip that first line, if Helvetica was the site-wide font.
this topic makes sence for PHP, java, javascript, ASP, etc... but HTML is not a programming language it has no logic... no loops.. it's just data storage really...
So you think repetition is somehow more acceptable for structural markup? Just because it's not executing doesn't mean that poorly-factored CSS isn't a PITA to maintain.
the one thing I will admit (as a web designer who still makes everything in notepad) is the way web design software makes HTML does drive me nuts... but thats just 'cause I started making websites when the size of your file mattered back in the days of 28.8 k/33.6 k
The size of files still matters... the effect is less pronounced than it used to be, but it's still definitely an issue. Some web authors even deliberately break standards-compliance to reduce size, since many attribute quotes and close-tags can be omitted without confusing web browsers. But if you use Notepad to keep your HTML sizes down, you're a braver man than I... I like an editor with syntax highlighting (Notepad2, or EditPlus, or GVim, or anything but god-awful Notepad!).
The one thing in web design that pisses me off more than anything else is when a webform is loaded, and the first, topmost, and obvious field doesn't automatically get the focus to type in. So, the hand goes back off the keyboard to the mouse to click in the box, and then typing begins or resumes.
Sorry. I'm partially responsible for that, being a web developer. Here's the issues from the other side of the fence:
Focusing on an input rather than the page itself breaks the up/down/pageup/pagedown/space/maybe-scrollwheel functionality of any page that has a scrollbar. As a user, I get frustrated when a large page is displayed with focus defaulting on the first input, since it prevents me from scrolling the page without clicking out of the form. Thus, for some pages, the focus issue is "damned if you do, damned if you don't". Though, for trivial pages like login forms (e.g. Gmail), this is definitely the way to go.
Timing issues come into play, since autofocusing an input element requires Javascript. No matter when you specify to perform the focus (on window load, or inline in the page), it's possible that the user has already clicked on some part of the page to give it focus. You may end up inadvertently stealing the focus from a user, which again is frustrating. I always wished there was an HTML focus attribute for labels, so the browser would deal with this issue.
It takes a little bit of time to set up the infrastructure required to reliably do this on all of the forms of a web application. If you work for someone who understands the benefits, this probably isn't a problem, but not everyone works for such enlightened managers/clients.
If the (X)HTML spec provided for something like <body focus="idOfSomeElement">, this would be easy... but it's just one of those things that got overlooked. There's probably some tricks around that by using tabindex, but I try not to mess with that too much, as I hear it can do some nasty things to non-visual browsers.
Traditional projects using so called "best practices" fail with atonishing regularity.
My Software Architecture professor (Ralph Johnson) said something to the effect of, "Best Practices should really be call Good Enough Practices", because they're really just a collection of ideas that are known to not be outright failures.
But just because it's not an outright failure doesn't mean that a "best practice" can't still be the wrong thing to do in a particular situation.
Once Flash enters the picture, it either becomes necessary to have Flash to access the content, or it becomes obvious that Flash was unnecessary in the first place.
On the contrary, there are many cases where Flash + graceful degradation is a nice thing to have; they may not be obvious to you, though, because you probably don't notice them (since they aren't annoying). One example is Fahrner Image Replacement, which uses Flash + Javascript for fancier text headers, but falls back to vanilla HTML headers when it fails (so yes, it works in Lynx).
The main problem this solves is the absolute suckitude of font management/use on the web. Want to use a font that isn't in the default Windows fontset? Your other alternative to FIR is to generate images for all of your headers, which is far worse.
What I'm talking about is that today's *batch* of DBMSes are terrible at storing data that is not an integer or varchar.
Modern programming languages are generally based on a combination of primitive data types (integers, floating-point numbers, and arrays for C/C++) and aggregates (objects)... heck, even a floating-point number is "just integers"... an exponent and a mantissa. In the same way, relational databases use basic data types, and then aggregate those types (as rows) to form more complex objects. While I may be completely wrong, it sounds like you've either A) not been reading up on the capabilities of your RDBMS, or B) using MySQL/Excel/Access as your RDBMS.
There are other database engines that give you the power to do things with aggregates, like enforcing arbitrary contraints or providing arbitrary functions (gosh... almost like treating a record as an object). Or, you just get more powerful primitives... Off the top of my head, Postgres allows MAC addresses, IP addresses, timestamps (but who doesn't?), time intervals, and uniformly nested/typed arrays. It also allows defining new datatypes based on old ones with CHECK constraints, so e.g. if I can create a function that validates a URL (or email address, or domain name, or mailing address, or conjugatable verb,...), I can create a URL datatype and provide a complete set of functions with it.
In addition, today's DBMSes have no protection against bad data that isn't explicitly engineered into the data model.
How is that different from any other programming task? If I write a PHP script or a Java servlet, I have to put in my own protections against all sorts of bad user input. No language knows my data model. If I say "write an integer here ____" and the user writes nothing, is that a NULL? or zero? It depends on the domain, and it can't always be automated. I'd say that SQL-based constraints are actually some of the better ways of providing protection against bad data. Define a few datatypes with appropriate validation functions, and then just leave it at that. Want to know if "FOO BA ZUFYE" is a valid MyMagicType? Send it to the database... if it complains, there's something wrong. But no system is going to do the work of a data modeler.
here are solutions for nearly all of these in your average DBMS product, but they all require that the Database Administrator play dictator to enforce... A better solution would be to take the same tack that computer languages and compilers have been taking: Make a mistake impossible as early in the process as possible.
So.... you don't want a DBA to play dictator by creating database constraints... but you want the database to enforce constraints? Constraints don't just appear out of thin air—someone has to create them. That's why DBAs exist in the first place: to take a logical set of constraints from the domain at hand, and then translate that into an executable form via our handy-dandy fully-featured RDBMS.
For example, if you have a personnel table the fact is that there tend to be a lot of simple facts about a person, like date of birth, height, etc. The Right Way to handle these is as attributes because each person has one and only one associated with him/her.
Ironically, personnel attribute management is one of the flagship examples of LDAP databases. LDAP is basically a hierarchical storage mechanism... a tree with predefined structure. Come to think of it, SNMP is also hierarchical, and it's also used to store and transmit large amounts of statistical data (mostly network monitoring attributes). Also, DNS... they even managed to combine load distribution based on the hierarchy. Basically, The Right Way is not to use a relational database at all for something like this, unless you're actually actively performing column aggregates (average height of all people, most common eye color).
The trouble is that I've never seen a particularly good solution for a dataset that is partially relational and partially hierarchical. The best solution to be likely adopted (from a worse is better point of view) is probably some sort of hierarchy embedded in a relational DB, with special syntax or functions for accessing via a.b.c.d notation
Slashdot Mirror
Have you ever been to a coed college dorm? The girls don't like walking through the guys' hall because of the stink. I had to fight awful hard to keep my own room smelling decent, if only because of the dirty clothes in the hamper in a small space. I may not expect a girl to smell nice in the "because that's the way things should be" manner, but I certainly do predict that an average girl will smell nicer than an average guy; There's no implication necessary. Most guys sweat more, and thus smell muskier (or just plain worse), than most girls.
Single-bounce reflections and refractions can be done without raytracing. Now, reflection through a glass sphere is more interesting than a single bounce (and embarassingly easy with raytracing), but if you look at NVidia SDK Samples, you'll see plenty of non-raytraced examples that do use single-pass traces (in a pixel shader, usually).
Area lights? Or point lights? Light maps are (in general) a good and simple solution to dynamic lighting, but they suffer from pixelation problems in some situations. Thus, care is required to prevent lights from getting into "bad situations", but the rendering is still faster using cache-friendly rasterizating. Dynamic area lights are more difficult for raytracing and rasterizing alike, so the general trick is to use static (precomputed) area lights and dynamic point lights.
This can be done regardless of the rendering method. Now, realtime radiosity, that would be sweet, because it can be combined with either raytracing or rasterizing. I don't have a link handy, but Henrik Jenssen (sp?) has a GPU-based photon-mapping solution, which would add caustics. I doubt that would scale up to an appropriate quality for gaming right now, but sooner or later someone will figure out a hack that's close enough.
That certainly would be cool. I betcha a hybrid solution would be the fastest, though. Raytrace just the dynamic objects in a scene through the mirrors, as a CPU-based vertex processor... but still render by rasterizing. After all, dynamics systems for collisions are already similar to raytracing... aside from having a physics subsystem, maybe some games could start implementiong a raytracing subsystem prior to rendering.
The thing is, even as raytracing gets faster, rasterizing gets faster, and people are still pushing new research into rasterizing, and GPUs are continually speeding up. Rasterizing algorithms are much more cache-friendly, which is one of the biggest weaknesses of raytracing that will never go away. GPUs presently blow CPUs out of the water, performance-wise, so you're at the point of waiting for N-way processor machines to be on desktop machines. NVidia and ATI aren't going to sit around with their thumbs up their asses while they wait for CPUs to put them out of business, which means anything that can run on a GPU is still going to outpace the multicore CPU systems.
No matter how fast someone makes a raytracing solution, someone else is going to jump through whatever hoops are necessary to have a faster rasterizing solution, given the current trends in hardware. I suppose this all goes out the window if a GPU is developed that is better at raytracing than rasterizing, though.
I always thought the Zelda and Metroid game series were enjoyable, and I'd definitely consider them adventure games.
Except if you're smaller than a bank (like most individuals are), in which case you have to pay through the nose for someone else to handle the actual currency exchange for you. Then you have to weight the cost of a single currency transaction with the potential future gain from it, and... now you're a trader. And most traders don't make money.
Ah, yes, the standard library the redefines data structures (ArrayList vs. Vector) but can never remove them due to backwards compatibility. But since Vector is so ubiquitous in other languages, and ArrayList is... erm... two similar words put together... most beginners use the wrong tool to begin with. Same issue with Hashtable vs HashMap. Or the decision that Properties "is-a" Hashtable instead of "has-a", which again can never ever be replaced with the proper relationship (a private member instead of inheritance) because somewhere, someone depends on that dynamic typing, for no good reason, and we don't want it to break. Yeah the Java API is awesome. At least they added autoboxing so basic data types aren't incredibly annoying to use with basic data structures.
Me, I'll take x = dict(foo=[1, 2, 3]) and the Python file metaphor (if it has fileno(), you can stream to/from it) any day over Java's megalomaniac collections API.
Java's still better off than C++ in that regard. Every C++ unit-testing framework I've seen either jumps through template-metaprogramming-hell hoops to get compile-time reflection, or uses some sort of preprocessor to do out-of-band reflection (e.g. perl/python script that roughly parses the unit tests and generates a skeleton). So while Java's reflection mechanisms may be weak (I don't know the extent of it), it's certainly not the weakest of the lot.
The wonderful thing is that Python's typing system allows APIs to become standardized simply through function naming, syntax, and a little bit of semantics. People complain that database modules like psycopg and pypgsql (both database access layers) aren't well-documented. But since they both more-or-less follow the DB-API 2.0 spec, they can more-or-less be interchanged without screwing things up. Plus, the developers don't have to document everything; just the parts that differ from the spec.
If only GUI toolkits were the same way.
I don't think I've ever heard of anyone confusing re with string. Though I've never met anyone who approached Python without first knowing what a regular expression is. I can see my girlfriend (who knows neither Python nor regular expressions) being confused about why basic substring and replacement functionality is in string, but more "sensible" substring and replacement functionality is anywhere else. But really, for anyone adept at using Linux from the command line, figuring out Python modules is usually a walk in the part, eating a piece of cake. pydoc and the plethora of good online resources should be more than enough for someone who learned ps from the man pages.
Ok... I'll give you os and sys. I have a tendency to forget some of the obscure parts; I blame naming. It's somewhat misleading to have "system" and "operating system". Maybe runtime.argv and runtime.stdin would be more obvious than sys, but I'm sure 50% of the Python-using population would vehemently oppose that (for whatever reason).
For that matter, maybe /etc would be better named /config, but backwards-compatibility rules all (including being backwards-compatible with the ideas in the developers' heads, regardless of how correct or good those ideas are). So just think of sys as secretly being runtime or whatever else tickles your pickle, and the module division should make more sense.
My positive references to local studios is probably biased towards a college town, where there's a wealth of young musicians who are already in debt to the school. Plenty of them are willing to pay $50-$75/hr for a bit of recording time (there's always someone reaching down to that market, since $50 is better than nothing), because a "couple of grand" is what it costs to have a bed to sleep in for a year. Plenty of them also want live recordings from their existing performances, which is where the "recording service" model becomes even more attractive.
Not if you're serious about reducing your noise floor while keeping your levels high. None of the post-processing in the world will fix a noisy recording without damaging the "good" parts of the signal as well.
Mind you, I'm not defending the advertised costs of recording studios from the big corporations. Signing with a major label as a small player is generally a bad idea due the numerous ways they screw you over. But local studios do have controlled sonic environments and access to a lot of gear such as microphones, amps, and processors that would cost much more to own than to rent. Generally, these studios started as people who accumulated gear and discovered they could recoup their costs by renting it (plus associated services).
If your home recording setup is good enough that you couldn't benefit from recording at a local studio... you should consider offering services yourself, since at that point you've become a studio.
Just one step closer to the hand-wavey-fingery interfaces you see in Minority Report (or any other number of sci-fi movies). Granted, our input device is still mostly limited to the mouse and keyboard, which is rather limiting, there are plenty of opportunities to improve a visual interface:
Overall, a thousand tiny differences in the visual interface add up to a less stressful experience. You may not pay attention to it most of the time, but tiny differences like this do add up.
Plus, there are technical benefits to offloading work onto the GPU:
That's cool, but you didn't answer the one productive question I have about Java, so let me be more specific. I've installed stock Tomcat on Windows, Debian, an Ubuntu, and every time, the "Hello World" application is dog-slow compared to PHP apps that I've written myself (I don't doubt you that sugarCRM is crap... most popular PHP projects are). I don't care about caching solutions, because any dynamic content can be cached. I care about latency going through a single request on an unloaded server. What is so wrong with the default setup that I experience lag going to http://127.0.0.1:8080/?
No! General multithreading is not the solution for extreme performance, especially on web applications. Multithreaded applications have too many locks and context-switching. You want something like a libevent driver or Python Twisted that does single-threaded event dispatching with asynchronous I/O, so you can avoid locking and context switches.
What's more, thread concurrency is really a red herring here. You only want enough threads to keep a single CPU busy without thrashing... server farms get more concurrency simply by adding CPUs, and that is far more effective than throwing 10,000 threads onto a single server (take Google, for example). If you're writing multithreaded PHP scripts that are accessed from the web, I am sorry for whoever has to come maintain it. Much cleaner to multithread by using object, iframe, or other client-side methods of invoking multiple server-side scripts concurrently.
PHP + Memcache for object caching + APC for script-parse caching + some sort of distributed-session mechanism (dunno what's out there, never had to do it). Assuming you're talking about cluster-wise scaling. But there's about 10 definitions of "scalability" so I'm not sure what you mean here.
I don't have a lot of Java experience, but In My Experience Java servlets run at hampster-wheel speed on anything but the biggest iron machines you can get. I can make PHP scripts that use spartan database access functions that scream even on small machines. It may take longer to get something working, but it'll be faster and use less resources. If you have any tips on reducing latency for Java Servlets, let me know, because that's always been my #1 turnoff for Java.
You definitely have a point there. Talented PHP developers cost more money, because they're so rare!
Banks aren't exactly known for technological innovation. They tend to cluster together on some "best practices" solution regardless of whether or not it's the best choice. Banks use Java because lots of other people have used Java, and it's hard to make an argument against it (from their perspective). PLus, they'd have to pay more for a PHP solution simply on the basis that competent PHP developers are much rarer than competent Java developers.
I may as well add the Python equivalent:
class DoStuff(object):
def DoStuff(self):
self.somenumber = 0 # or whatever default you want
Then you do this:
> o = DoStuff()
> o.somenumber = 15
> print o.somenumber
Then if you want to add instrumentation to it later (validation for setter, tracking for getter), you just turn it into a property and hide the bald data:
class DoStuff(object):
def DoStuff(self):
self.__somenumber = 0
def __somenumber_getter(self):
print "get"
return self.__somenumber
def __somenumber_setter(self, somenumber):
print "set"
self.__somenumber = somenumber
somenumber = Property(__somenumber_getter, __somenumber_setter)
# or we could omit the setter to make it read-only
Client code doesn't need to change (looks to be the same with Ruby).
Many PHP tutorials focus on the wrong side of database security. You don't want to blacklist certain content; you really want to make any content safe for the database. PDO (or other drivers that support prepared statements) gets around this by having the driver handle content escaping. No blanket loop will work for all inputs; you need to trace every input variable and individually handle it.
You might want to re-approach your experiment with the methodology of treating every input as a dedicated datatype, where you deserialize-or-die. Something like this:
$id = toId($_GET['id']);
$ip = toIPv4($_GET['ip']);
$macaddr = toMacAddr($_GET['mac']);
$safe = cleanInputs($_GET, array('id' => 'toId', 'ip' => 'toIPv4', 'mac' => 'toMacAddr'));
extract($safe);
If you're working in PHP 5, you can use objects with constructors that perform the deserialization, and throw exceptions on failure. With PHP 4, you can at least continue using native PHP variables with normalized contents, making the functions call trigger_error() or just die on failure.
Then, when you need to send your data to the database, then you perform whatever database escaping is necessary (again... use prepared statements if possible). While you're at it, you can do the same thing with all of the variables that you print to the screen, so a variable of '& and NULL IS NULL <script will work like a charm in SQL and HTML.
I don't think I would ever recommend MDB2 over PDO, specifically, because it's PECL instead of PEAR. Granted I've only used PEAR::DB and not PEAR::MDB2, I can state with certainty that the PHP-land driver ended up being my old company's main performance bottleneck (even the time executing SQL queries was less). PDO doesn't suffer from the same bloat issues because it spends more time in C-land instead of PHP-land. If lightweight isn't a priority, I'd go with something like ADOdb that actually does database abstraction, instead of database access abstraction.
If your host doesn't provide you with PDO (or PHP 5), get a new host.
Checking inputs for security's sake shouldn't ever be inelegant. It's a very normal part of taking HTTP-land inputs (GET/POST/cookies/session/URL/...) and transforming it into domain-land input, and anyone who'se doing it inelegantly is probably doing so mostly out of inexperience.
I know it's not what you mean, but the idea of Visual Basic running in some sort of homebrew VB Interpreter Servlet running inside the Servlet Container makes me weep.
Whoa, calm down! This was a pretty limited example... If you follow the spirit of the article, you would probably be able to skip that first line, if Helvetica was the site-wide font.
So you think repetition is somehow more acceptable for structural markup? Just because it's not executing doesn't mean that poorly-factored CSS isn't a PITA to maintain.
The size of files still matters... the effect is less pronounced than it used to be, but it's still definitely an issue. Some web authors even deliberately break standards-compliance to reduce size, since many attribute quotes and close-tags can be omitted without confusing web browsers. But if you use Notepad to keep your HTML sizes down, you're a braver man than I... I like an editor with syntax highlighting (Notepad2, or EditPlus, or GVim, or anything but god-awful Notepad!).
Sorry. I'm partially responsible for that, being a web developer. Here's the issues from the other side of the fence:
If the (X)HTML spec provided for something like <body focus="idOfSomeElement">, this would be easy... but it's just one of those things that got overlooked. There's probably some tricks around that by using tabindex, but I try not to mess with that too much, as I hear it can do some nasty things to non-visual browsers.
My Software Architecture professor (Ralph Johnson) said something to the effect of, "Best Practices should really be call Good Enough Practices", because they're really just a collection of ideas that are known to not be outright failures.
But just because it's not an outright failure doesn't mean that a "best practice" can't still be the wrong thing to do in a particular situation.
On the contrary, there are many cases where Flash + graceful degradation is a nice thing to have; they may not be obvious to you, though, because you probably don't notice them (since they aren't annoying). One example is Fahrner Image Replacement, which uses Flash + Javascript for fancier text headers, but falls back to vanilla HTML headers when it fails (so yes, it works in Lynx).
The main problem this solves is the absolute suckitude of font management/use on the web. Want to use a font that isn't in the default Windows fontset? Your other alternative to FIR is to generate images for all of your headers, which is far worse.
Modern programming languages are generally based on a combination of primitive data types (integers, floating-point numbers, and arrays for C/C++) and aggregates (objects)... heck, even a floating-point number is "just integers"... an exponent and a mantissa. In the same way, relational databases use basic data types, and then aggregate those types (as rows) to form more complex objects. While I may be completely wrong, it sounds like you've either A) not been reading up on the capabilities of your RDBMS, or B) using MySQL/Excel/Access as your RDBMS.
There are other database engines that give you the power to do things with aggregates, like enforcing arbitrary contraints or providing arbitrary functions (gosh... almost like treating a record as an object). Or, you just get more powerful primitives... Off the top of my head, Postgres allows MAC addresses, IP addresses, timestamps (but who doesn't?), time intervals, and uniformly nested/typed arrays. It also allows defining new datatypes based on old ones with CHECK constraints, so e.g. if I can create a function that validates a URL (or email address, or domain name, or mailing address, or conjugatable verb, ...), I can create a URL datatype and provide a complete set of functions with it.
How is that different from any other programming task? If I write a PHP script or a Java servlet, I have to put in my own protections against all sorts of bad user input. No language knows my data model. If I say "write an integer here ____" and the user writes nothing, is that a NULL? or zero? It depends on the domain, and it can't always be automated. I'd say that SQL-based constraints are actually some of the better ways of providing protection against bad data. Define a few datatypes with appropriate validation functions, and then just leave it at that. Want to know if "FOO BA ZUFYE" is a valid MyMagicType? Send it to the database... if it complains, there's something wrong. But no system is going to do the work of a data modeler.
So.... you don't want a DBA to play dictator by creating database constraints... but you want the database to enforce constraints? Constraints don't just appear out of thin air—someone has to create them. That's why DBAs exist in the first place: to take a logical set of constraints from the domain at hand, and then translate that into an executable form via our handy-dandy fully-featured RDBMS.
Ironically, personnel attribute management is one of the flagship examples of LDAP databases. LDAP is basically a hierarchical storage mechanism... a tree with predefined structure. Come to think of it, SNMP is also hierarchical, and it's also used to store and transmit large amounts of statistical data (mostly network monitoring attributes). Also, DNS... they even managed to combine load distribution based on the hierarchy. Basically, The Right Way is not to use a relational database at all for something like this, unless you're actually actively performing column aggregates (average height of all people, most common eye color).
The trouble is that I've never seen a particularly good solution for a dataset that is partially relational and partially hierarchical. The best solution to be likely adopted (from a worse is better point of view) is probably some sort of hierarchy embedded in a relational DB, with special syntax or functions for accessing via a.b.c.d notation