DEV Community: Alex Awesome

Do you think it's a myth that technological progress inevitably leads to job losses?

Alex Awesome — Tue, 26 Dec 2023 09:50:36 +0000

The Transformative Impact of Technology and Digitalization on Employment: Beyond the Myths

In an era where technology and digitalization are rapidly reshaping the business landscape, concerns about their impact on employment are widespread.
The prevailing myth suggests that technological advancements inevitably lead to job losses.
However, a more nuanced perspective reveals that while technology does transform the nature of work, it also creates new opportunities and demands adaptation.
I want to illustrate this dynamic, challenging the myth and highlighting the positive aspects of this transformation.

Revisiting "The Intern" - A Metaphor for Change

"The Intern" offers a poignant example. A traditional factory closes, giving way to an online magazine.
This represents a broader trend: industries pivoting from conventional methods to digital platforms, not eliminating jobs but evolving them.
The film underlines the adaptability of the workforce and the emergence of diverse roles in new sectors.

Technology as a Catalyst for New Employment Opportunities

Tech and Software Development: The digital era has birthed an entire industry in IT and software development, with roles in coding, cybersecurity, and AI development.

E-Commerce Revolution: Companies like Amazon and eBay have transformed retail, creating jobs in digital marketing, logistics, web development, and customer support.

The Green Tech Movement: The shift towards sustainable energy is not just an environmental choice but an economic one, creating jobs in solar and wind energy, battery technology, and sustainable building practices.

Healthcare and Biotechnology: The intersection of technology and healthcare has opened new roles in biomedical engineering, telemedicine, health informatics, and pharmaceutical research.

Automation and Robotics: While automation may replace some manual jobs, it also creates roles in robot design, maintenance, programming, and integration into existing workflows.

The Gig Economy: Digital platforms like Uber, Airbnb, and Upwork have created a new economy, offering flexible employment opportunities across various sectors.

The Necessity of Skill Adaptation and Lifelong Learning

The transition to a tech-centric job market requires a paradigm shift in skills and learning.
Continuous education, reskilling, and upskilling are crucial to remain relevant.
This shift isn't necessarily about harder work, but about adapting to new ways of working, emphasizing problem-solving, creativity, and technical skills.

Addressing Displacement and Inequality

While technology creates jobs, it can also lead to displacement and inequality.
It's crucial for policymakers, educators, and businesses to work together to ensure that the benefits of technology are widely accessible.
This includes investing in education, providing retraining programs, and ensuring equitable access to emerging job markets.

Conclusion

The narrative that technology destroys jobs is overly simplistic.
While it does change the nature of work, it also opens up new avenues for employment and economic growth.
The key lies in embracing change, adapting skill sets, and recognizing the vast potential of technology and digitalization.
The future of work is not about the loss of jobs due to technology; it's about the evolution and diversification of the employment landscape, where adaptability and learning are at the forefront.

What do you think? Is it a myth or not?

Mastering Test-Driven Development. Chapter 2: Fundamentals of TDD Workflow and Principles

Alex Awesome — Sun, 24 Dec 2023 14:12:10 +0000

The Red-Green-Refactor Cycle

🟥 Red Phase: Where It All Begins

The red phase is similar to the starting blocks of a race. Here, we're setting ourselves up for what's to come. Writing a test first might feel like putting on your shoes before you have feet, but there's a method to this madness. It forces you to think about how your code should behave - it's like planning your route before you start driving.

Thoughts: This phase is crucial for understanding what you're about to build. It’s about expectations and specifications, not just blind coding.

public function testSum() {
    $this->assertEquals(10, sum(4, 6));
}

test('adds 4 + 6 to equal 10', () => {
  expect(sum(4, 6)).toBe(10);
});

func TestSum(t *testing.T) {
    got := sum(4, 6)
    want := 10

    if got != want {
        t.Errorf("sum(4, 6) = %d; want %d", got, want)
    }
}

We don't have a working code yet, but we already have its documented behaviour. This means that we know exactly what to program.

🟩 Green Phase: Making Things Work

Now that we have our failing test, it's time to make it pass. This is where you write the code that fulfills the test's criteria. But remember, this isn't an art contest - no need for fancy strokes just yet. The aim is to get from point A to point B with the shortest, simplest route possible.

Thoughts: It might seem counterintuitive to write simple, even rudimentary code, but the essence here is functionality, not perfection. We're aiming for a working solution, not the Mona Lisa.

function sum($a, $b) {
    return $a + $b;
}

function sum(a, b) {
  return a + b;
}

func sum(a int, b int) int {
    return a + b
}

Refactor Phase: Polishing the Diamond

Refactoring is where the code starts to shine. It's not about altering what the code does, but how it does it. This is where we can get a bit artsy, cleaning up the code, improving its structure and design, optimizing performance, and making it more readable.

We did the work and we don't need anything else. Maybe. But we can improve this function to make it count the sum of several numbers.

function sum(...$numbers) {
    return array_sum($numbers);
}

function sum(numbers) {
  return numbers.reduce((acc, current) => acc + current, 0);
}

func sum(numbers ...int) int {
    total := 0
    for _, number := range numbers {
        total += number
    }
    return total
}

I showed the refactoring step this way only to show refactoring in this simplest example. TDD involves a red-green-refactoring cycle. I broke this cycle above.

The right order of actions should be:

write the test for more than two numbers
see red tests
write the implementation

In the world of TDD, the Red-Green-Refactor cycle is your bread and butter. You start by dreaming of what you want (Red), then you cook up something that just about fits the bill (Green), and finally, you garnish and season it to taste (Refactor). It's a continuous loop of expectation, implementation, and improvement – a dance of sorts where your code gracefully evolves from a rough sketch to a masterpiece.

Writing Tests First

In the world of TDD, writing tests first is not just a step; it's a philosophy. It's like drawing the map before embarking on a treasure hunt. It sets the destination before you start the journey. This approach has a profound impact on how you think about your code and how it evolves. Let's explore how to embrace this approach with examples.

The Mindset Shift

Writing tests first requires a shift in mindset: from thinking about how to implement a feature to thinking about how you'd like the feature to behave. It's like setting the rules of a game before playing it. This shift leads to clearer, more focused development efforts.

I worked in a company where TDD was a required standard. All these things were explained during the onboarding process. But I've seen programmers who haven't made The Mindset Shift. They know the rules but continue to think about implementation first. This is a very important step to be cool at TDD. You should beat yourself up when you start writing an implementation rather than a test.

We already have examples above but repetition is the mother of learning.

Let's say we're building a function to check if a number is even. We'll begin by writing tests for this function in PHP, JavaScript, and Go. (They are the same. Just different languages)

use PHPUnit\Framework\TestCase;

class NumberTest extends TestCase {
    public function testIsEven() {
        $this->assertTrue(isEven(4));
        $this->assertFalse(isEven(5));
    }
}

// The isEven function is not yet implemented.

const isEven = require('./isEven');

test('checks if a number is even', () => {
  expect(isEven(4)).toBe(true);
  expect(isEven(5)).toBe(false);
});

// The isEven function is not yet implemented.

package main

import "testing"

func TestIsEven(t *testing.T) {
    if !isEven(4) {
        t.Error("4 should be even")
    }
    if isEven(5) {
        t.Error("5 should not be even")
    }
}

// The isEven function is not yet implemented.

The First Test Run

After writing these tests, the first run will obviously fail because the isEven function doesn't exist yet. This failure is a good thing! It confirms that our tests are set up correctly and are ready to guide our implementation.

Implementing the Feature

With our failing tests in place, the next step is to implement the isEven function. The aim is to write just enough code to make the tests pass, no more.

PHP Implementation:


function isEven($number) {
    return $number % 2 === 0;
}

JavaScript Implementation:

function isEven(number) {
  return number % 2 === 0;
}

module.exports = isEven;

Go Implementation:

package main

func isEven(number int) bool {
    return number%2 == 0
}

Running the Tests Again

After implementing the feature, we run the tests again. This time, they should pass, confirming that our isEven function behaves as expected.

This process of writing tests first ensures that we're always focused on the desired outcome of our code. It guides development in a structured, goal-oriented way, reducing the risk of drifting off course. It's like having a compass in the wilderness of coding: it always points you in the right direction.

Small, Incremental Steps

The practice of taking small, incremental steps in Test-Driven Development (TDD) is like building a house brick by brick rather than trying to erect walls in a single day. It’s a disciplined approach that focuses on simplicity and steady progress. This methodology not only keeps the process manageable but also ensures that each step adds a stable and well-tested piece to the overall structure of the software.

The Philosophy of Incremental Development

When adopting TDD, you embrace the art of breaking down complex problems into smaller, more manageable pieces. Each test and the subsequent code written to pass that test represent one of these small steps. This approach allows for more frequent feedback, easier debugging, and better adaptability to changing requirements.

Let's illustrate this with a practical example. Suppose we are building a function that calculates the factorial of a number. We'll develop this functionality incrementally, adding one test at a time and then writing just enough code to pass that test.

Small, Incremental Steps
The practice of taking small, incremental steps in Test-Driven Development (TDD) is like building a house brick by brick rather than trying to erect walls in a single day. It’s a disciplined approach that focuses on simplicity and steady progress. This methodology not only keeps the process manageable but also ensures that each step adds a stable and well-tested piece to the overall structure of the software.

The Philosophy of Incremental Development
When adopting TDD, you embrace the art of breaking down complex problems into smaller, more manageable pieces. Each test and the subsequent code written to pass that test represent one of these small steps. This approach allows for more frequent feedback, easier debugging, and better adaptability to changing requirements.

Examples in PHP, JavaScript, and Go
Let's illustrate this with a practical example. Suppose we are building a function that calculates the factorial of a number. We'll develop this functionality incrementally, adding one test at a time and then writing just enough code to pass that test.

PHP Example:

First Test and Implementation:

// tests/FactorialTest.php
use PHPUnit\Framework\TestCase;

class FactorialTest extends TestCase {
    public function testFactorialOfZero() {
        $this->assertEquals(1, factorial(0));
    }
}

// src/MathFunctions.php
function factorial($number) {
    return 1;
}

Second Test and Enhanced Implementation:

// Adding a new test
public function testFactorialOfOne() {
    $this->assertEquals(1, factorial(1));
}

// Updating the implementation
function factorial($number) {
    if ($number === 0 || $number === 1) {
        return 1;
    }
}

JavaScript Example:

First Test and Implementation:

// factorial.test.js
const factorial = require('./factorial');

test('factorial of 0', () => {
  expect(factorial(0)).toBe(1);
});

// factorial.js
function factorial(number) {
  return 1;
}

module.exports = factorial;

Second Test and Enhanced Implementation:

// Adding a new test
test('factorial of 1', () => {
  expect(factorial(1)).toBe(1);
});

// Updating the implementation
function factorial(number) {
  if (number === 0 || number === 1) {
    return 1;
  }
}

Go Example:

First Test and Implementation:

// factorial_test.go
package main

import "testing"

func TestFactorialOfZero(t *testing.T) {
    if factorial(0) != 1 {
        t.Errorf("Factorial of 0 should be 1")
    }
}

// main.go
func factorial(number int) int {
    return 1
}

