Archive for the ‘programming’ Category
gChartPhp - sometimes life gets the best of you.
Posted by detour1999 | Filed under google, nerdly, programming
yeah..
I haven’t touched gChart in months.
Realistically, I’m not going to… I’m just way to swamped at work.
If someone wants to take over, lmk. I’ll gladly add you to the project.
Otherwise… who knows.
-d.
gChartPhp - progress of a sort.
Posted by detour1999 | Filed under OO, google, nerdly, programming
Real quick:
I had less time than I wanted to to work on gChartPhp this weekend.
In that time I fixed a couple bugs (bar chart bar width calculation for one…) and got x-axis labels working.
I plan to get y-axis labelling working asap. The plan is to allow you to put labels for the y-axis, or just specify how many y-axis labels to have and let it calculate what those are.
That will have to wait until tomorrow.
Also:
Dhaval Patel did a bunch of work to version 2 of the code and got a lot more working. I have been stupidly busy and haven’t had a chance to even look at it, but I will probably put that code up (fully credited, of course) on google code when I commit the axis labelling stuff tomorrow.
So, not as much progress as I was hoping, but progress nonetheless.
-d.
gchartphp - progress will happen.
Posted by detour1999 | Filed under google, programming
Sorry for the general delay.
Holidays and actual “work” have gotten in the way of getting more stuff done/integrated on gchartphp.
I haven’t forgotten.
More will be happening soon.
(let’s call it a new years resolution…)
-d.
google reader sharing: conjecture or inference.
Posted by detour1999 | Filed under google, nerdly, programming, reader, social
I’ve been thinking a lot about google reader and the sharing fiasco over the past couple of days.
It seems to me that the new sharing feature doesn’t really work for anyone. For some, (who communicate primarily through their @gmail.com account) it was way too easy to share with their contacts [NB: I said "Contacts" not "Friends", that's a rather important semantic distinction.] For others (who don’t really use their @gmail.com address as their main email address) it became a series of emailing actual friends for their @gmail.com account. Personally, I had already bothered my friends once (a while back) for their shared items address… I didn’t need to bother them again for their gmail address.
In theory, better integration of friend’s shared items is an awesome idea. I was (and still am to an extent) incredibly excited about it. The problem is in the definition of friend.
The criteria for “Friend”ship in google reader is the ability to chat user@gmail.com to user@gmail.com. That ability comes about either by explicitly choosing to allow chat between users; or by exchanging emails. That is really the core problem with google’s implementation. Conjecture.
I’ve been wrestling with the idea for a while. In my mind, google’s implementation is based on flawed logic, but that flawed logic seemed to stem directly from trying too hard to apply DRY principles.
Say I had a dataset representing a person. I wouldn’t want to store both birthdate AND age. Age can conclusively be inferred by birthdate.
Say I had a dataset representing social interaction. I wouldn’t want to store social connectivity if it can be inferred from existing data, right?
In this case, no.
Given the age example, age can ALWAYS be calculated given a birthdate. Friendship can NOT be calculated based on email exchange. For example, 60% of my “friends”, according to google reader, are people I have bought used volkswagen parts from. Exchanging emails about buying used headlights does not infer friendship. Interaction, yes. Friendship, no.
Inference is good practice. Conjecture is not.
If you can’t get reproducible results ALWAYS (or at the very least, most of the time) it’s not inference… it’s conjecture.
better charts than yesterday.
Posted by detour1999 | Filed under OO, google, nerdly, programming
word.
More playing with the google chart API.
Second cut is somewhat more usable (at least for me).
Check out the “demo” (quotes, as it’s not much of a demo…)
- Limitations as it currently sits:
- no support for lxy, venn, or scatter-plots. lxy and scatter should be available soon… I’ll go into the venn diagram stuff later…
- scaling is in place, but kinda useless until I get axes marked correctly. That’s tops on my priority list for this.
- Some extras still need implementation (chart background, image background, data point markers, etc.)
werd it up.
I am kinda pleased with how the code is shaping up. I haven’t had much of an opportunity in the past to play with inheritence and polymorphism in PHP (blah, blah, blah…).
Currently I have it set up where like so (in terms of inheritence):
- gChart (the base chart class)
- gPieChart (has a simple set3D(bool) function)
- gLineChart
- gBarChart
- gStackedBarChart
- gGroupedBarChart
I will probably refactor that sometime soon. But, I’m happy with how it works currently.
I was concerned for a bit about how I would be losing the ability to change the chart type with one line of code (as I could [and did] with the first draft) by breaking chart types out into separate classes. The fact of the matter is that really, no one is very likely to be doing that anyway. So, better code at (perhaps) the sake of some usability…
My plan for next week: axes labeling, those last three chart types, and what’s left of the “extras”.
I put the latest class (gChart2.php) up on google code if anyone wants to see. I’m sure there are plenty of ugly things in there… I’m still getting used to a bunch of things.
-d.
ps.
Venn Diagrams. WTF?
according to the docs:
Supply one data set where:
* the first three values specify the relative sizes of three circles, A, B, and C
* the fourth value specifies the area of A intersecting B
* the fifth value specifies the area of B intersecting C
* the sixth value specifies the area of C intersecting A
* the seventh value specifies the area of A intersecting B intersecting C
Couple things…
Always three circles? No matter what? WTF?
The three circles are relatively sized, but the intersections are not? So nothing is to scale?
Like so: A=300, B=200, C=250, A∩B=10, B∩A=10, C∩A=0, A∩B∩C=0
…fucking nevermind.
those first three values (A, B, C) NEED to be scaled by the user. Anything over 100 will be 100. so, that example above, if those circles look equal, that’s cause they are. I should be able to have Venn Diagrams knocked out soon. UGH. Way too much time wasted trying to figure out wtf that “the relative sizes of three circles, A, B, and C” was supposed to mean.
Update: 12/9/07 21:26
Venn Diagrams are working and on that demo page.
I’m still non-plussed with the implementation. Whatever.
-d.
more charting…
Posted by detour1999 | Filed under OO, google, nerdly, programming
alright.
I’ve been playing with a php wrapper for the google chart API.
My first cut of it kinda sucks. But here it is…
- Limitations as it currently sits:
- only 1 data series per chart (yeah… I’m working on it…)
- scaling is not in place yet (had it working, then introduced a bug in arithmetic somewhere…)
- colors and “extras” haven’t been implemented yet. (They will be.)
werd up.
I will admit, it’s nice to use as an object.
More to come. My plan for tomorrow is: proper scaling, multiple data series, and all the “extras”.
(I put together a project on google code… I don’t have an SVN client on my mac yet, so I haven’t committed anything yet. I put the basic class in the downloads section, if anyone actually wants to see it.)
werd.
-d.
charts w/ the google chart api.
Posted by detour1999 | Filed under general, nerdly, programming
What if there was something that could merge a sad love for data (and the display thereof) and a disturbing affinity for the web and its development.
What if.
What … t f
Oh hell yes. A relatively simple API that will generate a simple .png of a chart based on data you pass it. Awesome.
so, I had some fun playing with it today.
It’s pretty damned easy to use and puts together some pretty nice results…
not too shabby, right?
Harper suggested I write a php wrapper for the api.
I told him it almost wasn’t worth it since the API is so easy to use. However, being the sad, lonely man that I am, I spent my friday night playing computers.
So, after playing with the API for a couple hours, I have some issues…
- No support for negative numbers. None. WTF?!
- Bar/Line charts only support numbers <=100
check it out:
Lame.
But, there are ways around most of these…
all data needs to be converted to a percentage. So, 1000|100|10|-10 would become 100|10|1|-1.
Negative numbers are still an issue… some people over on the Google Chart API Google Group were talking about adding a second set of data to mimic the x-axis to get the display of the negative number to kinda work.
I decided not to bother with that just yet.
So, I started working on a PHP wrapper for the API that took all of these things into consideration…
…which I should have kinda working this weekend.
-d.
oo thanks.
Posted by detour1999 | Filed under OO, nerdly, programming, work
I’ve been thinking about object oriented development of late.
Ive been doing OO dev for about 8 years now… (C# for about 6 year, and VBA/VB6 for a couple before that, mostly windows apps.) I’m kinda ok at it.
Recently, i’ve been doing a lot more OO dev in other languages. (specifically js and php)
And it comes pretty easily…
…and I’ve been wondering why.
…
Also, it’s cold here in Chicago.and whenever it gets cold, I get sentimental and stuff…
…And i realized that I’ve been super lucky to have great co-workers to learn from.
so, that being said…
Jeff really realigned my thought process to an OO way of thought.
Mike and Rick help to make me passionate about doing OO as right as possible.
Brian got me thinking about OO on the web with a web appropriate language.
Harper gets me thinking about doing stuff outside of OO, and breaking my reliance on msft. (And gave me a shot at my new job @ skinnyCorp.)
Bryan refuses to ever take anything I say at face value, and forces me to really think about why we should do anything.
werd.
thanks guys…