Google+ does not understand context

Google Plus is a beautiful product, it was built exactly the way it should have, fully integrated with all of the other Google tools, effortless in removing all barriers from users to connect and share content, a logic approach from a logical company that does not do anything out of pure chance. 

In Google’s ideal world everything is interconnected, all systems are intertwined aware of one another very much like a living organism where separate parts of the system work together with the same end goal, the problem is that the principle behind the product is based on the assumption that Humans beings value convenience and utility equally on all aspects of life, after-all it worked for search, mail, and mapping, why wouldn't it work for social?

Human Interaction is not as linear as it may seem. Context is important. Once a user goes into Facebook he/she switches off work mode and the context changes completely, users are surrounded by people they know and care about (well most of the time) in an environment that does not resemble anything that can be connected to work.  

This is precisely where things turn sour for Google Plus as it is not recognizing that context affects the way users interact with a system, and so the biggest strength of the product, its close integration with all the Google ecosystem, becomes its biggest weakness. Work and leisure may be all part of who I am, it is important for me that a boundary between both parts of my life to exist.

Django is not Python

I have noticed an interesting phenomenon of young software developers that start learning a specific coding language from a Framework rather than mastering the language on the first place, to me, it's almost like knowing how to cook a recipe without having tried the ingredients first; it all goes well if the process is seemingless, but the moment there is an exception things can turn sour very quickly. 

Currently Django is my Framework of choice. Not only does it use Python, but despite all of its flaws it does a fantastic job in maintaining some of the principles that make Python so great (i.e. DRY) while speeding up the development process by adding structure: MVC, great DB handling and design. "The Web Framework for perfectionists with deadlines"

The problem is that convenience can be a dangerous thing; as with most Frameworks it is very easy to get lost in abstraction of all that magic that happens under the hood. It is terribly addictive, when I am developing on Django I don't really feel like I am coding at all, it feels like  operating a factory line joining parts together, by the time I a done its difficult to know/remember how I got there. 

For example Classes in Django have very little resemblance to Python Classes. From a configuration perspective, it is far from ideal, but if a developer is not fully versed on Python before dwelling in the "Merlin World" of Django, looking a the way that Django converts strings into objects for example may look like an act of Magic. 

Django is a fantastic tool used by Python developers to speed up the development process, I do not recommend it as a starting point to anyone wanting to learn Python. 

PostHaven as an Alternative to Posterous

As soon as the announcement was made that Posterous had been acquired by Twitter, it was obvious to me that the service would not survive for long.

Unfortunately, this was the case. On the February15th, Posterous Founder and CEO Sachin Agarwal posted in the company’s blog that on the 30th of April, Posterous service would be shutting down. The message was short and sweet; lights were going to be “turned off” indefinitely on all desktop and mobile applications as from that moment forward.

Posterous was a great idea, very well executed, but like many others before, without a solid monetization model behind it. It’s the product of a generation of entrepreneurs that did not care too much for making money. 

I can relate to this in more ways than I would like to. Making a difference while worrying about utility bills is draining and ultimately, constraints growth.

Checking out

I found that a great idea wants to be born and wants to fulfill its promise. It does think it needs funding, business cases, risk assessment, or legal support. It just wants to exist. Unfortunately, a great idea does not know if its good or bad. 

Posterous happened to be a good one, a very good one, however, even good ideas need fuel to run, and it does not matter how disruptive or innovative something is, if it does not have financial backing, it is not likely that it will take off. This was what ultimately sealed Posterous destiny. 

Fortunately, the idea that every cloud service should be free or depend on advertising seems to be slowly fading away. Even the likes of Google is now moving from relying exclusively on Pay-Per-Click advertising and is charging for services online. I am hoping this will lead the way for other companies, particularly startups, to start thinking differently about the sustainability of their products before they hit the market. Very few ideas can survive if they do not have means to survive.

The Posterous Experience

I have nothing but great things to say about my time as a Posterous user. It had this awesome vibe about it that sometimes its hard to explain. Looking at it “scientifically”, it did not really have any disruptive functionality, but a combination of different factors made the platform special. 

The folks at Posterous paid a lot of attention to detail, enabling a wonderful, consistent user experience within their platform. The Blog templates were an extension of this experience. Every element of the Blog design was carefully design with purpose, unnecessary functionality and elements was stripped away. 

So the platform transpired simplicity at its finest, geared for blogging and content, built for what they were meant for, a testament to Steve Jobs famous quote “Simplicity is the ultimate sophistication”. 

This is exactly where I felt Posterous added a lot of value and got it right. The company seemed to remain focused on their core product it was a blogging platform, and it fulfilled its purpose beautifully.

The only downside I can remember as a Posterous was the reliability and availability of their network. It was always been somewhat flaky, something that most users have learned to accept as the downside to a free service. This was however all too unnecessary, as I am very certain most users would have gladly paid for the service, I know I would.

Posthaven as an alternative

So how does Posthaven compare to Posterous? 

Posthaven is co founded by Garry Tan and Brett Gibson, both previous co founders at Posterous. The company's pledge states that it is in this for the long run. It bravely emphasis a principle that I think should be at the core of every entrepreneurial venture; Companies need money to be able to survive. 

Currently the homepage is just a splash page that talks about the companies pledge, and a bit about the service. One needs to register to fully experience everything beyond that page. 

The registration process is very straightforward, email, password, subdomain url,  and you are done. Keep in mind that you will need to provide credit card information to be able to login, but no charges will be made beyond the trial period. Nevertheless, payment information needs to be provided in order to access the dashboard features. 

One thing I accidently noticed was that even when I did not provide my payment details at first, I was able still able to register and I think my username was immediately “reserved”, because the second time I tried to register, it made me login, even though I had not provided my credit card details on the previous attempt. 

