Introduction

This article is the continuation of the “Eureka Advent Calendar 2025”.

We built a protobuf plugin that automatically generates authorization maps from proto file annotations, enabling seamless role-based permission management for gRPC/HTTP APIs.

Who Should Read This Article?

This article is ideal for:

• Backend engineers looking to implement authorization systems in microservices architectures, particularly those working with gRPC and protobuf.
• Platform engineers interested in code generation tools.
• Go developers curious about the protobuf ecosystem, code generation patterns, and building custom protoc plugins.

Prerequisites: Basic familiarity with APIs, Go programming, and general understanding of microservices concepts. No strong prior protobuf or gRPC experience required. I may explain these along the way briefly.

At Eureka Inc, we were building a new API service that needed role-based authorization. Managers required full permissions (create, read, update,
delete) while regular users needed only read access.

Rather than maintaining separate authorization configuration files, we wanted our API permissions to live directly alongside our API definitions in
our protobuf files, a true single source of truth.

This article shows how we built a custom protobuf compiler plugin with AI assistance to automatically generate authorization code from proto
annotations.

The technologies and frameworks involved

• protobuf (Protocol Buffers) is a system for serializing structured data developed by Google. It utilizes a specialized Interface Definition Language (IDL) to define the structure of data and service interfaces.
• gRPC, a Remote Procedure Call (RPC) framework that can run in any environment and can efficiently connect services. It also allows us to have API documentation and server code interfaces automatically generated.
• On top of that, we added gRPC Gateway, a plugin of the Google protocol buffers compiler protoc. It reads protobuf service definitions and generates a reverse-proxy server which translates a RESTful HTTP API into gRPC.

Since we were already using protobuf as a way to generate OpenAPI documentation automatically whenever new endpoints were added in the proto files, we thought that having the permissions written directly in those proto files and having the permissions generated automatically at the same time would be quite convenient for engineers, so we decided to give it a try.

Once our solution was implemented, we ended up having an automatically generated map of endpoints and permissions ready to be used in our application that looks like this ⬇️

syntax = "proto3";

service TestService {
  rpc TestNoPermissions(TestNoPermissionsRequest) returns (TestNoPermissionsResponse) {
    option (google.api.http) = {
      post: "/v1/test/{foo_id}"
      body: "*"
    };
    // No auth is required for this endpoint
    option (proto.v1.authz) = {no_auth_required: true};
  }

  rpc TestWithPermissions(TestWithPermissionsRequest) returns (TestWithPermissionsResponse) {
    option (google.api.http) = {
      post: "/v1/test2/{foo_id}"
      body: "*"
    };
    // This endpoint requires READ access
    option (proto.v1.authz) = {permissions: ["read:all"]};
  }
}

// generatedAuthzMap contains authorization rules extracted from 
// the proto definitions above.
// This map is automatically generated when the `buf generate` command is executed.
var generatedAuthzMap = map[string]AuthzRule{
 "/v1/test/{foo_id}|POST": {
  Permissions:    []string{},
  NoAuthRequired: true,
 },
 "/v1/test2/{foo_id}|POST": {
  Permissions:    []string{"read:all"},
  NoAuthRequired: false,
 },
}

// example usage
if hasPermissions(generatedAuthzMap, reqEndpoint, reqMethod, userPermissions) 
{ ... }

⬆You can see that this generated authorization maps is actually mapping HTTP endpoints instead of gRPC methods. Normally, the gRPC-Gateway works by translating HTTP/JSON → gRPC request and then making a real gRPC network call to the gRPC server. But in our setup, we simplified it, the gateway and gRPC server are running together inside the same process.

Instead of sending a new gRPC request over the network, the gateway directly unmarshals JSON into the generated Protobuf models and passes them straight into our service implementation. As a result, no more gRPC transport layer and double marshalling involved.

Doing this non-recommended way to run gRPC gateway has advantages, but it made us have to use an HTTP middlewares instead of a gRPC interceptor to check our authorization system, which is why the generated authorization map is mapping actual HTTP endpoints and HTTP methods.

At the end of this article, you will be learning about the protobuf compiler and plugin, navigate through the different go packages that ended up being used by the AI Agent and learn about them, and more.

Why this project was perfect for AI-assisted development

Clear requirements, uncertain implementation 💡

The Goal: we needed to automatically generate authorization code from our proto files. Instead of manually maintaining a separate authorization configuration, we wanted our API permissions to live directly alongside the API definitions in our protobuf files ( to really push that single souce of truth idea ).

The Challenge: while we knew exactly what we wanted to achieve, some of us didn’t have experience building a protobuf compiler plugin before. Protoc ( protobuf compiler ) plugins are specialized tools that extend the protobuf compiler to generate custom code. In our case, authorization mapping. This involved learning an entirely new ecosystem of APIs, and conventions.

This is the sweet spot for AI: clear goals combined with technical uncertainty about implementation ideas.

Code generating code 🫨

Meta-programming (writing programs that write programs) presents cognitive challenges:

• Debugging becomes complex because errors can exist in either the generator or generated code.
• Template-like code generation requires careful escaping and formatting.

AI assistance is quite helpful there because it catches template formatting issues that are easy to miss and avoid you headaches to some extent 😅.

Text parsing complexity 🔎

Proto files, while structured, are ultimately text files with complex syntax rules:

