Представьте что у вас команда специалистов, которая по принципу 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, это ваши вопросы, вам от меня огромная благодарность. Надеюсь, от всех читателей тоже.

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

Чтобы проводить расследования по открытым данным в интернете, совершенно не обязательно обладать сверхтехническими познаниями.

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

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

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

Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова “стоп” в количестве обязанностей на 1 человека.

Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на “облако” выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.

Несколько лет назад я читал на Хабре про скандал разраба Алексея Адамовского с компанией Xored. Липкий кейс, компания не заплатила человеку деньги, и для меня сразу стал очевиден главный враг в этой истории. Непонятно было другое. Адамовского наняли работать в новосибирском офисе компании, а он очень хотел поработать в пражском. За те же деньги. Кое-как уговорил их и уехал туда. В целом его право, но меня тогда очень задело другое — неужели человек настолько ненавидит жить в РФ, что готов смотаться отсюда на любых условиях?

Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретаторов для нескольких языков, в числе которых Zortech C++ — первый нативный компилятор C++. Он также создатель игры Empire, послужившей основным источником вдохновения для Sid Meier’s Civilization.

Язык D был с самого начала спроектирован так, чтобы легко и напрямую обращаться к C и, в меньшей степени, C++. Благодаря этому в нём доступны бесчисленные C-библиотеки, стандартная библиотека C и конечно же системные API, которые как правило построены на API языка C.

Но C — это не только библиотеки. На C написаны многие большие и неоценимо полезные программы, такие как операционная система Linux и значительная часть программ для неё. И хотя программы на D могут обращаться к библиотекам на C, обратное неверно. Программы на C не могут обращаться к коду на D. Невозможно (или по крайней мере очень сложно) скомпилировать несколько файлов на D и слинковать их в программу на C. Проблема в том, что скомпилированные файлы на D могут обращаться к чему-то, что существует только в рантайме D, а добавлять его в линковку обычно оказывается непрактично (рантайм довольно объёмный).

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

Так было до тех пор, пока не появился Better C.

Первый прототип подводного дата-центра компания Microsoft разработала и погрузила под воду еще в 2015 году. Его нарекли Leona Philpot, а сам проект получил название Natick.

Первая модель подводного центра была небольшой, все необходимое оборудование поместили в контейнер габаритами 3*2 метра. Управление — дистанционное, поскольку людей внутри по понятным причинам не было. Прототип проработал без проблем в течение 105 дней. Компания Microsoft признала эксперимент успешным. Энергоэффективность ДЦ очень высокая. Шутка ли, показатель PUE составил всего 1,07. После того, как дата-центр разобрали и проанализировали его состояние, проект решили продолжать.

«Каспийский монстр» — советский экраноплан, который весил 544 тонны, что делало его самым тяжелым летательным аппаратом в мире. Сделан с нуля за два года. Думай об этом, закачивая лэндинг по продаже трусов «всего» за полгода.

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

Если вы ещё не заметили — интернет уже не та либертарианская утопия, свободное конкурентное пространство и стартовая площадка с равными условями для каждого.

Такое время было, но прошло: расцвет эпохи гиков в интернете пришёлся на нулевые годы XXI века. Десятые годы стали эпохой транзита от изобретателей к маркетологам, предпринимателей к менеджерам, стартапов к корпорациям, конкуренции к монополизации.

Символическим концом этого транзита можно считать 2018 год, когда Google официально отказался от своего знаменитого морального императива Don't be evil. Вместо него теперь на главную Google в пору вешать не менее знаменитое Greed is good.

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


«Трон: наследие»: битва пользователя против программы

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