Category: it

Category was added automatically. Read all entries about "it".

cat with many words

Про программирование, выпуск 1

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

Один код для разных целей

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

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

Другой классический пример - одна константа на два случая. Определили вы, скажем, что ALPHA = 500, а потом эту константу используете как для количества товаров на странице, так и для количества товаров в имейл-рассылке. Все чудно и здорово во время разработки, но я прямо вижу, как к вам подходит пм и говорит, что 500 для рассылки много, дава 10, а у вас эта константа уже по всему коду распихана, и никто уже не вспомнит, что именно и для чего.

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

Самодокументируемый код

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

Например, мы футер будем добавлять только для бананов.

hasFooter := productKind == 'bananas'

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

Но даже второй подход не помогает программисту понять, с какого хера футер должен появляться только для бананов. Почему?

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

Читаете вы код, а там вдруг без объявления войны:

bla.ToString()

Что это значит? В сообщении к коммиту об этом написано не будет. Вы же не помните уже наверняка, что когда-то дебажили библиотеку Х версии 1.2.3, и в ней есть внутренный кеш, который можно так заполнить. И как переменную не называй, ничего не поможет, только правильно составленный комментарий спасет. Причем не только в стиле // fill the cache for library x, а развернутый - dima: we're using library x to send emails. To make it faster we need to warm up library to generate all emails faster. Имя поможет тем, кто будет медитировать над этим кодом через 22 ребейза и три хард пуша.

cat with many words

Весь опенсорс в паре тредов.

Каждый, кто подключал наушники в ubuntu или любом другом дистрибутиве, в какой-то момент задавался вопросом: почему все так херово? Смартфоны, другие операционки - везде все норм, но под линукс ничего не получается. В моем случае это выглядит так. Если под мак можно пользоваться встроенным в наушники микрофоном, и все будет работать, то под линукс переключение на внутренний микрофон приводит к автоматическому переключению на другой профиль, который обеспечивает качество звука уровня телефонного звонка. Чтоб стало еще понятнее, это все происходит не тогда, когда именно начинается звонок, а частенько случайно при подключении наушников.

Начав рыться, я быстро понял, что вообще говоря проблема не с моими наушниками конкретно, а с поддержкой нужных кодеков в pulseaudio. Еще круче, также требовались определенные изменения в ядре. И, на минутку, вопрос затрагивает bluetooth, один стандарт которого тянет на 1000 страниц, и он настолько кудрявый, что одного понимание его работы дорогого стоит.

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

Этот тредик отражает основные проблемы опен-сорса. Если нет корпорации, которая стояла бы за продуктом, то:

  • Разработчики будут работать над тем, что им нравится, а не то, что нужно пользователям
  • Пользователи по инерции будут думать, что им кто-то что-то должен
  • Изменения не будут мерджиться годами
  • У самого популярного проекта может быть близкое к нулю количество мейнтейнеров

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

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

Чтобы было понятно, что приведенный пример - не частность, упомяну еще парочку из тех, которые когда-то затрагивали меня. Ветераны помнят, что когда-то, в эпоху mp3 файлов в рунете, во многих из них названия треков записывались в кодировке windows-1251. В винде все отображалось прекрасно, под linux - бито. Почти ко всем клиентам появились патчи с исправлениями - хотя бы настройкой с выбором кодировки, но в большом количестве клиентов эти изменения не принимались, так как по стандарту в тегах должен быть unicode, и ничего больше. И все.

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

И вроде бы все происходящее - личное дело людей, поддерживающих эти программы. Им даже никто не платит, в конце концов. Но на самом деле нет, особенно, когда эти программы начинают использоваться как основной компоненты множества дистрибутивов. В результате конечные пользователи сталкиваются с большим количеством плохо работающих программ, и в каждой из них решение проблемы затрагивает несколько компонентов, авторых которых имеют свое мнение и всякое говно мерджить не будут. Если таких людей набирается много (часто достаточно одного), то изменения не попадут в основную ветку и через несколько лет.

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

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

cat with many words

Laravel

Волею судеб покодил немного на php, конкретно под Laravel. Очень адекватный фреймворк, надо сказать. После экспериментов с джангой показался глотком свежего воздуха - все сделано понятно, ручки писать просто, всякие очереди с кронджобами поддерживаются в лет. Валидация сделана просто и понятна, легко настраивается и сделана отдельно от конкретных кейсов, так что можно один и тот же валидатор использовать что для аякс ручек, что для простых запросов, что для json, который прилетел откуда-то еще. ORM вполне нормальный, миграции отличные.

