The 6-verse Prelude of the Gaudapada Karika

 The following link is the text of the Gaudapada Karika  embedded in a book length commentary by Shri Raghunath Damodar Karmarkar. As discussed in the preface commentary, the style of the text is in terse Sutra style and the text has not evolved over the ages - it has been reprinted from an original manuscript. In the book, the full Gaudapada Karika is explained page by page starting from (PDF) page 60 with a literal line-by-line English translation (as can be easily verified) Page 60 of the PDF version of the book looks as follows (red-emphasis mine):  The 6 verses of the prelude are clearly visible before the start of Chapter 1. Their numeric annotations are added to indicate that they are in the clear style of the Gaudapada - in tight sutra with numerical meanings attached. My interest in the 6 verses of the untranslated prelude stem from a link to standard Number Theory in mathematics, where the indicated cycle lengths are the typical cycle lengths associated with the respective Su

Leaving Pinterest today

Today's my last day at Pinterest. A journey comes to an end. Hopefully a new one begins also. I'm keeping a few memories from friends and team mates here. Looking back at the journey, the most important points were:  I had the opportunity to mentor 6 promotions in 4 years: Karthik (L5 to L6 MLE, now an L7 MLE Manager) Lu (L5 to L6 to L7) Heng (L4 to L5 to L6) Qingxian (L4 to L5 MLE) ... and there are more that should get promoted this year or the next. I had the opportunity to indirectly influence the growth of my mentees: Jeremy (then L5, now L6 in Security) Deborah (then L4 in ML ranking) Lily (then L4 in Data Analytics) Jason, Chenqi, Anumol, Kanchi, Dinesh, Nishant and many others. I had the opportunity to build and deploy one of the world's largest Flink clusters Set up the infrastructure to support 20 million messages/s. Train and upskill a 15 person team Support 300+ engineers across 24+ teams.  Deliver on the business critical path, on time and without being a bloc

BUCK2 import Maven dependencies

Meta's BUCK2 doesn't yet have Java and Android support (see github issue 394 ), however, it's useful to have a script to autogenerate remote_file and prebuilt_jar rules from Maven coordinates, if the code did work. If you're trying to get BUCK2 to compile Java, save yourself the trouble just yet and use Bazel - it should work for you.  That said, here's a quick attempt at a script to import maven jars for BUCK. If it's useful to you, feel free to use. #!/usr/bin/env bash # # Import a Maven dependency based on the coordinates. # # # Print debug log # set -x # Exit on error set -e if [[ $# != 1 ]]; then echo Usage: $0 com.pinterest.optimus:library:version echo echo Imports the given Maven target into a BUCK file in third_party/ exit 1 fi # Change to third-party directory cd `dirname $0` MVN_COORDS=$1 GROUP_ID=$(echo $MVN_COORDS | cut -f 1 -d:) ARTIFACT_ID=$(echo $MVN_COORDS | cut -f 2 -d:) VERSION=$(echo $MVN_COORDS | cut -f 3 -d:) MAVEN_CENTRAL_UR

How to correctly compile Thrift using Maven

The is old and largely unmaintained (last updated 2013). It should not be used anymore. The correct plugin to use is org.apache.thrift:thrift-maven-plugin which was last updated in 2017.  The main problem with the maven-thrift-plugin and the thrift-maven-plugin is that it doesn't correctly integrate with the maven generate-sources command (at-least for Maven 3.8.4). The way to fix that is to change the generated sources to be placed in the src/main directory of the maven package. The ` <generator>java</generator> ` is to fix some of the backward incompatible changes on the thrift compiler's command line (usually shows up as an error: " unknown option java:hashcode").  Adding the following to your pom.xml will allow a process where the thrift files can be manually updated with a local command the rest of the compile is straightforward.  <plugin> <!-- Note: trigger rebuild of java classes from thrift

Quality documentation requires Diátaxis

It was an eye opening day for me when I first learnt that there's a theory around how documentation should be organized. That grand unified theory of documentation is called Diátaxis . Diátaxis states that documentation belongs in one of 4 quadrants: Tutorials How To Guides Explanations Reference documentation They illustrate the idea using the following image: You'll see that the space of documentation was broken down along 2 axes: Personal State: Understanding or Executing Task state:  For Understanding: Theoretical vs Real-World  For Executing in the Real World: Processes (User Flows) vs Tasks (micro actions) The 2x2 breaks down as follows: Understanding a Theoretical Scenario: (What's my model of the world? How is this system solving it?) Architecture Explanations Architecture Diagrams Data Flow Diagrams Algorithms & Theory Design Docs Problem statement / Problem setting Understanding a Real-World Scenario: (Walk me through how I can solve a p

The day I met Whit Diffie (of the Diffie-Hellman crypto fame)

It was either December 11th or December 18th. It was a neighborhood party at Didi's place. Honored to meet a Turing Award winner. I was too tongue tied to say anything beyond platitudes though. Tons of respect for what he's achieved. 

public static is harmful. It has no home in modern programming.

In the modern era of software development, "public static" is a relic of a past age. It reflects a bygone era where the concepts of composition and dependency injection were not yet well understood. In the modern world of software, where we understand both of these concepts relatively well - it's important to know that public static has no future. Let's see why: 1. public static forces static coupling, breaks composition and dependency injection This one is fairly obvious - it's in the name. A call to a public static function typically looks like: void myCallingFunction() {   MyUtils.publicStaticFunction(args); } As we can see clearly, the call to the public static function is happening with a direct reference through the containing class. The calling function is tied down to using only the implementation in MyUtils. The caller may not choose another implementation even if the caller may be calling the code in a test environment ( brittle composition ). This  &quo