Здравствуйте, меня зовут Дмитрий Карловский и я… люблю плевать против ветра. Утираться и снова плевать. Хобби у меня такое. И всё, что я создаю, делаю я без оглядки на тенденции, стараясь решать проблемы системно, а не как привычно. Зачастую бывает, что основная сложность даже не в том, чтобы придумать решение, а в том, чтобы объяснить другим, что проблема вообще существует.

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

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

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

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

Доброго времени суток, друзья!

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

JSON.stringify() часто используется при отладке для преобразования объекта или обычной строки в строку в формате JSON. Но как данный метод используется, и можем ли мы обойтись toString()? Давайте попробуем это сделать.

// создаем объект user
const user = {
    name: 'Harry Heman',
    age: 29,
    job: 'developer'
}

// преобразуем объект в строку, используя стандартный метод toString(), и выводим результат в консоль
console.log(user.toString()) // [object Object]

[object Object] — это не совсем то, что мы хотели увидеть, не правда ли?

Не спрашивайте, зачем мы вообще используем toString(). Предположим, что нам жизненно необходимо перевести объект в строку.

Теперь попробуем использовать JSON.stringify():

console.log(JSON.stringify(user)) // {"name":"Harry Heman","age":29, "job": "developer"}

Мы сделали это, Карл!

Однако возможности JSON.stringify() этим не исчерпываются.

Предлагаю ознакомиться с расшифровкой доклада Виталия Левченко Go vs Python

Go — волшебное слово, решение всех проблем продакшна разом и одновременно негодная технология без эксепшнов. Истина посередине, поэтому поговорим о конкретных примерах:

• asyncio vs горутины;
• производительность узких мест;
• лаконичность vs простота кода;
• порог входа;
• тулинг и паттерны поиска проблем и оптимизации производительности;
• обслуживание в продакшне.

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

Хорошим выбором для этого мог бы стать DOOM. Мегахит 1994 года от id Software был портирован на всё, что только можно. Игра спроектирована вокруг ядра, чётко разделённого на слои. Обычно легко найти и прочитать реализацию шести подсистем ввода-вывода.

Другим выбором могла бы стать Another World 1991 года от Эрика Шайи, в Северной Америке более известная под именем Out Of This World. Я бы сказал, что на самом деле её интереснее изучать, чем DOOM, из-за полигональной графики, подходящей для диких оптимизаций. В некоторых случаях хитрые трюки позволяли игре работать на оборудовании, созданном за пять лет до выхода игры.

Компания Wargaming юридически преследует своих бывших сотрудников за работу над Open Source проектом (программным обеспечением с открытым исходным кодом), который она официально развивала до весны 2018 года. Wargaming подала персональные иски к своим бывшим сотрудникам, которые на данный момент работают в ООО «БлицТим», с требованиями о компенсациях на суммы до полумиллиона долларов с человека.

Предисловие

Всем привет! Меня зовут Саша, и я больше шести лет занимаюсь тестированием бэкенда (сервисы Linux и API). Мысль о статье у меня появилась после очередной просьбы знакомого тестировщика подсказать ему, что можно почитать по командам Linux перед собеседованием. Обычно от кандидата на позицию QA инженера требуют знание основных команд (если, конечно, подразумевается работа с Linux), но как понять, про какие команды стоит почитать во время подготовки к собеседованию, если опыта работы с Linux мало или вовсе нет?

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

В преддверии нового года хочется всем тимлидам пожелать расслабиться, отпустить все трудности на работе и готовиться ĸ празднованию с семьей, с друзьями.

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

Если посмотреть его пока не было возможности, то январские праздники отличная возможность, чтобы это исправить.


Итак, немного о рабочих буднях тимлида:

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

Этой статьей мы продолжаем серию публикаций о том, как мы автоматизировали в одном из крупных проектов ЛАНИТ процесс ручного тестирования (далее – автотесты) большой информационной системы (далее – Системы) и что у нас из этого вышло.

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

