Уже которую неделю один многоуважаемый ИТ-ресурс не отпускают бурления по поводу найма в ИТ. Хотя нет, правильно — «уже который год». Среди участников этих крайне бурных обсуждений есть два устойчивых лагеря, которые всё никак не найдут взаимопонимания.

Честно скажу — не знаю, как в других отраслях складывается ситуация, хотя, по слухам, много где есть нарекания. Но вот почему специалисты в ИТ, умные люди, всё никак не могут договориться?

Часть 1. Строительство
Часть 2. Отопление
Часть 3. Электроснабжение
Часть 4. Комфорт дома и гаджеты.

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

Когда вопрос собственного жилья у меня стал основательным, а съем квартиры стал нерентабельным, я пришел, как и многие, к выбору: во что вкладываться — в дом или в квартиру?
Стоимость квартир даже в Подмосковье за пару комнат начинается от трех миллионов. Без отделки и со всеми сопутствующими проблемами. Посчитав, я пришел к выводу, что за те же деньги можно построить дом в Подмосковье с такой же транспортной доступностью и близкой инфраструктурой.
Для ленивых я расскажу все в ролике, а для любителей букв я подготовил текст с картинками.

Недавно я делал очередную замену батареек в своих ИБП. Я решил поглубже изучить вопрос правильного использования свинцовых АКБ, их устройство и химию процесса.

Цена батарей растет из-за курса и покупать их становится накладно.

Можно ли сделать так, чтобы батарейки служили дольше? Как получить от них максимальную отдачу, чтобы оборудование работало дольше и отключения электричества меня совсем не беспокоили?

Хочу поделиться опытом. Кому интересно, прошу под кат…

Изображение с сайта oxygen-icons.org

Задача

Передавать лог-файлы на центральный сервер:

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

Условия: в инфраструктуре используются только Linux-сервера.

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

Существует два основных пути становления топ-менеджмента в IT-компаниях:

1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

Второй путь является более долгим и не гарантирует успеха, так как является противоречащим сути интроверта-программиста. Однако, на этом пути я бы хотел заострить внимание и поделиться опытом и знаниями.

Джулия Эванс, автор материала, перевод которого мы сегодня публикуем, решила рассказать об одном из своих любимых сетевых инструментов, который называется Wireshark. Это — мощная и сложная программа, оснащённая графическим интерфейсом, предназначенная для анализа трафика в компьютерных сетях. Джулия говорит, что на практике пользуется лишь немногими возможностями Wireshark, но они обычно оказываются очень кстати. Здесь она хочет поделиться со всеми желающими рассказом о самых полезных приёмах работы с программой и надеется, что они пригодятся не только ей, но и всем, кому приходится решать сетевые проблемы.

Дачная электрика – известная проблема, отношение к ней в большинстве случаев наплевательское, если не сказать хуже. Если есть возможность подключить что-то не так и не туда — это, конечно, будет сделано.

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

В продолжение Части 1 — Colocation

Следующая часть — Переезд

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

Итак, прошлую часть мы закончили на моменте с поиском нового помещения для «строительства» собственного ЦОДа. Как мы уже писали это было жизненно необходимо для нашего молодого проекта, который испытывал трудности в моменты серьезных проблем в дата-центре. Покажу несколько кадров здания ЦОДа. При этом хочу сказать что с владельцами мы работаем до сих пор в других направлениях и расстались хорошими друзьями. Сейчас (по слухам от коллег которые там размещаются) — все отлично.

Внимание! Много изображений. Есть не сжатые фото панорам, ибо при их сжатии — очень сильно теряется качество.

В продолжение Части 1 — Colocation
В продолжение Части 2 — Гермозона

Здравствуйте! Судя по отзывам, письмам и комментариям к прошлым двум частям нашей статьи — Вам понравилось, а это главное. Напоминаю, постройкой собственного мини-ЦОДа мы обязаны именно «жителям» Хабра, именно Вы помогли нам с реализацией наших идей — своими статьями. Поэтому данный цикл статей благодарность пользователям и комментаторам, из идей которых мы и «черпали» вдохновение.

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

О системе

Разработчик — Edgewall
Лицензия — BSD
На чем написана — Python
Среда обитания — Там где обитает Python, а значит почти везде

Добрый день, хаброчитатели.

Снова хочу поделиться с вами небольшими практическими наработками.
Совсем недавно в рамках одного проекта мне была поставлена задача подготовить для команды тестеров стандартное окружение для сборки и тестирования приложения (Jenkins + SVN + Maven).

На тему систем централизованного управления конфигурациями на Хабре написано немало статей и, в частности, про Chef есть несколько хороших статей. Однако, количество релизов Chef растет, и я решил немного освежить его описание для читателей Хабра. Статья предназначена как для новичков, так и для тех, кто уже знакомился с системой, но по какой-то причине отложил изучение и хочет все-таки продолжить. А продолжать стоит! Поскольку, Chef полезен и для администрирования нескольких VPS, и для управления большим парком серверов. Особенно, если вам часто приходится заниматься настройкой серверов с нуля, подключением дополнительных нод в кластер и т.д.

