Забавно, что статья так подробно описывает количественные характеристики (и вполне логично находит их бесполезными) и обходит молчанием качественные. К примеру, всего один, но весомый PR в репозиторий с серьезным code review позволит многое сказать о кандидате, начиная от умения разобраться в чужом коде до способности взаимодействовать с другими разработчиками.
Почти все описания Redux начинаются со слов «управление состоянием в современных приложениях — сложная штука, поэтому мы придумали Redux, чтобы решить её» Вот, к примеру, здесь. Т.е. первым предложением создается проблема, а следующим предлагается великолепное решение. И решение выглядит как серебрянная пуля, которая необходима всем разработчикам SPA. Очень хочется увидеть пример, где демонстрируются, а не декларируются преимущества Redux и описываются области применения.
Разные виды типизации нужны для достижения одной цели: обнаружение ошибок до запуска проекта и они элементарно сравниваются по усилиям, необходимыми для внедрения и по количеству обнаруженных ошибок.
То что какой-то человек задает такой вопрос на собеседовании не доказывает его корректность. Попробуйте измерить время такого запроса и вы приятно удивитесь. Поймите, что расходы на массу абстракций, которые существуют поверх физической пересылки байт между компьютерами столь высоки, что сравнение 5 или 50 байт пароля просто утонут в этом море.
Пример мне кажется некорректным. Это немыслимо, чтобы время исполнения запроса на сравнение пароля зависило бы от длины пароля, если конечно длина пароля меньше тысячи символов. Накладные запросы на обработку сетевого запроса, выделение под него динамических объектов в JS, паузы GC, работа других процессов в системе, пападание-непопадание строки в кэш процессора, запрос к БД и степень её разогретости. Есть тысячи факторов от которых зависит время исполнения запроса и для простого пароля его длина, мне кажется, занимает почетное последнее место.
Когда-то пользовался и задавал пару вопросов. Сейчас зашел и минут 5 тыкал по интерфейсу чтобы просто увидеть список МОИХ вопросов и ответов (как на SO)… не нашел. Только случайно догадался тыкнуть на иконку профиля. Неплохо бы как-то акцентировать внимание на этом элементе
1) Мне думается, что вы здесь намеряли не скорость чтения файла, а скорость взятия файла из кэша. Нужно читать разные файлы, а не один и тот же
2) Какой смысл теста без указания ОС, типа носителя и файловой системы? Там тоже результат может отличаться в разы!
думаю WebGL из сравнения лучше убрать или подходить к сравнению столь далеких друг от друга технологий в более узком контексте, нежели «работа с графикой»
я заметил на последнем коллаже, как дерево модели на WPF отрисовано поверх 3D модели. Интересно, как получилось это скрестить без просадки производительности?
1)В Sketchup набросать план получится за час, у меня, скажем, за 10 мин. в спец программе намного быстрее работать. Там вы работаете с полигонами, а тут с розетками, окнами и стенами
2)Моя фишка — точные размеры и быстрое редактирование, увы Sketchup — Paint по меркам САПР
3)С веб-версией идёт куча плюшек вроде оценки нужных стройматериалов прямо с телефона в магазине
А что это за параметр и как вы его измеряете?) У меня скорость создания 100 гигакирпичей в секунду))))
А если серьезно, то дьявол кроется в деталях и если вы занимались этой темой, то сможете увидеть между строчек кое какие особенности. Я для примера покажу одну вещь: моделирование планировки, в сравнении с указанным вами Планопланом:
1) В планоплане задется размер стен, у меня — размер комнат, вы можете заметить это на иллюстрациях. Разница принципиальная: в купленой квартире измерить абстрактный размер между центрами стен не представляется возможным. И когда вы проектируете сложное многокомнатное помещение с кривыми стенами построить модель по размерам, которые вы измеряете — не самая простая вещь.
2) Возможность моделирования единообразно на видах и в 3d. Т.е. для меня разница между видом и 3d лишь в положении камеры, в большистве аналогов моделирование возможно лишь в плане. У меня все функции доступны на любых проекциях.
3) Из предыдущего пункта легко вытекает проектирование многоэтажных конструкций именно в 3D
4) Динамическое редактирование всех размеров прямо на модели и уже сейчас реализовано 7 различных спобов
Ведь самое интересное начинается, когда построив план вы построили и обнаружили, что пару размеров нужно поменять и эти инструменты будут востребованы.
5) Корректный расчет площадей всех помещений, с учетом монолитных колонн. В планоплане я вижу расчет абстрактной площади по серединам толщины стен
6) Полноценное моделирование стен, без разбивание их на части касательными стенами
Это я на вскидку перечислил возможности только касательно проектирования плана помещения. В других частях тоже есть немало интресных моментов.
PS: круто если пример будет на Angular т.к его ChangeDetection способствует упрощению кода
2) Какой смысл теста без указания ОС, типа носителя и файловой системы? Там тоже результат может отличаться в разы!
2)Моя фишка — точные размеры и быстрое редактирование, увы Sketchup — Paint по меркам САПР
3)С веб-версией идёт куча плюшек вроде оценки нужных стройматериалов прямо с телефона в магазине
А если серьезно, то дьявол кроется в деталях и если вы занимались этой темой, то сможете увидеть между строчек кое какие особенности. Я для примера покажу одну вещь: моделирование планировки, в сравнении с указанным вами Планопланом:
1) В планоплане задется размер стен, у меня — размер комнат, вы можете заметить это на иллюстрациях. Разница принципиальная: в купленой квартире измерить абстрактный размер между центрами стен не представляется возможным. И когда вы проектируете сложное многокомнатное помещение с кривыми стенами построить модель по размерам, которые вы измеряете — не самая простая вещь.
2) Возможность моделирования единообразно на видах и в 3d. Т.е. для меня разница между видом и 3d лишь в положении камеры, в большистве аналогов моделирование возможно лишь в плане. У меня все функции доступны на любых проекциях.
3) Из предыдущего пункта легко вытекает проектирование многоэтажных конструкций именно в 3D
4) Динамическое редактирование всех размеров прямо на модели и уже сейчас реализовано 7 различных спобов
Ведь самое интересное начинается, когда построив план вы построили и обнаружили, что пару размеров нужно поменять и эти инструменты будут востребованы.
5) Корректный расчет площадей всех помещений, с учетом монолитных колонн. В планоплане я вижу расчет абстрактной площади по серединам толщины стен
6) Полноценное моделирование стен, без разбивание их на части касательными стенами
Это я на вскидку перечислил возможности только касательно проектирования плана помещения. В других частях тоже есть немало интресных моментов.