create or replace trigger upper_sometable_trig before insert or updateon sometable referencing new as newRow for each row begin
newRow.column1 = upper(newRow.column1);
newRow.column2 = upper(newRow.column2);... end;
And this can be done to any database, in-house or third-party. An even better solution is to let them put mixed case data in the table and just create a function-based index on upper(indexedColumn). If they want to present the data in all caps, that is a UI concern, and queries can be done quickly with UPPER(indexedColumn) in the where clause. I can think of many legitimate cases where it might be desirable to present in mixed caps. For example, which of the following automatically-generated messages seems more personal:
Dear Jerry McGuire,
Or
Dear JERRY MCGUIRE,
In some cases it's possible to derive mixed caps from all upper caps (many languages support the notion of "proper case") but in situations such as the one above it's very difficult to go back. Of course, all of this hinges on the quality of the source data and the quality of your data entry personel.
McDonalds is a private business competing for your patronage. Perhaps we should outsource police work to competing agencies, and sign them to term contracts to police cities (or districts). That might also make the operations run more efficiently, since they are competing on price as well as performance.
But then again, if you emphasize the bottom line, then corners must be cut. The last time I was at McDonald's it took 30 minutes to get my food. Lower wages increase staffing issues (work ethic as well as number), and so response time suffers. Emergency workers are the last people I would want this to happen to.
Pay them more. Make it an employer's market, so they can be choosy about who they hire and keep on. Attract decent people with good work ethic, and fire those that abuse their position. Or, if you'd rather not deal with an increase regional sales tax, live with the current work force.
A provision like this should indemnify vendors who provide source code. The thought behind this is that if the customer has access to the source code, he can perform his own audits and the vendor has made a good-faith effort at full disclosure (as far as the vendor itself is aware). Also, many eyes looking at the same code will reduce the likelihood of fault. If the customer chooses to use the software without audits or tests, then the customer is 100% accountable. If the customer performs sloppy tests or audits, then the customer is still at least partially responsible for his decision to use the software (50/50 I'd say).
The other concept here is warranty. Perhaps software should be warranted against defects and updates for problems (not enhancements) should be free of charge. Again if the source is provided, then the customer can identify and correct problems themselves, attributing more responsibility for damages on the customer's decision to knowingly use the software. In my mind, software provided free of charge cannot be required to have a warranty, since there is no loss of value to the customer. It's purely up to the customer whether or not he uses the software, and anyone that blithely deploys free software in a mission-critical application is 100% responsible for the outcome.
In these scenarios closed-source vendors would ultimately end up being insurance companies. The cost of potential payouts would need to be built into the software price, and so customers would be paying to indemnify themselves through ignorance (lack of access to source code and inability to perform due diligence before using the software).
There are a couple of things that could be done to improve dialog boxes (which, incidentally, are also good ways of improving communication with management):
Instead of a paragraph of text, provide a short bulleted list of import key points, i.e.:
The sender of this E-mail is not in your adress book
This type of attachment is dangerous
Running this attachment may result in viral infection
Running this attachment is not recommended
Something about the organization of bulleted lists makes them infinitely more readable.
Read the text of the dialog to the user and disable the buttons until playback is complete. The hearing impaired may not hear the dialog, but while they are waiting for the buttons to become enabled they might as well read the dialog.
Default to the "safe" option. If a user simply hits enter, assume the worst and choose the an innocuous default. For example, if the buttons for opening an executable attachment were "Yes", "No", or "More Info..." then default to "No" or "More Info...". This should cut down on wanton enter-clicking.
Use dialogs judiciously. The frequency with which we are bombarded with frivolous dialogs makes it difficult to discern which are important and which are not. In my opinion informational messages should be displayed passively at that top of the application in a "message" bar or something, whereas important decisions should be presented as important dialogs. Modal dialogs should be avoided if at all possible.
All of the above would be very annoying for experienced users, and probably more than a little annoying for novices, although it would reduce the incidence of, "Uh, what did I just do?" Technique #2 should be used sparingly in cases where the action is relatively infrequent (opening an attachment) and the consequences of an uninformed action are severe (data loss).
Haven't we been over this? Apple sells a computing experience. The only way that they can guarantee a stable, secure, and performant environment is to assert control over their hardware. They can't write drivers for everything, and if they opened up a driver API for third party vendors the result would be chaos, and then everyone would complain about instability and speed issues for the next ten years until all of the major third party vendors got their drivers sorted out. This is the same reason you can't buy XBox firmware for a Sony Playstation. Like videogame consoles, Apple computers are platforms consisting of hand-picked, thoroughly-tested sets hardware, firmware, and software. That is one of the primary factors in their reliability, and it isn't going to change any time soon.
The experience is more than the software, and therefore costs more. If it is truly worth it to you, you will buy a mac. If not, enjoy the alternatives. Regardless, theft is theft and I believe Apple is perfectly within their rights, not only as it relates directly to profits but also with respect to their reputation. OS X is not going to run as well on random x86 chipsets and peripherals, and the resulting quirky behavior will be damaging to their image.
While its true that there were distributed systems that predate Windows, they differ from todays systems in the following ways:
* Prohibitively expensive to own and operate a site * Exclusive: only universities and government sites * Unclassified: no sensitive data on the network * Trusted: there was a lot more involved in getting on the network, and as such you knew who your neighbors were
UNIX systems have had their share of growing up to do as well (rlogin, rsh, SSL, rpc, ftp, telnet, and other insecure applications).
All three items are possible, but entirely dependent on the virtual machine implementation.
1) In the current Sun JVM you can allocate more memory space with the -Xms and -Xmx switches (min and max heap size, respectively)
2) I believe that the Solaris VM has 64-bit support. 64-bit support for AMD/G5 could be forthcoming, but they are still relatively new. Than, and you can't really expect Sun develop optimized JVMs for competitors.
3) As for hardware specific calls and optimizations, I'm sure that if AMD, Apple, IBM, and/or Intel wanted to invest in developing their own custom JVMs with those optimizations they would be welcome. Again, it's not really in Sun's best interest to develop VMs optimized for their competitors' hardware. Apple has their on JVM, but I'm not sure what kind of effort they have put into hardware optimization.
3) Java is not C or assembly language. If your performance requirements are critical to the point necessitating direct hardware calls then I can pretty much guarantee that Java is not the appropriate platform for you application.
There are limits on free speech. Contractual agreements are one of them. ThinkSecret may be free to express anything they like (and are), but their source is not.
Besides, this is not some human rights violation or political scandal. Apple seems to be trying to prevent damage to their business from stock price inflation and consumer disappointment, which in my opinion is a worthy goal. In any case, if someone signed an NDA and spilled the beans then they should be punished.
Furthermore, ThinkSecret is profiting from this secret information, so it's not as if they are some altruistic, pro-consumer reporter. If Apple can demonstrate that ThinkSecret profits from information that ultimately causes damage to Apple's business, then they may have a case against them as well.
Or, they begin a lawsuit and the discovery process through which they can acquire much more information than they could otherwise. If the judge decides there is a case, then Apple is free to request (and must be provided) a lot of information it would not otherwise be privvy to...including ThinkSecret's source(s). Once they have the source I am sure the lawsuit will be dropped, since ThinkSecret itself is not under NDA. However, the source(s) will likely be terminated and/or sued themselves.
Unless, of course, ThinkSecret destroys documents and/or lies under oath. One would hope that the "hero" in this story would suck it up and give Apple what they want so that they can enforce the contractual agreements they do have.
What I miss most about running Windows is SmartFTP and mIRC. While there are a plethora of graphical FTP and IRC clients for Mac OS X, they all lack something, and it has been my experience that the most usable Mac software is released as demoware, shareware, or strictly commercial software. That in and of itself isn't a bad thing (mIRC is ostensibly shareware), but the Mac stuff is usually crippled, or time-limited, or something to that effect (I don't have a problem paying for software--I'm probably one of the few that registered mIRC--but I don't have a lot of patience for nag screens, bugs, and lack of features. Also, no source or documentation).
Then there are the games...but I don't really miss those. The ones I would be inclined to play (Doom III, Neverwinter Nights, Worms 3D) have Mac ports (although my lowly G3 won't run them).
Lastly, my biggest pet peeve is that new versions of Java are almost always 6 months to a year behind the Solaris/Linux/Windows release from Sun. I would really like to start messing with 1.5/5.0, but it won't be out until Tiger is released.
That's it, really; everything else is gravy. I have Firefox 1.0, Mail.app, iTunes, MPlayer OS X (which is fantastic, btw), Netbeans, Eclipse, Tomcat, Postgres, MySQL, Open Office, SNES 9X, Bittorrent (or Azureus), Gimp, and so on and so forth. I haven't regretted my decision at all since switching 3 years ago.
(Incidentally, Quicktime will display full-screen if you pay for the pro version ($30). I use MPlayer OS X instead, because it's free, faster, and plays many more formats. There's also VideoLan Client, which is more robust but slower and more resource intensive. I have no idea what is meant by "extended desktop".)
And in order to do away with terrorism we should all convert to Islam. This is the most asinine thing I think I have read all day. Everyone in America is given a free education, access to public libraries, opportunities at need-based scholarships, loans, and grants, among other things. If someone is predisposed to resent the hard-working and successful, making them less poor is not going to stop crime. These are not acts of desparation, they are acts of resentment. It's the "I gots ta get mine" syndrome and it's not going to stop by installing a socialist government. People commit crime because it's easier than working for an honest wage, and that is not acceptable.
Punishing the hard-working and law-abiding because some shiftless layabout can't be bothered to better themselves with the plethora of private and government assistance is not the answer. Last I checked socialist England has the worst crime in the world, and they've only got that little bit of island to look after!
I agree. I especially love the concept of "properties", which address the concept of getters and setters without the need for naming conventions. I also like the foreach( ) loop syntax, and the way Collections are handled.
But with Java you'll find that things are more verbose because they are more extensible that way. There are tons of places where the object model can be optimized to suit your needs at the moment, but they are they way they are for a reason. A good example is the JavaMail API. It's a pain in the butt to add attachments to E-mail (because the MIME stuff is so complicated), but I've used the JavaMail API to parse multipart-encoded form elements to write a file upload Servlet. It wasn't the intended purpose for JavaMail, but the MIME stuff was so well-written and abstracted that I could easily apply it to another (unrelated) MIME application.
I think probably the real problem is that some people prefer procedural languages (C, badly-written C++, Perl, etc.) than object-oriented languages. If you're one of those people, you're not going to like Java or the Java APIs. Java takes OOP to the extreme.
And with Java 1.5 (Java5) you get generics, enumerations, and that new funky for loop, which should make Java slightly less verbose while making it more robust.
How large is your application? What architecture are you using? Are you using an application server? Does the application server manage persistence? Is the application distributed? Is vendor lock-in an issue with your database? Do you have a staff of knowledgeable DBAs to code and debug stored procedures? Do you have a strategy for passing exceptions to the business tier? Is performance really that much of an issue?
Some things to consider:
There is no standard (or convenient) way to pass or return complex data structures (objects, arrays, etc.) to and from a stored procedure.
Stored procedures can return cursors, but implementation differs from databas to database and driver implementation to driver implementation. In my experience it's more trouble than its worth.
Application servers nowadays have very efficient persistence management that monitors object properties for changes using dirty flags and whatnot. Tools such as Hibernate can even track multiple of changes to object in memory before actually committing the data to the database, reducing the number of transactions, which may increase performance more than a stored procedure.
Stored procedures aren't good at logic. The looping and conditional structures are very primitive in most cases. Oracle has Java stored procedures and SQL Server 2003 has.NET stored procedures, but that's all fairly new and I'm sure there's a catch somewhere.
It's always more difficult to debug a stored proc. You can't exactly compile it -f and run it through an IDE. You'll have to use printlns or SQL traces in most cases.
Transaction management can get complicated using stored procedures. Many application servers/environments have transaction management through message oriented middleware...if you build all of that logic into stored procedures then that defeats the benefit of using configurable transaction management.
Stored procedures can be good, but they are really at their most useful in 2-tier architectures (client/server) on set-in-stone platforms. There is a lot of PowerBuilder/Oracle stuff out there, especially in the Government, because Oracle ain't going nowhere.
Personally, I'd avoid them (makes everything simpler and is the most flexible option), but it's up to you. Use constraints and triggers (where you have to) to ensure integrity, but handle business logic in the business tier.
There are more applications than just spam. For example, sending out personalized memos, bills, delinquency notifications, weekly newsletter things, etc. Furthermore, it's not like this is giving spammers a tool that they don't already have; it's just giving normal folks the ability to do legit stuff without a lot of work.
Interestingly enough, if you factor in the cost of benefits, 401K contributions, and FICA taxes, a $70K-$80K per year employee becomes a $140K-$160K employee.
Contractors must provide their own benefits, and do not get 401K or FICA contributions. (Of course, the smart contractors incorporate and pay themselves something like $25K/yr and have their wives as majority stockholders receiving dividends...that circumvents FICA entirely)
It's a wash. An employee is worth what a company is willing to pay. If the company doesn't provide a good working environment (flex time, vacation, office vs. cubicle, nice chair, fast PC, telecommuting options, opportunities for advancement, etc...there's much more than pay in the equation) then they deserve to lose their employees.
It becomes a matter of pragmatism. In order to build the perfect end-user product for every company I would have to spend my entire life developing a contextual rules engine that could facilitate every conceivable scenario. Having done so, I will have this behemoth of an application that is impossible to configure without a PhD. It's a waste of my time, and it's a waste of time for my customers.
Companies that develop end-user products focus on the 80/20 rule: meet 80% of the needs of 80% of your target users. That provides a nice balance between cost of development and usefulness to the end user. The smarter companies invest a little extra time developing an API that will let them hit that extra 15-20% of functionality for a particular business through consultancy. Generally, even if an API is open, it's confusing and poorly documented, so it's almost always a cash cow.
It's far more pragmatic for the consumer to spend a little bit of money on the common, easy-to-configure 80%, and then spend a little more money developing the remaining 20% in-house. This portion can be "hard-coded", meaning little, if any, configuration is required, which is less work for everyone involved. All of his needs are met, and he didn't have to wait (or pay) for the perfect product.
Now, to address profit-motive and other such concerns in this thread. I am an advocate of open source software. That doesn't imply that I am also an advocate of free software, although I myself has contributed and I am grateful to the community for the innovation and competition they have provided. In a business setting, it may not always be practical to produce or use free software, although it is *always* in the best interest of the consumer to have the source code and the ability to modify it.
The money comes from the fact that no matter how long a free or commercial software program is developed and maintained it absolutely will not fit all of the needs of any organization. Currently I work for a company that uses three large closed-source systems for order entry, provisioning, and billing. As configurable as these systems are, I spend all of my time writing applications that apply our business logic on top of them. I am forced to reads/write from the DB, apply custom triggers, rewrite their stored procedures, and in some cases edit or replace ASPX files to attain the integration needed. Not only is this time-consuming, risky, and often inconvenient for users (trigger errors don't often bubble up to the UI in a friendly way), it also violates all kinds of support licenses, which is whole the point of buying these large closed-source systems in the first place.
Now, back in the day we used Tomcat and wrote most of our stuff in-house. We had a need to write a custom security layer for authentication/authorization against both LDAP and a windows domain controller. Nothing like that existed, so we wrote one ourselves using the Tomcat SecurityPrincipal interface and simply pluging in our extensions. Took a day, at most, to write and test, whereas we would have had to jump through hoops for weeks on an IIS system.
That's where your money comes from. Taking what's already written and what nobody wants to write again and adding business-specific logic, and integrating it with other systems. One of our vendors has changed their business model. They make virtually nothing on software sales and support, but they survive on their consultancy business. IBM is also doing this, and you can see by Microsoft's latest ISV push that they recognize this trend as well.
The question now is do I pay for closed-source software and lock myself into consultancy from that one vendor, or do I use an open source package as my base and pick and choose the talent that I bring in to improve and maintain it? If it were my business, I would choose the latter.
Not if Sun maintained the official repository, and managed commits similar to the way they are handled in Linux. Sun could still maintain their current Java Community Process to identify and prioritize enhancements, and then leverage the development efforts of the open source community rather than relying only on their internal developers.
Not everyone would have commit access, giving Sun time to verify, document, and test any improvements before including them as part of official Java project releases.
That doesn't stop forks, but lets face it, how many forks are there of Python, PHP, et al? As long as the community is satisfied that it's getting what it wants, and the source is available for ports and whatnot, I'm sure Sun can still hold onto the reins. It also allows Sun (in RedHat-esque fashion) to maintain a fully tested and supported ($$$) Enterprise version that's a few versions late, while giving developers nightly snapshots and unsupported minor releases.
It's better than what they have now, which is official support for Windows and Linux, and screw everyone else. We all download and use it for free anyway...why not put the community to work porting and improving it? It would sure make the JSRs go faster...
I think the fundamental problem with Microsoft products is that because of their ubiquity, they are are easily accepted and demanded by consumers. Now here's where it gets tough...as easy as these products are to consume (thanks to Microsoft, for all of the bundled software), they are equally hard to produce. none of the software used to produce content in these forms is not free. You can't even make a JPG image in Windows without buying something, but you can sure view it.
Which is fine...I'm all for capitalism. It sucks for me, but Microsoft has to make money somehow. But their tools are difficult to use and do not expose all of the functionality available. In this way, Microsoft always maintains an upper hand over its partners. With proprietary objects and functions they can do some wicked cool things with JScript in microsoft.com that leaves everyone scratching their heads wondering, "how did they do that?"
(There are, of course, Ruby, Flash, etc., but these plugins aren't bundled with the system, so content in this format is not *as* accessible.)
So...easy to consume, but difficult to produce. You have uncontrollable consumer demand due to the fact that every computer comes with the software, but the ability to produce said content costs money and is limited. I think that's everyone's major gripe--not that the products are actually useless, but that in order to produce content we're more or less forced to conform to the de-facto standard, and even then, only what's available to us.
(Incidentally, DivX is a poor example. A lot of technically inclined people know it and love it, but very few normal users even know it exists. And since there is a WMP plugin for it that automatically downloads from Microsoft's website in the event that they should want to view something in this format, how does the user ever know there are alternatives?)
So, as with Netscape/Mozilla(IE), Javascript (JScript), MP3/Ogg(WMA), AVI/MPG(WMP), Java(.NET), and every other well-designed, well-implemented, open, and arguably better format gets overshadowed by its Microsoft equivalent. Even freely evailable implementations. This is not market forces at work. This is a monopoly, and the only way to correct it is to force an even playing field for other products, ubiquity be damned.
ArrayList Z = new ArrayList( ); ArrayList N = new ArrayList( ); N.AddAll( Z );
You couldn't cast between them per se, but this would be much safer anyway. Look at it another way:
Integer z = new Integer( 1 ); Number n = z; n.Parse( 5.2 );
If the object referenced by n were actually of type Number, then the above should work. However, the object is of type Integer, so the parse should fail (although I must confess that I don't know what the actual outcome would be...I haven't used Java in over a year). It's really the same situation. Intuitively you would think it would work, but you can see from the example how unsafe it would be. The following *would* work in any case:
Integer z = new Integer( 1 ); Number n = new Number( z.intValue( ) ); n.Parse( 5.2 );
or:
Integer z = new Integer( 1 ); Number n = z; n = new Float( 5.2 );
What would be nice is if the fob had 256 MB of storage space, and you could grab the album right there at the kiosk, plug the FOB into your portable MP3 player, and listen to it on the way home. Like a nomad with a public/private keypair. Plug it in, your account is debited, and the music is transferred to the device. Impulse buying at its finest.
Slashdot Mirror
Easy (and far more robust) solution:
...
create or replace trigger upper_sometable_trig
before insert or updateon sometable
referencing new as newRow
for each row
begin
newRow.column1 = upper(newRow.column1);
newRow.column2 = upper(newRow.column2);
end;
And this can be done to any database, in-house or third-party. An even better solution is to let them put mixed case data in the table and just create a function-based index on upper(indexedColumn). If they want to present the data in all caps, that is a UI concern, and queries can be done quickly with UPPER(indexedColumn) in the where clause. I can think of many legitimate cases where it might be desirable to present in mixed caps. For example, which of the following automatically-generated messages seems more personal:
Dear Jerry McGuire,
Or
Dear JERRY MCGUIRE,
In some cases it's possible to derive mixed caps from all upper caps (many languages support the notion of "proper case") but in situations such as the one above it's very difficult to go back. Of course, all of this hinges on the quality of the source data and the quality of your data entry personel.
McDonalds is a private business competing for your patronage. Perhaps we should outsource police work to competing agencies, and sign them to term contracts to police cities (or districts). That might also make the operations run more efficiently, since they are competing on price as well as performance.
But then again, if you emphasize the bottom line, then corners must be cut. The last time I was at McDonald's it took 30 minutes to get my food. Lower wages increase staffing issues (work ethic as well as number), and so response time suffers. Emergency workers are the last people I would want this to happen to.
Pay them more. Make it an employer's market, so they can be choosy about who they hire and keep on. Attract decent people with good work ethic, and fire those that abuse their position. Or, if you'd rather not deal with an increase regional sales tax, live with the current work force.
A provision like this should indemnify vendors who provide source code. The thought behind this is that if the customer has access to the source code, he can perform his own audits and the vendor has made a good-faith effort at full disclosure (as far as the vendor itself is aware). Also, many eyes looking at the same code will reduce the likelihood of fault. If the customer chooses to use the software without audits or tests, then the customer is 100% accountable. If the customer performs sloppy tests or audits, then the customer is still at least partially responsible for his decision to use the software (50/50 I'd say).
The other concept here is warranty. Perhaps software should be warranted against defects and updates for problems (not enhancements) should be free of charge. Again if the source is provided, then the customer can identify and correct problems themselves, attributing more responsibility for damages on the customer's decision to knowingly use the software. In my mind, software provided free of charge cannot be required to have a warranty, since there is no loss of value to the customer. It's purely up to the customer whether or not he uses the software, and anyone that blithely deploys free software in a mission-critical application is 100% responsible for the outcome.
In these scenarios closed-source vendors would ultimately end up being insurance companies. The cost of potential payouts would need to be built into the software price, and so customers would be paying to indemnify themselves through ignorance (lack of access to source code and inability to perform due diligence before using the software).
Something about the organization of bulleted lists makes them infinitely more readable.
All of the above would be very annoying for experienced users, and probably more than a little annoying for novices, although it would reduce the incidence of, "Uh, what did I just do?" Technique #2 should be used sparingly in cases where the action is relatively infrequent (opening an attachment) and the consequences of an uninformed action are severe (data loss).
Haven't we been over this? Apple sells a computing experience. The only way that they can guarantee a stable, secure, and performant environment is to assert control over their hardware. They can't write drivers for everything, and if they opened up a driver API for third party vendors the result would be chaos, and then everyone would complain about instability and speed issues for the next ten years until all of the major third party vendors got their drivers sorted out. This is the same reason you can't buy XBox firmware for a Sony Playstation. Like videogame consoles, Apple computers are platforms consisting of hand-picked, thoroughly-tested sets hardware, firmware, and software. That is one of the primary factors in their reliability, and it isn't going to change any time soon.
The experience is more than the software, and therefore costs more. If it is truly worth it to you, you will buy a mac. If not, enjoy the alternatives. Regardless, theft is theft and I believe Apple is perfectly within their rights, not only as it relates directly to profits but also with respect to their reputation. OS X is not going to run as well on random x86 chipsets and peripherals, and the resulting quirky behavior will be damaging to their image.
While its true that there were distributed systems that predate Windows, they differ from todays systems in the following ways:
* Prohibitively expensive to own and operate a site
* Exclusive: only universities and government sites
* Unclassified: no sensitive data on the network
* Trusted: there was a lot more involved in getting on the network, and as such you knew who your neighbors were
UNIX systems have had their share of growing up to do as well (rlogin, rsh, SSL, rpc, ftp, telnet, and other insecure applications).
Patents hobble revision. If an idea is truly novel, then it will not be hindered by the patent system.
All three items are possible, but entirely dependent on the virtual machine implementation.
1) In the current Sun JVM you can allocate more memory space with the -Xms and -Xmx switches (min and max heap size, respectively)
2) I believe that the Solaris VM has 64-bit support. 64-bit support for AMD/G5 could be forthcoming, but they are still relatively new. Than, and you can't really expect Sun develop optimized JVMs for competitors.
3) As for hardware specific calls and optimizations, I'm sure that if AMD, Apple, IBM, and/or Intel wanted to invest in developing their own custom JVMs with those optimizations they would be welcome. Again, it's not really in Sun's best interest to develop VMs optimized for their competitors' hardware. Apple has their on JVM, but I'm not sure what kind of effort they have put into hardware optimization.
3) Java is not C or assembly language. If your performance requirements are critical to the point necessitating direct hardware calls then I can pretty much guarantee that Java is not the appropriate platform for you application.
- Jesse
There are limits on free speech. Contractual agreements are one of them. ThinkSecret may be free to express anything they like (and are), but their source is not.
Besides, this is not some human rights violation or political scandal. Apple seems to be trying to prevent damage to their business from stock price inflation and consumer disappointment, which in my opinion is a worthy goal. In any case, if someone signed an NDA and spilled the beans then they should be punished.
Furthermore, ThinkSecret is profiting from this secret information, so it's not as if they are some altruistic, pro-consumer reporter. If Apple can demonstrate that ThinkSecret profits from information that ultimately causes damage to Apple's business, then they may have a case against them as well.
Or, they begin a lawsuit and the discovery process through which they can acquire much more information than they could otherwise. If the judge decides there is a case, then Apple is free to request (and must be provided) a lot of information it would not otherwise be privvy to...including ThinkSecret's source(s). Once they have the source I am sure the lawsuit will be dropped, since ThinkSecret itself is not under NDA. However, the source(s) will likely be terminated and/or sued themselves.
Unless, of course, ThinkSecret destroys documents and/or lies under oath. One would hope that the "hero" in this story would suck it up and give Apple what they want so that they can enforce the contractual agreements they do have.
What I miss most about running Windows is SmartFTP and mIRC. While there are a plethora of graphical FTP and IRC clients for Mac OS X, they all lack something, and it has been my experience that the most usable Mac software is released as demoware, shareware, or strictly commercial software. That in and of itself isn't a bad thing (mIRC is ostensibly shareware), but the Mac stuff is usually crippled, or time-limited, or something to that effect (I don't have a problem paying for software--I'm probably one of the few that registered mIRC--but I don't have a lot of patience for nag screens, bugs, and lack of features. Also, no source or documentation).
Then there are the games...but I don't really miss those. The ones I would be inclined to play (Doom III, Neverwinter Nights, Worms 3D) have Mac ports (although my lowly G3 won't run them).
Lastly, my biggest pet peeve is that new versions of Java are almost always 6 months to a year behind the Solaris/Linux/Windows release from Sun. I would really like to start messing with 1.5/5.0, but it won't be out until Tiger is released.
That's it, really; everything else is gravy. I have Firefox 1.0, Mail.app, iTunes, MPlayer OS X (which is fantastic, btw), Netbeans, Eclipse, Tomcat, Postgres, MySQL, Open Office, SNES 9X, Bittorrent (or Azureus), Gimp, and so on and so forth. I haven't regretted my decision at all since switching 3 years ago.
(Incidentally, Quicktime will display full-screen if you pay for the pro version ($30). I use MPlayer OS X instead, because it's free, faster, and plays many more formats. There's also VideoLan Client, which is more robust but slower and more resource intensive. I have no idea what is meant by "extended desktop".)
- Jesse
And in order to do away with terrorism we should all convert to Islam. This is the most asinine thing I think I have read all day. Everyone in America is given a free education, access to public libraries, opportunities at need-based scholarships, loans, and grants, among other things. If someone is predisposed to resent the hard-working and successful, making them less poor is not going to stop crime. These are not acts of desparation, they are acts of resentment. It's the "I gots ta get mine" syndrome and it's not going to stop by installing a socialist government. People commit crime because it's easier than working for an honest wage, and that is not acceptable.
Punishing the hard-working and law-abiding because some shiftless layabout can't be bothered to better themselves with the plethora of private and government assistance is not the answer. Last I checked socialist England has the worst crime in the world, and they've only got that little bit of island to look after!
I agree. I especially love the concept of "properties", which address the concept of getters and setters without the need for naming conventions. I also like the foreach( ) loop syntax, and the way Collections are handled.
But with Java you'll find that things are more verbose because they are more extensible that way. There are tons of places where the object model can be optimized to suit your needs at the moment, but they are they way they are for a reason. A good example is the JavaMail API. It's a pain in the butt to add attachments to E-mail (because the MIME stuff is so complicated), but I've used the JavaMail API to parse multipart-encoded form elements to write a file upload Servlet. It wasn't the intended purpose for JavaMail, but the MIME stuff was so well-written and abstracted that I could easily apply it to another (unrelated) MIME application.
I think probably the real problem is that some people prefer procedural languages (C, badly-written C++, Perl, etc.) than object-oriented languages. If you're one of those people, you're not going to like Java or the Java APIs. Java takes OOP to the extreme.
And with Java 1.5 (Java5) you get generics, enumerations, and that new funky for loop, which should make Java slightly less verbose while making it more robust.
How large is your application? What architecture are you using? Are you using an application server? Does the application server manage persistence? Is the application distributed? Is vendor lock-in an issue with your database? Do you have a staff of knowledgeable DBAs to code and debug stored procedures? Do you have a strategy for passing exceptions to the business tier? Is performance really that much of an issue?
.NET stored procedures, but that's all fairly new and I'm sure there's a catch somewhere.
Some things to consider:
There is no standard (or convenient) way to pass or return complex data structures (objects, arrays, etc.) to and from a stored procedure.
Stored procedures can return cursors, but implementation differs from databas to database and driver implementation to driver implementation. In my experience it's more trouble than its worth.
Application servers nowadays have very efficient persistence management that monitors object properties for changes using dirty flags and whatnot. Tools such as Hibernate can even track multiple of changes to object in memory before actually committing the data to the database, reducing the number of transactions, which may increase performance more than a stored procedure.
Stored procedures aren't good at logic. The looping and conditional structures are very primitive in most cases. Oracle has Java stored procedures and SQL Server 2003 has
It's always more difficult to debug a stored proc. You can't exactly compile it -f and run it through an IDE. You'll have to use printlns or SQL traces in most cases.
Transaction management can get complicated using stored procedures. Many application servers/environments have transaction management through message oriented middleware...if you build all of that logic into stored procedures then that defeats the benefit of using configurable transaction management.
Stored procedures can be good, but they are really at their most useful in 2-tier architectures (client/server) on set-in-stone platforms. There is a lot of PowerBuilder/Oracle stuff out there, especially in the Government, because Oracle ain't going nowhere.
Personally, I'd avoid them (makes everything simpler and is the most flexible option), but it's up to you. Use constraints and triggers (where you have to) to ensure integrity, but handle business logic in the business tier.
There are more applications than just spam. For example, sending out personalized memos, bills, delinquency notifications, weekly newsletter things, etc. Furthermore, it's not like this is giving spammers a tool that they don't already have; it's just giving normal folks the ability to do legit stuff without a lot of work.
- Jesse
Please do not taunt the dynamite monkey.
Interestingly enough, if you factor in the cost of benefits, 401K contributions, and FICA taxes, a $70K-$80K per year employee becomes a $140K-$160K employee.
Contractors must provide their own benefits, and do not get 401K or FICA contributions. (Of course, the smart contractors incorporate and pay themselves something like $25K/yr and have their wives as majority stockholders receiving dividends...that circumvents FICA entirely)
It's a wash. An employee is worth what a company is willing to pay. If the company doesn't provide a good working environment (flex time, vacation, office vs. cubicle, nice chair, fast PC, telecommuting options, opportunities for advancement, etc...there's much more than pay in the equation) then they deserve to lose their employees.
It becomes a matter of pragmatism. In order to build the perfect end-user product for every company I would have to spend my entire life developing a contextual rules engine that could facilitate every conceivable scenario. Having done so, I will have this behemoth of an application that is impossible to configure without a PhD. It's a waste of my time, and it's a waste of time for my customers.
Companies that develop end-user products focus on the 80/20 rule: meet 80% of the needs of 80% of your target users. That provides a nice balance between cost of development and usefulness to the end user. The smarter companies invest a little extra time developing an API that will let them hit that extra 15-20% of functionality for a particular business through consultancy. Generally, even if an API is open, it's confusing and poorly documented, so it's almost always a cash cow.
It's far more pragmatic for the consumer to spend a little bit of money on the common, easy-to-configure 80%, and then spend a little more money developing the remaining 20% in-house. This portion can be "hard-coded", meaning little, if any, configuration is required, which is less work for everyone involved. All of his needs are met, and he didn't have to wait (or pay) for the perfect product.
Now, to address profit-motive and other such concerns in this thread. I am an advocate of open source software. That doesn't imply that I am also an advocate of free software, although I myself has contributed and I am grateful to the community for the innovation and competition they have provided. In a business setting, it may not always be practical to produce or use free software, although it is *always* in the best interest of the consumer to have the source code and the ability to modify it.
The money comes from the fact that no matter how long a free or commercial software program is developed and maintained it absolutely will not fit all of the needs of any organization. Currently I work for a company that uses three large closed-source systems for order entry, provisioning, and billing. As configurable as these systems are, I spend all of my time writing applications that apply our business logic on top of them. I am forced to reads/write from the DB, apply custom triggers, rewrite their stored procedures, and in some cases edit or replace ASPX files to attain the integration needed. Not only is this time-consuming, risky, and often inconvenient for users (trigger errors don't often bubble up to the UI in a friendly way), it also violates all kinds of support licenses, which is whole the point of buying these large closed-source systems in the first place.
Now, back in the day we used Tomcat and wrote most of our stuff in-house. We had a need to write a custom security layer for authentication/authorization against both LDAP and a windows domain controller. Nothing like that existed, so we wrote one ourselves using the Tomcat SecurityPrincipal interface and simply pluging in our extensions. Took a day, at most, to write and test, whereas we would have had to jump through hoops for weeks on an IIS system.
That's where your money comes from. Taking what's already written and what nobody wants to write again and adding business-specific logic, and integrating it with other systems. One of our vendors has changed their business model. They make virtually nothing on software sales and support, but they survive on their consultancy business. IBM is also doing this, and you can see by Microsoft's latest ISV push that they recognize this trend as well.
The question now is do I pay for closed-source software and lock myself into consultancy from that one vendor, or do I use an open source package as my base and pick and choose the talent that I bring in to improve and maintain it? If it were my business, I would choose the latter.
Not if Sun maintained the official repository, and managed commits similar to the way they are handled in Linux. Sun could still maintain their current Java Community Process to identify and prioritize enhancements, and then leverage the development efforts of the open source community rather than relying only on their internal developers.
Not everyone would have commit access, giving Sun time to verify, document, and test any improvements before including them as part of official Java project releases.
That doesn't stop forks, but lets face it, how many forks are there of Python, PHP, et al? As long as the community is satisfied that it's getting what it wants, and the source is available for ports and whatnot, I'm sure Sun can still hold onto the reins. It also allows Sun (in RedHat-esque fashion) to maintain a fully tested and supported ($$$) Enterprise version that's a few versions late, while giving developers nightly snapshots and unsupported minor releases.
It's better than what they have now, which is official support for Windows and Linux, and screw everyone else. We all download and use it for free anyway...why not put the community to work porting and improving it? It would sure make the JSRs go faster...
I think the fundamental problem with Microsoft products is that because of their ubiquity, they are are easily accepted and demanded by consumers. Now here's where it gets tough...as easy as these products are to consume (thanks to Microsoft, for all of the bundled software), they are equally hard to produce. none of the software used to produce content in these forms is not free. You can't even make a JPG image in Windows without buying something, but you can sure view it.
Which is fine...I'm all for capitalism. It sucks for me, but Microsoft has to make money somehow. But their tools are difficult to use and do not expose all of the functionality available. In this way, Microsoft always maintains an upper hand over its partners. With proprietary objects and functions they can do some wicked cool things with JScript in microsoft.com that leaves everyone scratching their heads wondering, "how did they do that?"
(There are, of course, Ruby, Flash, etc., but these plugins aren't bundled with the system, so content in this format is not *as* accessible.)
So...easy to consume, but difficult to produce. You have uncontrollable consumer demand due to the fact that every computer comes with the software, but the ability to produce said content costs money and is limited. I think that's everyone's major gripe--not that the products are actually useless, but that in order to produce content we're more or less forced to conform to the de-facto standard, and even then, only what's available to us.
(Incidentally, DivX is a poor example. A lot of technically inclined people know it and love it, but very few normal users even know it exists. And since there is a WMP plugin for it that automatically downloads from Microsoft's website in the event that they should want to view something in this format, how does the user ever know there are alternatives?)
So, as with Netscape/Mozilla(IE), Javascript (JScript), MP3/Ogg(WMA), AVI/MPG(WMP), Java(.NET), and every other well-designed, well-implemented, open, and arguably better format gets overshadowed by its Microsoft equivalent. Even freely evailable implementations. This is not market forces at work. This is a monopoly, and the only way to correct it is to force an even playing field for other products, ubiquity be damned.
ArrayList Z = new ArrayList( );
ArrayList N = new ArrayList( );
N.AddAll( Z );
You couldn't cast between them per se, but this would be much safer anyway. Look at it another way:
Integer z = new Integer( 1 );
Number n = z;
n.Parse( 5.2 );
If the object referenced by n were actually of type Number, then the above should work. However, the object is of type Integer, so the parse should fail (although I must confess that I don't know what the actual outcome would be...I haven't used Java in over a year). It's really the same situation. Intuitively you would think it would work, but you can see from the example how unsafe it would be. The following *would* work in any case:
Integer z = new Integer( 1 );
Number n = new Number( z.intValue( ) );
n.Parse( 5.2 );
or:
Integer z = new Integer( 1 );
Number n = z;
n = new Float( 5.2 );
What would be nice is if the fob had 256 MB of storage space, and you could grab the album right there at the kiosk, plug the FOB into your portable MP3 player, and listen to it on the way home. Like a nomad with a public/private keypair. Plug it in, your account is debited, and the music is transferred to the device. Impulse buying at its finest.
G5 Powerbooks soon, perhaps?