Plex Updates

CA Plex Updates


Update: Removed old legacy links that were causing Google issues.

Wow! What a week.

I, like many of you spent 3 hours on the recent CA Plex/2E webcast marketed as 'Blitz'. For me it was a little more inconvenient as it was from 2am until gone 5am in the morning. To top it off it was a school night as well. Suffice to say, Friday night after a hard days work, I was exhausted.

The result though was worth every last minute of sleep deprivation. I felt energised by what these guys had achieved.

To kick off we had an overview from Bill Hunt with a plug for the 4th Annual Conference in Ft Lauderdale, Florida, USA. Then the action got going.

We were treated to an update for the ADC Austin/Websydian Plex Web Client. Delivered by John Rhodes. This is a plex client delivered out of the box once you have the patterns and web environment setup which is receiving plaudits from around the community.

Then Gary McGeorge from Desynit in old blighty demonstrated their customer solution for a trading desk. The highlights for me were the sheer speed of the screen refreshes, the look of the application using the codejock controls with their YouEye pattern. The ability to split the application over 4 dealer screens and have configurable screen layouts blew me away and was a topic of discussion with one of my Plex introduced friends here in NZ the next day. Well done lads.

I wasn't so chuffed with the screaming baby in the background from one of the attendees of the conference who clearly forgot to mute their phone line. I would suggest in future that each presentation has a slide saying 'Mute that damn line now punk. Do you feel lucky!!!'

This was followed by Soren from Websydian showing us what TransactXML was capable of. I had never seen this before but now I understand what it delivers and with the import facility, how easy it is to implement, I will definitely take a much closer look.

Then we had Marty (MKS) and Chistoph (CM First this is the English link) demonstrate the new features in their respective toolsets that support Plex integration and best practice modelling concepts. I would certainly like to know how configurable the flow that was demonstrated actually is, but it looked like a pretty good start to me.

Finally Bill wrapped up with a sell for the upcoming conference. With the guaranteed weather and content similar to what we saw on Thursday it will be a great event by the looks of it, and I thought Cincinnati was good.

My only disappointment is that the guys at ‘all about’ didn't have a slot. What I have seen of their Plex-XML solution is mind-boggling and the presentation layer is amazing. This is a great solution and I am interested in seeing how this develops. They have recently updated their website to include integration with a rich web editor. Amazing stuff.

Until then.

Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). 
Lee.

Why bad design sucks! - Part II

Why bad designs sucks!


Hmmmm,

As I suspected a couple of weeks ago once you open your eyes to a subject and commence blogging about it you have it constantly in the back of your mind. My post on bad systems design and planning has had this affect on me.

I am minding my own business at my local quiz night when a question was read out by the quiz master or perhaps mistress as she is a lady. "What day of the week was Valentines Day in the year 2000?" Now as I am not the romantic type so I certainly couldn't recall this answer based on an event, although a friend 'H' was adamant he knew the day.

I decided the simple solution was the mobile phone calender so I plucked out the phone. It is a reasonably new Motorola Razor phone. So you know the routine, Menu, Organiser & Tools, Calendar. Voila.... The calendar is showing February 2009 (the current month when this event occurred).

"Excellent", I said (I remember the excitement), I can now work it out by counting back. Then I thought what about the leap years? So at this stage I decided to press the previous month button again and again and again working my way back in time faster than Marty McFly in his time machine and I didn't need a flux capacitor.

You get the idea, November 2008 came and went. July 2006 soon appeared but a few more key presses and my phone stopped working. It got as far as January 2005 and it stopped. No message, no nothing.

Bang. Another blog appears out of the blue. And a lot of questions.

Why did it stop at January 2005? How am I going to answer the question? Anyhow another of the team had an older phone that could go back further and we got the answer right in the end. fyi it was a Monday.

This got me thinking a little. What is the upper limit for this phone. After hundreds and hundreds of key presses (1007 to be precise) I got my answer NOVEMBER 2088. December 2099 I can understand as it would have covered a century but NOVEMBER 2088, what a strange limitation.

