Category: Technology

I work in technology sector. And I do round a clock, not only from 9 to 5. It is my bread and butter, it is my hobby, it is the fascination of my life. And with the current rate of change particular in information technology (IT), there is always something new to learn, to try, to talk about. I often post news, thoughts, and reviews. And when I do, this is the category I use.

PHP CEO on Twitter

@PHP_CEO is a new corporate humor goldmine on Twitter. It’s very much like I am a developer, but, you know, from the CEO perspective.

Some of those tweets are nothing short of brilliant!

Time for a new adventure

This week I’ve handed in my resignation letter, marking my last working day as February 28, 2019. After 4.5 years as a Chief Technology Officer at Qobo, I feel it’s time for a new adventure.

Looking back at the last 4.5 years, it feels like there is enough to fill several lifetimes – so much has been done, so much has changed, so many people met, so many ideas tried, and so many things accomplished!

Have a look at my annual posts summarizing just the most noticeable changes:

Or, if you feel like it, take a deeper dive into more blog posts, varying from Instagram pictures to some deep technical brainstorming and solutions.

Obviously, I can go on and on for hours, but here are a few high-level points just to keep things in context:

  • Offices. We’ve opened a new office, or moved to a new office, pretty much every year. First, Nicosia office was moved and expanded. Then Limassol office opened. Then London office opened. Then Limassol office moved and expanded.
  • People. From a small team of 7 when I joined, we’ve expanded to over 20 now. But it wasn’t only about the headcount. We’ve grown the number of roles in the company as well – sales, support, QA, etc.
  • Clients. We’ve built an impressive portfolio, with many large, medium, and small clients, across a variety of industries from a several countries.
  • Technology. We’ve built an impressive set of technology, both internally and externally. Our Amazon AWS cloud infrastructure nearly doubles every year. We have integrated a number of excellent tools to help with project management, quality assurance, development cycle and continuous delivery. And we’ve made Qobrix from scratch into a recognizable brand and force to be reckoned with.
  • Open Source. True to our Open Source believes, we have made significant contributions to Open Source, both via our own repositories, and through the tools and libraries that we use and build on top.

I have met and worked with some really amazing people and teams, true professionals, and inspiring individuals. I have learned a great deal over the years, and have grown both personally and professionally.

So, why am I leaving then? I feel it’s time. It’s time for a change both the company and for myself.

When I joined Qobo, it was a tiny startup, like many others, trying to find its identity, develop, and grasp some luck. It was also still trying to survive the catastrophic consequences of the “Cyprus haircut“, which killed many stronger, more mature businesses. Gladly, we managed to pull through all of that. It wasn’t easy by any means, but we’ve done that. The company has survived, grown, and matured.

It is now well on the way to success, with a clear vision, great products, strong client portfolio, good reputation, and an amazing team.

I think I have done enough to help Qobo to get here. There are now many new people, ideas, and approaches, which will take it forward in a smoother, faster, and more efficient way.

As for myself, it’s also been quite a ride. There has been countless nights and weekends of tight deadlines, non-stop work, lack of sleep, nervous breakdowns, alcohol abuse, emotional highs and lows, and so on. (All kind of expected in a startup.) But I need to step back and recover a bit. On top of that, over the last few month, my focus was mostly needed in non-technical areas. I want to get back to my routes for a bit, and dive into the hands-on technology – things that I like the most: writing code and administrating infrastructure.

Where am I going then? To tell you the truth, right this moment – I don’t know yet. The decision to step down as a CTO and to leave Qobo took quite a bit of thinking, consideration, and preparation. I haven’t looked at my new options or opportunities yet. But given the state of the IT industry in Cyprus and a growing deficit of developers, devops and system administrators, I’m sure I’ll find my next adventure soon enough. (If you have any suggestions or recommendations, please do ping me either here or via LinkedIn).

I would like to take this opportunity to say a huge thank to you to everyone I’ve met and worked with while my years in Qobo. I am truly humbled and honored to have had the opportunity to work with you and to learn from you! I’m sure our paths will cross again.

PHP : Composer Galaxy

PHP has one of the greatest, in my opinion, dependency managers – Composer. The tool works mostly with the public projects via the Packagist website (although it also supports private repositories).

There are over 200,000 packages available on the Packagist to choose from. However, the stats could be a lot better.

Today I came across a mind-blowing visualization of the composer packages and the dependencies between them. Have a look at Code Galaxies Visualization. You can find specific packages via the search, or interactively navigate the star map, like you are in the spaceship.

Stunning!

Our Software Dependency Problem

“Our Software Dependency Problem” is a great article going in-depth into the subject of the dependency management during software engineering.

Dependency managers have scaled this open-source code reuse model down: now, developers can share code at the granularity of individual functions of tens of lines. This is a major technical accomplishment. There are myriad available packages, and writing code can involve such a large number of them, but the commercial, legal, and reputational support mechanisms for trusting the code have not carried over. We are trusting more code with less justification for doing so.

Not only it nicely describes the problem in simple terms, but also provides practical examples and solutions to it. In particular, I enjoyed the section that suggests how to improve dependency evaluation in terms of design, code quality, testing, debugging, maintenance, usage, security, and licensing.

Redmine: Estimated Time as mandatory field

At work, we are using Redmine for all our project management needs. It is a flexible and powerful system that allows flexible configuration for the processes of most companies.

Recently, we have decided to make the Estimated Time field mandatory for all the tickets. Configuring this turned out to be trickier than I thought initially. I couldn’t find the option to do so on the first go.

Some Googling around suggested that Redmine’s source code needs to be modified for that. Not something that I wanted to do. And the tip is also from 8 years ago, so it’s probably quite outdated.

After digging deeper, I found a way, that doesn’t require source code changes. This can be accomplished via editing the Field Permissions in the Workflow. Here’s the process (for Redmine 3.3.0 stable, that we run currently):

  1. Login to Redmine as administrator.
  2. Navigate to the Administration screen (a link in the top bar or so, depending on the skin you are using).
  3. Navigate to Workflow.
  4. Switch to Field Permissions tab.
  5. Select desired roles and trackers.
  6. Press Edit button.
  7. Scroll down to the Estimated Time field.
  8. Select Required from the dropdown for each status, as needed.
  9. Press Save button.

You are all done. Now all tickets of the above selected trackers will require the input of the Estimated Time for all above selected statuses and roles.

Similarly, you can make other fields required or read-only, as per your company or team needs.