The end of “easy mode” in IT, or just another level of abstraction?

For many months now, I’ve been reading through social media, and it’s hard not to get the impression that a single tone often dominates the IT world: anxiety. Many people fear layoffs tied to developers—and others—being replaced by AI agents. Many are attacking this new direction, trying to undermine the quality of solutions delivered by AI.

However, I want to look at this entire situation from a different perspective. Because what many see as a "crisis" today, is something entirely different to me.

It’s simply the next shift in the level of abstraction.

History likes to repeat itself

If we look at the history of software engineering, we will notice a recurring pattern. Everything constantly shifts toward automation and giving up control:

• In the beginning, there was Assembler: Developers controlled every CPU register and every byte of memory. Writing code was an almost physical craft.
• Then came high-level languages: C, Java, Python. We handed over direct control of the CPU to compilers and interpreters. Many purists argued back then that "real programming is over."
• Next came the era of frameworks: We stopped writing HTTP mechanisms, ORMs, or routing from scratch. We handed control over to Spring, React, or .NET to focus strictly on the business logic itself.

Every single time, the scenario was the same: developers handed a piece of manual control "higher up" to be able to build bigger, faster, and more complex things.

AI agents are not the end of IT. They are just another framework.

Today, we are facing the exact same process. We are starting to give up control to AI agents that code entire modules or refactor systems. And this is the inevitable direction that IT technology will follow.

The market is simply drastically changing the rules of the game and verifying who we really are:

• The end of code monkeys: If your only skill was mechanically translating documentation into code, then yes—AI will do it faster and cheaper.
• The rising role of architects: Today, a developer's job looks less and less like writing lines of code from scratch, and more and more like supervising autonomous agents, connecting architectural pieces, and managing a clean workflow.
• Business and communication above all: Since code is becoming a readily available commodity, those who win are the ones who can manage requirements, talk to stakeholders, and understand business processes.

New times

For us engineers, this is no reason to panic, but a signal to take action. Instead of crying over the past, it’s time to accept the new level of abstraction, master the tools, and map out a new strategy. The IT market isn't dying. It just took another step forward.

Problem with Error Handling in React 16

New Error Handler in ReactJS 16 gives some great changes to how React handles JavaScript errors inside components. But I found one problem with it in case described below.

We have global script Application.jsx

export default class extends React.Component {
    render() {
        return (
          <GlobalErrorBoundary>
    <Content/>
</GlobalErrorBoundary>
        )
    }
}

(I omit import sections in my snippets to show more concise code)

GlobalErrorBoundary.jsx

export default class extends React.Component {
    constructor(props) {
        super(props);
        this.state = {error: null};
    }
    componentDidCatch(error, errorInfo) {
        this.setState({error});
    }
    render() {
        if (this.state.error) {
            return (
                <p>Global Boundary</p>
            );
        }
        return this.props.children;
    }
}

Content.jsx

const _getElement = Symbol();
export default class extends React.Component {
    render() {
        return (
            <LocalErrorBoundary>
                {this[_getElement]()}
            </LocalErrorBoundary>
        )
    }
    [_getElement]() {
        return (<div><InnerComponent/><InnerComponent2/></div>)
    }
}

LocalErrorBoundary.jsx

export default class extends React.Component {

  constructor(props) {

    super(props);

    this.state = {error: null};

  }

  componentDidCatch(error, errorInfo) {

    this.setState({error});

  }

  render() {

    if (this.state.error) {

    return (

      <p>Local Boundary</p>

    );

  }

  return this.props.children;

 }

}

Component1.jsx

const _getElement = Symbol();
export default class extends React.Component {
    render() {
        return (
            <div>
                {this[_getElement]()};
            </div>
        )
    }
    [_getElement]() {
        return 'InnerComponent1'
    }
}

Component2.jsx

const _getElement = Symbol();

export default class extends React.Component {

  render() {

    return (

      <div>

        {this[_getElement]()};

      </div>

    )

  }

  [_getElement]() {

    return 'InnerComponent2'

  }

}

And waht will happened when Content.jsx thows an error?

[_getElement]() {
        throw 500;
    }

It will be cought by 

componentDidCatch(error, errorInfo) {
        this.setState({error});
    }

and printed what we expected:

<p>Global Boundary</p>

But what happenes when we have some widget s on our page and one of them throws an error? Error will be caughed by <LocalErrorBoundary> and will be printed: 

<p>Local Boundary</p>

In many cases this is a desirable behavior, but not in my case. 
In my case, when I have many independent widgets on page and each of them gets data content from other resource (which could thow an error) this solution does not work. I’ll expect that problematic widget, which throws an error, will print error information only in its own block and Error Handling will not stop rendering other widgets.

Maybe is the other solution? I'll try to find out.

Check permissions in ZF2 Zend/Navigation with ZfcRbac

ZfcRbac is not tailored to work with Zend/Navigation. There aren’t any builded native solutions that gives ZfcRbac permission to enable or disable entry of menu. The solution for that problem is quite simple.

I found solution in this blog: http://blog.webdevilopers.net/check-zend-navigation-page-permissions-with-zfcrbac/. I based on it. But this solution caused a problem. Positions in menu are displayed only if perrmision is defined. If permission is not defined, menu’s posiotin is displayed.

I’ll show you how to implement checking perrmisions and enabled / disabled menu positions with ZfcRbac. There is only one change in RbacListener:

class RbacListener

{

  protected $authorizationService;

  public function __construct(AuthorizationServiceInterface $authorizationService)

  {

      $this->authorizationService = $authorizationService;

  }

  public function accept(EventInterface $event)

  {

      $page = $event->getParam('page');

      if (! $page instanceof AbstractPage) {

          return;

      }

      $permission = $page->getPermission();

      if (is_null($permission)) {

          $event->stopPropagation();

          return false;

      }

      $event->stopPropagation();

      return $this->authorizationService->isGranted($permission);

  }

}

Do not mess your code!

PHP is great language that gives us flexibility. PHP has weak typing. On the other side, many programmers abuse it. They create little monsters and spaghetti code.

In this post I will show you, on simple example, how you should prevent yourself from ambiguous return value.

Base principle: You should always return the same type.

My favorite example:

/**

* @return mixed

*/

public function getProductList()

{

   $resultArray = $this->products->get();

   return empty($resultArray) ? $resultArray : null;

}

What’s wrong with it? Return value is ambiguous. In next step in your code, after calling this method you must check what method returned to you.

if ($return === null) {

   //do something...

} else {

   //do something...

}

In this example you have two statements to check. More clear is this code:

/**

* @return array

*/

public function getProductList()

{

   $resultArray = $this->products->get();

   return $resultArray;

}

In above example, you always gets the same type of result. On the other hand, you may use designed pattern, but this is the other solution, not described in this post.

Why Programmers Should Have a Blog

http://architects.dzone.com/articles/why-programmers-should-have