Redesigned Appoxy Website

If you're reading this, you've likely seen the redesigned Appoxy website we released over the weekend. Captures all the things we're doing at Appoxy -- building web applications for others and developing cloud management tools in the process.

It's just a start. Look for more information on services, on customers, on products, and on tips and insights on developing in the cloud.

And also more pictures of the team and the fun Appoxites (Appoxians??) bring to their work.

Cloud Computing Tests

Watching the live stream of Marc Benioff's keynote at Salesforce's Dreamforce conference today in San Francisco. He's moving quickly from topic to topic burying the ledes in many of them. He says, "databases need to be in the cloud" and then moves on. Took Travis to note to me that Techcrunch this morning posted a notice that Salesforce launched database.com, a SimpleDB-like cloud data storage service. Update: At the end of his talk, before handing the mic over to the product people, he runs through the list of products -- database.com included. It looks like an

impressive list, putting Salesforce as a serious company to watch in the cloud infrastructure space.

At some point, he moves on to some digs at Oracle. (There are many of these throughout.) One story he tells leads up to his call for a cloud test. "We need a cloud computing test" soon followed by "beware the false cloud." It's a nice couple lines. The slide that goes along with it makes a lot of sense when going up against Oracle.

But it's not necessarily as good as Amazon's list of cloud attributes:

Note that the first slide talks about cloud (kloud) definition number 1 (software as a service). Amazon, of course, is offering up cloud definition number 2 (infrastructure as a service).

Now if only Marc could go after Microsoft for their brainless "into the cloud" TV commercials. (We're not linking to them because you won't forgive us if we do.)

Web 3.0 | More Parts on the Table

It's easy to hear a term like Web 2.0 – and now Web 3.0, Internet of Things, and BigData – and think they're trite and meaningless. Conjured up by "thought leaders" and used by marketing folks to position companies as new, different, and on the leading edge. They can be overused and difficult to define.

But that doesn't mean that there isn't something to them. With Internet 1.0 and Web 2.0, it's easy to see in retrospect how powerful base sets of technologies were in allowing people to come up with revolutionary things.This power of base components was brought home by a recent article in the Wall Street Journal by Steven Johnson.

The article explores the genius of tinkerers and their abilities to take commodity parts and assemble them to make brilliant and resourceful inventions. A baby incubator for developing countries made from car parts, appliances, and other assorted pieces is the example he uses to open the article.

Web app developers share many of the same traits as these tinkerers, especially these days with widely available open source software, on-demand cloud computing, sophisticated language frameworks, and affordable web services.

The key reason why the terms above – Web 3.0, Internet of Things, and BigData – have real meaning is because behind them are serious technologies that have commodity aspects to them – affordable, widely available, and simple to employ.

The Genius of the Tinkerer

There is a famous moment in the story of the near-catastrophic Apollo 13 mission--wonderfully captured in the Ron Howard film--in which the mission control engineers realize they need to create an improvised carbon dioxide filter, or the astronauts will poison the lunar module atmosphere with their own exhalations before they return to Earth.

The astronauts have plenty of carbon "scrubbers" onboard, but these filters were designed for the original, damaged spacecraft and don't fit the ventilation system of the lunar module they are using as a lifeboat to return home. Mission control quickly assembles a "tiger team" of engineers to hack their way through the problem.

In the movie, Deke Slayton, head of flight crew operations, tosses a jumbled pile of gear on a conference table: hoses, canisters, stowage bags, duct tape and other assorted gadgets. He holds up the carbon scrubbers. "We gotta find a way to make this fit into a hole for this," he says, and then points to the spare parts on the table, "using nothing but that."

The space gear on the table defines the adjacent possible for the problem of building a working carbon scrubber on a lunar module. (The device they eventually concocted, dubbed the "mailbox," performed beautifully.) The canisters and nozzles are like the ammonia and methane molecules of the early Earth, or those Toyota parts heating an incubator: They are the building blocks that create--and limit--the space of possibility for a specific problem.

The trick to having good ideas is not to sit around in glorious isolation and try to think big thoughts. The trick is to get more parts on the table.

Congrats to Plaster Networks for Winning CEPro's BEST Award!

A panel of industry experts, integrators and the editors of CE Pro and Electronic House, has awarded Plaster Networks (www.plasternetworks.com) PLN3 powerline adapters the 2010 Best Award in the home networking category. Criteria included creativity, innovation, incorporated equipment, obstacles overcome, aesthetics, and lifestyle benefits. The selection was announced last week at the custom installer conference CEDIA in Atlanta, Georgia.

