Антон Репьев, технический директор Lodoss Team, специально для блога Нетологии поделился кейсом, как внутри компании организовать программу стажировки и вырастить с нуля молодых специалистов.

Кадровый голод — вечная проблема IT-компаний. Все решают её по-своему: кто-то прокачивает HR-бренд и хантит кандидатов в LinkedIn, кто-то воспитывает своих разработчиков с нуля. Мы в Lodoss Team выбрали второй путь. Я разработал тренинг для начинающих специалистов и курирую обучение стажеров в компании. Что из этого получилось и зачем нам это надо, читайте в этой статье.

Зачем растить джунов

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

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

Зачастую в IT проще обучить сотрудников «с нуля», чем переучивать человека с опытом.

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.

Рассмотрим такие темы как:

• Git 101
• Методологии разработки (Git flow)
  
  • GitHub flow
  • GitLab flow
• GitLab
• GitLab CI

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

Предыдущие части: первая, вторая.

Перед современным веб-разработчиком стоит широчайший выбор платформ для хостинга и хранения данных, инструментов для работы с HTML, CSS и JavaScript, способов фактической реализации дизайна, а также всевозможных библиотек и фреймворков. В помощь тем, кто хочет найти свой путь в этом обилии вариантов, сеть услужливо предоставляет массу статей, обсуждений на форумах и примеров «наилучших» решений. Но вне зависимости от того, как и с помощью чего начинающие разработчики создают сайты, многие совершают одни и те же ошибки. Давайте рассмотрим некоторые из них, чтобы в будущем не наступать на эти популярные грабли.

Примечания tsafin:

Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.

Введение

Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.

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

Привет, читатель!

В этой публикации я расскажу тебе о «Книжной полке фронтендера».

Предыстория

К сожалению, в рунете очень мало по-настоящему качественных ресурсов для изучения фронтенда. Эти ресурсы можно буквально пересчитать по пальцам одной руки — это Frontender Magazine, HTML Academy, «Современный учебник JavaScript». Я благодарю авторов этих ресурсов за их неоценимый вклад в развитие и популяризацию фронтенда в рунете.

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

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

Сходу расстрою — посылкой управлять никак нельзя. Если она долго не «прилетает» в Россию (т.е. статус Экспорт стоит, а Импорт — нет) — тут вряд ли что-то поможет. Однако страхуемся, делаем по шагам, описанным ниже.
Порадовать тоже могу: процентов 95 посылок все-таки доходят. Объем для сравнений — порядка 10 посылок в месяц из США и Европы.
Обращаю внимание, что многие посылки (процентов 60 всех отправлений) я получаю «от себя», используя сервисе вроде Шипито. В некоторых случаях это означает, что почта не может отказать в претензиях по причине того, что они представляются «не отправителем». Однако во многих случаях рекомендую идти и биться за свою посылку при помощи процессов и документов, представленных ниже.

Продолжению быть!
Часть 1

---

Задачи поставлены, и вроде бы самое время перейти к чтению различных обзоров и тестов, но…
С чего начать? В какую сторону вообще смотреть?

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

Учёные уже полностью дизассемблировали H1N1 и занесли его в вирусную базу NCBI Influenza Virus Resource. Там всё задокументировано в подробностях. Например, образец A/Italy/49/2009(H1N1) был обнаружен в носу 26-летней женщины, вернувшейся из Италии в США. Вот первые 120 бит его генетического кода.

atgaaggcaa tactagtagt tctgctatat acatttgcaa ccgcaaatgc agacacatta

Сколько бит убьёт человека?
По приблизительным подсчётам, общий размер исходников H1N1 составляет 26 022 бит, а если исключить служебные стоп-сигналы (указывают на окончание каждой белковой последовательности), то исполняемый код состоит примерно из 25 054 бит. Это число является приблизительным ещё и потому, что в вирусе присутствует механизм генерации избыточного мусора для маскировки от антивирусов.

Итак, получается около 25 килобит или 3,2 килобайта. Таков объём кода для программы, имеющей ненулевые шансы убить человека. H1N1 написан гораздо эффективнее, чем компьютерный вирус MyDoom размером около 22 КБ.

Очень унизительно, что меня могут убить всего 3,2 КБ генетических данных. Впрочем, в 850 МБ человеческого генома по любому должны быть дыры для парочки эксплойтов.

Пока гугл борется с правозащитниками в Германии, другие компании просто так без рекламы и громких заявлений открывают аналоги Google StreetView. Сервис sightwalk.de представил Кёльн в 360°.



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

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

Зачем это может быть нужно вам

• Cheap life. Тот же уровень жизни можно сохранить при гораздо меньших денежных затратах. Для тех, кто любит совать это слово в каждую статью — ок, называйте это антикризисным предложением. Для тех, кто не любит — затраты настолько меньшие, что тут удобнее было жить и до кризиса.
• Easy life. Инфраструктуры много, она рядом, она дёшева. Куча едальных заведений, кафе, рынков, развлечений разного рода. Всё в минутах езды на мотоцикле.
• Interesting life. Это во-первых, заграница, экзотическая страна. Во-вторых, здесь встречается много интересных, свободомыслящих людей со всего мира. Здесь есть множество способов провести время активно, творчески и т. п.
• Colorful life. Что лучше — работать в бывшем заводском цеху, или красивом тропическом саду? Я предлагаю второе!

Зачем это нужно мне?

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

Естественно, если дело пойдёт, такое объявление здесь появится. А пока я хочу собрать «могучую кучку» людей, которые образуют костяк коворкинг-центра. Людей, которые готовы уже готовы собрать чемоданы ;)

