I've talked before about how crash reporting hasn't yet entered the mainstream of available services from open source hosting sites. GNU Savannah, Sourceforge, Google Code, none of them provide crash reporting to their customers. If your program crashes in the field, you either need your user to report a bug manually or you need to implement or reuse a crash reporting system, but more importantly, you also need to host your own crash reporting service.
I've talked before on how this is really a shame especially considering that Google produces breakpad, certainly good enough for the C and C++ community to start improving the quality of their software thanks to good crash reporting and some projects definitely are, albeit, again, using their own servers.
To this day, Microsoft is the only company that is hosting an error reporting service that it makes available to all developers in the form of Windows Error Reporting. Kudos to Microsoft for this effort.
I've been very enthusiastic about my jump from C++ to the Java platform, or to a much lesser extent the .Net (Compact) platform. The reasons for this aren't related to language features, C++ armed with smart pointers and modern libraries and idioms can easily compete with the Java 5 language and C#.
No, the reason is how much richness is kept in the compiled binary format representation of these platforms. Of course, the massive advantage of Java over, well, pretty much everything else, in the number of high quality libraries that are available certainly helps too. The point being if you've had to deal with post-mortem debugging before, the rich and high quality stack traces you can get from a Java exception versus the information you get from a minidump file is night and day. You can't get this from a C or C++ program even if you do all your symbol generation correctly because a lot of good and necessary information is optimized away. While with the other two, the non optimized version is still available on disk since it's compiled just in time.
Taking a step back here for a second to talk about ahead of time versus just in time compilation. I'm not too familiar with .Net outside of the compact edition but the performance of Java SE 6 is simply amazing, I've done enough high level C++ to know that Java SE 6 beats it hands down performance wise. Forgetting the ton of adaptive optimizations that the HotSpot virtual machine can do here for a moment, one of the major reason for this is the heap. Heap implementations in C++ are still based on C's malloc which isn't exactly good at dealing with tons of little polymorphic object allocations. C's malloc is still geared toward the C program, you allocate a bunch of memory at start up and you use that as a pool until your program ends. Not exactly friendly to a high level C++ program nor a multi-threaded one.
Getting back on track here, the lack of error reporting services unfortunately extend to the Java world. Even the tree major Java hubs out there, in addition to the tree named at the start of this post, namely java.net, Apache and Codehaus do not provide crash reporting services. I guess Apache is off the hook since they provide mostly libraries and server software, but still, much could be done in the area of crash reporting.
All of this brings me to how NetBeans handles unhandled exceptions that occur in the wild. NetBeans pops up this little dialog and asks you to send in your report. Once you do send it, it's almost magical, reports are queued, analyzed, associated to either a new report or an existing report and finally the generic reports are associated to an issue in IssueZilla and it does it all automatically. If the issue is fixed, it even tells you in which, upcoming or not, version it has been fixed.
This is how it should be done. I don't know what license this system is under, but how about getting this into the greater community? Let's get this system moved from being NetBeans specific to all projects hosted at java.net for example. And what's really nice about this is that it doesn't have to be limited to Java SE/EE, this can work just fine with Java ME too. Now, wouldn't that be something?
Sunday, August 17, 2008
Friday, July 25, 2008
BlackBerry + WiFi
Taking a short break from the planned article list to rant about my new least favorite feature of BlackBerry OS.
If you have a BlackBerry that also happens to support WI-FI, you might be surprised to find out that your favorite networked application doesn't favor WI-FI over APN when you're in range.
In fact, these applications will never favor WI-FI over your regular data network link. This is because the BlackBerry operating system does not abstract this for the application programmer. In other words, unless the application programmer knows about this and explicitly codes support for WI-FI in his application, the application will never use WI-FI.
So how do you get WI-FI support in there? You have to append the magical string ";interface=wifi" to any URL that you want to open. So, assuming standard Java ME/CLDC network programming here, you would do something like:
String uri = "http://www.spectrumdt.com;interface=wifi";
HttpConnection c = (HttpConnection) Connector.open(uri);
Otherwise, your application will inform you that "Could not open tunnel - Max time out" or go over your regular data link.
And that's about it. Oh, and by the way, if you don't have WI-FI or you're out of range, the OS won't do you any favors and fall back to your regular data link, so you have to make sure to try out the regular data link in case of errors too.
Finally, I would like to say that this feature is mostly impossible to find in the BlackBerry documentation. I found it in a beta version of an upcoming manual. The only reason I noticed this is that my development BlackBerry doesn't have a sim card, the browser worked, but my application didn't. Also of interest, almost all non first party applications I tested couldn't use WI-FI either. I'm guessing quite a few people don't know about this.
If you have a BlackBerry that also happens to support WI-FI, you might be surprised to find out that your favorite networked application doesn't favor WI-FI over APN when you're in range.
In fact, these applications will never favor WI-FI over your regular data network link. This is because the BlackBerry operating system does not abstract this for the application programmer. In other words, unless the application programmer knows about this and explicitly codes support for WI-FI in his application, the application will never use WI-FI.
So how do you get WI-FI support in there? You have to append the magical string ";interface=wifi" to any URL that you want to open. So, assuming standard Java ME/CLDC network programming here, you would do something like:
String uri = "http://www.spectrumdt.com;interface=wifi";
HttpConnection c = (HttpConnection) Connector.open(uri);
Otherwise, your application will inform you that "Could not open tunnel - Max time out" or go over your regular data link.
And that's about it. Oh, and by the way, if you don't have WI-FI or you're out of range, the OS won't do you any favors and fall back to your regular data link, so you have to make sure to try out the regular data link in case of errors too.
Finally, I would like to say that this feature is mostly impossible to find in the BlackBerry documentation. I found it in a beta version of an upcoming manual. The only reason I noticed this is that my development BlackBerry doesn't have a sim card, the browser worked, but my application didn't. Also of interest, almost all non first party applications I tested couldn't use WI-FI either. I'm guessing quite a few people don't know about this.
Sunday, July 13, 2008
GWT + j_security_check
I went out looking for a solution to this recently and found very little information. A lot of questions unanswered led me to believe I was not the only one who wanted to do this. I present here a small sample on how to accomplish this.
Before presenting the sample, let's go over a few things first on why you would want to do this and more importantly why you still need an Ajax style security token for all your GWT services even after this is implemented.
The reasons you would want to do this? One is automatic single sign-on (SSO) if supported by your container, e.g., Glassfish supports SSO out of the box for its web, EJB and web services tiers. If you use j_security_check, you're in; you're into all these services. Furthermore, if you use a J2EE authorization agent like OpenSSO inside Glassfish, you're into any services or sites provided by that federation. So even if you’re fronting your application with GWT, your back end might be composed of all these elements and more.
This also allows you to use any standard security annotations in your EJBs or, if you're orchestrating like me, in OpenESB. You can do this because you now have a Java security principal setup inside the container.
This also allows you to leverage the clustering features, if any, of your application server. Glassfish, again, contains great out of the box support for clustering. Session replication and expiration is managed for you and it just works. One call can proceed on one server while the other can proceed on another while the caller remains completely oblivious to where its work is actually being executed.
What you can’t do however is assume that you should no longer have an object representing your logged in user in your GWT client code. GWT RPC calls are still out in the open with this technique, you should pass in at the very least your session id value as a parameter to the GWT remote call so that the RCP service can do validations.
You still need SSL. Use SSL to make sure your password is transmitted securely over the wire. Hashing on the client side is completely useless. First, because MD5 is usually about the only thing available in JavaScript and that is easily broken. Second, because you should be counting on SSL to do its job correctly. Third, once on the server, you should hash your password with something that is secure, i.e., not MD5 and throw away the clear text representation of the password.
I use NetBeans 6.1 and release candidate 1 of GWT 1.5 for this example. The idea is to use the RequestBuilder class to touch a resource that has been marked off limits by the container. We do this because the j_security_check, in Java EE 5 at least, cannot be invoked directly in a portable manner. When the server sees the access to the protected resource by an unknown, it redirects you to the login page. When this occurs, the method “onResponseReceived” is called. We ignore the redirect and submit our own form. The form just needs to have at least 3 named elements present:
- The form name, j_security_check
- The user name field, j_username
- The password field, j_password
If you don’t touch a protected resource first and simply submit your form immediately, you will find that you still don’t have a security principal since no login actually occurred in the container.
You would apply the same rules for defining a protected area than you would for a normal non-GWT application. You can see on how to do this in Glassfish and Tomcat by following the tutorial here.
Here is some sample code that fulfills a login on Java application server. I originally had more here in terms of error handling but it seemed it got to be too large for presentation purposes.
|
|
Wednesday, July 9, 2008
Upcoming
The blog has been very silent but I have quite a few articles in the queue coming up. Upcoming on this blog are:
I'm so busy I don't know when I'll have time to write any of these but hopefully they will be up before long.
I'm so busy I don't know when I'll have time to write any of these but hopefully they will be up before long.
Wednesday, June 11, 2008
Just How Bad is Windows CE?
Lately, I've been developing concurrently on the iPhone and Windows Mobile. The .Net Compact framework is actually pretty good compared to the iPhone SDK but the user interface of Windows Mobile is just so very, very awful. I can't think of anyone who has tried absolutely anything else and like this. I can't even think of anyone liking this period. Considering how good a job Microsoft is doing with its general and server operating systems, how is it possible that they are even willing to release this product in the first place? Considering the quality and usability of the desktop and server systems that Microsoft puts out, Windows Mobile isn't even worthy of calling itself Windows. Sure the underlying kernel and technologies are pretty solid but it doesn't change the fact that the user interface is just crammed for such a small screen. I was using this the other day just to make a call and kept thinking to myself how many people I know wouldn't even be able to answer or make a call with this thing.
The real problem with Windows Mobile is that it isn't trying to be a really good phone, it's trying to be a pocket PC which not so coincidentally was its original brand. It just doesn't have the screen real estate to pull that off.
At WWDC 2008, Apple announced 3G iPhones that are actually cheaper than the current models. This is bad news for every smart phone vendor out there. I see really two segments now, the people who just want a basic phone, and the people who want an iPhone. The iPhone is really just that disruptive of a technology. I can't explain in words just how horrible it is to start using another smart phone again. Furthermore, it's the only phone that I have encountered that makes mobile web browsing viable.
So what is everybody else doing? Well, you have things like Android and the Samsung Instinct which are clearly heavily influenced by the iPhone but neither are yet available. The iPhone 3G, with its 7 Mbps Internet access, goes on sale early July of this year.
All is not lost for other vendors however. Let's face it, even with its new focus on the enterprise with the iPhone, Apple is really not very good at dealing with businesses and developers at this scale. Those users won't put up with half the things the regular Apple fan boy puts up with. If you're in the iPhone developer program right now, you probably don't like Apple very much. The things they make you do to actually deploy an application to real hardware is pretty obscene. At this point, I think it's Apple's market to lose. We'll see if Apple will learn a bit of humility here and open up this platform instead of imposing their will on everything closely related to the iPhone. This is really where the door is open for something like Android to come in and really give iPhone a run for its money.
We'll only know for sure over time but Google, now more than ever, needs to get real hardware out into the wild and at the very least refresh the Android public SDK. The Android SDK drop is still the one from last March and, thanks to controlled leaks, doesn't look or feel anything like the Android of today.
So just how bad is Windows CE? Well, it's so bad I don't even think it's a contender anymore. Let's face it, convergence is still ever creeping in. In a few years, your primary computer will probably be your phone that you cradle to get a full sized screen and keyboard. This is already happening, just have a look at the Celio REDFLY. I would think this makes Microsoft pretty nervous.
The real problem with Windows Mobile is that it isn't trying to be a really good phone, it's trying to be a pocket PC which not so coincidentally was its original brand. It just doesn't have the screen real estate to pull that off.
At WWDC 2008, Apple announced 3G iPhones that are actually cheaper than the current models. This is bad news for every smart phone vendor out there. I see really two segments now, the people who just want a basic phone, and the people who want an iPhone. The iPhone is really just that disruptive of a technology. I can't explain in words just how horrible it is to start using another smart phone again. Furthermore, it's the only phone that I have encountered that makes mobile web browsing viable.
So what is everybody else doing? Well, you have things like Android and the Samsung Instinct which are clearly heavily influenced by the iPhone but neither are yet available. The iPhone 3G, with its 7 Mbps Internet access, goes on sale early July of this year.
All is not lost for other vendors however. Let's face it, even with its new focus on the enterprise with the iPhone, Apple is really not very good at dealing with businesses and developers at this scale. Those users won't put up with half the things the regular Apple fan boy puts up with. If you're in the iPhone developer program right now, you probably don't like Apple very much. The things they make you do to actually deploy an application to real hardware is pretty obscene. At this point, I think it's Apple's market to lose. We'll see if Apple will learn a bit of humility here and open up this platform instead of imposing their will on everything closely related to the iPhone. This is really where the door is open for something like Android to come in and really give iPhone a run for its money.
We'll only know for sure over time but Google, now more than ever, needs to get real hardware out into the wild and at the very least refresh the Android public SDK. The Android SDK drop is still the one from last March and, thanks to controlled leaks, doesn't look or feel anything like the Android of today.
So just how bad is Windows CE? Well, it's so bad I don't even think it's a contender anymore. Let's face it, convergence is still ever creeping in. In a few years, your primary computer will probably be your phone that you cradle to get a full sized screen and keyboard. This is already happening, just have a look at the Celio REDFLY. I would think this makes Microsoft pretty nervous.
Tuesday, May 6, 2008
The BlackBerry Curve
I have spent quite a bit of time dissecting this phone lately. The BlackBerry is certainly quite popular with some estimating its market share at 41% of all smart phones. On a recent trip to Pennsylvania, I saw many, many phones on planes and at the airports and I can certainly confirm that ratio. I counted close to 400 phones, half of which were some model of BlackBerry.
I have to admit, so far, this is the most impressive Java ME/CLDC capable phone found I have tried. Not only are many optional CLDC packages available but many more BlackBerry Java packages are present. That being said, Research in Motion (RIM), implements custom GUI packages that are specific to its platform. What that means is that if you code an application that follows the look and feel of a BlackBerry application, it will not function on any other phone.
I have to say however that this device is too expensive. At a suggested retail price upward of $400, it only features 64 MB of memory and an empty micro-SD card slot. A similarly priced iPhone comes with 128 MB of SDRAM and between 8 and 16 GB of flash memory. The iPhone screen supports touch and it's twice the vertical size of the Curve's screen.
The iPhone comes with Wi-Fi support too. Which means you can enjoy much faster networking on any hot spot and potentially save on those outrageously expensive over the air rates for bandwidth too. In Canada, MB per dollar access is ridiculously expensive. Rogers, for example, charges $10 per MB outside a plan. If you have a plan, prices range from $25 for 4MB per month to $100 for 100MB per month. Just disgusting if you ask me. Getting back on track here, you have expensive bandwidth and no memory to implement any kind of good caching on the phone. The only strategy left is to implement watered down services. Consider the browser on the BlackBerry for example, it has no JavaScript support and it mostly ignores any image properties found on a page in order to keep bandwidth consumption at a minimum. Sure, you can access the web but it doesn't mean it's any good.
RIM also develops probably one of the worst integrated development environments (IDE) you've ever seen. The JIDE is an all Java IDE that you use to code for the BlackBerry device. JIDE redefines what the word "ugly" means. Fortunately, RIM has started to develop a plugin for Eclipse and a plugin for Visual Studio. It's also possible to use NetBeans if you have enough energy to invest into it.
Looking at the BlackBerry, I have to wonder if the company suffers too much from the "not invented here" mentality and how much of that affects the price tag of its products. The company develops an IDE, customizes the licensed library and CLDC virtual machine from Sun, has its own executable format, implements its own content designers tools, etc, etc, all of which are very expensive. Talking to various colleagues these last few months, I am convinced that RIM must refresh its hardware in order to stay competitive. By refresh, I not only mean the power and visual appeal of their devices but the overall quality of the BlackBerry development platform or risk irrelevance.
I have to admit, so far, this is the most impressive Java ME/CLDC capable phone found I have tried. Not only are many optional CLDC packages available but many more BlackBerry Java packages are present. That being said, Research in Motion (RIM), implements custom GUI packages that are specific to its platform. What that means is that if you code an application that follows the look and feel of a BlackBerry application, it will not function on any other phone.
I have to say however that this device is too expensive. At a suggested retail price upward of $400, it only features 64 MB of memory and an empty micro-SD card slot. A similarly priced iPhone comes with 128 MB of SDRAM and between 8 and 16 GB of flash memory. The iPhone screen supports touch and it's twice the vertical size of the Curve's screen.
The iPhone comes with Wi-Fi support too. Which means you can enjoy much faster networking on any hot spot and potentially save on those outrageously expensive over the air rates for bandwidth too. In Canada, MB per dollar access is ridiculously expensive. Rogers, for example, charges $10 per MB outside a plan. If you have a plan, prices range from $25 for 4MB per month to $100 for 100MB per month. Just disgusting if you ask me. Getting back on track here, you have expensive bandwidth and no memory to implement any kind of good caching on the phone. The only strategy left is to implement watered down services. Consider the browser on the BlackBerry for example, it has no JavaScript support and it mostly ignores any image properties found on a page in order to keep bandwidth consumption at a minimum. Sure, you can access the web but it doesn't mean it's any good.
RIM also develops probably one of the worst integrated development environments (IDE) you've ever seen. The JIDE is an all Java IDE that you use to code for the BlackBerry device. JIDE redefines what the word "ugly" means. Fortunately, RIM has started to develop a plugin for Eclipse and a plugin for Visual Studio. It's also possible to use NetBeans if you have enough energy to invest into it.
Looking at the BlackBerry, I have to wonder if the company suffers too much from the "not invented here" mentality and how much of that affects the price tag of its products. The company develops an IDE, customizes the licensed library and CLDC virtual machine from Sun, has its own executable format, implements its own content designers tools, etc, etc, all of which are very expensive. Talking to various colleagues these last few months, I am convinced that RIM must refresh its hardware in order to stay competitive. By refresh, I not only mean the power and visual appeal of their devices but the overall quality of the BlackBerry development platform or risk irrelevance.
Sunday, May 4, 2008
JavaOne is this Week
The Java front news has been dry for the last little while since everyone is holding off on announcing anything, instead waiting for the conference in the hopes of getting more press.
I'm really eager to see what will be made available this week. That being said, I'm hoping for major announcements on JavaFX from Sun. At the very least, I'm hoping to see some strong tooling support for content creation on that platform for graphic designers. Also, I'm expecting a new Java ME/CDC operating environment for phones based on the assets acquired from SavaJe and the PhoneME Advanced project. This new environment will feature JavaFX across the board.
Now, I still think Android is better than Java ME/CDC, but the CDC with all optional profiles is equivalent to Java SE 1.4 which is still pretty enticing. Furthermore, Java ME + JavaFX might go a long way to catching up with Android. By the way, PhoneME Advanced implements all the optional CDC profiles, so yes, it's equivalent to Java SE 1.4.
I'm really eager to see what will be made available this week. That being said, I'm hoping for major announcements on JavaFX from Sun. At the very least, I'm hoping to see some strong tooling support for content creation on that platform for graphic designers. Also, I'm expecting a new Java ME/CDC operating environment for phones based on the assets acquired from SavaJe and the PhoneME Advanced project. This new environment will feature JavaFX across the board.
Now, I still think Android is better than Java ME/CDC, but the CDC with all optional profiles is equivalent to Java SE 1.4 which is still pretty enticing. Furthermore, Java ME + JavaFX might go a long way to catching up with Android. By the way, PhoneME Advanced implements all the optional CDC profiles, so yes, it's equivalent to Java SE 1.4.
Thursday, May 1, 2008
Mac OS X 7 Years Later
Continuing my work in the mobile space, I recently had to purchase a Mac. By recently, I mean the day that Apple made their iPhone SDK public. I like the iPhone, it's the device that has raised the bar, the device that has forced all other mobile manufacturers to rethink their own product lines. We should see some real advancements this year from mobile hardware, that it be in terms of screen quality, power and features from competing companies thanks to the iPhone.
If the iPhone and iPod Touch are neat little devices, I have to admit I'm not much of a fan of Mac OS X however. I remember being so excited when I got my copy of OSX 10.0.0. That excitement was promptly crushed when I saw it under perform on my lowly PowerPC G3. After that, I pretty much left the world of Macs behind until the iPhone SDK was publicly made available.
The first I notice is how little has actually changed since 2001. OSX today is pretty much the same OSX that I used in 2001. The performance is much better of course but pretty much the same nonetheless.
I don't like the inherent security policies that are setup after install time. For example, to install an application, you usually have to start an installation wizard to guide you through the process. At one point during the installation, you're usually presented with a privilege escalation dialog. Entering your credentials will allow the installation to proceed. Unfortunately, the same cannot be said about uninstalling. First of all, there is no global registry of installed applications, so there is no uninstall wizard. You just go to the applications folder and drag an application to the trash to uninstall it. That's fine, my point is that you don't actually need to escalate to drop your applications into the trash. That's just plain wrong. Furthermore, it's only fine if this is where the application installed all of its files in the first place. Some applications will also install software in more traditional UNIX locations. If you happen to install such a beast, you'll be stuck with those extra utilities or have to rely on using a custom uninstaller before doing a regular uninstall. These custom uninstallers are usually Bourne shell scripts.
Speaking of escalation. Apple may poke fun at Microsoft about UAC in their commercials, but let me tell you they have nothing to brag about. First of all, they have an escalation prompt too, just like UAC. However, a filtered administrator, instead of a single click on 'Continue', must enter his password every time or optionally cache his credentials for a limited amount of time. Both options are terribly insecure. First, because if a malicious piece of software on both these systems makes a dialog box that mimics the appearance of this dialog, you get two very different results. On Vista, you have given out a mouse click (by clicking on 'Continue'), while on OSX you have given out your escalation credentials. Yeah Apple, keep making jokes. Furthermore, caching of credentials? Really? So everything I execute for the next little bit is running escalated? Really? At this point, I think OSX is only secure because it's less of a target than Windows, that's it, nothing else. It really has nothing to brag about. You can say all you want about the underlying UNIX security model found in OSX but if the user interface handles security this way, it's all for nothing.
I officially don't like Objective C. You can talk about the virtues of your favorite programming language all you want or not at all but it doesn't change the real reason some languages are popular and some aren't, in a word taste. Considering mostly all languages these days are Turing complete and object oriented, what a language looks like on screen is pretty much the only differentiator. When people like something, they have a reaction to it and they like it. Same thing when they don't like it. It's the same really for programming languages, when you look at a piece of code on screen, something in you reacts and decides if you like it or not, it really is that simple. When the dust settled, most people decided they didn't like how Objective C felt and used something else. Well, I'm now part of that group too except I can't use something else on the iPhone. I don't completely dislike it, e.g., I like the big class library and I like being able to retrieve the constructor of a class with nothing else but a string that represents the class name, I do, I really do... but that's about it really. The overly verbose method calls, the unified diff challenged syntax, i.e., '+' for static methods and '-' for instance methods is just plain evil when you're reviewing patches.
Using memory pools manually is also really just annoying. What is this? C or Objective C? I'm still not clear on how to correctly use these things across threads on the iPhone. I'm aware that the full OSX supports garbage collection now.
What I really despise however, what turned me off to Mac OS Classic and still does it for me today is the workbook style windows found in applications. If you've never used Mac OS, early versions of Visual Basic and Delphi suffered from this problem on Windows too. You have a single application but instead of being contained into a single master window, you have many little windows floating around everywhere. If you have multiple applications opened at the same time, you can see the windows of other applications within the holes of your current application. Most annoying is that there doesn't seem to be a standardized shortcut for quickly moving focus around between the windows of a single application. This makes use of Xcode really annoying. If I just happened to miss this keyboard shortcut, please, for the love of any deity you worship, please leave me a comment and tell me what it is.
Of course, it's not all bad. One very good feature of this OS is the startup and shutdown times. They both put Windows and Linux to shame.
The UNIX command line is a very nice touch too. I have to admit, as much as I like Vista, I don't think I could use it, or any other version of Windows for that matter, if it weren't for Cygwin.
If the iPhone and iPod Touch are neat little devices, I have to admit I'm not much of a fan of Mac OS X however. I remember being so excited when I got my copy of OSX 10.0.0. That excitement was promptly crushed when I saw it under perform on my lowly PowerPC G3. After that, I pretty much left the world of Macs behind until the iPhone SDK was publicly made available.
The first I notice is how little has actually changed since 2001. OSX today is pretty much the same OSX that I used in 2001. The performance is much better of course but pretty much the same nonetheless.
I don't like the inherent security policies that are setup after install time. For example, to install an application, you usually have to start an installation wizard to guide you through the process. At one point during the installation, you're usually presented with a privilege escalation dialog. Entering your credentials will allow the installation to proceed. Unfortunately, the same cannot be said about uninstalling. First of all, there is no global registry of installed applications, so there is no uninstall wizard. You just go to the applications folder and drag an application to the trash to uninstall it. That's fine, my point is that you don't actually need to escalate to drop your applications into the trash. That's just plain wrong. Furthermore, it's only fine if this is where the application installed all of its files in the first place. Some applications will also install software in more traditional UNIX locations. If you happen to install such a beast, you'll be stuck with those extra utilities or have to rely on using a custom uninstaller before doing a regular uninstall. These custom uninstallers are usually Bourne shell scripts.
Speaking of escalation. Apple may poke fun at Microsoft about UAC in their commercials, but let me tell you they have nothing to brag about. First of all, they have an escalation prompt too, just like UAC. However, a filtered administrator, instead of a single click on 'Continue', must enter his password every time or optionally cache his credentials for a limited amount of time. Both options are terribly insecure. First, because if a malicious piece of software on both these systems makes a dialog box that mimics the appearance of this dialog, you get two very different results. On Vista, you have given out a mouse click (by clicking on 'Continue'), while on OSX you have given out your escalation credentials. Yeah Apple, keep making jokes. Furthermore, caching of credentials? Really? So everything I execute for the next little bit is running escalated? Really? At this point, I think OSX is only secure because it's less of a target than Windows, that's it, nothing else. It really has nothing to brag about. You can say all you want about the underlying UNIX security model found in OSX but if the user interface handles security this way, it's all for nothing.
I officially don't like Objective C. You can talk about the virtues of your favorite programming language all you want or not at all but it doesn't change the real reason some languages are popular and some aren't, in a word taste. Considering mostly all languages these days are Turing complete and object oriented, what a language looks like on screen is pretty much the only differentiator. When people like something, they have a reaction to it and they like it. Same thing when they don't like it. It's the same really for programming languages, when you look at a piece of code on screen, something in you reacts and decides if you like it or not, it really is that simple. When the dust settled, most people decided they didn't like how Objective C felt and used something else. Well, I'm now part of that group too except I can't use something else on the iPhone. I don't completely dislike it, e.g., I like the big class library and I like being able to retrieve the constructor of a class with nothing else but a string that represents the class name, I do, I really do... but that's about it really. The overly verbose method calls, the unified diff challenged syntax, i.e., '+' for static methods and '-' for instance methods is just plain evil when you're reviewing patches.
Using memory pools manually is also really just annoying. What is this? C or Objective C? I'm still not clear on how to correctly use these things across threads on the iPhone. I'm aware that the full OSX supports garbage collection now.
What I really despise however, what turned me off to Mac OS Classic and still does it for me today is the workbook style windows found in applications. If you've never used Mac OS, early versions of Visual Basic and Delphi suffered from this problem on Windows too. You have a single application but instead of being contained into a single master window, you have many little windows floating around everywhere. If you have multiple applications opened at the same time, you can see the windows of other applications within the holes of your current application. Most annoying is that there doesn't seem to be a standardized shortcut for quickly moving focus around between the windows of a single application. This makes use of Xcode really annoying. If I just happened to miss this keyboard shortcut, please, for the love of any deity you worship, please leave me a comment and tell me what it is.
Of course, it's not all bad. One very good feature of this OS is the startup and shutdown times. They both put Windows and Linux to shame.
The UNIX command line is a very nice touch too. I have to admit, as much as I like Vista, I don't think I could use it, or any other version of Windows for that matter, if it weren't for Cygwin.
Wednesday, April 16, 2008
Google's App Engine
Seriously, what happened? Python? I don't mean to offend anyone but why come up with this nice, huge, not to mention free, application server if all you're going to support is Python?
Now, I'm sure they are tons of people who like Python, I just happen to not be one of them. I don't like languages that are brace challenged. What's really annoying is that Google has been pushing its Web Toolkit(GWT) this last year, a toolkit that lets you write Java code for the client that gets compiled down to JavaScript so that is can execute on the client. Why is this not supported?
That being said, since GWT compiles down to static HTML and JavaScript files, it's still possible to use the client side, compiled product from Google's App Engine. The server end of the application would have to be written in Python. Furthermore, the RPC mechanism provided by GWT would need to be dismissed in favor of REST or JSON for communications.
All this to say that the top four requested features on the Google Code site for this project are support for other languages. I can understand Google not supporting Ruby, PHP and Perl. Google doesn't have any significant history with any of these languages. Java on the other hand? I just don't get it.
Now, I'm sure they are tons of people who like Python, I just happen to not be one of them. I don't like languages that are brace challenged. What's really annoying is that Google has been pushing its Web Toolkit(GWT) this last year, a toolkit that lets you write Java code for the client that gets compiled down to JavaScript so that is can execute on the client. Why is this not supported?
That being said, since GWT compiles down to static HTML and JavaScript files, it's still possible to use the client side, compiled product from Google's App Engine. The server end of the application would have to be written in Python. Furthermore, the RPC mechanism provided by GWT would need to be dismissed in favor of REST or JSON for communications.
All this to say that the top four requested features on the Google Code site for this project are support for other languages. I can understand Google not supporting Ruby, PHP and Perl. Google doesn't have any significant history with any of these languages. Java on the other hand? I just don't get it.
Wednesday, March 19, 2008
NetBeans 6.1: The Best just got Better
When it comes to IDEs, I've been around. I've used Visual C++ since version 1.5. Tried other environments over the years, but Visual Studio was by far the best no matter what other people claimed.
I started using Eclipse since that's what everyone around me was using for some Java work and I hated it. I'll reserve my thoughts on that for a future blog post but it was never a comfortable fit for me. Needless to say, I've converted my entourage from Eclipse to NetBeans now.
Version 5.5.1 of NetBeans was pretty good but the editor kept, well, I'm not quite sure on how to describe this, but it kept being wrong... or feeling wrong at least. Not sure if that makes any sense but that's the best I've got to offer.
NetBeans 6 was simply fantastic. It was just great. Probably one of the best IDEs I've ever used. That being said, it had a few shortcomings that were really annoying. On huge files, code completion was somewhat slow. Not that slow, but code completion is one of those features where you must literally work at the speed of thought of the developer. Otherwise, you break the flow of the developer. Startup time was annoying but manageable.
NetBeans 6.1 has really been great for me, so great that I've ditched 6 for the 6.1 beta. They are several reasons for this. First, it seems to me like this thing has had a lot more debugging time than a fully patched 6.0.1 release has. So it just works even if it's just a beta. That being said, a small caveat here is that I shun JavaScript work in favor of GWT. So I don't know how the rewrite has impacted that editor.
However, it's the little things that make the difference. For example, my favorite new feature by far is the default location of the Glassfish domain. Silly? Maybe, but I use Vista across the board. It has always been considered impolite under Windows to write to "Program Files" after installation has completed. Starting with Vista however, that folder has now been locked down. Meaning that with NetBeans 6, the default developer domain lived under "Program Files\Glassfish\domains\domain0". Under Vista, you had to either unregister your Glassfish server from the IDE and re-register it again with a more polite location, or you had to go into the Glassfish folder in "Program Files" and grant yourself write privileges to the domain's folder in order to support all scenarios. NetBeans 6.1 under Vista, and hopefully under any other Windows version too, creates the default domain inside your home directory. I think I almost cried when I saw that.
That being said, as much as I love this IDE now, ending a 14 year old run on Visual Studio/C++, I still have my pet peeves. In no particular order:
I started using Eclipse since that's what everyone around me was using for some Java work and I hated it. I'll reserve my thoughts on that for a future blog post but it was never a comfortable fit for me. Needless to say, I've converted my entourage from Eclipse to NetBeans now.
Version 5.5.1 of NetBeans was pretty good but the editor kept, well, I'm not quite sure on how to describe this, but it kept being wrong... or feeling wrong at least. Not sure if that makes any sense but that's the best I've got to offer.
NetBeans 6 was simply fantastic. It was just great. Probably one of the best IDEs I've ever used. That being said, it had a few shortcomings that were really annoying. On huge files, code completion was somewhat slow. Not that slow, but code completion is one of those features where you must literally work at the speed of thought of the developer. Otherwise, you break the flow of the developer. Startup time was annoying but manageable.
NetBeans 6.1 has really been great for me, so great that I've ditched 6 for the 6.1 beta. They are several reasons for this. First, it seems to me like this thing has had a lot more debugging time than a fully patched 6.0.1 release has. So it just works even if it's just a beta. That being said, a small caveat here is that I shun JavaScript work in favor of GWT. So I don't know how the rewrite has impacted that editor.
However, it's the little things that make the difference. For example, my favorite new feature by far is the default location of the Glassfish domain. Silly? Maybe, but I use Vista across the board. It has always been considered impolite under Windows to write to "Program Files" after installation has completed. Starting with Vista however, that folder has now been locked down. Meaning that with NetBeans 6, the default developer domain lived under "Program Files\Glassfish\domains\domain0". Under Vista, you had to either unregister your Glassfish server from the IDE and re-register it again with a more polite location, or you had to go into the Glassfish folder in "Program Files" and grant yourself write privileges to the domain's folder in order to support all scenarios. NetBeans 6.1 under Vista, and hopefully under any other Windows version too, creates the default domain inside your home directory. I think I almost cried when I saw that.
That being said, as much as I love this IDE now, ending a 14 year old run on Visual Studio/C++, I still have my pet peeves. In no particular order:
- it's still slow to startup even it's a lot faster than it used to be.
- I hate the fact that they are no project grouping feature similar to the solution concept in Visual Studio. NetBeans does actually have a project group feature but I just hate it. I hate it because it doesn't live on the file system, hence I can't commit it to source control. This means sharing project groups between team members is really annoying. I hate it because it clutters up the UI. The idea of a master project I find is also broken. Simply because you don't know right off the bat which of the project in a hierarchy is the master. I'm hoping that full support for Maven in NetBeans 7 will take care of this.
- I use this IDE for pretty much everything now except for Windows Mobile and Android development. Which means I use it for C++ too. I don't use C++ that much anymore but it does come in handy. It works really well under Windows with cygwin, I even have Microsoft's Platform SDK hooked into this thing. Again, works pretty well. That being said, g++ is the only supported compiler under Windows. Considering the Visual C++ compilers ship with the Platform SDK now, I would like to be able to just use those instead of g++.
- I would like to be able to run multiple instances of the IDE at the same time. The scenario here is when I want to debug both the client and server end of an application at the same time.
- Better GWT support. Matisse is great but with all these new languages and toolkits like JRuby, Groovy and GWT coming into the Java ecosystem now, isn't it about time this thing started to learn new tricks? Look at SharpDevelop for instance. It has a visual form designer for all the languages it supports.
- Message queues in the services tab. I really like the services tab. I really like the fact that databases are showing up there too now with this release. The Java DB menu item looked out of place in the tools menu in 6. Support for stand alone instances of JMS brokers would be a welcomed addition. I use Glassfish a lot, but I also use ActiveMQ outside of any Java EE container a lot too. Why? Because of the additional interoperability features it provides. Very handy to have around. And yes, before anyone comments on this, I know about the STOMP adapter from CodeHaus could probably be installed on OpenMQ.
- Support for Groovy, Groovy and Groovy.
- Lastly, I would like to see a Geronimo server plugin. Yeah, I know this a weird one considering I'm all Glassfish. However, I have one project where Geronimo was the best compromise I could reach. Maybe this is selfish but in my defense, I would probably have started coding this if it hadn't been for this thread here.
Subscribe to:
Posts (Atom)