O Di

munin или скриптами запускать проверку и отправлять ответ (для одного сервера)
Зббикс это реально пушка :)

К примеру это умеет zabbix, но это unix-way и для одного сервера — это из пушки по тараканам.

Не знаю, как для hg, а для гита — GitLab — очень даже хорош.

Я бы посоветовал пройти курсы на www.codecademy.com/
Стоит пройти HTML, CSS, JS, Jquery, Projects, Php.
После этого картина станет вполне целостной и уже можно будет браться за реальные задания.
И не нужно зацикливаться на тонкостях HTML или JS, это даже вредно. Главное — понимать общую суть и уметь пользоваться справочниками, а остальное приобретается с опытом.

как-то Вы заморочились на спецификации HTML — всё гораздо проще :)
Рекомендую попробовать связку PHP-fpm + PostgreSQL + Redis + Nginx + AngularJS + Twitter Bootstrap.
Ещё можно написать чат какой-нибудь, там слово «PostgreSQL» заменяете на NodeJS в этом уравнении и всё :)
Наверняка в комментариях высыпят фанаты модных трендов вроде рельс — я не против рельс, не против питона, но я не могу рекомендовать вещи, в которых сам не опытен :)

Решате вопросы по мере необходимости. Сейчас читать и учить всё подрят бесполезно, так как теория без практики лишь добавит каши в голове. Да и в современном вебе лучше знать обёртки, чем низкоуровневые апи, jQuery вместо javascript, RoR вместо понимания http и ruby, ROR active record вместо SQL-MySQL-NoSql. Главное знать обёртки и уметь копаться в гугле в случае проблем.

p.s. Прямо сейчас завершаю проект. который делался на незнакомых angularjs, nodejs + express, mongodb (работал раньше). Так что освет опробовал на себе, до сих пор все доки на технологиям не освоил, зато проект делается без проблем и освоил кучу недокументированных возможностей и косяков, а опыт с работой с mongodb в php мне только мешал.

Вообще, не увлекайтесь спецификациями. Марк Цукерберг как-то без них обошелся. Google тоже не следует строгим стандартам.

Если вы хотите «эффективно» изучить матеиал, тогда вы должны читать статьи «для чайников» (которые вы с вашим опытом, наверняка освоите за кратчайшее время). HTML/CSS так устроены, что даже если вы сделаете 100 ошибок на странице, он все равно как-нибудь да отобразится. Ну если вы хотите более солидные знания, то параллельно смотрите непонятные моменты в спецификациях, это в общем-то полезно. А сэкономленное время посвятите практике. Она тут очень важна.

Вот, что стоит изучить (в любом порядке):

1) Начните с основ HTTP (только ради бога, не читайте спецификацию целиком, хватит общего представления о методах запросов, заголовках и теле запроса, кодах ответа 403/404/500/200/300)
2) Изучите основы HTML (есть раздел на сайте htmlbook). SGML вам хватит в том объеме, в котором он упоминается в спецификации HTML. PCDATA не упоминается в ней и потому знать про отличия от CDATA вам не нужно (ну если так хотите узнать, найдите спецификацию SGML и почитайте).

Обратите внимание, в некоторых (некачественных) статьях вы можете увидеть штуки вроде [br /] — самозакрывающиеся теги. Это ошибочный синтаксис, который употребляют авторы, путающие HTML и XHTML. В HTML такого синтаксиса нет (хотя в силу своей толерантности к ошибкам в HTML такой код как-то работает).

3) Изучите CSS и позиционирование элементов. Вот хороший учебник, разъясняющий тонкости всяких флоатов: softwaremaniacs.org/blog/category/primer/ А спецификацию CSS2.1, думаю, вы нагуглите сами, она довольно понятно написана.

4) Изучите яваскрипт (да, включая замыкания и прототипы) и DOM. Обратите внимание, jQuery — лишь обертка над DOM и не зная DOM, вы не сможете нормально пользоваться jQuery, вы лишь научитесь копипастить скрипты из интернета, не понимая, как они работают. После этого можете изучать jQuery, заодно советую заглянуть в исходный код, а не только читать документацию.

5) Изучите один из серверных языков, хотя бы основы

6) Изучите основы SQL

7) Начинайте что-нибудь делать, так как в этот момент у вас будет очень много теоретических знаний и очень мало практических. Можете сделать простое веб-приложение, можете улучшить какое-нибудь существующее.

8) Изучите ООП

9) Изучите какой-нибудь серверный MVC-фреймворк

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

> А есть ещё и XHTML, который тоже имеет свои отличия…

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

> Клиентская разработка нынче редко обходится без всяких шаблонизаторов типа HAML/SASS

Вы еще Coffescript забыли упомянуть. Это очень спорные вещи, есть мнения как за, так и против. Но в любом случае, согласитесь, как-то странно изучать SASS, не изучив вначале CSS, верно? Начинающему это не нужно.

> а для эффективной серверной разработки всё и того сложнее: фреймворки, ORM, continuous integration, очереди задач и прочая-прочая.

Для приложения из 3 страниц все это не нужно. Сложные технологии нужны в больших и огромных проектах, начинать можно и без них. И более того, не имея определенного опыта работы с кодом, вы вряд ли поймете, зачем это нужно. А когда понадобятся, тогда и изучите.

