Adding FireFox 3 Protocol Handlers for webcal and mailto

FireFox 3 has a new protocol handler feature that will let you use web sites to handle mail and calendars. Here's how.

Posted By Randall on 05-Sep-2008 07:11

Add Qrimp mailto: handler

Add Qrimp webcal: handler

Add Qrimp webcal: handler (debug url)

Another Reason I Love Qrimp

There are many reasons I love Qrimp, but today I was faced with a problem that would have been much more difficult to solve without it.

Posted By Randall on 21-Aug-2008 16:31

A startup record label, Youthful Chaos, came to us a few weeks ago saying they were releasing the debut album for Bombazine Black called "Here Their Dreams." With traditional site development tools, that would be a really tight time line, but as you can see from the links above, it's already live -- nearly a week ahead of schedule and Youthful Chaos is taking orders now. The site includes PayPal integration and secure file download, management interfaces, content management and of course the flexibility to add a community, comments, ratings, and more albums in the future.

Beating tight time lines like this to build such a rich application is reason enough to love Qrimp, but that's not the reason I want to talk about today.

Today I'm going to talk about a little bug in some custom JavaScript that was causing problems with a couple browsers. Of course cross browser compatibility has always been a real pain. Solving them meant developing the site in one browser and moving over to another computer to test the changes. This process could take a very long time, especially if that other browser wasn't on site or the bug was happening somewhere inside some source code that has to be recompiled and redeployed to be tested.

Qrimp is 100% browser based so it helps developers solve cross browser issues much faster. Instead of going to another machine or browser to test changes, the changes are made using the very browser showing the compatibility problems. As soon as the test is made, refreshing the buggy page is all that is required to test it. There's no compiling and no need to redeploy.

Not only does Qrimp reduce the time it takes to get a web application up and running, but it also reduces the amount of time it takes to fix problems that arise later. The JavaScript problem on the Youthful Chaos site was fixed in a matter of minutes, not hours. The whole process of debugging, testing, and fixing the problem was done in a live environment and the change pushed out transparently to the customers. The site got better for the end user, but the site never went down.

So to fix this pesky JavaScript bug, I just went to the OSX partition of my MacBook Pro and loaded up the site. Sure enough, the bug was there. Using only a browser, I investigated, modified the JavaScript and some other deeper components that would have required a code change without Qrimp, saved them, and reloaded the page. Just took a minute or two. Bug gone!

That's just another reason I love Qrimp. I also love Here Their Dreams, you can buy it on the Youthful Chaos site. The album is $9.99 and you can download the MP3's immediately.

Pack your bags, we're moving to the cloud! (part one)

So it's time to move to the cloud, but where do you start? What do you need to think about? What questions should you ask and what are your options?

Posted By Randall on 26-Jun-2008

Note: Most of this is my response to a question posed by Suman Chaudhuri in the Cloud Computing Group. My intent is to provide a general overview of the topic of moving to the cloud. If you are new to cloud computing or want to begin to think about how, why, and what you may want to move to the cloud, this series of posts is for you.

The first question you have to ask when moving an app to the cloud, or using, or building an application in the cloud is, "What kind of application is it?" This is important, because the type of application will help us determine if it is suitable for the cloud at all. For example, a large enterprise system that uses many legacy systems, extremely large databases, and/or ultra secure information is on the most expensive end of the migration cost spectrum. A phone book application is on the cheaper end and may be more appropriate for the cloud. The phone book end of the spectrum is where you want to start, maybe even something less confidential that you actually want the world to see, like a product catalog.

When you are deciding on your first application for the cloud, try to pick something where you need to get the information outside your network. You may have systems like this now that your employees access remotely via VPN or a terminal service like VNC or Citrix, or perhaps customers often call to ask you the status of an order or something like that. Are there any situations where your employees could work from home or client sites if they could easily access the information they need to do so? What are the risks and consequences of data security compromise? Are they low like with a public product catalog or high like a list of customers' credit cards? On the cheap/easy end of the spectrum, are small applications that are easy to build, already web enabled or running on a platform that is natively supported by a cloud provider with minimal security concerns.

To wade into the cloud, you might want to start with a suitable packaged application currently offered as SaaS. In this case, you merely need to subscribe to the service and get your data into it. How do you do that? A lot of SaaS products have import capabilities. You can upload data in spreadsheets, tab or comma delimited files, XML and other formats that are supported by the vendor. You'll have to get your data, if you have any already, into one of the supported formats first, which may or may not be a trivial process. If you don't have data, just pay the fees or fill out the account request form and start using the application. The next step would be to consider training the part of your organization that will be using this system -- just like any other application.

