Dynamically Updating Environment Variables in Postman

If you haven’t used Postman yet for your general development needs while building or consuming a REST (or SOAP!) API, go get this amazing tool NOW and then keep reading. Otherwise, here’s a quick tip to make to help when dealing with frequently changing environment variables, such as session IDs or JWT tokens.

Continue reading “Dynamically Updating Environment Variables in Postman”

Matrix Code Tunnel

API Insights – ORMs, ViewModels, SummaryViews, and Transforms

I’ve been working through another project lately that is being build using a WebAPI model with an AngularJS front end. It’s becoming a very popular way of building things out. It’s quite helpful, but it does lend itself a little bit to some complexities not always found in a traditional MVC model, especially when it comes to the structure and size of the data being returned in the payload. Here is one way I work around those issues. Continue reading “API Insights – ORMs, ViewModels, SummaryViews, and Transforms”


Soup to Nuts – Dynamically Submitting Sitefinity Forms Using AJAX

Sitefinity has a nice forms module baked right into the system. Within a few steps you can easily setup your basic questions, add it to a page, and track the results. You can even get e-mail notifications when a new form item is submitted, should you choose. However, the one downside to the forms module is that out of the box, a from is submitted through your typical .Net PostBack method, and there is no setting to make the form submit via AJAX. Sitefinity boasts about how web service friendly the platform is and that how a lot of modules in the system are already “WCF enabled”. By digging into these, we make our forms submit over a standard REST web service call.

Continue reading “Soup to Nuts – Dynamically Submitting Sitefinity Forms Using AJAX”


Soup to Nuts: Exporting a GridView to Excel

Excel spreadsheets are a subtle form of currency in LOB and other environments. If you can get some data off the screen and into a spreadsheet to an Excel guru, they will love you for life and can do some amazing things with the data. In the ASP.Net WebForms world, GridViews still run rampant. They are easy to configure, easy to extend to include update/edit/delete controls, and provide a nice way to interact with data in a common interface.

Making these two items work together has been a little daunting in the past. Interfacing with the GridView wasn’t the issue, it was generating an Excel document. You could easily generate a CSV file with the data needed, but that doesn’t allow you to generate a header and potentially format some key cells in the spreadsheet. There are the Interop libraries, but these are older COM wrappers and are generally frowned upon with .Net apps. Visual Studio Tools for Office (VSTO) is a robust library for working with all of the Office document types, but it also requires Office on the system to generate the objects fully.

I recently stumbled upon a new library, called NPOI, which makes this entire process quick and painless. The library isn’t terribly new. It is a port of Apache’s POI library, which is a Java library used create and read Office documents. The POI library has been around a while and is well written, so getting the .Net version of it puts you ahead, even for its 1.2.3 release.

The example package you can download has some great samples and its really simple to iterate through the row/column structure of the document you’re creating. Since the GridView is equally easy to interate through its row/column structure, I was able to tap into an existing web application and create a basic spreadsheet in about 20. The code is as simple as this:

DocInfo = PropertySetFactory.CreateDocumentSummaryInformation();
DocInfo.Company = "Dillie-O Digital";
Workbook.DocumentSummaryInformation = DocInfo;

SummaryInfo = PropertySetFactory.CreateSummaryInformation();
SummaryInfo.Subject = "Soup to Nuts GridView Export Example";
Workbook.SummaryInformation = SummaryInfo;

DataSheet = Workbook.CreateSheet("Employees");

for(int i = 0; i <= GridData.Rows.Count - 1; i++)
   CurrRow = DataSheet.CreateRow(i);

   for(int j = 0; j <= GridData.Rows[i].Cells.Count - 1; j++)
         CurrCell = CurrRow.CreateCell(i);

ResultStream = new FileStream(EndPath, FileMode.Create);

All of the dirty work is handled by the libraries in the API and you do not need Office installed on the machine generating the documents! It is really simple and effective, which is a HUGE credit to the library, and the authors porting it to help .Net developers. There is a lot more available in these libraries, which is worth looking into!

Similar to my other “Soup to Nuts” type articles, I’ve created a C# and a VB.Net project that contains everything you need to export a GridView to Excel for viewing. I’ve done a little header formatting in the example, as well as include an option to exclude columns from being exported (as in the case when you have a GridView with action links in one of the columns. I’ve also included a sample on how to export the GridView to a file and how to export the GridView to a file and prompt the user to download/open it. Many thanks to NPOI for making my life a lot easier, and hopefully this will help you to!

