Задать вопрос
  • Как разработчику подготовиться к миграции на компьютер под управлением OSX?

    Lerg
    @Lerg
    Defold, Corona, Lua, GameDev
    Если сидели на никсас, то никакой сложности в освоении не возникнет.
    Наверника то, что вы уже использовали, будет работать и на маке - PhpStorm, VirtualBox, Sublime Text и т.п.
    Скайп есть, куда без него. Таск трекеры все в вебе (Atlassian и прочие), так что платформа не принципиальна. С того же Bitbucket можно скачать SourceTree.

    А вообще в интернете много информации по этому поводу...
    Ответ написан
    Комментировать
  • Chrome OS для верстальщика

    omun
    @omun
    Как говорит поддержка огнелиса: google's chrome os is a restricted system - you can't install any third-party applications on it locally.
    Прозреваю, что ответ на первый вопрос - категорическое нет.
    Disclaimer: личного опыта работы с хромосью у меня нет.
    Ответ написан
    Комментировать
  • Как можно объяснить пример кода?

    Общий коммент такой:
    Скрипт, Ваш, делает следующее, как только скроллинг страницы ушел ниже 200px - появляется кнопка, по нажатию на которую происходит "промотка" страницы к начал.

    $(function(){ // "Упаковываем" - вызываем после загрузки страницы 
    
      $(window).scroll(function(){ // Привязываем событие к скроллу окна
        var scrolled = $(window).scrollTop();  // Узнаем величину, на которую ушел скролл
        if (scrolled > 200) $('.go-top').fadeIn('slow');  // Если эта величина больше 200px - показываем кнопку
        if (scrolled < 200) $('.go-top').fadeOut('slow');   // Если эта величина меньше 200px - убираем кнопку
      });
       
      $('.go-top').click(function () {  // "Вешаем" событие на клик кнопки
        $("html, body").animate({ scrollTop: "0" },200);  // "Мотаем" в начало страницы
      });
    });
    Ответ написан
    2 комментария
  • Как можно объяснить пример кода?

    miraage
    @miraage
    Старый прогер
    // функция, которая выполнится по событию DOMReady
    $(function(){
      // обработчик события 'scroll' у объекта window, проще говоря - при скролле страницы
      $(window).scroll(function(){
        // смещение относительно начала (верха) страницы. по идее в пикселях
        var scrolled = $(window).scrollTop();
        // $('.go-top') - выбрать элементы с классом go-top, .fadeIn('slow') - показать их, медленно
        if (scrolled > 200) $('.go-top').fadeIn('slow');
        if (scrolled < 200) $('.go-top').fadeOut('slow'); // либо скрыть, соответственно
      });
       
      // обработчик события 'click' у объектов с классом go-top
      $('.go-top').click(function () {
        // Никогда не понимал зачем оба селектора, выбирает элементы html и body
       // Выставляет им свойство scrollTop в 0, то есть в начало (верх) страницы с временем выполнения 200мс
        $("html, body").animate({ scrollTop: "0" },200);
      });
    });


    Поправьте, если где-то ошибся.
    Ответ написан
    3 комментария
  • Обработчики запросов в ExpressJS

    mannaro
    @mannaro
    Умею профессионально гуглить
    Вы издеваетесь? Node.js асинхронный. Полностью. Пересмотрите логику.
    Сделать можно, например, так:

    app.get("/", function(req, res){
     setTimeout(function(result){
      // some logic
      console.log('finished');
     },1000*5);
     res.end('Processing..');
    });
    Ответ написан
  • В чём преимущество асинхронных серверов перед PHP/nginx?

    AMar4enko
    @AMar4enko

    Если коротко, то ошибка закралась вот тут:
    В асинхронном сервере в единый момент времени обрабатывается столько запросов, сколько есть воркеров

    Представьте себе, что у вас на сервер приходит запрос, связанный с выборкой данных из БД.
    Он отрабатывает, предположим, за 150 мс, из которых 130 это работа с базой данных.

    В случае с PHP у вас воркер будет заблокирован эти 150 мс для обработки других запросов.
    В случае с асинхронным сервером, он, пока запрос 1 ждет данные от БД в течение 130 мс, сможет принять и начать обрабатывать другие запросы. Предположим, что у нас один PHP-воркер. В этом случае таких запросов, как из примера, он сможет обработать семь штук за секунду.

    Асинхронному же, допустим, прилетят 20 запросов. Он обработает каждый до взаимодействия с БД, допустим за 10 мс, полетят 20 запросов к БД, пройдут, допустим, за 500 мс, и сервер сформирует ответ. И это все практически параллельно. Итого меньше чем за секунду мы таким образом обработаем 20 запросов.

    Можно, конечно, увеличить пул FastCGI, но оверхед при обработке запроса каждым воркером будет несоизмеримо выше, чем при обработке асинхронным сервером.

    Ответ написан
    4 комментария
  • В последнее время появилось много критики Монго. С чем связано это?

    @baadf00d
    эйфория от новых возможностей прошла и вскрылись недостатки, на мой взгляд основные их них:
    — Слабая производительность на 1-серверной БД. Особенно заметно на map-reduce по данным, которые полностью влезли в память.
    — Особенности документо-ориентированной структуры. Многие переходили с табличных БД и тут понеслась: сначала радость, что не надо возиться со структурой, а потом расплата — в одной коллекции куча разных объектов и приложение регулярно читает из вроде бы известной коллекции что-то для себя неожиданное (очень старые объекты, некорректно измененные и т.п.).
    — Целостность данных. Кто-то привык, что БД контролирует этот вопрос, вешают констрейнты и ловят ошибки в логе в случае какой промашки по части бизнес-логики. Монга же ничего такого сама не контролирует, ну и получаются внутри БД ссылки на объекты, которых нет.
    — Отсутствие полноценных транзакций. Те, кто бросились все хранить в монге с ужасом поняли, что для биллинга нужно что-то другое. (должен оговориться, что не все пока поняли)

    По моему мнению отказаться от классической реляционной БД в пользу монги может позволить далеко не каждый проект. Если перетаскивать какой-нибудь небольшой интернет-магазин, то с бОльшей вероятностью это принесет боль и страдание нежели ожидаемый профит. Эффективным решением будет параллельное использование монги и реляционной БД, но чтобы это имело смысл — проект должен быть соответствующих размеров. Для небольшого проекта городить такой огород контрпродуктивно.

    PS Мое мнение основано на годичном опыте неплотной работы с монгой, опыт работы с реляционными БД — примерно 10 лет.
    Ответ написан
    2 комментария
  • В последнее время появилось много критики Монго. С чем связано это?

    nekipelov
    @nekipelov
    Сначала все руководствовались слухами, а теперь собственным опытом? :-)

    Лично я много раз расстраивался, используя mongo. Уже по коду первый версий видно, что БД пишется далеко не профессиональными программистами (ну а кому еще взбредет в голову переопределять стандартные C функции? пруф: github.com/mongodb/mongo/blob/v1.4/util/assert_util.h, github.com/mongodb/mongo/blob/v1.4/util/allocator.h). Но вроде бы, от версии к версии, с проблемами сталкиваемся все реже. Только вот наш продукт еще на этапе разработки, кто знает, что будет в реальной работе…
    Ответ написан
    2 комментария
  • Сборка проекта, AMD, LMD, использование модулей проекта

    azproduction
    @azproduction
    Использовать сборку и автоматизацию — однозначно стоит.

    require.js имеет свой собственный сборщик модулй и оптимизатор — r.js

    Достаточно много с ним работал из опыта могу сказать, что он хорош, но мне не подошел — муторно поддерживать проект на нем:
    — это AMD, а значит нужно писать обертку define, колдовать если заходится использовать модуль в node.js… (можно не писать обертку, но придется опять колдовать)
    — require() — God Object и возвращает всевозможные тип ресурсов всевозможными путями. Долго вникать что к чему если код чужой
    — плагинная система у него странная для восприятия «с нуля»
    — результат сборки сложно окинуть взглядом «все как-то само»

    В общем, я устал от AMD и RequireJS, смотрел в сторону всевозможных подобных проектов тк мне не хотелось писать еще один велосипед. В итоге, мне пришлось написать инструмент своей мечты — LMD.

    Исходил я из слудующих соображений:

    * Сегодня все собирается. Даже dev
    — зачем писать обертку и вобще писать что-то лишнее если за тебя это может сделать робот?!
    * Читаемость кода очень важна
    — Нужно исключить неявные конструкции
    — Я как архитектор моего проекта хочу знать, что в нем будет «валяться»
    * Сборок бывает много
    — dev, production, dev-ru, test-en_US
    * Нужен контроль результата сборки
    — Проверка целостности
    — Подробная информация о сборке
    — Аналитика

    Сегодня LMD умеет все то, что умеют другие сборщики, и имеет ряд преимуществ: CommonJS/Modules, честная и тотальная изоляция модулей, шикарная аналитика сборок как статическая так и динамическая, CLI с автокомплитом, GUI. LMD особенно хорош если у вас много сборок — много языков, много окружений.

    Если вы используете grunt, то у LMD есть для него плагин — grunt-lmd.

    Буквально на длях я написал целую кучу примеров к всевозможным плагинам и фичам LMD. Посмотрите их. Если будут вопросы задавайте тут или в ЛС.
    Ответ написан
    3 комментария
  • Возможно ли получить прямую ссылку на файл в github?

    image
    Ответ написан
    Комментировать
  • Как запустить независимий процесс из node?

    unclechu
    @unclechu
    #!/usr/bin/env node require('child_process').exec('name &', function (err) { if (err) { console.log('Can\'t start child process.'); process.exit(1); } console.log('Child process is started.'); });
    Ответ написан
    1 комментарий
  • Существует ли расширяемая, модульная, платная/бесплатная CMS с хорошим внутренним дизайном?

    SilentImp
    @SilentImp
    Нет, не существует.
    Ответ написан
    Комментировать
  • Сколько будет 0/0?

    SLY_G
    @SLY_G
    журналист, переводчик, программист, стартапщик
    Математически не определено.
    Дело в том, что x/x=1 так как x = x * 1
    Но поскольку <любое число> * 0 = 0, получается неопределённость.
    Ответ написан
    Комментировать
  • Помощь с придумыванием имён?

    bobermaniac
    @bobermaniac
    Что бы не говорили злые языки, ни одно из правил именования переменных не является самоочевидным.

    Например, во многих языках аксессоры принято именовать, начиная с префикса get. Это не является верным для Objective C, в котором с get начинаются только те методы, которые получают значение внутреннего буфера во внешний, заранее размещенный в памяти.

    В Java любой метод, начинающийся с Get скорее всего является простым аксессором. В C# если метод начинается с Get — это скорее всего сложный аксессор с изменением состояния или побочными эффектами.

    Если вы делаете API — просто задокументируйте его. Хорошая документация стократ лучше, чем любое, самое «очевидное» решение по именованию.
    Ответ написан
    Комментировать
  • Как запретить автообновление конкретного плагина Firefox?

    Smileek
    @Smileek
    Нужно проделать следующее:
    — Набрать в адресной строке about:config
    — Правый клик -> Создать -> Логическое (New -> Boolean)
    — Присвоить новой переменной имя: extensions.{GUID}.update.enabled
    — И значение: false

    Осталось выяснить откуда взять GUID.
    Ленивый вариант: Extension Manager Extended, показывает GUID в свойствах плагина.
    Ручной вариант: в config'е задать фильтр «extensions.{» и обнаружить плагин по описанию.

    Источник

    З.Ы. А можно поинтересоваться, почему такая аллергия на обновления? Шустрее ведь работают следующие версии.
    Ответ написан
    5 комментариев