U's

Alone (ish)

2009-03-28T13:09:00.015-04:00

/* This continues the topic I started in Quantum Observations. For the initiated the point of the article was that the potential spontaneous appearance of an observer on one of the branches of the superposition, however improbable, would collapse the functions making the slightest chance for the appearance of an observer an inevitable fact.
I am arguing that this is the real explanation of the highly improbable appearance of conscious life or more precisely - observers.

I've mentioned that this also means that we are alone in the universe but in what sense?

Many of the questions I got are different versions of the following argument:
When the superpositions collapse, is that a local thing or does it apply to the whole universe? If it is local, can't two separate observers created on two remote galaxies, eventually meet?

Let's start by taking a closer look at our abused kitten. When the poison pill explodes the kitten is painfully aware of it. If it doesn't, it is just lying in the dark, bored and upset. Either way, from its perspective the superposition has already collapsed. Only outside the box is it still undecided. The experiment tells us that superpositions collapse when knowledge is obtained by the observer. The effects are definitely local.

If you are looking at a distant galaxy that only appears as a bright dot in the night sky, you have very little knowledge about it. All positions that manifest as this bright dot are still undecided. In a manner of speaking this galaxy is one big superposition waiting to happen.
Previous arguments are leading us to suspect that the distant galaxy is crawling with intelligent and inevitable observers so why can't we meet them? We invent federal tax, build a huge telescope, turn it on and aloha!
Well, the second we turned on the telescope the superposition collapses to one of its more probable positions and sadly this doesn't include any green men.

The strongest argument for life other than ours in the universe state that if it happened once it could happen twice: there is nothing special about us that could not theoretically happen again. However, if we accept the singularity of observers as the explanation for the appearance of life, there is something that makes us special: we were first (from our point-of-view at least and yes it is a bit confusing but give it some time).

When we say that the appearance of an observer is inevitable, it is true for that specific observer. There are infinite universes with Observers in them but only one observer in each one. We are alone in ours.

* this is using the terminology of the Many-Worlds interpretation of quantum mechanics. If you'd like to use a different interpretation the wording will change but the result would be the same - we are alone in our universe.

* When I say "specific observer", it means all of us on this planet. If the first observer had a way to reproduce, it's off-springs are likely enough to happen. Since evolution (i.e. error prone replicators) happened to be the path that led to our first observer, the second one is part of that same observer "type".

*/

The History of Cameras

2008-12-08T04:31:00.004-05:00

/* I've always been fascinated with cameras. Not the art of photography, mind you but the cameras themselves. The high precision, the complex mechanics and the fact that until recently you could take one apart and understand what each part does and why. Cameras have always been at the forefront of contemporary technology pushing the envelope of mechanical engineering and electronics.

The iPhone is the perfect platform to tell the story of the camera's evolution and, most importantly, try and preserve a small chunk of the user-experience and look-and-feel of these technical marvels.

The result is the History-of-Cameras, an educational iPhone app that covers the major milestones of cameras' evolution and provides a simulator for each one.

I've tried to tell the story as accurately as possible.
For comments, corrections, suggestions and support email me: yuvalperlov at gmail.com

*/

Quantum Observation

2008-02-17T16:42:00.010-05:00

