В интернете можно найти множество статей касающихся преимущественно программистов и их опыта переезда в Германию, но практически нет таковых про системных администраторов. При этом работа системного администратора (и поиск её) обладают своей спецификой, к тому же я за последние полгода смог наступить на целый ряд граблей, о которых тоже полезно было бы знать заранее. Собственно, об этом я и хотел бы рассказать в данной статье.

Прошу прощения, что публикую в не совсем профильный «Государство и IT», потому что более подходящего хаба на данный момент нет, а при попытке опубликовать в песочницу на GeekTimes, попросили опубликовать здесь.

Предлагаю читателям «Мегамозга» перевод заметки «21 Ways to Minimize Employee Retention» из блога Jon Haddad. Это мой первый перевод, заметка понравилась и захотелось поделиться.

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

1. Устранить любую приватность. Сотрудники должны чувствовать, что за ними все время следят. В идеале использовать открытую планировку, которая поможет максимизировать отвлекающие факторы. Если открытая планировка не доступна, набейте людьми небольшие помещения насколько это вообще возможно. В любое время, сотрудники должны быть в состоянии чувствовать запах дыхания каждого человека в комнате.

Примечание переводчика: Некоторое время назад я прочитал замечательную статью на Medium.com. Автор статьи Samuel Thomas Davies взял за основу исследования профессора Стэнфордского университета Би Джей Фогга об изменении поведения. Сегодня я хочу поделиться ее переводом с хабрасообществом.

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

Очевидно, что делать это намного сложнее, когда вы совершаете ошибки, которые достаточно банальны, но при этом часто недооценены или просто-напросто проигнорированы ввиду их неприметности.

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

Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

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

Перевод книги Marijn Haverbeke "Eloquent JavaScript". Лицензия Creative
Commons attribution-noncommercial license. Код предоставляется под лицензией MIT.

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Революционные технологии всегда являются загадкой: взлетит — не взлетит, перейдут — не перейдут, будет у всех или забудут через полгода… Одни и те же вопросы мы повторяем себе каждый раз при встрече с чем-то действительно новым, но одно дело, если мы говорим о очередной соцсети или тренде на вид интерфейса и совсем другое, если дело касается промышленного стандарта.

OpenFlow, как составляющая часть концепции SDN в виде протокола управления между соответствующими контроллерами и коммутаторами, появился по мерками компьютерной индустрии уже сравнительно давно — 31 декабря первая версия стандарта отметит свое пятилетие. Что же в итоге мы получили? Давайте смотреть и разбираться, тем более, что история весьма интересная.

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

Вы наверняка знаете или представляете, что управление большой инфраструктурой с помощью Puppet — непростая задача. Если для десяти серверов Паппет не нужен, для пятидесяти в самый раз и код можно писать как угодно, то когда речь идет о 500+ серверов, то в этом случае приходится уже серьезно думать об оптимизации своих усилий. Плохо, что Паппет изначально, видимо, не задумывался, как решение для больших инфраструктур, по крайней мере иерархия в него изначально заложена из рук вон плохо. Стандартные node definitions совершенно неприменимы в больших компаниях. Node inheritance (также как и class inheritance) Puppetlabs не рекомендуют больше использовать вообще, вместо этого лучше загружать данные о иерархии из внешних источников, таких как Hiera и External Node Classifier (ENC).

Иногда случается так что необходимо перенести клиент-банк или другое разнообразное бухгалтерское и не очень ПО с одного компьютера на другой. В том случае когда в качестве криптопровайдера выступает СКЗИ Крипто-ПРО обычно проблем не возникает — СКЗИ имеет штатные средства копирования ключей. Но не всегда все гладко — в том случае, когда ключевой контейнер находится в реестре Windows, и при генерации ключа не была выставлена галочка «Пометить ключ как экспортируемый» то при попытке скопировать куда-либо этот ключ Крипто-ПРО будет ругаться и не скопирует ключ.
Из этой ситуации есть очень простой выход — выгружаем ветку реестра HKLM\SOFTWARE\CryptoPro\Settings\Users\{SID}\Keys\(в x64 операционках контейнеры лежат в HKLM\SOFTWARE\Wow6432Node\CryptoPro\Settings\Users\{SID}\Keys\), а на том ПК куда необходимо импортировать смотрим разрядность ОС\SID пользователя, блокнотом правим .reg файл(меняем SID и, если необходимо, путь к конечной ветке), и импортируем его в реестр.

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

На написание этого поста меня сподвиг замечательный пост «За что конкретно я ненавижу некоторых отдельно взятых маркетологов — или как айтишник по магазинам ходил». Сразу хочу извиниться за возможные опечатки — пишу с планшета, сидя в микроавтобусе и вытягивая сеть телефоном. Hacker's keyboard очень удобен для ssh-доступа, но большие тексты писать им не очень удобно.

