Привет, Хабр!

Следуя завету древних “хочешь разобраться в вопросе — напиши об этом статью”, я решил разобраться в вопросе — а какие собственно специальности будут востребованы в ближайшем будущем, и не в сферическом «глобальном мире», а в конкретном Воронеже месте, где родился и проживает герой нашего эпиграфа.

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

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

Вопрос — сможет ли он, при таких стартовых условиях, расчитывать также войти в 10% по уровню дохода и общественного признания? Как вы понимаете — ответ отрицательный с вероятностью 95%, и тому есть ряд объективных причин. Рассмотрим, где может работать наш условный герой.

Карьера в ИТ-департаменте не-ИТ компании

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

А сейчас я наблюдаю тенденцию снижения роли ИТ-дирекций в крупных непрофильных компаниях по нескольким причинам:

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

Да и тенденция передачи всего непрофильного на аутсорсинг вполне соответствует рекомендациям «большой тройки», к которым вынуждены прислушиваться владельцы крупных предприятия (ведь многие завязаны на иностранные кредиты, и показатель “выработка на сотрудника” не менее важен чем ебитда).

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

— Уровень ИТ-компетенции простых сотрудников растет, и услуги «няньки» нужны все реже. Крупные проекты автоматизации могут быть сделаны вообще без ИТ-директора. Нужна MES-система? Пошлем директора по производству в отраслевой тур — пусть опросит коллег — «у кого что стоит», и предложит продукт, подрядчика, и план проекта. Нужна глубокая аналитика? Наймем старшего маркетолога с хорошим стат- мат- образованием — пусть сразу со своим ПО и приходит, и нас всех научит.

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

— В непрофильной компании ИТ-директор управляет немаленьким бюджетом, львиная доля которого — закупка оборудования, корпоративные соглашения с майкрософт / оракл / etc, и наличие «политических» моментов сильно затрудняет попадание на эту должность простого программиста, даже если он местный гений.

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

Карьера в местной ИТ-компании

Это уже лучше, но в нашем условном Воронеже таких немного, и основная часть — это про 1С или дистрибуцию / поддержку брендового ПО. Условия труда здесь обычно хуже, свободы меньше, тайм-менеджмент жестче, так как в среднем эти компании беднее, чем крупный завод или агрохолдинг, зато здесь лучшая школа, и можно вырасти, но лишь в узко-профессиональном смысле, без шанса попасть в число лиц, от которых что-то зависит в масштабе города — ведь основные деньги зарабатываются не здесь, а, как известно, где деньги, там и власть, и карьера.

Резюме. Такую работу можно рассматривать лишь как старт перед переездом в одну из столиц. Второй вариант — вы сможете со временем основать собственную мелкую фирму по сопровождению 1С, и даже купить мицубиси. Но это потолок в смысле именно ИТ-карьеры.

Удаленная работа и фрилансинг

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

Пример 1. Представьте ситуацию — вы хирург-травматолог в районной больнице города Карачаевска, других травматологов в окрестности 100 километров нет, горная местность, горячий народ, травм много, и даже если вы не очень хорошо учились, слабенько оперируете — у вас не будет отбоя от клиентов, весь город будет нести вам подарки и стараться дружить.

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

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

Пример 2. Вы — руководитель строительных проектов, прораб по простому. Вы конкурируете внутри вашего города, а дома строятся, перестраиваются, сносятся даже в кризис, потому что людям надо где-то жить, а не цифирки в гаджетах разглядывать.

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

Пример 3. Вы — юрист по специализации “оценка земель, землепользование, природоохрана”. У кого-то участок попал в водоохранную зону, кому-то налоги завысили, в каком-то районе надо задрать / опустить кадастровую оценку, потому-что какой-то уважаемый человек решил всю улицу скупить, и т.д. Работа у вас будет, а в кризис — особенно.

Пример 4. Вы программист, ищете удаленную работу, либо фриланс. В этом случае вам придется конкурировать сразу с половиной мира — от питерского программиста до венского / израильского / индийского, и вам придется соответствовать.

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

Психологические аспекты карьеры

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

