Today is a good day to code

Why I Will Never Specialize

Posted: January 5th, 2009 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

Why I Will Never Specialize

Picture of IrvinI realized a few weeks ago that I had left behind the concept of being an expert in any particular language. Not that being an expert is all bad, however the pace of change in software development makes it impractical.

For a while now my interviewing ( candidates ) has changed to reflect that belief. I frequently get into constructive arguments with my hiring managers about the types of resumes they are sending to me to screen. The problem isn’t that they aren’t qualified, the problem that I see is that they are insanely qualified. Meaning that they have for example 20 years of Java or something with no hint of other languages, or techniques. I mean how many awesome programmers have you met that had never deployed their own PHP server, or their own tomcat server. How many programmers have had no experience with shell scripting.

Actually a red flag for me is someone who has never even looked at what Microsoft has to offer. I don’t use Microsoft technologies, but I have worked for companies where I did, and I stay as informed as possible about their various languages and APIs. The reason is because I am interested in programming, not in making a bunch of money ( even though that would be nice ) or finding a cush job to lounge in. I really want to understand what is happening inside of the compiler, etc…

I mean recently I started on a foray into what I thought was the V8 JavaScript engine, which is *MEGA COOL* by the way, but I found myself looking at the assembly language commands and thinking, hmmm… I want to understand that. So I started digging in, and now I think that assembly language is cool. Boy, I’m a long way from ColdFusion.

I don’t have anything against people who specialize in one language. That is the way people hire, the reqs always are asking for 10 years experience in Java or some truck like that. I would prefer the req say, and they do when I have control of them, 10 years of programming experience, which means you could be 18 or 75, its all the same to me. The best resumes are the ones where the person has just about every language, with one at around 8 to 10 years of experience, but lots of side projects in everything from lisp to sed and awk. It is probably hurting my chances of getting ahead in my career, but that doesn’t matter, that I won’t just stick to one thing, but I really want to understand this, I want to know how it all works, and I want to have a part in making it better.

It probably means that I am a freak.


Installing ColdFusion MX 7, and the Apache Connector on Leopard Server (10.5.5)

Posted: December 31st, 2008 | Author: | Filed under: Apple, ColdFusion, Companies, java, Programming, Uncategorized | Tags: , , , , , , , | No Comments »

Installing ColdFusion MX 7, and the Apache Connector on Leopard Server (10.5.5)

Picture of IrvinThis weekend, I spent an unpleasant 24 hours or so working on upgrading a client’s server to Leopard 10.5.5. The actual Leopard upgrade went pretty well on the G5 XServe. The secret to that was having a crossover cable, and knowing the specific RackMac system identifier to be able to get the IP address to SSH into. The problems started with ColdFusion.

Now I am going to rant. My client has an Enterprise license, so we aren’t running on some hacked up installation, we are running a major OS that has been on the market for about a year, it has been in the hands of developers for more than a year. That there isn’t a proper connector bundled with the installation is criminal. If I wanted to go hacking around inside of source code, building crap, I could run open source. Why did we pay so much money for this? I will not write any more private applications with ColdFusion. If a corporation wants me to build ColdFusion applications, I may, but only after I try to convince them to go with something that is more likely to be supported on UNIX / Mac OS X.

I mean, how long has Apache 2 64-bit been out there, this shouldn’t come as a surprise to Adobe. I can’t trust that they will support major platforms going into the future. This is because of one or both of two things. The first possibility is that Adobe doesn’t want to put money into ColdFusion because it is dead or dying, the second is that Adobe wants to force people to upgrade to ColdFusion 8 by any means necessary. What Adobe has done is to make me look bad in front of my clients for choosing a technology that was not supported. I have already begun to write my applications in RoR, now I am definitely going to write my applications in RoR. I am done. I could have made so much more money writing code instead of screwing around with compiler flags.

The problem is that I would expect to run into trouble installing or running my software when using OSS. That comes with the territory, but when you buy software and it claims to support the platform, one would reasonably assume that the platform would be fully and actively supported. Anyway, rant over.

Now I will show how I fixed the problem:

First:

If you have a standalone installation (the only one that works), you will need to start it by switching to your ColdFusion directory, if you followed the defaults, it will be /Applications/ColdFusionMX7/runtime/bin. You will need to issue the JRun command from here ./jrun -start coldfusion. This will work, if you try to start it any other way, you will get the THIS_PROCESS_HAS_FORKED errors.

