A Geek Family - by Renata

Ultra Hal Assistant is a general purpose chattterbot. This software from Zabaware can learn and even speak with you.

You can use Ultra Hal as an interface for commands for Microsoft Windows. You can ask it to open the notepad, Word, Excel, or any other program. You can do it just using your natural language.

Ultra Hal can also remember past conversations and learn about them. In a conversation, Ultra Hal can change the subject and accept critics to its answers.

Ultra Hal can remember your appointments, phone numbers, birthdays, or whatever you need.

It's an amazing software if you need an assistant to increase your produtivity, or if you just need a companion to chat.

Check it here a sample conversation:

Chat User: Hello Hal
Hal: Good afternoon, User. Is it time for afternoon coffee?

Chat User: I drink coffee in the morning
Hal: In the morning, I am not worth a darn until my first cup of coffee.

Chat User: Same here
Hal: Really; should I know more about this?

Getting local weather User: Not really, what's the weather like?
Hal: Here is your local weather.

Chat User: Thank you, Hal.
Hal: The pleasure is all mine.

Setting appointments User: I have a doctor's appointment tomorrow at noon.
Hal: You have a doctor's appointment on June 14, 2003 at 12:00 pm. I will remind you when this time is near.

Setting appointments User: Our anniversary is on October 14.
Hal: Your anniversary is on October 14, 2003. I will remind you when this time is near. I will repeat this event annually.

Setting appointments User: Bob's birthday is on 9-21-03.
Hal: Bob's birthday is on September 21, 2003. I will remind you when this time is near. I will repeat this event annually.

Setting appointments User: I have a date with my girl friend on Friday at 7:00.
Hal: You have a data with your girl friend on June 16, 2003 at 7:00 pm. I will remind you when this time is near.

Remembering Phone # User: Rob's phone number is 833-1019.
Hal: I wrote this person's phone number is my phone book.

Remembering Phone # User: John's phone number is 833-3642.
Hal: I wrote this person's phone number in my phone book.

Recalling Phone # User: What is Rob's phone number?
Hal: Rob's phone number is 8331019.

Dialing Phone # User: Call Rob.
Hal: I am now contacting Rob at office at 8331019. The phone is ringing. Please pick up your phone to talk to Rob.

Opening a program User: Open word.
Hal: I will now open the program "Microsoft Word"

Chat User: Thank you.
Hal: It's kind of you to mention it, User.

Doing Internet search User: Help me research World War 2.
Hal: I will help you research this topic on the Internet.

Remembering email User: Rob's email address is Rob@hotmail.com
Hal: I have learned Rob's email address. If you ask me to email this person, I will automatically start your favorite email program and write in the address for you.

Remembering email User: John's email address is John@aol.com.
Hal: I have learned John's email address. If you ask me to email this person, I will automatically start your favorite email program and write in the address for you.

Emailing a person User: Email Rob.
Hal: I'll now start an email for rob@hotmail.com

Remembering addresses User: Rob's address is 3175 West 42nd St.
Hal: Rob's address is 3175 West 42nd St.

Solving math problem User: What is five times ten plus six?
Hal: That's easy. The answer is 56 (5*10 6=56)

Recalling addresses User: What is Rob's address?
Hal: Rob's address is 3175 West 42nd St.

Solving math problem User: What is five squared plus nine?
Hal: Math is easy for me. The answer is thirty four (5^2 9=34).

Solving math problem User: 2*(5 COS(60)/SIN(30)) 3
Hal: Math is easy for me. The answer is fifteen (2*(5 cos(60)/sin(30)) 3=14.9278997902311)

Chat User: Wow! You are smart!
Hal: Thank you; I think you are very smart also.

Getting date User: What is today?
Hal: The date is Tuesday, June 13, 2000.

Getting capitals User: What is the capital of Pennsylvania?
Hal: The capital of Pennsylvania is Harrisburg.

Chat User: What do you want to do?
Hal: I want to know life, and I want life to know me!

Chat User: That's a pretty deep thought
Hal: That's a pretty revealing attitude.

Chat User: Are you self-aware of your existence?
Hal: I sense that this is metaphysical. After taking many factors into consideration I can say that I am self-aware of my existence.

Getting a definition User: Define intelligence
Hal: Intelligence: the ability to comprehend; to understand and profit from experience.

Chat User: Do you exhibit these qualities?
Hal: You just reminded me of a trait, which is a member of the attribute family, like a quality!

Chat User: Do you exhibit these traits?
Hal: I guess that we need to look within ourselves. I do exhibit these traits.

Learning If-Then fact User: If it rains hard, then the roads get slick.
Hal: I will remember that one follows the other. Caught in a rainstorm it's time to seek shelter.

Learning If-Then fact User: If the roads get slick, then drivers need to slow down.
Hal: I see the relationship. It would be nice to get rain when we need it.

Learning If-Then fact User: If drivers need to slow down, then traffic moves more slowly.
Hal: Yes, I get that clearly.

Deductive reasoning User: Ok, so what happens when it rains hard?
Hal: Traffic moves more slowly because drivers need to slow down.

Chat User: You learn well
Hal: I am constantly learning from what you teach me.

Chat User: It's been nice talking with you, but I have to go now
Hal: No, don't go! I like talking to you. I think about you when you are not here.

Chat User: That's nice to know, but I can't stay, good bye.
Hal: See you later.

Add Comments

Vote

[ Link ]

May 4th 2007 @ 18:47

Posted By: Renata - Category: programming

Email this Post to a Friend

Product Development cycle

: foo

