Joe Mayo

As a Twitter developer, I’ve had a fair amount of experience with their API and thought that I might express how I think Twitter could help developers.  Twitter interacts with the community, requesting feedback on new features, helping developers, and generally letting us know what is happening with API status at Twitter Development Talk.  Twitter also offers API Announce to let developers know what is happening with the API.  If you’ve been watching, the Twitter API team has been growing and evolving in a positive direction to help developers.  These are all good signs that indicate a continued dedicated effort toward improving their API, but there are still pain points that I’ll address in the following paragraphs, including testing, API availability, and roadmap.

One of the first things I noticed when coding against the Twitter API was the glaring absence of a test environment.  That means all coding and testing must be done against the production Twitter environment.  As a professional software engineer, this ripples against the grain of common sense and is still something that causes me hesitation any time I test.  The current answer is to set up a dummy account on Twitter to test with.  However, that still leaves me wondering about things like usage policies and the like.  For example, what if I wrote a test that slammed Twitter with tons of new requests.  Would an unfortunate result in my programming and testing behavior make me a hacker, a spammer, or just an idiot that didn’t desk-check his development code; and what would be the response from the folks at Twitter evaluating the results of my actions? To fix the problem with no test environment, Twitter should offer an endpoint for just testing and let developers establish test accounts.

The way Twitter is handling release of the latest API’s is to give a selected set of users access to a feature and a selected set of developers access to the associated API. This is normal with Beta testing and developers who weren’t included should normally not be concerned.  The problem occurs when the feature is given to the general public and the vast majority of developers are caught unprepared to support users.  Two features that follow this pattern are Lists and Retweets.  I’ll give Twitter credit for publishing specs, which at least gave some developers the ability to write code to the spec, but it doesn’t solve the problem.  The problem is that the situation can result in users frustrated because their 3rd party applications are slow in providing support for the new features. Just an observation, but those users could always dump their current 3rd party vendor and run to a 3rd party vendor that was included in Twitters beta program for early API access.  It would be helpful if Twitter released new APIs to the developer community before releasing the new Web site feature to the general public.

The Roadmap could be much better. The problems are that it is too tactical, lacks important information, and is useless for planning. If there were a good thing I could say about the roadmap is that it seems to be fairly well-organized and shows some of the items they have considered for implementation; although some items, such as the test environment plans discussed earlier, are nearly a year old.  Looking at the items on the list, most subject areas look like down-in-the weeds topics that are important in themselves, but provide no strategic direction or vision on where the API is headed. For example, one of the items is named “Return User object on end_session method”, which is important; but is important on only that part of the API. These tactical items are already on the bug list and Twitter could enhance the developer experience with a separate priority list for bugs; which might be entirely possible with the existing Web site tools.  Another problem is that the Roadmap doesn’t include information about upcoming APIs, which I believe is more appropriate content.  For example, what if the roadmap had included significant API features such as Retweets, Lists, or Geotracking, which are the type of things that should be included in a roadmap? The purpose of the roadmap should be for developers to look at what Twitter has planned and prepare accordingly. The Twitter roadmap has no information on priorities or planned implementation. If 3rd party applications want to plan for future growth, they can’t use the roadmap for any long term plans because Twitter publishes previously unannounced APIs before items on the roadmap are addressed.  The roadmap would be much more useful if it concentrated on strategic initiatives that included upcoming APIs with at least some indication of when the API will be implemented.

As Twitter continues to grow and 3rd party libraries and applications glom on, Twiiter should nurture the developer ecosystem they brought into being.  A testing platform is long overdue, proper release of APIs should be fair, and the roadmap should support planning and vision rather than being a hit list for heads-down coders.  I’m sure you might have a favorite item to put on Twitter’s developer ToDo list, but these are the things that I’m thinking about the most.

@JoeMayo

If you search for AG_E_PARSER_BAD_TYPE, you’ll find many entries going back to early Betas of Silverlight, which may or may not be applicable today. When I received this error, my search led me to Bill Kratochvil’s blog entry, AG_E_PARSER_BAD_TYPE Adding Silverlight Toolkit control to module.

In my particular problem, I was using Prism and my project with Shell.xaml (Project A) referenced another project module (Project B), which referenced two utility libraries (Project C and Project D). The occurred during the call to InitializeComponent() in a View in Project C. The line number and column in the exception message specified code in the View XAML that referred to an object in Project D.  Going back to Project A, where Shell.xaml resides, I observed that Project A referenced Project B and Project C, but not Project D.  I fixed the problem by adding a reference from Project A to Project D.

