Full Blog TOC

Full Blog Table Of Content with Keywords Available HERE

Monday, August 21, 2023

Publish Android Library AAR to Maven Central


 

In this post we will review the steps required to publish an Android library as an artifact in maven central. This is required when we create an Android library that we want our customers to use, without the need to manually download files, and also allows the customers to enjoy the maven dependency management.


The procedure below includes 3 steps:

1. Create a local maven artifact

2. Create a new project in maven central

3. Manually upload the artifact to maven central


Create A Local Maven Artifact

Open the project in Android Studio, make sure the gradle version is at least 7.1.

This is visible through the File menu, Project Structure, Project (on the right bar).



Now, open the build.gradle under the library folder, and add maven-publish plugin right below the existing android library plugin:



Next, in the same file, right after the android root element, add the publishing:



The full text of the publishing element is below. Notice that I've used my-company and my-library, but feel free to replace with the text that describes the relevant company/library. Notice that this company name must be under your ownership at github.




After updating the gradle, we need to rebuild the library.



And finally, run the publish: under the Android Studio gradle tab, select the library project, then under tasks, publishing, select publishReleasePublicationToMavenLocal.



The built maven artifact is now available in ~/.m2/repository/io/github/my-company/my-library


Create a New Project in Maven Central

1. Create new github user by the company name. For example:

https://github.com/my-company/my-library


2. Create new user in Sonatype: https://issues.sonatype.org/secure/Signup!default.jspa


3. Create ticket to create new project: https://issues.sonatype.org/browse/OSSRH-94213

You must prove ownership on the project ID, so either own the DNS or use GitHub and prove ownership on the GitHub user. I have chosen github. Once the ticket is open, follow the instructions in the ticket to prove ownership.


4. Create gpg keys:

gpg --full-gen-key

# select 1

# select 4096

# select 0

# enter name and email

# comment can be empty

gpg --list-keys

gpg --keyserver keyserver.ubuntu.com --send-keys THE_KEY_ID_SHOWN_IN_THE_LIST_KEYS

gpg --export-secret-keys THE_KEY_ID_SHOWN_IN_THE_LIST_KEYS| base64



Manually Upload The Artifact To Maven Central

Basically this steps can be automated, see steps here:

However, I would not recommend doing this automatically, as it is very complicated process, and not expected to be run many times in most scenarios.

The manual steps are listed here:
But we provide details below, so keep on reading below.


1. Run gpg for each file:

cd ~/.m2/repository/io/github/my-compant/my-library/1.0.0/
rm -f my-library-1.0.0.aar.asc
rm -f my-library-1.0.0.pom.asc
rm -f my-library-1.0.0.module.asc
gpg -ab my-library-1.0.0.aar
gpg -ab my-library-1.0.0.pom
gpg -ab my-library-1.0.0.module
rm -f bundle.jar
jar -cvf bundle.jar *


3. Select “Staging Upload” on the left bar




4. Select Artifact bundle

5. Select the file ~/.m2/repository/io/github/my-company/my-library/1.0.0/bundle.jar and upload


6. Select “Staging Repositories” on the left bar



7. Select the uploaded repository, and click Close button on the top



8. In case of failures, the reasons appears on the bottom under the activity tab:



9. Finally, release the library using the release button


Monday, August 14, 2023

Compacting JSON Representation in GoLang



In this post we will review a method to shrink JSON representation of Go structures. This is critical in case we need to save the state by marshaling the state objects and save them in Redis, which works really bad with large bulk of strings.

Let dive in quickly with an example. Let assume our state is represented by a struct, and see the JSON representation of it:


package main

import (
"encoding/json"
"fmt"
"time"
)

type DetectorConfig struct {
AnomalyThreshold float32
AnomalyPattern string
EnableDetection bool
}

type State struct {
Counter int
Stations []string
Detector DetectorConfig
LastUpdateEpoch int64
}

func ProduceDefaultState() *State {
return &State{
Counter: 0,
Stations: []string{"load", "build", "deploy", "test", "deliver"},
Detector: DetectorConfig{
AnomalyThreshold: 5.55,
AnomalyPattern: ".*",
EnableDetection: true,
},
LastUpdateEpoch: time.Now().Unix(),
}
}

