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

Технология веб-сокет позволяет в веб-приложении или в мобильном приложении реализовать отправку сообщений с сервера на клиент, что невозможно сделать средствами REST-API. Для работы с веб-сокетами часто используют библиотеку socket.io, или же разработчики работают с нативными объектами веб-сокет браузеров. В этом сообщении я попытаюсь показать, что оба пути не решают всех проблем, и гораздо лучше использовать для работы с веб-сокетами специализированные серверы, например mqtt-сервер (раньше его назвали mqtt-брокер).

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

Хочется, чтобы забот перед Новым годом было меньше, а праздничного настроения — больше. Не всегда это получается. Нужно закрывать месяц. Нужно закрывать год. Если задуматься, нужно закрывать целое десятилетие. И если вы еще не успели подобрать все-все-все подарки, мы в Madrobots готовы прийти на помощь.

Под катом — динозавр, робот-шар, спорткар начала XX века и еще несколько любопытных вариантов.

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

Но тут проблема: если вы собираете НЧ с помощью привычных Яндекс.Вордстата и Планировщика Google, ваши конкуренты делают то же самое. Решение — найти НЧ, о которых ваши конкуренты не догадываются (а если и догадываются, то не все). Рассказываем, как это сделать.

Нано-нейрон — это упрощенная версия нейрона из концепции нейронной сети. Нано-нейрон выполняет простейшую задачу и натренирован на конвертацию температуры из градусов Цельсия в градусы Фаренгейта.

Код NanoNeuron.js состоит из 7 простых JavaScript функций, затрагивающих обучение, тренировку, предсказание, прямое и обратное распространение сигнала модели. Целью написания этих функций было дать читателю минимальное, базовое объяснение (интуицию) того, как же все-таки машина может «обучаться». В коде не используются сторонние библиотеки. Как-говорится, только простые «vanilla» JavaScript функции.

Эти функци ни в коей мере не являются исчерпывающим руководством по машинному обучению. Множество концепций машинного обучения в них пропущено или же упрощено! Это упрощение допущено с единственной целью — дать читателю самое базовое понимание и интуицию о том, как машина в принципе может «учиться», чтобы в итоге «МАГИЯ машинного обучения» звучала для читателя все более как «МАТЕМАТИКА машинного обучения».

Что если взять замечательную математику (а именно линейные уравнения) и наш не менее замечательный JavaScript, а потом наложить одно на другое? То в условиях ограничений и специфики js-среды простая математическая задача может обернуться весьма любопытной и полной подводных js-камней проблемой. На прошедшей конференции HolyJS 19 в Москве одно такое линейное уравнение (среди прочих задач от компании SEMrush) наделало не мало шума.



И да, это снова рубрика Занимательного JavaScript'а: прошу под кат всех неравнодушных.

Всем привет!

В пятницу мы провели небольшой опрос среди пользователей мобильного интернета на тему «Какие версии веб-страниц вы предпочитаете просматривать на смартфоне?». Прошло некоторое время и мы можем подвести итоги опроса.

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

Мои исходные данные: небольшая близорукость, -1 диоптрия, но всего лишь 20% остроты — видел только две строчки. Очки или линзы мне были неудобны, поэтому я решил сделать операцию. Выбор сводился всего к двум типам — Femto lasik или Smile.

Фемто — проверенный и надежный метод, а про Smile я узнал по статьям хабре от клиники Шиловой. Однако, когда я начал копать дальше, то понял, что у метода Smile есть один серьезный недостаток — человеческий фактор.

2 года назад я сделал операцию femto lasik и до сих пор ей доволен — сразу после операции мое зрение имело 120% остроты, а сейчас находится в районе 100%. Мои друзья и знакомые интересуются и спрашивают, стоит ли им делать Smile. Я немного устал объяснять всем одно и то же, поэтому и решил написать статью на хабре, в которую собрал всю информацию, которую смог найти.

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

REST — чрезвычайно популярная архитектура веб-приложений. Для вызова функций на сервере используются обычные HTTP-запросы с задаваемыми параметрами (для структуризации параметров обычно используют JSON или XML), при этом, строгого стандарта для REST-архитектуры не существует, что добавляет ей гибкости (и, конечно, немного хаоса).

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

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

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

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

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

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

Казалось бы, какой пост может быть о CSS Flexbox в 2019 году? Верстальщики уже несколько лет активно используют данную технологию, и все тайны должны быть разгаданы.

