Никита Назаров

Для начала о себе: по образованию я врач-психиатр, по должности я ведущий бизнес-аналитик в фирме, которая пишет медицинский софт.

Ответ коротко: нет, не нужно.

Подробно:

1. Высшее образование в медицине (я имею ввиду лечебный факультет, стоматологию (5 лет) и фармацевтику (5 лет) не рассматриваю) это 6 лет. После этого вы обязаны 3 года отработать врачом общей практики. После этого у вас специализация от 2 до 5 лет в зависимости от специальности. Чтобы пройти специализацию бесплатно, вам надо быть краснодипломником или к ним приближенным (что ой как не просто) чтобы пройти конкурс на федеральную льготу. Если по федералке не прошли, то остаются два способа: заплатить (простейшие специальности типа терапевта участкового стоят порядка 100 тыс./год), либо продаться больнице на 3 года (больница оплачивает вам обучение, а вы потом эти деньги отрабатываете). Если вы не проходите специализацию (это возможно) то значит практического опыта у вас по нулям. Ценность ваших знаний для разработки ПО -10 по шкале от 0 до 10 (я не опечатался, величина отрицательная при положительной шкале). чтобы понимать реальные потребности бизнеса вам нужен опыт, чтобы его получить вам надо: 1) пахать студентом в ночные смены мед.сестрой 2) пройти практику специализации.
   Кстати летние практики вам тоже надо проходить, и ночные дежурства в них тоже входят.
   
2. На лечебном факультете заочки нет.
   
3. Пропускать занятия - нельзя. Пропускать лекции - нельзя. Присутствие на лекциях проверяют, часто не ленятся пофамильно проверить весь курс (~300 человек). Пропускать сдачи историй болезни крайне не рекомендуется (хрен найдешь потом препода, а если найдешь - еще и хрен сдашь). Двойки получать - нельзя. Они штрафуются и/или отрабатываются (очно). Деканат обычно на стороне кафедры. Т.е. то что ты получил пару, потом не осилил 3 из 3 отработок в этом семестре и теперь тебя кафедра не допускает до сессии (кстати экзамена у этой кафедры в эту сессию может и не быть, но она все равно должна поставить допуск) - твои проблемы и только твои. Не выход на сессию - отчисление.
   
4. Обучение медицине одно из сложнейших. Вам придется заучивать огромные объемы информации. Там нет логики. Например, чтобы сдать простейший (!) экзамен по нормальной (бог с ней, с патологической) анатомии вам придется заучить три тома анатомического атласа формата а4 по 600 страниц в каждом мелким шрифтом на латыни+русском + уметь все это показать на трупе (да-да, на три года ваш второй дом - анатомичка, есть, одной рукой ковыряя в трупе - это норма) Когда заучите, это первые года три - придется учится принимать решения исходя из всей этой информации
   Добавьте к этому: мудаков профессоров коих +50% в каждом вузе, разброс знаний: вам нужно будет ориентироваться в мед.биофизике, органической и неорганической химии, биохимии, биологии, ну профильных дисциплинах (первые три года - норма и патология тела+общая фармакология, вторые три года - клинические кафедры, когда собственно начинаем учить болячки (и да, тут снова придется кучу всего заучивать, но уже проще). Завершается это клинической фармакологией, которую заучить не возможно. Ты либо помнишь и понимаешь все свои 6 лет, либо очень плохо быть тобой)
   
5. Для того чтобы писать медицинский софт в команду нужны бизнес-аналитики + грамотный архитектор + нормальный представитель на стороне клиента. Как и везде. Именно эти люди формируют техническое задание, осуществляют проектирование. К тебе в итоге уже придет конкретное задание вида "сделай класс А"
   
6. Что бы быть хорошим бизнес-аналитиком, тебе на старте нужна не столько предметка, сколько методологии бизнес-анализа. Ты должен понимать как вытащить из пользователя что ему надо и зачем
   
7. 95% рынка - это базовые учетные контуры (регистрация пациентов и их историй болезней/мед.карточек). Мед. тут не поможет вообще ни как от слова совсем. А вот хороший лид + внятный клиент + светлая голова и скрупулезность = profit. Оставшиеся 5% это исследовательские задачи, но тут без domain subject expert все равно не обойтись, даже если ты медик.
   

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

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

