JavaScript – technological singularity & younglings effect

On March 2017, Eugene Gusev had an interesting talk (in Russian) at HolyJS regarding the technological singularity as whole in Front-End, and JavaScript ecosystem in particular. As a thesis taken, he noted an enormous number of 350k packages in NPM.

Few points being stated over the talk:

  • Quality of the packages (aka younglings publish low quality tools)
  • Hype over the ecosystem (frameworks and libs go up and down in popularity scale).
  • Business forces the choice, leaving minimum time on technical decision-making process.
  • Stop writing code, or “stop publishing your code”.
  • In order to program you should be a computer scientist.

All the points are quiet controversial. Though, accepting some of these statements as a potential problem, most of them have a reasonable explanation.

Prelude

Back when the trees were tall and the grass was green, I graduated my BSc in Computer Science, I’ve started working as a Junior Web Developer. By that time, a programmer who knew only JavaScript, or solely was coding on Perl/PHP/Python was considered lazy/unemployed/unicorn. The time flew by and the industry started splitting technological stack, so from Programmer/SysAdmin we forked into Front/Backend developers, SysAdmins to DevOps etc.

University, really?

We still have certain professions that require an educational degree. By paying for your education, you’re prompted to access research laboratories, expensive equipment that’s required for your research. Think of physicists or chemists. Stating that diploma (for Computer Science) somehow justifies your profile, or what you should be doing for living left behind with the era of industrial revolution. “The spice must flow” – that’s where we get into the almighty Internet for self-education. Udemy, Coursera – it’s right there, most of it is free, just read it, learn it.

Technological Singularity

Technological singularity is a hypothesis that the invention of artificial superintelligence will abruptly trigger runaway technological growth, resulting in unfathomable changes to human civilization.

Are we there yet? Yes, we are. It just arrived silently. Clustering professions to narrow the specialization is one of the countermeasures to prevent the informational noise that we get once diving into IT-sector. That’s where we step into Hype effect.

Hype Effect

Hype Cycle diagram
Hype Cycle by Ember in the Real World

350 thousand package in NPM. That’s massive, but hold on a minute! CPAN didn’t have the same issue in Perl community? PEAR and Pecl repositories stacked by repetitive packages, written by people just because they could. And they did! Every year, some big player like Google, Facebook, name a few, presents a new approach towards a common problem. Angular, React, EmberJS, VueJS. It automatically triggers a hype.

Architects in the companies start massively migrating to trendy frameworks, as it’s backed up by one of the above companies, which promises stable development, stable versioning and ongoing support. We get a drastic shift of packages developed for these frameworks. And the story continues until something new arrives on the market.

As companies do not operate in vacuum, all these transitions correlate with business decisions. Packages appear in almost-ready-to-us state, and remain loosely maintained just to get your npm/phake/rake running smoothly during the deploy process.

Packages & Plugins flood

Slowly the picture of 350k packages come into place. Each of the packages is a reflection of a person behind it and the problem he or she was trying to solve. Good solutions become trendsetters itself, become community defacto standards. What happens with others? – Well, it’s a pure darwinism, which triggers professional boost among the developers.

To sum things up

Your knowledge derives from those who dared, and published something. If you cannot choose out of a hundred packages one or two that might fit in your application, maybe you should question yourself what exactly you trying to solve? Diversity of approaches in IT and its openness is our strength. You found something wrong, write a bugreport, or send a pull request. The rest is just excuses in most of the occasions!

Office 365 – test trial is over, back to Google

I’ve been using Office 365 for office correspondence for about 7 months, since I moved to Qobo. Today I say enough to Office365 corporate lookalike email client. Everything is back to Google.

UX experience

One of the things I couldn’t get used to is the right-click bindings. I guess the assumption was to enrich the functionality of the interface by letting you move/delete assets on your sidebar (aka folder management). As the result – half of the browser daily routine is cut off. Most of the time my main working tool (apart of the vim) is the browser (webdev happy days!).

When someone screws up the shortcuts that I use gazillion times per day, it kind of annoys me. Who would have thought to replace Ctrl-R to “reply” shortcut for “refresh“. Ah, bollocks, moving on!

Focused/Other/Pinned emails. Pinned email go to the top of the list. Focused follow right after. Others – somewhere at the end. 6 emails fit into my laptop screen height, so you can get an idea, that the number of pinned or focused emails is quiet limited. I guess, I’m too old school to get these things right!

Search & Filter. Google Email search and filtering is unbeatable. Period.

 

Work fuel: what really motivates us

Seth Godin published once again a great article on work/life motivation.

  • Becoming a better version of yourself
  • Catastrophe (or the world as we know it will end)
  • Connection (because others will join in)
  • Creative itch (the voice inside of you wants to be expressed)
  • Dissatisfaction (because it’s not good enough as it is)
  • Engineer (because there’s a problem to be solved)
  • Generosity (because it’s a chance to contribute)
  • Possibility (because we can, and it’ll be neat to see how it works in the world)
  • Selection (to get in, win the prize, be chosen)

