Kyle Mulka's Blog

Yey! I’m in Seattle now, and I’ll be here for a few months while I do an internship with Amazon.com.

So far, the weather has been great. I took a bus into the city this morning, walked around for a bit and found Harried and Hungry for lunch.

I took the bus back up and decided to take the mile or so walk down to where I’ll be working. The way to work is all downhill… but of course that means its all uphill coming back. That’s one big difference with being out here… so many hills.

The corporate housing is being subsidized by Amazon, although I still have to pay for part of it. It’s really nice, but there is no internet yet. :( Right now, I’m out in the courtyard picking up wireless.

I haven’t gone to the grocery store yet. I’m kind of wondering how I’m going to travel to and from considering I don’t have a car. The bus is an option, but carrying groceries on it isn’t ideal. I might take a taxi and stomach the fare every once in a while. Maybe one of my friends here has a car… hmm…

So, I think I figured out why the one side of my laptop is falling apart, the screw coming undone and my monitor wouldn’t stay up. Basically, I think the other side of my screen completely broke off of the base and was only being held on by the other side. It just couldn’t take the pressure, so decided to start unscrewing itself… awsome. So, there are two connections between the monitor and the rest of the laptop. One is completely broken and the other is barely intact. Just thought I would share.

What is the best way to access information via mobile devices like cell phones?

There are many answers to that question. When it comes down to it, I think the main problem is user interaction. What is the best way of getting the information to the user in the format they want it and can handle it. Out of all the senses, the only ones that make sense for retrieving information are sight and hearing. So, you could have voice which speaks the information, text describing the information, or possibly more visual information such as maps, diagrams, or charts.

The other problem is trying to get the right queries from the user into the phone. That can be tricky with such a small screen. Hopefully voice recognition will be good enough to work on small mobile devices. That seems to be the main way of getting a query to whatever service you are accessing. After that, maybe some sort of intellegent menu system. I know this has already been done with many hotlines where you listen to a menu and select the correct choice… but wouldn’t this be a ton faster if this was a text menu instead of listening to a voice read you the menu?

Here are some of the main technologies I’ve seen that might have a chance in the next generation of user interaction on small mobile devices:

• J2ME
• WAP/WML
• VoiceXML
• WebBee
• Opera Platform
• Dasher

Title says basically what I’m looking for. I’m looking for a web based calendar which will publish and subscribe via iCal and will also sync with Palm Desktop on my laptop.

Why hasn’t there been a good AJAX calendar that you can use to publish and subscribe to calendars via the ical standard? Right now, the best I’ve seen is Planzo, but it has yet to publish or subscribe via iCal. Next on the list to evaluate is AirSet, which looks promising, but their site is so full of features that it is hard to get to the simple stuff you really want.

One really good use of this type of software is to plan semi-weekly meetings between a group of about 10 people when individuals schedules sometimes change depending on the week, but for the most part stay the same.

I started to do this with Mschedule a couple summers ago, but the only data I drew from was from the University of Michigan’s schedule of courses and individual students’ schedules that we’re imported into the site by simply copying and pasting from the official site hosted by the University called Wolverine Access. It was my first web application, so I didn’t really know what I was doing with PHP, CSS, or even HTML div tags (I used tables for all the layout).

We’ve added the Dudertstadt Center to the liveUgli service. So, now, when University of Michigan students are studying in the Duderstadt Center, they theoretically will be able to find their friends and classmates to study with. If you don’t have a UofM uniqname, sorry… you can’t access the service.

http://www.liveugli.com/

The documentation for the Google Maps API version 2 has been released. Oh my… I’ll have to read into this more next weekend. It’s looking like a lot of the stuff I’ve been doing beyond the basic features have been made easier to do. Looks like Google is encouraging the making of custom map types. Yey!

http://www.google.com/apis/maps/documentation/

Cosign is the authentication mechanism that the University of Michigan uses to authenticate users to their web applications. It allows the user of a web application the ability to use their standard University of Michigan uniqname and password with that application safely. The password is always transmitted directly to a secure central server (https://weblogin.umich.edu/) and behind the scenes, that central server tells the web application what the uniqname of the user is via a server side variable. This means that the web application never actually puts its hands on a users password, and even if the service is hacked, it will only affect that one service and not entire users accounts.

For this article, I’m only going to describe the University of Michigan’s implementation of Cosign. It is possible for other institutions to download the entire source code for Cosign and host their own central server which handles all authentication, but I’m not going to cover that since I don’t know much about the Cosign authentication server, just the Cosign which runs on the web server serving the specific web application you want secured via Cosign.

Examples:

• Webmail
• Wolverine Access
• UMOD
• CTools
• liveUgli (my current project)

In order to use Cosign, you have to have it installed on the server your web application is running on. Installing the Cosign client is no easy task. There are many things that make this challenging for someone who doesn’t really know what they are doing. Here’s some things you need to know in order to truly understand what’s going on here.

Cosign requires you have an SSL secured web page (HTTPS) for at least the authentication step of your web application. They reccommend you SSL secure anything that is not public that you have to be logged in to view otherwise user session to your web application could be hijacked.

In order for your web application to communicate with the central authentication server, the webmasters need to sign an SSL certificate for your server. This ensures that the communication between your web application and the central server is always secure.

Installing Cosign from source can always be an interesting challenge, especially if it doesn’t work the first time. I’ll try to go into this in more detail in another article. In the meantime, just check out these notes on my Cosign installation I wrote up a while ago, and the official Cosign web page.

Spread the word…. Mschedule is up for Fall 2006 including the automatic schedule generator! I’ve fixed it once again… But, the domain mIschedule.com is still dead, and probably won’t be coming back to life. Check it out and let me know if you have any problems.

It’s time to announce it to the world! I’ll be working for Amazon this summer in Seattle for about 12 weeks as a Software Development Engineer Intern starting May 8th. I’m really pumped!

I thought this was interesting… I looked in the headers of an email I recieved from facebook. The message said it was sent with ZuckMail. I’m not sure what ZuckMail is, but I’m assuming its named after the head honcho over there at facebook, Mark Zuckerberg. Anyone with more information about what ZuckMail is, please let me know…. I’m interested. Check it out:

Received: from zuckmail ([207.75.132.61])
by wccnet.facebook.com with HTTP (ZuckMail);
Mon, 6 Mar 2006 05:54:32 -0800

X-Mailer: ZuckMail [version 1.00]