All streams
Search
Write a publication
Pull to refresh
9
0
Колесников Роман @x512

User

Send message
да, видел, но не понимаю к чему вы его упомянули? Он не адресует ни одну из описанных мной проблем — я там не увидел ни текста, ни толстых линий, ни нормального wireframe. Cсылок на batching я тоже не нашел. Плюс к этому зависимость от Java мне не очень подходит.
Скажите, вы уже раскрывали или может быть планируете следующие моменты:
1) Инстинкты — как они формируются в организме, в какой памяти хранятся и как они в целом вписываются в вашу модель
2) Согласно вашей концепции, есть ли принципиальная разница между логикой сознания человека и животного… насекомого?
Ребят, а чем вам refresh_token не угодил-то? Вместо этого городить Redis и постоянно на каждый чих делать туда запросы на блеклист токена это моветон.

Текущего пользователя нужно доставать далеко не всегда, наоборот JWT создан для того чтобы в нем хранить скажем, его роли,, а не лазить за пользователем постоянно в базу.

В итоге ваш велосипед приводит к минимуму 2 обращениям к двум разным базам на каждый запрос… Оптимизация в действии.
Отличная статья! Есть пожелание использовать для примеров Identity Server 4 у которого уже вышел первый релиз-кандидат и подробнее рассмотреть авторизацию и аутентификацию в клиентских SPA.
У вас, как я понимаю, Facebook авторизация сделана по старинке через всплывающее окно? Почему не через редирект?
Дело в том, что SPA приложения практически не загружают HTML c сервера — они его генерируют через JS. Т.е. результирующую страницу вы не получите, пока не отработает весь JS код. В результате получается, что 90 процентов время загрузки страницы тратится на исполнение JS и его взаимодействию с DOM. Создание современного движка JS с поддержкой фич вроде async и генератов видится мне нетривиальной задачей даже для опытной команды. А подключение любого из современных движков JS будет и сложно и неэффективно, т.к. все они (SpiderMonkey, Edge, V8) разработаны с учетом использования из С++ кода и сами на нем же, очевидно, и написаны.

Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servo
На современных HTML страницах много JavaScript, а во все более набирающих популярность SPA их ОЧЕНЬ МНОГО, на порядок больше CSS кода и производительность в таком случае упирается в производительность JS (а точнее, зачастую в скорость манипуляции DOM через JS). Неужели вы планируете поддерживать JavaScript тоже? И даже если так, то затупы JS сведут все оптимизации с парсингом HTML/CSS в никуда.
А то, что приятные глазу команды процессора в машинном коде заменены на всякие операторы и идентификаторы у вас неприятных ассоциаций не вызывает?)
Ожидал увидеть в статье важный на мой взгляд тезис, что основное преимущество JavaScript (и других интерпретируемых языков) состоит в компиляции на компьютере пользователя и наличии интерпретатора с профайлером перед компилятором в машинные коды. Первое позволяет компилировать код в самые эффективные команды, доступные на запускаемой архитектуре. А второе позволяет эффективно оптимизировать основной путь исполнения кода. Ну и конечно JS позволяет делать эффектные оптимизации с помощью кодогенерации.
Тогда вам стоит задуматься о переходе к ассемблеру или к brainfuck-у на худой конец и использовании розг в учебном процессе.
Только вчера обнаружил еще одну приятную вещь: если на главной странице проекта вызвать диалог выбора ветки (клавиша w) и ввести несуществующее название, то он предложит создать новую ветку с набранным именем
скажите, а какое меню открывается при нажатии на слоеную кнопку в левом верхнем углу? По идеи там должен вылезать sidebar. Если так, то какие там категории?
Я думаю к сравнению стоит добавить еще один открытый проект https://github.com/gitbucket/gitbucket
Эх, где вы были пару лет назад?!!! Пришлось городить свои костыли. А так вещь нужная — мне потребовалсь для того чтобы сделать Entity-Component-System. вот для того чтобы в Entity хранить массив разнородных компонентов это решение в самый раз.
Сравнение конечно не самое лучшее и многое о чем автор позабыл (и дремучие ошибки компиляции темплейтов и сама скорость компиляции и вообще инструменты отладки кода (увы, это относится и к языку, т.к. сделать для C++ аналогичные удобные инструменты малореально), и сахарные возможности C# вроде оператора?.. и многое-многое другое) Однако автор мыслит абсолютно прагматично. И я бы сделала такой вывод: при создании нового проекта где нет жестких требований вроде переносимости под какие-то редкие платформы и/или полное отсутствие рантайма и сборщика памяти или необходимости тесного взаймодействия с другими С++ библиотеками, то писать такое приложение на С++ — чистое безумие.
я решил написать библиотеку своей мечты
А чем вам protobuf не угодил?
Вы капитан очевидность. Именно потому что она переписана чуть ли не с нуля и возник вопрос актуальности проблем, описанных статье.
все описанные проблемы также актуальны для EF7?
Включен, но настройка его компиляции достаточно ограничена. Неясно, как группировать файлы для компиляции в единый JS и использовать AMD лоадеры с получившимися файлами. Мой вопрос — использовать gulp или более совершенные инструменты будут в VS из коробки.

Information

Rating
Does not participate
Location
Коломна, Москва и Московская обл., Россия
Date of birth
Registered
Activity