P.S. Если хочется по работать в сфере мед.информатики - напишите, можем пообщаться.

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

Какие задачи нужно уметь решать на чистом JS, перед тем как переходить к изучению библиотек и фреймворков?

Кроме синтаксических конструкций, математических и логических выражений, нужно знать:

• Область видимости переменных
  
• Замыкания
  
• Объектно-ориентированное программирование, в частности наследование через прототипы
  
• Шаблон проектирования "модуль"
  
• Операции над DOM
  
• Понимание принципов событийно-ориентированного программирования
  

Важно - нужно знать, откуда копипастить.
Тебе нужно быть очень хорошо знакомым с одной-двумя-тремя популярными библиотеками на JavaScript. В идеале ты должен иметь представление о том, что определённый класс задач может быть решен с помощью определённых библиотек, хотя бы одной, но такие знания приходят с практикой. Вообще ты должен быть знаком с ними так близко, чтобы помнить, в какой части мануала по библиотеке можно найти описание форматов входных данных нужной тебе функции и какой будет результат, чтобы скопировать и вставить в свой код, а потом поправить, чтобы работало.

Важно - инструменты программиста JavaScript
У тебя должен быть удобный инструмент для разработки (IDE, Integrated Development Environment), чтобы он тебе подсвечивал код (syntax highlight) и подсказывал о синтаксических ошибках (syntax check), о формальных параметрах функций (type hinting), о стиле кодирования (code style), помогал писать код (live templates).
Ты должен знать, как отлаживать скрипты в популярных браузерах (Firebug, Chrome Developer Tools и другое). Что такое точки останова, как управлять исполнением во время останова, как посмотреть и поменять содержимое переменных, как настроить останов по условию.

Хотелось бы узнать что это за задачи(упомянутые вами 80%)

Реальные задачи джунов:

1. Возьми из сборника задач по javascript любой скрипт случайно и вслух расскажи, что он делает.
   Важно - читать и понимать чужой код намного важнее, чем писать свой. И на работе тебе это приддётся делать чаще, чем ты думаешь. Чтобы подключить к своему проекту чужую JS либу, нужно понимать что она делает, как она конфигурируется, как управлять её поведением. Скажу точно, что написать свой скрипт, который строит графики, намного сложнее, чем понять, как настраивается highcharts.
   
   
2. Напиши скрипт на JS, который в заданном тексте удалит один или два символа, выбранных случайно
   
   1. Усложнение: удалять можно только буквы в словах, а знаки пунктуации и цифры удалять нельзя
      
   2. Усложнение: принять, что этот текст является программной на Javascript, удалить одну-две команды JS, но только если они не в строковых литерах (break как команду удалить можно, а в строке "break my heart" нельзя)
      
   3. Усложнение: воспользуйся этим скриптом и "попорти" код какого-нибудь другого скрипта на Javascript, а потом отладь, найди ошибку и восстанови работоспособность
      
   Важно - этим обычно все и занимаются - ищут баги. Только в реальной жизни они и без этого скрипта появляются. И не по одному, а прям пачками.
   
   
3. На страницу HTML нужно встроить график курса доллара по отношению к рублю. Формат входного массива значений курса определи сам, исходя из своего скрипта для построения графиков.
   
   1. Усложнение: на одном графике должны быть два курса, по разным шкалам. Наприме, курс доллара к евро и курс юаня к рублю
      
   2. Усложнение: первоначально график вывести в детализации по месяцам, но чтобы можно было "приблизить" (drilldown) детализацию до дней
      
   3. Усложнение: первоначально график вывести текущем месяце, но чтобы можно было загрузить данные для предыдущего месяца без перезагрузки страницы (AJAX)
      
   
   
4. При клике по картинкам, вставленным в текст HTML, показывать всплывающее окно для просмотра увеличенной картинки.
   
   1. Усложнение: в всплывающем окне сделать навигацию по картинкам, вперёд/назад и к нужной картинке
      
   2. Усложнение: в всплывающем окне вместо картинки показать видео-ролик с Youtube
      
   3. Усложнение: в всплывающем окне показать текст HTML
      
   
   
