Мы применяли AOP/AspectJ одно время. Потом отказались, т.к. он значительно увеличивает время компиляции, ну и поддержка AOP в эклипсе была реализована, скажем так, не очень. Оказалось, что писать логгирование и обработку ошибок в нужных местах вручную не так уж и сложно :-)
Интересно использование AOP вместо самодельных правил для checkstyle… Выглядит, во всяком случае, короче.
Никогда не понимал, зачем делать ссылки, непохожие на ссылки, и кнопки, непохожие на кнопки. Бедные пользователи. Они так не любят (в который раз) переучиваться.
Когда-то на хабре была замечательная статья https://habrahabr.ru/post/235121/
Атомы с самоподпиской я удачно скрещивал с реактом, что позволяет вообще обойтись без component state и всяких-разных Flux, призванных этим состоянием управлять.
На функционал пока не смотрел, но ТС забыл одно из самых важных преимуществ своего подхода — 16 kb gzipped. Это уже позволяет задуматься о stateless rendering людям, которым небезразлично UX на мобильных устройствах.
Судя по тому, что библиотека собрана webpack, там еще есть к чему стремиться в плане размера и скорости старта.
Весь рендер выполняется на сервере, динамика реализована путем POST запросов, которые возвращают HTML, вставляемый в нужное место.
Никаких библиотек, всё написано на чистом яваскрипте.
Никакой минимизации и объединения ресурсов, система навигации умеет подгружать скрипты и стили динамически по необходимости
Серверная часть написана на С, что обеспечивает минимальное время отклика
поддерживается как навигация через ajax, так и полностью серверный рендер. Т.е. при навигации с сервера подгружаются куски HTML в нужные места DOM, но если обновить страницу, то она придет сразу целиком. Идеальное решение для SEO.
Из минусов:
клиентский яваскрипт представляет из себя жуткий спагетти, написанный без внимания к каким-либо стандартам и даже без use strict
серверная часть тоже должна быть весьма, весьма сложна...
Я не спорю, что пока они не реализовали перехват TLS траффика. Но как еще можно объяснить пассаж с "гугль работать перестанет"? На самом деле, конечно, есть два варианта:
они действительно собираются перепаковывать чужой TLS траффик
это просто страшилка, чтобы пользователи поставили себе этот сертификат, без которого будут проблемы не с гуглем, а с гос. сайтами. Но надо же думать головой, а не одним местом, когда такое пишешь...
Утилиты командной строки в линуксе. Идея в том чтобы сделать аналог port forwarding, только с шифрованием траффика. Пока кто-нибудь не напишет внятный мануал, нужен навык системного администрирования или программирования.
Решение — использовать ВПН и скремблирование траффика.
Скомбинировав netcat и openssl, можно получить TCP-туннель, шифруемый AES, и пускать OpenVPN уже по нему.
При таком подходе какая-либо идентификация траффика по сигнатурам невозможна.
инкрементальные бэкапы — это всё замечательнои у нас они есть, но обязательное требование — автоматическая доступность базы при отказе одного хоста. И крайне желательно, чтобы при отказе мастера не пришлось потом руками медленно и печально восстанавливать недореплицированные данные. Неужели писать координатор самому — единственное решение?
Нам нужно избежать потери данных, если НЛО внезапно похитит мастер-ноду. Мы рассчитывали, что синхронная репликация мастер-слейв с автоматическим переключением на слейв в read-only mode нам обеспечит целостность, отсутствие даунтайма и возможность выполнять часть запросов на слейве. А вы тут рассказываете, что это невозможно в принципе...
Мы применяли AOP/AspectJ одно время. Потом отказались, т.к. он значительно увеличивает время компиляции, ну и поддержка AOP в эклипсе была реализована, скажем так, не очень. Оказалось, что писать логгирование и обработку ошибок в нужных местах вручную не так уж и сложно :-)
Интересно использование AOP вместо самодельных правил для checkstyle… Выглядит, во всяком случае, короче.
Это всё библиотеки. react + диспатчер + underscorejs какой-нибудь + прочие плюшки — вот скомпилированный js и вылез за мегабайт.
гм, и правда бред
Просто дождитесь следующего айфона :-)
Никогда не понимал, зачем делать ссылки, непохожие на ссылки, и кнопки, непохожие на кнопки. Бедные пользователи. Они так не любят (в который раз) переучиваться.
Когда-то на хабре была замечательная статья https://habrahabr.ru/post/235121/
Атомы с самоподпиской я удачно скрещивал с реактом, что позволяет вообще обойтись без component state и всяких-разных Flux, призванных этим состоянием управлять.
Не думали в эту сторону?
Здесь — 16: https://cdnjs.cloudflare.com/ajax/libs/vidom/0.3.3/vidom.js
Наверное, где-то есть минимизированная версия, но я ее не нашел
На функционал пока не смотрел, но ТС забыл одно из самых важных преимуществ своего подхода — 16 kb gzipped. Это уже позволяет задуматься о stateless rendering людям, которым небезразлично UX на мобильных устройствах.
Судя по тому, что библиотека собрана webpack, там еще есть к чему стремиться в плане размера и скорости старта.
В плане UX идеалом я считаю вконтакте:
Из минусов:
Я не спорю, что пока они не реализовали перехват TLS траффика. Но как еще можно объяснить пассаж с "гугль работать перестанет"? На самом деле, конечно, есть два варианта:
Было бы похвально, если бы не последний абзац про недоступность google по HTTPS без установки сертификата
Утилиты командной строки в линуксе. Идея в том чтобы сделать аналог port forwarding, только с шифрованием траффика. Пока кто-нибудь не напишет внятный мануал, нужен навык системного администрирования или программирования.
Решение — использовать ВПН и скремблирование траффика.
Скомбинировав netcat и openssl, можно получить TCP-туннель, шифруемый AES, и пускать OpenVPN уже по нему.
При таком подходе какая-либо идентификация траффика по сигнатурам невозможна.
Странно, что нигде нет сравнения с Solr/ElasticSearch. Они тоже активно используются в качестве аналитических БД.
Да, почти в любом деле главное — без фанатизма :-)
Статья хорошая, но немного однобокая. Часто в бизнесе, как и в армии, посредственное решение сейчас ценнее, чем хорошее — потом.
инкрементальные бэкапы — это всё замечательнои у нас они есть, но обязательное требование — автоматическая доступность базы при отказе одного хоста. И крайне желательно, чтобы при отказе мастера не пришлось потом руками медленно и печально восстанавливать недореплицированные данные. Неужели писать координатор самому — единственное решение?
Практически не отстает, но мы не хотим терять данные, вообще не хотим терять данные. Что хотелось бы иметь:
Если это возможно сделать, пожалуйста посоветуйте как или ткните куда читать.
Нам нужно избежать потери данных, если НЛО внезапно похитит мастер-ноду. Мы рассчитывали, что синхронная репликация мастер-слейв с автоматическим переключением на слейв в read-only mode нам обеспечит целостность, отсутствие даунтайма и возможность выполнять часть запросов на слейве. А вы тут рассказываете, что это невозможно в принципе...
https://www.freelancer.com/