Как стать автором
Обновить
11
0
Алексей Хомченко @gagoman

Пользователь

Отправить сообщение
Хороший пример — Cassandra. Написана на Java, кушает себе память и кушает. Конечно, гиганты типа Facebook держат in-house патчи или что-то такое для их объемов, но для большинства — оно работает.
И с каждым улучшением GC Java (вплоть до специально для Cassandra написанного) все пользователи
будут получать улучшение производительности или репортить баг и получать улучшение производительности.

И есть scylladb (не умаляю труда разработчиков), которая год назад только и умела, что сыпать краш дампы.

Для меня лично плюс GC в том, что я уже получаю тысячи часов работы умных людей и могу решать задачу.
А если мне понадобится оптимизировать какое-то место, то есть умные коллеги, которые сделают выбор
free vs delete или, что скорее, скажут заменить O(n^3) на O(n)
Разные проекты, требования, подходы и сроки. Где NASA может тратить 1000$ на строчку кода, обычно тратится в разы меньше. Этим и вызван взрывной рост интернета. Если бы все писали, считая delete vs delete[] vs free, то непонятно где бы мы были. Все как всегда — «каждой задача по технологии»
Вижу бенчмарки в JS, вспоминаю mraleph: https://www.youtube.com/watch?v=HPFARivHJRY
Вижу бенчмарки в Java, вспоминаю @shipilev
Что-то у вас не так работало. То, что `venv` добавили в поставку это правда. А так — `pip` должен быть сразу.
Routable Components, которые никак не доедут, уберут понятие Controller, а с ним и доступ напрямую через model. Будет или attrs как в React, или что-то подобное

https://github.com/ef4/rfcs/blob/routeable-components/active/0000-routeable-components.md
https://gist.github.com/samselikoff/1d7300ce59d216fdaf97
На счет первого, в дальнейшем не будет доступа через model, так что имеет смысл уже не писать через него, а делать напрямую через setupController, который тоже должен уйти.
На самом деле сейчас в Ember тот еще разброд и шатание (сам пишу на нем с 1.3).

В идеале, в вашем примере нужно:

  • использовать

    setupController(controller, models) {
      controller.setProperties(models);
    }

    чтобы перестать использовать model. в шаблонах (deprecated)

  • input использовать согласно DDAU (ох уж эти любители акронимов) и с <> скобками

  • rollbackAttributes пока что не умеет работать с belongsTo / hasMany

А так, куча вещей помечено deprecated, но при этом замены пока нет.
А могли бы подсказать где это окно?

Спасибо
Есть предложения, как сделать быстрей? Jin быстрее React?
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.


Сейчас переходят на компоненты, a-la React. Но в целом, конструкций вида this.controllerFor хватало. Опишите детальней пример, подумаю, как можно решить, потому что сам много раз бодался.
А куда пропала возможность настроить кол-во столбцов в экспресс-панели?
GWT еще легок по сравнению с Vaadin. Был с последним опыт — это что-то для тех, кто не хочет писать под веб, но их заставили и они пишут как под десктоп.
Почему вы не используете обычные средства языка для манипуляций над коллекциями? Если их не хватает, есть lodash/lazyjs/whatever.

К примеру, ваш код на ES6:

// First sample

const isEven = n => n % 2 === 0;

const numbers = [4, 8, 15, 16, 23, 42, 108];

numbers.filter(isEven).map(n => n + 5); // [9, 13, 21, 47, 113]

// Second sample

const toLower = s => s.toLowerCase();
const reverse = s => s.split('').reverse().join(''); // TODO: look for Unicode-aware reverse

const strings = ['abcde', 'xyZ', 'HAAR'];

strings.map(toLower).map(reverse); // ["edcba", "zyx", "raah"]
Ember хорош, но в тоже время «магия» иногда приводит к значительным остановкам, а некоторые вещи нельзя сделать до определенной версии Ember.

ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу

но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним

В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.
Это то, к чему они идут в 2.0. Т.е. все property, фильтры и прочее в Route?
Пишу на Ember. По началу — все радужно. Потом всплывают разные косяки, которые обещают починить в 2.0

Основное, что считаю поломанным сейчас:
1. собственно EmberData. Да, оно в бете, и грех жаловаться, но готовьтесь к тому, что: rollback не работает на one-to-one, one-to-many, DataBoundPromise никак не доедут до релиза
2. документация отличная, но не покрывает все моменты (некоторые вещи приходится смотреть прямо в коде)
3. многострадальные queryParams. Они вроде как есть, но некоторые вещи в них не работают и на них заведено много issue
4. синглтон контроллеры настолько всем не нравятся, что их убирают в 2.0
5. сложно писать сложные компоненты, где требуется обновление большого кол-ва property и не хватает one-way binding property. Новый подход к компонентам обещают в 2.0 (больше похоже на React)

Что действительно радует — роутер, к нему претензий нет.

Судя поrfc для 2.0, они хотят с помощью HTMLBars + one-way binding сделать компоненты похожими на React, но при этом использовать всю мощь роутера и EmberData для моделей
У вас их сколько? 10-20-100? Если много, то скорее всего вы используете или какой-то шаблон их создания/запоминания или просто разделяете на важно/не сильно важно/вообще не важно и для каждой группы делаете пароль. Если же вы реально помните кучу уникальных, сложных паролей, то снимаю шляпу.
1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Днепр, Днепропетровская обл., Украина
Дата рождения
Зарегистрирован
Активность