Automated testing can radically increase the reliability of custom-developed applications and make it easier to add new features and components. The Protractor capability in Google’s AngularJS is a great way to put automated testing into practice.
By Emory Merryman
Protractor is an automated testing engine for AngularJS, the Google developed framework for building enhanced HTML-based applications. Protractor simulates user interactions and will help you verify the health of your Angular applications. Using Protractor, you can radically expand the type and variety of automated interactive tests that you can perform, which makes your applications more reliable and reduces the amount of manual testing you have to perform.
We’ve been using Protractor for some our most demanding clients with great results. My purpose today is to explain how you can use automated testing to protect against regression in your applications as you add more features and underlying complexity. Future posts will delve into the specific uses and advantages of Protractor.
By Rick Garvin
The pace of business change is not predictable. Technology systems and products must evolve rapidly enough to meet business demands and take advantage of opportunities. The symptoms of technology failures can manifest themselves throughout your organization, but all point to just a few root causes. Ten Mile Square calls the exercise of matching technology problems with their cause — Technology Pathology.
Here is the best way to think about your company’s Technology Pathologies:
- Symptoms are what you see
Technology problems do not stand alone. Chronic problems meeting expectations are caused by underlying technology and business process breakdowns. Treating the symptoms without addressing the fundamental causes makes the symptom go away, for a while. They’ll be back.
Business executives often view software developers as the strange, but necessary, creatures that create the code that makes the business run well – or not. It’s true that the average developer’s personality is radically different from that of a top salesman. There’s one thing they have in common; The need for feedback. Continuous, constructive feedback can make the difference between an application that delivers great business value and one that everyone hates.
By Jay Gelman
As software developers, we’ve all been there. After months of hard work, our system is almost ready for release. We’ve been developing APIs and front-ends, and writing tests. We’ve been load testing and performing security audits. And now that we are almost ready for release, our stakeholders are actually paying proper attention to what we are doing, providing the level of business focus that we’ve been asking for since the project started.
Unfortunately, our stakeholders have realized that what they actually want is not what the system does. There are fundamental changes that need to be made. We can either try to add a series of kludges that will work in most but not all cases, or we can do some serious refactoring. The refactoring option will push out the schedule, blow the project budget, and cause the business to delay key initiatives that were promised to the market and shareholders. Either way, someone is not going to be happy. If only our stakeholders had provided more up front input and applied more business focus over the course of the project, we wouldn’t be in this mess.
Entrepreneurs have huge upsides and equally huge downsides. As an entrepreneur, if you know what you’re likely to do wrong upfront, you are more likely to succeed and grow your business faster and more profitably than you had ever imagined.
By Peter S Buchanan
It’s an age-old and true maxim that great entrepreneurs usually don’t make it to the executive suite at IBM, GE, HP, or Exxon. Big companies love the upside – the passion, the long hours, the breakthrough thinking, the ability to inspire others, and the knack for getting lots done with few resources. For big companies, however, each element of upside comes with an equal element of downside. Most entrepreneurs in corporate clothing don’t do well with complex sales models, product review boards, rigorous budgeting of finite funds, and managing trade-offs between products. Entrepreneurs are all about the new and never been done – in particular, new markets, products, technologies, and customers. Therefore, talented executives leave the world’s great corporations and bravely take on the quest of creating the next Microsoft, Google, Cisco, or Sun.
The odds are not in their favor. Only one in ten new companies seeking capital actually gets funded, and, of those ten, only one or two will pay off handsomely for investors and employees. Running and growing a young company doing new and wondrous things is a hazardous exercise. Only people who bring lots of nerve, passion, leadership skills, and a love of extreme risk should really attempt it.
By Frank Oelschlager
Recently, I did some work with a SaaS company in Silicon Valley. Besides observing that they embodied the full stereotype of a silicon valley tech company– open space plan, game consoles, walking desks, fully stocked pantry, open wet bar, ultra-casual dress code, etc., I found a company that wasn’t “doing” agile.
They were living it. Being agile was as much a part of their culture as breathing is a part of living. Somehow, while ignoring most of the stuff one reads about how to do agile the correct and strictly adherent way, they manage to embody each and every part of the Manifesto for Agile Software Development.
By Rob Giseburt
This is the third part of a series about using SSH with bastion hosts. You may wish to read the other parts if you haven’t already:
SSH Connection Multiplexing
If you might be opening multiple connections through the bastion host, either to a single machine or to multiple machines, it’s possible to use “connection multiplexing” to share the same connection to the bastion host as a transport to many ssh connections. This saves both resources and time establishing new connections. For a more in-depth discussion of connection multiplexing, look here.
By Rob Giseburt
This is the second part of a series about using SSH with bastion hosts. You may wish to read the first part for background about using SSH bastion hosts:
Dynamically loading the bastion server address from AWS
Credit to my colleague Jason Mao for devising this technique.
Here we will describe how to load the bastion server’s address from AWS, using AWS tags and the shell environment’s AWS authentication information. This could easily be extended or modified to use any other means of dynamically loading the hostname during the connection.