/* This one is about Quantum Mechanics and Natural Evolution. Yes, it is a bit off topic. My blog.

(1) As an historical account of our development, Evolution has one major flaw: It's probability of ever happening is so extremely close to zero. Despite a mountain of corroborating evidence, skeptics still dismiss the whole idea with sentences that begin with "yes, but do you really believe that...". Intuitively and mathematically the chances of life ever starting are slim. Combine that with the chances of life surviving the first few million years and the whole thing seems a bit of a stretch. The common answers are (a) human intuition sucks and (b) the universe is so ginormous, everything is possible. Meh. The problem with these arguments is that they are virtually impossible to substantiate with actual numbers. It is not possible for us to imagine all the possible ways for life to appear and deduce a probability from it.

(2) For the past few hundred years, philosophers and physicists have done their best to ruin our romantic view of the world. Mysticism, magic, even God, have been replaced with boring numbers and formula. However, there is one element that persists despite their best attempts: The concept of the Observer. In quantum mechanics the Observer is a crucial part of any experiment. The theories that try to explain her presence are so strange they make you reminisce old-style, straight-forward witchcraft. If the inquisition ever came across a guy believing in parallel universes he'd be thrown in the bon fire before he had time to say Schrödinger's cat.
Now this particular cat is part of an experiment that demonstrates the strange part of quantum mechanics. A dog lover sticks a cat in a box together with a poison pill. The poison pill will open if something happens on a quantum level. That something has a 50% chance of happening. The dog lover closes the lid on the box, with a satisfactory smile of a job well done. Now the point of this experiment (beside showing the furry bastard who's boss) is that until you open the lid and check, the cat is neither dead nor alive - he is in a superposition: 50% alive 50% dead. Only once the observer opens the box does the superposition collapse and the fate of the cat is decided. This is the common consensus; if you have any problems with this part, write a letter to your elected physicist.

Of course the experiment could be further complicated by requiring two dependent quantum events to break open the poison pill. Now the cat would be 25% dead and 75% alive. The idea is that the events accumulate and all four branches exist in superposition until they collapse into one under the Observer's watchful eyes.

The Observer is somewhat of a mystic entity. There is no clear definition of what an Observer is apart from its ability to, well, observe. Er go that a stone is not an Observer yet Sharon Stone is. Somewhere in the stone-Stone range, matter can become an Observer. It's not just an arrangement of molecules that make an observer. There has to be some level of consciousness (for instance Dr. Livingstone, despite his promising name, can observe no more).

If you are still with me, here comes the fun part: The universe can be looked at as one big Schrödinger box. Only when it first banged into existence, there was no observer to speak of and all those random quantum occurrences simply accumulated creating one huge superposition. With the lack of an observer, the branches just kept on splitting again and again. The probability of each "leaf" was the accumulated probability of all it's preceding branches: extremely close to zero.
Until one warm evening, one of these quantum-lines produced an Observer. At that very moment, the whole superposition collapsed, obliviating all other branches (or sending them off to parallel universes which amounts to the same thing).
One could speculate if the first Observer was a biological cell, a prehistoric fish or Homo sapiens (or one of its close relatives). Whoever she was, she appeared rather late in the game, making the first steps of evolution, the hard ones, not only probable but virtually inevitable.

If you follow this logic, there are some other conclusions to be made:

We are probably the only Observer level entities in our universe. The chances of the same quantum-branch containing two separate Observer level entities, around the same time, are nil. Once we observers begun collapsing the waveform, there can be no more statistical miracles.

If the first Observer is human, then the biblical story of creation is a rather nice allegory. All those improbable creations building up to Adam, the first Observer. Given the fact that without an Observer, time passage is extremely hard to define, even the timeframe sounds about right.
*/

public class U {
    Choice decide(List<Choice> choices)     {
        Collection.sort(choices, new U.ChoiceSorter());
        // Free will, yey!
        return choices.get(Math.rand() > .75 ? 1 : 0);
    }
}

Users

2007-12-02T04:19:00.000-05:00

As posted on 47Hats

