When I first joined Wix as a Software Engineer, I heard about the book Growing Object Oriented Software guided by Tests by Steve Freeman and Nat Pryce (which is referred to as the GOOS cause it’s official name is oh-so-long). In this series of posts, I will be summarizing the main chapters of the book.
Basically the book is about TDD (Test Driven Development). Everyone who’s read the book says it’s a must-read, and I know that when I read such technical books I enjoy them but I can’t remember the bottom lines cause these books are just so so…
If you still haven’t read chapter 4, I recommend going back :)
Before you start writing code for a new feature, start by writing an acceptance test. It should:
Separate tests that measure progress from those that catch regressions.
If you haven’t read the previous chapter, go back to chapter 3!
“We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” — Frank Tibolt
You should have a system that enables you to build, deploy and test before you start writing any code!
So you’re gonna test a walking skeleton.
Step 1: Work out how to build, deploy, and test a “walking skeleton”. You need a general clue about the major system components needed to support the first planned release. You…
If you haven’t read chapter 2’s TLDR yet, I recommend going back to it now :)
Good news, I summed up chapter 3 into 1 term you need to know:
A test fixture is a fixed state that exists at the start of a test. It ensures that a test is repeatable — every time a test is run it starts in the same state so it should produce the same results. A fixture may be set up before the test runs and torn down after it has finished. The fixture for a test is managed by the class that…
If you haven’t read chapter 1’s TLDR, I recommend starting here.
Ok, I know you can’t wait to get the gist of chapter 2 so let’s drill right in, with defining what’s an object oriented system.
An object oriented system: A web of collaborating objects.
The communication between the objects can be seen through tests. Don’t try to model your system…
Hi Pablo, sorry for missing your message for so long! that repo readme looks good, I haven't used it so it's hard to tell, but I would look into that autoscaler closely to make sure it can handle cases such as pulling down an instance that's in the middle of calculating a task, and handling retries in case of failure.
So, You want to serve Deep Learning Algorithms as a service.
You have a really cool algorithmic library written in Python and TensorFlow/Keras/Some other platform that requires running workloads on a GPU and you want to be able to serve it at scale and have it up and running fast.
Celery is an open-source asynchronous task queue which is based on distributed message passing. After reading all possible blog posts and seeing all the Youtube videos about Celery, I decided it’s the right solution for the task at hand.
Please welcome our main characters of the plot:
Innovation lover, Technology geek, Enthusiastic Software Engineer