Architecture - Design

Why is naming things so difficult? Look in any reasonably sized code base, and you’ll see—in abundance!— crimes against naming. The Spring framework has a class AbstractSingletonProxyFactoryBean—and there are many worse examples. We in the computer industry tend to name things by what they do, rather than why they do it, and thus rob ourselves of the opportunity to tell an interesting and intriguing story. Andy Palmer says it hasn’t always been this way. In the early days of computing, names were rich with metaphor. Names, that today are synonymous with the concepts, were once compelling and novel stories. Terms such as Desktop, File, and Folder all had analogues in the physical world, and this helped people come to grips with the new concepts. Andy gives some examples of metaphors from the early days of computing, discusses some more modern examples, gives reasons why we might choose to program in this way, and suggests some ways in which we can improve our ability to tell a story through our code.

We all talk about conflict. We all experience it. But do we really understand what causes it and how we deal with it? Do we have any idea what to do about it? Much research and study has been done, but that doesn't help when you're in the middle of conflict. You don't have time to pull out the reference book or go to a website. You need simple, clear understanding. Learn the categories of conflict and how to recognize them, which means having an understanding of what generates them. Learn the different strategies of dealing with conflict, recognize your own preferred strategies, and understand where you may choose to change your strategy. Discover specific tools you can use in any situation to comfortably and confidently deal with conflict. Doc List introduces some ideas to enhance your learning after you leave the session, so you can continue to expand your love affair with conflict.

In our personal and business lives, many of us know leaders who foster environments of incredible creativity, innovation, and ideas—while other leaders fail. So, how do the top leaders get it right? Going beyond the basics, Pollyanna Pixton explores with you the ways that the best leaders create “safety nets” that allow people to discover and try new possibilities, help people fail early, and correct faster. Removing fear and engendering trust make the team and organization more creative and productive as they spend less energy protecting themselves and the status quo. Pollyanna shares the tools you, as a leader, need to develop open environments based on trust—the first step in collaboration across the enterprise. Learn to step forward and do the right thing without breaking trust. Find out what to do to foster trust through team measurements, protect team boundaries, build team confidence without taking away their ownership, create transparency, and what to do when there is broken trust in the team.

Mobile applications are now a required component of enterprise operations, with both consumers and workers relying on mobile technologies for communications and productivity. To ensure a functional, secure, and worthwhile mobile experience, enterprises must stay abreast of growing complexity in mobile devices, applications, and platforms while remaining responsive to unforgiving user expectations for speed and service. To meet this challenge, many firms are turning to cloud-based automated testing, which reduces the complexity and cost of manual, on-premise testing and offers extraordinary flexibility to accommodate a variety of scenarios. Joe Schulz outlines the reasons why cloud-based application testing is beneficial, discusses the role it plays in supporting testing automation, and explores the best practices for adopting this solution. Get a practical grounding in cloud-based automated mobile testing. Learn how this approach helps companies speed time to market, optimize security and performance, increase user satisfaction, and contain costs.

The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the long run. How can we know the right balance of upfront design work and emerging design approaches? Al Shalloway shows how to use design patterns—coupled with agile’s attitude of don’t build what you don’t need—to guide your design efforts. The trick is to identify potential design alternatives, analyze how each may affect the system in the future, and then find the simplest approach for isolating those potential effects. Al describes the essence of emergent design—start with a simple design and let it evolve as the requirements evolve—and demonstrates how to refactor to achieve better designs, which really is quite different from refactoring bad code.