If you have installed it in multi-server, you are screwed, I have not found any decent way to get this to work.

Second:

You should be able to get to the administrator on http://127.0.0.1:8500/CFIDE/Administrator/index.cfm. Then you will need to set up the connector, this was crazy. The solution I am about to post I found on Scott Pinkston’s blog. The post is called ColdFusion 8 Leopard with apache an answer for the rest of us. It is generally for CF 8, but it will work on ColdFusion MX 7.

Here are the steps from his blog:

go to terminal window.
cd /Applications/JRun4/lib
unzip -d src wsconfig.jar
cd src/connectors/src  

apxs -c -Wc,-arch -Wc,x86_64 -Wl,-arch -Wl,x86_64 -n jrun22
mod_jrun22.c jrun_maptable_impl.c jrun_property.c jrun_session.c
platform.c jrun_mutex.c jrun_proxy.c jrun_utils.c

apxs -i -n jrun22 -S LIBEXECDIR=/Applications/JRun4/lib/src/connectors/src/
mod_jrun22.la

strip mod_jrun22.so

Now run the connector configuration:
sudo java -jar /Applications/JRun4/lib/wsconfig.jar

After it finishes, run this command:
cp /Applications/JRun4/lib/src/connectors/src/mod_jrun22.so /Applications/JRun4/lib/wsconfig/1/mod_jrun22.so

sudo apachectl restart

The order of the files to be compiled is *IMPORTANT* I was working on a Dual-G5 2.3 GHz so my command was /usr/sbin/apxs -c -Wc,-arch -Wc,ppc64 -Wl,-arch -Wl,ppc64 -n jrun22 mod_jrun22.c jrun_maptable_impl.c jrun_property.c jrun_session.c platform.c jrun_mutex.c jrun_proxy.c jrun_utils.c.

You will get some warnings, you can ignore them. If you get an error saying something about functions that start with an underscore in your apache error logs, when you try to start it, you have the file names in the wrong order. If you see an error that says it found the module, and it is mach-o, but it is the wrong architecture, you are probably using -WI (I as in imitate) instead of Wl (l as in Larry).

Step 3:

Make sure to add the add handler to your httpd.conf. in the ifmodule for mod_jrun22.so. Mine did not install this by default, so my ColdFusion templates were coming up with the code showing up as plain text. Here is the default handler: AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf.

I hope this prevents anyone from going through the ridiculous configuration nightmare that I went through this weekend. I apologize for the rant, but I have some other cool projects that I would rather work on than spending forever hacking around with my application server.


What Does a Sun Bankruptcy do to Enterprise?

Posted: December 29th, 2008 | Author: | Filed under: Companies, java, Programming, Sun Microsystems, Uncategorized | Tags: , | No Comments »

What Does a Sun Bankruptcy do to Enterprise?

Picture of IrvinFor more than a few weeks now, I have been pondering some broad implications of companies that we all rely upon failing. Probably the grand-daddy of these is Sun Microsystems.

Normally I wouldn’t be concerned about tech companies going away. It is part of the normal advancement of the art, but in Sun’s case, it does concern me. While I don’t share many developers’ blind love of Java, or Solaris, or any product really. I do feel that Sun has given a tremendous amount to the software engineering community and would be sorely missed if they were to go belly up. At the time of my writing this, Sun’s stock is at $3.41 per share, and their market capitalization is 2.52 Billion, less than Sun has on hand in cash.

I don’t necessarily think that Sun is in financial trouble, but it does seem that there are a bunch of products that they release that are mostly not for pay. Not to mention that their financial performance may / should, be giving some corporate IT departments pause as to their dependence on their technologies. Many companies rely on support from Sun, and if that were to transition to the community, the level of response may not be sufficient. The question I would ask is, “Will a Sun Bankruptcy Drive Corporations Back to Microsoft?”

Unfortunately, I can’t see any other alternative at the moment. There are millions of lines of code out there written against the Sun JVM, and while the JVM is now mostly open source, and so is Solaris, the companies that count on those lines of code typically are not interested in maintaining that code as well. Without Sun, you could have JVM forking, Solaris forking, etc… where a particular application written against Java or Solaris may not run in a given company. Corporations would have none of these problems if they used the .net stack for application development.

