Какое-то время оно работать будет. Но чувствую, что следующим шагом упыри начнут не просто ждать 200 а ждать подписи переданного хеша секретным ключом сервера.
Чего только лоди не придумают, чтобы не учится программировать.
А во всяких BPM системах как любят мантру «дешевый системный аналитик, не умеющий программировать, сможет создать бизнес-процесс без привлечения программиста».
По факту,
1) меньшая гибкость. Проблемы с подключением сторонних библиотек/сервисов. Правда, есть заплатки, что можно свои блоки создавать. Но тогда уже некая гибридная парадигма выходит, совмещаюшая недостатки обоих
2) неудобства с наследованием, абстракциями
3) даже с диффами и VCS, меньшая приспособленность к анализу изменений в проекте
Ps: может, если применить AI, и оставлять ему на откуп тривиальные операции вроде всяких биндингов, банальных преобразований, джойнов, а описывать схемой только желаемый вход и выход, то и будет толк
А почему вдруг стало проще расти вертикально? Тактовая частота не растет уже лет 10 (еще и падать начала у многоядерных E5 к примеру, из годам в год), системы с больше, чем четырьмя сокетами стоят космических денег (правда, может intel scalable family исправит ситуацию, хз). С облаками так вообще, надо уметь горизонтально масштабировать.
Из реальной практики, была задача год назад, где надо хорошую однопоточную производительность на серверном железе обеспечить. Взяли e5-2643v4 (3.4 GHz частота, максимум, что есть на рынке). На домашних дешевых процессорах куда веселее цифры, увы.
Если попробовать влезть в шкуру идеолога проекта, то можно предположить, что он мог бояться воровства идеи. Пока бы он делал прототипы и MVP, и опрашивал друзей, некие шустрые ребята могли перехватить гениальную идею, и опередить автора. Если бы идея и вправду была гениальной, то именно так, как действовал идеолог проекта — правильно.
Ситуация описанная в комментарии хорошо решится, если критерий крайне простой — каждый ответ вырождается в + или — в отчете. Такой критерий отлично зайдет при наборе формошлепов и знатоков конкретного набора фреймворков. А вот даже для набора перспективных трейни я бы так не делал.
При выборе человека, которому придется создавать что-то новое (таких принято называть инженерами), важнее ход мысли, а не конечный ответ. Сравнить ход мысли даже на одинаковых вопросах не так то просто.
PS: количество да, чем больше кандидатов, тем скорее пойдет народная молва о вопросах
А по факту он работает. ИС позволяет отсечь людей с несовпадением по ценностям. Это важнее, чем недостаток хард скиллов. К сожалению, выявлять ценности человека на собесе почти никто не умеет (есть много тех, кто думает, что умеет).
Об одинаковых вопросах для всех кандидатов не согласен в корне. Цель компании — не составить рейтинг (для этого есть спортивное программирование), а найти человека, который будет создавать ценность. И если будет небольшая погрешность, это не страшно.
А вот то, что одинаковые вопросы позволяют геймить систему, это важнее. Потом вопросы начинают передаваться из уст в уста. Я сам был в ситуации интервьювера со списком вопросов, когда пришел человек мгновенно отвечающий на вопросы, и я не мог понять, человек действительно крут, или просто его друг собеседовался ранее. Мне тогда помог именно десяток вопросов, которые я держал в голове, и задавал 2-3 из них в добавок к вопросам их списка.
PS некоторые компании вообще устраивают письменное групповое тестирование для джуниоров, и там выигрывают люди со свежим опытом списывания и хорошим зрением.
Уверен, что к этому придут, к сожалению. Да, это куча неудобств, но сделав сервис, технически похожий на Cloudflare, которому будут доверять и рекламодатели и вебмастера, можно заворачивать весь траффик, и по ходу переколбашивать разметку, гомогенизируя контент.
А вот когда появится супероружие по ссылке, то придется, конечно, напрячься рекламщикам, и проявлять креатив.
PS: лично я даже поставил бы галочку в блокировщиках «готов майнить, нагружая 20% процессора», если бы она была. Мне мое личное время дороже процессорного времени. Без хоть какого-то win-win победа блокировщиков призовет пейволы, и проиграют все.
PPS: Хотя… против пейволов можно создать р2р сеть, которая будет кешировать контент, и после первого просмотра страницы участником сети, оплатившим пейвол, давать доступ всем…
встречал рекламу украинского интернет-магазина Розетка, которая пробивает стек из нескольких блокировщиков (и ручная блокировка AdBlock Plus работала до нажатия F5). Подозреваю, что на каждый запрос генерируется уникальная рандомная разметка. Тревожный звоночек.
кстати да, рандомная (неперсонализированная) реклама тоже имеет свой смысл. Можно сразу понять, зайдя на сайт:
1) кто целевая аудитория сайта
2) на что тратят в основном деньги пользователи сайта
3) что вообще сейчас пытаются пользователям интернета впаривать
то есть, чисто из любопытства, это интересно. Персонализированная реклама убивает такую возможность. Она лишь дает мне понять, что обо мне думают RTB боты, но не дает доп инфы об окружающем мире.
И самое обидное, что даже отключив персонализацию, получаешь не глобальную картину, а некий срез самой дешевой рекламы за клик, которую суют неперсонализированным пользователям (и распределение будет радикально отличаться от модели, когда персонализации нет в принципе).
первые минуты (пока каждый человек и брамин на счету) играть довольно тревожно. Но когда еды становится >2000, и приходится использовать jQuery для множественных покупок, то все начинает идти как по маслу)
Вообще весело представлять себе, как караван из 500 человек и 10К быков встречает охотников, и говорит: нам бы купить еды дней так на 100. А охотники: да не вопрос, вот как раз настреляли.
Еще при грузе что-то около миллиона проявился баг: каждый раз при выходе из города караван сразу перегруженный, приходится несколько десятков тысяч груза сбрасывать. При докупке еще браминов баг рассосался.
выходит, что если бы продавцы были чуть умнее, и давали бы данные со случайной задержкой (скажем, от секунды до часа, причем, случайная задержка как на запрос, так и на отдачу покупателю), то детектив был бы в разы интереснее?
Если абстрагироваться от вопросов безопасности, то все написанное в статье не особо то и приносит ценности.
Касательно единой БД, никто не мешает поставлять с приложением свою базку данных (тот же SQLite), оптимизированную именно под задачи приложения. Где-то нужна документарная, где-то SQL, а всем хорошо (да еще и на десятилетия вперед) не сделаешь. Да, лишние мегабайты, но
у нас ведь гигабайты памяти
Касательно единой шины, сейчас не особо то и надо межпроцессное взаимодействие. Для редких задач есть куча средств и так. В основном запросы к серверу надо (либо сокет), вот и все.
Он просто ищет в БД документы с указанным типом «email». Когда GUI хочет отправить сообщение, то назначает ему свойство outgoing=true. Простой модуль составит список всех исходящих почтовых сообщений и отправит их по STMP.
Вспоминаю, как дважды в жизни работал с smtp программно (раз на C#, раз на питоне), за 5 минут на стековерфлоу находилась ссылка на бесплатные опенсорс либы, и писалось приложение в 10 строк кода. В чем проблема? Лишние библиотеки на n килобайт?
Осталось больше вопросов, чем ответов:
1) Модели, работающие в проде, и на новых клиентах, обращаются к тому же datalake, где проверяются гипотезы, или под них отдельная инфраструктура?
2) Как делятся ресурсы (что происходит, если 3 отдела одновременно запустили тяжелые джобы на кластере)?
3) Может ли, образно говоря, помощник младшего аналитика, используя DataResearchPlatform, получить конфиденциальную информацию, которая может помочь конкурентам?
С Ашотом аргумент не совсем хорош. Государство, как заказчик, не теряет деньги на том, что скажем, Малайзия купит тот же софт за пару долларов (в отличии от заказчика Ашота). Наоборот, если есть еще и договор на поддержку, то багфиксы в общих модулях будут происходить бодрее, если софт работает во многих странах одновременно.
Но, с другой стороны, справедливо было бы выплатить заказчику что-то вроде роялти, за каждую следующую продажу.
Еще 1 момент, что возникает конфликт интересов. Подрядчику выгодно манипуляциями/личными договоренностями склонить заказчика к фичам в ТЗ, которые хорошо продаются другим заказчикам (и не нужны заказчику), и уговорить отказаться от фич, которые нужны только заказчику.
Как предусмотрена борьба с тем, чтобы записать исходное видео в 4к, воспроизвести на качественном проекторе, а потом просто в меньшем разрешении снять часть экрана, водя по нему в соответствии с алгоритмом?
на эту тему вспомнилась статья.
по сути, если абстрагироваться от предметной области, то люди целенаправленно и очень сильно сужают воронку продаж на начальном этапе, чтобы снизить нагрузку на ресурсы (людей, которые отвечают на письма) на следующих.
А во всяких BPM системах как любят мантру «дешевый системный аналитик, не умеющий программировать, сможет создать бизнес-процесс без привлечения программиста».
По факту,
1) меньшая гибкость. Проблемы с подключением сторонних библиотек/сервисов. Правда, есть заплатки, что можно свои блоки создавать. Но тогда уже некая гибридная парадигма выходит, совмещаюшая недостатки обоих
2) неудобства с наследованием, абстракциями
3) даже с диффами и VCS, меньшая приспособленность к анализу изменений в проекте
Ps: может, если применить AI, и оставлять ему на откуп тривиальные операции вроде всяких биндингов, банальных преобразований, джойнов, а описывать схемой только желаемый вход и выход, то и будет толк
Из реальной практики, была задача год назад, где надо хорошую однопоточную производительность на серверном железе обеспечить. Взяли e5-2643v4 (3.4 GHz частота, максимум, что есть на рынке). На домашних дешевых процессорах куда веселее цифры, увы.
При выборе человека, которому придется создавать что-то новое (таких принято называть инженерами), важнее ход мысли, а не конечный ответ. Сравнить ход мысли даже на одинаковых вопросах не так то просто.
PS: количество да, чем больше кандидатов, тем скорее пойдет народная молва о вопросах
А вот то, что одинаковые вопросы позволяют геймить систему, это важнее. Потом вопросы начинают передаваться из уст в уста. Я сам был в ситуации интервьювера со списком вопросов, когда пришел человек мгновенно отвечающий на вопросы, и я не мог понять, человек действительно крут, или просто его друг собеседовался ранее. Мне тогда помог именно десяток вопросов, которые я держал в голове, и задавал 2-3 из них в добавок к вопросам их списка.
PS некоторые компании вообще устраивают письменное групповое тестирование для джуниоров, и там выигрывают люди со свежим опытом списывания и хорошим зрением.
только у меня такой финальный логотип?
А вот когда появится супероружие по ссылке, то придется, конечно, напрячься рекламщикам, и проявлять креатив.
PS: лично я даже поставил бы галочку в блокировщиках «готов майнить, нагружая 20% процессора», если бы она была. Мне мое личное время дороже процессорного времени. Без хоть какого-то win-win победа блокировщиков призовет пейволы, и проиграют все.
PPS: Хотя… против пейволов можно создать р2р сеть, которая будет кешировать контент, и после первого просмотра страницы участником сети, оплатившим пейвол, давать доступ всем…
Хотя… на подходе motherboard.vice.com/en_us/article/9a4yny/princetons-ad-blocking-superweapon-may-put-an-end-to-the-ad-blocking-arms-race
1) кто целевая аудитория сайта
2) на что тратят в основном деньги пользователи сайта
3) что вообще сейчас пытаются пользователям интернета впаривать
то есть, чисто из любопытства, это интересно. Персонализированная реклама убивает такую возможность. Она лишь дает мне понять, что обо мне думают RTB боты, но не дает доп инфы об окружающем мире.
И самое обидное, что даже отключив персонализацию, получаешь не глобальную картину, а некий срез самой дешевой рекламы за клик, которую суют неперсонализированным пользователям (и распределение будет радикально отличаться от модели, когда персонализации нет в принципе).
Вообще весело представлять себе, как караван из 500 человек и 10К быков встречает охотников, и говорит: нам бы купить еды дней так на 100. А охотники: да не вопрос, вот как раз настреляли.
Еще при грузе что-то около миллиона проявился баг: каждый раз при выходе из города караван сразу перегруженный, приходится несколько десятков тысяч груза сбрасывать. При докупке еще браминов баг рассосался.
Касательно единой БД, никто не мешает поставлять с приложением свою базку данных (тот же SQLite), оптимизированную именно под задачи приложения. Где-то нужна документарная, где-то SQL, а всем хорошо (да еще и на десятилетия вперед) не сделаешь. Да, лишние мегабайты, но
Касательно единой шины, сейчас не особо то и надо межпроцессное взаимодействие. Для редких задач есть куча средств и так. В основном запросы к серверу надо (либо сокет), вот и все.
Вспоминаю, как дважды в жизни работал с smtp программно (раз на C#, раз на питоне), за 5 минут на стековерфлоу находилась ссылка на бесплатные опенсорс либы, и писалось приложение в 10 строк кода. В чем проблема? Лишние библиотеки на n килобайт?
1) Модели, работающие в проде, и на новых клиентах, обращаются к тому же datalake, где проверяются гипотезы, или под них отдельная инфраструктура?
2) Как делятся ресурсы (что происходит, если 3 отдела одновременно запустили тяжелые джобы на кластере)?
3) Может ли, образно говоря, помощник младшего аналитика, используя DataResearchPlatform, получить конфиденциальную информацию, которая может помочь конкурентам?
Но, с другой стороны, справедливо было бы выплатить заказчику что-то вроде роялти, за каждую следующую продажу.
Еще 1 момент, что возникает конфликт интересов. Подрядчику выгодно манипуляциями/личными договоренностями склонить заказчика к фичам в ТЗ, которые хорошо продаются другим заказчикам (и не нужны заказчику), и уговорить отказаться от фич, которые нужны только заказчику.
по сути, если абстрагироваться от предметной области, то люди целенаправленно и очень сильно сужают воронку продаж на начальном этапе, чтобы снизить нагрузку на ресурсы (людей, которые отвечают на письма) на следующих.