Leidseplein

Сначала нужно расписать функционал приложения по пунктам: составить список тех функций, которые будут у приложения. Далеко в будущее заходить не надо, так как планы могут поменяться.
Потом взять те пункты, без которых приложение не состоится, самые минимальные и базовые вещи, и сделать их. Например, для магазина это: витрина товаров, возможность заказать товар, указав адрес доставки. Корзина и регистрация на этом этапе не обязательны, так как магазин может работать и без них. А без витрины и возможности заказать товар не может. После реализации этих базовых функций уже можно накручивать функционал дальше.
Суть в том, что на каждом этапе у тебя должно быть законченное, рабочее приложение. Разница между этапами — степень проработки деталей функционала приложения. Это метод прогрессивного джипега :) Или agile.
Чтобы понять, с чего начать, нужно посмотреть на приложение глазами пользователя: пользователь заходит на сайт, видит витрину товаров, видит описание у товара, цену, другие параметры, кнопку купить и т. д. То есть нужно реализовывать сценарии поведения пользователя. Можно даже acceptance-тесты накатать — помогает собрать мысли.

Может кто наталкивался на хорошие статьи на тему, что бы ссылку дизайнеру кинуть или тыкнуть заказчика мордой в теорию.

В последнее время сам себя тыкаю в замечательную статью - UX/UI Best Practices: 125 Easy Tweaks to Optimize .... Там обо всем простыми словами и с примерами.

Прошло много лет, я прокачал скиллы и знаю что ответа на этот вопрос нет. Всем спасибо)

И. М. Виноградов. Основы теории чисел. стр. 8.

ИМХО, тут есть несколько аспектов:
1. Как написал brainick , математический бэкграунд и английский в data science практически обязателен.
Причин этому несколько: отсутствие хорошей литературы на русском языке (как по теории, так и по программированию), обилие английских терминов (lift/top/cross-validation и прочие), значение которых в переводной литературе порой объяснятся весьма туманно.
2. Если говорить о конкретной литературе, которую стоит почитать, я бы выделил несколько уровней:
Уровень 0
1. Бизнес-аналитика - Паклин, Орешков (самое базовое и обзорное введение)
2. Статистика/Тервер ( по мне, хороши книги Айвазяна/Мхитаряна)
3. SQL - в обязательном порядке. Мне в свое время помогла книга "SQL для простых смертных"
4. Изучаем Python - М. Лутц (наиболее полная книга по языку, все что нужно для data science здесь точно есть)
5. Программируем коллективный разум (к слову сказать, вот в этой книге отличный перевод)
Уровень 1
1. Математические основы машинного обучения и прогнозирования - Вьюгин (книга сложная, без подготовки по учебникам НМУ на тему анализа и линейной алгебры лучше не подходить)
2. Python for Data Analysis (pandas во всей красе, тут нечего добавить)
3. Примеры и статьи по построению моделей в sklearn - на хабре в последнее время часто мелькают статьи на эту тему, там все достаточно хорошо расписано.
Уровень 2
1. Hadoop и иже с ним ("Hadoop в действии", "Programming Pig")
2. Apache Spark - достаточно почитать описание Python API.
Тут есть еще один момент - не стоит слишком привязываться к одному языку и фреймворку.
Одна из неприятных проблем python+pandas+sklearn заключается в том, что эта связка слабо масштабируется - при 2-3-4 гб данных становится сложно разместить их в оперативной памяти. Я знаю про chunk-reading+partial_fit, но точность таких моделей оставляет желать лучшего.
С другой стороны, если обрабатывать эти данные в pyspark, то теряется все удобство pandas.DataFrame и так далее. Отрасль data science быстро развивается и обрастает новыми технологиями, так что нужно все время держать руку на пульсе.
UPD: в spark 1.3 появились DataFrame.

Python используется потому что его можно потом встроить в рабочее приложение. Так делает гугл, яндекс и др.
Numpy и т.п. библиотеки написаны на С поэтому они не такие медленные как кажется.
Там где не хватает скорости python библиотек написанных на С, используется С++ а не SQL.
SQL подходит для некоторых задач, но нарисовать график с помощью SQL нельзя, а с помощью тех же python библиотек возможно. В анализе данных часто строят графики, считают векторные и т.п. произведения, на SQL такое писать неудобно.
Если не используется SQL или python, то используют обычно wolfram mathematica или mathcad и т.п. математические программы где удобно считать матрицы, векторы, производные и удобно строить графики.
С помощью python пишут софт, в котором используется результат анализа данных, поэтому и саму обработку данных пишут на python(или на С++).
Для python есть большие machine learning библиотеки наподобие google tensor flow https://www.tensorflow.org/ что опять же говорит о том, что данный язык является стандартом для написания прикладных приложений, связанных с machine learning, так же как SQL является стандартом для работы с БД.

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

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

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

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

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

На основе многих рекомендаций и отзывов.

Начало:

1. Сэнд "Hello World. Занимательное программирование"
2. Доусон "Программируем на Python"
3. Любанович "Простой Python"

Закрепление:

1. Лутц ("Изучаем", "Программируем", "Карманный справочник")
2. Рамальо "Python - к вершинам мастерства"
3. Саммерфилд "Python на практике"

Прикладное применение:

1. Митчелл "Скраппинг веб-сайтов на Python"
2. Свейгарт "Автоматизация рутинных задач с помощью Python"
3. Маккинни "Python и анализ данных"

Django:

1. Djangogirls
2. Головатый "Django. Подробное руководство"
3. Документация

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

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

Помимо серверных языков, нужно знать еще и SQL и логику работы с базами данных, соответственно, нужно выбрать и СУБД для изучения.
Помимо фреймворков на php, если Вы не владеете никаким серверным языком, можно поглядеть еще на другие технологии (кроме php + MySQL), например, Python + Django + PostgreSQL, C# + ASP.MVC + MSSQL и т.д.