gbezyuk
0
Теоретически я с вами согласен, нейросеть мозга в теории должна быть способна распознавать визуальные образы в отрыве от аудиальных. Осталось переспорить томограф.
gbezyuk
+1
Насчёт интерактивных учебников нельзя не упомянуть hooktheory.com
И да, к чёрту 3D.
gbezyuk
0
для дешёвых сайтов только для русского рынка — ничего плохого, один хрен PHP ;)
но конечно лучше писать всегда как будто вам код на международной конференции показывать — дисциплинирует, и в конечном счёте упрощает жизнь и повышает доход.
gbezyuk
0
Серверный рендеринг для SPA — просто необходимость, если вы SEO хотите какое-то человеческое иметь, и стартовое состояние страницы. Заодно и сетевые задержки улучшаются, и в целом UX пользователя.

Но Nuxt не про это (как и Next) — с этим, как справедливо было замечено, вполне справляется Vue (и React, соответственно). Nuxt позволяет писать полноценные Vue-приложения настолько просто, насколько просто писать статические html-сайты — и это очень круто, честное слово.
gbezyuk
0
А переводя книги, переводчики порождают класс некомпетентных читателей? =)
gbezyuk
–1
Хоть бы глянули на доки =)
gbezyuk
0
А выход Vue.js 2.x как бы не заметили, да? =)
gbezyuk
0
Спасибо за спасибо!
gbezyuk
+1
Dirty-checking алгоритмически таков, что даёт мягко говоря нелинейный рост, так что я не соглашусь — «уметь готовить» его можно разве что в режиме «использовать в очень ограниченном объёме». Он же не от хорошей жизни применяется, а из-за отсутствия возможности применить более эффективный подход. Vue отказался от двухстороннего связывания (Flux же, не нужно оно) и поддержки старых браузеров — и dirty checking не понадобился, и работает всё шустро. Кроме первого Ангуляра есть ещё ряд фреймворков с аналогичными проблемами, опять таки — в документе-сравнении упоминались.
gbezyuk
+1
Напомните, вы чего доказать-то хотите?
gbezyuk
0
Гмм, если всё действительно так, как вы описываете, рост тормозов с увеличением размера не денется никуда, и для серьёзных проектов такой подход не годится. Но что-то я сомневаюсь, чтобы при переходе ко второй версии там всем известной основной проблемы первой не пофиксили.
gbezyuk
0
Да ладно? https://github.com/translation-gang/ru.vuejs.org/graphs/contributors
Вы наверное про список членов организации, там да — не все публичность включили.
gbezyuk
0
В Angular2, насколько мне известно, dirty-checking тоже нет. Но он громоздкий очень, особенно по сравнению с Vue.
gbezyuk
0
Коротко — у Vue с производительностью всё хорошо. Конкретно у первого Angular основная проблема была в dirty checking, у Vue такой проблемы нет. Подробнее — в вышеупомянутом документе со сравнением с другими фреймворками.
gbezyuk
0

Напрямую не получится, но адаптировать можно — JSX понимать умеет.

gbezyuk
0
Начинаешь вообще с одной строчки подключения скрипта, если хочется просто попробовать.

Для серьёзных проектов есть шаблоны и CLI.
gbezyuk
+1
самая приятная фишка — однофайловые компоненты .vue
в целом — всё просто работает из коробки, никаких танцев с бубнами как при сборке react/redux-проектов
с angular сравнивать некорректно, первый — был давно, а второй — уж больно тяжеловесен, не так категория
gbezyuk
0
Кстати, в документации есть специальная страница сравнения с другими фреймворками: https://ru.vuejs.org/v2/guide/comparison.html
gbezyuk
0
«Переписанный начисто React», без переизобретения CSS/HTML внутри JS и с централизованной поддержкой всей экосистемы; с возможностью инкрементального внедрения; некоторые красивые фишки понадёрганы из Angular, но нет dirty-checking с его проблемами производительности
gbezyuk
0
> Ожидает merge'а деплоя документация vue-router, появится здесь: router.vuejs.org/ru
gbezyuk
+3
>> За свою жизнь я не видел ни одного программиста C++, изучившего Java, а потом заявившего «Нет, мне не нравится этот язык, C++ лучше».

Посмотрите на меня =)

А Scala лучше Java — это факт. Впрочем, не нужно быть чем-то невероятным, чтобы быть лучше Java.
gbezyuk
0
Графики очень крутые, научите такие делать.
По приложению — попробовал настроиться, моментально потерялся и отказался от этой затеи. В общем, не смог преодолеть входной порог интерфейса.
За открытые исходники — отдельное спасибо.
gbezyuk
+5
Старый как мир вопрос с бессмысленной спешкой. Когда дедлайн не мотивирован физическими ограничениями, если вы понимаете что не укладываетесь в него — надо его просто отодвинуть. Бизнесу объяснить это сложно, но объясняться после вынужденных спешкой факапов — в ряд ли легче.
gbezyuk
0
я просто спросил. webpack это умеет из коробки dev-server'ом, и этим активно пользуется, например, Dan Abramov в своём redux-devtools.
gbezyuk
0
А hot reloading require.js умеет?
gbezyuk
0
а вот статья говорила.
gbezyuk
+5
Мой опыт показывает обратное. Самые вкусные позиции — это «умный опытный разработчик вообще».
gbezyuk
0
Наташа молодец ;) Хороший туториал.
gbezyuk
+1
Ну обозвали вы классы интересов «интравертами» и «экстравертами», ну сделали их произведением 4-х бинарных классификаторов. Всё равно это всего лишь группировка по интересам, а про «типы личностей» — притянуто за уши, уж простите.
gbezyuk
0
Для обратной связи, например. И да, это будет действительно нейроинтерфейсом, в то время как описанное в статье надо как-то по-другому называть, чтобы терминологически точно было.
gbezyuk
+4
Не вполне понятно, почему «хранение данных в памяти» считается недостатком. Хассо Платтнер* уже давно показал, что с текущим соотношением быстродействия оперативки и накопителей и их возможностями масштабирования — данные в памяти хранить не только можно, но и нужно; а на дисках — по сути дела бэкапы. *(see open.hpi.de/courses/imdb2015 for details)
gbezyuk
0
Это не «типовая проблема функциональных языков», это очевидная проблема масштабирования данной «лабораторной» реализации. То есть по сути это «проблема микроскопа» в ситуации забивания им гвоздей.
gbezyuk
+2
После заглавного фото я уже ничему не удивлялся.
gbezyuk
+3
А все остальные статьи на Хабре, следуя логике — находка для нерадивых программистов, желающих «нагрузить» якобы тайным смыслом работы.
gbezyuk
+1
Метод сравнения по Stack Overflow говорит скорее о средней по популяции использующих язык склонности искать решения самостоятельно и не задавать (простых и глупых) вопросов.
gbezyuk
+4
>> Чтобы просто установить и изолировать зависимости проекта, virtualenv часто оказывается слишком тяжелым решением.
серьёзно? можно реальный пример?
gbezyuk
0
Было бы интересно прочесть не менее подробное описание систем собственно международных платежей. Центробанк внутри страны-то понятно как работает и зачем нужен, но в той же аббревиатуре SWIFT есть любопытная буковка «I».
gbezyuk
+1
Я пока на Шри-Ланке жил, попытался закрепить знания сингальского небольшой веб-страничкой. Не смог: символы-то вроде все есть, а вот порядок применения гласных к согласным как-то не очень определён и разнится от редактора к редактору. Рисовать же, само собой, поленился.
А письменность сингальского сильно проще того же бенгальского.