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.

Amazon Linux AMI : Let’s Encrypt : ImportError: No module named interface

Let’s Encrypt has only experimental support for the Amazon Linux AMI, so it’s kind of expected to have issues once in a while.   Here’s one I came across today:

# /opt/letsencrypt/certbot-auto renew
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Traceback (most recent call last):
File "/root/.local/share/letsencrypt/bin/letsencrypt", line 7, in <module>
from certbot.main import main
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/certbot/main.py", line 12, in <module>
import zope.component
File "/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/zope/component/__init__.py", line 16, in <module>
from zope.interface import Interface
ImportError: No module named interface

My first though was to install the system updates. It looks like something is off in the Python-land. But even after the “yum update” was done, the issue was still there. A quick Google search later, thanks to the this GitHub issue and this comment, the solution is the following:

pip install pip --upgrade
pip install virtualenv --upgrade
virtualenv -p /usr/bin/python27 venv27

Running the renewal of the certificates works as expected after this.

P.S.: I wish we had fewer package and dependency managers in the world…

JSON API? No … HAL!

Wait, what?  That’s exactly what I said when I read this blog post.  I am still making my way through the JSON API specification.  And now it seems I might be wasting my time, as I should be learning HAL.

Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.

HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.

Sometime I think that I should just stop learning.  What’s the point?  By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.

Meh…

PHP Package Development Standards

Paul M. Jones announces the availability of PHP Package Development Standards for review:

This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.

PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.

Have a look at php-pds/skeleton GitHub repository.

Personally, I welcome this initiative.  PHP ecosystem exploded in the recent years with the help of composer and Packagist.org.  There are over 120,000 packages just on the Packagist.org.  I think, it’s good to have some standards and best practices.  The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs).  But we could have some more guidelines in order to have some consistency.

PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices.  They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.

Looking at the packages that I am involved with, only a few minor changes are necessary to comply.  Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.

Power in a distributed organization vs traditional

Chris Hardie, who works for Automattic, shares his observations on where the power in a distributed organization comes from, versus the traditional one.

In an office setting, I see power and influence gather around…

  • The person with the newest, coolest and/or most expensive clothing
  • The person with the larger corner office
  • The person with the most assistants
  • The person with the most impressive sounding title
  • The person with the closest parking space
  • The oldest, richest, whitest males
  • The person who’s allowed to create or interrupt meetings
  • The person with the most impressive social and public-speaking skills
  • The person who uses their power to get what they want

In a distributed organization, I see power and influence gather around…

  • The person who produces output and solutions that exceed expectations
  • The person who can connect deeply with colleagues over a distance
  • The person who can effectively and concisely articulate their own views and ideas
  • The person who helps their coworkers be the best versions of themselves
  • The person generous with their understanding of how to navigate the organization’s processes and culture
  • The person who can give voice to unrecognized or unspoken truths
  • The person who learns fastest from their mistakes
  • The person who uses their power to empower others

It’s of course not fair to generalize this way. There are healthy traditional organizations where appearances are not necessarily the basis for power. There are probably unhealthy distributed organizations where power centers around the appearance of lots of activity that produces few good outcomes. But my experience so far is that a distributed organizational structure inherently facilitates an experience of power, empowerment and leadership that is better for the people in it, and for the work they are doing together.

I don’t have much experience working for a distributed organization, but judging by many Open Source projects, which are, in essence, distributed organizations, I’m inclined to agree with the above observations.  I wouldn’t be able to put in words so well though.

Conky – light-weight system monitor for X

Conky is a light-weight system monitor for X.  It supports all kinds of metrics – anything from CPU, memory and network, to emails, music players, and more.

It reminds me of the old days, before Gnome and KDE took over the desktop environments – I think everybody had something similar running as part of the screen background.

The installation on Fedora is trivial – conky is packaged and available with a simple “yum install conky“.  The configuration, on the other hand, is not so much.  GitHub repository provides quite a few fancy user configurations, but there was a change in configuration file format in the version 1.10, and things aren’t as smooth as I would like.

It’ll take a bit of playing around, but I’m sure I’ll eventually lose enough sleep over this to just give up and have something semi-decent on my screen.