Not sure if someone else noticed it, but some charts in Apple’s Stocks application got broken recently. Looks like last data point is always 0.0000, which causes charts to get distorted and unfortunately useless. Issue seems to affect currency exchange rates, but only for some pairs and only for periods >= 1m.

For example GBP/EUR:

Or GBP/CHF:

 

Other problematic currency pairs I identified: GBP/PLN, CHF/PLN, EUR/PLN.

 

Advertisements

Few days ago a new Java vulnerability has been discovered that affects all versions of Java 7 on most browsers. Luckily Oracle addressed it quickly by releasing an update. Since I previously had JDK 1.7.0_04 installed, I had to manually switch to use latest version by going to Applications > Utilities > Java Preferences and changing active version in the drop-down.

I wanted to remove the old version from my Mac, since it was unlikely I’d ever use it again. Unfortunately Oracle help page I found did not offer the solution. Luckily this turned out to be rather easy – all you need to do is go to Mac HD / Library / Java / JavaVirtualMachines and remove VM file that you no longer need (jdk1.7.0.jdk in my case).

Hope that helps.

Today I launched iCal and noticed that all my entries were duplicated. Removing unnecessary copies would be so time consuming it’s not even funny. After I opened Calendars List, it showed two sets of calendars – On My Mac and iCloud. Unchecking every calendar in one of them, even thought seemed to help, was not a real solution. Luckily real fix is equally simple. It worked for me, hopefully will help someone:

Quit iCal, go to System Preferences and navigate to iCloud. Uncheck Calendars, confirm and then check Calendars again. Confirm again if needed and launch iCal. You should only see a list of iCloud calendars and no duplicates!

I read an interesting post on official Flex blog few days ago. Flex: Where we are headed tries to summarise Adobe’s view on Flex framework and it’s future. Unfortunately my comment has not been approved for about two weeks now (holidays?) so I decided to post in on my blog. Hopefully some of these concerns will be addressed. Here we go:

Dear Adobe,

It’s great to read that you treat your platform seriously. You are positioning yourself as enterprise platform provider, but the reality shows you are not there yet. Several improvements to Flex and Flash need to be made for that duo to become truly useful in the enterprise world. I have worked on a number of large scale Flex projects for major financial institutions and would like to share some of my observations. I know this is an ultimate wish-list, but all these things really matter:

  • Flash runtime needs to be made more efficient. Really big budgets are required to make large modular applications work smoothly. Drop some backwards compatibility baggage if you need to. Virtual machines can be really fast (JVM).
  • AS3 needs to be updated (it’s 5 years old already) to have proper collections library, support for generics and decimal type. You need to make it even more expressive and powerful.
  • Better reflection and code instrumentation capabilities are needed.
  • Better support for modularisation and runtime dependencies is needed – make RSLs even more powerful and controllable by developers.
  • General quality of code across Flex SDK needs to be improved considerably. Having so many bugs and regressions is not acceptable in mature enterprise framework.
  • Performance of Flex SDK components needs to be improved. Hundreds of components and tons of data on the screen should not be a problem. That’s how enterprise applications usually look like.
  • Styling engine in Flex needs to be replaced with one that is more powerful, efficient and less buggy.
  • Flex compiler needs to be faster. Compile time in any larger project are so high, that may seriously hurt productivity.
  • Flash Builder needs to become world class IDE – some third party IDEs are ahead (IntelliJ).
  • Proper profiler is a must. Current solution is not powerful enough, doesn’t visualise results well and is way too slow.
  • Better support is needed for tools that are widely used in enterprise, such as maven. Contrary to some opinions, flex-mojos is not good enough yet.

Flex developers spend too much time fighting their tools. That makes building Flex platforms rather expensive and risky investments. If this perception will get instilled in minds of managers and directors, then enterprise Flex is dead and lots of Flex developers will need to start looking for new job. Keep us informed about your plans.

Thanks.

I find it really annoying when applications I use keep creating their own folders in my Documents directory. Luckily some applications can be configured not to do it. Today I was fighting against Flash Builder, trying to make persuade it not to create workspace in Documents (I have separate folder for development).

Using File > Switch Workspace works for as long as you don’t delete the one created in Documents by default. It turns out, that you have to edit this file to make it work properly:

<your-FB-install>/eclipse/configuration/config.ini

and change these properties to point to directory of your choice:

osgi.instance.area.default
osgi.configuration.area

Atry pointed me to latest release (0.8.7) of his protoc-gen-as3 library. I re-ran my tests to see if it brings any performance improvements – and it does!

