Twitter takes control with new API rules, plans to limit access for third-party clients

We all knew this day was coming after reading Twitter’s fairly recent blog post on the company’s future plans, but now it’s been made official, and traditional Twitter clients should watch their backs. In another blog post earlier this week, Twitter’s Vice President of Product Michael Sippey outlined exactly how the company plans to control the user experience of its product.

For starters, large Twitter clients using Twitter’s API will have to obtain direct approval from Twitter in order to function. If a developer plans to create an app that requires access to a user’s timeline, direct messages, etc. (which are most traditional Twitter clients), they must seek Twitter’s permission if they plan to cultivate a user base over 100,000. The social media giant isn’t completely unreasonable, however, and won’t limit those applications already sporting over 100,000 users until their user base grows by 200 percent.

Twitter's chart of desirable and undesirable apps

As you may have guessed, “traditional Twitter clients” like Echofon and Tweetbot (both named specifically by Sippey in the article) are in the most danger. Sippey went into a lot of detail regarding the types of applications Twitter approves of and those it would rather not cater to, even creating the graphic above to illustrate his point.

Basically, the apps that fall in the upper right corner are being discouraged, while Sippey would like to see the number of applications grow in the remaining quadrants. Sippey used Klout as an example of a successful application geared towards the consumer and social analytics, an area that Twitter approves of.

Sippey said the changes would take effect “in the coming weeks” and regardless of their effect on existing Twitter applications, developers will be glad to finally hear some specifics after the somewhat foreboding letter to developers that was published a couple months ago.

The first indication of Twitter’s new cut-throat nature came with its decision to drop out of a partnership with LinkedIn. Then, of course, it followed that up with the announcement of high-profile partners like The Wall Street Journal and TIME for its new Twitter Cards.

Twitter has made it crystal clear it’s ready to take business a lot more seriously, and it’s up to developers to keep up to Twitter’s increasingly complex and challenging demands.

SharePoint 2010: Mysterious Errors Using Query String Parameters

SharePoint 2010
I am SharePoint... Feel my wrath!

One of the things I love about my job is that satisfying feeling of accomplishment that I get when I solve one of SharePoint’s quirky difficulties. If it weren’t for this feeling of euphoria that comes along every so often, I’d have gone insane long ago. Thankfully, SharePoint has no shortage of strange behavior and head-scratching moments.

One of my colleagues recently ran into a strange error while developing a custom Application Page. No matter how he was catching and handling runtime errors, every time an exception was raised during the Page Load event, the page would crash, displaying a perplexing error message and stack trace.

Specifically, he’d receive a “No item exists at . It may have been deleted or renamed by another user” error. What item? The one that the page isn’t using at all? Obviously. The corresponding stack trace wasn’t too helpful either. When stepping through the debugger, it was clear that the Page Load event was executing successfully, but the page was still crashing, even when the entire method was wrapped in a try/catch block with proper exception handling.

At this point, I thought of something. The page was utilizing query string parameters to receive data and pass data to itself across postbacks, so perhaps something was wrong with one of the parameters? I noticed one of the parameters he was using was named “ID”. I suggested we change the name of this parameter to something else, and lo and behold, the problem was solved.

The Moral of The Story

For reasons I still don’t quite understand, although it does sort of make sense, the “ID” query string parameter is a reserved keyword in SharePoint. Any time this parameter is present, SharePoint tries to do something internally, which sometimes makes it take a crap. Oddly enough, the problem only happens when an exception is raised during code execution, regardless of error handling. The moral of this story is to NEVER use a query string parameter named “ID” while developing for SharePoint.

There are several other query string parameters one should not use as well, and most (but not all) of them are far more obvious than the ambiguously-named “ID” parameter:

  • FeatureId
  • ListTemplate
  • List
  • ID
  • VersionNo
  • ContentTypeId
  • RootFolder
  • View
  • FolderCTID
  • Mode
  • Type
  • PageVersion
  • IsDlg
  • Title
  • _V3List_

(Thanks to Stefan Goßner over at TechNet Blogs for this list.)

How to Create a HTML-style ComboBox in WPF and C#

Before I started doing software development in C# and WPF, I spent quite a bit of time with HTML. Because of this, I was used to having the ability to create drop-down boxes (known as select in HTML) to display lists of information with a “front-end” value the user could see and a “back-end” value that held data.

For example, I could create a list of colors that would display the color’s name in the select box, but would then correspond to a hexadecimal value in the background:

