sergiko

на апворке с отзывами автоматом ничего не делается, его оставляют люди
если заказчик норм оставил норм и будет

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

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

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

Если клиент не хочет с тобой работать а хочет "об тебя" подумать / прикинуть / получить проектировку бесплатно - лучше об этом узнать заранее.

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

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

Продолжай, и не делай всем раскладки просто так. Успехов.

touch-reload

uwsgi, в общем-то, может сам перезапускаться при изменении кода, но это недопустимо на продакшене, да и вообще занимает слишком много ЦП.

Выигрыша по производительности действительно нет, т.к. CBV превращаются в обычную вьюху.
Выигрыш по скорости разработки есть, т.к. в generic описано достаточно много типовых вьюх (ListView, DetailView, FormView). Код в CBV более структурирован, особенно, если вьюха принимает сразу несколько методов (POST, GET, ...). Количество кода также сокращается за счёт использования самих CBV и миксинов.

Добрый день, Дмитрий.

1. В такой последовательности:
Python
a) Майкл Доусон - рус ... eng
b) Марк Лутц - рус ... eng
c) Дэвид Бизли + Лучано Рамальо
Дальше - самостоятельный выбор, исходя из личных потребностей.
Django
a) Джейкоб-Каплан Мосс и Адриан Головатый - рус ... eng
b) Django Girls Tutorial
c) Гринфилды + Равиндран

Параллельно читаем Django documentation

2. HTML5 + CSS3 + JS + SQL.
Знать на уровне, достаточном для реализации собственного проекта с нуля (скажем, свой сайт). Для этого, правда, достаточно HTML и CSS, в объеме указанных книг. Другой вопрос, что и JS, и SQL практически всегда требуются в багаже знаний при устройстве на работу (достаточно посмотреть вакансии).

3. Нет, просто нету смысла. Актуальной качественной литературы по Python хватает. Есть некоторые исключения (некоторые из них мною упомянуты), но в целом, повторюсь, с современной литературой у Python все в полном порядке. Ищите на Amazon, сортируя по дате выхода.

>И поэтому меня мучает вопрос - является ли схема с user agreement и инвойсами (хз что это) чисто белой или это полусерая схема, лишь бы хоть как-то обелить доходы перед налоговой?

Налоговая как не интересовалась Вами пока Вы не платили налоги, так и не будет интересоваться, когда платить начнете. Особенно с 2016 по 2018 - пока действуют надзорные каникулы. Заинтересуется только когда будете закрывать ИП (если будете), и то, если последние три года вашей деятельности не будут состоять из нулевых деклараций.

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

Реальные проблемы у Вас будут (точнее могут быть) с валютным контролем банка с которым будете работать. У основной массы банков ориентированных на предпринимателей схема работы с Upwork отлажена. У модульбанка логотип Upwork - вообще на странице валютного контроля https://ext.modulbank.ru/?cityid=f27b4452-0f6f-e41...

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

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

Лучшие консультации Вам дадут сотрудники валютного контроля того же модульбанка или банка Точка. Чистота сделки в глазах контролирующих органов - одна из услуг которую они предоставляют.

Если не готовы вручить свою судьбу валютному контролю банка, соберите в гугле ссылки на статьи по теме легализация oDesk|Upwork и перечитывайте по одной ссылке в день или неделю. То что раньше казалось спорным или китайской грамотой, через несколько недель или месяцев станет простым и очевидным.

На эту тему на хабре есть:
https://habrahabr.ru/company/mlclass/blog/252743/
https://habrahabr.ru/company/spbifmo/blog/276479/
https://habrahabr.ru/post/270449/

Буквально неделю назад на Coursera стартовал https://www.coursera.org/learn/mathematics-and-python - посмотрите лекции, возможно станет понятнее какие из разделов математики стоит подтянуть, т.к. в самом курсе информация по ним довольно сжатая.

1) берем Dependency Walker, смотрим зависимости экзешника;
2) обращаем внимание на зависимости, которые резолвятся из системных директорий. Среди них нужно выбрать те, которые не являются обязательной частью системы (сложно перечислить конкретные, скриншот окна DepWalk не помешает);
3) могу на 90% сказать, что это будет Студийный рантайм (msvcr*.dll/msvcp*.dll).
4) удовлетворяем эти несистемные зависимости. Если райнтам - то желательно его нормально поставить (из redist-пакета), если не вариант - то можно просто положить dll рядом с exe.

Даже если закрыть глаза на оформление кода, постоянное дублирование, то это всё равно очень странный код с неопределённым поведением. И вот почему:

try:
    categories = Categories.objects.get(name=line[0])    # Метка 1
      img_url = line[1]   # Метка 2
      content = urllib.request.urlopen(img_url).read()        # Метка 3
      Item(categories=categories, img=content, name=line[2], text=line[3], options=line[4]).save()
    except:
      categories = Categories(name=line[0])    # Метка 4
      img_url = line[1]
      content = urllib.request.urlopen(img_url).read()
      Item(categories=categories, img=content, name=line[2], text=line[3], options=line[4]).save()    # Метка 5

