Today is a good day to code

The Future of The Internet May Not be HTML5

Posted: May 7th, 2010 | Author: | Filed under: CSS, JavaScript, Programming | Tags: , , , | 1 Comment »

A few days ago, Joe Hewitt wrote a Twitter tirade about how web development has been stifled by the glacial nature of innovation at the w3c which caused a lot of reactions across the web, even some from Google.  Joe Hewitt also quit developing for the iPhone because of the App Store’s policies.  I have been thinking for a while about this, and it is what makes me want to write a web browser.

I agree with Joe Hewitt about Cocoa, the framework is awesome, for someone who has been fighting browsers for control of the UI for years, it is like a breath of fresh air.  However, this is true for any native rendering solution.  It is part of what makes it hard for me to go back to developing web applications.  I like JavaScript, but HTML and CSS not so much.  Talking it over with friends, and thinking about it further, I think that HTML5 may be exactly the wrong direction for us to be taking the web in.  Before you click away, this is not some “Apple should allow flash” argument.  I am thinking about this on a deeper level, about the types of applications that we are making today on the web, and some of the issues we are bumping our heads against.

The web has been good at delivering applications with zero-install, as well as presenting formatted documents.  The latter is what HTML was designed for.  XHTML was created because HTML was overstepping its bounds.  Currently I believe, even though native developers tend to look down on web developers, that developing a web application is one of the single most difficult challenges for modern development.  There are multiple languages that one needs to master, each with a different metaphor, syntax, and implementation.  There is overlap between the languages.  There are latency issues, networking issues, lack of resources on the client, these are all incredibly difficult things to deal with in general even with native implementations, the problems with the web exacerbate these issues.

At the heart of the problem is that with native frameworks and systems, you expect for everything to be different as you move across platforms, business stakeholders have an appreciation that moving from a Windows app to a Mac app will be hard, and they will staff up and provide the appropriate resources to do that.  In truth, coding a cross-browser application is no easier, however the issue with web development is that it appears to be easier.  HTML looks like a ubiquitous rendering language, it appears as though it would work exactly the same across the board, but it doesn’t and it likely never will.  JavaScript appears to be the same language across the browsers, but nothing could be further from the truth, it performs, and behaves differently in each.  CSS seems like it would be identical since all browsers comprehend the same syntax, but the same style can appear vastly different across the browsers, and in some not appear at all.

That is the current situation, and we are pressing further into the problem instead of dealing with it.  My opinion is that HTML should be present in browsers as a legacy rendering system.  What I would like to see is a raw vector based rendering engine, similar to the canvas tag, as the browser view that will give me, as the remote agent, the size of the window and the capabilities of the browser, such as audio, OpenGL, Sound, DirectX, etc…  It should also tell me what the origin of the screen is, UL, UR, LL, LR so that I can give the correct rendering directives.  It should send me a list of the languages that are supported, or are enabled by the user, binary, javascript, ruby, python, etc…  Then the browser should progressively download the code and execute it as it receives complete instructions.  The binary stuff could be jitted using LLVM + an appropriate front end, and cached.  The memory addresses could be sandboxed and virtualized.  The user could set heap sizes for the amount of memory that the applications were allowed to use.  Google’s native client is a step in this direction, but it doesn’t go far enough.  Scripting language code could be executed pretty much as it is.  This would allow the frameworks to control everything about the experience, as opposed to the browsers.  Innovation could happen overnight, and browsers would be more responsible for enforcing security policies than rendering.

The benefits of this approach, full on applications could be developed as one stack and would appear on the client as the developer wished.  The performance would be insane, the execution environment would be simplified such that we could develop an adequate sandbox.  Authentication would be up to the developer and would be native, many of the security issues would go away.  One could code their application as code + data to render as pages easily.

What are the issues with this approach, no one has managed to build an adequate sandbox, however as we have seen JavaScript + HTML isn’t really a great sandbox either, there are tons of exploits out there.  The delay in downloading the initial code, although with progressive execution, this should be mitigated.  The biggest issue is lack of crawlability.  This is where XHTML 2.0 comes in.  If your content is available as resources through a service, instead of crawling your app, your content could be crawled.  This would dramatically improve the value of search engines.  If you give an appropriate resource id, the engine could point the user to a URI that would render the content in your application instead of raw, or the crawler could be an application that shows your data in a slightly different format.

I think that native jitted code + data mixed together are likely our future, especially watching how the App Store is taking off with consumers.  Even they seem to be choosing native applications delivered over the internet over web apps.  I think that this is a primitive method of what I am describing, but the benefits to the end user and for the user experience are clear.

Why I Decided to Raise the Price of Mides

Posted: February 13th, 2010 | Author: | Filed under: Apple, Cocoa, Companies, iPhone, mides, Objective-C, Programming | Tags: , , , , | No Comments »

A few days ago I completed an analysis of what my profit and loss looked like for both of my applications. What I discovered was very disturbing, or would be to any entrepreneur.