Что понравилось в нем меньше всего, так это разные фасады. В язык всеми силами подвозили типы, а здесь разрабы бабац и сделали классы, по которым не поймешь, что на самом деле происходит. Почему? Да потому, что везде и всюду динамический вызов методов, и если автор фасада не догадался перечислить все поддерживаемые методы, то хрен вам, а не подсказка типов в vscode. А вроде ведь интерфейсы в языке теперь есть. Вообще, после джавы и го сложно понять страсть к таким динамическим штуками, их ведь даже грепать сложно. Другой пример - ответ от http клиента, в котором геттеры генерируются автоматически. Чем это помогает? Если они просто проксируют значение переменной без модификации, что толку ноль. Есть гибкая поддержка разных хранилищ для файлов, но опять же в виду динамизма и хелперов, которые используются без единого импорта, очень сложно понять, что сохраняет куда, в некоторых случаях сохранить элементарно (как при сохранении формы с файлом), в других надо руками проверять, создана ли папка и т.д. и т.п.

Отдельный косяк, который сильнее всего чувствуешь, написав какое-то количество кода на го - это нетипизированный ввод. Поясню: в го невероятно дешевые типы, обхявлять их просто, парсить тот же json в структуры - элементарны. Это развращает! После такого волосы на голове шевелятся, когда тебе надо опять раз за разом печатать сырой json объект в консоль только чтобы посмотреть (опять), что там и где лежит. Но здесь уже не про php, а про жизнь.

cat with many words

Инфра определяет сознание

В индустрии ПО очень любят говорить о том, что продукт всегда развивается согласно организационному делению в компании. Очевидная правда в этом есть, но есть еще один момент, о котором говорят меньше.

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

Кроме легкости/сложности каких-то задач также важен набор примитивов в наборе у программиста. Если для любого нового проекта можно легко подтащить переводы, базу, платежи подключить, да что угодно еще, то новые продукты растут гораздо проще.

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

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

Понятное дело, что можно сразу найти пример, что Ваня, вот, таки сделал. Но это чаще всего именно вопреки. Ваня молодец, но его мало, и он скоро совсем выдохнется, пошлет всех и уволится, а что делать остальным?

Принцип работает во всех плоскостях - развитие города или там личные планы.

cat with many words

Бег по граблям

Программирование - ужасно увлекательное занятие, можно решать самые разные задачи, получать самые удивительные результаты. Но как и во всех делах в реальности решение прекрасных интересных задач занимает 20% времени, а все остальное - это разборки с тем, почему штука икс не работает, как надо. Самый хороший вариант - это когда ты упираешься в возможности системы и это решаешь. Чаллендж, или ты ее, или она тебя.

Но иногда огребаешь на ровном месте. Сегодня поставил андроид студию из официального, блин, источника. Шел шажок за шажком по туториалу, по сторонам не смотрел. И все-равно у этой скотины в какой-то момент просто перестал работать эмулятор без видимых на то причин. И вот, вместо решения интересной и увлекательной задачи, начинаешь нарезать круги в гугле и стековерфлоу, чтобы понять, что обозначает очередной загадочный стектрейс. Ах да, права не прописали, ах да, в убунте проявился такой баг в новой версии андроид студии. Ах да, просто какая-то адская борода из стектрейсов в логах по неизвестной причине. Программисты, помните. Каждый раз когда вы выпускаете на волю плохоотлаживаемое непрозрачное непонятное говно, где-то на земле очередной программист решает послать все к какой-то там матери и поехать жить в лес, как можно дальше от людей вообще и от таких программистов как вы в частности. Умирает ли при этом котенок?

cat with many words

Про будущее

Многие годы стандартной шуткой линуксоидов на первое апреля было, что майкрософт выпустит дистрибутив microsoft linux, и вот на тебе, заявлено ядро в составе системы. А еще, помню моего коллегу с одной из бывших работ, который любые новости про Теслу встречал со словами "ну вот когда они сделают x / будут ездить в условиях y, тогда и поговорим". Наверное и сейчас так говорит. Не знаю, как в России сейчас, в Европе кругом и всюду стремительный рост электрического транспорта. В Амстердаме куда ни плюнь уже электричекие такси, автобусы, грузовики, теслы и прочие электромобили встречаются тоже во всех углах. Хотя нет, вот когда они по тундре 10000 км проедут, тогда и поговорим.

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

