Forem: SangeethaKP

Machine Learning on the Edge with Sangeetha KP

SangeethaKP — Thu, 23 Jul 2020 11:53:58 +0000

Sangeetha is a software developer at Amazon focused on building features for the mobile shopping app. Previously she worked on building features on Echo devices and the Alexa companion app. When she is not programming, she can be found tinkering with photography, scouting around Seattle meetups or lurking on Twitter.

The world is filled with billions of small, connected, intelligent and compute-efficient smart-phones. What if we can tap into this power and do more on the edge? It turns out, ML fits perfectly here. Let us explore the MLKit library that makes it easy to do on-device Machine Learning which has several benefits such as latency and bandwidth wins, offline-first experiences, better security to name a few.

This talk covers:

What is Machine Learning on the edge and what is the need for that? This section also talks about the pros and cons of doing ML on the edge.
Introduction to MLKit library that helps achieve ML on the edge and what are the features it offers? This section will talk about the different use-cases one could use these features as well.
Demo of an Android application built using MLKit library that demonstrates the above said features so that the audience get an understanding of MLKit in action.
Code walk-through of above demo to understand ML to convey how can one get started right away with integrating MLKit in their mobile applications.
Summary of talk

Here is a download link to the talk slides (PDF)

Refer this source, for more resources on this talk

This talk will be presented as part of CodeLand:Distributed on July 23. After the talk is streamed as part of the conference, it will be added to this post as a recorded video.

Nature's code - a Fibonacci appreciation post

SangeethaKP — Sat, 04 Jul 2020 02:23:05 +0000

Some of us were likely introduced to "Fibonacci sequence" in early Programming/Math classes. It is a Mathematical sequence that goes like this:

1, 1, 2, 3, 5, 8, 13, 21...and so on

Fibonacci sequence, was just that, a sequence to me until recently, when I learnt about all the magic it beholds. My sister and I were having a conversation about patterns and somehow it veered towards the Fibonacci sequence. She told me that the fibonacci pattern can be widely observed in nature. This was totally news to me and I was low-key bummed I did not know this earlier. But hey, better late than never, right? So I looked this up online and this post distills how Fibonacci sequence serves as the nature's code.

What is the Fibonacci pattern?

The pattern here is that each number in the sequence can be generated by adding up the previous 2 numbers.

For example:

The 6th number in the sequence is 8 which can be generated as the sum of 5 and 3 which are the 5th and 4th numbers in the sequence respectively.

Thus the nth number in the sequence can be mathematically represented as:

x(n) = x(n-2) + x(n-1)

Fibonacci sequence - visualized

To get a better idea of the picture, let us visualize the sequence in a pictorial format. The sequence can be visualized by stacking together boxes in the following way:

First let us start with a square-box of dimension 1
Move in anti-clockwise direction and stack another square-box along the length of the rectangle formed so far. The dimension of this new square-box should be the length of the rectangle formed so far.

Let us go step by step:

We start with a square-box of dimension 1
The length of the rectangle formed so far is 1. So we will stack a square-box of size 1 along the length of the rectangle formed so far.
The length of the rectangle formed so far is 2. So we will stack a square-box of dimension 2 along the length of the rectangle formed so far.
The length of the rectangle formed so far is 3. So we will stack a square-box of dimension 3 along the length of the rectangle formed so far.
The length of the rectangle formed so far is 5. So we will stack a square-box of dimension 5 along the length of the rectangle formed so far.
And we can continue to stack boxes like this

Let us note down the dimension of the squares stacked in this process:

1,1,2,3,5,8,13,21, .... The fibonacci sequence!

The fibonacci spiral

Onto furthermore fun stuff. Let us trace a curve starting from the first square and move in the anti-clockwise direction covering the boxes along the way.

Does this curve look familiar? This is the fibonacci spiral and can be found in a lot of places such as :

