Deft Labs » Reviews

Craigslist – A Haven For Pirated Software?

Ryan — Sun, 01 Mar 2009 18:53:38 +0000

Recently, we upgraded one of our Macbook Pro laptops with the idea of selling the old model on Craigslist. Within an hour of posting the laptop, there were a handful of interested parties. The question asked by most of the interested parties was, “What software is installed?” This question seemed odd but after reviewing some of the other Macbook Pros for sale, we realized that people were selling their laptops with expensive Adobe and Microsoft software installed. The real question is, are they also selling the license for the software? If the seller does not include the license for the software, then he/she is selling pirated software. For example, one post claimed the following software was installed:

Adobe CS4 Master Collection: $2,499.00
Microsoft Office 2008: $399.00

This means for $2,000 you get a laptop worth $1,800 and software worth $2,898. What most people don’t realize is that the software is pirated and they are not selling a valid license. It is amazing that Adobe and Microsoft have not cracked down on this potentially illegal market. The reckless disregard for intellectual property rights is disturbing, although for a site that has been dealing with prostitution and human trafficking, it appears to be par for the course.

Updated: Craigslist bowed to legislative threats from around the United States and removed their erotic-services category in favor of a legal adult services category. Each post to this new category must be manually approved by Craigslist for a $5 fee.

Review: The 2008 Social Technology Predictions

Ryan — Mon, 08 Dec 2008 03:47:25 +0000

photo credit: dharma

Technology predictions are always challenging. A detailed knowledge of the past and a thorough understanding of the industry are required to attempt to predict the future. Major financial upheavals are difficult to predict and can definitely shorten growth cycles.

We are going to review the social technology predictions we made at the end of 2007.

Social Networks

LinkedIn did not purchase Meetup but they were able to raise an additional round of $22.7 million on a valuation of just over $1 billion. There has not been a massive rush to develop applications for the platform but it is not stagnant either. Reviews are mixed about its platform. Given the ease of application development, we are surprised that LinkedIn is not more agile.

According to Compete, Plaxo was able to double its unique monthly visitors in 2008. An impressive number, but Plaxo still feels like it is “the other business social network.” Perhaps a change in management might help move this product forward.

Facebook made it through what will probably be its largest growth phase (with regards to new user registrations). We predicted Facebook would grow to 100 M+ users and it succeeded by enrolling roughly 120 million unique users.

MySpace looks like it had a rough year. The site’s traffic appears as if it is still being cannibalized by Facebook. Below is the most recent MySpace/Facebook Compete chart:

With its traffic numbers sliding so much, it is amazing that the MySpace big focus appears to be who will be named CEO of its music business.

Ning did not make any acquisitions in 2008 and Marc Andreessen joined the Facebook board. This is a surprising move given that Ning was able to increase its monthly unique visitors by roughly 650%:

Technologies

Google’s OpenSocial has continued to grow and gain strength although it is still lagging Facebook’s application platform. OpenSocial has been strongly criticized for not living up to its “write once, distribute broadly” claims.

OpenId failed to deliver in 2008. The technology was adopted by several large players; however, there is a lot of criticism about the complexity of implementing OpenId.

Browser-based widgets have become the norm for just about every publisher on the Internet. They are primarily seen as additional channels for content distribution. We eventually expect to see a fairly sophisticated “affiliate” model work its way into the widget market.

RSS has continued to move forward. It is considered by many to the be the fastest growing social technology platform. Companies are finally starting to monetize their RSS feeds by inserting advertisements. Gawker Media claims to have seen a 300% gain in their RSS advertising revenue.

Blogs

WordPress appears to be moving ahead at full steam and LiveJournal appears to be toeing the line after its acquisition by Russian based SUP.

Twitter was an obvious success, as predicted. Twitter experienced explosive growth in 2008:

Tumblr also had an explosive year. To date, Compete has reported an annual traffic increase of 387%. We like and use the Tumblr services, but have been a bit disappointed by the evolution (or lack thereof) of the product.

Instant Messaging

Last year, we pleaded for Mozilla to integrate a messaging client into the browser and it appears as if they have made some progress with the 0.13 release of the Instantbird product. We have not had the opportunity to take Instantbird out for a test-drive, but we look forward to doing so.

Is Google Doing Something Evil?

Ryan — Tue, 24 Jun 2008 02:24:03 +0000