Which looks like:

If the user selected “Green”, it would show up as “#008000” behind the scenes.

This type of control is known as a ComboBox in WPF and C# and has similar functionality, but by default you can’t store Name –> Value pairs in them like you can in HTML. In this guide, I’ll show you some simple code you can use to recreate this functionality.

Creating HTML-style ComboBox in WPF and C#

For this example, I wanted to create a drop-down menu for selecting the Parity value of a serial port connection. Parity is an enumeration in C# and has values like Parity.None, Parity.Even, and Parity.Odd, but I wanted to display just “None”, “Even”, and “Odd” to the user.

The first thing I did was to create a custom class that expands the functionality of the standard ComboBoxItem. This class will store the pretty front-facing name in a string called “contents” and store the data value in an object called “tag”.

If you’re familiar with ComboBoxItems, you’ll know that they already offer Content and Tag properties. These properties don’t function the same way they do in HTML, so I found it best to create my own custom class.

// Contains the visible "Name" of the item.
private string _contents;
public string contents { get { return _contents; } set { _contents = value; } }

// Contains the hidden "Value" of the item.
private object _tag;
public object tag { get { return _tag; } set { _tag = value; } }

public CustomComboBoxItem(string contents, object tag)
 this._contents = contents;
 this._tag = tag;

// Only the Name will be displayed when the string value is used
public override string ToString() { return _contents; }

I created my ComboBox in WPF and created a Loaded event to programmatically populate the values.

And then created the corresponding comboBox_Parity_Loaded function in my C#  file where I added the CustomComboBoxItem items to the ComboBox. You can see that the first value I give it is its front-facing name, and the second is the value of the Parity enumeration.

private void comboBox_Parity_Loaded(object sender, RoutedEventArgs e)
 // Add the options with my custom class CustomComboBoxItem. This allows me to store a unique "Name"=content and "Value"=tag for each item
 comboBox_Parity.Items.Add(new CustomComboBoxItem("None", "Parity.None"));
 comboBox_Parity.Items.Add(new CustomComboBoxItem("Even", "Parity.Even"));
 comboBox_Parity.Items.Add(new CustomComboBoxItem("Odd", "Parity.Odd"));
 comboBox_Parity.Items.Add(new CustomComboBoxItem("Mark", "Parity.Mark"));
 comboBox_Parity.Items.Add(new CustomComboBoxItem("Space", "Parity.Space"));

Compiling and executing this program shows my ComboBox filled with items called “None”, “Even”, and “Odd”, but its selected value now corresponds with “Parity.None”, “Parity.Even”, and “Parity.Odd”.

To access the back-end value of the user’s selection in your code (I was using it to change a hardware setting), you need to cast the SelectedItem property of the ComboBox as a CustomComboBoxItem.

// This takes whatever item is selected in the comboBox and stores it in a new item called item_Parity. This gives you access
 // to the properties of the CustomComboBoxItem like .tag and .content.

CustomComboBoxItem item_Parity = (CustomComboBoxItem)this.comboBox_Parity.SelectedItem;

To test it out, you can use the following code to write the item’s name and corresponding value to the console.

Console.WriteLine("Item's name is: " + item_Parity.contents + " and Item's value is: " + item_Parity.tag.ToString());

That’s it! You should now have HTML-style ComboBoxes in WPF and C#.

Dealing with Workflow Failed On Start (retrying) errors in Microsoft SharePoint

I don’t know why I expect SharePoint to work without problems. In almost every project I’ve done, some unforeseeable problem pops up that seems to make little sense. Maybe, after beating my head against the wall so many times, I’ve developed SharePoint amnesia, but I always expect the project to be a pleasant experience. I guess that’s just my inner masochist rearing its ugly head.

Recently, I had a working Visual Studio workflow for SharePoint 2007 which was designed to set access permissions at the list item level based on the metadata assigned to the document. When a document is added or updated in the library, the workflow will update the permissions associated with the document. Simple stuff.

Then we had a new requirement. Since permissions are assigned base on metadata values assigned to documents, what happens when the SharePoint groups and/or users associated with a value needs to change? With the current workflow, it would be necessary to manually run the workflow for each and every document. In a small document library, this would not be a problem. But when you’re dealing with a document library containing several thousand documents, this would be a life sentence.

