Meta

Month: July 2012

(Preface: This post is my opinion only. It represents some thoughts Iâ€™ve had rolling around in my head for a while. To free up some space in my brain, Iâ€™m draining this thought pool now. Iâ€™m in no way trying to tell anyone whatâ€™s â€œrightâ€ or â€œwrongâ€â€”those are decisions based on your own set of circumstances. I could be totally wrong here. Wouldnâ€™t be the first time, wonâ€™t be the last time. Feel free to leave polite comments.)

Since last October Iâ€™ve been giving a talk on using jQuery in a Metro JavaScript application. Itâ€™s been well attended and well received, and it gave me a good opportunity to work with Win 8 through its various releases. After we first finished the sample, I sat there and thought â€œthatâ€™s cool, but who would do this?â€ Let me explain.

Itâ€™s not that I think Metro is going to flop. I donâ€™tâ€”I think consumers, especially those with a Win 8 tablet, will go nuts for Metro apps. Enterprises overall will be slower to adopt Metro, but you can bet weâ€™ll see the best of the best as we approach RTM and GA. I just think most of the Metro apps will be written in XAML, not JavaScript. Microsoft did a fine job with the capabilities of WinJS libraries (especially feature parity between XAML and JS), and when combined with the tooling, Metro JS app development is relatively painless. I proffer two reasons why I feel adding a JavaScript option isnâ€™t as important as it first seemed.

First, there are far fewer web devs in the world than people think. Most of us who call ourselves web devs actually are writing native applications, the UI of which is merely a final output which is displayed in a browser. Most of us have a heavy reliance on a server side framework, be it ASP.NET, Ruby, PHP, Java or whatever. In Metro apps, there is no server framework available to us. I consider â€œpureâ€ web development to be based on client side Ajax calls and DOM manipulation, coupled with SOA, which is the architecture of a Metro JavaScript app. Ironically, some of the â€œpurestâ€ â€œweb developmentâ€ you would ever do is writing a native Windows (Metro) app.

Secondly, Iâ€™m of the opinion that web devs donâ€™t write native apps not because they canâ€™t, but because it offends the sensibilities that their app wonâ€™t (at least in theory) run everywhere. Itâ€™s not enough that an app will work on all Windows machinesâ€”there are Macs, Linux, tablets and (with a little extra work) smartphones out there. One codebase to rule them all! Remember, web devs obsess over a 1 pixel difference in how FireFox and IE render inputs. To us, the browser is the OS, and is the device. We care not whether Chrome is running on Mac, Windows or Linux (as Chromium). In fact thatâ€™s what we find appealing. While an attractive option at first, I think the realization that these are OS-specific apps will slow the adoption of Metro JavaScript.

None of this is not to say that there wonâ€™t be some great JavaScript apps produced for Windows 8. There will be. Iâ€™m just of the opinion that over time the numbers will favor XAML apps.

Two â€œlives’â€ ago, I led the team of enterprise developers. We did everything from the data warehouse/BI to LOB apps to systems integration. It was good times, we kept busy. It is an amazing company, small with people but with big revenues and big needs. As our trading partners and services grew, we needed to significantly upgrade our EDI capabilities, including AS2. After several months of evaluating solutions, we settled on BizTalk, because it was very flexible with EDI mapping, could multicast documents (which we needed to do), and would handle other types of messaging as well (we had a requirement for XML between several systems). We settled on BizTalk 2009, which as it turned out had its share of issues and limitations we found out later.

One of the limitations of BizTalkâ€™s AS2 connector is that it had to run on the same machine as BizTalk (I donâ€™t know if this has changed or not). This meant either having a second license of BizTalk just for AS2 (cost prohibitive), putting a production server in the DMZ (stupid) or poking a hole into our internal network (over the network adminâ€™s dead body). Time to find a new, simple, cost-effective solution.