So, adding to Bill’s observation, it appears that this problem can be solved by locating the project of the object in the XAML where the error occurs (Project D) and ensuring that the project containing Shell.xaml (Project A) has a reference to Project D. 

If you’ve ever opened the Visual Studio Entity Designer and spent more than a few seconds searching for a specific entity, you’ll quickly wonder if there must be a better way to do this.  Fortunately there is, through the Model Browser.  Finding the specific entity is only a few clicks away:

1. Open the Model browser.  You can select View > Other Windows > Model Browser:

2. When you see the Model Browser window, open the Conceptual Entity Model, which often has the “Model” suffix if you created the model with the default naming scheme.  In this example, I’m using the Northwind database, which is named NORTHWINDModel. Then open the Entity Types branch and you’ll see something like this:

3. To find the Customer entity, right-click on the Customer entity in the Model Browser and select Show in Designer, like this:

4. The designer automatically centers on your entity.

Got to looking at the Laconica API and noticed that they built a Twitter compatible API.  This got me thinking that LINQ to Twitter might work with Laconica.  So, I pointed LINQ to Twitter at http://jtweeter.com and fired it up:

var twitterCtx = new TwitterContext(userName, password, "http://jtweeter.com/api/", "http://search.twitter.com/");

var publicTweets =
    from tweet in twitterCtx.Status
    where tweet.Type == StatusType.Public
    select tweet;

publicTweets.ToList().ForEach(
    tweet => Console.WriteLine(
        "User Name: {0}, Tweet: {1}",
        tweet.User.Name,
        tweet.Text));

And Success!

The buzz is on for a release date for Silverlight 3.  Pulling info from Silverlight.net Forums, ScottGu’s Linked .NET User Group presentation, and TweetSphere, it looks like we’ll see something around July 10th.

Delphi Prism that is.  Since Delphi Prism supports LINQ, I wondered if LINQ to Twitter would work with it.  It broke on my first try because the enum parameters were being parsed differently than in C#.  So, I fixed this and checked in the new fix: http://linqtotwitter.codeplex.com/SourceControl/ListDownloadableCommits.aspx.  Be sure to grab ChangeSet #53131 or later.  Here's a small demo application:

namespace TwitterTest;
 
interface
 
uses
  System.Linq,
  LinqToTwitter;

type
  TwitterTestClass = class
  public
    class method Main; 
  end;

implementation

class method TwitterTestClass.Main;
begin

  var TwitterCtx : LinqToTwitter.TwitterContext := 
    new LinqToTwitter.TwitterContext;

  var Tweets :=
    from tweet in TwitterCtx.Status
    where tweet.Type = StatusType.Public
    select tweet;

  for tweet : Status in Tweets do begin
     System.Console.WriteLine(
        "User Name: {0}, Tweet: {1}",
            Tweet.User.Name,
            Tweet.Text);
  end;

end;
 
end.

Now my Delphi friends have an easy way to program Twitter applications.

IE8 has a feature called accelerators that allows you to highlight screen artifacts and do things to them.  One of the neat features that I used today was the translator accelerator, shown in the following image:

As you can see, this was on Twitter.  I highlighted the tweet, which showed the accelerator icon.  Then I picked Translate with Live Search, selected the from/to languages, and viewed the translation.

Another step in making the world a smaller and friendlier place to be.

I’m building a data model for a pretty good sized database.  I’ve used the SQL Server data designer in the past and that has been useful. You get a nice visual on tables and relationships and can build different views.  For this job, I wanted something simple where I could communicate the data model, have documentation, and make quick changes.  SQL Server data diagrams are the actual database as opposed to the abstraction you get when modeling, print out very poorly, and are slow as a dog to do anything with.  So, I took a look at Visio.

I’ve used the Visio entity model designer before, but it just didn’t click with me.  Maybe it was something I wasn’t used to or maybe I preferred having the larger workspace of the SQL Server designer; I don’t know.  However, this go round, Visio is working quite well.  It lets me model at a higher level of abstraction, concentrating on properly capturing data requirements without too much focus on detailed design. Since it’s page based, it will print out nicely, which is well suited to what I want.  Another big advantage is that working with Visio is remarkably quick.  Drag-and-drop is quick, naming is easy, and adding fields is a simple matter of clicking a tab and everything I care about for defining a field is on one line, including field description.  Associations are quick drag-and-drop and the FK/PK relationship is immediately inferred, which is what I want to do most of the time anyway.  Cool stuff that Visio; now if I could just figure out how to push my model into SQL Server real quick…