• Nested brace structures for method definitions and options
• Multiple comment styles (// and `/* */`) that need to be handled
• Whitespace variations and formatting differences across teams
• etc.

These parsing challenges involve algorithmic complexity that AI can help iterate through. Rather than spending hours debugging regex patterns or brace-counting logic, AI can help rapidly prototype and refine parsing algorithms.

AI-Assisted Discovery: Learning the protogen Framework

Rather than spending days reading documentation and examples, we were able to rapidly explore the protogen ecosystem which ultimately allowed us to generate custom Go code from .proto files, understand its conventions, and implement our solution iteratively.

Here’s how we navigated this unfamiliar ecosystem with AI as our guide.

Usage of buf.gen.yaml

buf.gen.yaml is a configuration file specifically designed for code generation.

version: v2
clean: true
managed:
  enabled: true
  disable:
    - file_option: go_package_prefix
plugins:
  // Generate go code from the proto file
  - local: [go, tool, google.golang.org/protobuf/cmd/protoc-gen-go]
    out: ./gen
    opt:
      - paths=import
  // Generate the authorization map from the custom annotations added in the proto files
  - local: [go, run, ./protoc-gen-go-authz]
    out: ./gen
    opt:
      - paths=source_relative
    strategy: all

It is used by the buf generate command to define how Protobuf plugins are executed to generate code from your proto files.

When we run buf generate, tools like buf or protoc read the .proto definitions and produce strongly typed Go code, including message structs, service interfaces, and REST handlers.

It ensures all team members produce consistent code and makes it easy to add custom plugins like the authorization one we added.

How AI helped navigate unfamiliar APIs and conventions:

The process is mainly separated into two parts:

• main.go = Orchestrator (High-Level)
• parser.go = Algorithm Worker (Low-Level Details)

The full code is written in this open-source repository, but to give you an insight:

main.go never touches regex, file I/O, or string parsing. It just says:

“Hey parser, give me the authz rules annotations from these proto files”

parser.go does all the dirty work:

“I’ll read the files, count braces, strip comments, parse permissions, and hand you clean authzRule structs”

This is separation of concerns: the orchestrator stays clean and delegates complex parsing logic to a specialized component.

So let’s dive into what exactly those files are doing.

The main orchestration file

The main.go file serves as the high-level orchestrator for our plugin. Its primary responsibility is to interface with the protobuf compiler ecosystem and delegate the complex parsing work to specialized components. Here’s how it’s structured:

1. Plugin Initialization and Feature Support

First, we set up the plugin capabilities and entry point:

package main

import (
    "google.golang.org/protobuf/compiler/protogen"
    "google.golang.org/protobuf/types/pluginpb"
)

func main() {
    // Tell protoc what features our plugin supports
    plugin.SupportedFeatures = uint64(pluginpb.CodeGeneratorResponse_FEATURE_PROTO3_OPTIONAL)

    // Start the plugin
    protogen.Options{}.Run(func(plugin *protogen.Plugin) error {
        return generateAuthzCode(plugin)
    })

The SupportedFeatures declaration is important. Without this, protoc assumes we’re a legacy plugin and might not send us newer protobuf features or generate warnings in some cases.

2. The Core Generation Loop

The heart of our orchestrator iterates through proto files and delegates parsing:

func generateAuthzCode(plugin *protogen.Plugin) error {
  // Create output file
  filename := "authzmap/generated_authz_map.go"
  gen := plugin.NewGeneratedFile(filename, "github.com/aymenworks/public-medium-protocgen/gen/authzmap")

  parser := newProtoAuthzParser()
  var allAuthzRules []authzRule

  // Process each proto file
  for _, file := range plugin.Files {
   // Fitler files that shouldn't be generated ( value will be false )
   if !file.Generate {
    continue
   }

   rules := parser.parseFile(file)
   allAuthzRules = append(allAuthzRules, rules...)
  }

  // Always generate the authz map file, even if empty
  // This ensures the package exists for imports
  generateAuthzMapFile(plugin, allAuthzRules)

Notice how main.go never touches regex, file I/O, or string parsing. It stays at the orchestration level.

3. Code Generation with protogen’s Magic

The gen.P() method is where the magic happens. It’s generating our file content that will contain our authorization map, utility functions, struct, etc.

It looks simple but handles complex plumbing:

func generateGoCode(gen *protogen.GeneratedFile, rules []authzRule) error {
    // Generate package header
    gen.P("// Code generated by protoc-gen-go-authz. DO NOT EDIT.")
    gen.P("package authzmap")
    gen.P()
    gen.P("import \"strings\"")
    gen.P()

    // Generate struct definition
    gen.P("type AuthzRule struct {")
    gen.P("    Permissions    []string")
    gen.P("    NoAuthRequired bool")
    gen.P("}")
    gen.P()

    // Generate the authorization map
    gen.P("var generatedAuthzMap = map[string]AuthzRule{")
    for _, rule := range rules {
        gen.P("    \"", rule.endpoint, "|", rule.method, "\": {")
        gen.P("        Permissions:    []string{", formatPermissions(rule.permissions), "},")
        gen.P("        NoAuthRequired: ", rule.noAuthRequired, ",")
        gen.P("    },")
    }
    gen.P("}")

    return nil
}

Instead of using protogen.GeneratedFile and gen.P(), Why not just use os.Create() and write files directly?

The protogen.GeneratedFile and gen.P() pattern exists because:

Protocol compliance:

1. protoc compiles the .proto files into a structured representation and packages this information into a CodeGeneratorRequest.

// https://github.com/protocolbuffers/protobuf-go/blob/v1.36.10/compiler/protogen/protogen.go#L69
func run(opts Options, f func(*Plugin) error) error {
 if len(os.Args) > 1 {
  return fmt.Errorf("unknown argument %q (this program should be run by protoc, not directly)", os.Args[1])
 }
 in, err := io.ReadAll(os.Stdin)
 if err != nil {
  return err
 }
 req := &pluginpb.CodeGeneratorRequest{}
 if err := proto.Unmarshal(in, req); err != nil {
  return err
 }

2. Our protoc plugin receives this request, processes the descriptions and annotions, generates the desired code ( whatever we want to do with our plugin ), and then packages the results into a CodeGeneratorResponse.

// https://github.com/protocolbuffers/protobuf-go/blob/v1.36.10/compiler/protogen/protogen.go#L69
func run(opts Options, f func(*Plugin) error) error {
  ...
   resp := gen.Response() // CodeGeneratorResponse
   out, err := proto.Marshal(resp)
   if err != nil {
    return err
   }
   if _, err := os.Stdout.Write(out); err != nil {
    return err
   }
}

3. protoc receives the CodeGeneratorResponse and handles the final output, such as writing the generated code to files.

protogen.GeneratedFile and gen.P() are specifically designed to build this response, abstracting away the low-level details of interacting with protoc which is why it’s pretty convenient.

Simplified Code Generation:

gen.P() provides a convenient way to write lines of code to the generated file. It handles indentation, line breaks, and other formatting aspects, making the plugin code cleaner and easier to read compared to manually concatenating strings and adding newlines.

4. What AI Helped Us Learn

Working with an unfamiliar framework like protogen, AI assistance was invaluable for understanding:

• The stdin/stdout communication protocol between protoc and plugins
• Why plugin.SupportedFeatures matters for modern protobuf features
• Which of theplugin.Files have file.Generate = true ( only the PRJ files for our config )
• The buffering strategy behind GeneratedFile which will not write into the file until the plugin finished executing.

The parser file

While main.go handles orchestration, parser.go does the heavy lifting of extracting authorization information from proto files. This is where AI assistance truly shined, helping us navigate complex text parsing challenges that would have taken days to debug manually.

golang-proto-authorization-plugin/protoc-gen-go-authz/parser.go at main · Aymenworks/golang-proto-authorization-plugin

The Challenge: Parsing Proto Files as Text

Here’s what we needed to extract from our proto files:

service TestService {
  rpc TestWithPermissions(TestWithPermissionsRequest) returns (TestWithPermissionsResponse) {
    option (google.api.http) = {
      post: "/v1/test2/{foo_id}"
      body: "*"
    };
    option (proto.v1.authz) = {
      permissions: ["read:all"]
    };
  }
}

From this, we need to extract:

• RPC method name: TestWithPermissions
• HTTP path: /v1/test2/{foo_id}
• HTTP method: POST
• Permissions: ["read:all"]
• Whether auth is required: false (since permissions are specified)

1. Parser Structure and File Processing

The parser is organized as a struct with methods for processing different levels of the proto file:

// protoAuthzParser handles parsing of authz options from proto files.
type protoAuthzParser struct {
    authzExtensionNumber protoreflect.FieldNumber
}

func newProtoAuthzParser() *protoAuthzParser {
    return &protoAuthzParser{
        authzExtensionNumber: 50001, // proto.v1.authz extension number from option.proto
    }
}

// parseFile extracts all authz rules from a proto file.
func (p *protoAuthzParser) parseFile(file *protogen.File) []authzRule {
    rules := make([]authzRule, 0, len(file.Services))

    for _, service := range file.Services {
        serviceRules := p.parseService(service)
        rules = append(rules, serviceRules...)
    }

    return rules
}

// parseService extracts authz rules from all methods in a service.
func (p *protoAuthzParser) parseService(service *protogen.Service) []authzRule {
    rules := make([]authzRule, 0, len(service.Methods))

    for _, method := range service.Methods {
        rule, err := p.parseMethod(method)
        if err != nil {
            // Skip methods without authz options - this is normal
            continue
        }
        rules = append(rules, rule)
    }

    return rules
}

You can see that there are ready-to-use utilities methods from the protogen library such as file.Services and service.Methods giving us access to the list of services and methods within the proto files.

2. Method Parsing and File-based Extraction

The core method parsing delegates to file-based text parsing when protobuf descriptors don’t contain our custom extensions:

// parseMethod extracts authz rule from a single method.
func (p *protoAuthzParser) parseMethod(method *protogen.Method) (authzRule, error) {
    // Extract authz permissions and no_auth_required flag
    permissions, noAuthRequired, err := p.extractAuthzOptions(method)
    if err != nil {
        return authzRule{}, fmt.Errorf("failed to extract authz options: %w", err)
    }

    // Extract HTTP information
    httpPath, httpMethod, err := p.extractHTTPInfo(method)
    if err != nil {
        return authzRule{}, fmt.Errorf("failed to extract HTTP info: %w", err)
    }

    return authzRule{
        HTTPPath:       httpPath,
        HTTPMethod:     httpMethod,
        Permissions:    permissions,
        NoAuthRequired: noAuthRequired,
    }, nil
}

// extractFromProtoSource extracts permissions and no_auth_required by examining the proto source.
func (p *protoAuthzParser) extractFromProtoSource(method *protogen.Method) ([]string, bool, error) {
    // Get the proto file path and read it
    protoPath := method.Desc.ParentFile().Path()
    methodName := string(method.Desc.Name())

    // Extract from the proto file content for any service/method
    return p.extractAuthzFromProtoFile(protoPath, methodName)
}

3. HTTP Information Extraction using Protobuf Extensions

For HTTP path and method extraction, we use protobuf’s built-in extension system:

service TestService {
  rpc TestWithPermissions(TestWithPermissionsRequest) returns (TestWithPermissionsResponse) {
    option (google.api.http) = {
      post: "/v1/test2/{foo_id}"
      body: "*"
    };
    option (proto.v1.authz) = {
      permissions: ["read:all"]
    };
  }
}

// extractHTTPInfo extracts HTTP path and method from google.api.http annotation.
func (p *protoAuthzParser) extractHTTPInfo(method *protogen.Method) (string, string, error) {
    methodOpts := method.Desc.Options().(*descriptorpb.MethodOptions)

    // Check if google.api.http extension exists
    if proto.HasExtension(methodOpts, annotations.E_Http) {
        httpRule := proto.GetExtension(methodOpts, annotations.E_Http)
        if httpRule != nil {
            return p.extractHTTPInfoFromRule(httpRule)
        }
    }

    return "", "", fmt.Errorf("no HTTP annotation found")
}

method.Desc.Options().(*descriptorpb.MethodOptions) and proto.GetExtension(methodOpts, annotations.E_Http) will get the protobuf method options and check for HTTP extension annotations (annotations.E_Http is the protobuf extension field
number for google.api.http )

From there, we can already get access topost:"/v1/test2/{foo_id}" body:"*"

// extractHTTPInfoFromRule extracts path and method from HTTP rule.
func (p *protoAuthzParser) extractHTTPInfoFromRule(httpRule any) (string, string, error) {
 // The HTTP rule should be a message containing HTTP info
 msg, ok := httpRule.(protoreflect.ProtoMessage)
 if !ok {
  return "", "", fmt.Errorf("HTTP rule is not a proto message")
 }

 reflectMsg := msg.ProtoReflect()
 fields := reflectMsg.Descriptor().Fields()

 // Check for different HTTP methods (get, post, put, delete, patch)
 for i := range fields.Len() {
  field := fields.Get(i)
  log.Printf("field: %s\n", field.Name())
  if !reflectMsg.Has(field) {
   continue
  }

  switch field.Name() {
  case "get":
   path := reflectMsg.Get(field).String()
   return path, "GET", nil
  case "post":
   path := reflectMsg.Get(field).String()
   return path, "POST", nil
  ....
  }
 }

 return "", "", fmt.Errorf("no HTTP method found in rule")
}

The HTTP rule is a protobuf message, so protobuf
reflection is used to inspect it with ProtoReflect. In this case, reflection is used to get all the HTTP methods from the annotation as well as the actual field values ( in our case, post )

4.Brace counting algorithms, regex patterns to handle whitespace variations, etc.

You can see more details of its usage and specificities in the open-source repository code.

5. Where AI Made the Difference

Working on this parser, AI assistance was invaluable for:

• The usage of ProtoReflect: AI helped find out which protobuf fields and methods to use right away
• Regex refinement: Iteratively improving regex patterns to handle whitespace variations and optional elements
• etc.

The most challenging aspect was that proto files aren’t just structured data. They’re text files with complex syntax that can vary significantly in formatting. AI helped us build a robust parser that handles proto files.

Challenges debugging code that generates code

Obviously, if you don’t take the time to understand in detail how the generated code works, you will have a tough time debugging and investigating issues with the generated code.

So while it’s very convenient for discovery and explanations, it may be worth taking the time to give the generated code a read/catchup.

Key Takeaways

Building this protobuf authorization plugin taught us valuable lessons about when and how to leverage AI effectively in software development.

When AI excels

Unfamiliar APIs discovery/catchup, boilerplate code, pattern recognition with complex parsing logic. Without AI assistance, those would have been extremely time-consuming.

Where to be careful

Although everything ended up being smooth, it was not that easy from the beginning.

• Poor instructions made the AI agent create a plugin that was “dumb”. As an example, the plugin is supposed to read the proto files every time and generate the authorization map for it, but the initial AI creation ended up having hardcoded authorization map code in the plugin directly which prevented it from being dynamic at all
• It didn’t right away handle parameterized path parameters such as /foo/{id}/create and ended up having issues with those. When the algorithm was trying to match /foo/2/create , it wasn’t able to match both requests, even thought they do. So we had to do back-and-forth communicating with the agent to support those cases.

Wrong communication can lead the AI agent to generate code that you don’t expect or that doesn’t cover edge cases, so doing back-and-forth communicating with the AI agent is recommended to make sure the alignment is clear, edge cases are covered, and ideally have some unit test ready!

You can find the open-source repository in the link below allowing you to use and experiment with the protoc plugin as you wish

• https://github.com/Aymenworks/golang-proto-authorization-plugin

How We Built an API Authorization System with a Protobuf Plugin and AI Assistance from proto file… was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

🎅🏻 This post is part of the Eureka Advent Calendar 2023 🎅🏻

I have been living in Japan for a few years now and except my hometown France, it's been a long time since I have been outside Japan.

At the end of September, me and my coworker and friend James had the opportunity to travel to San Diego in California to attend the GopherCon 2023 .

I want to thank Eureka, our company, who sponsored our conference trip and gave us the opportunity to meet new people, learn and experience new things.

Eureka aims to make dating a social norm in Japan. We're developing one of the top matching application Pairs , released in October 2012, which is the most used love/marriage matching app in Japan (*1) with over 20 million registered users (*2) in Japan.

We are hiring and have different roles available, so if you're interested, feel free to send me a message on Twitter.

The conference happened over four days, the first two being workshops focused and the last two being talks focused. There were also many talks from light to deeper ones, tech to non-tech ones.

Some people may already have written articles about things they learned at the conference, or dive-in into specific talk like my coworker James did about capslock.

What are your Go dependencies capable of?—An introduction to capslock

On my side, I will share a bit of side topics that I found interesting for the community, JSON v2 and Telemetry with Go.

JSON v2

JSON, a text-based data exchange format, is among the top imported package as highlighted by Joe Tsai during the GopherCon.

It's been used for years and over time, desired functionalities and performance limitations were a concern of many people.
At the time of writing this article, there are around 85 proposals for theencoding/jsonpackage.

Desired features

The most desired missing features tend to be the one that overtime required engineers to come up with some hacky way for a specific issue, whether it’s for convenience reason and/or to avoid writing boilerplate code again and again.

One example of it is being able to annotate custom date/time format directly within the JSON tag in order to avoid coming up with hacky way such as having to write a Time wrapper as below.

Before using a Time wrapper:

package main

import (
   "encoding/json"
   "log"
   "strings"
   "time"
)

type GopherCon struct {
   StartDate ConferenceDate `json:"start_date"`
   EndDate   ConferenceDate `json:"end_date"`
}

type ConferenceDate time.Time

func (m *ConferenceDate) UnmarshalJSON(p []byte) error {
   t, err := time.Parse(time.DateOnly, strings.Replace(
      string(p),
      "\"",
      "",
      -1,
     )
    )
   if err != nil {
      return err
   }
   *m = ConferenceDate(t)
     return nil
}

func main() {
   jsonData := `{"start_date": "2023-09-25", "end_date": "2023-09- 28"}`
   var conf GopherCon
   if err := json.Unmarshal([]byte(jsonData), &conf); err != nil {
      log.Fatal(err)
   }
}

After: Now with v2, you will be able to use a new custom struct tag format:

package main

import (
   "log"
   "time"
  
   "github.com/go-json-experiment/json"
)

type GopherCon struct {
   StartDate time.Time `json:"start_date,format:'2006-01-02'"`
   EndDate   time.Time `json:"end_date,format:'2006-01-02'"`
}

func main() {
   jsonData := `{"start_date": "2023-09-25", "end_date": "2023-09-28"}`
   var conf GopherCon
   if err := json.Unmarshal([]byte(jsonData), &conf); err != nil {
      log.Fatal(err)
   }
}

Quite cool and straightforward?

Another example is how it's not seamless to be able to omitempty a struct type field without using pointers. In v2, omitempty has been redefined in terms of the JSON type system, rather than the Go type system.

Before, you needed a pointer on the *Venueobject below to omit it from the JSON when it was not set.

package main

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

type Venue struct {
   Name string `json:"name,omitempty"`
}
type GopherCon struct {
   StartDate time.Time `json:"start_date,format:'2006 -01-02'"`
   Venue     *Venue    `json:"venue,omitempty"`
}

func main() {
   conf := GopherCon{StartDate: time.Date(2023, 11, 10, 0, 0, 0, 0, time.UTC)}
   b, err := json.Marshal(conf)
   if err != nil {
      fmt.Println(err)
   }
   fmt.Println(string(b))
}

// result: {"start_date":"2023 -11-10T00:00:00Z"}

With the v2 version, omitempty will omit the field if the value would have been encoded as an empty JSON value and this is recursively effective:

package main

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

type Venue struct {
   Name string `json:"name,omitempty"`
}
type GopherCon struct {
   StartDate time.Time `json:"start_date,format:'2006-01-02'"`
   Venue     Venue     `json:"venue,omitempty"`
}

func main() {
   conf := GopherCon{StartDate: time.Date(2023, 11, 10, 0, 0, 0, 0, time.UTC)}
   b, err := json.Marshal(conf)
   if err != nil {
      fmt.Println(err)
   }
   fmt.Println(string(b))
}

// result: {"start_date":"2023-11-10"}

If you're interested, you can find more about it in the discussion right here .

Performance

It's impressive how Unmarshal got faster, but if you look at the existing Unmarshal implementation, you can see that there is a caveat.

func Unmarshal(data []byte, v any) error { 
  // Check for well-formedness. 
  // Avoids filling out half a data structure 
  // before discovering a JSON syntax error. 
  var d decodeState 
  err := checkValid(data, &d .scan) 
  if err != nil { 
      return err 
  } 
  
  d.init(data) 
  return d.unmarshal(v) 
}

You can see that in addition to unmarshal at the end, the JSON data first need to be read entirely to check whether it's a valid JSON or not through checkValid. So there are two costly operations.

Even though the existing json cache implementation fields some information and can help process faster the information after its cached once.

func (d *decodeState) object(v reflect.Value) error { 
  ... 
  var fields structFields 
  ... 
  switch v.Kind() { 
  .... 
  case reflect.Struct: 
    fields = cachedTypeFields(t)
  ...
}

It seems that this double parsing for validating the data and finally unmarshalling really makes it heavy anyway.

If you're interested in looking more at the performance, you can find benchmarks there: https://github.com/go-json-experiment/jsonbench.

Telemetry with Go

What is it?

Russ Cox, who, at the time of writing this article leads the development of the Go programming language at Google, made a talk about Go changes and talked to us as well about their proposal to introduce Transparent Telemetry. And started from a discussion.

To make it simple, it will allow some Go tools like the compiler, gopls, and govulncheck, to report some data back to Google for analytics in order to privide better, more effective features and fixes to the community.

Why do we need it?

The main reason is for the Go community to be more happy, obviously. Telemetry would provide different information than user surveys.

The more analytics data collected by the Go team, the more accurately they can suppose whether a feature they released is used as expected or not.

Russ was explaining how Go's new features come from a data-driven process:

• List of proposals in GitHub and everyone discuss it
• Talking to users: go user survey, in-editor survey, research interviews/user experience
• Random Open source code analysis, and regarding the Sampling: the more the better

But those were not enough. Indeed, most of the users report only when they think something is broken, but sometimes what is actually broken may not seem like a bug for users.

An example shared was when in 2020, the 1.14 version of Go contained changes for the macOS distribution ended up unwillingly requiring the users to install the Xcode Developer Tools, when actually this was not expected.

This was not found until late 2022, so two years later, when the Go team found out about it when investigating some stuffs. Users may have thought that this was the expected behavior for MacOS while it actually wasn't and this shows how bug reporting feature is not always effective.

So the idea was to put in place a transparent telemetry through Go tools, and by transparent, it means sharing how the data will be collected, what kind of data, the frequency etc.

If you're interested about the proposed design, you can find more there.

Optional feature instead of by default..

They initially were planning to enable it by default but that made many people worries about it and ended up going with an opt-out option ( not by default ), meaning that users will actually need to be educated about why this is in their benefits to actually enable it, which is very unfortunate as this doesn't always guarantee that the Go team will have enough accurate collected data from Go users to validate new proposals efficiency.

Looking forward for the actual proposed implementation and its roadmap.

You can read more about the details regarding the opt-out decision there.

If you go to San Diego and you're interested in trying good and affordable Mexican foods, Lola 55 was lovely in the East Village.

GopherCon San Diego2023 was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Transition from an iOS engineer to a backend engineer

This is the December 7 article for Eureka’s 2021 Advent Calendar
Nearly one year ago, I transitioned from an iOS engineer position to a Backend engineer position within the same company, Eureka.

Hopefully, I can provide you with some useful insights regarding the transition from an iOS role to a Backend engineer role by writing and sharing about how I proceed to do it and the different steps taken to catch up the technical skills.

The transition from iOS engineer to backend engineer

I joined Eureka in June 2018 as an iOS Engineer. It’s a company developing the dating application Pairs, which help people find their life partners and Pairs Engage which is a digital and affordable Marriage Matchmaking Agency helping people to marry as soon as possible.

Starting with iOS

As an iOS Engineer working for the Pairs Engage product, my contributions and learning were very diverse. Since I joined the project as it just started, I worked with a team of engineers, designer and product owner to design and implement new features from mapping the user journey, user stories, giving UX and UI ideas to developing and shipping the iOS application for new targets/markets.

On the iOS side, it was an honor to work with the friend and teammate John Estropia leading the iOS development with who I learned a lot.

I got the opportunity to work on very interesting tech stacks from:

• A iOS project architecture that is MVVM/Flux reactive based to provide a single source of truth data-wise
• Making delightful experience through very smooth graphics thanks to libraries such as Texture/AsyncDisplayKit
• Implementing face detection to help center the user’s uploaded profile picture to make it easier to notice his facial profile,
• Many more..

We were sometimes doing study-times and pair programming for knowledge sharing, that sometimes resulted in the creation of multiple open source animations challenges available in Github.

If you’re interested to learn more about those animation challenges, you can read the first one right there about the Bear’s iOS search animation.

Why changing to Backend

I think at some point, I wanted to widen my skillset ( horizontally ). When we create iOS apps, we interact a lot with backend engineers. How data is structured and stored, business logic treated, performances for fetching and manipulating data managed, etc. So I got an interest for this team because I thought that as someone with an iOS experience, I may know what may or may not be convenient for front engineers, etc. And learning how things on the API side are done behind the scene are simply interesting.

What’s similar and what’s different

When I started working on API tasks, little by little I started seeing similarities or sometimes big differences both in the way of thinking and the programming languages themselves.

Programming languages differences

Both Swift and Go lang are statically typed, meaning that we need to know the type of properties during compile time, whether it’s inferred or set explicitly, which is good for coding safely 😇.

// go 
s := "Hello" // type of `s` is `string`

----

// swift
let s = "Hello" // type of `s` is `String`

It’s difficult to compare both languages because they are made for different purpose.. Go was apparently made to be scaled across multiple processor which explain its native support for concurrency through only one keyword go yourFunction(), as well as being able to communicate between goroutine using channels, native support for web servers, etc..

In term of language features, in my opinion Swift wins with many features, such as:

• Optional types, which is Swift-way that help you avoid nil pointer exceptions errors as much as possible.

Another example is if you have embed type with nullable properties.

Also, in addition to Optional types:

• Inheritance
• Generics ( coming soon with go! )
• The possibility to add custom operators for any types
• Enum cases and the possibility to check at compile-time that your switch-case is not missing any possible values from your enumeration..
• Many more..

Different challenges

Both platforms have theirs very different challenges

iOS:

Device and iOS Compatibility: supporting old iOS versions to keep as much users as possible, updating the app to resolve the issues that may happen with a new iOS version, fixing layout issues when a new device with a very small or big screen is released, deciding when to stop supporting a specific iOS version, etc.. All those things takes time and work.

App Store rejection: Releasing is not about just pushing a button, it’s about hopping that the released version will not be rejected on the App Store, that it’s not going to be delayed by days before it’s approved..

High Expectations of UX/UI, Graphics: In order to fulfill the user’s need, an important amount of work regarding the experience of an application, its usability, how easy and smooth it is to do something is one of the important challenges that front engineers in general need to deal with.

And many more..

Backend:

Scalability and resilience. Compared to an iOS app where there is usually only one user logged in, servers, depending on the company, have to support a load of millions/hundred of thousands/dozens of thousands/thousands users connected and using the API services at the same time.

So I would say in general, if you can delegate heavy work from your server to someone else, that would be beneficial for your server CPU/memory consumption.

For example, if the server is using Amazon Web Services (AWS) S3 to upload images in buckets and in the case where it’s common for the client to upload heavy pictures on your server, then instead of asking the iOS client to send you a heavy base64 picture or through a multipart request, in which situation both the client and the server have to deal with a considerable amount of resources/memory usage, AWS S3 come up with a nice feature called Pre-signed URL that will allow the client to upload the image directly at a specific URL, thus delegating the work from the server to AWS.

Another example: if one of your database for example is down, having a way to quickly resolve the situation is important. It’s common to have replication of database ( multiple “slave” databases ) that will all have copy of the main (master) database and will always be synchronized ( with a little delay ). Every time a request to fetch data is executed, instead of asking the master database, one of the slave database will be used instead, thus dividing the charge of work.

Infrastructures costs. Since a tons of users may be logged in and using the API services, making sure in general to choose the most optimized solution for an implementation is important as the cost/resource consumption increase proportionally to the number of users using the service. So if you’re implementing for example a login frequency implementation, then make sure for example to compare the pro/cons between different services in term of costs and server resource consumption depending on your needs e.g data has a lifespan, etc. ( MySQL? Amazon AWS DynamoDB? other? )

And many more..

How did the transition from an iOS Engineer to a Backend Engineer happened within my company Eureka

1. Sharing with the manager

I took the first step by sharing what I wanted to do with my manager. I wanted to have his opinion. A few months later, after meeting with the manager of the Backend team, we agreed on the start date.

When I started, I was exchanging closely with the CTO kaneshin and from there a friend and lead backend engineer James Kirk took me under his arms and mentored me all the way till now.

From this graph which kinda summarize some of the important skillsets to have as a Backend engineer, we took it into account as well as the existing tech stacks of our Pairs Engage API project, and we started working on a side project first while being mentored.

2. Started working on a side project first while being mentored

In order to catch up with the minimum required skills to start being productive as soon as possible, working on projects/small tasks and learning fast was necessary.

James Kirk invited me in a weekly 1~2h pair programming meeting that we had and kept for most of the year ( lucky me! )

a) We first looked at the basics or base setup of a server app, meaning what are the things that need to be understood and implemented as soon as someone start a new project.

In a different and new project made specially for experimenting and learning, after having done an interactive introduction to the Go language, we covered some basics things like:

• How environment variable are used within the project for local development: the fact that with environment variable, your project configuration including sensitive data ( API keys, tokens, etc. ) are not stored in your repo but locally in a env/envrc file
• Go mod or how to manage dependencies within a Go Lang project
• The life of an HTTP request in a Go server where we took a look at handlers, middleware, etc.
• Panic handling or how to recover when something bad happens in a request that could crash the server, such as an unhandled fatal error.
• How to implement a Graceful Shutdown through Go’s Signal and Channel mechanisms in order to safely and properly shutdown resources/tasks/connections when the server needs to be turned off.
• And many more..

b) We then moved to the next step that covered:

• Clean Architecture whose ideas/patterns are used within the project. Hands on on implementing a constraint-based architecture where very layer should be independent and testable as much as possible that would allow for example to easily replace any frameworks that we are using, replacing any databases, etc. — -> see more below about it
• The use of Docker and Localstack. Playing with AWS services freely could sometimes be dangerous cost-wise 😅, and since not all of the services have an easy way to work locally on our computer, Localstack was used in the side project in order to be able to interact with different AWS services such as AWS S3, DynamoDB, etc.

GitHub - localstack/localstack: 💻 A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline

• Learning on my side through Udemy classes..

c) From that, I then worked on small tasks that includes bug fixes, code improvement etc in order to get familiar with the project’s code.

As the tasks got bigger and bigger, and I was getting more and more familiar with the project’s code thanks to my team PR reviews and feedbacks and coaching, I started taking in charge bigger and bigger features that were rolled out in production to our users. Again, those tasks were really diverses. Those tasks included for example:

• Reducing the charge of our server for multiple image uploading by using Pre-signed AWS S3 URLs, which delegated the role to upload the image from the server to the client.
• Designing DynamoDB table to implement a login frequency feature ( last 10 days )
• Resolving N+1 problems
• etc..

Hopefully, those insights regarding how I proceed to transition and the different steps taken to catch up the skills and learned were useful for you.

So from those info, don’t hesitate to go talk to your manager if you want to try, and try to find a mentor that can help guide you at the beginning, that would be very helpful!

I would like to thanks my company Eureka for being very encouraging regarding this transition and their support.

We’re hiring in Japan. You can find the list of jobs there.

Careers - Eureka, Inc.

If you’re interested, don’t hesitate to send me a private message on my twitter account: aymenworks

From an iOS engineer to a Backend Engineer was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animations challenges is actually pretty fun. It’s about picking a random animation in one of the app that we use everyday ( twitter, Facebook, Slack, others .. ) and try to recreate it together by doing Pair Programming.

December 12 was the first day for me or John, both iOS Engineer at Eureka, for our Animations Challenges.

Animations are very funny. When you look at them, they look very simple, but when you try to look closer, you will notice that it involves many changes/sub-animations under the hood, making the end result amazing and almost unnoticed.

So the goal of those animations challenges is to try to analyze those animations and try to replicate them. After that, there will be a blog article showing how we approached this challenge.

For this animation, I had to work on it by myself for the Advent Calendar event. John will join us for another challenge, hopefully!

This post is a part of the Advent calendar organized of Eureka, following the second day article written by Shima in Japanese regarding the implementation of the tooltip on iOS.

Introduction

The third animation I decided to reproduce was the animation from the Zenly Pops animation.

Let’s dive in

Initial state:

I created a quick design to start from. It has a label, background, and a white view.

Observation #1: Faces are falling from the sky!

One of the first observation we can make is that we can see faces falling from top to the bottom.

• They fall one by one
• They fall from different x position
• The way they fall down feels very familiar. It falls faster over time. Similar to taking an orange and letting it fall from a table.

While creating such “falling” animations may be possible using the traditional way to make animation with UIKit and custom curve animations, those animations can easily be made with UIKitDynamics.

UIKitDynamics have a series of classes we can use to communicate to a user how something feels by trying to reproduce real-life physics.

We could divide UIKitDynamics into two:

• Behavior classes: those classes are specific dynamic behavior such as gravity, collision, etc.
• UIDynamicAnimator: the class that will allow us to manage our behaviors above.

To reproduce the falling effect, the behavior we will be first using is the UIGravityBehavior: gravity is an invisible force of attractions that exists between two items. Earth’s gravity is what pulls us on the ground and that’s why items are falling down.

• 1: the class that will allow us to manage our behaviors aka specific dynamic behavior
• 2: We delay the creation of the face view to display them “one by one”
• 3: Faces will have a random size
• 4: x: We position the face randomly in the x-axis, so that faces can fall down from different position, y: negative so that they are falling from above
• 5: We add a gravity behavior for each of our face
• 6: We ask our “manager” to add the gravity behavior, which will automatically trigger the animation.

Which produce this result:

Observation #2: Collisions everywhere!

We can notice that there are not only one type of collisions, but multiples ones:

• Between the faces and the bottom white view
• Between the faces themselves
• Between the faces and the borders of the screen.

The behavior we will be for creating collision-like effects is by using the UICollisionBehavior.

Similarly to the UIGravityBehavior, we will create an instance of it, add a collision behavior for each of our faces and then tell our animator manager to add it.

If you run the code…

…nothing will happen 😅

The reason is that although we made our faces views to have a collision behavior, we didn’t say anything about the rest: the white bottom view, the left edge or even the right edge. Our faces views are not aware of any “walls” or “barriers”, so we need to communicate that.

One way of doing that is by manually adding an invisible “boundary” that will act as an invisible wall. We do that by calling the addBoundary method from the collision behavior and we indicate the path of our white bottom view.

So since we are using the collisionBehavior property inside a different method, we need to move its declaration from inside the viewDidLoad to outside the viewDidLoad.

And the result is:

The white bottom view is now acting like a wall ✅
But wait.. Why are our faces escaping to the left and the right edges now??

Well, similarly to what we did to our white bottom view, we need to create invisible walls for the left and right edges so that our faces can stay within the area.

Since the edges positions are quite straightforward, we can directly add them in the viewDidLoad:

If we run, the result is:

Well… It’s quite bugged 😅 🙄

My guess is that it’s because we didn’t really set physic-related properties in the code such as the friction between the views. We will see that in the next section.

Observation #4: Polishing physics

Let’s take a look again at the original animation:

• One thing we can notice is that the faces views don’t have a big elasticity or even not at all. It’s not as bouncy as a ping-pong ball or a basket ball.
• Another thing we can notice is the friction. Friction is a force that opposes the sliding motion when two object rub each other. When you’re skying, your ski and the snow are in friction. You are still moving fast on top of the snow because the friction is low, which let the motion happens fast. So another observation in this Zenly animation is that it doesn’t look like there is a big friction between the faces views. Face views are almost sliding when they are rubbing into each other.

So let’s try to apply those observations by using a new behavior class, called UIDynamicItemBehavior. This class allows us to customize some real-like physics properties such as elasticity, friction, etc.

And the result is:

It’s better! 🤓

Observation #5: Pan gesture to move items and create chaos!

If you wait till the end of the gif animation, you will notice that items are moving and pushing each other near the end:

The way I approached this behavior is by adding a pan gesture that will push the face view toward the direction of the pan!

By applying the pan gesture to the face view with my finger, I will use a dynamic behavior to translate/push the face view following the velocity of the gesture.

To do that,

and the result as we apply pan movements:

✅ Good job for reading and reaching the end 💪

You can now reproduce a “similar” animation as the Zenly Pops animation!

You learned that sometimes, something that looks like a challenge, once putting enough through on it, can be achieved without struggling too much.

This is the third animation challenge blog article I write, and there is going to be more! So if you have any feedbacks, let me know :).

You can find the full animation project there:

Aymenworks/AnimationsChallenge

If any questions, you can reach me on twitter anytime :).

