Wednesday May 31, 2006 Seapegasus Blog
Wednesday May 31, 2006 And the Oscar Goes to... a Book? (2)
As promised last month, here is the interview with one of the NetBeans FieldGuide authors, Patrick Keegan. The page also includes links to sample chapters to read, and to online-shops where you can order the book.
In order not to restrict ourselves to Quicktime or WMF, we published the movie in the 'neutral' Flash format. So far, so good. Unfortunately we realised, there is still no Flash player v8 for Linux... Oh well. In the meantime, Linux-user like us will have to reboot or respectively use MoL or Wine to see the interview, like I just did, and it's worth it! Do you recognise the location from my earlier photo? :)
Quick poll:
- Would you like to see more NetBeansTV-style interviews like this one?
- If yes, which subjects would interest you most?
- Do you have access to Flash 8?
PS: Last thing I heard was that there will be no Flash 8.0 for Linux, ever! :( Instead, Flash 8.5 will be renamed to Flash 9 and be released for Linux. Next year! :-( *sigh* Read penguin.swf for the latest news.
Posted by seapegasus ( May 31 2006, 12:30:08 PM CEST ) Permalink
Monday May 29, 2006 Those of you who were at JavaOne, remember the game consoles in the hang zone? The Bash party with the Dance Dance Revolution box for the ladies? And the Halflife game against a pro-gamer for the boys? (where every match ended 0:25)? That was all nothing -- thanks to community developers and hack^H^H^H^Hextendable APIs, this is what we will play at the next conference:
PS: wii?!: "However, the name is unlikely to go down well across the large swathes of the English-speaking world - including the United Kingdom - where "wee" is a very common children's slang phrase for the act of urination. In Scotland and Ireland, however, the diminutive console will at least be appropriately named, as "wee" is a word meaning "small" in the vernacular of those regions." ... In German, "wii" sounds like "Wie?" ("Pardon me?"), and in French it sounds like "oui" ("yes"). European gamers are bound to have some interesting conversations in the near future.... >:-D
Posted by seapegasus ( May 29 2006, 07:38:51 PM CEST ) Permalink
Sunday May 28, 2006 The DaVinci Quote - now in a blog near you
Dude. Why are these DaVinci Code guys puzzling over paintings when they could solve much more interesting mysteries right there in the movie database! :-) You know how even eye-witness testimonials often remarkably contradict each other in some points? Well, you don't need a crime scene for that to happen, just look at these two 'DaVinci Code' quotes from the IMDB quote collection that (I assume) were contributed to the database from memory:
Sir Leigh Teabing: Shall I serve tea or coffee?
Robert Langdon: Tea.
Sir Leigh Teabing: Precisely. Now... what shall I put in the tea... milk or lemon?
Sophie Neveu: [whispered to Langdon] Milk.
Robert Langdon: That would depend on the tea.
Sir Leigh Teabing: Very good. Now, the last... in what year did a cocky Harvard
professor outwit a great Englishman?
Robert Langdon: Surely such a travesty has never occurred.
Sir Leigh Teabing: Well done. You have proved your loyalty
Sir Leigh Teabing: First, shall I serve coffee, or tea?
Sophie Neveu: I would think in England it's customary to serve tea.
Robert Langdon: Tea!
Sir Leigh Teabing: Correct. Next question, shall it be served with Lemon or Milk.
Robert Langdon: It would depend on the drink now, wouldn't it?
Sir Leigh Teabing: Correct! Now finally, the last question. Now tell me in which
year did a Harvard honor student defeat an Oxford student at history?
Sophie Neveu: [after a long pause] I don't think ever Mr. Langdon.
Robert Langdon: [Reluctantly] Never, Leigh.
Sir Leigh Teabing: [Laughs] Correct. Now, come along inside.
Hmmm... So, in the first version of the dialogue, useless Sophie remains mostly silent and Langdon 'passes the test' by ignoring the one wrong answer she whispers to him ("milk"). In the second version, Sophie saves the day by prompting two of Langdon's correct answers and never even suggests the third (wrong) one... Well? Which of the two versions is closer to the actual scene shown in the movie (that I haven't seen)? Or was it maybe teamwork, neither knew all the answers, but together they got it right?
Moreover, in the quote collection, there's a third (different) version of the Oxford/Harvard question: "In what year did a Harvard man out row an Oxford man?" WTF? Allright, the witnesses (movie audience) agree Leigh was questioning the victory of a Harvard person versus possibly an Oxford person. We don't know whether it was about students or professors, or whether the disciplin was history, wits or rowing. Isn't it scary to see how human memory and perception doesn't get obvious things right, not even replayable movies that everybody supposedly sees and hears from the same perspective?
PS:
FWIW and on a more serious note, so, what about the hype? Allright, you and I know the DaVinci Code is fiction, and you and I know which plotpoints are made up; groovy. Still, each and every advertisement I've seen play-pretends the Code's a documentary. The taglines are all "Can it be true that <insert scandal here>? And what if <rumour of your choice>? Waaait, we never said that! It's only an old marketing joke -- get it?" More damage is done by these ads than by a simple fiction book's content.
IMHO, the threat perceived by opponents is not that a fiction story might make believers lose their faith, but that it might mislead as yet uninformed people. I like being entertained by fnord about Legolas, Harry Potter and James Bond as much as the next person. But there are many who don't know bleep about the historical background of (say) Christianity — except for what they see in the media. <sarcasm>So, what's the next movie for your children and neighbours to watch? A shocking (but of course fictitious) thriller about how all democratic elections are fraud? Or a self-incrimating (but of course fictitious) drama focusing on 9/11 attack conspiracies? Why not? It's all free speech and obvious fiction, isn't it?</sarcasm> The media are a tool, they have an effect, we shouldn't pretend it's only about entertainment.
Monday May 22, 2006 Your Mobile Wants You To Know This
Java ME, here I come. ;-) Yesterday after coming home JavaOne, I talked to a nice Swiss business man and he spontaneously gave me his old Motorola, simply because he just had bought a new one! :-o (And no, it wasn't stolen, he had the cables and original Software on CD and all.) And as we all know, having a "set" of devices (I just bought a Nokia last week) to test apps on is the first step to Java ME development... :-)
At least that's what Rodney Aiglstorfer (?) said at his Java ME Troubleshooting session at JavaOne 2006. He did not only reveal his secrets of the trade (see below) but also made me aware of the differences in the USA and European markets: Neither did I know that a lot of Americans use mobile phones without SIM cards, nor that SIM card phones are refered to as "GSM". Probably in Europe nobody talks about this distinction because there is only one system, as opposed to the USA where you choose between GSM and CDMA.
Asia and Europe are already huge markets for Mobile applications, and the USA is about to catch up: Looks like good business perspectives for professional Java ME developers. Here are some interesting items form the JavaOne JavaME Troubleshooting session:
Debugging and Testing
- The big Java ME development secret: "Run once, test everywhere". If you are a professional Mobile developer this literally means purchasing and testing each device, or at last device family.
- Workflow secret: The first 90% of testing is done on emulators. Then you test the app on a device family (e.g. S60 phones) and then on a random selection of individual devices. Members of a "device family" in this sense do not have to be from the same manufacturer, you cluster them by features that are important to your kind of application.
- JUnit test secret: Only the GUI should need human testing - all other tests should be done automatically. Use ME4SE as MIDP library when running JUnit tests.
- Debugging secret: For most developers, the only way to debug mobile apps is using System.out.println() ... You can also write your own logfile to the Record Management System (RMS).
- Tip 1: I want to pipe in that NetBeans Mobility Pack comes with a debugger, e.g. for Siemens and Sony Ericsson devices!
- Tip 2: Declare a final static boolean and use it as a debug print switch -- in the deployment version, staticly false if-statements will be automatically stripped out by the compiler.
- Tip 3: MobileComplete.com is a remote device testing company who can provide you with test results of your application on any number of devices.
Java ME Tools
- For Java ME development you need the Sun Wireless Toolkit WTK. Some tools even offer artificial clockspeed delay etc to simulate the response (or lack thereof) of slow devices.
- There are still people out there developing sucessfully with only emacs + ant. :-) Other alternatives are the NetBeans and Eclipse IDEs.
- Java programming on Blackberry is quite a pain in the neck. Recommendation: NetBeans Mobility Pack or the Blackberry IDE.
- MacOS as a development platform is unfortunately lacking many emulators. On MacOS, the speaker himself uses Eclipse + ME4SE (from Kobjects.org).
Increasing the target group
- Use MIDP 1.0 instead of 2.0 when possible.
- Make sure your app's JAR files are as small as possible, this means 30kb-100kb.
- Avoid requiring special device or carrier APIs, bluetooth, 3D libraries, etc just because they are cool.
Java ME networking secrets:
- Only http is widely supported.
- Put each network request in separate thread to prevent lock-ups!
- Download webdata in chunks - it's faster and can be canceled; only tiny amounts of data should be fully downloaded in one piece.
- Note that the length of a stream of data is unknown in advance, the EOF is only marked by a -1.
- Closing a connection is often the cause of a crash.
- Some carriers cash webcontent -- if up-to-date data is needed, add a random number argument to the URL to make it appear new to the caching server.
- Carriers can control and change http headers, so you can't trust them.
Java ME imaging secrets:
- Use PNG file format for images. Note that MIDP 1.0 does not support transparency for PNG. There are various PNG formats, you need to try which is best.
- If you have lots of images, use tiled maps instead of several individual files to improve performance!
- Always double-buffer.
XML parsing secrets:
- Use a pull parser (with buffering, and while-switch-case), it's faster.
- Recommendation: WBXML + KXML parser.
Data storage secrets:
- Use the Record Management Store (RMS)'s RecordStore API for persistant data storage.
- Don't forget that a MIDlet cannot necessarily access all of the theoretically available memory!
- The definition of the MIDlet-Data-Size attribute varies from device to device (can refer to a hard or soft size limit!) -- so don't trust the API, always test.
Unsorted Java ME secrets:
- If you plan to develop premium services for carriers, be aware they don't pay well, some even require you to pay fees. On the other hand, premium SMS is becoming a common means of downloading pay-to-use content to your mobile phone and it's already a promising market in Europe.
- Certify (sign) your app, otherwise your app will display an annoying dialogue with each connect.
- The fewer classes your app uses, the better: Fewer classes means more free heap space, which means less crashes.
- Depending on the device, the pauseApp() method sometimes pauses, and sometimes exits!
- The speaker listed Sony-Ericsson and Nokia as examples of good mobile device manufacturers, and Sprint and Cingular as examples of good carriers.
This cartoon reminded me... I once went to a class titled "Introduction to computer science for Cooks". Really! Half of the students only showed up for the first lecture to reveal the secret behind the title. I of course came for the hardware and Java programming basics. ;-) After the professor, a crazily self-confident but competent guy, told us the story of his life (from carpenter to university professor!), he deigned to proceed to the ritual of revealing the truth behind the class's name...:
Officially, the class's name is "Introduction to computer science for students of all faculties". So every year, the prof asked the students which faculty they were from. One year it came to pass that about half of the students answered they came from 'Domestic Economy' -- One of the classes in this slot was canceled at the last moment so they spontaneously decided to come here and learn Java. And the prof went "Huh, what's Domestic Economy? Oh that's, like, cooking, right? Whatever, then I'll go teach computer science for cooks." Well, at least his assistants thought it was funny, and when they later created UNIX accounts for the practical sessions, they created two user groups, cooks for the students and chefs for the assistants. And thusly it was done each year, and probably is still done thusly today! :-)
Posted by seapegasus ( May 22 2006, 11:14:22 PM CEST ) Permalink Comments [3]
Saturday May 20, 2006 Jackpot - I think I'm a Clone Now
Hey, maybe next year at JavaOne, instead of having a slotcar race, we should have a cloning contest! :-) Not what you think, I mean cloning a la Tom Ball: Clone your experience. The contest objective: "Here's an inefficient program; write Jackpot rules to improve it; the team with the fastest implementation wins." :-)
In the Jackpot preview sessions on Thursday and Friday it became clear that the Jackpot Technology in NetBeans IDE is not just some fancy kind of Search and Replace. Neither is it only redesigned Refactoring. It's a project wide semantic pattern search and transformation tool. Semantic search means that Jackpot has access to every kind of information that javac has. You can search for pattern of method calls, types, instances, and you can make it treat transformation targets different depending on whether it has side effects or not, etc...
The syntax is super easy to learn: Variables are marked with a dollar sign ($variable for one and $variable$ for several items); rules are of the form pattern => transformation :: constraint.
This simple "remove unnecessary cast rule" rule for example
($T)$a => $a :: $a instanceof $T;
says: Find every $a that is cast to type $T, and replace it by only $a, if $a is already an instance of type $T. The compiler can identify all these cases with 100% confidence, that's much more than you could do with search and replace only.
After running, Jackpot will open a diff window similar to the one used in version control to show you every line of code where the rule holds, plus the transformed version. That's handy especially while writing your first rules, so you can see that they really do what you want. You can make Jackpot adhere to your writing style so a change doesn't cause unecessarily huge diffs in your code. Tom Ball is already working on a live preview rule editor: It will display the effects of the rule you are writing live on a piece of example code!
What's in it for you? Well, as Tom Ball suggested in the beginning of his talk, you can clone yourself, clone your experience. Your team can create whole query sets that include quick replacements for deprecated methods, "Effective Java" fixes for the most common glitches, or your company's best practises in a nutshell. Save and share your rules in a textfile (such as a blog entry), or even better, in an NBM file, for others to use and extend. Tom Ball gave several examples how developers came up with great rules in a blog comment discussion. Readers could grasp quickly what a Jackpot rule does and could come up with improvements.
In the future, even the lightbulb feature and standard refactorings may be Jackpot-based. There is however no magic to it. Jackpot is a tool hat empowers you to write rules that improve your code -- or break it. this reminds me -- Jackpot could really be a cool game: Take a sample programm every player is familiar with. The goal of the game is to modify the program in a way that the players agree on before the game. In each round, everyone proposes a Jackpot rule to be applied, or a new goal. These propositions can be vetoed by the other players however, so choose wisely. The one who installs the last change that leads to the current goal wins. Whatd'ya think, would that kind of game work? :)
Posted by seapegasus ( May 20 2006, 02:07:07 AM CEST ) Permalink
Friday May 19, 2006 Help, My Car Has its Index Out of Bounds
What world are we living in when cars can have an Index out of bounds? *Sigh* ;-) It just happened live on stage during today's slot car race finals. There were three contestants, one of them a team of German students who reached a spot in the final top 3 on just during the last day or so -- by teamwork: One was coding, one was watching the race, while the remaining two stood and queued! With this clever technique they caught up with the others quickly. One of the other two contestants, I think his Name was Chou, I've alread seen live at work during the last days tweaking realtime code on the racetrack.
Well, After Gosling's presence single-handedly expelled the index bug from the presentator's machine, ;-) the slotcar race could begin. Due to the earlier bug, the one car that was first carried out of the track was not disqualified... Phew. Gosling mentioned that the teams actually had to tame their racing code over night, seems they were all pressing the limits too hard when they heard they were in the finals... But during the actual run, the slotcars showed their best behaviour. Chou won while the German team came in second, but it was pretty close! Cool, very exciting, I hope we will have more of these contests in the future. So what do you want for next year? Post a comment. :)
Posted by seapegasus ( May 19 2006, 08:54:19 PM CEST ) Permalink
Wednesday May 17, 2006 Does Your GUI Clack or Rattle?
OK, here is my brainstorming about what Karsten Lentsch said at JavaOne about Swing GUI Design Dos and Don'ts. He had a weird kind of dry humor that made the audience laugh while he kept a straight face. Oh and I will also sum up what he said about the NetBeans GUI builder Matisse in this context.
- The GUI mustn't distract the viewer's attention. Visual representations are like poetry: Be aware that people intuitively try to assign meaning to every constellation of color, position, shade, blinking, movement, weight, size, alignment, they encounter: So don't send a message you don't want to send! (E.g. the fact that components are not aligned can be interpreted as that they don't belong together.)
- Fancy is not cool: Avoid sprinkling the GUI with blotches of saturated colors, noisy backgrounds, large or bold fonts, or fonts of different families (unless you want the reader to focus on only this odd-one-out, which you ususaly don't). Everything that strays from the standard is in the spotlight. If suddenly everything is in the spotlight, the users is blinded and stumbles around without guidance.
You usually only want the workflow to be in the spotlight -- This is e.g. why headlines are few, short, bold, large, and in a different font. - Be consistent with icons, theme, colors - also with respect to the OS. Don't swap/move positions of items if you have multiple dialogues or menues (e.g. don't swap "save" and "delete".) "Muscle memory" makes people associate positions with actions, so don't waste their time by forcing them to regather this information for every screen. Think of walking up a staircase where every step has a different height, you'd hate that!
- If the component/label doesn't add essential information, skip it! Can the user tell in one glance what the tool does? Make a Squint test to find out what stands out first. Be clear (remove noise), concise (nobody is ever going to read that). A GUI is not a 3-minute pop song, it's a tool in your hand that you use to accomplish something: If a button doesn't do what expected, you'll want your money back.
- One of Lentsch's metaphors was, if you brush over the interface with your fingernails, it should clack, not rattle. So no unnesessary lines: No double lines/borders between components, no nested titleborders, no gratuitous pseudo-3D effects. Use white space to group components instead of separator lines. Subtle gradient backgrounds can help to counterbalance other components' overhead weight.
- Symmetry, Grid & Alignment: Align components that have something in common! The user will thank you for this additional information. Align textfields to the fontbaselines. All fields should have the same size and spacing -- unless you want to convey the message that textfields of certain lengths are meant for contents of certain lengths (phone numbers, ZIP codes). In the latter case, constrain yourself to max. 3 sizes (small, medium, large textfields.)
If the component's content is known and fixed in size, use static component sizes; dock or split windows only if necessary. Use a few aesthetic aspect ratios when spreading the components.
In Matisse he saw a great step in the right direction (e.g. it nicely aligns to fontbaselines), but he pointed out some weak spots: Matisse lacks guided alignment of components in multiple panels/windows/components, and it allows aligned components to have different heights. (When I'm back I need to try whether InterfaceBuilder can do that?) So don't count on a tool to do all the thinking for you.
So why are all these aesthetics relevant? Isn't the tool's function way more important? Unfortunately, humans tend to interpret good looks as health, and balanced GUI design as clear bugfree programming... Just flip the coin: If the GUI looks brittle, confused, clumsy, careless, users will have prejudice against it: "What is this klutz tool going to do with my precious data?" Oops, just lost a customer.
I'm well aware there are "ugly" but popular applications, but these often merely lack professional graphics, while their layout is intuitively clear and easy to use (and that counts).
Tuesday May 16, 2006 Amok running robots at JavaOne
How cute, a silver iMac on wheels in the JavaOne pavilion! Oh wait -- that's Tommy? Let's see what this egg on wheels is up to: Luckily, there were still empty seats in the "A robotic dune buggy named Tommy" session. (The alternatives would have been a session on AJAX, and one on Swing animations, still, Tommy's session was a good choice. There'll be other AJAX stuff). This technical session covered the DARPA grand challenge of Oct 2005. The challenge is a forum for building and testing real robotic vehicles, the winner receives an appropriate financial reward. The experience gathered will later be used for military, personal or professional purposes, for example, military surveilance, the handling of dangerous objects, or work in live-threatening environments. They say. Or maybe they just want to play with robots.
The challenge's goal is briefly to create an autonomous vehicle that can (for starters) travel through a desert and reach a target without any human intervention. Remember the Mars buggies of late? A planet's surface is not a German freeway. Every step has to be planned, discussed with ground control (radio signals from Mars can take something like 15 minutes), and then the step has to be taken slowly and carefully, or it'll be their last. But the DARPA challenge is different, as the vehicle has to complete the task at "mission-relevant" speeds, too. When the first grand challenge was held, even the best robots got stuck after 10km. But in the following years, the winners already managed to cover the whole alloted distance. On the other hand, each year a random number of great brave robots crashes, burns, or simply bails out during the first few meters -- it's by far not a trivial task, as we will see later.
Tommy is a cool retro-looking silver egg-shaped vehicle. He seems to be propelled by gas like a car and is pretty DIY, thanks to the team-members' enthusiasm and dedication. In the design phase (going from cardboard-box-sized to increasingly bigger robots) redundancy was already an essential part of the plan. You never know when one or the other signal doesn't come through. And, to be honest, you could count on the DARPA choosing a terrain that was not fully covered by the conventional global positioning system (GPS), just to make the game more interesting. So the Perrone team made sure to equip Tommy with a triple redundant navigational system: Two high-resolution GPSs (one beacon- and one satellite-guided), plus a lower-resolution standard GPS. Additionally, Tommy got two kinds of radars and lots of outside sensors, as well as internal state sensors. All that was orchestrated by one microprocessor that could make decisions and send them to the actuators (the motors and wheels that make the vehicle speed up, slow down, break, or turn).
The software used was a general purpose Java-based robotics platform, "Perrone MAX", if I remember correctly. Basically, you have threads running that are triggered by certain cofigurations of sensor input and internal state. Tommy's got a kind of artificial intelligence, pre-defined rules that allow him to make quick and good choices. The AI does not involve any machine learning however, the rules are hand-coded in Java. Some jinxers may claim, neither the Java Standard nor the Micro Edition would really scale to this kind of task -- so just to prove them wrong, Tommy's software uses both: Java ME and Realtime Java SE. Realtime means, that processes have a higher priority even over the garbage collection processes. Garbage collection slows down importantant realtime actions by milliseconds, a delay that you could cope with during a game of Minesweeper, but not when your autonomous robot is trying to defuse an actual bomb. Thanks to Java (and NetBeans IDE, woot!) :-) Tommy fulfills his demanding tasks happily with one microprocessor, and they detected no performance bottleneck what-so-ever. After his "training", Tommy was able to complete several tasks, among other things:- He could find his way to waypoints in the desert with aid of GPS;
- Sensors told him to slow down in time to not roll over or tilt.
- He could drive through a dark tunnel without GPS -- at least for 30 secs.
- He could resolve obstacles in a 500-feet range (170 meters) and kept track of them in his memory. At the same time he made sure not to pollute his obstacle map with, say, blades of gras, so the obstacle avoidance methods calculated the urgency by confidence level. E.g. an obstacle that only was detected once may be a sensor error and should not be avoided.
Monday May 15, 2006 Today's NetBeans Day! And I'm so jetlagged I can't even google straight. ;-) Since I dream weird stuff and can't sleep anyhow, here's today's cartoon. (I hope the pun works, in my tired state I'm easily amused.) Sorry for the travel-related bad drawing quality, next week we'll be back again to good old sophisticated state-of-the-art... well... stick-figures.
Thursday May 11, 2006 I sneak around the corner with a blueprint of AJAX
Oooh look what I found, java.sun.com/javascript with lots of new Web-2.0-ish stuff like AJAX and JavaScript. You surely have seen AJAX before, AJAX is this fancy stuff that completes what you type in a webform while you type. Or, what's even more useful, it can do live form validation, too. Like for example, if you access www.google.com with the complete=1 parameter in the URL, you get suggestions, live, while you type. I mean, in case you can't think of anything to search for. ;-)
Curious? If you want to see how AJAX works and what it can do for you, there are some AJAX sample files in the NetBeans IDE's help menu under "Blueprints". Choose AJAX from the popup menu and then you could choose e.g. "Auto-Complete" or "Progressbar" or what sounds interesting to you (I don't know anything about Java Server Faces yet, so I skipped those.) In the solution tab, you'll learn for which kind of problem this method is a good solution. In the Design tab, you get the blueprint (code samples and diagrams) showing how to design the webpage. Go to the Example tab to create a NB project for this example that you can actually run and deploy to see how it works. It's all the rage, check it out. :-)
PS: And look, today there is more: developers.sun.com/ajax and java.sun.com/javaee. Need a tool to go with it? Incidentally, ;-) you can test-run J2EE and UML features with NetBeans IDE 5.5 Beta now.
Posted by seapegasus ( May 11 2006, 09:00:07 PM CEST ) Permalink Comments [3]
Monday May 08, 2006 I'm Not Stupid, I'm a Digital Ghost
Ever played Tron? Live? In 3D? In a city? I just read an article titled Intelligente Experimente stating "mobile games don't have to be stupid!" It's German, but I'll translate it for you. :-) Coz this is cool, listen to that:
Starting August 2006, the south-west German city of Regensburg (that's near Munich) offers her tourists a new treat: The pervasive exploration game REXplorer invites visitors to discover the city's history with the aid of a mobile phone. Worldwide, this is the first mobile game of its kind that will be permanently installed in a city. The game was developed by scientists from two technical universities, RWTH Aachen (Germany) und ETH Zürich (Switzerland) in cooperation with Nokia.
Explorers are equipped with an artificially intelligent device, a modified GPS mobile phone. Their mission: Assist local scientists in researching mysterious phenomena in Regenburg's Old Town! The device guides them to interesting locations and lets them get in touch with local spirits. [I'm not kidding you, that's what it says.] RWTH's Tico Ballagas, who was responsible for the game's implementation, explains: "When an explorer arrives at certain locations, the mobile device displays an increasing heart beat. Making certain gestures gets the explorer in contact with a local spirit. The spirit speaks via the mobile's loudspeakers to tell a story about the history of this location, and asks the visitors to perform a task for him."
The device may for example lead players to an old tower, where the ghost of a Jewish merchant tells his story. The spirit asks them to go to the synagogue for him and bring him a photograph. In search of the synagogue however, the visitors learn it was destroyed decades ago. There's nothing else to do than taking a picture of the memorial that was raised in the synagogue's place. The quest is solved (and the ghost can rest again) as soon as they upload the photograph to their team's blog. The team with the most mysteries solved wins. At the end of the day, the blog remains as a personal souvenir.
Some pervasive games are already available for free, others can be downloaded for a small fee, or are pre-installed on modified mobiles that are lent to tourists. Mobile games of this kind often need a mobile device equipped with a camera, a wide display, and GPS. The fly catching game Skeeter uses the built-in camera to interpret the player's gestures as game moves. In the 3D game Tron, the GPS locates the player in the real world, and walking through the city leaves lines on the map on the mobile's display — cross another player's line during the game and you lose...
LOL. Isn't this great? And now the best thing -- It happens to be the case I need to buy a new cell phone... (My old one is dual-band only, which would be sub-optimal for staying in contact during NetBeans Day and JavaOne). Of course, my new one will support MIDP 2.0... And just by chance I happen to know where I can get a nice Mobility Pack... ;-) I'm not gonna start right away with the GPS stuff, ;-) but I suddenly feel very tempted to write something, anything, myself that I can run on the new phone... Stay t00ned for the first episode of "I crashed my cell with tetris but it was worth it" (hopefully) soon on this channel!
Posted by seapegasus ( May 08 2006, 09:51:32 PM CEST ) Permalink Comments [1]
Friday May 05, 2006 Save your buffers, the end of the world is nigh
You might not know the German yellow-press newspaper that Ed's latest blog entry reminded me of (and if you do, you probably wish you did not). -- Apart from pulling stunts like claiming the world is coming to an end right after JavaOne (source? crop-circle!), this paper enjoys subtly 'informing' readers with objectively harmless but easily misleading headlines. Or in other words, Ed stating his opinion that Sun seems "ready to join Eclipse" doesn't mean anything more than that, it is his opinion. As far as we know, Sun is not planning to join (Ed lists the reasons himself).
Speaking of the end of the world after JavaOne -- This may not only be your last chance to grab an one of the nifty give-aways (iPod, USB-memory or the NetBeansField Guide), but also your last chance to nominate a fellow NetBeans user for the NetBeans Community awards! ;-o Better send your nomination now to nbdiscuss@netbeans.org or webmaster@netbeans.org, with a few words about why you think your nominee should be recognized. Today is the last day for nominations! The nomination period will be followed by a voting period that will run until next Friday (May 12th).
In case you too were planning to nominate Roumen -- despite him being the role model of a NetBeans Award candidate, I don't see Sun giving an award to an already renowned Sun employee, when there are so many honorary Evangelists out there that would deserve the recognition (and Gosling-style prizes) too! But it sure is flattering you thought of him. :-)
PS:
Whether you're nominated or not -- why not start again to build up reputation in preparation for next year's community award? ;-) NetCAT 5.5 (the community acceptance testing program) invites every community member with experience or interest in Java EE programming to participate in quality testing NetBeans IDE 5.5.
Monday May 01, 2006 Since today's a holiday (Labour day, Walpurgisnacht, or whatever), today's cartoon runs a bit late, but here it is, enjoy! (Kinda PG-13) ;-)
