German Jet

Вакансий в разы меньше. Но нужно понимать, что компании, кто пишет на java/.net cтабильней в силу объема, плюс задачи достаточно последовательные. Так что 5-10 вакансий на .net могут перекрывать, 40-50 вакансий на php/python/ruby.

Так что если возьмешь место, можно там 3-5 лет стабильно работать.

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

С точки зрения программиста: есть целый ряд принципиальных различий:
1) УТ10 - это экранные формы, которые рисуются по аналогии с Visual Studio, т.е. на полотне экранной формы набрасываются в нужных местах укравляющие элементы и прописываются их обработчики событий; такие формы доступны только в режиме "толстого клиента". УТ11 - это управляемые формы, которые создаются по аналогии с DIV-версткой веб-страниц, т.е. основа любой формы это десятки групп, которые вложены друг в друга с указанием порядка группировок подчиненных элементов, размер и вид которых генерируется автоматически (можно влиять но не так абсолютно, как было в УТ10); такие формы доступны не только в версии для ПК, но и через браузер при наличии публикации базы на веб-сервере.
2) Сильно изменилась система прав. В УТ10 - были роли-должности (продавец, кладовщик и так далее), а в УТ11 - море ролей-функций (право на чтение контактной информации, право на формирование отчетов и так далее) из которых тонко настраивается справочник профилей доступа и уже по назначению такого профиля элементу справочника пользователи у самого пользователя назначаются нужные роли.
3) Изменилась стратегия проведения. В УТ10 обычно сначала делались проверки доступности остатков, а потом проводки (при чем некоторые проводки могли порождать в глубине общих модулей другие движения, о которых программист не задумывался - к примеру, так себя вели проводки по партиям), и при этом в каждом документе был свой "путь", а в УТ11 в каждом документе все причесали под единую гребенку и сначала делались проводки, а потом контроль "не ушли ли в минус".
4) С точки зрения отчетов. В УТ10 множество отчетов на базе универсального отчета (который создан на основе объекта построитель отчета), а в УТ11 все отчеты на базе компоновки данных.
5) Значения по умолчанию. В УТ10 были настройки пользователя, которые мог себе настроить пользователь или админ, и из которого значения по умолчанию можно было подставлять на формы новых документов, отчетов и обработок. В УТ11 от этой системы отказались и перешли к использованию статистики - т.е. если продавец чаще выписывает документы с основного склада, то именно этот склад через некоторое время начнет подставляться, но сначала нужно все указывать вручную; а часть параметров нужно вообще всегда вносить вручную (по этому поводу очень много возмущений на форумах).
6) Интерфейс. В УТ10 - было несколько вариантов интерфейса, которые создавались в конфигураторе для определенных групп пользователей. В УТ11 есть единый для всех интерфейс, в котором недоступные по правам доступа элементы просто скрыты.

Это из крупного что я вспомнил. О том, что в УТ11 есть встроенное БСП (такое себе "государство в государстве" со своими законами) я вообще уже молчу.

Естественно, что еще есть других отличий вагон и маленькая тележка. Что бы неплохо разбираться в обоих системах УТ10 и УТ11 нужно достать вопросы на профессионала и прорешать их. А еще лучше сходить на курсы.

Я бы сделал так:

models.py

class PageHit(models.Model):
    url = models.CharField(unique=True)
    count = models.PositiveIntegerField(default=0)

decorators.py

from functools import wraps
from django.db.models import F
from django.db import transaction

def counted(f):
    @wraps(f)
    def decorator(request, *args, **kwargs):
        with transaction.atomic():
            counter, created = PageHit.objects.get_or_create(url=request.path)
            counter.count = F('count') + 1
            counter.save()
        return f(request, *args, **kwargs)
    return decorator

views.py

from .decorators import counted

@counted
def some_view(request):
    ...

Репозиторий демонстрационного проекта.

Или можно написать middleware, который будет делать то же самое для всех запросов.

public function create()
    {
        if (!$this->validate()) {
            return null;
        }
        $news = new News();
        $news->create_at = $this->create_at;
        $news->status = 'archive';
        var_dump($news);die;
        return $news->save() ? $news : null;
    }

>>> в форме var_dump($news) - так же нет id.
конечно нету, т.к. оно еще не сохранено. уберите вардамп из формы и поменяйте экшен на

public function actionCreate(){
        $model = new NewsForm();
        $model->create_at = (new DateTime())->format('Y-m-d H:i:s');
        $model->update_at = (new DateTime())->format('Y-m-d H:i:s');
        if ($news = $model->create()) {
           echo 'УРА! Запись' .  $news->id . 'была успешно добавлена';
        }
    }

если не выведет id - будем дальше ковырять

Вам больше не нужно использовать django, чтобы рендерить html-ки. Этим будет заниматься react. Вам нужен API сервер, и я так понимаю, подойдет что-нибудь такое (ну или гугл).

Если можете написать API, то значит нет смысла искать видео-уроки/просто уроки по комбинации Ddjango + React, и вам нужно лишь подтянуть знания по react/redux/react-router или подобной связке.

Если даже в теории ваша задача не разбивается на 2 части (написание API и написание одностраничного приложения), значит django и react.js в данный момент вам никак не соединить.

p.s. если есть уже существующий сайт, где используется шаблонизатор от django и рендерятся страницы, то можно взять любую из них, где много динамики (например, удаление и добавление строк в таблице, какие-то xhr запросы и т.д.) и переписать для начала только ее на react.

Мне лично удавалось устроиться за пару недель. Но при этом недостаток вакансий для джуниров есть, да.