You can already find the first and second animation challenge right there:

• Animations challenges #1 — Bear iOS Search animation
• Animations challenges #2 — Asana Loader animation

Animations challenges #3 — Zenly Pops Animation was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who I am?

I am Aymen and I am from Marseille, France, working in Tokyo, Japan.

I joined Eureka in June 2018 as an iOS Engineer. It’s a company developing the dating application Pairs, which help people find their life partners 🌸 and Pairs Engage which is a digital and affordable Marriage Matchmaking Agency helping people to marry as soon as possible.

Why I am talking about this topic

One of my goal recently was to be able to help my team with not only my iOS development skills, but also helping with UI/UX if possible.

So I tried to think about an interesting issue we found out that was happening in our product and that I could try to resolve: Some users think that Pairs Engage is like an Online Dating app ( but it’s not, it’s a digital Marriage Matchmaking service )

So I researched about how to change people image/vision about a product and make users feels like this is a digital Marriage Matchmaking service and not only an Online Dating service.

And while I was doing research about how to do that, I found an interesting website called Laws Of UX.

Laws of UX

Jon Yablonski created a list of what he calls UX Laws about User Experience and he believes that by knowing them, you will be able to create more intuitive design.

Why? Because those rules are based on general scientific understanding on how the mind works and so focus on the psychology part of design