Первым делом хочу обратить внимание на строку с комментарием "Метка 4". Вы, насколько я понял, хотите создать модель Categories, если её не нашлось в строке "Метка 1". Создать-то Вы её создали, но не сохранили! В базе такого объекта нет. Поэтому при вызове сохранения Item (см. "Метка 5") Вы можете схватить ошибку.

А можете не схватить, потому что возможна другая ситуация, когда категория (см. "Метка 1") нашлась, но картинка для скачивания определилась неправильно, и скачивание сломалось. Или просто сеть недоступна. В этом случае вывалится urllib, а категория будет определена правильно.

Далее: очень непонятный момент про img=content. Насколько я понял, Вы прямо берёте саму картинку (набор байт) и пишете его в БД? Если да, то это в корне неверно, ImageField работает по-другому. Во-первых, в базе данных это обычный varying charfield. Во-вторых, он хранит не сам контент картинки, а имя файла, под которым файл был сохранён при аплоаде. Сам файл хранится в другом месте (по умолчанию — в файловой системе рядышком в директории, указанной в настройке MEDIA_ROOT) Например, если в таком поле записано значение 'path/to/my/photo.jpg', то это значит, что при обращении model_name.img.url (обратите внимание, что мы обращаемся к атрибуту url поля img модели model_name) будет возвращено что-то типа /media/path/to/my/photo.jpg, где /media/ — корень хранилища загружаемых файлов (по умолчанию задаётся в настройке MEDIA_URL и имеет значение "/media/").

Советую переписать код.

• Во-первых, при оформлении настоятельно советую поддерживаться PEP8.
• Во-вторых, как уже рекомендовали выше, использовать requests.
• В-третьих, использовать шорткаты, которые предоставляются Джангой. В данном случае я говорю про функцию render вместо пары HttpResponse(render_to_string) и метод get_or_create() у менеджера модели.
• Избавиться от дублирования кода
• Не использовать жадные except'ы. Ловить следует только те исключения, которые могут возникнуть штатно в процессе работы.

С учётом вышеизложенного, Ваш код может выглядеть как-то так:

from django.shortcuts import render
import requests
import requests.exceptions as rex

def baza(request):
    # В этом месте мы скачали страничку по адресу BAZA_URL/
    try:
        page = requests.get("BAZA_URL")
        page.raise_for_status()

    # Попутно обработали ситуацию, если страница по каким-то причинам
    # недоступна (например, её переместили, сервер ушёл в даун или просто
    # сеть недоступна). Все остальные возможные ошибки мы в этом месте
    # не обрабатываем.

    except (rex.ConnectionError, rex.HTTPError) as ex:
        return HttpResponse("Unable to open BAZA_URL")

    baza = page.content.split('<br>')

    for line in page:
        # Здесь мы просто ввели локальные переменные для упрощения
        # кода. Согласитесь, когда в поле модели name нужно подставить
        # имя, то проще написать переменную name, чем высчитывать, какой
        # же это по счёту элемент массива :)
        #
        # К тому же, если вдруг формат данных изменится, код придётся
        # править только в одном месте. так что мы заодно избавились от
        # дублирования.
        cat_name, img_url, name, text, options = line.split('--')[:4]

        # Воспользовались шорткатом от Джанги. Модель будет взята из базы,
        # если на существует с таким именем. Если нет, то будет создана.
        # Тоже избавление от дублирования
        categories, created = Categories.objects.get_or_create(name=cat_name)

        # Создание модели Item с помощью метода create у менеджера. Сразу
        # же мы решаем здесь возможную проблему с сетью. Если какой-то файл
        # окажется недоступным, мы его не будем сохранять, а перейдём к
        # следующему

        try:
            pic = requests.get(img_url)
            pic.raise_for_status()

            Item.objects.create(categories=categories,
                                img=ContentFile(pic.content),
                                name=name,
                                text=text,
                                options=options)
        except (rex.ConnectionError, rex.HTTPError) as ex:
            # Пришлось немного продублировать код, потому что здесь
            # возможны те же ошибки, что и в самом начале вьюхи.
            continue

Некоторые вещи я намеренно опустим (например то, что для всех HTTP-запросов с помощью requests можно использовать одно соединение, не создавая новое для каждого запроса)

И ещё один совет: операции, которые выполняются длительное время и которые могут свалиться по независящим от Вас причинам, лучше не делать в цикле запроса-ответа, а вынести в фоновую обработку. Например, воспользоваться celery

Все просто при нажатии на кнопку купить, вам следует отправлять в сессию корзины id-ик картины, когда переходите к оформлению заказа просто делаете запрос к базе с выводом необходимой вам инфы по id-ам которые у вас есть в сессии.
<a href="#" data-id="1">Название картины</a>
Вьюха корзины

