Fotis Alexandrou geeky adventures

If you're anything like me, you're probably dealing a lot with the terminal. I use it all the time because i'm working with Git and lots of branches, i create cron jobs and console applications, so i need a pretty good terminal.

MacOS already has a great terminal but there are a lot of stuff missing from it, just because MacOS isn't meant to be used like Linux.

Anyhow, iTerm is a great terminal replacement and i highly recommend it

As it matures, the driving force of the sharing economy will become time, and the companies that can do business in real-time will occupy a more strategic, and profitable, place in the ecosystem.

Fresh off its $1 billion valuation, Airbnb is the most common reference point for all manner of “this for that” pitches bouncing around the Valley right now, with many new ventures proposing to be the “the Airbnb of X.”

But Airbnb is only one species of the sharing economy genus — a genus that will stratify over the next few quarters.

Real-time makes your brand a hero

Hotel Tonight is a great example of the flip side of the Airbnb coin. It focuses on real-time reservations, and the real-time use of latent capacity.

Airbnb’s transactions typically take place five or more days in advance of a stay, and any requests inside that window are put on a standby list. In contrast, Hotel Tonight only offers rooms for the current night, with a cutoff of 2 a.m. local time. It’s a fascinating constraint, and one that has propelled their business forward. When people need a room immediately and you’re able to provide them one, they will remember you.

Real-time can command premiums, not just discounts

Of course, different markets and different kinds of capacity have unique sensitivities to time.

Uber’s car service business is incredibly time-sensitive. One of its most common use cases is trips to and from the airport, which usually involves a high-stakes deadline on at least one end of the journey.

Other popular uses are travel on a busy holiday (think Halloween or New Year’s Eve in New York City during a public transportation strike).

The more time-sensitive a market becomes for buyers and sellers, the more lucrative the corresponding business opportunity.

This is an old lesson — price and revenue optimization wizards hold time in the highest regard. And as the time-sensitivity of a situation increases, the number of parties we’re willing to entrust with our affairs dwindles to a small handful.

Real-time puts coveted data in your pocket

What Hotel Tonight, Uber and my company LiquidSpace have in common is that we all know a lot about our customers’ travel patterns.

Additionally, we can extrapolate a ton of information about preferences — from who customers are likely to collaborate with to where they like to work or hang out.

With this real-time data, we’re primed to find other ways to make your stay, ride or meeting that much more enjoyable. We can quickly provide add-ons that customers need, such as snacks or printing, or partner with other vendors who can.

Whether by offering new services or opening up this powerful real-time data, we are exposing new revenue streams that the sharing economy enables.

With enough time, any latent capacity can be utilized. Each year at South by Southwest in Austin, Texas, we see twelve month’s worth of planning make use of every nook and cranny.

On short notice, sharing economies are harder to organize, and they involve more risk. Real-time capabilities mean that you sit closer to purchasing decisions, closer to strategic imperatives, closer to profit and loss, closer to sealed deals and averted crises.

Real-time is difficult, and precisely because it is so challenging to do real-time well, and safely, the market will reward those who invest in making the “here and now” a priority. In short, you’re closer to risk, and closer to reward.

Consumers want real-time access, and businesses demand it. The sharing economy is not only online, it’s also picking up speed.

Mark Gilbreath is co-founder and CEO of LiquidSpace, a mobile application that helps people find and share available workspaces.

Image courtesy of Flickr user psd.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Themes for a connected world: GigaOM RoadMap review
• Connected world: the consumer technology revolution
• Green IT Q3: Solar stumbles while car sharing zooms ahead

Using principles of progressive enhancement we turn a standard drop-down into an advanced auto-complete field. This means the drop-down remains accessible, while providing a much better experience in modern browsers – handling typos, multiple spelling sequences, synonyms and prioritization.

You can read the more about the design process and usability aspects in our article on Smashing Magazine: Redesigning the Country Selector.

Very interesting approach

How GitHub Uses GitHub to Build GitHub

September 21, 2011 / Helsinki, Finland / Frozen Rails 2011

Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features *as quickly as possible*? It's not just features, either: faster development means happier developers.

Slides

References

• Merlin Mann's "Mud Rooms, Red Letters, and Real Priorities"
• sinatra_auth_github
• Why GitHub Hacks on Side Projects
• How GitHub Works
• Scott Chacon's "GitHub Flow"

The actual presentation is hosted in the source website. Please visit. It basically describes an awesome productive way to work around your company or build your product

The Speaker

Garrett Dimon

Garrett is the founder, designer, and developer of Sifter, a simple hosted bug and issue tracking application.

View Speaker Details

Another great presentation on building a web application designed to make profit. I think the title says it all

Very interesting

This is how you can set up CodeIgniter to direct mysql queries to different read/write hosts in your db replicated environment, using a db_slave for your SELECT’s, and a db_master for the INSERT/UPDATE/DELETE queries.

File: application/config/database.php

Specify the different database hosts in the database config file:

< ?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

$active_group = "master";
$active_record = TRUE;

# db_master
$db['master']['hostname'] = "host1";
$db['master']['username'] = "username";
$db['master']['password'] = "password";
$db['master']['database'] = "exampledb";
$db['master']['dbdriver'] = "mysql";
$db['master']['dbprefix'] = "";
$db['master']['pconnect'] = FALSE;
$db['master']['db_debug'] = TRUE;
$db['master']['cache_on'] = FALSE;
$db['master']['cachedir'] = "";
$db['master']['char_set'] = "utf8";
$db['master']['dbcollat'] = "utf8_general_ci";

