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


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

Современные научные представления говорят о существовании у процессов функционирования человеческого мозга определенных особенностей, которые:

• на личном уровне подталкивают к прокастинации;
• в стартапе по мере его успеха и роста приводят к потере прежней творческой «внутренней атмосферы» и нарастанию бюрократии;
• в больших компаниях приводят к «иерархическому регрессу».

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

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

У нас в солюшене 51 проект. В 10 из них используется TypeScript. Объем минимизированного JavaScript-кода ~1 MB. TypeScript-код одних проектов зависит от кода других проектов. Для многих React-компонентов используются глобальные переменные.

Все вместе это приводит к долгим часам отладки front-end кода. Чтобы упростить себе жизнь, мы внедрили Webpack. А по пути отловили грабли.

TL;DR

1. Устанавливаем node 7 + npm
2. Выполняем в консоли npm i -g webpack typescript
3. Устанавливаем Webpack Task Runner
4. Добавляем webpack.config.js
   в папку "основного" проекта
5. Добавляем webpack.config.part.js
   в папку каждого зависимого проекта

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

Речь пойдет о FuseTools — фреймворк для написания нативных мобильных приложений с потрясающими возможностями.

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

Коротко о боте: получает список YouTube-каналов пользователя и уведомляет о новых видео с возможностью напомнить о нем позже.

В статье расскажу об особенностях написания этого бота и взаимодействия с Google API. Я люблю краткость, поэтому в статье будет мало «воды».

На какие вопросы ответит статья:

• Где взять внешний адрес сайта для Webhook
• Где взять HTTPS-сертификат как его использовать, чтобы Telegram ему доверял
• Как передавать данные и обрабатывать нажатия на Inline-кнопки
• Как получить вечный OAuth токен для Google API
• Как передать данные пользователя через OAuth callback url
• Как получить бесплатный домен 3 уровня

Стэк:

1. Back-end: Node.js + Express.js
2. БД: Mongo.js + mongoose
3. Пакетный менеджер: Yarn (он действительно быстрый)
4. Telegram-бот фреймворк: Telegraf
5. Продакшн: Docker + Docker Compose + Vscale.io

Считается, что мир JavaScript бурно развивается: регулярно выходят новые стандарты языка, появляются новые синтаксические фишки, а разработчики моментально все это адаптируют и переписывают свои фреймворки, библиотеки и прочие проекты с тем, чтобы все это использовалось. Сейчас, например, если вы всё ещё пишете в коде var, а не const или let, то это уже вроде как моветон. А уж если функция описана не через стрелочный синтаксис, то вообще позор…

Однако, все эти const-ы, let-ы, class-ы и большинство других нововведений не более чем косметика, которая хоть и делает код красивее, но действительно острых проблем не решает.

Александр Крижановский ( krizhanovsky, NatSys Lab.)

По Сети уже давно бегает эта картинка, по крайней мере, я ее часто видел на Фейсбуке, и появилась идея рассказать про нее:

Денис Измайлов ( DenisIzmaylov )

Всем привет! Вкратце расскажу о себе. Я — Денис Измайлов. Последние 5 лет сосредоточился на JS-разработке, делал много Single Page Application, highload, React, выступал на MoscowJS несколько раз, каммитил webpack и т.д.

Сегодня хотел бы поговорить вот о чем: почему от Single Page Application в его классическом виде стоит отказаться; как изоморфные приложения отразятся на Вашей зарплате; и что вы будете делать на этих выходных?

Привет! Последние несколько лет я занимался фрилансом на Upwork (бывший oDesk) и вот наконец решился поделиться своим опытом и наблюдениями с Хабрасообществом в небольшом цикле статей. Начать хотелось бы издалека: кому на мой взгляд стоит рассмотреть фриланс как основной вид своей деятельности + хотелось бы разобрать основные «отпугивающие» факторы, которые мешают многим решиться. Кому небезразлична тема фриланса и Upwork в частности — добро пожаловать под кат.

Здесь описаны мои исследования, как сделать ревизию кода в команде более приятным занятием, которое может дать новый опыт всем участникам. У нас полностью географически распределённая команда, все коммуникации выполняются через интернет, и зачастую асинхронно. Мы используем Trello для описания возможностей продуктов, поодиночке создаём код, отправляем в GitHub пулл-реквесты, а также пользуемся встроенной в GitHub функцией их ревью. Это отличается от просмотра кода лицом к лицу в офисе и даже по видеочату.

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

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

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

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