Однако, на любой серьезной должности никакого здоровья не хватит контролировать все лично, а навык «неважное и несрочное — поручить и забыть» не развит, и как следствие — наш герой будет метаться меж 2-х крайностей — от перфекционизма до полного отсутствия контроля, и оба варианта будут хуже.

Резюме

Если вы действительно хотите карьеры в ИТ — уезжайте в столицы тех стран, где делают ИТ, причем сразу после школы, а если хотите остаться в провинции — выбирайте работу, более близкую к земле и живущим на ней людям — врач, юрист, строитель, полицейский в конце концов. А в свободное время Вы можете продолжать программировать, в качестве хобби, если захотите.

Добрый день, нашел в интернете задание написать программу, осуществляющую перевод Hex числа в Dec число.

Мною написан нижеследующий код:

var x='2D';

function foo(x){

var arr=[];

for (i=0;i<x.length;i++){

var holder=x.slice(-1-i,(0-i)==0?undefined:0-i);

if (!Number.isInteger(+holder)) {

holder={'A':10,'B':11,'C':12,'D':13,'E':14,'F':15}[holder];

}
arr.push(+holder*Math.pow(16,i));
}

return arr.reduce((a,b)=>a+b);
}

foo(x);

Могу ли я претендовать на позицию джуниора.

>>79545
- Непоследовательно используются стрелочные функции - например Worker.js, коллбэк function(e) и через пару строк cache => ..., зачем так?

- Непоследовательно делается проверка браузерных фич - почему-то предусмотрено сообщение для проверки наличия FileAPI, который есть с IE10, но не проверяется ES6-синтаксис или те же веб-воркеры

- Непоследовательно используется for ... of и .forEach

js.js
- Проверка noJдля ES5-браузеров скажет что не включен JS, хотя он включен
- Зачем тогглятся классы .js и .nojs для body?
- В том же месте Array.prototype.forEach.call вместо спреда, хотя в других файлах спред есть, опять непоследовательно
- Зачем вообще вся эта проверка, тогглы классов, обработчик DOMContentLoaded, удаление элементов, если есть тэг <noscript>, в котором и можно твое предупреждение показать?

editText.js
- Длинные заголовки заметок выползают за пределы меню если написаны в одно слово, надо либо ограничивать максимальную длину, либо text-overflow: ellipsis, либо word-break
- Двойной щелчок для перехода в режим редактирования неинтуитивно, тем более когда курсор при наведении превращается каретку.
- Зачем вообще вся эта схема, копировать символы при вводе из area в span? Можно обойтись одним textarea и тоглить у него readonly, либо одним div'ом с contenteditable
- В чем цель копировать вычисленные getComputedStyle в style?
- У element.classList есть метод .add(), можно добавлять классы через него а не спредить-клеить
- Тройное присваивание?
- Возвращать в получившемся компоненте промис чтобы потом через editText().then(text => ...) получить введенное значение это очень странная идея. Промисы нужны не для этого, они для асинхронных действий - работа с сетью, работа с файлами. Здесь полностью синхронная цепочка, да и она посыпется как только к onBlur компонента захочется другие хэндлеры добавить. Эти обработчики должны передаваться просто переменными:
editText(model), где model({ element, focusClass, onBlur, onChange, ... }).

main.js
- notes = notes.filter(n => n.hasOwnProperty('title')).map(({title, text}) => {return {title, text}});
Какой смысл этой операции?

Очень некрасивые стили

>это работало нормально до тех пор, пока я не захотел, чтобы одна кнопка закрывала текущую модалку и потом делала кое-что. В итоге надо было повесить на кнопку два атрибута data-action, что невозможно.

Можно сделать третий экшн thirdAction() { firstAction(); secondAction(); }
Можно передавать список через разделитель "firstAction, secondAction"

>>79702
Спасибо, некоторое поправил, по остальным есть вопросы, надеюсь ответишь.

>Непоследовательно делается проверка браузерных фич

А как я проверю ES6? Да и надо ли? Я думал скачать webPack, засунуть все туда. Слышал, что какой-то babel там все превратит в es5.

> for ... of и .forEach

