Category: Web work

These days, most of my work is very related to the online world. Building web sites, reviewing web applications, integrating with web services, coordinating people who are far away from each other, etc. Whenever I find a new tool or service or an innovative, interesting idea about working online, I share it in this category.

WordPress plugin : Google+ Comments

WordPress plugin : Google+ Comments

This looks very interesting.

google plus comments

 

There is some overlapping functionality with Social plugin, which actually brings comments from social networks back into the WordPress installation.  That’s a bit more useful in longer term, when social networks come and go.  Social also brings in likes from Facebook, and retweets and favorites from Twitter.  However for the discussion flow, this plugin might be a better fit.  I’ll probably try it on for a few days just to see how it goes.

Toni Schneider – Automattic As A Distributed Work Force

Toni Schneider – Automattic As A Distributed Work Force

Lots of Automattic employees within 7-9 months tell Toni that they can’t imagine going back to a regular job.

Automattic has been 100% distributed since day 1.

180 people, 28 countries, 138 cities make up the Automattic workforce.

Interesting point about people working from home. The assumption is that people would goof off. But Toni mentions how they have the opposite problem of people working too much.

This sounds awesome, but, personally, I don’t think I have the discipline to work this way.  I need to be in the office and I need face-to-face time.  I still appreciate the flexibility Automattic offers though.

Aggregating feeds isn’t all that simple

As I mentioned a few times, one of my first start-up ideas was an RSS aggregator.  It was back in 2005 or so, before Google Reader was even alive.  Bloglines was the coolest tool, if I remember correctly, and it sucked badly.  I got together with a few friends of mine and we started coding.  It was an interesting challenge both technically and aesthetically.  But we got it to the point where it actually worked and wasn’t all too bad.  It was a weird mixture of Python, Perl, and PHP though.

Eventually, it became too much work.  We couldn’t figure out how to monetize the thing.  And Google Reader was announced.  That sort of killed the project.

A few month back, when the announcement of Google Reader’s end of life came out, I looked at the alternatives and wasn’t pleased.  I thought with all the technical advances in the last few years, and with my own improved knowledge, I could attempt the task again.  Yes, I know, I am hopeless optimist in a lot of matters.

At least this time it took just a few days to convince me not to pursue the goal.  Alternatives are plentiful.  Each and every one of them is light years ahead.  I still don’t enjoy front-end development.  And I still have no clue as to how to monetize it.  So, the Subs Reader got frozen.  At least I got it all in frameworks, and left it in the Open Source state.  If I ever will have another try, I can pick up from here.

One of the biggest mistakes I’ve done the last time, was not documenting the project’s process at all.  I vaguely remember that I didn’t sleep for a few nights, trying to figure out all kinds of problems.  But what were they, I don’t remember.

Today, I came across a blog post which lists similar problems that I had to solve, but in greater number and variety.  Even if you aren’t thinking about writing your own RSS reader any time soon (or ever), you should still read through the Brian’s stupid feed tricks.  First of all, they clearly illustrate how much complexity is hiding in the details.  Secondly, they show non-standard is the web in general and RSS in particular.  If you do any kind of web crawling, you’d probably see half of the same issues in your application.  Thirdly, even if you aren’t crawling the web at all, but just code a web application or an API to one, you’ll many places where you can go wrong without noticing it.  All in all, it’s a great list of problems that everybody involved in web development can learn from.

Burberry Kisses, good or evil?

Here is something I have mixed feelings about:

Thanks to modern technology you can connect with your loved ones by sending a quick note, a photo of your cat, even a smile :) around the world in seconds. But one of humanity’s most iconic forms of communication—the kiss—has been left out in the cold. Now, though, you can send a kiss to anyone, anywhere in the world, through Burberry Kisses, a new campaign from Burberry and Google. And not just any kiss, but your kiss.

On one hand, this is sweet and romantic.  Yet, on the other, Google is so well known for its crowd-sourcing experiments, that it makes me wonder – what’s behind this one?  After all, when Google wanted to fix all those bad scans in Google Books project, they’ve started the Google Captcha service that used everyone on the web.  When Google wanted to teach it’s voice recognition of all the accents (at least in the States), they’ve opened up a directory service.   And they’ve done more of the same for images, artificial intelligence, and even maps.

So, what is a possible usage for a huge collection of lip images?

The darkest version I have is somewhere around fingerprinting.  Lip prints are probably as unique as finger prints.  And when you mix it up with, say, face recognition that they already have, who knows where that can lead.  Oh, by the way, now that I thought of face recognition, Android’s face recognition lock sounds suspicious as well.  Oh, crap.  I think I’m going paranoid!