• Как можно построить архитектуру действительно большого Flask приложения?

    @asd111
    Динамический выбор таблицы для одной и той же модели в django обычно решается примерно так:
    def get_model(db_table):
      class MyClassMetaclass(models.base.ModelBase):
        def __new__(cls, name, bases, attrs):
          name += db_table
          return models.base.ModelBase.__new__(cls, name, bases, attrs)
    
      class MyClass(models.Model):
        __metaclass__ = MyClassMetaclass
    
        class Meta:
          db_table = db_table
    
      return MyClass
    
    my_model = get_model('29345794_table')
    my_model.objects.filter( ...


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

    @0x131315
    Стратегию уже подсказали: найти любую работу, чтобы кушать, и тем самым выиграть время на изучение чего-то, что поможет зарабатывать больше, и тем самым выиграть еще больше времени, и в конце концов изучить то, благодаря чему будешь работать не на зарплату, а на удовлетворение.

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

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

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

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

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

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

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

    Со вторым все понятно: надо либо создать условия, либо отказаться от этой деятельности, и перейти к другой.
    Кто-то отказывается, уходит на другие работы, в основном физические, неквалифицированные, просто чтобы не думать. И как правило остается там до конца, уже не в силах выбраться из болота рутины.
    Кто-то приспосабливается - отгораживает себе уголок, меняет работу на ту, что дает больше свободного времени, начинает работать по ночам, забивает шум наушниками, и т.п. костыли.
    Кто-то кардинально меняет свою жизнь - переезжает в сьемные квартиры, выделяет себе комнату, изолирует ее или устанавливает в доме режим тишины, в общем создает себе полноценные комфортные условия для творчества. Это если удаленка - многие именно из-за невозможности работать дома, предпочитают офисы, или специальные кафе или клубы для работы.

    С первым все просто: не можешь что-то решить - отложи, и спустись на ступеньку ниже по шкале сложности.
    Есть такой психологический феномен: от решенных задач ты получаешь удовлетворение, силы и мотивацию двигаться вперед, от нерешенных - негатив, апатию, потерю воли и мотивации.
    Причем мозг устроен так, что запоминается лишь негатив. Поэтому крайне важно решать задачи, и не допускать незавершенных задач. Отложи, но не забрасывай.
    Нерешенная задача - это как психологический запой, нечто вроде депрессии: одна нерешенная задача тянет за собой другую нерешенную задачу, и так быстро уходишь на дно, теряя мотивацию и веру в себя. Замкнутый круг. Ты находишься именно в нем.

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • Как разместиться правильно на github?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    1. вместо /v1.0/ используйте теги гита
    2. test | tests | ... - обычно это каталог для авто тестов
    3. build | release | ... - это каталоги для собранных (релизных) файлов, тот же jquery.min.js например
    4. external | vendor | ... - каталоги с внешними зависимостями текущего проекта
    5. src | lib | ... - сам код проекта
    6. bin - каталог с исполняемыми файлами для проекта
    7. var | tmp | ... - каталог для временных файлов
    8. Makefile - настройка для консольной утилиты make
    9. bower.json - зависимости bower
    10. package.json - зависимости npm
    ...

    Видите ли, сейчас одно-файловые скрипты особо никто не пишет (не берем в расчет тривиальные на полторы строки).
    Ответ написан
    Комментировать
  • На каком языке пишут ААА игры?

    lexxpavlov
    @lexxpavlov
    Программист, преподаватель
    werw прав, но в последнее время всё чаще для AAA-игр используют UnrealEngine и Unity3d (помимо своих собственных разработок, почти наверняка на c++). Поэтому, чаще всего язык - c++ (UnrealEngine или свой фреймворк) или c# (Unity3d).

    UPD. Серверную часть игры часто делают на Java, но не-серверную часть про написание на Java я не слышал.
    Остальные языки (типа Erlang, например) могут использоваться, но гораздо-гораздо реже.
    Ответ написан
    4 комментария
  • Инстаграм написан на Python? Как так?

    fornit1917
    @fornit1917
    Инстаграмм это не только мобильное приложение. Это еще и серверное приложение с сайтом. Вот они то на питоне и написаны.
    Вот, если интересно, статья (правда уже старая) с описанием некоторых применяемых на сервере технологий и архитектурных решений https://www.insight-it.ru/highload/2012/arkhitektu...
    Ответ написан
    Комментировать
  • Какая есть хорошая книжка по Python?

    chewarer
    @chewarer
    Доусон. Книга недлинная, можно с первых глав что-то делать уже.
    А потом Лутца уже, заполняет пробелы после первой книги ))
    Ответ написан
    Комментировать
  • Какие вы знаете интересные сайты о Python?

    @1a9ran9e
    Ответ написан
    Комментировать
  • Какие вы знаете интересные сайты о Python?

    Vdomike
    @Vdomike
    Веб-разработчик
    Ответ написан
    Комментировать
  • Какие вы знаете интересные сайты о Python?

    tema_sun
    @tema_sun
    Ответ написан
    Комментировать
  • Какие вы знаете интересные сайты о Python?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    Ответ написан
    Комментировать
  • Какие вы знаете русскоязычные сайты для изучения программирования?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Только есть одно условие - сайт и курсы на нем должны быть на русском языке.


    HSLivcueqro.jpg

    Серьезно, без знаний английского, хотя бы на уровне чтения технической литературы (это на самом деле не сильно высокий уровень) вы очень быстро упретесь в потолок. При том что при нынешей ситуации с электронными словарями, переводчиками, онлайн курсами и т.д. выучить хотя бы немного язык займет не сильно много времени зато поможет вам в будущем.

    По программированию рекомендую книгу "структура и интерпретация компьютерных программ", она есть в хорошем переводе на русском, и по ней учат в MIT. Но для ученика школы может быть тяжелова-то. Потому лучше воспользоваться какими-то упрощенными штуками типа codeschool, а там уже нужен язык.
    Ответ написан
    9 комментариев
  • Что обозначает этот простой код?

    @abcd0x00
    Объяснение

    Когда делаешь
    class Application(Frame):
    то Application - это твой самодельный класс, который делается из существующего класса Frame.

    Это значит, что все объекты (экземпляры) класса Application будут двух типов одновременно - типа Application и типа Frame.

    Когда делаешь
    def __init__(self, master):
    это значит, что ты у класса Application делаешь метод __init__. При этом у класса Frame есть свой собственный метод __init__. Эти методы могут полностью различаться.

    Когда делаешь
    app = Application(root)
    ты создаёшь объект (экземпляр) класса Application. При этом ему в метод __init__ передаётся основное окно всей программы.

    app имеет сразу два типа - самодельный Application (который ты сам сделал) и существующий Frame (который уже сделали до тебя). По правилам tkinter'а, когда ты создаёшь какое-нибудь окно, его надо прилеплять к основному (так можно давать команды сразу всему дереву окон, в котором одни окна прилеплены к другим, и всё это прилеплено к основному окну).

    Так вот, чтобы было всё правильно, твой самодельный объект, который сделан из существущего оконного типа, нужно прилепить к основному окну. Но так как твой объект - самодельный и сам по себе окном не является, то внутри себя он должен обратиться к тому типу, который делает его окном, и передать ему основное окно программы, чтобы тот мог к нему прилепиться.

    Понимаешь, у тебя app - это один объект как бы двух типов: один тип не делает ничего, в нём есть только свой __init__ и ещё там какой-то самодельный метод; а другой тип является окном со всеми методами и свойствами окна.
    Поэтому, чтобы в своём самодельном типе что-то делать, ты обращается просто к его элементам. А чтобы в существующем типе что-то делать, ты к нему получаешь доступ через super() (от слова суперкласс), а потом обращаешься к своим же элементам но через методы другого типа.

    Поэтому запись
    super(Application, self).__init__(master)
    Означает, что нужно взять метод __init__ у базового класса Frame и передать в него аргумент master, переданный в __init__ производного класса Application.
    Функция super() как бы отыскивает базовый класс у класса Application и возвращает его, а дальше уже идёт обращение к методу __init__ этого найденного класса.
    Ответ написан
    Комментировать
  • Mono || Java || Python: оптимальный стэк технологий для нового проекта?

    @jackroll
    Сверхразум
    >опытных коллег
    здесь такие не водятся, ищите на stackoverflow.com
    Ответ написан
    3 комментария
  • Где можно попрактиковаться в php?

    @sergey_privacy
    Админ со стажем, начинающий DevOps
    Может быть я не прав и вас интересует программирование в качестве развлечения. Но основная масса программистов зарабатывает этим деньги. Поэтому зайдите на биржу фрилансеров, прочитайте первое попавшееся задание и попробуйте его сделать. Потом второе, третье. ДВИЖКИ ПИСАТЬ НЕ НАДО! Возьмите ModX и на нем реализуйте несколько заданий. Потом возьмите вордпресс и еще пару популярных и на каждом по 3-4 задачи сделайте.
    Ответ написан
    Комментировать
  • Чем отличаются языки программирования PHP, PYTHON, RUBY?

    1. Аналогию с самими языками проводить не стоит. Аналогию стоит провести для платформ.
    Платформы вроде .net и java, которые разрабатывались для энтерпрайза, разумеется лучше для него подходят. И не важно даже, десктопное у вас приложение или веб-сервис. Важно, что в платформе есть поддержка нужных стандартов и технологий с гарантией качества от производителя.
    С другой стороны, многие компоненты таких платформ это closed-source. Поэтому, если вы не банк, а стартап, то для веб-сервиса выбирайте
    Ruby или Python.
    Социальную сеть можно сделать много на чем, но я бы делал на рельсах или джанге. А вот функционал сбербанк-онлайн я бы делал на ASP.NET MVC (т.е. на C#) или на джаве (на спринге например). Однако, тот же близзовский battle.net написан на спринге (сервер когда-то случайно отдал мне stack-trace после ошибки).

    Хотя, имхо, некоторые ключевые элементы дизайна языка все-таки влияют на возможность его применения в крупных проектах. Например, я считаю, что писать крупные проекты на языке со статической типизацией намного проще. Однако это вопрос очень холиварный.

    2. Нет, не будет. Не должно быть, если точнее. Для пользователя язык общения с сервисом - HTTP. Если в современном веб-фреймворке нельзя нормально абстрагироваться от используемой технологии, это плохой фреймворк.

    3. На PHP много чего нельзя сделать. Вернее, КАК БЫ можно все, но нормально можно только веб. Именно поэтому для меня он не язык, а какой-то шаблонизатор - слишком у него дурная история и связь с веб (что нехорошо для языка общего назначения). Конечно, современные веб-фреймворки его очень хорошо причесывают, что даже можно работать с ним, но мы же о языках говорим..

    4. Для веб-проектов между Ruby, Python и PHP человек бы выбирал исходя из своих умений. У каждого языка своя экосистема (библиотеки, пакетные менеджеры, серверы приложений/плагины для веб-сервера) и довольно непросто знать все сразу. Именно поэтому все расходятся по своим лагерям и просто работают. Первичный выбор языка часто определяет его популярность. Лет 5 назад Руби всех рвал за счет Рельсов, сегодня Питон и PHP подтянулись в плане экосистемы, поэтому ситуация уже другая.
    Если человек таки сумел познакомиться с разными языками, он выберет тот, в котором ему проще мыслить. Модель ООП, статическая/динамическая типизация - все это определяет ощущения КОНКРЕТНОГО человека от КОНКРЕТНОГО языка.

    5. PHP учится быстрее всех, но если вы не знаете других нормальных языков, лучше его не учите - испортитесь как программист. Python и Ruby учатся примерно одинаково. Изучение C++ - совсем другая история, я бы не ставил его в один ряд с Питоном - этот язык несколько другого уровня и требует других (более глубоких) знаний о вычислительной технике (т.е. он 100% учится дольше, чем Python).
    Ответ написан
    22 комментария
  • Почему все хотят django?

    @dustyattic
    Всем хорош Django, все у него есть, но...
    Django - это коробочный продукт, со всеми достоинствами и недостатками, присущими коробочным продуктам. То есть внутри большой коробки, называемой Django, есть много других коробочек, содержимое которых прекрасно состыковано с самим продуктом и с другими коробочками. Поэтому разработчик на Django чувствует себя вольготно. А если у него возникает проблема, то большое комьюнити всегда поможет.
    Я разработал на Django только один проект. Возможно, будь проект простым, я до сих пор бы использовал Django. Но проект оказался неожиданно сложным. Написание кода для обработки данных из некоторого количества таблиц с довольно запутанными связями показало мне, что у Django, несмотря на его популярность, совершенно никудышный ORM. Используя Django, я половину обращений к таблицам реализовывал в чистом SQL, а затем стыковал результаты с данными полученными с помощью ORM. У меня все получилось. Но осадок остался. Поэтому следующую версию того же проекта, и все последующие тоже, я написал на Flask, используя в качестве ORM небезызвестный SQLAlchemy.
    Я не жалею времени, потраченного на изучение Django. Это хороший опыт. Те, кто используют Django, чувствуют себя защищенными. Они часть большого дружного сообщества, где можно найти любую поддержку.
    Но я также не жалею, что я ушел от Django. У Django вся магия ( регистрация, авторизация, работа с сессиями и многое-многое другое) спрятана под капотом, я просто подключал компоненты и использовал их. Используя Django, я делал многие вещи автоматически, совершенно не задаваясь вопросом как эти вещи работают. Уйдя от Django, я лучше стал понимать то, чем занимаюсь каждый день.
    Можете мне поверить на слово, на Flask-е возможно писать очень большие проекты, с большим количеством кода. При этом реализация всей магии ложится на Вас. Это просто вопрос доверия. Используя Django, Вы доверяете всю магию Django, не используя его, Вы доверяете всю магию себе.
    Ответ написан
    Комментировать