Bugs Are In The Eye of the Beholder

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!

Google search and Web Edition

If you use Real Studio Web Edition right now the contents of your app are invisible to Google. I think a lot of people are using WE for internal projects or for apps that need a user to log in before anything useful is available. This isn’t a problem for that kind of project but for some web apps it would be nice to have certain areas show up in Google’s search results.

This isn’t just an issue with WE, other AJAX based web apps have the same type of issue and Google has a document that describes how to make AJAX web apps crawlable:
http://code.google.com/web/ajaxcrawling/

The basic idea is that you have special hash tags for the parts of the your app that should be indexed. When Google sees those it asks your app for snapshot of what the app would look like after the JavaScript has been evaluated.

One approach that Google suggests for getting snapshots is to use something like HtmlUnit. HtmlUnit is a program that acts like a web browser but doesn’t have a user interface. It executes JavaScript just like a browser would and then you can extract the contents of the page.

I did a little bit of experimentation and found that this approach works for simple cases. I ran into a some problems with a real application but they probably have solutions. It seems like the best solution, though, is for WE to support Google’s approach itself. I’ve created a feedback report requesting this as a feature.

If there are parts of your app that could serve as entry points and you want to be able to drive search engine traffic to them, please sign to this report:
feedback://showreport?report_id=19412

Malformed Header Error?

I know that some people are having problems getting R2 Web Edition web apps to run.  I was having the same problem on a few of the more complicated apps I’ve been working on and what made it frustrating was that locally, on my Mac, they ran fine in debug and in as regular web apps.  But on two separate Linux servers (one in CentOS and the other is unknown) they crashed.  I dug into the Error Logs on the servers and kept running across lines like this:

Malformed header from script. Bad header=App.Open

What was in my open event?  Well, I was connecting to the database and upon success opening  a web page and that’s it.  Simple, right?

I was also doing some logging and was calling a method called PrintAndLog which would append whatever string I passed in to a log file and it would send the same message to the console via the Print command.

After much tearing out of hair (and those that know me surely will recognize that I’ve done this a lot!) I commented out ALL the code in App.Open and ran it on the server.  It worked!  So I then started uncommenting code line by line.  Eventually I got to the PrintAndLog call and sure enough that was it.

I then did the same thing in the PrintAndLog method and discovered it was the very first line in the method:

print s

Crazy huh?  Comment out that line and it works again.  What makes it weird is that I’ve used this in multiple places AFTER app.open and it works fine.  So I can only conclude that it has something to do with the application initializing and that print isn’t recommended at that point in time.

Yeah, I agree, it’s a stretch but stranger things have happened. This has been reported <feedback://showreport?report_id=17388> with an example project (the project is private, sorry).  Oh, and this still happens in the R3 beta’s.

So hopefully this might help someone in a similar predicament.

Finally!

Real Software today announced in their monthly newsletter the public availability of a Web Edition web app that can be launched on their website.  The link is http://demos.realsoftware.com/cgi-bin/orders/orders.cgi and you get get the source code for the project as well.

This is a decent example of what Web Edition can do for you.  It’s a fairly vanilla application but it’s something to look at and kick the tires of, so to say.  It’s nice to see it finally up as it was exposed to the beta list for a while.

I’ve been using Web Edition for real world projects since last November.  I think if they had developed this app back in November it would be a much more stable and mature product than it has been.

I hope that this is just the first of many such web apps that showcase the product.  Your thoughts?

Web Edition Question

Real Studio Web Edition has been around for roughly 6 months and 4 (or it is 5?) general releases.  Does anyone find it disconcerting and disappointing that Real Software does not have a SINGLE web app running on their website?

For desktop apps they can point to the IDE itself as what you can do with the product.  Web Edition needs examples, working, on their website, that do something.  If they really want to get people to buy their product the really need to have working examples.

What say you?

Real Studio Download Thoughts

You can file this one in the “Bob was bored and had a wild/random thought” category.  🙂

The Real Studio download package comes with several hundred example projects.  These examples range from very useful to downright useless (in my opinion) but they’re there for people to explore and use.  So in other words, the example may or may not be all that helpful depending upon your skill level.

So my question of the day is why are these part of the download package/installer and not available in a special section of the Real Software website?  It would save on download sizes and it would become a centralized location for Real Studio examples.  Ideally, anyone could contribute to this list.

When we started ARBP and added the Source Code Repository, this was the intention.  I wanted it to be the Planet Source Code of Real Studio projects.  The ARBP source code repository has over a hundred projects and gets a fair amount of traffic and downloads.  The drawback is that few people contributed to it and the older projects are really showing their age.  The other drawback is that it’s NOT Real Software and despite only needing an account to use it a lot of people shy away.

