Архив метки: Программирование

Создан портрет типичного ИТ-шника. Чем отличаются программисты на Java и .NET? Фото — CNews

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

Портрет типичного программиста

Консультационная компания DataArt показала, как выглядят среднестатистические программисты мужского и женского пола. Для этого сквозь специальной компьютерной алгоритм были пропущены фотографии 2 тыс. айтишников из восьми стран мира: Аргентины, Болгарии, Великобритании, Германии, Польши, США, Украины и России. Проанализировав их, алгоритм определил усредненные черты типичного разработчика.
Мужской портрет был составлен на основе анализа фотографии 1541 мужчины, женский — 512 женщин. Среднестатистический мужчина-айтишник получился светлокожим, круглолицым, с обычной короткой стрижкой. Очки, усы, борода, татуировки и пирсинг на лице на усредненном фото отсутствуют. Типичная женщина-программист так же имеет округлое белокожее лицо, она более улыбчива, чем ее коллега мужчина.
Определившись с портретом типичного айтишника вообще, специалисты DataArt решили выяснить, как выглядят разработчики, специализирующиеся на конкретных направлениях в программировании. Среднестатистический разработчик Java получился очень улыбчивым человеком, а типичный специалист по .NET на обобщенном фото носит довольно отчетливо заметные очки.

Технические особенности

Алгоритм для обобщения лиц был написан на C++ с применением фреймворков dlib и opencv. Работа с чертами лица проводилось по методике разработчика Сатьи Маллика (Satya Mallick). На каждом лице были выделены 68 ключевых точек, в число которых попали уголки глаз, бровей и губ, крылья носа и прочие. После этого алгоритм провел триангуляцию лиц, то есть разделил их на треугольные фрагменты в соответствии с ключевыми точками. Обобщение тона кожи и других цветов лица проводилось отдельно в каждом треугольнике.

Так выглядят среднестатистические программисты мужского и женского пола
Как поясняет автор проекта Андрей Сорокин, разработчикам пришлось решить вопрос с чрезмерным потреблением памяти в процессе обобщения изображений. Изначально оно превышало 4 ГБ, этот показатель удалось сократить до 100 МБ. Кроме того, анализ был затруднен плохим качеством некоторых фотографий и несовпадением ракурсов на них. Различие между портретами специалистов по Java, .NET и другим направлениям разработки удалось выявить с помощью спектрального анализа векторов, проведенных по различным чертам лица.

Средняя зарплата айтишника

Ранее CNews писал, какие зарплаты в среднем получают айтишники. Например, директор по ИТ в Москве и Московской области может получать до 600 тыс. руб. в месяц — если он имеет более 4 лет опыта работы, и трудоустроен в компании, где численность штата превышает 1000 человек. Для компаний численностью от 200 до 1000 человек зарплата ИТ-директора составляет порядка 250-350 тыс. руб.

Разработчики Java склонны чаще улыбаться
Системный администратор с опытом работы от четырех лет получает от 80 до 120 тыс. руб., если он работает в компании, штат которой насчитывает менее 200 человек. В компаниях с численностью сотрудников от 200 до 1000 человек системный администратор с таким же опытом получает 120-160 тыс. руб.
Разработчик с опытом работы более 4 лет в компаниях с численностью персонала до 200 человек получает 100-140 тыс. руб., в компаниях с количеством сотрудников от 200 до 1000 человек — 120-170 тыс. руб., а в компаниях со штатом свыше 1000 человек его зарплата составляет от 120 до 180 тыс. руб.

Так выглядят типичные разработчики .NET
В отечественной ИТ-отрасли не распространено трудоустройство по контракту — большинство специалистов предпочитает ставку, даже если она рассчитывается исходя из более низких расценок. Относительной популярностью контракты пользуются только в среде разработчиков. В 2017 г. трендовыми направлениями в найме айтишников были большие данные, распознавание голоса и развитие искусственного интеллекта. В 2018 г. отрасли понадобится руководители проектов, имеющие навыки развития продуктов, а также специалисты в сфере финтеха.