We have to preface this post by stating that we love Google Apps. We’ve been using Google Apps at Deft Labs for almost two years and have had a fantastic experience. It’s an excellent product for the price. Everyone pays $50 per user per year for a slew of business tools (a fantastic browser-based e-mail tool, group calendar, e-mail lists, browser-based office suite, etc.). This breaks down to ~$0.14 per day per user. Microsoft Office will run you ~$0.18 per day per user if you buy one new $260 license every four years. Additionally, if you stop using Google Apps after two years, you would have only spent ~$0.14 per user per day versus the ~$0.36 you would’ve paid for Microsoft Office. If you factor in the e-mail server hosting expense, you’re looking at a cost per user per day that is an order of magnitude higher when using Microsoft Office.

Productivity Gains

What’s difficult for most people is the switch to a purely web-based solution. For years, people have been using the same interface for their office tools. When you introduce a new tool you can expect to suffer an initial productivity setback. After your users have adjusted to the new tool, you should see a significant productivity gain. Google runs their highly successful business on the same tools.

Inbox Zero

One of the most important productivity gains we discovered with Google Apps is the concept of Inbox Zero. The basic premise of Inbox Zero is that you only have action items in your e-mail inbox. Everything else is archived or organized by a limited set of labels. One of the major setbacks of Outlook is search. There really is no comparison to the e-mail search capabilities of Google Apps. Even amongst thousands and thousands of e-mails, it’s easy to find the one you’re looking for. In Outlook, people tend to compensate for poor search capabilities by archiving their e-mail in (often) scores and scores of nested folders. The overhead associated with organizing and accessing data in this manner can often be overwhelming. SAI recently released a similar post describing the cost of compulsive e-mail monitoring.

What Evil?

Alright, now we have to justify our title :-) Recently, we went to renew our Google Apps account and when we were presented with the checkout screen we weren’t able to adjust the number of user accounts. This was on the confirmation page before the checkout (i.e., billing) page. Next, we thought about what e-commerce sites on the Internet don’t allow customers to modify the quantity of their order before checkout, and we couldn’t think of one. After clicking around for a minute or so we weren’t able to figure out how to change the quantity. Eventually, we sent a message to customer support and a day or so later they cheerfully responded with a link to a help page. After reading ten or so FAQs entries we found the section we needed to solve the problem.

Help Pages?

A not-so-radical theory in user interface design is that help pages are a list of failures. Sometimes they’re intentional but most of the time they document strange scenarios/functionality that isn’t intuitive to the majority of users. Looking at this issue, it’s obvious to us that modifying the quantity of your order should be apparent to everyone. The real question we had to think about is does Google not understand that modifying your order before checkout needs to be obvious or did they intentionally make it difficult in hopes that they would experience a rebate effect (i.e., if you require the customer to go out of their way then they probably won’t make the effort to do so, even if money is involved).

If you consider that Google has 92% of the web-based productivity market then you realize the amount of money that could be collected by making a quantity change difficult. One pleasant surprise is that they pushed our renewal date back a few days to allow us to compensate for the customer support interaction :-)

Google’s App Engine

Ryan — Thu, 24 Apr 2008 01:46:11 +0000

Recently, we’ve been researching cloud computing so we decided to take a look at Google’s App Engine. We had hoped to write this earlier, but it was some time before we received access from Google to use App Engine :-) We’re excited to see cloud computing move forward but, as usual, we’re digging through the hype.

Data Access

Data access appears to be well implemented. Users have the option to create Google Query Language (GQL) or object-based queries. GQL is essentially a scaled down version of SQL (currently, GQL does not support join statements). The GQL extension is handy, but we expect most people to use the object query interfaces. We were pleasantly surprised when we saw that App Engine supports transactions.

Configuration

The configuration files for App Engine use YAML. While this is cool from a geeky staindpoint, XML would’ve been a better choice for the masses. Hopefully, Google will add a nice web UI down the road that removes the need to edit these ugly configuration files.

Local Development

We like the local development SDK, although it needs a lot of work. When we added an error to our “hello world” application, we were a bit frightened. The stack trace was scary and the first 90% of the message related to App Engine SDK (dev_appserver.py). After scrolling to the very bottom of the page, we found our problem:

Runtime Language

Google’s App Engine only supports Python right now. However, there is a placeholder in the primary configuration file (app.yaml) that keeps the window open for additional language support down the road. We’re not huge Python fans, but they should be able to easily integrate just about any language into the cloud in the future.

Pricing

Details about how much Google will charge for the service haven’t been released yet. The free account only allows 500 MB of storage so it seems as if their model is to make money on storage and CPU. Their bandwidth prices are pretty good… they offer 10GB in and out per day for free. We shall see how they do in their quiet entry into the CDN industry. Perhaps this will be the product that pushes Akamai to sue Google over patent 6,108,703.

Missing

The main component that is missing is an advanced UI. Google lets you perform some basic operations in their administration interface but it’s not even close to a robust environment. We expected a really slick browser-based editor from Google.

