Введение

Наверняка некоторые из вас знают, что такое блокчейн Эфириум (с англ. Ethereum), другие, напротив, не имеют даже малейшего представления о нем. Так или иначе, и первые и вторые что-нибудь да слышали о данной платформе. В последнее время этой теме было посвящено множество статей в различных крупных журналах, однако для тех людей, кто мало что слышал об Эфириуме, все статьи на эту тему представляются чем-то мистическим и совершенно непонятным. Тогда, что же собой представляет данная платформа? Если вкратце: Эфириум – это общедоступная база данных с возможностью хранения цифровых транзакций в течение неограниченного времени. Важно также отметить, что для обслуживания и защиты такой базы данных не требуется каких-либо систем управления ключами. Вместо этого данная платформа работает как «беззащитная» транзакционная система – фреймворк, в котором физические лица могут совершать одноранговые транзакции, при этом ни одна из сторон не несет перед другой или третьей сторонами каких-либо обязательств.

Мы в компании Triplebyte проводим много собеседований. В реальности за последние два года я собеседовал более 900 инженеров. Насколько это эффективное использование моего времени — здесь можно спорить (иногда я просыпаюсь в холодном поту и сомневаюсь в этом). Но независимо от моих ощущений, главное, что мы стараемся улучшить процедуру собеседований. Для этого мы проводим собеседования без просмотра резюме (background-blind inrterview), определяем навыки программирования, а не оцениваем заслуги и рекомендации. После того, как инженеры прошли наше собеседование, они направляются для финального интервью напрямую в компании, с которыми мы работаем (включая Apple, Facebook, Dropbox и Stripe). Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.

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

На прошлой неделе создатели облачного Help Desk сервиса Okdesk опубликовали первую часть историй со всего мира о результатах внедрения Help Desk для «внешней» клиентской поддержки. Теперь, если Вы захотите обосновать Вашему руководству необходимость проекта запуска системы автоматизации постпродажного обслуживания, то в качестве примера можете рассказать о том как:

• Sennheiser сократил срок реакции на заявки более чем в 5 раз;
• Whirpool на 20% сокращает количество входящих электронных писем;
• Jamberry сокращает штат поддержки более чем на 20%;
• «Кейсистемс-Иваново» — повысил удовлетворенность поддержки своих клиентов (органы государственной власти и местного самоуправления) до 96,4%

Сегодня публикуем вторую часть историй успешного внедрения подобных решений

Всем привет! Давно уже хотел написать статью о UniRx на Unity3d. Начнем с небольшой философии RX программирования. Например, разрабатывая игру, мы создаем кнопку, наблюдаем событие клика этой кнопки и реагируем на это каким нибудь кодом.

Реактивное программирование — это всё то же самое, только на стероидах, то есть мы можем создавать потоки данных всего. И также наблюдать за ними и реагировать. Update, OnCollisionEnter, Coroutine, Event, Mouse input, Keyboard input, Joystick input — все это потоки.
Все что нас окружает это потоки.

Буфер глубины

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

Недавно мы запустили новый проект под названием Froala Design Blocks. Через несколько дней мы попали в список самых популярных репозиториев GitHub. Спустя неделю мы набрали 3500 звезд и в течении следующих двух стабильно собирали еще по 500 в сутки.



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

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

Перевод статьи Colorizing B&W Photos with Neural Networks.

Не так давно Амир Авни с помощью нейросетей затроллил на Reddit ветку /r/Colorization, где собираются люди, увлекающиеся раскрашиванием вручную в Photoshop исторических чёрно-белых изображений. Все были изумлены качеством работы нейросети. То, на что уходит до месяца работы вручную, можно сделать за несколько секунд.

Давайте воспроизведем и задокументируем процесс обработки изображений Амира. Для начала посмотрите на некоторые достижения и неудачи (в самом низу — последняя версия).

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

Однако даже генераторы реальных случайных чисел (RNG), собирающие непредсказуемые данные физических явлений, имеют недостатки: они могут быть громоздкими, медленными и дорогостоящими в производстве. Нет никакой гарантии, что проприетарная система не открыта для спецслужб — поэтому разработчики FreeBSD, отказались от непосредственного использования аппаратных генераторов, встроенных в чипы Intel.

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

ETL – аббревиатура от Extract, Transform, Load. Это системы корпоративного класса, которые применяются, чтобы привести к одним справочникам и загрузить в DWH и EPM данные из нескольких разных учетных систем.

Вероятно, большинству интересующихся хорошо знакомы принципы работы ETL, но как таковой статьи, описывающей концепцию ETL без привязки к конкретному продукту, на я Хабре не нашел. Это и послужило поводом написать отдельный текст.

«Я не злюсь, я просто разочарован.»
— PM



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

Представляем вам чеклист из 50 пунктов для самопроверки. Вот примерные подразделы:

1. Логин и регистрация
2. Первый опыт
3. Важные детали
4. Запуск
5. Профиль
6. Безумные потоки

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

