Привет! Меня зовут Анна Наумова, сейчас я работаю старшим менеджером по продукту (Senior Product Manager) в компании Zello в Остине, штат Техас. Сначала я сама прошла 110 собеседований в Америке, а теперь сижу по другую сторону стола и помогаю подбирать инженеров в команду. Хочу рассказать про то, с какими трудностями столкнулась, и к чему быть готовым во время интервью с продактами в США.


Наша команда Zello

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

Так, например, для определенного Рида-Соломона кода (РС-кода) необходимо установить:

• длину n кодового слова (блока);
• количество k информационных и N-k проверочных символов;
• неприводимый многочлен р(х), задающий конечное поле GF(2^r);
• примитивный элемент α конечного поля;
• порождающий многочлен g(x);
• параметр j кода;
• используемое перемежение;
• последовательность передачи кодовых слов или символов в канал и еще некоторые другие.

Здесь в работе рассматривается несколько другая частная задача — моделирование собственно РС-кода, являющаяся центральной основной частью названной выше задачи анализа кода.

Привет! Меня зовут Женя, я Java-разработчик в Usetech, в последнее время много работаю с микросервисной архитектурой, и в этой статье хотела бы поделиться некоторыми моментами, на которые может быть полезно обратить внимание, когда вы пишете новый микросервис на Spring Boot.

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

6 августа сего года Microsoft объявила о выходе релиз-кандидата TypeScript 4.0. Там появилась поддержка кортежей с маркированными элементами (Labeled Tuple Elements). А это — именно то, появления чего я ждал в TypeScript.

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

Почему я этого ждал? Объясню это на примере разработки функции.

Несколько лет я писал код, а мне за это платили. За это время я узнал о некоторых неприятных вещах, касающихся работы программиста. Мне всегда хотелось написать об этом. Надеюсь, вы понимаете, что я рассказываю вам всё это не для того, чтобы вас расстроить. Я считаю эту статью особым нигилистическим подарком для всех, кто готов такой подарок принять.



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

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

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

Всем привет!

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

Представьте что у вас команда специалистов, которая по принципу code-first делает систему с множеством бизнес-историй на базе микросервисов. Все люди опытные, всем есть что делать кроме того как писать документации или спецификации на разработанный API. И все изначально знают, что если захотел использовать какой сервис, то надо заглянуть в код и потом спросить в общем чате если что непонятно. Знакомая ситуация не так ли? -))) И в целом все нормально, если бы со временем не росла команда, не росло количество сервисов и функций, не появлялись баги от бизнеса и тестеров, не требовалось предоставлять API для интеграции смежным командам...

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

Недавно сменил очередное место работы, я программист, Team Lead, PM, BA, Data Analytic, HR, QA, CTO, продюсер и психолог (последнее и по образованию, и по факту).

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

Приведу пример. Если вы как-то связаны с it, то, наверное, вам удавалось слышать такие фразы как:

• Я уже 3 года, тут работаю, а он только пришёл
• Front End ничего не смыслит в Back End
• Менеджеры надоели со своими бесполезными митингами
• Дизайнеру это просто вправо подвинуть, а нам переделывать неделю

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

Перевод статьи подготовлен в преддверии старта курса «Разработчик C#».

---

Одной из наиболее важных функций .NET Core 3.0 и C# 8.0 стал новый IAsyncEnumerable<T> (он же асинхронный поток). Но что в нем такого особенного? Что же мы можем сделать теперь, что было невозможно раньше?

В этой статье мы рассмотрим, какие задачи IAsyncEnumerable<T> предназначен решать, как реализовать его в наших собственных приложениях и почему IAsyncEnumerable<T> заменит Task<IEnumerable<T>> во многих ситуациях.

Ознакомьтесь со всеми новыми функциями .NET Core 3

В этой статье мы рассмотрим пример GraphQL на Java и создадим простой сервер GraphQL со Spring Boot.

Таким цыпочкам тоже нравятся примеры GraphQL на Java со Spring Boot!

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

В этой статье мы рассмотрим пример GraphQL на Java и создадим простой сервер GraphQL со Spring Boot.

На первый взгляд, dynamic в C# — просто object с поддержкой машинерии компилятора. Но не совсем.