Visual Studio 2010 Solutions
S2NGridViewExcelCS (C#)
S2NGridViewExcelVB (VB)

Visual Studio 2008 Solutions
S2NGridViewExcelCS (C#)
S2NGridViewExcelVB (VB)

Note: You’ll need 7-Zip to extract these files:


Is the API the next killer app?

The ?killer app? is a term for those of a geekish lean that describes the ultimate application out there that you simply can?t live without. It is typically used identify a utility or program that provided countless opportunities to create new things, or tweak out your computer, or give you immense flexibility over content consumption. If was a mark of good standing if your application was tossed around in the question, ?Is this the killer app?? I dreamed I could write something remotely close to this.

By most references, VisiCalc was the first killer app since it open the doors to spreadsheets for the average user on a computer. Around the time I was getting into computers (the glorious age of DOS 5.2 of 14.4K baud modems), you could look to archive tools, such as PKZip, as the killer app that allowed people to move large sizes or numbers of files around with minimal hassle. Around this time I also found QModem to be my own killer app, since it allowed me to connect to my local BBS with plenty of custom scripting options [yep, I scripted out my own ZModem downloads before the protocol came standard 8^D].

As computers became more ?average Joe friendly? (no derogatory implications in any form), the killer app migrated out a bit more into the public sphere. Compuserve, then AOL. Became the killer app because users could send messages to friends, shop online, and check out special products from vendors. I?m sure there?s plenty of folks who remember when TV commercials had the tagline ?Check out AOL keyword X? at the end of them. Further still, browsers became the killer app, since you could use various plugins, or sites that were JavaScript heavy, to do things without downloading or installing anything. Even this trend seems to have passed by and the ?social portal? seems to be the next killer app. Facebook has held the lead on this one for a while now, but there are a good number of clones or similar type websites that will allow folks to share photos, discuss common interests, play games, and easily consume your free time.

But on the edge of the social portal I think lies the next, or potentially current, killer app, the API. For those not familiar with term, API is an acronym for Application Programming Interface. In simple terms, it is a programming library that the creator of a program has opened up to allow other programmers to interact with the core of the system, or the data within it. For example, in the process of updating the CCG Toolkit, I chose to create web services to be used as an API to view the Tournament Card Registry data. That way, anybody that knew how to consume a web service (or had a program that did so), could easily get at card data and rulings for their cards.

Firefox became immensely popular due to its plug-in interface, which was made possible by an API that allowed programmers to create nearly any kind of ?widget? that would load with Firefox and allow the end user to do more with their browser. The Flock browser took the best plug-ins it could find and integrated them natively into the browser to enhance the user?s browsing experience.

Twitter is probably the best example of leveraging the API to its advantage. By itself, Twitter is simply a protocol for displaying status updates and passing on other people?s statuses you find interesting. The interface was incredibly simplistic: a web page. You had to various searches if you wanted to check out what else was going on in the ?twitterverse.? That all changed with the release of the Twitter API. Now every programmer under the sun could create a desktop or web based application that did all the fancy searching/sorting/following that you wanted. You could create widgets on top of the Twitter API in order to display your recent status updates, or trending topics on your blog page.

The beauty of this is that Twitter developers themselves only had to focus on the infrastructure and the protocols to be used. They can then let the creativity of developers and the demand of the users dictate which applications bubble to the surface and are used. As a result there are huge amount of twitter clients out there on every platform imaginable. By doing this, usage of Twitter itself has increased without the actual developers of Twitter having to worry about aesthetics, UX, or even platforms specifics, something that has plagued desktop applications for a long time.

Facebook has an API. Various Google Apps (including Calendar and Maps) have APIs. MySpace has an API. My favorite programming site, StackOverflow, has recently released an API and is hosting a contest to see who can build the most awesomeness out of it. I could go on and on.

So while people are getting less and less tied down to a specific platform for their data and day to day interactions (I use a Windows 7 box at home, an iPod Touch while I?m out and about, and have an XP box at work), the killer app has to keep up with this. Since keeping up with the plethora of platforms out there is insane, the killer app has had to take itself one level deeper, to the core of the code itself, or the API. The new killer app is really an API on top of a framework that is going to generate users across any platform somebody is willing to write for, without troubling the original developer at all.

I guess the next question that arises, does the API need to come first for your product, or do you generate the product and use the API to seal the deal?