На основе разговоров с выпускниками ведущих вузов Москвы и комментариев на Хабре.

___Военные/сотрудники спецслужб быстро и/или эффективно выучивают языки

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

А спалишься на любой мелочи. Обычная шпана вычисляет самозванцев с полпинка: «Кого знаешь?» Штирлица не то, что не было – его быть не могло, потому что никогда ещё он не был так близок к провалу, как КАЖДУЮ СЕКУНДУ. Тем более под лупой гестапо. (Окей, персонаж Ю.Семёнова правдоподобный: набор исключительных качеств + хорошая легенда.)

Поэтому в реальной жизни разведчик работал не под видом местного, а под видом иностранца. И разведданные получал через завербованных МЕСТНЫХ чиновников и военных. Оно и сейчас так происходит. (То, что язык для разведчика – только полдела, мы даже не обсуждаем.)

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

___Про детей

Никто не спорит с тем, что они круто усваивают языки. Миф заключается в том, что они якобы делают это «легко» и/или «быстро». Очень многим детям ставят диагноз «задержка развития речи», и причины далеко не всегда патологические. Дети даже без этого диагноза в 3-м классе пишут прошедшее время глагола «цвести»: «цвестил», «цвестила». Школьные учителя могут и пострашнее истории рассказать...

По поводу детей и ин.языков: 42 секунды и с 30:02 до 36:07

Я стал большим сторонником DynamoDB за последние несколько лет. Эта база данных имеет много сильных сторон, которых нет у конкурентов, таких как гибкая ценовая модель, соединение без состояния (stateless), которое прекрасно работает для беcсерверных (serverless) вычислений, и постоянное время ответа, даже когда ваша база данных масштабируется до огромных размеров.

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

Привет, Хабр!

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

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> }

Алгоритм Гровера достаточно прост

1. Задаём в регистре (массиве кубитов) начальное значение H|0>
2. Повторяем несколько раз (исходя из оценки) пару трансформаций над регистром
   
   • Отражение от решения Uw: { |w> to -|w>, |x> to |x> if |x> != |w> } или Uw = I-2|w><w|
   • Отражение от s=H|0> Us = 2|s><s|-I
3. Забираем нужное решение из регистра (с большой долей вероятности, что оно правильное)

Применим этот алгоритм для решения задачи нахождения ключа шифра Цезаря ...

При начале разработки нового проекта у моей команды всегда появлялся вопрос, какую библиотеку выбрать для межсервисного взаимодействия? А какую использовать для походов в сторонние сервисы? В этой статье я постарался вкратце осветить различные обёртки над HttpClient.

Продолжаем разговор об историях массовых увольнений в Интел. Двум памятным случаям из моей практики и будет посвящена эта глава.

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

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

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.

В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

Статья состоит из шести разделов:

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

Однако в 1969 году всё приняло не стандартный оборот: в прямом эфире по указу президента Ричарда Никсона была проведена лотерея, в которой победители получали не денежный чек, а возможный билет во Вьетнам.

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

Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю, её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.

Продолжаем наш ретроспективный цикл о тех советских разработках, которые стали историей и за которые, как принято говорить — “не стыдно”. В предыдущих постах цикла мы уже затрагивали разработку языков программирования в СССР и в этом посте хотели остановиться на ней подробнее. Несмотря на достаточно скромные достижения в этой области, разработчики языков и трансляторов знали моменты триумфа, а фундаментальный вклад советских ученых в развитие программирования ощутим и сегодня. Под катом немного о языках и трансляторах, разработанных в Стране Советов в 50-е — 60-е годы, а также об их создателях. 

Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...

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

1. Пролог

В изучении языка есть стандартные этапы отчаяния:
- «Мне поможет только погружение в языковую среду»;
- «Что-то идёт не так, нужен какой-то особый подход» [после малорезультативного «погружения»].

На самом деле это один и тот же этап: в какой-то момент застрявшая в голове рекламная демагогия неизбежно начинает конфликтовать с реальностью.

