Scott's Spot 5 - Tech Review - Mid-1012 uni-body MacBook pro

Scott's Spot 5 - Tech Review - Mid-1012 uni-body MacBook pro

Date: 5/18/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, we discussed the various types of performance testing, how they are different, and some of the benefits that come from running a successful performance test.

Summary of this episode

• You are in for a treat today…. I’m going to review the MacBook Pro that I bought off of Groupon. I’m going to talk about the reason why I chose this exact model, what it came with, and the upgrades that I had planned for it when I bought it.

What’s in it for you?

• After listening to this episode, you will have a better understanding of this model of MacBook Pro so that you can determine if it is a project that you would want to undertake for yourself.

Episode Content

• I have been watching a lot of youTube videos on several channels where the host buys and upgrades a mac (of some make or model).

  • It seemed like it was not that bad of a project to undertake if you had a little bit of handiness and chose the right model.

  • After watching what felt like 200-300 videos, I found on Groupon the model that I finally bought.

  • It was a mid-2012 uni-body MacBook Pro 13” model.

  • Besides the fact that the company that was fulfilling the order took forever to send me the laptop, it is a pretty good little machine.

  • I had a Dell before that and it was just too big to get in my backpack to take on trips.

  • I was looking for smaller laptop that I could take with me on trips so that I could record podcasts episodes from remote locations.

• I unboxed the laptop and what was supposed to be a refurbished grade-A actually had a couple of tiny dents in the cover.

  • So I crank it up and it boots with no problem.

  • It took about 5 minutes to get to a login prompt.

  • Some of the specs that this thing came with: 4 GB RAM, core I5 processor, 500 GB 5400 RPM drive.

  • That is so not what I was hoping for.

• Now comes the upgrades that I had planned.

  • So trash the RAM and upgrade to 16 GB.

  • Swap out the hard drive for an SSD.

  • I would love to swap out the processor but the board that came with it would not support a newer processor.

• So back to YouTube to watch a couple dozen more videos on the best way to upgrade the macBook and I’m finally ready.

  • I pop it open and the ram upgrade goes pretty darn easily.

  • I then pulled the hard drive out and started to swap it for the SSD…….tada…...I don’t have the correct screwdriver to remove the posts that hold it in place.

  • So off to Amazon to order a complete set of micro tools which takes a week to arrive.

  • Then I try it again. Boom. I take the SSD where I had already copied the drive contents to and it popped right in.

  • Go figure. If you have the right tools, and follow the instructions, things just work.

• So now I get the hardware straightened out and what do I find…..this sucker boots up in under 45 seconds.

  • From 5 minutes to 45 seconds. I like that improvement.

  • I tested it with a bunch of the core apps and it was pretty snappy.

  • Not stellar but not bad.

  • I ran the performance metrics and guess what I found out.

  • My expectations are pretty low apparently.

  • The benchmarks on this thing are really low.

  • But you know what….I’m not using it for gaming...I’m not a gamer….and I’m not doing 4K video editing on it….so for what I need it is what I’ll call sufficient.

• If you choose to do this type of project yourself, you will need the following:

  • uni-body MacBook Pro (a model that is upgradable, check before you buy it)

  • A SCSI SSD transfer cable

  • A SSD drive

  • New memory cards (check the model you want to see what the main board memory capacity is)

  • A toolkit with specific screwdrivers.

• This project only works because of the model of MacBook Pro that I selected. So buyer beware!

  • The mid-2012 uni-body MacBook Pro is the last model that is upgradable by the buyer.

  • All of the newer models have chipsets and memory that is soldered to the mainboard.

  • So…..you have to send your laptop to Apple to have it upgraded (for a cost).

Recap of this episode

Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!

Next Episode: <next_episode_description_here>

Where you can find us!

Direct Messages:

• @cs_everhart on Twitter

• ScottTalksTech group on Facebook

• ScottTalksTech.slack.com

Links to Podcast Providers:

• On Google Podcasts

• On Apple Podcasts

• On Spotify

• On iHeartRadio

• Pandora coming soon

• PodcastAddict – web link not available but podcast is available in the app

• On PodChaser

• On Deezer

• On ListenNotes

• On OverCast

• On CastBox

21 – Making it in the real world - Performance Testing

Date: 5/11/2020

Guests: None

Welcome and greetings

Recap of last episode

• In our last episode, I discussed the concepts relating to System Integration Testing. I talked about what it is, how it differs from other testing, and what you hope to gain from performing it.

Summary of this episode

• In this episode, I’m going to discuss what performance testing is and the benefits that you receive once it is completed successfully. I will also talk about the different types of performance testing and how they each tell a different story about the health and reliability of your application.

What’s in it for you?

• After listening to this episode, you will be able to discuss the various types of performance testing and the benefits of each one. You will hopefully be able to have conversations with your peers that show the value that can be realized by a successful performance test.

Episode Content

Performance testing goes by a variety of names but in all instances you are trying to determine how your application will perform under real world conditions. Nobody wants to deploy their application to their production environment only to realize too late that their web servers do not have the capacity to handle all the users that are trying to use it for some purpose. This is especially true for companies that run websites that sell products or perform banking activities.

Types of Performance Testing:

• Load Testing: How the system performs under a defined load

• Stress Testing: How the system performs when the load is increased

