DEV Community: Marcos Rezende

Benchmark test to compare Wire vs. Dig in Go

Marcos Rezende — Wed, 05 Feb 2025 14:08:14 +0000

How This Benchmark Works

Wire Test: Uses manually written code to simulate Wire's behavior (since Wire generates Go code at compile time).
Dig Test: Uses Uber's Dig to inject dependencies dynamically at runtime.
Manual DI Test: A baseline to compare against both approaches.

The benchmark runs each method multiple times to measure execution speed.

Install Dependencies

First, install Wire and Dig:

go install github.com/google/wire/cmd/wire@latest
go get go.uber.org/dig

Create the Benchmark File

Create a new file benchmark_test.go:

package main

import (
    "testing"
    "go.uber.org/dig"
    "github.com/google/wire"
)

// Mock Service
type Service struct{}

func NewService() *Service {
    return &Service{}
}

// === Dig Benchmark ===
func BenchmarkDig(b *testing.B) {
    container := dig.New()
    _ = container.Provide(NewService) // Provide dependency once

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        container.Invoke(func(s *Service) {}) // Resolve dependency at runtime
    }
}

// === Manual DI Benchmark (Simulating Wire) ===
func BenchmarkManualDI(b *testing.B) {
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = NewService() // Directly instantiate dependency
    }
}

// === Wire Injector (Simulated) ===
// Wire generates this function automatically
func InitializeService() *Service {
    wire.Build(NewService)
    return &Service{}
}

// === Wire Benchmark (Simulated) ===
func BenchmarkWire(b *testing.B) {
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = InitializeService() // Call Wire-generated function
    }
}

Run the Benchmark

Run the test using:

go test -bench=.

Expected Results

You'll see output similar to this:

BenchmarkDig-8         50000             32500 ns/op
BenchmarkManualDI-8   1000000             1000 ns/op
BenchmarkWire-8       1000000              950 ns/op

Wire should be slightly faster than Manual DI.
Dig should be slower due to runtime reflection overhead.

Summary of Performance Findings

After benchmarking Wire (Compile-Time DI) vs. Dig (Runtime DI), the results show clear trade-offs between performance and flexibility.

Benchmark Results Overview

Approach	Performance	Overhead
Manual DI	✅ Fastest	No extra cost
Wire (Compile-Time DI)	✅ Fast	No runtime overhead
Dig (Runtime DI)	❌ Slower	Reflection adds overhead

Key Takeaways

Wire is faster because it generates Go code at compile time, avoiding any runtime overhead.
Dig is more flexible but slightly slower due to reflection-based dependency resolution at runtime.
Manual DI (without any DI framework) remains the fastest but lacks dependency management features.

When to Use Each Approach?

✅ Use Wire if performance is a priority and dependencies don’t change often.
✅ Use Dig if you need dynamic dependency injection at runtime.
✅ Use Manual DI for simple projects where dependency injection is unnecessary.

Would you like a deeper breakdown of the benchmark results or an extended comparison? 🚀

Dependency Injection in Go: Comparing Wire, Dig, Fx & More

Marcos Rezende — Wed, 05 Feb 2025 13:53:15 +0000

Introduction

