NetQuarry Platform Support for Maps and Charts

COSTA MESA, Calif. – February 18, 2008 – NetQuarry, Inc. announces release of its Google Maps and Google Charts integration modules for its NetQuarry Enterprise Application Platform.

NetQuarry’s mapping and charting modules leverage Google’s publicly available API’s for rendering maps and charts. With the NetQuarry integration, developers using the NetQuarry platform can immediately take advantage of the Google capabilities without having to learn the Google API’s.

The mapping and charting modules are included as a standard part of the NetQuarry platform and will ship with subsequent releases.

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

NetQuarry adds SQL-Server Reporting Services Integration

COSTA MESA, Calif. – December 10, 2007 – NetQuarry, Inc. announces release of its SQL-Server Reporting Services (SSRS) integration module for its NetQuarry Enterprise Application Platform.

The SSRS integration allows developers to tightly integrate SQL Server Reports into a NetQuarry application taking full advantage of the rich filtering and security features of the NetQuarry Platform without having to re-secure the data for the reports.

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

NetQuarry Wizard Enhancements

September 24, 2007 – NetQuarry, Inc. announces release of the first-generation meta-data-driven wizard engine for its NetQuarry Enterprise Application Platform.

NetQuarry’s new wizard engine is capable of composing wizard pages driven entirely by declarative meta-data. NetQuarry application developers can take advantage of the new wizard engine to add multi-page data collection processes to their applications without writing a single line of code. Like other NetQuarry rendering components, the wizard engine allows developers to customize their application even further by adding programmatic extensions to the wizard.

Earlier versions of the NetQuarry wizard engine required developers to create custom user controls, configured via meta-data into the application, for each page in each wizard. The upgraded wizard engine retains this ability, but adds the ability to create entire wizards in a purely declarative manner.

NetQuarry Chief Scientist Campbell Woods described the idea behind the new functionality this way – “The idea behind the wizard engine improvements is really consistent with one of the design principles we try to incorporate in the platform as a whole. That is, try to make it very easy to do the things developers do all the time and still allow them to reasonably do the one-off things that every application needs.”

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

Are we there yet?

I’ve been absorbed lately with the nagging question that keeps coming up every time I solve what I thought was going to be a simple problem – “Are we the only ones doing this?” This is followed by the more important question – “How is everyone else doing this?” At NetQuarry, we sell, effectively, answers to these questions. The problem, and the thing that always suprises me is the fact that we have to do much of what we have to do to produce our product. The complexity of enterprise application development is startling. You basically need to be an expert on about 10 things just to get started.

I’ve been personally involved in an enterprise architecture project for a well funded valley company (it was J2EE, to be fair) that had 100 people (including QA, Docs, and a bunch of managers) working for 2 years to implement an enterprise application architecture. We spent nearly 40 million dollars (seriously) on development. I’ve spoken to CTOs at software companies (ISVs) who are solving this and have arrived at the conclusion that nobody knows exactly where to start.

Most people in my position would roughly agree with me, at least in principle, but most would have a hard time citing real examples of why this is so hard. So, here are some examples:

Simple example first – permissions.

When you build an application of any reasonable complexity, you will have to architect and implement a way to authenticate users, retrieve a set of profiles (groups), and restrict access to parts of an application based on who the user is and which profiles have been assigned to them. How could you accomplish this? There are a ton of ideas out there. There is an idea of a database directory that .NET will build for you in SQL Server. There is a decent way to hook in Microsoft Passport authentication. There is a user/password/reset password control. There is the “forms based authentication” that takes a real time investment to understand and once you do you wish you hadn’t. What doesn’t exist anywhere is a reasonable way to consume the information you get from your authenticated users.

What also doesn’t exist (and this is the important bit) is a way for you to declaratively hide a column in a grid based on which user just logged in. Hold on, I’m going to explain.

Say I have a column in my DataView grid (say a salary column) that I only want users with the Administration Profile to see. Further, I want to define this by checking a little box somewhere that says “Hide from general users, please.” Then, I want that information stored in some persistent format that allows me to check it into source control. Asking too much? You might say this is easy. All you have to do is… build a file that holds the data, or put the data in a database (this sort of discussion ends relationships), write a little tool that edits the file or just screw with it yourself, store this file in source code, add it to your installation script, build a tool to change it inside your application (which you need to secure as well), copy it to the server before you go live, … Crazy.

Another example  – filtering