5. По клику на кнопку "Click me" показать всплывающую форму.
   
   1. Усложнение: реализовать проверку данных на корректность перед отправкой формы (непустое значение, минимальное количество символов, максимальное количество символов, минимальное числовое значение, максимальное числовое значение)
      
   2. Усложнение: если в значении текстового поля встретилась гиперссылка, то считать её за 22 символа при любой длине этой ссылки (как в твитере)
      
   3. Усложнение: реализовать отправку формы на сервер через AJAX, без перезагрузки страницы
      
   4. Усложнение: саму форму в виде HTML загрузить с сервера через AJAX, в момент клика по кнопке "Click me", правила проверок данных должны как-нибудь "извлечься" из самой загруженной формы, например из аттрибутов полей ввода
      
   
   
6. К форме ввода данных на поле ввода даты "навешать" всплывающий календарь для выбора даты.
   
   1. Усложнение: сделать форму календаря мультиязычной. Хотя бы через настройки на том же JavaScript
      
   2. Усложнение: сделать так, чтобы с помощью календаря можно было выбрать диапазон дат, чтобы она была привязана к двум полям формы "дата начала" и "дата окончания", и чтобы значение в поле "дата начала" обязательно была меньше чем в поле "дата окончания"
      
   3. Усложнение: сделать так, чтобы с помощью в календаре можно было видно визуально этот диапазон
      
   4. Усложнение: диапазон может быть открытым, но не пустым, то есть пользователь должен задать хотя бы дату начала или дату окончания.
      
   
   
7. Сделать пред-просмотр веб-страницы HTML с разными темами. Тему страницы выбирать через селектор на javascript, а показывать в фрейме.
   
   1. Усложнение: сделать селектор "тип устройства", чтобы менять размер фрейма (например, "iPhone 5c 1136x640") и "чекбокс" для смены ориентации страницы "горизонтальная" или "вертикальная" (соответственно 1136x640 или 640x1136)
      
   2. Усложнение: в селекторе тем предусмотреть поиск тем по подстроке, и аналогично поиск устройств по части названия (авто-дополнение, auto-complete)
      
   3. Усложнение: тема страницы должна меняться без перезагрузки фрейма
      
   
   

Задачи повышенной сложности, исходя из личного интереса

1. Реализовать форму для многошагового мастера: форма должна состоять из нескольких страниц (шагов), пользователь может переключать страницы через какие-нибудь элементы управления "вперёд/назад" или "перейти на страницу".
   
   1. Усложнение: реализовать функциональную связь значений, когда некоторые данные зависят друг от друга (ввёл число в поле "количество" и в поле "сумма" значение пересчиталось)
      
   2. Усложение: доступность некоторых полей ввода должна зависеть от данных (например, если указал "есть личный самолёт", то значит можно ввести "марка самолёта")
      
   3. Усложение: видимость некоторых страниц должна зависеть от данных из предыдущих страниц (например, если указал "есть личный самолёт", значит появилась страница "ТТХ самолёта"; иначе страница должна скрыться)
      
   
   
2. Реализовать однопользовательскую браузерную игру "змейка", "тетрис", "найди пару"
   
3. Реализовать многопользовательскую браузерную игру "крестики-нолики", "морской бой" на два игрока в режиме "hot seat"
   
   1. Усложнение: два игрока на разных компьютерах, ходы передаются по websocket
      
   2. Усложнение: ограничение на ожидания окончания хода 15 секунд, по окончании ожидания автоматически делается случайный ход
      
   
   
4. Реализовать todo-list. Пользователь вводит список, затем он превращается в строки с "чек-боксами". Когда "чекбокс" включен, строка зачёркивается.
   
   1. Усложнение: пользователь может переименовывать, удалять, добавлять строки
      
   2. Усложнение: список хранить в localStorage браузера, чтобы при перезагрузке страницы он восстанавливался
      
   3. Усложнение: пользователь может иметь несколько независимых списков todo
      
   
   
