Tuesday, March 13, 2018

SSIS Package Template Location for Visual Studio 2017 Pro

If you've been looking around already, here's the short answer:

For the Pro version:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\ProjectItems\DataTransformationProject\DataTransformationItems

For the Community version:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\SSIS\ProjectItems\DataTransformationProject\DataTransformationItems

To learn more, read the existing articles that got me almost there... except for the VS 2017 Pro-specific part.

Friday, January 12, 2018

Isomorphic SmartClient with TypeScript

Short version: Check out the Isomorphic SmartClient TypeScript type defnition library on GitHub.

Longer version (how I get here):
I started out programming thick-client Windows applications for enterprises. The demand for that has significantly decreased over the last 10 years as web technologies have improved immensely. So now I'm an enterprise web application developer. But, coming from a thick-client background, I don't much care for slow, full page refresh applications. And, coming from an Object Oriented Programming background, I don't much care for JavaScript as it lets me make all kinds of mistakes which I do consistently. What to do?

With my first attempt at a single page application (SPA) in 2008-ish, I chose to use GWT and with it the Isomorphic SmartGWT library which contains a ton of widgets that all work together nicely. I learned a lot with that project including Java, GWT, the Isomorphic SmartClient/GWT library, the Net Beans IDE etc. and it worked. Maintaining that application, however, was difficult because I only worked on it once in a while and every time I came back to it, I spent hours updating my environment: Visual Studio, NetBeans, browsers, libraries, GWT etc. and usually at least one of those things would cause my application or development environment to break. So before I could even get to the fixes/enhancements I had planned for the day, I spent hours fixing bugs introduced (or exposed) by the environment updates and then of course testing those fixes.

While I really liked programming in Java compared to JavaScript, the GWT environment seemed unstable to me. It started off with browser plug-ins for debugging which were always behind the browser versions, much of the time it didn't even work with Google's own browser, Chrome, so I was using Firefox sometimes and Chrome other times. The compiler was really slow (with good reason) which slowed down my development cycle. Debugging in the IDE was great when it worked but then it changed to what they called 'Super Dev Mode' which was really just debugging in the browser with map files. I know that Google has many applications using GWT so I know it's a good system... just maybe not for a guy who programs mostly with Microsoft stuff and who's not using it everyday to keep everything up-to-date.

So, for my next attempt at a SPA, I decided to bite the bullet and use JavaScript so that I could still use the Isomorphic SmartClient library (the JavaScript version) and not worry about maintaining multiple IDEs, web servers, plug-ins etc. I could do everything with Visual Studio and IIS. Also, my client probably would not have accepted introducing Java into the house. This worked well also. All I had to do was maintain a bunch of JavaScript instead of Java and only one IDE. Debugging is done in the browser, just like with GWT, just no map files.

