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

Для случаев без кодоизврата (а их большинство) можно использовать такой код:

code = code
// ключевые слова (список неполон, написал, что в голову пришло)
.replace(/(var|function|typeof|new|return|if|for|in|while|break|do|continue|switch|case)([^a-z0-9\$_])/gi,
'<span class="kwrd">$1</span>$2')
// всякие скобочки
.replace(/(\{|\}|\]|\[|\|)/gi,'<span class="kwrd">$1</span>')
// однострочные комментарии
.replace(/(\/\/[^\n\r]*(\n|\r\n))/g,'<span class="comm">$1</span>')
// строки
.replace(/('.*?')/g,'<span class="str">$1</span>')
// функции (когда после идентификатора идет скобка)
.replace(/([a-z\_\$][a-z0-9_]*)\(/gi,'<span class="func">$1</span>(')
// не люблю восьмизначные табы, пусть лучше будет 4 пробела
.replace(/\t/g,'    ');

Фигура Джона Кармака в индустрии компьютерных игр (далее по тексту КИ) неоднозначна. Существует большое количество слухов и скандалов, связанных с его именем. Многие считают его неприятным человеком, и многие также считают его гением. Эти два свойства, кстати, не взаимоисключающи. Можно быть не самым приятным в общении человеком, но при этом делать удивительные вещи. В этой публикации мы не рассматриваем все заслуги Джона перед КИ, не обсуждаем его прения с членами команды, и не стараемся раскопать наибольшее количество скандалов. Даже историю Id Software затрагиваем не полностью, лишь вскользь касаясь пройденных Джоном вех.

Любой разработчик со стажем и любой отдавший всю свою жизнь индустрии может быть предметом глубоких исследований, множества публикаций, и даже книг. Однако все понимают, надеюсь, как много нужно времени, чтобы собрать всю эту информацию воедино, проверить и сопоставить факты, связаться с фигурантами, выработать четкую стратегию изложения. Чем больше проходит времени, тем плотнее пелена истории покрывает удаляющиеся от нас годы, откуда можно было бы извлечь знание. Одно дело если ты был очевидцем его, если читатель (или писатель) представляет старый пласт игроков и пласт людей интересующихся. Совсем другое дело если с материалом знакомятся люди, которые вообще не знакомы с играми Wolf3D, Doom, Quake и кому наборы букв IDDQD и IDKFA ничего не говорят. Как рассказать все и не утомить читателя? Как сосредоточиться на главном? Как не потратить недели и месяцы на публикацию казалось бы ненужной статьи?

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

От переводчика

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

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

Почему я решил перевести этот текст (ведь он короткий и не особо насыщенный откровениями)? Потому, что это выступление Кармака. А он, как-никак, знаковая фигура в отрасли разработки ПО. То, что написано ниже, показывает отрыв теории разработки ПО от практики. Ведь, если эти мысли посещают такого разработчика и выносятся на QuakeCon, — то что тогда творится в головах рядовых прикладных программистов?

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

Простота — дух эффективности. // A. Freeman

В октябре прошлого года «Мой круг» пригласили на РИФ Воронеж сделать доклад про профессиональное выгорание среди ИТ-специалистов. Как всегда, мы подошли основательно, провели по этой теме соцопрос среди пользователей «Моего круга» и «Хабра» и сегодня рады поделиться своим исследованием. Посмотрим, насколько ИТ-специалисты подвержены выгоранию, какие его признаки выделяют, на какие причины указывают, как выходят из него.

Большинство вопросов анкеты строилось на материалах мастер-класса Наталии Дзеружинской, доктора медицинских наук, профессора, врача-психиатра высшей квалификационной категории, проведённого ею в рамках «Школы менеджеров «Стратоплан»» (видеозаписи 5 мастер-классов школы).

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

Как мы узнали, более 50% ИТ-специалистов имеют опыт профессионального выгорания, причём половина из них прошли через этот опыт 2 и более раза. Для работодателя подобное выгорание сотрудников имеет довольно серьёзные последствия: до 20% сотрудников находятся регулярно в подобном состоянии, только 25% выгорающих остаётся на прежнем месте работы. А значит, довольно большая часть сотрудников работает крайне неэффективно и мешает другим, плюс постоянно нужно вкладывать средства в рекрутинг и адаптацию новых сотрудников взамен выгоревших. Если работодатель научится управлять процессом выгорания, то сможет экономить много материальных и моральных сил для своей компании.

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

DeepMind, дочерняя компания Alphabet, которая занимается исследованиями в области искусственного интеллекта, объявила о новой вехе в этом грандиозном квесте: впервые ИИ обыграл человека в стратегии Starcraft II. В декабре 2018 года свёрточная нейросеть под названием AlphaStar размазала профессиональных игроков TLO (Дарио Вюнш, Германия) и MaNa (Гжегож Коминц, Польша), одержав десять побед. Об этом событии компания объявила вчера в прямой трансляции на YouTube и Twitch.

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

Пару месяцев назад я начал заниматься проектом под названием malicious-packages (ака "вредоносные пакеты"). Он следит за обновлениями в npm репозитории, скачивает все новые модули, а затем проверяет их на вшивость — ищет сетевую активность, подозрительные операции с файловой системой и т.д. Даже маленькие проекты на node.js часто имеют большое дерево зависимостей, и у разработчиков физически нет возможности проверить их все. Это даёт злоумышленникам огромный простор для манёвра, и возникает вопрос — сколько же всякой гадости прячется по тёмным углам npm registry? 180000 проверенных пакетов спустя я получил примерный ответ.

Весной 2018 года я купил легкий электросамокат, за лето проехал 2500 км и на личном опыте ощутил преимущества. Благодаря самокату, я не спускался в метро и не стоял в пробках в душных автобусах — заменив их на ветер в лицо, крики чаек и панорамы петербургских набережных. На проезде (включая такси) за четыре месяца я сэкономил 20.000р — половину месячного дохода.

Теперь электросамокатом мало кого удивишь. Но если люди непосвященные видят это «как факт» — изнутри электро-сообщества было видно, как этот процесс последние два года развивался по экспоненте.

Я хотел бы рассказать ещё об одном процессе, который пока не заметен извне. Люди с самокатов пересаживаются на моноколёса. Миграция в девяти случаях из десяти идёт в этом направлении. На вопрос «какой самокат выбрать» в чатах отвечают не тратить время и сразу выбирать колесо.

Транспорт будущего уже здесь, только вы этого еще не поняли.

Привет. 24–25 сентября в Москве прошла конференция фронтенд-разработчиков HolyJs https://holyjs-moscow.ru/. Мы на конференцию пришли со своим стендом, на котором проводили quiz. Был основной квиз — 4 отборочных тура и 1 финальный, на котором были разыграны Apple Watch и конструкторы лего. И отдельно мы провели квиз на знание react.

Под катом — разбор задач квиза по react. Правильные варианты будут спрятаны под спойлером, поэтому вы можете не только почитать разбор, но и проверить себя :)