The fibonacci spiral is so ubiquitous in nature, that it is fondly referred to as the nature's code. For example, plants prefer that all their leaves get maximum exposure from the Sun. This can be ensured by growing leaves at non-repeating angles so that the leaves don't overlap as much and get a fair share of exposure to sunshine. Phi (φ) which is of the value ~1.618 is an irrational number that guarantees this. Thus leaves generally shoot up at this angle. Also, take the ratio between any two adjacent numbers in the fibonacci sequence and you can see we move closer to the Phi value.

1/1 = 1

2/1 = 2

3/2 = 1.5

5/3 = 1.66

8/5 = 1.6

13/8 = 1.625

21/13 = 1.615

... and so on, getting closer and closer to the value of Phi (φ) which is ~1.618.

This number is also called the 'Golden ratio' and has it's applications in various stuff universally such as photography, art, architecture and more.

Though fibonacci sequence can be spotted in a lot of places, some folks have claimed that we exaggerate and tend to force fit the pattern on things that don't necessarily adhere to it. This follows the idea that once we see a pattern, we are likely to carve out the same pattern in other things as well. That being said, I had lot of fun revisiting fibonacci sequence and learning them through an entirely different lens, hope you did too.

And oh hey, since you've made it this far, here is a joke for ya:

Why was Jim bad at making Fibonacci jokes? Because his last two jokes didn't add up 😛

References

If you are hooked, def check this video that has an excellent explanation of Fibonacci patterns in plants

24 debugging tips and tricks

SangeethaKP — Sat, 28 Mar 2020 11:35:06 +0000

Bugs are inevitable in any code base. Learning to love the process of debugging and having your own Swiss Army of tools to aid you in that process would make you multiple times more efficient at it. Below are 25 debugging techniques that help me see sense in the chaos.

1. Try to find a consistent step to reproduce the bug: This is a very important step to squash any bug. Once we determine the steps to reproduce a bug, we should try reducing the number of steps to the most minimal as possible to narrow down the scope of the problem. Once this is done, we can step through the code-base corresponding to those steps and analyze it. Additionally, once you determine a fix for the bug, you have solid scenarios to ensure that the bug is indeed fixed.

2. Unit test to reproduce a bug: When we know that the code fails to work as expected for a particular scenario, write a unit test to confirm the failure and go about debugging. By reducing a problem to a failing test case, we figure out a nice starting point to work. Unit tests also double as a measure to prevent regressions for the same test case in the future.

3. Rubber Duck Strategy: "A well-understood problem is half done" - This is my favorite strategy while debugging or any problem in general. Thinking out loud about the bug and explaining it in simple terms to a co-worker or to yourself helps uncover some false assumptions / blind spots.

4. Add logs: This is a simple and widely used debugging strategy and I have found some of the most senior Engineers adopt this technique to debug as well. Add a bunch of log statements that hold information about the state of the program to help you validate the correctness of code execution. In addition, modifying the code slightly to add early returns, conditional returns, etc could be used to debug edge cases as well.

5. Debugger: Invest in good debugging/developer tools to make debugging a better experience. Breakpoints, dynamic expression evaluation, analyzing heap dumps, chrome debugger, API verification tools such as Postman etc are a few examples.

6. Refer Documentation: Some people might find this old school but this is a surprisingly good tip. Go back to the documentation of APIs to confirm your assumptions.

7. Git Help: Determining commits that went in since the last time the code worked fine will help us narrow down the problem space. By combing through the git diff we can determine changes that could have potentially caused the bug. Git tools such as git bisect, git blame and git log are your friends to check for regressions, potential pull requests that might be the cause of the bug.

8. Check if it is the right app version / right version has been deployed or not: Oh boy, this is yet another popular cause of bugs. Always cross verify the version of the application that you are verifying your bug against to ensure that it is supposed to be working fine. In the service world, always cross-verify whether the changes have built through all the pipelines fine.

9. Multi-threading and concurrency issues: Do not discount potential multi-threading/concurrency issues as potential causes for bugs. They are not super evident right away and are tricky to root-cause or debug. Debuggers and logs among other things are your friends here to unravel such issues.

