Wednesday, July 30, 2008

Awesome Pie Charts with FoxCharts in zero time

If you haven't been trying out the VFPX project FoxCharts , or you tried but were a little frightened by how to implement it, here's some code that I wrote up quickly to build a nice little pie chart.

I call it GenPie and it gets called with any table and it will summarize it for you.

DO GenPie with "issues","cstatus","1","","Count of Issues"
or

DO genpie WITH HOME()+"SAMPLES\DATA\ORDERS","to_country","order_amt","","Orders"

The code essentially creates a form, drops FoxCharts on it and then uses a built-in cursor to create the chart. You can also pass it a Filter (before the title) and the starting color (in RGB).

DO genpie WITH HOME()+"SAMPLES\DATA\ORDERS","to_country","order_amt","","Orders",RGB(255,150,255)

Here's a sample:


LPARAMETERS tcTable,tcDirField,tcSizeField,tcFilter,tcTitle,tnStartColor
PUBLIC ox
ox = CREATEOBJECT("form")
IF EMPTY(tcTitle)

tcTitle = tcTable
ENDIF
ox.newobject("foxcharts","foxcharts","foxcharts")
ox.foxcharts.width = ox.width
ox.foxcharts.height = ox.height

IF EMPTY(tcFilter)
tcFilter= ".T."
ENDIF
SELECT &tcDirField,CAST(SUM(&tcSizeField) as numeric) as ntotal,COUNT(*) as ncnt FROM (tcTable) WHERE &tcFilter GROUP BY 1 INTO TABLE x

ox.foxcharts.sourcealias = "X"
ox.foxcharts.fieldxaxis = tcDirField
ox.foxcharts.visible = .t.
ox.foxcharts.ChartsCount=2
ox.foxcharts.fieldvalue1 = "ntotal"
ox.foxcharts.fieldvalue2 = "ncnt"
ox.foxcharts.Legend2="# Orders"
ox.foxcharts.Legend1="Total "
ox.foxcharts.ChartType = 1
ox.foxcharts.FieldLegend = tcDirField
ox.foxcharts.fieldcolor = ""
ox.foxcharts.colortype = 3
IF EMPTY(tnStartColor)
    tnStartColor = RGB(255,0,0)
ENDIF
ox.foxcharts.color1 = tnStartColor

ox.foxcharts.Title.Caption = tcTitle
ox.foxcharts.SubTitle.Caption = "Pie"
ox.foxcharts.yaxis.Caption=tcTable
ox.foxcharts.FontName = "Verdana"
ox.FoxCharts.ShowValuesonShapes = .T.
ox.foxcharts.DrawChart()

ox.foxcharts.visible = .t.

ox.show()

*!*    logif = _SCREEN.system.Drawing.Imaging.ImageFormat.Bmp
*!*    ox.foxcharts.oBmp.Save("x1.bmp",logif)


It's really easy and even though there are tons of options with it, this piece of code may make it a little easier to work with. If you notice the commented piece out just above, you can easily save the output as a bitmap.

FoxCharts totally rocks!

Sunday, July 20, 2008

Using Scour - Comparing Results

