Different settings for different file typesEdit

You may want indentation for html files to use tabs with 2-columns per indent, while Python files use spaces with 4-columns per indent. To apply suitable settings automatically, first enable file type detection with the following in your vimrc:

filetype plugin indent on

Create file html.vim with contents:

setlocal shiftwidth=2
setlocal tabstop=2

and file python.vim with contents:

setlocal expandtab
setlocal shiftwidth=4
setlocal softtabstop=4

The html.vim and python.vim files should be in this directory (which you may need to create):

• ~/.vim/after/ftplugin on Unix-based systems; or
• $HOME/vimfiles/after/ftplugin on Windows systems

The standard plugins probably do not change settings such as shiftwidth, and in that case the directory ~/.vim/ftplugin (or $HOME/vimfiles/ftplugin) would work as an alternative. However the "after" directory should be used because you intend to override settings from other plugins.

Using the "after" directory as above is recommended, but it is possible to put commands such as the following in your vimrc as an alternative:

autocmd FileType html setlocal shiftwidth=2 tabstop=2
autocmd FileType python setlocal expandtab shiftwidth=4 softtabstop=4

Useful PHP tip

Free tier for new AWS customers*

New AWS customers will receive the following EC2 services each month for one year. Usage is calculated each month across all regions and automatically applied to your bill - unused monthly usage will not roll over. Restrictions apply; see offer terms for more details.

 

• 750 hours of Amazon EC2 running Linux/Unix Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) - enough hours to run steady state each month
• 750 hours of Elastic Load Balancing plus 15 GB data processing
• 10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs, 1 GB snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests
• 15 GB of bandwidth in and 15 GB of bandwidth out aggregated across all AWS services

 

 

Voxer is a walkie-talkie for the modern age, an iPhone app that lets you instantly talk across the interwebs and listen at the same time and leave voice messages if no one is on the other end and simultaneously chat with multiple people and toggle between text and voice to your heart's content. It's a real-time internet app in the extreme, and that's why it's built with a development platform most of the world has never heard of.

Matt Ranney and his team originally conceived Voxer as a two-way VoIP radio for the military, and he started coding in good old fashioned C . "That's what you use for a serious, high-performance military application," he says. But C proved too complex and too rigid for the project at hand, so he switched to Python, a higher-level language that famously drives services at the likes of Google, Yahoo!, and NASA. But Python proved too slow for a low-latency VoIP app, so he switched to Node.

Node is what the developerati call Node.js, a two-year-old development platform specifically designed for building dynamic net applications. The "js" stands for JavaScript. Node is built atop V8, the open source JavaScript engine at the heart of Google's Chrome browser. But it's not a browser technology. Node moves V8 from the client to the server, letting developers build the back end of an application in much the same way they build a JavaScript front end.

Voxer: the Node walkie-talkie

But that's only half the proposition. Node is also an extreme example of an "event-driven" system, a software architecture that's built around not threads or data but events: messages from other other applications or inputs from users. In short, it doesn't wait for one thing to happen before moving to the next. If it calls a database for information, for instance, it can tackle the next task before the database responds. Whereas traditional multithreaded systems are suited to heavy CPU work, event-driven systems are meant for network applications that involve heavy I/O.

When a user connects from across the net, the Node "event loop" needn't preallocate a huge chunk of memory for whatever happens next. It allocates only small slice of memory – a placeholder, if you will, that simply identifies the connection – and it grabs additional memory only as required.

This setup, Matt Ranney realized, is ideal for an app like Voxer, which requires unusually low latency with an unusually large number of open connections. "If you want to make something where the user gets a real-time update stream of some kind, you need to keep open a bunch of connections to the server. That's very expensive in, say, a PHP architecture. But in Node, it's nearly free. You can keep the connections open for a very long time, and the incremental cost per connection is very low," Ranney, Voxer's CTO, tells The Register.

"Node is the best of both worlds. We get JavaScript, which is uniquely suited to this kind of evented programming, but we get the performance too."

When he first built Voxer, Ranney ran a test to see how many connections he could open a single server. "I just decided to open as many connections as I could, just to see where things would fall down," Ranney says. "With Node, I could open, well, all of them. I couldn't open any more connections without getting more IP addresses on my test machine. Node uses such small amounts of memory, it's astounding. I ran out of port numbers."

Next page: The New Everything