Алексей Сергеев

Будем честны друг с другом, не каждый опытный программер может реально зарабатывать фрилансом.
На питоне заказов мало. В России фриланс это в 30% кидалово, в 50% мозгоебство на уровне профи.
Тебе это надо? Чтобы за половину от реальной зарплаты джуна тебе все мозги выносили?

Будь я сейчас в школе я бы занялся тремя вещами:
1. Спорт
2. Девушки
3. Подготовка в нормальный вуз(берлинский технический например).

От того что ты будешь зарабатывать 10 - 20 тысяч в твоей жизни ничего не изменится. Я думал что закончу универ, буду получать зп 20 и всё будет в шоколаде. Я получаю сейчас примерно в 2 раза больше моих хотелок. За год устал пропивать их, уже купил все ништяки что хотел. На что-то большее не хватит, квартиру и авто купить хорошую нужно или годами так же сидеть и себя ущемлять, либо получать зп в разы больше.

В итоге отрывайся и учись, забудь о работе. Я тоже так думал в 15, сайты клепал, языки учил. Толку вышло конечно больше чем у окружающих, но вот в 25 нихера себя счастливым и обеспеченным не чувствую. От того насколько много ты получаешь или какие ты купил ништяки, счастье надолго не прибавляется.

Сорян если огорчаю.

Но программирование и электроника это реально профессии будущего, которые даже в РФ будут нормально получать.

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

Я вот в школе когда был напросился ходить в универ на интересные лекции . Учился потихоньку, сверстники смотрели как на сумашедшего=))))

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

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

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Разницы нет, смотрите портфолио дизайнеров, выбирайте то, что вам нравится, читайте отзывы.
Я бы разместил на нескольких.

https://channels.readthedocs.io/en/stable/

Как минимум два способа решения. Один - прописать нужный статус в url, другой - передавать как GET параметр.

В первом случае будет так:

# в urls.py
# ...
url('^mypage/(?P<status_num>[1-3])$', ClientListView.as_view()),
# ...
# в views.py

class ClientListView(ClientTemplateListView):

  def get_queryset(self,):
    self.client = Client.objects.filter(status=self.kwargs['status_num'])
    return self.client

Соответственно, если передавать GET параметров по ссылке вида /mypage?status_num=2

class ClientListView(ClientTemplateListView):

  def get_queryset(self,):
    self.client = Client.objects.filter(status=self.request.GET.get('status_num'))
    return self.client

В примере нет валидации для GET-параметра, потому что это уже другой вопрос.

1. Ты не сказал, какая задача.
2. Побуду Вангой сегодня:

a)

student_struct = {}
summ = 0

Думаю, это стоит внести в цикл.
b) Есть функция sum, которая считает сумму iterable объекта. Причём, намного быстрее, чем реализация на питоне. Подозреваю, что код

summ = 0
for individual_mark in all_marks:
        summ += individual_mark

Можно заменить одной строчкой sum(all_marks)
c) all_marks = student['marks']
Это дублирование непонятно для чего вообще. Можно убрать вовсе.
d)

student_struct = {}
student_struct['name'] = individual_name
student_struct['average'] = summ

Это тоже сокращается в

student_struct = {
    'name': student['Name'],
    'average': sum(student['marks'])
}

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

students_data = [
    {'name': 'Vasya', 'marks': [4, 5, 4, 5, 5]},
    {'name': 'Petya', 'marks': [3, 5, 3, 4, 2, 2]},
    {'name': 'Ivan', 'marks': [4, 5, 4, 4, 4, 4]},
    {'name': 'Dima', 'marks': [4, 5, 4, 3, 3, 3]},
]

average_data = [{'name': student['name'], 'average': sum(student['marks'])} for student in students_data]

P.S. Непонятно, почему сумма называется average.

Нашел для себя оптимальное решение по админке - это подрубать Wagtail CMS - все в коробке. Настройки стандартные. Единственное, что хороших примеров мало. В целом достойная замена для django админки.

Как вариант - перекодируйте в base64, и вставляйте прямо в тело письма:

import base64
...
my_image = '<img src="data:image/jpg;base64,{im}" />'.format(im=base64.b64encode(instance.image.read()))
...
mail_html = """
        <html>
            <head></head>
            <body>
                <h4>Заголовок письма</h4>
                {img}
                ....
            </body>
        </html>
        """.format(img=my_image)

Далее кодируете текст письма в MIME и отправляете.

Как уже было указано выше, - на той стороне график, который вы рендерите с помощью javascript, не увидят, потому что javascript отключен.
Поэтому генерируйте картинку в png или jpeg, - в сети есть примеры как это сделать на phantomjs, и отсылайте в качестве аттачей.

1) сохраняете в файл (jpeg или, понтовее, pdf, или xls но хз как с корректностью диаграммы получится)

2) отправляете attachments

https://docs.djangoproject.com/en/1.9/howto/output...

x-editable-columns

Схематически, можно сделать так

var obj = {
    2: {
        5: 15,
        11: 220,
        30: 70
    },
    3: {
        1: 65,
        4: 30,
        30: 5
    }
};

function daysInMonth(month, year) {
    return (new Date(year, month, 0)).getDate();
}
var months = Object.keys(obj),
	tbl = '<table>',
    lineTop = '',
    lineBot = '';

for(var i = 0; i < months.length; i++) {
    lineTop = '<tr>';
    lineBot = '<tr>';
	for(var d = 1; d <= daysInMonth(months[i], 2016); d++) {
    	lineTop += '<th>' + d + '</th>';
        if(obj[months[i]].hasOwnProperty(d)) {
        	lineBot += '<td class="has-val">' + obj[months[i]][d] + '</td>';
        } else {
        	lineBot += '<td></td>';
        }
    }
    lineTop += '</tr>';
    lineBot += '</tr>';
    tbl += lineTop + lineBot;
}
tbl += '</table>';
document.body.innerHTML = tbl;