Автор: Валерий Фетисов
Дата публикации: 2018-02-02T07:26:00.004+02:00

7 смертных грехов программирования / Начинающему программисту

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

Джон Парселл, создатель CaveOfProgramming.com

  1. Использовать «Пробел» вместо «Tab». Всегда, всегда используйте «Tab», а не «Пробел».
  2. Использовать «Tab» вместо «Пробела». Всегда, всегда используйте «Пробел», а не «Tab».
  3. Не использовать автоформатирование. Забудьте про весь мусор вроде табов и пробелов, используйте автоформатирование в своем коде и людям не придется видеть ваши странные скобки и отступы.
  4. Использовать интегрированную среду разработки (IDE) с ее автоформатированием и цветными клавишами. Все коды должны быть написаны в vi или Emacs, что подтверждает безупречность ваших навыков программирования.
  5. Не использовать IDE. Никто не хочет платить за время, которое вы тратите на набор текста, если это можно сделать в один клик, или за прокручивание вверх-вниз с помощью заумной комбинации клавиш из LISP.
  6. Не учить С и С++. Два этих языка жизненно необходимы любому программисту. Думаете, Java так же хорош? Отлично, создайте мне систему управления гоночными автомобилями в режиме реального времени на Java, и я вам поверю.
  7. Учить С и С++ в то время, которое вы могли бы использовать на что-то более современное, например, на Java. Признайте – все таблицы, написанные на С или С++, изживают себя в течение 5 лет. И в таком случае в программном обеспечении есть серьезные ошибки, которые Java просто не позволил бы вам совершить.

Рой Леман, разработчик ПО

  1. Сначала написать, потом подумать. Вы получили требования к товару, пробежались по ним, запустили свою любимую IDE и принялись за работу. Легко, не правда ли?
    Стоп! Вы уверены, что поняли требования до конца? Я не сомневаюсь в вашем умении читать. Но учли ли вы все пограничные случаи? Продумали, как будете тестировать систему? Набросали алгоритм, который собираетесь использовать? Завтра вы этого и не вспомните!
  2. Изобретать колесо. Итак, вам нужно создать шаблон проектирования Producer-Consumer. Вы знаете, как это сделать, еще с университетской скамьи… Легко, не правда ли?
    Стоп! Не важно, с каким языком вы работаете, уже существуют готовые шаблоны, или модули, или открытые исходники. Используйте их. Или по крайней мере изучите их перед тем, как создавать свои.
  3. Бояться прикасаться к коду. Итак, у вас есть задание добавить несколько функций к 20 000-линейному файлу (О, нет! За что?) Вы радостно беретесь за работу и вдруг замечаете огрехи в исходных функциях – нет пограничного случая или проверки на нулевой показатель. Это находится за пределами сферы вашей ответственности. Так? Стоп! Если вы видите небезопасный код – исправьте его. Вы еще хлебнете на этих ошибках, даже если код написан не вами!
  4. Быть безразличным к тому, чем занимается ваша компания. Вы программист, верно? Написание кодов – это здорово, вы не изучали маркетинг или продажи, с чего вам интересоваться тем, что не имеет к вам отношения?
    А следовало бы! Как можно создать продукт, не понимая, чем занимается компания? Как сделать так, чтобы продукт удовлетворял потребности клиента?
    Никак! Изучите дело, будьте в курсе всех вопросов компании, а не только тех, которые касаются непосредственно вас. Это важно! В какой-то момент это даже может повлиять на ваше повышение.
  1. Не следить за новыми трендами. Вы занимаетесь программированием уже 10 лет и подыскиваете работенку.
    Перед этим вы работали старшим разработчиком С++ в крупной корпорации – за многое отвечали и имеете отличные рекомендации. Вы вроде знаете, что такое DevOps, но на практике никогда не сталкивались с этими практиками и с С++14? На вашем предыдущем месте работы в ходу был С++98… Не так уж важно, не так ли?
    Нет, не так!
    Никто не похвалит вас за владение технологиями 15-летней давности!
    Если вы не учитесь в свободное время, чтобы соответствовать запросам работодателя, ваша кандидатура будет отвергнута!
  2. Не обладать коммуникативными навыками. Вы разработчик, к чему вам уметь общаться с людьми! Вам платят за умение общаться с компьютером, а не коллегами. Сиди себе, пиши качественные коды и добьешься успеха, верно?
    Не верно!
    Ваше неумение кратко и четко изложить суть дела вышестоящим – самая большая головная боль для менеджера.
    Очевидно, что это не единственный параметр, по которому вас оценивают, но все же – грамотное предоставление информации в дружественной манере повысит доверие со стороны коллег и вот тогда вы добьетесь успеха.
  3. Не иметь целей. Вам нравится ваша работа, вы прекрасно владеете технологиями Deep Learning. Передовые технологии, прекрасные коллеги… Вы могли бы работать так вечно.
    Но – вы не будете. Все когда-нибудь заканчивается, иногда резко и неожиданно. Если у вас не будет карьерных целей, вы можете оказаться на задворках, выполняя работу и получая зарплату, которые вас не достойны.
    Так что думайте наперед – где бы вы хотели оказаться через 10 лет? В какой роли вы себя видите?
    Научным работником? Разработчиком? Менеджером по продукции? Вице-президентом? Техническим директором? Исполнительным директором?
    Вам решать!