Deserialization times are very similar to 0.8.4 which I used previously. I would assume any differences are statistical errors.

Deserialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
445.96 962.16 1313.68 326.26 962.00 1435.76
Std dev:
(ms)
25.23 24.35 15.96 4.69 4.38 9.96

Serialization times are greatly reduced – PB library is now 3.5 times faster then before for small messages, over 4 times faster for medium and 4.5 times faster for large. It is still slower then AMF3, but I for most use cases the difference is now negligible.

Serialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
137.68 214.08 317.76 237.84 563.08 814.70
Std dev:
(ms)
13.11 14.88 16.45 11.52 15.83 17.37

Very good news!

Note: Tests were ran on MacBook Pro, 2.26GHz Core 2 Duo, 2GB RAM.

Update: I ran tests again using newer version of protoc-gen-as3. They can be found here.

For last couple of days I have been investigating Google’s Protocol Buffers with intention to use it in Flex application. While in Flex world such idea instantly raises at least a couple of questions, let me explain our situation a little bit more.

We are looking into using Kaazing, which is quite low level and data format agnostic solution, to provide us with streaming capability. This means we have a choice of format we want to use for our messages (and streaming protocol, but that’s a topic for another post). We have never really considered XML because of message size, performance and Flash Player bugs (apparently fixed in version 10.1). Using AMF3 would give us a lot of developer friendliness and client-side performance, thanks to native FP support, but in our case would also add additional (and probably not insignificant) load on the server. As Protocol Buffers are already used to communicate between deeper layers of backend, we decided we could try to push PB messages up to the client, without having to translate them into another format. As that solution would also tick a couple of boxes on our nice-to-have list, we decided to give it a go.

During my investigation I concentrated on performance as this is very important factor for us. Our application will need to receive more than hundred messages per second and update view with minimal latency. As outbound traffic will not ever be as high, I was mostly interested in deserialization performance. To have some point of reference, I decided to test Protocol Buffers against AMF3, which in Flex world is a synonym for “as fast as you can get”. I used protoc-gen-as3 project, which seems to be most complete and is continuously maintained by it’s author.

Test application ran in total 150 tests per each format, 50 per each of three test classes. All tests classes have different size, so trend could be observed. Following listing shows definition for test class I refer to as Small in results section below. In terms of number of fields Medium is twice the size and Large thrice.

public class InstrumentPriceSmall
{
    public var numeric1 : int;
    public var numeric2 : int;
    public var text1 : String;
    public var text2 : String;
    public var date1 : ValueDate;
    public var date2 : ValueDate;
}

public class ValueDate
{
    public var year : int;
    public var month : int;
    public var day : int;
}

During each test an object was created, filled with data, serialized 10 000 times and then deserialized 10 000 times. Test application was compiled in release mode so that Protocol Buffers serialization and deserialization logic, which is completely coded in Action Script, could run with maximum efficiency. To minimize impact of garbage collector, System.gc() was called before running each test.

Results
In terms of over the wire size, PB is quite efficient for simple messages. However it’s advantage over AMF3 would quickly go away for objects that hold multiple references to the same value. This is fortunately not relevant for our use case, but could be for other scenarios.

Size
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Size:
(bytes)
198 290 371 31 80 123

On average deserialization times for PB are very close to AMF3. It also seems to scale quite well (although curve is steeper than AMF3). One thing I found surprising was that PB times were more stable (standard deviation smaller by factor of 2 to 6, depending on test object size). This is very desired feature because sometimes (like in our case) not only average timing is important, but also how far off best and worse case timings are.

Deserialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
444.92 955.06 1348.38 332.46 977.12 1457.12
Std dev:
(ms)
18.19 20.88 16.32 3.10 6.77 7.42

Serialization times look much less promising. Protocol Buffers are much slower, even 5 to 10 times depending on test object size.

Serialization
AMF 3 Protocol Buffers
Class: Small Medium Large Small Medium Large
Average:
(ms)
165.30 235.08 320.66 835.82 2385.44 3619.78
Std dev:
(ms)
22.22 17.15 16.57 17.89 63.02 81.80

I will keep my summary short. Small message size could mean short over the wire transfer time, deserialization times comparable with AMF3 could mean low processing overhead on the client. No need to translate each message to AMF3 could reduce server load. In our scenario Protocol Buffers could work.

EDIT: There’s one more thing that might be important. AMF3 serialization and deserialization is done by Flash Player on a separate thread while Protocol Buffers messages are processed by AVM on GUI thread. This means that large volumes of data might influence framerate and disrupt animations.