Category Archives: coding

Golang ElasticSearch for beginners

(You may not be familiar with what elasticsearch is : for a good introduction checkout this post from Igor Kopanev)
Extracting data from ElasticSearch in golang is not a simple task. First of all you might not be the one who wrote data into it so these are some commands to find out how is data structured in your ES server :

List all your indexes

$ curl https://<your-server>/_aliases?pretty=true
  "billingdata" : {
    "aliases" : { }
  "checkpoints" : {
    "aliases" : { }

Your indexes data structures can be queried with :

curl https://<your-server>/<index_name> 

Now that I had an idea of how data was structured I started looking at the ES official library ( ) to find out that it is probably not used that much directly. This a code example to execute a query :

  // Build the request body.
  var buf bytes.Buffer
  query := map[string]interface{}{
    "query": map[string]interface{}{
      "match": map[string]interface{}{
        "title": "test",
  if err := json.NewEncoder(&buf).Encode(query); err != nil {
    log.Fatalf("Error encoding query: %s", err)
  // Perform the search request.
  res, err = es.Search(

Then (God bless Oliver Eilhard) I ray of light came in through my window and I found this package : that makes everything much more simple :

	searchResult, err := es6.Search().
		// Query(timerangeQuery). // if you need to filter
		Do(context.Background()) // execute

Much better. If you need a time range query :

// sdate,edate are time.Time	
timerangeQuery := elastic.NewBoolQuery().

Or maybe you need to query by time range and field value :

companyQuery = elastic.NewTermQuery("company_id", CompanyId)
// combine queries :
CombinedQuery = elastic.NewBoolQuery()
CombinedQuery = CombinedQuery.Must(timerangeQuery).Must(companyQuery)

// now search using Query(CombinedQuery)

Setting up your ES Client is pretty easy :

	// Create a custom HTTP client to setup timeouts and TLS config
	// esHTTPClient := &http.Client{
	// 	Timeout: time.Second * 10,
	// 	Transport: &http.Transport{
	// 		Dial: (&net.Dialer{
	// 			Timeout: 5 * time.Second,
	// 		}).Dial,
	// 		TLSHandshakeTimeout: 5 * time.Second,
	// 		TLSClientConfig: &tls.Config{
	// 			InsecureSkipVerify: true,
	// 		},
	// 	},
	// }

	// Create a client
	client, err := elastic.NewClient(
		// elastic.SetHttpClient(esHTTPClient),

You can also aggregate data easily, sum, avergage. I’ll come up with more examples as soon as I have some working code.

October reading list

“simplicity, or the art of maximizing the work not done” : I really like this sentence, from Marco Cecconi Kind of summarizes my thoughts around simplicity in software, removing accidental complexity, over engineering code, get rid of complex and slow learning curve tools and languages. Thanks to Orfware for reference to Marco.


Golang elasticsearch API : kudos to Oliver Eilhard for his package!

What is Software Development ?

According to Steve McConnell “Code Complete” there are plenty of metaphors out there:

This last view seems to be shared by many ( , Jeff Atwood likes it too and I feel close to him on really many things) and I tend to see it more close to what software development is today : a continuously changing (growing) artifact, not totally manageable, that requires constant maintenance (here the building metaphor fails a bit), designed and redesigned over time like a garden, subject to seasons (“lots of new requirements” season, “robustness and reliability” season).

September reading list

Nice article on gRPC in a js client, Envoy and go gRPC server

Reaction/rejection to complexity and “worse is better”

Some points to further investigate : the main idea is that early 2000 years started a reaction to (unnecessary) complexity :

start here :

simple is better (worse is better) : the point here is all about what is considered to be better. Some furher reading “what’s wrong with word simple

Why use inheritance when a simple object will do :

optimism in coding is dangerous :

worse is better :

worse is better

again :

Mar 2020 reading list

Image optimization and compression is one of main features of ImageEngine CDN (I work on this project). This Netflix blog article is great at going into details of why we probably need a new, modern image format : “AVIF for Next-Generation Image Coding”

Faster Paint Metrics with Responsive Image Optimization CDNs

Speed up Woocommerce with an Image CDN

Faster Image delivery with Chrome Light mode

How to Reduce the Carbon Footprint of Your Website by 50%

Images are not static content

Prepare for the Ultimate Gaslighting

TeamCity : pin and tag a build using the REST API from inside the script

We use Teamcity for most of automation in building/testing/deploying golang microservices to prod and during test phase I wanted to be able to notice easily if an integration/benchmark test crashed a microservice. Pinning the build and tagging it with the word “panic” seemed to be a good idea, from inside the buildconf script :

# txt are are the microservice logfiles, substitute as neeeded
grep panic.go *.txt
if [ $retVal -eq 0 ]; then
   # grep found panic in some file, tag with panic
   nohup sh -c 'sleep 10 ; curl --header "Origin: https://<your_tc_server>" --header "Authorization: Bearer <yourbearertoken>" --request POST "%teamcity.serverUrl%/app/rest/builds/" --data panic --header "Content-type: text/plain"' &
   nohup sh -c 'sleep 10 ; curl --header "Origin: https://<your_tc_server>" --header "Authorization: Bearer <yourbearertoken>" --request PUT "%teamcity.serverUrl%/app/rest/builds/"' &

Took more than expected to figure out this : some examples would be helpful. Note that the build needs to be finished to be able to pin it/tag it so we have to put this ugly sleep to postpone operations on the rest api when the build is finished.


On the importance of design in software

Many time we face situation were productivity of a software team is impaired by initial flaws in system design. These initial flaws require too much time to be completely removed (the effort of complete rewrite is only marginally touched here and is normally and indication of other problems in your software project )

So, in order for a software team to be able to work at its maximum, good design is a must. Design is much more responsible for productivity than any single coder, scrum master, product manager or development methodology/language in the sense that bad design can take an all-star team using top tools/methodology to perform badly.

There were times when it was taken for granted that before building a system, it was necessary to design it. That time looks gone (even though Agile does not explicitly prohibit making good design). The general idea seems to be that there is “never enough time to do something right, but there’s always enough time to do it over” again.

But what is design in software ?

That kind of intellectual activity which creates a whole from its diverse parts may be called the design of a system

Melvin E. Conway, How Do Committees Invent?

So you compose parts to make the whole system. How you do this ?

It is basically decomposition to generate single parts that acting together will generate the goal. The 2 tools you will need as a designer are :

  • decomposition
  • composition

 But first of all you need :

  • understanding of the system boundaries : the borders of the nation your system lives in
  • understanding the global scenario of what your system is going to do. Designing subsystems without knowing the whole picture is not a good idea.

Why decomposition of a system into smaller components (services) is good for you :

  • information hiding : well identified interfaces create a contract that the component has to provide, hiding any network/system implementation details. This will make the component implementation completely free to be modified/enhanced as long as the new implementation is compliant with the contract.
  • less development time : separate components/services can be developed in parallel since they don’t require (or require little) external dependencies, so less contention between engineers. Every component is independent on integration and performance test that can be developed autonomously.
  • scalability : with little effort in design every component might be deployed in a way to be one of many instances that will make that service scalable when traffic increases.
  • clarity : the system could be studied a component (service) at a time with the result that the whole system could be better designed because it was better understood

We could go on here and analyze what are the criteria to be used in decomposing a system into services. I’ll leave this to another moment and you can find some interesting notes here :

What I would like to stress is that design is a fundamental phase in software engineering. You can’t just skip it and pretend that since you have a good team you’ll get a good job done.

Thanks to the following for inspiring me on this post :

Thanks year 2000 : less is (immensely) more (the 90s produced a lot of crap)

Thanks to god after year 2000 information technology has started moving towards more pragmatic, simple and effective tools and languages. Some examples that in my opinion make this evident : 

Languages and language tools

  • go, rust, swift are all born with the goal of simplifying their direct parents (c++, objectiveC) and removing their pitfalls.
  • UML abandoned : this is a relief for all coders which had to deal with it. I don’t know anyone using it nowadays.
  • git : finally some one (thanks Linux Torvalds) simplified svn/sourcesafe by putting features that are needed by developers in a clear, pretty intuitive command line interface
  • atom/sublime : reaction to the complexity of Visual Studio, IBM Rational, Eclipse ? I think yes


  • Key-value stores/noSQL are just taking ER/SQL model and making it simpler, providing only the features needed in 99% of the applications. Boyce-Codd normal form is pretty nice and interesting but in real world applications you’ll never use it. 
  • Object Databases completely disappeared and in some way also the idea that OO methodology/hierarchy could be applied everywhere (just because you are where using OO languages)


  • docker/rkt are slim alternatives to virtualization and virtual machines


  • plain old REST API aren’t just a simple way for doing things without having to Corba/Soap ?
  • gRPC : provides corba like features while being 1 order of magnitude more efficent and portable on any platform.

What I’m saying is that the 90s produced a lot of unnecessarily complicated tools and technology which developer just did not need/like which is being progressively substituted with simpler stuff.

Interesting to note that the phrase “Less is more” is originally attributed to Mies Van Der Rohe for his minimalism in architecture design . Looks at his buildings : nothing more than necessary and functional elements are present.

But before him Leonardo da Vinci : “Simplicity is the Ultimate Sophistication”