Also noticeably absent is the ability to run scheduled/cron jobs.

Vendor Lock-In

There is huge potential for vendor lock-in with App Engine. Google has open sourced all of the App Engine APIs, but if large tech companies don’t support/implement the platform then it’s little more than a defense to ward off lock-in criticism. AppDrop has already released an alpha implementation but without support from an IBM, Red Hat or Novell, it probably won’t gain much traction.

Competition

Google’s App Engine release formally kicks off the third chapter of the Internet’s evolution. There are already several startups working feverishly on cloud platforms and we expect lots of exciting news this summer about new companies trying to compete in the space. Of course there will be a lot of companies who washout, but the more people involved, the more innovation we’ll see.

Overall

If App Engine had been released by a startup, we would’ve given the product five stars. However, Google employs nearly 17,000 people and is worth roughly $174 billion. We’re happy that there are cloud platforms coming to market but expected more from Google.

We had the opportunity to play with the 10gen alpha, and so far, App Engine has some ground to cover to compete in the cloud space. Of course, having the most recognized brand in the world goes a long way ;-)

WordPress 2.5

Ryan — Thu, 17 Apr 2008 03:51:54 +0000

We decided to take the plunge and upgrade to WordPress 2.5. Despite the many prompts to upgrade in the WordPress administration tool, we decided to wait a few weeks to before upgrading the application.

The process was easy but definitely required more typing than we expected. With over 15 plugins installed, we were surprised that everything but PhotoDropper worked after the upgrade.

The 2.5 admin tool is a pleasant surprise. The interface is fresh, clean and simple. There are some things we would change surrounding wide computer screens but, they’re minor inconveniences.

We moved from Blogger to WordPress about two months ago and so far we’re very happy with the product (and the price – free).

The three step upgrade process is available on the WordPress site. The entire upgrade process took about 20 minutes :-)

Update: PhotoDropper fixed their plugin and it works great.

Yahoo! User Interface Libraries

Ryan — Thu, 28 Feb 2008 22:14:23 +0000

We are always on the hunt for web technologies that add functionality and decrease development time. We have been tracking The Yahoo! User Interface Libraries (YUI) for a while and are finally ready to slap on the Deft Labs seal of approval :-)

photo credit: V.P.Tz.

Paradigm Shift

For more than a decade engineers have been debating about which technologies are best suited for dynamic HTML page development. Typically, a developer would fall into the PHP, Java, Microsoft, Perl, Python or Ruby camp. All the platforms have similar tools, strengths and weaknesses when it comes to dynamic page development.

Something a lot of developers haven’t fully grasped is that the future will not include much in the way of server-side Html generation. The Internet makes a lot more sense when HTML clients are developed exclusively in JavaScript/static HTML. The paradigm of client-side HTML generation definitely isn’t new but the tools available are finally maturing.

Review

Over the last year we researched Dojo, GWT, script.aculo.us, Prototype, and YUI. All the frameworks have numerous strengths and weaknesses but we found YUI to be the best in show. To make our decision, we looked at:

Documentation
Available Libraries/Functionality
Sample Code
Styling Attributes
Developer Adoption
Code Performance
Reliability
Project Progress
Content Distribution

We found that when all aspects were considered in each framework, YUI was the best solution for us.

Content Distribution

The beautiful part about client-side HTML rendering is that your client can be deployed globally on a CDN. Requests for dynamic content will still be sent to your servers via AJAX but the amount of data transfered for each action/request is drastically reduced. Additionally, you can cache data on a CDN in the form of JSON encoded data structures/files.

An added bonus of using the YUI is that you are able to piggyback on their content delivery network. This provides lower bandwidth costs, geographic distribution but most importantly caching in the browser. Yahoo! also uses YUI so there is a good chance the libraries will already be cached in the user’s browser (thus decreasing the time to load the page).

SEO Issues

One of the primary issues with an all JavaScript UI is Search Engine Optimization (SEO). Most bots or crawlers are not smart enough (yet) to render JavaScript UIs. This creates a problem when user’s are trying to find a piece of content through a search engine. Until the crawler technologies catch up, there is a simple way around this problem. You can identify the user agent in the request and display a separate/simple page. For example, if the request detects a crawler then you can display your content in a bot friendly format.

Of course the links provided to the bot must be translated when the user agent is indicative of a user. To assist you in keeping track of the crawlers you can use the data provided by the Browser Compatibility Project. The basic flow of this looks like:

If you’re using Apache you can accomplish this using the rewrite module.

Another way to simplify things for crawlers is to create a Sitemap file with all of your pseudo crawler links. If you only have several pages that need to be indexed then you can always use the