Microsoft continues to threaten web development by Thom McGrath

I just read an article about Internet Explorer 9. Considering that Internet Explorer 7 and 8 have made significant strides towards standards-compliance, I was under the impression that IE9 might begin to support CSS3 and HTML5. Especially since Microsoft has taken an interest in working with the W3C, Apple, Mozilla, and Google on HTML5.

First the good news. IE9 brings significant improvements to JavaScript performance. This is fantastic since IE8 cannot keep up. I've actually disabled some features on the REAL web site when using Internet Explorer because it just is not fast enough.

The bad news is that Microsoft is continuing to threaten standards. Rather than supporting the proposed cross-platform WebGL, Microsoft intends to support their own Windows-only Direct2D. Once again, developers will need to choose which side they're on. It is nothing new either. In the IE6 days, developers needed to choose to do things right and support everything except IE6, or do them simple and wrong to support IE6. This will be even worse, because a developer looking to do 3D will have no choice than two write two sets of code, or choose to support only IE9 or standards browsers.

Does it surprise me? Yes and no. It surprises me because it seemed as if Microsoft was interested in making a good browser. It does not surprise me because Microsoft gets everything else wrong, so why would this have been different.

[ Permalink | Accepting Comments (1) | Accepting Pings (0) ]

Feedback Ships by Thom McGrath

After a very long time in development, REAL Software's new feedback system is finally available to the public and in use.

I've been working on this system for a long time, since about mid-March if I recall correctly. It's so nice to finally see it live. I'm so proud to have contributed this to REAL Software, since it is such a crucial part of the company. Sure, I've worked on critical parts of the company for about a year now (new website backend, new servers, new order system), but there is something special about this. That other stuff is all very important, probably more than the feedback system, but this is an app that our customers will use frequently.

We've already been getting many compliments about the design of the app, and I do plan to do a post-mortem type article on the company blog. It does surprise me though, because although I find the UI simple, it's certainly not ground-breaking in my opinion. Or I just have high standards.

Early in the development process, we discussed a very critical choice: web-based or desktop-based. The discussion was heavily weighted towards web-based, and I could certainly do it, but I saw an opportunity to do something special. By creating a desktop app, it could be designed to show-off some of the abilities of REALbasic (not that the IDE does not already do that) and it allows us an unprecedented level of integration with our products and our user's systems.

Since it was being developed on the desktop, the argument was made that this should be completely integrated into REALbasic. While an interesting thought, that posed a couple problems:

1. If REALbasic crashes, that system has a lot of functionality that needs to work inside an application that has already had an exception and locked up. There is a lot of potential for lost information there.
2. If there is a minor bug in the feedback system, it could not be fixed until the next release of REALbasic. That's a significant problem for a new system. Keeping it separate allows us to push updates (yes, it has an auto-update system) to our users without them downloading the entire REALbasic package.
3. What about our other products? Should a customer really be expected to launch REALbasic just to report a bug about our website or REAL Server? No.

So development on the app began from the ground up. Code was developed to handle preferences correctly on each platform, open source projects were utilized to provide animation, client-to-server communication and CoreFoundation support, and the source list and automatic updates were provided by code I had laying around and needed a good testing route. Right off the bat, many of the core systems of the application were falling into place.

Another big source of debate is the app's client-to-server communication method. This app does not speak to our database directly. An abstraction layer was implemented on the server to provide security and ease development. During the beta process, many bugs were fixed simply by updating server-side code. Using a straight SQL connection could not have done that. If we needed to move databases, upgrade servers, etc then we would need to issue an update to app. Instead, we could switch the database backend entirely without the app ever complaining. There's no database login details in the app, nor does it even know where the database is. That provides a significant amount of security. This abstraction layer also allows the activity viewer to work. You'll notice that the app almost never locks up or appears unresponsive. That's another thing an SQL connection could not have provided. There is still some debate that the app should be speaking directly to our REAL Server, but I stand by my position that this abstraction layer is not only very useful, but very important.

We quickly realized people would be asking for some of this functionality in REALbasic. It'll happen. I don't know when, and I don't know what, but we are aware of some gaps in the REALbasic framework that the code from this app can fill.

We have big plans for this tool. Remember, this is the 1.0.0 release. There is plenty of room to grow. Of course, I can't say what ideas are floating around, but I will say it will keep evolving.

Lastly, although I did all the development work on the app, the entire team provided lots useful feedback, suggestions, requirements, etc. I can't take all the credit.

[ Permalink | Accepting Comments (1) | Accepting Pings (0) ]

Marvel Dies by Thom McGrath

Marvel has agreed to be bought-out by Disney. Need I say more? I imagine everybody else already has, but I'll say it as well.

[ Read More | Accepting Comments (3) | Accepting Pings (0) ]

iPhone Upgrading by Thom McGrath

I decided to upgrade my launch-day iPhone to a new white 32GB 3GS. The upgrade went pretty smoothly, and the features are nice. This article is part review, part nightmare.

[ Read More | Accepting Comments (0) | Accepting Pings (0) ]

Nintendo Almost Disappoints by Thom McGrath

I watched Nintendo's E3 conference live today. As expected, it was more gimmicks. A lot of them. I'm happy to see New Super Mario Brothers coming to the Wii, and I imagine the RPG titles coming to the Wii and DS will make their fans happy too. But most of the conference was about appealing to tweens and non-gamers. That's fine, but gamers need something too!

[ Read More | Accepting Comments (2) | Accepting Pings (0) ]

Life Without Logic by Thom McGrath

Not too long ago, I noticed Microsoft's new windows tagline: "Life Without Walls". Right...

[ Read More | Accepting Comments (0) | Accepting Pings (0) ]

REALbasic 2009r1 Released! by Thom McGrath

REALbasic 2009r1 is one of my favorite releases, and it should be yours too. This release adds a handful of useful new features, and it's also the first release I've directly contributed code to.

[ Read More | Accepting Comments (0) | Accepting Pings (0) ]

Tip: Fix Linux Button Sizes by Thom McGrath

This really bugs me about Linux, at least on Ubuntu. Button sizes are typically 30 pixels tall, as opposed to the 20 pixels on Mac and Windows. So when you're creating your UI and plan to deploy to Linux as well, be aware of this. If your button sizes are 20 pixels tall - the REALbasic default - your buttons will look terrible on Linux, only showing the top half of the caption.

My solution? A subclass of PushButton I call RespectfulPushButton. In it's Open event, I simply make the height 10 pixels taller and move it up by 5 pixels. The result won't harm the UI much, and the buttons look perfect on Linux. You'll then want to define a new Open event, and trigger it from the Open event of the subclass. Of course, use conditional compiles to only resize the buttons on Linux. I then just use this subclass instead. Minimal work to setup, but you'll then need to get into the habit of using the subclass instead when placing new buttons.

PopupMenus have this pain as well. I have not seen this on any other controls, but I most write my own anyway.

[ Permalink | Accepting Comments (0) | Accepting Pings (0) ]

REAL Software Website Updates by Thom McGrath

We've had our new site online for a little over a month now and since then, we've been listening to user feedback and rolled out some new updates for the site. Some of which you'll notice, others are under the hood. (Those under-the-hood ones are very useful, but I won't speak of them here.)

[ Read More | Accepting Comments (0) | Accepting Pings (0) ]