Нико Салминен, старший консультант

  1. Лень: Ну, кажется, код работает нормально. Нет необходимости писать комментарии или проводить автоматизированное тестирование.
  2. Похоть: Эй, а ведь этот новый срочный проект – отличная возможность опробовать новый крутой фреймворк, о котором все говорят!
  3. Зависть: Другая команда продвигается быстрее, чем мы. Лучше не помогать, если у них возникнут проблемы при интеграции с нашим кодом.
  4. Чревоугодие: Мне нужно выполнить итерацию ключей объекта. Мне совершенно необходимо импортировать 1,5-Мбайтную библиотеку для проведения этой операции.
  5. Гордыня: Прочтение этой книги по шаблонам проектирования сделало меня лучшим разработчиком, нежели коллеги! Я собираюсь использовать каждый шаблон, упомянутый в книге при работе над следующим проектом.
  6. Гнев: К черту все! Пускаю этот патч hotfix прямиком в производство!
  7. Алчность: Они что предлагают изменить код в моем репозитории? Отклонить! Это мой проект!

Усман Шаукат, более 8 лет опыта в сфере веб-разработки, PHP, Javascript, Node.Js

Вопрос касается программирования не как процесса разработки ПО в целом, так что мой ответ касается непосредственно фазы программирования:
  1. Программировать, не планируя. Самый страшный из всех грехов.
  2. Пытаться изобрести колесо. Если есть возможность, всегда используйте алгоритмы, предложенные в книгах и научных статьях (например, алгоритмы сортировки, поиска и т.д.), а не пишите собственные.
  3. Писать несистематизированные/некачественные коды и не придерживаться стандартов программирования.
  4. Считать, что тестирование – это не ваша забота. Я вас очень прошу, пожалуйста, тестируйте свои коды.
  5. Писать сложный код, когда с тем же успехом можно обойтись простым. Простые коды – это элегантно.
  6. Слепое копирование-вставка с сайтов вроде stackoverflow.com без ознакомления с пояснениями и комментариями.
  7. Последнее, и самое важное – совершенствуйтесь сами и осваивайте новый инструментарий. Никогда не бойтесь новшеств. Знакомьтесь с ними раньше всех. Это поможет вам оставаться востребованным.

Автор: Валерий Фетисов
Дата публикации: 2018-01-31T06:09:00.000+02:00

Семантическое версионирование 2.0

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

Основная идея

Существует основной формат:

MAJOR.MINOR.PATCH

Формат включает в себя три неотрицательные цифры, которые увеличиваются в соответствии со следующими условиями.

