Autoretweet from Twitter list

It's finally there!
We've just released new feature for RoundTeam which allows you to automatically retweet from any public Twitter list.

Using this feature you can autoretweet all feed generated by particular list on Twitter. You still can filter it by #hashtags, @mentions, or keywords.

Of course, retweeting from followers, following (those who are followed) and all Twitter is there as always.

More about how to use and configure auto retweet from Twitter list here: http://roundteam.co/faq#faq14

You are welcome to give it a try, it's a big fun :)

Like us on Facebook: http://facebook.com/RoundTeam
Follow us on Twitter: @RoundTeam
Visit our web-site: http://roundteam.co

Design and implementation pattern

One of my favorite approaches to design and implement new application components is the following:

I start with the public interface of the component, defining how it will communicate with the other app components and external world.

This provides a vision of how future component will be integrated into the application.
Then I continue with writing a skeleton for "business" methods. These methods are usually very high-level, they don't have complicated parsing, validation, operations with DB etc. Usually all such methods are quite declarative and can easily be read. For example:

 public function add(Team $team, $allListItemStr) {

  $listItemsToAdd = $this->parseAll($allListItemStr);

  $listItemsExisting = $this->allByTeam($team);

  $newItems = $this->findNew($listItemsExisting, $listItemsToAdd);

  foreach ($newItems as $newItem) {

   $newItem->setTeam($team);

   $newItem->save();

  }

 }

This is simplified example of one of the components of RoundTeam web-app responsible for adding new list items.

So, I start with writing such skeletons for each public interface method. It helps to identify the workflow of these methods, extract future common helper methods etc. Nothing more is done at this point. Such methods like "parseAll" and "findNew" are not yet implemented.

This process can take several recursive steps in depth when one of the methods used in public interface methods requires invocation of several other methods to work etc.

Once this work is done, full component architecture is visible. How it will communicate with outer world, what is the workflow of the business logic methods etc.

After that I start writing actual low-level code like parsing, DB operations from the very bottom. From the most low-level methods. Those methods can usually be easily unit-tested since they are "atomic" meaning they don't rely on other complex methods etc. Those methods are implemented and covered with unit-tests one by one, level by level, until the most high level business logic methods actually start to work. At that point usually it's also easy to cover them with unit-tests, since all methods they rely on are already implemented and unit-tested.

This approach of course has it's own boundaries, but in general it's quite commonly used in my development.

One of the pitfalls here, is to think in advance about the error handling. How errors are going to be propagated from the low-level methods and influence the behavior of the high-level methods. If one missed this step in the beginning of design phase, there is a risk whole architecture should be re-done in the middle of the implementation stage.