So what if there is no packaged SaaS available to suit your needs? In this scenario you are going to need to do some customization of an existing system. There are lots of web-based platforms that will let you completely customize a web application to meet your needs. I'll plug my company's platform as a service called the Qrimp Platform.

What are platforms as a service? If you look at the application development trend over time, the tools used to build applications eventually move into the target application environment itself. For example, when we started solving programs with computers, we used punch cards to tell computers to print out code words that were the answers to our questions. Then we used code words (Assembly Language) to tell computers how to make long words. When C and Fortran arrived, we could use longer words to build systems and then C++ modelled the objects in the real world and allowed us to build graphical window based event driven programs. Next came the IDE's like PowerBuilder, Visual Studio, and Eclipse that were themselves graphical window based systems. Today, for the most part, those IDE's are used to build web applications and the very latest development in this trend are the platforms which have moved web application development itself into that target web environment. You could consider these platforms the next step in the evolution of application development.

To get started using a Platform as a Service, think of it as a traditional custom development project, except instead of using tools that exist on your local computer to build the application and then move it into the cloud, you use your web browser to go to a website that lets you build and customize your application in the cloud already. I would suggest using a PaaS is the easiest way to get started with custom apps in the cloud because you don't have to think about the underlying infrastructure, which I will get to in the next post that begins with some questions you should ask when selecting a platform vendor.

Continue to Pack your bags, we're moving to the cloud! (part two) ...

Pack your bags, we're moving to the cloud! (part two)

How do you choose a PaaS and what are some issues involved in moving an internal custom app into the cloud?

Posted By Randall on 26-Jun-2008

This is part two of three posts about moving to the cloud. Read Pack your bags, we're moving to the cloud! (part one)

So how do you evaluate a Platform as a Service? Some of the questions you should ask when deciding on a PaaS provider are:

• Is the PaaS standards based or will you have to learn a new language to customize it?
• Will the system work offline?
• How much does it cost?
• What are the licensing issues and do they suit your project?
• Does it work with your company's web browser or mobile devices?
• Can you move it to servers inside your firewall if you need to?
• Will the customizability of the PaaS suit the needs of your particular problem?
• What are the security options available?
• What happens if the Platform runs into a brick wall and you need to move your data to another system?
• Does the vendor lock you in?
• Does the platform you are using run on an environment similar to your own systems?
• How easy or difficult will it be to integrate the remote platform with your other internal or cloud hosted systems?
• Does the provider offer an API?
• Can it ingest data from other providers and systems?
• Can you make your internal systems accessible by the external platform for integration, either by push or pull?

Of course there are more questions than that, but let's move on to the situation where you have an existing application running inside and want to migrate it to the cloud. In this scenario you may have a code base that doesn't lend itself easily to simply dropping that application into cloud host. You have to evaluate all the components of your system and find a cloud based infrastructure provider that offers the hardware and software components that will support your system.

For example, your system may be written in Java, Rails, or .NET in which case you will need to find a cloud that will accommodate applications built with those languages. Another consideration is the need for persistent storage and database access. Does your system use MySQL, MS SQL Server or Oracle? You'll need a provider that offers the database or the mechanism by which you can install it yourself. http://cloudcomputing.qrimp.com can help you find the particular environment you need.

Once you have found a suitable provider, you have to understand the migration process. You will have to move all the bits needed for your application including the database files, static files (images, css, javascript) and also the binaries, either compiled class files, DLLs and scripts that are used to process that data. You may be able to do this as easily as FTPing the files and going to the url with your browser, but it's more likely you'll need to tailor your application to the cloud provider because of the nature of a resource pooled environment. Connection strings will change, the names and locations of environment variables may be different, middleware, email, state and session management, caching, process isolation, security issues and others will crop up in places you never expected and really the only way to find them all is just to move the code and start using it in the wild.

It won't always be easy to find or fix these problems because if you are building and debugging the code on your local computer or network systems, they won't exactly mirror the cloud system so sometimes you will have to make a change locally that will break it in your local system so it will work on the cloud. There are various techniques you can use to determine where your application is running and then do different things based on the environment so it will run in both places. You could use some intrinsic property of the environment like the servername or something foreign like a config file. You may need to discuss these issues with your provider, but they almost certainly will crop up.

Some things you'll need to think about that you may not have to worry about when running systems internally is how to integrate your cloud application with other systems you are building internally. These questions are similar to the ones for a PaaS, but in this scenario, you will have to build the web services and APIs yourself and ensure that connectivity exists between the cloud and your internal systems. This may or may not be a trivial issue. For example, you may use LDAP to provide authentication to your internal systems, but integrating your cloud app with your internal LDAP may not be an option. so you'll have to roll your own security mechanisms.

