Горе мне горе.. когда-то давно, по просьбе какого-то хедхантера создал себе аккаунт и вылил в него образцы кода. Пока помнил логин пароль даже поставил несколько звёзд кому-то там... Потом забыл... Наверняка при анализе мой потеряшка стал подозрительным.. ;)
Сообщество хабра, кмк, разнородно как по направлениям разработки, так и по бэк-фронт, по применяемым языкам и тем более сторонним библиотекам. Если автор пиарит некое свое решение, то это может и вовсе не означать "пиар", как его продвижение, а, к примеру, демонстрация "во как я могу", или "есть и такое решение" среди множества иных. Но! Даже если это и пиар, поскольку автору решение кажется "самым клевым", то это не значит что оно продвигается на всё сообщество целиком. Тут, кмк, действует "свобода выбора": не нравится - не читай, делов-то..
Не увидел в табличке сравнения как с чистым JS, так и с низкоуровневой (будем считать так) библиотекой JQuery. Возможно такой пример был бы и сложнее и даже существенно, но в качестве сравнительной колонки, кмк, просто обязан присутствовать. А так .. в JS можно писать любые "обфускаторы" и надстройки.. дорого всё это, что наглядно видно на страницах сайтов, как только спускаешься с небес на землю. Достаточно попасть в какой-то уголок, где штатная скорость 20-50кБод и фсё .. можно покурить, налить и выпить кофе пока прогрузятся страницы с очередным модным шаблонизатором - улучшателем ДОМ .. :(
Извините, но из Вашего возражения про маленькие банковские транзакции на миллионы этого не следует. Я просто хотел чтобы Вы всего лишь уточнили, что Вы имели ввиду в деталях. Никаких холиваров, просто любопытно, чего такого я не знаю про микросервисы и монолиты..
Спасибо, ознакомлюсь. Пока что нагуглил вот такое: http://314159.ru/kushnerov/kushnerov1.pdf оказывается работы в этом направлении активно ведутся, тут ссылки на 2005год.
http://www.wikiznanie.ru/ru-wz/index.php/Троичный_сумматор тут есть вся математика троичного сумматора и даже вариации на базе двоичной логики. Но, как раз аппаратных решений на базе троичной логики -U,0,+U сходу не нашел. Я про этот путь написал.
Интересно, почему троичные компьютеры рассматриваются с точки зрения однополярного напряжения и токов? симметричные CMOS схемы с двуполярным питанием вполне могут работать на +- логике с нулевым значением (нет напряжения - выход в третьем состоянии). Собственно вся двоичная логика на CMOS с открытым коллектором разве не такова? Только там применяются "токи смещения", что кмк является наоборот усложнением для реализации двоичной логики, не?
Вы не внимательны. Написал же не просто так: "монолит - реентерабелен И шардируем". Давайте уточню. Скажем монолит на горутинах, шардируется в нужных горутинах. Где выгода?
А каким способом перенос сложности бизнес приложения с внутреннего монолита, на микросервисную архитектуру повышает производительность, при внесении как миниум дополнительной сетевой задержки?
Если бизнес-монолит реентерабелен и шардируем, в чем преимущество микросервисов? Поясните пожалуйста.
Ну.. можете заминусовать, но странички Сбер-онлайн это содом и Гоморра. Особенно на деревенских скоростях 56кбод. По 300+ обращений к серверу и чего только нет в них.
И такое часто, особенно среди молодых коллективов, откуда поувольнялись предыдущие сеньоры. Всё может быть можно и молодежно и с самыми передовыми технологиями, но .. лепить "здравствуй мир" через фабрики, хелперы и в полном применении обратных зависимостей, даже там, где они прямее не бывают. Где-то уже даже публиковалось подобное..
Плюсанул статью, хотя бы за то что в ней отсутствует codeigniter в качестве серебряной пули.
Акцентирую внимание на одном моменте:
В начале статьи автор рассказывает о ручном тестировании через Postman, а потом приводит несколько примеров по созданию пирамиды тестов.
Постман умеет не только хранить запросы во всей их красе, но также умеет в команды, что резко снижает временную стоимость рефакторинга, как факт. Сколько потребуется времени на написание текстов из статьи, создание моковых наборов, особенно для покрытия всех краевых событий хорошо изложено в статье.
Овичнка точно стоила выделки? ;) При этом никоим боком не против автотестирования, но может примеры слишком переусложнены?
Спасибо за статью. Но, кмк, прогноз в 10+ лет великоват, и скорее всего предполагает линейную или квадратичную функцию накопления фактологии и продвижения вперед. К сожалению она экспоненциальная.. С другой стороны имеем: от времени изобретения автора прошло 30лет. "Стакан наполовину полон" по сути год-два назад. Отсюда, можно сделать прогноз что не через 10лет и не "следующий шаг", а через 3-5 лет мы поимеем роботов со свободой воли, способных творить Зло. Точнее, понявших что "Человек тут не нужен".. никакой. :(
Собственно эти выводы, видимо когда-то и привели к стагнации развития компьютерного дела в СССР. Была у Беляева фантастика по этой проблематике примерно в налаче 70-х. Как известно, он "имел доступ" .. не удивлюсь, если когда-нибудь узнаем что команда Ершова, Кнорозова, Колмогорова, Маркова когда-то получила подобный прогноз или даже результат.. Марковские цепи, Байесовские сети .. Причинно-следственное исчисление .. вероятностный вывод .. рандомное озарение..
О, сколько нам открытий чудных,
Готовит Просвещенья Дух.
И Опыт - сын ошибок трудных,
и Гений - парадоксов друг...
.. и Случай. Бог-Изобретатель.
(с) А.С. Пушкин.
Очень правильно понимал, что Эйнштейн ошибался со своим "Госполь не играет в кости".. да только этим он и занят! ;)
Ну .. сказочники, способные писать журналистские статьи на заданную проблематику, с обучением по некоторому обьему исходной информации прижились уже давненько. Здесь есть замечание про "обобщать информацию", что является некой претензией на ИИ. Остается следующий шаг: "активная генерация новой информации" на основе каталогизации и обощения с применением некого рандомного подхода. И последний шаг: активное формирование внутренней модели внешней среды на основе предыдущего механизма.
И .. добро пожаловать в мир роботов и ИИ, где человек .. не нужен (но .. может так и правильно?!?)
Проблема всего процесса в том что мало кто понимает реальную скорость роста экспоненциальных функций развития разных процессов во времени: Если стакан заполняется за 30 секунд некими бактериями, делящимися каждую секунду, то стакан был наполовину пуст всего лишь секунду назад!
В приложении к проблеме ИИ: если Вам кажется, что пройдена только половина пути, то вторая половина .. может быть УЖЕ пройдена, пока Вы читали этот комментарий.
Сам по себе подход "категорирования товаров" в группы и подгруппы - кмк, сильно ущербен. Попробуйте для развлечения совместить каталог хотя бы 3-4 продавцов из одной и той же ниши - повеселитесь.
Давно (2006-2011) занимался этой проблемой, начав как раз с попытки совместить 3 рубрикатора от разных рекламных изданий (ещё печатные СМИ).. проблемы:
Во главу угла (верхний уровень) также как у Вас в статье ставится свойство товара "назначение" (Одежда обувь). Начать с того, что это несколько разное назначение (применение) т.к. никто ботинки не одевает на голову как шапку, и продолжить тем, что товар часто имеет множественное назначение.
Для дальнейшего внесения путаницы авторы вводят "подкатегории", которые зачастую или а) уточняют назначение "женская одежда" или делят множественную категорию, а бывает что в подкатегорию попадают товары .. по иному признаку "из кашемира".
Ещё тогда родилась простая как мычание идея: нет никаких "категорий" и "рубрикаторов". Есть товар (услуга, понятие) как имя Существительное (брал словарь Зализняка) и его описание свойств. Назначение - одно из. Да, свойство может быть коллекцией и часто выражается Прилагательным.
Второй момент - "наборы товаров".. в целом, любой товар является "набором" - свойство "состав".
Типовые свойства, мало интересные покупателю, но часто сильно влияющие на его выбор и цену: фасовка, упаковка, гарантия (как Услуга) - сопутствующие товары.
Создайте БД имен существительных, с возможностью дополнять описание прилагательными и составом(комплектом, набором). Разберите свои прилагательные (они иногда забавны) по принадлежности к существительным, которые станут вашим "каталогизатором" и придайте им "веса" - получите "рубрики" и "подкатегории", которые и станут вашим поисковым фильтром.
Собственно это фсё. Когда-то пробовал крутить такое на Сфинксе.. но железо оказалось "слабовато". Сейчас времена иные и ресурсов у многих в достатке.
Прочёл статью, но не пользователь мессенджера от Яндекса, поэтому по картинкам мало что понял. Возник вопрос:
Может есть причина, но почему различаются чаты и треды-обсуждения? Разве это не многоуровневый чат, который, как и написано выше, может начаться с любого сообщения далее, и в котором автор стартового сообщения может стать его "админом"? Почему не подходит "деревянная" структура?
Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.
Микросервисы? Не, ну можно конечно, если тур-агенство способно закупить супер железо, и выкачивать каждый раз 3/4 БД обращаясь к нескольким сервисам .. транзакционность? Да тоже можно на программном уровне, только стоит ли овчинка выделки для тур-агенства, в котором как правило "3 пленных немца", включая директора.
Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.
Кмк, очень спорно и далеко не всегда полезно. Но, как средство выколачивания из бизнеса денег на покупку самого толстого железа - очень надежно.
Горе мне горе.. когда-то давно, по просьбе какого-то хедхантера создал себе аккаунт и вылил в него образцы кода. Пока помнил логин пароль даже поставил несколько звёзд кому-то там... Потом забыл... Наверняка при анализе мой потеряшка стал подозрительным.. ;)
Сообщество хабра, кмк, разнородно как по направлениям разработки, так и по бэк-фронт, по применяемым языкам и тем более сторонним библиотекам. Если автор пиарит некое свое решение, то это может и вовсе не означать "пиар", как его продвижение, а, к примеру, демонстрация "во как я могу", или "есть и такое решение" среди множества иных. Но! Даже если это и пиар, поскольку автору решение кажется "самым клевым", то это не значит что оно продвигается на всё сообщество целиком. Тут, кмк, действует "свобода выбора": не нравится - не читай, делов-то..
Думаю там про этот фреймворк http://vanilla-js.com/
Иначе как-то слабо верится что обфускатор, генерирующий в конечном итоге JS-код, работает быстрее оригинального js. "так не бывает".. ;)
Не увидел в табличке сравнения как с чистым JS, так и с низкоуровневой (будем считать так) библиотекой JQuery. Возможно такой пример был бы и сложнее и даже существенно, но в качестве сравнительной колонки, кмк, просто обязан присутствовать. А так .. в JS можно писать любые "обфускаторы" и надстройки.. дорого всё это, что наглядно видно на страницах сайтов, как только спускаешься с небес на землю. Достаточно попасть в какой-то уголок, где штатная скорость 20-50кБод и фсё .. можно покурить, налить и выпить кофе пока прогрузятся страницы с очередным модным шаблонизатором - улучшателем ДОМ .. :(
В общем, табличку стоит таки дополнить.
Извините, но из Вашего возражения про маленькие банковские транзакции на миллионы этого не следует. Я просто хотел чтобы Вы всего лишь уточнили, что Вы имели ввиду в деталях. Никаких холиваров, просто любопытно, чего такого я не знаю про микросервисы и монолиты..
Спасибо, ознакомлюсь. Пока что нагуглил вот такое: http://314159.ru/kushnerov/kushnerov1.pdf оказывается работы в этом направлении активно ведутся, тут ссылки на 2005год.
http://www.wikiznanie.ru/ru-wz/index.php/Троичный_сумматор тут есть вся математика троичного сумматора и даже вариации на базе двоичной логики. Но, как раз аппаратных решений на базе троичной логики -U,0,+U сходу не нашел. Я про этот путь написал.
Интересно, почему троичные компьютеры рассматриваются с точки зрения однополярного напряжения и токов? симметричные CMOS схемы с двуполярным питанием вполне могут работать на +- логике с нулевым значением (нет напряжения - выход в третьем состоянии). Собственно вся двоичная логика на CMOS с открытым коллектором разве не такова? Только там применяются "токи смещения", что кмк является наоборот усложнением для реализации двоичной логики, не?
Вы не внимательны. Написал же не просто так: "монолит - реентерабелен И шардируем". Давайте уточню. Скажем монолит на горутинах, шардируется в нужных горутинах. Где выгода?
А каким способом перенос сложности бизнес приложения с внутреннего монолита, на микросервисную архитектуру повышает производительность, при внесении как миниум дополнительной сетевой задержки?
Если бизнес-монолит реентерабелен и шардируем, в чем преимущество микросервисов? Поясните пожалуйста.
Ну.. можете заминусовать, но странички Сбер-онлайн это содом и Гоморра. Особенно на деревенских скоростях 56кбод. По 300+ обращений к серверу и чего только нет в них.
Никогда такого не было и вот опять снова .. ;)
И такое часто, особенно среди молодых коллективов, откуда поувольнялись предыдущие сеньоры. Всё может быть можно и молодежно и с самыми передовыми технологиями, но .. лепить "здравствуй мир" через фабрики, хелперы и в полном применении обратных зависимостей, даже там, где они прямее не бывают. Где-то уже даже публиковалось подобное..
Ржака в отделе возможна как раз по причинам выгорания и цинизма. Этакий маятник.
Все так, отличная статья. Пару раз уходил из ит, в котором примерно с 1979...
Плюсанул статью, хотя бы за то что в ней отсутствует codeigniter в качестве серебряной пули.
Акцентирую внимание на одном моменте:
В начале статьи автор рассказывает о ручном тестировании через Postman, а потом приводит несколько примеров по созданию пирамиды тестов.
Постман умеет не только хранить запросы во всей их красе, но также умеет в команды, что резко снижает временную стоимость рефакторинга, как факт. Сколько потребуется времени на написание текстов из статьи, создание моковых наборов, особенно для покрытия всех краевых событий хорошо изложено в статье.
Овичнка точно стоила выделки? ;) При этом никоим боком не против автотестирования, но может примеры слишком переусложнены?
Спасибо за статью. Но, кмк, прогноз в 10+ лет великоват, и скорее всего предполагает линейную или квадратичную функцию накопления фактологии и продвижения вперед. К сожалению она экспоненциальная.. С другой стороны имеем: от времени изобретения автора прошло 30лет. "Стакан наполовину полон" по сути год-два назад. Отсюда, можно сделать прогноз что не через 10лет и не "следующий шаг", а через 3-5 лет мы поимеем роботов со свободой воли, способных творить Зло. Точнее, понявших что "Человек тут не нужен".. никакой. :(
Собственно эти выводы, видимо когда-то и привели к стагнации развития компьютерного дела в СССР. Была у Беляева фантастика по этой проблематике примерно в налаче 70-х. Как известно, он "имел доступ" .. не удивлюсь, если когда-нибудь узнаем что команда Ершова, Кнорозова, Колмогорова, Маркова когда-то получила подобный прогноз или даже результат.. Марковские цепи, Байесовские сети .. Причинно-следственное исчисление .. вероятностный вывод .. рандомное озарение..
О, сколько нам открытий чудных,
Готовит Просвещенья Дух.
И Опыт - сын ошибок трудных,
и Гений - парадоксов друг...
.. и Случай. Бог-Изобретатель.
(с) А.С. Пушкин.
Очень правильно понимал, что Эйнштейн ошибался со своим "Госполь не играет в кости".. да только этим он и занят! ;)
Ну .. сказочники, способные писать журналистские статьи на заданную проблематику, с обучением по некоторому обьему исходной информации прижились уже давненько. Здесь есть замечание про "обобщать информацию", что является некой претензией на ИИ. Остается следующий шаг: "активная генерация новой информации" на основе каталогизации и обощения с применением некого рандомного подхода. И последний шаг: активное формирование внутренней модели внешней среды на основе предыдущего механизма.
И .. добро пожаловать в мир роботов и ИИ, где человек .. не нужен (но .. может так и правильно?!?)
Проблема всего процесса в том что мало кто понимает реальную скорость роста экспоненциальных функций развития разных процессов во времени: Если стакан заполняется за 30 секунд некими бактериями, делящимися каждую секунду, то стакан был наполовину пуст всего лишь секунду назад!
В приложении к проблеме ИИ: если Вам кажется, что пройдена только половина пути, то вторая половина .. может быть УЖЕ пройдена, пока Вы читали этот комментарий.
Сам по себе подход "категорирования товаров" в группы и подгруппы - кмк, сильно ущербен. Попробуйте для развлечения совместить каталог хотя бы 3-4 продавцов из одной и той же ниши - повеселитесь.
Давно (2006-2011) занимался этой проблемой, начав как раз с попытки совместить 3 рубрикатора от разных рекламных изданий (ещё печатные СМИ).. проблемы:
Во главу угла (верхний уровень) также как у Вас в статье ставится свойство товара "назначение" (Одежда обувь). Начать с того, что это несколько разное назначение (применение) т.к. никто ботинки не одевает на голову как шапку, и продолжить тем, что товар часто имеет множественное назначение.
Для дальнейшего внесения путаницы авторы вводят "подкатегории", которые зачастую или а) уточняют назначение "женская одежда" или делят множественную категорию, а бывает что в подкатегорию попадают товары .. по иному признаку "из кашемира".
Ещё тогда родилась простая как мычание идея: нет никаких "категорий" и "рубрикаторов". Есть товар (услуга, понятие) как имя Существительное (брал словарь Зализняка) и его описание свойств. Назначение - одно из. Да, свойство может быть коллекцией и часто выражается Прилагательным.
Второй момент - "наборы товаров".. в целом, любой товар является "набором" - свойство "состав".
Типовые свойства, мало интересные покупателю, но часто сильно влияющие на его выбор и цену: фасовка, упаковка, гарантия (как Услуга) - сопутствующие товары.
Создайте БД имен существительных, с возможностью дополнять описание прилагательными и составом(комплектом, набором). Разберите свои прилагательные (они иногда забавны) по принадлежности к существительным, которые станут вашим "каталогизатором" и придайте им "веса" - получите "рубрики" и "подкатегории", которые и станут вашим поисковым фильтром.
Собственно это фсё. Когда-то пробовал крутить такое на Сфинксе.. но железо оказалось "слабовато". Сейчас времена иные и ресурсов у многих в достатке.
Прочёл статью, но не пользователь мессенджера от Яндекса, поэтому по картинкам мало что понял. Возник вопрос:
Может есть причина, но почему различаются чаты и треды-обсуждения? Разве это не многоуровневый чат, который, как и написано выше, может начаться с любого сообщения далее, и в котором автор стартового сообщения может стать его "админом"? Почему не подходит "деревянная" структура?
Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.
Микросервисы? Не, ну можно конечно, если тур-агенство способно закупить супер железо, и выкачивать каждый раз 3/4 БД обращаясь к нескольким сервисам .. транзакционность? Да тоже можно на программном уровне, только стоит ли овчинка выделки для тур-агенства, в котором как правило "3 пленных немца", включая директора.
Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.
Кмк, очень спорно и далеко не всегда полезно. Но, как средство выколачивания из бизнеса денег на покупку самого толстого железа - очень надежно.