In order to accommodate the new requirement, I had to modify the workflow to be able to loop through all of the documents in the library and re-apply permissions. Making the change was easy enough; the code that sets the permissions on one document simply had to be wrapped in a foreach loop of all documents in the library. Problem solved, right?

Failed On Start (retrying)
It's lying!

I deployed the workflow to the test environment and started it. It ran for several minutes with no apparent problems. The workflow history list was logging all of the tracking messages for each document, and permissions were being set as expected. Then all of a sudden, the workflow status switched to “Failed on Start (retrying).” Workflow history logs stopped appearing, and the workflow was certainly not “retrying”.

After several Google searches came up largely empty, I began making changes to the code to see if I could get a different result. Nothing was working. No matter what I changed, the workflow would run for several minutes and fail again. Then I decided to add more workflow history logging to pinpoint a particular line of code that may be causing the error.

With the new workflow history logs added into the code, I redeployed and ran the workflow again. This time I noticed the workflow was much quicker to fail. It seemed that the workflow history list had something to do with the problem. To test my hypothesis, I commented out the workflow history logs and tried again. Sure enough, the workflow ran to completion, without any problems. After I verified on a random selection of documents that permissions had been set correctly, I did my happy dance. Problem solved.

So what happened?

My best explanation of what the problem could have been is that the workflow was logging too many workflow task items, which eventually caused the workflow to crash. Since the workflow was originally written to run on a single document, it was adding 5-10 workflow history logs per document, depending on the values of the metadata tied to the document. Multiply this by 5000, and you get 25,000 to 50,000 new list items per workflow instance.

It is generally recommended to keep list sizes below a few thousand list items in SharePoint 2007, so the plethora of workflow history items was essentially crushing the workflow under its own weight.

CampfireThe moral of this story is this: Logging is great for debugging and ensuring proper operation of your workflows, but don’t go overboard. It’s like they always say: “Too many logs in the fire means no more roasted marshmallows.” Or something like that.



SharePoint Solution Deployment Horror

A couple of weeks ago, I had the worst professional SharePoint moment of my life, thanks to SharePoint 2007, Visual Studio 2008, and WSPBuilder. Deploying custom solutions to SharePoint is something I have done many times, but I’ve learned to expect nothing but the worst, especially when the task at hand seems like it should be easy. In the end, I had wasted far too much time performing a seemingly mundane task. My goal is to relay this experience and how I overcame it, in the hopes of saving several hours of your life.

Using Visual Studio 2008 and WSPBuilder, I had created a custom Workflow solution to deploy to a SharePoint 2007 site. The workflow was a fairly simple one, simply copying a document from a drop-off library to a document library on a different site collection, along with its associated metadata. Using a stand-alone installation of SharePoint 2007 on a virtual machine, I created a model of the production site, based on my understanding of the architecture. Then I proceeded to write a workflow to fit this design.

After writing the code and creating the .wsp, the initial deployment to production went without a hitch. However, after some quick testing, it was clear a couple minor tweaks needed to be made to the workflow; my development site did not quite match the production environment. In retrospect, I would say this is where things began to go wrong. But at the time, this seemed like no big deal. It should be easy to tweak the workflow code and redeploy it. Right?

Unfortunately, I’ve never been so wrong. After making the code changes, I created a new .wsp, retracted and removed the old solution from SharePoint, and deployed the new solution. I tested the workflow again, and, to my bewilderment, it still did not work correctly. In fact, it didn’t seem to be behaving any differently than the first time.

I went back over my code to see if I made any silly mistakes. Everything looked good as far as I could tell, and unfortunately in this situation, I could not debug my solution on the production server. My only option was to change the code and redeploy. After making minor code changes and redeploying several times, nothing I did seemed to make a difference. The workflow seemed to run exactly the same each and every time, returning what seemed like the same error in the same place.

So I began to think about it a little differently. It almost seemed to be using the original DLL in the GAC (Global Assembly Cache), even though I obviously had retracted the old one and deployed a new one. The GAC is a cache, after all. Just to be sure, I navigated to the GAC in Windows Explorer at C:\Windows\assembly, and sure enough, the DLL was not listed in there after retracting the solution. And when I deploy the new solution, the DLL would show up. It seemed to be working exactly as I would expect.

Global Assembly Cache
Windows Explorer view of the GAC

One thing I did notice was that the assembly version was still Perhaps since I left the assembly version the same in Visual Studio, the GAC wasn’t taking the new DLL at all? To change the DLL version, I had to change it in 3 spots in Visual Studio: in the project properties pages, in the elements.xml file, and in the feature.xml file. After making this change, I packaged up the .wsp again, and deployed it, confident my nightmare was nearing its end.

