jehy
0

Или "http handler" (если уж по английски), или "обработчик http запроса", "обработчик маршрута".

jehy
0

Пожалуйста, не пишите про "http ручки". Не в первый раз сталкиваюсь с этим беспощадным и неграмотным сленгом. Не "ручки" они. Ни в русском, ни в английском.

jehy
0

Ну не стоит прям обобщать SQL на фуллстек по всем технологиям. В 80% вакансий по бэкенду требуется именно хороший SQL плюс знание какого-то конкретного языка разработки. Хотя сейчас этот процент падает потихоньку.

jehy
0

А, так ad1Dima про них писал. Пардон. Я в стандартных человеческих часах считал — отсюда и расхождение.

jehy
0

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


А ещё студенты профессиональных курсов обычно идут применять полученные знания сразу, а не спустя ещё 2-3 года.


Ну и как написали выше — в семестре может быть разное количество часов на курс. У меня вот было 2 пары в неделю, итого 2х1.5х18=54 часа.

jehy
0

Вам навскидку несколько примеров того, с чем сталкиваешься с этой стороны рекрутинга:


  • Кандидат молча не приходит на встречу.
  • Когда пытаешься выяснить, чем занимался кандидат на прошлой работе, отвечает несколько раз односложно "Внедрял!"
  • Кандидат не может найти офис при условии того, что у него есть адрес и прикреплённая карта.
  • Кандидат не может предоставить никакой образец кода, мол "всё под NDA". Тестовое задание брать тоже отказывается.
  • На вопрос о удобной дате встречи, кандидат предлагает дату через полтора месяца.
  • Несмотря на то, что в вакансии трижды написано, что работа только в офисе, кандидат продолжает гнуть линию, что будет работать из дома или из своего города. Если ему говорят, что этот вариант не подходит так как у нас PCI DSS, то в ответ начинает говорить, что мы застряли в каменном веке.
  • У части пришедших кандидатов нет разрешения на работу. Иногда вообще приходят нелегальные эмигранты. Что характерно, об этом человек готов рассказать только после собеседования.
  • Внезапно оказывается, что "ну, я могу приезжать только к 12. И уезжать надо в 17. И вообще могу приезжать только по средам в чётные числа".

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

jehy
+2

Если у вас программируют на Минск-32, то без этого никак!

jehy
0
а как можно (не нужно, а просто можно) адекватно отреагировать в тот самый момент?

Если всё совсем плохо, то можно вежливо посидеть, покивать, уйти и отписать письмом, что было не так (чтобы не было вероятности устроить прям на месте разборки и скандал с каким-нибудь особо эмоциональным человеком). А если с той стороны явно неадекватный человек — то лучше даже не писать, а просто заблокировать.


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


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


Насчёт юмора — не рекомендую. Чувство юмора у всех разное, у некоторых его вообще нет. Это не минус человека, просто данность — встречал отличных специалистов, которые вообще никогда не улыбаются. Так что всегда лучше отписать полноценное письмо с пояснениями. Фидбек это бесценно, он делает мир немного лучше.

jehy
0

Пожалуйста, вот вам простая функция транслитерации на яваскрипте. Сразу оговорюсь, что автор не я.

jehy
0

Две пары в неделю — одна на лекции, одна на практику.

jehy
+2

It depends.


  1. Даже у самой замечательной компании могут быть печальные HR процессы, так что соискателю не воспринимать этот список как "увидел хоть один пункт — беги".
  2. В списке есть несколько спорных моментов, которые на самом деле могут означать разное (на мой взгляд, 2-3, хотя это мой же список).
  3. Если вы сознательно идёте работать в организацию вроде банка с большим количеством бюрократии, то нужно быть готовым встретить минимум 5 пунктов из списка.
  4. Часто организация использует HR на аутсорсе, в этом случае все ошибки имеют отношение не к компании, а к аутсорсерам.
  5. Никто не совершенен, и некоторые косяки случаются просто потому что случаются (shit happens). Так что не стоит воспринимать первый же антипаттерн как сигнал о том, что всё плохо систематически. Люди заболевают, опаздывают, забывают, у всех есть свои личные обстоятельства — так что иногда нужно просто, например, напомнить о себе. У меня такое случалось довольно много раз, и HR потом извинялись и отлично вели коммуникацию дальше.

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


