IE 6 became the defacto web browser years ago and then stood still. In that time, since it was released, we watched the rise of browsers such as Firefox, Safari, Opera, and now Chrome. These are browsers that have made a steady effort to meet web standards. The result? Internet Explorer, as a whole, has lost almost 50% of its market share.
Microsoft hasn’t stood still, they finally released IE 7 after it became clear that Firefox was eating their lunch, but IE 7 wasn’t good enough. Sure, it copied a bunch of features from the other browsers, but it did diddly-squat for web standards and people noticed. Thus, IE market share continued to erode. There’s a lesson in that: sites are getting sick and tired of having to put in a whole bunch of hacks just to make IE look and behave like every other browser on the market. This appears to be affecting the end user who are starting to see a substandard experience compared to the others and thus started to abandone ship.
Microsoft certainly noticed and has now released IE 8. Interface wise, it’s pretty similar to IE 7, but that’s the end of it. Finally, and it’s about time, Internet Explorer has become substantially more compliant to web standards. What this means, for the user that has been clinging to Internet Explorer, is that the excuses are done. If you don’t want move from Internet Explorer, that’s fine, but you had better damn well upgrade to the latest version and join the rest of us in the modern age.
That goes for IT people as well: get it done. The simple fact is, you guys are the single biggest reason IE 6 is even on the radar of web site development. Enough of it, you’ve had plenty of time to test and so your excuses are also done. I’m sure that I speak for every single web developer on the planet when I say that we’d like to give you a swift kick where it hurts the most because it hasn’t happened.
A little while ago, in a discussion with a co-worker, I was describing some of the quirks I’d discovered while playing around with managed C++ and coined the expression ‘C+-‘ for it. He got a pretty good laugh over it. It is, however, somewhat appropriate…
This is not an indepth review of the language, just a few small observations that I’ve come up with as I’ve been playing with it. There are a lot of good reviews out there and, in general, using Managed C++ is not a whole lot different than working with C# in the .NET environment.
- The only .NET language that can mix managed and unmanaged in the same code. This may not seem like a monster win, but it is. The .NET framework and C++ are very powerful and this combination gives you access to the classes in the framework while giving you the ability to go to as low a level as you need when performance is important. You can’t do that in C#, for example.
- Some of the common C++ coding errors are reduced or even eliminated. I do a lot of code reviews and one of the biggest things that keeps coming up is memory leakage. An awful lot of people forget to clean up memory when they’re done and, over time, that makes the software unstable. Managed C++ won’t eliminate this, but it reduces it. If you don’t think this is valuable, being an old-school C++ guy, then you should take it up with the C++ standards committee, a similar memory management model is slated for the next for revision of the standard.
- Some of the language semantics are weird. For example:
String^ a = gcnew String(); This gives you a “handle” to a string on the managed heap. This is compiler lazyness. There are two things that indicate that the object is on the managed heap: the ^ symbol instead of a * and the use of gcnew vs new when constructing the object. One of the two is needed, but both? After the object is created, either way, you’re going to use the same semantics in accessing their methods and members. Net effect, the compiler should be able to tell which heap has the object based on the use of ^ or the use of gcnew.
- No bitfields in a managed class or struct. Obviously you can work around this by making the bitfield unmanaged, but there is a cost associated with mixed code. More importantly, however, the implication of this lack is that your control over memory usage is massively reduced and memory control is a big feature in C++. Basically, your control over memory packing is non-existent.
- Visual Studio insists on sticking everything in the header. When I say everything, I mean everything. The project will get created with a .h and .cpp file, but the .cpp file is basically empty, containing only a #include for the header. This is simply for the compiler, everything else lands in the header file. Huh? I’m okay with simple methods being in the header, usually one liners, but massive methods are stuffed in there as well. If you’re like me, you’ll end up moving the code around, but be careful since that can mess up the IDE if you’re doing any Windows forms development.
- Visual Studio insists on sticking the visibility declaration (public, protected, private) on every entry. While it’s not a big deal, C++ is NOT C# and it just looks ugly. I end up cleaning this up, but it’s a pain. Generally, I end up avoiding the visual designer after the initial layout just to avoid this and the previous complaint.
I’m not quite the C++ purist as my aforementioned co-worker, so managed C++ (or C+- if you prefer) is not a language I’m going to avoid. There are some ups to it and some downs, but I’d rather use it than C# when it comes to .NET development. Anyways, these are just some minor thoughts that have come to me as I’ve worked with the environment, your mileage may vary.
If you’re looking at doing Windows forms development with managed C++, be careful with x64 vs x86 and third party libraries. A lot of control libraries are written in C#, which is fine, and are compiled for “Any CPU” allowing them to be used by 32-bit and 64-bit code in .NET, but not all are done that way. If the control is explicitly compiled for x64 it will be unusable in the forms designer. You can use it, but not by dragging it on to the form in the designer, it’ll throw an error. This is because Visual Studio is a 32-bit app and can’t work with visual controls explicitly targeted to the x64 CPU. Just an FYI.
I wasn’t totally clueless as to the basis of Flex, but what I didn’t know is that it had been opensourced by Adobe. Needless to say, that discovery prompted a discussion at work and we decided to move my current project from Flash to Flex. While this wasn’t a completely trivial task, it was quite simple and, two days later, it was done. More importantly, it was done in a basic text editor and that was the kicker. We have a Flash license, but that’s just it: a license. This makes it painful to assign work to different people on this project, so the beauty of Flex is that we don’t need a Flash development environment, the entire project is basically ActionScript and any old text editor will do (I personally use UltraEdit).
Net effect, I’m quite happy with the outcome, though the resulting SWF files are larger, even if you use the runtime shared libraries. However, my general opinion is that dialup users are already feeling the pains of long load times just about everywhere now, so a few extra kilobytes is really meaningless in that realm. After all, if you’re on dialup and you live someplace that has broadband, get a grip. So, yeah, expect a larger SWF and expect, if this is their first hit to a Flex application, an additional 500K hit as well. The dialup folks can go make dinner.
Along the lines of Flex, though, I have to say I’m much happier with it than with AS3 in Flash. The Flash stuff still had the baggage of the “movie” concept dragging around in it, but Flex discards that entirely. Oh yeah, you can still use it, but it’s not really the basis of Flex. I can see why my general readings on the subject show that longtime Flash folks are struggling and why software developers are saying it’s about time. Yep, it’s about time.
A couple of years ago, before Adobe bought Macromedia, I had an occaision to dip into some Flash development. As a software developer, the entire Flash environment was so alien that it was useless. The whole thing was predicated on a movie concept and was just awkward to write code for. Happily, I didn’t spend a lot of time with this and moved on to other things involving programming languages not writen by spastic artists.
Flash forward (yeah, yeah) to the present and I was asked to look into some Flash stuff for work. Needless to say, I wasn’t looking forward to this, but I fired up Adobe Flash CS3 and started doing some reading… I was surprised. Clearly the best thing that happened to Flash as a development platform was Adobe, it was significantly better put together, structured much more logically, and allowed me to totally ignore the whole movie concept.
This isn’t to say that Flash has shed all of its legacy, but its ActionScript 3 is light years ahead of the previous versions. Yeah, there’s some goofy things like not having the libraries in the class path by default, having to drag components onto the stage before you can use them, and the like, but it’s actually not pain-inducing like the previous versions were. I do have some suggestions for the next release, though:
- Fix the default class path. I shouldn’t have to dig around to figure out where it is in order to use the standard libraries supplied with the compiler.
- Don’t force me to add components to the stage to use them. It’s a library, if I reference it and use it, link it in with the compiler.
- Fix the action script editor for the frames so that it is integrated with the tabs for the actual flash and any external scripts. This is pretty annoying, to switch between I have to collapse the frame action script window, select the new tab, edit, and then to switch back select the flash instance tab and expand the action script window. Huh?
- The Java model of directories and file names matching the namespace and the class instance is retarded. If I have a package called “Grumpy” and a class called “Grump”, then the class has to be in a file called “Grump.as” in a directory called “Grumpy”. That’s directly a result of a lazy developer.
- Following on with the previous, let me define more than one public class in a file. Again, this is a retarded Java model, and is irritating.
I may expand the list a little more as time goes by, but nobody has the bandwidth to see my complaints about the previous versions of Flash, so this is an enormous improvement. Good work Adobe, now just make it better.
Find attached “Galleria” which is the gallery solution that I came up with. Some features:
- Drupal 5.x
- Thumbnail ribbon with image caching
- Image scaling
- Upload image files and zip files
- Comes with a block function to allow “last updated” or “last created” view of galleries
- Control over user content (in other words, you don’t have to let users create galleries)
- Uses Drupal content types for nodes, so hooked into the whole node system
- Sorting and captions
- Click viewing image to see original
- Filenames are retained
There are more features, so have a look at the initial sample gallery I uploaded. There’s probably the odd bug or two, but I tested it with IE 7 and Firefox 2. I’m upgrading my Mac, so Safari testing will follow.
If you want the module, it’s attached. The license is simple: do what you want with it and I’m not responsible for any problems resulting from the use of it. If that works for you, feel free to download. If you find any bugs and/or want to share enhancements to it, please drop a comment on this posting.