Kyle Mulka's Blog

I just watched a really good presentation called Set Amazon’s Servers on Fire by Don MacAskill, CEO and Chief Geek at SmugMug. It’s an interesting look into one of probably the largest users of Amazon’s S3. He talks about how they are using S3, and are going to use Amazon’s EC2 soon as well. He’s candid about what Amazon Web Services doesn’t currently provide that is needed for a company like his.

[via AWS Blog]

Note: I would put a link here to the AWS Blog article that had a bunch of presentations, but I don’t want other people to suffer the CPU stranglization (?) while loading all the SlideShare presentations.

Wow… this is big. Nokia, a cell phone manufacturer buys Navteq, a map data provider for more than $8 billion in cash. Nokia has just made a huge leap off a cliff hoping that halfway down their homemade paraglider that they are going to pull out of their backpocket lifts them up to new heights.

I guess they think that this will allow them to take over the budding location based services market. Buying Navteq may allow them to take competitors out of the market by simply not providing data to them, or charging them a heafty sum of money for it.

I expected this kind of thing from Google, but not a cell phone company. I guess even Google doesn’t have $8 billion just lying around. Then again, I don’t think Google really wants to be a data company. They want to be a technology company that builds software around the data that other companies and individuals provide.

So, what happens when some other big phone manufacturer decides to buy the other major map data provider Teleatlas and both decide to no longer license data to Google? Oh… I guess no more Google Maps… even on the Apple’s iPhone…

[via All Things Digital]

The name pretty much says it all I think: wiki drawing tool. Basically, I want a website where I can go and draw something, then other people can come in later and edit it. Just like Wikipedia, all changes will be saved, and each drawing would be able to be instantly reverted to a previous version.

Introducing Cartiki, a user edited database of locations. A cartography or map making wiki.

Anyone can add a location name to the database with a corresponding bounds on the map, a parent location, alternate names, and external URLs.
Other features will be released soon based on user feedback, so, send me an email and let me know what else you want to see on Cartiki!

I originally wrote the following as my biography for WhereCamp, an unconference for geo-hackers. I realized that readers of my blog might be interested in this too. Also, if you are going to be in SF next week for Where 2.0, Google Developer Day, or WhereCamp, please contact me if you’d like to meet up.

Hi! I’m Kyle Mulka. I just graduated from the University of Michigan with a degree in Computer Science. When the Google Maps API first came out, I was really excited about the possibilities and started hacking with it right away. I built a bunch of stuff, some of which you can see on my Google Maps page.

The semester after that summer, I started a class project which was basically Plazes but with more detail inside of buildings at our University. We called it liveUgli. UGLi is short for undergraduate library. Basically, we wanted the site to be a representation of what was currently happening in the library: what people were studying, which groups were meeting, if someone was planning a study break for lunch or frisbee or whatever. It would allow people to find study groups and meet up with friends and classmates. They would be able to more easily discover the people near them, but not close enough to see.

I believe there were many reasons which made liveUgli unsuccessful, the main one being that no one was using it, so the site was useless. This is a problem with all social networking sites. You need a critical mass of users for something like this to be successful. But, beyond that, there was no automatic detection of location (yet), and even the manual method was kind of difficult for users. Many people told me that they didn’t study in the UGLi, so the site was useless to them as well.
I set out to create a system by which we could easily add new location names and maps and floor plans to the system. I ended up calling this system Cartiki which stood for cartography wiki, or map making wiki. Not only would we, the administrators of the site be able to add locations, anyone could add locations in wiki fashion. I’m almost to the point where I’m ready to release Cartiki as a stand alone web application to be used to help people find locations, both on a regular Google Map, and on uploaded floor plans of buildings. This would be ideal as a university/corporate campus room finder.

The ability to upload custom maps and floor plans comes from another system I built for this purpose called the Gmap Uploader. This can also be used separately from Cartiki and liveUgli, especially for viewing high resolution photos.

Maybe I’m a little biased because I’ll be working for them soon, but I think Amazon’s new web services are really cool. Basically, they offer a really reliable computing infrastructure for developers with a pay-as-you-go pricing structure. You only pay for what you use, and the interfaces are dead simple. They offer both SOAP and REST style web service interfaces.