Now, I am not advocating that all corporations out there should drop their Sun implementations and run to Microsoft, but what I am saying is that they should prepare themselves for a little instability. I tend to use Ruby and the Rails framework for most everything anymore, but I have come to be somewhat skeptical of the gems that I am using. I am also aware that there is currently no support beyond community support for most of these items, and the developers working on them could get bored and go away. So for functionality that is more than a nice-to-have, I tend to write it myself.

Hopefully this will go away when we start to see professional gem houses, but in the near term, I would hope that companies would begin to diversify their stack a bit so as to mitigate the cost, such as re-engineering their non-core systems to be less dependent on core software from a particular vendor. The last thing you would want would be to find a showstopper bug in something you were about to release that was based on a technology from a shaky vendor, that holds up your business process.

Most good IT shops already support a variety of technologies so as to not be locked in to any one particular implementation from any given vendor, but enterprise developers should not continue to believe that Sun or Java will be around forever in its current enterprise-blessed, no-brainer form. I think serious unbiased evaluation of technologies to be included in future products should gradually become the norm. If Microsoft wins, so-be it, there is some good stuff in .net, but I would hope that Ruby and PHP would benefit from this situation.


JavaScript and Object Oriented Programming

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

JavaScript and Object Oriented Programming

Picture of IrvinFor some time now I have advocated using what I, for lack of a better term, call object oriented style coding when approaching JavaScript. Recently, Joseph Smarr talks about some of the challenges faced by developers who try to do too much with JavaScript. He brings up some good points, I'd like to discuss some of his findings, and add a few that were left out.

He talks about every line having a cost with JavaScript and being brief when writing it. I would go along with that, with the caveat that if you are writing something with JavaScript's condensed notation and no one including yourself will be able to understand it in a year, you should probably go ahead and write it out longhand with comments, whether you leave the comments in when you release it is up to you, but I think the extra cost in performance is worth clarity.

You have to be willing to not make an object out of everything. In lots of ways, we have to “kill our darlings” to borrow a literary term, in that you have to be willing to break encapsulation, destroy design patterns, and do some hacking for performance. It is important to remember that with languages people typically use OO for, the compiler will take out redundant statements, and optimize away some of the things you have done to maintain sane code. With scripting languages, especially JavaScript, we don't have that luxury. That elegant factory pattern that looks so good in the code may, and probably will fall apart as far as execution performance. Unfortunately, many developers will not compromise the ideals they have been taught once they reach this point. So we end up with slow performing UIs that could be fast.

One thing that Joseph Smarr doesn't talk about is taking a hard look at what really needs to be done on the client. It is critical, when profiling to determine if the speed of a round-trip to the server is worse than the performance of your code against the client. It is important to think about ways in which the beefy server can do some processing. As sexy as a fully SOA is, if it performs like a dog, no one is going to care what the technology is behind it.

Many of the best developers refuse to work with JavaScript because of these things, and it is a shame because I think these are the people who are best in a position to change some of the negative aspects of the language. Also, writing procedural code forces some efficiency while OO seems to allow just about anything. If you can't handle the prospect of writing JavaScript, try C, not C++ it is the same sort of thing.


JoostBook – Joost to Facebook Interface Widget

Posted: December 31st, 1969 | Author: | Filed under: java, JavaScript, Programming, Uncategorized | Tags: , , , | No Comments »

JoostBook – Joost to Facebook Interface Widget

Picture of IrvinSince I'm in love with Joost, I have been thinking about good applications that I could write for the platform. Before I get into talking about the widget / plugin, let me just say that the experience I have had with communicating with the Joost engineers, through their joost-dev google group, as well as them allowing early access to their SDK, has been outstanding. I have rarely come across a more open and generous group. Typically, the SDK guardians are very selfish about discussing future features, and are usually quite arrogant about the possibility of a developer finding an undiscovered bug. None of this has been the case with the Joost SDK staff.

If you don't want to read the details about how I built it, and you just want to use it, you can get it here: JoostBook: Joost / Facebook Interface. You will need Joost, and a facebook account to get started.

Now, about the widget. Firstly, the installation is a little wierd because of the level of control facebook insists on. In order to use the SDK, you have to authenticate, if an unauthenticated request is made, the response is with the facebook login page. This makes for some unique error catching conditions.

