Bjornie

Пгдамп , хранить вне дигитал ошена

Ответ тут --> https://stackoverflow.com/questions/39457549/herok...

Но перед тем, как прописать эту команду нужно:

1. Установить heroku CLI в терминале https://devcenter.heroku.com/articles/getting-star...
   
2. Зайти в свой учетную запись: heroku login
   
3. Склонировать свой приложение:

   git clone https://github.com/heroku/name_your_app.git

   https://devcenter.heroku.com/articles/getting-star...
   Посмотреть ветку git можно на сайте в личном кабинете:

   Personal-->name_your_app-->Settings-->Info-->Heroku Git URL

   
   
4. Зайти в склонированную папку: cd name_your_app
   
5. Выполнить команду

   heroku run python manage.py dumpdata --natural-foreign -- > data.json

   
   

Json файл сохранится в корне папки.

Предпринимательский подход к разработке и программированию

Для начала отделить мух от котлет.

Предприниматель - специалист по зарабатыванию денег.
Программист - специалист, который пишет программы по заданию.

Когда программист работает в организации все просто - дали задание, пиши код, тебе скажут с чем нужно работать, что прокачивать.

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

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

Со своей колокольни посоветую.
В первую очередь - протокол http - основные заголовки, методы передачи данных на сервер, как кодируются формы.
Основные принципы работы веб-сервера, принципы переписывания урлов.
Основые sql и серверных языков, принципы формирования страничек.
Глянуть простенькие туториалы по основным фреймворкам для разных языков.
Почитать что такое ORM и глянуть основные для популярных языков.
Вот как-то так.

Пример решения с использованием стандартной библиотеки difflib:

from difflib import get_close_matches as gcm

model = 'A 170 Classic - 7/2004 - 85Kw'.upper()
model_list = map(str.upper, [
    'A 170 CDI CAT ELEGANCE',
    'A 170 CDI CAT CLASSIC',
    'A 170 CDI CAT AVANTGARDE',
])

result = gcm(model, model_list, n=1, cutoff=0.5)[0]

print(result)  # => 'A 170 CDI CAT CLASSIC'

Также посмотрите в сторону difflib.SequenceMatcher().ratio(), это имеет прямое отношение к cutoff в примере выше:

from difflib import SequenceMatcher as SM

s1 = 'A 170 Classic - 7/2004 - 85Kw'.upper()
s2 = 'A 170 CDI CAT CLASSIC'.upper()

SM(isjunk=None, a=s1, b=s2, autojunk=True).ratio()  # => 0.52

Теория: Расстояние Левенштейна

Два аспекта вашего вопроса:
1. Можно ли писать программу для iOS под Линуксом?
Конечно, можно. Это же просто текст, его можно писать где угодно.
2. Можно ли полный цикл создания приложения для iOS пройти без Мака хоть с какими-никакими удобствами?
Да щас, дождешься от Apple интереса к твоим проблемам...
Марш в магазин за макбуком, айпадом и аккаунтом разработчика! И не рассуждать!

>>> from collections import Iterable
>>> def flatten(items):
	      for x in items:
		        if isinstance(x, Iterable):
			            yield from flatten(x)
		        else:
			            yield x

>>> a = [1, 2, 3, [4, 5, 6], 7, 8]
>>> list(flatten(a))
[1, 2, 3, 4, 5, 6, 7, 8]

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

https://docs.python.org/3/library/functions.html#g...

И тогда:

def validator_team(self, field, member='something', name='surname'):
    if field:
            for i in getattr(field, member).all():
                p = getattr(i, name)
                do_something(p)
            ...
    return field

Но вообще это говнокод)

У Амазона много специфики в парсинге.
Обычно я не меняю UA, исплоьзую только IP rotation. Однако, если хочется, можно использовать готовые middleware, например эту https://github.com/alecxe/scrapy-fake-useragent.
Если хотите вручную менять UA при создании Request, просто прописывайте UA в header.
По поводу плохих ответов, есть два варианта.
1) Амазон будет отдавать вам каптчу, можно её распозновать при помощи индусов, например anti-captcha.com или можно написать или использовать готовую OCR. (у меня есть примерно с 30% шансом распознования)
2) Амазон будет отдавать вам 503, когда ваш IP окончательно ему надоест.
По поводу сохранения прогресса с asin. Я брал список asin из MySQL и записывал данные обратно туда-же, меняя статус, если всё ок.

Никогда не разрабатывайте в master бранче! Всегда делайте отдельную ветку git checkout -b new_branch_baby

Чтобы сейчас выйти из этой неловкой ситуации вам нужно:
- Скопировать все изменения в отдельный бранч ( git checkout -b my_changes )
- Почистить мастер от своих изменений ( git checkout master ; git rebase -i HEAD~6 )
- обновить мастер бранч ( git pull origin master )
- обновить свой бранч (git checkout my_changes ; git rebase master )

удачи