Дмитрий perfect_pixel

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

Всем привет!

Начну с небольшой предыстории.

Свой новый проект я решил попробовать сделать на Vue.js. Мне нужен был серверный рендеринг (SSR), CSS модули, code-splitting и прочие прелести. Разумеется, для повышения производительности разработки нужна была горячая перезагрузка (HMR).

Я не хотел использовать готовые решения, типа Nuxt.js, т.к. при разрастании проекта важно иметь возможность кастомизации. А любые высокоуровневые решения, как правило, не дают этого делать, или дают, но с большими усилиями (был похожий опыт с использованием Next.js для React).

Основная проблема локальной разработки при использовании серверного рендеринга и горячей перезагрузки состояла в том, что мало запустить один webpack-dev-server. Мы должны также что-то сделать с исходниками, которые запускает Node.js, иначе при следующей перезагрузке страницы мы получим код, который не был обновлен на сервере, но обновился на клиенте.

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

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

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

Можно пойти обычным путем – скопировать сайт и доработать его на своей машине, или же писать все прямо на работающий сайт (так лучше не делать).



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

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

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

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

Привет, Хабр!

Не так давно я понял, что работа с CSS во всех моих приложениях — это боль для разработчика и пользователя.

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

^{Гора Пику образовалась очень задолго до прихода колонистов, ещё когда ломалась геологическая плита на Азорах. Высота Эвереста 8848 метров. А Пику — 8449 метров. Из которых 2351 метр приходятся на надводную часть, а остальное — гора под водой. То есть люди уже живут на склоне где-то в районе верхушки.}

Представьте, что вы португальский колонист. Вам достался совершенно офигенный остров, состоящий почти полностью из базальта. И совсем немного — из почвы. Куда ни ткнись, везде атмосфера, напоминающая замок «Инферно» из Героев. Если просто стоять на берегу, скоро на зубах начнёт скрипеть от базальтовой и туфовой крошки. Потому что остров образовался всего 60-70 тысяч лет назад.

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

Потом вы живёте тут год и успеваете построить дом из окаменелой лавы. Посадить немного растений (на земле, которую вы очистили от лавы) и сделать себе новую лодку. Но не из лавы, а из дерева.

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

Anfangen ist leicht, Beharren eine Kunst (Начинать — легко, продолжать — искусство)
Немецкая пословица

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

Чего воду в ступе толочь, вступления писать, сразу к делу.

Первый слой – кто хочет?

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

Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?

Если собрать всех – например, программистов – и спросить: кто хочет что-то изменить в отделе, компании или отрасли? – то руки поднимут больше половины. Почему до конца, до реальных изменений, полезных и заметных, доходят эти несчастные доли? Где, и почему теряются остальные?

Этот процесс чем-то напоминает воронку, как в продажах. Помните же воронку продаж? Она показывает, сколько обращений переходят в деньги. Выглядит примерно так:


Ой, не то. Вот так:


Попробуем разобраться — кто, где отвалился и почему.

Итак, первый, самый широкий слой воронки – те, кто поднял руку.

В наше время использование HTTPS становится обязательным для всех сайтов и веб-приложений. Но в процессе разработки возникает проблема корректного тестирования. Естественно, Let’s Encrypt и другие CA не выдают сертификаты для localhost.

Традиционно есть два решения.

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

Как запустить асинхронные циклы по порядку или параллельно в JavaScript?

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

Области видимости в JavaScript всегда были непростой темой, особенно в сравнении с более строго организованными языками, такими, как C и Java. В течение многих лет области видимости в JS особенно широко не обсуждались, так как в языке попросту не было средств, которые позволяли бы существенно повлиять на сложившуюся ситуацию. Но в ECMAScript 6 появились некоторые новые возможности, которые позволяют разработчикам лучше контролировать области видимости переменных. Эти возможности в наши дни уже очень хорошо поддерживают браузеры, они вполне доступны для большинства разработчиков. Однако новые ключевые слова для объявления переменных, учитывая ещё и то, что старое ключевое слово var никуда не делось, означают не только новые возможности, но и появление новых вопросов. Когда использовать ключевые слова let и const? Как они себя ведут? В каких ситуациях всё ещё актуально ключевое слово var? Материал, перевод которого мы сегодня публикуем, направлен на исследование проблемы областей видимости переменных в JavaScript.

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

Я всегда был фанатом багов и уязвимостей «на поверхности», всегда завидовал чувакам, которые пишут эксплойты для самых защищённых ОС, а сам умел только скрипткиддить (термин из нулевых). Однако мой пост про уязвимости в системах контроля версий набрал более 1000 лайков на Хабре и остаётся топ1 постом за всю историю Хабра, несмотря на то, что был написан 9(!) лет назад.