5. Реализовать простой графический редактор. Пусть рисуется точка в месте, где пользователь кликнул.
   
   1. Усложнение: добавить переключатель режимов "точка"/"линия", в режиме "линия" рисуются линии между двумя последовательно кликнутыми точками
      
   2. Усложнение: можно менять толщину, цвет линий, размер точек
      
   3. Усложнение: последовательность кликов можно воспроизвести ещё раз с самого начала, равномерно или с реальной задержкой между кликами, с обычной скоростью или ускоренно
      
   4. Усложнение: можно выгрузить получившийся рисунок в формате PNG или SVG, причём SVG c анимацией воспроизведения
      
   
   

Можно использовать любую существующую библиотеку.
Например,
для построения графиков www.highcharts.com
для загрузки и передачи данных через AJAX: jquery.com + что-нибудь на сервере
для всплывающих диалогов с картиками, видео и формами: fancyapps.com/fancybox и https://jqueryui.com/dialog/
для валидации форм rickharrison.github.io/validate.js
для календаря https://jqueryui.com/datepicker/
для автодополнения https://jqueryui.com/autocomplete/
для передачи данных между несколькими пользователями socket.io или обычный AJAX

Кусок моего галпфайла. Что-то снабдил комментами.

var connect      = require('browser-sync'); // livereload
var sass         = require('gulp-sass'); // Кому что, я использую SCSS
var csscomb      = require('gulp-csscomb'); // Обязательно!
var cssmin       = require('gulp-cssmin');
var imageop      = require('gulp-image-optimization'); // Лучшая альтернатива gulp-imagemin
var concat       = require('gulp-concat');
var uglify       = require('gulp-uglify');
var plumber      = require('gulp-plumber'); // Не позволяет плагину умереть молча
var autoprefixer = require('gulp-autoprefixer');
var ngrok        = require('ngrok'); // Пробрасываем локальному серверу путь наружу для для заказчика
var spritesmith  = require('gulp.spritesmith'); // Спрайты
var notify       = require('gulp-notify'); // Уведомления
var merge        = require('merge-stream'); // Деление таска на разные потоки

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

Необязательно на каждый чих заводить отдельную модельку. Тем более нет смысла хранить чисто визуальное состояние в бизнесовой модели.
Чем меньше вьюха — тем проще вносить изменения, но без фанатизма.

Я правильно понимаю, что .email-folder - это пункты меню?
Такой подход вполне имеет право на жизнь, на мой взгляд.
Конечно, по-хорошему, нужно создавать модель, заводить у нее свойство is_active и рендерить view в соответсвии с ней, в этом весь смысл MVVM-фреймворков.
Но вот в таких простых ситуациях я предпочитаю не усложнять.
Вот если вам понадобится, например, хранить состояние панели в localStorage, или программно открывать папки - тогда точно нужно использовать коллекцию моделей.

Если вы используете для подключения слушателей jQuery, вам нужен метод .on() - jquery.page2page.ru/index.php5/On

основная проблема слушателей - они могут быть повешены только на существующие объекты. Для обхода этой проблемы, слушатель фактически вешается выше, на существующий объект, но отслеживает потомков. Например, у вас есть таблица, в которой динамически подгружаются поля. Таблица существует всегда. Вот на неё и вешается слушатель для полей.
$('table').on('click', 'td', function(){})
Примерно так.

Например, в википедии.

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

Потому что надо включать определение mime-типов в настройке сервера:

include       /etc/nginx/mime.types;
default_type  application/octet-stream;

Или же что-то вроде:

location ~ \.css {
    add_header  Content-Type    text/css;
}

Я постараюсь подключить философию, примеры и "как если бы я говорил в баре с вами".

