Software Developer
Привет, Хабр!
Микросервисная архитектура предлагает нам гибкость, масштабируемость и управление сложными приложениями на новом уровне. Однако, чтобы извлечь максимальную выгоду из этой архитектуры, важно правильно спроектировать микросервисы и обеспечить эффективное взаимодействие между ними.
gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.
Криптохомячкам посвящается ...
Алгоритм Гровера представляет собой обобщённый, независящей от конкретной задачи поиск, функция которого представляет "чёрный ящик" f: {0,1}^n to {0,1}^n, для которой известно, что EXISTS!w:f(w)=a, где a — заданное значение.
Считаем, что для f и заданного a можно построить оракул Uf: { |w> to |1>, |x> to |0> if |x> != |w> }
Применим этот алгоритм для решения задачи нахождения ключа шифра Цезаря ...
__________На уровне системы
Много лет работаю со студентами московских вузов и представляю, как там преподают английский язык. Не жалуются (в силу очень специфических причин) студенты только трёх: МГЛУ, МГИМО и МФТИ.
В коридорах только и разговоров, что английский всем нужен. Но вот всё что‑нибудь неладно: то «языки — не моё», то «не могу сдвинуться с мёртвой точки», то «языковой барьер»... Что за атмосфера мистики вокруг иностранных языков? Почему до сих пор нет признанной технологии качественного учебного процесса и подготовки преподавателей?
В спорте давно поняли, что по чемпионским программам можно тренировать только суперодарённых детей. Остальных эти программы загонят, просто физически могут покалечить. Зато такое «равнение на лидеров» широко распространено за пределами спорта, поскольку не влечёт немедленного и явного физического ущерба. Постоянно вижу что‑нибудь вроде: «Как учить язык: советы полиглота». Полиглоты функционируют на другом уровне абстракции за счёт уже выученных языков, а при запоминании опираются на несопоставимо большее количество ассоциативных связей. И даже свой первый иностранный язык они учат с огромным преимуществом перед средним изучающим.
Советы и мнения по поводу изучения языков часто подкрепляются тем, что так сказал‑де переводчик‑синхронист, или профессор иняза. Люди, хорошо владеющие языками (в том числе преподаватели), обычно имеют несовместимые с реальностью представления о том, как их надо изучать. Это не парадокс: почти везде языки дают плохо, и реально выучивают их, как правило, довольно способные люди. Для них не нужно особого преподавательского мастерства или специальных приёмов — они воспримут любой способ подачи материала. Что‑то сами додумают. А потом всю жизнь рассказывают, как замечательно «это работает».
При начале разработки нового проекта у моей команды всегда появлялся вопрос, какую библиотеку выбрать для межсервисного взаимодействия? А какую использовать для походов в сторонние сервисы? В этой статье я постарался вкратце осветить различные обёртки над HttpClient.
Продолжаем разговор об историях массовых увольнений в Интел. Двум памятным случаям из моей практики и будет посвящена эта глава.
В продолжение темы о метаниях компаний между удаленным, офисным и гибридным форматами хочется поговорить о бизнес-процессах. Любой из форматов работы будет хорош, если нормально эти самые процессы выстроить. А сотрудники не станут возмущаться, если не менять правила игры прямо “в полете”.
Мы в свое время настроили удаленный формат и работаем так уже почти семь лет. Продолжаем допиливать детали, но в общих чертах можем отчитаться о том, что “контроль без контроля” действительно работает. В этой статье рассказываем, как он устроен.
Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.
В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.
В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.
Статья состоит из шести разделов:
Американские граждане испытывают особый пиитет к лотереям, нашедший отражение в массовой культуре, а люди с нетерпением ждут очередных розыгрышей, формируя многомиллионные рейтинги телеканалам, транслирующим мероприятия в прямом эфире.
Однако в 1969 году всё приняло не стандартный оборот: в прямом эфире по указу президента Ричарда Никсона была проведена лотерея, в которой победители получали не денежный чек, а возможный билет во Вьетнам.
В измерении продуктивности разработчиков хорошо то, что можно быстро выявлять плохих программистов. Я хочу рассказать вам о самом плохом программисте, которого я знаю, и о том, почему я сражался за то, чтобы его оставили в команде.
Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю, её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.
Продолжаем наш ретроспективный цикл о тех советских разработках, которые стали историей и за которые, как принято говорить — “не стыдно”. В предыдущих постах цикла мы уже затрагивали разработку языков программирования в СССР и в этом посте хотели остановиться на ней подробнее. Несмотря на достаточно скромные достижения в этой области, разработчики языков и трансляторов знали моменты триумфа, а фундаментальный вклад советских ученых в развитие программирования ощутим и сегодня. Под катом немного о языках и трансляторах, разработанных в Стране Советов в 50-е — 60-е годы, а также об их создателях.
Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...
Заявление звучит довольно громко и, я бы даже сказал, провокационно. Но в последние годы я всё больше и больше считаю, что это утверждение действительно верно, и хочу подробно объяснить, почему.
Статья (скорее всего, временно) переехала сюда: https://habr.com/ru/articles/803719/
Администрация приносит извинения за доставленные неудобства.
«ЗНАТЬ иностранный язык» и «УМЕТЬ на нём разговаривать» — это очень разные вещи. Письменные переводчики знают язык глубоко, но разговаривают некоторые из них хуже девочки-секретаря, которая ловко оперирует двумя-тремя сотнями заученных фраз. У них разные задачи: переводчик имеет дело со сложными текстами, а работа секретаря — короткие типовые разговоры.
Если человек уже знает иностранный язык, научиться говорить для него — вопрос нескольких дней или недель. Вот что по-настоящему сложно и к чему нужно стремиться — так это выучить язык, т. е. понять, как в нём связываются слова друг с другом, понять внутренние принципы, по которым он работает.
«Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка». Эту фразу из несуществующих слов предложил в начале XX века академик Л.В. Щерба. Из неё ясно, что "будлану́ла" — действие, которое ку́здра (ж.р.) совершила в отношении бо́кра (м.р.); бокрёнок, скорее всего, детёныш бокра. Для русского это очевидно сразу. Иностранцу придётся сначала выучить русский. Фраза показывает, что язык — это НЕ СЛОВА. Слова легко переходят из одного языка в другой. Язык — это принципы, по которым слова связываются друг с другом.
В том, чтобы научиться говорить, абсолютно ничего сложного нет – проблема это придуманная. А основная причина частых неудач — это то, что люди, как говорится, put the cart before the horse, ставят телегу впереди лошади. Пытаются говорить, не разобравшись, как связываются слова в языке. Это как пытаться бегать, не научившись ходить.
В статье не рассматривается уровень руссо туристо, когда говорят наполовину инфинитивами, наполовину знаками – это вообще не язык, строго говоря. Под умением «говорить» подразумеваются три уровня:
Как скомпоновать приложение? Какие в нём должны быть слои? Как назвать пакеты? Где расположить DTO, маперы, реализации интерфейсов? И нужны ли вообще интерфейсы? Когда новичок попадает в свою первую компанию, очень часто на эти вопросы у него нет однозначного ответа. Он смотрит код своих коллег, и тут уж как повезёт - если команда сильная, у новичка есть все шансы научиться писать хороший, чистый, код. Если же не повезёт, то новичок будет цепляться за то, что есть, нахватается плохих практик, и по прошествии года-двух он уже сам будет себе авторитетом, которого не так-то просто будет переубедить.
В посте ниже я описываю личный и командный опыт, под который я постарался подвести теоретическую базу, опираясь на "Чистую архитектуру" Роберта Мартина. Да, этот пост - для новичков, хотя, эта тема жива и среди устоявшихся программистов, поскольку споры о компоновке приложения не утихают и среди сениоров.
Зайду я немного издалека и напомню, что такое луковичная архитектура.
В разработке программного обеспечения иммутабельным (immutable — неизменяемым) называется объект, который после своего создания не может быть изменен. Зачем вам может понадобиться такой объект? Чтобы ответить на этот вопрос, давайте проведем анализ проблем, которые могут возникнуть в результате мутации (изменения) объектов. Вернемся к основам того, что делает каждое приложение: создает, извлекает, обновляет и удаляет данные (CRUD-операции). Ядро любого приложения манипулирует объектами. Ответ на вопрос о том, работает ли приложение в соответствии со своей спецификацией, в первую очередь определяется правильностью обработки данных. Вам необходимо быть уверенными, что код работает правильно, каждый раз, когда он затрагивает какой-либо объект.
Но что, если бы существовали объекты, которые не могли бы изменяться? Исходя из вышеизложенного, очевидно, что если объект не может измениться, то либо не будет кода, пытающегося изменить его, либо, если такой код все-таки написан, он не будет работать.
Если ваше приложение является многопоточным, иммутабельность должна быть фундаментальной частью вашей архитектуры, поскольку неизменяемые объекты по своей природе являются потокобезопасными и невосприимчивыми к состояниям гонки. Если ваше приложение использует data transport objects (DTO — объекты передачи данных), вам также следует серьезно подойти к иммутабельности ваших объектов. Предметом дискуссий остается лишь то, как наиболее эффективно реализовать и работать с иммутабельными объектами, поскольку C# не предлагает встроенной поддержки таких объектов. Эта статья предлагает ответ на этот вопрос.