That works out at 83 years and 11 months or 30,650 days and I can't for the life of me think of a reason why my phone wouldn't be calculating this on the fly. It is not showing holidays. Leap years can be identified by a simple formulae. I certainly can't see a contraint in computing terms that would cause this to occur.

If someone can tell me why the programmer decided to restrict the dates in this way I'd be keen to hear your comments. It might be because they assumed that the phone was made after 2005 and therefore didn't need to go back for storing calendar entries. Fair assumption. But why put it in? Another unnecessary computer programmer/designer limitation I think.

Other friends on the night had different limitations on their phones and a colleague at work with a cool new blackberry had no issues at all with date range restrictions far in excess in both directions that he was prepared to sit around trying to find.

I don't think you have heard the last of the 'Why bad design sucks!' series....... It does worry me that people still impose design limitations.

Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). 
Lee.

Why bad design sucks! - Part I

Why bad design sucks!


There are many areas of computing that have been let down by poor design.

Actually that may be a little harsh.

However, poor assumptions have definitely led to numerous designs that in hindsight could be considered questionable at best. These decisions have in turn led to systems that have suffered due to higher than anticipated volumes or longer than expected life spans.

A few examples that come to mind are:-

The millennium bug. Everyone knows this story. Developers designed systems in the 60s, 70s and 80s with 6 character dates ie DDMMYY or MMDDYY. The assumption being that storage is expensive and this system won't be around in 20 or 30 years. Well we all know how much effort was involved ensuring that airplanes never fell out of the sky in the late 90's, not to mention the contract rates for COBOL programmers that went with it. So I guess the lesson learned here is short sightedness.

http://www.trademe.co.nz/. Another example I heard about was for a very popular auction trading site here in New Zealand. The founders at a Microsoft TechEd conference a few years ago talked candidly about the early days of the business. They were describing growth of the business and unexpected challenges for the fledgling company.

The site was adding customers at a nice steady state when one day the system stopped working. No more new customers could be added.

They were a little concerned at first. After all they had just added their 32767th customer.

The issue was that in the early versions of their database they hadn't considered the domain of this particular field to carefully. i.e. the size. They had reached the limit for the integer field type on their platform. Now that the site is the most successful site in New Zealand and has made the creator a multi-millionaire, I am sure they have used at a minimum a long integer. The lesson learned here would be factor your wildest assumptions into your database designs.

www.Virtualrugby.co.nz. A sports predictions site here in NZ that has just rebranded again with another sponsor but suffered the ignominy of poor application performance and a whole host of players unable to access the site. On one occasion I was advised that the server was unable to make a connection because the limit of 111 connections had been reached. This is for a site that had over 100,000 active participants the previous year. I will go as far as suggesting the infrastructure suppliers arrangement may have changed as a result of the sponsorship change. Hopefully they'll get it sorted.

The lesson learned here. Never underestimate your audience and your processing peaks. Most of all ensure that your test systems have a reasonable subset of data to stress a mass participant application. Three guys in a room pressing the submit button as often as possible is not load/stress testing.

IPv6. Another in a long line of bad designs, or is it? It is alleged that we are to run out of IP addresses in the next few years. Some claim that this is the millennium bug of the 2000's. If it is and given the age of computing in general, we might have a few more yet. Sounds not too different to the 100 year storm scenario that happens every 4 years in these days of global warming.

I guess this one could have also been avoided but the caveat once again was when IP addressing got going the internet was quite young and connected devices were at a far lower number than they are today. Lesson earned! What do you think?

......

With all these though, IMHO it was human expectations that were at fault or shortcuts being taken to save a few bytes here or there. My advice to all application developers is to ensure that all your applications have database fields that are capable of supporting data sets beyond your wildest dreams. And to ensure that your application architecture is fit for purpose.

Bad design really does suck. Ask your end user(s).

Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). 
Lee.

p.s. I titled this Part I as I guess that now I have finally got this off my chest there will be other scenarios out there that will jump out shouting - BLOGGERTUNITY. Actually, one has just emerged but I will save that for another day.

