Paul Krugman explains why 2010 should be the year of China, in a sense. His parting words may be addressed at the wrong reader -- who has nothing to gain from such advice --, but that's just another, more understated way, to tell all others that the time has come for a change. Though I wouldn't -- who would? -- expect things to change that much in 2010 (or at any other time), his words are well read and his arguments are convincing.
Friday, January 1, 2010
Wednesday, December 30, 2009
greener...green...gr...grrr...gray...grayer...grayest
More reflections on expatriation this morning. Later, coincidentally, while reading my daily dose of economist.com, I caught a new article on that very topic. It sums things up nicely and I would recommend it to anyone who is out there, far away from their home.
And (harsh) justice for all.
A friend of mine and I discussed this sad story over lunch today, and we agreed that the sheer lunacy of attempting to smuggle 4kg of heroin into China by stashing it in luggage registered to one's name -- such were the accusations against him -- bogs the mind. An accuser would have to be either simpleminded or delusional to not recognize such a fact, after some deliberation of course.
Which brings this proverb -- apparently of African origin -- to mind:
in times of trouble, leniency becomes crime
Tuesday, September 23, 2008
Apples and Nuts
15 days into the tracking, patching, testing, cussing loop from hell. Familiar whining this. It pretty much epitomizes the life of a hacker.
The iPod Touch remains in its original box, untouched, waiting for the next (Palm OS) release of ninerpad (will it? ever?).
But I like to peek. So I waded, again, through the iPhone SDK (hush hush Apple may be listening) docs. Things are becoming clearer.
But then, this very interesting post by Michael Ash. It helped put things back in perspective.
Yes, the iPhone oasis may beckon, but you may want to reconsider drinking from its pool. The process of getting an app on the iTunes store is not as simple as it is for Palm (mobireach, my cart provider, makes the process a google times simpler). But that's not the main issue for me. Learning has its curves, like many good things, so it can't be that bad.
No, my main beef is that Apple will not remit royalties to participating developers until their net reaches 250$. Granted, if your paid app is hugely popular, that may come fast and easy. But if it is not -- and that is the most likely (just do the math) scenario "for the rest of us" -- , it may take months before you see that first payment. Nice? Not.
But I'll try anyway. After all, nobody likes to miss a boat, any boat, no matter how small.
Still, just to keep things on an even keel, I think I'll stick around for a while with the Palm OS and with my friends at mobireach.
And now, back to our regular programming: cussing at Palm OS 5.
The iPod Touch remains in its original box, untouched, waiting for the next (Palm OS) release of ninerpad (will it? ever?).
But I like to peek. So I waded, again, through the iPhone SDK (hush hush Apple may be listening) docs. Things are becoming clearer.
But then, this very interesting post by Michael Ash. It helped put things back in perspective.
Yes, the iPhone oasis may beckon, but you may want to reconsider drinking from its pool. The process of getting an app on the iTunes store is not as simple as it is for Palm (mobireach, my cart provider, makes the process a google times simpler). But that's not the main issue for me. Learning has its curves, like many good things, so it can't be that bad.
No, my main beef is that Apple will not remit royalties to participating developers until their net reaches 250$. Granted, if your paid app is hugely popular, that may come fast and easy. But if it is not -- and that is the most likely (just do the math) scenario "for the rest of us" -- , it may take months before you see that first payment. Nice? Not.
But I'll try anyway. After all, nobody likes to miss a boat, any boat, no matter how small.
Still, just to keep things on an even keel, I think I'll stick around for a while with the Palm OS and with my friends at mobireach.
And now, back to our regular programming: cussing at Palm OS 5.
Friday, September 5, 2008
Palm developer vacation spot du jour: iPhone SDK
ninerpad 1.1R2 is out, at last. Time to take a short break and open that iPod Touch box...
Links of interest:
Links of interest:
- iPhone GUI PSD will come in handy for UI mockups
- Hand Picked iPhone Application Development Resources
- ninersim...
Saturday, August 30, 2008
Christmas in August
I bought an iPod Touch yesterday. I justified the purchase as a necessary investment in my career as a wannabe independent software developer.
At the same time, though, another voice spoke, much louder this time. It was the kid in me, and he said: "Cool. A new toy!"
The iPod Touch (iTouch) looks like an expensive toy. It's cute, and sleek, and eye candy jumps out at you as soon as you turn it on. How can one resist? And I thought to myself "Ah, Apple design..." And as I did, Venice came to mind; not the city as much as the feel of it; the way I would have said "Ah, Venice..." if I had been there (as I have).
One could say that there's a little bit of Venice in every Apple product.
Later, I skimmed through the developer documentation, trying to get my bearings and preparing the ground for my next -- and first iTouch -- project. By the time I was finished, my inner developer too was feeling the rush: "... so many cool APIs... so many possibilities... so much... nerd candy".
And no wonder today was a special day. Three significant fragments of my personality were in agreement, for once. Pleasure delayer that I am, I still haven't opened that box, though. It sits there in my bag, waiting for that moment when fragment #1 says "okay boys, let's open the presents and start coding".
I can't wait.
At the same time, though, another voice spoke, much louder this time. It was the kid in me, and he said: "Cool. A new toy!"
The iPod Touch (iTouch) looks like an expensive toy. It's cute, and sleek, and eye candy jumps out at you as soon as you turn it on. How can one resist? And I thought to myself "Ah, Apple design..." And as I did, Venice came to mind; not the city as much as the feel of it; the way I would have said "Ah, Venice..." if I had been there (as I have).
One could say that there's a little bit of Venice in every Apple product.
Later, I skimmed through the developer documentation, trying to get my bearings and preparing the ground for my next -- and first iTouch -- project. By the time I was finished, my inner developer too was feeling the rush: "... so many cool APIs... so many possibilities... so much... nerd candy".
And no wonder today was a special day. Three significant fragments of my personality were in agreement, for once. Pleasure delayer that I am, I still haven't opened that box, though. It sits there in my bag, waiting for that moment when fragment #1 says "okay boys, let's open the presents and start coding".
I can't wait.
Thursday, August 28, 2008
Shortcut #2317
About that ninerpad background color preference... It seemed like an easy-to-do feature request at first. People asked for a way to set note backgrounds to a color other than white and I was going to give it to them.
(this post courtesy of Palm OS 5's non-support of alpha channels by the way)
ninerpad works in 8 bit screen depth mode. This means that you only have 256 colors to play with, upside being that the drawings take a lot less room to store, and can thus be commensurately larger or numerous. Good for note taking, that.
Now, to store a drawing, I need to give every pixel a value. I mean, there is no such thing as a non-value. So, 4 months ago, at version 1 design time, the answer came easily: fill blank drawing data with zeroes, one for each pixel (compressed data actually, hence fewer bits, but that discussion is for later).
And therein it lies: zero happens to be the only index for the color "white" in the Palm system palette. No other color well in that palette gives us that.
So, if I want to let users draw in white over, say red, I have a problem. I can let them draw in color zero (white) over red, sure, but what about those other empty pixels then, those that they did not draw over and yet that need a storage value?
The answer lies at the bottom of the ninerpad's BG color selector (inside Preferences). You will notice that one of the color wells down there is also set to white. That well, #254, is a cheat. It was reconfigured from its default color, black, to white.
Now, when you draw in white, you are actually setting those pixels you draw over to hold color value 254, instead of 0. When I read back the data, I overlay non-zero-index data over the BG color and presto, you can now even draw in white over white, if that strikes you as shiny. The drawn data will still be there.
Somewhere a bug lies in ambush, waiting for that right moment. I know this. And when it does, it will likely appear as some kind of display glitch, i.e., something appears in white that should have been some other color.
ninerpad restores the system palette to its default values when it exits, so other apps are safe. But if some 3rd party application pops something up over ninerpad while the later is active, the bug may show its ugly (white) head.
Waiting for that day, and asking: must every shortcut come at a price?
(this post courtesy of Palm OS 5's non-support of alpha channels by the way)
ninerpad works in 8 bit screen depth mode. This means that you only have 256 colors to play with, upside being that the drawings take a lot less room to store, and can thus be commensurately larger or numerous. Good for note taking, that.
Now, to store a drawing, I need to give every pixel a value. I mean, there is no such thing as a non-value. So, 4 months ago, at version 1 design time, the answer came easily: fill blank drawing data with zeroes, one for each pixel (compressed data actually, hence fewer bits, but that discussion is for later).
And therein it lies: zero happens to be the only index for the color "white" in the Palm system palette. No other color well in that palette gives us that.
So, if I want to let users draw in white over, say red, I have a problem. I can let them draw in color zero (white) over red, sure, but what about those other empty pixels then, those that they did not draw over and yet that need a storage value?
The answer lies at the bottom of the ninerpad's BG color selector (inside Preferences). You will notice that one of the color wells down there is also set to white. That well, #254, is a cheat. It was reconfigured from its default color, black, to white.
Now, when you draw in white, you are actually setting those pixels you draw over to hold color value 254, instead of 0. When I read back the data, I overlay non-zero-index data over the BG color and presto, you can now even draw in white over white, if that strikes you as shiny. The drawn data will still be there.
Somewhere a bug lies in ambush, waiting for that right moment. I know this. And when it does, it will likely appear as some kind of display glitch, i.e., something appears in white that should have been some other color.
ninerpad restores the system palette to its default values when it exits, so other apps are safe. But if some 3rd party application pops something up over ninerpad while the later is active, the bug may show its ugly (white) head.
Waiting for that day, and asking: must every shortcut come at a price?
Subscribe to:
Comments (Atom)
Subscribe to ninermentia
Posts
All Comments