Сегодня я поведаю о таком звере, как NativeScript(да, он изменился, да, сильно). NativeScript — фреймворк для кроссплатформенной разработки, придерживающийся концепции write once — use everywhere, и, возможно, у него получилось!

Настоящие программисты — это облака, big data, high load… А у нас — практически DIY. 2 установки — уже тиражирование, 100 штук — производство… Но зато атомные ледоколы, маневровые локомотивы, трактора, шлюзы, мосты, опускающиеся вниз от лишнего асфальта, беспилотники размером в дом, 50 человек персонала на цех длиной больше двух километров… и надежность, надежность, надежность… И пяток гендиректоров в костюмах прямо на поле при демонстрации системы на тракторе…


Обычное окончание отладки — убираем антенны с путеправильной машины

Итак… пришла просьба от коллег — написать ТКП (технико-коммерческое предложение) на хитрый GPS-трекер. И комментарии, что большие и настоящие делать отказались.

Конечно, многие скажут, что это ни-ни и писать для веба нужно только на PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.

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

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

Раньше у меня уже было веб-приложение на ассемблере — CMS для малого сайта. Только оно работает в режиме "один пишет, многие читают". При том, использует CGI интерфейс и поэтому "многие" читать одновременно тоже не получается.

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

Введение

8-9-го декабря 2016 года была проведена первая конференция по Angular в Бельгии. Игор Минар (ведущий разработчик Angular) выступил в качестве основного докладчика с несколькими интересными объявлениями относительно того, по какому графику будет выпускаться Angular. И представьте себе, в марте 2017 года нас ждет релиз Angular 4. При этом, на данный момент уже опубликована бета-версия.

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

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы выясним куда делась третья версия, и почему мы по-прежнему можем быть верны Angular. Сейчас начинающему фронтенд-разработчику, изучающему JavaScript, довольно трудно определиться: какой же фреймворк или библиотеку им взять и изучить, оставаясь в тренде? Конечно, без слова React, сейчас не обходится ни один разговор на тему фронтенда, однако, в свое время я начал с первой версии Angular, начитался много руководств по написанию фронтенда на ES6 (с классами и прочим добром) и до сих пор не жалею. Да, вы можете писать корпоративные приложения с использованием только jQuery, но по мере развития и сложности проекта вы начнете закапывать себя в спагетти-коде, смешивая логику и представление, MV*-фреймворки же этого сделать вам не дадут.

Геймдев — занятие по настоящему увлекательное, особенно когда в команде есть как опытные программисты, так и новички. В отличии от таких движков как Unreal и CryEngine, в Unity достаточно низкий порог вхождения, и зачастую ветераны .NET и новички начинают выяснять отношения, которые заканчиваются дракой с применением офисной мебели.

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

1. Пиши на UnityScript

Один язык в проекте — это скучно. Разнообразь жизнь своих коллег, пусть учаться быть полиглотами. C# — это майкрософт, и вообще строгая типизация это не твое.

2. Не используй var

Сами Unity запрещают^* это делать, да и вообще непонятно, какого типа переменная. Когда тебе скажут про подсказки IntelliSense — закатывай глаза, майкрософт головного мозга! Твой Notepad++ этого не умеет.

3. Смешивай стили

Ну а что? Сами Unity нарушают C# Style Guide и фигачат camelCase в пропертях, чем ты хуже? Если используешь MonoDevelop, не забывай периодически менять табы на пробелы и обратно. При этом говори всем, что в MonoDevelop «настройки слетели» — про этот баг все знают!

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



Я занимаюсь дизайном уже 16 лет, а в свободное время пишу музыку. Владение этими навыками утвердило меня в мысли, что интерфейсы должны объединять в себе как минимум звук и изображение. Команда из компании Udemy, где я сейчас работаю, в данный момент разрабатывает новый подход к обучению. В ходе мозгового штурма возникла идея подключить звуковые сигналы к промежуточным экранам. Я увлекся и стал экспериментировать с синтезатором and MIDI-сэмплами, чтобы обеспечить пользователю аудиофидбэк в процессе прохождения и завершения курса. Мы пробовали разные инструменты, аккорды и темп. Сложность заключалась в том, чтобы аудиоконтент осмысленно демонстрировал прогресс и вместе с тем, выражал ценности нашей компании. Какие звуки могут рассказать о нас? В итоге мы остановились на коротких, ненавязчивых мотивах в ля мажор, наигранных на маримбе и арфе.