Application Development, Mobility, Test Driven Development, Tools

Taking on the Challenge of Mobile App Testing: How to Test Cross-Platform

A recent report by OpenSignal revealed that there are 18,796 distinct Android devices in use. This data was gathered directly from users who installed the company’s app. Even though device fragmentation is not a new phenomenon in the Android world, the sheer number of devices is impressive (up from 11,868 devices counted last year).

Read More
By Axel Buerkle on Sep 2, 2014 11:17:16 AM
Languages, Oracle Fusion Middleware, Tools

Mind Shift Necessary When Adopting Oracle Fusion Middleware – Part 1

A couple of years ago, Online began an Enterprise level project with multiple vendors and a total team size of over 500 people. Oracle Fusion Middleware had been selected as the implementation technology. With 14+ years of development experience in traditional development languages such as C\C++, Delphi, C#, and Java, I approached this new technology as I would any of the other languages I’d learned. I attempted to apply SOLID principles and in doing so, realized that there was a mind shift necessary to successfully achieve this goal.

Read More
By Dave Thomas on Sep 23, 2013 4:55:11 PM
Languages, Tools

Multiple Eclipse Configurations

If you are like me and have embraced Eclipse as your preferred IDE for dabbling in various java related frameworks, you have undoubtedly run into a situation where Eclipse is no longer happy. Either from slowing to a crawl, or the Scala plugin is complaining while you are trying to do Android development or one of many other possibilities. Besides, why do you want the overhead of the Android plugin when you are working in Scala, or the svn headaches when you are using git?

Read More
By Duane Colley on Sep 3, 2013 10:23:47 AM
Languages, Tools

Open Source ESB Search - Part 2

Previously on “Open Source ESB Search

Today, on “Open Source ESB Search”

  • Ramping up our Open Source ESB Implementation

What are the current, mature, best of breed Open Source ESB offerings?

  • JBoss – the most mature, but lacks a development paradigm that allows for TDD using any IDE. Arquallian provides some support, but not ready for production. Operational support offered by Red Hat.
  • Mule – lower level DSL’s that feel dated. Less testing support. Operational support offered by MuleSoft.
  • JBoss Fuse ESB – nice aggregation of common tools available to Java or XML DSL. Seems to be the “simplest thing that works” while covering 40+ EIP’s. Operational support offered by Red Hat.
  • Spring Integration – provides EIP and generally very good, but would still require container support. Operational support offered by VM Ware.
  • WSO2 – has matured recently, but seems to require more current development than other projects that reuse other OSS components. Operational support offered by WSO2.

Which ESB scored highest? Which feels like the right fit?

  • Fuse’s features combined with the ability to “upgrade” to the full JBoss stack without losing support swayed the decision in favor of Fuse. JBoss is in the process of applying other JBoss tooling to the Fuse environment. Operational support available via Red Hat may be offered to our clients on a deployment-by-deployment basis.
  • Previous investigation resulted in positive feedback with Fuse ESB’s leveraging Camel’s DSL.
  • Fuse ESB’s use of CXF to publish web acceptors is familiar to each project developer.
  • Red Hat’s Linux offerings position us to deploy to either a free or an enterprise OS while staying within the same support proposition.

What due diligence did we perform?

  • Evaluated each Open Source ESB for platform openness, community involvement, upgrade paths, development support, and many other concerns.
  • Investigated possible Red Hat partnership.
  • Became a Red Hat partner.
  • Attended Camel One.
  • Attended Red Hat Summit.
  • Investigated sample and example code for quality.
  • Performed gap analysis between the ESB features and our first project’s requirements and non-functional requirements with an eye towards system expandability and flexibility.

Where are we now in the process?

  • We have a system architecture and design.
  • We are validating our system architecture and design against the Fuse ESB.
  • Help desk has built out three virtual machines – as defined by our system architecture; we require three virtual machines to validate our failover, tracing, and lost-less message non-functional requirements.
  • We started a bit of an “Iteration Zero” and spike iteration. As an Agile shop, we demand customer-usable software features delivered in each and every iteration starting with the first iteration. For this project, we have a bit of time before the client is ready to consume any deliverable, so our Delivery Manager is the customer stand-in.

What are some of the next steps/posts?

  1. Further Discuss the Problem Domain
  2. Map the Solution Domain onto the Problem Domain
  3. Discuss Testing Tools and Techniques
  4. Discuss our ESB Ecosystem and Topology
  5. Enumerate ESB Acceptors and Message Canonicalization
  6. Conclusion and Postmortem


Read More
By Duane Colley on Jul 23, 2013 2:27:31 PM