VIM + screen. Organization of a remote web development environment

A million articles have been written about workflow organization, code editors, usability and stability. Without claiming to be the “most wonderful way,” I want to tell you how the web development environment is organized for several people from our team. I’ll make a reservation right away if you use only local GUI code editors, Notepad ++, Eclipse, etc., then this article is not for you. We work a lot in the console, and therefore, as a result of many years of natural selection, many came to VIM, and the console is almost a separate tab in the development environment, as in the process, you need to look at the logs, write database queries, restart services, etc. Therefore, I want to share a specific practical recipe for organizing a web development environment for a programmer or admin who works for a long time in a standard remote console.


Using this scheme, our work environment on any computer is just PuTTY and a browser, and we have all the joys of a multi-screen, crash-proof development tool that is entirely on the server side. When the light suddenly blinks, all computers go into reboot and popular unprintable expressions come from all directions, I just reconnect to the server and find myself right in the middle of the expression that I had before the reboot. This is very convenient, given that on the local computer I have nothing but PuTTY, a browser and WinAmp, and I can safely do the same 5 minutes after I throw my computer out of the window and take a new one.

But formally, the requirements for the development environment are as follows:

• VIM text editor
• Windows on a local computer (any other OS with a terminal is also suitable)
• The complete lack of working settings on the local computer
• Several parallel full-fledged consoles (logs, DB console, all sorts of configs, code, templates, etc.)
• Each console is a tab, switching between them is done using Shift + <left and right arrows>
• Saving the state of all consoles (tabs) when disconnecting from the server

There are also disadvantages:

• No network - no work. No letters. Although, for a web developer working on a test server, working without a network is still unrealistic, so I do not consider this a serious drawback
• Only console code editors. As I already mentioned, everything described below will relate to work in consoles, as the main workhorse will be the linux screen
• Because PuTTY has its own text buffer, and screen has its own, and they do not know about each other, in order to scroll up the output of a thread of a long SELECT, you have to press Ctrl + A and then ESC, after which you can use the cursor and PgUp , PgDown go up and down the screen-a buffer, and press Enter to exit the screen-a buffer movement mode

I’m a lazy person, I’m not too interested in reading a bunch of configuration options and delving into the intricacies of the programs used, so I just copied many pieces of configs from several different articles, the authors of which are respectful and deep human thanks.

For starters, two screenshots from PuTTY, more precisely, its modifications, begPuTTY . I use begPuTTY only for one purpose: it correctly transfers the keyboard shortcut Shift + Arrow Left and Shift + Arrow Right to the console, which I need to switch between a la xterm consoles. You can download it and thank the author here. If you are ready to use a different key combination to change the tab, then you can use the usual PuTTY. That, in fact, is all that I need to work on the project. Portable, isn't it?

So screenshots:





The most interesting thing here is the bottom line, where AUTO1, AUTO2, etc. These are tabs, I switch between them using the very coveted Shift + Arrow Left / Right, and each of them is a full-fledged separate console, the state of which saves a separate screen. For example, in AUTO2 the open mysql console usually hangs, and in AUTO3 and AUTO4 code. I recommend not to be greedy with the number of tabs, because a person can effectively keep in memory, without confusion, from 6 to 9 entities. Such a number of tabs can be easily kept in mind and remember what is happening. If you do more, you will have to spend time remembering where. But this is so, an excursion into the beginnings of cognitive psychology ...

Having entered the server, I run the command to connect to the desired project, and screen either creates eight new independent consoles with tabs in the status bar or connects to the current ones, restoring the state of each individual console.

Suppose I have two projects, for example, “ auto ” and “ moto ”, each of them has its own environment and its own set of screens. I have one .bashrc , which contains a different environment and different alias for each project, depending on the environment variable $ PROJ . Here is this .bashrc :

