Software pricing

Regarding this comment in James Robertson's blog, I'd like to point out that most jobs follow this premise:

You will make your ultimate boss earn much more money than you are paid.

This is especially so when you see that today's job market is geared towards job positions that require the least education possible. No education means low salary. If education is necessary, then the job is outsourced to a poor country. Therefore: most people, educated or not, have low salaries.

So there are three kinds of customers:

1. undertaxed corporations which can pay higher prices but usually do so to other corporations,
2. overtaxed people cheated out of a decent salary and a decent education for whom $24.95 is unaffordable - so they cheat back and get the crack from the web,
3. less than 1% in between, to which I think we belong because we have the time and resources to write blogs.

The software pricing problem is just another consequence of thinking it is ok to allow 3.10^2 people to have more money than 3.10^9 others.

I think we need to keep in mind that we are not a representative sample of the world's population.

Have a nice day.

PS: By the way, yes it is true. The top 300 people are worth more than the lower 3 billion people. If you think it's fair, it's because nobody you know is in the lower 3 billion.

Winamp in the background

I like Winamp's AVS plugin. It lets you define whatever visualization you want in terms of mathematical expressions that depend on the sound being played. Very cool.

What I found is that you can tell AVS to be in overlay mode, and then to set the background color to be a mask for the overlay.

Whoa. Talk about an active desktop! AVS' output is then redirected to the background of your desktop in full screen mode - and all your windows and icons go right on top. You can now take a rest from the lava lamp that helps you refresh yourself when you're coding. Now the lava lamp changes all the time behind your windows. Get some AVS preset collections, put them in your AVS folder and it cycles for you. Very very cool!

One of the presets that comes with Winamp 5.0x looks like the oil film lamp a friend of mine told me about sometime ago...

Tenet

Sometime ago I noticed a pattern of problem solving that bugged me. Sometimes, when confronting a problem, some of us have a tendency to procastinate, or get upset and complain about how bad things are, or mention how this is yet another instance of more problems, how achieving world peace would make the problem irrelevant...

... and after a while of this, what happens? Usually in a bad mood, they do what they knew had to be done but did not want to. And because they are in a bad mood, they usually do not find the most positive way of dealing with the issue.

Or you could simply fix the problem. And move on to something else. So:

When confronting a problem, you have two options: you can get upset, complain, and maybe even bitch about it, get in a bad mood and spread the bad vibe to others and then try to fix it... or you can fix it.

Chances are you will find a good solution if you are in a good mood. That's why I like to be happy - finding good solutions is exciting!

Wordsmithing

It's so nice when you find the right words for what you mean... we should work with a thesaurus at hand. These are some selectors I found especially rewarding:

aWindow>>pledgeToPrint
aWindow>>renouncePledgeToPrint

Done in ObjectStudio where different windows would be the ones responding to the Print action as triggered by the File menu item. Totally killer.


aTestCase>>failValidationBecause: aString

As mentioned below, part of the SUnit Validation framework I wrote. And the killer part is that the code can read self failValidationBecause: self isRequired!!!


aComplexCondition>>ifAllTrue:ifAnyTrue:otherwise:

Part of ComplexConditions, a framework I wrote to simplify complicated boolean constructs. Talk about major code shrinking when using these! More on this soon.


Integer>>ones
Integer>>nthPowerOfTwo
Integer>>firstBitsFrom: anInteger

Oh yes, bit manipulation on steroids! And check this out:

anInteger>>ones


^self nthPowerOfTwo - 1

Just beautiful.

Integer>>spaces is also good for padding purposes.

About Squeak 2.0

I wrote a lengthy response to a comment on my posting About Squeak. Take a look if you are interested in this topic.

Proper "abuse" of SUnit

Test cases and user data entry validation have a lot in common - they have the question "does this pass all the tests?" behind.

Since SUnit is an excellent place to formulate these tests, it is also an excellent place to formulate user data entry validation rules. In other words, use SUnit to write your domain object validation rules.

Yes, this is using SUnit in your runtime image in "headless" mode, without the Test Runner.