/* What do you feel toward your users? Take a second to think about it. Picture them, sitting in concentration, scratching their heads, trying to figure out how to use your latest creation. Make a mental note of your feelings. Keep reading.

My two and half year old daughter has recently decided she wanted to "work" with the computer, just like daddy. I figured painting would be a good place to start so we tried Photoshop for a while. She enjoyed the painting part (throwing the trackball about while colors fill up the screen) but would very quickly get into trouble - she would click outside the window, switch paint tools, hit the start key - the desktop is a hostile environment when you're starting out. Each time I had to help her out, she grew more frustrated, until it became evident that for sanity's sake, hers and mine, I better come up with something. Daddy took a day off and wrote BabyPaint.

The basic requirement was to have a safe painting environment where no accidental key stroke or mouse gesture can have unforeseen consequences. As I was coding along, picturing her trying to use it, new requirements came up: The cursor had to be BIG. She had to be able to select colors but the color palette had to be enormous and hidden until explicitly and easily called up. Mouse button optional. Heavy key strokes ignored. etc. etc.

The software was ready to ship on time (daycare makes for a hard deadline) and was a huge success. She immediately sat down to use the program and simply got it. Plain joy, no frustration (I could tell by the relative lack of high pitched screams). It was my proudest moment as a developer. The application had all the features and polish needed for her to have a positive experience on the first attempt. I also had a great time writing it.

So what (you ask)? Creating software for your kids, exciting as it sounds, is not the basis for a compelling business plan (unless you have enough of them for a long-tail strategy). Well, the point is this: the feeling wasn't new. It was the same feeling I get every time I create an application. I want my users to have a good time and succeed at what they do while also taking pride in my creation (in an infantile "look what I did" sort of way).

Love thy users is a rare sentiment in the software business but it’s out there. Developing software is as much a creative process as it is an engineering discipline. Pen-to-paper, paint-to-canvas, button-to-form. All subject to the taste and personal preferences of your audience. The people that use your software do so because they like your style, respect the decisions and compromises you made and intuitively grasp your way of doing things. They deserve the same love music fans get from their idols (of course, when I say users I mean people who are actually using your software. The people from purchasing, legal, PM group, requirements committee, let them find someone else to love them).

Our users are not only our audience and fans but also the true connoisseurs. Your boss/friends/mother can all look impressed and give you a raise/pat on the shoulder/kiss on the cheek (respectively I hope) but they can't truly appreciate your work - it doesn't address their need. Our users are the only ones who have the time and depth to fully understand the subtleties of our applications. They are the only ones that have the particular itch we are trying to scratch.

This feeling, I believe, is at the heart of all great software. Done right, the actual design, coding and testing become mere details, technical activities that need to occur for a vision to take form. Scrum vs. Agile, Ruby vs. PHP, C# vs. Java are all important questions (well, questions) but are not central to the matter (also, let's face it, you end up writing JavaScript most of the time anyway).

The love for our users, that's where the real advantage of microISVs and startups lies (at least the ones that are in it for the right reasons). That is why the next time someone looks at your software and tells you that it would take an IBM or an HP five days to develop and two more weeks to throw you out of the market, you are allowed a humble smile.
*/

public class U {

    boolean isHireable(Developer developer) {
        return isHireable((Person)developer) &&
            (Interview.testCodeSmithing(developer) * 0.20 +
             Interview.testPassion(developer) * 0.80) > 0.95;
    }
}

Projects

2007-10-04T19:18:00.001-04:00

