Публикуем второй отчет зарплатного сервиса «Моего круга». Отчёт построен на данных по 7900+ зарплатам, внесенных нашими пользователями за последние полгода. 70% зарплат внесено разработчиками, остальные — администраторами, тестировщиками, менеджерами, аналитиками, дизайнерами, эйчарами, маркетологами и специалистами поддержки.

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

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

В небольшой команде тимлид может попытаться судить обо всем происходящем на основе субъективных ощущений, но, чем больше компания, тем важнее использовать объективные данные и метрики. Александр Киселев (AleksandrKiselev) и Сергей Семенов в своем докладе на TeamLead Conf показали, как использовать данные, которые вы уже накопили, где взять дополнительные, и что они все вместе могут помочь определить неочевидные проблемы. И даже, аккумулировав опыт многих коллег, предложили варианты решения.


О спикерах: Александр Киселев и Сергей Семенов в IT мы уже больше 8 лет. Оба прошли путь от разработчика до тимлида и далее до product-менеджера. Сейчас работают над аналитическим сервисом GitLean, который автоматически собирает аналитику у команд разработки для тимлидов и CTO. Задача этого сервиса в том, чтобы технические менеджеры могли принимать свои решения на основе объективных данных.

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

Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 21 веке двигало …» и «… понять, как устроено предприятие».

На страницах ИТ-интернета тема Enterprise Architecture (ЕА) — одна из популярнейших. Она дает возможность поговорить о «высоком», — об «архитектурном» подходе, десятках framework, почувствовать себя Архитектором «с большой буквы».

Пишут многие и пишут много. Читатели статей «Архитектура предприятия» одобрительно кивают, восхищаясь … «платьем короля». На «благодатной почве» ЕА развелись всевозможные «архитекторы».

Книги, учебные дисциплины, консалтинговые проекты, группы, консорциумы, целые институты со специализацией ЕА (IFEAD, iEAi и др.), глобальные организации (GEAO), одноименные журналы (Journal of Enterprise Architecture), международные стандарты (ISO 15704, 42010 и др.) и прочее — прочее.

Тем не менее, в контексте ЕА, остаются вопросы: что такое «архитектура», что такое «предприятие» и что такое «архитектура предприятия», а также — кто главный потребитель ЕА и почему конкретных примеров этой самой ЕА нигде нет.

Методик, эталонных моделей и архитектурных фреймворков (обычно с окончанием на «AF»: FEAF, TEAF, DoDAF и т.п.) — «как грязи», а реальных результатов посмотреть негде.

Да-да, ключевая особенность этого направления: нет ни одного конкретного полного примера этой самой загадочной enterprise architecture в открытом доступе.

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

#ОТ АВТОРА
За свою карьеру я встречал много IT предпринимателей, помогал строить бизнес, решал проблемы. Видел взлеты и падения, успех и крах.

Смысл этой истории (и всех последующих в рубрике “Истории юриста”) рассказать вам о юридических аспектах и нюансах жизни отечественного IT бизнеса.

Представлюсь. Меня зовут Вячеслав Устименко, я основатель известной среди IT предпринимателей юридической компании и YouTube блогер.

Иногда наши рефлексы, вызванные инстинктом самосохранения, могут привести к летальному исходу. Например, когда переходишь дорогу в России, надо посмотреть сначала налево, а потом направо. А в Англии наоборот: сначала направо, затем налево. Если забыть о левостороннем движении — можно попасть под машину.



При переходе от проектного бизнеса (например, веб-студии или компании аутсорсинговой разработки) к продуктовому (разработка и вывод на рынок собственного решения) — происходит то же самое. Сложно избежать привычного подхода к бизнесу. Директор Акселератора ФРИИ Дмитрий Калаев рассказал о шести привычках проектного бизнеса, которые мешают продуктовому расти, а в самых тяжелых случаях — убивают стартап.

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

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

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

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

Как разработчика популярной блокчейн-платформы меня иногда спрашивают есть ли в планах развития нашего сервиса Multichain место умным контрактам по типу тех, что используются в Ethereum. В ответ всегда звучит: «Нет, или во всяком случае не сейчас».



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

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

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

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

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

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

Такой способ создания программного обеспечения используется в процессах Непрерывной интеграции (Continuous Integration) и Непрерывного развертывания (Continuous Deployment), или CI/CD-цепочке. В этой статье мы пройдем по всем шагам настройки такой цепочки, используя для ее построения бесплатные облачные сервисы.

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

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

Перевод «Я люблю ИП»

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

Если вы не верите, что можете научиться дизайну, просто вспомните слова легендарного Дэвида Грола (барабанщик в группе Nirvana, гитарист и вокалист FooFighters, прим. ред.) об изучении новых вещей:

Я никогда не учился играть на барабанах. Я никогда не учился играть на гитаре. Я как-то сам до всего дошёл. Если вы действительно любите своё дело, увлечены им и сфокусированы, вы сможете сделать всё, что захотите.

А теперь, помня эти слова, вы готовы к нашему крэш-курсу? Пристегните ремни, мы начинаем в произвольном порядке.

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

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

Сегодня платформа Ethereum стала одним из самых узнаваемых брендов блокчейн сферы, вплотную приблизившись по популярности (и капитализации) к Bitcoin. Но из-за отсутствия "полноценного" рускоязычного гайда, отечественные разработчики все еще не очень понимают, что это за зверь и как с ним работать. Поэтому в данной статье я попытался максимально подробно охватить все аспекты разработки умных контрактов под Ethereum.

Я расскажу про инструменты разработки, сам ЯП, процесс добавления UI и еще много интересного. В конечном итоге мы получим обычный сайт-визитку, но "под капотом" он будет работать на умных контрактах Ethereum. Кого заинтересовало — прошу под кат.

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

«Как узлам сети достичь одинаковой точки зрения на журнал транзакций блокчейна в распределенной сети при условии, что произвольные узлы могут «падать» или зависать, руководствуясь лишь общими правилами обработки сообщений в сети?»

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

Часто это просто модное название компьютерной программы

В научной фантастике возможность угрозы со стороны искусственного интеллекта (ИИ) связана с взаимоотношениями людей и разумных машин. Будь то Терминаторы, Сайлоны или такие вспомогательные машины, как компьютер из «Звёздного пути» или дроиды из «Звёздных войн», машины заслуженно называют искусственным интеллектом, когда те становятся разумными – или, по меньшей мере, осознают себя достаточно, чтобы действовать мастерски, неожиданно и по собственному желанию.

Что же можно сказать о текущем взрыве «якобы ИИ» в СМИ, индустрии и технологиях? В некоторых случаях назвать нечто «ИИ» в принципе возможно, хотя и с натяжкой. Робомобили не сравнить с R2D2 (или Hal 9000), но у них есть набор датчиков, данных и вычислительные возможности для выполнения сложной задачи вождения автомобиля. В большинстве случаев системы, заявленные, как ИИ, не осознают себя, не разумны, не обладают волей и не могут удивлять. Это просто программы.

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.