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

Предисловие

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

Другой вариант тоже был любопытным. Фирма сочиняла эссе и курсовые для американских студентов, которым в лом было писать самим. Уже потом я узнал, что это довольно распространенный и прибыльный бизнес, которому даже придумали собственное название — «paper mill», но сразу такой способ зарабатывания на жизнь показался мне полным сюром. Однако же надо заметить, что интересных задач на этой работе оказалось немало и среди них — самая сложная и хитрая из тех, что я делал за свою карьеру, и которой можно потом с гордостью рассказывать детям.

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

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

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

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

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

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

Здесь будет длиннющая стена текста, с типа случайными мыслями. Основные идеи:

1. В C++ очень важно время компиляции,
2. Производительность сборки без оптимизаций тоже важна,
3. Когнитивная нагрузка ещё важней. Вот по этому пункту особо распространяться не буду, но если язык программирования заставляет меня чувствовать себя тупым, вряд ли я его буду использовать или тем более — любить. C++ делает это со мной постоянно.

Блогпост «Standard Ranges» Эрика Ниблера, посвященный ренжам в C++20, недавно облетел всю твиттерную вселенную, сопровождаясь кучей не очень лестных комментариев (это ещё мягко сказано!) о состоянии современного C++.

Даже я внёс свою лепту (ссылка):

Этот пример пифагоровых троек на ренжах C++20, по моему, выглядит чудовищно. И да, я понимаю, что ренжи могут быть полезны, проекции могут быть полезны и так далее. Тем не менее, пример жуткий. Зачем кому-то может понадобиться такое?

Давайте подробно разберём всё это под катом.

Перевод отрывка из интервью с создателем Node.js Раяном Далом (Ryan Dahl) в котором обсуждается модель программирования и язык Go.

— Расскажи нам, как проходила начальная разработка Node? Это ведь уже было достаточно давно, ты создал Node в 2009.

Райан: — Я думаю для себя лично, что нет лучшего момента в жизни, когда ты, как это говорится, «в потоке» и у тебя есть идея, в которую ты сильно веришь. И при этом есть время, чтобы сесть и на самом деле работать над ней. И я думаю, Node была именно такой идеей, которая ждала, чтобы её кто-то ухватил, и если бы не я, то это бы сделал кто-то другой. Но так случалось, что я был тогда достаточно свободен от работы и имел время, и мог работать нон-стоп несколько месяцев, которых как раз были нужны, чтобы выкатить начальную версию. Так что да, это был отличный период.

— Отлично, супер. Node построена на идее «полностью асинхронной» модели программирования. Удачна ли она была для Node?

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

Хотя сам продукт имел очень общее назначение, клиенты обычно использовали его для конкретных задач. Эти задачи выжимали максимум из CMS, а разработчикам приходилось искать решение проблем. После десяти лет работы в таком окружении я узнал огромное число способов, как может сломаться веб-приложение в продакшне. Некоторые из них обсудим в этой статье.

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

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

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:

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

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

Здравствуй (Это важно!) уважаемый читатель.

Если, читая эту статью, ты приложил руку к лицу и согнул спину – то в этой статье ты можешь взглянуть на свое возможное будущее. Моя болезнь развивалась скорее по травматическому сценарию, за 3-4 месяца сильно деформировалась поясница, а далее, как карточный домик деформировался весь позвоночник, за год, я познакомился с проблемами в каждом суставе: от коленки до 1-ой кости позвоночника после которой спинной мозг переходит в головной.
Патологии позвоночника имеют одну уникальную особенность, которой нет ни у одной другой болезни. Любая патология позвоночника – очень тяжелая… В прямом смысле – масса костей человека около 15 кг., и любая проблема в суставе имеет большой физический размер и очень часто проблему в суставе можно пощупать пальцами, а современные средства диагностики, позволяют даже заглянуть внутрь (МРТ, Рентген). Поэтому вряд ли у человека есть такой же орган, с настолько же понятными функциями и простотой наблюдения как позвоночник.

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

#пятничное

В нашей компании на данный момент есть три вакансии:

— Frontend-разработчик
— QA Инженер
— Младший UX/UI-дизайнер

И почти всю эту неделю мы проводим в нашем офисе собеседования кандидатов, некоторые из которых получаются довольно забавными. Например, один кандидат спросил, во что мы играем по локалке. На фоне этого в паблике ВК решили устроить небольшую развлекуху: «Провалите собеседование в компанию мечты (должность на выбор: фронтендер / бэкендер / дизайнер / сисадмин) с помощью 4 слов?». С первых минут в комментариях стало смешно — мы даже решили сделать небольшую подборку.

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



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

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

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

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

Продолжение цикла обзорных статей с конференции CppCon 2017.

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

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

Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].

Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.

Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.

Исходным текстом будет обычный Hello, world (hello.cpp):

#include <iostream>
int main()
{
        std::cout << "Hello, world!" << std::endl;
}

Ксения Каланова, выпускница нашего курса по копирайтингу и маркетолог в MERA, написала колонку для блога Нетологии о том, как заставить текст звучать «по-английски», даже когда до уровня Advanced еще далеко.

Вся моя жизнь связана с английским языком: школьные олимпиады, подготовка к вступительным экзаменам в вуз, пять лет на переводческом факультете, лето в США и путешествия по миру. В студенческие годы я работала письменным переводчиком, а сразу после выпуска — устным.

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

Если бы не опыт работы переводчиком, меня такие просьбы поставили бы в ступор. Ведь мой текст увидят иностранцы — клиенты компании, руководители!



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

Обновление: у этой статьи появилось продолжение, переведённое @achekalin. В каком порядке читать — на ваше усмотрение: в этой статье можно получить удовольствие от обширной попоболи автора, а в продолжении — от сделанных им выводов.

Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.

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

Промотаем нашу историю до 2016. Новая работа, новая компания, и хайп вокруг докера поднялся безумный. Разработчики уже выкатили докер в продакшен, так что сбежать с него не удастся. Хорошая новость в том, что команда run наконец-то заработала, мы можем запускать и останавливать контейнеры. Оно шевелится!

У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).

Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.