func main() {

state := ProduceDefaultState()
bytes, err := json.Marshal(state)
if err != nil {
panic(err)
}

jsonText := string(bytes)
fmt.Printf("JSON length is: %v, JSON text is: %v", len(jsonText), jsonText)
}


And the output is:


JSON length is: 178, JSON text is: {"Counter":0,"Stations":["load","build","deploy","test","deliver"],"Detector":{"AnomalyThreshold":5.55,"AnomalyPattern":".*","EnableDetection":true},"LastUpdateEpoch":1691996599}


How can we compact it?

We could use the `json` annotation to use shorter names for the elements, but then we will not be able to display a clear and user friendly JSON to the system admin. A better method would be to decide upon need whether to use clear and user friendly JSON representation when displaying the state to a human, and whether to use a compact JSON representation when saving the state to a DBMS such as redis.

Here is an example of using the compact form:


package main

import (
"fmt"
jsoniter "github.com/json-iterator/go"
"time"
)

type DetectorConfig struct {
AnomalyThreshold float32 `compact:"a"`
AnomalyPattern string `compact:"b"`
EnableDetection bool `compact:"c"`
}

type State struct {
Counter int `compact:"a"`
Stations []string `compact:"b"`
Detector DetectorConfig `compact:"c"`
LastUpdateEpoch int64 `compact:"d"`
}

func ProduceDefaultState() *State {
return &State{
Counter: 0,
Stations: []string{"load", "build", "deploy", "test", "deliver"},
Detector: DetectorConfig{
AnomalyThreshold: 5.55,
AnomalyPattern: ".*",
EnableDetection: true,
},
LastUpdateEpoch: time.Now().Unix(),
}
}

func main() {
state := ProduceDefaultState()
jsonCompact := jsoniter.Config{TagKey: "compact"}.Froze()
bytes, err := jsonCompact.Marshal(state)
if err != nil {
panic(err)
}

jsonText := string(bytes)
fmt.Printf("Compact JSON length is: %v, compact JSON text is: %v", len(jsonText), jsonText)
}


and the output is:


Compact JSON length is: 102, compact JSON text is: {"a":0,"b":["load","build","deploy","test","deliver"],"c":{"a":5.55,"b":".*","c":true},"d":1691996466}


But can we do better?

What if out state is mostly static, and only a few fields are changing? Then we can list only the fields that change, and merge them in to the default config.


package main

import (
"encoding/json"
"fmt"
"radware.com/proximity/commons/global/reflectionapi"
"time"
)

type DetectorConfig struct {
AnomalyThreshold float32 `compact:"a"`
AnomalyPattern string `compact:"b"`
EnableDetection bool `compact:"c"`
}

type State struct {
Counter int `compact:"a"`
Stations []string `compact:"b"`
Detector DetectorConfig `compact:"c"`
LastUpdateEpoch int64 `compact:"d"`
}

func ProduceDefaultState() *State {
return &State{
Counter: 0,
Stations: []string{"load", "build", "deploy", "test", "deliver"},
Detector: DetectorConfig{
AnomalyThreshold: 5.55,
AnomalyPattern: ".*",
EnableDetection: true,
},
LastUpdateEpoch: time.Now().Unix(),
}
}

func main() {
state := ProduceDefaultState()
state.LastUpdateEpoch = time.Now().Add(time.Second).Unix()
state.Detector.EnableDetection = false

defaultState := ProduceDefaultState()
diffMap := reflectionapi.CreateDiffMap("compact", defaultState, state)
bytes, err := json.Marshal(diffMap)
if err != nil {
panic(err)
}

jsonText := string(bytes)
fmt.Printf("Diff JSON length is: %v, diff JSON text is: %v", len(jsonText), jsonText)
}


And the output is:

Diff JSON length is: 32, diff JSON text is: {"c":{"c":false},"d":1691996360}


Of course the length had significantly reduced, and will be reduced much further the bigger is our state, and the less updated fields it includes.


The reflection library is below:


package reflectionapi

import (
"fmt"
"reflect"
"strings"
)

type DiffHandler func(
elementPath string,
value1 interface{},
value2 interface{},
)