Что я делал? Откликался на вакансии для миддлов и даже сеньёров, в некоторые писал, что на самом деле я джуниор, но готов развиваться. И это работает. Я сейчас уже почти 2 месяца на новой работе и мне до сих пор приходят письма от хедхантера о том, что вакансия на которую я откликался больше не актуальна. При том, что на некоторые отклики мне сразу отвечали отказом, большинство просто игнорировало. Ещё несколько компаний проводили со мной собеседования и готовы были дать ответ спустя неделю / две. Кто-то перезванивал, кто-то нет. Зато была пара компаний, которые хотели чтобы я вышел на работу как можно скорее, при том, что это было прямо перед новогодними праздниками. В итоге одна из компаний мне особенно понравилась и я вышел на работу уже на следующую неделю после собеседования. Так что ищите и обрящете.

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

REST можно применить, почти, где угодно. Главное понимать, а зачем? Сейчас вы пытаетесь получить навык не зная, а нужен ли он в том или ином месте? Изучите сначала сферы применения. Какие плюсы от его использования и какие минусы. Не зная ответов на "Зачем?" и "Почему?" про REST нет смысла думать над вопросами "Можно ли применить REST для объекта X?"

GET /v1/books/ - показать все книги
GET /v1/books/1 - показать книгу с ID равным 1
DELETE /v1/books/ - удалить все книги - такое только с соотв.привелегиями
DELETE /v1/books/1 - удалить книгу с ID равным 1
POST /v1/books/ - Добавить новую книгу
PUT /v1/books/1 - Обновить существующую книгу с ID равным ID

При этом:
1. То что выдается для одного элемента GET /v1/books/ должно быть точно таким же как и для GET /v1/books/1.
2. Не давайте хакеру понять причину ошибки, лучше сразу HTTP 404. В клиентском коде, редко когда нужно знать реальную причину ошибки
3. Указывайте версию API.
4. С HTTP-методами PATCH, HEAD не заморачивайтесь. Они редко кому нужны

Можете посмотреть на : https://apigee.com/console/instagram там будет видно что и как можно начудить

Зависит исключительно от работодателя.
У него и нужно узнавать, такие вещи в должностной инструкции прописываются и в приложении к трудовому договору.
Кому-то нужен именно программист - просто писать код на языке 1с и ничего более.
Кому-то нужно чтобы кроме написания кода человек разбирался в предмете - торговля, бухучет, бизнес-процессы, особенности работы птицефабрики, и.т.д.
Кому-то нужно чтобы кроме написания кода этот человек еще и пользователей консультировал.
Зачастую на 1с программиста возлагают полностью все что касается 1с - администрирование сервера 1c и SQL, настройка, установка, обновления.
Некоторым возможно нужно будет компьютеры починять и принтеры заправлять заодно.
Кое-где могут и двор подметать заставить, по совместительству.

В общем кого найдете, и как договоритесь.

Сперва вырезаешь все ненужное из сообщения, потом фильтром добавляешь нужные тебе теги.

Вот пример как работать с текстом с помощью фильтров:

from django import template
from django.utils.html import conditional_escape
from django.utils.safestring import mark_safe

register = template.Library()

@register.filter(needs_autoescape=True)
def initial_letter_filter(text, autoescape=True):
    first, other = text[0], text[1:]
    if autoescape:
        esc = conditional_escape
    else:
        esc = lambda x: x
    result = '<strong>%s</strong>%s' % (esc(first), esc(other))
    return mark_safe(result)

Подробнее про фильтры: djbook.ru/rel1.9/howto/custom-template-tags.html

В общем дошел до дома, подробнее напишу. Если у тебя определено поле для юзера в модели, то ты его можешь вообще вручную выбрать, а если лень это делать то можно так.
Допустим у тебя есть приложение для публикации статей "articles", в articles/models.py есть модель статьи, в которой есть поле с пользователем который ее добавил, можно добавить еще одно поле для пользователя который ее последний раз редактировал, а можно и не добавлять если нужен только пользователь добавивший статью:

# остальные импорты опущены 
from django.conf import settings


class Article(models.Model):
    ...
    added_by = models.ForeignKey(settings.AUTH_USER_MODEL, blank=True, null=True,
                                 related_name="articles_added")
    last_edited_by = models.ForeignKey(settings.AUTH_USER_MODEL, blank=True, null=True,
                                       related_name="articles_edited")
    ...

Так как два поля ссылаются на одну модель, нужно определить для них related_name чтобы потом с помощью него можно было работать с ORM, типо чтобы получить все статьи добавленные пользователем:
*объект_нужного_пользователя*.articles_added.all()

Потом в файле articles/admin.py определяешь новую модель для "администратирования" этого объекта:

from django.contrib import admin 
from .models import Article


class ArticleAdmin(admin.ModelAdmin):
    readonly_fields = ("last_edited_by",) # делаем полем рид онли, чтобы нельзя было его отредактировать

    def save_model(self, request, obj, form, change):
        if change: # True если изменяется уже существующий объект, False если добавляется новый
            # определяем и записываем пользователя если изменяется существующий объект
            obj.last_edited_by = request.user 
        else:
            # определяем и записываем пользователя если добавляется новый объект
            obj.added_by = request.user 
        super(ArticleAdmin, self).save_model(request, obj, form, change)


admin.site.register(Article, ArticleAdmin)

Все, пробуй. Если не нужен юзер редактировавший статью, то, надеюсь, разберешься что удалить надо?

Подробнее о save_model():
https://docs.djangoproject.com/en/1.10/ref/contrib...
Подробнее о request:
https://docs.djangoproject.com/en/1.10/ref/request...