По вопросу, где брать информацию: авторитетные источники (для поиска ответа во всех подробностях) — это спецификации W3C, официальная документация фреймворков, неофициальные источники вроде htmlbook, stackoverflow или Хабра — для того, чтобы быстро получить представление о тех или иных возможностях HTML. Еще можете какую-нибудь книгу почитать, только не старую.

git clone <repo>
git checkout <branch>
sudo ./install.sh

Как-то так. Зачем заморачиваться с deb пакетами и прочим? Напишите один скрипт, заведите git репозиторий.

В свое время мне сильно помогла данная статейка и еще несколько с этого сайта.

Худшее что может сделать хороший программист — это стать посредственным менеджером

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

Я знаю людей которые из программистов становились директорами. А кто-то может из программиста становился садовником.

Не существует одной «ветки развития» как в играх. Есть просто более популярные направления и менее. Кто-то может из программиста стать менеджером, кто-то техническим менеджером, кто-то архитектором, кто-то может тестировщиком, кто-то начальником отдела, кто-то открывает свою фирму, кто-то становится программистом на другом языке или в другой области, кто-то просто уходит делать тоже самое ну лучше (опыт же накопился) и за большую зарплату.

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

Вот моя короткая история. в основном я пишу на php.

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

и вот недавно я делал тоже портал на рельсах, но намного больше по функционалу. новости, афиши, поиск по предприятиям, вобщем тоже много разного функционала. Ребята, это превый проект который я сдал в срок, причем весь код покрыт тестами,!
было круто. причем, руби я знал базово и много узнал по ходу разработки.

Пишите то на чем удобно и что чаще всего используете (язык в том числе). Имел прекрасную возможность реализовать проект на джанге и на рельсах. Проект с большим развесистым API изначально был на джанге, потом я с горящими глазами за пару дней реализовал его на рельсах, я был в восторге от того что все есть из коробки, программирования на основе соглашений, REST full api описывается тут же в контроллере, куча батареек на все случаи жизни, слежение за зависимостями. Мне казалось дикостью что core девелоперы джанги отказывались ломать совместимость в пользу ускорения введения новых фич. Плюс руби на котором все делали кучу удобных DSL-ей на все случай жизни. Но через большое время жизни проекта я понял что мне очень не хватает опыта с рельсами, а еще больше с руби, мой основной язык работы питон + огромная волна задач на js (полноценные веб приложения с большой логикой), и когда вновь возникали задачи на проект с рельсами я чувствовал дискомфорт от того что простые задачи требовали кучу времени. Затем вновь была джанга, она уже казалась такой родной, я знаю почти все её уголки, и с большей уверенностью смогу решить на ней любые поставленные задачи. У джанги нет того многообразия батареек и фишек из коробки, поэтому стоит немного уделить внимание поиску решений задачи прежде чем писать код. Управление статикой, миграций, деплой, все решается батарейками, не хуже чем на рельсах. Когда я стал замечать рутинные задачи которые решались на рельсах, я старался находить пути решения, обычно на это уходит 5 минут поиска или кодинга (большая часть решается фабриком).
А в настоящее время набирает просто гигантскую популярность nodejs у которой просто гигантское количество батареек аналогов которых нет не у кого.
Я это все к тому что надо выбирать инструмент с головой, тот что более знаком, желательно написанном на основном для себя языке. Но если есть возможность то пробовать все то что приносит радость, я очень благодарен моему начальству которое дало мне эту возможность.

Я начинал с Django, но однажды наткнулся на рельсы и этот туториал , и влюбился в них.

Почему Rails?

— Быстрая разработка. В Rails это поставлено на первое место, и вместе с тем, рельсы неплохо масштабируются.
— Экосистема. Для рельсов целая туча гемов на все случаи жизни. Devise, Gon, Mongoid, Rails_best_practices…
— Тестирование. Просто попробуйте такие гемы как RSpec, Cucumber, Capybara.
— Язык. После более простого питона, я немного побаивался языка с кучей спецсимволов, как оказалось, зря :) Хорошо написанный код читается как текст на английском, в особенности при использовании DSL.

Перешел с Python (Flask, Bottle) на Ruby (Sinatra, Rails). Не жалею. В плане web-разработки, ИМХО, Ruby экосистема развита лучше.

Для начала я считаю, что программистом может быть не каждый, если у вас это получается, считайте, что это отличная возможность для карьеры.

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

Есть программист, который работает в институте за 5 тыс в месяц, что-то исследуют и ходит счастливый. Его потребности полностью удовлетворены, он работает с отдачей и улыбается. Это я про реального человека, пример не абстрактный.

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

Автору я хочу посоветовать понять для себя, сделать чистосердечное признание, что бы он делал если бы у него уже были миллионы. Когда ответ будет, это первый шаг. Дальше надо определиться с суммой, которая закроет текущие потребности. Дальше смотрим на нашу цель, на уровень зарплаты и начинаем думать и неистово стремиться.

Этот подход выглядит очень «по-западному», что с того? Можно работать над проектами, которые меняют жизнь к лучшему и при этом зарабатывать хорошие деньги, только придется попотеть пока такое сочетание найдешь.

Это связанно с генерацией имен и Rails соглашении об именах. Модель он создает с именем в единичном, числе, а вот таблицу во множественном. Т.к. некоторые слова в английском языке во множественном числе звучат по-другому, у Rails есть на этот счет словарь, в котором как раз описаны подобные связки. People как раз в него входит. Там есть еще другие, так что это нормально

Регулярные апдейты, ssh c доверенных IP-адресов, авторизация по ключам и сложные пароли.