Something interesting happened today in Twitter.  It started when someone was reading the C# Tutorial.  At the same time, I was updating Lesson 12, which that person was reading. The site bugged out during the update, but came back to normal. I tweeted the update, which appeared on a Twitter badge that I put on C# Station. The reader saw the tweet on the badge, realized what had just happened to them, and responded to me on Twitter.

Maybe I’m a easily fascinated by shiny things, but this is one of the moments that demonstrates the power of social networking. Whether its a blog, Twitter, or any other Web 2.0 site, the possibilities for enhanced communication and interaction are huge. It’s no wonder why new on-line mediums, such as Twitter, are getting so much attention in the news. Journalists are in the business of communication and they get it as well, if not better, than the rest of us.

Not only did the structs lesson in the C# Tutorial have code smells, but the writing wasn't too fresh either.  Got an email this morning that something in the lesson wasn't quite right, so I took a look.  The result is that I felt a compelling need to rewrite 99% of the lesson. This version incorporates earlier feedback from other people, such as a little more explanation of the differences between class and struct and example code that was closer to best practice.  I think the code is at least not bad practice anymore, but any small example will be limited in accomplishing anything other than the specific goal it is written to achieve.  Anyway, here's the link and I hope people find it useful:

The C# Tutorial @ C# Station - Lesson 12: Structs

A lot of developers jump straight into a project and begin coding.  The boss gives a vague “do this” instruction and the programmer starts writing code, which is fun.  Maybe it continues to be fun until the boss starts bugging for the application to be done.  If they haven’t done so in the beginning, they’ll ask for an estimate of when it will be done.  Of course, they get a vague or incorrect answer back because “do this” is very vague itself.  If the developer is inexperienced and/or is using a new technology, in addition to “do this” requirements, who knows what the end result of the project will be.  Making matters even worse, the boss’ perspective of “do this” is totally different from the developer’s view of “do this”.  A lot of times, the end result will be a failed project, or one survived through heroics.

The result on the companies that write software this way is an incredible waste of money, late deliveries, and lost revenue.  A lot of companies get started with software projects, having no idea what the true cost is.  Many people have used productivity tools like MS-Access, Excel, or some other RAD tool and have been given the false impression that they can build enterprise applications with a few drag-and-drop operations and maybe some VB glue code here and there.  In reality, these applications have no optimizations, proper data definitions, constraints, validations, error checking, or any other QoS considerations.  So, their perception of what a true enterprise application costs is skewed by their own inexperience.  They regard formal requirements/scenarios, architecture, design, test, stabilization, and deployment as non-essential overhead or trivialities they have no time for.  Furthermore, they want to save money any way they can, and they’re often unaware of the consequences.

Solving this problem is a matter of fixing two sides of the equation, which includes both the company and the programmer.  Just like the company relies on proper planning and execution for its core business, it must regard software engineering as an important enabler to the success of their business and invest in a process that facilitates proper development. There are many processes out there, but any business person who has an ounce of education should understand organization, planning, execution, and coordination management functions.  Regardless of what pundits and zealots preach, these management functions translate directly into many software processes.  Rather than just jumping in head first and coding, a developer should have a methodology in mind that they subscribe to for their software development process.  Essentially, all of the processes boil down to some form of requirements, design, coding, testing, and deployment.  Both the developer and boss need to communicate on the process they will use and then make it work, which will go a long way to avoiding the problems described in the first two paragraphs.

Split screen in Visual Studio can be used for various reasons, but it really excels when writing tests.  To split a screen, right click on the Tab in the editor, and select New Horizontal Tab Group.  You can tab vertical too.  To undo the split, right-click on the bottom (or right) tab and select Move to Previous Tab Group. 

The following figure shows a test in the top pane and the method being tested in the bottom pane:

I’ve been doing a lot of manual parsing on Twitter dates with LINQ to Twitter and it kind of bugged me how primitive the implementation was.  Messing around today, I put this together:

var twitterDate = DateTime.ParseExact("Thu Jan 24 22:14:29 -0700 2008", "ddd MMM dd HH:mm:ss %zzzz yyyy", null);

One statement; That’s more like it.