Definition of “done”

It’s been a long way for the definition to get to this blog post, so i’ll choose the one which favors the most, meanwhile its revision history:

An example Story definition of done would look like this.

  1. All story should have automated acceptance test.
  2. The story should have working code supported by unit test that provide around 60 – 70 percent coverage.
  3. The story should have well defined acceptance criteria.
  4. The code must have been written as a pair or should be code reviewed.
  5. Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
  6. The product owner must accept the story.
Sprint Definition of done:
  1. Product owner should have defined a sprint goal.
  2. All stories completed for the spring must be accepted by the product owner
  3. All the automated acceptance tests should be running for the stories in the sprint.
  4. All code should have been pair programmed or must have gone thorough a code review process.
  5. If there is a database involved, the database scripts must have been automated and tested.
Release Definition of done
  1. Product is deployed to the test box and makes it to staging
  2. Product has a formal release date.
  3. There are deployment documents for the release
  4. Training manuals are available for users.
  5. All stories for the release are completed and accepted.
  6. The release does not have any level one bugs.

code-07

 

Qobo: first month benchmark

It’s been already one month since I moved to Qobo Ltd, as a backend developer, so it’s about time to do some benchmarks on the work done.

Open-Source

The level of open source involvement of Qobo is enormous. All the projects I’ve been involved in before were always about open-source: it was either based on open-source, or using open-source solutions into some extend. Every time it ends up locking down the solutions for indoor use. It was either features the company didn’t want to share with the open-source community, or key business aspects that were crucial for competitive advantage. The story repeats over and over – the level of feedback to open source was minimal.

Contrarily, Qobo’s approach towards open-source is different. I didn’t do the exact measures, but it’s approximately 70-80% of code that goes to public repositories. Apart of advocating open-source within the company, we participate in other development communities, which helps us get things better. What’s the point of getting stuck with yet another closed-source plugin/module/library that others troubleshooted/patched and use everywhere. Examples? Well, it’s CakeDC community, CakePHP framework, WordPress, Bootstrap, and many others.

Side-effects of it:

  • You write better code (if you want to get things accepted in pull requests)
  • You stand on the shoulders of giants (community helps. Always)
  • Self-development (you’re not stuck with repetitive tasks)
Teams

Q: how many programmers does it take to change a light bulb?

A: none, that’s a hardware problem (c)

Small teams, dedicated to certain projects or split by the expertise in certain technology or business aspects. Mind blowing speed of deployment & accuracy. The most appropriate way of describing the social system and involvement in the projects would be meritocracy – “We do it, because we can”.

 

From hardware to software: key points

Absolutely great article by Seth Godin on hardware/software perspectives looking at the giants, like Apple. Few points need to be quoted:

  • Software can change faster than hardware, which means that in changing markets, bet on software.
  • It’s tempting to treat the user interface as a piece of fashion, some bling, a sort of jewelry. It’s not. It’s the way your user controls the tool you build. Change it when it stops working, not when you’re bored with it. Every time you change the interface, you better have a really good reason.
  • Hardware always gets cheaper. If you can’t win that race, don’t run it.
  • Getting users is far more expensive than keeping users, which means that investing in keeping users is the smartest way to maintain your position and then grow.
  • Software can create connection, and connection is the engine of our future economy.

Twitter as communication tool for botnets

ESET researchers discovered an Android backdoor Trojan controlled by tweets. Detected by ESET as Android/Twitoor, it’s the first malicious app using Twitter instead of a traditional command-and-control (C&C) server.

After launch, the Trojan hides its presence on the system and checks the defined Twitter account in regular intervals for commands. Based on received commands, it can either download malicious apps or change
the C&C Twitter account to another one.

“Using Twitter to control a botnet is an innovative step for an Android platform,” says Lukáš Štefanko, the ESET malware researcher who discovered the malicious app.

First appearance of twitter-controlled botnets though was discovered in 2009, as mentioned in the article.

Comparing Twitter to other social media like Facebook, blogs (WordPress, Tumblr), Twitter stands out as a massive communication protocol – everyone talks with everyone, the message format is defined, limited by size. Twitter’s been used as a communication tool in many occurrences, either helping people as “Twitter monitoring of decease outbreaks“, or organising massive manifestations in Taksim square, Turkey.

twitter_cover

No wonder, why we ended up seeing Twitter as botnet communication tool.

In those days, I posed the concept that Twitter should not be a company alone. It should be an open protocol much like HTTP or email protocols (IMAP/POP). There should be an adopted industry standard that Twitter, the company, should and could (and still can) champion and work through with the guidance of other industry members.

It’s been published in 2012. Four years later, we’re witnessing the results, and more interesting things to come. There have been rumours that Twitter isn’t profitable, but tools it developed will evolve in the community anyway. Ideas get their niche and evolve in new products.