И сегодня я хотел бы на пальцах показать и рассказать про такую штуку, как вардрайвинг. А точнее, как стандартными средствами MacOS можно добыть пароли от Wi-Fi соседей. Нелёгкая забросила меня на очередную квартиру. Как-то исторически сложилось, что я ленивый. Пару лет назад я уже писал, что моя лень, новая квартира и провод Beeline (бывшая Corbina) помогли мне найти багу у Билайна и иметь бесплатно интернет в их сети. «Сегодня» происходит «подобное», я на новой квартире, нет даже провода, но есть много сетей у соседей.


Заколебавшись расходовать мобильный трафик, я решил, что «соседям надо помогать», и под «соседями» я имел введу себя…

«Компания» — оператор связи ПАО «Мегафон»
«Нода» — сервер RabbitMQ.
«Кластер» — совокупность, в нашем случае трех, нод RabbitMQ работающих как единое целое.
«Контур» — совокупность кластеров RabbitMQ, правила работы с которыми определяются на стоящем перед ними балансировщике.
«Балансировщик», «хап» — Haproxy – балансировщик, выполняющий функции переключения нагрузки на кластеры в рамках контура. Для каждого контура используется пара серверов Haproxy, работающих параллельно.
«Подсистема» — публикатор и/или потребитель сообщений, передаваемых через кролика
«СИСТЕМА» — совокупность Подсистем, являющая собой единое программно-аппаратное решение, используемое в Компании, характеризующееся распределённостью по всей территории России, но обладающее несколькими центрами, куда стекается вся информация и где происходят основные расчёты и вычисления.
СИСТЕМА – географически распределённая система – от Хабаровска и Владивостока до Санкт-Петербурга и Краснодара. Архитектурно это несколько центральных Контуров, разделенных по особенностям подсистем, к ним подключённым.

Искусственный интеллект был создан для принятия организационных решений и государственного управления; он нуждается в человеческой этике, заявляет Джонни Пенн из Кембриджского университета

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

Рассмотрим информатику. Его происхождение прослеживается не только аналитической философией, чистой математикой и Аланом Тьюрингом, но и что удивительно, историей государственного управления. В книге «Правительственная машина: революционная история компьютера», изданной в 2003 году, Джон Агар из Университетского колледжа Лондона рисует диаграммы развития британской гражданской службы, как она увеличилась с 16 000 сотрудников в 1797 году до 460 000 к 1999 году. Он заметил, аномальное сходство между функциональностью человеческой бюрократии и электронно-вычислительной машиной. (Он признался, что не может утверждать, было ли это наблюдение тривиальным или глубоким).

Обе системы обрабатывали большое количество информации, используя иерархию предварительно установленных, но адаптируемых правил. Но один из них происходил от другого. Это показало важную связь между организацией социальных структур людей и цифровыми инструментами, предназначенными для их обслуживания. Г-н Агар связывает само происхождение информатики с Аналитической маши́ной Чарльза Бэббиджа, разработанной в 1820-х годах в Британии. Ее разработка была субсидирована правительством, предполагая, что она будет служить его спонсору. Проекты Бэббиджа, отмечает г-н Агар, следует рассматривать как «материализацию государственной деятельности».

Использование SVG-картинок в качестве плейсхолдеров — это очень неплохая идея, особенно в нашем мире, когда чуть ли не все сайты состоят из кучи картинок, которые мы пытаемся асинхронно подгружать. Чем больше картинок и чем более объемные они, тем выше вероятность получения различных проблем, начиная от того, что пользователь не совсем понимает, а что же там собственно грузится, и заканчивая известным скачком всего интерфейса после прогрузки картинок. Особенно на плохом интернете с телефона — там может и на несколько экранов все улететь. Именно в такие моменты заглушки приходят на помощь. Еще один вариант их использования – это цензура. Бывают такие моменты, когда нужно скрыть от пользователя какую-то картинку, но хотелось бы сохранить общий стиль страницы, цвета и место, которое картинка занимает.

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

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3

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

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

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

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

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

TL;DR — за два года маленькая команда из 2 человек (я как «строитель», и мой московский друг как главный конструктор) сумела спроектировать раму и механику дорожного электробайка, а так же построила его первый прототип. Собственно, на КПДВ — именно этот самый прототип, да. Видео тестовых покатушек — в конце статьи.

Если вам интересна история его создания — прошу под кат.