Сергей

tar zcf - tobearchived | ssh user@destination_server_ip 'tar zxf -'
Жмёт со сжатием в tar, отдаёт поток сжатого по ssh, на той стороне запускается tar и распаковывает.
В цепочку можно добавить любой архиватор по вкусу.

Для ускорения канала - выкидываем сложную шифрацию в настройках SSH, оставить какой-нибудь RC4, компрессия скорей всего тоже будет только замедлять.

я так дамп сервака делаю периодически :)

У вас скромный рейт. Хотя, возможно, для Чехии это нормально.

Я работал и работаю на фрилансе уже много лет. И в штате много лет тоже работаю.
Поэтому могу кое-что сказать.

Минусы

1. Все байки про фриланс — правда.

2. Нужно иметь железную дисциплину, чтобы работать в строго отведенные часы, а в другое время отдыхать. И чтобы вставать вовремя, а не спать до обеда.

3. Со временем ты превращаешься в пещерного человека, потому что большую часть времени проводишь дома. Кому-то это комфортно, кому-то не очень. Кто-то умеет с этим справляться, кто-то нет. Но социализации, доступной в офисе, очень не хватает. Фейсбук и чаты не заменят живое общение.

4. Очень много мудаков среди клиентов. Со временем научишься их определять с первых же слов в переписке. Но до этого придется некоторое количество раз обжечься.

5. Клиенты имеют привычку тянуть с оплатой. С предоплатой никаких проблем, а вот чтобы забрать постоплату — частенько нужно задолбать клиента. И это вполне понятно — на фриланс приходят молодые бизнесы, и довольно часто у них бывают кассовые разрывы, дефицит бюджета, смена направление и много чего еще. Из-за этого у тебя у самого уже начинают возникать кассовые разрывы. Вроде, тебе и денег должны прилично, а когда их получишь — хз.

6. Хорошее описание проекта, хороший продукт сам по себе — на фрилансе этого мало. Повезет, если получится удаленно вписаться в команду, которая делает или большой проект или делает много проектов на потоке. Если же это разовые проекты, то будь готов к задаче вида "ну мне вот сайт нужен с формой, сообщениями и робокассой, а ну вот еще там корзина, да".

7. Забудь про стабильность. Сегодня ты заработал двойную зарплату, а в следующем месяце процентов 50. Нет никого, кто строго раз в две недели будет тебе перечислять деньги на карту.

Плюсы

1. Свобода в выборе задач и проектов. Это прям кайф.

2. Есть возможность заниматься своими делами, потому что за проекты отвечаешь ты и только ты. Соответственно, можно брать выходные, когда тебе удобно, а не когда они на календаре пришли.

3. Если наработать клиентскую базу, то можно со временем отойти от дел руками, а заниматься лишь форвардом задач или вообще вырасти в полноценный продакшен.

4. Есть возможность учиться. Не вечером после работы, днем, когда голова свежая.
Офис эту возможность сильно ограничивает.

5. Есть много времени и сил на свои проекты. То, до чего не доходили руки целый год офисной работы, может быть сделано довольно быстро.

Где работать
Попробуй везде. И на фл и на апворке есть свои плюсы и минусы.
Но самые лучшие клиенты — это, конечно, которые приходят напрямую.

Все системы, в которых безопасность базируется на алгоритмах типа RSA, окажутся скомпрометированы. Защищенный обмен данными по HTTPS, подпись обновлений программ и оборудования, ключи авторизации SSH.
Производители постараются как можно быстрее выкатить апдейты ПО, закрывающие образовавшиеся дыры в алгоритмах обновления и авторизации (используя, например, алгоритмы эллиптических кривых), но далеко не все произведут обновление, а некоторые устройства и вовсе невозможно будет обновить.
Если такой алгоритм действительно будет найден и будет выложен в открытый доступ, будет полный бардак в мире IT на ближайшие 5 лет

Для управления 5+ серверами удобно использовать софт для оркестрации, для начала посмотри на ansible.

Как заливать код/бинаркини на сервер - да как угодно. Хотя проще/секурнее использовать тот же scp, благо ansible с ним работает из коробки.

Bittorrent нужен, когда тебе надо закинуть условно 100Gb на 100 серверов и все эти сервера в одной сети, это совсем другая задача.