/* If you try to teach a physicist how to throw a ball you basically have two options: you can describe the forces that affect the ball (hand, gravity, friction) or the transfer of energies (chemical, kinetic, potential, heat). The first is a detailed, moment-by-moment account while the second is a simpler, high level description. It will give our guy some insights as to what goes into throwing a ball with no serious danger of unleashing a ball-hurling-physicist unto an unsuspecting world.

Ready? Here is everything you need to know about software projects, provided you never try to actually execute one (if you want to learn how to do that, I recommend failing miserably at your first project and never repeating the same mistake twice).

A project, any project, is about trading money for some desired output. The trick about managing them is optimizing your expenses and output so your customers and CFO are equally happy (or miserable, depending on the industry you happen to work in).

With software, there are two surprisingly common misconception regarding each side of this simple equation:
(a) Optimizing programmers' time instead of cost. It doesn't matter if you measure your input with dollars - the question is how freely can you use your budget to purchase things that improve quality, such as training, services, hardware, software, etc. If you can't, your input is actually man-months and not money.
(b) Targeting the agreed (and often signed) scope of work. More often than not this approach will involve post-delivery-lawyers or at the very least slowly eat away at a firm's reputation. The real output of a software project is Quality.

On one extreme you can drive down cost by doing nothing. On the other, you spend eternity perfecting your software. Just before that there is a green zone that means your users are at various acceptable degrees of happy.

There are managers, often senior, who'll do anything to cut down the cost of a project. These managers are usually not technical and consider the developers a bunch of misfits that wouldn't be able to find their desk in the morning if it wasn't for them (so they build a maze of cubicles, just to prove their point). They know about the red zone just beyond quality and are terrified of it. They believe it is the source of all their trouble (it almost never is) and often use it as an excuse to ship horrible software ("it would take you forever to get it right so just ship it now"). They are the main reason software is in such a bad state and I hope hell has a special testing department just for them.

Although time goes hand-in-hand with cost it deserves special mention because while the law of Diminishing Returns is at its worst when applied to software, it is often ignored to simplify project planning (by developers too!). Also, managers believe that they can do that because the effort estimations are exaggerated anyway (and they are: if management believes that the budget is exaggerated the only thing left for the developers to do to protect their project is overestimate).
There are no shortcuts: if you want to change your work force for a particular project, you have to make sure you can re-plan it so you actually finish sooner. I've seen projects where taking a few people off the team actually reduced time-to-deliver (btw - if you haven't read the bible, go read it. now. seriously).

Cost and Time are just two (albeit important) factors that affect project success. There are countless others. Every decision during the life cycle of a project trades off some parameters, more often than not, affecting quality.
Which technology to use? What development process to apply? Do I unchain the developers from their cubicles at night so they can go home and watch Seinfeld reruns?
Some ad-hoc decisions are just other ways of looking at money and do not deserve a place on the circle. The ones that do, are the ones that deal with principles or general guidelines that are easy to dismiss in favor of short-term goals. When you draw your circle you have to decide which values are part of who you are and how you envision your work.
Take for instance the happiness of the team. A happy team will create better software. However, happiness costs both money and time (also, too much beer and your happy team might yield some silly creations). There is no "right" place to put the X but you have to make a conscious decision of where you want to be - it will make sure you will get there when the pressure starts to build.

Future and past projects often affect your current project far more than the decisions you are currently making (this also gave me a chance to test 3d modeling software to find the one intuitive enough you can use without permanent brain damage - Rhino). For instance, a common development approach, formally known as Quick-and-Dirty (QaD) trades speed for future quality (watch this for a good description of the effect and other interesting ideas).
Using new, unproved, technology trades present quality for future quality (or, if you happen to choose wrong, for the money it costs to redo everything). If you don't train your people you will get better cost and delivery time until one day you won't be able to deliver anything, etc, etc.
I once worked with a team that wouldn't upgrade their development tool because they were afraid it will let in bugs they weren't testing for. Seven years later they had to upgrade six major releases and ship a version that had some major new functionality, all in one shot. As you might guess, it wasn't their finest hour (the previous versions weren't that great either - teams that do silly things tend not to stop at one).

The Orange tells you everything you need to know about software projects: Quality is what you are aiming for but be careful of overshooting, a lot of other constraints make quality hard to achieve, your decisions in previous projects affect your current project which in turn affects your ability to deliver quality in the future.

The rest is details.

And like any good model, when you run out of dimensions you can put on paper, it's done.
*/

public class U {

    public Action solution(Problem problem) {

        int timeToThink = problem.getComplexity();

        // Turns out it is more important to get
        // it right...
        // if (World.getPressure()==Pressure.HIGH) {
        //   timeToThink = SHOOT_FROM_THE_HIP;
        // }
        return courseOfAction(problem, timeToThink);
    }
}

Quality

2007-09-21T09:23:00.000-04:00

