AWS Modern Application Development E-Book

Amazon Web Services recently published an E-Book on modern application development. In short, this guide explains the significance of digital transformation and how it can reinvent how your business delivers value. The main topics covered include: Digital Innovators, Characteristics of Modern Applications, Data Management & Computing in Modern Applications, and Security & Compliance. Below, I have summarized a few takeaways from each topic.

Digital Innovators

To be a digital innovator, you must work backwards to understand that innovation starts with your customers and listening to their wants and needs. AWS calls this process the “innovation flywheel.” The innovation flywheel consists of three steps: listen, experiment, iterate. After putting your customers first, it is essential to put technology at the center of your business. Some ways to do this are through digital marketplaces (two sided market that connects buyers and sellers,) direct-to-customer engagement, digital products as services, and insight services.

Characteristics of Modern Applications

Modern application development is a powerful approach to designing, building, and managing software in the cloud. Characteristics of Modern Applications align with digital innovation (see above.) Modern Applications require a culture of ownership, which also starts with the customers. To create this culture, companies should hire builders and support them with a belief system and let them build. It is important to trust in others skill sets and know where your boundaries lie. In terms of the architectural patterns of modern applications, most are micro-services. Micro-services have minimal function services, are deployed separately but interact together, each has its own datastore, is organized around business capabilities, the state is externalized, and provides a choice of technology for each micro-service.

Data Management & Computing in Modern Applications

Data management refers to purpose built databases that serve as decoupled data stores. Data management includes computing in modern applications. Computing with micro-services effect the way you package and run code, and compute in modern applications such as AWS Lambda. Release pipelines in AWS are standardized and automated. This means that they are no longer manual, there is continuous integration and continuous delivery. Also, there is a server-less operational model. These models are ideal for high-growth companies that want to innovate quickly because they don’t require server management, they provide flexible scaling, you pay for the value you need, and they automate high availability.

Security & Compliance

Security configuration and automation are needed. To ensure security and compliance, these practices are incorporated within the tooling. Some of this tooling includes code repositories, build-management programs, and deployment tools. Security and compliance are also applied to the release pipeline itself and the software being released through the pipeline. Lastly, DevOps and DevSecOps safeguard security and compliance. AWS defines DevOps as, “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” Similarly, DevSecOps is described as “philosophy of integrating security practices within the DevOps process. DevSecOps involves creating a “Security as Code” culture with ongoing, flexible collaboration between release engineers and security teams.”

I hope that you found these summary useful. We will continue to try to summarize AWS content so that you don’t have to read it or navigate demo vids / webinars. Like what you read? Check out our blog post on why AWS is so cool: https://shout.setfive.com/2019/07/11/what-makes-the-aws-cloud-so-cool/.

QA: An afternoon with the Rainforest QA test builder

Even in 2019, software testing is still a challenge for a lot of small companies. Testing is usually not prioritized amongst small teams. Small teams frequently lack a dedicated QA resource, this causes writing good tests to be a unique skill in itself. Because of this, teams will end up with maturing software products that have few or no tests. As development continues, the downside is that there is an increased potential for bugs to enter the product. So, how can small teams tackle this challenge? As the software development industry has evolved, the industry has developed a wide array of quality assurance (QA) tools and techniques. Broadly, these tools can be categorized into two buckets – manual (human) testing and automated testing.

Manual / human testing is essentially exactly what it sounds like. A human QA engineer manually executes a list of steps, evaluates the results, and decides if the tested software is passing. Manual testing is relatively easy to start because non-technical resources can develop and execute the tests. However, as the test suite grows, teams run into issues because they’re limited by how many QA resources they have. This leads to teams only running tests before certain deployments, causing them to miss bugs.

In contrast to manual testing, automated testing is typically entirely code based. A QA engineer writes tests in a general purpose programming language. This asserts that the tested software is still working as anticipated. Since the tests are executed by a computer, this approach does not suffer from the limitation highlighted above. The trade off is that, because the tests are written in a programming language, technical resources are required to develop the tests.

So, what if there was a hybrid approach that combined some aspects of each approach? Well, that’s why you’re here! Say hello to RainforestQA.

What is RainforestQA?