А что, надо выбрать один из двух и всегда использовать только его? Где что-то простое, пишу forEach, где что-то сложное, пишу for of, чтобы код был читабельнее.

>Проверка noJдля ES5-браузеров скажет что не включен JS, хотя он включен

Что за проверка и почему она так скажет?

>В том же месте Array.prototype.forEach.call вместо спреда,

В смысле, как это связано вообще? Спред это для распаковки массивов, а forEach.call это чтобы проитерировать не массив.

>В чем цель копировать вычисленные getComputedStyle в style?

Чтобы не проебать дефолтные паддинги некоторых элементов.

>У element.classList есть метод .add(), можно добавлять классы через него а не спредить-клеить

Так зато одна операция всего, иначе пришлось бы опять .forEach(c => e.classList.add(c)). Разве плохо?

>Промисы нужны не для этого, они для асинхронных действий - работа с сетью, работа с файлами.

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

>да и она посыпется

Почему?

>notes = notes.filter(n => n.hasOwnProperty('title'))

>какой смысл

Убедиться в том, что в хранилище не попадет ненужный мусор, который пользователь мог записать в .json.

>Очень некрасивые стили

Если ты про то, как они выглядят, то я не дизайнер, мне норм. Если ты про сам код по поясни.

>Можно сделать третий экшн

>Можно передавать список

Думал об этом, оба варианта выглядят не очень. Неужели на серьезных проектах так и делают?

>>79709
Я не ставил это целью, так получилось. А как сделать лучше? Я разбил, что мог, на отдельные файлы. Современные проекты любые даже больше всего используют.

>>80662
Не делается это через дебаунс. Дебаунс появляется когда есть обработчик на изменение и он вычислительно тяжелый, поэтому вводят задержку чтобы уменьшить количество обращений к этому обработчику, чтобы ввод/скролл/etc были плавными. У него обработка идет не на нажатие, а на onBlur, здесь просто коллбэк нужен.

>>80631

>А как я проверю ES6? Да и надо ли?

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

>А что, надо выбрать один из двух и всегда использовать только его? Где что-то простое, пишу forEach, где что-то сложное, пишу for of, чтобы код был читабельнее.

Ты меня обманываешь.
- раз: for (let note of notes) notesList.add(note);
- два: notes.forEach(n => delete n.key);
Либо у тебя невероятно плохая способность разделять сложное и простое, т.к. операции здесь одни и те же, либо ты чем-то другим руководствовался или ничем не руководствовался. Когда человек незнакомый с твоим кодом пытается его прочитать такие прыжки от одного стиля к другому сильно мешают, сразу пытаешься понять, почему одна и та же вещь здесь так написано, а здесь иначе, нет ли в этом какого-либо смысла который надо учесть при внесении фикса/доработки. Ты своим коллегам будущим жизнь усложняешь, плюс у всего написанного кода должна быть какая-то причина, причина "здесь мне хотелось так, а здесь иначе" - плохая причина.

>Что за проверка и почему она так скажет?

Вся проверка которую ты в этом файле js.js написал. Открой в IE11 свой сайт, увидишь сообщение что надо включить JS и ошибки в консоли, потому что используется ES6-синтаксис. "У вас не включен JS" и "У вас устаревший браузер, скачайте новый" это две разные ситуации и два разных сообщения.

>В смысле, как это связано вообще? Спред это для распаковки массивов, а forEach.call это чтобы проитерировать не массив.

Array.prototype.forEach.call(document.body.querySelectorAll(".nojs"),o=>o.remove())

[ ...document.body.querySelectorAll(".nojs") ].forEach(item => item.remove())
Спред тебе превратит итерируемый объект вроде NodeList в обычный массив. Либо Array.from(document.body.querySelectorAll(".nojs")).forEach(item => item.remove()). Так как ты написал сейчас никто без специального умысла не пишет.

>Чтобы не проебать дефолтные паддинги некоторых элементов.

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

>Так зато одна операция всего, иначе пришлось бы опять .forEach(c => e.classList.add(c)). Разве плохо?

classList.add() может массив принимать