But then the application started to get more complicated and maintaining the JavaScript was troublesome. It's no fun to refactor JavaScript because you never know what you're going to break... until you test of course. Yes, there are ways of maintaining OOP-like JavaScript (that's what the SmartClient library does) but that was beyond my pain threshold. So, I looked for alternatives like TypeScript, CoffeeScript etc. that wouldn't require a new IDE. I settled on TypeScript because:
  1. It was created by Microsoft, fully supported in Visual Studio and I work in a Microsoft shop so I knew there wouldn't be any backlash.
  2. It's really gaining in popularity (a la Angular).
  3. There are already a bunch of type definition libraries available for JavsScript libraries like JQuery which makes it really easy to use existing JavaScript libraries.
Unfortunately, there was no type definition library for SmartClient, by far the largest JavaScript library I was using and the face of my application.... bummer. I proceeded anyway figuring I could convert everything except the SmartClient stuff to TypeScript. Since JavaScript is TypeScript, the SmartClient JavaScript still works, it's just not typed and thus still prone to JavaScript errors (of which I had many). I had actually considered TypeScript at the beginning of the project but decided not to go that route because there were no type definitions for SmartClient, figuring someone would build one and then I would switch over. Well, that never happened.

Fortunately I had recently gained a lot of experience with code generation and Isomorphic published an XML file for their documentation that had all the information necessary to build TypeScript typedef libary. I just had to build a code generator to read the file and build the library. It took a while and required some help from Isomorphic to fix up the XML file but it worked. You can find the library on my GitHub page at https://github.com/kylemwhite/isc. The library has been working well for me and my client such that we now have a good sized single page application written in C# on the back-end and TypeScript on the client. It has proven to be much easier to maintain and more robust than the JavaScript version.

Now that TypeScript is becoming more mainstream, Isomorphic has announced that they will begin supporting TypeScript in their next version (http://blog.isomorphic.com/5-more-release-12-0-features/) which is of course what I was hoping for all along. Everybody wins!

What is an Enterprise Application?

When I tell people who are not in the I.T. industry that I develop enterprise applications, I am typically facing a gentle nod and a blank stare. Sometimes I get the same reaction from people who ARE in the I.T. world. I think Enterprise Application is one of those terms that people think they should know... but don't.

So, I thought I'd share what I mean by Enterprise Application. Of course, it will differ than other people's definitions because we all work in different places with different technologies etc.

According to Wikipedia:
Enterprise software, also known as enterprise application software (EAS), is computer software used to satisfy the needs of an organization rather than individual users. Such organizations would include businesses, schools, interest-based user groups, clubs, charities, or governments.[1] Enterprise software is an integral part of a (computer-based) information system.
Ok, but what does that really mean? Let's start with the word "enterprise". No, it's not the starship on a 5 year mission. An enterprise is a large organization... like a big company or government agency. We (almost) all know what an application is. It's the term we used before it got shortened to 'app' (also known as a program or software). So, an enterprise application is an app for a company or government agency (or department, office, bureau, ministry etc.) or some other type of large organization.

How is that different from any other kind of application? It is unique in at least two ways:
  1. It is not meant for general public use. It belongs to the organization to help them do their business, whatever that is, and is specific to that organization - either because it was specifically developed for the organization or it is an off-the-shelf product that has been configured for the organization.
  2. It is typically used to get data into and out of a database. So, it is not usually for creating images (like Photoshop) nor connecting drivers to people who need a ride (Uber, Lyft) nor is it used for creating complicated documents (Word, PowerPoint, Excel, although reports are typically involved). 
Large organizations typically need to keep track of all kinds of data, usually with databases. Sometimes it is very general stuff that many organizations use; such as contracts, invoices, bills, checks, employee records etc. For these applications, there are often commercial off-the-shelf  (COTS) systems that can handle it. Examples include accounting, ERP (Enterprise Resource Planning), and HR software.

Another common case is the need for something very specific to the organization. For example, a government agency that regulates pesticides may have a database of different pesticides and companies that produce pesticides etc. Since this is so specialized, there are probably no off-the-shelf systems to keep track of it. A custom developed enterprise application for this agency would facilitate the data entry and reporting on this data to meet business and/or regulatory requirements.

Other common properties of enterprise software include:

  • Security - It should use the enterprises default authentication mechanism (but doesn't always).
  • Density - May have more dense (more stuff per square inch of screen space) and look busy. Consumer applications try to not look too dense because it scares people off. In an enterprise, the users are typically forced to use the application even if it looks scary. What's more important is that it uses the screen efficiently.
  • Maintainability - Should be easily maintainable by the I.T. department.
  • User load - Probably doesn't need to handle a high user load like GMail although certainly some applications in very large organizations will face a high load.
  • Style - In consumer applications, arguably, form is more important than function because it has to sell. So, a lot of work goes into making a consumer application look good. For an enterprise application, function is much more important. That doesn't mean an enterprise application HAS to be ugly. I certainly try to make them look good... but I'm no artist.
  • Predictable network - An enterprise should have a reliable LAN and an enterprise application will probably take advantage of that. Usually it doesn't need to work over a dial-up connection or cell phone so there may not be as much effort put into network efficiency. Although I certainly try to make my application efficient. I assume that someday they will have to work over a public network subject to slowness and outages.

I build Enterprise Applications and I make them network efficient, good looking, maintainable and scale-able, just in case they become very successful and end up with millions of users.