RainforestQA is a SaaS product that incorporates manual and automated software testing approaches. RainforestQA offers a free trial, followed by a pay-as-you-go billing model, where you only pay for the resources being used. RainforestQA tests are executed by an automated system, or human testers, depending on how the test is constructed.

What does an automated RainforestQA test look like?

The tests are composed of a series of steps, which describe actions or assertions, that the automated system must take. The steps can include, “load this page” or “scroll the page down,” while the assertions are things like, “see a button” or “confirm text on the page.” When any one of these steps / assertions fail, the entire test fails, which indicates that something is broken in the software being tested.

What’s the process of building these automated tests?

Building automated tests on the Rainforest QA differs depending whether it is written in Plain English or Beta Language. When constructed in English, the user is constructed to write their own question and answer for each step. If the test is written in Beta Language, an action can be selected from the sidebar on the right, followed by a target, which is also listed on the same sidebar. The types of actions and targets can be adjusted depending on the test and what is being assessed.

When composing certain tests in Beta, you will find that the same sequence of steps are needed. Instead of writing out every individual step, over and over, the “custom actions” feature can be used. This feature enables a series of steps to be grouped together, which saves a lot of time and energy. I found the custom actions feature exceptionally useful when a login was required at the beginning of the test. However, a flaw in this feature can appear if the actual custom actions, itself, is being tested. The test results for a custom action will not appear unless the results page is reloaded. While this is a very small detail, it was a fairly substantial inconvenience for me. The rest results appeared as though the custom action test was in progress for over an hour, when in actuality, the test results were returned within a few minutes, they just did not appear until the page was refreshed.

How does the back-and-forth work between users and Rainforest QA engineers?

When running a test, everything is sent through a real and active test team of almost 60,000 testers. The test team provides clear feedback in a timely manner. If the test is passed, it will appear in green (as pictured above.) If the test is failed, it will come back in red. If the “Go To Test” button is selected, the test feedback can be viewed. Specific comments and critique are given on the particular step that caused the test to fail. Additionally, all of the tests and results are automatically recorded and stored in a neat and orderly fashion.


What is the Difference Between Testing Languages?

As discussed, on the Rainforest QA, tests can be written in “Plain English” or “Beta Language.” Writing tests in plain english is faster and easier, but also much more expensive. For a test to be passed in “Plain English,” the tests have to be written and constructed in a very specific way. For example, if you wanted to test the login page while leaving the username or password blank, you cannot use the “type” action to exemplify that you are leaving it empty. With the Beta Language tests, you have to select a specific action from the bar on the right, followed by a target. The only choices are what is already listed. In Beta, you have the option to use custom actions, you can also make new targets, but only by labeling a pre-existing type of target. When conducting a test in beta language, screenshots are used to identify what should be seen/clicked on each page. The downside being, if there are three of the same buttons on one page, you cannot type in directions, nor can you describe which of the three identical buttons needs to be selected.


Conclusion

I haven’t plugged Rainforest into our development workflow, so I cannot speak on the integrations or reporting. However, I would recommend the Rainforest QA to anyone- regardless of their technical ability- that wants to run automated tests on a timely and inexpensive budget. Building tests on this QA very quick and straightforward. While you may find a few complications and specificities on each language, it typically would not take more than one revision to fix the issue.

TL ; DR

Likes:

  • Interface is easy to use
  • Variety of features available to test
  • Access to a test team that provides feedback quickly
  • Non-technical users can build tests and test the UI without writing code
  • Free trial and then pay as you go pricing
  • Custom actions

Dislikes:

  • Tests written in Plain English language ask for specific answers on tests which allows a huge margin for error including spelling, spacing, and plurals
  • Have to be written and constructed in a very specific way to be passed and you can’t use any screenshots to clarify directions
  • Screenshot feature for capturing targets do not always capture / appear
  • Cannot specify instructions on Beta language

Interviewing in Tech: Advice from Three Experts

Interviewing, and getting hired, in the tech industry is exceptionally difficult. From multi day interviews, ridiculously difficult coding tests and recruiter third-party assessments, this process can take months. To provide more insight on this strenuous practice, I have interviewed three specialists in the industry who have experienced the technical interview first hand. The three interviewees are introduced below.

Moriah Maney
Twitter: @MoriahManey
Title: Front-End Software Engineer at Webflow


Brian Hurst
Twitter: @BrianCeltics1 @ConstantContact
Customer Engagement Specialist at Constant Contact