def cart(request,id):
    if 'cart' not in request.session:
        request.session['cart'] = list()
    request.session['cart'].append(int(id))
    ....
    return ...

Ну и вьюха оформления

def checkout(request):
    cart = Images.objects.filter(pk__in=request.session['cart'])
    ....

Как то так

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

В первую очередь нужно выбрать средство обработки и хранения.
В случае с Java это HBase Cassandra
HBase - когда пишется в базу очень много, и большинство индексов "самодельные".
Cassandra - когда соотношение чтения / записи 4:3, так как в Cassandra уже есть средства колоночной индексации.

В случае с реальным высоконагрузом это ScyllaDB - обладает теми же особенностями что и HBase, но С++11 и Share-nothing approach и от того в 6-7 раз шустрее.

Для БД до 200Гб хватит банального MySQL'я c R-tree индексом и Engine Archive.
Вот PostgreSQL при правильной настройке спокойно строит B-tree индексы для объёмов данных в 500-700Гб, что для MySQL'я непосильная задача Ну и в PostgreSQL часто приходится дописывать сишные функции агрегации и строить по ним разнообразные индексы, иногда пространственные (gin/gist).

Вот небольшой обзор разных типов индексов.

От себя ещё добавлю MVP-tree для поиска похожих персептивных хэшей и Fusion-tree как более съедобный вариант дерева Ван Емде Боаса.

По поводу хипстер-культа вокруг MongoDB - скажу что PostgreSQL с индексами на хэш-таблицах и небольшими множествами документов в 1.5-3 раза шустрее, потому что "Building Index with Vodka". А нормальная репликация и партицирование напрямую зависит от принципов решения задачи Консенсуса в каждом конкретном приложении, и без понимания работы Raft / Paxos не стоит надеятся на чудеса той же MongoDB или PostgreSQL, они являются не более чем инструментами для решения этой задачи.

MongoDB очень даже ничего для реактивных проектов на основе Meteor, а для всего остального уже GoldenHammer™.

По индексации, надо обязательно-обязательно прочитать книги Ханны Самет
Foundations of Multidimensional and Metric Data St... = Applications of Spatial Data Structures: Computer ... + The Design and Analysis of Spatial Data Structures

В принципе книжки Foundations of Multidimensional and Metric Structures должно хватить с головой, но можно "дочитывать" более полное описание в более древних работах. Одним словом тётка "жжёт", и я не знаю почему это до сих пор никто не перевёл.

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

По машинному обучению можно пройти курс Эндрю Ына на курсере.

Есть Южный DataScience-централ, там есть много чего полезного. Его можно почитывать. Есть ещё поверхностные CheetSheet'ы, видел и получше, но не нашёл.

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

Если лезть в Java, то на примере Spotify чаще всего используются связки
Apache Kafka -> Apache HBase -> Apache Storm -> Apache Spark (mllib) -> Apache HBase -> Apache Phoenix -> Hibernate + любой MVC фреймворк и т.п.

Естественно об относительно высокой производительности и хорошем вертикальном масштабировании речи не идёт, если брать C++11 ScyllaDB -> Neon хорошо отпрофилировать и допилить, можно получить в 3-5 раз выше производительность и соответственно гораздо меньшие задержки, но обычно всем влом. REST API под такое обычно пытаются писать на сях (без плюсов) в виде расширений под Nginx, что является довольно породистым извратом - в большинстве случаев банального golang/netty будет достаточно.

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

По поводу HA и Zookeeper можно увидеть много срача, особенно в Netflix'e, по этому для менеджмента высокой доступности лучше использовать именно их решения - eureka или для отказоустойчивости Hystrix. Хотя я не могу сказать что это достаточно зрелые проекты - в них тоже хватает изъянов, но они на много шустрее остальных Apache поделок.

Нельзя делать одновременно отказоустойчивые и высокодоступные приложения - потому что CAP теорема имеет место быть.

Ещё есть очень тонкий момент с Java в целом - нужно минимизировать время сборки мусора и лезть в offheap, стоит глянуть как реализованы буферы в netty - это arena аллокатор по типу того что используется jemalloc и различная misc.unsafe ересь. Можно ещё пробовать Hazelcast / Terracotta, но принципиально там тоже самое, только платно и "расспределённо".

Для REST API я чаще всего использую Vert.x и ванильную Java.
Overhead от Scala довольно таки большой, а время компиляции просто вырвиглазное.
Для минимизации копи-пасты вполне безопасно использовать Groovy c @ Immutable и @ CompileStatic.
Но в Vert.x'e он весь "динамичный" :|

Я ничего не могу сказать по поводу производительности Clojure, он местами через чур invokeDynamic. Естественно что ванильная Java будет шустрее, но я без понятия на сколько.

Желаю Вам приятного вечера.

p.s. не везде проставил ссылки просто потому что хочу спать.