Меня зовут Екатерина Шалапанова, в DataArt я работаю с 2008 года, занимаюсь в основном управлением проектами. Иногда, правда, совмещаю эту роль с ролью системного аналитика. В индустрии с 2000 года, начинала карьеру программистом и незаметно для себя переродилась в менеджера, которой интересно заниматься смежными областями. Сразу уточню, что мое мнение может не совпадать с позицией компании, которую я тут представляю.

Сразу оговорю, что под Agile подразумеваю в основном-таки Scrum, хотя в курсе существования других подвидов. Рассуждения эти, по моим ощущениям, более или менее применимы ко всем гибким процессам, т. е. проектам без фиксированного scope в начале работ и с уверенностью, что потом команда вырулит. Речь ниже пойдет о том, почему же команда не всегда выруливает.

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

Помни: сила рыцаря-джедая — это сила Вселенной.
Но помни: гнев, страх — это всё ведет на темную сторону Силы.
Как только ты сделаешь первый шаг по темному пути,
ты уже не сможешь с него свернуть…

Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.



Для любителей пруфов — welcome.

Т. ч. в нашем ремесле без знания *nix-систем никак. Давайте проведем экскурс в мир *nix и поймем, какими знаниями должен обладать юный падаван.

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

Привет, меня зовут Андрей Яновский, я работаю дизайнером в DataArt. Хочу поговорить о новых гайдлайнах Google Material Design и об их применении в разработке приложения для покупки билетов в кинотеатр.

Все, конечно же, сейчас обсуждают часы от Apple и свежие айфоны, но я остановлюсь на недавно представленных Google обновленном дизайне для Android — Material Design. Сразу хочу сказать, что я — большой поклонник Apple, с 2008 года использую их технику как основной инструмент для работы, но Gmail, например, начал пользоваться еще в 2005. Поэтому постоянно слежу за Google, интересуюсь их разработками в области дизайна и UX, и до последнего Google I/O они меня особо не радовали. Ну, не испытывал я после 10 минут наедине с телефоном на Android того щенячьего восторга, который ощутил, когда в 2009 пересел с Windows Mobile на еле работающем HTC на iPhone 2G.

И вот в этом году я решил посмотреть Google I/O, у нас как раз его транслировали на работе, в офисе DataArt. После трансляции было стойкое желание попробовать в деле, но, к сожалению, текущие проекты и середина лета были не совсем со мной согласны. Поэтому я решил отложить эту идею и плюс найти проблему, достойную решения. Через месяц у меня появилось свободное место в рабочем расписании и, договорившись с главой дизайн департамента, я полностью погрузился в проблему.

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

Итак, дано: разработать приложение для Android, позволяющее купить электронный билет в любой кинотеатр на любой фильм.

“… british scientists proved…”

Привет, Хабр. Меня зовут Сергей Сапегин, я работаю PHP-разработчиком в DataArt. Но сегодня я хочу поговорить не о PHP.

Работники IТ, вне зависимости от области специализации, в последнее время все чаще сталкиваются с интересным феноменом мира ПО — ITIL. Поскольку общемировая тенденция не миновала и DataArt, мы предприняли небольшое исследование, дабы понять, что и как следует знать нашим разработчикам, чтобы некоторые процессы заказчиков не ставили в тупик всю команду. Представляем вам, что из этого получилось…

Всем привет. Я — Денис Мельский. Работаю PHP Developer в DataArt. Область моих профессиональных интересов — Web Development и Linux. Сегодня я хотел бы поговорить с вами о «скрещивании ежа с ужом».

Intro

На первый взгляд может показаться, что это безумство и, в некотором роде, архитектурный костыль. Но, если посмотреть с другой стороны, это один из вариантов выхода из часто встречающейся тупиковой ситуации: заказчик хочет WordPress и ничего другого не признает. Скорее всего, что-то он такое услышал, нагуглил, увидел, посоветовал сосед гуру кодер Джон (ну, или Вася).
А программисты наотрез отказываются натягивать на движок блога, с, мягко говоря, не самой лучшей архитектурой, функционал, допустим, интернет-магазина, форума, и вдобавок — REST API для партнёров этого магазина, и сверху — еще пачку кронов с бизнес-логикой.

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

Один из вариантов, который я нашел проводя исследование, на эту тему— скрещивание WordPress и Yii.

Введение

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

Что будет в этой статье:

• Разберем, из чего состоит фреймворк и зачем он нужен;
• разберем вопрос безболезненного развертывания кластера;
• посмотрим на конкретный пример;
• немного коснемся новых фич Hadoop 2 (Namenode Federation, Map/Reduce v2).

Чего не будет в этой статье:

• вообще статья обзорная, поэтому без сложностей;
• не будем лезть в тонкости экосистемы;
• не будем зарываться глубоко в дебри API;
• не будем рассматривать все околоdevops-задачи.

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



Всем привет! Меня зовут Родион Горковенко, и я… нет, не то, о чем вы подумали. Я — Senior Java Developer в компании DataArt. Хочу поделиться историей, как я дошел до жизни такой и, возможно, немного подсказать молодым специалистам, как выжить в беспощадных джунглях Java и стать полноценным цифровым хищником.

Введение (красивая заставка)

Сначала я программировал на C. Были и другие языки, но большую часть времени (несколько лет) я писал именно на C. Поэтому и моя карьера в IT началась с этого языка. Однако область применения его ограничена сравнительно низкоуровневым софтом — я писал на нtv для микроконтроллеров, когда разрабатывал электронику, и позже — для POS-терминалов.

Ответ на вопрос «куда двигаться дальше?» был для меня не очень ясен. Можно, конечно, было углублять изучение C++, но небольшой опыт работы в команде на C/C++ оставил несколько негативное впечатление. Альтернативой была Java. О ней я не знал почти ничего, разве что, пару тестовых приложений для мобильников с JavaME написал еще в институте — конечно, не разбираясь подробно в нюансах языка.

Что ж, в течение года посвященного POS-терминалам, у меня было немного свободного времени до и после работы. Гугление подсказало, что нужно скачать Java Development Kit (JDK) с сайта Sun (теперь java.oracle.com) и, в общем, можно начинать.

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

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

Откуда в компаниях берутся лишние рутины, бесполезные функции и менеджеры, бесцельные отчеты и ритуалы? В основном, это следствие трех причин:

1. Излишняя систематизация.
2. Инерция и шаблонность.
3. Управленческие ошибки.