Georgie Cooke
Twitter: @Georgiecel
User Interface Engineer at Campaign Monitor


How long have you been working in tech? What is your role?

Moriah Maney: 5 years, 3 of the years were undergrad, two post-grad. I am a Software Engineer (Full-Stack Engineer) experience across all areas of tech applications but I focus on Frontend development, primarily using React, the Javascript framework. Middle level / tipping senior. 

Brian Hurst: Since 2016, my role has been in an aspect of technical customer support.

Georgie Cooke: I have been working in tech for about eight years now, having started while I was studying my Masters degree. I’m currently a User Interface Engineer at Campaign Monitor, a company that provides email marketing software for companies and individuals to communicate with their customers. I’ve maintained largely the same role over the course of my career.

What types of projects do you typically work on?

Moriah Maney: I work at Cisco Systems, I work on the Webex Team’s platform (chat and video service platform, similar to Zoom.) I am on the developer experience team, I specifically focus on Open Source software and the Webex Team’s Widgets.

Brian Hurst: My current role is at Constant Contact, I answer inbound customer calls relating to software and digital marketing. Additionally, I have contributed to social media, template design, and innovation. 

Georgie Cooke: I work on building user interfaces with HTML, CSS and JavaScript, but also improving code to make it more maintainable and scalable. The user interfaces I build can be complete pages of UI or entire websites. Right now at work I’m spending a lot of time on a design system with reusable and scalable components, which will make collaboration, maintenance, and the process of putting together UI a lot easier.

How familiar are you with the technical interview process? 

Moriah Maney: Super familiar, approximately 20-25 interviews. 

Brian Hurst: Fairly familiar, most of my interviews haven’t dabbled into the technical space requiring whiteboarding or an in-depth technical assessment (ie. coding)

Georgie Cooke: I am most familiar as the interviewee or person being interviewed. I have not been an interviewer in the technical interviewing process, but I am aware of the process Campaign Monitor goes through with potential hires.

What was your worst experience interviewing in Tech? 

Moriah Maney: I had an interviewer speak to me in an accusatory tone, not believing my knowledge of subject matter due to my age. I have also had challenging interview settings, like open office interviews, which were distracting and noisy.  Once, I was interrupted during a technical screening and told that my work was incorrect, which was extremely off-putting. I later found out that my work was correct.

Brian Hurst: I find it frustrating when companies do not follow up, or keep candidates in the loop about the status of their job opening.

Georgie Cooke: I struggled having to do a Hackerrank test, which is set up online like a timed quiz. It was to test my technical skills and I was given a very brief description of what to expect. The timer was visible on the screen while doing the test and I found it rather stressful, especially because a lot of the test content was not what I expected from the description. I struggled and felt very unconfident because some of the questions were beyond my skill level.

Additionally, I applied for a job through a recruiter. This position did not work out. After moving on, and finding a job on my own, I was still receiving calls and hassled by the recruiter with questions about my new role, and the recruiter still offered me new roles, which I found inappropriate.

What was your best experience interviewing in Tech? 

Moriah Maney: Technical assessment was collaborative with their team, was asked to do an implementation, a current engineer provided a code review, then was asked to make the adjustments accordingly

Brian Hurst: Interview at Constant Contact, efficient process, got to meet the team before accepting the offer. Also, was able to observe the role in real time that I was interviewing for. 

Georgie Cooke: My best experience was with the company I currently work for. I was made to feel very welcome when I arrived on-site, and prior to that, the communication between myself and the company’s recruiter was fantastic. On-site for the interview, I was offered a cup of tea or coffee and this made me feel comfortable. I was shown around the office a bit as well, everyone I encountered was friendly, and this really eased my nerves.

After the interview, I was kept up to date on how things were going with the process, including the fact that other candidates were being interviewed. I did not feel like I was left in the dark.

What advice would you give for people preparing for this process?

Moriah Maney: Easy to get discouraged, go in with low expectations and that it is okay to fail and it is okay to not know how to do something and tell your interviewer that. Do not take the rejection personally. 

Brian Hurst: Try to provide a few different statements and examples of work in advance, so that you can demonstrate your skill set and experience. Also, use specific language in your descriptions to paint a more detailed picture of yourself as a candidate. 

