Всем капиталистам хочется больших быстрых денег а не создавать что то там и улучшать что-то там. Капитализм он про капитал, бизнес в первую очередь пылесос капитала или сопротивление в "электрической" схеме движения капитала, которое норовит пристроиться в место где напряжение повыше... Улучшение это вынужденная мера - создайте тепличные условия и нормальная компания выродится в паразита, подобие глиста (зачем что то делать, если живешь в еде). Именно поэтому в США делили монополии, чтоб не зажрались и не деградировали ( монополизм снижает потенциал страны, избавление от паразитов внутри по сути)
Модель выживания - сначала продать, затем сделать, для минимизации затрат (а вдруг не отобьются?). Сначала показываем картинку, ПоС после предоплаты. В идеале. Когда репутации нет или тема новая, приходится делать демо.
Те кто вкладываются в работу, рискуют сделать ненужный продукт.
Как решить вопрос? Гарантированным заказом. Но это фу, скучно и долго.
Какие минусы? При гарантированном заказе расценки фиксированы, не получится "выстрелить". А всем капиталистам хочется больших быстрых денег... Начинаем рисковать...
Побольше бы content addressable memory, можно было много задач ускорить... Лет 20 ее обещают, но пока только крошечные объемы в сетевом оборудовании...
У меня опыт работы в 3х стартапах: первый помер на ранней стадии, второй почти десять лет до продажи индусам, третий тянет волынку почти 20 лет но уже подходит к концу жизненнего цикла.
Размер команды в 6-7 человек выбран не случайно: это эмпирически подтвержденное количество людей с которыми человек может поддерживать коммуникацию на высоком уровне.
В единоборствах такие же группы по размеру рекомендуются, не больше.
С увеличением размера группы расходы на коммуникацию увеличиваются и общение формализируется, замедляется.
Помню, читал книгу одного IBM инженера, если не ошибаюсь, про создание OS 360, тот же размер группы на острие разработки рекомендовал.
Но нужно гораздо больше людей для сопровождения, как в армии - один в поле, десять в тылу создают оружие, пашут, работают в госпитале и тд.
потребление редкоземов не такое большое и руда есть много где, но процесс разделения муторный и грязный. В штатах мощности законсервированы.
Раскачаются если приспичит, с другой стороны пример деградации ядерной промышленности США показывает что раскачка может быть долгой. Может им ядерка не особо нужна, поэтому?
У меня был подобный in house проект, язык запросов для поиска, там пришлось указывать source для полей, для маппинга. По аналогии с алиасами таблиц в sql.
Поиск был в гетерогенных репозиториях, черт ногу сломит, и rdbms и nosql, и иерархические агрегаторы с merge типа union в sql. Иначе пришлось бы всю кухню выносить на бизнес уровень.
Больше 10 лет назад, в одном банке на проекте, на коленке за пару дней был собран SQL парсер для FileNET, yже не припомню деталей, чем то похожим на JavaCC.
Использовалось для проверки и модификации запросов в репозиторий документов сторонними сервисами. Репозиторий увеличивался на пару миллиардов документов в год.
С JPA тоже наигрались тогда, закончилось рукописными запросами.
Аналогично с индексами - не зная какой будет поиск, ставят не глядя кластер на пяток нодов, включают реплицирование, создают под сотню шардов и выясняется в проде что join не работает либо медленнее в сто раз и проще было бы отклонировать вертикально масштабированные 3 сервера с одним шардом в каждом. Потому что 50 шардов с примерно 10 млн доков в каждом для join категорически не подойдут - коммуникация между нодами сжирает время. Wildcard запросы да, быстрее будут.
Бывает так что архитектура выбирается для портфолио - модно, сковородно, хорошо для резюме.
повторение мать учения - мне что ссылку на текст давать и цитату?
задолго до текста знал историю Форда и основания автопромышленности США. Воспоминания Ли Якокки еще в 90е прочитал.
Детройт конечно печально выглядит сейчас - знакомые жили напротив, наблюдал его с набережной реки, где рыбаки ловили ребешек, в город не заезжал - Баффало хватило. Вокзал с пустыми окнами, а ведь было красивое здание. Кипела жизнь, сейчас разруха. Дома по 5 долларов - налетай, покупай кварталами!
Ps. На брудершафт с тобой пили или нет, не припомню?
наверное нужно все в меру использовать. Щепотка соли это улучшение вкуса, а столовая ложка за раз - смерть.
Микросервисы хороши для динамического управления произовидительностью и защиты от падения (чтобы все не легло). Там где нагрузка может привести к падению процесса, лучше его выделить в сервис.
В "он премисис", где бюджет заложен жестко, бывает проще руками настроить все один раз и не трогать (несколько больших производительных монолитов).
Как только вводишь новую технологию, это подразумевает вопрос клиента "кто будет поддерживать?", приходится работать с тем стеком и специалистами, которые есть.
К8S? кто будет его поддерживать? Еластик? У нас есть Солр, давайте с ним же. и тд и тп.
"Делая большие дела, не забывай о малых, но умей расставлять приоритеты".
Верно замечено... Конечно, в монолите можно культурно обработать ошибки (сохранить ошибку на стартапе к примеру, и описать причину во время запроса) но самая главная проблема связана с падением процесса. К примеру, ООМ в Java приложении или ошибка JVM - это не лечится. Память заранее не обсчитать (можно конечно оценку сделать но во первых Java и так тормозная, а во вторых, в многопоточном приложении это тяжело делать). Вспоминаешь С, Objective C - там с оценкой расхода памяти было попроще...
Особенно проблема усугубляется когда код интенсивно использующий ресурсы, интегрируют с фасадом взаимодействующим с пользователем.
Был проект zero footprint viewer, там рендеринг запаковали в web war, хотя по хорошему его как раз нужно выносить наружу в ферму сервисов рендереров.
Пытались разрулить нагрузку балансером запросов но это не помогало если пришел к примеру документ "бомба" который ест CPU (привет, веб таймат!) или память (привет, ООМ!).
У меня разок еще поисковик у клиента подвисал и терял сессию - оказалось запрос на поиск шел 20 минут. Стал копать - виртуальная машина перегружена, диск I/O реально было 30 МБ/сек и поиск шел 20 минут. На тестовом стенде с SSD, тот же поиск занял 1.5 сек. Это самый тяжелый запрос был с полным сканированием, первый холодный поиск.
Был у меня в соседней группе монолит - всем монолитам монолит... Конфиг XML на сотни строк, с кросс ссылками, коннекторами в репозитории, вьюверы и тд. Само приложение тоже неудобное - часть модулей мавен отключено в дефолтном профайле, по коду ничего не найти если не знаешь где. "Метастаза" было бы хорошим названием этому приложению.
Я упирался руками и ногами чтоб не делать что либо в этом проекте - проблема не в коде сделать фикс а проверить билд...
Однажды столкнулись с проблемой узкого канала у заказчика при использовании распределенной системы при переносе данных из одного репозитория документов в другой.
Консультанты не выяснили что канал между серверами старого и нового репозитория узкий, около мегабайта в секунду, использовался для небольшого трафика. А тут мы по нему погнали сотни млн документов.
Повезло что приложение можно было резать на части (kafka streaming api) с заглушками в файловой системе ( дерево папок с метаданными и контентом).
Второе хорошо что небольшое расстояние, километров 20 - возили хард как Амазон дата трак с дисками....
всякое может быть - если упадет энергопоток то будем в лучшем случае на коняшках, иногда на мопедах, богатые на машине с газогенератором из опилок, ездить. Ниче, я коняшек зацепил краем, в детстве помогал пасти общее стадо когда в селе был в гостях.
На всякий случай тренируюсь на огороде - сегодня помидоры высадил, под картошку перекапываю грядки.
еще лет 100 не будет полноценных протезов массово.
Наработают теорию, практику - если произойдет скачок в технологиях, выстрелит накопленный задел.
Нейронки на другой основе, pulsed, экономичнее.
Поезда в туннелях сделают скорее всего, китайцы, они сейчас лидеры в промке, бетон, сталь и тд. Хотя, встает вопрос экономической целесообразности - зачем возить тушки если есть коммуникации? В США активно летали самолетами, даже помню, проездные были. Я сотню рейсов как то на проекте сделал туда сюда (понедельник - четверг) , как вся команда, хотя сидел и работал удаленно в пределах здания с сервером. Не проще ли было удаленку организовать, можно даже под камерой? Реально бы предпочел.
Маск поднимает интересные темы, по многое не идет дальше популизма, к сожалению, хотя многое и делается.
Успех Маска во многом не то что он суперкрут или технологие прям фантастика у него а в том что ближайшие конкуренты ( NASA, GM, и тд) - окаменевшие , погрязшие в бюрократии и распиле динозавры. Как кактусы - вроде стоит как живой, зеленый, а ткнешь пальцем - внутри уже пустой ..
Привели за руку "мальчика" около 50 лет на проект в команду. Отпрыск одной уважаемой семьи из Пенсильвании.
Папа устроил чтоб побыл в хорошей компании и не занимался ерундой типа наркоты и тд а каким то делом.
Зарплата ему была не нужна, папа иногда подвозил на своем самолете. Чешется язык но промолчу - скажу что приглашал посетить одну из старейших пивоварен в США , семейный бизнес. Еще фабрика мороженого. Семья весьма небедная. Менеджер наш был из тех же краев. Networking, короче.
Нашему менеджеру возможно приплатили (или услуга за услугу) за то что взял его понянчиться. "Мальчик" сидел, особо ничего не делал, но и не мешал.
вспоминаю своих учителей... У нас учитель математики мог спокойно провести лекцию по архитектуре высотных зданий или по Роллс Ройс.. А затем выдать задание по "пропущенной" лекции - ну вы сами выбрали тему лекции, а домашку никто не отменял.
Ни один преподаватель не вел лекции по бумажкам. МВТУ, самый конец 80х, начало 90х.
На экзамене по математике, на 3м курсе, изрядно загрузился на доп вопросе и меня коротнуло - перепутал имя и отчество преподавателя.
Он улыбнулся, и обратившись ко мне по имени/отчеству, сказал:"если вам трудно запомнить как меня зовут, зовите меня просто Вовочка, я не обижусь...". Владимир Борисович, помню до сих пор, а многие имена забыл .
У меня было отлично по математике - все таки, матшкола дала хороший "буст", на первом курсе разок подловил молодого выпускника МГУ что вел семинары ( но не стал ронять его авторитет, все равно никто ничего не понял), потом тет а тет поговорили, он мне сказал спасибо а я извинился - говорю у нас в школе математичка ( была тоже после МГУ, жена военного, как жена декабриста, в Сибирь поехала и подняла нашу школу) настаивала чтобы мы доказывали правоту если уверены и спорили с учителем. Заодно сделала обязательным обучение в заочных школах МФТИ и МГУ, по почте. Так что подловить учителя в нашей школе на ошибке было как получить чек от Дональда Кнута и означало отличную оценку.
Оценка у меня в школе рпо математике была 3 (на двойки и кола за неправильное решение налетал, если не понравилось учителю), но в конце четвёрти обычно менялась на 5 (учитель могла колы на 4 поменять). Так что резня бензопилой шла на полную... На оценки было плевать, если честно
этология, мать ее.
Пока честный готовится, жулик пользуется.
Всем капиталистам хочется больших быстрых денег а не создавать что то там и улучшать что-то там. Капитализм он про капитал, бизнес в первую очередь пылесос капитала или сопротивление в "электрической" схеме движения капитала, которое норовит пристроиться в место где напряжение повыше... Улучшение это вынужденная мера - создайте тепличные условия и нормальная компания выродится в паразита, подобие глиста (зачем что то делать, если живешь в еде). Именно поэтому в США делили монополии, чтоб не зажрались и не деградировали ( монополизм снижает потенциал страны, избавление от паразитов внутри по сути)
Модель выживания - сначала продать, затем сделать, для минимизации затрат (а вдруг не отобьются?). Сначала показываем картинку, ПоС после предоплаты. В идеале. Когда репутации нет или тема новая, приходится делать демо.
Те кто вкладываются в работу, рискуют сделать ненужный продукт.
Как решить вопрос? Гарантированным заказом. Но это фу, скучно и долго.
Какие минусы? При гарантированном заказе расценки фиксированы, не получится "выстрелить". А всем капиталистам хочется больших быстрых денег... Начинаем рисковать...
Побольше бы content addressable memory, можно было много задач ускорить... Лет 20 ее обещают, но пока только крошечные объемы в сетевом оборудовании...
хорошая статья, "годная".
У меня опыт работы в 3х стартапах: первый помер на ранней стадии, второй почти десять лет до продажи индусам, третий тянет волынку почти 20 лет но уже подходит к концу жизненнего цикла.
Размер команды в 6-7 человек выбран не случайно: это эмпирически подтвержденное количество людей с которыми человек может поддерживать коммуникацию на высоком уровне.
В единоборствах такие же группы по размеру рекомендуются, не больше.
С увеличением размера группы расходы на коммуникацию увеличиваются и общение формализируется, замедляется.
Помню, читал книгу одного IBM инженера, если не ошибаюсь, про создание OS 360, тот же размер группы на острие разработки рекомендовал.
Но нужно гораздо больше людей для сопровождения, как в армии - один в поле, десять в тылу создают оружие, пашут, работают в госпитале и тд.
потребление редкоземов не такое большое и руда есть много где, но процесс разделения муторный и грязный. В штатах мощности законсервированы.
Раскачаются если приспичит, с другой стороны пример деградации ядерной промышленности США показывает что раскачка может быть долгой. Может им ядерка не особо нужна, поэтому?
У меня был подобный in house проект, язык запросов для поиска, там пришлось указывать source для полей, для маппинга. По аналогии с алиасами таблиц в sql.
Поиск был в гетерогенных репозиториях, черт ногу сломит, и rdbms и nosql, и иерархические агрегаторы с merge типа union в sql. Иначе пришлось бы всю кухню выносить на бизнес уровень.
Больше 10 лет назад, в одном банке на проекте, на коленке за пару дней был собран SQL парсер для FileNET, yже не припомню деталей, чем то похожим на JavaCC.
Похожий пример грамматики SQL
Использовалось для проверки и модификации запросов в репозиторий документов сторонними сервисами. Репозиторий увеличивался на пару миллиардов документов в год.
С JPA тоже наигрались тогда, закончилось рукописными запросами.
Аналогично с индексами - не зная какой будет поиск, ставят не глядя кластер на пяток нодов, включают реплицирование, создают под сотню шардов и выясняется в проде что join не работает либо медленнее в сто раз и проще было бы отклонировать вертикально масштабированные 3 сервера с одним шардом в каждом. Потому что 50 шардов с примерно 10 млн доков в каждом для join категорически не подойдут - коммуникация между нодами сжирает время. Wildcard запросы да, быстрее будут.
Бывает так что архитектура выбирается для портфолио - модно, сковородно, хорошо для резюме.
повторение мать учения - мне что ссылку на текст давать и цитату?
задолго до текста знал историю Форда и основания автопромышленности США. Воспоминания Ли Якокки еще в 90е прочитал.
Детройт конечно печально выглядит сейчас - знакомые жили напротив, наблюдал его с набережной реки, где рыбаки ловили ребешек, в город не заезжал - Баффало хватило. Вокзал с пустыми окнами, а ведь было красивое здание. Кипела жизнь, сейчас разруха. Дома по 5 долларов - налетай, покупай кварталами!
Ps. На брудершафт с тобой пили или нет, не припомню?
наверное нужно все в меру использовать. Щепотка соли это улучшение вкуса, а столовая ложка за раз - смерть.
Микросервисы хороши для динамического управления произовидительностью и защиты от падения (чтобы все не легло). Там где нагрузка может привести к падению процесса, лучше его выделить в сервис.
В "он премисис", где бюджет заложен жестко, бывает проще руками настроить все один раз и не трогать (несколько больших производительных монолитов).
Как только вводишь новую технологию, это подразумевает вопрос клиента "кто будет поддерживать?", приходится работать с тем стеком и специалистами, которые есть.
К8S? кто будет его поддерживать? Еластик? У нас есть Солр, давайте с ним же. и тд и тп.
"Делая большие дела, не забывай о малых, но умей расставлять приоритеты".
Верно замечено... Конечно, в монолите можно культурно обработать ошибки (сохранить ошибку на стартапе к примеру, и описать причину во время запроса) но самая главная проблема связана с падением процесса. К примеру, ООМ в Java приложении или ошибка JVM - это не лечится. Память заранее не обсчитать (можно конечно оценку сделать но во первых Java и так тормозная, а во вторых, в многопоточном приложении это тяжело делать). Вспоминаешь С, Objective C - там с оценкой расхода памяти было попроще...
Особенно проблема усугубляется когда код интенсивно использующий ресурсы, интегрируют с фасадом взаимодействующим с пользователем.
Был проект zero footprint viewer, там рендеринг запаковали в web war, хотя по хорошему его как раз нужно выносить наружу в ферму сервисов рендереров.
Пытались разрулить нагрузку балансером запросов но это не помогало если пришел к примеру документ "бомба" который ест CPU (привет, веб таймат!) или память (привет, ООМ!).
У меня разок еще поисковик у клиента подвисал и терял сессию - оказалось запрос на поиск шел 20 минут. Стал копать - виртуальная машина перегружена, диск I/O реально было 30 МБ/сек и поиск шел 20 минут. На тестовом стенде с SSD, тот же поиск занял 1.5 сек. Это самый тяжелый запрос был с полным сканированием, первый холодный поиск.
Был у меня в соседней группе монолит - всем монолитам монолит... Конфиг XML на сотни строк, с кросс ссылками, коннекторами в репозитории, вьюверы и тд. Само приложение тоже неудобное - часть модулей мавен отключено в дефолтном профайле, по коду ничего не найти если не знаешь где. "Метастаза" было бы хорошим названием этому приложению.
Я упирался руками и ногами чтоб не делать что либо в этом проекте - проблема не в коде сделать фикс а проверить билд...
Сколько я их перепаял.. Щупаешь пальцами плату, находишь место вызывающее рассинрон и впаиваешь туда мелкий конденсатор.
А музыкальные процессоры?
Спасибо, вспомнил ночные загрузки игр с подкруткой головки магнитофона.
Однажды столкнулись с проблемой узкого канала у заказчика при использовании распределенной системы при переносе данных из одного репозитория документов в другой.
Консультанты не выяснили что канал между серверами старого и нового репозитория узкий, около мегабайта в секунду, использовался для небольшого трафика. А тут мы по нему погнали сотни млн документов.
Повезло что приложение можно было резать на части (kafka streaming api) с заглушками в файловой системе ( дерево папок с метаданными и контентом).
Второе хорошо что небольшое расстояние, километров 20 - возили хард как Амазон дата трак с дисками....
всякое может быть - если упадет энергопоток то будем в лучшем случае на коняшках, иногда на мопедах, богатые на машине с газогенератором из опилок, ездить. Ниче, я коняшек зацепил краем, в детстве помогал пасти общее стадо когда в селе был в гостях.
На всякий случай тренируюсь на огороде - сегодня помидоры высадил, под картошку перекапываю грядки.
понятно что это не нейросети , но сам факт что разрешили такие операции...
еще лет 100 не будет полноценных протезов массово.
Наработают теорию, практику - если произойдет скачок в технологиях, выстрелит накопленный задел.
Нейронки на другой основе, pulsed, экономичнее.
Поезда в туннелях сделают скорее всего, китайцы, они сейчас лидеры в промке, бетон, сталь и тд. Хотя, встает вопрос экономической целесообразности - зачем возить тушки если есть коммуникации? В США активно летали самолетами, даже помню, проездные были. Я сотню рейсов как то на проекте сделал туда сюда (понедельник - четверг) , как вся команда, хотя сидел и работал удаленно в пределах здания с сервером. Не проще ли было удаленку организовать, можно даже под камерой? Реально бы предпочел.
Маск поднимает интересные темы, по многое не идет дальше популизма, к сожалению, хотя многое и делается.
Успех Маска во многом не то что он суперкрут или технологие прям фантастика у него а в том что ближайшие конкуренты ( NASA, GM, и тд) - окаменевшие , погрязшие в бюрократии и распиле динозавры. Как кактусы - вроде стоит как живой, зеленый, а ткнешь пальцем - внутри уже пустой ..
почему бы не монетизировать вопрос?
откатинг на рекрутинг... Все имеют свой процент.
У меня был случай на проекте в США.
Привели за руку "мальчика" около 50 лет на проект в команду. Отпрыск одной уважаемой семьи из Пенсильвании.
Папа устроил чтоб побыл в хорошей компании и не занимался ерундой типа наркоты и тд а каким то делом.
Зарплата ему была не нужна, папа иногда подвозил на своем самолете. Чешется язык но промолчу - скажу что приглашал посетить одну из старейших пивоварен в США , семейный бизнес. Еще фабрика мороженого. Семья весьма небедная. Менеджер наш был из тех же краев. Networking, короче.
Нашему менеджеру возможно приплатили (или услуга за услугу) за то что взял его понянчиться. "Мальчик" сидел, особо ничего не делал, но и не мешал.
вспоминаю своих учителей... У нас учитель математики мог спокойно провести лекцию по архитектуре высотных зданий или по Роллс Ройс.. А затем выдать задание по "пропущенной" лекции - ну вы сами выбрали тему лекции, а домашку никто не отменял.
Ни один преподаватель не вел лекции по бумажкам. МВТУ, самый конец 80х, начало 90х.
На экзамене по математике, на 3м курсе, изрядно загрузился на доп вопросе и меня коротнуло - перепутал имя и отчество преподавателя.
Он улыбнулся, и обратившись ко мне по имени/отчеству, сказал:"если вам трудно запомнить как меня зовут, зовите меня просто Вовочка, я не обижусь...". Владимир Борисович, помню до сих пор, а многие имена забыл .
У меня было отлично по математике - все таки, матшкола дала хороший "буст", на первом курсе разок подловил молодого выпускника МГУ что вел семинары ( но не стал ронять его авторитет, все равно никто ничего не понял), потом тет а тет поговорили, он мне сказал спасибо а я извинился - говорю у нас в школе математичка ( была тоже после МГУ, жена военного, как жена декабриста, в Сибирь поехала и подняла нашу школу) настаивала чтобы мы доказывали правоту если уверены и спорили с учителем. Заодно сделала обязательным обучение в заочных школах МФТИ и МГУ, по почте. Так что подловить учителя в нашей школе на ошибке было как получить чек от Дональда Кнута и означало отличную оценку.
Оценка у меня в школе рпо математике была 3 (на двойки и кола за неправильное решение налетал, если не понравилось учителю), но в конце четвёрти обычно менялась на 5 (учитель могла колы на 4 поменять). Так что резня бензопилой шла на полную... На оценки было плевать, если честно
Обязательно.
Протезирование шагает по планете - руки ноги, глаза, органы слуха. Дистанционное управление силой мысли (через обруч).
Как только имплант станет миниатюрным и автономным, его можно будет вшить в тело или спрятать.
Коммуникация возможно не напрямую с мозгом, это сложно, а через органы чувств или подобие обруча как в мышке управляемой силой мысли.
Маск уже вшивает чипы.
Другой вопрос что человека надо тренировать с детства и готовить к определённому роду деятельности так как мозг пластичен до определённого возраста.
Грубо говоря, учить языки желательно примерно до 6-7 лет чтобы не было акцента.
Будешь развивать память (учить тысячи иероглифов) - потеряешь в сообразительности (изобретательность).
С телом так же - шпагат легче освоить до 15 пока хрящи большие.
Другой вопрос что делать в будущем когда появятся импланты с базами знаний...