Emad Alashi’s Blog

Update: Twitter “statuses/followers” API documentation had a small note at the bottom that says that it returns only 100 followers if no paging is used, I have updated the script accordingly. Thanks to @RamyMahrous for notifying me on this in his comment below. <End of Update>

For a long time I thought that @DotNetArabi shouldn’t follow it’s own followers due to various reasons I had, but lately I discovered that I was wrong. So I have decided to follow them back no matter how many they are, but that would be a tedious thing to do manually. Here comes Powershell to the rescue.

I wrote the following Powershell script in Powershell ISE (the Integrated Scripting Environment) which is already shipped with Win7, utilizing Twitter’s API’s and it did the trick:

———————–
 $wc = new-object System.Net.Webclient
 $wc.Credentials = new-object System.Net.NetworkCredential "dotnetarabi","UseYourOwnPWbuddy!"
 $cursorCount = "-1"
 
 do { 
 
 $rest = $wc.DownloadString("http://api.twitter.com/statuses/followers.xml?cursor=" + $cursorCount)
 $xml = [xml]$rest
 foreach( $user in $xml.Users_list.users.user ) 
 { 
    $wc.UploadString("http://api.twitter.com/1/friendships/create/" + $user.screen_name + ".xml", "")
 } 

 $cursorCount = $xml.users_list.next_cursor
}
while($xml.users_list.next_cursor -ne 0)

——————-

It’s simple and straight forward; I used “UploadString” method of the Webclient class because it produces a “POST” HTTP request required by Twitter API rather than “GET”.
Note that the response you get from the “Create” API will be either an XML representation of the followed-user entity, or a server error “Forbidden” for many of reasons Twitter may have. This is how you will know if each “follow” procedure succeeded or not

Thanks to Helge Klein I could highlight my Powershell script by his script here

Today we came across an interesting issue at work: we have two teams A and B who interchange API calls. Team A needed an API from team B to process a business that is owned by team B of course. The signature was like the following:

public OutputEntity MyMethod(List listOfIds);

It appeared afterward that this method was very slow, and the client was already very upset about the low performance, which consequently caused big pressure on the teams by the superiors to enhance the performance.
After investigating the issue, it appeared that the list of ID’s sent as input consists of some ID’s that do not need to be processed, this criteria of “not need to be processed” is a business owned by team B, done by using properties of the entities these ID’s represent. So the  solution to this issue was one of the following:

1. Moving the business out of the API to the client application to do the filtering, since the calling method already has the entities themselves (not so good to move business out of scope!)
2. Let the API do the filtering, but this will worsen the performance because the API will have to retrieve these entities from the database in order to use its’ properties!

So is that a dead end? actually that was stupid! the situation was stressful enough and pressured by our superiors to enhance the performance that we missed a very simple fact: pass the list of entities themselves!

Stressful situations make us stupid, so make as less stress as possible on your team, help them to be smarter.

We are working on this big project at work in which several teams are assigned to different modules. The modules are, naturally, overlapping in certain areas where they they need to interact with each other through API’s.

One of these modules is central and crucial to the rest of the modules, the dependency is very high that the team has to provide many API’s. Certain API’s was needed by different modules; our team needed a list of entity X, and another team also wanted a list of entity X, BUT…we had different criteria!

For example, Entity X had an Enum property called “Type”. The API provided a parameter to filter on this Type, but the options were limited to couple of choices; either you get entities of THIS type, or you get all entities.  If you needed type A and B only, you will have to get all the entities in the database, or make two hits to the database and join the two lists.

A solution was to give all the various options to the user as optional parameters some of which was Array of values. This resulted in an ugly API signature that had many optional parameters, and when ever a new criteria is needed, the signature would change and break all the already existing calls for the API, and I will not even imagine how the SP would look like!. An ugly alternative as well is to create new SP for each different criteria. Both choices are maintenance killers.

In such cases, the dynamic queries are just wonderful; depending on the properties the end user needs to filter on, a query will be created dynamically with proper operator passed. Usually ORM engines, or similar engines, will provide you with an “internal language”, e.g. SubSonic:
——————
Episode  ep = new Select().From<DA.Episode>().Where(“Title”).Like(“SOA”).ExecuteSingle<DA.Episode>();
—————-

Another example is the “query by example” in NHibernate (code snippet is taken from NHibernate help):
——————-
IList episodes = session.CreateCriteria(typeof(Episode))
    .Add( Expression.Like(”Title”, “SOA%”) )
    .List();
—————–

And, of course, LINQ:
—————–

var episodes = from x in db.Episodes where x.Title.Contains("SOA") select c; ---------------

Or you can build your own .

I hope this gives an insight.