Georgie Cooke: Make sure you do your research on the company you are interviewing for, and don’t be afraid to ask questions. You want to make sure the role is right for you, so ask anything about the role or the company that you are not sure about, because they might help you make a better decision.

I would also suggest going over your best skills and make sure you are able to talk about them verbally or talk about yourself with confidence. While actual coding tests can be difficult, being able to talk about your skills and the work you do can leave a good impression, as the interview is not always solely about the test.

If you could do one thing to change this process what would it be?

Moriah Maney: I would take out whiteboarding because no one does their best work in that position and it does not depict how you would work from day to day in that environment. I would also make tech more accessible, provide more/multiple options, especially for people who are on the job search while employed full-time.

A technical assessment often requires multiple hours of work which applicants do not always have. Instead, assign a paired partner challenge with a current engineer, where you solve problems together, or each solve half. By increasing flexibility and options in a technical interview process, your company is facilitating applicants in showcasing their best work.

Brian Hurst: I think that the interview itself should be more two-sided, so the applicant asks questions as well. Essentially, it would be more of a conversation where both parties exchange back and forth.

Georgie Cooke: It is very important for companies to give feedback and let candidates know if the answer is “no,” and what they can do to improve, or where they missed the mark. It can feel awful to be left hanging. I understand companies go through many, many candidates, but a quick email or phone call would go a long way.

Providing feedback can help the individual improve for future interviews, possibly even re-apply for the same role in the future.

Have tips on how to improve the technical interview process? Comment below or checkout our suggestions here: https://www.forbes.com/sites/theyec/2019/07/26/how-effective-is-your-technical-interview/#74ff59e6b0c0.

Design: How to Make a Vintage Website

Remember what websites looked like before they became so interactive and graphic savvy? The World Wide Web- in the early 2000s- was not aesthetically pleasing. So, we decided to recreate it. Out with the new, in with the old.

Below, we have provided an example of a modern-looking website. Specifically, we used a Bootstrap template. Then, we have listed the changes we made to the current website code. We discovered that the key to making an old-looking website is not using specific technologies, but using the styles and the aesthetics that your site embraces. Let’s take a Bootstrap template, Clean Blog – Bootstrap Blog Theme, and how we retrofitted it!

The current, modern version looks like:

To make it “look old” I made the following changes:

  • Removed all of the JavaScript
  • Dropped the custom fonts, went back to a fixed width Sans-Serif font (Courier New) and dropped the line-height
  • Switched the background image to something low quality and repeating
  • Filled all the whitespace by setting the content to 100% width
  • Add some obnoxious color – see links and menu items. 
  • Toss in a gradient for good measure

The final Product:

Some other options for replicating an early 21st century website include: the venerable marquee HTML tag, animated GIFs, and of course, anything neon.

Of course there is always the all time GOAT retro website, the original 1996 Space Jam website, which is still up!

Have additional suggestions for how to make an old-looking website, or any formatting requests you’d like to see? Let us know in the comments below!

What Makes the AWS Cloud so Cool!?

We watched an AWS Cloud webinar, so, you don’t have to. (But if you want to, it’s attached below.) Here are are three aspects of the AWS cloud that make it both unique and useful, particularly for ISVs (Independent Software Vendors.)

  • Architectural Design helps ISV’s customers focus on which services are being used, understand how scalability is managed, and preview how an application looks in the cloud. The priority of the architectural design is to ensure:
    • High performance / ability 
    • Dynamic scalability 
    • Adherence to AWS best practices
    • Flexibility to automate app deployment – using CloudFormation templates, AWS Marketplace, and more
  • Security & Compliances allow ISV’s to provide their customers with risk assessment and mitigation methodologies to strengthen their security posture on AWS. These features supply customers with the documentation to explore how application deployment in AWS meets requirements and reduces a barrier to entry.
    • Architectural security strategy
    • Frameworks for compliance 
    • Policy and controls mapping
  • Cost Optimization assists ISV’s in offering more cost-effective services to their customers. This aspect persuades customers to adopt more solutions by ensuring that software properly utilizes AWS. With increased elasticity, and a minimized resource consumption, customers are facilitated in making decisions to move forward with an application.
    • Minimizes idle resources
    • Properly right-sizing infrastructure 
    • Helps avoid common architecture pitfalls