While many sites have compared the search results between Google, MSN and Yahoo, noting that generally they are all the same. I started using Scour recently which puts search results for all three into a single item (yes, it's a Point-based search which is interesting in and of itself but reminds me of most "point-based" systems - you'll never get enough points to make it of use without trying to game it). (you do get to "rate" each search response which may / may not have its own benefits - it's too early to tell).

Yes - the results of all three are generally the same BUT the relevance is interesting. Here's a sample (inspired from a tweet by Marina Martin):

The Pragmatic Programmer - Scour Search

Here are the results:


Notice anything?

1. While Amazon shows as the number one, MSN placed it as the number 1 result while Google/Yahoo placed it as number two. Just because I'm searching for a phrase that matches a book doesn't mean I want the book - it's great that it's there - but if I wanted to BUY the book, wouldn't I likely just go to Amazon or my favorite online bookstore?

2. Both Google and Yahoo link to essentially the same site but with a different URL (Google points to this one  (http://www.Pragprog.com) while Yahoo points to this one (http://www.pragmaticprogrammer.com). But the content itself is IDENTICAL.

3. Google's second result takes you to the main site whereas Yahoo's (doesn't show in the image) takes you to an articles page. which arguably has more details.

What all of this shows me is that the Search for all three companires is still reproducing the same site, trying to put a slightly different spin on essentially the same result. On the entire top 10 list, the same core site is listed 5 times, a book store is listed once (but at the top), Wikipedia is listed twice,  an interview with the authors is listed once , and the book distributor (OReilly) is listed once as well.

Is there really more valuable content on each of the 5 different links from the same site or would a person be more likely to "click" around the site? If that's the case, is it any wonder that people get frustrated by search?

Monday, July 14, 2008

Do you Scale?

Great post by Dare, Scalability: I Don't Think That Word Means What You Think It Does
following up on a post from Scott Loganbill at Google about their choice of "scalable" services.

Scalability is a funny question. Every application is designed to handle a certain type of architecture - it's usually one of those fundamental sales analysis questions "and how many orders do you typically process a day? How many people do you have working for you".

While scalability problems can be due to both technology and design, it's typically design that is the major culprit. (ok, yes, the guy that said he can run a 15,000 transaction a day system in Access - he likely chose the WRONG technology).

But everytime I think of scalability, I always think of 37 Signal's approach to scalability - in short, "Do you really need 12 servers now if you can run on two for a year?" - note read the comments from David Hansson "... Not worrying too much about scaling doesn’t mean building Basecamp on an Access database with a spaghetti soup of PHP making 250 database calls per request. It simply means having a profitable price per request, chilling the f*ck out, and dealing with problems as they arise."

Actually, their better quote is here. "If you've got a huge number of people overloading your system then huzzah! That's one swell problem to have."

Many of these posts and statements are generally made for large systems designed for mass usage. Not necessarily the same issues facing the systems that small businesses or even medium-sized businesses need. But still, just thinking about scalability when designing your databases can help in a big way.

I see silly design decisions that limit scalability all the time and they are generally made for no reason at all. A limit of 2 characters for Sequence numbers - what?!? you're never going to get over 99 items on a single order? Regardless of how unrealistic it may seem, chances are someone will hit it.

And then there are those that become requirements: A 5 character code for a customer ID - then the customer comes up and says I need to use 6. Is that really a scalability issue? Not really - until you've reached 26^5 customer codes, but the customer may perceive it as such. But the whole 26^5 argument does show there is a scalability design flaw in that definition. Will it ever show up? Hard to say.

Two Real Factors
So consider two different factors when it comes to scalability: hw uptime/access (as in can your hardware infrastructure handle a large number of users/transactions) and design (can your application handle a large number of users/transactions). Both go hand in hand yet demand different solutions.

The infrastructure factor can play off the design - if your application is designed for small groups but has lots of small groups, you can always put one group onto another server, if need be.

The Design can detrimentally affect the infrastructure. You can have as many servers as you want but if you constantly pull down lots of records when you only need one, you're asking for headaches.

And One more...
There is one more scalability factor to consider...and it's one that I think many people disregard because it's a Design issue but not so much an architecture design one - it's a user experience scalability design. Many applications were/are built for single transactions (the first web banking site for my bank only allowed one bill to be paid at a time). Just as much as uptime/downtime can play into it, if your application doesn't make it EASY to handle the increase in use, you can just forget about your other scalability problems.

Purists will say "Every software should scale " (and scale infinitely). Pragmatists will say "there will always be SOME scalability flaw in any design".

Think of this another way...even scales have scalability problems - in the design. Many only go to 300lbs. With the obesity epidemic these days, I'm not sure that's a limitation that users can overlook.

Wednesday, July 02, 2008

SQL Server 2008 to ship next week?

That's a juicy rumor. There's been a lot of posts about SQL 2008. It's the last of the next big dev things for 2008 from Microsoft based on the Heroes Happen Here and it's the one piece that I've been waiting for before doing any real production testing. 

SQL Server 2008 to ship next week? > > SQL Server Blog by Jason Massie

Looking forward to it - and if the rumor is true, Congrats SQL Team!

Crashing Fox

OK - so it says Firefox crash - but it's still a great photo. Thanks to Olaf for pointing to it!

Tuesday, July 01, 2008

Blogging the Prague DevCon

Twitter / OlafDoschke on Twitter, is doing an amazing job blogging the Prague Devcon conference.

He's doing it through Twitter at amazing speed which makes it very interactive.

He just finished doing Christof's Guineu session and Mike Feltman's Collection Classes.

I love it when people Live Blog conferences but never thought of using Twitter for it. I'm glad he did.