Just what is so bad about phpPgAdmin? The fact that it allows you to do just about anything in PostgreSQL? Oh, I suppose it doesn't display as many nice colors as phpMyAdmin, but other than that, what is wrong with it's feature set:
* Administer multiple servers * Support for PostgreSQL 7.0.x, 7.1.x, 7.2.x, 7.3.x, 7.4.x and 8.0.x * Manage all aspects of:
o Users & groups
o Databases
o Schemas
o Tables, indexes, constraints, triggers, rules & privileges
o Views, sequences & functions
o Advanced objects
o Reports * Easy data manipulation:
o Browse tables, views & reports
o Execute arbitrary SQL
o Select, insert, update and delete * Dump table data in a variety of formats: SQL, COPY, XML, XHTML, CSV, Tabbed, pg_dump * Import SQL scripts, COPY data, XML, CSV and Tabbed * Excellent language support:
o Available in 26 languages
o No encoding conflicts. Edit Russian data using a Japanese interface! * Easy to install and configure
Fact is, phpPgAdmin has to do a *lot* more than phpMyAdmin, since PostgreSQL supports so many more features. I think they've done an outstanding job.
Having logic in the database does not seem to be practical for high-load systems.
First of all, based on what research? There are incredibly large systems based on keeping business logic in the database. Just last week at OSCON I met several people who are running primary systems on PostgreSQL, some inserting several GB a day of new data. That seems pretty high-load to me.
What magic is there that means re-implementing constraints in Java would be somehow faster than the implementation of most serious DBMSs, which are written in C and usually have many more years of research and stability behind them? Remember the TANSTAAFL factor. Yes, you can create huge server farms in Java, but you can create server farms with databases. Replication, clustering, tablespaces, physical partitioning all allow for this sort of thing.
Cached data is another red herring:
1. Caching is not business logic. It is merely a common-sense application-level thing to do.
2. Who says you can't cache data with a DBMS? Most busy read-intensive databases automatically cache the frequently-hit data, so the reads rarely hit the disk. Writes should never be buffer-cached in a mission-critical system if you really want data integrity.
3. On the DBMS side, there are all sorts of performance tweaks you can do in addition to automated caching, such as temporary tables, cursors, prepared queries, etc...
There is little duplication or re-implementation - logic is simply placed at the appropriate point in the various layers of processing to optimise scalability and performance.
Thus the greatly increased possibility that the system will be compromised, because a change in logic here might not be dealt with over there.
Anyway, if performance is your only reason for not keeping logic centralized then wouldn't you agree that that is either a result of bad implementation on the database side (I mean in the storage implementation of the DBMS itself), or a sacrifice of integrity on the application side? Of course, all of this is a judgement call, and people make compromises all the time in these areas, but at least understand the chances you are taking.
There is absolutely no conflict between an application having an object model of the data and a relational database having good relational integrity, views etc.
Non sequitur; I never said there was. What I said was that having an application layer that reacts to changes in the database doesn't *necessarily* mean that every change to a base table need be reflected in a change in the application layer.
As for ORM, I am not a fan of it, but that is because of the coupling thing I mentioned. I prefer an orthogonal relationship between application and data model, rather than maintaining a congruity between classes and tables. Of course the tools you mention alleviate a lot of the drudgery of tracking changes, but the duplication of logic still occurs.
The problem with RoR is that it can react very poorly to database changes. Because there is no column mapping column names are scattered throughout the code - even into web pages.
That wouldn't surprise me at all. Note that I'm not defending RoR, and have no experience with it beyond just reading the presentation on the website.
However, again with the database design issue: why is it a bad idea for column names to be visible? If they are named meaningfully, and reflect the business logic, then what's the problem? Also, again I prefer a logical separation of base tables from the application via views and procedures, so that I can rename the "visible" columns at will. To me, the ultimate in application flexibility and robustness is to be able to refine or change business logic simply by changing the database design. Now it's true that there are very few (if any) application frameworks sophisticated enough to really do this, but isn't that something worth working toward?
Not all business logic needs to be, or should be, in the database. This is a very old-fashioned view. Increasingly data (or subsets of it) are being decentralised and distributed - sometimes into smaller databases, sometimes as files which are snapshots of data, sometimes as web services. The relational database has a key role, but it is not where everything is done.
My view being old-fashioned does not discredit it. Logic and mathematics themselves are old-fashioned, having very few real advances in the past millenium. Simply describing current practice is not an argument. I am having this discussion because I disagree with current practice.
Of course, I know that an application's *data* can be maintained in multiple places, but I argue that the core logic should be in one place (federated database systems are a good example). Yes, it is possible for the application layer or even multiple application layers to maintain the logic, and just use the database as a mere repository. Fine, do that, but in the end any truly sophisticated system of that nature will end up re-implementing many (or even most) of the things already being done by a proper DBMS. Where's the gain? Especially when these reimplementations are usually "ad hoc informally-specified bug-ridden" ones.
While PostgreSQL usually doesn't seem to get decent press from O'Reilly, it practially dominated the database talks at OSCON. Just about every database event either included or featured PostgreSQL.
The things in the works for 8.1 and 8.2 are looking very interesting indeed. Besides 2-phase commit and bitmap indexes:
- Full multi-master replication with Slony 2 (Slony 1 is single-master) - IN/OUT paramater declaration for more flexibility in functions (making PL/PgSQL even more like PL/SQL) - Much more useable and flexible custom datatype creation. "Complex" dataypes may not seem too useful for standard business databases, but they have all sorts of applications in areas like mapping, engineering, scientific analysis, etc... (Not to mention which, you might even want to think in terms of mapping custom datatypes to classes in your applications.) - Horizontal partitioning: this is a concept used in very large tables, where you might want different groups of rows from one table stored in different locations, such as different physical disks, SANs, etc... This sort of thing is actually already being done informally by leveraging PostgreSQL's table inheritance features and tablespaces, but in the future (8.2 or 8.3?) it should become a standard feature.
Speaking of which, how many people caught Josh Berkus and Joe Conway's talk on "Terabytes of Business Intelligence"? Very interesting insights on how to handle very large databases in PostgreSQL. For example, Joe Conway's project gathers statistics from industrial equipment around the world, receiving several GB a day of data on the central server, an 8-CPU XEON, storing the data on a SAN array via NFS mount configured for jumbo frames. To handle the super-large main table, he created a partitioning schema where there are 12 sub-tables, each holding the data for one month of the year, and then creating a main table via inheritance from these tables to present a unified relation of all this data. In some ways this may sound like a view from a UNION query, but the implementation has much better performance and maintenance implications.
All this means PostgreSQL is steadily gaining ground on the Big 3 database vendors, and in some ways surpassing them, as far as the quality of the implementation. Many of the distinctions now are in external areas, such as application servers and federated systems. (You can do either of these things in PostgreSQL, but there is no official standardized method)
We all know that the main DB vendors don't allow anyone to publish benchmarks without permission, so of course there are no easily accessible benchmarks between PostgreSQL and Oracle, for instance. But, in informal talks at OSCON, I found at least a couple companies who had done their own internal benchmarks and PostgreSQL came out ahead surprisingly often.
The idea of working dynamically from database tables is great for getting things up and running fast, but is not great for long term use, as at some future date the database may need to be modified or shared with other applications.
And some of us think this has it exactly backwards. The biggest problem for most modern applications is that they canNOT react to changes in the database design without explicitly changing code, often in multiple places. Your approach also doesn't take into account the utility of a relational approach to these things, in which changes in base tables in do not necessarily predicate a change in the application layer. We have these wonderful things called views and view updating via triggers or rules. For more sophisticated automated interaction, you can even write set-returning functions or procedures that transparently return data as if they are tables.
Not that I am saying RoR is the ultimate solution, but the idea of an application that can react to database changes is actually a pretty good one, especially when the database is designed properly. This approach actually allows for greater decoupling between the application and the database, allowing more business logic to be handled where it belongs: in the database.
Judging by the "social skills" the average high-schooler displays, I'd say you are putting out a pretty good argument for home-schooling.
Most of what passes for "socialization" these days means basically making 85% of the kids feel like losers because they don't fit in the cool/jock/gangsta/pimp-my-ride crowd.
As someone who has been both home-schooled and high-schooled, I say the socialization argument holds ONLY if the home-schooled students have no social involvement with other kids. Most home schoolers are not as isolated as you might think. They have associations, they have events where the get together, field trips, sports, etc... Also, such things as church, boy scouts, etc... (Oh, I know... how hokey) provide excellent socialization opportunities.
Also I must say, based on the the current crop of home-schooled kids I have met, they display some remarkably geeky, self-reliant, non-conformist traits of the type usually lauded by./ers.
Well, here is the USA's most dangerous intersection (which I drive through every day), so just keep refreshing the picture and you should see something soon;-).
In addition to the many DB abstraction layers written in PHP, for years there has been a built-in module for DB abstraction called DBX. Unfortunately, it is not compiled into PHP by default, so you have to either re-compile PHP or load the module upon startup. Once you do that, you get high-performance cross-DB abstraction, with essentially all the speed of the standard DB-specific modules.
It's a mystery to me why this hasn't been included in PHP by default. I even entered a request for this in the bug list, and was brushed off with the remark that "PDO is coming soon, and we would rather focus our attention on it". Oh well... I hope PDO is worth the wait.
I'm pointing out that it's silly to use __construct for the method name rather than the name of the class
AFAIK, PHP 5 lets you use either the classname or __construct as the constructor. Each approach has its pros and cons; it's nice to be free to make the choice.
Don't underestimate Javascript. In some ways, Javascript is actually a more elegant and well-thought-out language than PHP. See Crockford's rant.
Many *implementations* of Javascript are lacking, but Mozilla applications turn Javascript into a full-featured scripting language, including the ability to use sockets, read/write files, run other executables, and in general do just about everything you would need to do for a XUL "front end" application. For more serious back-end integration, just use sockets to talk to other processes, which can be written in PHP, C, Python, whatever.
XUL was not intended to be a proprietary "web browser language". It was intended as a completely open-source, and open-standard way to create GUI components (mostly it was aimed at creating client-side applications, such as the browser itself). In that sense it is not, nor was ever intended to be a proprietary replacement for DOM/HTML. In fact, Mozilla/Firefox is more DOM/HTML compliant than any other browser available.
I use XUL all the time in my work creating client-side touchscreen applications. I would never use XUL for a web application open for the general public, although I might be tempted to use it for an internal company web app (if I have control over the browsers being used).
I agree completely with you in regard to RDF and the whole idea of using Mozilla's data-management components. Mozilla/XUL should be looked at as a front-end only. Whatever method you use to get and store the data, simple javascript is the answer to manipulating it in memory. RDF, and all other XML-oriented data management techniques are incredibly overcomplicated and offer no special benefit, other than being able to say you are using "XML datasources".
For web-based apps, XMLHttpRequest is a good way to handle remote datasources, although it is even possible to work easily with sockets, if you install JSLib.
In my current Mozilla-based project, I am using JSlib sockets to talk directly to PHP (CLI mode) daemons, in order to get access to data. I have found this method to be extremely fast, and allows me the benefit of all PHP's database modules, as well as PHP's mature back-end system interaction capabilities.
Yes, if you are referring strictly to toolbar menus, then menupopup , as well as menu, menubar, etc... are the elements you need. These also have a nice list of Javascript methods that can be called, including 'insertBefore' and 'insertAfter', while many more methods such as 'appendChild' can be called on individual menuitem elements in the menu.
I personally shy away from RDF and the use of mozilla datasources, because they don't really offer that much of use to me. Their performance is not very good, and they really overcomplicate the whole idea of data management. I would much rather simply interact with a regular database and use Javascript to populate menu and list items. If I need to maintain simple lists in memory, Javascript arrays do the job quite well.
Maybe in Linux everything goes into/usr (actually not even all Linuxes), but in a 'real' Unix, or any of the *BSDs,/usr/local is the more appropriate location for general user software, while core system stuff resides in/usr. Also, there is/usr/X11R6 for X related software.
There actually are some very good reasons why Unix software is spread across several directories, although you are most definitely not limited to that approach. One reason is that most *nix software reuses many system libraries, and often these applications install libraries that will be reused by other apps. Thus we have/usr/local/lib,/usr/local/include,/usr/local/share, etc... Also, there is a strength to having a common structure to all programs, and a common place to put documentation, etc... A system of symlinks as you mention might work, but as AFAIK, use of many symlinks for frequently-used binaries and libs can slow a system down.
As I said, you are definitely not limited to the/usr or/usr/local approach. For example, if you want to compile Apache on your own, you can specify any install directory, and then all Apache binaries and shared objects will be placed inside that directory, rather than spread in the standard locations. Sometimes this has the benefit of making it easy to experiment with installs, but it also raises the possibility of multiple versions of some libraries being used on your system.
Whild it is fairly easy to remove standard Unix applications, once you understand the conpceptual layout, FreeBSD and the other *BSDs provide some *very* nice package management tools that resolve dependencies (even allowing you to commit or rollback grouped changes with portupgrade and portdowngrade), and provide easy ways to keep your system clean and up-to-date. Once I discovered this, I never went back to Linux;-).
I agree that it is unfortunate there is no nice collection of HowTos for XUL/JS. To really document and explain all of the possibilities, it would take several books.
Ummm... porn has no connection to violence? (Not to mention the implied and/or explicit misogyny evident in most porn)
"Teaching" kids through "Visual media"? Just look at how these words are being used. This is one step removed from Newspeak.
Yes, teenage (and pre-teenage) boys will usually find access to porn sooner or later, and this happened to a lesser degree even before the internet. But, there is something profoundly creepy about the thought of a father "introducing" his kids to the idea of sex through porn. This is not education, it is escapism. Porn never teaches about the reality of such things, but instead creates a completely unrealistic fantasy. I can't think of any better way to make my child unhappy for life than to teach him or her to use porn as the model for life.
Well... I'm sure this is a troll ("niche's variants"), but still:
I have tried it. OS X is a great desktop/workstation, but it is not the definitive Unix server. I had the pleasure of administrating on XServe running a very large and busy website, and I will take plain 'ol FreeBSD any day, hands down. Apple just tends to overcomplicate many aspects of the server, with non-standard system layout, elaborate extra configurations for standard services, making it hard to turn off services, and for Cthulhu's sake, why would a serious Unix sysadmin want a machine that always has a power-hungry graphical interface running? I'll take consistent, clear thinking and conservative architecture over "superior kung fu" any day.
Sorry... FreeBSD all the way for my servers. Actually, at work I also use FreeBSD 5.3 (since Beta) as my desktop, and with KDE 3.3 plus a few choice packages from/usr/ports/audio and/usr/ports/multimedia, I have a very nice workstation, thank you;-).
If it's 10^7 lines of code, and was written by people who assumed it would only be used on Linux, then you may have a long, hard road ahead.
Actually, even then your road is not usually that hard. You can even run Linux native binaries, such as RedHat RPMs. Just install the Linux compatibility ports, read the basic documentation, and you will find it's not that hard to get a Linux binary running. For example, I use this to run certain proprietary CUPS printer drivers that were written only for RedHat. (Yes, I agree that is can be complicated for larger applications, but some have even managed to get the Linux versions of DB2 and Sybase to run on FreeBSD)
FreeBSD performs quite well running Linux binaries, so you will se virtually no negative performance effects.
Unfortunately (for we libertarians, that is), this is too true. The Libertarian party has no heroes, no "story". I think libertarianism is one of the few political movements out there that actually have consistent logical arguments for their positions, but who pays attention to that sort of thing?
There are many more applications done in XUL. Just browse Mozdev and the Firefox Extensions list for a few of them. Quite a few smaller companies have started internal projects based on XUL/Mozilla (as my own company has). Also, there are some larger companies, such as ActiveState with the Komodo editor, and Axentra with the Oeone Desktop.
I predict that within the next 2 or 3 years we will see many more mid-level applications developed in this platform, and even a few large ones.
Umm... actually, there are several other good reasons besides money. If all I wanted was money, I would have become a trial lawyer a long time ago (and according to all my SAT, etc... that was the perfect sort of occupation for me). But I prefer doing something I care about and enjoy. Also, I prefer doing something that allows me to actually spend time with my wife and children.
Of course a job is a means to an end, but the end is not only money. This only reinforces my absolute amazement at the posters above who somehow think a BNW would be a good thing. I will never cede to the State the right to make my own choices and take my own risks, thank you.
Mod parent up, please... it's actually a good thoughtful commentary, not some bigotted knee-jerk reaction as often seen by both left- and right-thinkers.
Read "The Askew Wall" and other documents by Hugh Darwen at www.thethirdmanifesto.com for some really good brief descriptions of some of the many logical inconsistencies with SQL.
Really, 95% of the problems that Chris Date and Hugh Darwen have with SQL revolve around an incomplete relational treatment of data. For example, by definition, a relation cannot have duplicate tuples (rows), but a table in SQL *can*. Also, columns in a table should not have a left-to-right ordering, which they do have in SQL (they should be thought of only as attributes, not positionally). Also, SQL fails to completely implement closure, where the result of *any* relational expression becomes a relation which can be in itself modified by any other relational expression. Also, SQL fails to provide a truly extensible approach to user-defined datatypes or domains.
Etc... etc... there are many other small kvetches and some big ones with SQL. Read the Darwen docs, and you will see some interesting things.
Essentially, the problem comes down to an ad-hoc experimental language (SQL), which was only intended as a temporary solution, which was then taken over and re-designed by a committee (ANSI).
Re:Hibernate is good, but I am using Prevayler mor
on
Hibernate in Action
·
· Score: 2, Informative
Notice this quote by one of the Hibernate developers in an interview earlier this year:
"I went into this knowing very little about ORM, and even very little about databases. One of my first tasks was to go out and buy a book to learn SQL properly. All my understanding of the problem comes from what our users have taught us over the last two years."
Sigh... basing a product on secondhand experience from users who probably have never even learned what the relational model is really about.
Slashdot Mirror
Fact is, phpPgAdmin has to do a *lot* more than phpMyAdmin, since PostgreSQL supports so many more features. I think they've done an outstanding job.
Having logic in the database does not seem to be practical for high-load systems.
First of all, based on what research? There are incredibly large systems based on keeping business logic in the database. Just last week at OSCON I met several people who are running primary systems on PostgreSQL, some inserting several GB a day of new data. That seems pretty high-load to me.
What magic is there that means re-implementing constraints in Java would be somehow faster than the implementation of most serious DBMSs, which are written in C and usually have many more years of research and stability behind them? Remember the TANSTAAFL factor. Yes, you can create huge server farms in Java, but you can create server farms with databases. Replication, clustering, tablespaces, physical partitioning all allow for this sort of thing.
Cached data is another red herring:
1. Caching is not business logic. It is merely a common-sense application-level thing to do.
2. Who says you can't cache data with a DBMS? Most busy read-intensive databases automatically cache the frequently-hit data, so the reads rarely hit the disk. Writes should never be buffer-cached in a mission-critical system if you really want data integrity.
3. On the DBMS side, there are all sorts of performance tweaks you can do in addition to automated caching, such as temporary tables, cursors, prepared queries, etc...
There is little duplication or re-implementation - logic is simply placed at the appropriate point in the various layers of processing to optimise scalability and performance.
Thus the greatly increased possibility that the system will be compromised, because a change in logic here might not be dealt with over there.
Anyway, if performance is your only reason for not keeping logic centralized then wouldn't you agree that that is either a result of bad implementation on the database side (I mean in the storage implementation of the DBMS itself), or a sacrifice of integrity on the application side? Of course, all of this is a judgement call, and people make compromises all the time in these areas, but at least understand the chances you are taking.
There is absolutely no conflict between an application having an object model of the data and a relational database having good relational integrity, views etc.
Non sequitur; I never said there was. What I said was that having an application layer that reacts to changes in the database doesn't *necessarily* mean that every change to a base table need be reflected in a change in the application layer.
As for ORM, I am not a fan of it, but that is because of the coupling thing I mentioned. I prefer an orthogonal relationship between application and data model, rather than maintaining a congruity between classes and tables. Of course the tools you mention alleviate a lot of the drudgery of tracking changes, but the duplication of logic still occurs.
The problem with RoR is that it can react very poorly to database changes. Because there is no column mapping column names are scattered throughout the code - even into web pages.
That wouldn't surprise me at all. Note that I'm not defending RoR, and have no experience with it beyond just reading the presentation on the website.
However, again with the database design issue: why is it a bad idea for column names to be visible? If they are named meaningfully, and reflect the business logic, then what's the problem? Also, again I prefer a logical separation of base tables from the application via views and procedures, so that I can rename the "visible" columns at will. To me, the ultimate in application flexibility and robustness is to be able to refine or change business logic simply by changing the database design. Now it's true that there are very few (if any) application frameworks sophisticated enough to really do this, but isn't that something worth working toward?
Not all business logic needs to be, or should be, in the database. This is a very old-fashioned view. Increasingly data (or subsets of it) are being decentralised and distributed - sometimes into smaller databases, sometimes as files which are snapshots of data, sometimes as web services. The relational database has a key role, but it is not where everything is done.
My view being old-fashioned does not discredit it. Logic and mathematics themselves are old-fashioned, having very few real advances in the past millenium. Simply describing current practice is not an argument. I am having this discussion because I disagree with current practice.
Of course, I know that an application's *data* can be maintained in multiple places, but I argue that the core logic should be in one place (federated database systems are a good example). Yes, it is possible for the application layer or even multiple application layers to maintain the logic, and just use the database as a mere repository. Fine, do that, but in the end any truly sophisticated system of that nature will end up re-implementing many (or even most) of the things already being done by a proper DBMS. Where's the gain? Especially when these reimplementations are usually "ad hoc informally-specified bug-ridden" ones.
While PostgreSQL usually doesn't seem to get decent press from O'Reilly, it practially dominated the database talks at OSCON. Just about every database event either included or featured PostgreSQL.
The things in the works for 8.1 and 8.2 are looking very interesting indeed. Besides 2-phase commit and bitmap indexes:
- Full multi-master replication with Slony 2 (Slony 1 is single-master)
- IN/OUT paramater declaration for more flexibility in functions (making PL/PgSQL even more like PL/SQL)
- Much more useable and flexible custom datatype creation. "Complex" dataypes may not seem too useful for standard business databases, but they have all sorts of applications in areas like mapping, engineering, scientific analysis, etc... (Not to mention which, you might even want to think in terms of mapping custom datatypes to classes in your applications.)
- Horizontal partitioning: this is a concept used in very large tables, where you might want different groups of rows from one table stored in different locations, such as different physical disks, SANs, etc... This sort of thing is actually already being done informally by leveraging PostgreSQL's table inheritance features and tablespaces, but in the future (8.2 or 8.3?) it should become a standard feature.
Speaking of which, how many people caught Josh Berkus and Joe Conway's talk on "Terabytes of Business Intelligence"? Very interesting insights on how to handle very large databases in PostgreSQL. For example, Joe Conway's project gathers statistics from industrial equipment around the world, receiving several GB a day of data on the central server, an 8-CPU XEON, storing the data on a SAN array via NFS mount configured for jumbo frames. To handle the super-large main table, he created a partitioning schema where there are 12 sub-tables, each holding the data for one month of the year, and then creating a main table via inheritance from these tables to present a unified relation of all this data. In some ways this may sound like a view from a UNION query, but the implementation has much better performance and maintenance implications.
All this means PostgreSQL is steadily gaining ground on the Big 3 database vendors, and in some ways surpassing them, as far as the quality of the implementation. Many of the distinctions now are in external areas, such as application servers and federated systems. (You can do either of these things in PostgreSQL, but there is no official standardized method)
We all know that the main DB vendors don't allow anyone to publish benchmarks without permission, so of course there are no easily accessible benchmarks between PostgreSQL and Oracle, for instance. But, in informal talks at OSCON, I found at least a couple companies who had done their own internal benchmarks and PostgreSQL came out ahead surprisingly often.
The idea of working dynamically from database tables is great for getting things up and running fast, but is not great for long term use, as at some future date the database may need to be modified or shared with other applications.
And some of us think this has it exactly backwards. The biggest problem for most modern applications is that they canNOT react to changes in the database design without explicitly changing code, often in multiple places. Your approach also doesn't take into account the utility of a relational approach to these things, in which changes in base tables in do not necessarily predicate a change in the application layer. We have these wonderful things called views and view updating via triggers or rules. For more sophisticated automated interaction, you can even write set-returning functions or procedures that transparently return data as if they are tables.
Not that I am saying RoR is the ultimate solution, but the idea of an application that can react to database changes is actually a pretty good one, especially when the database is designed properly. This approach actually allows for greater decoupling between the application and the database, allowing more business logic to be handled where it belongs: in the database.
Judging by the "social skills" the average high-schooler displays, I'd say you are putting out a pretty good argument for home-schooling.
./ers.
Most of what passes for "socialization" these days means basically making 85% of the kids feel like losers because they don't fit in the cool/jock/gangsta/pimp-my-ride crowd.
As someone who has been both home-schooled and high-schooled, I say the socialization argument holds ONLY if the home-schooled students have no social involvement with other kids. Most home schoolers are not as isolated as you might think. They have associations, they have events where the get together, field trips, sports, etc... Also, such things as church, boy scouts, etc... (Oh, I know... how hokey) provide excellent socialization opportunities.
Also I must say, based on the the current crop of home-schooled kids I have met, they display some remarkably geeky, self-reliant, non-conformist traits of the type usually lauded by
More fun:
z = function (k) { return k; }
z(x);
z(f);
z(f());
z(f()());
Well, here is the USA's most dangerous intersection (which I drive through every day), so just keep refreshing the picture and you should see something soon ;-).
In addition to the many DB abstraction layers written in PHP, for years there has been a built-in module for DB abstraction called DBX. Unfortunately, it is not compiled into PHP by default, so you have to either re-compile PHP or load the module upon startup. Once you do that, you get high-performance cross-DB abstraction, with essentially all the speed of the standard DB-specific modules.
It's a mystery to me why this hasn't been included in PHP by default. I even entered a request for this in the bug list, and was brushed off with the remark that "PDO is coming soon, and we would rather focus our attention on it". Oh well... I hope PDO is worth the wait.
I'm pointing out that it's silly to use __construct for the method name rather than the name of the class
AFAIK, PHP 5 lets you use either the classname or __construct as the constructor. Each approach has its pros and cons; it's nice to be free to make the choice.
Don't underestimate Javascript. In some ways, Javascript is actually a more elegant and well-thought-out language than PHP. See Crockford's rant.
Many *implementations* of Javascript are lacking, but Mozilla applications turn Javascript into a full-featured scripting language, including the ability to use sockets, read/write files, run other executables, and in general do just about everything you would need to do for a XUL "front end" application. For more serious back-end integration, just use sockets to talk to other processes, which can be written in PHP, C, Python, whatever.
XUL was not intended to be a proprietary "web browser language". It was intended as a completely open-source, and open-standard way to create GUI components (mostly it was aimed at creating client-side applications, such as the browser itself). In that sense it is not, nor was ever intended to be a proprietary replacement for DOM/HTML. In fact, Mozilla/Firefox is more DOM/HTML compliant than any other browser available.
I use XUL all the time in my work creating client-side touchscreen applications. I would never use XUL for a web application open for the general public, although I might be tempted to use it for an internal company web app (if I have control over the browsers being used).
I agree completely with you in regard to RDF and the whole idea of using Mozilla's data-management components. Mozilla/XUL should be looked at as a front-end only. Whatever method you use to get and store the data, simple javascript is the answer to manipulating it in memory. RDF, and all other XML-oriented data management techniques are incredibly overcomplicated and offer no special benefit, other than being able to say you are using "XML datasources".
For web-based apps, XMLHttpRequest is a good way to handle remote datasources, although it is even possible to work easily with sockets, if you install JSLib.
In my current Mozilla-based project, I am using JSlib sockets to talk directly to PHP (CLI mode) daemons, in order to get access to data. I have found this method to be extremely fast, and allows me the benefit of all PHP's database modules, as well as PHP's mature back-end system interaction capabilities.
Why 'alas'?
Yes, if you are referring strictly to toolbar menus, then menupopup , as well as menu, menubar, etc... are the elements you need. These also have a nice list of Javascript methods that can be called, including 'insertBefore' and 'insertAfter', while many more methods such as 'appendChild' can be called on individual menuitem elements in the menu.
I personally shy away from RDF and the use of mozilla datasources, because they don't really offer that much of use to me. Their performance is not very good, and they really overcomplicate the whole idea of data management. I would much rather simply interact with a regular database and use Javascript to populate menu and list items. If I need to maintain simple lists in memory, Javascript arrays do the job quite well.
Maybe in Linux everything goes into /usr (actually not even all Linuxes), but in a 'real' Unix, or any of the *BSDs, /usr/local is the more appropriate location for general user software, while core system stuff resides in /usr. Also, there is /usr/X11R6 for X related software.
/usr/local/lib, /usr/local/include, /usr/local/share, etc... Also, there is a strength to having a common structure to all programs, and a common place to put documentation, etc... A system of symlinks as you mention might work, but as AFAIK, use of many symlinks for frequently-used binaries and libs can slow a system down.
/usr or /usr/local approach. For example, if you want to compile Apache on your own, you can specify any install directory, and then all Apache binaries and shared objects will be placed inside that directory, rather than spread in the standard locations. Sometimes this has the benefit of making it easy to experiment with installs, but it also raises the possibility of multiple versions of some libraries being used on your system.
;-).
There actually are some very good reasons why Unix software is spread across several directories, although you are most definitely not limited to that approach. One reason is that most *nix software reuses many system libraries, and often these applications install libraries that will be reused by other apps. Thus we have
As I said, you are definitely not limited to the
Whild it is fairly easy to remove standard Unix applications, once you understand the conpceptual layout, FreeBSD and the other *BSDs provide some *very* nice package management tools that resolve dependencies (even allowing you to commit or rollback grouped changes with portupgrade and portdowngrade), and provide easy ways to keep your system clean and up-to-date. Once I discovered this, I never went back to Linux
What you need is appendItem and friends, or such methods as "insertItemAt", "insertBefore" and "removeAllItems" for the menulist element, along with addEventListener.
I agree that it is unfortunate there is no nice collection of HowTos for XUL/JS. To really document and explain all of the possibilities, it would take several books.
Ummm... porn has no connection to violence? (Not to mention the implied and/or explicit misogyny evident in most porn)
"Teaching" kids through "Visual media"? Just look at how these words are being used. This is one step removed from Newspeak.
Yes, teenage (and pre-teenage) boys will usually find access to porn sooner or later, and this happened to a lesser degree even before the internet. But, there is something profoundly creepy about the thought of a father "introducing" his kids to the idea of sex through porn. This is not education, it is escapism. Porn never teaches about the reality of such things, but instead creates a completely unrealistic fantasy. I can't think of any better way to make my child unhappy for life than to teach him or her to use porn as the model for life.
Well... I'm sure this is a troll ("niche's variants"), but still:
/usr/ports/audio and /usr/ports/multimedia, I have a very nice workstation, thank you ;-).
I have tried it. OS X is a great desktop/workstation, but it is not the definitive Unix server. I had the pleasure of administrating on XServe running a very large and busy website, and I will take plain 'ol FreeBSD any day, hands down. Apple just tends to overcomplicate many aspects of the server, with non-standard system layout, elaborate extra configurations for standard services, making it hard to turn off services, and for Cthulhu's sake, why would a serious Unix sysadmin want a machine that always has a power-hungry graphical interface running? I'll take consistent, clear thinking and conservative architecture over "superior kung fu" any day.
Sorry... FreeBSD all the way for my servers. Actually, at work I also use FreeBSD 5.3 (since Beta) as my desktop, and with KDE 3.3 plus a few choice packages from
If it's 10^7 lines of code, and was written by people who assumed it would only be used on Linux, then you may have a long, hard road ahead.
Actually, even then your road is not usually that hard. You can even run Linux native binaries, such as RedHat RPMs. Just install the Linux compatibility ports, read the basic documentation, and you will find it's not that hard to get a Linux binary running. For example, I use this to run certain proprietary CUPS printer drivers that were written only for RedHat. (Yes, I agree that is can be complicated for larger applications, but some have even managed to get the Linux versions of DB2 and Sybase to run on FreeBSD)
FreeBSD performs quite well running Linux binaries, so you will se virtually no negative performance effects.
Unfortunately (for we libertarians, that is), this is too true. The Libertarian party has no heroes, no "story". I think libertarianism is one of the few political movements out there that actually have consistent logical arguments for their positions, but who pays attention to that sort of thing?
How do we fix that? Any suggestions?
There are many more applications done in XUL. Just browse Mozdev and the Firefox Extensions list for a few of them. Quite a few smaller companies have started internal projects based on XUL/Mozilla (as my own company has). Also, there are some larger companies, such as ActiveState with the Komodo editor, and Axentra with the Oeone Desktop.
I predict that within the next 2 or 3 years we will see many more mid-level applications developed in this platform, and even a few large ones.
Umm... actually, there are several other good reasons besides money. If all I wanted was money, I would have become a trial lawyer a long time ago (and according to all my SAT, etc... that was the perfect sort of occupation for me). But I prefer doing something I care about and enjoy. Also, I prefer doing something that allows me to actually spend time with my wife and children.
Of course a job is a means to an end, but the end is not only money. This only reinforces my absolute amazement at the posters above who somehow think a BNW would be a good thing. I will never cede to the State the right to make my own choices and take my own risks, thank you.
Mod parent up, please... it's actually a good thoughtful commentary, not some bigotted knee-jerk reaction as often seen by both left- and right-thinkers.
Read "The Askew Wall" and other documents by Hugh Darwen at www.thethirdmanifesto.com for some really good brief descriptions of some of the many logical inconsistencies with SQL.
Really, 95% of the problems that Chris Date and Hugh Darwen have with SQL revolve around an incomplete relational treatment of data. For example, by definition, a relation cannot have duplicate tuples (rows), but a table in SQL *can*. Also, columns in a table should not have a left-to-right ordering, which they do have in SQL (they should be thought of only as attributes, not positionally). Also, SQL fails to completely implement closure, where the result of *any* relational expression becomes a relation which can be in itself modified by any other relational expression. Also, SQL fails to provide a truly extensible approach to user-defined datatypes or domains.
Etc... etc... there are many other small kvetches and some big ones with SQL. Read the Darwen docs, and you will see some interesting things.
Essentially, the problem comes down to an ad-hoc experimental language (SQL), which was only intended as a temporary solution, which was then taken over and re-designed by a committee (ANSI).
Notice this quote by one of the Hibernate developers in an interview earlier this year:
"I went into this knowing very little about ORM, and even very little about databases. One of my first tasks was to go out and buy a book to learn SQL properly. All my understanding of the problem comes from what our users have taught us over the last two years."
Sigh... basing a product on secondhand experience from users who probably have never even learned what the relational model is really about.