IT- специалисты — народ любопытный. То соберут на базе микроконтроллеров автоматическую систему полива и освещения для любимого фикуса, то пропатчат прошивку мультиварки для раздачи торрентов. Но, по непонятной и загадочной причине, когда дело доходит до еды, пресловутый принцип DIY дает сбой. И наш герой, способный часами переделывать кинескоп старого телевизора в Луч Смерти, идет на кухню утолить голод соевым текстуратом пополам с гидроцеллюлозой и «коллагеновым сырьем».

В этом посте я хочу разрушить миф о том, что еда может быть либо быстрой и удобной, либо съедобной. Не секрет, что многим из нас приходится работать по 12 часов в сутки, что не способствует кулинарным подвигам с участием 28 приправ и перьев с зада дракона, омытых слезами единорога. Вы получите замечательную возможность посмотреть в глаза своей половинки на 8 марта после того, как она получит не контроллер для дистанционного управления шторой, а свежевыпеченный хлеб ручной работы рано утром. Если вам надоело есть синтетику — добро пожаловать под hubracut.

Предисловие к FAQ.

Программирование является моим хобби уже давно (правда на других языках и платформах), но до андроида руки дотянулись совсем недавно. Прошло несколько этапов, прежде чем я добрался до написания программ.
Сначала была пара месяцев посвященных Java, на сайте с «Сгибателем».
После, долгие попытки подружится с Eclipse, закончившиеся побегом на Android Studio.
На данный момент выпущено 7 программ и две находятся в разработке.
Данная подборка возникла как попытка структурирования и оптимизации полученной в процессе информации.
Заранее извиняюсь за возможно некорректную терминологию – так как практикую обучение через создание, и в теоретической части есть пробелы.

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

Пользуясь регулярно подходом ABC of ICT обнаружил что информации об этом крайне мало (сам познакомился благодаря ссылке где-то в комментариях). Под руки попалась неплохая статья по методике и решил ее перевести, возможно кто-то после захочет ближе познакомиться с этим подходом к развитию и управлению процессами в компаниях.



Оригинал опубликован на сайте GamingWorks (создатели наиболее популярных бизнес-симуляций для IT всего мира)

Много текста

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

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

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

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

Вам снова календарик!

В карман (100×70мм):
pdf, eps, svg или png (1185×831, 300dpi)

На стенку (A4):
pdf, eps, svg или png (3512×2484, 300dpi)

Сделай сам:
Генератор календариков (Python, GPL)

С Новым Годом!

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

Ролик снимался год назад для информационного сайта. В роли «жертвы» — мой друг, имеющий дело с компьютерным железом каждый день и знающий реальные расценки на подобные услуги.

Привет всем!

Данный пост посвящен длительной поездке для работы на Бали. Из него Вы узнаете о том, за сколько, как и когда можно и удобно находится с максимальным комфортом за человекоподобный прайс в месте, где работа через интернет никак не омрачается смогом от пожаров, аномальными перепадами температуры, звуками заведенного трактора и другими правовыми катаклизмами.

Наверное, многие из вас, как и я, были «приятно» удивлены официальной рекомендуемой ценой (RRP) HTC Desire в России. 25990 руб — немаленькая сумма для телефона на базе молодой, развивающейся свободной ОС.

Рекомендуемая цена на Nexus One подсказывала, что и HTC Desire должен был стоить на порядок меньше. Беглый осмотр иностранных интернет-магазинов показал, что цена на HTC Desire колеблется в районе 18-20К у таких монстров, как Amazon.de, и 16-17К в онлайн e-Tailer'ах. Вот уж поистине — привет российские налоги и жадность локальных ритейлеров…

Поразмыслив о гарантии и итоговой сумме телефона, я решилась на покупку.

Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard

«Даже если вы получите какое-нибудь письмо, вы не сможете его прочитать»
(Марк Твен)

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

Итак, ваш проект набирает популярность и нравится пользователям, вы собираетесь оставаться с ними на связи. Вы ознакомились с административными требованиями (о которых мы писали ранее) и собираетесь ответственно и без спама организовать рассылку для тех пользователей, которые готовы ее получать. А может быть, вы просто собираетесь настроить корпоративную почту. Поднимаете из дистрибутива почтовый сервер, пишете скрипт, запускаете и… 70% получателей письмо не доставлено, у 15% оно попало в папку «Спам», а остальные не могут прочитать то, что в нем написано. О том, что делать, чтобы этого не случилось, я попробую рассказать в этой статье.

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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