Каждый день системный администратор сталкивается с задачами, которые так или иначе приходится решать банальным набором команд. Порою доходит до смешного:

• распространить файл на 100 серверах
• распространить пакет на 100 серверах
• изменить строку в файле
• обновить систему
• добавить пользователя
• перезапустить сервисы

и т.д., администратор инфраструктуры делает руками, поочерёдно заходя на все сервера и выполняя набор из 1-10 команд. Продолжая так работать, вскоре, системный администратор крупной системы превращается в «эникейщика серверной».
И есть два пути решения данной проблемы: нанять младшего сотрудника и «сгрузить» на него всю грязную работу, либо автоматизировать простые и не очень задачи.

На данный момент существует множество систем, которые позволяют это сделать, но наиболее популярные это Chef, Puppet и Ansible.
В данной публикации речь пойдёт о Chef и как при помощи него автоматизировать повседневные задачи на множестве серверов.

Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.

Концепция infrastructure as code позволяет нам применять к инфраструктуре решения из мира разработки. Отдельные компоненты инфраструктуры в проектах часто повторяются. При интеграции таких компонентов наиболее удобный вариант – общие кукбуки. Код кукбуков постоянно меняется, фиксятся баги, появляется новый функционал. С помощью тестирования мы отслеживаем регрессии, контролируем обратную совместимость и внедряем новые фичи быстрее.
В этой статье мы познакомимся с инструментами для тестирования, напишем простой кукбук и тест к нему.

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов

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

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

В этот момент средства управления конфигурациями и вступают в игру. Во многих случаях, мы управляем группами одинаковых серверов, на которых запущены одинаковые приложения и сервисы. Они размещаются на системах виртуализации внутри организации, или же запускаются как «облачные» и гостевые в удаленных ЦОД. В некоторых случаях, мы можем говорить о большом количестве оборудования, которое существует только для поддержки очень больших приложений или об оборудовании, обслуживающем мириады небольших сервисов. В любом случае, возможность «взмахнуть волшебной палочкой» и заставить их всех выполнить волю системного администратора не может быть обесценена. Это единственный путь управлять огромными и растущими инфраструктурами.

Puppet, Chef, Ansible и Salt были задуманы чтобы упростить настройку и обслуживание десятков, сотен и джае тысяч серверов. Это не значит, что маленькие компании не получат выгоды от этих инструментов, так как автоматизация обычно делает жизнь проще в инфраструктуре любого размера.
Я пристально взглянул на каждый из этих четырех инструментов, исследовал их дизайн и функциональность, и убежден, что несмотря на то, что некоторые оценены выше, чем другие, для каждого есть свое место, в зависимости от целей внедрения. Здесь я подвожу итоги моих находок.

The best way to learn Chef is to use Chef
— getchef.com

Chef — это инструмент для конфигурирования серверов в концепции Infrastructure as a Code(IaaC).
Лично для меня, Chef — это, в первую очередь, возможность хранить архитектуру сервиса в виде ролей, и модифицировать её, избегая рутинных действий по установке пакетов и конфигурации.

Копаясь в своих старых записях совершенно случайно наткнулся на документ JBOSS 4.2.3 Manual, написанный мной (а по сути скомпилированный из разных источников) несколько лет назад. И чтобы не пропадать добру, решил немного поделиться знаниями с уважаемым Хабрасообществом.
Если вы являетесь специалистом с опытом более года — скорее всего ничего нового для себя не найдете и можете сразу проходить мимо, дабы не тратить свое время. Статья же может быть полезна следующим людям:

• студентам, начинающим свой путь в IT карьере по Java направлению
• java junior разработчикам
• junior инженерам внедрения и техподдержки
• junior deploy и build инжеренам

Понятно, что версия JBoss 4.2.3 достаточно древняя (сейчас актуален 8-ой JBoss, который по сути уже и не «Jboss»), но считаю, что она все еще может быть полезна, учитывая наличие большого количества старого унаследованного java-кода и приложений в жестоком интерпрайз секторе, которые все же необходимо иногда поддерживать.

Кто-то в детстве мечтает изобрести лекарство от рака, кто-то — стать космонавтом или владельцем свечного заводика. А я мечтал о том, что у меня появится климатическая система, и в квартире, наконец, не будет душно, вечная простуда от сквозняков исчезнет, а горло перестанет першить от сухости. И теперь мечта исполнена!

Примерно с декабря 2015 по июнь 2016 года я читал форумы, катался по строительным магазинам, собирал систему в квартире и на балконе, паял контроллер и писал прошивку — и добился своего.

В этой статье я собираюсь похвастаться результатом и рассказать, как устроена моя установка. Полностью описать процесс сборки в одной статье невозможно, но, надеюсь, краткое описание окажется интересным для тех, кто хочет дышать свежим тёплым воздухом. Если кратко, то моя установка устроена так: