• Используем потоки в Ruby
    0
    В версии 1.9 избавились (но GIL остался).
  • Используем потоки в Ruby
    +1
    Однако, у этого способа есть недостаток. Форки процессов копируют память создавшего их процесса, и таким образом сервер Unicorn с тремя «работниками» может забирать 1ГБ памяти, едва начав работу. Тоже самое касается библиотек для исполнения фоновых задач, например Resque.
    В Ruby 2.0 оптимизировали GC для copy-on-write, так что теперь форки потребляют значительно меньше памяти.
  • Особенности работы или «За что я люблю JavaScript»: Замыкания, Прототипирование и Контекст
    +4
    В Ruby методы являются объектами. Просто obj.f — вызов метода, а obj.method(:f) — объект.
  • Знакомство с CoffeeScript
    +1
    А напишите неизбыточный эквивалент объявления по условию:

    if prompt() == 'square'
      f = (x) -> x * x
    else
      f = (x) -> x * x * x
    
  • Знакомство с CoffeeScript
    0
    Посмотрел. Я так понял это далеко не полный транслятор. Если тут перечислены все фичи, то в coffescript реализовано почти всё из этого, и ещё намного больше. Вряд ли все фичи ES6 можно эмулировать в ES5.
  • Знакомство с CoffeeScript
    0
    Где есть транслятор ES6?
  • Знакомство с CoffeeScript
    0
    CoffeeScript очень хорошо сочетается с ExtJS, помогает бороться с большой вложенностью декларативного кода.
  • Правая граница в исходном тексте
    0
    В смысле зачем? Я имел в виду, что в Vim есть стандартная команда gq, которая переразбивает выделенный текст так, чтобы он вместился в заданное количество символов по ширине.
  • Правая граница в исходном тексте
    +1
    Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.
    Очередной пример превосходства Vim над другими жалкими редакторами. ;)
  • Отказоустойчивая архитектура из двух веб-серверов на примере Debian Squeeze
    0
    С 4-мя чуть не так, кворум то есть, но он достижим при том же количестве упавших нод, что и с 3-мя. То есть преимущества нет. Но если одному дать дополнительный голос, то кластер выдержит сбой от 1 до 2-х нод. Кластер не может выдержать сбой серверов в количестве большем или равным половине серверов, так как невозможно изнутри узнать причину сбоя — сеть или питание.
  • Отказоустойчивая архитектура из двух веб-серверов на примере Debian Squeeze
    0
    3-х серверный кластер может выдержать сбой одного сервера. Если все три потеряли связь, то ни один работать не будет, так как нужен кворум. А с 4-мя серверами кворума нет, но можно одному из них дать дополнительный голос. Это касается автоматического режима. Но если произошел сбой большей части кластера, то можно еще вручную указать какому-то серверу продолжать работать, это тоже будет безопасно для данных.
  • Отказоустойчивая архитектура из двух веб-серверов на примере Debian Squeeze
    0
    Если на разных серверах обновить одну и ту же запись разными значениями, то серверы так просто не синхронизируются. Чтобы такого не было, надо непарное количество серверов, тогда каждый сервер будет знать, находится он в большей части повреждённого кластера или в меньшей. Если в меньшей, то он перестаёт принимать запросы. Другой вариант — база может в любой момент вернуть несколько версий документа, и пусть приложение решает как обьеденить их. Так сделано в Amazon Dynamo и Riak, для MySql, конечно, не подойдёт.
  • Отказоустойчивая архитектура из двух веб-серверов на примере Debian Squeeze
    0
    Разве что у вас нет ни одного апдейта. Данная архитектура не может быть полностью отказоустойчивой.
  • Отказоустойчивая архитектура из двух веб-серверов на примере Debian Squeeze
    0
    Что будет при разделении сети? То есть серверы друг друга не видят, но некоторым клиентам удаётся соединиться, причем к обоим серверам.
  • Основы теории вычислительных систем: машина с конечным числом состояний
    +2
    Знание основ теории вычислительных систем позволяет вам брать проблему X, которую вы понятия не имеете как решать, и применять к ней подход: «Я не знаю, как решить X, но я знаю, как решить Y и как привести решение для Y к решению для X. Вот почему теперь я знаю, как решить X».
    Наверно индус, который писал этот код, тоже так думал:
    uint i;
    ...
    if (i.ToString().Length == 1)
    {
      ...
    }
    
  • Выполнение произвольного кода в Rails
    +4
    При чем тут руби?
  • Выполнение произвольного кода в Rails
    0
    echo "ActionController::Base.param_parsers.delete(Mime::XML)" >> RAILS_DIR/config/environment.rb
  • SQL — гибок или почему я боюсь NoSQL
    +5
    Зачем так делать? То что монго поддерживает такие структуры — не означает, что надо везде их применять. Стандартный подход с двумя коллекциями никто не отбирал. В документации всё расписано, когда стоит это применять, а когда нет.
  • SQL — гибок или почему я боюсь NoSQL
    –1
    JOIN'ы можно делать на клиенте, GROUP BY — с помощью агрегаций или map/reduce, нормализация — это хорошо пока не начнет тормозить.
    Поскольку БД не предоставляет запросов для таких нужд, не сложно оказаться в ситуации, когда вы вынуждены извлечь все данные для их автономной обработки через MapReduce.
    Зачем и куда извлекать данные, если map/reduce сам их извлекает?
    Если запросы становятся медленными, вы можете просто добавить индексы в тех местах, в которых это необходимо.
    До некоторого предела. А потом придется переписывать без всех этих join'ов и транзакций.
  • Передача файлов от дизайнера к программисту. Скрипты
    0
    Странно, дизайнерша на картинке с усами и хотдогом.
  • Использование регулярных выражений в Ruby
    0
    /(?<hi>hello)/ =~ 'hello'
  • О беспилотных автомобилях или почему я не хочу жить в «умном доме»
    0
    Вот с последним абсолютно согласен.
  • О беспилотных автомобилях или почему я не хочу жить в «умном доме»
    0
    Есть много статистики по поводу снижения преступности при разрешении скрытого ношения короткоствола. Нам это не помогает принять такой закон. С чего вдруг с автопилотами поможет?
  • О беспилотных автомобилях или почему я не хочу жить в «умном доме»
    +1
    У нас на данный момент судебная практика такова, что при любом ДТП с участием пешехода, суд обычно становится на сторону последнего. Допустим автопилот сбивает человека на трассе вне пешеходного перехода — выскочил прямо перед машиной, а сцепления с дорогой не хватило (а таких случаев будет очень много). Вижу три варианта развития событий:
    1. Приговор выносят водителю. Сесть невиновному обидно, а не держав даже руль — вдвойне.
    2. Виновным признают производителя. Кто захочет вообще продавать такую технику при таких раскладах?
    3. Самый фантастический. Кто-то придет и исправит нам наши суды.
    В итоге даже когда на западе это как-то решат, нас это вряд ли коснётся.
  • Транзакции в MongoDB
    0
    Сверху уже давали ссылку на описание two phase commit, заметьте — она находиться в официальной документации. Почему-то часто забывают, что MongoDB заточена под распределенность. А знаете как реализованы распределенные транзакции в, например, Oracle? Правильно — всё тот же two phase commit.
    По поводу Durability — настоящая надежность обеспечивается только репликацией. Можно даже без журналирования. Односерверная конфигурация не переживет физического уничтожения сервера в любой базе данных.
  • NoSQL базы данных: понимаем суть
    +1
    Выходит консистентность сохраняется, но теряется availability. Ну правильно, это прямое следствие CAP-теоремы — если добавить распределенность, надо убрать или availability или consistency.
  • NoSQL базы данных: понимаем суть
    0
    А консистентность и изоляция сохраняется? Если да, то наверняка это очень медленно, если нет — тоже самое можно сделать в NoSQL вручную.
  • NoSQL базы данных: понимаем суть
    +2
    Мощный сервер стоит гораздо дороже чем кластер из слабых, еще надо умножить на количество реплик. При этом если база всё таки достигнет потолка — будет очень неприятно. И зачем нужен этот риск?
    Для заведомо простых приложений есть еще Redis. Супер быстрый и прикольный — сделан для программистов, работа с данными происходит похоже на работу с памятью, привычные структуры данных и т.д.
  • NoSQL базы данных: понимаем суть
    0
    В реляционных базах тоже нельзя джойнить между шардами.
  • NoSQL базы данных: понимаем суть
    –1
    Под надежностью обычно понимают другое. А вообще, то что всё должен делать прикладной программист — это правда. Более того NoSQL базы намного более понятны и приятны в работе для программистов. Следовательно DBA теряют востребованность и им это не нравится. :)
  • MongoDb в действии — интернет магазин
    0
    db.system.js.save( { _id: «foo», value: function( x, y ){ return x + y; } } );

    Сама хранимая процедура ничего не даст. Если транзакция как в этом примере, в пределах одного документа, то монго и так это поддерживает. Есть куча интересных функций для атомарного изменения документа. Но уже в пределах коллекции гарантий нет, так как она может быть распределена на много серверов.
  • MongoDb в действии — интернет магазин
    0
    а что делать — если индексов куча и все не вмещаются???


    Ну конечно sharding. Это же основная идея почти всех NoSQL хранилищ — легкое горизонтальное масштабирования. У монго оно еще и автоматическое.

    как на счет БД в 60 Гб?

    Например, тут размер базы 10TB.
  • MongoDb в действии — интернет магазин
    +1
    Да блин, там куча вариантов. Можно отправить запрос не дожидаясь подтверждения — быстрее некуда. Можно дождаться подтверждения, что сервер принял запрос и записал в память не синхронизируя ни журнал, ни базу — запишется само через определенный интервал.

    Дело в том, что можно регулировать durability очень гибко в широких пределах и для каждого запроса. Так чтобы одновременно и быстро и надежно физически не может быть.
  • MongoDb в действии — интернет магазин
    +1
    Монго всегда будет занимать всю свободную память, потому что это просто файловый кэш ОС. Главное чтобы индексы вмещались в память.

    По поводу бекапов, мне кажется, что вы используете mongodump/mongorestore. Они подходят для работы с отдельными коллекциями, и, например, индексы не сохраняют. Восстановление из правильного бекапа — это просто копирование директории data. Бекап должен выглядеть так: заходим на вторичную реплику, переводим процесс в режим только для чтения, копируем файлы данных, снимаем блокировку. Тут главное чтобы не кончился oplog. Если делать снапшот файловой системы, то разблокировать можно сразу же.
  • MongoDb в действии — интернет магазин
    0
    При горизонтальном масштабировании транзакции перестают нормально работать, так же как и джойны. Поэтому от них лучше сразу отказаться.

    user1.balance+=amount user2.balance-=amount user1.save user2.save


    Тут как раз описан этот пример.
  • MongoDb в действии — интернет магазин
    0
    32-битная версия имеет много ограничений, легче вообще её не рассматривать.

    В то же время, журнал невозможно настроить на полностью синхронную запись (по умолчанию — интервал 100мс). Конечно, в большинстве случаев это приемлемо, но уже компромисс.


    Всё наоборот. Для каждого запроса можно синхронизировать журнал на диск, базу данных на диск, минимальное количество реплик, минимально количество датацентров и т.д. Никаких компромиссов.
  • База по языкам программирования: Как появлялись языки и зачем
    +5
    > Хорошо известными вам декларативными ЯП являются правила описания страницы HTML и CSS.
    Всё ясно.
  • О глупости умных людей
    0
    Хм… «Новое исследование [...] доказывает, что умные люди сильнее подвержены подобным ошибкам.»
  • HTML уже не торт?!
    +1
    Ну и бред. На javascript написали виртуальную машину, на которой запустили бинарник.
  • SCSS — немного практики, часть I
    0
    Особенно если использовать вместе с HAML и CoffeeScript, получается красивая связка.