The .NET Framework and Visual Studio, along with the competition (J2EE, and the slew of tools available here) has a way to take data out of a database and present it in a grid. Generally there is a way to handle sorting, paging, hiding columns, and, of course, applying some sort of theme. However, what if you want to filter the list in some way? Simple, right? All you do is build another set of controls on the form for each column that you want to use in your filter. Some of the columns are foreign keys to other tables, so you’ll want to build some sort of interface to deal with these. Many of your foreign keys are really just lookup values, so you’ll want a way to build a DropDownList control with these values in it. Next, you’ll have to take the result of a postback on this form, determine if it has to do with your filter controls, and construct some sort of SQL filter for your database and re-display your list. If your users want to be able to filter on multiple values, well, then, its a bit harder. You’ll need either a new interface, or you’ll have to handle filters like: “BETWEEN x AND y” or “This Month” or “>Today” or “=FRED” or “Starts With Fred” and likely a bunch of others.

The kicker – you have to do this with every grid. You’ll probably get clever and build a base class that reads information from the DataSource and builds some filtering capabilities. Once you’ve done this, you’ll think its pretty easy. Honestly, though, a full featured grid view with good filtering (forget about column wise permissions) is a bunch of work. Even if you are pretty good at this you’ll still have the problem of managing the thousands of foreign key lists. (Much more on this idea here.) And, each one is just a little different. So, you probably end up with a bunch of pages all with slightly different code in them to change the properties of the particular page you are working with. At least you can check these into source control.

Meaning?

Enterprise application development is hard, really hard. Any way you look at it, you absolutely must solve most of these problems, even if you solve them poorly. Generally this is done by giving your Highly Paid talent the title of Architect and asking them to guide you through this process. If you are smart you’ll get two of these smart folks, because one smart guy alone will always come up with dumb ideas. If he is working by himself then you’ll usually end up implementing some of these ideas. Loosely quoting Brian DePalma – “Every time you think up a perfect architecture there are 50 ways to screw it up. If you think of 25 of them, you’re a genius.”

The solution always looks about like this:

  1. Hire 1 or 2 expensive people and let them think for 3-6 months.
  2. Add a productive resource and start writing a low-level database access class library that wraps ADO.NET. or JDBC. This puts you 6-9 months into the project.
  3. Add another productive resource and build a reasonable grid, detail view, and a simple navigation metaphor. You are at least 9 months into the task now.
  4. Frantically add a bunch of not so productive (read, cheap) resources and tell them you are behind. Sometimes you send your application to India, China, or Iowa at this point.
  5. Scramble for another 6 months or so until you begin slashing features as fast as you can.
  6. Release your first version 18 months from the start of your project to resounding cries of disappointment and astonishment from your user base.

This isn’t just me talking. There are well known research reports from respected analysts that assure us that more enterprise projects fail than don’t. Below, from Software Magazine, a blurb on the Standish CHAOS report:

“The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects. That’s more than a 100-percent improvement from the success rate found in the first study in 1994.”

So, we’re getting better. Only 66% fail. I’m not suggesting that poor architecture implementation is the only reason projects fail. I’m betting that it isn’t even the leading direct cause. But I do know who gets blamed when the project doesn’t go correctly – the Highly Paid developers. And, I believe it isn’t necessary.

Why hasn’t this been solved?

I believe that eventually Microsoft will introduce enterprise infrastructure to the .NET Framework that solves a good chunk of this problem. What they have done so far is give us the Enterprise Library, which solves some real problems, but is still, as its name suggests, a library. You’ll still need an implementation of an architecture using this library before you can start your application. Why the Enterprise Library isn’t directly part of .NET is another question. I love this quote:

“Enterprise Library is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product.”

So, why hasn’t Microsoft solved this yet? I think they don’t want to offend anyone. When one implements an architecture you have to make choices that will cause concern and questions from almost any of the consumers. Where is the application metadata stored – relational database or the file system? Is the object mapping strictly typed or not? What is the external access strategy – Web Services? What about authentication? Permissions? Data Permissions? Deployment? Testing? Localization? Internationalization?

The other reason there isn’t any cohesive strategy around an implementation of an enterprise architecture is because there are a lot of people that get paid a lot of money who are pretty interested in continuing to get paid to design and implement terrible applications. If I had a choice between a year getting paid $200 (or more) an hour or simply using an available solution, it would be a simple choice.

The other problem is that depending on the group of people you are talking to, many are convinced that this problem can be solved by using the right tools or selecting the correct grid control. Really. I’ve spoken to presumably smart people who have told me that the problem with enterprise development is simply management process. This is generally followed by a conversation with someone who knows that if you would simply get the requirements right nothing would go wrong. Next, I’ll speak to an Architect who has landed on a architecture that is, in its entirety, .NET. And, of course, you can throw a rock and hit someone who believes that the answer is UML. The worst, of course, is this: “we’re using SOA.”

I-got-a-good-idea

NetQuarry is an enterprise application platform (for Microsoft .NET). What this means is that we have a layer of runtime code that reads a definition of your application at runtime and produces an ISV quality web-based application. The definition includes references to code that you write (extensions), profiles you declare, schema that you design, and presentation that you build. Much of the definition is built using our tooling (NetQuarry Studio). When you write your code you use Visual Studio, we’re not in the IDE business. Read more here.

