не знаю о какой массе ты говоришь, но селектор «img[ preceding-sibling::label / input / @checked ]» имеет совсем незначительную сложность, а в css такое не реализовать, что сильно угнетает =(
то, о чём ты тут рассуждаешь было придумано ещё в мезозое и называется «оси». очень хорошо они описаны теми самыми «старперами» из w3c в спецификации xpath. рекомендую почитать для расширения кругозора. citforum.ru/internet/xpath/xpath02.shtml
> Работая с Node.js, люди ожидают увидеть именно асинхронный код.
ага, особенно используя require и *Sync методы) не знаю как насчёт людей, а я предпочитаю простой, ясный и понятный синхронный код, а не костыли типа Flowy и ко
> И ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.
в этом-то вся и соль. мне совершенно не важно откуда там оно прилетело — я работаю с простым апи: запрашиваю данные и потом с ними работаю.
> это уже проблемы стороннего кода — зачем моей либе с ним разбираться?
очевидно затем, что из-за него падает твоё приложение. и ты никак не можешь эту ошибку перехватить и продолжить выполнение.
> Отчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.
быстро поднятое упавшим не считается?)) смотри как бы сервер у тебя в один прекрасный момент не ушёл в бесконечную перезагрузку.
> Судя по моему опыту, это наиболее распространенный подход к организации такого кода. Уж не волокна точно.
нет, у каждой такой библиотеки свой апи с которым приходится разбираться.
> Асинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?
из многочисленых статей описывающих очередной велосипед выстраивания колбэков в цепочки на подобии синхронного кода.
> Все понятно: «статью не чилал, но осуждаю».
а скажешь нет? как, например, пропустить один шаг?
> Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
на этом закончим наш спор. похоже у тебя неизлечимая деформация мозга, если такой код ты считаешь write-only:
function leaveMessage( username, text ){
....var user= model.users.findOne( username )
....if( !user ) throw new Error( 'user not found' )
…
....var message= model.messages.create( user, text )
....model.notifications.create( message )
}
а такой простым и понятным:
function leaveMessage(username, text, callback) {
....Flowy(
........function() {
............model.users.findOne(username, this.slot());
........},
........function(err, user) {
............if (!user) throw new Error('user not found');
............model.messages.create(user, text, this.slot());
........},
........function(err, message) {
............model.notifications.create(message, this.slot());
........},
........callback //any error will be automatically propagated to this point
....);
}
> Во-первых, сложно то, что мы «ставим поток на паузу».
и что же в этом сложного? особенно в сравнении с асинхронной лапшой.
> Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке.
прежде чем говорить эти глупости не мешало бы самому попробовать с ними поработать.
> Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:
нет там таких проблем. в моей либе используется автоматическое распарралеливание. волокно не останавливается, пока нам не потребуется работа с результатом. аналогичный код на fibers/promise выглядел бы так:
console.time( 'parallel' )
var resp1= get()
var resp2= get()
console.log( resp1.wait().statusCode )
console.log( resp2.wait().statusCode )
console.timeEnd( 'parallel' )
> С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие forever, в конце-концов.
некоторые подобные либы не ловят, ну да хрен с ними. основная проблема всяких этих либ в том, что они ловят только ошибки в коде, который с их помощью написан. любой сторонний код для них — чёрный ящик, который может упасть и утащить с собой весь сервер. это не годится для продакшена совершенно. к тому же, какой стектрейс мы получим в случае ошибки в колбэке?
> Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
можно подумать Flowy или любая другая либа являются традиционными и к ним привыкли разработчики) да и вообще, ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на ноде — это что-то из практик BDSM)
всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение. однако, реальная жизнь интересней, в ней нужно часть потока выполнять в зависимости от условия, в ней нужно некоторые ветви выполнять циклично. и тому подобное. в js есть все основные операторы контроля потока, зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?
они ставятся через npm как и любые другие модули. используются через require как и любые другие модули. какая разница в ядре они или «плагином»?
и в чём же заключается его «экспериментальность»? по моим наблюдениям работает исправно.
опять же, что сложного для понимания в схеме «запускаем поток и когда надо ставим его на паузу»? это простая и естественная схема, в отличие от «городим кучу функций и через прямую кишку прокидываем между ними переменные»
а с отладкой что за сложности? единственная сложность — стектрейс не учитывает контекст старта асинхронной операции. характерна она для любого асинхронного кода, а не только для волокон. однако библиотеки реализующие «продолжения» подклеивают стектрейс вызова. кроме того, приятный бонус — ошибки в асинхронных запросах вызывают исключение в волокне, а не пытаются убить весь процесс.
так что ты лучше не вороти нос от прогрессивных технологий и не изобретай колесо. сделай лучше что-нибудь действительно полезное.
есть куда более подходящий для этого формат — github.com/nin-jin/node-jin#tree
это логичеки xml но чуть больше свободы в именах и совсем без синтаксического мусора и даже без эскейпинга
может проще реализовать его на шарпе?
один из xml-примеров можно было бы переписать так:
Button
....@ Visibility =Visible
....Button.ToolTip
........TextBlock @ Text =Tool tip text
....TextBlock @ Text =Button text & 'another' «text»
вместо многоточий — табы
и так можно представить любой xml
На мой взгляд не код должен подстраиваться под среду разработки, а наоборот среда разработки должна подстраиваться под код. пинайте разработчиков вашей ide чтобы запилили поддержку аннотаций для массивов, xml, yaml, tree и всего остального и от этого будет куда больше пользы, чем хранить конфиги в виде лапши.
делаю нечто похожее, так что небольшой обмен опытом)
1. для парсера нужно уметь указывать baseURI относительно которого будут вычисляться relativeURI. использовать везде абсолютные ссылки — не предлагать)
2. get — слишком абстрактный интерфейс, лучше его конкретизировать: getDOMNode, getSimpleXML и тп. у меня у каждого узла просто есть свойства DOMNode и DOMDocument.
3. www:paginate — опять же префикс слишком абстрактен, лучше использовать конктретный типа easyweb:paginate. и использовать его не только в имени функции, но и в имени режимов (easyweb:previous,easyweb:next,...). основная цель пространств имён — не указать предназначение, а избежать конфликтов и недопониманий. впрочем, там действительно нужна эта функция? сдаётся мне всё это реализуемо не слишком сложными шаблонами. к тому же, почему нельзя указать откуда брать данные? или предполагается для каждого блока на странице вручную прогонять по xslt преобразованию? не слишком практичное решение.
4. инвалидация по времени — зло. неужели так сложно сделать инвалидацию по событиям? да и вообще, что там кешировать? xslt преобразования и так реактивны. а если уж совсем жалко процессорного времени фронтенда, то можно вообще переложить его на плечи клиента. для примера сайт: hyoo.ru/?article=XStyle;author=Nin+Jin — статейку тоже почитайте, может заинтересует)
5. «В репе лежит easybook.sql — его надо импортнуть в базу, создать MySQL-юзера, прописать его логин-пароль в datasource.xml, и все — сайт заработает.» — фу как сложно) вы же наверняка используете какой-нибудь pdo, так что какая проблема по умолчанию автоматом создавать sqlite базу с нужной структурой?
6. почему нету checked_children, кидающего исключение в случае отсутствия детей, а также checked_alone_children проверяющего, что он такой один?) я это к чему — ошибка в данных не является настолько исключительной ситуацией, чтобы раскручивать стек. и все такие ошибки должны быть обработаны и зачастую могут быть заменены дефолтными значениями или другими источниками получения. а если нужна логика «либо всё верно и работаем, либо не верно и падаем», то лучше применить какую-нибудь схему валидации с более совершенными механизмами чем проверка «в элементе есть хотябы один узел»)
не делайте так пожалуйста. бесит.
я тыкаю пальцем в поле ввода, чтобы перевести на него фокус и тут всплывает это чудо на пол экрана. потом я набираю текст с железной клавы и оно пропадает.
лучше показывать клаву только при клике в поле которое уже находится в фокусе. тогда все будут счастливы.
запилил за вечер на свг nin-jin.github.com.local/etc/planets/
в отличие от канваса не грузит проц практически
кто-нибудь знает как сделать чтобы в хроме не дрожали планетки и тексты?
получать имя класса исключительно через их апи, которое потом может быть статически проанализировано лишь их инструментом (а там ведь не простая регулярка?) — достаточно кривое решение. лучше всего гугловцам было бы воспользоваться концепцией атомов (http://habrahabr.ru/post/97670/) тогда можно достаточно легко связывать имена из разных типов файлов и сжимать их синхронно. собственно я у себя это и реализовал. правда особой пользы от этого не было так как все ресурсы грузятся лишь один раз, да её и по зипованному каналу, уменьшение объёма не такое уж и значительное. так что читабельность на мой взгляд куда важнее.
ага, особенно используя require и *Sync методы) не знаю как насчёт людей, а я предпочитаю простой, ясный и понятный синхронный код, а не костыли типа Flowy и ко
> И ты никогда не узнаешь, читая код, было ли тебе возвращено просто immediate значение, или же прилитело что-то из колбека.
в этом-то вся и соль. мне совершенно не важно откуда там оно прилетело — я работаю с простым апи: запрашиваю данные и потом с ними работаю.
> это уже проблемы стороннего кода — зачем моей либе с ним разбираться?
очевидно затем, что из-за него падает твоё приложение. и ты никак не можешь эту ошибку перехватить и продолжить выполнение.
> Отчего же? Если не нужно писать сверхотказоустойчивую автономную систему, то вполне годится. Я еще раз подчеркну, есть лог консоли приложения и утилиты автоматического перезапуска упавшего инстанса.
быстро поднятое упавшим не считается?)) смотри как бы сервер у тебя в один прекрасный момент не ушёл в бесконечную перезагрузку.
> Судя по моему опыту, это наиболее распространенный подход к организации такого кода. Уж не волокна точно.
нет, у каждой такой библиотеки свой апи с которым приходится разбираться.
> Асинхронность никогда не доставляла никакой боли ни мне, ни другим разработчикам, с которыми мне приходилось работать. Откуда дровишки-то? Из статей блоггеров-хэлловорлдщиков?
из многочисленых статей описывающих очередной велосипед выстраивания колбэков в цепочки на подобии синхронного кода.
> Все понятно: «статью не чилал, но осуждаю».
а скажешь нет? как, например, пропустить один шаг?
> Программа, может, и не потеряет контекст, но разработчик, читающий код, сойдет с ума. Write-only код — это как раз то, что не нужно для продакшена, а не вылетевший иксепшн из-за бага, который тут же пофиксят следом.
на этом закончим наш спор. похоже у тебя неизлечимая деформация мозга, если такой код ты считаешь write-only:
function leaveMessage( username, text ){
....var user= model.users.findOne( username )
....if( !user ) throw new Error( 'user not found' )
…
....var message= model.messages.create( user, text )
....model.notifications.create( message )
}
а такой простым и понятным:
function leaveMessage(username, text, callback) {
....Flowy(
........function() {
............model.users.findOne(username, this.slot());
........},
........function(err, user) {
............if (!user) throw new Error('user not found');
............model.messages.create(user, text, this.slot());
........},
........function(err, message) {
............model.notifications.create(message, this.slot());
........},
........callback //any error will be automatically propagated to this point
....);
}
и что же в этом сложного? особенно в сравнении с асинхронной лапшой.
> Во-вторых, пытаться написать асинхронный код в синхронном стиле — это как раз-таки «экспериментальность». Волокна скрывают асинхронную природу кода, усложняя его понимание при чтении и поддержке.
прежде чем говорить эти глупости не мешало бы самому попробовать с ними поработать.
> Опять же, по причине того, что код начинает выглядеть «синхронно», появляются дополнительные проблемы с параллельным выполнением асинхронных запросов, которые уже не вписываются в эту уютную концепцию и добавляют ложку дегтя в эту «прогрессивную» бочку:
нет там таких проблем. в моей либе используется автоматическое распарралеливание. волокно не останавливается, пока нам не потребуется работа с результатом. аналогичный код на fibers/promise выглядел бы так:
console.time( 'serial' )
console.log( get().wait().statusCode )
console.log( get().wait().statusCode )
console.timeEnd( 'serial' )
console.time( 'parallel' )
var resp1= get()
var resp2= get()
console.log( resp1.wait().statusCode )
console.log( resp2.wait().statusCode )
console.timeEnd( 'parallel' )
> С «приятными бонусами» в виде отлова ошибок тоже спорно. Если ошибку можно обработать, то и во «Flowy» (и в любом подобном инструменте) ее можно поймать на последнем шаге. А она вылетела, пытаясь убить весь процесс, то это, видимо, ошибка, которую нужно чинить, а не отлавливать в волокнах — существует же лог консоли и утилиты наподобие forever, в конце-концов.
некоторые подобные либы не ловят, ну да хрен с ними. основная проблема всяких этих либ в том, что они ловят только ошибки в коде, который с их помощью написан. любой сторонний код для них — чёрный ящик, который может упасть и утащить с собой весь сервер. это не годится для продакшена совершенно. к тому же, какой стектрейс мы получим в случае ошибки в колбэке?
> Прогрессивные технологии — это замечательно. Волокна, в частности, — это очень мощный в умелых руках инструмент. Но это пока что не традиционное средство, к которому привык разработчик на Node.js (да что уж там, любой разработчик), а незнакомые инструменты — это первый шаг к беспорядку в проекте и ошибкам в коде.
можно подумать Flowy или любая другая либа являются традиционными и к ним привыкли разработчики) да и вообще, ратовать за явную асинхронность в то время как работа с нею является самой большой болью разработчиков на ноде — это что-то из практик BDSM)
всякие такие библиотеки-выравниватели реализуют лишь один вид потока — последовательное выполнение. однако, реальная жизнь интересней, в ней нужно часть потока выполнять в зависимости от условия, в ней нужно некоторые ветви выполнять циклично. и тому подобное. в js есть все основные операторы контроля потока, зачем их переизобретать на своём асинхронном dsl, если ест возможность дожидаться завершения асинхронных операций не теряя контекста?
и в чём же заключается его «экспериментальность»? по моим наблюдениям работает исправно.
опять же, что сложного для понимания в схеме «запускаем поток и когда надо ставим его на паузу»? это простая и естественная схема, в отличие от «городим кучу функций и через прямую кишку прокидываем между ними переменные»
а с отладкой что за сложности? единственная сложность — стектрейс не учитывает контекст старта асинхронной операции. характерна она для любого асинхронного кода, а не только для волокон. однако библиотеки реализующие «продолжения» подклеивают стектрейс вызова. кроме того, приятный бонус — ошибки в асинхронных запросах вызывают исключение в волокне, а не пытаются убить весь процесс.
так что ты лучше не вороти нос от прогрессивных технологий и не изобретай колесо. сделай лучше что-нибудь действительно полезное.
github.com/nin-jin/node-jin#sod
это логичеки xml но чуть больше свободы в именах и совсем без синтаксического мусора и даже без эскейпинга
может проще реализовать его на шарпе?
один из xml-примеров можно было бы переписать так:
Button
....@ Visibility =Visible
....Button.ToolTip
........TextBlock @ Text =Tool tip text
....TextBlock @ Text =Button text & 'another' «text»
вместо многоточий — табы
и так можно представить любой xml
У меня как-то с этим по проще было: github.com/nin-jin/PMS/blob/80db5fd273a9cd25d3b8459a1951e28d9f977fcd/wc/css3/wc-css3.vml
1. для парсера нужно уметь указывать baseURI относительно которого будут вычисляться relativeURI. использовать везде абсолютные ссылки — не предлагать)
2. get — слишком абстрактный интерфейс, лучше его конкретизировать: getDOMNode, getSimpleXML и тп. у меня у каждого узла просто есть свойства DOMNode и DOMDocument.
3. www:paginate — опять же префикс слишком абстрактен, лучше использовать конктретный типа easyweb:paginate. и использовать его не только в имени функции, но и в имени режимов (easyweb:previous,easyweb:next,...). основная цель пространств имён — не указать предназначение, а избежать конфликтов и недопониманий. впрочем, там действительно нужна эта функция? сдаётся мне всё это реализуемо не слишком сложными шаблонами. к тому же, почему нельзя указать откуда брать данные? или предполагается для каждого блока на странице вручную прогонять по xslt преобразованию? не слишком практичное решение.
4. инвалидация по времени — зло. неужели так сложно сделать инвалидацию по событиям? да и вообще, что там кешировать? xslt преобразования и так реактивны. а если уж совсем жалко процессорного времени фронтенда, то можно вообще переложить его на плечи клиента. для примера сайт: hyoo.ru/?article=XStyle;author=Nin+Jin — статейку тоже почитайте, может заинтересует)
5. «В репе лежит easybook.sql — его надо импортнуть в базу, создать MySQL-юзера, прописать его логин-пароль в datasource.xml, и все — сайт заработает.» — фу как сложно) вы же наверняка используете какой-нибудь pdo, так что какая проблема по умолчанию автоматом создавать sqlite базу с нужной структурой?
6. почему нету checked_children, кидающего исключение в случае отсутствия детей, а также checked_alone_children проверяющего, что он такой один?) я это к чему — ошибка в данных не является настолько исключительной ситуацией, чтобы раскручивать стек. и все такие ошибки должны быть обработаны и зачастую могут быть заменены дефолтными значениями или другими источниками получения. а если нужна логика «либо всё верно и работаем, либо не верно и падаем», то лучше применить какую-нибудь схему валидации с более совершенными механизмами чем проверка «в элементе есть хотябы один узел»)
я тыкаю пальцем в поле ввода, чтобы перевести на него фокус и тут всплывает это чудо на пол экрана. потом я набираю текст с железной клавы и оно пропадает.
лучше показывать клаву только при клике в поле которое уже находится в фокусе. тогда все будут счастливы.
в отличие от канваса не грузит проц практически
кто-нибудь знает как сделать чтобы в хроме не дрожали планетки и тексты?
* моно -> стерео
* горизонтальное разделение
* вертикальное разделение
* шахматное разделение
* черезкадровое разделение
в последнем очевидно фулл хд, но я не пиксельдрочер, так что с поиском источника не заморачивался.
возможно ли при выкладке новой версии сохранение созданных предыдущей версией файлов? или каждый раз создаётся чистая виртуалка?
forum.vingrad.ru/forum/topic-182406.html