Основные возможности платформы Hexlet не доступны в вашем браузере. Пожалуйста, обновитесь.
13 дней назад, Natalia Bass

РазработкаОписание современного JavaScript для динозавров

Изучать современный JavaScript — болезненно, если вы не знакомы с ним с самого его рождения. Экосистема разрастается и меняется с такой скоростью, что сложно разобраться с тем, какие проблемы пытаются решить разные инструменты. Я начал программировать в 1998 году, но к серьёзному изучению JavaScript приступил только в 2014. В то время я помню как анализировал Browserify и изумлённо смотрел на его слоган:

Browserify позволяет запрашивать (require) модули в браузере, объединяя все зависимости.

Можно сказать, я не понимал ни слова в этом предложении, и с трудом осознавал, насколько это может быть полезно мне, как разработчику.

Цель этой статьи — показать исторический контекст развития инструментов JavaScript до их уровня в 2017. Начнём с самых первых моментов и построим шаблон веб-сайта, как бы это сделали динозавры — без инструментов, чистый HTML и JavaScript. Затем мы будем пошагово вводить различные инструменты, чтобы на практике видеть, какие задачи они решают — поочерёдно. Благодаря историческому контексту у вас будет больше возможностей изучить и лучше адаптироваться к бесконечно меняющемуся JavaScript. Давайте начнём!

Читать дальше →
13 октября 2017, Natalia Bass

РазработкаВосхождение по бесконечной лестнице абстракций

Это перевод статьи Climbing the infinite ladder of abstraction от Алексис Кинг.

Я начала программировать ещё в начальной школе.

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

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

Кирпичная стена невыразительности

Когда только начала программировать, я в основном забавлялась с ActionScript и Java, просто ковыряясь в разных возможностях и пытаясь увидеть, что из этого получится. Это было очень увлекательно, я получала удовольствие от решения задач: зацепило меня почти мгновенно, но я также довольно быстро столкнулась с разочарованиями. Если говорить точнее, я начала писать много кода, который выглядел примерно так:

public String getName() {
  return this.name;
}

public void setName(String name) {
  this.name = name;
}
Читать дальше →
02 октября 2017, Natalia Bass

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

Специалисты Facebook обнаружили, что их боты общаются на новом языке. И остановили их.

Боб: “I can can I I everything else.”

Элис: “Balls have zero to me to me to me to me to me to me to me to me to.”

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

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

«Не было никакого смысла придерживаться английского», — говорит Дхрув Батра, инженер Georgia Tech из Facebook AI Research (FAIR). Учитывая то, что эти два агента конкурировали за лучший результат — это такая высокоэффективная схватка ИИ против ИИ — инженеры модифицировали «генеративно-состязательную сеть», и ни у одного из ботов не стало стимула общаться как люди. Поэтому они стали отклоняться от нормы и смешивать реальные слова в кажущиеся бессмысленными предложения.

«Агенты будут отклоняться от понятного языка и изобретать кодовые слова для себя», — говорит Батра, высказываясь в пользу уже предсказуемого явления, которое встречается тут, тут, и тут. «Как если бы я сказал «оно» пять раз, а вы бы поняли, что мне нужны пять копий определённого предмета. Это не сильно отличается от того, как сообщества людей придумывают сокращённые понятия».

Читать дальше →
26 сентября 2017, Natalia Bass

РазработкаГлобальное изменяемое состояние

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

Определение

Global mutable state содержит в себе три слова, каждое из которых имеет важное значение:

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

Mutable — означает изменяемый (в русскоязычной среде часто говорят «мутабельный», — прим. ред.). Часто можно заметить: все, что может прочитать значение, может так же и изменить его. Два считывания данных, следующих одно за другим, могут возвращать разные значения. Или, что еще хуже, сами возвращаемые структуры данных изменяются после чтения.

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

Читать дальше →
01 сентября 2017, Natalia Bass

РазработкаПрагматичное функциональное программирование

Подвижка в сторону функционального программирования произошла, признаться честно, около десяти лет назад. Мы заметили, что языки вроде Scala, Clojure, and F# начали привлекать внимание. Это было больше, чем приычный энтузиазм — "О, круто, новый язык!". Было что-то выделявшее его, по крайней мере мы так думали.