MAJOR — увеличение версии говорит об обратно несовместимых изменениях API.
MINOR — увеличение версии говорит о добавлении новой функциональности при сохранении обратной совместимости.
PATCH — увеличение версии говорит об обратно совместимых фиксах.

Какую проблему решаем?

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

Как решаем?

Основная идея была описана выше, а ниже некоторые, на мой взгляд, важные вещи из спецификации SemVer.

  • если какие-то изменения сделаны после релиза, то они попадут только в новый релиз;
  • публичный API для версии 0.х.х не должен рассматриваться как стабильный, это версия для начальной разработки;
  • версия 1.0.0 определяет публичный API;
  • если часть API помечена “устаревшей”, то инкрементируем минорную версию, в том числе она может в себя включать фиксы;
  • мажорная версия может включать в себя изменения характерные минорной версии и патчу;
  • версию можно дополнять указателями на предрелизные выпуски или сборками изменяющими метаданные, но идентификаторы версий только в ASCII.

Всегда ли это подходит?

Нет, не всегда. Если вы разрабатываете программу/веб приложение для конечного пользователя, а не библиотеку или http API, то скорее всего семантическое версионирование вам не нужно. Прежде всего, посмотрите на цели и статус вашего проекта, возможно он находится на поддержке, всё, что вы делаете, — исправляете ошибки, то есть “новая функциональность” не появляется, это значит, что первые две цифры будут вечно неизменными, тогда какой в этом смысл? С другой стороны, если взглянуть категорично, то так и должно быть, каждый раз закрывая пачку багов, вы обновляете PATCH версию, а при необходимости хот-фиксов просто расширяете её дополнительными идентификаторами.

Для кого это подходит?

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

Сайт семантического версионирования

Автор: Roman Brovko

CudaText: кроссплатформенный текстовый редактор для программистов с открытым исходным кодом

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

Я не могу назвать его одним из лучших редакторов с открытым исходным кодом, потому что он еще слишком молод. Я даже не могу назвать его альтернативой Notepad ++ для Linux, потому что он больше похож на легкую среду IDE, такую как Geany. Хотя интерфейс по умолчанию напоминает Eclipse IDE.

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

Давайте посмотрим, что нам предлагает CudaText:

Читать

Генетический алгоритм: эволюция помогает подросткам

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

Генетический алгоритм

Генетический алгорим (далее ГА) — это метаэвристический (metaheuristic) универсальный (general-purpose) алгоритм.

Метаэвристические алгоритмы — это мощнейший, популярный класс оптимизационных методов, сила таких алгоритмов в способности решения сложных задач без знания пространства поиска. Фактически такие алгоритмы ищут случайным образом решение и останавливаются при достижении какого-либо условия или числа операций. Иногда можно доказать, что найденное решение близко к оптимальному, но на практике, оптимальное решение нужно далеко не всегда. Вот неполный перечень метаэвристических алгоритмов: алгоритм оптимизации муравьиной колонии, эволюционные вычисления, включая ГА, итеративный локальный поиск, метод имитации отжига, алгоритм поиска с запретами и другие.

Алгоритм считается универсальным (общего назначения), если вы можете взять различные задачи и реализовать с его помощью решение.

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

Генетический алгоритм

 

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

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

Будьте готовы, что теория иногда разнится в терминах.

Проблема

Представим, что у нас есть проблема: мама отправляет за хлебом, нужно встретиться с друзьями, магазин закрывается рано, а еще нужно успеть погулять с девочкой. Вероятно, вы думаете, что такие проблемы никого не волнуют, но если вы вспомните каково это быть подростком, то думаю, что проблема вполне реальна. Также в качестве входных данных нам дается матрица весов. Если мы проиндексируем наши действия, как 0 (сходить за хлебом), 1 (встретиться с друзьями) и 2 (погулять с девочкой), то получится следующая матрица весов. Индекс строки будет означать, что действие выполнится первым, а индекс столбца — это действие которое будет выполнено следом.