Источник

В этой статье мы описываем структуру классов и организацию кода, которая позволила нам небольшими силами разработать более полутора тысяч end-2-end UI тестов на базе Junit и Selenium для крупной системы федерального значения. Более того, мы ее успешно поддерживаем и постоянно дорабатываем существующие сценарии.

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

Статья будет полезна всем разработчикам, которые разрабатывают автотесты на базе Selenium.

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



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

Наступил 2020 год, а значит, Python 2 перестал поддерживаться. Если быть совсем точным, то основные разработчики уже перестали заниматься веткой, а выход релиза 2.7.18, приуроченный к PyCon US в апреле 2020 года, ознаменует полное прекращение любой активности, связанной с Python 2.

С другой стороны, совсем недавно состоялся релиз Python 3.8, добавивший немного синтаксического сахара в язык. Python 3.9 же ожидается ещё нескоро, да и пока не похоже что добавит в язык что-то интересное.

Так что если вы вдруг ещё не отказались от Python 2, то дальше тянуть смысла просто нет: поддержка второй версии уже прекратилась, а переход сразу на 3.8 позволит использовать язык в его самом актуальном состоянии ещё долгое время.

Ну а, чтобы решиться было проще, ниже приведён обзор главных нововведений Python 3.8, которые пригодятся каждому питонисту.

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

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

Первые созданные человеком 3D-модели выглядели примерно так:


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

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

Всем привет!