Я готов предложить этим людям помощь в:

• Переезде
• Решении визовых вопросов
• Ориентировании на местности

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

Что скажете?

Мини-ЧАВО по вопросам из комментов

У меня есть жена, мне нельзя в Тайланд!
Я не зря написал «север Тайаланда» — это совсем не пляжные секс-курорты. Здесь, можно сказать, интеллектуальный центр — много университетов, много студентов. Есть даже международные факультеты, оттого — много молодых и умных американцев и европейцев.

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

У меня самого есть жена :). Более того, многие знакомые живут тут с 1-2 детьми совершенно разных возрастов — от грудных, до школьных (студенты уже едут учиться либо в столицу, либо в развитые страны — Австралию, Европу, США).

Что с пасспортно-визовым режимом? Не темни!
Безвизовый въезд, либо виза по прибытию на мес. Путём простых манипуляций можно получить и потом продлять более долгосрочные визы. Люди живут тут годами.

Каковы траты на жизнь?
Всё зависит от вас. Можно жить в комнате за 2500 рублей в месяц и есть за 20 рублей местную еду. Можно жить в дворце за тысячи долларов и питаться в пафосных ресторанах. Можно выбирать какие-то промежуточные состояния.

Можно ли открыть счет в банке, платить налоги? Работать?
Счёт можно открыть, как инсотранцу, получать на него деньги откуда угодно. Работать — найдя работодателя, готового совершить все операции по легализации. Однако в рамках данного топика речь идёт прежде всего об удалённой работе.

Где это вообще — север Тайланда?
Это тут!

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Typesafe Stack — современная программная платформа, которая обеспечивает возможность создания легко масштабируемых программных систем на Java и Scala. Стек функционирует на JVM, включает в себя фрэймворки Akka 2.0 и Playframework 2.0. Ядром платформы, которое обеспечивает практически неограниченную масштабируемость разрабатываемой системы, является библиотека Akka, реализующая многозадачность на основе модели акторов.

Приветствую хабрасообщество!
В начале прошлого лета, когда пришла пора думать о написании диплома, я прошуршал весь рунет на тему тонкостей и особенностей этого процесса не то, что бы на нашей кафедре, а хотя бы на моём факультете. Не нашлось ничего.
Обычный для большинства универов способ передачи этой информации – от старших товарищей к младшим и далее между младшими. В случае нашего потока горизонтальные и вертикальные связи оказались нарушены настолько, что большинство работало “в слепую”.

Пройдя данный путь до конца, я бы хотел облегчить его тем, кто пойдёт следом и подробно рассказать как это было у нас, на специальности Информационные системы и технологии (230201) кафедры ИС факультета ИТиП СПбГУ ИТМО.

Предисловие

Давно хотел написать. Мысли есть, желание есть, времени нету… Но вот нашлось, так что привет, Хабра.
Здесь я собрал все идеи, которые помогали и помогают в разработке веб-приложений. Для удобства я разбил их на группы:

1. Память
2. Оптимизация операций
3. Выделение критических участков
4. Циклы и объектные свойства
5. Немножко о DOM
6. DocumentFragment как промежуточный буфер
7. О преобразованиях в объекты
8. Разбитие кода
9. События перетаскивания
10. Другие советы

Сейчас речь не пойдёт ни о каких библиотеках. Я постараюсь передать знания о механизмах самого языка, а не их реализациях в библиотеках.

Память

Хоть это и не должно волновать клиентского программиста, но не забываем, что память всё-таки не бесконечна и когда-нибудь может закончиться, например, когда запущено несколько массивных программ: офис, графический редактор, компиляция большой программы и др. Несмотря на то, что приведенный пример тривиален, у меня действительно такое случилось, хоть и не из-за браузера, но он тоже сыграл свою роль: 1,3 Гб оперативы (отладчик, около 30 вкладок), начались тормоза по перегрузке страниц ОП в файл подкачки.
Чтобы уменьшить расход памяти, я предлагаю несколько способов:

Доклад «Tarantool: как обрабатывать 
1,5 млрд запросов в сутки?» — очередной в серии расшифровок с Форума Технологий Mail.Ru 2011. Подробности о том, как работает система расшифровки докладов — см. в статье «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management. Там же, а также на сайте Форума (http://techforum.mail.ru) — ссылки на расшифровки других докладов.

(Скачать видеоверсию для мобильных устройств — iOS/Android H.264 480×368, размер 170 Mb, видеобитрейт 500 кбит/с, аудио — 64 кбит/с )

(Скачать видеоверсию большего разрешения H.264 624×480, размер 610 Mb, видеобитрейт 1500 кбит/с, аудио — 128 кбит)

(Скачать слайды презентации, 520К)

Представлять данного докладчика тяжело, потому что его все знают. Каждый из вас, я уверен, пользуется продуктами, к которым Костя приложил руку. Это, в первую очередь, MySQL. Костя на протяжении многих лет занимался разработкой этой популярной базы данных, которую используют если не 100%, то 90% российских сайтов точно. Сегодня Костя работает в компании Mail.Ru Group. Костя нам сегодня расскажет о том, что мы сделали, как это работает и главное — какую производительность это позволит получить на ваших сервисах.

Добрый день. Вас сегодня очень много. Cпасибо, что пришли! Меня уже представили, поэтому я бы только хотел добавить, что я в душе и по делу все-таки инженер. Я, скорее, не руковожу, а активно участвую в разработке Tarantool, поэтому, если вам это интересно, у вас сегодня есть возможность узнать про него абсолютно всё. Так или иначе, этот доклад, помимо философствования на тему будущего СУБД, о Tarantool.

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

Вступление

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

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).