The leading argument against such a page on Real Software’s website are the Real Studio users themselves.  There is a tendency for Real Studio users to complain (loudly) when the examples don’t work.  They are justified, in my opinion, since examples in the download package should work with the version of Real Studio in the download package.  To me, if it’s in the download package it implies that it works implicitly with that version of Real Studio.  Unfortunately, that’s not how it works and sometimes leaves new users with a bad taste in their mouths.

A projects repository web page doesn’t have this problem as the person uploading the project sets the version of Real Studio it was created with and perhaps what operating system and adds some tags to it or something like that.  How cool would it be to upload the project file(s), have an RS web app scan it, pull out the keywords and make it part of a searchable system?  Of course it would allow other users to vote and leave comments.

I post a fair bit in the Real Software forums.  Often times I point to the relevant information the poster needs in the Real Software wiki or to various 3rd party developer websites.  I could see a projects page doing something similar and allow me to link to the project that would help the poster out.

Another thought would be to make this a Web Edition application since essentially we’re talking about a web app that’s a front end to a database.  Perfect place for a WE we app in my opinion.

Could ARBP do this?  Of course they could and it was discussed, in-depth, at the Atlanta conference in March.  They could do it – I have no doubt since they have some pretty smart people in ARBP – I just don’t think ARBP should be the one doing it.  I’m arguing that Real Software is a better and more logical entity to host this thing.

The Real Studio community isn’t as large as Visual Basic – that’s just simple math.  You could argue that a mere percentage or two of users would ever contribute to the projects page and that probably true.  However, assuming that Real Software sticks around for a few more decades, I would argue that one contribution a month is more than what we have now and more examples are better.

What say you?

WebContainer Different in R2

I noticed another significant change in Web Apps in 2011 R2 this morning while updating another Web Edition video training project.  It appears that WebContainers don’t behave the same as they did in R1 (and earlier).  For some reason, WebImageViews aren’t redrawing properly.  See example URL’s:

R1:  http://www.bkeeney.com/apps/WebContainerR1/webcontainerr1.cgi

R2:  http://www.bkeeney.com/apps/WebContainer/webcontainer.cgi

I’ve tried a variety of ways to get it to refresh by moving things around in the shown vs the open even to no avail.  This significantly reduces the usefulness of WebContainers.

I have reported this in case 17414 with example project.  Unfortunately it added it as private so you can’t view it.

Web Edition R2 Tip

I updated a good portion of my Web Edition training apps tonight to 2011 R2 and discovered something new (after banging my head up against the wall for several hours).  It seems that in R2, using the Application Identifier property is not only a good idea, but a necessity if you have have multiple web apps running.

What happens if you don’t have the Application Identifier property set?  Your first app will start just fine.  But subsequent apps will fail.  I finally figured that out after looking at my server log and seeing entries like this:

malformed header from script. Bad header=Another instance of com.yourco: myapp, referer: http://www.bkeeney.com/realbasic-training-section

Once I recompiled the apps with unique app identifiers they loaded no problem.  So the lesson is to make sure you have unique identifiers for all of your Web Edition apps.

Hopefully this saves you some time (and a bit of skin).  And maybe it will solve a mystery for you.

R2 WE Woes Solved

My post yesterday described the issues I was having getting a fairly simple WE app running on my Debian based web server.  The issue appears to have been a Print statement in the App.Open event.  Technically I was calling a method that did both a print and logged it to a local file as well, but the end result is that the print statement itself was the issue.

Once I got rid of the print statement, the app ran fine.  Why this was causing an issue I have no idea as I was doing pretty much the same thing in R1 apps.  Using the print statement elsewhere in the app is also no problem so this bug appears to manifest itself only in the app.open event.

The feedback ID, in case you are interested is <feedback://showreport?report_id=17388>

Hopefully this saves you a little bit of time.

R2 WE Woes Continue

I spent all morning on a dirt simple WE web app and for the life of me I can’t get it to run.  I replaced the line of code that I mentioned in a post from last week.  Uploaded the app, verified permissions, and I get nothing but a standard server error message.

In my web server log I get the following error:

malformed header from script. Bad header=App.Open: myapp.cgi

Just to add to the mystery, I created a little log function that write to a local file and the app is starting, opening the database connection and then quitting without hitting the app.close event (hard crash?).

Web Apps built with R1 seem to work with no problems but I’ve been unable to get R2 apps to run.

Anyone else seeing this?  Anyone have any ideas?  This is very annoying.