For 10 cents per hour per CPU, you can rent as many or as few CPUs as you want. And, this can all be controlled automatically via their web service API. You pick the linux distribution, software, and data you want the machine to boot with. This pay-as-you-go computing is called the Elastic Compute Cloud, or EC2.

For 15 cents per GB per month, you can store as much or as little data as you want with the Simple Storage Service, or S3. Each file in S3 can be anywhere from 1 byte to 5 GB large. Because of the way REST works, public files can be downloaded directly from the browser, so they can be embeded in or linkable from web pages.

Another service that I just started playing with is called the Simple Queue Service or SQS. At first, it didn’t seem all that useful to me, but I think it will become useful for messaging between unreliable or not on 24/7 systems. My planned use of EC2 doesn’t require my server to be running 24/7, so I’m going to use a queue to accumulate jobs to be processed once the server boots up. As soon as all the jobs in the queue are processed, the EC2 server will shut itself down, saving money in the process.

You may ask: “But Kyle, aren’t you just playing with this stuff? Surely you don’t have a real use for it.” Well, yes and no. I’m playing with it because I think its cool, but I’m also busy developing the Gmap Uploader, a service which allows you to upload any image into the Google Maps framework. This means, you can upload pictures, floor plans, campus maps, and a whole bunch of other stuff that isn’t available as a part of the standard Google Maps. The interface allows you to easily pan and zoom in to large maps and images. If you know or can learn Javascript and have your own web space, you can add markers, and info windows on the custom maps as well using the highly popular Google Maps API.

UPDATE: You can hear a lot more practical usage of Amazon’s web services in this podcast from IT Conversations.

I usually don’t blog about personal stuff, but this whole graduation from college is kind of a big deal. That’s right, I can now call myself an alumnus of the University of Michigan, Ann Arbor with a degree in Computer Science in Engineering.

Now that I have graduated, the question comes up: “What are you going to do with the rest of your life?”

I at least have a little bit of it planned out. I’m planning a trip to the east coast in the next couple weeks with a couple of my housemates. Then, probably on Memorial Day, I’ll be flying out to Silicon Valley to attend a few conferences involving pretty much exactly what I’m interested in, web-based mapping: Where 2.0, the Google Developer Day, and WhereCamp. After visiting with a few friends there, I’ll come back to Ann Arbor, where I’ll probably just be relaxing. I may decide to visit some other friends in June… possibly in Chicago. Then, I’ll be around for my Grandma’s birthday on the 4th of July.

Shortly after, in mid-July, I’ll be flying to Seattle to start a full-time job at Amazon.com. I’ll be working with the Enterprise Multi-Channel group, which basically means we use Amazon’s technology infrastructure to build ordering systems which allow large merchants to receive orders through multiple ordering channels such as on the web, over the phone, and in the store. Last summer, as an Inten with Amazon I worked on Marks and Spencer‘s ordering pipeline… the part where you enter your delivery information. Their new website, powered by Amazon just launched a couple months ago.
What happens after that is anyone’s guess! Maybe you can be a part of it!? Come visit me in Seattle!

It’s only the second day of justin.tv, but I’m surprised its still working. It was posted on TechCrunch last night. I have a feeling it will get really popular, and they won’t be able to support the amount of traffic they will be getting. Looks like its time for Zattoo to step up and help out, (see previous Zattoo post) assuming they are going to have issues. Who knows maybe they won’t have bandwidth issues and will be just fine. In the style of YouTube, you can embed the live feed right into your blog, but I couldn’t get it to work.

So, one of my classmates a couple semesters ago IMed me today, and we had the following conversation about the University of Michigan‘s Cosign system (see previous post), and also how to get user information from the umich directory. I thought other people at UofM looking to implement web applications using the uniqname login system, might find this discussion useful.