Our team at Appoxy congratulates Plaster Networks for the award and wishes them many more successes!

And yes, Plaster Networks is one of our long time clients. We work on their big data in the cloud and remote management capabilities.

cloud (kloud) n.

Had a couple conversations in the last week with smart tech people about what "cloud" means. Thought it was well understood but based on these conversations, it appears not so much. In light of debate, here's a definition that bridges the different interpretations I came across.

cloud (kloud)
n.
1. Web services and applications that operate through the browser and http and are accessed through the Internet. Examples include Salesforce, Google mail and Google docs, Basecamp, and any of the thousands of other applications hosted on the Internet. Also referred to as Software-as-a-Service. Most people not arm-deep in building applications have this definition in mind when they come across the term "cloud".

2. Infrastructure for building and running applications hosted by third party services. Leading providers include Amazon Web Services and Rackspace although IBM, Microsoft, SalesForce and others are quickly rolling out cloud platforms of their own. This type of use is also referred to as Infrastructure-as-a-Service and comes in public and private variations. The base offering is access to virtual servers -- on-demand computing resources that can be accessed and provisioned in minutes. Additional services include load balancing, elastic data storage, distributed content delivery, and other infrastructure capabilities.

ReadWriteWeb - Why Cloud Equals Better Outsourcing

The following is a post that was written by Appoxy for ReadWriteWeb:

Business Week published an article recently that talked about changes in outsourcing. They got the cloud part right - massive disruptions and changes in the IT infrastructure stack both in technology and company power positions. But they got the outsourcing part wrong.

There will be big changes for large and middle-tier outsourcing companies. But the large won't necessarily get larger. In fact, the combination of cloud and modern programming frameworks makes it perfect for small developers and medium IT shops to get a leg up on the big consulting firms, putting their models - and margins - at risk.

This post explains why cloud makes for better outsourcing. More specifically, why cloud lets you keep a better eye on outsourced development, lets you more quickly correct issues that might arise, and gives you more security when taking ownership of the work.

Read more >>

Minimum Viable Product = Measure Once, Cut Many Times

Developing with RoR + AWS provides incredible agility - making it possible to quickly develop products that people can react to. This combines well with “minimum viable product” theory -- an approach which is rapidly moving from web 2.0 startups to many companies across the spectrum.

From Wikipedia:

A Minimum Viable Product has just those features (and no more) that allows the product to be deployed. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

The idea is not that different than the long-time approach of developing a prototype except that now the prototype becomes a production version. It may not be released widely but it’s not necessarily built to be disposable. The prototype is expressly created to test market reaction. Prototypes in the past were developed primarily to assess the technical challenges or to create a version for internal reaction only.

In this MVP process, requirements and user interface design are still important (and essential). The difference is that it’s no longer the case of working with internal team members using long documents and multi-week processes. Development now gets front-loaded more quickly into the process -- which for architects and developers is a great thing given how eager they are to roll up their sleeves.

Getting to a minimal viable product means that you have to be practical and determined in taking the vision, focusing in on a market and specific use cases, reducing what’s possible to the essential features and flows. Approaches for distilling requirements are similar to approaches for time-management. There are many often opposing ways to organize to-do lists but that’s because they map to the different ways people work.

One back-of-the-napkin approach to reducing requirements is to take a data model view and prioritize and group the entities that you’ll be tracking. You’ll find they are probably 3-4 major data elements with others nesting around these. By mapping the flows and actions between these elements you should have the primary value of the application. Add in straightforward navigation, minimal visualization and design and you’ll have a rough outline of the first agile cycle. The other data elements will accommodate additional features and capabilities and take care of edge cases. But you’ll want to get to these only if and when you find out they’re in demand.


Ruby’s object support and GEM structure makes it easy to build and extend. Rails provides a great framework for structuring applications. AWS enforces a loosely coupled but solid approach to system architecture. This means you can create and adapt applications quickly.

Which means you can measure once and then you can start developing. And then based on market data from real use, you can develop again. Without protracted periods of measurement market research and requirement cycles. The application becomes the plan.

MVP + RoR + AWS couldn't make for a better combination. (Unless of course, there was a monkey.) **


** Great commercial and back story on the monkey. We recommend.