This time, SharePoint did not seem to recognize my new feature at all, as I could not find it in the site collection features list to activate it, or see the workflow in the list of available workflows to add to a list. After Googling my issue, I decided that I may benefit from using STSADM exclusively for adding, deploying, and installing solutions and features. Previously, I had been simply adding it with STSADM, and then using Central Admin to deploy the solution and activate it. This approach, in my experience, has appeared to work flawlessly with SharePoint 2010, but apparently this is not the case for SharePoint 2007.

It turned out that while I had updated the solution to a new version, the feature was still looking for the old version. This is where extensive use of stsadm came in to play. Using the command prompt, I issued these commands, in order:

  • stsadm –o deactivatefeature –name –url <URL of SharePoint web application>
  • stsadm –o uninstallfeature –name <name of feature folder> –force
  • stsadm –o retractsolution –name <name of solution .wsp file> –immediate –allcontenturls
  • stsadm –o deletesolution –name <name of solution .wsp file>
  • stsadm –o addsolution –filename <file path to .wsp file>
  • stsadm –o deploysolution –name <name of solution .wsp file> –immediate –allowgacdeployment –url <URL of SharePoint web application>
  • stsadm –o installfeature –name <name of feature folder> -force
  • stsadm –o activatefeature –name <name of feature folder> –url <URL of SharePoint web application> -force

Using stsadm –o updatesolution probably would have worked as well, but that is not the route I ended up taking. Finally, I tested the workflow one last time, and it worked like a charm. After wasting many hours of my life on something that seemed so simple, I was relieved to have this nightmare behind me. Hopefully this will help prevent you from experiencing the same problem.

As I mentioned before, I probably could have saved a lot of headache if I had a better understanding of the production site’s architecture before I began development. It is important to ask the right questions in order to get the answers you need. The person you are getting the information from won’t always know all of the important details, so it is up to you, as the architect and developer, to get the information you need to get the job done.

If you want to learn more about WSPBuilder or STSADM, please check back here soon. I plan on covering both of these useful tools in the near future.

Image Courtesy: Brian Pennington

Want to Create a Web Application? Use CakePHP for Rapid, Secure Development

So you’ve got a sweet idea for a web application—great, let’s get to work! You’ll need a basic GUI, some sort of user registration, a templating system, logic processing, error handlers, form verification, AJAX processing, and… woah, this is adding up in a hurry. At what point do you get to start making the app itself?

What you need is a framework that will accelerate your app development by offering an easy way to employ common components to a site and the flexibility to quickly add custom logic.  This is where CakePHP enters the stage.

CakePHP is a PHP framework that simplifies the way you do programming. What do I mean by “framework”? This concept is best explained by making a comparison with traditional application scripts: a typical PHP script starts at the top and proceeds to the bottom while utilizing included classes to create objects and processes the intended logic. An error in your syntax ruins everything, and you need to manually code database connections and other activities not native to the language.

However, in a framework, you simply extend existing (and rigorously tested) libraries. For instance, CakePHP has the ability to “scaffold” a database table, where you simply provide a line code describing the table, and poof—the framework will display a basic interface for inserting, updating, and deleting records. No, really, it’s that easy… and that just skims the surface of CakePHP features.

So, the question really boils down to this: Why should you waste your time learning to use CakePHP? I’ll give you three solid reasons.

Faster development

You may or may not have any appreciation for online dating sites, but I think we can all agree that it would be a complex project if we had to build one from scratch. Ever heard of Mingle2? Yeah, me neither, but it’s a dating site that boasts 100,000+ users and was made with CakePHP in 66 hours. 66 hours. Let’s put this in perspective—this man started and finished production of a large scale social network in less time than it took me to beat Final Fantasy 7 the first time through. Impressive? You decide.

CakePHP shaves a lot of time off your typical coding assignments by letting you create a few lines of code that utilize the backbone libraries built into the framework. Do you need your application to send email? No problem. Do you want to verify a form to make sure the user is entering a credit card number? CakePHP has you covered. Need to interact easily with a mySQL database (or others)? Easy shmeasy.

On a lesser note, the package is a piece of cake to install. (See what I did there?)

Structure, security, and scalability

