Posts Tagged Web
Some companies have the same look and feel
Posted by Morten in Uncategorized on October 15, 2010
Sometimes its hard to spot the difference
Presenting JS-Analytics
Posted by Morten in Uncategorized on May 4, 2010
With the success we had with EQATEC Analytics at RemoteX I started looking around for something similar, but for JavaScript. I didn’t find anything that satisfied my needs.
Thus I created my own error collecting and analysis tool, and named it JS-Analytics.
You use it similar to how you use Google Analytics, you add a few given script tags to your website and JS-Analytics will try to collect any unhandled JavaScript error that occurs, and send information about it back to JS-Analytics website.
JS-Analytics uses a combination of window events to collect errors. These events aren’t available on all browsers so JS-Analytics will use JQuery to provide cross browser support. This means that cross browser support is only available for JQuery code.
For more information about how it works I recommend this page.
Right now this JS-Analytics provides just some basic analysis. But I felt that it was better to announce it and hopefully get some feedback on it, than to carry on without any feedback.
Grails vs. Python on Google AppEngine
Posted by Morten in Uncategorized on April 7, 2010
A few weeks ago I got fed up with the bad performance I was getting on Google AppEngine for my Grails project. I was also having trouble figuring out how to combine references for Entities to build more complex structures.
As a result I finally lost it and started experimenting with Python on Google AppEngine. So here are some of my conclusions.
Framework
I still wanted to have a framework to build on for developing my application. Since Grails has a lot of dependencies that are sent to GAE I wanted something that was already supported by GAE. Partially because I heard that sending all these dependencies around in Google’s datacenter was one of the reasons for the bad performance I was experiencing.
So I chose Django. The Django framework is already installed on the web servers hosting the applications on Google AppEngine, which would reduce the load cost for dependencies.
There is also a Django helper that will help you use GAE features through the normal Django API.
Static files
Something I was missing from the Grails solution was the use of static files, most of the client side java script I server were static, so I just wanted a high expiration date and static serving of the files. This is inherent in Python GAE app.yaml file.
To be honest I am quite impressed by what I can do with the app.yaml file. I can set expiration dates on content, declare parts of the urls I define as secure. I can even reserve some parts of my site for me personally. Allowing me to build Administration interfaces for the application.
I will however miss the UI-performance plugin, as it handles my java script files the way I want, potentially even better. Now I have to manually set up something that during deployment compress and bundle my java script files.
Working with the API
Working with the python API for GAE gave me a better sense of control over what I was doing. The concepts of the Datastore and other features made much more sense. All of a sudden making applications with more complex data structure wasn’t an issue. How things connect to each other was inherent and the documentation was there to assist me when I missed something.
I also had to write less code to achieve the same features, however part of this could be because I had already solved the problem once and could produce a better solution with this.
What I really liked was testing, where I earlier had had problems with getting tests to run for Grails with the AppEngine plugin. The tests not only worked out of the box, but they took roughly 0.1 second to run 10 tests.
Performance
So finally, the performance part. Remember this was one of the reasons I made the switch.
Before I get to the actual numbers, I have to mention that there are some changes that affect the results. When hosting on Python I could serve most of my pages as static HTML files, where using Grails I was depending on the virtual machine to boot up before content was delivered. Performance for the static files could probably be achieved if the Java app is configured to serve the files as static files through GAE.
And now the numbers
| Avg. Response time | |
| Grails | 4985 ms |
| Python | 252 ms |
| Uptime | |
| Grails | 53.48% |
| Python | 100% |
These numbers are captured using Pingdom, with checks running every 5 minutes on the website from all over the world.
Conclusion
Since I don’t require any plugins for Grails for this project and Python serving so well I’ll go with Python for this project.
This being said as I know Grails will get performance improvements for Google AppEngine in coming versions.
Screens taking off
Posted by Morten in Uncategorized on November 25, 2009
I just visited a local library. I took the time to pop in around lunch since they have reopened the library just recently (2 years ago?), with some new concepts in place.
What I noticed is that they have a lot of work stations placed around the library. All carrying 28” screens with good resolution. End result, most web sites viewed in the library only cover between 30-50% of the screen.
Right now it seems that screen resolution is taking off, and web sites aren’t following.
This is natural, the few people go back and update their web sites. Especially if it is focused on functionality to begin with. The thought I have is, should web browsers try to optimize for maximum screen utilization or not?
Rethinking design desicions
Posted by Morten in Uncategorized on November 21, 2009
I read a blog post at Three Rivers Institute that lead me to the following presentation.
The presentation is about startups and search engine optimization. How to drive visitors to your website.
Dharmesh discusses how to adapt your webpage to generate visitors, also promoting his hubspot seo grader.
Now this got me thinking of a project I’ve been working on. It’s a highly dynamic JavaScript based page, hosted on Google AppEngine. (currently not in a state I’d like to show it off since its still lacking the basic features).
The page is being designed with a few ideas in mind:
- All dynamic data i served to the page through REST
- All static pages are served with long expiration, most content is static
- The main page never reloads, instead JavaScript does AJAX to update the content
- The JavaScript is designed using SOLID design principles
- The JavaScript is tested
- Back and forwards buttons still work
- Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material
Now the idea here is to give a similar feeling as to what GMail feels like. A common trend, in web application development I think. However, after watching the presentation the following thought occurred to me. The GMail application needs to be found by search-engines.
Google has a signup page with content that is searchable, but the main JavaScript client is not designed to be found by Search Engines.
I want my page to be found by search engines, and this means that there are a few of the basic Ideas behind the page that I need to reconsider. Especially the following:
- The main page never reloads, instead JavaScript does AJAX to update the content
- Meaning that the page looks “empty” to search engine crawlers since all content is loaded using JavaScript
- Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material
- Right now this is implemented using IFrames, which probably cause trouble for search-engines (yeah yeah, I know frames suck especially IFrames… but there were some cross site issues I didn’t want to fix right now),
I need some of my content pages to be searchable, but not the AJAX-driven application in it self. So now I have to rethink some of my decisions which were made from a pure coding view-point, to adapt to marketing viewpoints (and search engine algorithms so its not all bad).
Invitation model marketing
Posted by Morten in Uncategorized on October 8, 2009
The Google Wave beta program rolled out a bunch of Beta invitations lately. I discussed this with a friend, the marketing value of an invitation model for software.
GMail started as an invitation, most people I know started using GMail as they were invited by others. I my self started with GMail after a friend evangelized the interface.
I believe that Google hopes to apply the same marketing model to Google Wave, and as far as I know they will succeed with it as well.
Now lets consider the benefits.
- They can build hype, but still release the product early for feedback
- They can scale slowly, making sure the system can handle the load as the user base grows
- They can target specific users for invitations, say 20% targets students, 20% targets media, and then som distributions between web browsers and operative systems
Now the targeting of users is interesting. This part is just hypothesis, but in theory they could use search to look up people. For example, they could find people on Facebook and see what kind of friends they have, even interests for example. They can check out whom follows who on twitter. All in all, they can in theory data mine the net to target out specific users whom will fill the role for Marketing, Feedback and Development.
Note that I do not believe that Google does this kind of datamining, but I believe that they are capable of it. Just as anyone is capable of it, there are even services available for this specific task.JQuery: keeping your site-state in the addressbar
Posted by Morten in Uncategorized on June 9, 2009
More and more sites are doing it. Keeping their state in the address bar of the browser, enabling AJAX driven dynamic html pages to use the back and forward buttons between javascript driven views. The most common website that uses this functionality, that I know of, is GMail. If you look at the address bar in GMail when in an message you can see that they added a bookmark hash (#) specifying which message to show. The updated address bar allows the application to keep state in the browser history.
I started working on a solution for this on my own, at the time I couldn’t find any JQuery plug-ins with the desired functionality. Now however there are several. In order to reduce the amount of specific code in my own application I tried out three.
JQuery History, JQuery hashchange and JQuery address .
After looking at JQuery address I can honestly say that it has the best fail-safe of the three I looked at. It uses full page post backs as a fallback. I haven’t been able to get it to work without reloading the entire page. So for that reason I cannot use the plug-in myself.
This is my favourite. I has a nice and clean interface and does only what you tell it to do. However I couldn’t get it to work on Internet explorer 6. Which is also one of the reasons why I’m looking at the plug-ins to begin with.
JQuery history is actually the plug-in that led me to the others. I came in contact with another Mor.ph user who used it on his site. As far as I can tell from the usage of this it needs to interact with the link’s on the page in order to work properly. Catching the click events on the links. This is also a problem for me. I’d prefer just to update the bookmark hash.
Now while I couldn’t use any of these plug-ins I just wanted to give a shout out to people looking for them. They are there. A few things to think about, that I found out. Is that your page needs to be designed for this type of behaviour. If you use any of the plug-ins then your page will most likely be couple to that design. It’s also much easier to add this type of behaviour for the page in the beginning than appending it to already existing Ajax pages. These are my experiences with it.
I also lack a word for the technique of keeping your state in the address-bar.
IETester
Posted by Morten in Uncategorized on May 27, 2009
I found a new tool for testing web-applications in IE today. It’s called IETester, and it allows me to test IE versions 5.5 to 8 in the same application. Which is great, since my Vista machine only runs 8 normally.
I use it to verify my Grails application in IE6. Tonight I managed to create a unit test capturing the issue I was experiencing in IE6, using IETester and QUnit, so now I know where to take off tomorrow.
However it isn’t that stable, I’m running it on a 64-bit machine which might add some extra strain on the application. But for me it needed to be re-started or crashed a few times while I was isolating the bug I am working on.