Возможно, вы уже знаете про инициативу Machine Learning for Social Good (#ml4sg) сообщества Open Data Science. В её рамках энтузиасты на бесплатной основе применяют методы машинного обучения для решения социально-значимых проблем. Мы, команда проекта Lacmus (#proj_rescuer_la), занимаемся внедрением современных Deep Learning-решений для поиска людей, потерявшихся вне населённой местности: в лесу, поле и т.д.

Новый год все ближе, скоро закончатся 2010-е годы, подарившие миру нашумевший ренессанс нейросетей. Мне не давала покоя и лишала сна простая мысль: «Как можно ретроспективно прикинуть скорость развития нейросетей?» Ибо «Тот, кто знает прошлое — тот знает и будущее». Как быстро «взлетали» разные алгоритмы? Как вообще можно оценить скорость прогресса в этой области и прикинуть скорость прогресса в следующем десятилетии? 



Понятно, что можно примерно посчитать количество статей по разным областям. Метод не идеальный, нужно учитывать подобласти, но в целом можно пробовать. Дарю идею, по Google Scholar (BatchNorm) это вполне реально! Можно считать новые датасеты, можно новые курсы. Ваш же покорный слуга, перебрав несколько вариантов, остановился на Google Trends (BatchNorm). 

Мы с коллегами взяли запросы основных технологий ML/DL, например, Batch Normalization, как на картинке выше, точкой добавили дату публикации статьи и получили вполне себе график взлета популярности темы. Но не у всех тем путь усыпан розами взлет такой явный и красивый, как у батчнорма. Некоторые термины, например регуляризацию или skip connections, вообще не получилось построить из-за зашумленности данных. Но в целом тренды собрать удалось.

Кому интересно, что получилось — добро пожаловать под кат!

Современная история противостояния Intel и AMD на процессорном рынке ведёт свой отсчет еще со второй половины 90-х. Эпоха грандиозных преобразований и выхода в мэйнстрим, когда Intel Pentium позиционировался как универсальное решение, а Intel Inside стал чуть ли не самым узнаваемым слоганом в мире, ознаменовалась яркими страницами в истории не только синих, но и красных – начиная с поколения K6, AMD неустанно соперничали с Intel во многих сегментах рынка. Однако именно события чуть более позднего этапа – первой половины нулевых – и сыграли важнейшую роль в появлении легендарной архитектуры Core, до сих пор лежащей в основе процессорной линейки Intel.

Немного истории, истоков и революции

Начало 2000-х годов во многом связывают с несколькими этапами в развитии процессоров – это и гонка за заветной частотой 1 ГГц, и появление первого двухъядерного процессора, и ожесточение борьбы за первенство в массовом десктопном сегменте. После безнадежного устаревания Pentium, и выхода на рынок Athlon 64 X2 Intel представила процессоры поколения Core, ставшие в итоге поворотной точкой в развитии индустрии.



Первые процессоры Core 2 Duo были анонсированы в конце июля 2006 года – более чем через год после выхода Athlon 64 X2. В работе над новым поколением Intel руководствовалась в первую очередь вопросами архитектурной оптимизации, добившись высочайших показателей энергоэффективности уже в первых поколениях моделей на базе архитектуры Core под кодовым названием Conroe – они превосходили Pentium 4 в полтора раза, и при заявленном теплопакете в 65 Вт стали, пожалуй, самыми энергоэффективными процессорами на рынке на тот момент. Выступая в роли догоняющей (что бывало нечасто), Intel реализовала в новом поколении поддержку 64-битных операций с архитектурой EM64T, новый набор инструкций SSSE3, а также обширный пакет технологий виртуализации на базе х86.


Кристалл микропроцессора Core 2 Duo

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

Я увидел этот вопрос на Quora и начал писать ответ. Но ответ получился слишком большим, так что я превратил его в эту статью.

Вот часть изменений в случайном порядке, которые я заметил в программировании за последние 20 лет:

• Многие концепции, которые были лишь теоретическими 20 лет назад, сегодня широко применяются на практике. Например, такие функциональные парадигмы как неизменяемость объектов, хвостовая рекурсия, ленивые коллекции, сопоставление с шаблоном, функции первого класса и взгляд свысока на тех, кто всё это не использует.
• «Десктопным приложением» многие неиронично называют упакованный браузер со страницей по умолчанию и без адресной строки.

Как я делал свою первую карту на Leaflet.js.

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

Итак задание было следующее: есть черно-белый планшет (маленький кусок карты города) размером 5913x7863 пикселей в формате .bmp + .shp слои.

(изначально карты были отрисованы в формате .dwg (формат автокада), но это закрытый формат и с ним ничего не сделаешь, поэтому ребятам пришлось сохранить каждый слой отдельно в .shp + атрибутивные данные в .dbf)

Из этого всего нужно сделать онлайн карту, основной функционал которой — это вывод атрибутов при нажатии на слой и включение/отключение этих слоёв.

Выбор пал на leaflet.js, так как это оболочка с открытым кодом, на ней сделаны OSM и мой любимый 2GIS. К тому же он хорошо работает на мобильных устройствах.

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

Для отрисовки веб-карт существует несколько открытых библиотек, например, OpenLayers и Leaflet. Довольно давно наш выбор пал на Leaflet и мы продолжаем его активно использовать при реализации проектов. Для редактирования геоданных хотелось бы использовать его же и, при этом, иметь возможность интегрироваться с существующими хранилищами пространственных данных.

Для достижения последней цели как правило используются ГИС-сервера (geoserver, mapserver), которые умеют публиковать большое количество разнообразных форматов данных по стандартам OGC. Так, WMS протокол прекрасно справляется с функцией визуализации готовой карты, но не предполагает функции редактирования, для которой резонно использовать WFS-протокол с возможностью изменения данных. Запросы к WMS возвращают уже отрисованные тайлы — картинки, а к WFS — сырую информацию, «исходный код» за этими тайлами. Leaflet поддерживает модули расширения, соответственно, можно поискать готовый компонент, либо написать свой. Т.к. поиск готовых модулей для Leaflet удовлетворяющих результатов не дал, мы приступили к собственной реализации.

По статистике запросов на leaflet.uservoice.com понятно, что данный модуль интересен не только нам.

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