The important point to understand about NetQuarry is that it is both an architecture and an implementation of an architecture. It is also important to understand what it is not. It is not a code generator and it is most decidedly not a framework.

We also think that the real promise of NetQuarry isn’t simply an architecture with implementation, but rather what you might do with this implementation once it becomes generally available. The largest idea is the concept of application content. What I mean by this is the availability of functional application parts that can be deployed into a platform (like NetQuarry). Real application assembly. Salesforce.com has done something like this with AppExchange. I like AppExchange but of course I can’t see how I’d use this to create OptionEase, DiForza, or iLUXCARS. For these sorts of applications I have to build it myself. So, the content parts should be a bit less coupled with the application, which is hard, but possible, again, once we have a real implementation of a platform.

If you are interested in the NetQuarry platform or what you might be able to do with it please feel free to contact us: info@netquarry.com.

Ryan

NetQuarry Version 2.0 Released

COSTA MESA, Calif. – February 28, 2007 – NetQuarry, Inc. announces release of v2.0 of its NetQuarry Enterprise Application Platform.

“The last year and a half has been busy for our engineers,” said Ryan Reid, NetQuarry CTO. “During this time we’ve ported to .Net 2.0, put our first customer applications into production, and landed our first international client all the while adding a wide range of features and aggressively fixing bugs.”

The v20 release includes a wide range of new features including:

  • Support for .Net 2.0,
  • UI enhancements,
  • Internationalization,
  • Advanced data revision tracking and auditing,
  • Improved email integration,
  • Improved tooling,
  • Performance enhancements,
  • Accumulated bug fixes.

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

NetQuarry and Comensura Ltd of Luton, UK

COSTA MESA, Calif. – December 18, 2006 – NetQuarry, Inc. announces that its NetQuarry Enterprise Application Platform has been selected by Comensura Ltd of Luton, UK, as the development platform for the next generation of its C.net Temporary Recruitment application.

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

VisualBasic

It occurs to me, and not just because we write and sell a .NET product, that a good number of owners of large VB 6.0 applications are about to become a little nervous. As part of a proposal for one of these companies, I was tracking down the support dates and end-of-life statements by Microsoft about VB 6.0. It says, basically, that the Visual Basic runtime (or an updated version) will ship will Windows Vista and will be supported fully for 5 years, and not so fully for 5 more years after that.

The actual support of Visual Basic and Visual Studio 6.0 (in which VB 6.0 shipped) is over now. This sort of surprised me. I assumed that Microsoft would continue to support VB more or less forever, silly as that may sound. The actual dates for “support” are here: Visual Basic Product Lifecycle, and this says that real support ended 3/31/2005, and extended support will last until 4/8/2008.

I was a long time Visual Basic user — our last product used it as the extension language — and if I had a large VB 6.0 application, I would probably worry. I’m pretty sure that many VB 6.0 applications will continue to run. I’m also pretty sure that if they didn’t, and if they were mission critical, most enterprises would be able to find someone to tweak their application so that it would continue correctly.

What would worry me is less concrete. If you manage or develop an important product for a large enterprise and the language that the application was written in was out of official support, I’d start thinking that maybe it was time to think about a port. Why? If nothing else because anything large enough to worry about is likely to take until April of 2008 to get ported.

All of this is a somewhat shameless pitch for NetQuarry, of course. Actually, I don’t see how one would begin a reasonable port of a large Visual Basic application without at least the start of the infrastructure that we provide. Many of these applications are huge — e.g. 1000s of pages, tables, and complex rules. Most of the folks who built and probably deeply understand the application are off on other projects (presumably in a more modern language).

OptionEase

NetQuarry has been used to develop OptionEase.com, a software-as-service application that manages stock option expense tracking for the new (as of Jan 1, 2006) FASB 123R accounting rules. The team that built the application (Version 1.0) was composed of 3-4 developers over about a 3 month period. They have generated a large amount of interest with CFOs in the last couple of months, even signing up their 2nd real customer. We think this proves the promise of NetQuarry well. From concept to customer, with a small team in a little over 6 months. A demo-able version of the application was running in the first 3 weeks.

A few interesting ideas came out of the building of this application. Perhaps the most significant is the addition of what we are calling “TypedMappers.” A TypedMapper is a helpful, extrememly lightweight type-safe wrapper class around a NetQuarry Mapper object.

You typically use a TypedMapper as a helper class in an extension. You can create a TypedMapper and attach it to the sender (IMapper) of the event or you can use the TypedMapper derivative to create a new mapper – either for the purpose of creating a new row or reading/updating an existing one. Connecting a TypedMapper via one of the constructors or TypedMapper.Attach is very inexpensive and generally a safer way to work with a mapper.