#db_slave
$db['slave']['hostname'] = "host2";
$db['slave']['username'] = "username";
$db['slave']['password'] = "password";
$db['slave']['database'] = "exampledb";
$db['slave']['dbdriver'] = "mysql";
$db['slave']['dbprefix'] = "";
$db['slave']['pconnect'] = FALSE;
$db['slave']['db_debug'] = TRUE;
$db['slave']['cache_on'] = FALSE;
$db['slave']['cachedir'] = "";
$db['slave']['char_set'] = "utf8";
$db['slave']['dbcollat'] = "utf8_general_ci";
...

File: application/core/My_Model.php

Add this into My_Model:

< ?php

class MY_Model extends CI_Model {
    function __construct(){
        parent::__construct();
    }

        function MY_Model()
        {
                $this->db_master = $this->load->database('default', TRUE);
                $this->db_slave = $this->load->database('default', TRUE);
        }

}

File: application/models/example_model.php

Use the read/write queries in your models like this:

< ?php
class example_model extends MY_Model {

        function example_model()
        {
                parent::MY_Model();
        }

        # read query
        function getSomething()
        {
                $query = $this->db_slave->get('mytable'); // db_slave
                return $query->result();
        }

        # write query
        function insertSomething()
        {
                $this->db_master->insert('mytable', $_POST); // db_master
                return $this->db_master->insert_id();
        }

That´s it!

Useful!

Jared Rosoff concisely, effectively, entertainingly, and convincingly gives an 8 minute MongoDB tutorial on scaling MongoDB at Scale Out Camp. The ideas aren't just limited to MongoDB, they work for most any database: Optimize your queries; Know your working set size; Tune your file system; Choose the right disks; Shard. Here's an explanation of all 5 strategies:

1. Optimize your queries. Computer science works. Complexity analysis works. A btree search is faster than a table scan. So analyze your queries. Use explain to see what your query is doing. If it is saying it's using a cursor then it's doing a table scan. That's slow. Look at the number of documents it looks at to satisfy a query. Look at how long it takes. Fix: add indexes. It doesn't matter if you are running on 1 or 100 servers.
2. Know your working set size. Sticking memcache in front of your database is silly. You have lots of RAM, use it. Embed your cache in the database, which is how MongoDB works. Working set = Active Documents + Used Indexes. Hitting something in RAM is fast, disk is slow. If you have a billion users and only 100K are active at a time then 100K is your working set. You want to have enough RAM for those 100K so operations are in RAM on not on disk. Remember indexes take memory too. It doesn't matter if you are running on 1 or 100 servers.
3. Tune your file system. Performance problems often traced to the filesystem. EXT3 is ancient. Use EXT4, XFS, or some other well performing file system. Turn off access time tracking, for a database there's no need to update a file every time a file is accessed, this is another write. Preallocating 2GB of files on EXT3 must actually write those bytes, it's slow.
4. Choose the right disks. Seek time is what matters. Most of what you are doing is random IO. Seek time is governed by a mechanical arm that has to swing over the disk. The average disk drive can do 200 seeks a second. Faster drives will move data off the disk faster, that is they have higher bandwidth, but their seek times will be the same. Single disk: you can do 200 queries a second. RAID 0 (stripe across multiple disks): 3 disks means 600 queries a second. RAID 10 (mirror and stripe): 6 disks means 1200 seeks a second. Choose the right disks. RAID matters. SSDs are awesome: .1 ms for a seek vs 5 ms for a disk seek. Great for random access.
5. Shard. If your app is slow, uses bad indexing, has slow disk drives, then a single node will be slow. Fix all this stuff before scaling out using sharded. Sharding lets you spread your workload over more machines along with high availability with replica sets. Data is partitioned to shards by ranges, for example. Can scale out to 100s of servers. Each can process 10s of 1000s of writes. Can add more capacity easily. Sharding with a good database multiples the benefits of having good queries, good drives, and good working sets. 

Related Articles

• Hilarious Video: Relational Database Vs NoSQL Fanbois

Useful :)

We all know that getting the IP address of the user is a quite easy job in PHP, even in any programming language. But are you sure that you are getting the real IP of the user?

In php, $_SERVER['REMOTE_ADDR'] is used to get the IP address of the user. But what happen if any user from USA access you site via proxy server of Australia. In this case $_SERVER['REMOTE_ADDR'] will return ip address of the Australia rather than ip address of USA.

Now let’s see the code snippet:

if (!empty($_SERVER["HTTP_CLIENT_IP"]))
{
 //check for ip from share internet
 $ip = $_SERVER["HTTP_CLIENT_IP"];
}
elseif (!empty($_SERVER["HTTP_X_FORWARDED_FOR"]))
{
 // Check for the Proxy User
 $ip = $_SERVER["HTTP_X_FORWARDED_FOR"];
}
else
{
 $ip = $_SERVER["REMOTE_ADDR"];
}

// This will print user's real IP Address
// does't matter if user using proxy or not.
echo $ip;

via xpertdeveloper.com

This is a super cool trick