Second Test and Enhanced Implementation:

// Adding a new test
func TestFactorialOfOne(t *testing.T) {
    if factorial(1) != 1 {
        t.Errorf("Factorial of 1 should be 1")
    }
}

// Updating the implementation
func factorial(number int) int {
    if number == 0 || number == 1 {
        return 1
    }
}

Building Up Complexity

With each additional test, we slowly expand the functionality of our code. This gradual process of adding and passing tests continues until the function fully meets its specifications. By doing this, we avoid the pitfalls of trying to solve the whole problem at once, which can lead to complex and bug-prone code. It's a step-by-step journey towards our goal, ensuring solid footing at every stage.

Focusing on Testable Code

In test-driven development (TDD), focusing on writing testable code is akin to an architect designing a building with accessibility and maintenance in mind. It's about anticipating how each component can be accessed, tested, and maintained over time. Testable code not only makes TDD more efficient, but also results in cleaner, more modular, and more robust software architecture.

The Essence of Testable Code

Testable code is characterized by a few key attributes: simplicity, modularity, and clear interfaces. It’s like crafting a puzzle where each piece is distinct and fits perfectly with the others, yet can be examined and tested independently.

Let's consider a scenario where we are creating a simple logging system. Our focus will be on writing code that is easy to test and maintain.

PHP Example:

In PHP, we can write a logger that adheres to an interface, making it highly testable.

// LoggerInterface.php
interface LoggerInterface {
    public function log($message);
}

// FileLogger.php
class FileLogger implements LoggerInterface {
    public function log($message) {
        // Logic to log message to a file
    }
}
// LoggerInterface makes it easy to mock FileLogger in tests

JavaScript Example:

In JavaScript, using functions and modules can enhance testability.

// logger.js
export function log(message) {
    // Logic to log message
}

// Using export makes it easy to import and test this function

Go Example:

In Go, interfaces are a powerful tool for creating testable code.

// logger.go
package main

type Logger interface {
    Log(message string)
}

type FileLogger struct{}

func (l FileLogger) Log(message string) {
    // Logic to log message to a file
}

// Logger interface allows for easy mocking and testing of FileLogger

Imagine each piece of your code as a component in a car. Testable code means that each part, like the engine or brakes, can be independently checked and serviced without disassembling the entire car. It’s about building systems where components are both individually assessable and collectively functional.

Why Focus on Testable Code?

Ease of Testing: Clearly defined and isolated parts of the system are easier to test. It reduces the complexity involved in setting up tests and makes your tests more reliable.
Maintainability: Testable code often leads to a design where changing one part of the system has minimal impact on others. This isolation simplifies maintenance.
Flexibility for Future Changes: When your code is testable, adapting or extending your system becomes more manageable. It’s like having a flexible foundation that can easily accommodate renovations.
Enhanced Collaboration: In a team setting, testable code allows different members to work on separate parts of the system with minimal interference, much like a well-orchestrated symphony.

Principles of Good Testing: Reliability, Repeatability, Isolation, etc.

Understanding the principles of good testing is like learning the rules of a sport; knowing them not only improves your game but also makes it more enjoyable and effective. In Test-Driven Development (TDD), good testing principles are the backbone that supports the entire process. These principles ensure that the tests are reliable, repeatable, and provide meaningful feedback.

1. Reliability

Tests must yield consistent results. A reliable test will pass if the code under test is correct and fail otherwise, regardless of external factors like the environment or timing.

A few strange examples to demonstrate a violating reliability

// Unreliable test depending on an external API
public function testWeatherAPI() {
    $response = file_get_contents('http://api.weather.com/current');
    $data = json_decode($response);
    $this->assertEquals(20, $data->temperature); // Fails if the temperature changes
}

// Unreliable test based on dynamic document content
test('checks dynamic content', () => {
  document.body.innerHTML = '<div id="time">' + new Date().getTime() + '</div>';
  const now = document.getElementById('time').textContent;
  expect(now).toBe(new Date().getTime().toString()); // Fails due to timing differences
});

// Unreliable test depending on a network resource
func TestDownloadSpeed(t *testing.T) {
    speed := testInternetDownloadSpeed()
    if speed < 100 {
        t.Errorf("Expected at least 100 Mbps, got %d Mbps", speed) // Fails with varying internet speeds
    }
}

2. Repeatability

Good tests should yield the same results every time they're run. They shouldn't rely on mutable external data.

Also, a few strange examples to demonstrate violating

// Non-repeatable test due to a static date
public function testIsWeekend() {
    $today = new DateTime(); // Static date
    $this->assertTrue(isWeekend($today)); // Fails if not run on a weekend
}

// Non-repeatable test due to dependency on file system state
func TestFileExists(t *testing.T) {
    if !fileExists("/tmp/some-temp-file") {
        t.Errorf("File should exist") // Fails if the file state changes between runs
    }
}

3. Isolation

Each test should be independent of others; they shouldn't share state. This isolation prevents tests from causing side effects that could affect the outcome of other tests.

// Tests not isolated due to shared database state
public function testUserCreation() {
    createUser("testuser");
    $this->assertTrue(userExists("testuser"));
}

public function testUserExist() {
    $this->assertFalse(userExists("testuser")); // Fails if testUserCreation hasn't run
}

// Non-isolated tests due to shared state
let counter = 0;

test('increments counter', () => {
  counter++;
  expect(counter).toBe(1);
});

test('counter is zero', () => {
  expect(counter).toBe(0); // Fails because of the side effect from the previous test
});

Other Principles
Apart from these primary principles, good testing also involves:

Simplicity: Tests should be as simple as possible, focusing on one specific aspect at a time.

Readability: Clear and understandable tests are crucial, as they often serve as documentation.

Coverage: Good tests cover a wide range of scenarios, including edge cases.

As we wrap up Chapter 2, "Fundamentals of TDD Workflow and Principles," we've journeyed through the essential elements that form the backbone of Test-Driven Development. Each segment of this chapter has been carefully designed to not only introduce you to the core concepts of TDD but also to instill a deeper understanding of their practical application.

From the disciplined rhythm of the Red-Green-Refactor cycle, which teaches us the art of iterative development and constant improvement, to the principle of writing tests first, which shifts our perspective from 'making things work' to 'ensuring things work correctly,' we've laid the groundwork for quality software development. We've seen how breaking down complex problems into small, incremental steps not only makes coding more manageable but also enhances the quality and maintainability of the code we write.

A key focus on testable code underlines the importance of crafting our software in such a way that it lends itself well to testing - promoting practices that result in cleaner, more modular, and robust architecture. And finally, by understanding the principles of good testing - reliability, repeatability, and isolation - we ensure that our tests themselves are dependable and provide meaningful feedback.

As you step into the subsequent chapters, armed with the knowledge from this one, remember that TDD is more than a set of practices; it's a mindset, a way to approach software development that prioritizes quality, agility, and sustainability. The journey through TDD is continuous and evolving. There will always be new challenges and lessons to be learned, but the foundation you've built here will guide you through them.

So, keep this foundational knowledge close as you continue your journey through the world of Test-Driven Development, and prepare to build upon it in the chapters to come. The path to mastery is a marathon, not a sprint, and every step taken is a step towards excellence in software development.

To be continued...

-
Follow me
https://t.me/awesomeprog
https://twitter.com/shogenoff
http://facebook.com/shogentle

Mastering Test-Driven Development. Chapter 1: Understanding Test-Driven Development

Alex Awesome — Wed, 09 Aug 2023 13:07:14 +0000

History and Evolution of TDD

In the 1960s and 1970s, the concept of using tests to drive development was far from being the standard. Software development methodologies were in their infancy, and the focus was more on designing and implementing features rather than ensuring their correctness and robustness through tests.
I know developers who think this way these days. Fortunately, more and more programmers understand the power of tests.

Fast-forward to the 1990s, and the seeds of TDD started to sprout within the Extreme Programming (XP) methodology. Kent Beck, often recognized as the father of TDD, was working on the Chrysler Comprehensive Compensation System (C3) project. He brought to light the "test-first" concept as a core practice of XP, a project that will serve as the source for TDD.

The basic idea was sipmle: write a failing test and then write the code to make this test pass. Let's consider an example for a simple function to add two numbers:

JS:

const add = require('./add');

test('adds 2 + 3 to equal 5', () => {
  expect(add(2, 3)).toBe(5);
});

GO:

package main

import "testing"

func TestAdd(t *testing.T) {
    got := Add(2, 3)
    want := 5

    if got != want {
        t.Errorf("Add(2, 3) = %d; want %d", got, want)
    }
}

Python:

def test_addition():
    assert add(2, 3) == 5

Running this test would naturally fail because we haven't defined the add function yet. That's where we step in with our production code:

JS:

// add.js
function add(a, b) {
  return a + b;
}

module.exports = add;

Go:

package main

func Add(x, y int) int {
    return x + y
}

Python:

def add(x, y):
    return x + y

Running the test again, it would pass. It was the completed red-green cycle of TDD.

The introduction of this red-green cycle was revolutionary. It shifted the development focus from simply writing code that meets the requirements to writing code that passes tests. This approach drastically reduced the number of bugs and improved code quality.

As we moved into the 21st century, TDD became more widespread. It crossed the boundaries of XP and found its place in many Agile practices. Modern development environments started to provide better support for TDD, offering integrated testing frameworks and tools that made the process more seamless.

In the past two decades, TDD has continued to evolve. We've seen the introduction of concepts like Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD), which extended the original premises of TDD to higher levels of software design and development.

Of course TDD is not a default standard. But despite its challenges and the debates, TDD benefits in producing robust, maintainable, and reliable software are undeniable

Definition and Purpose of TDD

Test-Driven Development (TDD) is a software development methodology that revolves around the repetition of a very short development cycle. Let’s unpack it in more detail.

Definition

Here's a step-by-step breakdown:

Write a Test: Before you even start with your actual code, write a test for what you intend to develop. This test is expected to fail since there’s no corresponding functionality yet.
Run the Test: Execute the test and watch it fail. This is an essential step to ensure that the test is not accidentally passing from the get-go and to understand the current failure mode.
Write Minimal Code: Draft the least amount of code necessary to make the test pass. This doesn’t mean writing bad or shortcut-filled code, but focusing purely on meeting the test’s expectations.
Run All Tests: Execute all tests to ensure your new code hasn't inadvertently broken any existing functionality.
Refactor: Once the test passes, refine and optimize your code, all the while ensuring the test still passes. This step is crucial for maintaining a clean and efficient codebase.

Purpose and Benefits

Quality Assurance: TDD is like setting up a safety net. By defining what success looks like (through tests) beforehand, it ensures that your code does exactly what it's intended to do.
Focused and Efficient Development: By laying out criteria for success upfront, developers often find they code more efficiently and with greater focus on the task at hand.
Evolvable Code Design: TDD pushes for a modular design, making future changes and feature additions easier.
Protection Against Regression: When making changes, the robust suite of tests will notify if a recent change has adversely affected existing functionality.
Confidence in refactoring. A comprehensive test suite means developers can refactor or restructure code with confidence. If the tests still pass, the behavior of the software remains stable.
Kind of Documentation: A developer can understand how a piece of code behaves by examining tests.

