потому, что трюк с переименованием не сработает для неподконтрольного нам (библиотечного) css, а у нас такого вагон. плюс есть общие стандарты, где нет ничего про scss. тут проще sass закастомайзить, но пока меня этот вариант немного пугает (какой sass? какая кастомизация? ведь хочется лишь source maps для объединенного css чтобы сделать разработку еще чуть проще).
не собирать все в один файл это оффтоп, т.к. source maps в таком случае вообще не нужны )
вот и хочу узнать ответ на этот вопрос. :) навскидку, утилита sass не применяет к css файлам всяческие полезности scss, скажем не инлайнит import. а менять css на scss не вариант, т.к. это куча, в том числе стороннего кода.
любопытно, можно-ли эту штуку адаптировать для более простого (и думаю распространенного) случая, когда результирующий CSS собирается по кусочкам из отдельных CSS-файлов? вроде как SASS это надмножество CSS.
может есть какая-то генерилка sourcemap для такого случая и если есть получится-ли воспользоваться функциональностью хрома?
чудо-поиск, индексация и прочий автокомплит в ST2 нормально работают лишь с локальными файлами. работать с реальными проектами, поверх сетевых файловых сиситем, мне показалось непрактичным (может сеть такая :()
механика плагина sftp в этом смысле вполне адекватна — саблайм работает с локальными файлами, а плагин предоставляет кучу ручек для разных вариантов синхронизации с удаленной машинкой. но если при синхронизации падает соединение, то, действительно, спасает лишь перезапуск саблайма. а еще он ацкий тормоз при копировании большого количества файлов. было бы круто, если бы они запили в качестве транспорта rsync, вместо костылей над sftp.
еще можно повесить github.com/axkibe/lsyncd. правда в этом случае синхронизация выполняется асинхнонно, и при кодинге сильно не хватает обратной связи со стороны редактора (не понятно, файл синхронизировался с удаленной машинкой или еще нет).
Модель Солоу или модель Солоу-Свана — неоклассическая модель экономического роста Роберта Солоу, основанная на неоклассической производственной функции (например, на производственной функции Кобба-Дугласа) с учетом экзогенного нейтрального технического прогресса
вот почему в русскоязычной wiki сначала идет куча непонятных терминов и формул, а где-то в конце статьи можно найти пару прикладных выводов. а в анлоязычной — сначала прикладное описание, а формулы в конце? %)
по-моему, программирование и прочее ТАУ, принципиально отличается от управления людьми, не смотря на то, что понятие «управления» используется и там и там. все дело в пресловутом человеческом факторе. в то время как программисты бездушных железяк споконо могут быть нердами, для управления людьми крайне важны личностные качества. сосбтвенно пост, отчасти, и про это.
Теперь, чтобы нормально работали сайты, пользователь будет вынужден синхронизировать историю посещений между девайсами. интересно, каким будет следующий шаг фонда мозиллы в заботе о прайваси?
Вроде фишка в том, что ключ позволяет идентифицировать связи между хостами. если каким-то способом определить владельца хотябы одного из них, можно связать и все остальное.
Не понимаю, где тут деньги. Вероятнее, что через очки будут детектиться предпочтения их обладатедей, эффективность показа рекламы и т.п. Аналитикс, способный трекать фокус внимания, не только на сайтах, это мечта просто.
зачем это все? js, как язык, коряв от рождения, но он популярен благодаря постоянству и как следствие — выдающейся совместимости. новые навороты, не несут ни чего оригинального — все это есть в нормальных языках и даже больше — но сводят все преимущества js на нет.
RFC3986 (URI) описывает несколько видов нормализации URI при сравнении, но про «host» в нем говорится лишь то, что они должны сравниваться как строки, без учета регистра. в RFC2616 (HTTP/1.1) определение host отдается на откуп RFC2396 (который устарел и замен RFC3986) и там тоже ни какой отдельной нормализации для хостов не предполагается.
отсюда я делаю вывод, что хоть «server.com» и «server.com.» резолвятся в DNS одинаково, с точки зрения URI, это два разных хоста. тогда не понятно, почему в nginx считает их эквивалентными? видимо отсюда возникает часть этой путаницы:
вы и не подозреваете, что ваш сайт доступен по доменному имени с точкой в конце (domain.zone.), так как браузеры позволяют обращаться к сайтам, как с точкой в конце домена, так и без неё
с той лишь разницей, что неподозреваемая доступность сайта лежит на совести сервера, а не браузера.
согласен с выводом в статье, что в большинстве случаев для web-сайта будет хорошим тоном при запросе к «server.com.» откликаться 301 редиректом на «server.com», как и во всех остальных случаях с alias'ами. просто этот aiias достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)
видимо tv + smarttv внутри, продается проще, чем tv + планшет. хотя я согласен с вами, и здравый смысл подсказывает, что будущее где-то тут. надо лишь дождаться, когда цены на ipad'ы станут соизмеримыми с ценами на tv-пульты :)
нормализация это метод исключения логических аномалий в реляционной модели данных. что тут делает NoSQL вообще — он, типа, поощряет в данных логическую противоречивость?)
не собирать все в один файл это оффтоп, т.к. source maps в таком случае вообще не нужны )
может есть какая-то генерилка sourcemap для такого случая и если есть получится-ли воспользоваться функциональностью хрома?
читал по диагонали. охренел. %)
механика плагина sftp в этом смысле вполне адекватна — саблайм работает с локальными файлами, а плагин предоставляет кучу ручек для разных вариантов синхронизации с удаленной машинкой. но если при синхронизации падает соединение, то, действительно, спасает лишь перезапуск саблайма. а еще он ацкий тормоз при копировании большого количества файлов. было бы круто, если бы они запили в качестве транспорта rsync, вместо костылей над sftp.
еще можно повесить github.com/axkibe/lsyncd. правда в этом случае синхронизация выполняется асинхнонно, и при кодинге сильно не хватает обратной связи со стороны редактора (не понятно, файл синхронизировался с удаленной машинкой или еще нет).
вот почему в русскоязычной wiki сначала идет куча непонятных терминов и формул, а где-то в конце статьи можно найти пару прикладных выводов. а в анлоязычной — сначала прикладное описание, а формулы в конце? %)
при таком способе формирования регулярки, подставляемые значения нужно re.escape()'ить.
отсюда я делаю вывод, что хоть «server.com» и «server.com.» резолвятся в DNS одинаково, с точки зрения URI, это два разных хоста. тогда не понятно, почему в nginx считает их эквивалентными? видимо отсюда возникает часть этой путаницы:
с той лишь разницей, что неподозреваемая доступность сайта лежит на совести сервера, а не браузера.
согласен с выводом в статье, что в большинстве случаев для web-сайта будет хорошим тоном при запросе к «server.com.» откликаться 301 редиректом на «server.com», как и во всех остальных случаях с alias'ами. просто этот aiias достается задаром — его не надо отдельно регистрировать и париться за киберсвотеров. :)