Ты - не Twitter или Facebook, и ихнструменты, которые используют они, для тебя могут быть бесполены или даже вредны.

Полномочия на склейку и удаление тегов есть только у администраторов сервиса, т.е. предложения по склейке и удалению тегов следует направлять в форму обратной связи.
Нужно заметить, что рабочий день сотрудника службы поддержки, как правило, насыщен более актуальными задачами, поэтому некритичные задачи, типа работы с тегами, решаются ими в свободное от работы время.
Сам по себе процесс довольно трудоемкий:

• перед склейкой тега требуется просмотреть всю его ленту и убедиться, что туда не затесались вопросы не имеющие отношения к тегу с которым планируется склейка (при обнаружении таких вопросов, соответственно, приходится их редактировать и указывать актуальные для них теги);
  
• перед удалением тега требуется просмотреть всю его ленту и убедиться, что в ней нет вопросов отнесенных лишь к этому тегу (при обнаружении таких вопросов, соответственно, приходится их редактировать и указывать актуальные для них теги).
  

В последнее время нам с этим активно помогает модератор DevMan (поэтому пользователям часто приходят упоминания о том, что он внес изменения в их вопрос) и нам остается лишь проводить транзакцию по склейке/удалению.
Поскольку число тегов конечно, то я надеюсь, что рано или поздно мы избавимся от бесполезных и абстрактных тегов (например, «запрос» или «онлайн»), появившихся во времена, когда создать тег мог любой желающий, и приведем систему тегов к балансу при котором подписчики тегов будут получать только релевантные вопросы, а авторы вопросов получат больше шансов обрести ответ.

как лучше обращаться к Go, через Proxy или FastCGI?

И так и так хорошо. Я все же предпочитаю вариант проксировать запросы на Go.

Не могу проверить вообще, так как на рабочей машине Windows.

Это не проблема, поставьте виртуалку и вперед. В конце-концов: личный опыт лучше любых объяснений.

И ещё очень странный вопрос: нужно-ли при таком подходе компилировать Go? Просто где-то видел пример кода, когда обращаются к исходному файлу с расширением .go.

Компилировать нужно, особенно в случае большого приложения.
Да, можно сделать:
go run file.go
Но, во-первых, код все равно компилируется в бинарник и выполняется при таком подходе, просто это происходит в папке с временными файлами и как бы скрыто от Вас.
Во-вторых, этот подход не катит, если в папке с проектом больше файлов нежели file.go (имеется в виду на уровне package main).
В-третьих, это обязует Вас иметь установленный Go соответственной версии на production серверах, когда обычный бинарник этого не требует.
В-четвертых, а как быть в таком случае с демонизацией и zero downtime reloads? Да, можно, но неудобно, учитывая что каждый раз нужно будет перекомпиливать.
Лучше скомпилировать один раз и не заморачиваться.
Команда go run больше подходит для небольших файлов аля скрипт для выполнения одноразовой работы и тому подобное.

Прошу не кидать камнями, я только учусь правильному написанию веб-сайтов на Go.

Учиться - всегда полезно, никто камнями кидать не будет.

Ой как я вас понимаю. Сам страдал от подобного долгие годы (9 лет, если быть точным). К сожалению, мгновенного решения для вашей проблемы не существует. А смена работы - всего-лишь временная отдушина. В моём случае технический скилл был (и надеюсь остаётся) выше среднего, а лидерский (так называемый софт-скилл) - на нуле. Умение договариваться с людьми, адекватно реагировать на нужды коллег, продукта и бизнеса - оказались очень полезными навыками. К сожалению этот скилл не прокачаешь за выходные. Вот примерный список того что можно делать для прокачки лидерских качеств:
- читать книги (в т. ч. художественную литературу)
- участвовать в опен-соурс проектах
- делиться опытом (выступать на митапах, выступать в кругу коллектива)
- прокачивать т.н. "эмоциональный интеллект"

В своём случае я почувствовал ощутимые улучшения примерно через год целенаправленной работы над собой.

Как показывает жизненный опыт, на одних-лишь технических навыках в рай не уедешь. Чтобы быть красавчиком нужно уметь решать конфликтные ситуации.