Importing my Posterous blog was extremely easy, I only needed to provide my Posterous credentials while logged in on both platforms, and the process was quick. Its worth to note that I chose to only import 70 posts, so not sure how the system will behave with bigger blogs. 

The User Dashboard is very well built and easy to use. In comparison to Posterous, its as clean, but somehow feels more robust. There is an apparent understanding of what made Posterous successful, even with the bare minimum functionality available at the moment.

Every detail was looks like it was carefully engineered into the concept. The User Interface is device responsive, and looks amazing in a Tablet. There is an ability to add posts seaminglessly across devices, even on a mobile phone. A user can start a post on a desktop, and continuously edit it on other devices until its ready to be published. 

It is already possible to create multiple blogs through the admin interface, and import content from Posterous. Within the blogs, the functionality is still slightly limited, but it is possible to assign a custom domain to a blog, edit its name and description, and of course, add and edit posts.

There are some features that I am hoping to see very soon. I miss Social Connections and ability to post to different social channels is a must. It would also be good to see more blog templates, but I would rather see very few amazing templates rather than a focus in quantity. Afterall, one of the Unique Selling points of Posthaven should be a “refocus” on content. 

Endless widgets, plugins and functionalities that regurgitate third party content should be left for other blog platforms, like Wordpress and Blogger. Posthaven users care about the content they produce, about how its published and how its used by people. I feel this is exactly what Posthaven needs to capitalize on. Posthaven bloggers are not like any other bloggers, treating them differently, the same way Apple treated their small user base 10 years ago, looks like the right thing to do. 

In short, Posthaven needs to Stick to the basic principles behind a Blogging platform for people who create unique content, stripping away everything that is a distraction, providing the tools to create and share blog posts from any device.

Posthaven is off to a great start and has the potential to become as unique and awesome as Posterous once was. It also seems to be avoiding the mistakes made by posterous by understanding that the service will need to be paid to be able to survive and evolve.

Server Naming Conventions

Had an interesting discussion a couple of weeks ago about the best way to identify servers in a scalable and sustainable way.  I used to be very keen in naming boxes with generic unconventional unique names. i.e. city names, colours, movie characters,  but have found that this simply does not scale.

Had a very good piece of advice from my friend Christopher Farley that gave me a different insight to this and outlined the importance of getting this right when scalability is a factor.

In his view,taking a functional approach to server naming, in time, proves to be a scalable solution, by making the identification of boxes more efficient and pragmatic, allowing sys admins and network engineers to quickly map a box against an environment profile.  This saves time and a lot of hassle, particularly in a time when network frames are downsized and upsized in very short time spans.

There are a great number of different conventions out there. I searched for common standards, but it seems that there isn’t a cohesive approach across the industry; each organization tends to follow its own way, which makes sense to a certain extent, but also adds a degree of confusion that could possibly be mitigated if there were a set of principles recognized by the industry. 

For large organizations, identifying boxes with names of the geographic locations where the server is hosted, the data centre location, followed by other specifications, might sound logical, but the most obvious constraint to this approach is around what to do when servers need to be repurposed. 

A clear example of this would be moving a box from one location to the other without intending to make a clean install. Since the Hostname is identified with a specific location, repurposing would not be effortless. Now if we are talking about a significant datacentre migration, this would constitute a major risk and an unnecessary overhead to an already complex operation. 

The same set of limitations is also present when attributing other functional attributes to server names  i..e db001 *database server. What if a server needs to be repurposed to a Web frontend box? or a Load Balancer? These are all valid questions, that should be asked before one chooses a specific server naming convention. Unfortunately, as like most IT challenges, bad decisions usually are only apparent when its too late to do anything about them.

On the other hand, the main advantage behind the functional approach is the ease of identification. In theory, the only thing that needs to be clarified is the principle, i.e. Server Type - Server Number - Location of server. From this moment forth, identifying servers in a network, regardless of the size, becomes extremely efficient. DB001NY - Database Server - Number 001 - Located in New York. 

This is particularly useful when working with external providers that do not necessarily know what is, and what should be mapped against. 

The final case that can be brought forward in favor of the functional naming convention, is that in most cases, repurposing servers is not really the right thing to do. Servers are built for a specific purpose, the Hardware and Software should be aligned to what we want to achieve, not the other way around, thus while repurposing a server might seem to be the quickest solution to respond to an immediate need, long term, its not the ideal way to built a scalable infrastructure.

For more information about this subject, there is a very interesting article by Scott Lowe that provides an excellent insight. 

Installing Apache – Mysql – PHP in less than 5 minutes

Was just setting up a brand new Linux Centos box, and thought I would contribute with a small tutorial on how to quickly install the core components of a Web server though shell.

Now note that to get the absolute latest software version an installation through the source code is required. While this is still easy, it’s not as fast.

The commands poster here will work with the Centos and Fedora distributions. 

1.  Login as a Roor user and paste the following command line

yum -y install httpd php mysql mysql-server php-mysql

2. Make sure Mysql is running.

# mysqladmin -u root -p status

If it’s not running, you should be getting something down the lines of…

mysqladmin: connect to server at 'localhost' failed

error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'

Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

To start the service simply type in the command:

/etc/init.d/mysqld start

The Output of this should be something down lines of…

Initializing MySQL database:  Installing MySQL system tables...


Filling help tables...


3. Protect Mysql by setting a password

mysql -u root@localhost

set password for root=password(‘yourpasswordhere’);

reload privileges;

4- Set apache and Mysql to run on startup. 

  /sbin/chkconfig httpd on

  /sbin/chkconfig --add mysqld

  /sbin/chkconfig mysqld on

  /sbin/service httpd start

  /sbin/service mysqld start

Thats it! your web server is good to go!