1:29:54 PM Yaniv: i am hoping for some advice about setting up and using cosign
1:30:23 PM Kyle Mulka: for what purpose?
1:30:30 PM Yaniv: the idea is to have students log into a site with kerberos uniqnames, and be able to submit a vote
1:30:41 PM Kyle Mulka: I ask because if its for a University thing, then you should have the University set it up for you
1:30:53 PM Kyle Mulka: on their servers
1:31:13 PM Yaniv: yeah, i’ve been talking to the UM webmaster team also
1:31:17 PM Kyle Mulka: ITCS is good about setting cosign up on their web servers if you ask them
1:31:23 PM Kyle Mulka: and usually pay them
1:32:07 PM Yaniv: is it possible to set up on an independent server, and communicate with kerberos somehow?
1:32:15 PM Kyle Mulka: yes, it is… but its hard
1:32:21 PM Yaniv: liveugli, for example, is its own domain right?
1:32:42 PM Kyle Mulka: we’ll… you’ll notice that you don’t actually login to the liveugli domain
1:32:50 PM Kyle Mulka: liveugli.com just hosts the front page
1:33:03 PM Kyle Mulka: but… it is possible to use cosign on a non-umich domain
1:33:28 PM Yaniv: but you’d recommend to have itcs host it and they would set up cosign?
1:33:43 PM Kyle Mulka: yes
1:33:51 PM Kyle Mulka: I mean… is there a reason not to go that route?
1:34:07 PM Kyle Mulka: liveugli was able to get cosign setup through the GROCS program
1:34:19 PM Kyle Mulka: http://www.dc.umich.edu/dmc/grocs/index.html
1:34:30 PM Kyle Mulka: we’re considered a “project in residence”
1:34:33 PM Yaniv: the group this project is for already has a webhost from a third party
1:35:11 PM Yaniv: so lets assume that ITCS would host it
1:35:42 PM Yaniv: then with some language, i could say something like:
1:35:58 PM Yaniv: authenticatedUser -> getGraduationYear()
1:36:06 PM Yaniv: and find some attributes about the person?
1:37:14 PM Kyle Mulka: you can query people’s year (Fresh, Soph., Junior, Senior) from the directory
1:37:28 PM Kyle Mulka: all cosign gives you is the uniqname
1:37:43 PM Yaniv: oh i see
1:37:49 PM Yaniv: and which directory are you talking about?
1:37:51 PM Kyle Mulka: http://liveugli.com/umod.php?uniqname=mulka&valueof=classstanding
1:37:56 PM Yaniv: directory.umich.edu?
1:38:11 PM Kyle Mulka: yes
1:38:19 PM Yaniv: oh very nice
1:38:24 PM Yaniv: is there an API for that?
1:38:31 PM Kyle Mulka: directory.umich.edu is just a front end for the LDAP directory
1:38:44 PM Kyle Mulka: LDAP is a standard directory protocal
1:39:03 PM Kyle Mulka: replace my uniqname in that URL with yours…
1:39:13 PM Kyle Mulka: http://liveugli.com/umod.php?uniqname=mulka
1:39:21 PM Kyle Mulka: that’s all the info you can pull from the directory…
1:39:34 PM Kyle Mulka: however, not all of it is public… some people have made theirs private
1:39:49 PM Yaniv: right
1:39:59 PM Kyle Mulka: http://liveugli.com/umod.php
1:40:13 PM Yaniv: so the umich LDAP server is publicly available?
1:40:28 PM Kyle Mulka: yes
1:41:06 PM Kyle Mulka: here’s the source code for that script if you want to use it
1:41:06 PM Kyle Mulka: http://kylemulka.com/umod.phps
1:41:39 PM Kyle Mulka: you’ll notice the host name for the ldap server:
1:41:40 PM Kyle Mulka: ldap-master.itd.umich.edu
1:42:40 PM Kyle Mulka: but… when it comes down to it, if you just want to run elections… I would recommend not writing your own program, and using the one MSA, LSA-SG, and UMEC uses
1:42:49 PM Kyle Mulka: http://vote.www.umich.edu/
1:43:44 PM Yaniv: right right, i’ve been in contact with their developer about that, we’re trying to arrange something
1:43:59 PM Yaniv: but I wanted to have a sense of what is involved in case that doesn’t work out
1:44:25 PM Kyle Mulka: you have a better chance with that than getting cosign running yourself
1:45:06 PM Kyle Mulka: but… if you want the adventure, feel free to give it a try
1:45:41 PM Kyle Mulka: here’s some of my notes from when I did it a couple years ago
1:45:41 PM Kyle Mulka: http://kylemulka.com/projects/cosign-install.txt
1:45:58 PM Kyle Mulka: and… you’ve probably seen the cosign page
1:45:59 PM Kyle Mulka: http://www.umich.edu/~umweb/software/cosign/
1:46:26 PM Yaniv: suppose i get cosign installed on an independent server, i still have to tell it to communicate with the UM credentials somehow, right?
1:46:37 PM Kyle Mulka: uh… yea…
1:47:00 PM Kyle Mulka: basically, you have to generate a certificate and get it signed by the UM webmasters
1:47:37 PM Kyle Mulka: digital certificate, digitally signed if that wasn’t already clear
1:47:58 PM Yaniv: ok, so in these 10 minutes, i concluded that its much better to have itcs host it
1:48:09 PM Yaniv: and even better to use the existing voting site
1:48:23 PM Kyle Mulka: and… if you do an independent thing, you’ll have to pay for a certificate if you don’t want that annoying box coming up
1:48:33 PM Kyle Mulka: which … costs about $100
1:48:46 PM Yaniv: right, thats true, i forgot about that
1:48:50 PM Yaniv: needs the SSL
1:49:04 PM Kyle Mulka: ssl isn’t actually required though… just recommended
1:49:19 PM Kyle Mulka: liveugli doesn’t use ssl
1:49:31 PM Yaniv: oh.. i see..
1:49:52 PM Kyle Mulka: one reason we don’t use it is because IE would complain on every page load that there were “unsecure” things on the page
1:49:58 PM Kyle Mulka: like… the Google Maps APi
1:50:27 PM Yaniv: yes, that would be annoying
1:50:53 PM Yaniv: ok, well that was very helpful, i do have a much better understanding of the big picture
1:50:58 PM Yaniv: thank you very much
1:51:03 PM Kyle Mulka: you’re welcome
1:51:56 PM Kyle Mulka: I probably should have pointed you to this too…
1:51:57 PM Kyle Mulka: http://blog.kylemulka.com/?p=355
1:52:09 PM Yaniv: oh and thanks for that php code, i’ll look at it more closely, i’ll let you know if i use it and credit you if i do
1:52:34 PM Kyle Mulka: k, thanks
1:54:01 PM Yaniv: your articles are very good, i should have searched for them :)
1:55:59 PM Kyle Mulka: I appreciate the compliment, thanks
2:02:17 PM Kyle Mulka: Yaniv, do you mind if I post the transcript of this conversation?
2:11:53 PM Yaniv: no, not at all, please do

Why can’t you have SSL name-based virtual hosts?

I discovered that this was impossible… twice. So, hopefully this explaination will satisfy people’s curiosity and stop the frustration trying to get this to work when it just won’t.

The problem lies with the way name-based virtual hosting and SSL work.

Name-based virtual hosting is when you have more than one domain name being served with the same IP address on the same port. DNS takes care of giving you an IP address based on a domain name. Then, when that domain name gets sent via an HTTP header to that IP address and port, the web server, (usually Apache) can determine which web site to display. This is all well and good. The web server can figure out which domain name you want on each request, because your browser always sends it. But, what happens when we go to a secure page and add SSL to the mix?

HTTPS uses SSL to encrypt HTTP traffic. Before the HTTP request is received by the server, the server must send a certificate to the client verifying the server’s identity. The certificate contains a domain name. How does the server know which domain name’s certificate to send if it hasn’t received the HTTP request yet? It doesn’t. So, the server just sends the only certificate knows how based on the IP address and port number that the connection is coming in on.

This is why you can’t do SSL name-based virtual hosts with Apache, or any other web server for that matter.

Hopefully this explaination helps some people save a lot of time.