Никого из нас не удивить банкоматом (АТМ). Даже люди старшего поколения мало-помалу привыкли к этому устройству и свою пенсию в состоянии как-то снять. Однако кроме всего прочего — банкомат – это крайне занятная штука с технической и организационной точки зрения. Даже сотрудники банковских учреждений (в т.ч. и связанных с платежными картами) не всегда представляют себе тонкости его работы. В прошлой жизни я достаточно много лет был связан с платежными картами и обслуживанием банкоматов. Мне доводилось и отогревать его феном и выковыривать оттуда по кусочкам мышь кровь кишки, застрявшую в обнимку с купюрами. Даже спалил один из подконтрольных банкоматов. Дважды. Поэтому поделюсь некоторыми, на мой взгляд, интересными техническими нюансами в работе АТМ.

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

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

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

Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.

Сегодня утром стартовал очередной, уже четвёртый по счёту набор в школу программистов HeadHunter.
Занятия будут проходить по вечерам, два раза в неделю с октября по апрель в московском офисе технического департамента, недалеко от метро Алексеевская. Преподаватели – наши специалисты, в числе которых blv, mikesub, tum0rc0re и ваш покорный слуга. Во время обучения студентам выплачивается ежемесячная стипендия – 15 тыс. рублей. Лучшим выпускникам будущей весной мы предложим присоединиться к нашей команде.

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

Сегодня я хочу поделиться с вами моим вольным переводом статьи, написанной Сергеем Повзнером (Sergey Povzner). Сергей ведёт блог bongizmo.com и занимается разработкой туристических гидов под общим названием Citybot.

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

Статья будет полезна как новичкам, так и опытным разработчикам. Это гид по миру Android-разработки.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

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

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

7. Карта ума.

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

Для создания карты ума (её чаще называют английским термином «Mind map»), мы можем использовать специальное ПО, я рекомендую Xmind.

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

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