Brand, Product and Loyalty

Brand and Product are not the same thing. A product is made by a company and can be purchased by a consumer in exchange for money. But a brand is a collection of perceptions in the mind of the consumer. It is a promise or covenant between the company and the consumer that a certain experience or set of benefits will follow when the brand is used.

Building a brand is hard compared to building the product. In the journey of building a brand, Social media and user communities plays a major and very critical role. The success of brand now depends on what the community talks about it. So it’s a critical fact to carefully manage and listen to these contents that published in different channels. One small mistake is enough to take down a business. In order to do the branding correctly, it is important to understand the purpose of it first. According to De Chernatony and McDonald (1994), the purpose of branding is to facilitate the circumstances for gaining loyal consumers and retaining them with acceptable cost with the goal of accelerating return on investment. Brand loyalty defines how much a consumer is  attached to a brand. Once he/she attached to it, they will spread the word about the it within the community and that message has a larger impact compared to a message from the brand itself. So the loyal customers have a big contribution towards the success of the brand and it’s important to keep their momentum of spreading the word and increase the size of the loyal community.

Companies publish content to different social media channels and they are being followed and seen by different user communities. Some of the content receive negative feedback and some receive positive feedback from the community. Ones with negative feedbacks have different levels of impacts towards the brand and vice versa for ones with positive feedback. Perceptions of the community can’t be known until it is published, but however tracking feedbacks for the published contents can help with deciding on new content to be published. However within this broader audience there are loyals who not only look at the content but also spread the word about it. As mentioned above they are the key success factors of the brand. So it is with utmost importance to identify the loyals and ensure their continuous loyalty towards the brand.


Processing Multi-Stage Tasks using Firebase Queue

This is an implementation of Pipes and Filter Pattern which is a commonly used Cloud Design Pattern. The most common approach to implement this pattern is via multiple queues as shown in the following figure.


Pipeline Using Multiple Queues (Ref : MSDN)

The prosed solution here uses a bit different approach than above and use a single queue instead of multiple queues as shown below.

Data Flow Diagram

Pipeline Using a Single Queue

To practically implement a solution like above the common approach would be to maintain a state for each queue message and assign a state for each workers(filters) to filter the messages accordingly before execution. However recently when I was trying out Firebase Realtime Database I found Firebase Queue which is a queue implementation on top of the Firebase Realtime Database and it turned out that it comes with a out of the box solution for maintaining a state (their term is specs) for queue messages as described above. So I worked on a PoC to evaluate this and in my personal opinion it’s really cool. But this is not enough to make a dicission so I was looking at various benefits we can achieve here with the usage of Firebase Realtime Database.


  • Using firebase realtime behaviour we can easily show the progress of the running tasks on a front-end
  • Since it’s single queue it’s less hazzle to implement and maintain
  • Uses push instead of polling to notify workers about new tasks
  • Implementation has been made super easy with their library
  • Nicely support to be run in a clustered environment distributing workload among nodes

Use Cases

  • In scenarios where REST APIs facilitate time consuming processing heavy back­end functions
  • In scenarios where triggered background tasks run for streaming data

Android Wireless Debugging

If you are a mobile app developer, you surely have noticed that it’s a burden to debug having connected your device via a USB cable. And it’s a waste if your PC has only few USB ports. So anyways there is a cool solution for this.

If both your PC and your android device are connected to a wireless network (should be in same network), you can debug your device wireless.

Step 1

Connect your device to your PC via a USB connection (Make sure USB debugging is on)

Step 2

Go to your android platform-tools directory and open a command window and run

               adb tcpip 5555
               adb connect <Device IP>:5555

Step 3

Disconnect USB connection. Now you can debug your device wireless, you can run “adb logcat” and check whether it’s working.

To switch back to USB run the following command

               adb usb

4+1 View Model

Architecture of software-intensive system can be described using multiple, concurrent views. Based on this fact Philipe Kruchten developed a view model consists of 5 views, that a software architect can look at a system. But why is this called 4+1 view model rather 5 view model ? The obvious reason is unlike four views one view shows the systems functionality from the view point of the outside world.

Following figure shows the 5 views, how they are related to each other and the diagrams used to explain each view.
Logical View

  • Shows the parts that compromise the systems
  • Represent a set of abstraction
  • Emphasizes classes and objects
UML diagrams used
        Class diagram
        State diagram
        Object diagram
Process View
  • Describes system processes
UML diagrams used
        Activity diagram
        Sequence diagram
        Communication diagram
Implementation View (Development View)

  • Illustrates a system from a programmer’s perspective
UML diagrams used
         Component diagram
Deployment View (Physical View)

  • Illustrates system execution environment
  • Maps software artifacts to hardware that hosts them
UML diagrams used
         Deployment diagram
Use Case View

  • Illustrates system functionality
  • Captures user goals and scenarios
  • Helpful in defining the structure and functionality in other 4 views
UML diagrams used
        Use case diagram