9 из 10 жалуются: я плохо воспринимаю речь на слух… что делать… У рекламщиков ответ уже готов: «Улучшить восприятие на слух? — Приходите! Поможем!» Заканчивается всё очередным разочарованием и ещё более глубокой убеждённостью в «уникальности» своего случая. В общем, давайте разберёмся, из чего состоит аудирование.

Во-первых, не надо слишком буквально понимать знакомых, которые, якобы, хорошо разбирают речь носителей на слух. Если ты не рос в Англии, у тебя ВСЕГДА будут проблемы с восприятием речи британца. Помните, как вы хорошо понимали носителя, пока он говорит с вами, но мгновенно переставали его понимать, когда он начинал говорить с другим носителем. Как так?

Реальные живые носители произносят не совсем те слова, которые мы читаем в субтитрах. Ни в одном словаре нет слова forya (ударение на первый слог), хотя оно и распространённое (в субтитрах пишут for you). Не менее распространено слово whaddaya (в субтитрах будет what do you). То же самое в скоростной русской речи: вместо «он говорит» в реальной жизни мы обычно используем слово «онгрьт» с невнятными «н» и «т». Очсомневаюсь, что оно есть в словаре. Носитель расшифровывает «онгрьт» через 3 канала одновременно:

«Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка». Эту фразу из несуществующих слов предложил в начале XX века академик Л.В. Щерба. Из неё ясно, что «будлану́ла» — действие, которое ку́здра (ж.р.) совершила в отношении бо́кра (м.р.); бокрёнок, скорее всего, детёныш бокра. Для русского это очевидно сразу. Иностранцу придётся сначала выучить русский. Фраза показывает, что язык — это НЕ СЛОВА. Слова легко переходят из одного языка в другой. Язык — это принципы, по которым слова связываются друг с другом.

В том, чтобы научиться говорить, ничего сложного нет — проблема это придуманная. А все неудачи от того, что люди, как говорится, put the cart before the horse, ставят телегу впереди лошади. Пытаются говорить, не понимая, как связываются слова в языке. Это как пытаться бегать, не научившись ходить.

Не будем обсуждать руссо туристо, когда говорят наполовину инфинитивами, наполовину знаками. Выделим три уровня «говорения»:

1-й уровень: говорим по-простому, но +/- грамматически правильно. Например, не зная выражения «прикрой форточку», говорим проще: «закрой маленькое окно, но не до конца».

2-й уровень: говорим на конкретные темы именно теми фразами, которые используют носители языка («прикрой форточку»).

Есть реальная история про русского математика, который читал лекцию на английском в Оксфорде. Упоминал степени, корни, дроби и прочие математические штуки, которые не каждый переводчик сумеет описать без подготовки. А после лекции к нему подошла студентка и попыталась заговорить. Математик улыбнулся: «Sorry, I don’t speak English». Лекцию он прочитал настоящими фразами носителей, но за пределами описания математических формул и действий едва говорил на 1-м уровне.

Как скомпоновать приложение? Какие в нём должны быть слои? Как назвать пакеты? Где расположить DTO, маперы, реализации интерфейсов? И нужны ли вообще интерфейсы? Когда новичок попадает в свою первую компанию, очень часто на эти вопросы у него нет однозначного ответа. Он смотрит код своих коллег, и тут уж как повезёт - если команда сильная, у новичка есть все шансы научиться писать хороший, чистый, код. Если же не повезёт, то новичок будет цепляться за то, что есть, нахватается плохих практик, и по прошествии года-двух он уже сам будет себе авторитетом, которого не так-то просто будет переубедить.

В посте ниже я описываю личный и командный опыт, под который я постарался подвести теоретическую базу, опираясь на "Чистую архитектуру" Роберта Мартина. Да, этот пост - для новичков, хотя, эта тема жива и среди устоявшихся программистов, поскольку споры о компоновке приложения не утихают и среди сениоров.

Зайду я немного издалека и напомню, что такое луковичная архитектура.