Ну и последнее — если вы не столкнулись ни с чем из списка, то это с большой вероятностью означает адекватность всей компании, и при выборе места работы надо учесть этот фактор. Адекватные люди адекватны во всём.

jehy
0

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

jehy
0

Отвечаю как преподаватель. Сейчас на СУБД обычно выдаётся один семестр. Этого катастрофически не хватает для полного понимания, и даже из усвоенного студенты забывают половину к моменту трудоустройства.

jehy
0

У меня есть такая задача "на засыпку" для кандидатов, которые говорят, что хорошо знают SQL. Задаю простой вопрос:


Что будет результатом запроса select * from a, b где a и b это некие таблицы?

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

jehy
+1

Чёткое ТЗ это хорошо, кто бы спорил. Но повторюсь — в печальной реальной жизни есть огромное количество чёрных ящиков без спецификации. И когда мы работаем с крупными банками (не буду называть конкретно), то часто возникает ощущение, что их софт им подарили рептилоиды, и документации на него столько же, сколько на египетские пирамиды и НЛО.

jehy
+1

Зря так на ad1Dima накинулись — скилл писать без дебаггинга действительно порой востребован. Например, у меня были случаи, когда нужно было через цепочку RDP+TeamViewer+SSH на проде внести мелкие правки при помощи vim. Другой вопрос, что если это не единичный случай, а система, то бегите из компании со всех ног.


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


И последнее — да, разбор крешлогов. Например, в случае, если тебе для мобильного приложения упал лог, а воспроизвести поведение пользователя и его девайса (тысячи их!) никак не удаётся.

jehy
+5

Хорошее отношение к работникам показывают завтраки/обеды и фрукты в офисе. А так же всякие варианты компенсации спорта. Печеньки это дёшево для работодателя и дорого для попы программиста. А ещё это часто не физические печеньки, а "cum to the dark side" (опечатка не случайна).

jehy
0

С одной стороны — да. С другой — часто рекрутера интересует некий "общий стаж", а так же компании, в которых вы работали, и роли, в которых вы там выступали. А ваша текущая сфера специализации и ожидания в любом случае указываются отдельно. Опять же, даже Node.JS разработчику может быть частично релевантен опыт работы с Delphi, если он использовал в Delphi проектах, например, реляционные СУБД.


Так что обычно лучше написать больше. Если это не нужно, то для рекрутера не должно составить проблем выкинуть несколько листочков — а не вчитываться в хроники 90х годов.

jehy
+6

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


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

jehy
+3

Здесь есть нюанс в различии между "на листочке" и "без IDE". Про себя скажу, что люблю начинать писать с драфта, а потом его наращивать. Плюс к этому, у меня ужасный почерк. Так что к любому предложению написать что-то на бумаге я отношусь негативно. В специализированном тренажёре, текстовом редакторе или скайпе — ещё более-менее. Хотя если честно, я не понимаю, какой такой бонус может дать разработчику IDE, чтобы его лишать этого бонуса на тестировании.


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

jehy
+4

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

jehy
+1

Про Delphi начинают рассказывать, если про это начинают спрашивать. В статье я упомянул, что многие любят посмотреть работу 10 лет назад и задавать по ней вопросы. Вам и мне понятно, что практическую ценность обычно имеют последние 2-3 года работы.

jehy
+10

Для рекрутеров в IT. Это реальный список того, с чем я сталкивался — причём и сам выступая в роли соискателя, и нанимая людей через рекрутинговые агентства. Можно использовать как чеклист. Конечно, есть нюансы, но если рекрутер видит там несколько знакомых пунктов — это значит, что что-то пошло не так.