• Spike testing: How the system performs when the load is dramatically increased for a short duration

• Endurance testing: How the system performs when the load is maintained for longer than expected

• Scalability Testing: How the system performs when it is dynamically scaled by a pre-determined factor for transaction volume (2:1, 3:1, etc.)

• Volume testing: Another name for Load Testing that involves large sets of data.

Here are some of the activities that take place when you are planning a performance test:

• Determine test environment requirements

  • This can include servers, operating systems, the application to be tested, other applications needed to run the test, and any configurations needed to ensure the successful completion of the performance test

• Design performance testing requirements

  • what is an acceptable response time for the application under test for a given transaction type?

  • what is an acceptable level of uptime for the application and what tests will ensure that that level has an acceptable chance of being reached?

• Design the tests that will be executed

  • identify specific use cases that are in the high volume category

  • this can be accomplished by working with the development team to identify candidate use cases.

• Buy, install, configure the testing environment

  • this will include ensuring that the software required to execute the test is available, licensed, and configured prior to executing the test.

• Write you performance testing scripts per the agreed upon design

  • This can be complicated with web applications that generate lots of dynamic content.

  • The dynamic content will need to be parameterized in the scripts so that run-time errors are not encountered during the test if a non-parameterized value is encountered

• Execute the tests according to the plan

  • The performance tests are run as agreed upon.

  • Support staff should be scheduled prior to the test to ensure that any issues can be addressed in a timely manner.

  • The time it takes for a test to get to the steady state of a particular transaction volume is called the ramp up time and should be built into the testing timeframe.

  • The time it takes for all transactions to finish after the agreed upon transaction volume is reached is called the ramp down time and while not needed for most performance metrics that you will compile, it can help clean up a system if you are planning on running several performance tests consecutively.

• Accumulate, document and publish the test results

  • all results should be collated and analyzed in order to provide the most accurate recommendation possible after a test is complete.

  • The results can either clear an application for release or send it back to the software engineering team for changes to improve its performance.

Recap of this episode

• In this episode, we discussed the various types of performance testing, how they are different, and some of the benefits that come from running a successful performance test.

Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!

Next Episode: Scott’s Spot Product Review

Where you can find us!

Direct Messages:

• @cs_everhart on Twitter

• ScottTalksTech group on Facebook

• ScottTalksTech.slack.com

Links to Podcast Providers:

• On Google Podcasts

• On Apple Podcasts

• On Spotify

• On iHeartRadio

• Pandora coming soon

• PodcastAddict – web link not available but podcast is available in the app

• On PodChaser

• On Deezer

• On ListenNotes

• On OverCast

• On CastBox

20 - How do you get along with your neighbors? System Integration Testing

Episode #20 - How do you get along with your Neighbors - System Integration Testing

Date: 5/4/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode we discussed what Component Integration Testing is and how it is used….along with a funny analogy using Jack and Jill and some water.

Summary of this episode

• In this episode I provide an overview of System Integration Testing (SIT) and how it differs from other forms of testing. I provide examples of what it means and how you should think about approaching it.

What’s in it for you?

• At the end of this episode, you will be able to discuss what SIT is and how it differs from other forms of testing by using real world examples.

Episode Content

• AKA – SIT, System Testing, End-to-end testing

• It is the process of testing a system's components and how they interact.
  • Unlike CIT, where all the tests are performed functionally as it relates to 2 different software components in the same application, SIT is performed on 2 or more applications in the same System (hence the handy moniker of SIT).
• It allows you to verify how the different modules or applications interact with each other and any problems with interfaces between them.
• For example – you have a website – it has distinct and different applications for the following items: search, item class, inventory data, shopping cart, checkout, shipping, billing, order authorization (credit card auth), and the list goes on.
• SIT is designed to enhance lower level testing from Unit Testing, Component Testing, Component Integration Testing, etc.
• It lets you find system level defects before the application is deployed to production
• It is performed against a production like system. usually a percentage size of production.
  • In the past, hardware and processing power were not cheap. Scaled down version of the application was considered a good compromise to allow full end to end testing of the entire system.
  • This still caused issues because you could not test every scenario for a variety of reasons….but you could get close.
    • Different hardware specs
    • limit on the amount of traffic that you could pump through the system
    • limit on data available for testing
  • Today this is not as much of a problem if you have a full cloud model for your software environments or a hybrid cloud model with on-premisis and cloud environments. Both of these solutions help control some of the costs related to SIT.
• In the past, most of the SIT was performed manually by hundreds of testers at large organizations. Today, devops and automation help run the tests faster in an on-demand fashion...look for these topics in the future.

Recap of this episode

• In this episode, I described what SIT is and how it has been designed and run in the past. I also talked briefly about how automation is helping test faster now and in the future.

Next Episode: OMG - Your Application has Stage Fright - Performance Testing

Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!

Where you can find us!

Direct Messages:

• @cs_everhart on Twitter
• ScottTalksTech group on Facebook
• ScottTalksTech.slack.com

Links to Podcast Providers:

• On Google Podcasts
• On Apple Podcasts
• On Spotify
• On iHeartRadio
• Pandora coming soon
• PodcastAddict – web link not available but podcast is available in the app
• On PodChaser
• On Deezer
• On ListenNotes
• On OverCast
• On CastBox