TDD promotes better design, fewer bugs, and clear documentation via tests. It's not just a testing method—it's a development philosophy. As you progress through this chapter, we'll dive deeper into how TDD affects every facet of development, from design choices to debugging strategies.

Benefits and Potential Pitfalls of TDD

Test-driven development (TDD) is not without strong advocates and cautious naysayers. It's critical to view TDD as a tool in a developer's toolbox, and like any tool, it's not the answer to every problem. But with skillful use, it can bring significant benefits. Let's dive into both the benefits and potential pitfalls of TDD.

Benefits of Adopting TDD

High-Quality Code

By continuously testing as you develop, you’re more likely to catch and fix bugs early on. This proactive approach leads to a more robust, error-free codebase.

Documentation

Tests provide a clear, executable specification for how each part of the system is supposed to work. They serve as a fantastic reference for both current team members and newcomers.

Enhanced Design

By having to write tests for your code, you're compelled to make your code testable. Testable code is often modular and follows the Single Responsibility Principle, which makes it more maintainable and scalable.

// Instead of a confusing function that does several things
// we break it down to smaller testable units.

function processData(data) {
    cleaned = cleanData(data);
    transformed = transformData(cleaned);
    return transformed;
}

Peace of Mind ✌️

With a solid suite of tests, developers can make changes or add new features with confidence, knowing that any regression will likely be caught by the tests.

Cost Savings in the Long Run

Detecting and fixing bugs early in the development cycle is often less expensive and time-consuming than addressing them post-release.

Potential Pitfalls of TDD

Steep Learning Curve

For teams unfamiliar with TDD, the initial stages can be daunting. Writing tests first might seem counterintuitive, and getting into the groove of the red-green-refactor cycle can take time.

Increased Development Time

Initially, TDD might seem to slow down the development process. Writing tests in tandem with code can make the development phase longer. However, this potential slowdown is often offset by fewer bugs and less time spent on debugging later in the project.

Overemphasis on Unit Tests

While unit tests are the backbone of TDD, it is important to strike a balance with other types of tests such as integration tests and end-to-end tests. Over-reliance on unit tests can sometimes miss issues that arise when modules work together.

Risk of writing extra tests

Especially when starting with TDD, there's a risk of writing tests for every conceivable scenario, including edge cases that are highly improbable. It's essential to prioritize meaningful tests that add value and avoid testing for testing's sake.

False Sense of Security

Just because all tests pass doesn't mean the software is bug-free. Tests are only as good as their scope and quality. There's a risk of developers becoming complacent, assuming that if the tests pass, everything is fine.

TDD brings with it a lot of benefits, it's not a silver bullet. Adopting TDD requires careful consideration of both its advantages and its challenges. However, for many teams and projects, the long-term improvement in code quality, maintainability, and overall software reliability justifies the initial hardship.

TDD vs. Traditional Development Approaches

To truly appreciate the essence of test-driven development (TDD), it is necessary to contrast it with more traditional approaches to software development. Here we explore the differences and contextualize the unique strengths and potential weaknesses of TDD compared to traditional paradigms.

Traditional Development Approach

Often termed as "Waterfall" or simply "code first, test later", the traditional development approach generally follows these steps:

Requirements Gathering: Before any code is written, a comprehensive list of requirements is compiled.
Design & Architecture: The system's design and structure are decided upon based on the requirements.
Implementation: The actual coding happens. This is where developers translate the design into software.
Verification: Once the code is written, it's tested. This could be manual testing, automated testing, or, in many cases, a combination of both.
Maintenance: Post-deployment, the code enters the maintenance phase, where bugs are fixed, and changes are made as needed.

Test-Driven Development (TDD) Approach

TDD, on the other hand, introduces a cyclical paradigm:

Write a Test: Before writing functional code, a test is penned down for the expected functionality.
Run the Test: The test is expected to fail since the functionality isn't there yet.
Write Code: Code is written to fulfill the test's expectations.
Refactor: The code is optimized while ensuring the test still passes.
Repeat: The cycle begins anew for every new feature or functionality.

Contrasting the Two

Feedback Loop: Traditional development often involves longer feedback cycles. Developers might work on a module for days or weeks before it's tested. TDD significantly shortens this loop, allowing for immediate feedback on the written code.
Bug Detection: In traditional approaches, bugs are often detected during the verification phase, which could be much later in the development lifecycle. With TDD, bugs are typically caught and fixed as the code is being written.
Design Philosophy: Traditional development can sometimes lead to overengineering or building features based on assumed needs. TDD forces developers to focus on what's needed immediately, promoting simpler and more modular designs.
Code Safety: With TDD, there's a safety net. Anytime a new feature is added or an existing one is modified, the developer can be assured that they haven’t broken any other part of the application, as long as tests are comprehensive and they all pass.
Mental Model: Traditional development often sees testing as a separate phase. In TDD, testing is the development. It's not an afterthought but the very foundation of the code being written.
Efficiency Over Time: While TDD might seem time-consuming initially, it often leads to faster development cycles in the long run due to reduced time spent debugging and a lower incidence of complex, hard-to-trace bugs.

As software development evolves, more and more teams are finding value in the iterative, feedback-rich environment supported by TDD. This encourages you to think about design, functionality, and potential pitfalls from the very beginning, making the whole process more thoughtful and often more efficient.

Ok, it seems like TDD propaganda. I have to confess I'm a TDD adept. This is the reason why I'm writing this cycle of articles.

TDD in the Context of Other Testing Strategies

Testing is a multi-faceted discipline in software development, where each strategy serves specific purposes in the software life cycle. Test Driven Development (TDD) is just one such strategy. To understand TDD's place in the larger scheme of things, it's important to see how it interacts with other popular testing methodologies.

Unit Testing

What it is: Testing individual units or components of software in isolation from the rest. The focus is on ensuring that specific functions or methods work as expected.

How TDD fits in: TDD is inherently focused on unit testing. When practicing TDD, the tests you're writing are unit tests. The distinction is that in TDD, you write these tests before the actual implementation.

function add(x, y) {
    return x + y;
}

test('test add', () => {
   expect(add(2, 3)).toBe(5);
});

Integration Testing

What it is: Testing the interactions between integrated components or systems to ensure they function together as expected.

How TDD fits in: While TDD’s primary focus is on unit testing, its principles can still guide integration testing. After individual components are developed using TDD, integration tests can be written (or even written first in a TDD fashion) to ensure these units integrate well.

import { databaseConnect, saveUser } from './userModule';

test('saveUser should save user to the database', () => {
    databaseConnect();
    const response = saveUser({ name: 'Alice' });
    expect(response.status).toBe(200);
});

System Testing

What it is: Validating the entire system's functionality against the defined requirements. It’s an end-to-end testing of the whole system.

How TDD fits in: TDD mainly focuses on the development phase. However, the modular and well-defined code resulting from TDD often makes system testing smoother, as individual units are already validated.

Acceptance Testing

What it is: Ensuring the software meets the acceptance criteria defined by the client or end-users. It validates that the right product has been built.

How TDD fits in: Acceptance tests can be seen as a higher-level counterpart to the low-level unit tests written in TDD. In fact, in practices like Behavior-Driven Development (BDD), acceptance tests are written first in a format understandable by non-developers. TDD ensures individual components work, while acceptance tests ensure they work as the client intended.

Regression Testing

What it is: Testing the system to ensure that new code changes haven’t adversely affected existing functionalities.

How TDD fits in: Since TDD involves writing tests for every piece of functionality, it inherently builds a suite of regression tests. As new features are developed and tested, running the existing test suite ensures that nothing previously working is now broken.

While TDD is powerful, it's just one star in the vast galaxy of testing. It is important to view TDD not as a replacement for other testing methodologies, but as a complementary practice. Adopting TDD does not mean neglecting system or integration tests. Instead, it ensures that as we progress through the stages of development, we're building on a solid foundation, allowing other testing strategies to further validate and refine the software.

Follow me
https://t.me/awesomeprog
https://twitter.com/shogenoff
http://facebook.com/shogentle

Hardhat Smartcontract Lottery (Raffle) Using TypeScript and latest versions of everything

Alex Awesome — Sun, 02 Jul 2023 16:07:30 +0000

I am in the progress of learning Patrick Collins' tutorial. This tutorial provided a fantastic introduction to blockchain and web3 development using JavaScript, Solidity, and Hardhat. One of the lessons aimed to develop and deploy a lottery(Raffle) smart contract using hardhat-deploy, hardhat dev testnet, and the Rinkeby testnet. Patrick also implement a typescript version of his code.

This article aims to build upon that work by updating the application to TypeScript and using the latest versions of all dependencies. I would like to use TypeScript in a stronger way. We'll also switch from the Rinkeyby testnet to the Sepolia testnet, which is more up-to-date.

It's not a complete tutorial of creating a hardhat application. It's just an extension to Patrick Collins' ultra-ultimate tutorial for year 2023 when we have ehters.js version 6.

This is the typescript branch Patric Collins' repository https://github.com/PatrickAlphaC/hardhat-smartcontract-lottery-fcc/tree/typescript

We will be making a few small corrections in line with the rapidly changing worlds of JS and blockchain.

Installation & preparations

Hardhat has great documentation https://hardhat.org/hardhat-runner/docs/getting-started#installation. I will describe hardhat things in a nutshell.

Installation and setting up

You can install hardhat globally or locally. I prefer the second option but if you desire to be a super-skilled senior smart-contract developer you probably need to have it installed globally. Anyway, we have to install hardhat somehow.

Then we should initiate the project

hardhat
npx hardhat

Or after installing the hardhat-shorthand you can use just

hh

To simplify the process we chose the Typescript project option:

Agree with everything and set it up.

We don't need contracts, scripts, and tests generated by Hardhat.

rm -rf contract/ scripts/ test/

We will have the same Solidity contract as Patrik. https://github.com/shaggyrec/hardhat-smartcontract-lottery-ts/blob/main/contracts/Raffle.sol
There are no changes here.

We also have to install a couple of dependencies

npm i @nomicfoundation/hardhat-toolbox @nomiclabs/hardhat-ethers@npm:hardhat-deploy-ethers dotenv hardhat-gas-reporter -D

I usually use eslint. Patrick used prettier. It doesn't matter which tool you choose. But it would be good practice to choose something because JS allows you too much and you should have borders to have your code in great condition.

For eslint I need to make

npm i eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser -D

and turn it on in the IDE.

We can make 'hh compile to have contract typings to write our code. But it is not necessary. The Hardhat executes this command right before the deploy.

Config

We want to use TypeScript. And we want to use it in the right way. Patrik Collins has helper-hardhat-config.ts in his repo we won't. Instead of it, we will extend the Hardhat config.

I don't want to use any additional config files. And I really want to have all configurations of the current network in the network option. This is a difference between Patrics' solution and the current solution. In the following config file you can see blockConfirmations, entranceFee, gasLane, subscriptionId, callbackGasLimit, interval option right in the network object.

import '@typechain/hardhat';
import '@nomicfoundation/hardhat-toolbox';
import '@nomiclabs/hardhat-ethers';
import '@nomicfoundation/hardhat-ethers';
import 'hardhat-deploy';
import 'hardhat-gas-reporter';
import './type-extensions';
import 'dotenv/config';
import { HardhatUserConfig } from 'hardhat/config';
import { ethers } from 'ethers';