jehy
0
«Если у вас есть 2 яйца и вы собираетесь выяснить, с какого максимального этажа здания вы можете бросить яйцо, не разбив его, как вы это сделаете? Предложите оптимальное решение»

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


«У вас есть 100 монет, лежащих на столе. У каждой из них есть две стороны: «орел» и «решка». 10 монет «орлом» вверх и 90 «решкой» вверх. Вы не можете почувствовать, увидеть или как-то распознать, где какая сторона. Вам нужно поделить все монетки на две части так, чтобы в каждой из них было равное количество монеток, которые лежат «орлом» вверх»

Разделю монеты на две равные стопки и поставлю на ребро.


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

Сразу после того, как вылить кофе из чашки.


«Опишите случай, когда вы обидели друга и как вы с этим справились?»

Легко справляюсь с такими проблемами — меня не огорчает обижать людей.

jehy
0

Довольно очевидное решение, которое будет работать — почему бы и нет. Сам периодически такое пишу. Например, программа для прошивки MPOS терминалов написана именно на node.js — настройка в браузере, потом вызов локальной ноды, которая уже дёргает вендорское приложение или нативные мультиплатформенные модули. В плюсах — есть интерфейс, удобно работать, легко поддерживать, не надо размываться на ещё один стек. Минусов пока не обнаружено.


По вашему коду — непонятно, почему у вас в 2017 году древний javascript и callback hell как он есть.

jehy
0

Дети-то способны к чему угодно. Я о том, что детей нужно заинтересовать. А чтобы заинтересовать — нужно показать некий интересный практический пример, который они смогут развивать.


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

jehy
+14

Довольно очевидный вопрос. Джуниор ни в чём не виноват — он по определению не должен иметь доступ к продуктовой базе. Более того, желательно, чтобы у него даже доступа в сеть с продуктовой средой не было. Так что к нему вообще никаких вопросов.


Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.


А технический директор — просто редкостно некомпетентный идиот, раз он сделал такие выводы. И на своём месте принесёт больше вреда, чем пользы. Так что в расход без сожалений.

jehy
0

Присоединяюсь к комментаторам, которые говорят, что это было мило но бесполезно. У вас был всего один урок для того, чтобы ребята поняли, что программирование — это не удел каких-то высоколобых гениев. Вы им показали обратное. Что я бы сделал, попав в такую ситуацию? Вместо программирования научил бы ребят за урок рисовать простые html странички. Это был бы некий импульс, которым они могут воспользоваться дальше сами. А давать им плюсы — значит не вызвать ровно никакого интереса. Ещё можно было дать им простеньких скриптов на php.


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

jehy
+11

Очень хорошая и правильная статья. Но до своей ЦА вряд ли дойдёт. А этих ребят, как ни странно, безумное количество. Раз в неделю вижу примеры, например, переписывания с PHP на Go неких проектов, которые годами исправно тащили все свои полтора rps. Причём уже несколько раз видел, когда это закономерно проваливается, и люди делают вывод, что нужно было подражать другому популярному тренду. И начинают новый виток бессмысленной разработки.

jehy
–27

Открыл тест — посмотрел — закрыл. Скучно.

jehy
0

А как вы решаете вопрос, если camera2 на устройстве ещё нет? Какой-то универсальный адаптер?

jehy
0

Статья полноценно выжимается в одно предложение "ставьте и обновляете через гит". Ну как-то ни о чём. Возможно, следовало объединить с последующими частями.

jehy
+1

Просто мне сложно представить другой кейс, в котором вам захочется использовать то же имя переменной. А с глобальными я верю, поскольку видел воочию код, в котором использовались глобальные переменные с названиями вроде c, v, cc, vv и a. И код этот писался блоками по 400 строк. Думаю, разработчик сильно икал, когда я это рефакторил. Не надо так делать — и никаких проблем с no-shadow у вас не будет.