Dependency Injection (DI) is a powerful design pattern that helps manage dependencies in large applications. In Go, DI can be tricky because the language does not have built-in support for it like some other languages (e.g., Java’s Spring or C#’s .NET Core). However, several libraries provide DI capabilities in Go, each with its own strengths and weaknesses.

In this post, we’ll compare some of the most popular DI tools for Go:

Wire (by Google)
Dig (by Uber)
Fx (built on Dig)
GoCloud Wire (for cloud-native applications)
Dagger (unofficial for Go)

By the end, you’ll understand which tool is best for your use case! 🚀

Why Use Dependency Injection in Go?

Manually managing dependencies in a growing Go application can lead to complex and tightly coupled code. Dependency injection provides:

✅ Better modularity – Decouple components for easier testing and maintenance.
✅ Easier testing – Inject mock dependencies for unit testing.
✅ Improved maintainability – Avoid manually wiring dependencies in main.go.

But not all DI tools in Go work the same way. Some resolve dependencies at compile time, while others do it at runtime. Let’s dive into the differences.

Comparing Wire vs. Dig vs. Fx vs. Others

Different Go dependency injection tools offer different trade-offs. Some resolve dependencies at compile time, ensuring performance, while others do it at runtime, offering flexibility.

Tool	Type	Reflection?	Compile-Time Safety?	Flexibility	Best For
Wire	Compile-time	❌ No	✅ Yes	❌ Less flexible	High-performance apps
Dig	Runtime	✅ Yes	❌ No	✅ More flexible	Microservices
Fx	Runtime	✅ Yes	❌ No	✅ More flexible	Large applications
GoCloud Wire	Compile-time	❌ No	✅ Yes	❌ Cloud-focused	Cloud-native apps
Dagger (unofficial)	Compile-time	❌ No	✅ Yes	❌ Less flexible	Dagger-based projects

Now, let’s take a deeper look at each of these tools.

1️⃣ Google Wire (Compile-Time DI)

Wire is a compile-time dependency injection tool developed by Google. It generates Go code that manually wires dependencies before compilation, ensuring that there is no runtime overhead.

✅ Pros

✔ Zero runtime overhead (no reflection).
✔ Type-safe – Errors are caught at compile time.
✔ Simple and explicit – No magic happening at runtime.

❌ Cons

✘ Requires code generation – You must re-run wire when dependencies change.
✘ Less flexible than runtime DI tools like Dig.

When to Use Wire?

✅ Best for performance-sensitive applications where compile-time safety is important.
✅ Ideal when your dependencies don’t change frequently (to avoid re-running wire).
❌ Not ideal for highly dynamic applications where dependencies change at runtime.

2️⃣ Uber Dig (Runtime DI)

Dig is a runtime dependency injection library developed by Uber. Unlike Wire, which resolves dependencies at compile time, Dig resolves them at runtime, making it more flexible but with a slight performance cost.

✅ Pros

✔ More flexible than Wire – Dependencies can be injected dynamically.
✔ No need to regenerate code when dependencies change.
✔ Works well in dynamic applications where components may be swapped at runtime.

❌ Cons

✘ Uses reflection, which adds a small runtime performance overhead.
✘ Errors are detected at runtime, rather than at compile time.

When to Use Dig?

✅ Best for microservices or applications needing runtime flexibility.
✅ Useful for complex dependency graphs where components frequently change.
❌ Not ideal for high-performance applications where runtime overhead matters.

3️⃣ Uber Fx (Built on Dig)

Fx is a framework built on top of Dig that provides structured dependency injection along with lifecycle management. It simplifies the setup of large applications by managing logging, dependency injection, and application startup.

✅ Pros

✔ Includes lifecycle hooks for application startup and shutdown.
✔ Simplifies dependency management in large applications.
✔ Uses Dig internally, providing the same runtime flexibility.

❌ Cons

✘ Higher learning curve compared to Wire or Dig alone.
✘ More opinionated, making it harder to integrate into existing projects.

When to Use Fx?

✅ Best for large applications where lifecycle management is important.
✅ Useful if you're already using Dig and want additional structure.
❌ Not ideal for small projects due to added complexity.

4️⃣ GoCloud Wire (Cloud-Native DI)

GoCloud Wire is an extension of Wire that integrates with the Go Cloud Development Kit (Go CDK). It is optimized for dependency injection in cloud-native applications.

✅ Pros

✔ Works well with cloud services (AWS, GCP, Azure).
✔ Optimized for Go CDK, making it easy to use cloud components.

❌ Cons

✘ Not a general-purpose DI tool – best used in cloud-based projects.

When to Use GoCloud Wire?

✅ Best for cloud-native applications using Go CDK.
❌ Not ideal for general Go applications that don’t rely on cloud services.

5️⃣ Dagger (Unofficial for Go)

Dagger is a compile-time dependency injection tool widely used in Java and Kotlin. Although not officially supported in Go, some developers have experimented with using it.

✅ Pros

✔ Type-safe and optimized for compile-time dependency injection.
✔ Familiar for teams already using Dagger in other languages.

❌ Cons

✘ Unofficial support in Go – not widely adopted.
✘ Limited community support and documentation for Go.

When to Use Dagger?

✅ If your team is already using Dagger in other languages.
❌ Not recommended for most Go projects due to lack of support.

Which One Should You Choose?

🚀 Use Wire if you need high performance and compile-time safety.
⚡ Use Dig if you need runtime flexibility.
🏗 Use Fx for large applications that require lifecycle management.
☁ Use GoCloud Wire for cloud-native applications.
❌ Avoid Dagger unless you are already using it in other languages.

Conclusion

Choosing the right dependency injection tool depends on your project’s performance needs and flexibility requirements.

Would you like to see a real-world project using Wire, Dig, or Fx? Let me know in the comments! 🚀

Happy Coding! 🎉

The 4 basic libraries every Symfony Project needs to improve code quality

Marcos Rezende — Sat, 21 May 2022 08:55:46 +0000

Everytime we think to start a new Symfony project we need to think about which libraries are needed to have a good code quality. It happens to me and with every single other Symfony developer, for sure.

For this reason, I decided to create a script which creates a symfony skeleton project with all needed dependencies to improve its quality.

With this script you can create your next symfony skeleton project using the four libraries, in my opinion, should be used on every symfony project.

Save the code bellow and run it as follows:

./symfony-setup-project.sh {project-name}

#!/usr/bin/env bash
set -e
PROJECT=$1
composer create-project symfony/skeleton ${PROJECT}
mkdir ${PROJECT}/tools
mkdir ${PROJECT}/tools/php-cs-fixer
cd ${PROJECT}
composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer
composer require --dev phpstan/phpstan
composer require --dev phpunit/phpunit ^9.5
composer require --dev symfony/phpunit-bridge
composer require --dev qossmic/deptrac-shim
tools/php-cs-fixer/vendor/bin/php-cs-fixer fix src
php vendor/bin/phpstan analyse src
php bin/phpunit
php vendor/bin/deptrac analyse

What it will do:

1. Create the new Symfony application

composer create-project symfony/skeleton ${PROJECT}

It will create a new ${PROJECT} directory, download some dependencies into it and even generate the basic directories and files you'll need to get started.

2. Install the PHP Coding Standards Fixer

mkdir ${PROJECT}/tools

mkdir ${PROJECT}/tools/php-cs-fixer

cd ${PROJECT}

composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer

Following the recommendations from the PHP CS Fixer page, the above lines will install the PHP CS Fixer tool which fixes your code to follow standards; whether you want to follow PHP coding standards as defined in the PSR-1, PSR-2, etc., or other community driven ones like the Symfony one.

3. Install the PHP Static Analysis Tool

composer require --dev phpstan/phpstan

PHPStan is a important library which helps you on finding errors in your code without actually running it,catching whole classes of bugs even before you write tests for the code. It moves PHP closer to compiled languages in the sense that the correctness of each line of the code can be checked before you run the actual line.

4. Install the PHP Testing Framework

composer require --dev phpunit/phpunit ^9.5

composer require --dev symfony/phpunit-bridge

PHPUnit is a programmer-oriented testing framework for PHP. It is an instance of the xUnit architecture for unit testing frameworks.

5. Install Deptrac

composer require --dev qossmic/deptrac-shim

Deptrac is a static code analysis tool for PHP that helps you communicate, visualize and enforce architectural decisions in your projects.

Conclusion

If you use these four libraries into your Symfony Projects, you will be able to enforce that you follow the same coding standards on every class of your project, to catch bugs even before of running your project or writting tests, to build tests for your project and check it every time you delivery a new code's version, and to keep your architecture clean defining your architectural layers over classes and which rules should apply to them.

I intend to write more about these libraries, but you can easily follow the links of each one to learn more about them.

If I missed some important library here, please leave a comment helping me to improve this knowledge.

User is not in the sudoers file after Monterey upgrade

Marcos Rezende — Wed, 02 Feb 2022 12:21:46 +0000

After MacOS Monterey upgrade I got this error while trying to run any command with sudo:

❯ sudo apachectl -k restart
Password:
rezende79 is not in the sudoers file. This incident will be reported.

While it wasn't possible to run sudo visudo to edit the sudoers file properly, I created a /tmp/sudoers file with the following content:

# sudoers file.

#
# This file MUST be edited with the 'visudo' command as root.
# Failure to use 'visudo' may result in syntax or file permission errors
# that prevent sudo from running.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification
Defaults    env_reset
Defaults    env_keep += "BLOCKSIZE"
Defaults    env_keep += "COLORFGBG COLORTERM"
Defaults    env_keep += "__CF_USER_TEXT_ENCODING"
Defaults    env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults    env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults    env_keep += "LINES COLUMNS"
Defaults    env_keep += "LSCOLORS"
Defaults    env_keep += "SSH_AUTH_SOCK"
Defaults    env_keep += "TZ"
Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults    env_keep += "EDITOR VISUAL"

# Runas alias specification

# User privilege specification
root    ALL=(ALL) ALL
rezende79    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
%wheel    ALL=(ALL) ALL
%admin    ALL=(ALL) ALL

# Same thing without a password
# %wheel    ALL=(ALL) NOPASSWD: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now
ALL ALL=(ALL)     NOPASSWD:/opt/dplat/bin/Revision/CMUpdatePackage/Installer.app/Contents/MacOS/Installer
ALL ALL=(ALL)     NOPASSWD:/opt/dplat/bin/UpdatePackageInstaller.app/Contents/MacOS/UpdatePackageInstaller

Please note that the user rezende79 had already belonged to admin group and the user was inserted inside the file above.

After this, you only need to run the following command at your terminal to copy the content from /tmp to /etc folder:

osascript -e 'do shell script "cat /tmp/sudoers > /etc/sudoers; chown root:wheel /etc/sudoers" with administrator privileges'

This post is based on the following solution:
I accidentally deleted the sudoers file on Mac OS X

Avoid this when using Date/Time functions in PHP

Marcos Rezende — Sat, 28 Aug 2021 16:37:31 +0000

Is there any difference between getting the current date/time in the following ways in PHP?

(new \DateTimeImmutable())->format('Y-m-d H:i:s');

\DateTimeImmutable::createFromFormat('U', (string) time())
    ->format('Y-m-d H:i:s');

Imagine that you are inserting data into a database table using the first way, but when querying the same database table you use the second option.

While the first option will return the current date/time of your server taking into account its Time Zone configuration, the second way will return the current date/time of your server based on UTC time zone.

After creating just a single user into a users table with this data

$user->name = 'Sebastian';
$user->createdAt = (new \DateTimeImmutable())
    ->format('Y-m-d H:i:s');

and querying the user table in this way

$dql = <<<EOT
        SELECT u FROM App\Entity\User u
        WHERE u.createdAt <= :createdAt
    EOT;

$now = \DateTimeImmutable::createFromFormat('U', (string) time())
    ->format('Y-m-d H:i:s');

$users = $this->entityManager()
    ->createQuery($dql)
    ->setParameter('createdAt', $now)
    ->getResult();

you will receive an empty array of $users if the server which hosts your application is located in any country with Time Zone configuration greater than 0 (Austria, Denmark, Germany, and so on).

It will happen because the data which will be inserted into your user table will have the createdAt field filled with 18:14 while when you will try to query the database, you will use the time 16:14.

You didn't create any user before 16:14!

You will never find the users that you have recently created.

It occurs because when you use U to format the date/time values, you get a Unix Timestamp date/time format which gets the date/time always based on Coordinated Universal Time, and never takes into account the Server's Time Zone configuration.

This concept looks pretty basic, but maybe you have never had this issue because you have been working bellow UTC Time Zone (Denmark, South America, Canada, USA, and so on).

Pay attention to that, and you will never suffer trying to solve this issue.

On Being A Mature Engineer

Marcos Rezende — Sat, 14 Aug 2021 16:31:28 +0000

While reading the great article On Being A Senior Engineer of John Allspaw, I felt a desire to make notes, and this current post is a way to turn those notes public.

First of all, instead of using the word "senior" to reference experienced engineers, John used the word "mature" because (as he said):

I expect a “senior” engineer to be a mature engineer.

To be a senior engineer is more to develop engineering skills than soft skills. On the other hand, to be a mature engineer is more to develop soft skills than engineering skills.

For me, engineering skills is easier to learn than soft skills because these last need time, patience and reflection from whom desire to have them. While engineering skills are just a matter of study.

Mature engineers seek out constructive criticism of their designs.

John mentioned four questions which are asked by mature engineers to their peers:

“What could I be missing?”

“How will this not work?”

“Will you please shoot as many holes as possible into my thinking on this?”

“Even if it’s technically sound, is it understandable enough for the rest of the organization to operate, troubleshoot, and extend it?”

Mature engineers know that they are not the best and that good peer review is what makes better design decisions. They “beg for the bad news.” completed, John said.

Mature engineers do not shy away from making estimates and are always trying to get better at it.

Mature engineers are capable to make estimates and to make them better one after another. They don't avoid commitment. They know what they are doing and if not, they find a way to know.

Mature engineers have an innate sense of anticipation, even if they don’t know they do.

Mature engineers see problems coming. Rather than being taken by surprise, mature engineers present their views on likely problems as soon as they realize they might happen.

Mature engineers understand that not all of their projects are filled with rockstar-on-stage work.

Work is work, even if it is bug fixing, a mature engineer always knows that is possible to deliver great results independently of what kind work they are doing.

Mature engineers lift the skills and expertise of those around them.

The base code is something built and maintained by the entire team, not only by the most seniors. With that principle in mind, mature engineers always work looking for what they can do better but also what their peers can do better too.

Mature engineers understand the difference between mentorship and sponsorship, and develop a habit of the latter.

What members of underrepresented groups in tech often need most is opportunity and visibility, not advice.

Instead of advising, mature engineers give to each person on their group the opportunity and visibility bringing those who have less seniority of them to the same level.

Mature engineers make their trade-offs explicit when making judgments and decisions.

The ETTO Principle - Efficiency-Thoroughness Trade-Off

“Premature optimization is the root of all evil.”
Understanding what is and isn’t “premature” is what separates senior engineers from junior engineers.’

Mature engineers don’t practice CYAE (“Cover Your Ass Engineering”)

Mature engineers stand up and accept the responsibility given to them. If they find they don’t have the requisite authority to be held accountable for their work, they seek out ways to rectify that.

Mature engineers are empathetic.

Goal conflicts are inherent in all engineering work, and complaining about them (instead of embracing them as requirements for success) is a sign of a less mature engineer.

Mature engineers don’t make empty complaints.

Instead, they express judgments based on empirical evidence and bring with those judgments options for solving the problem which they’ve identified.

Mature engineers are aware of cognitive biases

Culturally, engineers work day-to-day in empirical evidence in research. Basically: show me the data. The issue with cognitive biases is that we can be blissfully unaware of when we are interpreting data with our own brains in ways that defy empirical data and can have a surprising effect on how we get work done and work on teams.

Mature engineers know the importance of feelings people have.

Mature engineers know they're not just dealing with code. The code that a company produces is the end result of teamwork done by people (your team) for people (your customers). Learning to deal with the feelings of others is essential to being desirable to a company that depends on people to deliver software.

Spaceship, Ternary and Null Coalescing operators in PHP: Quick examples

Marcos Rezende — Sat, 14 Aug 2021 10:59:34 +0000

These are so simple concepts, but sometimes forgotten by PHP developers. In order to quick introduce and explain how to use there three types of comparison operators in PHP, I've decided to share the simple codes bellow.

If you need further information, please check the official Comparison Operators documentation page.

Spaceship Operator

This:

$result = ($expr1) <=> ($expr2);

Is the same of:

if ($expr1 < $expr2) {
    $result = -1;
} else if ($expr1 == $expr2) {
    $result = 0;
} else if ($expr1 > $expr2) {
    $result = 1;
}

Ternary Operator

This:

$result = ($expr1) ? ($expr2) : ($expr3);

Is the same of:

if (true == $expr1) {
  $result = $expr2;
} else {
  $result = $expr3;
}

And this:

$result = ($expr1) ?: ($expr3);

Is the same of:

if (true == $expr1) {
  $result = $expr1;
} else {
  $result = $expr3;
}

Null Coalescing Operator

This:

$result = ($expr1) ?? ($expr3);

Is the same of:

if (null !== $expr1) {
  $result = $expr1;
} else {
  $result = $expr3;
}

You can play with here: https://3v4l.org/SWfOt

Minimal list of the things every software professional should know

Marcos Rezende — Wed, 07 Oct 2020 18:20:02 +0000

As a software professional, I see a lot of programmers being evaluated about their techniques and not about their knowledge or, in other words, about what and not about how they code.

I have ever being a true believer that if you know the principles you can deduce the techniques from it. Doesn't matter the language because the grammar of each programming language is similar to the other, so it's just the matter to just the syntax and refines the grammar, but you still must know how to be a good writer. And this is what Uncle Bob teaches us. When we are coding, we are writing code.

Please, take a look at this excerpt from The Clean Coder book where Uncle Bob says out loud exactly what I think about how to become a good software professional and where I (and you) should put the effort to accomplish that goal:

1. Design patterns.

You ought to be able to describe all 24 patterns in the Gang of Four book and have a working knowledge of many of the patterns in the POSA books.

2. Design principles.

You should know the SOLID principles and have a good understanding of the component principles.

3. Methods.

You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.

4. Disciplines.

You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.

5. Artifacts.

You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Besides that "small" list about the minimal of what we need to know as a software professional, Uncle Bob adds: continuous learning, practicing, collaboration, mentoring, domain knowing, employer shoes, and humility.

Bonus.

If I can add something to Uncle Bob's list, I suggest you learn about Refactoring. The majority of the time which we spend on projects is doing refactoring of previous code. So, master this discipline will add more XP to you as a software professional, increasing your value in the market.

Do you have anything to add to this list? Please, comment below.

Photo by olia danilevich from Pexels.

Sparse Arrays Code Challenge Solved

Marcos Rezende — Sat, 05 Sep 2020 21:34:14 +0000

Ok! That's a simple problem with a simple solution written in Python 3, but to not lose the habit, I am publicly exposing my solution here.

There is a collection of input strings and a collection of query strings. For each query string, determine how many times it occurs in the list of input strings.

Complete the function matchingStrings in the editor below. The function must return an array of integers representing the frequency of occurrence of each query string in strings.

matchingStrings has the following parameters:

strings - an array of strings to search
queries - an array of query strings

Solution

def matchingStrings(strings, queries):
    return [strings.count(query) for query in queries]

That is it. With one single line, we are returning an array that counts how many queries appears in strings.

Arrays: Left Rotation Code Challenge Solved

Marcos Rezende — Sat, 05 Sep 2020 21:32:16 +0000

A left rotation operation on an array shifts each of the array's elements 1 unit to the left. For example, if 2 left rotations are performed on array [1, 2, 3, 4, 5], then the array would become [3, 4, 5, 1, 2].

Given an array a of n integers and a number d, perform d left rotations on the array. Return the updated array to be printed as a single line of space-separated integers.

Function Description
Complete the function rotLeft in the editor below. It should return the resulting array of integers.

rotLeft has the following parameter(s):

An array of integers a
An integer d, the number of rotations.

Input Format
The first line contains two space-separated integers n and d, the size of a and the number of left rotations you must perform.
The second line contains n space-separated integers a[i].

Constraints
1 <= n <= 10^5
1 <= d <= n
1 <= a[i] <= 10^6

Output Format
Print a single line of n space-separated integers denoting the final state of the array after performing d left rotations.

Sample Input

4
1 2 3 4 5

Sample Output

5 1 2 3 4

Explanation
When we perform left rotations, the array undergoes the following sequence of changes:

[1, 2, 3, 4, 5]
[2, 3, 4, 5, 1]
[3, 4, 5, 1, 2]
[4, 5, 1, 2, 3]
[5, 1, 2, 3, 4]

Solution

function rotLeft($a, $d) {
    $i = 0;
    $m = $d;
    if ($d > sizeof($a)) {
        $m = ($d % sizeof($a));
    }
    while ($i < $m) { 
        $a[] = $a[$i];
        $i++;
    }
    array_splice($a, 0, $m);
    return implode(' ', $a);
}

2D Array - DS Code Challenge Solved

Marcos Rezende — Sat, 05 Sep 2020 21:29:51 +0000

Given a 6 x 6 array, arr:

1 1 1 0 0 0
0 1 0 0 0 0
1 1 1 0 0 0
0 0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0 0

We define an hourglass in A to be a subset of values with indices falling in this pattern in arr's graphical representation:

a b c
  d
e f g

There are 16 hourglasses in arr, and an hourglass sum is the sum of an hourglass' values. Calculate the hourglass sum for every hourglass in arr, then print the maximum hourglass sum.

For example, given the 2D array:

-9 -9 -9  1 1 1 
 0 -9  0  4 3 2
-9 -9 -9  1 2 3
 0  0  8  6 6 0
 0  0  0 -2 0 0
 0  0  1  2 4 0

We calculate the following 16 hourglass values:

-63, -34, -9, 12, 
-10, 0, 28, 23, 
-27, -11, -2, 10, 
9, 17, 25, 18

Our highest hourglass value is 28 from the hourglass:

0 4 3
  1
8 6 6

Function Description
Complete the function hourglassSum in the editor below. It should return an integer, the maximum hourglass sum in the array.

hourglassSum has the following parameter(s):

arr: an array of integers

Input Format
Each of the 6 lines of inputs arr[i] contains 6 space-separated integers arr[i][j].

Constraints
-9 <= arr[i][j] <= 9
0 <= i, j <= 5

Output Format
int the largest (maximum) hourglass sum found in arr.

Solution

function hourglassSum($arr)
{
    $sum = -72;
    $sum_arr = array();
    for ($line = 0; $line < 4; $line++) {
        for ($col = 0; $col < 4; $col++) {
            $top = $arr[$line][$col] + $arr[$line][$col + 1] + $arr[$line][$col + 2];
            $middle = $arr[$line + 1][$col + 1];
            $bottom = $arr[$line + 2][$col] + $arr[$line + 2][$col + 1] + $arr[$line + 2][$col + 2];   
            if (($top + $middle + $bottom) > $sum) {
                $sum = $top + $middle + $bottom;
            }
        }
    }
    return $sum;
}

Repeated String Code Challenge Solved

Marcos Rezende — Sat, 05 Sep 2020 21:23:45 +0000

Lilah has a string, s, of lowercase English letters that she repeated infinitely many times.

Given an integer 'n' find and print the number of letters 'a's in the first letters of Lilah's infinite string.

For example, if the string s = 'abcac' and n = 10, the substring we consider is abcacabcac, the first 10 characters of her infinite string. There are 4 occurrences of 'a' in the substring.

Function Description
Complete the repeatedString function in the editor below. It should return an integer representing the number of occurrences of 'a' in the prefix of length in the infinitely repeating string.

repeatedString has the following parameter(s):

s: a string to repeat
n: the number of characters to consider

Input Format
The first line contains a single string, s. The second line contains an integer, n.

Output Format
Print a single integer denoting the number of the letter a's in the first letters of the infinite string created by repeating infinitely many times.

Sample input
aba
10

Sample output
7

Explanation
The first letters of the infinite string are 'abaabaabaa'. Because there are a's, we print on a new line.

Solution



function repeatedString($s, $n) {
    // check the number of occurrences of letter 'a' on given string $s
    $a_occurrences_in_s = substr_count($s, 'a');

    // check how many occurrences of string $s belongs to an repeated string $s of length of $n
    $s_occurrences_qty = floor($n / strlen($s));

    // get the $s occurrences left
    $s_occurrences_left = $n - ($s_occurrences_qty * strlen($s));

    // left string
    $s_left = substr($s, 0, $s_occurrences_left);

    // 'a' occurrences in left string
    $a_occurrences_in_s_left = substr_count($s_left, 'a');

    // occurrencies of 'a' on the entire repeated string of $s with a length of $n
    return ($a_occurrences_in_s * $s_occurrences_qty) + $a_occurrences_in_s_left;
}