So I want to dive in through some of those UX Laws, understand them, and see how it can happens with both physical and digital products.

Aesthetically pleasing effect Law

Did you ever wonder why cheap wine tastes better in fancy glasses? I did. And that’s kind of what is it about.

Researchers Masaaki Kurosu and Kaori Kashimura from the Hitachi Design Center tested 26 variations of an ATM UI and found out that users are strongly influenced by the look and feel of interfaces.

Basically, It means that nice design can make users more tolerant of minor usability issues and prevent issues from being discovered during usability testing.

To have a better understanding of this, if we take a look at the screenshot below:

That would mean that most of the users preferred the screen at the left over the one at the right because of the “better UI”, its look and feel.

When looking more closely, we can see that actually the screen at the left has some issues, such as not being able to correct, erase nor validate manually the pin code like we find in nowadays ATM UI ( right screen ).

Peak End Rule Law

The Peak End Rule says that we don’t remember experiences accurately.
Rather, we tend to recall the highlights and how the experience end ( good or bad end )

A good example is people waiting in a queue for an attraction:

Attractions Parcs like Disney Land have tons and tons of amazing attractions. And so long queues where people wait to be able to do them. After waiting, here we go, it’s time for the fun. It’s usually a short time of fun, excitement, and pleasure in comparison to the waiting queue.