const config: HardhatUserConfig = {
    solidity: '0.8.18',
    defaultNetwork: 'hardhat',
    networks: {
        hardhat: {
            chainId: 31337,
            blockConfirmations: 1,
            entranceFee: ethers.parseEther('0.01'),
            gasLane: '0x474e34a077df58807dbe9c96d3c009b23b3c6d0cce433e59bbf5b34f823bc56c',
            subscriptionId: '',
            callbackGasLimit: '500000',
            interval: 30
        },
        sepolia: {
            chainId: 11155111,
            url: process.env.SEPOLIA_RPC_URL,
            accounts: [process.env.SEPOLIA_PRIVATE_KEY as string],
            blockConfirmations: 6,
            vrfCoordinator: '0x8103B0A8A00be2DDC778e6e7eaa21791Cd364625',
            entranceFee: ethers.parseEther('0.01'),
            gasLane: '0x474e34a077df58807dbe9c96d3c009b23b3c6d0cce433e59bbf5b34f823bc56c',
            subscriptionId: '3092',
            callbackGasLimit: '500000',
            interval: 30
        }
    },
    etherscan: {
        apiKey: {
            sepolia: process.env.ETHERSCAN_API_KEY || ''
        },
    },
    namedAccounts: {
        deployer: {
            default: 0
        },
        player: {
            default: 1
        }
    },
    developmentChains: ['hardhat', 'localhost'],
    organizerFee: 10,
    mocha: {
        timeout: 40000
    }
};

export default config;

But it's not enough. TypeScript/Eslint will show the errors

One more important thing.
In ethers 6 you can no longer use ethers.utils.parseEther('0.01') the function doesn't exist. Utils isn't exit. We should use just ethers.parseEther('0.01').

I created type-extensions.ts file to extend the default config.

import 'hardhat/types/config';

declare module 'hardhat/types/config' {
    export interface HttpNetworkUserConfig {
        blockConfirmations?: number;
        vrfCoordinator?: string;
        entranceFee: bigint;
        gasLane: string;
        subscriptionId?: string;
        callbackGasLimit: string;
        interval: number;
    }

    export interface HardhatNetworkUserConfig {
        blockConfirmations?: number;
        entranceFee: bigint;
        gasLane: string;
        subscriptionId?: string;
        callbackGasLimit?: string;
        interval: number;
    }

    export interface HardhatUserConfig {
        developmentChains: string[];
        organizerFee: number;
    }

    export interface HttpNetworkConfig {
        blockConfirmations: number;
        vrfCoordinator: string;
        entranceFee: bigint;
        gasLane: string;
        subscriptionId: string;
        callbackGasLimit: string;
        interval: number;
    }

    export interface HardhatNetworkConfig {
        blockConfirmations: number;
        vrfCoordinator?: string;
        entranceFee: bigint;
        gasLane: string;
        subscriptionId: string;
        callbackGasLimit: string;
        interval: number;
    }

    export interface HardhatConfig {
        developmentChains: string[];
        organizerFee: number;
    }
}

I believe that structure is very clear. Declarations with UserConfig suffix are for hardhat config. Declarations with Config suffix are for exposing these properties in your scripts.

Let see it. The deploy/01-deploy-raffle.ts should be similar to

import { HardhatRuntimeEnvironment } from 'hardhat/types';
import { config, network } from 'hardhat';
import { DeployFunction } from 'hardhat-deploy/dist/types';
import verify from '../utils/verify';
import { VRFCoordinatorV2Mock } from '../typechain-types';
import { EventLog } from 'ethers';

const deployRaffle: DeployFunction = async function ({ getNamedAccounts, deployments, ethers }: HardhatRuntimeEnvironment) {
    const { deploy, log } = deployments;
    const { deployer } = await getNamedAccounts();
    let vrfCoordinatorV2Address = network.config.vrfCoordinator;
    let subscriptionId = network.config.subscriptionId;
    let vrfCoordinatorV2Mock: VRFCoordinatorV2Mock;

    if (config.developmentChains.includes(network.name)) {
        vrfCoordinatorV2Mock = await ethers.getContract('VRFCoordinatorV2Mock');
        vrfCoordinatorV2Address = await vrfCoordinatorV2Mock.getAddress();
        const transactionReceipt = await (await vrfCoordinatorV2Mock.createSubscription())
            .wait(1);

        subscriptionId = (transactionReceipt?.logs[0] as EventLog).args.subId;
        await vrfCoordinatorV2Mock.fundSubscription(subscriptionId, ethers.parseEther('2'));
    }

    const args = [
        vrfCoordinatorV2Address,
        network.config.entranceFee,
        network.config.gasLane,
        subscriptionId,
        network.config.callbackGasLimit,
        network.config.interval,
        config.organizerFee
    ];

    const raffle = await deploy('Raffle', {
        from: deployer,
        args,
        log: true,
        waitConfirmations: network.config.blockConfirmations || 1
    });

    if (config.developmentChains.includes(network.name)) {
        await vrfCoordinatorV2Mock!.addConsumer(subscriptionId, raffle.address);
    }

    if (!config.developmentChains.includes(network.name) && process.env.ETHERSCAN_API_KEY) {
        await verify(raffle.address, args, log);
    }

    log('----------------------------');
};

deployRaffle.tags = ['all', 'raffle'];
export default deployRaffle;

We've imported the network from the hardhat and I can use network.config.vrfCoordinator, network.config.subscriptionId. Awesome!

Another awesome thing is that we have hintings for our contract object.

We can get contract using TypeSctipt generics thing

import { Raffle } from '../typechain-types';

const raffle = await ethers.getContract<Raffle>('Raffle');

And now we can use this kind of magic:

All other things of the application are the same. I will attach the link to the repository in the end of this article.

Tests

Tests are almost the same. We have the difference in case of bigint interactions. But it is so easy:

const contractBalance = BigInt(raffleEntranceFee) * BigInt(additionalEntrances) + BigInt(raffleEntranceFee);

Also, we should use instead of

raffle.callStatic.checkUpkeep("0x")

a bit different

raffle.checkUpkeep.staticCall('0x');

And we can replace this bulky time-machine functionality

await network.provider.send('evm_increaseTime', [interval + 1]);
                await network.provider.request({ method: 'evm_mine', params: [] });

with laconic

import { time } from '@nomicfoundation/hardhat-toolbox/network-helpers';
...
await time.increase(interval + 1);

I have two skipped tests because at the time of writing this article events firing doesn't work properly in the latest version. Link to the github issue

Sepolia

Patric Collins works with Rinkeby in his tutorial. Using of Sepolia is quite similar.

Creating subscription https://docs.chain.link/vrf/v2/subscription/supported-networks/#sepolia-testnet

VRF things https://vrf.chain.link/

Upkeep registering https://automation.chain.link/sepolia

Etherscan https://sepolia.etherscan.io/

Conclusion

We can deploy and enter the lottery

hh deploy --network sepolia
hh run scripts/enterRaffle.ts --network sepolia

We used the latest version on everything and bit rewrite Freecodecamp Patrick Collins' Raffle application

We have a problem with a subscription to the events in the latest version of hardhat. But I believe that it will be fixed soon.

There you have it, a lottery smart contract built with Hardhat, TypeScript, and the latest versions of all dependencies, and deployed locally or on the Sepolia testnet.

The link to the repository of this article is

https://github.com/shaggyrec/hardhat-smartcontract-lottery-ts

Follow me

https://t.me/awesomeprog
https://twitter.com/shogenoff
http://facebook.com/shogentle

Mastering Test-Driven Development. Introduction

Alex Awesome — Wed, 21 Jun 2023 14:23:22 +0000

I'm going to write a series of articles about the TDD.
It should be an ultimate almanac-tutorial for this topic.
It's the first part of this long journey. Let's go.

Welcome to "Mastering Test-Driven Development: A Practical Approach." Fasten your seat belts because we are embarking on a fantastic journey through the world of Test-Driven Development (TDD).

Importance of Test-Driven Development (TDD)

Instead of the traditional method of writing code and then testing for bugs, what if we switched things up? What if we flip the script and write our tests first, then develop our code to pass those tests? This is called Test-Driven Development. TDD is about setting the rules of the game before it starts.

TDD offers an array of benefits. It ensures the code is error-free, makes easy maintenance, improves the design, and ensures that your code works as expected.

We'll walk you through TDD, from the basic principles, through the nuances of test writing, to advanced techniques and best practices. Whether you're a skilled developer or just starting out, our aim is to equip you with the knowledge and skills needed to integrate TDD into your coding process.

So, are you ready to change your coding game and use a method that enables you to produce better, cleaner, and more reliable code? Let's dive into the world of Test-Driven Development.

Promises and challenges of TDD

The beauty of Test-Driven Development is in its promise. TDD promises greater confidence in your code, improved design, reduced debugging time, and code that's easier to maintain and refactor. It's the promise to replace that constant feeling of being "lost in the code" with a methodical, navigable, and systematic approach.

But you will face challenges.
Writing tests before the code can seem counterintuitive, sometimes even tedious. It requires discipline, might slow you down in the beginning, and can even seem like overkill for simple tasks.

I remember myself at the beginning of the TDD way. I couldn't understand how to write tests before the code. Actually, I wrote one test before the coding and the rest of them after. It was not TDD.

Moreover, you might face skepticism or resistance from colleagues or managers unfamiliar with the benefits of TDD. If you're working in a team setting, achieving the buy-in necessary to shift the entire development process can be tough.

The initial challenges pale in comparison to the benefits that unfold as you get the hang of it. The code becomes self-documenting, you have fewer bugs, and the quality of your software improves.

In the following chapters, we'll go through both the promise and the challenges of TDD. We will be arming ourselves with the tools to overcome these challenges and use TDD to its full potential. You're in control, and with TDD, you'll be piloting your coding projects with increased confidence and efficiency.

Overview

Let's watch a «trailer» for the series of articles.
It defines our path to mastering TDD.

In «Understanding Test-Driven Development», we'll start from the basics. It's like the instruction manual for your new gadget, but a lot more fun. We'll explore what TDD is, why it matters, and how it contrasts with traditional development approaches.

Moving on to «TDD Workflow and Principles», we'll dive deeper into TDD. We'll discover the red-green-refactor cycle and the discipline of writing tests first.

In «Setting Up Your TDD Environment», we'll choose the right tools, install the necessary frameworks, and get everything ready for our TDD adventure.

When we get to «Writing Your First Test», things start to get real. We'll start to write test cases.

In «Implementing Code to Pass Tests» we'll discuss how to write code that satisfies your tests, ensuring that it meets the necessary requirements.

«Refactoring for Maintainability and Efficiency»: Here, we'll learn to improve your code through refactoring, while maintaining its behavior and using your tests to validate those changes.

Section «Advanced TDD Techniques» will cover more sophisticated aspects of TDD, like mocking, stubbing, and using test doubles.

After «TDD Best Practices», we'll know how to ensure your tests cover enough code, are easy to read and maintain, and how to strike a balance between unit and integration tests.

