Задать вопрос
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    SowingSadness
    @SowingSadness
    web-разработчик
    PostgreSQL лучше во всех аспектах, в том числе и по скорости ответа.
    Уже нет причин использовать MySQL.

    PostgreSQL можно продавать со своим продуктом. MySQL - нет.
    PostgreSQL умеет массивы, MySQL - нет.
    PostgreSQL умеет json, MySQL - нет.
    PostgreSQL умеет DateTime с временными зонами, MySQL - нет.
    PostgreSQL умеет работать с временными интервалами, MySQL - нет.
    PostgreSQL умеет нормально работать с unicode, MySQL - нет.
    PostgreSQL умеет DISTINCT по выбранным колонкам, MySQL - нет.
    PostgreSQL умеет ограничивать значения индексов по условиям, MySQL - нет.
    PostgreSQL имеет схемы, MySQL - нет.
    PostgreSQL имеет наследование в таблицах, MySQL - нет.
    PostgreSQL есть нормальная оптимизация JOIN, MySQL - нет.
    PostgreSQL умеет материализованные представления, MySQL - нет.
    PostgreSQL умеет PLSQL, MySQL - нет.
    PostgreSQL умеет Python функции, MySQL - нет.
    PostgreSQL умеет ключи из внешних источников, MySQL - нет.
    PostgreSQL умеет нормальные(вложенные) транзакции, MySQL - нет.
    MySQL есть проблемы с установкой и удалением своих сервисов под Windows, PostgreSQL - нет.
    ̶P̶o̶s̶t̶g̶r̶e̶S̶Q̶L̶ ̶у̶м̶е̶е̶т ̶а̶с̶и̶н̶х̶р̶о̶н̶н̶у̶ю р̶е̶п̶л̶и̶к̶а̶ц̶и̶ю̶, ̶M̶y̶S̶Q̶L̶ ̶-̶ ̶н̶е̶т.
    Ответ написан
  • Плюсы/минусы смены профиля с PHP на Python/Ruby. Оно того стоит?

    @skynetdev
    С учетом того что скоро выйдет PHP 7
    не советую вам ни питона ни руби
    пхп будет рулить в этом случае по полной
    Ответ написан
    Комментировать
  • Почему protected и private методы значительно медленнее чем public?

    выбирать модификаторы доступа из соображений оптимизации - мягко говоря не самый мудрый подход.
    Ответ написан
    Комментировать
  • Как работает веб сервер?

    Lerg
    @Lerg
    Defold, Corona, Lua, GameDev
    По TCP приходит сигнал в сетевую карту, та вычленяет из него пакет и перенаправляет в ядро ОС, ядро уже смотрит какому приложению отдать этот пакет. Находит Apache и передаёт ему, тот парсит пакет, выделяет запрос, парсит запрос и дальше по программе.
    Ответ написан
    3 комментария
  • Как разобраться в философии symfony2?

    @shoomyst
    dumb
    Symfony это конструктор, который поставляется в собранном виде. Но ничто не мешает вам его разобрать и собрать по-своему. Многие критикуют фреймворк за это качество: нет ощущения целостности как у Yii или Laravel. Похожее говорили в свое время про Zend1: монстр, куча несвязанных компонент, лучше я буду кодить в своем уютном CodeIgniter-e.

    Symfony Framework - это (грубо) HttpKernel + DependencyInjection Container (DIC) + EventDispatcher.

    Главное задачей HttpKernel является конвертирование Request в Response. Для этого он загружает и инициализируется бандлы, создает контейнер (DIC), пытается по Request определить контроллер, выполнить его и убедиться, что результат выполенения контроллера является объектом Response, если нет, то пытается преобразовать результат в Response.

    DIC занимается созданием и хранением сервисов, если совсем грубо, то это такой навороченный Registry.

    Ну а EventDispatcher запускает события, на которые могут подписываться любые части фреймворка и приложения. Вы можете подписаться на любые события внутри Symfony и влиять на ход выполенения вашего приложения.

    Бандлы лучше всего сравнить с плагинами. Есть ядро, которое было описано выше, а бандлы это плагины для него, добавляющие некий функционал (FrameworkBundle, TwigBundle, MonologBundle). FrameworkBundle это основной плагин, который добавляет основной функционал: формы, валидация, сессии, translations. При желании его тоже можно заменить как и любой другой. Другой задачей бандлов является интеграция различных библиотек в ваш проект: twig, monolog, swiftmailer (поставляются с симфони), sphinx, elastic и т.д. Ну и логика приложения так же может быть размещена в бандлах.

    Чтобы Symfony узнал про ваш бандл, его необходимо зарегистрировать в AppKernel.

    У каждого бандла есть своя конфигурация, с помощью которой он может интегрироваться в Symfony:
    1. Регистрация своих сервисов в DIC. Далее вы можете использовать их, например, в контроллере: $container->get('sphinx.search')->query(...)
    2. Бандл может повесить свои сервисы на какие-то события. Например, на событие KernelEvents::CONTROLLER, тогда ваш бандл получит управление при подборе контроллера и вы сможете обойти штатный механизм подбора и вернуть свой, который и будет выполнен.
    3. Использование тегов. Например, вы создали класс HelloWorldViewHelper и хотите его подключить в Templating. В конфигурации указываете для него тег "templating.helper" и он будет подхвачен Symfony и встроен в шаблонизатор.
    Ответ написан
    6 комментариев
  • Как правильно разработать легкомасштабируемую платёжную систему?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

    2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

    По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
    На мой взгляд получение баланса например вполне можно сделать синхронным.

    3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.

    4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

    5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
    Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

    6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

    PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)
    Ответ написан
    Комментировать
  • Как правильно реализовать ООП класс базы данных с PDO?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Я уже отвечал как-то на подобный вопрос. И не один раз. И не два.
    Поскольку мозги всех пользователей пхп ходят по одним и тем же рельсам, не сворачивая. Впрочем, не всех. 85% всю жизнь продолжают писать mysl_query, которую выучили из видеоурока, и не видят в этом проблем. И только у самых талантливых 15-и процентов в какой-то момент возникает мысль ВСЁ АВТОМАТИЗИРОВАТЬ. Это, на самом деле, хороший знак. Такое желание как раз и отличает потенциального программиста от клепальщика гуано-кода.

    Но всё портит недостаток знаний в SQL. Искренне полагая SQL не более чем key-value хранилищем, они всерьез уверены в том, что функция select() с двумя аргументами - это все что им надо.

    Настоятельно рекомендую прочесть аргументацию по ссылке выше.

    После этого понять, что существует ТРИ класса классов для работы с БД:

    1. DB-хелпер. Класс, берущий на себя всю грязную работу по исполнению запросов. В случае с ПДО не сильно-то и нужен. Позволяет исполнять любые запросы. НИКАКИХ функций типа select(), ограничивающих функциональность, в нем быть не должно ни в коем случае.
    2. Query builder. Функция типа select() может быть только в квери билдере, который маскирует SQL в функции РНР. Заведомо ущербен по сравнению с первым, но зато позволяет использовать запросы более сложные, чем ORM.
    3. ORM. То, что начинающему пользователю на самом деле нужно, но он об этом просто не догадывается. Как раз та самая волшебная палочка, которая делает примитивное доставание данных из базы по первичному ключу столь маняще единообразным.

    Cамое главное, что надо понять:
    Все вышеперечисленное - это РАЗНЫЕ типы классов, не имеющие между собой ничего общего.
    И не пытаться под видом первого городить нежизнеспособное второе, имея в виду третье. Надо очень четко понимать, что сначала делаем первое, а потом, на его основе - либо второе, либо третье. Но не все вместе.

    А можно не пытаться изобретать велосипед, а использовать готовое. Например - популярный фреймворк. Тогда желаемая функция будет выглядеть вот так:

    public function viewUser($id)
    {
        return User::model()->findByPk($id);
    }

    Это в самом предпочтительном случае - при использовании ORM.
    На квери билдере это будет что-то вроде
    public function viewUser($id)
    {
        return DB::select('*')->from('users')->where("id", '=', $id);
    }


    При этом можно использовать и чистый SQL. Запрос прямо в классе юзера - это не так уж и страшно. Тем более, что есть такие запросы, которые по другому просто не выполнишь. Другое дело, что всю работу по исполнению запроса должен брать на себя хелпер. Пример можно посмотреть по ссылке выше - там хоть и SQL , но того ужаса, который здесь, нету:
    public function viewUser($id)
    {
        $sql = 'SELECT * FROM users WHERE id=?';
        return DB::prepare($sql)->execute([$id])->fetch();
    }
    Дальнейшую работы над классом можно производить только после того как ты определишься, какой именно класс ты хочешь написать.
    Ответ написан
  • Какими документами регулируются написание ТЗ?

    karnavorn
    @karnavorn
    Student, Junior java developer.
    Слушаюсь и выполняю!
    Ответ написан
    Комментировать
  • Какими документами регулируются написание ТЗ?

    @PiloTeZ
    ...
    Да, капитан!
    Ответ написан
    Комментировать
  • Как лучше синхронизировать модели Django и SQLAlchemy?

    @brutal_lobster
    Очень неудобная и немного не понятная схема :) Софтины как-то сильно связаны, нужно ли разделять процессы их разработки?
    Чтобы ничего не отваливалось при изменении - пишите тесты! :)

    А миграции однозначно помогут. Инкрементальная разработка - все дела :)

    Если изменения равноправно и раздельно вносят обе стороны - централизируйте их (может быть даже вынесите миграции в отдельный субрепозиторий). Сделайте, чтобы для мерджа пулл-реквеста, который изменяет модели, было бы необходимо согласие обеих сторон и успешное прохождение каких-нибудь тестов на совместимость моделей.
    Или не выделяйте миграции как отдельную сущность, но сместите ответственность в сторону одного проекта и тесты, тесты, тесты..
    Ответ написан
    Комментировать
  • Работа в Беларуси в IT ?

    @lookid
    Варгейминг! половина Белорусии там работает
    Ответ написан
    2 комментария
  • Как заставить людей писать текст на сайте?

    savostin
    @savostin
    Еще один программист
    Для начала пишите сами (под разными никами) и отвечайте себе же - получите тематику и вектор развития. Потом по мере прихода живых активных пользователей нужно будет только периодически направлять этот вектор, чтобы не скатилось в угарное г.
    Ответ написан
    3 комментария
  • Чем отличается junior от middle? а Senior?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Вот как это выглядит с т.з. работодателя

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

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

    Синьор
    - собеседование
    указывает на ошибку в тестовом задании, предлагает два решения проблемы, над которой команда пыхтела последнюю неделю и альтернативный стек технологий, на который можно перевести проект
    - испытательный срок
    рефакторит проект, делает билд джун-устойчивым, по ходу дела пишет алгоритм для киллер-фичи, запланированной только на следующий квартал и под конец испытательного срока организует воркшоп, на котором представляет свои наработки "в свободное время" по переводу проекта на другой стек технологий, в которых уже реализована большая часть функционала следующего релиза.
    - работа
    пинками помогает команде в переходе на одобренный руководством новый стек, в чем его активно поддерживает джун, окрыленный тем, что теперь его накопившиеся косяки точно никто не заметит, переводит проект на новый стек, увеличивает производительность в два раза, через год переводит еще раз, периодически генерирует идеи новых продуктов, может пропасть на неделю и вернуться с новой фичей, а может уйти в накопившийся за несколько лет отпуск и больше не вернуться, т.к. случайно встретил старого знакомого, передложившего другой мега-проект с гига-зарплатой.
    Ответ написан
    4 комментария
  • Чем отличается junior от middle? а Senior?

    вы все знаете — Junior
    вы поняли что ничего не знаете — Mid
    вам все равно — Senior

    habrahabr.ru/post/231649/#comment_7826819
    Ответ написан
    2 комментария
  • Существует ли теория, о том как построить общение между двумя объектами, ничего незнающими о друг друге?

    @angry_bender
    PHP, JS
    Есть. Сначала передаем друг другу в основные законы математики, начинаем с самого примитивного: например 3*3+ 4*4 = 5*5. После расшифровки другая сторона будет знать как кодируются числа и арифметические операции. Затем сообщения усложняем вплоть до абстрактных понятий. Тем самым у собеседников будет определенный язык общения.
    Ответ написан
    4 комментария
  • Как контролировать программистов в разрабатываемом старт-Апе?

    cissav
    @cissav
    Руководитель Omnidesk.ru
    Вы, конечно, можете понаставить им кучу палок в колеса, но на 100% обезопасить себя от "слива" базы не получится. Можете использовать Github Enterprise и т.д., но это не решит проблему.

    Проблема в подходе к делу. Вам нужно брать людей, которым можно доверять, и самому научиться доверять. Частично этот момент я затрагивал в статье на Хабре. Рекомендую ознакомиться.

    Плюс ко всему, ценность вашего стартапа должна быть в видении того, каким должен быть сервис, и в каком направлении он должен развиваться. У ваших разработчиков не будет стратегической картинки, а у вас должна быть. Если её не будет и у вас, а разработчики будут разбираться во всем лучше, то едва ли стоит вообще браться за проект.
    Ответ написан
    1 комментарий
  • Как организовать в django отношение "родитель -- дочерняя запись" в models красиво?

    sim3x
    @sim3x
    Ты бежишь впереди паровоза

    Вот такое не надо
    id = models.IntegerField ( primary_key=True )
    оно само делается ОРМ

    OneToOne это не про то. Это поле, которое связывает две модели, которые по некоторым обстоятельствам были разделены. Раньше их часто употребляли для связи захардкоженной модели User и UserDetails с доп полями, которые нужны были разрабу

    FullName
    CamelCase - для классов
    under_score - для переменных, полей модели и тд

    class Person(models.Model):
        full_name = models.CharField( default=u"Иванов И.И.", max_length=256 )
        # ...
        parent = models.ForeighKey('self', blank=True, null=True)
        # or
        # parent = models.ForeighKey("Person", blank=True, null=True)


    то это перестроение всего одного индекса

    Но как и раньше - решаешь проблемы, которой еще нет
    Ответ написан
    5 комментариев
  • На повестку дня: Ruby On Rails или Node.js или php или Python?

    webus
    @webus
    Golang | Python | NodeJS | Java
    Python / Django.

    Мода на Ruby / Rails прошла. Владельцу проекта нужна предсказуемость и прозрачность работы фреймворка, на котором построен его проект. Этого достаточно сложно добиться с "магией" Ruby, которую понять то сложно, если пришел с других языков. Это первое.

    Второе, как ни крути но Ruby медленный. Да я пробовал последний Ruby 2.1 с последними Рельсами, и говорю он медленный. Да я знаю, что можно запускать Рельсу на всяких passanger, thin и unicorn. Знаю что есть JRuby и прочие реализации. Знаю что можно закешировать все что можно. Я это пробовал. И все равно, Руби - медленный. К слову реализаций Python тоже много, есть и Jython, PyPy, Stackless Python. Django на фоне Rails выглядит просто молнией, быстрый старт и прозрачность работы. Нет никакой магии, все понятно как работает от начала и до конца.

    Третье, Django достаточно консервативный фреймворк. В него никогда не добавят какую-нибудь сомнительную фичу, как это бывает в Rails (например никому не нужный turbolinks). Скоро выходит версия 1.7. Где достаточно много плюшек действительно нужных.

    Вам будут говорить про разветвление Python на версию 2 и 3. Что все плохо. Не верьте. Это все ерунда. В настоящее время большинство популярных библиотек уже давно на Python 3. Django, Flask уже давно. Мы все новые проекты начинаем на Python 3 и проблем никаких нет.

    На счет NodeJS. Использовать можно, но... Неудобно. Переносимость кода client side < - > server side по факту равна менее 10%. Сейчас большинство используют NodeJS как платформу для запуска нужных тулз для сборки фронтэнда, например Grunt / Gulp, Bower и прочее. Конечно пакетный менеджер npm.

    Надеюсь ответил на ваш вопрос.
    Ответ написан
    4 комментария
  • Действительно ли использование селектора по ID - признак абсолютно плохого стиля?

    Тот кто говорит об избегании использовании id в селекторах - клинический идиот с завышенной самооценкой. Не слушайте этих людей.

    Селекторы по классам и по id - это основа выборки элементов. Селекторы по классам предназначены для определения групп элементов. Селекторы по id для определения конкретных элементов. Сочетание этих селекторов позволяет выделять конкретные элементы в определённых группах.
    Ответ написан
    Комментировать
  • Действительно ли использование селектора по ID - признак абсолютно плохого стиля?

    somenumboola
    @somenumboola
    Team Lead in B-online Solutions
    Пробежал статью глазами. Мое мнение - весьма бредовая статья. Клинический перфекционизм в разработке + собственные вкусовые пристрастия выставлять как канон... В ID нет ничего ничего, ну абсолютно ничего плохого, особенно учитывая описанный вами подход.

    Хотя если очень захотеть то можно извращаться сколько угодно. В свое время пробовал построить веб страницу используя haml scss и модификатор строгости в CSS. Удалось полностью избавится и от классов и от ID. Вот только код был как Китайская стена длинной. Оно вам надо?

    Более того при разработке фронта (javascript) от ID полностью уйти невозможно. А в общем вы правильно описали принципы применения и того и другого, так что не смешивайте конвенции сжатого и читабельного кода с идеей божественного сечения. Главное пишите, пишите и еще раз пишите, стиль как свой так и "правильный" вырабатывается только с практикой. И не всегда "как надо" необходимо больше нежели "как хочется" ;)
    Ответ написан
    Комментировать