*Arrays can be quirky in 2e

Synon 2E - *Array bug and workaround


Hiya,

I have just become aware that *Arrays do not support the correct ordering sequence for negative index values. This has been referred to CA Support (2nd Level) for investigation.

My scenario is an array that is ordered based on a difference between two values. For the purposes of a meaningful example lets pretend that our array is a league table for the English football premier league (Soccer to some). If your game is rugby or another sport then you can draw your own comparisons.

The scenario is that after 2 games of the season I have 5 teams on 4 points. These teams are place 1 to 5 on the table. Let's further embelish this example and assume that my team, Tottenham Hotspur (Spurs) are at the top. :-)

TeamPointsGD (Goal Difference)
Tottenham4pts+78
Liverpool4pts+5
Everton4pts0
Wigan4pts-4
Chelsea4pts-8
......
Arsenal0pts-78


Apart from the obvious good start by Wigan and the strange GD for two games. I believe the example table to be a fair reflection of the real world. With Tottenham at the top. COYS. Blue and White army. Stand up if you hate Arsenal.

If I were to create an *array in DESCENDING order with the keys of Points and GD. My array would sort itself as follows:-

TeamPointsGD (Goal Difference)
Tottenham4pts+78
Liverpool4pts+5
Everton4pts0
Chelsea4pts-8
Wigan4pts-4
......
Arsenal0pts-78


The arrays doesn't handle the negative sign and although it preserves the negative sign it is unable to sort it. Note the order of Chelsea and Wigan.

Until this is fixed, a simple workaround I have used is to *ADD an arbitrary figure to the GD to ensure it is a positive value. In order not to blow a limit (as over a season a team can be -100) I need to cater for a higher number so I chose 10,000 for the *array as an offset.

At the point of display which happens to be a DSPFIL I simply deduct 10,000. Simple workaround. Hopefully, simple solution that will be fixed some time in the future. Another option which I contribute to my colleague Chris Koloszar is to do the 10,000 offset for the key and leave the original value as an attribute of the array also.

My main concern is for those of you that have negative values but have yet to discover them.

I will post updates as I hear back from CA.

Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). 
Lee.

UPDATE HISTORY
==============

2:54pm (Same Day). I have had some quick responses from CA (Very impressed - Thanks Lynn). CA claim this to be working as designed. I am countering that it is a bug and was designed incorrectly. I hope that this will be fixed and I will keep you all updated.

What do you think?

Next Day - Referred to development not a trivial fix but I am confident it will be a good look over. Thanks.

Goopression - I've invented a word

Google Depression!


I thought I'd have a little whinge today about Google. Well not Google themselves. I think that they are a great innovative company who have transformed how we all interact with the internet and for that, I am grateful. I do remember the early days with Compuserve dialup and prior to that premium phone bulletin boards and usenet groups.

But recently I have been exploring business ideas of my own. When I say recently. Like most IT guys I have been pondering the 'garage' project, aka the 'killer app' for years.

We can all use google to research our ideas, get an idea of the validity of the idea i.e. any competitors that may be lurking in the wings etc.

However, today, I am suffering for "Goopression". Google depression!!! This means that your killer idea (no matter how you search for it) has already been taken. The domain has gone, as has your enthusiasm for your idea. This feeling really sucks.

You see, as much as the internet can be an inspiration to us all. One quick google of an idea and all of a sudden you are depressed......Someone else has stolen your idea. Sorry - got there first.

Now for sure. If it is a good idea (which I believe I have) backed up by a great business plan you may well achieve your aim. You will remember the number of search engines that were around pre-google...... Just don't be surprised if your killer idea has already been considered, invented or patented.

That all said, if you are having the ideas in the first place then one day that killer app/idea will happen. Just be prepared for a little disappointment along the way courtesy of our friends from Google.

Thanks for reading the
Synon 2E and Plex Emporium by Lee Dare (A developer blog). 
Lee.

p.s. I've invented a word!