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.
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)
Q: how many programmers does it take to change a light bulb?
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”.
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.
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.
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.
The first step is to invent a thing worth making, a story worth telling, a contribution worth talking about.
The second step is to design and build it in a way that people will actually benefit from and care about.
The third one is the one everyone gets all excited about. This is the step where you tell the story to the right people in the right way.
The last step is so often overlooked: The part where you show up, regularly, consistently and generously, for years and years, to organize and lead and build confidence in the change you seek to make. (c) Original article
Today, we are excited to share the fruits of our research with the broader community by releasing SyntaxNet, an open-source neural network framework implemented in TensorFlow that provides a foundation for Natural Language Understanding (NLU) systems. Our release includes all the code needed to train new SyntaxNet models on your own data, as well as Parsey McParseface, an English parser that we have trained for you and that you can use to analyze English text.
Google announced the release of their English parser earlier today. Great news, let’s see how it will influence the market in the bearest future.
I’m not the only one blown away after digging up some of React/Redux boilerplate code. Great article proving some of my thoughts on the subject:
Copy-pasting configs from boilerplate projects always leads to hard-to-debug issues like this. It’s easy to miss somebody’s configuration decisions when you’re not the one making them. Don’t use boilerplate projects unless you understand each and every technology it uses!
I understand Dan’s frustration. But could we look at this from a different perspective? Don Norman’s The Design of Everyday Things teaches that there’s no such thing as “user error” — humans always make mistakes, and the failure to deal with these is on the product, not the user. How would we approach these user errors if we looked at them as design failures?
Yet another justification of “convention over configuration” and the reason of choosing EmberJS at the given time. Sorry React, not now, maybe a bit later.