cat with many words

Абстракции

Все, что нужно знать об абстракциях - это то, что они начинают терять товарный вид, как только на них посильнее надавишь, а иногда и этого не надо. Говорят тебе, у нас лучшая база данных, просто сделай db.set(key, value), чтобы записать, а потом db.get(key), чтобы прочитать. Вроде бы надо радоваться и спокойно пользоваться, но боевые раны уже начинают напоминать о себе, потому что даже в этом случае есть миллион разных вариантов, когда что-то может пойти не так.

  • А что там с репликацией?
  • А что происходит, при одновременной записи из двух мест?
  • Из разных тредов?
  • Какого размера может быть ключ?
  • А какого размера может быть значение?
  • А как делаются бекапы?
  • Как решаются конфликты?
  • И с авторизацией как?
  • Что будет, если процесс умрет где-то в середине?
  • Что если машина умрет?
  • А если сеть будет лагать, пакеты теряться?
  • А что там с консистентностью данных?
  • А как понять, что что-то пошло не так?

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

cat with many words

Почему я написал cl-journal

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

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

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

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

cat with many words

Из прочитанного. Выпуск 36

1) Java Performance, Charlie Hunt, Binu John

5 / 5

Подробная книжка про оптимизацию java-программ. Вступительная глава дает общую картину, где у приложения (не только на яве) может проседать производительность, а далее идет уже jvm-специфика. После объяснения работы jvm, поясняется как работает там сборщик мусора. В jvm применяется generational сборщики мусора. Это означает, что делается предположение, что объекты в памяти живут либо очень мало, либо очень долго, и на основе этого в подсистеме памяти выделяется четыре области - ясли для всех новых объектов, средняя зона, куда переносят более долго живущие объекты из яслей, большая область для старых объектов и четвертая статичная зона, где распределяется память для служебных объектов jvm на подобии объектов классов.

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

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

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

2) High performance MySQL, Baron Schwarz, Peter Zaitsev, Vadim Tkachenko

5 / 5

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

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

  • В MyISAM блокировка на запись по табличная, в InnoDB построчная, но!
  • Индекс в InnoDB строятся на основе двоичных деревьев. Из этого следует несколько выводов. Первый - именно по этому индекс используется, если в запросе используются полонки, указанные в индексе подряд, начиная с первой. Из-за этого InnoDB очень легко делать выборки по диапазанам данных.
  • Второй - блокируются не только строки, которые непосредственно изменяются, а вообще все строки, которые были выбраны индексом.
  • Первичный ключ всегда хранится прямо в индексе, другие колонки хранятся в индексе только если они в нем указаны. Что это значит? Это значит, что если выбирать только колонки, которые есть в индексе, можно избежать чтения самих строк с жесткого диска.
  • Во многих ситуациях производительность может резко падать из-за того, что MySQL не может проделать всю операцию в памяти, в этом случае данные пишутся во временную таблицу на диске, и там уже фильтруются/сортируются с соотвествующим пенальти по производительности. В этом случае надо гонять explain и смотреть, из-за чего так происходит
  • Оптимизацией запросов занимается сам Mysql, движки хранения могут ему только подсказать примерную оценку стоимости тех или иных операций. Как результат, не всегда выбираемая стратегия будет на самом деле самой быстрой.
  • Касательно оптимизаций, в MySQL за годы накопилось куча разных эвристик, которые оптимизируют запросы. Подстановка констант, переделка джойнов и еще много всякого.
  • Репликация в MySQL происходит с помощью бинлога, в который записываются все запросы в базе с поправкой на подставленные переменные, которые потом проигрываются на репликах мастера.
  • По курсорам, views и хранимым процедурам прошли вскользь, но я не фанат, как не фанат и сложных sql запросов.
  • Репликация - master/slave, master/master, которые по сути все-равно master/slave, типичные схемы.
  • Интересно про партицирование, которое оказалось не шардированием, про которое я подумал сначала, а именно что разбиением физического хранилища по признаку. Вроде полезно, но вполне возможно, что на этом этапе нужно уже другое хранилище использовать.
  • Про шардирование не было ничего mysql специфичного. Способ разбиения все-равно надо выбирать самому и поддерживать его в коде приложения.
  • Есть главы про бекапы и про тюнинг конфигурации, но я прошел их вскользь, просто потому, что их всегда можно прочитать потом при необходимости.

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

