False. Тому кто еще не прочувствовал эти правила может показаться что вот именно в его случае можно чем-то пренебречь. С точки зрения его «здравого» смысла конечно.
отличной архитектурой, которую можно было бы доработать под свои нужды,
Ларавел хорош, удобно пользоваться, всё ок пока не придет нужда залезть в их исходники чтобы понять как расширить/переопределить что-то под свои нужды. Да и повсеместные __call() и, как следствие, невозможность «серфить» по коду в IDE не добавляют ощущения отличной архитектуры. Порой хочется грустно посмотреть в глаза таким архитекторам. Правда не так часто нужно лазить под капот.
Наверное в какой-то момент началась ощущаться нехватка общесистемного правого клика на файлах. Все чаще в фаре запускал «start .» чтобы открылся проводник с данной папкой. В целом мой посыл — есть жизнь после фара.
После доса пользовался NC, VC, DN, Far, и когда фар перестал развиваться опечалился. Тотал командер выглядел так уныло. Если кто-то думает так же — попробуйте Altap Salamander. Вот что мне заменяет синие панельки сейчас на винде.
(в линуксе юзаю коммандную строку, привыкнуть к mc не смог)
В общем, я был бы рад, если хоть какая-нибудь часть разработчиков отказалась от бутстрапа в пользу зурба.
Ага, вы как в том ролике: переходите в Bolgenos, а то в винде скучные обои.
Вот все вы бэкендщики одинаковы. Дали вам конструктор, осталось раскрасить — всё равно фантазии не хватает :)
На то он и бутстрап, чтобы его потом закастомайзить. Но можно и готовое взять.
Если же говорить об альтернативах, то все более-менее одинаковы. А если разницы нет, то мэйнстрим имхо всяко лучше.
Пробовал mailbox на айпаде — всё круто, но насторожила куча мистических багов: то в инбоксе показывает письма которые уже в gmail архиве, то наоборот — в mailbox уже смахнул в архив, а в гмейле еще лежит. Сыровато пока.
1. нравится мне линейная история: если фикс мелкий (т.е. не фича-бранча), то перед пушем делаю git pull --rebase, чтобы избежать мерж коммита.
2. когда долго работаю в своей ветке то ребэйс делаю чтобы получить свежие изменения (если что-то критичное починили)
3. если я быстро заметил баг в предпоследнем коммите (и еще не пушал), то коммичу фикс, делаю git rebase -i HEAD~3 и объединяю с тем коммитом в котором я баг добавил. Это чтобы не дефрагментировать историю тайпо-фиксами.
угу, давно сделал себе алиас git up: up = !(git add . && git stash && git pull --rebase >&2) | grep -v 'No local changes to save' && git stash pop
(впрочем это для тех кто знает как резолвить конфликты)
Только graceful degradation это совсем не о том что надо забивать на поддержку старья. Я бы сказал это «помнить о фоллбэке где это возможно». Так скажем вместо span class='Underline' onclick='ajaxload(page)' лучше сделать ссылку с тем же обработчиком и с правильным href. Чтобы могло работать без JS плюс открывало in new tab если надо. И к слову есть еще progressive enhancement. Правда все это уже наверное устарело.
Соглашусь с oledje. Ractive это подобие Angular, не совсем успешная попытка сделать проще. Местами еще сырая.
Я из лагеря которые попробовали и то и другое. Рактив первым — когда столкнулся с задачей сделать сложное миниприложение. А через полгода пришлось разбираться с проектом на ангуларе. Да, с рактивом (после «pure jQuery» подхода) сначала было счастье, но затем начал ловить кучу мелких, но пакостных и сложновоспроизводимых багов, сообщал автору с примерами на jsfiddle. Некоторые он чинил, некоторые обещал посмотреть но забил. Самому же не было времени разбираться, нужен был рабочий инструмент. С энгуларом проблем не было, все работает четко и документации куча. НЕ всё ясно сразу, но и НЕ всё нужно сразу.
Все различия приводимые автором рактива — не плюсы, а ограничения рактива. Энгулар может работать в режиме рактива, но обратное не верно. В энгуларе таки совсем не обязательно использовать свой роутинг, DI, тесты, директивы, сервисы, фабрики и прочее, используй свое, или юзай только датабиндинг — добро пожаловать. Но когда проект (да и разработчик) начнет расти — этот набор пригодится, хотя бы в качестве best practices. Также не стоит заявлять что контроллеры это что-то что необходимо только в энгулар — в рактиве у вас контроллер внутри var Comments = Ractive.extend({...}). Еще автор рактива пугает некими $scope.$digest и $scope.$apply — но в «простом» режиме (т.е. в режиме имитации рактива) с ними скорее всего даже не придется столкнуться/понимать.
Я тоже сначала купился на простоту рактива. Но в работе обнаружил множество сложновоспроизводимых пакостных ошибок. Плюс библиотека сыровата, много чего не хватает. Например: данные обязательно нужно обновлять через Ractive.set(), иногда это не очень удобно (когда скажем кусок данных передаем в метод, и тот не знает всего пути). Банально не хватало Ractive.remove(whatever), потому что Ractive.set(whatever, null) не удаляет whatever, да и не должен. Еще пришлось сделать костыль вроде getRactivePathByDiv() — это когда надо что-то менять у соответственного объекта при клике на связанный div (в энгуларе это решается из коробки и чуть иначе: с помощью аттрибута ng-click='doWhatever(object)' — несмотря на олдскульность вполне удобно). Впоследствии еще обнаружил что в ractive очень не хватает аналога ngIf (ng-if) — возможности вырезать из дома HTML который не отображается (но влияет на скорость парсинга). А размер дома сильно порой влияет на плавность анимации.
Короче говоря, я бы посоветовал начать сразу с энгулара. Это не так сложно как кажется, точнее работать в режиме рактива точно несложно. Но намного полезнее с точки зрения обучения правильным подходам, включая: переходить на deferred вместо коллбэков, к DI и изоляции/тестируемости, устранить надобность в jQuery и её манипуляциях (по крайней мере в контролерах). И много чего еще, не говоря уже о возможности расширяьт HTML новыми тэгами, что самом деле круче декларативности — ведь это декларативность с инкапсуляцией. Впрочем, консерваторы могут опять же обойтись и без этого — angularjs довольно либеральный во всех отношениях.
Подскажите, почему оленемер отваливается при каждом (даже минорном) релизе. Неужели WG не может это починить? Вот не верится что они ломают обратную совместимость постоянно. Зачем им этот цирк с привязкой к номеру версии.
Ларавел хорош, удобно пользоваться, всё ок пока не придет нужда залезть в их исходники чтобы понять как расширить/переопределить что-то под свои нужды. Да и повсеместные __call() и, как следствие, невозможность «серфить» по коду в IDE не добавляют ощущения отличной архитектуры. Порой хочется грустно посмотреть в глаза таким архитекторам. Правда не так часто нужно лазить под капот.
(в линуксе юзаю коммандную строку, привыкнуть к mc не смог)
Дело ваше, конечно, но вы застряли в 20м веке :)
Вот все вы бэкендщики одинаковы. Дали вам конструктор, осталось раскрасить — всё равно фантазии не хватает :)
На то он и бутстрап, чтобы его потом закастомайзить. Но можно и готовое взять.
Если же говорить об альтернативах, то все более-менее одинаковы. А если разницы нет, то мэйнстрим имхо всяко лучше.
2. когда долго работаю в своей ветке то ребэйс делаю чтобы получить свежие изменения (если что-то критичное починили)
3. если я быстро заметил баг в предпоследнем коммите (и еще не пушал), то коммичу фикс, делаю git rebase -i HEAD~3 и объединяю с тем коммитом в котором я баг добавил. Это чтобы не дефрагментировать историю тайпо-фиксами.
up = !(git add . && git stash && git pull --rebase >&2) | grep -v 'No local changes to save' && git stash pop(впрочем это для тех кто знает как резолвить конфликты)
А лопухи, которые не понимают что делают, пускай пеняют на себя.
А почему вы не используете практики MVC для обмена данными с бекендом :)
Только graceful degradation это совсем не о том что надо забивать на поддержку старья. Я бы сказал это «помнить о фоллбэке где это возможно». Так скажем вместо span class='Underline' onclick='ajaxload(page)' лучше сделать ссылку с тем же обработчиком и с правильным href. Чтобы могло работать без JS плюс открывало in new tab если надо. И к слову есть еще progressive enhancement. Правда все это уже наверное устарело.
Я из лагеря которые попробовали и то и другое. Рактив первым — когда столкнулся с задачей сделать сложное миниприложение. А через полгода пришлось разбираться с проектом на ангуларе. Да, с рактивом (после «pure jQuery» подхода) сначала было счастье, но затем начал ловить кучу мелких, но пакостных и сложновоспроизводимых багов, сообщал автору с примерами на jsfiddle. Некоторые он чинил, некоторые обещал посмотреть но забил. Самому же не было времени разбираться, нужен был рабочий инструмент. С энгуларом проблем не было, все работает четко и документации куча. НЕ всё ясно сразу, но и НЕ всё нужно сразу.
Все различия приводимые автором рактива — не плюсы, а ограничения рактива. Энгулар может работать в режиме рактива, но обратное не верно. В энгуларе таки совсем не обязательно использовать свой роутинг, DI, тесты, директивы, сервисы, фабрики и прочее, используй свое, или юзай только датабиндинг — добро пожаловать. Но когда проект (да и разработчик) начнет расти — этот набор пригодится, хотя бы в качестве best practices. Также не стоит заявлять что контроллеры это что-то что необходимо только в энгулар — в рактиве у вас контроллер внутри var Comments = Ractive.extend({...}). Еще автор рактива пугает некими $scope.$digest и $scope.$apply — но в «простом» режиме (т.е. в режиме имитации рактива) с ними скорее всего даже не придется столкнуться/понимать.
Я тоже сначала купился на простоту рактива. Но в работе обнаружил множество сложновоспроизводимых пакостных ошибок. Плюс библиотека сыровата, много чего не хватает. Например: данные обязательно нужно обновлять через Ractive.set(), иногда это не очень удобно (когда скажем кусок данных передаем в метод, и тот не знает всего пути). Банально не хватало Ractive.remove(whatever), потому что Ractive.set(whatever, null) не удаляет whatever, да и не должен. Еще пришлось сделать костыль вроде getRactivePathByDiv() — это когда надо что-то менять у соответственного объекта при клике на связанный div (в энгуларе это решается из коробки и чуть иначе: с помощью аттрибута ng-click='doWhatever(object)' — несмотря на олдскульность вполне удобно). Впоследствии еще обнаружил что в ractive очень не хватает аналога ngIf (ng-if) — возможности вырезать из дома HTML который не отображается (но влияет на скорость парсинга). А размер дома сильно порой влияет на плавность анимации.
Короче говоря, я бы посоветовал начать сразу с энгулара. Это не так сложно как кажется, точнее работать в режиме рактива точно несложно. Но намного полезнее с точки зрения обучения правильным подходам, включая: переходить на deferred вместо коллбэков, к DI и изоляции/тестируемости, устранить надобность в jQuery и её манипуляциях (по крайней мере в контролерах). И много чего еще, не говоря уже о возможности расширяьт HTML новыми тэгами, что самом деле круче декларативности — ведь это декларативность с инкапсуляцией. Впрочем, консерваторы могут опять же обойтись и без этого — angularjs довольно либеральный во всех отношениях.
Эх, а чего бы не засунуть туда запасную батарейку, она б еще и вес уравновешивала :)