Не верится, что кто-то наконец сделал это все в Ruby в совокупности.
В свое время приходилось делать подпись XML через такую-то матерь.
Тогда начал писать свой Signer-гем и обертку для гостовых алгоритмов через патченный OpenSSL, но так и не дописал, так как проект закрыли и стало неактуально.
Сейчас такая необходимость может снова возникнуть и попробую это решение. Спасибо!
Вторая проблема, как и третья, решаются одинаково: $scope — это не модель, а контейнер моделей. Столько копий уже об это сломано.
Так что ваш пример, хоть и корректен, но является плохой практикой.
Если есть необходимость обнулять массив, то это сигнал, что он должен быть свойством другого объекта (модели)
$scope.model.array
Раньше еще часто замечали, что в ng-model должна быть минимум одна точка, тогда никогда не словите эту проблему и не будете иметь геморроя с хаками вроде array.length = 0…
По опыту: рано или поздно, если нарушать это правило, проблему не только словите, но и пропустите в продакшн, не заметив где-нибудь, и вот тогда уже перестаните это делать.
Можно манипулировать на подсознательном уровне, не добиваюсь стабильного результата, а можно делать это систематично и преследовать определенный цели, такие как выполнение работы в срок, повышение ее качества и т.д.
От этого манипуляция не станет быть какой-то более открытой или безчеловечной.
Мне показалось, что автор статьи как раз за разумное использование манипуляций, а не за пускание пыли в глаза.
Статья, безусловно, очень интересная. Знаю немало людей, которые пытаются сейчас выстроить нечто подобное.
Я же всегда при разговорах на подобную тему высказывался, что пользы от сайтов, произведенных по такой схеме, практически никакой нет. Максимум они годятся для неких пилотных проектов, чтобы просто нащупать почву в интернете. Но и это спорно. Поэтому жду с нетерпением статьи с небольшим анализом реальной пользы таких сайтов.
Аналогично. И тоже не нарадуюсь. Это теперь одна из тех программ, из-за которых слезть с мака на что-либо другое будет проблематично, уж больно она хороша.
Первая моя мысль, когда увидел начало статьи: наконец-то кто-то реализовал эту идею на практике и задокументировал :) Спасибо!
Обязательно покажу эту статью своим верстальщикам и сам попробую в деле.
На данный момент пользуюсь активно SASS через запуск компилятор в консоли. До настройки HAML пока просто руки не дошли. С CoffeScript дела обстоят сложнее, потому что редко когда приходится писать что-то сложное для фронтенда и вполне достаточно простого JS + jQuery, но в случае чего можно будет эту часть Padrino не использовать.
Ваш пример показывает, что вы ответственный работник. Вероятно, либо у вас есть такое человеческое качество изначально, либо внутри компании хорошо организован процесс и есть понимание того, что нужно делать в той или иной ситуации.
На практике же работник не всегда может правильно и вовремя определить, в чем проблема (в нем или его работе), поэтому слишком поздно становится понятно, где находится узкое место.
У меня была эта проблема. Не найдя решения, решил, что больше никогда в жизни не буду запускать Django из-под Windows и настроил Linux в виртуалке (VirtualBox), а потом настроил внутреннюю сеть между Windows, где по-преднему велось написание кода и верстка, и виртуалкой.
После этого моя жизнь стала похожа на сказку :) Никаких тебе проблем с компиляцией Python-модулей под Windows, никаких левых ошибок.
Разработка изначально не велась на Linux потому, что мне не нравится UI и скорость работы моих основных инструментов из-под Linux. На Windows с этим попроще.
PS: с тех пор я уже успел перелезть на Mac, на котором эта проблема отпала сама собой :)
Главное преимущество — экономия времени, потому что меньше кликов, особенно в узкие циферки пагинатора.
И есть еще один недостаток — невозможно доскроллить до футера, поэтому требуется какой-то другое интерфейсное решение, либо вообще футер убрать и перенести все го элементы в другое место.
Я бы сакцентировал побольше внимания на независимости отдельных обработчиков (то есть, как я понял, на том, что они могут быть частью совершенно разных модулей) и на том, что все это затевается ради приоритезации. Как-то из статьи это не сразу становится понятным, или я что-то упускаю.
Другой вопрос, что я ни разу не сталкивался с такой необходимостью. Поэтому моя первая реакция была та же, что и у @akaBd, то есть подумалось, что что-то не так с дизайном системы.
Конкретно эта задача возникала у меня не раз и всегда получалось решить ее очень просто. В частности, в Django, где используется некое подобие MVC, эту логику можно разместить во вьюхе и даже в зависимости от ситуации передавать данные в разные шаблоны.
Зачем так усложнять я тоже понять не могу. Может быть дадите более расширенный пример?
Для меня суть пакета — уже реализованный интерфейс админки, который выглядит именно как редактирование настроек. Причем с возможностью деления настройки на группы.
Приятно, когда параллельно с тобой у других людей возникают одни и те же задачи… а они из успевают решить раньше тебя :) да еще такую подробную статью на хабру написать. Спасибо!
В свое время приходилось делать подпись XML через такую-то матерь.
Тогда начал писать свой Signer-гем и обертку для гостовых алгоритмов через патченный OpenSSL, но так и не дописал, так как проект закрыли и стало неактуально.
Сейчас такая необходимость может снова возникнуть и попробую это решение. Спасибо!
Так что ваш пример, хоть и корректен, но является плохой практикой.
Если есть необходимость обнулять массив, то это сигнал, что он должен быть свойством другого объекта (модели)
$scope.model.array
Раньше еще часто замечали, что в ng-model должна быть минимум одна точка, тогда никогда не словите эту проблему и не будете иметь геморроя с хаками вроде array.length = 0…
По опыту: рано или поздно, если нарушать это правило, проблему не только словите, но и пропустите в продакшн, не заметив где-нибудь, и вот тогда уже перестаните это делать.
От этого манипуляция не станет быть какой-то более открытой или безчеловечной.
Мне показалось, что автор статьи как раз за разумное использование манипуляций, а не за пускание пыли в глаза.
Было бы здорово почитать развернутый рассказ про то, как собеседовать людей.
Я же всегда при разговорах на подобную тему высказывался, что пользы от сайтов, произведенных по такой схеме, практически никакой нет. Максимум они годятся для неких пилотных проектов, чтобы просто нащупать почву в интернете. Но и это спорно. Поэтому жду с нетерпением статьи с небольшим анализом реальной пользы таких сайтов.
Обязательно покажу эту статью своим верстальщикам и сам попробую в деле.
На данный момент пользуюсь активно SASS через запуск компилятор в консоли. До настройки HAML пока просто руки не дошли. С CoffeScript дела обстоят сложнее, потому что редко когда приходится писать что-то сложное для фронтенда и вполне достаточно простого JS + jQuery, но в случае чего можно будет эту часть Padrino не использовать.
Это может стать для кого-то решающим аргументом при выборе LESS, хотя сам я такую практику не понимаю.
На практике же работник не всегда может правильно и вовремя определить, в чем проблема (в нем или его работе), поэтому слишком поздно становится понятно, где находится узкое место.
После этого моя жизнь стала похожа на сказку :) Никаких тебе проблем с компиляцией Python-модулей под Windows, никаких левых ошибок.
Разработка изначально не велась на Linux потому, что мне не нравится UI и скорость работы моих основных инструментов из-под Linux. На Windows с этим попроще.
PS: с тех пор я уже успел перелезть на Mac, на котором эта проблема отпала сама собой :)
И есть еще один недостаток — невозможно доскроллить до футера, поэтому требуется какой-то другое интерфейсное решение, либо вообще футер убрать и перенести все го элементы в другое место.
Другой вопрос, что я ни разу не сталкивался с такой необходимостью. Поэтому моя первая реакция была та же, что и у @akaBd, то есть подумалось, что что-то не так с дизайном системы.
Зачем так усложнять я тоже понять не могу. Может быть дадите более расширенный пример?