func FindDiff(
tagForName string,
item1 interface{},
item2 interface{},
handler DiffHandler,
) {
findDiffRecursive(
tagForName,
"",
item1,
item2,
handler,
)
}

func findDiffRecursive(
tagForName string,
prefix string,
item1 interface{},
item2 interface{},
handler DiffHandler,
) {
reflectType := reflect.TypeOf(item2).Elem()
reflectValue1 := reflect.ValueOf(item1).Elem()
reflectValue2 := reflect.ValueOf(item2).Elem()

for i := 0; i < reflectType.NumField(); i++ {
fieldType := reflectType.Field(i)
useName := fieldType.Name
if tagForName != "" {
useName = fieldType.Tag.Get(tagForName)
}

value1 := reflectValue1.Field(i).Interface()
value2 := reflectValue2.Field(i).Interface()

path := prefix + "/" + useName
switch reflectValue2.Field(i).Kind() {
case reflect.Struct:
interface1 := reflectValue1.Field(i).Addr().Interface()
interface2 := reflectValue2.Field(i).Addr().Interface()
findDiffRecursive(tagForName, path, interface1, interface2, handler)
break
case reflect.Slice:
value1String := fmt.Sprintf("%v", value1)
value2String := fmt.Sprintf("%v", value2)
if value1String != value2String {
handler(path, value1, value2)
}
break
default:
if value2 != value1 {
handler(path, value1, value2)
}
break
}
}
}

func CreateDiffMap(
tagForName string,
itemBaseline interface{},
itemChanged interface{},
) map[string]interface{} {
diffMap := make(map[string]interface{})

handler := func(elementPath string, valueBaseline interface{}, valueChanged interface{}) {
diffMapEntry := diffMap

sections := strings.Split(elementPath, "/")
sections = sections[1:]

for {
sectionName := sections[0]
if len(sections) == 1 {
diffMapEntry[sectionName] = valueChanged
break
} else {
sections = sections[1:]
nextEntry := diffMapEntry[sectionName]
if nextEntry == nil {
nextEntry = make(map[string]interface{})
diffMapEntry[sectionName] = nextEntry
}
diffMapEntry = nextEntry.(map[string]interface{})
}
}
}

FindDiff(tagForName, itemBaseline, itemChanged, handler)

return diffMap
}













Monday, August 7, 2023

Simplifying creation of Go applications on Google Cloud - Post Review


TL;DR

Google seems to stop having new ideas, so it just publishes nonsense as if it was news


Once in a while I read the blogs for some frameworks such as GCP, AWS, and K8s.

Some of the updates are marketing posts, but among them we can find some interesting news. Lat week, checkin gthe GCP blog, I've found the post Simplifying creation of Go applications on Google Cloud. This post seems promising, as a framework for Go applications is something that takes time to build, and I thought I might find interesting ideas there.

The post includes 4 templates:


"

  • httpfn: A basic HTTP handler (Cloud Function)

  • pubsubfn: A function that is subscribed to a PubSub topic handling a Cloud Event (Cloud Function)

  • microservice: An HTTP server that can can be deployed to a serverless runtime (Cloud Run)

  • taskhandler: An basic app that handles tasks from requests (App Engine)

"


So I've checked the templates, and was very disappointed. Most of the templates include less than 10 lines of banal code. It seems that someone in google thought that adding sample code that does almost nothing is good enough to be published in the GCP blog.


The question asked here is: what are the expectations from such a post?


The answer is framework and standards!


Instead of a naive example for HTTP server handler function, add a framework to wrap the HTTP handler, add error handling and logging as part of the HTTP wrapper, add some built-in handlers to the HTTP server, such as pprof profiling capabilities, and setup standards for code design and style.

Most of the projects I've been part of have a major part of the code in the "common" libraries. These common libraries provide a real template for new applications, making them more robust, simple to create, and set code and design standards to the application using the libraries.

A partial list of such libraries is:

  • Logging, log level, logger handler
  • Error handling (panic, recover)
  • HTTP web server wrapper
  • Scheduler wrapper
  • Extend core functionality for: io, slices, strings, parallelism, time
  • Testing wrapper