In the next installment I'll talk about some of the testing issues you should consider. Continue to Pack your bags, we're moving to the cloud! (part three)

Pack your bags, we're moving to the cloud! (part three)

When you're moving to the cloud, testing your apps requires a bit of a different approach, here are some things to think about.

Posted By Randall on 26-Jun-2008

This is the third and final installment in a series of posts discussing issues to consider when moving to the cloud.

If you haven't read them already, you may want to start here:
Pack your bags, we're moving to the cloud! (part one)
and
Pack your bags, we're moving to the cloud! (part two)


The next three steps in the move to the cloud are test, test, and test. Testing is important whether you choose a PaaS or an infrastructure provider. In the best case scenario you can use automated test tools against your remote url just like your internal apps. You will want to simulate worst case scenarios like your internet goes down or the provider accidentally deletes your data files or crashes. What is your contingency plan if something like that happens? Make that situation happen and see if your fail over works appropriately. These are the same issues you will have with an application in a traditional environment -- they are just a bit more complicated in the cloud because your cloud environment is not totally within your control and identical to your development environment. You will almost certainly have to work with more limitations in the cloud than in a local environment.

The next type of testing you will want to do is for performance. Implementing a scaling solution is easier with some clouds than others. Some solutions scale automatically, some do not. What kind of latency should you expect and can you optimize your code to improve performance?

This performance testing will also help you better understand your cost to host the system in the cloud. Every cloud has their own method to determine utilization. You'll need to understand how your application uses the cloud environment with respect to disk storage, processor utilization, memory, and bandwidth. Because each provider charges a bit differently for each aspect, you will need to understand how your application uses the environment to understand how much it is going to cost you. It's almost impossible to predict the costs without actually testing your application in the cloud and estimates may not be as simple as extrapolating the number of users. Depending on the nature of the application itself, its growth could get out of control quickly. The Animoto case study is an example. Is your app a viral candidate? How will the data grow over time?

The third type of testing would be for security. The nature of cloud hosting is different from internal apps because there are more security concerns in the cloud. For example, you may not care if anyone within your corporate network can sniff the HTTP packets for an internal phone book application, but moving that into the cloud may require SSL security to prevent hackers from gaining access to your internal contact information and employee lists. Moving an app like this to the cloud would provide many benefits, including work from home, client and vendor extranets, and the like, but you may need protect the information by limiting access to an IP range or domain, secure files differently, use OpenID, etc. Your security testing should address all these issues that may be irrelevant when building an application to run internally.

As I reread this, it sounds like it's a lot more difficult to build cloud apps than internal apps and in some respects it is, but you need to evaluate whether the cost savings from reduced private infrastructure and hardware maintenance outweigh the additional development times, learning curves, and security concerns. I think in an increasingly large number of circumstances, it makes a good deal of sense to move to the cloud. The extra concerns and difficulties of the cloud are usually not as significant as the costs to host your own infrastructure, but your mileage may vary.

I hope this helps clarify some of the issues and things you'll need to consider. How to evaluate decisions based on all the factors is a much more lengthy topic and very dependent on the particular situation.

Start on the web and leapfrog the competition

Small organizations are at a particular technical advantage today because they can start out the right way -- on the web.

Posted By Randall on 24-Apr-2008

A few years ago, Asia went wireless and leapfrogged the western world. Wireless communication is cheap compared to wires. Western countries invested billions building out copper and fiber networks to connect people, so convincing boards to spend billions more building towers wasn't an easy sell.

The same holds true in corporate IT departments. Many of them have expensive legacy systems in place costing obscene amounts of money in support and maintenance. Getting information out of them and onto the web could cost millions, so these big ships keep moving forward, slowly. End users get frustrated with the old systems. Information gets trapped in huge silos. Many of them are doing the best they can, but change is difficult and expensive.

Enter the web. Now it's cheap and easy to get information into computers, automate workflows, build reports, integrate disparate systems and get the entire company on the same web page. Companies that start on the web are at a particular advantage compared to their less nimble foes. Employees are happier because they can work anywhere -- from home, the coffee shop down the street, even at airports and on the plane. We are more productive and can make better decisions because we have access to more of our information in one place instead of tracking it down in multiple databases, legacy systems, thick client server apps and the like.