/* Given the amount of energy the software industry spends on Quality it is amazing how elusive it remains (amazing as in stupefying, not awesome) . High quality software is not only hard to achieve but surprisingly hard to define.

For me, quality describes the fitness of the software to resolve the problem it was designed to deal with. Fitness in the Darwinian sense: how well is the individual optimized to the environment it lives in. Quality is also measured by ruthless Darwinian standards: is the software being used (life) or are users doing everything they can not to (death).

Every little detail of the user experience affects its survivability. Quality is not limited to the number of bugs or UI usability. It is also influenced by price and business model (providing the user has to deal with it), deployment method and even intangible properties such as coolness or humor.

Quality has such a broad span because there is no clear cut between a crashing app and the intangible values the software radiates. They are all affected directly by the way the software was designed and implemented.

Take for instance Firefox and Opera (34.5% vs 1.9% market share). They are both free browsers but Firefox is open-source and Opera is not. This is not just a business decision; it goes to the core of the system and affects every aspect of its design, development, feature set, even the way it is distributed.
You could argue that the end-user doesn't care if the browser she is using is open source or not. My argument is that the set of values Firefox is associated with and radiates affects its user experience far more than the way it implements tabbed browsing (given they all have some sort of tabs ... seven!!! it took you seven versions?!?).

Natural Selection as an indicator of quality also leads to some surprising revelations. Consider Microsoft Word (stay with me here). The software everyone loves to hate is by far the most widespread word cruncher out there . This makes it (admittedly by definition) the highest quality solution for word processing in the current environment. Sure its expensive, buggy, unpredictable, user hostile and altogether annoying. However, it is, at the moment, the optimal solution to word processing! This means that the aforementioned qualities are offset by others such as interoperability with other office tools, bundled apps, rich feature set and most importantly current spread and resistance to change (which falls in nicely with the evolution analogy).

This doesn't mean that dominating software guarantees its "safety" but rather that potential competitors will need a significant advantage in quality for the population to tilt towards them. For this reason, there is a good chance, Word's worst enemy is not OpenOffice or Google's hosted solution but rather new versions that tinker with old conventions. Combined with a changing environment (web apps, free alternatives, global warming) this might spell the end of the dominant specie (or not).

But why is it that software quality is so hard to predict it needs an after-the-fact definition? What is the big difference between a mail app and a toaster oven (excluding software embedded ovens that could land the space-shuttle)?

The common reason given, is that software development is complex and a bit fuzzy around the edges. Despite attempts by the academic world and big software houses, it is as close to an engineering discipline today as my late grandmother's cooking. Sure, it yielded good, fairly repeatable, results but was intuition-based and employed some informal methods, which if published could capture the FDA's attention (or some other three lettered agency).

Well, that's part of the story. The other part is the complex ecosystem in which software lives. Just as the optimal length of the cheetah's leg is impossible to calculate, there is no way to calculate the optimum point between Power and Simplicity or Speed and Scalability: there are just too many variables. As an example, take the classic Google vs. Yahoo approach: Only in retrospect is it possible to know that in the search-engine domain, users prefer a simple one-text-box solution to a powerful hundreds-of-useful-links page. Enough so, to challenge the dinosaurs of the time (contrary to the belief of many professional analysts).

So what is the point of these earth shattering insights? First, that great software will continue to rely on programmers with highly developed intuition and will not be replaced with "process" or tools in the foreseeable future. Second, that it is deceptively hard to judge software quality until it's too late. But maybe most important is the realization that I have lately exceeded the recommended dose of Dawkins writings.
*/

public class U extends Person {

   public void introduce(Meme meme) throws Feedback {
      Person origin = meme.getOrigin();
      if (idiots.contains(origin)) {
         //todo: implement a more diplomatic approach
         throw new Feedback("You're an idiot");
      }
      if (cutThroughTheCrap(meme)) {// A bit crude but highly optimized
         if (origin!=this) { // It happens :-(
            idiots.add(origin);
         }
         throw new Feedback("Let me think about this");
      }
      memeDatabase.add(meme);
   }
}

Vista-Rant: A Formal Approach

2007-08-31T17:53:00.000-04:00