Поехали!

Мы старались сделать для вас что-то интересное и необычное. Очень надеюсь что у нас получилось. Нам не хотелось оставлять вас без ответов и объяснений почему именно так. Давайте разбираться.

Для начала хочу напомнить как проходил конкурс, было 4 тура по 15 вопросов про JS, 1 внеконкурсный тур на 15 вопросов про React и финал на 10 вопросов.

Под катом — разбор задач первых 4 туров.

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Этим постом мы завершаем серию публикаций о конкурсах Яндекс.Блиц в 2018 году. Надеемся, что вам довелось поучаствовать или хотя бы посмотреть, какие приближенные к продакшену задачи мы предлагаем. Последний контест был посвящен применению алгоритмов во фронтенде. Сегодня мы публикуем подробные разборы 12 задач: первые 6 из них предлагались в квалификационном раунде, а задачи 7–12 — в финале. Мы постарались объяснить, как формировались условия, на какие навыки мы обращали внимание. Спасибо всем участникам за проявленный интерес!

Задача 1

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

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

Будучи дилетантом в области разработки приложений, я испытал сложности с пониманием алгоритма работы обратной польской нотации, а если быть точнее — алгоритма подготовки стека. Делу так же мало помогли статьи в «интернетах».

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

Делу помогли две статьи. Одна из них на википедии, а вторая была написана замечательным пользователем хабра, GORKOFF, который объяснил все буквально «на пальцах».