>Работа с пользователем тоже асинхронное действие, разве нет? Я не знаю, когда пользователь закончит писать текст, но когда закончит, я хочу что-то с новым текстом сделать.

Нет, не асинхронное. Ты знаешь, когда пользователь закончил писать текст - когда сработало событие onBlur (во всяком случае у тебя так, случай когда пользователь просто перестал печатать пока не рассматриваем), и промисы здесь ни к селу, ни к огороду. Одно строго следует за другим

>Почему посыпется?

Ну представь что ты сделал свой компонент редактирования текста editText, и ты у него сделал промис чтобы editText().then(text => ...) который получает введенный текст по окончанию ввода. И тут тебе понадобилось его доработать, и сделать два разных обработчика, на ввод символа и на потерю фокуса. Как делать будешь, editText().then(text => текст после ввода буквы).then(text => текст после потери фокуса)? И держать в голове что первый then обозначает это, а второй вот это? А если больше событий надо будет обработать, допустим текст при первоначальном рендере, текст после привязки данных, текст на ввод символа, текст на окончание ввода, текст на потерю фокуса? then().then().then().then().then()? Тебе промисы тут никак не помогают, только запутывают и создадут сложности с доработкой этого компонента

>Если ты про то, как они выглядят, то я не дизайнер, мне норм. Если ты про сам код по поясни.

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

>Думал об этом, оба варианта выглядят не очень. Неужели на серьезных проектах так и делают?

На серьезных проектах на ванилле редко пишут. Но вообще "выглядят не очень" это плохой аргумент, если ты не дизайнер :) В разработке обычно если "не очень", то всегда есть объяснение "почему".

>>80922

>У меня такая идея - я сейчас разберусь с webpack'ом, суну в него свою записную книжку и за счет babel получу es5, работающий везде.

FileAPI не работает в IE9 и меньше, у IE9 поддержка es5 частичная, так что может вообще в es3 надо будет транспилировать.
Как надо - я бы сначала сделал вот то что ты тут написал, и только потом уже стал бы писать проверки. С пониманием, зачем я их пишу и что в них должно быть.

>Добавить записку в список просто - есть записка под нее кнопка, готово. А тут используется оператор delete

Ты уже какую-то свою абстрактную сложность начал выдумывать, опираясь на свое знание/незнание операторов, по такой логике выбор между этими двумя вариантами
for (let item of items) item.pek()
items.forEach(item => item.pek())
должен делаться в зависимости от того, содержит pek две строки или двадцать. Это так не работает. Сложность - она в прочтении. Легче всего читается, когда элементарные операции - фильтрация, маппинг, итерарирование, редус сделаны через соответствующие семантические операторы. Откат на обобщенные for-циклы делается, когда логику уже нельзя выразить простым действием и там что-нибудь сложное начинается.

>Почему? Тут же лишняя операция создания массива. Говоришь везде на спрэды заменить стоит?

Лучше сразу отучаться "оптимизировать". Там лишняя операция, там for(;;) вместо forEach, прочая ересь.
Когда тебе надо будет оптимизировать, тебе об этом скажут. Делается это совсем по-другому - выявлением узкого места, с профилированием, графиками и возможностью численно оценить результат оптимизации. Навык оптимизации "на будущее" приходит с опытом и он опять же не в экономии на спред-операторах, а на знании архитектуры, инструментов и технических подходов к той или иной задаче. Например, зная, что getComputedStyle вызывает полный пересчет лэйаута, ты подумаешь, прежде чем дергать его допустим на странице со тяжелым DOMом, у большого количества элементов, в цикле, в событии скролла. Это хорошая преждевременная оптимизация, потому что ты заранее знаешь в чем проблема и как она проявится. Не использовать спред чтобы избежать создания промежуточного массива на три с половиной элемента из-за того, что кто-то в интернете провел замеры и обнаружил, что Array.prototype.forEach.call предпочтительнее спреда на массиве в два миллиарда элементов - это плохая оптимизация.