«TDD in Agile and DevOps»: We'll explore how TDD fits into Agile methodologies and DevOps practices, particularly its role in continuous integration.

In the final chapter, «Real-World TDD Case Studies», we'll try to find success stories, challenges, and advice from real-world implementations.

The aim of these articles is to take you from understanding the basic principles of TDD to being able to effectively implement it in your work.

To be continued...

Latest news of the devs week

Alex Awesome — Mon, 08 May 2023 10:33:25 +0000

Slack is working on its own AI

Slack is developing new generative AI capabilities, which will offer users automatic conversation summaries and native AI-powered writing assistance within its collaboration application.

Ali Rayl, Slack’s vice president of customer experience said:

We think that Slack has a unique advantage when it comes to generative AI. First and foremost, we hold an enormous amount of institutional knowledge: everything that your entire team has done in channels for the years that you've been using Slack, it's in your archives, it's all at your fingertips. That's an enormous body of knowledge for us to tap into.
Given the reliance we all have on chat-based collaboration, leveraging generative AI to summarize and automate what we have to do now — labor intensive scrolling around, switching from chat stream to chat stream, uncovering the key people in those endless threads — these types of initial applications of generative are helpful advancements

Link to the full article

Discord declared that all users on the platform will be requested to modify their usernames in the upcoming weeks.

Previously, users were identified by a name preceding a hash and four numbers.
The new system will require people to create a unique username following an "@" symbol, bringing it in line with Twitter, Instagram and other platforms.

It's time to start discord names squatting business

Full article

Microsoft are betting the farm on generative AI

Microsoft is commencing the next stage of Bing's growth, with a strong emphasis on AI integration. During a recent preview event in New York City, Microsoft executives showcased various features that will be added to Bing in the coming days, weeks, and months. These enhancements build upon Bing's recent developments, such as the AI-powered chatbot, Bing Chat, which utilizes OpenAI's GPT-4 and DALL-E 2 models. With over 100 million daily active users, Bing has facilitated more than half a billion chats and generated over 200 million images.

In the future, Bing will become more visually-oriented, incorporating image- and graphic-based responses in Bing Chat. Additionally, it will offer a more personalized experience by enabling users to export their Bing Chat histories and integrate content from third-party plugins. Bing Chat will also support multimodality, as it will be capable of answering queries in the context of images.

Full article

Apple and Google have partnered to address the issue of unwanted tracking through Bluetooth trackers like AirTags and Tile devices, aiming to combat stalking and other malicious uses

Apple and Google have collaborated on a pioneering industry proposal aimed at preventing the misuse of Bluetooth location-tracking devices for unwanted tracking purposes. This unique specification will enable such devices to be compatible with unauthorized tracking detection and alerts on both iOS and Android platforms. Companies like Samsung, Tile, Chipolo, eufy Security, and Pebblebee have expressed their support for the draft specification, which provides best practices and guidelines for manufacturers who wish to incorporate these features into their products

“Apple launched AirTag to give users the peace of mind knowing where to find their most important items,” said Ron Huang, Apple’s vice president of Sensing and Connectivity. “We built AirTag and the Find My network with a set of proactive features to discourage unwanted tracking — a first in the industry — and we continue to make improvements to help ensure the technology is being used as intended. This new industry specification builds upon the AirTag protections, and through collaboration with Google results in a critical step forward to help combat unwanted tracking across iOS and Android.”

Text if the note

We don't help with a visa, we give the opportunity to work from anywhere in the world.

Alex Awesome — Tue, 11 Apr 2023 18:55:53 +0000

I started to hear/read this statement quite often. In my opinion, it's the substitution of concepts. Let's dive into these manipulations to understand what is wrong with them.

Remote working is great. Most companies realized this after COVID-19. Now we can have a full remote or hybrid workflow from so many potential employers.

As more organizations recognize the benefits of remote work, such as reduced overhead costs, increased productivity, and access to a broader talent pool, it is becoming an increasingly popular option for both employers and employees. However, this newfound flexibility has also given rise to some challenges and complexities, particularly when it comes to employer responsibilities related to visa and legalization support.

The problem

In traditional work settings, employers often have established processes in place to assist with the legal and logistical aspects of hiring and relocating employees, including securing visas and work permits.

However, as telecommuting becomes more common, some employers are using this flexibility as an excuse to not provide the support they need, claiming that employees can work from anywhere they choose.

And it's too strong when a company says in vacation description or on an interview "We are the US/European company", "You will a part of the US/European company". It's so prestigious.

But this prestige has no meaning while can be a resident of this US/EU.

The Legal and Ethical Aspects of Visa and Legalization Support

Employer Obligations for In-Person Employees

For in-person employees, employers generally have a legal responsibility to assist with visa and work permit processes, as well as ensure compliance with local labor laws and regulations. This may include tasks such as sponsoring work visas, facilitating the issuance of work permits, and providing necessary documentation to government agencies. Additionally, employers must adhere to labor laws regarding wages, working hours, employee benefits, and safety regulations, among other things.

The Impact of Remote Work on These Obligations

In some cases, remote work can blur the lines between local and international employment laws, making it difficult to determine which rules apply. As a result, some employers may exploit this ambiguity to avoid providing visa and legalization support to their remote employees, passing the bear to the workers.

Moreover, remote work can make it challenging for authorities to enforce labor laws and protect employee rights. This can create situations where remote workers are more vulnerable to exploitation and may lack recourse in the face of unfair treatment by their employers.

Ethical Considerations for Providing Support

From an ethical point, employers should strive to create a supportive work environment for all employees, regardless of their location. This includes assisting remote workers with visa and legalization processes, and ensuring they have the necessary permissions and documentation to work legally in their chosen location. By doing so, employers demonstrate a commitment to fairness, equity, and the well-being of their employees.

Additionally, employers should consider the potential consequences of not providing visa and legalization support, such as increased stress, financial burden, and legal risks for remote employees. By prioritizing these aspects of remote work, employers can help to create a more sustainable and responsible remote work culture.

Consequences of Avoiding Visa and Legalization Support

Challenges Faced by Remote Employees

When employers avoid providing visa and legalization support, remote employees are left to face numerous challenges. Navigating the complexities of immigration and legal systems can be both time-consuming and costly, with employees often having to cover the expenses themselves. Additionally, remote workers may struggle to find accurate information and guidance on how to secure the necessary permissions, making the process even more daunting.

In some cases, the lack of employer support may lead to remote employees working without proper authorization or legal status, which can expose them to potential penalties and jeopardize their employment. Furthermore, the absence of a valid visa or work permit may limit remote employees' ability to access essential services such as healthcare, banking, and housing, significantly impacting their quality of life.

Impact on Employee's Morale and Retention

The absence of visa and legalization support can take a toll on employee morale and job satisfaction. Remote employees may feel undervalued and unsupported by their employers, leading to feelings of frustration, stress, and resentment. This can result in decreased productivity, engagement, and loyalty towards the company.

Over time, this lack of support may lead to higher employee turnover, as remote workers search for more accommodating and supportive employers. The costs associated with employee turnover, such as recruitment, training, and lost productivity, can be substantial, ultimately affecting the company's bottom line.

Long-term consequences for the company's reputation

Avoiding visa and legalization support responsibilities can also have long-term consequences for a company's reputation. As word spreads about an employer's unwillingness to provide necessary support, potential employees may be deterred from applying, making it more difficult for the company to attract top talent.

In an increasingly connected world, where employee reviews and feedback can significantly influence a company's reputation.

Recommendations for Employers and Remote Employees

How Employers Can Provide Visa and Legalization Support for Remote Workers

Develop clear policies.
Assign dedicated support personnel.
Partner with legal experts.
Offer financial assistance.

Steps Remote Employees Can Take to Address the Issue and Protect Themselves

Research potential employers.
Seek clarification: Request clear information about the employer's policies and procedures.
Document communication: Keep a record of all communication with the employer regarding visa and legalization support.
Consult legal experts.

Conclusion

The Importance of Addressing This Issue in the Remote Work Era

As remote work continues to grow in popularity, it is crucial to address the issue of employers bypassing their responsibilities for visa and legalization support. Failing to provide adequate support can have far-reaching consequences, affecting the well-being of remote employees, company reputation, and employee retention.

Encouraging Fair and Responsible Employer Practices

Employers must recognize their obligations and adopt fair and responsible practices that prioritize the needs of their remote workforce. By providing comprehensive visa and legalization support, employers demonstrate a commitment to their employees' well-being and help create a more equitable work environment. Taking these steps can also lead to increased employee satisfaction, loyalty, and productivity, ultimately benefiting the company in the long run.

Creating a Better Remote Work Environment

Creating a supportive remote work environment requires a collaborative effort between employers, employees, and policymakers. Employers should implement clear policies and provide resources for remote employees, while employees should take proactive steps to protect themselves and advocate for better working conditions. Policymakers must also work to update labor laws and regulations to address the unique challenges of remote work and ensure that employer responsibilities are enforceable.

Digital Nomad Visa of Spain

Alex Awesome — Sat, 08 Apr 2023 14:18:17 +0000

Remote working isn't something very new. We all were jealous of these attractive pictures of freelancers' work-style.

So many people aren't linked with any place because of remote working. And since 2020, the popularity of this concept has grown incredibly.
Digital nomads are individuals who use technology to work from anywhere in the world, untethered by the constraints of traditional office spaces. These professionals typically have location-independent jobs, such as programming, designing, freelancing, consulting, or working for companies with remote work policies. As digital nomads, they have the unique opportunity to combine their work with travel, experiencing new cultures and destinations while maintaining a steady income.

The growing trend of digital nomads has prompted countries worldwide, including Spain, to develop specialized visas to attract these people.

These visas allow remote workers to reside in the host country for extended periods, granting them access to local resources and infrastructure while contributing to the local economy. By offering these specialized visas, countries aim to attract skilled professionals who can boost their economy, foster innovation, and promote cultural exchange. Spain has been thinking for a very long time and has become one the latest countries to join this trend.

Overview of Spain's Nomad Visa

Eligibility Criteria

Spain's nomad visa aims to attract digital nomads who have certain requirements, ensuring that they can be financially self-sufficient and make a positive contribution to the local economy. To be eligible for a visa, applicants must meet the following criteria:

Proof of remote work: Applicants must provide evidence that they have a location-independent job, which allows them to work remotely. This can include a signed contract with an employer, a letter confirming their freelance or consulting work, or a description of their online business.
Minimum income threshold: Applicants must demonstrate that they have a stable and sufficient income to support themselves during their stay in Spain. At the time of this writing, this is €2,334 per month / €28,000 per year for an individual.
Valid passport: Applicants need to have a valid passport with an expiration date that extends beyond the duration of their intended stay in Spain. This is very logical, isn't it?
Health insurance: Digital nomads applying for the visa must have comprehensive health insurance coverage that is valid in Spain for the entire duration of their stay. The insurance should cover medical expenses, hospitalization, and repatriation.
No criminal record: Applicants must provide a certificate of no criminal record from their country of residence for the past five years, proving that they do not have any outstanding criminal charges or convictions.
No unauthorized stay in Spain: Digital nomads must not have previously stayed in Spain without proper authorization.
Sufficient experience and/or education: Either demonstrate 3 years of work-related experience prior to application, or be a graduate or post-graduate from a reputable university, vocational training, and business schools of recognized prestige