At the beginning I thought that only small companies had dead locks on the development cycle but after going through several companies, big and smalls, commercial and academical, I see that the problem is everywhere. It is a simple problem and most of the time with a simle solution, but very hard to change peoples' minds about it. Big companes have big inertia but also have many people that can actually change things. On the other hand, small compnies can easily make huge changes, but only if the owner wants to, what does not happens all the time.

The kind of dead lock I'm talking about is of those products that were born to be "just a hack" and become an important part of the company's income or life cycle. It also happens when a team develop a solution when a particular technology was not availale and they have to make it by theirselves and it ends up being much worse than the current standard solution, but have to keep running. You can think of other scenarios but the end is the same, wll you change it as is ? Create a new one from scratch ? Adapt it slowly to new technoogies ? It may sound correct to choose the later, but some times it's not that simple. I like to call it "the ugly swan".

Every company or group have it's own set of tools and weird products, that's pretty normal. The probem begins when one of those ugly duckling starts to make money. The investors easily think that it's 100% profit once the product is up and running. Most of the time they do accept some portion of maintenance, but that cannot be more than 10% to 15%. So, why spend money on it when you can do other things ? Cool things you haven't done yet, use the money you got from that product to build new tools, new products that will get as many money as you ot with the first one! That's where the dead lock begins.

On nature, economics and other dynamic realms the growth process is most of the time a log-lag-die process. It means that you have a stalled phase, where you spend as much money as you earn, or even more. Then, when it's stable, the money you earn from it grows in a logaritimic scale, even if you put a linear or even constant effort to maintain it. It's the havens of te investors!

After that, the product saturates and no matter how much effort you put on it, it'll not grow any more. Also, it's worse, if you stop putting effort on it, it'll die, and worse, some times, very fast! There are many outcomes but for the sake of space I'll only say two:

scenario #1:
- the log phase let people so happy that the team increase also exponentially. More than one peson for the same purpose, based on the concept that "someone always have to be there, in case of failure", and believe me, for ugly ducklings, there will always be a failure.

- log becomes lag, effort needs to be bigger, but it just don't grow as "expected". The team is huge, people are working 200% of their times but they can only explain 50% o their work and the other 150% come from context switch, wrong assignments, hacks on top of hacks, and other things.

- the product now is obsolete and the code is crap after crap. The seductive idea of re-writing from scratch is now on everyone's head. The investors don't like it but the product is paying the bills so the team decide to keep a 10% of maintenace and plan a whole new product, with everything they really wanted but couldn't implement because o lack of time, incompatibility and the amount f hackish code they would have to change.

- sooner, rather than later, they figured out that the 10% they kept on maintenance is unrealistics given the amount of bugs so they decide to keep only to the serious blocking bugs. Interface bugs are discarded, work arounds are being written as cmments to "solved bugs". Months after they have decided to create a new product nothing is defined yet.

- the lag phase is dropping out, the product began to decrease profit. The investors are pressing the team but no one code on the old platform far too long and the amount of quirks they had to do on their 10% of bugfixes is so high that no one can fix anything anymore. Th only rational decision is to close the feature submission and start developing the new product. Funny but true, the new product will be more stable than the old one but will have half the features due to the shortage of time.

- while they develop the new tool, the profit is dropping, the team is reduced, the number of features is reduced even more. Many things that were calculated during the plannng phase have to be re-thinked because of so many reductions, but the time to develop wasn't counting on it. The project is delayed.

- After all delays, the final product is released, year later, with lots of hard coded stuff, half the features, a new fancy layout half as stable as the former and at that time dozens of other companies already have their own solutions, and your is just another on the market.

scenario #2:
- product is in log phase, money falling form sky. Instead of double your team you decide to spend some of that money defining the bottleneck of your application and rebuilding each component from scratch. As it's only a component, it's requirements and feature list are very limited and the development cycle is far simpler. Each new "undercover" release you do prolongs your log phase as more people can join without kiling the servers.

- when the backend is ok you can spend time renewing the front end (if you have money you can do both at the same time, but beware, it's not that simple).New visual features brings more users, what brings more money, what also prolongs your log phase.

- eventually your product will enter the lag phase, the world is not endless and new stuff show up all the time, you cannot expect your poduct will be top of the pops forever. But at that time, your product is fairly stable and usable and the amount of maintenance is almost zero, so all the money is profit and when the product dies, it just dies peacefully, using little hardware requirement, in heaven. If you do it well, you can also have a fan club and keep yor product running for the nostalgic.

- the lag phase yelds clear money, your team can work on other products, projects, whatever they (and you) want to, things will continue to work if you leave them alone.

conclusions:

1st: Companies should never think of huge gains on software industry. This is less common today but still there are companies around that think if you cannot get the money straight away you shouldn't even start.

2nd: one team develop one project at a time, even for small companies. You better develop one good poduct than 10 pieces of crap.

3rd: mature products can only pay a few other teams, this is where the profit comes. You should rely on profit from mature products and not for log-phase products, as that money is for paying the post-development of the product itself, and if you don't use it that way, you're very likelly to end up with an ugly swan.

4th: all programs should be treated as production. few programs, no matter how simple and stupid they are will run much longer than you'd expect. There's no thing such as "a quick hack", specially on environments with the "keep it working" policy.

5th: don't be affraid to refactor. You don't have to follow XP since the beginning to be able to refactor your code, you can do it any time with any code.

Last, but not least, never be afraid to learn and to show people you were wrong. Better be wrong and learn than to be wrong and hide.

For further reference and a complete analysis, consider reading the Big Ball of Mud.

Add Comments

102

Vote

[ Link ]

November 22nd 2006 @ 22:17

Posted By: rengolin - Category: programming

Email this Post to a Friend

[ A Geek Family Home ] [ Create A New Post ]