Creating Development Standards in the Enterprise

As a member of the Sencha Professional Services team, I spend most of my time directly interacting with our larger enterprise customers. Our team offers a wide variety of expert services, and in many cases, we spend weeks working side-by-side with a group of developers helping them to create, build and deploy incredible applications using Sencha products.

I recently had an opportunity to work with one of our enterprise clients, helping them define how Sencha should be used within their organization. I wanted to share some lessons and high-level concepts about enterprise architecture with the community that I think will benefit everyone.

Sencha Complete

Working with the Enterprise

Working at the enterprise-level can be both very cool and very frustrating. On the one hand, I get to build really challenging apps; but on the other hand, enterprise applications often target legacy browsers and are prohibited from using cutting-edge technologies.

Having said that, I am starting to see many of our enterprise customers rethinking their development strategies and IT infrastructures: workstations are being upgraded to modern versions of Windows, and workers are being given more choices for a web browser. In some cases support for IE6 and IE7 are being dropped completely!

More importantly, I am noticing that enterprises are standardizing their development platforms to create an ecosystem of applications that can be maintained by a diverse team of developers. Because Sencha tools and frameworks are becoming the preferred development platform in this ecosystem, the Professional Services team has been helping our customers define their internal policies, training procedures and best practices in order to facilitate a transition to this new standard.

Why Development Standards Matter

Why Development Standards Matter

As a consultant, I constantly preach the benefits of having maintainable code:

  • Applications are faster to produce
  • Applications are easier to debug
  • New features are easier to add
  • Code has fewer bugs
  • New developers can be trained quickly

We all know that time equals money, so applications that take less time to create and maintain cost less money. Ultimately this makes managers, executives and shareholders happy. Because enterprise companies have many applications in production (both internal and external), it is critical that each member of the development team be able to jump onto any project in order to deliver on time and stay under budget.

Enterprise development teams often employ many developers distributed across large areas and contain a wide variety of skill sets. By standardizing the training, tools and best practices enterprises hope to decrease development time and costs while increasing the quality and lifespan of their applications.

Sencha as a Standard Platform

Sencha as a Standard Platform

When enterprises decide to make Sencha tools and frameworks a standard for application development, they’re often communicating a need for consistency across their internal and external applications. This consistency usually includes both the UI (styling, widgets, functionality) and the underlying code (architecture, libraries, best practices).

Every company using Sencha tools and frameworks should consider creating a centralized repository of resources and best practices for their development teams. While the specifics of these resources might differ between companies, the following areas should be clearly documented to help developers get started and maintain consistency across projects.

Developer Onboarding and Training

In my experience working in an enterprise, it can be difficult to get the tools you need installed on your machine.

Most enterprise companies have a highly defined IT infrastructure, so new developers are forced to wait while all required hardware and software meets approval. This process can often take days to complete, and afterwards workers remain unsure how to request additional resources. In short, new developers lack access to a clear onboarding roadmap.

For Sencha customers, I recommend that a handful of onboarding procedures be clearly documented to lubricate this process:

  • Required development tools
  • The process for requesting network credentials
  • Standard development workflows
  • How to access the Sencha forums and support portal
  • What Sencha training opportunities are recommended/offered

It’s important to remember that while developers don’t need this information on a frequent basis they need to know how to access it.

Supported Platforms

Supported Platforms

One benefit of working in an enterprise is that developers usually know the exact specifications of the environments they need to support, but historically these environments have been troublesome for web applications.

As enterprises move forward with hardware and software upgrades, it is important that developers deliberately document their current list of supported environments. This list might include things like:

  • Browsers (e.g. IE8, Firefox)
  • Operating Systems (e.g. Windows XP,7)
  • Devices (e.g. Lenovo ThinkPad)

Having this knowledge clearly defined before starting new projects (and while maintaining legacy applications) helps to improve the accuracy of the delivered products. It also allows developers time to request any new hardware/software for testing.

In some cases support for IE6 and IE7 are being dropped completely!

On the other hand, this knowledge also helps to point out potential weaknesses. For example, the latest Firefox versions will auto-update themselves and support a wide variety of modern web standards; IE8 does not. Developers who understand those implications can avoid development practices that might collide with the defined supported platforms.

It is also important to document the specific products or platforms being used in the development process. This list might include:

  • Frameworks (e.g. Ext JS 4.1.x, ASP.NET MVC 4)
  • 3rd party libraries or components (e.g. other charting packages)
  • Supporting technologies (e.g. SASS)
  • Workarounds (e.g. using JSONP)

This supplementary list is not only helpful in defining what products or platforms are required for development, but it can also define the skill sets necessary for employee acquisition and training.

Internal Best Practices

Development teams should also decide on a list of best practices, so all developers can contribute code without compromising maintainability.

The list of best practices can be short and high-level or long and detailed; the choice often depends on the size of your team and how the developer roles are organized.

For example, some high-level best practices might include:

  • Overall architectural decisions (e.g. namespacing, file structure)
  • Security implementations
  • Error handling
  • Shared libraries and custom components (UX)
  • Documentation
  • Testing, builds and deployment

…while some low-level best practices might include:

  • Whitespace usage
  • Commit practices
  • Console usage
  • Browser Strict vs quirks mode