With the rise of Cloud Computing Services like Mosso and web databases like Qrimp companies don't have to invest heavily in infrastructure. Some companies still have fears of security with information being outside the firewall, but in many cases, it's actually more secure, because the data is replicated across many servers with vigorous backups, and the networks are protected with physical and virtual security measures to keep the bad guys out. Small businesses with servers in the office might have great firewalls, but what if someone breaks into the office?

And what if someone steals a laptop? If data is in a web application on a server thousands of miles away, there's less to worry about when the thief opens up that computer to find nothing but a web browser. Stories like this one about a laptop with over 1,000 Social Security numbers on it or this theft that may cost Tennessee $1 Million. Some thieves just smashed a window, grabbed what they could and took off. That's less likely to happen at a robust data center with biometric security at every entry point.

So now that the information is better protected, there are two ways having the data available on the web improves the organization. First, it improves visibility within the company. If all the company's information is on the web, it's really easy to build a web service to aggregate that information all the way up to the CEO. User interfaces can be tailored to specific departments so the end user can focus on their data entry and analysis without locking that information up in a silo. Each employee sees exactly what that employee needs to see. As information flows up the chain, it's summarized. Sales Reps see details for each customer, but the VP only wants to see how much revenue was generated for each region. In some companies, each region is on their own system, so getting that data into one report is difficult. With tools like Qrimp it's super easy.

The next benefit of the web, is that it facilitates communication with customers and suppliers outside the company. If your data is locked up behind a firewall, how do you let your customers know about price changes? Catalogs? Phone Calls? Those methods are expensive and time consuming. Websites are relatively cheap and constantly updated to reflect the current prices. The web enables extranets where you and your suppliers can communicate and stay up to date on important projects. The web also enables asynchronous communication so people can work and respond when it is convenient. Phone calls are comparatively expensive and time consuming, because you have to get two people on the line at the same time.

These kinds of benefits are going to be realized by web-enabled companies immediately while the large legacy companies are spending a lot of money to catch up or keep their old systems running. I think in the future we are going to see smaller companies operating more efficiently and effectively, taking business and employees away from larger institutions. The big companies are going to continue doing things the old way, the expensive and time consuming way and get leapfrogged like Asia leapfrogged the west.

Presentation for Tulsa DNUG

I'll be giving a presentation at the Tulsa .Net User's Group (DNUG) March 31.

Posted By Randall on 20-Mar-2008

I'm quite excited to be presenting Monday, March 31 at the Tulsa DNUG meeting. I'll be giving an introduction to some methodologies we can all use to accelerate application development using the INFORMATION_SCHEMA views.

Here's the item on the calendar at the Tulsa DNUG site.

Qrimp vs. Microsoft Sharepoint

Qrimp's closest competitive offering from Microsoft is Sharepoint. I'll discuss some of the different features of the products.

Posted By Randall on 21-Jan-2008 12:35

Occasionally we have been asked how Qrimp compares to Microsoft Sharepoint. I won't discuss costs here, but I will say that Qrimp is sold per user license for the Qrimp platform, not by the number of users within Active Directory. This can be a significant cost savings when only a portion of your organization will be using Qrimp.

Technicalities

First, Sharepoint is a very extensible system. It integrates with a lot of tools from Microsoft, including Windows Workflow Foundation. This is a nice capability, but these are heavily oriented toward developers. To customize Sharepoint capabilities, you'll need a license for Visual Studio.

Qrimp is designed to be fully extensible from the web browser. There is no need to buy Visual Studio or other tools from Microsoft unless you run Qrimp on your own servers, in which case you'll need SQL Server. You'll need SQL Server for Sharepoint as well.

From the front end, the interface is much easier to use. You can add new lists to Sharepoint from within the web interface, but it is fairly complicated. I recently asked a Sharepoint guru how difficult it is to teach business users how to extend the Sharepoint capabilities and he said it isn't very easy. We've taught users who previously didn't know what a database was how to use Qrimp. If a user can understand a spreadsheet, they can probably understand what Qrimp is.

The Database Architecture

The significant difference between Sharepoint and Qrimp is that accessing the Sharepoint database directly is almost universally forbidden. Microsoft does not support directly modifying the Sharepoint database. When I asked the aforementioned Sharepoint Guru what he thought about the issue, he said: "NEVER NEVER TOUCH THE DATABASE DIRECTLY!" A Sharepoint Thoughts post says:

Whatever you do, do NOT PERFORM DIRECT EDITS TO THE SHAREPOINT DATABASE.
* Do NOT manually update records
* Do NOT manually insert records
* Do NOT manually delete records
* Do NOT MODIFY SHAREPOINT DATA!!!