When asking “how was the attraction?” to some peoples, many people may omit the annoying waiting queue in their discussion and just talk about how the attraction was, meaning good or bad.

That shows that how an experience ends is important and that’s what some people may remember the most from an experience.

How does it apply to digital products?

Many things can annoy users when using digital products: a survey, the reading of guidelines, a long and unterminable registration forms etc..

Does having a gift/surprise at the end as a “peak experience” can make the user forget about the boring but necessary survey/form? It can be a coupon, points or whatever makes the user feels like it was not worth nothing.

Hick’s Law

The time it takes to make a decision increases with the number and complexity of choices. Users bombarded with choices have to take time to interpret and decide, giving them work they don’t want.

What are the common points between those two images?

• They both have many options
• Some of them can be complex

For both examples, It can makes the user takes some time to do an action, or, for the case of Netflix, just giving up about watching something..

How to reduce the complexity of choices?

1. One way is to focus on what is important

This example shows how focusing on what is important can help reduce complexity.

For this second example, imagine having to look for a specific country among an unsorted and long list of all countries, compared to a sorted and group-by-continent list.. Using grouping of related informations can help reduce the complexity to find and achieve an action.

Miller’s Law

The average person can only keep 7 (plus or minus 2) items in their working memory.

Which phone number is easier to remember? There is a big change that the second one may be easier, and here is why:

Every time your brain has to remember information, whether it’s a phone number, how to navigate through a website, etc, there is a mental effort.

The problem is that the space in your brain in which this information is processed and stored is limited. Your brain begins to slow down or even abandon the task at hand when it receives more information than it can handle.

This overload can be due to too many choices, too much thought required, or lack of clarity.

Regarding the phone number, chucking is one way of reducing the overload/mental effort. It’s about grouping the long phone number into small group of information easy to remember.

Conclusion

https://lawsofux.com may be a great resource for improving your design-making process and also your arguments during design review since it’s based not on your personal taste or thinking but on scientific studies that can be used to demonstrate and add more value to your arguments when doing design review.t

Psychology in Design was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animations challenges is actually pretty fun. It’s about picking a random animation in one of the app that we use everyday ( twitter, Facebook, Slack, others .. ) and try to recreate it together by doing Pair Programming.

Animations are very funny. When you look at them, they look very simple, but when you try to look closer, you will notice that it involves many changes/sub-animations under the hood, making the end result amazing and almost unnoticed.

So the goal of those animations challenges is to try to analyse those animations and try to replicate them. After that, there will be a blog article showing how we approached this challenge.

If it’s the first article you see from me, you can check it out the cool article there about the Bear iOS app search animation:

Animations challenges #1 — Bear iOS Search animation

