We are not an agency. We can offer you help in prequalifying technical resources but that is all.

That said, if you have a project you'd like us to bid on or if you need one or a few senior resources to work on your existing project, please call us

X is the scope of the provided service, these are:

IaaS is Infrastructure as a Service, deployable units are typically virtual machines in this case, which you manage as you would a physical machine on premise, and deploy applications to it in the normal way. Amazon EC2 is the canonical example in this area. Other higher level infrastructure services are also provided, for example EC2 has EBS, a storage service that can be used to create disk, and a service to associate public IP addresses with servers in the cloud, etc.

What makes this particularly powerful is that the services used to provision and deploy compute units to the cloud are themselves programmable, so it is possible to have applications that dynamically provision and deploy additional servers, not just for one button deploys but also in response to load! This has application in other scenarios also, in particular where you temporarily need a large compute grid, even for load testing for example.

SaaS is Software as a Service, typically the software provider charges a monthly or annual fee for their service per user. In this scenario the vendor is responsible for the infrastructure as well as software which is maintained in the cloud. Salesforce is the canonical example in this area.

PaaS is the interesting middle ground from my point of view as an application designer and developer, where the elements provided are more abstract, in particular they are the platform services needed for enterprise applications of a particular flavour. In other words instead of provisioning machines you can provision an application and then possibly additional platform services that it interacts with, so for example a NoSQL data store, a message queue, cacheing, and so on. Deployed applications can be dynamically resized in response to load. This is a tremendously powerful concept that allows smaller shops to have access to technology that allows them to scale to arbitrarily large service loads, and to inexpensively and easily implement other techniques, such as live A/B testing, without having to provision additional machines. Google App Engine and Heroku are examples in this area.

This site is a Spring Roo application running on Google App Engine.

By agile I mean a methodology of software development where we design and build the software in short increments of approximately two weeks called 'iterations'. There are many 'agile' software development methods, but they all share this concept of short feedback loops of high quality product, done iteratively. We also call these 'lean' methods to set them against traditional 'Big Up Front Design' or 'Waterfall' methods which historically have not worked very well for anyone. Our preferred type of approach is Scrum-based, but we believe that there is no one-size-fits-all solution, the methodology itself needs to be adapted iteratively to the environment and problem domain.

Operations activities can also be managed in a similar way in scenarios where there aren't such clearly defined increments, Kanban is a method that can be used as a starting point in such a case.

While we do have the capability to create web graphics based on the digital version of your business card, we prefer to work with your graphical designer or printer to achieve the best use of everyone’s skills and give you the best results, consistent with your existing styles and branding. Alternatively some smaller companies may choose to manage this themselves these days in which case we can provide you with some guidelines to use when creating media elements for your web properties.

We can also connect you with some excellent graphic designers on request.

A picture is still worth a thousand words and it is useful to decorate pages with appropriate graphics or photos that convey the subject of that page. If you are selling a product these may be photos of the product, if it is a contact page perhaps it is a photo of you or your store. More evocative images may also be appropriate. We advise you to take care of intellectual property rights, if you are reusing images that you have found on the web make sure they are licensed for free commercial reuse.

Your graphics designer should be cognizant of intellectual property issues and will have sources for stock commercial or open sources images, and perhaps their own stock. So, more simply, once you have determined what content you would like to have in your site consider discussing with your graphic designer whether they have any images that they can license and/or provide to you to choose from to accompany specific pages.

Good question! When you see a demo you know that everything is working right? You're not a software expert anyway, your vendor will make sure that everything is working and meets your requirements! Unfortunately, this is often not the case, and the power of modern technology makes it all too easy for us to break things that were working by adding new features. For your part as a customer also you want to have some oversight of the work that your vendor is doing for you. So it assures you that work is being done and also, at least to a certain extent, that there is some effort to maintain quality. I would say that the ability to offer a customer a view of the test results of an ongoing development effort is a key quality differentiator that you should look for in a vendor. Even if you are not a software developer in general if you are provided with gauges and dials that show the progress, you can do something if a gauge goes into the red! Too often the only insight a customer has is through status meetings where every task on the Microsoft Project Gantt chart shows that it is 90% done...

Some reasons you want automated tests:

1. Your software is abstractly a collection of business rules describing your business, over time you may find that adding a new one may conflict with existing rules, so you want tests to confirm new rules are consistent.
2. Manual testing is necessary but time consuming. Automating processes that are run by some of your most expensive resources is money well spent.
3. Developers can capture edge cases and any tricky scenarios in test cases, these can be missed in casual or guerilla testing.
4. Writing great tests documents the activities of your application. If you maintain your test cases you are no longer reliant on people to remember all of the details of your system, as it is captured in tests.

Automated tests do fall into different categories, but the two main groupings are unit tests and integrated tests. Typically the former are written by developers in the language that they're writing the code, run extremely quickly, and do not depend on any external servers or resources. The latter are written by developers, testers and analysts and usually drive a client session through actual scenarios.

But this isn't just something that needs lip service, you should be able to get measurables from your vendor that give you different types of information about the tests that are being run.

Some of the information that you should be able to get from your vendor about testing include:

1. An automated build that runs after every checkin. This may fail occasionally but it shouldn't fail often, that's certainly a red flag! You can also see what kind of activity there is, you should be seeing one or two checkins per developer per day.
2. Test cases. As a very general rule of thumb you'll want to have one to two times as many lines of test code as production code. You want to see the number of test cases increasing every working day on almost every checkin.
3. Code coverage. There are analysis tools that can be used to tell you what proportion of your code is covered by these test cases. For Java I recommend Lemma. This will run as part of the build and create a report.
4. Other static analysis tools -- there are tools rather like 'lint' that check for 'bad' patterns in code and report these. You can validate whether modules conform to the coding style you want using Checkstyle, etc.

