• Консоль разработчика Google Chrome: десять неочевидных полезностей
    +1
    Тогда уж Array.from(document.querySelectorAll(value))
  • World of Warcraft — игра или цифровой наркотик?
    0
    Вы же написали то же что и я, но другими словами.
  • World of Warcraft — игра или цифровой наркотик?
    0
    Это Вы о мажоре? Ну, возможно. Но на наркомана он и сейчас не похож.
  • World of Warcraft — игра или цифровой наркотик?
    +1
    Знаете, очень многое в нашей жизни это только самовнушение )

    Я регулярно общаюсь с ним и его семьёй и, как человек неплохо знакомый с психиатрией, не замечаю в его речи или поведении признаков самовнушения (зацикленности, повышенной восторженности семьёй или своей жизнью, резкого отрицания своего наркотического опыта). Его жена так же не сообщала ничего подобного. Не говоря уже о его психиатре, которого он регулярно посещает по моему настоянию.

    Ну да. Джеф штука сильная. Но его сила чаще всего проявляет себя на фоне общего неблагополучия персоны. Справедливости ради стоит сказать, что чаще распространён он именно в социальных низах. Один знакомый, вполне себе мажор из обеспеченной семьи, пару недель пробовал джеф, потом просто забил, сказал, что фигня. А сигареты курит и по сей день )
  • World of Warcraft — игра или цифровой наркотик?
    +1
    То, что называют психологическим наркотиками, это не наркотики. Возможно, это моё личное мнение, но я не знаком с чем-либо, что могло бы его опровергнуть. Механизм тот же, что и у обычных привычек, отличие чисто количественное.

    Ну и не говорил, что это легко. Просто у многих людей «тяжело» в данном контексте почему-то ассоциируется с какой-то невероятной борьбой с самим собой, когда человек катается по полу, царапает себе лицо и выкрикивает всякие безумия. Чаще всего это не так: просто человеку не приходит в голову бросить привычку, тяжесть в данном случае это тяжесть решения, а не самого отказа. В случае с игрой: удалить игру, закрыть комп и пойти погулять.
  • World of Warcraft — игра или цифровой наркотик?
    +2
    Перед тем, как предлагать мне прочесть статью из Википедии, почитайте хотя бы Майерса, из которого списана эта статья )

    «Не всегда» это статистический подход к вопросу. Это значит, что в определённом проценте случаев человеку не удаётся избавиться от зависимости. Но в этом вина исключительно самого человека, который не очень-то и хочет избавляться или принять помощь других. Я убеждён в одной простой мысли: там где один человек был успешен, может быть успешен любой другой.
  • World of Warcraft — игра или цифровой наркотик?
    +2
    Я не пробовал героин, но у меня есть друг, которому я помог соскочить после нескольких лет употребления. Он не подмечал симптомов подобных тем, что описали Вы, его шкала оценок восстановилась и сейчас спокойно радуется семейной жизни с двумя детьми. Безусловно, у него остались воспоминания от героинового кайфа, но он не придаёт им столь великого значения.

    Меткатинон это «джеф»?
  • World of Warcraft — игра или цифровой наркотик?
    +5
    Психологическая зависимость это не наркомания. Она по своей сути ничем не отличается от выработанной зависимости человека от комфорта, любимой пищи, близких людей, способа жизни. Основана на слабости психики, отсуствии выбора, узком кругозоре, которые ведут к инерции и нежеланию менять взгляды на мир. Все эти феномены легко преодолимы самим человеком (а тем более с помощью друзей и близких) при наличии намерения и желания их преодолеть. С героина, без помощи врачей, просто так не соскочишь, прктически нереально самостоятельно пройти через ад абстинентного синдрома.

    «Психика иногда такие фокусы выкидывает» — сильный аргумент! ) Психика вообще много чего может. Тем не менее, в отличии от физиологических процессов, она подконтрольна человеку. Было бы желание.
  • World of Warcraft — игра или цифровой наркотик?
    +7
    Неправильная аналогия. Героин это вещество вызывающее физическое привыкание путём замещения в организме человека аналогичных веществ естественного происхождения, чем прекращает выработку этих веществ и ставит человека в зависимость от приёма наркотика. Это определение наркотика как такового. Человек не способен сознательно контролировать этот процесс вмешаться в него.

    Зависимость от игры психологическая. Это не более чем слабость человеческой психики, что указывает на её неразвитость и отсутствие стойкости. Справиться с подобным человеку вполне по силам, достаточно лишь твёрдого намерения. В этом плане любая игра ничем не отличается от какой-нибудь рулетки, игровых автоматов. Даже футбола: у меня есть знакомые, которые жить нормально не могут без того, чтобы не посмотреть очередной матч, пропустив его они грустят, плохо работают витают где-то. Давайте напишем статью: «Футбол — спорт или наркотик».
  • Письмо
    0
    Однако, если ты не перешлёшь это письмо хотя бы 10-ти людям из твоего контакт-листа, магия рассеется! Спеши, иначе у тебя ничего не получится!
  • Пишем одностраничный клиент на javascript
    –2
    Если честно, то я бы всё это заменил Мутулзом. Плюс добавил бы ещё одну свою либу, которая делает что-то вроде тех же моделей, но не абстрактных, а связанных с конкретными элемантами DOM.

    Скажите, а использование JS-шаблонизаторов это требование? Просто мне ничто никогда не представлялось настолько бессмысленным как шаблонизация на JS.
  • Тайная афера Facebook
    +2
    Здравствуйте, кэп, спасибо. Комментарий был не о том.
  • Тайная афера Facebook
    +10
    Вот так всегда. Разработчики берутся за дело и делают хорошие сервисы. А потом за дело берутся бизнесмены…
  • ФБР захватило домены PokerStars.com, Fulltiltpoker.com и UB.com
    +2
    Я говорю о понятии «азартная игра», а не «азарт». Игра, условия которой основаны на изменении погоды, была бы азартной.

    Покер можно рассматривать как угодно. Но если, при прочих равных, тебе выпадает каре против пары на руках соперника, то ты выигрываешь. А это и есть конкретизированное определение азартной игры — наличие элемента случайности.
  • ФБР захватило домены PokerStars.com, Fulltiltpoker.com и UB.com
    0
    Главным признаком азартности является случайность. И в покере она всегда была.
  • Настоящие инновационные компании
    +1
    Уже ведь написали выше: по сути это обмен базовой информацией с людьми за многие тысячи километров и не только. Возможность создать информационное пространство на любую тему с огромным количеством участников.

    По сути микроблоггинг это как инстант месседжинг, только открытый для широкой аудитории, а не закрытый.

    Пример: товарищ сидит в Ливии и строчит «У нас тут ужас-п***ц-революция». С фотками. Или с трансляцией. Допустим, реализуется технология встраивания потокового видео прямо в пост. А если товарищей десяток? У вас прямые новости с места событий на любую тему без цензуры и купюр.
  • Настоящие инновационные компании
    0
    Я ставлю. Микроблоггинг может стать одним из истоков для информационной революции.
  • Регулярная ловушка
    0
    … мы хотим проверить регулярным выражением, что в строке есть хотя бы одна цифра ...

    /\d/.test(str);

    Ну вот так как-то.
  • Валидация форм в JavaScript ч.1
    0
    Я всегда их так и делал ) Я практически весь JS-код подключаю исключительно через спецаттрибуты.

    И как это решает вопрос динамической генерации форм, скажите? По вашей логике генератор форм на сервере лежит, по любому нужно будет к нему обратиться, чтобы форма вышла согласно заданным в одном месте параметрам. Или я неправильно вас понял?
  • Валидация форм в JavaScript ч.1
    +1
    Ага, знаю ) Я как большой поклонник JS давно хочу попробовать Node. Но возможности пока не предоставляется.

    AJAX-валидация стала для меня выходом, к которому я пришёл после долгой работы с формами: наиболее удачное и автоматизируемое решение. Минимум разработки и максимум эффекта.

    ЗЫ: Никаких классов в моём уютненьком прототипном JS!
  • Валидация форм в JavaScript ч.1
    0
    Я понимаю в чём смысл валидации на клиенте, честно. И отказался от неё совершенно осознано. В наше время быстрых каналов экономия времени получается на спичках, а деньги сэкономленные от работы над скриптом валидации проще вложить в апгрейд сервера, это будет лучше чем избегать нагрузки подобным способом.

    Кроме того, проведённая вами параллель не совсем удачна: сжатие JS/CSS это простая технология. А логика валидации это, как ни крути, код со всеми из него вытекающими: поддержка, апдэйт либ в случае использования сторонних решений, рефакторинг.

    Я понимаю, допустим, использование рэгэксп-маски на поле, там скрипт простой и универсальный, пару строчек кода в логике. Написание же полноценной валидации это всегда разработка нового мета-языка обозначений: not_empty, is_email, is_url, is_phone и т. п. И везде оно разное, хотя и стандарты тоже есть. Дублировать довольно таки сложную и трудоёмкую логику я не вижу смысла.
  • Валидация форм в JavaScript ч.1
    +1
    То есть, вы предлагаете написать ещё дополнительный код, который будет связывать воедино логику сервера и клиента, вместо того, чтобы оставить только код на сервере?

    Кроме того, генераторы форм практически всегда оборачиваются головняком для верстальщика. Особенно, если внешний вид формы нужно кастомизировать. А ещё можно вспомнить ситуации, когда форма динамически генерируется на клиенте. Предлагаете в этом случае обращаться к серверу, чтобы он сгенерировал нам форму?

    Я просто не вижу смысла оставлять клиент-валидацию. Зачем она? Ну ладно, проверка занятости логина, как выше писали. Но зачем делать дважды одну и ту же проверку обычных полей ума не приложу.
  • Валидация форм в JavaScript ч.1
    0
    Бейте меня ногами, но я полагаю, что валидация должна быть только одна — на стороне сервера. Причины простые: на стороне сервера она должна быть обязательно (понятно почему), а значит придётся повторять тот же код. Причём, наверняка, на другом языке.

    Я сейчас практически всегда использую AJAX-формы. Проверка на сервере, ответ на клиенте. Массу клиент-кода экономит.
  • Обёртки для создания классов: зло или добро?
    +3
    Aux известный товарищ, который знает много страшных слов и любит примерять амплуа покрывателя икс-уями. Это не значит, что в пику ему стоит называть вещи не своими именами.

    «Зло», как вы выразились, вовсе не в том, чтобы сокращать запись, а в том, чтобы привносить в JS понятия, которых в нём отродясь не было — классы! — и которые там совершенно не нужны. Потому что пользователи библиотек (Мутулз, кстати, моя любимая JS-либа) потом пытаются переносить туда же и логику чуждую языку. Приватные свойства, например. ЗАЧЕМ? Почему я двенадцать лет пишу на JS и мне ни разу не понадобились приватные свойства? Что я делаю неправильно?

    Я к тому, что не нужно тащить в язык средства из чуждой ему парадигмы только для того, чтобы мимикрировать под привычную среду.
  • Жрецы программирования
    –1
    Выше написали абсолютную правду: использование подсказок по названиям и аргументам сводит вашу логику на нет.

    Я, как человек программировавший на многих языках, могу сказать, что объём аналитической работы при разработке на ПХП равен у меня аналогичному объёму для Явы. Ну точнее, для Явы всё же больше, но если убрать оборачивание каждого пука в объект, то где-то столько же.
  • Геттеры и сеттеры в Javascript
    0
    Да, я в курсе. Но предпочитаю нативную поддержку. Буду ждать.
  • Геттеры и сеттеры в Javascript
    +1
    Геттеры и сеттеры это то, чего ещё пока полноценно не хватает в JS, да. Ещё бы возможность следить за состоянием поля. Как здесь: https://developer.mozilla.org/en/Javascript/Reference/Global_Objects/Object/watch
  • Комментарии — авторам!
    0
    Я сторонник философии Перла: должно быть более одного способа сделать это. Пусть будет и личка и личные комменты. Тем более, что функционал один и тот же, практически.
  • Комментарии — авторам!
    0
    А ещё можно оставлять комментарии-ниндзя к другим комментрариям: «Смотри автор, вот в этом комментарии Истина!»
  • Комментарии — авторам!
    +2
    Нет, что Вы, это прекрасно! Но иногда хочется пообщаться с автором не прибегая к серьёзной переписке. Тем более, что в топике уже изначально заложена тема для беседы.
  • История создания Javascript
    0
    Скоро, скоро, благодаря серверному JS у серверных приложений тупо ничего не останется кроме последнего выбора — сдаться. Ну просто так сложилось, что ничто не в состоянии составить конкуренция JS. Питон и Руби могут попытаться, но вряд ли )
  • Правильный захват контекста в Javascript
    +1
    Ага, спасибо. Со мной иногда бывает.
  • Правильный захват контекста в Javascript
    +1
    Да, на ваш первый вопрос напрямую я не ответил, но как мне казалось написал достаточно. Отвечу сейчас: я с Вами не совсем согласен.

    Лично я уже не представляю себе программирования на JS без жонглирования контекстами. Что если контекст это просто абстрактный интерфейс хранящий функцию для другого контекста? А значит и называть и конструировать его следует как хранилище, а не как управляющий объект. А также использовать и описывать в документации.

    Поправьте, если я ошибаюсь, но вы рассматриваете контекст исключительно как програмную сущность, а его методы, соответственно, как функционал сущности. Но в JS способов употребления контекстов на порядок шире: я выше перечислил некоторые.

    Как это связано с темой поста? Очень просто: представьте, что функция-обработчик разрослась и было принято решение сделать её методом контекста. Такое случается сплошь и рядом. Правильное привязывание контекста гарантирует безболезненный рефакторинг. И это только один пример.

    Очевидно, что лучшим решением было бы использовать оба способа — как замыкание, так и привязку контекста — разумно взвешивая необходимость их употребления.
  • Правильный захват контекста в Javascript
    +1
    Именно нормально, а не допустимо. И тут я буду спорить до последнего ) Вы программировали на других функциональных языках? Лисп, например?

    В этой парадигме функция-метод это базовый кирпичик. А объект его обслуживает. В приведённом мной примере MegaContext.MilliContext это хранилище для метода. А в общем случае, в зависимости от реализации, этот контекст может быть и управляющим объектом, и хранилищем, и интерфейсом, и прототипом.

    Если совсем коротко сформулировать, то в JS методы определяют объект, а не объект методы.

    Ну и отвечаю на последний Ваш вопрос: я вступил в этот спор потому, что очень люблю Javsscript и, соответственно, не люблю когда в него начинают привносить привычные наработанные приёмы из других языков, которые нарушают его собственную логику.
  • Правильный захват контекста в Javascript
    0
    В JS любая функция это метод какого-то контекста. Если контекст не указан явно, то используется глобальный. Но в функциональных языках программирования нету жёсткой привязки к контексту: объявление метода в одном контексте это не привязка, а просто декларация его «места хранения», если можно так выразиться.

    Абсолютно нормально написать что-то типа:

    MegaContext.MilliContext.itsMethod.apply(GigaContext.MicroContext);

    Тем самым исполняя метод одного контекста в другом контексте. В JS это так же естественно как в классическом ООП инициализировать объект класса с помощью конструктора родственного класса.
  • Правильный захват контекста в Javascript
    0
    > Расширение системных прототипов, — дорога в прототип ада :)

    Не согласен абсолютно. Волков бояться — в лес не ходить. Опасность расширения родного прототипа это малообоснованное суеверие. Надо просто уметь расширять и, ещё раз, всегда следить за развитием используемого инструмента.

    Я лет шесть програмлю регулярно расширяя прототипы для JS, как системные, так и Motools'овские. И, представьте, до сих пор ни единого разрыва )

    Ничего личного, всё общее )
  • Правильный захват контекста в Javascript
    0
    Расширять системные прототипы не вредно, а нормально и естественно. Просто для этого нужен аккуратный подход и постоянный интерес к развитию языка и используемых им стандартов.

    Метод bind в ES5 был внесён именно из библиотек Prototype и Mootools. Так часто бывает, что удачные реализации из либ становятся частью стандарта. Мы не можем при разработке решения предвидеть все будущие ходы разработчиков стандарта, которые в будущем станут конфликтовать с нашим решением. Следовательно, правильный подход: забить на предсказания будущего и разрабатывать как тебе удобно, но при этом, повторюсь, живо следить за развитием стандартов и языка. Ошибка Motools в несоблюдении последнего, а никак не в расширении системных прототипов.
  • Правильный захват контекста в Javascript
    +1
    В Mootools всё проще, там можно сделать так:

    method(a).delay(200, this);

    Т. е. методы delay и periodical принимают ссылку на контекст исполнения как параметр. За что я и люблю Mootools, так это за правильную работу с контекстами.
  • Правильный захват контекста в Javascript
    +1
    А заставлять своих коллег помнить названия объектов и методов Вы, случайно, усложнением не считаете? )

    Выполнение методов в произвольном контексте — как в естественном, так и в кастомном — является неотъемлемым приёмом программирования на JS. Факт наличия «родных» методов apply и call у функции уже говорит об этом. JS функциональный язык, жонглирование контекстом исполнения есмь часть его парадигмы.
  • InducTable: футуристичный стол для гиков
    0
    Даже если такой столик сделать,… сложно представить сколько же энергии он будет жрать.