• Что лучше - Perl или Python и для чего?

    @odmin4eg
    с Перлами не сильно знаком, но после Похапе, Питон просто мир перевернул, язык для разработчиков, а не компиляторов ::))

    + такая плющка, что джангой завётся — невероятно подкупает.
    Ответ написан
    1 комментарий
  • Зачем спрашивать дважды почту при регистрации на ресурсах?

    Vas3K
    @Vas3K
    Все просто. Рассказываю как разработчик. В общем приходит заказчик и говорит:
    — Вот тут форма регистрации, поля такие, такие, почта два раза.
    — А зачем два раза почту-то? Вас не раздражает?
    — Нет. Вы не понимаете. Это стандарт. Все так делают, мы хуже что-ли.
    — Какой это стандарт? У кого?
    — У всех! На всех сайтах надо вводить по два раза. Вы что, вообще не разбираетесь что-ли в интернете? Мы вам платим за что?!
    — Ладно, пусть будет два раза.

    Вот так и появляется два раза почта, обязательное подтверждение по e-mail, вырвиглазные капчи и «уберите эти длинные дефисы».
    Ответ написан
    6 комментариев
  • Теория: структура высоконагруженного сервиса?

    VBart
    @VBart
    У вас в вопросе написано «теория», а далее идет изложение каких-то практических фактов, причем очень отдаленно. Как уже тут было выше сказано, у вас кардинально не верный подход.

    Каждое конкретное архитектурное решение зависит от конкретных задач. Для этого существуют системные архитекторы, в задачи которых входит кропотливый анализ задач проекта и выбор конкретных технических решений в конкретном случае. В больших высоконагруженных и постоянно развивающихся проектах эти люди должны работать на постоянной основе, получать зарплату.

    Никто вам не сможет помочь в данном случае по двум причинам:
    1) Вы не изложили во всех технических подробностях и деталях свой проект. Про фотки, соц. сеть и прочее — этого не достаточно, нужно многостраничное подробное толковое описание всех требуемых функций, хотя бы… я уж не говорю, что хорошо бы конкретизировать и ресурсы, а так же прикинуть нагрузки.
    2) Это не делается вот так вот на коленке. Толковый подробный анализ может занимать несколько месяцев, и разумеется бесплатно этим никто не будет заниматься. Есть некие теоретические основы, но они настолько теоретические, что вы их даже не изложили выше. Количество DNS-серверов, AA-записей, nginx-сы, php, устройство БД и т. д. — это все уже практическая область, которая сильно зависит от задачи. Вы можете реализовать все, что вы написали, и получить при этом громоздкое неповоротливое плохо масштабируемое приложение, требующее при этом огромных затрат. Исходя из того, что вы написали, могу лишь посоветовать не заниматься этим, ибо у вас изначально уже неверный подход и неверные представления. И любые практические советы, которые вам тут написали, или еще напишут — не более чем личный ничем не подкрепленный опыт, в решении собственных (а не ваших) задач, которые могут кардинально отличаться.

    Могу лишь поделится советом, как делаю я при выборе конкретного технического решения, по шагам:
    1) Сбор требований. Важно собрать и выявить как можно больше требований определяемых конкретной задачей по отношении к конкретному вопросу. Например, все требования к хранению данных такого-то сервиса.
    2) Отобрать как можно большее количество вариантов с помощью которых задача в принципе решаема, а затем исключить из них те, которые заведомо не вписываются в требования, оставив только те, что наиболее им удовлетворяют (бывает так что всем требованиям в принципе невозможно удовлетворить).
    3) Техническое решение — это всегда компромисс. Из оставшихся вариантов надо выбрать наиболее подходящий, зачастую для этого нужно провести сравнительное тестирование (причем именно свое собственное, на тестах так или иначе моделирующих вашу задачу). Если результат вас все равно не устроил, вероятно вам стоит пересмотреть требования или разбить задачу на несколько, по возможности. В любом случае, это отсылает вас к корректированию пункта 1.

    Бонус трек 1: KISS
    Бонус трек 2: One size never fits all
    Ответ написан
    6 комментариев
  • Файловая система для авaтарок?

    @great_boba
    давным давно ответом на этот вопрос мог быть reiserfs
    Ответ написан
    Комментировать
  • Организация кода django-проекта, связывание приложений?

    printf
    @printf
    Ем детей.
    По-хорошему приложение в django — юниксвей в чистом виде: делает что-то одно, делает это хорошо, обладает неким внешним API для взаимодействия с другими модулями. Обычно даже в небольшом проекте насчитывается около десятка приложений. Плюсы такого подхода — значительно легче тестировать, повторно использовать код, можно сравнительно безболезненно менять имплементацию модуля, не нарушая работу всего сайта.

    Антипаттерн — монолитные приложения (обычно буквально одно-два). Их, помимо прочего, тяжелее поддерживать, поскольку код выполняет множество не связанных напрямую задач (функции, отвечающие за генерацию RSS и смену аватарки пользователя, находятся рядом — в таком файле ничего не получится сделать без поллитры и ctrl-F). Это особенно актуально, когда в команду добавляется новый разработчик.

    Взаимодействие приложений — гораздо более обширная тема, ее вот так запросто в двух предложениях не раскрыть, как мне кажется.
    Ответ написан
    Комментировать
  • Как закачать письма обратно на почтовый сервер?

    savostin
    @savostin
    Еще один программист
    Простите, не удержался — напомнило вопрос «Как закачать файл обратно в Интернет — он мне больше не нужен».
    Ответ написан
    1 комментарий
  • Как задать свой autoincrement primary key в AppEngine/Python?

    adso
    @adso
    Это уже реализовано. Кроме ключей BigTable раздает и числовые id. Запрос к БД по id:
    Model.get_by_id()
    Для получения id любой сущности — entity.key().id()

    Оно вполне пригодно для урл, только учтите, что id инкриментится для сущностей любого типа в вашем приложении. Одно на всех. Поэтому числа выходят большие. Например, www.arhimir.ru/news/1126006 — сделано на GAE-Python.
    Ответ написан
    2 комментария