This might be difficult to imagine without seeing an example, fortunately there is an open source tool that collects this information for a Java project, this product is called sonar. See http://www.sonarsource.org/.

Sonar provides a build server for popular open source projects that you can look at for examples (it has some really large projects in here, such as Apache), see http://nemo.sonarsource.org. Click around on the different projects to get an idea of what I'm talking about.

It is possible to get carried away with a focus on these kinds of measurement, and you can expect different benefits at the (roughly) 70%, 90% and 99% coverage rates and the appropriate level will vary depending on the type of project. And it is possible to spend a disproportionate amount of time writing tests, you want to have a balance between functionality added and code quality. If you are doing agile software development then you should be seeing frequent feature demos and builds (weekly or bi-weekly) to assure you that you are making forward progress as well as upping the test case count.

There are approaches where you will use Java for the back end and Javascript for the front end. As Javascript is the only execution environment available in the browser you don't have a lot of choice here (but even here there are some). But even though Javascript is a typeless language it is possible now to use structured development tools to help shore things up, so in particular it is possible to write test cases, there is a kind of "lint" program for Javascript, one can use mocks for testing, and can integrate with a Java build process using ant or maven.

We can help you get up and running quickly and offer your some advice on infrastructure. We find that spending a few hours a week is typically sufficient to keep the pump primed in the early days. Expect that you will have to do a lot of work coming out of that.

We are not investors, our initial consultation is free but we're not looking for sweat equity in your business.

We are happy to work with you to determine the best way to implement your requirements, and even to define the requirements. We feel that this is best done incrementally and empirically -- i.e. you see how things are going and make small course corrections every week or two based on what you feel your priorities are.

That said, there are two things you can work on beforehand that aren't too hard to do and can smooth the way.

First, try to storyboard the core use cases of your application. We recommend using WireframeSketcher for this, but anything will do (even PowerPoint, Word, or hand-drawn sketches scanned in). You want to capture the main idea of the product, going through successful primary scenarios.

Second, while you're working through this you will think of things that are hard to draw or are exceptional cases or errors that can occur while in the main flow. Don't try to draw these scenarios out, instead, add these to a list in the format "As a [role] I would like [feature] so that I can [purpose]". We will use these later to create the skeleton of a backlog of product items for you that we'll work through to develop your product.

Google Apps is a cloud-based productivity suite that helps you and your team connect and get work done from anywhere on any device. It’s simple to setup, use and manage, allowing you to work smarter and focus on what really matters.

businesses are looking for a low-cost, reliable, and secure messaging and collaboration solution that supports their business rather than challenges it. If your business finds itself identifying with some of these challenges, then you might be interested in considering the Google Apps solution for your business.

Take a look at the business advantages of Google Apps other customers have found out for themselves.

Business challenges:

1. Cost and resource-draining IT challenges, such as unreliable servers, setup and maintenance expenses, and operating a multi-OS environment
2. Small email inboxes
3. Virus attacks, Spam and phishing
4. Compliance to internal and external policies
5. Consumption of disk space
6. Inefficient sharing and collaboration

How Google Apps solves these business challenges:

1. Dramatically lowers your total cost of ownership. No hidden maintenance or upgrade expenses - since Google hosts your data, we absorb those costs so that you don’t have to.
2. Boost employee productivity with 25GB of storage per user - your employees can focus on their work rather than on their email quota.
3. Lean on our 99.9% service level agreement for email to make sure your business is up-and-running.
4. Share information, don’t send it. Real-time document editing cuts down the hassle of sending email attachments and version confusion.
5. You’re actually safer with Google Apps. Since your data is hosted on Google’s reliable and redundant data centers, you can stop saving your corporate data on insecure devices, a leading cause of data security problems.
6. Better message control over what comes in and what goes out of your company with Google Apps’ message security and administrative management controls.
7. Access anywhere, anytime you have an internet connection - whether on your mobile device, laptop, or computer in a multi-OS environment (PC, Mac, Linux).

Google’s security and compliance services, powered by Postini, offer capabilities that many businesses use to satisfy their compliance requirements with a variety of regulations, such as HIPAA/FERPA, among others. Generally, an organization must decide whether its use of our products is compliant with any regulations the company may be subject to.

We understand that employees want to be able to work where they want when they want, to do so they are taking the data with them. Businesses are finding themselves in the position where more and more employees are burning corporate data onto CD/DVD, thumb drives, putting data on their home machines to work on in the evenings and weekends. This has created serious security concerns, because not only do these incidents expose the data to unwanted eyes but often times we lose the data permanently since much of data resides on laptops or desktops.

As such, we take the privacy and security of our Google Apps customer data very seriously. Security is core to our DNA at Google. Our products are designed with security considerations upfront, not as afterthoughts, and our Security team is comprised of some of the world’s leading experts in information, application and network security. Our infrastructure is composed of tens of thousands of identical systems, and we have custom built hardware. Our machines are built on a custom Linux software stack that is hardened and only has the necessary components and services to run the Google requirements, making it easy to uniformly update of all systems. Each single piece of data is replicated in multiple datacenters, so your Google Apps email is replicated to a primary and a backup data center, that are replicated in real time. We also undergo regular security reviews by third parties and SAS 70 audits by an independent third party.