(с)

С точки зрения программиста среднемесячная зарплата в России составляет 44 тыс. руб. — ниже всяческих ожиданий богатства и успеха. Но откуда вообще берутся представления об успехе, финансовом достатке и о методах их достижения?

Как изменится ваша жизнь, если дать вам 10 тыс. руб.? А как насчет 1 млн руб.? Или 100 млн руб.? Ответ на этот вопрос не так прост, как кажется, и зависит от вашего возраста, семейного положения и текущих накоплений. Еще более важно, что изменения, которые произойдут с вашим поведением после того, как у вас появится такая сумма, могут многое рассказать о текущем финансовом положении.

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

Добрый день!
Не так давно пользователь olekl попросил нас рассказать о RAID 1 в Synology, а именно

— raid 1, отказ одного диска, процедура диагностики и горячей замены
— raid 1 из двух дисков разных производителей
— raid 1, отказ самого устройства, спасение данных с диска средствами ОС

Спрашивали? Отвечаем!
Итак, 2-х дисковые накопители все чаще востребованы в среде домашних пользователей и небольших компаний, где требуется небольшой объем хранения и обеспечение отказоустойчивости. В линейке продукции Synology представлено аж 7 (семь) 2-х дисковых NAS накопителей. Это модели:
DS214+ и RS214 сегмента smb
DS214 сегмента soho
DS214play,DS213air,DS213j и DS214se сегмента home.

Диагностика и горячая замена
Для диагностики неисправностей жестких дисков в Synology применяется 2 процедуры: проверка поверхности диска, запускаемая при создании нового массива и в дальнейшем по расписанию (по желанию пользователя) и получение данных S.M.A.R.T. в реальном времени. Использование этих процедур позволяет отследить и вовремя предупредить выход из строя одновременно двух дисков.

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

Речь пойдет о борьбе с надоедливыми брутфорсами и сканерами портов, которые всячески норовят получить доступ к серверу. В статье будет рассказано о технологии Port Knocking, позволяющей обезопасить доступ на сервер посредством скрытия портов.

Доброго времени суток, уважаемое сообщество!

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

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

Помните очаровательного котика, которые чихал в заставке советского мультфильма? Мы помним, и нашли его — вместе с ворохом другой рисованной фантастики. В детстве она пугала и обескураживала, поскольку поднимала серьезные, взрослые темы. Настала пора пересмотреть старые мультфильмы, чтобы узнать, о каком будущем мечтали в той стране.

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

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

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

У меня где-то 680 GB файлов, из них процентов 90 это фото и видео.

Круговорот файлов в моих хранилищах:

Тут примерная схема того как и где хранятся все мои файлы.

Итак, GitLab CI: что можно ещё рассказать о нём? На хабре уже есть статьи про установку, про настройку раннеров, про командное использование, про GitLab Flow. Пожалуй, не хватает описаний того, как используется GitLab CI в реальном проекте, где задействовано несколько команд. А в современном мире разработки ПО это действительно так: ведь есть (как минимум) разработчики, тестировщики, DevOps- и релиз-инженеры. С подобным разделением на команды мы работаем уже несколько лет. В этой статье я расскажу о том, как мы, используя и улучшая возможности GitLab CI, реализовали и применяем в production для коллектива из нескольких команд процессы непрерывной интеграции (CI) и отчасти доставки приложений (CD).

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

Чтобы не привязываться к какой-либо конкретной технологии, предположим, что ваше приложение является простым набором HTML-файлов, никакого выполнения кода на сервере, никакой компиляции JS assets. Деплоить будем на Amazon S3.

У автора нет цели дать рецепты для конкретной технологии в этой статье. Наоборот, примеры кода максимально примитивны, чтобы слишком на них не зацикливаться. Смысл в том чтобы вы посмотрели на фичи и принципы работы GitLab CI в действии, а потом применили их для вашей технологии.

Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

---

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза "Hello world." Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

В области разработки высоконагруженных многопоточных или распределенных приложений часто возникают дискуссии об асинхронном программировании. Сегодня мы подробно погрузимся в асинхронность и изучим, что это такое, когда она возникает, как влияет на код и язык программирования, которым мы пользуемся. Разберемся, зачем нужны Futures и Promises и затронем корутины и операционные системы. Это сделает компромиссы, возникающие во время разработки ПО, более явными.

В основе материала — расшифровка доклада Ивана Пузыревского, преподавателя школы анализа данных Яндекса.

