We do not make this decision lightly. It comes after spending 1 year tryign to make the freemium model work.

The simple fact is that not enough people upgrade from free to paid. Then, the small amount of money that we do make, ends up paying for infrasturcture that is required to support all our free users (since there are many more free users than paid).

As an unfunded self supporting project we have decided it is best for us to focus all our time and effort on our paid customers from this point forward.

We hope you understand our decision.

All existing free users will be grandfathered into Pluggio’s new 30 day free trial system. After the 30 day free trial expires users will be required to pay a subscription if they wish to continue using Pluggio.

For more discussion on this subject we encourage you to read the article “Why Free Plans Don’t Work” by Ruben Gamez

• You will need to fully refresh Pluggio to see the new functionality (preferably clear your cache)
• For Friend Finder to work you will need to log-in to Pluggio a few times a day, and leave the browser window open for at least 10 minutes each time.
• If you are not getting any suggestions make sure that “Other Settings > My current follower-to-friend ratio” is set correctly

As always, give me a shout if you have any issues!

Pluggio’s “Search” & “Friend Finder” are now back online

————

You may remember that Twitter pulled search API access for Pluggio before.

Well, after they did that, I converted all searches to use oauth so that they were credited against a users account rather than the IP address.

That changed fixed things for a few months but it looks like they want to throttle things down even more.

So they have revoked search API access again.

This affects “Search” and “Friend Finder” both of which are is temporarily down

I’m not sure what I’m going to do but I’m going to try damn hard to get it resolved by the weekend.

Cheers,
Justin

Update
Search streams and general search is now working again (although links etc are not yet working in those streams)

He didn’t mind so much about ‘Bugs’. ‘Mistakes’ were the issue.

My Client’s Classification of a Bug:

On one page we had a search box, but rather than use std HTML we wanted to make it look nice by adding a background graphic with CSS. If you typed more than 30 characters the text overshot the end of the background image that would be considered a bug (an oversight).

My Client’s Classification of a Mistake:

The site had a section where you could store credit card information and a section where you could store bank information. A mistake would be if the drop down in the bank account section had the text “Credit Card” when it should  read “Bank Account” (a copy paste error).

During the discussion he made the interesting assertion that software developers ‘mistakes’ should be warranted and fixed free of charge. That’s an interesting concept and worthy of discussion. In this article I hope to show that neither the customer, nor developer can benefit from a “Warranted Code” code agreement when developing 100% hand coded custom software.

ALL Bugs Are Mistakes

It’s difficult for a non programmer to appreciate just how many mistakes it’s possible to make when coding. It’s even difficult for a new programmer to appreciate it. It’s only after you’ve been coding for a few years that you can truly grasp the magnitude of what can go wrong.

It’s not the same as, say, the number of mistakes you might make when writing an essay. After all once you have finished the essay it stays the same and the words don’t change…

But dynmic code is a different story. Each line consists of variables that rely on other variables that rely on functions that are chained together. One logic chain may have a depth of hundreds of library functions that rely on other library functions and so on. An infinite number of mistakes and bugs just waiting to happen.

If a developer were to try to think of ALL the possible things that could go wrong during their daily coding sessions – their output would probably slow down by a huge order of magnitude.

It’s not unusual for custom projects to have more than 10,000 lines of custom code, all interacting with each other. There’s an old saying “Only one company in the world makes bug free code. It’s NASA. It costs them a $1000 a line”. I bet that most startup’s would not be willing to pay $10m for creating 10,000 lines of custom code ;)

So, as a result, coders have no choice but to choose a comparatively small amount of tests to check any new code is “good enough” before handing it off.

The typical tests a web developer performs after building web functionality might be:

• Does a record get inserted in the database when I click the “Save” button?
• Does the error popup if I don’t enter a value? Correct error message?
• Is the inserted record correctly associated with the logged in user?
• etc.

In other words the developer is testing the ‘meat and potatoes’ of the application logic. As you can imagine when the developer has their head stuck in this level of ‘logic complexity’ it’s vey easy for them to miss something aesthetic such as… does the drop-down say ‘Credit Card’ or ‘Bank Account’.

Yet, from the clients perspective it seems astounding that the developer could pay so little attention to the front end and miss the obvious mistake staring them in the face – however from the developers perspective the front end is only the very tip of the iceberg.

For example, a web page on the front end might consist of two drop-downs and a button – but the backend interactions can involve thousands of lines of code with infinite error possibilities – and it is these that a good developer must focus on. After all, the wrong text on the front end is a 2 second fix, but badly tested code on the backend can bring the entire site down.

Don’t Eat Your Own Dogfood

In the world of software development it is widely acknowledged that coders should NEVER test their own output. This is for good reason. A dog can’t smell its own breath. It’s impossible for a developer to guess how other people might interact with the product they’ve made. There are other good reasons discussed here. If a developer was to FULLY test their own work it would decrease their output dramatically.

I know this because after the discussion with my client I tested the theory. I painstakingly tested all my new code to the Nth degree before releasing it. I was slowed down by about 80% due to the massive amount of permutations I needed to test for (rather than the core tests). My output became very low and my cost to ship each functional unit went up by a factor of 5. I also became bored and un-inspired with the work.

In my opinion, the very idea of warranted code is bad for the customer. It would force ANY sensible developer to test way more permutations than actually required – ‘on the clock’ – during billed time.

Yes the customer may end up with “better code” but at a huge price increase in cost and productivity.

A better idea is for the programmer to output work at their usual rate with a sensible amount of tests (i.e. database tests etc.) – but not test every possible outcome. Then as the project gets closer to launch, and bugs are picked up, they are can be cycled back to the developer who polishes them at that point.

With this method you only pay for “bugs that really matter” – vs – paying for “all possible code permutations” that a developer might think of.

You could go a step further and say that the appropriate time to get picky about how the software works and what it looks like is in the Q&A cycle (just before launch). Large software companies have an entire Q&A team that does nothing other than test software and report bugs to developers. Smaller software houses may not have dedicated teams, instead they usually have a dedicated Q&A cycle, in which everyone on the team focuses on testing the software and then cycles back bugs for developers to fix (once again, just before launch).

Development Cycle

A good testing/development cycle might look like:

1. Brainstorm features
2. Wireframe front-end
3. Developers code new custom features
4. Business owners check new custom features (loop back to step 3 as needed)
5. Final Q&A
6. Developers fix issues (loop back to 5 as needed)
7. Launch
8. Fix bugs that customers find

It’s important to note that at stage 4 we are not looking for 100% perfection. We should be looking for minimum viable product acceptable to the business owners. Then Q&A stage 5 will throw up plenty of finer detail bugs missed at stage 4 (and rightly so).

You will also note that at step 8 even more bugs are found by customers. This is why entrepreneurs should take a chill pill when it comes to perfectionist tendencies. In 20 years of software development I’ve never seen software that was bug free.

Conclusion

By using Q&A teams and Q&A cycles correctly entrepreneurs empower their developers to output code as quickly as possible without having to get bogged down in the minutiae of testing all the possible permutations as they go along. Even though it may be painful to see an imperfect product emerge, this is most likely a cheaper and faster way to develop software.

The likely alternative is to slow down developers by 80% and grind productivity to a near stand-still. It also risks stifling developers creative output, which can kill the spark and make a developers job less satisfying. Which in turn might give the developer itchy feet.

Update

There are some exceptions to this rule. For example if your software house has created a framework that you use as a cookie cutter system for all of your clients and you only create iphone apps  – then I can imagine you could warranty your work without too much of an issue (because presumably you would have tested your cookie cutter framework to the Nth degree).

The above article is targeted at developers creating one off custom code for a new start-up or business.

