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

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

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

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

Я эксперт в области того, как в технологиях используются слабые места нашей психики. Вот почему я проработал последние три года как специалист Google по этике в дизайне. Моя работа состояла в проектировании ПО таким образом, чтобы защитить умы миллиарда людей от «уловок».

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

Как технология эксплуатирует слабые места нашего разума?

Я научился так думать, когда был фокусником. Фокусники всегда начинают с поиска слепых пятен, краев, уязвимостей и пределов восприятия, так что они способны влиять на поведение людей, а последние даже не осознают этого. После того, как вы узнаете, как правильно нажимать на эти людские «кнопки», вы можете начать играть на них, будто на фортепиано.


Это я, творящий «волшебство» при помощи ловкости рук, на дне рождения моей матери

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

И я хочу показать вам, как они это делают.

Автор: Вячеслав Михайлов

Монолитные приложения и их проблемы

Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:

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

Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:

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

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

Термин «О-большое», знакомый нам из курса матанализа, был введён Паулем Бахманом в конце XIX века для описания асимптотического поведения функций. В конце 1970-х Дональд Кнут придумал применять этот термин для оценки эффективности и ресурсоёмкости алгоритмов, благодаря чему с «О-большим» знакомо большинство программистов. Понимание асимптотики быстродействия и ресурсоёмкости даёт возможность выбрать наиболее подходящий метод решения задачи в зависимости от текущих потребностей. «Плохая» асимптотика позволяет сразу же отбросить неподходящий метод.



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

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

12 мая мы с товарищами зашли в московское метро с его открытием утром и, не выбираясь наверх, посетили все 199 доступных в данный момент станций до закрытия метрополитена. Зачем мы всё это сделали – совершенно не ясно, но я попробую рассказать, как так получилось.

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

По мере изучения вопроса я обнаружил, что идея сама по себе не то чтобы очень нова – в нью-йоркской подземке аналогичные соревнования проходят с 1966 года. Что же касается московского метро, то ЖЖ-пользователь estrella-de-sur полгода назад проехал его за 12 часов 36 минут (расчётное время – 11 часов 50 минут) по правилу «один шаг на каждую станцию». Но у нас была другая задача – мы хотели выйти на каждой станции и по возможности красиво её сфотографировать. Это означало, что нам в большинстве случаев придётся ждать на ней следующего поезда. Исходя из этого я и строил расчёт.

Предупреждение: если вы умеете решать задачу коммивояжёра на 200 узлах (с помощью генетических алгоритмов или без них) – вас, скорее всего, ждут в другом месте. Можете просто пролистать пост и посмотреть картинки.

Адам Мадьяр — компьютерный гик, бросивший университет, фотограф-самоучка, Руб Голдберг высоких технологий, путешественник по миру и художник-концептуалист с растущим мировым признанием. Но никто не мог предположить, что он может быть еще и террористом, до того утра, пока он не спустился на станцию метро Юнион-Сквер в Нью-Йорке.

В то время Мадьяр был погружен в долговременный проект на стыке технологий и искусства под названием Stainless («Безупречные»), создавая изображения высокого разрешения из проезжающих поездов и пассажиров, используя сложное, написанное им самим программное обеспечение и доработанную промышленную фотокамеру. Техника сканирования, которую он разработал — объединение тысяч кадров шириной в пиксель в одно изображение — позволяет ему заставать пассажиров врасплох, пока они с шумом и лязгом летят сквозь темные тоннели метро, фиксируя их в призрачных изображениях, наполненных деталями, которые не может запечатлеть ни одна обычная камера.

В этой статье я расскажу как я решил проблему настройки окружения для разработки на Django под Windows.
Используется следующая связка:
1) Docker-machine
2) PyCharm
В Docker-machine:
1) PostgreSQL
2) Data container для PostgreSQL
3) Redis
4) И собственно само приложение на Django.

Сегодня неизвестные хакеры выложили в сеть данные о жителях целой страны — 49,6 миллиона турецких граждан были полностью раскрыты. Данные включают национальный идентификатор, имя, фамилию, имя матери и отца, пол, дату и город рождения, а также адрес места жительства.

Ссылка на слив появилась на форуме Hacker News сегодня, 4 апреля. По словам авторов топика, проблема Турции — в слабой защищённости технической инфраструктуры, из-за которой архив (база данных объёмом 6,6 ГБ) стал доступен публично.

Их давали нам, чтобы не мешали старшим чтобы котелок и мелкая моторика шли рука об руку. Но фишка конструкторов не только в этом.

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