Secondly, we web developers often take for granted that the DOM will have a listener attached to it, and will automatically refresh if anything in the DOM changes. Well, I know that the Joost engineers are working on it, but it doesn't refresh, and therefore, while you can create new XHTML elements, as well as modify the ones that are there with JavaScript. You are best off currently just hardcoding all of your objects up-front, and changing their contents. Also, injecting XHTML using innerHTML doesn't really work so well currently either. I'd suspect that much of this is because there is a bridge between the 2D world of XULRunner / Mozilla, and the 3D world of the Joost interface. I'm sure there is a lot of complexity between the two.

So basically, once you have downloaded Joost, and installed the plugin, the first thing I had to do was check for if you are logged in, if you aren't logged in, it has to show you the facebook login page in an iframe so that the XULRunner browser can be cookied. After that, the widget should work like one would expect. You may have to log in alot, and if you aren't logged in, obviously the application can't update the JoostBook facebook application.

Writing the Joost plugin was the easy part, getting the facebook stuff to work was the hard part. Most of it was because the error handling is terrible. Since facebook doesn't allow you to see the 500 errors that your server is throwing, and it doesn't log it, you have to find other ways to check to see if your server is behaving properly. I spent a lot of time in my logs checking for errors.

The install process is a little wierd too, for example, in Firefox 2.0.0.8 on Windows XP, when I clicked on the Joda file linked in the page, it tried to open it as if it were some kind of markup file, obviously the joda looked like garbage, I had to right click and save. Perhaps if I had used a joost:// link it would have worked OK, but I think more research is in order. I didn't really try it in IE because most of the readers of this blog use Firefox, but it should work the same way.

Then having to install the application in facebook can be a little difficult as well. Well, the installation isn't difficult, its the concept that you have to install two applications that work together that is hard. At least there is no particular order in which you need to install them, worst case whenever you run the JoostBook plugin in Joost, it'll show you the facebook login page all the time.

At any rate, it was a fun experience, and I still think the guys at Joost are on to something. I'm slightly less psyched about the facebook platform, but I'm still excited about it.


WebKit Nightlies With Local Storage and Wild CSS Functionality

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

WebKit Nightlies With Local Storage and Wild CSS Functionality

Picture of IrvinMy head is still spinning after downloading the WebKit nightlies and messing around with the local SQL Lite storage, and the css animation and transitions. Man, this stuff has my head swimming with the possibilities for interesting applications.

More importantly, when is this going to make its way to the iPhone. I hope we don't have to wait for Apple's next big cat to be released for us to get some of these features. I know the SQL Lite access is really early, and also that most of these features are HTML 5 things being given to us early by the webkit staff, but for early features, they sure are pretty complete looking at first glance.

I don't know what the what3g is in an uproar about, with Apple starting work on HTML 5 in their browser. To me it looks like innovation. It isn't always tidy, but it is always welcome. I haven't been this excited about the web since gmail hit and AJAX started taking over!

Anyway, please check out the nightlies at: WebKit Nightlies I am not sure if it will work with PC Safari, I think those are earlier builds, but if you have a Mac, have a field day. Also, check out Drosera, the JavaScript debugger, and the Web Inspector in the debug menu, if you are using databases, you can check out the contents with that. Boy Safari has come a long way in a short time. I think the battle will definitely be WebKit and Mozilla, I wonder what Firefox is going to come back with. The new WebKit stuff is really strong.


Coding Using Mides the PHP IDE for iPhone

Posted: December 31st, 1969 | Author: | Filed under: iPhone, java, mides, Programming, Uncategorized | Tags: , | No Comments »

Coding Using Mides the PHP IDE for iPhone

Picture of IrvinSo I have been checking out twitter, and it seems that people think that I am either crazy or sadistic for writing Mides so that one could code using PHP, JavaScript, and HTML on iPhone. The truth is that I am neither, well perhaps a little crazy.

What made me write it is that I was thinking it would be awesome if I could work on my sites on the iPhone. Everyone has downtime every once and a while where you wish you could do a little work. Mides does that for me. Working on projects here and there, it is amazing how much one can get done.