For this animation, I worked on it by myself, wihout John. This one is too easy for him 😚.

Introduction

The second animation I decided to reproduce within one hour ( but at the end within a few minutes ) was the loading animation from the Asana iOS app.

Let’s dive in

Observation #1 — A gradient of two colors: Pink and beige

First, we can see that there is probably two colors used in a horizontal gradient. How can we define this in code?

• We define a pink and a beige color
• We also create a gradient layer, aka CAGradientLayer.
• We create an empty setup function. We will get back to this function later. It will take care of setting up the gradient looks we want.

CAGradientLayer is a subclass of CALayer and allows you to create a color gradient with as many colors as you want. But by default, it spreads colors uniformly 😮. But wait! That’s not a problem. There are many customizables properties that allow you to create the gradient color of your dream. Among the properties that we will use, there are:

• startPoint and endPoint of the gradient. Basically it’s where the gradient starts and where it finishes. For exemple, a starting point of x=0.5,y=0 and an end point of x=0.5,y=1 means that the gradient will go from up to bottom. Another exemple: a starting point of x=0,y=0.5 and an end point of x=1,y=0.5 means that the gradient will go from left to right, etc..

So let’s set up the startPoint and the endPoint so that it will be a gradient that will go from left to right:

PS: I set up three colors on the gradient colors property, so that we can clearly see the gradient at the left and right side of the beige color.

If we run the app, it will appears that way:

• The locations. It’s an array of values that will indicate where the gradients colors stops. You can think of it as how much each color should fill the gradient. For exemple, if we want the beige color to be at the end of the gradient ( which is the second color in the array we gave to the gradient.colors property ), we can do something like:

And the result will be:

It’s because we say that the first color ( pink ) will stop at 70%, then the second color ( beige ) will start and finish at 90%, and then the rest will be filled by the third color ( beige ).

If our case, we suppose that the beige color start at the beggining of the gradient and will be animated over time, so let’s set it up:

Observation #2 — The beige color position is changing over time

We can see that the beige color position is changing over time, so how can we do that?

Well, if you look at the locations property documentation, it says:

locations: An optional array of NSNumber objects defining the location of each gradient stop. Animatable. https://developer.apple.com/documentation/quartzcore/cagradientlayer/1462410-locations

Animatable?? Wow! That’s amazing! It literally means that we can just change the locations property in a animation and the work will be done!

So let’s make it work right now!

To achieve that, we will use the convenient CABasicAnimation class that take care of animating CALayer properties very easily by defining a:

• fromValue: the starting value before the animation. In our case it’ll be the start position of our gradient colors ( the beige color starting at the beggining of the gradient ).
• toValue: the end value we want to reach at the end of the animation. In our case it’ll be the end position of our gradient colors ( the beige color moving at the end of the gradient )
• the property name
• any options you want

So , for this article, let’s start the animation when the view appear.

And create our startLoading() function:

• The CABasicAnimation takes into parameter the property name
• You can specify many things such as the duration of the animation or if your animation should loop using repeatCount
• The from and start value
• and more..

Let’s run the app.

Final result

✅ Good job for reading and reaching the end 💪

You can now reproduce a “similar” loading animation as the Asana iOS application

You learned that sometimes, something that looks like a challenge, once putting enough through on it, can be achieved without struggling too much.

This is the second animation challenge blog article I write. If it’s the first article you see from me, you can check it out the cool article about the Bear iOS app search animation.

There is going to be more! If you have any animations you would like to see how to built it, don’t hesitate to add comments below :).

You can find the full animation project there:

Aymenworks/AnimationsChallenge

If any questions, you can reach me or John on twitter anytime :).

Animations challenges #2 — Asana Loader animation was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animations challenges is actually pretty fun. It’s about picking a random animation in one of the app that we use everyday ( twitter, Facebook, Slack, others .. ) and try to recreate it together by doing Pair Programming.

December 12 was the first day for me or John, both iOS Engineer at Eureka, for our Animations Challenges.

Animations are very funny. When you look at them, they look very simple, but when you try to look closer, you will notice that it involves many changes/sub-animations under the hood, making the end result amazing and almost unnoticed.

So the goal of those animations challenges is to try to analyse those animations and try to replicate them. After that, there will be a blog article showing how we approached this challenge.

Before diving into our first challenge, I would like to explain how we proceeed.

Process and conditions

Duration =~1h
Process: Pair programming and Pomodoro Technique

The Pomodoro Technique is about using a timer to break down work into interval. We try to switch every 15 minutes and allow each other to work on it.

It has great advantages, such as allowing both of us making technical decisions while the observer is asking questions making sure we are doing things right.

Introduction

The first animation we decided to reproduce within one hour was the search animation from the Bear iOS app.

Let’s dive in

Observation #1 — Three different states

First, we observed that it involves three different states:

• The search is empty = start or default state
• The search button is full = full state
• The search button is scaled = final state

Let’s create a SearchView with properties that represents those three different states:

PS: We want the progress of the animation to be between 0 and 1.

Observation #2 — Scroll down to reach the goal

Animations happens when we scroll from top to bottom, which means that we have to:

• Decide when the goal (final state) is reached. For exemple, after scrolling about 50 points vertically, it may means that we finished
• Scrolling from top to bottom will generate a negative offset, so since we want to play with positive values, we cast it to a positive value
• Since we are playing with a progress property, we want it to be between 0 and 1 ( 0% a and 100% )

And let’s add an empty search function for now