I have to date put around 200 hours of work into Mides and around 90 hours into CycleMetrics. So far I have made less than $2,000 total on either of them.

Part of this is my fault, I started out with something of a flawed concept with the design of Mides because I was in love with the idea of nested code, self closing tags, and closures. This ended up eating away almost all of the devices’ memory, and was so recursive as to be nearly unmaintainable.

So I killed my darlings, went in for a heavy refactoring of the code without nesting, and ended up with a pretty decent mobile IDE.

However, at what my hourly rate is at this point in my career, based on my salary plus benefits, I am as of now, with all of my original plus ongoing effort into the software, about $30,000 in the hole on Mides, and $10,800 in the hole on CycleMetrics.

When I launched my app, shortly after the app store launched, I thought that I would be able to make back my money in 2 years and get positive. It has been 2 years, and I’m nowhere near making my investment back.

This is mostly O.K. since I have an awesome job, and I’m not missing a house payment or anything, but I think it is unwise to basically give away software that you keep shelling out effort on. I can’t let it die either, that doesn’t make sense, I love the idea of programming on your mobile, and I love the idea of being able to code on the apple tablet even more.

I also hate ads, and don’t want to do the ad driven thing. So while I’m still subsidizing the hell out of Mides at $9.99, it isn’t the slap in the face that $4.99 was.

So as a result, I have decided on $9.99 for Mides. I am putting in a fair amount of work to get to the tablet in an intuitive and sane manner, I also have a bunch of features planned. Some of which have been suggested by the awesome community at, and others that fit in with my dream of Mides.

I am still not sure what I want to do about CycleMetrics, but I have some online features that should be able to drive more reveneue for me. I don’t want to go to ads, and I don’t want to lock users in or try to steal their personal info to try to make a buck on it. That just doesn’t jibe with my philosophy.

We’ll see if the market thinks Mides is worth $9.99. I still think it is worth way more, but that is because I see it as it will be, not as it is. If people don’t think it’s worth $9.99, then they will later, but I can’t promise to keep the price there as I struggle to make it my dream of a fully featured mobile development environment.

What if Apple’s Vision of a Modern Platform is Right?

Posted: February 8th, 2010 | Author: | Filed under: Apple, Cocoa, Companies, Google, iPhone, Microsoft, Objective-C, Programming | Tags: , , , | No Comments »

This past weekend, I was thinking more about the iPad.  One of the thoughts that kept coming back was about the iPhone / Cocoa Touch development ecosystem as a platform, and how that looks in comparison to existing platforms.  The conclusion that I came to was a bit disturbing to me as a developer concerning the future of application development in general.

It is somewhat useful to quickly recap the development environments of the past to contrast them to today.  First we need to talk about Microsoft and what a platform meant to them.  To Microsoft, the computer was a tool for technical users.  Even if their said goal was to put a computer on every desk, the engineers clearly have and had difficulty putting them into the place of their users.

As the computers’ abilities increased, so did their complexity, and the complexity of the OS.  Doing simple tasks like taking a piece of text from a word processing program and putting it into your spreadsheet program in DOS was mostly ridiculously complicated.  Windows made things a bit easier initially, but only for the most technical users.  Doing what should be mostly simple tasks were still difficult, DOS was still around and necessary to do many common tasks.  The thing booted from DOS which created no end of problems.  It just wasn’t an optimal solution for the mass of computer consumers out there.  This was evinced by a proliferation of “computer” classes which were supposed to take the burden of designing something that was easy off of the engineers who designed the system.  That it did, and they proceeded to make a system that was even more of a tangle.

For those who would say that the Macintosh is much easier, I take issue with the word “much.”  In reality Unix / Linux / Mac OS X.x is not terribly easy to use.  To someone who has a good understanding of the computer, and conventions it is much simpler and more straightforward to use and manage.  For a technical user Apple does a fantastic job of making most things that normal people want to do easy without preventing technical users from doing complicated things, but the underlying complexity is not without its cost to the typical end user.

Now, if you were designing a platform today, for millions of people worldwide, with different levels of technical ability, the issue of computer and operating system security looming large, and the ever increasing abilities developers have to make computers do insanely complex things in the blink of an eye, how would you develop it?  Would it be like Windows, putting the burden of learning, understanding, and protecting themselves on the user?  Would it be like Unix / Linux, putting the burden of everything on the user, but exposing incredible levels of customization to the user?

What you would do would depend on what your goal was, but if your goal was to provide the best possible user experience, you would likely ( I know that I would ) take it upon yourself to protect your users from viruses, phishing, hacking, malware, etc…  You would likely make it difficult or impossible for developers working on your platform to make choices that would negatively impact the usability of the platform.  You might choose a somewhat difficult language combination for development to make a barrier to entry for developers, to make sure that the developers that did create for your platform were of a caliber such that they could actually make compelling content for your devices.