Добрый день, я занимаюсь разработкой сервиса по прогнозированию спроса на базе Microsoft Azure, Spark Apache в IT компании. В цикле статей я расскажу про реальные бизнес кейсы из российских реалий, с которыми сталкивается IT компания. В основном статьи будут про бизнес: есть клиент, есть его задачи, нужно найти способ как их решать и доказать менеджменту адекватность расчётов, далее уже внедрение.

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

Первый бизнес-кейс

Компания хочет понять сколько у неё потерь (очень круто, когда компания сразу знает, что хочет), и как можно их уменьшить.



Цель поставлена. Теперь немного о компании: Федеральная сеть 400 розничных магазинов. Пилотную версию проекта договорились проводить с одной категорией товара – 20 sku, средний срок годности продукта 15 дней.

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

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

Некоторое время назад выполнял я заказ для одной конторы. Суть проекта сейчас не важна (это был некий довесок к их корпоративной системе, который они ставили на компы своим клиентам), одним из требований было что бы приложение отправляло отчет об своем использовании. А попросту говоря, ребята хотели знать насколько их программа востребована среди клиентов. И вот на этой волне, возник у меня вопрос — а действительно, написал ты программу, отдал |продал в добрые руки или просто выложил ее в интернет. И что дальше? Сколько реальных пользователей ее увидели?

О том, как мы выбирали систему мотивации для разработчиков Calltouch, рассказывает руководитель разработки Роман Хохлов.


Источник изображения

Тема оценки эффективности персонала, расчетов KPI, мотивации и премирования стара, но будет жить еще долго. На форумах наталкиваемся на множество нескончаемых дискуссий и холиваров. С точки зрения оценки эффективности труда разработчиков, да и в ИТ в целом, ситуация еще сложнее — копий сломано не мало. Работа разработчика — это производство и интеллектуальный труд в тесной связке, которые оценить и измерить достаточно сложно. Плюс результат применения того или иного подхода напрямую зависит и от руководителя, и от команды, и от организации процесса — какие-то внедренные подходы работают, какие-то не работают и даже вредят.

Германия — очень популярное направление IT переезда в последние годы (да и не только IT, конечно). Но так ли просто переехать туда? Нет, к сожалению, не просто.

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

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

Компания-заказчик: Catchmyflight.se

Не так давно к нам обратилась небольшая компания из Швеции, занимающаяся перевозками пассажиров из аэропорта Skavsta в Stockholm и обратно.

К глубокому разочарованию многих, VR-индустрия испытывает тревожное затишье. Появление первого поколения потребительских шлемов не сопровождалось ни появлением впечатляющего контента, ни переносом существующих ААА-видеоигр (Skyrim и Fallout 4 не считаются), а VR-аркады остаются редкостью по сей день.

Конечно, процесс адаптации новой технологии занимает время. Даже iPhone не сразу покорил весь мир. По мнению директора по инновациям Game Insight Андрея Ивашенцева, сейчас VR-технологии находятся на стадии привлечения первых последователей.

Как это влияет на коллектив, менторство, качество кода, а также вопрос денег

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

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

Мы в Alconost перевели статью о том, насколько рискованно полагаться на команду молодых разработчиков и как такая ситуация влияет на опытных разработчиков, менторов и качество продукта.

Все переплетено, море нитей, но.
Потяни за нить, за ней потянется клубок.
Этот мир – веретено
_{Oxxxymiron – Переплетено}

Мир построения крупных ИС в топ-100 компаниях, как и любые другие ИТ-направления, подвержен веяниям моды. Еще пять лет назад SOA казалось решением всех проблем сложных архитектур. Банки и крупные ритейлеры активно перестраивали свои системы в интеграционном SOA-стиле. BPM-платформы внедряли там, где руководство придерживается современного подхода в построении бизнес-приложений и интеграционной архитектуры самой компании.

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

Но велико число тех организаций, где всё делается «по-старинке» — такие заказчики очень часто мыслят категориями имеющихся у них ИТ-систем. Мол, «мы купили вот такую крутую CRM-систему и счастливы». Или «у нас есть SAP ERP, нам его хватает на все случаи жизни». Хотя на самом деле сложности возникают: нередка ситуация, когда компания приобретает какую-то систему и начинает нашпиговывать её несвойственной ей функциональностью и ставить задачи, на которые вендоры и не рассчитывали. В итоге система превращается в неповоротливого монстра, чьи дополнительные возможности плохо задокументированы, с ней очень тяжело разбираться и работать. И самое главное — её тяжело развивать.

Вторая распространённая ситуация: каждый отдел внутри организации лепит что-то своё. В одном подразделении скачали Open Source систему учёта заявок, в другом заказали решение у местного программиста, и так далее. В итоге возникает зоопарк систем, решающих одни и те же задачи.

И выходом из двух этих крайних ситуаций по-прежнему являются интеграционные и BPM-решения. Замечательные представители которых — Oracle SOA Suite и Oracle BPM Suite. Что это такое и зачем они нужны?