Перед вами — первый материал из серии, посвящённой разработке полноценного веб-приложения, которое называется Budget Manager. Основные программные средства, которые будут использованы в ходе работы над ним — это Node.js для сервера, Vue.js для фронтенда, и MongoDB в роли базы данных.



Эти материалы рассчитаны на читателей, которые знакомы с JavaScript, имеют общее представление о Node.js, npm и MongoDB, и хотят изучить связку Node-Vue-MongoDB и сопутствующие технологии. Приложение будем писать с нуля, поэтому запаситесь любимым редактором кода. Для того, чтобы не усложнять проект, мы не будем пользоваться Vuex и постараемся сосредоточиться на самом главном, не отвлекаясь на второстепенные вещи.

Автор этого материала, разработчик из Бразилии, говорит, что ему далеко до JavaScript-гуру, но он, находясь в поиске новых знаний, готов поделиться с другими тем, что ему удалось найти.

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

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

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

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

404 страница. Это место для пасхалок, дурачества и креатива создателей сайтов. Про 404 ошибку есть даже выступление на TED.

Первая «4» — означает, что ошибка на стороне клиента, «04» — означает конкретную ошибку «Not Found».

Кому в пятницу нечего делать или кто в поисках вдохновения — добро пожаловать под кат, там подборка лучших (и худших) 404 страниц.

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

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

Я собираюсь показать вам все шаги, через которые я прошел, при создании моей ролевой игры в JavaScript.

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

В этой серии статей Альваро Виделла (соавтор книги «RabbitMQ in Action», предыдущие места работы: Apple, VMWare, EMC) поделится тем, как он попал в мир программирования. Он никогда не изучал IT в университете, но нашел способ обойти это.



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

В моем родном городе Дурасно, Уругвай, моя жена работала часами напролет за жалкие $160 (USD) в месяц. Да, это 1920 $ в год. Мы оба пожертвовали нашим временем, чтобы я смог стать учителем и нашел работу получше, потому что мы мечтали о лучшем будущем.

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

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

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

Данная публикация является переводом статьи «Introduction to commonly used ES6 features» под авторством Zell Liew, размещенного здесь. Перевод разделён на 2 части. Перевод 2-ой части находится здесь.

JavaScript серьезно развился в последние несколько лет. Если вы изучаете язык в 2017 году и при этом не касались ECMAScript 6 (ES6), то упускаете легкий способ читать и писать на нём.

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

Недавно мы опубликовали материал «Промисы в ES6: паттерны и анти-паттерны». Он вызвал серьёзный интерес аудитории, в комментариях к нему наши читатели рассуждали об особенностях написания асинхронного кода в современных JS-проектах. Кстати, советуем почитать их комментарии — найдёте там много интересного.



По совету пользователя ilnuribat мы добавили к материалу опрос, целью которого было выяснить популярность промисов, коллбэков и конструкций async / await. По состоянию на 9-е сентября промисы и async / await получили примерно по 43% голосов, с небольшим перевесом async / await, коллбэкам досталось 14%. Главный вывод, который можно сделать, проанализировав результаты опроса и комментарии, заключается в том, что важны все имеющиеся технологии, однако, всё больше программистов тяготеют к async / await. Поэтому сегодня мы решили опубликовать перевод статьи про переход на async / await, которая является продолжением материала о промисах.

Больше десяти лет я был PHP-разработчиком, но недавно перешёл на JavaScript, используя его серверные и клиентские возможности. До этого я уже был знаком с JS. Сначала работал с jQuery, потом освоил Angular, и, наконец, начал пользоваться React.

Когда я начинал писать на PHP, я встраивал его в HTML-файлы. Получался не код, а полный бардак. Поэтому, для того, чтобы привести мои разработки в приличный вид, я начал пользоваться фреймворками, в частности, ZF1 и ZF2. Через некоторое время подход, при использовании которого начинают разработку с API, привёл к тому, что у меня оказался сервер, состоящий из сгенерированных REST API и из нескольких сотен строк моего собственного кода.



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

Сегодня я расскажу, в основном, о своём путешествии с серверной стороны PHP на серверную сторону JS в виде Node.js. Здесь я не буду рассказывать о Webpack, React и о других клиентских технологиях JS.

^{Это краткий пересказ лекции Айры Гласса – ведущего и продюсера национального радио-шоу «This American Life» (Эта американская жизнь). Посвящается Данилу.}

---

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

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

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

О том как совершенствуется искусственный интеллект, можно судить по обычным играм. За последние два десятилетия алгоритмы превзошли лучших мировых игроков: сначала пали нарды и шашки, затем шахматы, «Своя Игра» (Jeopardy!), в 2015 году — видеоигры Atari и в прошлом году — Го.

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

Но как обстоит дело с играми с неполной информацией?

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

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.