In my experience, enforcing the low-level best practices is difficult to do without mandatory code reviews. While code reviews are a fantastic way to teach junior developers, maintain code quality and stimulate creativity, it’s not something typically done in most enterprises.

What are your thoughts?

This article highlights some ideas for implementing development standards in large organizations but is far from a comprehensive plan. The Sencha Professional Services team provides a variety of services including high-level architectural reviews, deep analysis of application performance, custom UX development and everything in-between, and we can tailor an engagement to fit each customer’s specific needs. The concepts above are a good start and should translate easily into any business.

If your company has implemented a set of development standards, please share your thoughts and experiences!

20130317-development-enterprise.png No Comments   Read more

Previewing Our New Cloud Services:

Previewing Our New Cloud Services: Earlier today at the Sourc{ conference in Split, Croatia we previewed two new cloud services from Sencha. To distinguish them from our SDK’s and tools we’re calling them “” services. The goal of services is to provide common application functionality as cloud services so that application developers (particularly mobile application developers) don’t have to reinvent the wheel every time they want to make an app. Our first two cloud services solve two common problems for app developers – resizing images for different mobile screen size/resolution combos, and making offline and collaborative data synchronization easy.

h3. Src

A diagram illustrating how Src distributes optimized images to mobile devices of any screen size.The first service we introduced was Src, which helps mobile apps resize images for the ever increasing number of mobile screen sizes. We’ve previously done a lot of work in Sencha Touch to make your UI resolution independent, io Src expands this to include your image assets. And it’s easy to use, simply add in front of your IMG tags and Src will automatically scale the image appropriately from the origin to the right size for that mobile browser. The benefits of using SRC is that the browser doesn’t have to resize a one-size-fits-all image inplace (which helps performance), or download more image than it needs (which improves latency).

Not only does Src perform automatic manipulation based on the device’s screen size, but it also has a complete API to let you customize how to scale your image, ranging from simple scales and skews to using it within data URIs. To ensure the best performance in a mobile scenario, original and resized images are cached by Src for 24 hours and the correct caching headers are sent to the mobile browser. If you’re familiar with tinySrc, Src is built on the same codebase and technology as tinySrc, which already serves millions of requests a month helping hundreds of mobile sites deliver a better experience.

Best of all, we’re excited to announce that it’s available today and at no cost for any reasonable usage. We’ll be bringing premium features to Src in the future, but rest assured that the basic service will be free forever.

If you’d like to check out Src in action, head over to Teagrams and see how the Teagrams app uses Src to dynamically resize images from Instagram. You can take a look at the source on Github as well. Teagrams is best viewed on a tablet. We’ll be be making the full documents available later this week.

h3. Sync

A diagram illustrating how Sync handles data input and output for your users on your web application. We also previewed Sync, our multi-master synchronization service that allows Sencha Touch apps to take their data offline and sync their models. We decided to start work on Sync after hearing from developers (and from our own experiences!) how unreliable mobile networks can be. Since Sencha Touch and the entire Ext JS platform is moving to a MVC pattern we realized how well built the “M” in our architecture was suited to enable apps to go offline and sync as well as to collaborate on a shared data set.

Using Sync, apps can operate offline, ensuring that all writes made to the local storage are replicated to the cloud master; apps can use Sync to backup data so the cloud has a replica of everything that’s in the client, and to recover data if the mobile data set gets lost. Better still, since Sync is multi-master, if an app expects a user to be on multiple devices, the data set can be edited and synced seamlessly between devices; or, if the app is multi-user, the same data set can be edited by multiple users from their own mobile devices.

Essentially, Sync provides the app with a distributed object store. A complete replica of the entire object store is available to each client, and each replica can receive updates and exchange updates with its peers through Sync. Think of it as peer-to-peer Sync in the cloud. If you’re interested in seeing some demos, open two browsers (e.g. Safari and Chrome) and open a tab in each for either Contacts and Crosswords. In Contacts, you can edit the data of the address book, replicate it to Sync, then hit the circle arrow in the other browser and the changes propagate. In Crosswords, each change is replicated and automatically synched between each client allowing multi-player gameplay. Sync is an state-based object replication (SOR) mechanism. There are many other flavors of replication and synchronization, but we think SOR is the most widely useful and applicable synchronization scheme that can work with a wide variety of apps. Unlike log or diff based replication, SOR can lose intermediate updates without corruption – which is handy when you’re on a semi-connected network. It’s also a more general purpose synchronization scheme than niche-ier approaches like Operational Transformation, which is most useful when doing synchronization within a list-object – for example Google Wave-style live collaborative editing.

We’re in the early stages of Sync and it’ll evolve as we work to get customer feedback. As of today Sync is in limited preview and we’re opening invitations for people who are interested. For more information and to sign up, please visit the page.

h3. Road Map

We’re excited in the coming months to share more about this new set of cloud services from Sencha. Src is available today and over the next few months we hope to expand the feature set and build out premium features that continue the mission of helping developers manage the complexity of mobile devices and enhance the speed of mobile delivery. Sync is in limited preview and we hope to role out a larger beta in the later summer.

Lastly, since this is a developer preview, please understand that everything might change. We want to make sure we’re sharing where we’re going with our community early and often so we can incorporate feedback properly. We look forward to seeing how you use the cloud services! Request an invitation today!

20110504-sencha-io-thumb.png 53 Comments   Read more