You might establish a certification board of some sort to determine if the applications being developed for your platform met your requirements for ease of use, stability, and security.  You may come to the conclusion that the only way to enforce your vision of the platform and be the ultimate consumer advocate, you would have to make sure that every application went through this board before they were available on your platform.  Once available for your platform, you might make the installation and configuration experience as painless as possible for the user, even if it meant imposing further complexity of implementation on the developer.

Does any of this sound familiar.  When I went through, designing a platform as a consumer advocate, what I ended up with was pretty much like what Apple has for the iPhone / iPad / iPod Touch development environment.  With one exception, I was actually more stringent in that I wouldn’t allow wapletts ( web application applets ) on the platform.  I would require those developers to just build a web application customized for the experience.

The funniest thing, or strangest if you don’t like that colloquialism, was that designing the platform as a developer, it didn’t look anything like this, in fact, it looked much more like the development experience around Ubuntu linux.  Where I ended up is that perhaps as developers, we are heaping too much responsibility on the average user trying to use the platform.  I think that Apple has the right mix with the app store experience for the types of devices that are running the Cocoa Touch framework on Objective-C.

That being said.  I don’t like it.  However, I understand it, and the UX / UI Designer at my heart rejoices at the emergence of this paradigm, where the responsibility for security and workflow consistency are on the developer, not the user.  But the programmer in me rebels at having someone tell me how to design and implement what I want on my device.  Having someone lord over me as to what is an acceptable software application is irritating to say the least.  I think the UX designer, and consumer advocate in me wins, and there are platforms like Mac OS X that I can work on to satisfy the programmer urges in me.

I predict, however that Apple will do away with the use of the existing Mac OS X on the MacBook,the iMac, and the MacBook Air.  I think they will start running this Cocoa Touch OS with all of the restrictions and HIG guidelines as the iPhone.  I think that there will be an app store for these devices, and I think that it will be the only way to install software.  Seeing iWork on the iPad is the first example of the migration of Cocoa Touch to a full fledged computer operating system.

Apple will probably, keep the MacPro line and the MacBook Pro, perhaps adding an iMac Pro running Mac OS X.x in the way we have always come to expect it, and it will likely become even geekier than it already is.  The most floor slapping, hilarious thing is that Apple has come full-circle to an old Microsoft idea that was right on, however, big surprise, was improperly executed.

Originally Microsoft had its Windows Professional and Home lines, they had Windows 2000 for business and Windows 98 for home users.  The concept was that they wanted to have a much simpler OS for normal consumers and a much more complicated, and powerful, platform for businesses to use.  Apple has slightly turned this on its head, they, in my humble opinion, want to have a platform that is an awesome one for media consumers, and general consumers, and a platform for the programmer geeks that have made Apple what it is.  It is for that reason that I anticipate a iPad Pro soon after the launch of the iPad, perhaps even as soon as WWDC ’10.  The iPad Pro would likely run a Cocoa Touch OS that was less restricted, and more like Mac OS X.x.

Ultimately, I think Apple wants, and will make everyone happy, but we are at the beginning of this incredible consumer platform, and I think that for its stated goals, the App Store, the “awful policies,” et cetera, are the best possible way to get to it.  However, I think for its perception among geeks, Apple needs to communicate their strategy as soon as possible.  If they intend to make all of their devices like the iPod Touch, then we have a problem.  However, this is extremely unlikely.  I can’t wait until WWDC this year!

iPhone Codesign Error 2.2.1 Firmware

Posted: February 6th, 2009 | Author: | Filed under: Apple, Cocoa, Companies, iPhone, Objective-C, Programming | Tags: , , , , , , | No Comments »

I have an older project and have had my certificates expire. I spent a couple of days trying to figure out how to get the stupid thing to build. Then I found this blog:

Basically what it says to do is to go into the .xcodeproj file for your application, open the project.pbxproj and modify the PROVISIONING_PROFILE variables.

This didn’t work for me, but removing all of the key / value pairs did.

Mides and The PHP Interpreter

Posted: January 17th, 2009 | Author: | Filed under: mides, Uncategorized | Tags: , , , , , , , | No Comments »

Mides and The PHP Interpreter

I really want to put a PHP interpreter into Mides, the problem is my interpretation of the Ts & Cs of the App Store. It is my understanding that executing downloaded scripts is prohibited. To the best of my knowledge, downloading a bunch of PHP templates and running them through the interpreter runs afoul of that provision.

What that really means to me is that the dream that I had when I originally wrote Mides will be a long time coming. I think that with some competition, Apple will hopefully broaden the types of applications that are available in the app store. It would be fantastic if they allowed scripting languages to be included in apps. It would be awesome to have the ability to have ruby on the device, as well as PHP and Python. Really the only platform that I could put some sort of PHP interpreter onto would be Android, but for some reason I am just not super excited about it.

What I am super excited about is the Palm Pre. It looks sweet, oh well Mides fans, I guess we’ll just have to wait.

* 5/6/2009 – I am currently working on a Dalvik compatible compiler for PHP that will work on Android.  It is a bit harder than I thought, so we’ll see if I can get through it.  I looked at it on iPhone, and it still seems to be a no-go. *