The way I came up with it was actually working in NetBeans and playing around with the code-collapse. That started the thought process that lead to the code collapsing metaphor present in Mides. I know that some hate it, and others love it, but for me it seemed to be a quick easy way to drill down into your code. Also, an additional benefit was that it allowed me to focus on the class, function, or loop that I was writing.

To me, the keyboard has never really been too much of an obstacle. I understand that for others it can be a problem, but having had my iPhone since it came out, the last time I thought about the keyboard was about two weeks after I had bought it. I really wanted a flexible bluetooth keyboard for blogging from the phone, but later I really didn't need it.

While not perfect, the code completion does help a lot, and once you get used to it writing markup can be really quick. I will keep working on ways, other than the ones already present, to allow Mides to accelerate text entry.

Some of the things that frustrate me while using it, even though I wrote it, are that I can't easily look up reference material on code that I am writing without leaving the code. Clearly copy and paste would be nice, and I wouldn't be surprised to see it in a subsequent release. The ability to debug JavaScript, and a real HTTP server running locally would be awesome, to help with resolving absolute paths. Ideally, I'd be able to process PHP directly on the iPhone, but that is complicated for a number of reasons.

Many of these features will be coming, but actually most of the effort has gone into thinking about how to achieve the complexity of a full modern IDE, while keeping the UI cluttered. I feel that I have succeeded in many places, where others need work. It is my aim, however insane, to build Mides into as feature complete an IDE as is possible given the hardware and software stack provided by Apple.

I used Mides to build the mides site, including all of the canvas tag work. I think I only did about 5% of the coding on the Mac. There were some interesting incidents working with alpha quality code trying to build a site on the iPhone.

Well, feedback is always welcome, and I am not above listening to rational criticism. I want Mides to be useful to everyone, and am looking forward to the day when I can do just about all of my work from my phone!


HTML 5 Simplification: Fixing HTML by Douglas Crockford Response

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

HTML 5 Simplification: Fixing HTML by Douglas Crockford Response

Picture of IrvinIn almost every way I agree with Douglas Crokford's Fixing HTML. I think in many ways, XHTML has started to take us down the wrong path. CSS was great, but it is now rapidly becoming a mess, largely unusable for anyone except experts. HTML is the same way. This becomes rapidly evident when you start trying to create a browser.

I really love the idea that we can abolish doctypes. They are arguably the most misunderstood element of HTML, and quite probably XML for that matter. That the browser should be responsible for determing if the markup matches a doctype element, after having to fix unclosed tags and improper syntax is part of what leads browsers to be so complex, error prone, and vulnerable to attack.

The best part of giving the html tag a version number, in Douglas' proposal is that no longer do browsers have to figure out what version of html you are coding for by looking at the doctype and your markup. If you tell it your page is html version=”5″ then if it doesn't conform, it shouldn't render. There would need to be more robust built-in error checking and descriptive error messages in browsers, but for the most part, this should be in there anyway.

Having only one scripting language allowed on a page is just common sense, I suppose there could be a justifiable business case for using more than one, but in almost all day to day use it is not practical and should not be supported.

JavaScript should never execute before the page has finished rendering. I can agree with processing scripts included in the head once the /head is encountered, partially. I don't think any scripts should be executed until everything has rendered. I know that this may limit the flexibility of designing pages where the JavaScript creates elements without explicitly calling an “init” method at the bottom of the page, but this is really, IMHO, the proper way to kick off your scripts.

There should definitely be no more document.write, and no more javascript:// urls. That was always just terrible, and allows for easy scripting attacks.

Largely, the changes that Douglas Crockford proposes for the script elements in HTML will result in faster more scalable JavaScript. If the browser always processes the scripts in the same way, and doesn't have to worry about processing the script elements at the same time as it is rendering the DOM, the execution of the script will be more predictable, and the page more robust.

Clearly frames, framesets, and iframes have to go. Although it would be nice if they are removed, to allow for, either the browser treating XHRs and scripted DOM changes as though they were page refreshes to maintain the back button's functionality, or give the scripting language a safe API to handle the back button press in the browser. The module tag that is proposed could easily replace the functionality lost by removing the frame metaphor.

I totally agree with him on the need for CSS content to be standardized, but I think that by allowing scripts to grab document elements by their CSS selectors, as well as improving encoding, the application of CSS can be cleaned up fairly nicely. CSS 3 and its support for namespaces could simplify the application of CSS as well, but the trick is to get all of the major browsers to support it.

