I just bought a 1TB external HD, the "Maxtor OneTouch 4 Plus" this weekend on sale at London Drugs. A bit of an impulse purchase but I've been digiizing all of our dvd's lately into iTunes and had completely run out of space...
The drive has a bunch of automated backup features I'll never use, so I skipped all the software and went to use the drive directly from Mac OS X. First step here is to convert the format of the drive from it's default of NTFS to something Mac can natively use. My impulse was to simply "format" and continue but unfortunately every time I tried the format disk utility would abort with nothing useful showing in the console logs. I went through this a few times with different file system settings and nothing worked. (See this ArsTechnica link for how to choose your filesystem)
Odd.
I then tried to partition the drive - and two partitions or more would all of a sudden work. Again odd, but I didn't want more than one partition in this case, but reverting back to one partition would cause the same problem all over again. I resorted to Google at this point and came across this very useful although somewhat poorly formatted post on Seagate forums. (seems to be a generic problem with disk utility)
http://forums.seagate.com/stx/board/message?board.id=freeagent&thread.id=1062
The gist of the problem being that the default partition table format needs to be changed to GUID. You can apparently only acheive this by partitioning (in this case to two partitions) so you can change the setting for partition table format and then partitioning again back to one partition with the new partition table format intact. Annoying but easily worked around once you stumble on the right answer.
Note this issue is actually new to 10.5.* and you can also solve the problem by formatting from an older version of Mac OS X (from a boot CD for example).
FlexBuilder 3 First Impressions
Where we're coming from
So at the beginning of the year I was tasked with evaluating a number of technologies for RIA development for the next evolution of my company's product. Up to this point we had been relying extensively on ASP.NET forms with a traditional post-back model that was responsible for a lot of wasted time and bandwidth. We've leveraged a lot of Ajax in the past few years, starting with simple fixes like trees and list based controls that use load on demand and going all the way up to full fledged single page applications that consumed purely services.
This has worked, but the cost is overwhelming for a development team of our size and makeup. We hire smart generalists for the most part, favoring developers with C++/Java/C# backgrounds. Some of our developers have acquired some deeper skills on the client side, but where possible we attempt to leverage control vendors like Telerik and ComponentArt as much as possible. They do an excellent job of hiding some of the complexity involved in cross browser web interfaces, but you will inevitably have to "hit the metal" and get your hands dirty. Relying on third parties also removes a lot of the control needed to do things the way you need them done. Regardless despite being a huge fan of the http://docs.google.com suite of tools, I have witnessed far too much ugliness in our organization with supporting multiple browsers (including having to support IE 6) and pushing the limits of complicated UI in the browser. As the size of the DOM increases and the size of our data sets increase we see wild variance in client performance with respect to things like drag and drop. I know it can be done, I know we are not at the limit yet, but seriously this is not pragmatic for our software and our market and our developers. I am a big fan of the view that JavaScript is becomming the assembly of the web, those who do this shit well, do it well by lifting themselves out of the muck with good abstractions like GWT.
One thing I think should add here in defense of Ajax though; UI design plays a really important role in the effectiveness of the DHTML approach and honestly I believe part of our problem has been designing a far richer interface than we could afford in the technology we were leveraging at the time. Take a close look at Google's lack of decoration, images etc. These things certainly matter.
Next steps... evaluation
Anyway, I'm getting off topic as usual. In the beginning of 2008 my feature matrix analysis really narrowed our options from about a dozen technologies (including XUL, ActiveX, Applets, JavaFX, Silverlight, ClickOnce, Ajax, Flex) down to three. Silverlight, Flex or Ajax. At the time of my evaluation Flex was at version 2, JavaFX was vapourware and Silverlight2 was in Beta. Given that we are a .NET shop and already have the C# programmers, the Silverlight option was looking like it was going to cleanly win out over Flex. Ajax was honestly only at the table still because we needed to justify our position and show we clearly evaluated all our options. Flex was seen as less desirable due to being based on ECMAScript and having to retool and retrain.
For the most part we've seen this as two relatively equivalent technologies with different stories for the developers. While there are important differences between how code is delivered and executed in Flex vs Silverlight, but at a high level we believe technically we can deliver our application in either technology very effectively. We prefer to keep working in C#, but the limited penetration of Silverlight is a serious risk for an application delivered in a SaaS model. That single fact has transformed the whole exercise into largely a business decision. I don't doubt Microsoft will be able to push their offering significantly, but I would not bet money on where they will be in 1 year. (Windows Media Player STILL doesn't equal flash in penetration)
Tool support however remains something that is extremely important to developers, and is one of those things Microsoft often trots out in arguing the superiority of their platform. We swallowed that line pretty easily at first, knowing that under the hood all the code written for Flex is just a variation of ECMAScript (JavaScript) is enough to scare us off. How can you acheive the refactorability and tool support provided by current and future versions of Visual Studio with a loosely typed language like ActionScript?
Trying it out
This week I downloaded FlexBuilder3 after one of our senior executives setup a call for us with Adobe evangelists to get more details on why to go with Flex. Again the motivation for this coming back to penetration and wanting to ensure we are making the right decision for what will become a million plus dollar iniitiave to re-engineer. I wanted to get some hands on time with the latest version of FlexBuilder (3) that had come out since our initial research.
I was immediately surprised by the leaps Flex had taken since I last really dived in. I'll admit there was some bias here though as I am also a huge fan of Eclipse, so the fact that FlexBuilder is built on Eclipse is in my mind a huge win. (not new btw)
The effort in actually building an application that connected to our existing .NET web services was embarrassingly trivial. FlexBuilder has a simple tool for generating and managing proxy classes to represent your web services. So after literally pasting a url into a wizard I had code for talking to our .NET SOAP based web services. (seemed to only support SOAP 1_0 not 1_2) I then got started with the Form Designer and had a simple application talking to our backend in under an hour even counting the little things that tripped me up like where to add my event handlers which wasn't immediately apparent. (too reliant on double clicking controls apparently ;-) hint : <mx:Script> tags and dom style event callouts)
The concept of states in Flex and the ease with which I was able to create a number of them in the designer and bind those to a dropdown for switching between them was pretty eye opening. A state in Flex is defined by the differences between your main UI (or just another state) and the state you wish to have/be in. The IDE allows you to visually manage these states and then visually modify each one to represent application states. I don't have an early sense of whether this actually scales for complex applications, but at first glance it's very cool. (Think hierarchical state machine) Couple this with the data binding model and you have some very effective UI management tools at your disposal. Maybe this only looks cool coming from our antiquated asp.net approaches, but this stuff is exciting. (Silverlight/WPF have the same capability, maybe even a little more advanced but with more overhead in my opinion) Having your model drive all changes is so much more manageable, scalable... and just correct than having explicit assignments in page PreRender methods that set visibility based on the state of that model. Barf.
The control toolkit out of the box with Flex is also extremely impressive. Check out this post for a list of all the FlexBuilder 3 Controls included out of the box . For now at least this control set will mean being highly more productive in the early stages of development than if we were either having to roll our own or rely on third party vendors. And of course you can roll your own in both Silverlight and Flex and each can be just about anything imaginable.
So I'm sold, at least sold on the fact that Flex deserves considerably more attention than what we had previously given it. I've bought the "Flex 3 Cookbook", and "Adobe Flex 3 Training From the Source" and I'm intending on spending at least some of this Christmas holiday catching up on just what's possible with that silly little flash technology.
So at the beginning of the year I was tasked with evaluating a number of technologies for RIA development for the next evolution of my company's product. Up to this point we had been relying extensively on ASP.NET forms with a traditional post-back model that was responsible for a lot of wasted time and bandwidth. We've leveraged a lot of Ajax in the past few years, starting with simple fixes like trees and list based controls that use load on demand and going all the way up to full fledged single page applications that consumed purely services.
This has worked, but the cost is overwhelming for a development team of our size and makeup. We hire smart generalists for the most part, favoring developers with C++/Java/C# backgrounds. Some of our developers have acquired some deeper skills on the client side, but where possible we attempt to leverage control vendors like Telerik and ComponentArt as much as possible. They do an excellent job of hiding some of the complexity involved in cross browser web interfaces, but you will inevitably have to "hit the metal" and get your hands dirty. Relying on third parties also removes a lot of the control needed to do things the way you need them done. Regardless despite being a huge fan of the http://docs.google.com suite of tools, I have witnessed far too much ugliness in our organization with supporting multiple browsers (including having to support IE 6) and pushing the limits of complicated UI in the browser. As the size of the DOM increases and the size of our data sets increase we see wild variance in client performance with respect to things like drag and drop. I know it can be done, I know we are not at the limit yet, but seriously this is not pragmatic for our software and our market and our developers. I am a big fan of the view that JavaScript is becomming the assembly of the web, those who do this shit well, do it well by lifting themselves out of the muck with good abstractions like GWT.
One thing I think should add here in defense of Ajax though; UI design plays a really important role in the effectiveness of the DHTML approach and honestly I believe part of our problem has been designing a far richer interface than we could afford in the technology we were leveraging at the time. Take a close look at Google's lack of decoration, images etc. These things certainly matter.
Next steps... evaluation
Anyway, I'm getting off topic as usual. In the beginning of 2008 my feature matrix analysis really narrowed our options from about a dozen technologies (including XUL, ActiveX, Applets, JavaFX, Silverlight, ClickOnce, Ajax, Flex) down to three. Silverlight, Flex or Ajax. At the time of my evaluation Flex was at version 2, JavaFX was vapourware and Silverlight2 was in Beta. Given that we are a .NET shop and already have the C# programmers, the Silverlight option was looking like it was going to cleanly win out over Flex. Ajax was honestly only at the table still because we needed to justify our position and show we clearly evaluated all our options. Flex was seen as less desirable due to being based on ECMAScript and having to retool and retrain.
For the most part we've seen this as two relatively equivalent technologies with different stories for the developers. While there are important differences between how code is delivered and executed in Flex vs Silverlight, but at a high level we believe technically we can deliver our application in either technology very effectively. We prefer to keep working in C#, but the limited penetration of Silverlight is a serious risk for an application delivered in a SaaS model. That single fact has transformed the whole exercise into largely a business decision. I don't doubt Microsoft will be able to push their offering significantly, but I would not bet money on where they will be in 1 year. (Windows Media Player STILL doesn't equal flash in penetration)
Tool support however remains something that is extremely important to developers, and is one of those things Microsoft often trots out in arguing the superiority of their platform. We swallowed that line pretty easily at first, knowing that under the hood all the code written for Flex is just a variation of ECMAScript (JavaScript) is enough to scare us off. How can you acheive the refactorability and tool support provided by current and future versions of Visual Studio with a loosely typed language like ActionScript?
Trying it out
This week I downloaded FlexBuilder3 after one of our senior executives setup a call for us with Adobe evangelists to get more details on why to go with Flex. Again the motivation for this coming back to penetration and wanting to ensure we are making the right decision for what will become a million plus dollar iniitiave to re-engineer. I wanted to get some hands on time with the latest version of FlexBuilder (3) that had come out since our initial research.
I was immediately surprised by the leaps Flex had taken since I last really dived in. I'll admit there was some bias here though as I am also a huge fan of Eclipse, so the fact that FlexBuilder is built on Eclipse is in my mind a huge win. (not new btw)
The effort in actually building an application that connected to our existing .NET web services was embarrassingly trivial. FlexBuilder has a simple tool for generating and managing proxy classes to represent your web services. So after literally pasting a url into a wizard I had code for talking to our .NET SOAP based web services. (seemed to only support SOAP 1_0 not 1_2) I then got started with the Form Designer and had a simple application talking to our backend in under an hour even counting the little things that tripped me up like where to add my event handlers which wasn't immediately apparent. (too reliant on double clicking controls apparently ;-) hint : <mx:Script> tags and dom style event callouts)
The concept of states in Flex and the ease with which I was able to create a number of them in the designer and bind those to a dropdown for switching between them was pretty eye opening. A state in Flex is defined by the differences between your main UI (or just another state) and the state you wish to have/be in. The IDE allows you to visually manage these states and then visually modify each one to represent application states. I don't have an early sense of whether this actually scales for complex applications, but at first glance it's very cool. (Think hierarchical state machine) Couple this with the data binding model and you have some very effective UI management tools at your disposal. Maybe this only looks cool coming from our antiquated asp.net approaches, but this stuff is exciting. (Silverlight/WPF have the same capability, maybe even a little more advanced but with more overhead in my opinion) Having your model drive all changes is so much more manageable, scalable... and just correct than having explicit assignments in page PreRender methods that set visibility based on the state of that model. Barf.
The control toolkit out of the box with Flex is also extremely impressive. Check out this post for a list of all the FlexBuilder 3 Controls included out of the box . For now at least this control set will mean being highly more productive in the early stages of development than if we were either having to roll our own or rely on third party vendors. And of course you can roll your own in both Silverlight and Flex and each can be just about anything imaginable.
So I'm sold, at least sold on the fact that Flex deserves considerably more attention than what we had previously given it. I've bought the "Flex 3 Cookbook", and "Adobe Flex 3 Training From the Source" and I'm intending on spending at least some of this Christmas holiday catching up on just what's possible with that silly little flash technology.
FlexBuilder 3 Controls
Controls included with FlexBuilder 3 out of the box below... check out some third party components here .
Notes will be updated as I actually get a chance to put some of these to use.
Notes will be updated as I actually get a chance to put some of these to use.
| FlexBuilder 3 Controls | |
|---|---|
| Control Name | Notes |
| AdvancedDataGrid | *Professional version only* + multi column sorting + grouping + tree view + printing support -- Still no paging support out of the box |
| AlertControl | not sure how this gets grouped with these other controls as it is not an explicit control but a static method "show()" which can be used from where ever. |
| Button | check out the FlexLib CanvasButton for a more flexible option |
| CheckBox | |
| ColorPicker | |
| ComboBox | |
| DataGrid | See this article for some hints on implementing paging |
| DateChooser | |
| DateField | |
| HSlider | |
| HorizontalList | |
| Image | |
| Label | |
| List | very fast and flexible, lots of issues with scrolling but workable |
| LinkButton | |
| NumericStepper |  |
| OLAPDataGrid | *Professional version only* |
| PopUpButton | |
| PopUpMenuButton | |
| ProgressBar | |
| RadioButton | |
| RadioButtonGroup | |
| Repeater | SLOOOW when binding to many objects, look at List based controls instead |
| RichTextEditor | Limited html formatting, seems to work ok |
| SWFLoader | |
| Text | |
| TextArea | |
| TextInput | |
| TileList | see list, very fast control but takes a bit more work for smooth work |
| Tree | |
| VSlider | |
| VideoDisplay | FLV based video player with simple cue and playback control |
| FlexBuilder 3 Chart Controls | |
| AreaChart | |
| BarChart | |
| BubbleChart | |
| CandleStickChart | |
| ColumnChart | |
| HLOCChart | |
| Legend | |
| LineChart | |
| PieChart | |
| PlotChart | |
| FlexBuilder 3 Navigation Controls | |
| Accordion | Great control, but needed to go custom almost immediately ( see FlexLib for custom header) |
| ButtonBar | |
| LinkBar | |
| Menu | |
| MenuBar | |
| TabBar | |
| TabNavigator | |
| ToggleButtonBar | |
| ViewStack | |
| FlexBuilder 3 Layout Controls | |
| ApplicationControlBar | |
| Canvas | |
| ControlBar | |
| Form | |
| FormHeading | |
| Grid | |
| HBox | |
| HDividedBox | |
| HRule | |
| ModuleLoader | not really a layout control? ModuleLoader allows you to load components of the application on demand, lowering initial download size and improving encapsulation |
| Panel | |
| Scrollbar | |
| Spacer | |
| Tile | |
| TitleWindow | |
| VBox | |
| VDividedBox | |
| VRule | |
visual c++ lesson 0.0.0.0.1 precompiled headers
I come from a background of managed memory and interpreted languages. I'm a big proponent of pragmatic approaches to problems and as little re-inventing of the wheel as humanly possible. I don't think the world needs another text editor, and I personally don't feel the need to write my own version of the stack I rely on for application development. (.NET Framework and IIS)
This however gives me less credibility with all those "real" programmers out there. The ones who read assembly for fun and don't believe in memory management or virtual runtimes/machines. I consistently find myself in battles with control freaks who argue that building an application on top of an application server like Tomcat or IIS is dangerous and excessive when it's so much simpler to just write your own daemon and connection handling.
Regardless. It is difficult to argue without having credible experience with the alternatives. Not only that, but a number of my dream jobs require extensive C/C++ knowledge (Google) and many important FOSS projects require the same. So I am finally diving in and (re-)learning some C++ with an initial task of writing an XML to ASN.1 converter. (don't ask why)
I'm doing this in visual studio 2008 with Visual C++, which as I'm learning has it's own learning associated with it. First is the question of ATL , MFC , WIN32 or just Blank. Visual studio doesn't give you a whole lot of background on why you might choose one or the other, but some simple wikipedia reading spelled out that for my project I wanted the simplest option. So I went ahead with Win32 Console as it seemed to have the least amount of overhead with easiest start.
From here I moved to some very simple HelloWorld love with some file IO. I've taken a course that used C for half of the assignments so I am not completely new to this, but I definitely needed a reminder. Here again I was presented with another option, stdio or iostream ? More wikipedia love, apparently stdio is the old C way of doing things and iostream is the new object oriented way of doing things. There seems to be a lot of contention still about when to use which when, but for my purposes the stream approach seemed more appropriate.
And include how?
#include "iostream"
//OR
#include <iostream>
//OR
#include <iostream.h>
Well visual studio doesn't allow the last one so that's easy. Using either of the first two work though works because using the double quotes option will check for an implementation defined location for the file before falling back to the same behavior provided by using the angle brackets. Ok, one more down.
Don't forget that in Visual C++ adding the above import does not explicitly import the associated namespace. So in order to actually use cin or cout you need to either prefix every instance with std::cin or use the statement "using namespace std;" in order to simply use those identifiers normally.
The next couple hours were learning how to create classes, use namespaces and some simple iterative build up of some basic classes to represent the document I needed to import. Still barely outside the realm of a hello world really.
Now, for this little project I am actually more interested in the ASN part of the problem than I am in the XML parsing so I looked for a parser. I came across the autumn project which references a parser written by Dr. Ir. Frank Vanden Berghen which was appealing as it was relatively small, portable and self contained. You can find the files here.
Now for the fun part. When attempting to compile my newly added class was throwing a dozen or so errors that didn't exactly make sense to me. I was prepared for some pretty ugly work in trying to port this thing from GCC to the Microsoft compiler, so I didn't really question these errors. To begin with it was mostly types that were missing. So I would search for the definition of that type and find it in a header file that I was sure was being included. At this point I naively began to move code around in an effort to understand the error. Moving one struct from the header to the cpp file seemed to resolve one error and cause a few more. This seemed to validate my guess that the header was somehow not being included. I had no expectation that this should just work out of the box of course though, so perhaps some of this code was just wrong. I started to chase down the parts of the code that were dependent on flags such as #ifdef WIN32 (I really like how visual studio grays out the code that will not be included based on those conditionals, very nice).
This went on for maybe an hour before I was convinced that this had to be easier. Looking more closely at the build output rather than the error log (which should always be done much sooner than this) revealed this warning :
1>c:\documents and settings\c\my documents\visual studio 2008\projects\xmltoasn\xmltoasn\xmlparser.cpp(82) : warning C4627: '#include <Windows.h>': skipped when looking for precompiled header use
1> Add directive to 'stdafx.h' or rebuild precompiled header
This is one of those steps where I know I should have asked more questions when I first started my project. The project by default included my "main" file, but it also included these two stdafx files (header and cpp) which I briefly looked at but didn't dig into. The comment at the top of stdafx.h shows this :
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
Which if you don't know what pre-compiled headers are may not make a ton of sense. And it sounds to me like this is optional in any case. Well, it isn't, at least not if you have the build options on your project set to use precompiled headers which by default I did. Simply adding "#include <windows.h>" to the stdafx.h file resolved all the problems. So in fact the xmlParser module WAS portable, and I just didn't have a clue.
The other way to solve this problem is to actually change the precompiled headers setting for your project to not use precompiled headers at all.
So this was a bit frustrating, but all in all a good first foray into this shit, and I'm at least a few steps closer to having a program that actually does something.
This however gives me less credibility with all those "real" programmers out there. The ones who read assembly for fun and don't believe in memory management or virtual runtimes/machines. I consistently find myself in battles with control freaks who argue that building an application on top of an application server like Tomcat or IIS is dangerous and excessive when it's so much simpler to just write your own daemon and connection handling.
Regardless. It is difficult to argue without having credible experience with the alternatives. Not only that, but a number of my dream jobs require extensive C/C++ knowledge (Google) and many important FOSS projects require the same. So I am finally diving in and (re-)learning some C++ with an initial task of writing an XML to ASN.1 converter. (don't ask why)
I'm doing this in visual studio 2008 with Visual C++, which as I'm learning has it's own learning associated with it. First is the question of ATL , MFC , WIN32 or just Blank. Visual studio doesn't give you a whole lot of background on why you might choose one or the other, but some simple wikipedia reading spelled out that for my project I wanted the simplest option. So I went ahead with Win32 Console as it seemed to have the least amount of overhead with easiest start.
(Why would anyone use the C++ CLR option?)
From here I moved to some very simple HelloWorld love with some file IO. I've taken a course that used C for half of the assignments so I am not completely new to this, but I definitely needed a reminder. Here again I was presented with another option, stdio or iostream ? More wikipedia love, apparently stdio is the old C way of doing things and iostream is the new object oriented way of doing things. There seems to be a lot of contention still about when to use which when, but for my purposes the stream approach seemed more appropriate.
And include how?
#include "iostream"
//OR
#include <iostream>
//OR
#include <iostream.h>
Well visual studio doesn't allow the last one so that's easy. Using either of the first two work though works because using the double quotes option will check for an implementation defined location for the file before falling back to the same behavior provided by using the angle brackets. Ok, one more down.
Don't forget that in Visual C++ adding the above import does not explicitly import the associated namespace. So in order to actually use cin or cout you need to either prefix every instance with std::cin or use the statement "using namespace std;" in order to simply use those identifiers normally.
The next couple hours were learning how to create classes, use namespaces and some simple iterative build up of some basic classes to represent the document I needed to import. Still barely outside the realm of a hello world really.
Now, for this little project I am actually more interested in the ASN part of the problem than I am in the XML parsing so I looked for a parser. I came across the autumn project which references a parser written by Dr. Ir. Frank Vanden Berghen which was appealing as it was relatively small, portable and self contained. You can find the files here.
Now for the fun part. When attempting to compile my newly added class was throwing a dozen or so errors that didn't exactly make sense to me. I was prepared for some pretty ugly work in trying to port this thing from GCC to the Microsoft compiler, so I didn't really question these errors. To begin with it was mostly types that were missing. So I would search for the definition of that type and find it in a header file that I was sure was being included. At this point I naively began to move code around in an effort to understand the error. Moving one struct from the header to the cpp file seemed to resolve one error and cause a few more. This seemed to validate my guess that the header was somehow not being included. I had no expectation that this should just work out of the box of course though, so perhaps some of this code was just wrong. I started to chase down the parts of the code that were dependent on flags such as #ifdef WIN32 (I really like how visual studio grays out the code that will not be included based on those conditionals, very nice).
This went on for maybe an hour before I was convinced that this had to be easier. Looking more closely at the build output rather than the error log (which should always be done much sooner than this) revealed this warning :
1>c:\documents and settings\c\my documents\visual studio 2008\projects\xmltoasn\xmltoasn\xmlparser.cpp(82) : warning C4627: '#include <Windows.h>': skipped when looking for precompiled header use
1> Add directive to 'stdafx.h' or rebuild precompiled header
This is one of those steps where I know I should have asked more questions when I first started my project. The project by default included my "main" file, but it also included these two stdafx files (header and cpp) which I briefly looked at but didn't dig into. The comment at the top of stdafx.h shows this :
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
Which if you don't know what pre-compiled headers are may not make a ton of sense. And it sounds to me like this is optional in any case. Well, it isn't, at least not if you have the build options on your project set to use precompiled headers which by default I did. Simply adding "#include <windows.h>" to the stdafx.h file resolved all the problems. So in fact the xmlParser module WAS portable, and I just didn't have a clue.
The other way to solve this problem is to actually change the precompiled headers setting for your project to not use precompiled headers at all.
So this was a bit frustrating, but all in all a good first foray into this shit, and I'm at least a few steps closer to having a program that actually does something.
ajax for mac lovers
Another Ajax Framework : (or rather, an Application Framework)
http://cappuccino.org/
http://cappuccino.org/learn/
Demo app built using it:
http://280slides.com/
http://cappuccino.org/
http://cappuccino.org/learn/
Demo app built using it:
http://280slides.com/
And a teaser for all those interface builder lovers out there :
I came across this in reader this morning and was totally blown away by how well the 280 slides application worked. It's really impressive... on non IE browsers. I sent the link to a co-worker to check out and he basically dismissed it as too slow and unresponsive, "typical web app". It took a minute or two to realize the browser was the problem at which point I launched the app in IE 8 Beta (IE 8!) and it performed terribly.It looked terrible, it was jerky and generally just a big let down after the speed of Chrome.
Whatever the technical reasons are, it sucks. Let's hope the new generation of javascript engines (FF3.1 and Chrome) are able to push Microsoft into stepping up. I'm excited about Flex and Silverlight and JavaFX but really I want to believe we can keep pushing the browser without the plugin.
Subscribe to:
Posts (Atom)