3) Gen Z @ Work, David Stillman & Jonah Stillman

3 / 5

Наверное, мне просто не зашла манера написания авторов. Суть книги показать уникальные черты, которые отличают поколение Z (1995 - 2010). Если просуммировать в двух словах - родители влияют на своих детей, то, что одно поколение только осваивает, следующее считает уже естественным. Второй момент - книга написана для американского рынка, в случае России новейшая история внесла свои коррективы.

Одно интересное наблюдение, про которое я не думал раньше: люди растят друг друга в среднем через поколение. Т.е. Бэбибумеры, которые родились после войны, растили миллениалов, поколение икс, которое шло следом, растило уже поколение Икс. Соответственно, события, повлиявшие на родителей, наносили свой отпечаток на детей. Как пример, авторы говорят, что бэбибумеры и миллениалы - это гораздо более оптимистичные и позитивные поколения. На поколение икс пришлись 80е со своими кризисами, это было первое поколение, выросшее в обнимку с телевизором при обоих работающих родителях. Если среди родителей было много разводов, как в случае с поколением икс, то как реакция, в этом поколении частота разводов резко снизилась (опять же, в случае штатов). Поколение Z тоже выросло не в самое лучшее время, они видели, как их родители переживают кризис 2008 года, и мир они воспринимали уже в этом ключе.

На этом сильно интересная чатсь книги для меня закончилась, пошли конкретные описания повадок поколения Z. Стиль подачи - сын из поколения Z помогает отцу понять это поколение и заодно пишет с ним эту самую книгу и ведет бизнес, отгадайте какой. Да, они всем рассказывают про особенности поколений!

Что можно узнать про поколение Z? То, что ото первое поколение, имевшее аккаунт на фейсбуке или аналоге всю сознавшую жизнь и не представляющее жизнь без ютуба со всеми вытекающими. Если миллениалам в интернете комфортно, то для этого поколения это просто среда обитания. Это первое поколение, привыкшее к супер кастомизации, когда можно детально подобрать любую деталь жизни - не только одежду, но и круг общения, способ и тематику обучения, даже музыку по трекам, а не альбомами (тут я сразу вспомнил дивные плейлисты для винампа или вк, которые имел каждый русский подросток в середине 2000х). Это поколение не любит навешивания ярлыков, привыкло, что все их шаги так или иначе видны онлайн (те же онлайн дневники школьные) и поэтому ожидает подобного же отношения и на работе. Плюс, там же на работе им не нравится иметь фиксированный тайтл и набор обязанностей, хочется чего-то, специально под них. Дальше я книгу уже начал листать, потому чего-то принципиально нового для себя уже не открывал, слишком близкое поколение видимо.

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

cat with many words

Вторичность

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

Для меня самая очевидная разница - технологическая. Сейчас есть две точки на Земле, откуда появляются технологические гиганты, которые действительно что-то приносят в мир - США и Китай. Говоря США, мы подрузамеваем силиконовую долину, ну и может быть Нью-Йорк. Говоря Китай, мы ничего особо не подразумеваем, потому что там нет настолько же разрекламированных мест. Условно, мы знаем про Шанхай и про Юго-восточное побережье. Но речь не о географии.

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

Может самый продвинутый проект по производству беспилотных машин находится где-то еще? Нет. Что бы вы не вспомнили, все там. Если вы разберете дистрибутив линукса и посмотрите на историю коммитов в самых важных проектах, внезапно окажется, что большинство их сделали американцы (в широком смысле этого слова).

Про Китай другой разговор. Их экосистема замкнута, не так часто видно проекты на гитхабе и т.д. Но с конца восьмидесятых там выросла куча технологических гигантов на все фронтах - Tencent, Huawei, Ali baba ну и далее по списку. И если раньше было смешно, то теперь у них четверть рынка смартфонов, сетевое оборудование и много чего другого. Так много его, что другие страны опасаются за свою безопасность.

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