A few weeks ago, we celebrated the launch of the new PUMA.com, the culmination of a nearly two-year effort here at Viget. The whole site is driven by a CMS written in Rails, and I’m very proud of the technological platform we’ve developed. I want to focus on one piece of that platform, Redis, and how it makes the site both rock solid and screaming fast.
jMapping has been long overdue for an update. Google announced a beta of version 3 of their Maps API in May of last year, and then made it the official version this May. jMapping has always used version 2 of the API along with the MapIconMaker (which is dependent on version 2 of the API). But as of today we have now moved to full version 3 support. Additionally, we're now officially supporting version 1.4.x of jQuery.
Making the change to version 3 of the Maps API meant we could no longer use the MapIconMaker library. Instead we've switched over to the StyledMarker library. This doesn't mean much of a functionality change for most users, but it does mean the values for the category_icon_options option has changed slightly (see the documentation for details).
The other change that will break compatibility with existing apps that use jMapping is what value type is expected of the map_config option. Previously, this was expected to be a callback that took the GMap2 object as its parameter, and allowed the developer to call functions on the GMap2 object to modify how the map would be rendered. In version 3 of the API most of the render options are no longer modifiable after initialization, so instead we accept a MapOptions object that will be used to create the map object instead of the jMapping defaults.
Those changes aside the plugin should work exactly as it always has, providing a quick and easy way to add Google maps integration to a page via a jQuery style API.
As always, feel free to contribute by forking the project on Github, or submitting feature request or bug reports. You can find the latest download links here.
We're always excited about new trends here at Viget, and the most recent phenomenon that's caught our attention is NoSQL - the reaction against traditional relational databases like MySQL. The movement has been characterized by an explosion of interest in key-value stores, document-oriented databases, and other (mostly non-relational) alternatives for data storage. Several of the developers here in the Labs have been experimenting with these emerging systems, and over the next few weeks, we'll be posting our thoughts.
We'll show examples of situations in which, say, MongoDB works particularly well - and we'll also show situations in which you're much better off staying with something more traditional. In fact, that's the conclusion we've drawn from the whole thing: just as many different programming languages can coexist, with each being useful for some particular set of problems, many different databases can coexist - with each being useful for some particular set of domains. Even more interesting to me, though, is the set of complex domains that can be best served with multiple database systems... Hey, if Twitter can rely on Scala and Ruby, why can't we build an application with MySQL on top of CouchDB?
In the course of this series, we'd love to hear your feedback - how are you using these alternatives to traditional databases? Have you abandoned Postgres to Tokyo Cabinet, or tested with Neo4j? How are they working for you?
Look for the first post in the series next week!
One of the most common feature requests from our clients is Google Map integration. On two projects recently I found myself creating very similar functionality: a map of points with links in a nearby list that activate the markers on the map. This seemed like an excellent opportunity to package up functionality into some sort of “module.” Given that jQuery is my framework of choice I decided to go the route of a jQuery plugin (see David’s recent post for the advantages of jQuery plugins).
My goal when crafting this plugin was to use the convention-over-configuration paradigm, yet allowing customization, and to have the data be embedded in the HTML, allowing for graceful degradation in the rare cases where Google Maps wouldn’t be compatible. This would also allow the javascript the end user would need to write to be very minimal; one line is the default case.
The requirements for the most recent project were simple enough:
div.While we were creating the SpeakerRate API, we noticed that ActiveRecord’s serialization system, while expressive, requires entirely too much repetition. As an example, keeping a speaker’s email address out of an API response is simple enough:
@speaker.to_xml(:except => :email)
But if we want to include speaker information in a talk response, we have to exclude the email attribute again:
@talk.to_xml(:include => {
:speakers => { :except => :email }
})
Then imagine that a talk has a set of additional directives, and the API responses for events and series include lists of talks, and you can see how our implementation quickly turned into dozens of lines of repetitive code strewn across several controllers. We figured there had to be a better way, so when we couldn't find one, we created SerializeWithOptions.
at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.
Future Insights Live -
April 29
to May 4
Future of Web Apps, Future of Web Design, Future of Mobile, and Future of Web in the Enterprise have joined forces to bring you our most comprehensive event EVER!