Кстати, регулярно вижу, когда разработчики прокидывают через всё приложение значимые объекты с названиями вроде c1. И попробуй пойми, что это. Байты что ли экономят? В общем, я своих разработчиков так делать отучил. И с кодом сразу стало на порядок проще работать.

jehy
+1

Вы не поверите, но в 2017 году глобальные переменные не используют...

jehy
+1

Видимо, вы никогда просто не пробовали это правило. Оно не заставляет называть всё уникальными именами. Оно не даёт только пересекать области видимости. То есть, у вас может быть функция, а внутри неё — сколько угодно циклов для i. А если у вас уже внутри этого цикла идёт ещё один — вообще довольно логично назвать переменную по-другому.

jehy
0

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

jehy
0
C var очень легко облажаться за счёт поднятие переменной. Именно из этого растут корни у сотен тестовых задачек для разработчика наподобие этой:

var foo = 1; 
function bar() { 
    if (!foo) { 
        var foo = 10; 
    } 
    alert(foo); 
} 
bar();


А let и const ведут себя точно так же, как и переменные в классических языках разработки — так что подобных стрёмных вопросов просто не возникает.

Собственно, у ESLint (без которого имхо писать не стоит) во всех современных стандартах даже есть специальное правило no-var, в описании которого стоит ровно то, что я чуть выше написал по своим ощущениям:

ECMAScript 6 allows programmers to create variables with block scope instead of function scope using the let and const keywords. Block scope is common in many other programming languages and helps programmers avoid mistakes.
jehy
0
Тут дело не в моде, а в прагматичности. Go для тех, кто хочет быстрый, простой в сопровождении и расширении код. Для модников, любителей смузи, callback и dependency hell’a есть nodejs.

Повторюсь в пятый раз. В Node.JS как минимум уже три года как нет callback hell. Dependency hell возникает крайне редко в случае использования огромного количества разношёрстных библиотек разной степени давности. Просто не надо так делать. Кстати, такие случаи возникают обычно в случае использования всякого клиентского Javascript. Учитывая то, что в примере данной статьи клиентский javascript собирается той же нодой, Go не даёт ровным счётом никакой выгоды.

В node и похапэ затраты будут значительно больше на деплой, сопровождение, отладку, тестирование.

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

на каждый чих надо прикручивать интеграцию со сторонними инструментами на подобие redis или memcached

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

отлично масштабируются на все ядра процессора, в отличие от однопоточного nodejs.

Опять повторюсь — если это нужно, то все ядра нагружаются кластером.

извращаться с shared memory при взаимодействии между процессами nodejs

Wut?

В Go затраты будут значительно меньше, поскольку...

У вас правда затраты измеряются исключительно затратами на железо? И снова повторюсь — большая часть затрат (опять же, если у вас не лютый хайлоад) — не на железо, а на время разработчиков. Время PHP разработчиков в 3-4 раза дешевле, чем Go разработчиков. Время Node.JS разработчиков в 1.5-2 раза дешевле, чем время Go разработчиков. В 99% случаев время окупаемости затрат на более дорогую разработку стремится к бесконечности. Аргумент про «содержат меньше багов» я просто опущу, поскольку это полнейший холивар.
jehy
0
Имейте совесть и смотрите бенчмарки, которые приводить в пример.
Там сравнивается производительность Go с кодом из пяти строк и использованием нативных библиотек с производительностью ноды с экспрессом. Если вы не в курсе, экспресс — один из самых универсальных и тяжёлых серверов для ноды. Всё то же самое можно было бы написать в такое же количество строк кода на нативных библиотеках, и работало бы это минимум раз в пять быстрее. Минимум.

Вот так вот и выглядит вся популяризация Go. Сделать любой подлог, только чтобы получить зрелищные бенчмарки. Стыдно должно быть.
jehy
0
Ещё раз повторяю. Приведённые тесты заведомо некорректны. И дело не в тюнинге (если упарываться, то можно хоть CUDA прицепить), а в фундаментальном непонимании принципов работы технологии. Попытайтесь просто это понять. Больше мне добавить нечего.