If you found this article interesting check out the weekly tech podcast I co-host (TechZing) which you can subscribe to on itunes by clicking this link or listen to here. You can also follow me on twitter @justinvincent

The good news is I am now completely bypassing Rackspace PHP session management (long story) – and as a result Pluggio’s performance has become super charged.

=> http://pluggio.com

User Interaction Latency.

When I use a native HTML or desktop app things happen instantly. When I click a drop down it instantly snaps down, when I scroll the page instantly moves.

When I do these things in Flash (website or air) there is a user interaction lag. Very noticeable on older machines but still noticeable even on the most modern machine. Just a fraction of a second, but noticeable none the less.

I’ve spoken to other Flash Dev’s (yes, I am a Flash developer of many years) who swear there is no Latency and that Flash is just as responsive as native apps HTML or desktop apps.. I don’t get why they don’t see it.

Anyway, user interaction latency is the only reason why I don’t use flash for my personal projects such as Pluggio

Anyone else notice it? Is it just me? Or am I correct in thinking it’s the unspoken elephant in the room…?

—

You can follow me on twitter @justinvincent or check out Pluggio the twitter client I’m building in jQuery.

If you are thinking about creating a business on top of the Twitter platform it would be well worth your reading through the list of blog posts below – in order to see what the common thread is – and what you need to do to stop your business from hitting the “naughty site” radar.

• TweetMiner suspended from Twitter API
• Buzzom suspended from Twitter API
• ManageTwitter suspended from Twitter API
• Pluggio denied access to the Twitter search API

If you know of any other blog posts with info about a site being suspended from Twitter please let me know so I can add it to the list.

And if it’s not too cheeky, while your here, you might like to check out the Twitter client I’m building :) http://pluggio.com

This breaks “Search” and “Friend Finder”.

When I asked Twitter why? Here was the response…

Hi Justin,

Thank you for your continued interest in our API. Instead of using the Search API to accomplish your application’s needs, we encourage you to look into the Streaming API instead: http://dev.twitter.com/pages/streaming_api . Specifically, you can establish one connection to the Streaming API that pipes in all the tweets containing at least one of your users’ keywords, instead of repeatedly sending search queries, using the statuses/filter method with the track parameter. Additionally, you can apply for elevated Streaming API access roles (such as track restricted, which allows you to track up to 10,000 keywords) by filling out the form at http://twitter.com/help/request_streaming . I hope that you are able to implement your app with the Streaming API, and I’m sorry for any inconvenience that this may cause you and your team.

In order to make Pluggio work with this new system it will take me 2-3 days hard core programming.

So hopefully this should be resolved my the end of the weekend.

I apologize for this service interruption and am doing everything I can to get things back on line.

Justin

Update Thu April 22nd 9:38PM PST

After thinking about this I have to say I’m quite disappointed that yet again Twitter have shut down large functionality on Pluggio without ANY kind of warning. Given that Pluggio now has almost 3700 registered users it would have been very easy for them to have sent a warning email offering me a few weeks grace to implement this new API. Which, incidentally is no walk in the park to integrate and has all sorts of ramifications about what type of server I can use for Pluggio.

Update Fri April 22nd 1:22AM PST

I have some news about this issue. It is not very good news. And makes me even more frustrated that Twitter shut down Pluggio’s search capability without warning.

Rather than use their search API they want Pluggio to use the stream API which in essence is a completely different concept to the search API. It’s very complex but I will try to explain.

With the existing “Friend Finder” pluggio will cycle through your keywords once every three hours and look for people who tweet about that topic.

So, let’s say you have #php, #apple, #ipad

Then pluggio will search for #php and then three hours later will search for #apple and three hours later will search for #ipad and then cycle back to the beginning again.

So pluggio just searches once for each term and twitter sends back the latest 20 tweets. Pluggio recommends the tweeters as friends. Simple.

As explained this no longer works because twitter turned it off.