The TypedMapper is an abstract base class, which means that you have to use our generator to generate derived classes that wrap your mappers. The ONLY potential drawback to using a TypedMapper derivative vs. the Mapper as is is that you will need to update (re-generate) the classes as you make metadata changes. On the applications that we (NetQuarry) are personally managing we are putting the generation code after we save the metadata and check-in the class file. We are recomending that you keep the generated classes more or less stand-alone (e.g. in its own assembly) and without any dependencies on other code.

The help is updated (NetQuarry Help) if you want to see code samples–Search for TypedMapper.

About NetQuarry

NetQuarry develops and licenses the NetQuarry Enterprise Application Platform. The NetQuarry platform helps professional software development teams develop significantly better enterprise and hosted applications.

NetQuarry is privately held. For more information, call (714) 881-4574, email info@netquarry.com, or visit our website at www.netquarry.com.

DiForza

NetQuarry is being used as the infrastructure for the new site Diforza.com. You can see it here: http://www.diforza.com

One of the more interesting aspects of this site is that unlike the default user interface this site is NOT using frames. What we did was add a feature to a page based on the Wizard Template that allows you to specify a header and footer “renderer” component.

Web Projects and .NET 2.0

I’ve spent a frustrating day (again) attempting to setup a web project that is a sub-project of our main application. For whatever reason, I can’t reference code in a referenced assembly unless I load it as a control reference and, at least in most cases, copy the referenced assembly to the main /bin folder.

Works like this:

  1. NetQuarry is installed. The core assemblies are in the <webroot>/bin folder.
  2. The application needs some custom controls (mostly for wizard pages).
  3. The application wants to reference another custom assembly. To do this, we copy the assembly to the /bin folder of the new project. We include the reference and we can use the code in the debugger.
  4. The application’s new web project is installed and developed in a sub-folder of NetQuarry. (<webroot>/Apps/<myapp>).
  5. The code compiles, but you can’t load any of the custom controls because it can’t resolve the type.
  6. On most machines (I can’t tell you why this isn’t all machines) all you have to do is add a reference in the .ASCX page like this:
    <%@ Register TagPrefix=”myappref” Namespace=”MyApp.Common” Assembly=”MyApp.Common” %>
  7. On other machines, you have to copy the referenced assembly to the root /bin folder.

Incidentally, I’ve tried the new Web Application Project model to solve this and failed as well. Scott Guthrie has a good post about it: Web Application Projects that you should read. The (really) good news about this new project model is that it compiles significantly faster. The bad news is that I have a similar reference problem when I try to create a web user control dynamically unless the assembly is copied to the <webroot>/bin folder.

So, why not just copy the sub-project .DLLs to the main /bin folder? Because I really don’t like it. In NetQuarry, sub-projects are loaded dynamically (a somewhat foreign concept to everything ASP, I know) and they don’t have a dependency on the main NetQuarry Web assembly. The idea is that one installs the core NetQuarry web, then builds their own web components (web user controls), references them as components using the NetQuarry Studio and uses them as PageElements to build wizards.

NetQuarry also loads extensions dynamically, which is exactly what we want to do with these web projects. So, I tried converting to the new Web Application Project model for sub-projects and loading the assemblies dynamically. Still didn’t work. Since these are web projects, you would think that the way to do this is in two steps: first, load the assembly, and second, load the user control via its virtual path. Once the assembly is loaded .NET should understand the types in the control but for some reason it doesn’t.

The idea behind NetQuarry is that you don’t have to know any of this stuff, but just so you know, the idea (that doesn’t work) is like this:

private IWizPage LoadWizardPage(NetQuarry.ComponentInfo ci)
{
    System.Reflection.Assembly asm = ci.LoadAssembly();
    return LoadControl(ci.Component) as IWizPage;
}

Where the ComponentInfo.LoadAssembly method is a little complex (and ommitted here for brevity). Basically, we try and find it in the list of loaded assemblies first, then in the specified path, then in <webroot>/bin, and finally in Apps/<appid>/bin.

Turns out that after you load the assembly, the component still doesn’t load. So we’re still discussing this. Perhaps I’ll break down and have custom projects deployed to the <approot>/bin folder, but I sort of doubt it. As ususal, it feels as if we’re the only ones solving this problem, but I did find this post from over a year ago (Dynamic LoadControl of ascx with dll not in bin path) and there is a response there (from a DevelopMentor staffer) that says: “ASP.NET mandates implicit loading of assemblies from ~/bin or the GAC. You can always call Assembly.LoadFrom, but I’m not sure if the LoadControl will work with that. It’s worth a try.”

I nearly refused to believe it, but after about 2 bad days on this, I’m convinced. Love to know why, Microsoft, anyone?

For now, we are leaving it alone and leaving the hacky @Register business in place.

We did, however, convert our main project (EAP.WebHost) into the new model and boy oh boy is it better.