Для начала, что называть конструктором? Например, пирамидки, паззлы, сортеры (когда детальке надо найти формочку), матрешки — это не конструкторы. Они называются «дидактическими игрушками» и учат работать по шаблону. Это, конечно, полезно и важно, но как тренировка. Поэтому иногда так хочется дать по рукам подтолкнуть ребенка, чтобы «закончили упражнение».

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

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

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

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

Однако, где-то полтора года назад, все изменилось. Как только я избавился от постоянных, изнуряющих головных болей, я с интересом погрузился в изучение йоги, медитаций и восточных философий. На самом деле, мне всегда были интересны различные подходы в познании мира и самого себя, так что, принимая во внимание тот факт, что я вырос в крайне религиозной семье, я проводил много времени за чтением таких авторов как Кен Уилбор, Рэм Дэс, Теренс Маккена и Алекс Грей. Естественным образом я ассимилировал их идеи в своем собственном мировоззрении, которое, кстати говоря, на тот момент мне казалось вполне нормальным и не сулящим никаких опасностей.



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

А я был болен.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

Приветствую, хабраюзеры.

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

Канада

1. Что последнее вы искали в Гугле?
2. Какой герой «Игр престолов» вам нравится больше всего?
3. Если бы сидели рядом с одним человеком на трансатлантическом авиарейсе, кто бы это был?
4. Как бы вы посчитали количество красных машин в городе?
5. Если бы вы были кухонной утварью, то чем именно и почему?
6. Как бы вы потратили последние свои 24 часа на Земле?
7. Чувствуете себя иногда полиэтиленовым пакетом?
8. Мы встретились с вами в лифте, и у вас есть время до 10-го этажа убедить меня взять вас на эту работу. Поехали!
9. Если бы вы были Премьер-министром на один день, какой закон вы бы изменили и почему?
10. Как бы вы перемешали колоду карт?

США

1. Когда хот-дог

— You have reached English Support. Will you be comfortable communicating in English?
— А по-русски можно?
— Мои извинения, как российской поддержки недоступен в данный момент. Я могу помочь вам перевод. Могу ли я? Я перевел свой ответ, используя Google.
— Хорошо!
Диалог с Дели во время российских праздников

Исторически так вышло, что даже когда первые люди Acronis сидели по чердакам МФТИ, нашими главными рынками были Германия, США и Япония. Поэтому из Москвы мы оказываем поддержку продвинутого, второго уровня на английском, немецком и ещё 4 языках. В других странах расположены команды, предоставляющие поддержку в основном первого уровня. Так, Япония поддерживается из Токио, в Бухаресте есть команда поддержки с несколькими европейскими языками, а также турецким. Ещё две большие команды поддержки, работающие с английским языком круглосуточно, в Дели и Бангалоре. На них иногда и попадают наши русские коллеги в нерабочие или праздничные часы — ниже будет ещё пара примеров, что из этого получается.

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

Сейчас я расскажу вам о том, как можно сэкономить немалое количество времени и денег на вашей IT-инфраструктуре.
Как централизованно админить большое количество linux рабочих станций не разводя при этом хаос в вашей экосистеме.
И так, что же такое LTSP?

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

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

У LTSP есть несколько режимов работы:

• тонкий клиент
• толстый клиент

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

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

Многие современные смартфоны достаточно мощные, чтобы без проблем поддерживать работу обычных офисных приложений, браузеров и других деловых (и не очень) инструментов. Но вот подавляющее количество программного обеспечения, выпускаемого для смартфонов, предназначено только для мобильных устройств. Что, если использовать смартфон в качестве портативного ПК, к которому можно подключить монитор и периферийные устройства?

Идея не нова, да, но успешно реализовать ее до сих пор не удавалось никому. Есть Continuum от Microsoft, старалась изменить ситуацию и компания Canonical со своими Ubuntu-смартфонами и кастомной ОС. Особого распространения все это ПО и аппаратное обеспечение не получило, к сожалению. Может быть, больше повезет MaruOS, это кастомный билд Adnroid. Если подключить к телефону с этой ОС дисплей, клавиатуру, мышь, можно запустить Debian.

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

В стандартной библиотеке Python есть немало кошмарных модулей, но этого нельзя сказать о модуле re. Несмотря на его преклонный возраст и многолетнее отсутствие обновлений, я считаю этот модуль одним из лучших среди всех динамических языков.

Python — один из немногих динамических языков, в которых отсутствует встроенная поддержка регулярных выражений, но это компенсируется проработанной базовой системой (с точки зрения API). В то же время он весьма причудлив. К примеру, поведение написанного на Python парсера может вас удивить. Если вы попытаетесь в ходе импорта профилировать Python, то, скорее всего, 90% времени вы проведёте в работе с модулем re.