One more time, you need to have proofs of remote work and minimum income threshold, health insurance for one year and a certificate of no criminal record.
It's not a very big list, right?

Duration of the Visa and Possibility of Extension

The visa is initially granted for a duration of one year if the applicant is applying from their country of residence. Three years for an applicant who does so from Spain.
The visa owner will have enough time to settle down, explore the country, and benefit from the local resources and infrastructure.

After the first(3rd in the second case) year, digital nomads have the option to extend their stay by applying for a visa renewal. At the moment of the extension, the applicant must still meet the eligibility criteria from the list above 👆.
The visa owner could extend their visa for up to five years.

Application Process for Spain's Nomad Visa

Required Documents

These documents include, but are not limited to:

Valid passport and its copy
Proof of remote work (Contract and Letter of authorization from to work remotely in Spain)
Proof of income
Proof of payment of the administrative fee
Health insurance
Certificate of no criminal record
Sufficient experience and/or education
Visa application form: A completed and signed application form for the nomad visa.
Passport-sized photos: Two recent passport-sized photographs that meet the consulate's requirements.

Application Fees

Applicants must pay a non-refundable visa application fee when submitting their application. It costs roughly 70 euros.

Once you're approved for the visa, it's about 15 euros to apply for a residence card.

Timeline for Processing the Application

The processing time for Spain's nomad visa application may vary depending on the consulate or embassy, as well as the applicant's individual circumstances. Generally, the processing time can range from a few weeks to a few months. It is recommended to apply well in advance of the intended travel date to account for any potential delays in processing.

Where to Apply

Applicants have two ways:

consulate in your country of residence
directly from Spain, as a tourist.

Applicants would get a 1-year visa (that can be modified to residency later on) for the first case. And they could obtain a 3-year permit (renewable for 2) in the second case.

Then, the applicant will need to visit the police office as one of the final steps to register their fingerprints and get their physical residency card.

Seems not very difficult. But the consulate can disapprove the application. I think we need to ask them very politely.

Taxes and Obligations

Do digital nomads have to pay taxes in Spain?

Digital nomads will inevitably become tax residents. And that's because if they want to extend their visa, they must abide by the first rule: spend at least 6 months in the country. Thus they must be aware of their tax obligations.

Report and remit taxes on earnings generated globally (including Spain and all other countries)
Pay income tax at an incremental rate that may go up to 50% (with minor regional variations)
Declare their assets by completing Form 720

Beckham law

The Beckham Law is a unique tax regime that enables you to be treated as a non-resident for tax purposes, even if you spend over 183 days in the country.

Gaining tax non-resident status offers significant benefits (compared to being a tax resident), as it allows for a substantially reduced income tax rate and eliminates the need to file and pay certain other taxes.

To be eligible for this special tax regime, you must not have been a legal resident in Spain for the past five years, and the reason for your move to Spain must be work-related (which applies to remote workers).

If you meet this initial requirement, you will have six months from the time you receive a positive resolution for your digital nomad visa to submit your application at the tax office.

Upon approval, you will enjoy the considerable advantages of being a non-resident for a total of five years (in addition to the year in which you apply). Afterward, you would transition to the general resident tax regime.

David Beckham saved up money with Beckham's law and was able to buy a yacht. Be like David.

How much exactly?

Digital nomads or remote workers in Spain using the Beckham law pay a flat rate of 24% on their work-related income up to €600,000, and 48% on any amount above that amount.

This is highly advantageous, as under the general tax system, you would pay a progressive rate that could go up to 50%.

But the benefits don't stop there.

As a digital nomad taking advantage of this special tax regime, you'll also experience additional tax advantages, such as:

No need to file Form 720 (which residents are required to file annually to declare their assets)
Exemption from wealth tax
Reduced capital gains tax, with a variable rate ranging from 19% to 28%

Is it possible to work in Spain digital nomad visa?

Yes, but income from Spain must not exceed 20% of all income.

Conclusion

Spain is an attractive destination for digital nomads, offering a rich cultural experience, a wide range of workspaces, and ample networking opportunities. By exploring the diverse cities and regions of Spain, digital nomads can find the perfect environment to thrive in their location-independent lifestyle.

Additionally, Spain's tax system, particularly the Beckham Law, can offer financial advantages for digital nomads, potentially leading to significant tax savings.

With a thriving startup environment, extensive collaboration spaces and numerous networking opportunities, Spain provides a great environment for digital nomads to grow personally and professionally. In addition, the country's excellent quality of life, warm climate, and rich history make it an attractive place to explore and relax in your spare time.

P.S. I know of a case where a digital nomad received this type of visa for 3 years initially. He did it in the Canary Islands.

Create a blog with content stored in GitHub (Examples in Golang)

Alex Awesome — Fri, 31 Mar 2023 18:18:50 +0000

You have the cheapest and easiest way to start your own IT(or not) blog. You don't need a lot of space to store your photos, and you don't even need to use a database.

In this article, I suggest using GitHub to store and edit articles. We will use a familiar GitHub markdown to design articles.

I will use Golang examples. But we can rewrite this code in PHP if we want the cheapest or even free solution. We can get the simplest PHP hosting that can be free.

Let's get it started!

Preparations

First, I need to choose the Go web framework. It doesn't matter which one. I closed my eyes and pointed at the pkg.go.dev site. My finger was on the Gin Framework. Okay, this is a popular choice.

Install Gin using the following command:

go get -u github.com/gin-gonic/gin

Then create a basic Gin web server:

package main

import (
    "github.com/gin-gonic/gin"
)

func main() {
    router := gin.Default()
    router.GET("/", getHome)
    router.GET("/article/:articleID", getArticle)
    router.Run(":8080")
}

func getHome(c *gin.Context) {
    c.String(200, "Welcome to the blog!")
}

func getArticle(c *gin.Context) {
    articleID := c.Param("articleID")
    c.String(200, "Displaying article with ID: %s", articleID)
}

Fetch content for GitHub

To fetch articles from a GitHub repository, we'll need to use the GitHub API. You can use the google/go-github library:

go get github.com/google/go-github/v39/github

Add a function to fetch articles from the GitHub repository:

package main

import (
    "context"
    "fmt"
    "os"

    "github.com/gin-gonic/gin"
    "github.com/google/go-github/v39/github"
    "golang.org/x/oauth2"
)

// ...

func getArticle(c *gin.Context) {
    articleID := c.Param("articleID")
    content, err := fetchArticle(articleID)
    if err != nil {
        c.String(500, "Error fetching article")
        return
    }
    c.String(200, "Article content:\n%s", content)
}

func fetchArticle(articleID string) (string, error) {
    ctx := context.Background()
    ts := oauth2.StaticTokenSource(
        &oauth2.Token{AccessToken: os.Getenv("GITHUB_TOKEN")},
    )
    tc := oauth2.NewClient(ctx, ts)
    client := github.NewClient(tc)

    fileContent, _, _, err := client.Repositories.GetContents(ctx, os.Getenv("GITHUB_USERNAME"), os.Getenv("GITHUB_REPO"), "path/to/articles/"+articleID+".md", &github.RepositoryContentGetOptions{})
    if err != nil {
        return "", err
    }

    content, err := fileContent.GetContent()
    if err != nil {
        return "", err
    }

    return content, nil
}

We need to set up a GitHub access token with the repo scope and store it in the GITHUB_TOKEN environment variable. We also need to store the environment variables "GITHUB_USERNAME" and "GITHUB_REPO" with the values of the actual GitHub username and repository name.

This example serves as a starting point for creating a blog that fetches articles from a GitHub repository using Golang.

Then we need to build upon this example to handle templating, styling, and other web development tasks to create a complete website.

Render HTML

To render articles from Markdown to HTML, we can use the github.com/gomarkdown/markdown package. This package also supports syntax highlighting for code blocks. It's very important for us because we are trying to create a popular IT blog.

First, install the necessary packages:

go get -u github.com/gomarkdown/markdown
go get -u github.com/gomarkdown/markdown/parser

Next, modify the fetchArticle function to convert the fetched Markdown content into HTML, and update the getArticle function to render the HTML content:

package main

import (
    "context"
    "fmt"
    "os"

    "github.com/gin-gonic/gin"
    "github.com/github.com/gomarkdown/markdown"
    "github.com/github.com/gomarkdown/markdown/parser"
    "github.com/google/go-github/v39/github"
    "golang.org/x/oauth2"
)

// ...

func getArticle(c *gin.Context) {
    articleID := c.Param("articleID")
    content, err := fetchArticle(articleID)
    if err != nil {
        c.String(404, "Article not found")
        return
    }
    c.Data(200, "text/html; charset=utf-8", []byte(content))
}

func fetchArticle(articleID string) (string, error) {
    ctx := context.Background()
    ts := oauth2.StaticTokenSource(
        &oauth2.Token{AccessToken: os.Getenv("GITHUB_TOKEN")},
    )
    tc := oauth2.NewClient(ctx, ts)
    client := github.NewClient(tc)

    fileContent, _, _, err := client.Repositories.GetContents(ctx, "YourGitHubUsername", "YourRepoName", "path/to/articles/"+articleID+".md", &github.RepositoryContentGetOptions{})
    if err != nil {
        return "", err
    }

    markdownContent, err := fileContent.GetContent()
    if err != nil {
        return "", err
    }

    // Parse and render the Markdown content
    extensions := parser.CommonExtensions | parser.AutoHeadingIDs
    mdParser := parser.NewWithExtensions(extensions)
    htmlContent := markdown.ToHTML([]byte(markdownContent), mdParser, nil)

    return string(htmlContent), nil
}

Now, the fetchArticle fetches the Markdown content from the GitHub repository, convert it to HTML, and renders in the browser with syntax highlighting for code blocks.

So far this code only covers the basics of rendering Markdown to HTML. We need to add CSS.

Make it stylish

To render HTML we can use the html/template package from the Go standard library.

Create a new file called templates/base.html with the following content:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="description" content="{{.Description}}">
    <title>{{.Title}}</title>
    <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css">
    <style>
        /* Add your custom CSS styles here */
    </style>
</head>
<body>
    <div class="container">
        {{.Content}}
    </div>
</body>
</html>

We use the Bootstrap CSS framework for styling to make it simpler.
You can replace it with your preferred CSS framework or custom styles.

Next, update the getArticle function to render the article content using the base.html template:

package main

import (
    "context"
    "fmt"
    "os"
    "html/template"

    "github.com/gin-gonic/gin"
    "github.com/github.com/gomarkdown/markdown"
    "github.com/github.com/gomarkdown/markdown/parser"
    "github.com/google/go-github/v39/github"
    "golang.org/x/oauth2"
)

// ...

func getArticle(c *gin.Context) {
    articleID := c.Param("articleID")
    content, err := fetchArticle(articleID)
    if err != nil {
        c.String(500, "Error fetching article")
        return
    }

    tmpl, err := template.ParseFiles("templates/base.html")
    if err != nil {
        c.String(500, "Error loading template")
        return
    }

    data := map[string]interface{}{
        "Title":       "Your Blog - " + articleID,
        "Description": "An article with the ID " + articleID,
        "Content":     template.HTML(content),
    }

    err = tmpl.Execute(c.Writer, data)
    if err != nil {
        c.String(500, "Error rendering template")
    }
}