/* I've been using Vista for a few seconds now and already I hate the dialog box that pops up, dims the screen, and asks you if it was you who just clicked whatever it is you clicked.
My first reaction was "sure, weren't you here?". The second time, I became somewhat irritated. Now I hate it. Everyone hates it (except for Apple).

My guess is the Vista product team has a 6'8 giant in charge of security called "The Crasher". His first plan was to just turn off the power - "No Power, No Hacker!" (Incidently, The Crasher has a heavy Austrian accent which makes it rhyme perfectly). After many a day of arm twisting they've reached a painful compromise which is what we are dealing with today.

Anyway.

Instead of bitching about Vista like everyone else, I've decided to provide scientific, rock-solid proof that it is a silly feature. We'll start with a premise, contradict it and hopefully the whole thing will just go away.

1. The whole point of this ordeal is making sure the active user never does anything with admin privileges unless she asks for it explicitly.
2. Why? If you are downloading some malware (how many times do I have to tell you Mom, not to open attachments from uifwef23vs@fasdcvs.ru) the damage it can do is limited by the fact that it does not run as an Administrator (that does not include all personal data but we will let this one slide).
3. Once you click continue, whatever it is you are running gets Administrator privileges and can do whatever it wants.
4. A user (any user!) has no way of telling which actions will require a "continue" and which won't.
5. Any program can be configured to run as Administrator which, when launched, triggers the "silly dialog".
6. A potential malware can replace a non-admin-requiring action with itself and make sure it requires admin privileges.
7. The next time our user is trying to perform the "infected" action, Vista will ask if it was actually her that is performing the action. Our user is sure to click continue (see 4).
8. We now have malware running as Admin. For good measure, it can run the actual task so everything looks nice and normal. This contradicts are starting point (1 I believe was its number), proving, once and for all, that the whole thing is just silly.
QED (and good riddance).

PS - Crasher, if you're reading this, I just want to say I've always admired your sense of humor. Also, if you need me, I am temporarily staying at the Hilton Tikrit.
*/

public class U {

   public Set<Thing> queryUniqueThingsICanDo() {
      // return thingsICanDo().removeAll(World.things());
      // Optimized: Found out there is
      // Nothing you can do that can't be done
      return new HashSet<Thing>();
   }
}

Hello World!

2007-08-03T18:48:00.000-04:00

WRITE (UNIT=*, FMT=*) 'Hello World!'
WriteLn("Hello World!");
printf("Hello World!\n");
PRINT "Hello World!"
cout << "Hello World!" << endl;
System.out.println("Hello World!");
puts "Hello World!"
Console.WriteLine("Hello World!");

public class U {
   // Can't wait to see what's next...
   public boolean canWaitToSeeWhatsNext() {
      return false;
   }
}

ABOUT ME

2007-08-03T18:33:00.000-04:00

/* Hello! I am U (not to be confused with You, which I am not).
My full name is Yuval Perlov and I create software for as long as I can remember now (my long term memory is surprisingly short). I also use parenthasis a lot when I write (it reminds a little of code comments, where all the REAL action takes place).
This blog came about as a place to publish my thoughts about software (God knows we need more of those!). More importantly, in the spirit of the open-source movement, I've decided it's time to publish my own internal implementation (like most people, I've been more concerned with exposing my interface).
Feel free to use this code under the open-source license of your choice.

In what can be described as my spare time, I run R-U-ON, the coolest monitoring service on the face of the web! */

public class U {

    private void blogInit() {
        createBlogTemplate();
        writeBlogStuff();

        // The world is a singleton (i hope)
        World.addListener(new Reaction() {
            public void onReadMyBlog() {
                feelings.gratidute.max();
            }
        });
    }
}

2007-8-4	Hello World	Warming up
2007-9-1	Vista-Rant	A formal approach to ranting
2007-9-21	Quality	The cat is out of the bag!
2007-10-07	Projects	Remember The Orange
2007-12-23	Users	Yes, them
2008-02-18	Quantum Observation	A little diversion
2008-02-18	The History of Cameras	"iPhoning"

U's