Bi-Weekly Report #4 — Tatag Aziz Prawiro

Published in

AdHub Team

7 min readApr 18, 2019

The strength of the team is each member. The strength of each member is the team — Phil Jackson

What’s up, guys. The 4th bi-weekly report has come, and it’s time for me to share more about what happens in our team. In the current report, I will be talking about Team Dynamics, Persona, and Mocking Test.

Team Dynamics

It has been two and a half month since the A-Team assembled themselves. It surely is not a very smooth ride, in fact, it was actually quite bumpy. So for the section of Team Dynamics, I will be talking about how I, as a hustler, play my part to become the “servant” of the team.

The Hustler Role

The role of Hustler is like the “center” of the team. The crucial part as a hustler is to become the one that mainly moves the team. The Hustler is like the “leader” of the team, although actually, he is not. Rather than “leading” the team, the hustler’s job is to “support” the team and also to become the face of the team in front of clients and other people.

Team Assembly and Groundwork

The A-Team was actually made before the PPL Course even started, although the team original name was “ATOM”. I think it was probably near last semester final exams period that the “ATOM” Team assembled themselves, although it’s not until around January that I was appointed as a hustler. The name A-Team was chosen just near the deadline of PPL team assignments.

I was appointed (or actually, sacrificed, hehe) as the hustler of the team because I am arguably the most vocal about anything in the team, sometimes even going a little bit out of line (bad habit). While I was having doubt at the time, I too actually am a little bit interested in the hustler role. And so, the first thing I did after I was appointed as a hustler was to establish a well-conditioned working environment for the team.

In order to do that several things I did are:

Created a collaborative working environment using Discord and Line
Created a messaging group using Line
Assigned weekly meeting time
Created a friendly environment in our circle

These 4 are the first steps I did in order to make a functional team. During this phase, I also created the team slogan, or rather, team values which I wrote in the first post in the A-Team Medium Publication.

Our Team Values are:

Amazing
Always strives to make amazing products.
Adventurous
Having an eager personality to explore the current state-of-the-art technology in software development
Atomic
Small team size, big impacts.

By doing these tasks, I put the groundwork in order to create an effective team. Next is the practice during development

Practice during Development

During development, not everything goes like in the paper. Each member in our team always has their up and downtime of their morale, this includes me. In order to prevent, or rather, reduce the effects of low morale, we always keep our communications up even when we are at our lowest of the low. Other than that, we also do occasional live coding in order to get the job done. We also tried to remind each other of their own responsibility and tasks that they take. We supported each other.

Aside from those routine above, we also had a Team Building Session. We did our team building at Upnormal Tebet. During the team building, we chat and just spend time together. We also had a live code session during it, to at least have a little bit of productivity.

All in all, I believe I am still not a good hustler yet, let alone a good person. I hope I can become better at helping my team grow.

Persona

Now, I am going to talk about the persona of our product.

A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words, personas represent fictitious people which are based on your knowledge of real users.
— Taken from the Agile Modelling

So in other words, a persona is like a “fictional” real user that is expected to use our product. Persona is used as a rough guideline to make our application. We should make application by referring to what our persona would do, what our persona would think, and what our persona would need. This way, it ensures that we develop our products the right way, the way that the user would want to use.

So moving on, these are our 2 personas.

So, our persona reflects the 2 kinds of the user that is going to use our product. Both personas are an entrepreneur that has a small to medium scale business (UKM). The first kind of persona represents the most kind of UKM owners, the middle-aged person who is not so familiar with information technology. The second kind of persona represents the more familiar kind to information technology.

Mocking Test

Now let’s move on to a more technical thing. During the development of AdHub, I am responsible for the development of the back-end functionality of Google API. Since we also use Test Driven Development in practice during our application development, this could become a liability in our test coverage. Why would that happen? Because Google API is not a function that is personally made by the development team, we cannot control it’s expected behavior even if it fails. So, what to do, then? One thing that we can do is to utilize the Mock.

Mocking Test — Definition

Fake it till you make it
— English aphorism

So what is test mocking? A mock is a fake object to replace the real data. In the development phase, it is very useful because you can premake a mock first that automatically return an intended data without having to develop the internal function first. You can use it to fill in place soon to be developed function or use it to replace an external function. The use in our case is the later because the mock is used to fake API Calls during the test phase.

Mocking Test — Python

To mock test in python, we can use the unittest.mock library.

The simplest way to mock test in python is to import patch decorator from unittest.mock

from unittest.mock import patch

After that, we then make a fake function that returns a predetermined value. I will show the fake function that I make in my application:

def fake_ad_group_response(self, *args):
        return '67552213105'

This fake function returns a fake ad group id that is used in the API Call in google API function:

def add_ad_group(self, payload):
        client = self.client        if payload['customer_id'] != '':
            client.SetClientCustomerId(payload['customer_id'])        ad_group_service = client.GetService('AdGroupService', version='v201809')
        ad_operations = {
            'operator': 'ADD',
            'operand': {
                'campaignId': payload['campaign_id'],
                'name': payload['ad_group_name'],
                'status': 'ENABLED',
                'settings': [
                    {
                        # Targeting restriction settings. Depending on the
                        # criterionTypeGroup value, most TargetingSettingDetail only
                        # affect Display campaigns. However, the
                        # USER_INTEREST_AND_LIST value works for RLSA campaigns -
                        # Search campaigns targeting using a remarketing list.
                        'xsi_type': 'TargetingSetting',
                        'details': [
                            # Restricting to serve ads that match your ad group
                            # placements. This is equivalent to choosing
                            # "Target and bid" in the UI.
                            {
                                'xsi_type': 'TargetingSettingDetail',
                                'criterionTypeGroup': 'PLACEMENT',
                                'targetAll': 'false',
                            },
                            # Using your ad group verticals only for bidding. This is
                            # equivalent to choosing "Bid only" in the UI.
                            {
                                'xsi_type': 'TargetingSettingDetail',
                                'criterionTypeGroup': 'VERTICAL',
                                'targetAll': 'true',
                            },
                        ]
                    }
                ]
            }
        }        response = ad_group_service.mutate(ad_operations)
        return response['value'][0]['id']

We then use the patch decorator to “patch” the function so that when the function above is called in a test, the fake function is called instead. Here is the snippet of the code that I wrote in AdHub application:

@patch('google_api.google.GoogleApi.add_ad_group', fake_ad_group_response())
    def test_create_google_campaign_success(self):
        payload = {
            'customer_id': 'customer_id',
            'campaign_id': 746-601-7617,
            'ad_group_name': 'TEST_CAMPAIGN_3'
        }
        response = create_google_ad_group(payload)
        self.assertEqual(response['ad_group_id'], '67552213105')

See that we use the patch decorator before we declare the test function. This way, when the function path google_api.google.GoogleApi.add_ad_group function is called, the function fake_ad_group_response() is called instead of the original function. This way, we ensure that our test success and failure is not dependent on the status of the external Google API itself, but only on the correctness of our application implementation.

Closing

That is it for this bi-weekly report. I hope I can explore more about both the technical aspects and the “hustler” aspects more in the future. Thank you for your attention.

El Psy Congroo.