Observation #3 — Two search buttons?

When looking at it closer, we see that while scrolling, we can see two different stroke colors at the same time for the search icon.

So based on that, we supposed that:

• There are maybe two buttons with the same size but different background and stroke color. The foreground button has a yellow dark background color with white stroke while the background button has a clear background color with a gray stroke
• There is a mask (which can be a CAShapeLayer ) that hide/show a part of the foreground button.
• As the user scroll, we are going to play with the mask path to show and hide the foreground button depending on the progress of the animation

So let’s fill our SearchView class now!

And then let’s layout everything:

Finally, let’s call the setup method when the view is initialized:

Observation #4 — Time to start filling

On the Observation #2, we created an empty update function.
This function will take care of making this animation possible, and the first step is to start reproducing that “fill” animation

There is a mask (which can be a CAShapeLayer ) that hide/show a part of the foreground button.

The role of this mask layer is to show/hide the foreground button (the one with the yellow dark background color), based on the mask path, that’s how we can create this “fill” animation.

If the mask layer path is nil ( default value ), the view it’s associated with ( foreground button ) will not be visible. This is the case right now.

So let’s try to change this mask layer path properties based on the progress of the scroll and see what’s happening:

Wow! It start looking like something already! Let’s just tweak a little bit the starting point of this so that the animation start from the bottom to the top as we want, instead of the opposite.

We are almost there! Now we have to take care of the scaling!

Observation #5 — Scaling to finish

Now that we can reach the full state, we need to make it to the final state when it’s scaled.

Let’s define how big we want the button to grow/scale, where 1.0 is the original size.

But there is one thing..Our update function is already using the progress property to change the mask’s path and fill the button completely when the progress is equal to 1.

But if we look at our animation states, the full state should be reached at 0.7, not 1.0. And from 0.7 to 1.0, it should play the scale animation..

So we have to tweak a little the progress property by shifting it from the interval 0…1 to 0…7.

How can we move from a range of 0…1 to 0…7 ?

Let’s apply some math:

• (progress-newStartInterval) / (newEndInterval — newStartInterval)
• (progress-0)/(0.7–0)

The new update function become:

Last and final step is to add the scaling feature. And there is another range shifting going on: we want to shift the progress from 0…1 to 0.7…1

Let’s apply some math again:

• (progress-newStartInterval) / (newEndInterval — newStartInterval)
• (progress-0.7)/(1–0.7)

So let’s add at the end of the update function the new shifted progress used for scaling the button:

So on the code below, if the progress is bigger than 0.7, then we start scaling based on the new shifted progress, otherwise, we remove the scaling effect;

Final Result

Oh! And if you wanna have the rounded animation like the original animation, then you can make your button a circle:

✅ Good job for reading and reaching the end 💪

You can now reproduce a “similar” animation as the Bear iOS search application

You learned that sometimes, something that looks like a challenge, once putting enough through on it, can be achieved without struggling too much.

This is the first animation challenge blog article I write, and there is going to be more! So if you have any feedbacks, let me know :).

You can find the full animation project there:

Aymenworks/AnimationsChallenge

If any questions, you can reach me or John on twitter anytime :).

Edit: You can already find the second animation challenge right there:

Animations challenges #2 — Asana Loader animation

Animations challenges #1 — Bear iOS Search animation was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

It works very well for team collaboration and allow us to create a better product.

Git tips and tricks #1

You’ll find for this first Git tips and tricks #1 some of them that I think can be useful ( time to time, haha ).

Who added this file ? 🤓

When entering a project, I wanted to check if there was any .gitignore file before creating one. And yes, there was one, and by curiosity, I wanted to check who added it

I was able to figure it out by doing :

git log — diff-filter=A — fileName

commit 4b8d6c960e0850273901f1e0dc9a5de0b3ab7d29
Author: Aymen Rebouh <aymen***@gmail.com>
Date: Wed Oct 19 11:51:20 2016 +0100

Add .gitignore file

If you look at the value affected to the filter ` — diff-filter=A`, `A` means Add, so it works also with `D` for Delete, `M` for Modified, etc…

But this command line is not that easy to remember, right ? By adding this alias :

git config — global alias.whoadded ‘log — diff-filter=A’

You can now do :

git whoadded .gitignore

Better, right ?

Git amend without without updating commit message 😎

For those who don’t know the amend trick, it’s an option when committing that allows you to add new changes directly to your previous commit.

git log

5cac4fe (HEAD -> master) Add Test

We can see that there is a commit with `Add Test` as title.
But what if you forgot to add for example comments to your code ?

One thing we generally do is making the changes and creating a new commit, something like :

git add .
git commit -m “Add comments”
git log

9b20d05 (HEAD -> master) Add comments for better use
5cac4fe Add Test

But why creating a new commit for that and making your git history horrible, if one commit is enough ? By using the ` — amend` option, you can add all my current changes to the last commit and have a clean git history :

git add .
git commit — amend
git log

5095e00 Add Test

Your comments have been added to the `Add Test` commit, and you can see that the commit hash changed as well.

We’re not finished. When amending, git offers you the possibility to change the commit message (by default), and it can be annoying if it always open a text editor for that 😒.

So if you don’t want to change the commit message, you can add the ` — no-edit` option.

✅ git — amend — no-edit

Last but not least 😈

Well, it’s not an amazing trick, but this is how your manager can see how many lines of codes you wrote today :

git diff — shortstat “@{0 day ago}”`

20 files changed, 4844 insertions(+), 4362 deletions(-)

Git tips and tricks #1 was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

CIDetector and Pictures analysis

It’s in my opinion the same for online dating and your profile pictures. Your profile pictures can have a big impact in your online dating experience because It’s what people see first.

There’s immense value in pictures analysis and there are so many interesting use cases. For example, some mobiles applications analyze photos and apply filters on it to make the pictures communicate more emotions like Snapchat. You can analyze photos and censure what may looks like unrelevant and/or forbidden content such as nudity. And a lot more 🤩.

I discovered CIDetector from the CoreImage frameworks and in this small article, I am going to show you what I discovered during my quick experimentation.

Did you already use Core Image before?

Core Image is a powerful API built into Cocoa Touch.

Personally, I don’t use it everyday. But it’s interesting to see that there are so incredible and useful features inside.

CoreImage — CIDetector: なにこれ？

CIDetector is an image processor object. So you have your CIDetector object. You give it any images and the CIDetector object will find for you information in your image: Those information can be:

• Faces
• Rectangles
• QRCode
• Text

For each of those information, you can again find some specific information. For face for exemple, you can find out if:

• There is a smile or not
• The user is blinking or not
• And probably other informations ( cf documentation apple )

Smile detection

So, we have this image and we want to find all the faces that appears. After than, we want to see if the person is smiling or not

How can we do it? Dō yatte suru no?

#1 Use CIDetector for detecting faces

let detector = CIDetector(
             ofType: CIDetectorTypeFace, 
             context: nil, 
             options: [CIDetectorAccuracy: CIDetectorAccuracyHigh]
)!

#2 Use CIDetector features for detecting Smile

let faces = detector.features(
                        in: CIImage(image: yourImage),
                        options: [CIDetectorSmile: true]) as? [CIFaceFeature]

#3 Then, do whatever you want with the results you got

For face in faces {
// face.bounds, face.hasSmile, face.mouthPosition, etc..
}

Did you already have to analyze pictures for some reasons? Let me know on my twitter @aymenworks.

I presented this small subject during the potatotips #54, a meetup where iOS and Android engineers share their tips, as simple as that 😅.

You can find the slides there.

potatotips #54 (iOS/Android開発Tips共有会) (2018/08/23 19:00〜)

Thanks for reading 🚀

CIDetector and Pictures analysis was originally published in Pairs Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.