While adding usage such set of libraries to existing application is almost impossible, this can set a standard to new applications, and this is what I expect from Google - to setup standards. I hope next post would be more in this direction...







Sunday, July 30, 2023

Which Software Engineer Should You Recruit?


 

Which software engineer should you recruit to your team? What is the difference between a junior, senior and an ace software engineer? What is the expected salary, and does it worth spending it?


A crucial part of a being a senior software engineer and team leader in a software company is the hiring new personal process. This occurs when you're building up a new team for a new project, when the project expands and requires more developers, and when your need to fill in the gaps of software engineers who went seeking other adventures out of the company.

Before starting a recruiting process, we must understand who are we looking for. Support we want a full stack developer, should we hire a fresh newbie just out of the university, or a software engineer that had been out there working for 2 years? 10 years? What if we happen to encounter a superstar, should we hire him and pay the high cost?


Mixed Team

To answer this we should first examine the current situation in the existing team. A general guideline for an excellent team is to have a team that includes up to 7 employees. Most of the employees in the team should be seniors, which means they should have a good experience of at least 10 years. One or two of the employees should be juniors, with experience of 1-4 years. If you're lucky, you will also have a superstar software engineer in the team, with at least 15 years of experience and excellent analytical and performance abilities.

Why do we need such a team? 

We need such a team to create maximum production while avoiding tension. The difference in the team members skills would create a sharing and teaching habit between the more experienced team members to the others. The superstar can technology guide and lead the team while tackling a huge share of the tasks himself. 

Let's examine each of these typecasts.




The Junior

The junior software developer has 1-4 years of experience. The production output from this team member is expected to be very low. It might be even negative production output:

1. The team needs to invest resources in educating the junior software developer.

2. The mistakes and bugs caused by the junior cause production lost, both when fixed during the development process, and when are discovers as bugs on customer deployments.


Still there are benefits for employing a junior:

1. The need to education and information sharing in the team becomes an integral and a legit process in the everyday working process. This benefits both the juniors, but under the surface provides a benefit for the senior team members as well.

2. The payroll of a junior is low.

3. There are many juniors available in the market

4. The junior would eventually become a senior, and in case he chooses to stay in the company, it is a senior with several year of experience exactly in the development domain you need.

5. In the long term, this is the only effective method to train new software developers, that is - by experience, and as a society we should strive to create senior software developers.


The Senior

The senior software developer has at least 5 years of experience, which usually spent in several companies. The production output from this team member is expected to be high. In case you don'y have a superstar in the team, this is where the majority of work is done. 

A senior in the team is expected to have payroll of 2-3 times more than a junior, and it is harder to find a good senior, and the seniors are less available in the market.

The senior is usually limited to few technology domains, for example: 1-2 programming languages, 1-2 development frameworks.

The Superstar

The superstar software developer has at least 15 years of experience. If you are lucky to get one in your team, then you are in good state. The superstar would both lead the guide the juniors and seniors in the team, and would take the heavy-lifting tasks on his own. A production output from a superstar is at least 5 times fold higher than a senior software engineer.

Why?

The superstar has high development rate and high quality code. This means a lot of output, with very few rejects in form of bugs and customer issues. The architecture of the product would usually also handled by the superstar, reducing mistakes that otherwise would have huge impact on the road-map in the future.

The superstar is not limited by domains, any new programming language, and any new framework, is usually taken over in a short period. In most cases, the superstar adapts and enhances the frameworks to the team needs.

A superstar in the team is expected to have payroll of 2-3 times more than a senior, and it is extremely hard to find one in the market.





Sunday, July 23, 2023

Rust - I give up!




 For the last 2 months I've been trying to use the Rust language. In the beginning it looked promising - get the performance of a C++ code with a better stability, simpler memory management, everything solved at compile time, and not sorrow hours of trying to solve a memory leak/overrun in runtime.

BUT...

As I've stepped through the Rust Book,  I've discovered the complexity of the compiler getting higher and higher. I've spend hours creating a code that in other programming languages I can do in 5 minutes. It make no sense.

Not only that, I've also discovered the "Smart Pointers" chapter, and the formal declaration:

"

Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust.

"

Oh really?? So why should I spend my time on this? As the applications in Rust get more complex, we are forced using smart pointers, and lose the memory magic of Rust. Suddenly I feel much less motivated to spend time on solving complex compilation when I get almost nothing for this.