With the stream API it works differently. Pluggio only gets access to one “real time” stream. The tweets that get sent to the stream are specified by “registering” keywords. So in the above example if you had the following friend finder words of #php, #apple, #ipad. Pluggio would need to register them and then they would come in, in real time in “one single stream” that pluggio has to store and deal with. The problem is that since Pluggio is only allowed “one stream” ALL users keywords on Pluggio need to be registered with the one stream.

At the moment Pluggio users have setup just under 1000 keywords. I ran a test with the stream with only 100 keywords plugged in, and the stream received about 5000 tweets in two minutes. By those calculations the stream will be pulling in 25,000 tweets per minute with 1000 keywords. That’s 36 million tweets per day.

I hope you can see that making Friend Finder work with the stream API is VERY different to the search API. With the search API as it is, all Pluggio needs to do is ONE search to get back 20 results every three hours. With the new stream API Pluggio has to deal with 36 million tweets a day (and that’s just with the current user base of 3700 users).

So, long story short. In this instance I don’t actually know what to do. There’s no way I will be able to build a system that deals with 36 million daily tweets by the end of the weekend (let alone the fact that twitter have not even given me access to that many search terms with the stream – Pluggio can only access about 100 searches right now).

One possibility is to make Friend Finder for premium accounts only and that way it would limit the stream, but even then it will be pulling in over 5000 tweets a minute with the current paid user-base.

Also, just to add insult to injury, the stream API does not allow keyword/location searches in a way that would be possible to tie back to any user who was using friend finder. So no matter what happens that is one nice function that will not work in the future.

Needless to say I’m upset about all of this and will be looking for some kind of solution over the next week or so.

All I can do is ask you to bear with me while I think about how to tackle this huge issue.

Today Bill Gates made the unprecedented announcement that Apple’s iTunes is banned from the Windows OS.

Our roving reporter was lucky enough to catch up with Bill and ask him why Microsoft had made this astonishing announcement. Bill had the following to say on this subject…

“In the first place we were happy that they (Apple) deployed iTunes to Windows; we got a lot of new customers just because of that one app, but, then we heard from an inside source that they (Apple) used the EXACT SAME code-base for iTunes Mac as for Windows.

On closer inspection we noticed that iTunes didn’t even use the real windows API! They make their own scroll system and their own chrome COMPLETELY bypassing our fantastic Windows OS. So, we’ve decided enough is enough. We’ll allow iTunes back into Windows when they (Apple) make the following changes.

• Apple MUST write a specialised version of  iTunes on Windows and use Windows compilers and Windows languages ONLY
  
• Apple MUST use native windows controllers such as our in built Windowing system and scroll objects.
• Apple MUST lose this RIDICULOUS attitude of writing code once and deploying to multiple operating systems. Just don’t go there.
  

If they (Apple) can follow those few simple rules, then we (Microsoft) will be happy to allow them back on Windows.”

Update:
Just to be clear this is a Thought Experiment article parodying the double standards that came from Apple’s 3.3.1 T&C clause. Also, the author (Me) is a huge fan of Apple and ironically purchased a Mac Book Pro the very day this article was written!

Update 2:

If you liked this, you can follow me on Twitter @justinvincent and/or check out the Twitter client I’m building in jQuery @ pluggio.com :)

If you check out Twitters  Policy: Rules, Terms, Violations > Spam and Abuse you can see the following:

You may not use the Twitter service for the purpose of spamming anyone. What constitutes “spamming” will evolve as we respond to new tricks and tactics by spammers. Some of the factors that we take into account when determining what conduct is considered to be spamming are:

• …
• If you post duplicate content over multiple accounts or multiple duplicate updates on one account;
• …
  

Your account may be suspended for Terms of Service violations if any of the above is true.

Long story short is it’s against Twitter’s rules and Terms Of Service.

Pluggio apologises for not to offering this functionality, but given that we know what it’s like to be shut down by Twitter, we make sure to follow their terms of service carefully :)

This is in an effort to offer our customers as much uptime and reliability as possible.