• Хватит ли 4000$ на разработку CMS?

    Ну есть куда более одной CMS, где админка и темизируется и переделывается не хуже, чем морда. Я вот в Drupal этим активно пользуюсь, например.
    Было же выше сказано - найти инструмент под свои нужды. Делать свой почти всегда мало продуктивно - исключением тут может быть создание каких-нибудь не стандартных, но однотипных сайтов разве что. Тогда да, можно сделать инструмент под данную задачу заточенный на котором она будет рализовываться быстро, работать шустро и.т.п.
    А писать CMS общего назначения с нуля дело неблагодарное. Ну и вспоминается lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D...
  • Хватит ли 4000$ на разработку CMS?

    @Masterme В том смысле, что вы сможете заработать больше, чем затратили на её разработку - да, когда-нибудь сможете.
    В том смысле, что за какое-то конечное время заработаете больше с ней, чем без неё настолько, чтобы окупить разработку - очень, очень спорно. Вполне вероятна даже обратная ситуация. Я бы сказал, что она намного более вероятна, особенно, если делать не однотипные сайты.
  • Хватит ли 4000$ на разработку CMS?

    @VovanZ Вообще такие есть, но в основном те, кто дошёл до осознания того, что использовать фреймворк разумнее, уже довольно профессиональны и откровенно говнокода не производят. Ну и наличествующая архитектура и договорённости помогают, конечно.
  • Хватит ли 4000$ на разработку CMS?

    @Quber Написав свою, вы быстро поймёте, что столкнулись с теми же проблемами. А то и бОльшими, т.к. очень мало разработчиков может хорошо продумать заранее архитектуру приложения. И велосипедов с квадратными колёсами море.
    А под большинство распространённых CMS уже есть готовые решения, которые позволяют их расширять в нужном направлении. И то, что вы быстрее пишете расширения для своей CMS, будет уже не так полезно и выгодно на практике.
  • Хватит ли 4000$ на разработку CMS?

    @0whitewolf0 Легче пользоваться тем, где баги уже выявили. А разобраться в готовой CMS досконально, куда проще, легче и быстрее, чем сделать свою.
  • Хватит ли 4000$ на разработку CMS?

    @0whitewolf0 А как удалённость сотрудника мешает участвовать в разработке активно? =)
  • pt или px. Равны ли они?

    1/72 дюйма он равен в полиграфии. А в нашем случае, всё зависит от установленного DPI монитора, и от соответствия его реальному DPI матрицы.
  • Почему программисты не любят MODx?

    Выбирают то, с чем умеют работать, прежде всего.
    И очень часто, из-за отсутствия возможности сравнить разные инструменты, выбирается инструмент, которым задача решается плохо, например, я видел магазины на вордпрессе. =)

    А по поводу минусов - да, идеальной CMS нет, но некоторые особенно неиделальны. =)
  • Почему программисты не любят MODx?

    Нет, допиливают 8 версию. Поддерживают 6 и 7.
  • Почему программисты не любят MODx?

    На данный момент, я остановился на двух инструментах:
    -Drupal - он покрывает очень широкий спектр более-менее стандартных задач.
    -Yii, когда задача выходит за эти рамки. Впрочем, в моём случае, это бывает часто. Т.к. созданием именно типовых сайтов, я занимаюсь сейчас не так уж и много.
    Ну и я довольно много занимаюсь оптимизацией и поддержкой совершенно разных проектов, и приходится немало сталкиваться с совершенно разными CMS, и прсто кодом разного качества... =)
  • Почему программисты не любят MODx?

    Если вы про evolution, то если переписать весь движок? =) Ну-ну. Зачем это нужно-то? Зачем заниматься некромантией, вместо того, чтобы использовать готовые и нормально работающие инструменты.
    Revolution неплохо работает в целом, если как следует разобраться с кешированием. Я делал на нём сайт с 2млн хитов в сутки, и очень неплохо в нем разобрался. Но больше никогда я применять этот инструмент не буду. Как только надо сделать что-то действительно серьёзное, вылезает всё убожество этого движка, и это хорошо понимаешь, если есть с чем сравнить.
  • Почему программисты не любят MODx?

    Да, это привёрнутый костыль. =)
  • Как на PHP сделать постоянно работающий скрипт?

    Дополню немного, чтобы было понятнее.
    В демоне пишем данные в какое-нибудь хранилище - база, файл и.т.п. А в приложении просто оттуда берём информацию и отдаём клиенту.
  • Как запустить PHP скрипт с задержкой в несколько часов?

    Выполнение нескольких строк кода, которые проверят, есть-ли что делать, очень маленькие издержки.
  • Как безопасно соединить АТХ блоки питания?

    Нельзя объединять даже совершенно одинаковые импульсники в параллель. С очень немалой вероятностью можно получить серьёзную проблему в цепях регулирования, и погоревшие блоки.
  • HDD ноутбуков: вылечить или сделать пепельницы?

    Методики в принципе есть, но в конкретном случае сказать, будет-ли какая-то работать сказать не имея у себя этого винта сложно.
    Если это не планируется сделать работой в какой-то момент. или увлечением хотя бы стойким, не надо в это лезть. Это сложно и дорого, т.к. потребуется и оборудование и софт, часть из которого сильно не бесплатна...
  • Операционный усилитель, подводные камни, теория VS практика?

    Это не упрёки. Вы не сможете проектировать реальные устройства с такими вопросами, вот и всё.
    Могу ответить на часть.

    1. Тип операционного усилителя. Есть различные по области применения. Малошумящие, rail2rail (макс уровень сигнала почти не отличается от питания), прецизионные, микромощные, высковольтные и.т.п.
    Какие характеристики важны, а чем можно пренебречь, зависит прежде всего от того, в какой схеме будет использоваться ваш OУ.
    В общем случае важен диапазон напряжений питания, и выходных напряжений, макс выходной ток, макс. рассеиваемая мощность, рабочая полоса частот или скорость нарастания на выходе, рекомендуемый КУ, входное, выходное сопротивление.

    2. Выбирается из необходимости получать униполярный или двуполярный сигнал на входе и выходе, иногда, если нужен чёткий "ноль", тоже даётся смещение в минус.

    3. Всё от применений зависит. Можно сделать интегратор или фильтр.
    Впрочем ваш вопрос не совсем понятен.

    4. Может тут вам больше подойдёт логика а не OУ? Компаратор на входе, и у вас будет цифровой сигнал. И моделировать и собирать это будет куда легче, чем на дискретных OУ.

    5. А что советовать - вы не задали граничных условий, а ОУ разных тысячи, на любой вкус.

    6. Соберите, например, микшер аналоговых сигналов на ОУ, или темброблок. Схем в интернете масса, ОУ для этого очень доступны, если не делать HiFi. =) Заодно, вы познакомитесь с поведением реальных ОУ как аналоговых приборов.

    7. Тут писать очень много, если по сигналу, то фильтры, на тех же ОУ, по питанию проще, обычно у ОУ очень высокая изоляция от шумов в питании. Рядом по питанию надо ставить небольшие керамические конденсаторы, но это касается почти всех IC. Подробнее можно почитать в даташите на конкретный ОУ.

    8. Тут в общем и сказать особо нечего - общие знания нужны и практика. Это не что-то связанное именно с ОУ.

    После прочтения вам, надеюсь, стал понятен мой начальный ответ?
    Всё, что я здесь написал, на самом деле довольно мало полезно, но это в то же время довольно развёрнутые ответы на ваши вопросы.
  • Возможно ли сделать трансфер базы данных, с cms Joomla на DLE?

    @SNPAC По поводу же кривости, он более кривой как CMS, но если сравнивать два одинаковых сайта, на Joomla и DLE, то всё не так очевидно. =) Тут всё будет зависеть от профессионализма разработчика. И к несчастью, в среднем, уровень разработчиков использующих, и тот, и другой инструмент весьма плачевен. Joomla очень доступна, и распространена. Полно модулей, написанных кем и как попало, и "сайтостроителей" со школьной парты. Они сильно портят средние показатели. =) А DLE не блещет в принципе, и серьёзный разработчик вряд-ли будет вообще смотреть в его сторону. =)