This time the decision was significantly easier. We looked at a number of options, from hosted solutions to AS2 apps, but /n softwareâ€™sAS2 Connector was exactly what we needed (they moved the current version of the connector to their RSS Bus product line, so donâ€™t panic since the company brands donâ€™t match). Just to clarify, /n softwareâ€™s EDI integrator is a component for building your own AS2 solutions. The AS2 Connector is a pre-built application with most or all of the functionality you needâ€”this is what fit the bill for us.

In a nutshell, hereâ€™s what we did:

1. Installed the AS2 Connector on a web server in our DMZ. Since we had several web servers already, and AS2 is pretty low bandwidth, nothing additional was required here besides the SSL certificate. Setup and config was insanely easy on our IIS box.

2. The version we used dropped all the AS2 files into one folder. To make it easy for BizTalkâ€™s processing rules, we needed to sort them by trading partner. The connector did have the ability to call a batch file after a receive was complete. We wrote a PowerShell script (called by a BAT file) to read the ISA line, and move the files to a folder named for the trading partner ID. We also had T and P folders, based on the test indicator. This was back in 2009â€”I think the current version does this now without needing a â€œsorting hatâ€ script.

3. On that same web server, we had a TFTP server set up. We secured it to only accept connections from a particular IP (corresponding to our BizTalk server), and had a specific firewall route exclusive for the BizTalk server into the DMZ.

4. We scheduled BizTalk to check the folders every few minutes. One of the downsides to this approach is that you lose BizTalkâ€™s file system watcher capabilities. BizTalk picked up the files via FTP and processed them per the rules we had configured.

What we ended up with was a very flexible system that was easy to expand as we brought on new trading partners, and we could meet all kinds of crazy new requirements. We actually started to become the go-to integration partner because of how fast we could adapt to changes and the processing we could do on the received information.

Of huge importance for a couple of our trading partners we brought on later was having a Drummond Certified solution. Fortunately, the AS2 Connector was (and still is) Drummond certified.

Something to remember that AS2 is not EDIâ€”AS2 is just a way of transferring files. You can send nearly any file type via AS2.

Suffice to say, this isnâ€™t a blog post I thought Iâ€™d be writing at this time. As of July 2, 2012, I am no longer a ComponentOne employee.

I truly enjoyed working there. I gave my heart and soul to the company, and no one could miss my enthusiasm for my coworkers or our products. I have many good friends at ComponentOne, and Iâ€™ll miss seeing them and working alongside them daily.

My time at C1 was amazing. I learned so much, and I met so many wonderful people I would not have met otherwise. Obviously I wonâ€™t be traveling nearly as much as before, but I still want to get to one or two good events each year. Iâ€™m leaving behind a good legacyâ€”Iâ€™m the #1 blogger at the company, Iâ€™ve delivered dozens of talks at dozens of events across the country, and thereâ€™s no doubt my efforts are a huge reason why ComponentOne is back in the consciousness of the community.

Iâ€™ll miss my friendsâ€”both in C1 and the community, but the timing was good for me. Two years ago when I was hired, I said this would be a two year role for me, and if my future beyond that was at C1, then great, otherwise, it was a good run but no hard feelings. Itâ€™s a statement Iâ€™ve repeated several times since then. The grind of travel and writing talks was wearing me down, and I was really feeling it this year. I was missing my family more and more with each trip. Although the reason and timing werenâ€™t exactly of my choosing, itâ€™s not far off from when I would be making the same call.

Itâ€™s been a crazy couple of weeks since CodeStock. I was accepted into ASP Insiders, and Pluralsight commissioned me to develop courses. The next few weeks Iâ€™ll be working on some back-burner projects, which is very exciting. Itâ€™s time to reinvigorate this blog. And, Iâ€™m looking forward to my exciting _________ career.

If I was in the middle of doing something with you, youâ€™ll need to get in touch with Kevin Griffin (keving@componentone.com) to pick up where we left off.

Itâ€™s been an awesome run, I look forward to the next time we meet. Whenever that is, remember Russ or Kevin is buying now.