# .bashrc
# здесь то, что обычно лежит в .bashrc и не относится к нашей проблеме
# …
# ВОТ ГЛАВНОЕ – алиасы, которые запускают screen с параметрами,
# говорящими ему подключаться к существующим скринам, если они есть, или создать новые
alias auto='screen -AadRRS auto_screen -c /home/supergdeto/WORK/.screenrc_auto'
alias moto='screen -AadRRS moto_screen -c /home/supergdeto/WORK/.screenrc_moto'
# теперь так, если $PROJ == ‘auto’ – готовлю ENV для проекта “auto”
If [ "$PROJ" = 'auto' ]; then
export PROJECTPATH="/home/supergdeto/auto/"
alias chik_chik_i_v_production='echo “yupi”'
cd /home/supergdeto/auto/
# куча всего по проекту auto
fi
# для ‘moto’ – свои настройки 
If [ "$PROJ" = 'moto' ]; then
export PROJECTPATH="/home/supergdeto/moto/"
alias chik_chik_i_v_production='echo “yupi”'
cd /home/supergdeto/moto/
# куча всего по проекту moto
fi

A separate screen (one of the tabs) is launched very simply - a script from a couple of lines. Two such simple files for " auto " and " moto ":

$ cat / home / supergdeto / WORK / dev_env_auto

export PROJ=auto
bash

$ cat / home / supergdeto / WORK / dev_env_moto

export PROJ=moto
bash

And finally, the main thing: .screenrc_auto ( .screenrc_moto made by analogy)

$ cat /home/supergdeto/WORK/.screenrc_auto

# Turn off start message:
startup_message off
# Set messages timeout to one second:
msgwait 1
# keep scrollback n lines
defscrollback 5000
hardstatus             alwayslastline
termcapinfo xterm*|rxvt*|kterm*|Eterm* 'hs:ts=\E]0;:fs=\007:ds=\E]0;\007'
termcapinfo xterm ti@:te@7 
# эта строка как раз рисует табы внизу, в строке состояния, подсвечивает текущий и т.п.
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{y}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
nethack on
vbell off
#  Здесь комбинациям Shift+Arrow Left/Right назначается переключение между табами
bindkey ^[[1;2C next
bindkey ^[[1;2D prev
# ну а здесь я создаю 8 скринов AUTO1 – AUTO8
screen -t AUTO1 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO2 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO3 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO4 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO5 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO6 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO7 /home/supergdeto/WORK/dev_env_auto
screen -t AUTO8 /home/supergdeto/WORK/dev_env_auto

At the end of the file are just those 8 screenshots-tabs with their names. To connect to them, I log in, type “ auto ”, start screen -AadRRS auto_screen -c /home/supergdeto/WORK/.screenrc_auto , which either creates new screenshots or connects to existing ones. In our experience, new screens are usually created only when the development server is overloaded or some binary output “exploded” the screen. This happens extremely rarely, so usually we don’t even worry about unsaved files.


Well, now the bonus! What I, the lazy, was terribly lacking in all the articles to quickly try this thing in action. Although cracking, reluctance to understand the intricacies of the screen, transferring key codes to PuTTY, draw the format of the status bar. The one who likes this, a long time ago did everything better than me, therefore, attention, step-by-step instructions for those who want to try. If there are several projects, then simply repeat steps 3-8 for a new project. Let user: avatar, project: projectone

1. Download yourself begPutty from here and use it
   
2. Create the directory / home / avatar / WORK
   
3. create an executable file dev_env_projectone in WORK (it launches a separate tab) and write down two lines there
   

   export PROJ=projectone
   bash
   

   
   
4. create the .screenrc_projectone file there (it starts a bunch of screenshots, launching the dev_env_projectone file in each of them ), copy the contents of the .screenrc_auto listing from this article into it
   
5. rename lines like " screen -t AUTO1 / home / supergdeto / WORK / dev_env_auto " into " screen -t PROJECTONE1 / home / avatar / WORK / dev_env_projectone " and make the number of these lines equal to the required number of tabs
   
6. in .bashrc, if you need a different environment for different projects, add a section for PROJ == ”projectone”, like this:
   

   If [ "$PROJ" = 'projectone' ]; then
   	# Здесь всё, что относится к настройке окружения при работе с проектом projectone
   fi
   

   
   
7. there, in .bashrc add alias
   alias projectone = 'screen -AadRRS projectone_screen -c /home/avatar/WORK/.screenrc_projectone'
   
8. log in or run .bashrc
   

Now connect to the server, type “projectone” in the console, and your tabs will appear. In each of them there will be a console with the environment for the project “projectone”;

Start typing “SPASI ...” and suddenly tear off the LAN or power from the connector, or cut off WiFi. Then repeat the operation, and finally add the magic word ...