To sum:

While Rust is great for simple tasks, such as string parsing, regex pattern, and a short lived tasks that do not save object oriented state in the memory, we can use rust. In such case the compiler complexity is somehow relatively small pain. 

In case we want complex state using object oriented design, do not waste time on rust. Instead use Java or Go or even C++. 



Sunday, July 9, 2023

Rust Cargo Workspaces

 



In this post we will review the steps to create a multi workspaces rust project.


For this example we will create a flags parsing library that gets settings from the arguments and from the environment variables, while using defaults if the setting is not configured.


Creating the workspace and crates


First we create a new folder for the workspace, and add the binary create to the project:

mkdir flagger
cd flagger/


Create a Cargo.toml file with the following content:

[workspace]

members = [
"flags_printer",


And then run:

cargo new flags_printer

 

Next we add a library to parse the flags.
We update the root Cargo.toml file:

[workspace]

members = [
"flags_printer",
"flags_parser",
]


and create the library crate:

cargo new flags_parser --lib

lastly we add dependency in flags_printer to the flags_parser in flags_printer/Cargo.toml

[dependencies]
flags_parser = { path = "../flags_parser" }


Creating the parser code

The main.rs:


use flags_parser::FlagsParser;

fn main() {
let mut parser = FlagsParser::new();
parser.configure_flag("runs","1");
parser.parse_flags();
}


The lib.rs:


use std::collections::HashMap;
use std::env;

pub struct FlagsParser {
values: HashMap<&'static str, &'static str>,
}

impl FlagsParser {
pub fn new() -> Self {
return FlagsParser {
values: Default::default(),
};
}
pub fn configure_flag(
&mut self,
name: &'static str,
default_value: &'static str,
) {
self.values.insert(name, default_value);
}

pub fn parse_flags(
&mut self,
) {
let mut last_key = "";
for argument in env::args() {
if last_key != "" {
let value:&str = Box::leak(argument.into_boxed_str());
self.values.insert(last_key, value);
last_key = ""
} else {
for (key, _) in &self.values {
if argument == "--".to_owned() + key {
last_key = key;
}
}
}
}

println!("{:?}",&self.values)
}
}




Monday, July 3, 2023

Rust closures ans iterators

 



Rust provides closures and iterators to enable functional programming. In first look it looks great, like the same nice functional programming in other programming languages, but a deeper check exposes that rust suffers from non friendly requirements. See the following example which demonstrates the weird iterators and closure interactions.



fn main() {
let mut updated_numbers: Vec<i32> = Vec::new();
let numbers = vec![1, 5, 4, 7, 8, 9];

// long and explicit definition of a closure
let decrement_number = |x: &i32| -> i32{
println!("decrement a number");
// here we access a variable from outside the closure scope
updated_numbers.push(x.clone());
x - 1
};

// short hand implicit definition of a closure
let increment_number = |x| x + 1;

// we use iterators to create new vectors
let incremented: Vec<i32> = numbers.iter().map(increment_number).collect();
let back_to_origin: Vec<i32> = incremented.iter().map(decrement_number).collect();


println!("numbers {:?}", numbers);
println!("incremented {:?}", incremented);
println!("and decremented back {:?}", back_to_origin);
println!("we've updated the following {:?}", updated_numbers);


/*
It turns out functional programming in rust is no fun!
iter() - creates a pointer to the items
filter() - creates another pointer to the pointer to the items
hence, we have a double pointer in the filter, very unexpected behavior
*/
let filter_even = |x: &&i32| -> bool { return *x % 2 == 0 };
let even: Vec<i32> = numbers.iter().filter(filter_even).map(|x: &i32| -> i32 { *x }).collect();

/*
This emphasise the complex rust internals.
we must redefine the closures since the order of actions is different
*/
let filter_even = |x: &i32| -> bool { return x % 2 == 0 };
let decrement_number = |x| x -1;
let odd: Vec<i32> = numbers.iter().map(increment_number).filter(filter_even).map(decrement_number).collect();

println!("even numbers are {:?}", even);
println!("odd numbers are {:?}", odd);
}