Закон Мура обещал нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Этот закон работал с 1960 до 2000. А затем остановился. Вообще. Частота тактовых импульсов достигла 3Гц и перестала подниматься. Скрорость света была достигнута. Сигналы не могли проходить сквозь поверхность чипа настолько быстро, чтобы реализовать более высокие скорости.

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

Читать дальше →
25 августа 2017, Артем Арбатский

РазработкаЧто такое callback-функция в JavaScript?

Это перевод статьи Брэндона Морелли "JavaScript: What the heck is a Callback?"

Что такое коллбэк?

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

Чуть сложнее: В JavaScript функции – это объекты. Поэтому функции могут принимать другие функции в качестве аргументов, а также функции могут возвращать функции в качестве результата. Функции, которые это умеют, называются функциями высшего порядка. А любая функция, которая передается как аргумент, называется callback-функцией. Чтобы лучше разобраться, давайте посмотрим на примерах, как это выглядит.

Зачем нам нужны коллбэки?

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

function first(){
  console.log(1);
}
function second(){
  console.log(2);
}
first();
second();
Читать дальше →
19 июля 2017, Natalia Bass

РазработкаЯзык для программирования

Это перевод статьи Артёма Чистякова "The language of programming", породившей интересные дискуссии на HackerNews и Reddit.

Я помню, как изучал свой первый язык программирования. Мы должны были освоить какой-то из диалектов BASIC в рамках обязательной школьной программы по информатике для второго класса. Скрючившись на своих партах под тусклыми флуоресцентными лампами, мы нетерпеливо поглядывали на жужжащие компьютеры IBM, расставленные вдоль стен душной классной комнаты. Это был 1997 год, Россия. Ни у кого из нас не было домашнего компьютера. На доске в меловых разводах учитель написала:

SCREEN 15, 0
PSET (100, 100)
DRAW "R20 D20 L20 U20"
END
Читать дальше →
09 июля 2017, Арбатский Артём

РазработкаКак программист автоматизировал свою работу и теперь мучается вопросами морали

когда все запрограммировал, и отдыхаешь

Перевели для вас небольшой пост со StackExchange, в котором юзер под ником Etherable делится историей о своей нелегкой кодерской жизни.

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

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

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

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

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

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

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

Что думаете, коллеги? Стоит ли парню рассказать о своем маленьком секрете и потерять хорошую работу? (вернее, потерять отличный источник пассивного дохода :D)

Оригинальный топик

Читать дальше →
29 июня 2017, Арбатский Артём

РазработкаКак читать код: 8 принципов, которые стоит запомнить

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

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

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

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

Читать дальше →
06 июня 2017, Rakhim Davletkaliyev

РазработкаНесдержанное обещание статической типизации

Это перевод статьи Даниэля Лебреро, которая также была опубликована на dev.to (там в комментариях есть интересное обсуждение на английском).

Меня удивил дядюшка Боб в посте под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".

Это утверждение не всем пришлось по душе. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы — как доказательства) делает юнит-тесты ненужными. Haskell даже утверждает, что "если скомпилировалось, то обычно работает".

Будь это уменьшение багов, улучшенное документирование, более продвинутая поддержка IDE или простота понимания, для меня все это означает одно обещание: меньше багов.

А я ненавижу баги. Я считаю, что баги — одно из худших сжирателей времени и энергии в проекте. Нет ничего, что раздражает меня сильнее, чем слышать в демо в конце итерации гордое «мы сделали Х стори-пойнтов и исправили 20 багов! Ура!».

По мне так это звучит как «В прошлой итерации мы написали более 20 багов, но наши клиенты смогли найти лишь 20! И нам заплатили и за их написание, и за их исправление. Ура!»

Читать дальше →
Мы учим программированию с нуля до стажировки и работы. Попробуйте наш бесплатный курс «Введение в программирование» или полные программы обучения по Node, PHP и Java. Хекслет

Подробнее о том, почему наше обучение работает →