Having 4, 6, 12, or even more accounts with individual invoices, billing methods, support contracts, reserved instance pools, and everything else that comes along would be enough to drive anyone crazy. Luckily, AWS offers a great solution that is easy to set up and manage.
Considered to be best practices in AWS, as well as one of the most popular ways to fully maximize the potential of AWS, is to utilize multiple accounts. Accounts can be set up as either per-organization, per-department, or even per-application and can be utilized to logically and physically separate any resources to fit your organization’s needs. This, combined with master-account billing and properly utilizing Tags, can allow you to be as separate, yet collected, as you see fit.
Today we are going to share a few modern SharePoint features that can save you time and money by eliminating some frequently performed and repetitive tasks while utilizing the latest in modern architecture and design.
Learn about creating, employing, or utilizing a framework for your functional tests to drastically improve your testing that benefits of creating functional test framework and what that framework might look like.
As a relatively new architect-level hire at Mercury, I have spent a large amount of time exploring code bases that are new to me. In that exploration, I have come across a variety of source code peculiarities and problems related to issues with naming conventions. These are fairly rare situations and as such can take a while to diagnose and get to the true root problem. The issues I will describe below are specific to situations in Mercury’s development process, but might help to identify possible pitfalls in yours.
At the end of 2016 I embarked on a goal to develop an in-house framework for Mercury to use on our internal websites and web apps, as well as client projects. This blog post is geared toward front-end developers looking to make their own framework, and in this post, I’ll talk about approaches I took and lessons I learned during development of the Mercury UI Framework.
A lot of women in tech, including myself, don’t like to spend a lot of time talking about being a woman in tech. The topic is controversial, usually uncomfortable, and comes with a negative connotation similar to “oh boy, what is she complaining about now?” Fortunately when you’re like me and work with a company that doesn’t just employ women in IT but empowers them, you can feel confident to speak on an issue that still persists.
The rising demand for getting a Minimal Viable Product (MVP) to the market as quickly as possible has highlighted the criticality of Validated Learning within the Software Development Lifecycle (SDLC.) Throughout the remainder of this blog post, we’re going to apply 2 of the 5 principles in Eric Ries’ book “The Lean Startup”: (1) Validated Learning and (2) Build-Measure-Learn. Let’s consider our first scenario.
Learning how to improve our functional testing capabilities one step at a time
Learn how to create a simple component in the first in a series of posts about learning React.