Archive of "Websites"

Archive for the "Websites" Category

Ning – the now

Posted on

Back when I started using Ning to create Commentosphere I wrote a review of the service. I have since had much more experience in working with the tools provided by Ning and there have been some improvements and so this is an update on my previous review.

Language Support
To the best of my knowledge Ning still only supports PHP and XNHTML. While they expect to support more languages, for now if you don’t like PHP you won’t like development on Ning. Their PHP support, however, is top-notch. Full PHP5 support with numerous extensions installed and many Ning-specific components that just make coding easier (automated comment system, Gmail support, etc). Having previously only worked with servers supporting PHP4, just the PHP5 support seems like a miracle: code is cleaner and I can use some of those nice OOP features I’ve been reading about for ages.

The Content Store
The content store may still be hard to get into for a coder used to SQL, but once you get your head around it, it can be easier to use in some ways. For example, there are some default fields (title, description, contributorName, createdDate, updatedDate) which, if used correctly, can make transferring code between apps easier. Built-in support for tagging objects means you no longer have to have your code manage (sometimes complicated) many-to-many tables for the relationships between tags and content.

  • All query filters still behave like an AND operation, but this limitation can often be overcome through code design. While the lack of a union (OR) operation can be painful to get around and would be very welcome, it is not a crucial thing in many apps.
  • There is still no proper pattern matching, but this too can be partially overcome by storing dummy fields that have appropriate characters (especially non-alphanumerics) replaced by spaces and using their full-text ‘like’ operator. Not the ideal solution, but workable.
  • There is still no way to change the owner of an object, but this is not the biggest problem and it seems Ning is moving towards providing API-style access themselves.
  • The OOP-style of returns still inhibits sorting to some extent, but not nearly as much as I originally feared. SQL-returned arrays are often difficult to merge and sort themselves, and XN_Content objects on Ning are not unsortable, they just require self-written sorting functions. Merging query results is not a common operation anyway.
  • The Content Store has been significantly speeded up. While mass operations begin to bog, or even freeze, when you deal with volumes approaching 100 objects, at least it is fast enough for some mass-updating operations.

Other Considerations and Conclusions
Multi-user development is still basically impossible on Ning. This is probably the feature #1 on my list of things I wish they’d add. The License problems are annoying (there’s a lot of good GPL code out there I’d like to use) but not fatal.

While Ning has not yet fully rectified my main initial points (speed content store to enable large scale importers, group development, pattern matching, better documentation) I have found that some of these points are mitigated as you get used to the service. While the speed limitation on the content store are annoying, they can be got around if you take data in smaller chunks. The documentation is not the greatest, but it is getting better, especially with the advent of the Ning Tech Blog. Group development is definitely my #1 request at this point.

Posted on is a site with an interesting purpose — to post any text. Plain text only (which is nice for posting code) this site seems free and unlimited. Just enter your text in the box and click the button. A (rather random) URL is generated as a permalink to your content (example) and then you can send that URL to anyone. For those of use who run blog(s) this isn’t all that useful — after all, most content we want to post should make sense on one of our blogs, but it could be very useful to people who just want a one-time (or a few-time) publishing of something quickly and don’t want to bother with an account registration process.


Posted on

Yes, I know, another post on a Ning app of mine. Wrinks is an app for the creation/management of webrings, blogrings, linkrolls, and blogrolls. Ring/roll creators have full power over what sites are members of their wrink and wrinks can be embedded in web pages using either JavaScript or PHP (depending on your hosting situation) as either webrings or blogrolls. The service aims at being a sort of ‘social blogrolling’ system. The first person to add a site to the system has control over that site’s metadata (title, description, feedurl, etc.).

Traffic data is stored for each Wrink and wrinks can be browsed by tag, sorted by traffic number. These lists of wrinks can be syndicated via either RSS 2.0 or JSON(P). Each wrink can also be retreived via JSON(P) for custom inclusion in webpages.

Wrink rolls can also be filtered by tag. Each site on a roll has tags, and if &tag= is passed to the wrink, only sites matching that tag (or tag intersection) are returned. This opens the way for the possibility of filtering blogrolls by tag.

Google Related Pages

Posted on

No, it’s not a new service provided by Google — it’s a Ning app built on the Google Search API. The functionality is simple. You feed Google Related Pages a URL, and it gives you back a list of related webpages. The data is collected using Google’s ‘related:’ operator. I have found in tests that it gets pretty good results when used on popular pages, but not as well when used on less popular ones.