10. Breaking Dependency changes: Often times we come across bugs in features that have been untouched for the longest time. Worry not and double confirm if there are any downstream/dependency changes that might be the root-cause for the bug.

11. "If someone else had a problem, what would I suggest?": This is a good prompt that comes in handy when we are too hard on ourselves while debugging an issue. Often times, I have wonderful advice for my friends or peers when they are debugging an issue (in Tech or life in general); but when it comes to the self, I am not so great. I employ this strategy while raising pull requests as well - before hitting the publish button on a PR, I review it from the lens of a code-reviewer and catch a few changes.

12. Outdated comments/documentation: Documentation and code comments are prone to go outdated unless duly maintained. While coding / debugging take care to ensure that the comments in the code base/docs are still valid.

13. Talk to someone who is familiar with the code-base: This is a very straightforward and effective strategy. Nothing like talking to the author or someone who is familiar with the code base to understand the code and it's intent. A few minutes of bouncing off ideas and talking through possible root-causes would give immense clarity and promising leads for the problem.

14. Difficult to debug code indicates that the code might need refactoring: One thing to keep in mind while debugging is, when you come across code that is difficult to read and understand, that is probably an indicator that it needs refactoring. Something to have in the back of your mind to be added in ticket backlog.

15. Stack overflow/google: This is a super straightforward debugging step that all of us follow - copy paste the error log and look for answers. Did you know that there are efficient ways to go about flexing your Google-foo? Check out this article.

16. Keep an audit trail of your debugging process: As you wind down the debugging hole, it is good to have a list of steps or actions that you have already tried. In addition to providing some mental clarity for yourself, this would help set context when you explain the problem to someone else. Additionally, once you have solved the problem, you can document this in the ticket for future reference for yourself and the team.

17. When blocked, bring it up with your team: When you have been at a problem for a long time and haven't found a solution yet, definitely consider bringing it up in the scrum with a short blurb. This way, anyone who might have some familiarity with the bug would hit you up post scrum and help you out.

18. Make the code to intentionally fail: Sometimes I flip the question "Why is this code not working right" to "How could this code fail?". This mindset forces me to think through unhandled edge-cases.

19. Buddy builds and automation: Some bugs are hard to reproduce manually. Automated tests are best tools in this case. Add a bunch of debug logs and metrics in your code-base and run it through a suite of automation tests. If it is a timing issue or 1-in-n-times reproducing bug, chances are high that automation could capture them. Once done, you can analyze the logs from the test run or metrics emitted for more information.

20. Please remember to not break your production code: Special care should be taken when we are debugging systems that can potentially have actual production impact. Example: working with databases, making configuration changes in production ,etc.

21. Platform-specific issues: When you find weird bugs on applications that run on mobile phones/browsers, confirm if the bug reproduces across different platforms or if it is isolated to a specific platform. An example would be bugs on android applications that reproduce only on Samsung devices or bugs that reproduce only on the Android 8 version.

22. Feature flags: When new features are rolled out, they are put behind a feature flag. If a feature is not working as expected, be sure to check that the feature flags have been dialed up appropriately.

23. Check with Quality Assurance Engineers: Teams usually have folks who specialize in testing the product to ensure it's quality. More often than not, they would have handy tools to simulate tricky scenarios and know edge cases that you might probably be unaware of. Seek time with them and walk them through the bug.

24. Take a break and get back ❤️: Seriously, this can do wonders. I often forget this rule and chip away at a problem for hours straining my eyes and mind. Taking a break and looking at the problem with a well-rested mind is always helpful.

References:
Following are some fantastic articles that I learnt a lot about debugging from:

A beginner’s introduction to Session Initiation Protocol (SIP)

SangeethaKP — Tue, 10 Dec 2019 02:40:06 +0000

Introduction

Have you ever wondered how convenient it is to instantly connect with friends and family who are miles away? The incredible ease with which we are able to signal and communicate with anyone globally is brought to us by the wonders of the Session Initiation Protocol (SIP). SIP is an application layer protocol that is responsible for setting up, tearing down and managing multimedia sessions between devices over the IP network. This blog post aims to provide you a high level overview of SIP.
History