These are all pretty broad topics, but I’ll keep the description concise—CakePHP’s Model-View-Controller system (MVC for short) changes the way you program by establishing conventions that will simplify the creation of your app. In essence, the Model dictates how your app will interact with the database and the Controller will process this information in a way you dictate, finally delivering it to the View for display to the user. Consequent to this structure, the application has better access to data objects, files are shorter and better organized, and since we rely on CakePHP convention and library files, the app tends to be properly positioned for scalability.

For a much more detailed look at the way CakePHP processes an app, glance below on the left.  Next to that is how most app processing paradigms look. Sad, right? I know, I’m embarrassed, too.

Let’s not forget that security in app development is often sorely neglected. Fortunately, CakePHP protects forgetful programmers by offering protection from database injections and AJAX vulnerabilities. Did I mention the built-in regular expressions? If you’re like me, those will save your butt more than once.

It’s PHP

This may seem like a minor point, but think about it—PHP is supported on nearly every hosted server on Earth (20 million domains utilized PHP in 2007). PHP is also a freely distributed packaged that integrates perfectly with free server software such as Apache. Can you think of a better environment for developing an application with a limited budget? Don’t say McDonald’s Playland. Don’t you dare say it.

CakePHP also allows you to inexpensively and easily switch your current PHP practice to a rapid deployment framework. Not many things are more depressing (or expensive) than telling your team of PHP developers that they need to abandon their expertise to shift focus to a different language. With CakePHP, it probably won’t be necessary.


CakePHP will improve your app development experience in a lot of ways, but guess what—it isn’t the only PHP framework in town. Other frameworks such as Zend and Symphony have had great success and, like CakePHP, are robust options with large support communities. You may consider adopting Symphony if you prefer XML for designing databases, and you may hold a preference for Zend (which is more like a collection of libraries than a true framework) if you require tight integration with other platforms such as Facebook or Google APIs. Of course, there are even more than just these options from which you can choose.

Hopefully this brief summary of CakePHP was enough to convince you of the benefits of developing within a framework. Sure, ground-up development has its uses, but when developing a large, scalable app why reinvent the wheel? Hasten the process with a framework while improving organization and security. To whet your appetite with more details concerning CakePHP, visit their forums and have a look at their online book to better weigh your options.

Click here to see some sites developed in CakePHP., Mozilla Firefox Add-ons, and Yale Daily News are among them!

Join the growing community of CakePHP developers and see what all the fuss is about. Sorry, I mean, “see about what all the fuss is”. That doesn’t seem right, but you get the picture. Happy programming!

Image credit: Nathan Eal Photography, Paul Downey

Google Re-Invents Android Development with App Inventor

The Android Marketplace may be getting a little bit more crowded soon.  This week, Google Labs revealed to the world App Inventor, a creative programming tool that allows just about anyone to figure out how to design and create Android applications… and there was much rejoicing.

Thanks to the open architecture of the Android OS, App Inventor allows for tweaking of everything and anything that is contained in the operating system, like a giant Android application sandbox.

The interface itself looks like something out of Visual Basic and uses a web browser and the Java Web Start kit to allow one to create and explore the Android environment.  According the the official website, the tool allows for the user to create packaged applications that can store data, create quizzes, provide access to the phone’s GPS and phone messaging features, and access websites to collect data.

Similar to Visual Basic, the program is a block based development tool allowing for things like timers, buttons, and the like to build an official Android application.  The App Inventor website, along with describing how to install the tool on one’s personal computer, has some free tutorials that show step-by-step how to create some basic applications ranging from drawing pictures on a cat (or any picture for that matter), to allowing teachers to create quizzes for students to complete.

While an application is being designed, it can be previewed by first turning on “USB Debugging” and “Stay Awake” (through Settings -> Applications -> Development) on the Android phone and then connecting it to one’s personal computer via USB.  At this point in time, this developmental tool is being presented as is; there is no way to start in App Inventor and export the Java source code for further tweaking.  From start to finish, this tool creates applications.  Furthermore, this software is currently in closed beta but anyone can attempt to sign up via their Gmail account here.

This is BIG news for the mobile community, and even though the tool is just two days old it is already being hyped, downplayed, argued, debated, and praised by every major technology and news publication (I’m surprised Women’s Day Magazine hasn’t covered it yet).  For now, the majority approve of this “every-man’s” developmental medium, but it will take some time to see the true results of this great leap forward.

Android was not built in a day, but very soon its applications will be.  Here’s to progress.