Boarding the plane
in a couple of hours. See you at DevWeek in London!
My talks are on
Wednesday (.NET Remoting vs. ASP.NET Web Services, Advanced .NET Remoting and
.NET Remoting Internals) and Friday ("A day of .NET Remoting" - don't miss this
one!).
Katja and I are
really looking forward to this week as it's our first time in London and apart
from the mandatory sightseeing tour, we're going to attend a showing of The
Phantom Of The Opera which definitely
rocks.
Robert tries to convince me that using the
Tablet is better than paper in any case. I'm sorry, Robert, but I certainly
disagree with you. Paper is more lightweight, doesn't need power, has better
resolution - and using my Visioneer
Strobe Pro, it reaches my harddrive in about ten seconds. (Oh - and by the
way, the Strobe really rocks - my Tablet PC doesn't help me with digitizing
incoming contracts, letters, invoices & receipts.)
So ... do I
like the Tablet at all? Sure I do. Absolutely. 100%. It helps me to see the
future. I can imagine a range of applications in the likes of Journal and
OneNote. Applications, which take advantage of the platform. I can also see the
next generation devices. Devices, which will be more lightweight (let's target 1
lb, ok?) have better battery power (12+ hours) and a higher resolution (about
2000x1600 pixels on a 12" screen would be a good start). Oh - and the
device has to recover from hibernation or standby in < 1 second.
Does that sound
unrealistic?
I don't think so. I
really expect that we will see these kinds of devices in the not so distant
future. We simply have to - the current generation doesn't address the very
issues I mentioned before.
Still ... I
like my Tablet in its current incarnation and actually it's the device I use
most of the time. Combining the power of Journal, OneNote and the Strobe, it
allows me to carry all my data with me in less than 4 lbs. And I can
use it in coach class on the plane. Something that's not possible with my 16"
Sony Vaio.
After talking with Robert
Scoble - and some other TPC owners - last
week, I finally decided to join the ranks of Star Trek officials and bought the
Compaq TC1000. It's a
convertible tablet with the additional benefit that the keyboard can be
completely detached - leaving you
with a perfect slate-style table. Sorry Robert, but the NEC one isn't sold in
Austria as this one came pretty close
;)
Generally,
it's a nice device - and especially the "Windows Journal" application
absolutely rocks. One can clearly see the future when working with this
device.
However, we're not there yet.
I'll spare you a listing of all the great features
of the tablet - just look at any of the usual pages. I second most of the great stuff you'll hear
there.
But for
today, I'll talk a little bit about the drawbacks or areas of improvement
I see:
* Boot-up speed. This device is positioned
to replace your paper based notebook. But even though it starts pretty fast
(taking from 10 to 15 seconds from hibernation), my sheet of paper and my pen
boot in about 0.1 seconds. I already had two different meetings where I had to
ask the other person to pause a little so that I can start the engines. Very
embarrassing indeed.
* Size & weight. It's still too heavy
and too thick. My paper notebooks weights about a tenth of the Tablet
PC.
* Applications. My paper-based time
planner comes with dozens of forms and it allows me to scribble, edit and paint
on all "one-sheet-a-day" planning pages. Outlook doesn't and even Franklin's
tablet planner forces me to constrain myself to "Add->New
Appointment->...". I want to just write on the pages of my time planner - wherever and whenever
I like!
* Resolution. Even though digital magazine
delivery rocks, I still can't read a full
magazine page on the screen without
scrolling. I think that we need about 1600x1200 (better even 2000 pixels)
resolution on the screens so that they look and feel more like paper.
* Hardware Buttons. I'd like to see at least eight
programmable hardware buttons which should be operated by simply pressing them, not by pointing with the
special pen. I want to use the
tablet for reading and don't want to search for the pen whenever I
want to turn the virtual
pages.
* Hardware support. The built in wireless LAN adapter doesn't
work with Ethereal. That's really
bad. At the dot.net conference two
weeks ago, the WLAN has been completely jammed by Slammer. Ethereal easily allowed me to trace down the
offending machine. I can't do this with my tablet. (Well yes, I can ... I'll
just carry an additional WLAN PCMCIA card. But that's not exactly the point of a
built-in card, right?)
That said ... don't get me wrong: I really like
this device. It's neat-o-factor is close to 100%. It's geeky-gadget-factor is
even way higher. The things mentioned above are just a reality-check from a
user's perspective: take them as an
encouragement or as suggestions when talking with your program manager -
especially if you're working in the Office group and thinking about the next
version of Outlook ;)
They put up a
petition which will be sent to Mr. President Putin and Mr. Magomedov (Chairman
of the State Council of Dagestan) and which urges them to do all within their
powers to help the efforts in achieving a safe release of this
doctor.
Sign the petition
to support an act of peace of people who are living in
interesting times.
Scott
wonders whether God stored the universe's constants "as a
readonly field in a static constructor or a singleton pattern, or assuming
parallel universes, a factory pattern?"
He also presents a
sample which unfortunately sports two serious
bugs:
a) God doesn't use
Hungarian notation for variables. He's a great supporter of the theory
that choosing a reasonable name for a variable
combined with an OO languages with strict type checking and
extensible metadata render Hungarian notation pretty obsolete.
b) God also faced the problem that most constants
aren't finite.Therefore he decided not to store them in any field. Instead he
created methods which returned the results as a stream and combined these with
some factory methods returning delegates to the helperfunctions thus creating a pretty pluggable
architecture.
After
implementing a prototype, he saw that streaming of infinitely
long numbers doesn't work pretty well in a SOAP 1.1 based distributed
environment incorporating multiple Universes. As an interim solution
he therefore limited Reality to a single instance. Somehow he has been
assigned to a different project in the meantime so we still live in a single
Reality.
He seriously
promises that the application is nevertheless scalable to multiple instances -
if he only gets to fix the bug in the calculation of the answer to the Great
Question of Life, the Universe and Everything.
Within one day,
more than 600 developers signed up for my Distributed .NET
Newsletter. I'm flattered to see that so many people allow
me to send my humble opinions on these topics directly to their
inboxes.
Special thanks fly
out to all fellow webloggers who helped to spread the word:
Brad Wilson:
Ingo's doing a Remoting newsletter. Do I have to say it? Go! Subscribe!
Now!
Brian Graf: I can't
wait for the first issue. I'm subscribed, are
you?
Brian Hjøllund: If you're into .NET, and
would like the lowdown on remoting, then you should consider signing up for
Ingo Rammers's newsletter on .NET distributed application design and
development.
Brad
More:I'm in, and you should
be too. Ingo's weblog was the first I read regularly, before I even
knew what an aggregator was ...
Christian Weyer:You probably won't get any better
information about how to design, implement, deploy and maintain distributed
enterprise applications of any scale.
Darren
Neimke: I imagine that this will be an
invaluable resource ...
Marsh Drew: Ingo knows his
stuff, so this is certainly one newsletter I plan to subscribe to and
recommend the same for anyone else that does work with these technologies.
Early next week,
I'll send out the first issue of my free "Distributed .NET Newsletter".
This bi-weekly
newsletter contains real world tips and tricks about .NET Remoting, Web Services
and EnterpriseServices, and design guidance for distributed applications. You'll
also find the occasional pointers to other free resources like white papers,
patterns&practices documents or other great samples on the web.
To all
weblog writers, newsletter publishers and usergroup members: It would
be really great if you could help me spread the word! This newsletter contains
real world advice, is completely free and I promise to never give any email
addresses to any third party. Ever. I hate spam as much as you
do.
Good point. Ok, let me tell you how this site has been created and show
you a little bit of its magic.
I
created a layout prototype in Photoshop. It looked exactly the same
way the website looks now.
Cranked open FrontPage to "translate" my image to HTML until
it really looks the same way as my initial Photoshop drawing.
Split the page up in header, content, footer areas and put the first
and latter into some magic ASCXs.
Done.
So, what's the cool part about this site? It's the magic behind the
scenes. For example, whenever you access an HTML page (like this) the complete
header, menus, etc. are generated dynamically by an http handler I inject into
the request pipeline. This handler takes the content out of the "real" HTML
file's <BODY>, detects the current context by looking at the path,
generates the correct menu structure based on this content, and renders the
complete thing in a templated way.
But that's not all it can do. If the .html file doesn't exist, the
handler looks for a .XML file in the same location (for example the real source
for this one is
actually that
one). It will then detect the namespace used in the XML, and render it using
for example this
XSLT. So, why did I do
this? Because I can later on also use this
XSLT to render PDF output instead of HTML.
Well.
There's one more thing: URLs are immutable. I used a bunch of http handlers
and magic rewriting rules to forward to the current location of the pages. This
way, Dave's link from last
year which pointed here is
still valid, even though I changed blog tools twice and even switched
domains.