Posted by John
Michael J. Shapiro, February 10, 2010
Zerista, a provider of event networking software, was selected to create a customized event and mobile social networking solution for the GSMA's 2010 Mobile World Congress, a mammoth event for the mobile industry to be held Feb. 15-18 in Barcelona, Spain. Read the entire article here ...
Posted by Anders
Many of you have asked for the ability to download maps to either GPS devices or Google Earth. We're happy to say we now support both formats.
To download a map you first need to login (this is a temporary solution to stop bots from constantly downloading maps). Then go to your map, and click the "Edit" button under the map title. That will take you to the map page, where you'll see a "Download" button, also under the title. From there you can pick which ever format you prefer.
KML is used by Google Earth, which is a freely available 3D map browser. Thus, you can see how you map looks in a 3D environment. That is particularly helpful for hiking and biking rides where you can preview the route, see what the scenery looks like and get a better feel for elevation gains and losses. This has all of the data from the map, so for any general usage, this is the best format to choose.
Most GPS receivers can hold tracks and waypoints, and GPX is a popular file format for transferring this data to and from different GPS devices. We already support uploading GPX files, and now we support downloading GPX files which allows you to load a map onto a GPS device.
This is useful for hikes and bike rides, or anytime you are going off road and want to make sure that you stay on the trail. Since all features from the map are put into the GPX file, any notes or special locations that people have added to the map are converted into either tracks or waypoints.
ESRI Shapefiles are the classic format for transferring data between Geographic Information Systems (GIS). A shape file is actually three files-in one, so to simplify things we zip the files together so you only have to download one file. Unless you're a GIS professional, you probably won't be interested in this format.
Posted by Doug
For anyone interested, here is a highly technical peak into what we have built. We have a central concept of items. Not everything is an item, but most things are -- maps, features, users, communities, comments, notes, even locations (although they aren't stored in the database, but generated on the fly by a geocoder). This allows us to have a common set of data for everything. One example is "articles," which we use for map descriptions, user profiles and comment bodies. Other examples are permissions, ratings and geometries.
It's a handy system, and works fairly well -- we just use the hooks we need, when we need them. But, occasionally, it has gotchas. For instance, when deleting comments we forgot to delete their items. That can cause problems - say a search returns some of these partial comments - the unsurprising result is an error.
This is partly a symptom of something else -- items were a late addition. Originally, maps, features, users and communities were their own thing, as well as comments. When we changed over to items, the code for displaying them also changed. That change happened long ago, but ever so often we run into an unanticipated side effect like this one.
But now they're fixed again, and we've got tests in place to make sure they stay fixed.
Posted by Anders
We've had icons for a while, allowing you to upload images to decorate maps, features, and your account. Due to popular demand, we've now added the ability to add photos images to features and maps.
The maximum pictures size is now 640x640. Unlike the smaller image sizes, this large size isn't cropped to be a square. Thus, nothing will be cut out of the image.
Here is what the "Feature Photos" looks like in the feature viewer:
Next up is a photo browser, that lets you see browse through photos using their larger size.
Posted by Doug
We've had a news feeds on the site for some time now. Unfortunately, as the site has grown, we realized our original design wasn't fast enough, particularly for large communities like the Colorado Mountain Club and NTEN. So it was time for a redesign.
Our news system consists of two concepts - events and notifications. Events happen when a user performs some action on the site, say, creates a map. Notifications are the individual items that make up a news feed. The big difference is that events are generic while notifications are targeted to specific users. To understand the need for this distinction, its easiest to go through an example. When you create a map, the notification in your news feed will be different than the notification your friends see.
Ideally, notifications can be generated on the fly from events, allowing you to have full and accurate information for every situation. But that turns out be slow. Very slow. Since notifications are viewed many times more than they are created, our original implementation was designed for fast retrieval and slow creation. To do that, we created all the notifications at the time of each event and store them into tables for later retrieval.
Of course, this ultimately ended up being a problem. Over time, we started using notifications in ways that we didn't expect. For example, they became a big part of our integration with Facebook and Twitter. We also added new ways of viewing them on the site that the original design didn't envision. Most of all, we didn't plan on having communities with thousands and thousands of users quite as soon as we did. As these problems came up, we fixed the quick and easy things - such as generating notifications in background processes so as to not slow down user requests. But it wasn't enough, and it was time for a major redesign.
Our basic premise remained the same - fast read and slower creation. But we needed to significantly improve notification creation times so that we could generate thousands of them at a time. We did that by storing the original events along with the notifications. That allowed us to move all the notification creation code into SQL, thereby vastly speeding up creation times.
Although it seems, and is, a simple change, it of course rippled throughout the system since notifications are used in so many places. Luckily one of our mantras from the beginning is as complete test coverage as we can manage. So although it turned out to be more painful change than we thought, we had a good idea at most times of what still needed to be fixed.
And now that we've done it, the notification system is once again fast. It's not perfect, of course (no one can ever really afford perfection), but it's good enough for now.
Posted by Charlie
Yesterday Apple released a beta version of Safari 3 for both Mac OS X and Windows.
We've wanted to support Safari for a long time, but haven't due to its lack of SVG support and rich text editing. Safari 3 fixes those issues - so we went straight to work getting it to work.
Unfortunately, we've had mixed success so far. On the positive side, the site renders beautifully and rich text editing seems to work well enough.
On the downside, the SVG support seems buggy. In particular, Safari does not correctly recognize mouseover events on features on the map when the map is offset from the top left corner of the page. In addition, as you drag a map around, Safari seems to "lose" feature - they flash in and out of existence.
For the short term, we'll update within the next week to provide read-only access to Safari. At the same time, we'll see if we can come up with any workarounds for the issues we've encountered and submit the apppropriate bug reports to Apple.
As for older versions of Safari, we are considering releasing a modified version of our software that lets you view/edit points but not lines or features. Does that sound like a reasonable thing to do?
Posted by Charlie
One of the tricky things about community driven sites is validating user uploaded content. If you aren't careful, you can create security holes that are known as cross-site scripting vulnerabilities.
The idea is that an attacker uploads content to the site which includes embedded JavaScript code. When another user visits the attacker's profile page, the malicious JavaScript code gets embedded into the HTML that the server generates for the page. The browser then executes the code as part of the user's environment, thereby giving it access to the user's private information.
As a result, you have to be very careful to check any uploaded content. This turns out to be quite difficult - new cross-site scripting vulnerabilites are constantly being found on the largest web sites. A particularly famous one is the Samy Worm that targeted MySpace in 2005.
When we rolled out the new article functionality for Maps earlier this month, we also implemented a new content verification system. If you are interested in the technical details, I've provided more details on my blog.
Posted by Charlie
One of the great mysteries of software development is what is the best way to do it. Its just like diets - every year or two the latest fad comes roaring through and everyone jumps on board. And just like diets, there is no one right way - it depends on what you are trying to accomplish and what type of team you have.
When it comes to writing software, on one extreme is the belief that every possible piece of functionality should be designed ahead of time in excruciating detail - resulting in thousands and thousands of specifications that almost no one reads. On the other extreme is the belief that the best thing to do is jump right in and see how things work out. In some cases either of the extremes is the right answer, in most cases something in the middle is better.
However, one thing that no development process can account for is human creativity. Just like painting, or writing music, or designing buildings, software development is a creative process. A couple of months ago we implemented one of the more complex parts of the system - who can view or edit features that are on a map. This turns out to be quite tricky to get right - so over a month we thought long and hard to figure out the best design. Once we thought we had it, we spent a couple weeks implementing it and thoroughly testing it.
And yet we were wrong. In a flash of insight last week, we discovered a much better solution - one that greatly simplifies the code and makes it reusable for permissions on any type of object (map, feature, comment, etc.). It took another week of work to implement the new solution - obviously begging the question why we didn't see it at first.
And this question goes right to the heart of design. Good design is based on experience - without it you don't have the requisite knowledge to solve difficult problems. But often times experience is not enough - difficult problems require that you immerse yourself in them trying any number of solutions until one clicks. Even more maddeningly, you usually then get so engrossed in a problem that so that you lose your ability to see the solution. At that point you have to walk away from the problem and give your subconscious a chance to put all the pieces together. If you're lucky, it will present you with a solution in the form of a Eureka moment when you least expect it. And that is exactly what happened to us.
Which leads to an obvious conclusion. The more you work, the less creative you are because you don't give your subsconscious enough time to find the best solution. This is hardly a novel thought - a quick searh on Google turns up a number of studies of this phenomenan. But its worth keeping in mind - if you have a really tough problem, and you've put in the necessary hours to fully understand it, then your best bet for solving it is a day at the beach or skiing!