Трудно - и с каждым годом будет все сложнее и хуже. С каждым годом растет объем пула "минимально-необходимых для программиста компетенций" . Каждый год появляются какие-то новые фреймворки, инструменты, фишки - которые по идее должны облегчать и упрощать разработку - но на деле вырастают непреодолимой стеной между тобой и "реальным миром веб-разработки". Потому что ты стареешь, а технологии молодеют.

Я бы картинку нарисовал, но там очень уж нецензурный вид получается ;-)

И "впихнуть" в себя все новые технологии ну не получается никак - ты или распыляешься и все знаешь по верхам... или идешь вглубь темы. Но тогда приходится откладывать новые технологии в сторону, потому что на них тупо не хватает времени и/или сил. В молодости - времени. Позже - сил.

Уже сейчас чтобы тебя считали верстальщиком/программистом/фронтэндером/бэкэндером - надо знать в 2 раза больше технологий, чем 2 года назад. Этакий Закон Мура наоборот. Да вы сами просто посмотрите эти списки "компетенций"!

Читаешь список требований к "Web-программистам" и видишь, что месяц за месяцем, год за годом HR-ы и те, кто там им задачи ставит, вписывают в требования все больше умных словечек, которые они сами услышали и не понимают, зачем оно им нужно и нужно ли? Все ближе и ближе ситуация подходит к "Если бы водителей принимали на работу как програм.... В 2010 году это была "шутка юмора". Сейчас это уже почти реальность.

Пример хотите?

Одна государственная организация выставила список требований к "веб-программисту". При зарплате в 35000 рублей он должен уметь чуть ли не МКС программировать и чуть ли не кластера из сотен серверов настраивать. А на деле основной задачей человека будет - таскать проекторы из аудитории в аудиторию, чистить мышки студентам, переставлять winxp и изредка, раз в полгода - добавлять статью на сайт гос.организации. Откуда информация? Связался с человеком, которому 45, который в этой организации работает уже 18 лет. Ему стаж капает, а деньги он зарабатывает совсем в другом месте.

Что уж говорить об организациях коммерческих? Особенно тех, для которых веб-программист - и чтец, и жнец, и на дуде игрец?

Но это все лирика и крик души. Извините.

И да, к 35-40-45 годам по мнению "молодых и амбициозных IT-специалистов" ты должен обладать строго определенным списком компетенций как в профессии, так и по жизни (к примеру, я столнулся с отказом в приеме на позицию программиста потому что у меня нет... автомобиля. Зачем программисту автомобиль? Ну там сложная и длинная логическая цепочка, сводящася к "раз у тебя нет автомобиля - ты лох, а лохи нам не нужны").
Мне кажется, проблема в том числе и в том, что подавляющее большинство этих самых "молодых и амбициозных" специалистов совершенно не думают о своем будущем. Нет, я не про то будущее, которое "куда я пойду, когда закончу вот этот крутой проект". Я о реальности. В их понимании 35 лет - это недостижимо далёкое будущее, а до 50 они не доживут (а если и доживут - то в мечтах тимлидами в гугле).

Соответственно "молодые и амбициозные специалисты" с презрением смотрят на людей, которые отдали 15 лет разработке определенной платформы, платформы, которую сейчас тщится заменить какой-то пул новых технологий. По их мнению - все что старше 5 лет - ненужное устаревшее говно мамонта. А те, кто не знают появившуюся полгода назад технологию - отставшие от жизни ламеры.
Also, Эффект Даннинга—Крюгера тут работает в полную силу.

Резюмирую: трудно, если у тебя нет в резюме стапятисот сделанных проектов. И чем дальше - тем сложнее и труднее будет. Но тебе может повезти - если ты компетентный специалист в узкой области (даже если она 'legacy'). Или ты можешь найти синекуру - гос.организацию, в которой ты присоединишься к когорте таких же скинутых с паровоза прогресса "молодыми и амбициозными". Не переживай, через 20 лет скинут их. А ты останешься.

Вот только кушать хочется сейчас. Хотя бы просто хлебушка.

Проблема не техническая, а организационная и соответственно решить технически её полностью нельзя. Никакие хуки на гит репо и continuous integration не защитят на 100%. Если есть желающие нагадить в коде они умудрятся это сделать.
Решается организационно, либо ктото за ними подтирает и ему за это платят ..либо ктото заставляет их исправлять (про code review выше писали) ..воспитывать/обучать "серунов" (если работает) ..либо увольнять.