Posts

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 org.apache.thrift.tools:maven-thrift-plugin 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

Image
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 .    https://diataxis.fr 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)

Image
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

Use the Heilmeirs for Project Funding

I learnt about the Heilmeirs from Vijay Gill , an ex-SVP at Databricks (now an SVP at RapidAPI). He said that this was the fastest way to focus the discussion around project funding. I've found it to be useful - sharing this with you. The Heilmeirs Project funding is governed by this one-pager process: What are you trying to do? Articulate your objectives using absolutely no jargon. How is it done today, and what are the limits of current practice? What is new in your approach and why do you think it will be successful? Who cares? If you are successful, what difference will it make? What are the risks? How much will it cost? How long will it take? What are the mid-term and final “exams” to check for success?

The Effective Executive

  The Effective executive “An effective executive does not need to be a leader in the sense that the term is now most commonly used. Harry Truman did not have one ounce of charisma, for example, yet he was among the most effective chief executives in U.S. history. Similarly, some of the best business and nonprofit CEOs I’ve worked with over a 65-year consulting career were not stereotypical leaders. They were all over the map in terms of their personalities, attitudes, values, strengths, and weaknesses. They ranged from extroverted to nearly reclusive, from easygoing to controlling, from generous to parsimonious. What made them all effective is that they followed the same eight practices: They asked, ‘What needs to be done?’ They asked, ‘What is right for the enterprise?’ They developed action plans. They took responsibility for decisions. They took responsibility for communicating. They were focused on opportunities rather than problems. They ran productive meetings. They thought and