Ядром времени выполнения является DLR (Dynamic Language Runtime) — подсистема/фреймворк для поддержки динамических языков программирования. Существует реализация под собственно C#, который идет в поставке с .NET, и отдельная для Iron-языков.

Когда мы работаем с обобщениями (generics), то CLR имеет свои оптимизации на предмет специализации оных. В тот момент, когда CLR+DLR должны работать с generics вместе, поведение написанного кода может стать непредсказуемым.

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

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

Техдир пришёл к ним, поздоровался и спросил: «Ребята, скажите честно, какой аццкий зверь меня ждёт в этом проекте? Потому что стейкхолдеры рассказали только о единорогах с радужными хвостами и розовых пони? Legacy, да?»

«Legacy, ...», — грустно ответили разработчики.

Сказка закончилась. Началась работа — и непростые решения.

Его теоремы о неполноте разгромили поиск математической теории всего. Почти сто лет спустя мы всё ещё пытаемся осмыслить последствия этого.

В 1931 году австрийский логик Курт Гёдель провернул, вероятно, один из самых потрясающих интеллектуальных трюков в истории.

Математики той эпохи искали неколебимые основы математики: набор базовых фактов, аксиом, которые были бы непротиворечивыми и полными, играя роль строительных блоков всех математических истин.

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

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?



Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.

Приветствую, дорогой читатель.

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

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

Я много раз слышал, как программисты смеются над тиммейтами, которые написали медленный код. Резкие, самодовольные фразы в стиле "этот болван четыре раза пробежался по коллекции, хотя можно было один", и тому подобное. Когда слышишь такое, сразу думаешь — ну тут все по делу, зачем делать лишние итерации? Почему нельзя изучить пару элементарных вещей, вроде принципов работы LINQ выражений в C#, и писать нормальный код? Ты смеешься над некомпетентными тупицами до тех пор, пока смеяться не начнут над тобой. И можете мне поверить — никакие знания в программировании не спасут вас от ситуации, когда вы по незнанию зафигачили квадратичный алгоритм вместо линейного.

Эксперименты

У меня зазвонил телефон.

— Алло, это Джаред.

— Здравствуйте. Я звоню вам насчёт телефонного собеседования в Гигантской Поисковой и Рекламной Компании [очевидно, это Google — прим. пер].

— Да! С нетерпением ждал вашего звонка!

— Хорошо. Можете написать алгоритм для поиска K-го самого большого значения в двоичном дереве?

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

— Можете написать тестовый пример для этого алгоритма?

Согласно исследованию Harvard Business Review, 41% женщин, работающих в IT, в итоге покидают эту сферу (по сравнению с 17% мужчин), и я понимаю почему…

Я научилась программировать в 16 лет, а сейчас мне за 30. Я получила степень кандидата математических наук в университете Дьюка. Я все еще помню свою гордость за алгоритм «хода коня», написанный на C++ в старшей школе; потрясающую головоломку — интерпретатор, интерпретирующий сам себя (курс Scheme моего первого семестра в колледже); мое увлечение различными типами разложениями матриц на C в аспирантуре; и мое воодушевление от реляционных баз данных и веб-скраперов на моей первой работе.

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

Наконец-то руки дошли до продолжения статьи "Истории о моей работе в Нидерландах" — а именно, пришла пора рассказать о деталях переезда и поделиться практическими советами с будущими трактористами. Прошу прощения у всех, кто ждал этого продолжения гораздо раньше. Не буду распространяться о причинах задержки, но поверьте, это были очень напряженные для меня месяцы, и я вряд ли мог взяться за эту статью в тот срок, который озвучивал раньше. Кстати, дорогие мои вопрошающие в личке! Вы, на самом деле, являетесь полноправными соавторами этой статьи, потому что некоторые из ваших умных и иногда неожиданных вопросов мне самому в голову не пришли бы, а другие сделали мою задачу гораздо проще. Вместо того, чтобы обдумывать план статьи, подачу и прочая, прочая, бери формат вопрос-ответ, и дело в шляпе. Уважаемые nightstalker, ATmegAdriVeR, Flem_1, dmtrr, ChingizKhalafov, Carduelis, artem2511, gri_mih, Ommonick, это ваши вопросы, вам от меня огромная благодарность. Надеюсь, от всех читателей тоже.

Ну а начну я все же с краткого рассказа о том, как я дошел до жизни в Нидерландах.