В 21:00 по Киеву
⎡04⎦ Производительность JavaScript и типы данных: Числа / Number.

Особенности использования JavaScript типа Number, которые оказывают влияние на производительность работы JS-кода.

Small integer, Int8, Int16, Int32, Float64, UInt и другие особенности работы современного JavaScript RunTime, которые значимым образом влияют на производительность выполнения кода.

https://www.youtube.com/watch?v=YntHgxlmKy4

Програмка за сегодня:

Уже состоялось:
⎡msk⎦ Разбор вопроса из Telegram о Array Double vs Array SMI
В телеграм, от Влада пришел вопрос: как так могло получиться в его тесте, что Array Double оказался заметно быстрее Array SMI.
Пробуем в живую разобраться и понять в чем может быть: либо проблема теста, либо проблема Мурыча, когда он утверждает что должно быть наоборот.
https://www.youtube.com/watch?v=vgHNERQGcPk




Впереди 21-00 по Киеву:
⎡msk⎦ Разбирем видео: "Я 💛 Фронтенд. Как это можно переписать?" и поищем верное решение

На скорости полтора, посмотрит видео, где JavaScript специалисты предлагают решения к задаче:
Создать функцию, которая принимает на вход число N и возвращает массив размером N и который будет содержать числа от 1 до N, таким образом, что:
1) каждое число, которое кратно трем, было бы представлено, не сами числом, но строкой "Fizz",
2) каждое число кратное семи, было бы представлено строкой "Buzz",
3) и каждое число которое, одновременно, кратно и 3 и 7 было представлено строкой "Fizz Buzz".

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

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

https://www.youtube.com/watch?v=MSLHs4z6sE4

Сегодня в 22:00 по Киеву.
⎡msk⎦ Разбираем вопрос JavaScript собеседований о передаче по ссылке и по значению

Раз и навсегда, строго в соответствии со спецификацией, закрываем вопрос о мифе с передачей параметров по значению и по ссылке.

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

https://www.youtube.com/watch?v=wn4O3Pq6zYE

В 04:00 по Киеву.
⎡msk⎦ Разбираем видео: "Сравнение языков программирования Java vs JavaScript"

На скорости полтора, посмотрит видео, где автор канала с over 300K подписчиков, сравнивает два языка: Java и JavaScript таким образом, что создается стойкое ощущение как будто - либо автор вообще ничего не понимает в программировании, либо нарочно записал видео таким образом, чтобы вызвать бурю в стакане.

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


https://www.youtube.com/watch?v=3GgfeCy8WuY

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

Приглашаем всех желающих.
Будем рады.)

t.me/AsForJsTalks

20:30 по Киеву.
⎡msk⎦ RegExp JavaScript Strings и Unicode

https://www.youtube.com/watch?v=yGNltdKMtF8

Тем, кто умеет рисовать и может/хочет помочь со следующей задачей:
Для обложки "книжки" мне нужна картинка. По своей сути напоминающую ту, что прикреплена. Где какойто обьект переполнен деталями, которые могут выглядеть совершенно ненужными.
Это не обязательно должен быть именно дом, замок. Это может быть что угодно - хоть франкенштейн о 7 руках и 8 ногах.
Даже набросок на салфетке подойдет.

На habrahabr появилась очередная статья, которая пытается научить гуманитариев вроде меня тому, чем являются числа с плавающей точкой.

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

Вот статья: https://habr.com/ru/articles/745640/
Вот комментарий: https://habr.com/ru/articles/745640/#comment_25725790
Вот ссылка на перевод главы о которой я говорю в самом конце: https://habr.com/ru/articles/337260/

Этот материал, возник как попытка аргументировано ответить @RNG_r на его комментарий https://t.me/AsForJsTalks/5593

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

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


Мы выносим за скобки саму математику - она для пояснения моего тезиса совершенно не важна. Важно понимание общего принципа.


⎡1. Проблематика⎦
В программировании, мы неизбежно сталкиваемся с рядом типовых задач, которые уже кто-то когда-то решал до нас.
Способы решения подобных типовых задач исследованы вдоль и поперек и зафиксированы в форме соответствующего решению алгоритма.

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

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

Big O нотация - это ОДИН ИЗ механизмов (существуют еще Тета нотация, Сигма нотация и так далее), позволяющих дать оценку алгоритму в плоскости необходимых для выполнения алгоритма шагов (ресурс процессора) и обьемом требуемой, для выполнения этих шагов, памяти ( оперативной, дисковой и т.д.)

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


⎡1.1. Проблематика => пример⎦
Стоит задача, найти первый индекс заданного символа в любом текстовом файле подаваемом на вход алгоритму.
Мы можем, прочитать условной одной командой весь файл в память и сделать поиск символа.
Такой алгоритм будет иметь наиболее выгодные цифры эффективности алгоритма с точки зрения необходимых для выполнения шагов. И наименее эффективные цифры с точки зрения потребления памяти.

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

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


⎡1.2. Проблематика => Резюме⎦
То есть мы для себя выяснили, что необходимость в оценке сложности алгоритма, появилась как ответ на необходимость иметь наглядный эффективный способ представления алгоритма, который бы позволил программисту, без необходимости вникать в его детали, принять решение (спрогнозировать) - удовлетворяет ли алгоритм, тем условиям в которых он решает задачу.

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

Запомнили, что оценка вычислительной сложности в плоскости О нотации и ей подобных,
опирается на две фундаментальные характеристики:
1) количество шагов, которое необходимо выполнить для реализации алгоритма. Чем оно меньше - тем эффективнее характеристика.
2) и оценка необходимого количества памяти для обеспечения функционирования этиъ шагов