Однако до конца я так и не понял тот важный вопрос: как же построить стек?

Построению карьеры посвящено много книг, фильмов, статей и даже песен. Я читал многие из них – прекрасные произведения. Но… Какие-то слишком они правильные, что ли.

В произведениях более легкого жанра – например, в песнях и фильмах – о построении карьеры сказано намного прозаичнее, зачастую – с юмором и иронией. Из того, что сразу приходит на ум, назову две песни – «Менеджер» группы Ленинград и, простите за идиому, «Попец» Сектора Газа (песня и правда так называется),

Но, как и положено легкому жанру, в них нет никакой системности, полноты, и примеров из жизни. Красиво, смешно – да. Но воспользоваться советами из песен не получится. По крайней мере, сюжет из приведенной выше песни Сектора Газа мне в жизни повторять не приходилось. А вот видеть, как его повторяют коллеги – сколько угодно.

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

Зачем парсить свой код? Например, для того, чтобы найти забытый console.log перед коммитом. А что делать, если вам надо изменить сигнатуру функции в сотнях вхождений в коде? Справятся ли тут регулярные выражения? В этой статье будет показано, какие возможности перед разработчиком открывают абстрактные синтаксические деревья.



Под катом — видео и текстовая расшифровка доклада Кирилла Черкашина (z6Dabrata) с конференции HolyJS 2018 Piter.

От переводчика:
Я не являюсь ни профессиональным программистом ни профессиональным переводчиком, но появление описанного в статье инструмента от создателя популярной библиотеки D3.js произвело на меня сильное впечатление.

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

Знакомьтесь, d3.express, интегрированная исследовательская среда.
(с 31 января 2018г d3.express зовется Observable и живет на beta.observablehq.com)

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

Последние лет восемь я разрабатывал инструменты для визуализации информации. Самым удачным результатом моих усилий стала js-библиотека D3. Однако опасность столь долгой разработки инструментария в том, что ты забываешь зачем ты это делаешь: инструмент становится самоцелью, польза от его применения уходит на второй план.

Предназначение инструмента визуализации — построение визуализаций. Но в чем же цель визуализации? Слово Бену Шнейдерману(Per Ben Shneiderman):

«Результат визуализации — это

Изначальная статья "Что всё-таки не так с наймом в IT?" многим порвала шаблон мышления месяц назад. Не все смогли адекватно воспринять суть трудового права. От шуток к делу, теперь слово берёт Министерство труда и социальной защиты Российской Федерации.

Ниже дословно:

В соответствии со статьей 64 Трудового кодекса Российской Федерации (далее — ТК РФ) необоснованный отказ в заключении трудового договора запрещается, если это не связано с деловыми качествами работника.
В целях проверки его соответствия поручаемой работе в трудовом договоре по соглашению сторон может быть предусмотрено условие об испытании работника (статья 70 ТК РФ).

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

Поэтому тестовое задание без трудового договора — это сразу ст.5.27. КоАП РФ:

• Соответственно 30-50 тыс. рублей за первое, и 50-70 тыс. рублей за каждое последующее нарушение для работодателя.
• Если работодатель отказывается признавать трудовые отношения, то ещё:
  
  • 50-100 тыс. рублей для работодателя, 100-200 тыс. рублей за повтор;
  • 3-5 тыс. рублей для конкретного работника, который выдал тестовое задание, 5-7 тыс. рублей за повтор.
• Невыплата зарплаты за тестовое задание — 30-50 тыс. рублей, 50-100 тыс. рублей за повтор.

Разбираемся под катом.

Хотите получить наглядное представление о том, что происходит с компонентами, когда вы работаете с React? Читайте под катом перевод статьи Ohans Emmanuel, опубликованной на сайте freeCodeCamp.