Однако, недавно у меня возникло стойкое ощущение, что нужно поделиться одним нетривиальным и, на мой взгляд, полезным приёмом, связанным с flexbox. Написать пост побудил тот факт, что ни один знакомый (из учеников, верстальщиков и просто людей, близких к web), не смог решить задачку, связанную с flexbox, хотя на это нужно всего 4-6 строк.

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

Объектно-ориентированное программирование принесло в разработку ПО новые подходы к проектированию приложений. В частности, ООП позволило программистам комбинировать сущности, объединённые некоей общей целью или функционалом, в отдельных классах, рассчитанных на решение самостоятельных задач и независимых от других частей приложения. Однако само по себе применение ООП не означает, что разработчик застрахован от возможности создания непонятного, запутанного кода, который тяжело поддерживать. Роберт Мартин, для того, чтобы помочь всем желающим разрабатывать качественные ООП-приложения, разработал пять принципов объектно-ориентированного программирования и проектирования, говоря о которых, с подачи Майкла Фэзерса, используют акроним SOLID.



Материал, перевод которого мы сегодня публикуем, посвящён основам SOLID и предназначен для начинающих разработчиков.

Примечание

Перед вами – перевод свободной онлайн-книги Майкла Нильсена «Neural Networks and Deep Learning», распространяемой под лицензией Creative Commons Attribution-NonCommercial 3.0 Unported License. Мотивацией к его созданию послужил успешный опыт перевода учебника по программированию, "Выразительный JavaScript". Книга по нейросетям тоже достаточно популярна, на неё активно ссылаются авторы англоязычных статей. Её переводов я не нашёл, за исключением перевода начала первой главы с сокращениями.

Желающие отблагодарить автора книги могут сделать это на её официальной странице, переводом через PayPal или биткоин. Для поддержки переводчика на Хабре есть форма «поддержать автора».

Введение

Этот учебник подробно расскажет вам о таких понятиях, как:

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

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

И снова здравствуйте! Сегодня хотелось бы написать мини пост и ответить на вопрос — «Зачем удалять зубы мудрости, если они не беспокоят?», и прокомментировать утверждение — «Моим родственникам и друзьям, папе/маме/деду/бабуле/соседу/коту — удаляли зуб и всё пошло не так. Абсолютно у всех были осложнения и теперь никаких удалений». Для начала, хотелось бы сказать, что осложнения возникли не от факта удаления зуба, а от того, как это удаление было проведено. Подобное могло случиться по нескольким причинам:

1. Исчезновение
2. Прибрежный бродяга
3. Золотая жила
4. Заговоры
5. Возможный сценарий
6. Капитан
7. Истина

1. Исчезновение

Тихой лунной ночью 8 марта 2014 года Боинг 777-200ER, эксплуатируемый Malaysia Airlines, вылетел из Куала-Лумпура в 0:42 и повернул в сторону Пекина, поднявшись на предназначенный ему эшелон 350, то есть на высоту 10 650 метров. Обозначение авиакомпании Malaysia Airlines — MH. Номер рейса — 370. Самолетом управлял Фарик Хамид, второй пилот, ему было 27 лет. Это был его последний тренировочный рейс, после которого его ждало завершение сертификации. Действиями Фарика руководил командир воздушного судна, человек по имени Захари Ахмад Шах, который в 53 года был одним из самых старших капитанов в Malaysia Airlines. По малайзийским обычаям, его звали просто Захари. Он был женат и имел троих взрослых детей. Жил в закрытом коттеджном посёлке. Имел два дома. В первом доме у него был установлен авиасимулятор, Microsoft Flight Simulator. Он регулярно летал на нем и часто писал на онлайн-форумах о своем хобби. Фарик относился к Захари с почтением, но тот не злоупотреблял своей властью.

В салоне самолёта находились 10 бортпроводников, все малайзийцы. Им предстояло позаботиться о 227 пассажирах, включая пятерых детей. Большинство пассажиров были китайцами; из числа остальных 38 были малайзийцами, а прочие (в порядке убывания) были гражданами Индонезии, Австралии, Индии, Франции, США, Ирана, Украины, Канады, Новой Зеландии, Нидерландов, России и Тайваня.

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

Сегодня вашему вниманию предлагается весьма дискуссионная статья, затрагивающая важный аспект философии "Чистого Кода". Автор статьи берет на себя смелость утверждать, что в большинстве случаев комментарии в коде вредны, но также не забывает указать, когда без них не обойтись.



Поэтому — читаем внимательно и, несмотря ни на что, комментируем.