Содержимое клеток означает следующее:

  • позитивное значение — действие желательно пропорционально значению;
  • негативное значение — действие нежелательно пропорционально значению;
  • 0 — действие может быть выполнено без какого-либо оттенка;
  • «-» — действие не допустимо.
    0     1     2
------------------
0| - -0,5 -1
1| 0 - 0.5
2| 0 0.5 -

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

Решение

Спроектируем решение с помощью генетического алгоритма. Как вы уже знаете нам нужно создать случайную популяцию, но что будет считаться индивидом? Нам необходимо построить наилучшим образом цепочку действий, т.е. чтобы сумма коэффициентов из матрицы с весами была максимальна. Индивидом в нашем случае является последовательность действий, т.е. каждый генотип содержит одну хромосому, которая будет иметь 3 гена, которые и представляют из себя цепочку. Например, индивид с генотипом с одной хромосомой, который содержит последовательность генов «1, 2, 0» представляет из себя решение «встретиться с друзьями -> встретиться с девочкой -> сходить за хлебом».

Как оценить такое решение? Для этого нам нужно определить целевую функцию (в генетическом алгоритме она называется функцией приспособленности). Простым языком, это функция, результат которой дает нам представление о том на сколько хорош о наше решение (особь). В нашем случае, целевая функция это сумма весов переходов. Мы должны обойти последовательность и в результате переход 1->2 дает 0.5, а 2->0 дает 0, итого, в сумме целевая функция дает значение 0.5.

Селекция

Как вы понимаете, теперь мы умеем оценивать «лучших» особей, однако, подходов к селекции всё равно много. Простейший способ выбрать лучших — отсортировать особей по значениям целевой функции и выбрать N штук с наибольшим значением. Такой селектор называется Truncation Selector. Еще один интересный и популярный экземпляр это Tournament Selector. Всё зависит от решаемой задачи. Как вы понимаете, после селекции в популяции следующего поколения остается свободное место и, в зависимости от подхода, новое поколение может быть наполнено либо дубликатами лучших особей, либо случайными особями. Я нашел интересную статью в которой разбираются 6 популярных методов для селекции. Вы сможете скачать эту статью по ссылке.

Скрещивание

Для операции скрещивания также существует множество подходов. В англоязычной википедии есть не плохое описание некоторых из них (ссылка). Для рассматриваемого случая с цепочкой действий один из лучших подходов к скрещиванию называние Cycle Crossover. Как он работает? Когда мы скрещиваем две особи в их генотипах мы находим общий цикл и сохраняем его для потомков, а вот гены не задействованные в циклах меняются местами. Для цепочек из трёх генов такой подход, конечно бесполезен, как и не оправдано использование этого алгоритма, но всё же. В тот момент, когда я пытался осознать этот способ скрещивания лучше всего мне помогло вот это видео на YouTube:

Cycle Crossover

 

Мутация

В нашем случае мутация это случайный обмен случайных позиций для двух генов, т.е. это обычная смена последовательности. Здесь даже объяснения не нужны: была хромосома 12-0, мы сделали обмен для 0 и 1 позиции (ранее случайно определенных) и получили мутировавшую хромосому 21-0. Обычно, вероятность мутации сильно ниже вероятности скрещивания.

Реализация

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

Я подскажу вам одну отличную библиотеку для Java, которой сам пользовался: jenetics.

Примеры работы с такой библиотекой вы можете найти в документации к ней, либо вот здесь.

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

При подготовке к статье в качестве теоретических оснований я использовал: http://tvim.info/files/56_72_Shcherbina.pdf

Автор: Roman Brovko

Bitrix. Получить id элемента/раздела по коду

Очень не люблю ЧПУ в адресах страниц. Бессмысленное жертва ради мнимого удобства. Из-за ЧПУ получаются супер-длинные адреса, которыми даже нельзя нормально делиться в некоторых соцсетях/мессенджерах из-за ограничения количества символов. Поэтому приходится переделывать некоторые сайты… Читать