Before the advent of SIP, we primarily communicated using landline phone calls that happened over the Public Switched Telephony Network (PSTN), sometimes fondly referred to as Plain Old Telephone Service (POTS). To establish a call using the PSTN network, a dedicated channel (or circuit) needs to be set up for the duration of the call. With the onset of IP network, there was an opportunity to replace communication over circuit-switched PSTN with packet-switched Voice over IP (VoIP) network. Unlike traditional PSTN, communication over VoIP does not require dedicated telephone lines and data is broken down and sent as packets across the Internet.

What is SIP and why do we need it?

VoIP communication, simply put, is data packets transferred back and forth between the communicating parties. These packets can be classified into two types:

Signalling packets : These packets are responsible for signalling the parties and establishing the communication between them.
Media packets : These are the data packets that is transferred in the communication such as audio / video / text / images etc. The analog media signals are encoded into 0s and 1s and sent as media packets. On the receiver’s end, the media packets are decoded back to the analog signals.

For communication to take place, the sender and receiver should be aware of two things:

The IP address of each other.
The media codecs supported on each other to do effective encoding-decoding.

As one would expect for effective communication to take place, the parties involved must agree on a common protocol (like a common language) in-order to transfer media between them. One such protocol is the Session Initiation Protocol. With SIP, the parties will be able to signal to each other that they are ready to start the communication.

SIP is an application layer protocol, responsible for setting up, tearing down and managing multimedia sessions between endpoints over the IP network.

A high level architecture overview of SIP

One of the most integral needs for communication to take place is to know the address of the other person. In the SIP world, the endpoint devices that the users interact with for communication are called the SIP User Agent Clients (UAC). Each UAC has a unique public address called the SIP AOR (Address of Record) with which they can be uniquely identified (similar to an email-id of a person). A SIP AOR looks like “SIP:user@domain”. As long as we know the SIP AOR of the other person we need to talk to, we can initiate a media session with them.

But in the true sense of a Voice over IP network, it is essential that we know the actual IP address of the UAC device in-addition to their AOR. How do UACs discover each other’s IP addresses that are not known publicly unlike the AORs?

Let us go over an example to understand this.

Alice and Bob are friends who have shared their SIP AORs with each other for communication.

As Alice wants to make herself available for any communication over SIP. She logs into her User Agent Client (endpoint device). As soon as she logs in, Alice’s IP_Address and SIP AOR are registered with a Registrar Service. The Registrar Service stores this IP_Address + SIP_AOR combo in a SIP Registry (probably a Database).

Bob would like to call Alice. Bob places a call to Alice’s SIP_AOR from his UAC.

At this point, Bob’s UAC sends an INVITE message (which is a message part of the SIP protocol) to a Location Service. The INVITE message from Bob’s UAC carries Bob’s IP_Address, Bob’s SIP_AOR and Alice’s SIP_AOR. The Location Service queries the Registry and retrieves the IP_Address corresponding to Alice’s SIP_AOR (remember Alice had initially logged in her device and her SIP_AOR + IP_Address was stored in the Registry). After obtaining Alice’s SIP_AOR + IP_Address, the location service proxies the call invite to Alice on behalf of Bob. Alice receives a call on her UAC and accepts the call. At this point, an ACK message that contains Alice’s SIP_AOR, Alice’s IP_Address is sent back to Bob.

So, as part of the INVITE message, Alice received Bob’s IP_Address and AOR. And as part of the ACK message, Bob received Alice’s IP_Address and AOR.

Hurray, both the UACs have discovered each other and a media session can be initiated between the two! 🎉

This is a basic overview of how a session is established between the different parties in a VoIP session.

Summary

Gary Audin, writer at nojitter.com sums it all up really well as SIP “tells you the presence of the other party, makes a connection and lets you do whatever you want over the connection, but it has no idea of what’s going over the connection”. This is a super high level overview of SIP and you can follow the following resources to learn more.

I hope to have helped you understand the world of VoIP a teeny bit better with this article.