We are creating a new frontend and at the same time are moving towards typescript. We wanted to use the page objects pattern to have a better maintainable end-to-end test script. Protractor is an end to end test framework for AngularJS applications built on top of WebDriverJS.
As of any problem with typescript we should first understand the javascript variant. So lets begin at the beginning and create a integration test for a example login page:
As you can imagine, elements or their selectors can change at any time, so a page object is very useful. Lets look at a pure javascript example with a page object.
Now as you can see the page object pattern helps a lot here, the test only describes what we want to do, and no longer is concerned with page specifics.
Now lets see how that looks in typescript:
You might hit a problem that you hit an error like ">> error TS2095: Could not find symbol 'module'." in your pageObject.ts file. The way around that is to insert the following code before your class definition:
Now the same problem can occur on the "require('pageObject.js')" bit as that is also a statement that typescript uses to load modules. So we can use the same workaround:
I don't know why some of the files need this "workaround" but it is workable.
Tuesday 11 March 2014
Tuesday 28 January 2014
HTML5 Application Cache (Safari) quirkiness
HTML5 Application Cache can be a powerful tool in modern browsers, but there are some quirks that you have to know when you use it. If you don't know about the Application Cache I suggest you checkout Eric Bidelman's A Beginner's Guide to Using the Application Cache.
First of is the size limit of the different browsers. There is a great website that list (and tests) the size limit of the different browsers: appcache-default-size
IE (at least 10 and 11) has a limit per domain, so a.example.com and b.example.com share the same storage limit. And any resources served with the header Cache-control: no-store in IE will fail the download of the application cache.
Safari (tested on 7.0.1) has strange quirk. We run our application with gzip enabled, so when I tried to load our application for the first time on Safari I got a "[Error] Failed to load resource: cannot decode raw data" on the manifest file. Safari tries to download the manifest with the correct gzip accept-header, but fails horribly when the data is gzip'ed, so disabling gzip for the manifest file fixes the problem, for the manifest. But then it downloaded the first file and the same error occurred, so we got to disable gzip for all resource files, as we can't identify if Safari is downloading normally or via the manifest. Fun fact is that Safari on the iPad works just fine.
Another quirk is that Safari downloads on a separate 'thread' witch has no cookies what so ever. So the 'thread' downloading is not logged in. This causes some problems as we had our resources secured with authentication.
So in conclusion to make Safari work with the application cache.
- You have to disable gzip for Safari (desktop).
- All resource files should be publicly accessible.
First of is the size limit of the different browsers. There is a great website that list (and tests) the size limit of the different browsers: appcache-default-size
IE (at least 10 and 11) has a limit per domain, so a.example.com and b.example.com share the same storage limit. And any resources served with the header Cache-control: no-store in IE will fail the download of the application cache.
Safari (tested on 7.0.1) has strange quirk. We run our application with gzip enabled, so when I tried to load our application for the first time on Safari I got a "[Error] Failed to load resource: cannot decode raw data" on the manifest file. Safari tries to download the manifest with the correct gzip accept-header, but fails horribly when the data is gzip'ed, so disabling gzip for the manifest file fixes the problem, for the manifest. But then it downloaded the first file and the same error occurred, so we got to disable gzip for all resource files, as we can't identify if Safari is downloading normally or via the manifest. Fun fact is that Safari on the iPad works just fine.
Another quirk is that Safari downloads on a separate 'thread' witch has no cookies what so ever. So the 'thread' downloading is not logged in. This causes some problems as we had our resources secured with authentication.
So in conclusion to make Safari work with the application cache.
- You have to disable gzip for Safari (desktop).
- All resource files should be publicly accessible.
Wednesday 13 November 2013
Raspberry Pi: NZBGet vs SABnzbdPlus vs NNTPGrab
This post is a bit off for what I usually want to post, but I want to share my experience with newsgroup downloaders on a Raspberry Pi.
First of I noticed that the speed of the external hard disk was very slow compared to the internal SD-card. It was around 900Kb/sec and the internal SD-card was around 3Mb/sec. This speed whet up to the same as the internal SD-card by removing the sync attribute of the usbmount options (in /etc/usbmount/usbmount.conf line 22). So that problem out of the way we can start testing.
Most people complain that SABnzbd is to cpu intensive and to memory hunger and that you should use NZBGet or NNTPGrab instead as they are less cpu and memory consuming. So lets compare the three. The internet connection that I'am using can download at 5.5Mb/sec on a normal desktop with SABnzbd so lets take that as 'control'
During this test a 1.5Gb file was downloaded. The download speed of SABnzbd was all over the place from low points of 1.2Mb/sec to some spikes of 2.5Mb/sec. The download speed of NZBGet was much more stable between 2.7 and 2.9, that is more what you would expect. The final one NNTPGrab was the wist of all download speeds never went over 700Kb/sec very disappointing...
The cpu consumption was very high during the download, and he Raspberry is running on 700Mhz by default, so what would happen if we increased the cpu speed?
We got a bit better results with the Raspberry running at 900Mbz (1000 caused a crash)
The download speed of SABnzbd was even more all over the place, with low points of 1.2Mb/sec to high speeds of 3.5Mb/sec. NZBGet was a bit better but still a very stable download speed. And NNTPGrab was still to slow.
Conclusion: SABnzbd could be used if your internet connection isn't that fast, or you don't mind waiting. But the best newsgroup downloader for the Raspberry Pi is NZBGet.
Update: Extra "speed boost": Disable CrcCheck (In Settings -> Download Queue) if you have a stable newsserver. This will increase the download speed with NZBGet to 3.7Mb/sec. A possible downside is that if an article fails to download correctly that the entire download needs to go tough a par2 check/repair, which will cost you more time in the end.
Some tech details:
I tested this on a Raspberry Pi model B with with '2013-09-25-wheezy-raspbian' distribution.
SABnzbdPlus version 0.6.15
NZBGet version 11
NNTPGrab version 0.7
First of I noticed that the speed of the external hard disk was very slow compared to the internal SD-card. It was around 900Kb/sec and the internal SD-card was around 3Mb/sec. This speed whet up to the same as the internal SD-card by removing the sync attribute of the usbmount options (in /etc/usbmount/usbmount.conf line 22). So that problem out of the way we can start testing.
Most people complain that SABnzbd is to cpu intensive and to memory hunger and that you should use NZBGet or NNTPGrab instead as they are less cpu and memory consuming. So lets compare the three. The internet connection that I'am using can download at 5.5Mb/sec on a normal desktop with SABnzbd so lets take that as 'control'
| Control | SABnzbd | NZBGet | NNTPGrab | |
| Average download speed (Mb/sec) | 5.5 | 1.7 | 2.8 | 0.6 |
During this test a 1.5Gb file was downloaded. The download speed of SABnzbd was all over the place from low points of 1.2Mb/sec to some spikes of 2.5Mb/sec. The download speed of NZBGet was much more stable between 2.7 and 2.9, that is more what you would expect. The final one NNTPGrab was the wist of all download speeds never went over 700Kb/sec very disappointing...
The cpu consumption was very high during the download, and he Raspberry is running on 700Mhz by default, so what would happen if we increased the cpu speed?
We got a bit better results with the Raspberry running at 900Mbz (1000 caused a crash)
| Control | SABnzbd | NZBGet | NNTPGrab | |
| Average download speed (Mb/sec) | 5.5 | 1.9 | 3.0 | 0.6 |
The download speed of SABnzbd was even more all over the place, with low points of 1.2Mb/sec to high speeds of 3.5Mb/sec. NZBGet was a bit better but still a very stable download speed. And NNTPGrab was still to slow.
Conclusion: SABnzbd could be used if your internet connection isn't that fast, or you don't mind waiting. But the best newsgroup downloader for the Raspberry Pi is NZBGet.
Update: Extra "speed boost": Disable CrcCheck (In Settings -> Download Queue) if you have a stable newsserver. This will increase the download speed with NZBGet to 3.7Mb/sec. A possible downside is that if an article fails to download correctly that the entire download needs to go tough a par2 check/repair, which will cost you more time in the end.
Some tech details:
I tested this on a Raspberry Pi model B with with '2013-09-25-wheezy-raspbian' distribution.
SABnzbdPlus version 0.6.15
NZBGet version 11
NNTPGrab version 0.7
Wednesday 15 May 2013
Calling SOAP web services in OSGi using Apache cxf
Calling SOAP web services in OSGi using Apache cxf
Calling a SOAP service in OSGi is not as straight forward as it seems. Although there are a lot of frameworks that can accomplish this, not all of them are OSGi bundle(s), and we want to keep the footprint as low as possible. This example has a footprint of 8.5Mb so its not that bad and in this example we will be using Java 7, BND tools 2.0, apache felix framework (4.0.3) and Apache cxf (2.7.4)
Oldy enough cxf has a required package javax.mail, javax.mail.internet and javax.activation, these packages are provided by the jvm but we need to explicitly configure them as run system packages. (this configuration can be found in the run.bndrun of the complete example link is below)
Download the cxf zip from the website: http://cxf.apache.org/download.html
And we must use the following bundles from the lib folder:
org.apache.cxf.bundle -> cxf-2.7.4.jar
org.apache.neethi -> neethi-3.0.2.jar
stax2-api -> stax2-api-3.1.1.jar
woodstox-core-asl -> woodstox-core-asl-4.2.0.jar
org.apache.ws.xmlschema.core -> xmlschema-core-2.0.3.jar
The wsdl4j bundle and another dependency xmlresolver in the lib folder in cxf are not OSGi bundles so we need to download them form somewhere else, I have chosen to download them form the org.apache.servicemix maven repository:
org.apache.servicemix.bundles.wsdl4j -> http://repo1.maven.org/maven2/.../org.apache.servicemix.bundles.wsdl4j-1.6.2_6.jar
org.apache.servicemix.bundles.xmlresolver -> http://repo1.maven.org/maven2/.../org.apache.servicemix.bundles.xmlresolver-1.2_5.jar
The application can start now but when we try to make a SOAP call cxf will be missing the async.httpclient. We can download that one from here:
org.apache.httpcomponents.httpclient -> http://repo1.maven.org/maven2/.../httpasyncclient-4.0-beta3.jar
You might want to rename the org.apache.httpcomponents.httpclient bundle to org.apache.httpcomponents.async.httpclient as what I have done in the example as there is a other bundle named 'org.apache.httpcomponents.httpclient' that does not export the same interfaces or packages and is there for not compatible. It is however possible to start felix with both bundles as they differ in versioning but it is not very clear. A prepared version can also be directly downloaded from the example git repository.
The example git repository contains a full example project with a hello world service client and can be found here: https://github.com/Japio007/OSGi_cxf
You can run it with the run.bndrun file (when you have a mock soap service for example with soapUI)
Calling a SOAP service in OSGi is not as straight forward as it seems. Although there are a lot of frameworks that can accomplish this, not all of them are OSGi bundle(s), and we want to keep the footprint as low as possible. This example has a footprint of 8.5Mb so its not that bad and in this example we will be using Java 7, BND tools 2.0, apache felix framework (4.0.3) and Apache cxf (2.7.4)
Oldy enough cxf has a required package javax.mail, javax.mail.internet and javax.activation, these packages are provided by the jvm but we need to explicitly configure them as run system packages. (this configuration can be found in the run.bndrun of the complete example link is below)
Download the cxf zip from the website: http://cxf.apache.org/download.html
And we must use the following bundles from the lib folder:
org.apache.cxf.bundle -> cxf-2.7.4.jar
org.apache.neethi -> neethi-3.0.2.jar
stax2-api -> stax2-api-3.1.1.jar
woodstox-core-asl -> woodstox-core-asl-4.2.0.jar
org.apache.ws.xmlschema.core -> xmlschema-core-2.0.3.jar
The wsdl4j bundle and another dependency xmlresolver in the lib folder in cxf are not OSGi bundles so we need to download them form somewhere else, I have chosen to download them form the org.apache.servicemix maven repository:
org.apache.servicemix.bundles.wsdl4j -> http://repo1.maven.org/maven2/.../org.apache.servicemix.bundles.wsdl4j-1.6.2_6.jar
org.apache.servicemix.bundles.xmlresolver -> http://repo1.maven.org/maven2/.../org.apache.servicemix.bundles.xmlresolver-1.2_5.jar
The application can start now but when we try to make a SOAP call cxf will be missing the async.httpclient. We can download that one from here:
org.apache.httpcomponents.httpclient -> http://repo1.maven.org/maven2/.../httpasyncclient-4.0-beta3.jar
You might want to rename the org.apache.httpcomponents.httpclient bundle to org.apache.httpcomponents.async.httpclient as what I have done in the example as there is a other bundle named 'org.apache.httpcomponents.httpclient' that does not export the same interfaces or packages and is there for not compatible. It is however possible to start felix with both bundles as they differ in versioning but it is not very clear. A prepared version can also be directly downloaded from the example git repository.
The example git repository contains a full example project with a hello world service client and can be found here: https://github.com/Japio007/OSGi_cxf
You can run it with the run.bndrun file (when you have a mock soap service for example with soapUI)
Sunday 10 February 2013
Loops in Java Script
There are many different ways to code a for loop in JavaScript, but not all of them are as efficient as a benchmark of Greg Reimer pointed out. This benchmark was done back in 2008 and the browsers have evolved a long way in this time, so it's time to see what's what.
Subscribe to:
Posts (Atom)