Not only it works - it really rocks! First of all: SUnit doesn't crash, so your validation won't crash either because of some silly bug like forgetting a nil check or so. You can refactor all your standard checks in validation helpers in some abstract test case superclass so you don't have to write them ever again. And since instance variables have the right names, right? :), then you can have SUnit Validation to write the user messages for you, i.e.:

#dateOfBirth prettyPrint, ' is required'

The validation methods usually come out as two or three liners:

validateDateOfBirth


self aspect: #dateOfBirth.
self aspectIsValidDate.
self aspectIsNonFutureDate

Done with that instance variable... next!

validationWithSUnit.doc

Sample implementation available upon request. My favorite selector is #failValidationBecause: aString.

About Squeak

Once upon a time I also used to contribute to Squeak.

To make the story short, I could not deal with the ever-growing mountain of crappy code anymore, and left. In the Squeak community, it's too easy to get credit for half-baking shitty code. Or, when you don't feel like writing crap of your own, plain stealing someone else's code and stomping your initials in.

There is no reward for cleanup. Squeak is, as far as I am concerned, a few good ideas on top of a horrible implementation. If anybody wants to do serious stuff, please resist the temptation and do not use Squeak.

It is very sad to come to say this, but you also have to consider whether Squeak's soil is the proper place for your esthetically pleasing intellectual seeds. It is not a good place for anything. Whatever is left that is good in Squeak should be immediately rewritten in VW, Dolphin, or some other decent Smalltalk that is not controlled by ruthlessly brute and insensitive people.

Examine the Squeak mailing list over a long period of time and do not miss the pattern. What do the people that stay in the community do? And what do the people that leave the community do?

For the foreseeable future, stay away from Squeak.

Why soccer and number 10

I am a fan of properly played soccer. I have an ever growing collection of soccer videos. It is a lot of fun for me. In soccer, shirt #10 is usually reserved for the most creative player in the team. Soccer's best players have worn #10, and #10 has become a synonym of the best there is.

Being rather unskilled at actually playing soccer, I had to resort to other methods of playing the game. I like soccer computer games. In particular, since 11/30/1990, I have played a soccer arcade game called Football Champ, together with its clones: Euro Football Champ, Euro Football Champ 92, and Hat Trick Hero.

After 14 years of having fun with the games playing always with #10, I made recordings for marp.retrogames.com - a world wide high score registry. They are at first spot, recordings of distilled skill perfected over the years. I am the world champion, and it makes me very happy!

You could ask what could possibly be done that is new after 14 years. The good thing is that even now, every so often, I discover something I didn't know before.

Practice makes perfect, perfect is exciting, exciting is addictive. Long live practice!

About ongoing discussions comparing early type declaration vs. late binding

How easily we forget change!

We can make our code more verbose and the behavior we want to model more explicit by actually coding every little detail and then assume it will be easier to understand (even in the face of papers that imply it's not the case).

But will strongly typed languages, and all their early decisions based on data that becomes more and more inaccurate as time goes by, be flexible enough to adapt to change that comes at an ever quicker pace?

I don't think the "language" life is written on is strongly typed because it would force the being's workings to make all the decisions correctly when they're being done at random. It does not allow for mutations at all. The last time I checked, It Just Does Not Work Like That.

Languages where you have to explicitly declare the type of every distinction, are good for a "commandment tables" style of programming. It's generally assumed that they are good for everybody and everything.

But it ain't necessarily so. IMHO, such monolithic pieces of software are flawed because of an intrinsic inability (or language misdesign so that they are not best suited) to effectively cope with change.

Change happens. Our languages should be designed to be able to deal with change effectively.

I wish this made developers free right now. Unfortunately, I am afraid it will make us miserable first.

Two quotes of mine

Here are two quotes I came up with that I think are worth writing somewhere.

Unnecessary complexity artificially raises the value of small accomplishments.

Why is it that we make complicated things when simple would do? Most software issues revolve around Create, Replace, Update, Delete. It seems to me we should have mastered CRUD 101 some time ago :(. Hopefully soon!

You should do the simplest working thing that could possibly be maintained.

Just simple doesn't cut it if any simple change brings the whole deck of cards down. It has to be simple and malleable enough so that change doesn't kill it. Your software must, like anything that is alive, be flexible to change - or face extinction. And you know change is coming. It is the force that keeps us busy.

Thanks for stopping by!
Andres.