// ...

I also added the simplest way to render <title> and <description> tags.

Code-style

We want to copy the GitHub style of .md files for our blog design.
We will include the github-markdown-css package and a syntax highlighting library highlight.js.

First, update the templates/base.html file to include the necessary styles and scripts:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="description" content="{{.Description}}">
    <title>{{.Title}}</title>
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/4.0.0/github-markdown.min.css">
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.6.0/styles/github.min.css">
    <script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.6.0/highlight.min.js"></script>
    <script>hljs.highlightAll();</script>
    <style>
        .markdown-body {
            box-sizing: border-box;
            min-width: 200px;
            max-width: 980px;
            margin: 0 auto;
            padding: 45px;
        }

        @media (max-width: 767px) {
            .markdown-body {
                padding: 15px;
            }
        }
    </style>
</head>
<body>
    <div class="container markdown-body">
        {{.Content}}
    </div>
</body>
</html>

That's it. Quite simple, isn't it? Now our blog should display articles with GitHub-style CSS and proper syntax highlighting for code blocks.

Images

The last one is images. At this point, our blog is not displaying images because the image links have relative paths.

To host images for the articles on GitHub and include them in the content, we can follow these steps:

Create directory

Upload your images to a specific folder in your GitHub repository. In our case it will will be the images folder

Add images to the article

In the Markdown article, reference the image using a relative path to the image file in your GitHub repository:

![Image description](/images/your-image-file.jpg)

Replace the image in the server-side

When fetching the article content in the fetchArticle function, replace the relative image paths with their corresponding raw.githubusercontent.com URLs:

// ...

func fetchArticle(articleID string) (string, error) {
    // Fetch article content from GitHub
    // ...

    // Replace relative image paths with raw.githubusercontent.com URLs
    rawImageBaseURL := "https://raw.githubusercontent.com/YourGitHubUsername/YourRepoName/main/images/"
    re := regexp.MustCompile(`!\[(.*?)\]\(/images/(.+?)\)`)
    markdownContent = re.ReplaceAllString(markdownContent, fmt.Sprintf(`![$1](%s$2)`, rawImageBaseURL))

    // Convert Markdown to HTML
    // ...

    return string(htmlContent), nil
}

It will work only for public repositories. If you would like to have a private one your code will be a bit complicated.

You can create a getImage function for getting images from GitHub:


func getImage(c *gin.Context) {
    path := c.Param("path")
    if _, ok := imagesCache[path]; !ok {
        response, err := requestFromGithub("images/" + path)
        if err != nil {
            c.String(404, "Not found")
        }
        responseImg, _ := http.Get(*response.DownloadURL)
        buf := new(strings.Builder)
        io.Copy(buf, responseImg.Body)
        imagesCache[path] = buf.String()
    }
    c.String(200, imagesCache[path])
}


func requestFromGithub(path string) (*github.RepositoryContent, error) {
    ctx := context.Background()
    var ts = oauth2.StaticTokenSource(
        &oauth2.Token{AccessToken: os.Getenv("GITHUB_TOKEN")},
    )
    tc := oauth2.NewClient(ctx, ts)
    client := github.NewClient(tc)

    fileContent, _, _, err := client.Repositories.GetContents(
        ctx,
        os.Getenv("GITHUB_USER"),
        os.Getenv("GITHUB_REPO"),
        path,
        &github.RepositoryContentGetOptions{
            Ref: "main",
        },
    )

    return fileContent, err
}

Add a route to the Gin

router.GET("/images/:path", getImage)

And replace relative paths to images with absolute ones:


func fetchArticle(articleID string) (string, error) {
    htmlContentString, ok := articlesCache[articleID]
    if !ok {
        fileContent, err := requestFromGithub("articles/" + articleID + ".md")
        if err != nil {
            return "", err
        }

        markdownContent, err := fileContent.GetContent()
        if err != nil {
            return "", err
        }

        extensions := parser.CommonExtensions | parser.AutoHeadingIDs
        mdParser := parser.NewWithExtensions(extensions)
        htmlContent := markdown.ToHTML([]byte(markdownContent), mdParser, nil)

        htmlContentString = strings.Replace(
            string(htmlContent),
            "<img src=\"../images/",
            "<img src=\"/images/",
            -1,
        )
    }

    return htmlContentString, nil
}

That's it for this article. We could improve the Social-Network appearance by adding something like this

 <!-- Open Graph Tags -->
    <meta property="og:title" content="{{.Title}}">
    <meta property="og:description" content="{{.Description}}">
    <meta property="og:type" content="article">
    <meta property="og:url" content="{{.URL}}">
    <meta property="og:image" content="{{.ImageURL}}">

    <!-- Twitter Card Tags -->
    <meta name="twitter:card" content="summary_large_image">
    <meta name="twitter:title" content="{{.Title}}">
    <meta name="twitter:description" content="{{.Description}}">
    <meta name="twitter:image" content="{{.ImageURL}}">

We could also improve SEO-Shmeo things by storing title and description in some way.

But these things are superfluous for this article.

If you liked the article then subscribe to the
Telegram-channel

https://t.me/awesomeprog

or to my Twitter
https://twitter.com/shogenoff

Have a nice code!

Telegram OAuth Authorization for Your Site

Alex Awesome — Fri, 24 Mar 2023 14:42:27 +0000

You can make authorization via Telegram another way. It works. But today we want to do the classic OAuth Authorization.
Before you begin, you need to create a Telegram bot and obtain your bot token. You can do this in @BotFather in Telegram. For more information on initiating a bot, read the Telegram Bot API documentation: https://core.telegram.org/bots

Redirect Users to Telegram's OAuth URL

To initiate the OAuth process, you'll need to redirect users to the following URL:

https://oauth.telegram.org/auth?bot_id=YOUR_BOT_ID&scope=YOUR_SCOPE&public_key=YOUR_PUBLIC_KEY&nonce=YOUR_NONCE

You have to replace YOUR_BOT_ID, YOUR_SCOPE, YOUR_PUBLIC_KEY, and YOUR_NONCE with your bot's specific information. The nonce is a unique, randomly generated string that you'll need to store for later validation.

Handle Telegram's OAuth Callback

After the user authorizes your application, Telegram will redirect them back to your site with a URL that contains a hash and a payload. You'll need to verify the hash, parse the payload, and store the user's information.
That's it! I could wrap up this article. But ok, I am going to add the examples in languages that I use: PHP, Node.js, and Golang.

PHP Example:

<?php

$botToken = 'YOUR_BOT_TOKEN';

// Extracting the hash and payload from the request
$hash = $_GET['hash'];
$payload = json_decode(base64_decode($_GET['payload']), true);

// Verifying the hash
$secretKey = hash('sha256', $botToken, true);
$checkHash = hash_hmac('sha256', $payload, $secretKey);

if ($hash !== $checkHash) {
    die('Invalid hash.');
}

// Extracting user information from the payload
$user = $payload['user'];
$userId = $user['id'];
$firstName = $user['first_name'];
$lastName = $user['last_name'];
$username = $user['username'];

// Store user information in your database
// ...

?>

Node.js Example:

const crypto = require('crypto');
const url = require('url');
const querystring = require('querystring');

const botToken = 'YOUR_BOT_TOKEN';

const handleTelegramOAuthCallback = (req, res) => {
  const parsedUrl = url.parse(req.url);
  const queryParams = querystring.parse(parsedUrl.query);

  const hash = queryParams.hash;
  const payload = JSON.parse(Buffer.from(queryParams.payload, 'base64').toString());

  const secretKey = crypto.createHash('sha256').update(botToken).digest();
  const checkHash = crypto.createHmac('sha256', secretKey).update(queryParams.payload).digest('hex');

  if (hash !== checkHash) {
    res.status(400).send('Invalid hash');
    return;
  }

  const user = payload.user;
  const userId = user.id;
  const firstName = user.first_name;
  const lastName = user.last_name;
  const username = user.username;

  // Store user information in your database
  // ...
};

// Use the handleTelegramOAuthCallback function as a request handler in your web server

Golang Example:

package main

import (
 "crypto/hmac"
 "crypto/sha256"
 "encoding/base64"
 "encoding/hex"
 "encoding/json"
 "log"
 "net/http"
)

const (
 botToken  = "YOUR_BOT_TOKEN"
)

type User struct {
 Id        int64  `json:"id"`
 FirstName string `json:"first_name"`
 LastName  string `json:"last_name"`
 Username  string `json:"username"`
}

type Payload struct {
 User User `json:"user"`
}

func handleTelegramOAuthCallback(w http.ResponseWriter, r *http.Request) {
 hash := r.URL.Query().Get("hash")
 payloadB64 := r .URL.Query().Get("payload")
 payloadBytes, err := base64.StdEncoding.DecodeString(payloadB64)
 if err != nil {
  http.Error(w, "Invalid payload", http.StatusBadRequest)
  return
 }

 var payload Payload
 err = json.Unmarshal(payloadBytes, &payload)
 if err != nil {
  http.Error(w, "Invalid payload", http.StatusBadRequest)
  return
 }

 h := hmac.New(sha256.New, []byte(botToken))
 h.Write([]byte(payloadB64))
 checkHash := hex.EncodeToString(h.Sum(nil))

 if hash != checkHash {
  http.Error(w, "Invalid hash", http.StatusBadRequest)
  return
 }

 user := payload.User
 userId := user.Id
 firstName := user.FirstName
 lastName := user.LastName
 username := user.Username

 // Store user information in your database
 // ...
}

func main() {
 http.HandleFunc("/telegram-oauth-callback", handleTelegramOAuthCallback)

 log.Fatal(http.ListenAndServe(":8080", nil))
}

It's very easy, isn't it?
Of course, these are not the best blocks of code ever, but they help to understand how to work with it.

Run a Golang, Nginx, and React App in Docker

Alex Awesome — Wed, 22 Mar 2023 19:26:15 +0000

Did you try to run your Golang, Nginx, and React apps locally and fight compatibility issues?
You need docker to save time. If you are very brave you can even use this scheme in production. But you will be judged by mature programmers with long beards.
In this article, we'll guide you through the process of running your Golang, Nginx, and React app in a Docker container, so you can avoid the headache of managing multiple environments.
I guess you know about docker if you can find this article.
Don't worry, you don't need to be a Docker expert or a rocket scientist to follow along.

Let's get started!

Setting Up the Environment:

Install the docker if you haven't done it yet.

We also will use Docker Compose. You have to have it. Don't be scared it's very easy to start using.

Next, create a new directory on your machine to hold your app files. Let's call it «docker-me-up-baby».

mkdir docker-me-up-baby
cd docker-me-up-baby

Now, create «docker-compose.yml». This file will define the services that make up your app and their configurations. Here's an example docker-compose.yml file for our simplest application:

version: '3'
services:
  web:
    build: ./nginx
    ports:
      - "80:80"
    depends_on:
      - api
  api:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    depends_on:
      - api

What the hell is going on here 👆?

This docker-compose.yml file does a few things:

It defines four services: web (for Nginx), api (for Golang), db (for PostgreSQL), and frontend (for React).
It specifies the build context for the api and frontend services, which tells Docker Compose where to find their Dockerfiles.
It exposes port 80 on the web service to port 80 on the host machine.
It exposes port 3000 on the frontend service to port 3000 on the host machine.

That's it for setting up the environment with Docker Compose! Now, you can build and run your app with a single command. Docker Compose takes care of building the images, creating the containers, and linking them together. All you need to do is run:

docker-compose up

I guess it won't work right now but believe me it's the right command.

Docker Compose will start all the services defined in the docker-compose.yml file, and you will access your app by visiting http://localhost in your browser.

Building and dockerizing the simplest Golang API:

Let's implement our rocket-science API

// main.go
package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello, World!")
    })

    http.ListenAndServe(":8080", nil)
}

It's great, isn't it?!

Lets dockerize this one (I'm assuming that Golang part is in the root directory of our project):

# Official Golang image (You shouldn't use the `latest` version in production but I'm a bad guy)
FROM golang:latest

# Working directory
WORKDIR /app

# Copy everything at /app
COPY . /app

# Build the go app
RUN go build -o main .

# Expose port
EXPOSE 8080

# Define the command to run the app
CMD ["./main"]

You can understand what is happening in this file by reading the comments.
Let's repeat one more time:

Dockerfile gets the official Golang image.
Sets the working directory to /app.
Copies the contents of the current directory into the /app directory in the container.
Builds the go app using the go build command.
Exposes port 8080.
Defines the command to run the app (in this case, ./main).

To build the Docker image for this Golang API, we cat run the following command in the app's directory (but we won't):

docker-compose build api

Actually, we don't need to do it because we will build everything everywhere all at once later.

We will do the same with running our container. I just have to mention that you can use this command for running the container

docker-compose up api

But we don't need it right now.

If you are so impatient, you can run build and run commands above. You can be sure that everything is ok if you see the "Hello world!" console. You can also access the API by visiting http://localhost:8080.

That's it for building the Docker image for the simplest Golang API!

Let's go ahead.

Set up the Nginx server (in Docker of course)

Let's put Nginx files to a new directory named nginxinside the app's directory. Inside the nginx directory, create a new file named nginx.conf with the following configuration:


server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://api:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This configuration sets up an Nginx server to listen on port 80 and forward all requests to the Golang API running on port 8080. Why is "api" in http://api:8080? It's name of the Golang API service defined in the docker-compose.yml file.

To build the Nginx image in a Docker container, create a new file named "Dockerfile" inside the "nginx" directory:

# Official Nginx image (Yes, in this article I always use the `latest`. Kill me!)
FROM nginx:latest

# Copy Nginx configuration file to the container
COPY nginx.conf /etc/nginx/conf.d

# Expose port 80
EXPOSE 80

One more time:

This Dockerfile gets the official Nginx runtime image as the parent image.
Copies the Nginx configuration file to the container.
Exposes port 80.

For build and run you can use the same commands as for the Golang API container but with name of service web.

docker-compose build web
docker-compose up web

If you run golang and nginx services by docker-compose up API web you can check the http://localhost in the browser.

Create the React app.

This article is not about building a React application. We can use something simple (From root project directory)

npx create-react-app frontend
cd frontend

Add the API integration:

Add the stupidest API integration in all over the world.
Create a new file named "api.js" in the "frontend/src" directory:

const api = {
  async getHello() {
    const response = await fetch('/api');
    const data = await response.json();
    return data.message;
  }
}

export default api;

For development, we will use the Docker.

frontend/Dockerfile:

# Use a Node.js image
FROM node:latest

# Set the working directory
WORKDIR /app

# Copy the package.json and package-lock.json files
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy everything to the container
COPY . .

# Expose port
EXPOSE 3000

This Dockerfile

Gets the Node.js image.
Sets the working directory to /app.
Copies the package.json and package-lock.json files to the container.
Installs dependencies

docker-compose build frontend
docker-compose up frontend

You can see something at http://localhost:3000

Let's simulate production build

It's just a demonstration. It's the worst way for real-life applications. Anyway, build the build

npm run build

Add the React build files to your Nginx configuration.

To include the React build files in your Nginx server, let's make nginx.conf file like this:

server {
    listen 80;
    server_name localhost;

    location / {
        root /app/frontend/build;
        try_files $uri /index.html;
    }

    location /api {
        proxy_pass http://api:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This configuration sets up an Nginx server to serve the React app from the build directory and forwards all API requests to the Golang API running on port 8080.

And finally, let's add a little correction to the docker-compose:

version: '3'
services:
  web:
    build: ./nginx
    ports:
      - "80:80"
    depends_on:
      - api
    volumes:
      - frontend/build:/app/frontend/build
  api:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    depends_on:
      - api

Got it? We added volumes. It will mount our frontend/build directory to the Nginx container.

All together

Now that you've built the Docker images for your Golang API, Nginx server, and React app, it's time to run the Docker container and test your app.

Start the Docker container:

docker-compose up

You can use

docker-compose up -d

to run it in the background

Test the app:

To test your app, visit http://localhost in your browser. You should see your React app being served by the Nginx server, with API requests being forwarded to the Golang API.

You can also test your Golang API by visiting http://localhost/api in your browser. You should see a JSON response with a "message" field containing the text "Hello, world!".

Stop it!

Stop the Docker container:
To stop the Docker container, press Ctrl + C in your terminal or run the following command if you use -d option:

docker-compose down

This will stop and remove all the Docker containers for your app.

That's it! You've successfully built and run a Docker container for your Golang, Nginx, and React app. Docker Compose makes it easy to manage all the services in your app and ensure they work together correctly.

If you want to learn more about Docker and app deployment, here are some additional resources you can check out:

Docker's official documentation: Docker's documentation provides detailed information on how to use Docker and Docker Compose to build and run containers. It includes guides, tutorials, and reference materials for beginners and advanced users.
Docker Hub: Docker Hub is a public registry of Docker images, where you can find images for various services and software. You can also use Docker Hub to store and share your own images.
Docker Stack is a tool provided by Docker that allows you to deploy a multi-container Docker application on a Docker Swarm cluster. It enables you to define your application's services, networks, and volumes in a single file called a "Compose file" and deploy the entire stack to the swarm.
Kubernetes: Kubernetes is an open-source container orchestration system that automates the deployment, scaling, and management of containerized applications. It can be used to deploy and manage Docker containers in a production environment.

I don't post links on purpose. Technology development is very fast. Find actual ones on Google.

Follow me on Telegram, and you can read all my articles https://t.me/awesomeprog.

Building a Simple Blockchain in PHP

Alex Awesome — Tue, 21 Mar 2023 12:30:33 +0000

Please don't shout «Whyyyyyyyyy?». It's just a crazy experiment to show that everyone can implement their own blockchain. Probably PHP programmers also want to create a blockchain as best they can.

Blockchain technology has become increasingly popular due to its decentralized nature and the ability to store data securely. In this article, we'll create a simple blockchain using PHP, demonstrating blockchain technology's basic concepts and principles:

Creating a Block class
Creating a Blockchain class
Adding blocks to the blockchain
Validating the blockchain
Additional examples and use cases

Let's get started!

1. Creating a Block class

The first step in creating our blockchain is to define the basic building block: the Block class. Each block will contain an index, a timestamp, data, a previous hash, and its own hash. We'll also create a function to generate the hash for a block.

class Block
{
    public int $index;
    public string $timestamp;
    public $data;
    public string $previousHash;
    public string $hash;

    public function __construct(int $index, string $timestamp, $data, string $previousHash = '')
    {
        $this->index = $index;
        $this->timestamp = $timestamp;
        $this->data = $data;
        $this->previousHash = $previousHash;
        $this->hash = $this->calculateHash();
    }

    public function calculateHash(): string
    {
        return hash(
            'sha256', 
            sprintf(
               '%d%s%s%s',
               $this->index,
               $this->timestamp,
               $this->previousHash,
               json_encode($this->data),
           )
        );
    }
}

2. Creating a Blockchain class

Next, we'll create a Blockchain class that will manage our chain of blocks. This class will have functions for creating the genesis block, adding new blocks, and validating the integrity of the blockchain.

class Blockchain
{
    public array $chain;

    public function __construct()
    {
        $this->chain = [$this->createGenesisBlock()];
    }

    private function createGenesisBlock(): Block
    {
        return new Block(0, '01/01/2023', 'Genesis Block', '0');
    }

    public function getLatestBlock(): Block
    {
        return $this->chain[count($this->chain) - 1];
    }

    public function addBlock(Block $newBlock): void
    {
        $newBlock->previousHash = $this->getLatestBlock()->hash;
        $newBlock->hash = $newBlock->calculateHash();
        $this->chain[] = $newBlock;
    }

    public function isChainValid(): bool
    {
        for ($i = 1, $chainLength = count($this->chain); $i < $chainLength; $i++) {
            $currentBlock = $this->chain[$i];
            $previousBlock = $this->chain[$i - 1];

            if ($currentBlock->hash !== $currentBlock->calculateHash()) {
                return false;
            }

            if ($currentBlock->previousHash !== $previousBlock->hash) {
                return false;
            }
        }

        return true;
    }
}

3. Adding blocks to the blockchain

Now that we have our Block and Blockchain classes, let's create a new instance of the Blockchain class and add some blocks.

$myBlockchain = new Blockchain();
$myBlockchain->addBlock(new Block(1, '10/03/2023', ['amount' => 50]));
$myBlockchain->addBlock(new Block(2, '15/03/2023', ['amount' => 100]));

4. Validating the blockchain

To ensure the integrity of our blockchain, we'll use the isChainValid() function to check if our chain is valid.

echo 'Is blockchain valid? ' . ($myBlockchain->isChainValid() ? 'Yes' : 'No') . "\n";

5. Additional examples and use cases

Now let's explore a few more examples of using our simple PHP blockchain.

Example: Displaying the blockchain

function displayBlockchain(Blockchain $blockchain): void
{
    foreach ($blockchain->chain as $block) {
        echo "Index: " . $block->index . "\n";
        echo "Timestamp: " . $block->timestamp . "\n";
        echo "Data: " . json_encode($block->data) . "\n";
        echo "Previous Hash: " . $block->previousHash . "\n";
        echo "Hash: " . $block->hash . "\n\n";
    }
}

displayBlockchain($myBlockchain);

Example: Tampering with the blockchain and validating

// Tamper with the second block's data
$myBlockchain->chain[1]->data = ['amount' => 75];

// Check if the blockchain is still valid
echo "Is blockchain valid after tampering? " . ($myBlockchain->isChainValid() ? "Yes" : "No") . "\n";

Conclusion:

In this article, we've built a simple blockchain in PHP. Why? I have no idea! But we've explored the creation of the Block and Blockchain classes, adding blocks to the blockchain, validating the integrity of the chain, and using our blockchain in various examples.

While this implementation is straightforward and suitable for educational purposes, it is important to note that real-world blockchains are far more complex, incorporating consensus algorithms, distributed networks, and more advanced security measures. However, this introduction to the basics of blockchain technology provides a solid foundation for understanding and further exploring the world of decentralized systems.