The reason is because the database architecture used to store the data within the Sharepoint system is much more complex than that revealed by the API to the developer. To access the data in the Sharepoint repository, you must go through the Sharepoint API. The API conceals the underlying data model from the end user and this data model could change with service packs.

Qrimp on the other hand builds a standard database architecture for your data. Tables are tables. If you view your table in grid view, that's what your table will look like if you accessed the database directly. If you update a record in your table with an SQL Query and then view that record from the web interface, the record will be updated. No harm done. One caveat is if you have versioning enabled on the table, the edit will not be stored, but your database will not be corrupt. Similarly, you can delete records or insert new records as well.

If you run Qrimp within your firewall, you can use bulk import tools to bring in as many records as you want into your Qrimp database and start using your system right away. There are some rules to how Qrimp stores information in the database to be aware of. Each table has an ID field that is an Integer Identity that is the Primary Key. The CreateDate and CreateId fields have special meaning for auditing. The rest is fair game.

Summary

The differences then, between Sharepoint and Qrimp is that Qrimp allows you to pay for only the users who use the system. Sharepoint is more extensible because you can use tools like WWF and Visual Studio to write any code you want -- but you have to code it. The final difference is that with Qrimp, your data is your data. You don't have to go through Qrimp to access it. If at some point in the future, you realize you need a custom process to access your Qrimp database and make changes and retrieve data, you can do that.

Qrimp is more flexible in this way. With Sharepoint, you are locked into using Sharepoint as the interface to your data. With Qrimp, you can pull your data out or access the existing Qrimp Database without any modification. Qrimp creates very nice standard data models for your data. Most DBA's will quickly recognize the models Qrimp builds for One-to-Many and Many-to-Many relationships.

If you have any questions about this, please don't hesitate to contact us.

Platform on Demand

Qrimp is a platform on demand that allows you to solve problems with software for which there is no existing software solution.

Posted By Randall on 20-Jan-2008

Qrimp is a platform on demand. When I talk about a platform, I mean a system that allows you to modify the way it works. An enclosed system that contains all the moving parts to make your new solution operate. If you use the hosted system, our platform is there without you needing to purchase hardware or software other than the computers you already use to browse the Internet.

The platform is on-demand, because you can make it do what you need it to do when you need it done. You can manage any kind of information: Customers, Contacts, Task lists, Conference Schedules and anything that is particular to your business that the makers of Qrimp may have never even heard of.

We are excited to see how our customers use Qrimp and all the ideas we hear from people about what they could do with it.

Anything you can do with a database or spreadsheet you can do with Qrimp. The advantage of using Qrimp is that you bring all the tools needed to put an interface around that data into one location. You don't need Integrated Development Environments, Relational Database Management Tools, Code Editors, HTML Editors. You don't need to download anything, just use your browser.

Data Portability

Data portability is about more than social networks. It's about progress and productivity.

Posted By Randall on 13-Jan-2008

All the fuss about Data Portability in the news lately is a much bigger issue than names and email addresses. Data Portability is about making your information easier for disparate systems to access both within and beyond your control.

One of my clients recently needed access to information from multiple vendors. They were in the business of reselling similar products and helping users find the best price. Part of the job was pulling the pricing and product information into a vast database that we could search through to find the exact match for the customers' needs and help them decide which one to purchase.

After contacting the vendors, there were about 10 of them, the conversations were all pretty much the same -- either it was too complicated for them to provide the data or they didn't have it outside their proprietary systems. The smoothest process in most cases involved someone from Company A calling someone from Company B and asking them what the current values were.

Such a process is horribly inefficient and prone to compounded data entry mistakes. Had Company B simply provided the data in XML, CSV, or some other sort of flat file, the process would have been very simple. But they didn't, in most cases, because it isn't simple to do that. Many systems might have the ability to export data, but how do you automate the process and how do you make that exported data available to users securely over the web?

Sharing data should be simple and painless. With Qrimp it's as simple as modifying the URL. For example, on the Qrimp demo site, you can view a list of fuel economy by vehicle in HTML or fuel economy in XML or CSV that you can easily import into your custom application. You can even create custom formats for RSS Feed Syndication, JSON and more.

If you have security enabled on your information and don't want just anyone looking at it, you can create a username and password. The organization with which you want to share information then makes two requests. The first passes the username and password and receives a customer user token that it uses to make subsequent requests.

Qrimp didn't exist while I was working for those clients, but if it had, they would have easily saved tens of thousands of dollars in development costs. The companies with the products would have saved money as well and increased exposure for their products much quicker. In this industry, time is money.

This was my motivation for building Qrimp. Not only will it save companies thousands, even millions of dollars, but it will help them bring these products to market much faster.