Сюда же и твой delete идет. Он редко встречается потому, что хотя в ванильном JS все объекты {} и имеют один тип, но под капотом в движке им присваиваются внутренние классы в зависимости от состава полей в этом объекте, за счет чего проводится оптимизация, и когда у тебя очень много очень сложных объектов, которые оптимизатор считает экземплярами одного внутреннего класса, а потом ты у них рандомно начинаешь делать delete свойств (из-за чего для части объектов получают другой внутренний класс), то оптимизатор может запутаться и после таких выборочных delete'ов не сможет соптимизировать, ну допустим конструктор этих объектов.
Тебе все это знать не надо. Это все настолько специфичные и нишевые проблемы, что когда тебе это понадобится - ты сам уже будешь знать, что вот такая проблема и вот такая причина и вот поэтому именно конкретно в этом месте delete нежелателен. А твое "выглядит апасна, да и аноны на двачах не советуют" - плохая методика.

>Ну смотри, у texarea есть свои паддинги, у кнопок свои, у параграфов их нет вообще. Получится, если кто-то попытается изменить текст на элементе без классов вообще, могут паддинги меняться при редактировании, текст будет прыгать.

Я тебя не понимаю. Дефолтный браузерный паддинг отличается для textarea с текстом и textarea без текста? Что бы за проблема там у тебя ни была, я совершенно уверен, что она решается не так.

>Так он их криво склеивает в один класс.

Что значит криво? Пикрил

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

Открываешь http://material.io и получаешь готовый гайдлайн как не будучи дизайнером получить приемлемый дизайн в своем приложении.

>>80987

>Как надо - я бы сначала сделал вот то что ты тут написал

Выучил бы вебпак? Ок, сейчас займусь этим.

>С пониманием, зачем я их пишу и что в них должно быть.

А где это понимание получить? Вот на том же MDN под статьей про ЛЮБОЙ кусок апи есть таблица поддержки, с версиями браузеров. Не вручную же мне проверять весь свой код на то, какая минимальная версия браузера это поддерживает, и какой es эта же версия использует. Может под вебпак\gulp есть что-то, что проверит весь код и выдаст мне, где он будет поддерживаться как есть, и где он будет поддерживаться, если я его в какой-нибудь прошлый еs транслирую.

>Легче всего читается, когда элементарные операции сделаны через соответствующие семантические операторы

Операторы? Методы? А вот такое простейшее, где я включаю кнопки меню, тоже выглядит нормально?

>Лучше сразу отучаться "оптимизировать".

Окей, починю.

>Я тебя не понимаю.

У texarea по дефолту есть паддинг, у параграфа нет. Пользователь хочет изменить параграф, у которого нет классов, через которые ему задают паддинги. У Texarea они значит тоже контролироваться не будут. Когда texarea заменит параграф появятся эти дефолтные паддинги и текст сместиться. Вот сейчас я убрал это и при редактировании заголовка записки меняется вес шрифта. Потому что он не контролируется на элементе классами, а значит что у элемента, что у textarea, который получает классы элемента, стоят дефолты. И они для этого свойства (вес шрифта) у них разные. Хотя может лучше контролировать это для элементов, на которые может быть вызван editText, я не знаю.

>Что значит криво? Пикрил

Прикольно. Но в editText все равно лучше просто склеить. Это же будет происходить при каждом вызове на разные элементы, т.е. прошлые классы надо удалить, новые присвоить.

>Открываешь http://material.io

Ладно, сейчас буду и стили переделывать.

>>80988
Даже если это action одно? Хотел как в Пистоне просто делать отступы на следующей строке, а мне сказали, что для одного действия и новая строка не нужна. Ну ладно, переделаю в уродливые }{}{{}. Кстати, а разве stylelint может такое проверять? Я думал это только для порядка css правил.

>>81081
Все, учу вебпак и бебель.

>И да, попытка запихать в один петпроект все невпихуемое

Ну я не пытаюсь, я делаю записную книжку и использую все по мере надобности. Ты хочешь сказать что тот же фэйсбук, о котором тут срач был, лежит у них на серверах где-то в разных версиях? Для поддержки ie одна, для современных другая, для суперсовременных третья?

Ещё оффтоп, почему firefox делает такое с моим текстом? На Хроме такого нет.