I don't agree about empty tags, I think that they should be required to self-close. In writing browsers, it would allow standard DOM parsers to be used to process the markup instead of having to go through the document, close the tags, and then feed it to the DOM parser. Doing this in Java, even with JTidy, as fast as it is, still has too much cost relative to the benefit of just self-closing the tags.

Custom tags and custom attributes are a must. CSS is robust enough now to fully control how the item displays, whether it is a block element, or inline, etc… I worry a little about overuse of these things, and how to enforce they not interfere with microformats, etc… but in general I think that allowing flexibility as long as the custom tags and attributes meet the requirements of HTML should be OK.

Originally I was really in the XHTML 2.0 camp, but I can see the need for more robustness in the basic markup tags than can be allowed in XHTML. HTML blows up the encapsulation of data, logic, and presentation in many ways, but it needs to remain and become an easy way for relatively un-expert individuals to create rich pages. It is currently far too complicated, and the proposed methods of handling mixed HTML 5 / 4 / XHTML pages sound scary and prone to exploits. I hope this little treatise doesn't fall on deaf ears. Are you listening what3g?


The Web as Google”s Data Source

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

The Web as Google's Data Source

Picture of IrvinOne of the things that Google is doing to the web is that it is, I believe by design, deterring individuals from doing things that make the presentation layer richer. The method by which they crawl and index pages leaves out Flash and AJAX content entirely. When a company that bases their revenue on pageviews and or visits is designing a web property, doing an all AJAX / Flash / Silverlight / etc… implementation of the interface is often swept off the table because Google and other search engines can't crawl it. It makes more sense for these companies, financially, to do a tidy looking crawlable interface.

The interesting thing about doing a “SEO friendly” interface is that it often isn't the best from an architectural perspective since your presentation and business logic are tied up in your controller. Technically speaking, you can't change one without the other changing on the application server. I talked about this a while ago in an article discussing the MVC pattern and application servers. Instead what you get, minus any JavaScript and CSS, is a nicely formatted, structured document, ready for ingestion into a massive database, i.e. Google's, and presented through a much nicer UI, i.e. Google's.

When looked at this way, it becomes apparent what the future of the web looks like. At first I was against things like AppEngine and doing SEO based pages until I realized that much of what is happening around us, RSS readers, and the like, are really interfaces that aggregate web content and taylor it to the way I want to see it in an often native interface. When you imagine the web as a massive data source you begin to understand the need to impose formatting rules on the interfaces. Not that crawling AJAX sites wouldn't be a daunting task, but with Google's technology, they could accomplish it, but I don't think it would be in their best interest.

If Google can get everyone to insert their content into the App Engine, then it saves them a step because your content would be inserted directly in their database, no need to crawl. Then Google could create optimized mashups of your content with other content to create superior applications. Anyone using AppEngine, or anything of the sort has to be aware that this is a possibility. If they want to control the creation of mashups, they should not use it.

My recommendation to build a future-proof site would be to build a clean simple version for the web, per Google's guidelines, and then build a desktop and mobile version that can digest your content and present it in a more flexible way. This may change as runtime web scripting languages become more powerful, but in some ways I think that we would be worse off without Google's webmaster guidelines. The web as a data source is a powerful concept, one that I'm sure is not lost on Google, or Vint Cerf. I just don't know how much that concept jives with the way people currently think of the web as a platform.


Do We Really Want Flash for the iPhone

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

Do We Really Want Flash for the iPhone

Picture of IrvinI've been thinking about this for a while now, and I believe, I'm still not 100% sure, that I do not want flash on the iPhone. This is not because I don't like flash, it is more because I have seen what JavaScript does to the CPU of the iPhone, and I have also seen my iPhone rarely exceed 60Kbps. I don't want my iPhone downloading flash ads that prevent the rest of the page from loading, or tie up my CPU, or make navigation difficult.

The bigger issue is do we really need flash on the iPhone with the canvas tag, SVG, the techniques collectively known as AJAX, QuickTime, MP3, and AAC support? I'd argue that I do not. I like flash, but as with anything it is being misused to put questionable ads on sites, and I normally don't mind too much until it starts slowing down my browsing. If EDGE were 3 Mbps then it still wouldn't be too big a deal, but as it is I think I'll pass on flash for now.