В 2008 году мне удалось побывать в одной ИТ-компании. В каждом сотруднике считывалось какое-то нездоровое напряжение. Причина оказалась проста: мобильники — в ящик на входе в кабинет, за спиной — камера, 2 больших  дополнительных «смотрящих» камеры на кабинет и контролирующий софт с кейлогером. И да, это не та компания, которая разрабатывала СОРМ или системы жизнеобеспечения самолётов, а просто разработчик прикладного бизнес ПО, ныне поглощённый, раздавленный и больше не существующий (что кажется логичным). Если вы сейчас потянулись и думаете, что в вашем офисе с гамаками и M&M в вазочках такого точно нет, вы можете сильно ошибаться — просто за 11 лет контроль научился быть незаметным и корректным, без разборок за посещённые сайты и скачанные фильмы.

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

В начале карьеры разработчика часто бывает страшновато: перед тобой встают незнакомые проблемы, многому нужно научиться и приходится принимать сложные решения. И в некоторых случаях мы в этих решениях ошибаемся. Это вполне естественно, и грызть себя по этому поводу не стоит. А вот что стоит делать, так это запоминать свой опыт на будущее. Я — разработчик-сениор, который допустил в свое время уйму ошибок. Ниже я расскажу о восьми самых серьезных из них, которые совершил, когда был еще новичком в разработке, и поясню, как их можно было избежать.

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

Не знаю почему, но вам понравилась история про одного парня. Если помните, он ушел.

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

Я, как вы поняли, с ним знаком. И не просто знаком – мы вместе учились на приборостроительном факультете. На носу День Радио, и он прилетел обратно в нашу дыру на встречу выпускников. Позвал меня выпить пива, и рассказал мне одну историю. Про одну девушку.

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

[В квадратных скобках — мои примечания.]

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

Я постоянно пытаюсь найти какие-то альтернативы RAID'ам в плане объединения нескольких жестких дисков в единый массив. Пробовал много что, но ни на чем так и не остановился окончательно. RAID не нравится тем, что штука достаточно капризная, негибкая и требовательная до дискового пространства.



Что мне вообще хочется:

1. Объединить диски с данными в один массив большого объема, чтобы не приходилось вручную сортировать файлы — что возникает при нескольких дисках (пусть даже при монтировании их в папки).
2. Иметь возможность добавлять/удалять/заменять диски в любой момент без развала массива.
3. Независимость информации на дисках друг от друга — чтобы смерть одного из них не приводила к недоступности остальных.
4. В идеале — какой-то метод хранения одного файла на нескольких дисках. Бэкапы — это хорошо и я их делаю, но лучше, когда к их помощи не приходится прибегать.

Разбираемся с технологиями роуминга (Handover, Band steering, IEEE 802.11k, r, v) и проводим пару наглядных экспериментов, демонстрирующих их работу на практике.

Ранее считалось, что после остановки сердца или прекращении активности мозга по другим причинам, без кислорода и электрической активности клетки мозга начинают умирать через несколько минут, и процесс этот необратим. В связи с этим врачи объявляли, что пациент — brain-dead, что являлось законным основанием для признания смерти.

Исследование, проведённое учеными Йельского Университета в Нью Хэйвене — Zvonimir Vrselja, Stefano G. Daniele с соавторами — показало, что это совсем не так.

Специалисты и ранее ставили под сомнение прежний подход, поскольку:

• исследования на кошках и обезьянах показали, что активность мозга можно полностью восстановить даже через несколько часов после полного прекращения поступления кислорода: science.sciencemag.org/content/168/3929/375, www.sciencedirect.com/science/article/pii/0006899374904788;

Нас все чаще спрашивают про разработку микросервисов в Kubernetes. Разработчики, особенно интерпретируемых языков, хотят быстро поправить код в любимой IDE и без ожидания сборки/деплоя увидеть результат — по простому нажатию на F5. И когда речь шла про монолитное приложение, достаточно было локально поднять базу данных и веб-сервер (в Docker, VirtualBox…), после чего — сразу же наслаждаться разработкой. С распиливанием монолитов на микросервисы и приходом Kubernetes, с появлением зависимостей друг от друга, всё стало немного сложнее. Чем больше этих микросервисов, тем больше проблем. Чтобы вновь насладиться разработкой, нужно поднять уже не один и не два Docker-контейнера, а иногда — даже не один десяток… В общем, на всё это может уходить достаточно много времени, поскольку требуется ещё и поддерживать в актуальном состоянии.