ЯП - это инструмент. Инструмент всегда взаимодействует с объектом и со средой. Соответственно, вам точно нужно что-то знать про объект и уметь пользоваться инструментом внутри среды, а это потащит дополнительные знания, назовем их "естественными" зависимостями. Насколько глубоко их нужно знать? Тут ответа не бывает: настолько, насколько нужно и хочется. Тут важен баланс и акцент. Если нет строгих параметров на уровне разума, нужно верить интуиции, потому что больше нечему. Для JS-программиста JSON/jQuery/AJAX - это естественные зависимости, их в любом случае не получится обойти. Даю зуб, что вам хватит вечера и немного гугла, чтобы стать чуть ли не LIKE A PRO в этом. Это все форматы хранения данных, либы, парадигмы. Это примерно как прочитать состав у шоколадки по сложности и входному порогу. Скорее всего, вас пугают сложные слова. Примерно как сказать "НАПРАВЛЕННЫЙ АЦИКЛИЧЕСКИЙ ГРАФ", и вы сразу знаете теорию графов, хотя с практической точки зрения суть настолько элементарна, что аж страшно, а вы будете долго прокрастинировать и искать что попроще.

Это что касается близких и неизбежных естественных зависимостей. Но есть и более далекие, но тем не менее все равно естественные, их знание позволяет развиваться, иметь более полную картину в голове. Вот есть гитарист, он может быть просто технарем. Есть гитарист-музыкант, который чувствует дорийский лад в блюзе. А есть гитарист-музыкант-звукорежиссер, который наконец-то понял, как надо жирно сводить гитары и теперь в симбиозе со звукарем. Кто из них самый крутой, очевидно.

Вы можете просто верстать (html/css) и игнорировать программирование в целом. Но естественная среда противится: вы уже (!) пишете на декларативном языке, неплохо было бы узнать об этом подробнее (о языках или даже о типизации), тем более, что крайне близко к вам находится интереснейший язык js, а там моментально вылезут проблемы связывания html и js, разные подходы к этому, целые парадигмы и фреймворки; и вот вам выпадает интересная задача по анимированию svg, вы курите мануал по нужной либе, читаете что-то про reflow/repaint, внезапно узнаете что-нибудь про селекторы. И через какое-то время, будучи все тем же верстальщиком, вы видите архитектурный косяк дизайна, который очень неудобно укладывается в используемые технологии, предлагаете его пофиксить и спасаете команду от факапа через месяц, когда какой-нибудь транзишн наложится на какой-нибудь position: fixed и еще и в Safari упадет анимация и только там, а тут и новая тудушка: "Переделать, нафиг, всю шапку, чтобы ок было". Что-то изменилось в мышлении и картина стала полнее. ВНЕЗАПНО вы уже и инженер, можно сказать, ЗП растет, все дела, рутины меньше стало.

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

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

Так вот, теперь у нас есть естественные зависимости, инжиниринг и баланс между порогами. А не php/jquery/html/css.

Важно также отметить, что все очень быстро развивается сейчас, а это еще один аргумент, что привязываться к инструменту не стоит. Кто-то может сказать, мол, взять тот же js, программирование на нем - это целая парадигма, иной подход, свои фичи. Это так, но дело тут не в js, а в целом в динамичных/интерпретируемых языках.

Кстати, что касается SEO: с технической точки зрения это пара мануалов от гугла и не более того. Там сеошники наговорить могут много, с ними надо быть осторожнее :)

А теперь, собственно, выводы:

1) Вакансий крутых много, надо пробовать. Нужно только отличать близкие и необходимые естественные зависимости от мастера на все руки. Я считаю, что мастером на все руки нужно поработать хоть однажды, чтобы просто понять, почему это плохо. Но зависимости будут всегда, и это норма. Вы перечислили слишком радикально, конечно.
2) Себя пилить под вакансию не нужно. Нужно просто идти туда, где интересно, всегда стараться быть инженером и не убить в себе искусство (то есть не бояться делать так, как кажется правильно, чтобы либо убедиться в правоте, либо ошибиться и стать круче).
3) Не нужно думать в стиле "а что если завтра рубионреилс развалится, комьюнити разойдется, вакансий не будет, что я буду делать". Вы же инженер. У вас опыт в проектировании IT-систем, перейти на что-то смежное, если будет понятно, что технология умирает, не составит труда.
4) По естественным зависимостям нужно двигаться по мере интереса, вы станете от этого только лучше.

Это, конечно, если вам действительно все это интересно. Все это области, очень близкие к искусству, и тут надо любить все это делать.