So what is the point? Why use this instead of just doing a ‘related:’ search on Google? Isn’t this just a nicer interface to something we could already do? Not quite. You see the app also generates RSS 2.0 and JSON(P) feeds of the results. Ultimately that is the point. Results can be integrated into pages, such as blog sidebars, or watched in feedreaders. Because the data is all in the Ning app, other formats will be easy enough to add if people want them.

The Ning Playground

Posted on

The Ning Playground is a webservice for the creation of webservices. It is where the code and data for Commentosphere resides. While great efforts have gone into making the service easy for novices to jump into, this results in a less powerful toolset overall.

Application Creation
Ning handles application creation and setup admirably. Although I did not investigate starting an app from scratch with no files, such a thing is likely possible. If it is not, cloning an app and deleting all code would serve the purpose just as well. There are numerous example applications with working code that can be easily cloned from the omnipresent Ning Pivot sidebar. Once this has been done one merely has to visit the (unchangeable) URL chosen for the new app and perform some minor setup functions and there is a working application. Nothing could be easier, although if left at that it is mostly useless. Selecting ‘edit code’ from the same sidebar presents you with a directory structure where you may add or edit files to build the app.

Language Support
Ning supports both PHP and their own XNHTML. While the focus on PHP may be a negative aspect to some, for me it made it easy to get right into development, as PHP is the language I am familiar with. All standard PHP methods, as well as quite a number of extension packages are supported admirably and without the contstraints usually found on free (or even cheap) hosting. They also provide thier own set of classes to enable interfacing with their Content Store and other things, such as Gmail, Google Maps, and reading/writing RSS feeds.

XNHTML is a very nice, very easy XML derivative that enables basic output control and data access. While I did not investigate it thoroughly (being more apt to the PHP side of things) I did use it for outputting the app name (for which there is a handy tag provided), displaying certian code only if the user is logged in / a specifi user is logged in (a matter of wrapping the code in question inside the provided user test tags), and addind data to the Content Store via form for the Aggregator (which was a simple matte of using the XNHTML form tags instead of normal XHTML and using standard XHTML ‘input’ tags for the form itself). I found XNHTML to be very easy to use, and very conveniant for simple operations.

The Content Store
Here is where things got a tad more confusing. To a novice, the Ning Content Store is very easy to use and easy to learn, but to a programmer used to SQL it is a pain to learn a new data access method, no matter how easy. To its credit, the Content Store has many benefits, including easy sharing of data between all Ning apps and the ability to perform basic queries with ease using the objects provided. It has also, however, some drawbacks, including :

  • No boolean operators for filtering (ie OR / NOT), all filters applied overlap as though put together using AND.
  • No pattern matching quieries analogous to the SQL LIKE operator. The ‘like’ and ‘likeic’ operators in Ning are full-text search operators. They claim that such a feature is on their wishlist for the service, but currently it does not exist because of the load they fear it would place on the servers.
  • The object owners can only be set to NULL (anonymous) or the currently logged in user. This creates a problem for services wanting to provide bidirectional third-party APIs.
  • All data returned is in the form of XN_Content objects, which support many nice operations for the transformation of data (htmlentities, urlencode) but are sadly unsortable, making the merger of multiple queries impossible without writing your own sorting function (which I plan to get to eventually).
  • It’s slow for adding content, and if you’re adding a lot of content (either one large record or a great many records at once — read importer) painfully so. They claim to be working on this as part of their plan to optomise the entire Ning backend, but for now things such as my importer are doomed to lock up connections and cause browsers to do funny things, which messes up the import and basically makes the operation impossible.

Other Considerations
While Ning is about social applications, developement is currently anything but social. In fact, only the creator of an app can modify its code, and this permissing cannot be given to anyone else. While others may clone the app to experiment with the code and then send their modifications back to the creator, group development is virtually impossible. In response to my inquiry about this they said that they are working on solving this, but who knows when that will come about.

All code on Ning is licensed under a fair, but GPL-incompatable license, making the use of GPLed libraries impossible.

Documentation is in plenty, but not always easy to find. For example, when looking up documentation on the nature of the ‘like’ and ‘likeic’ operators none was to be found under their appropriate classes / methods. I had to go to a mammoth article titled Querying the Ning Content Store to find it.

I like Ning, I really do. I like the concept, I like the implementation, but it needs some work. For small-scale apps or non-developers the way it is makes coding easy. Even as a more experianced developer I am not one to complain about ease of use. They need, however, to add features that cater more to the power market as well as the easy market. Above all else I would like to see (1) a faster backend that doesn’t hang on running import scripts and the like (2) group development (3) pattern matching (4) better documentation.