null преобразуется в строку «null», а потом пытается его конвертировать. Но для оснований от 0 до 23 не существует чисел, в которые машина может конвертировать это слово, поэтому возвращается NaN. На позиции 24 находится «n», 14-я буква латинского алфавита, она складывается с числом. На позиции 31 находится «u», 21-я буква, она тоже складывается, после чего можно декодировать всю строку. На позиции 37 уже не получится сгенерировать валидное число, поэтому возвращается NaN.
Можно подробнее про «складывается с числом», «после чего можно декодировать всю строку» и «позицию 37»? Не совсем понятно, что с чем складывается, почему после преобразования буквы «u» можно декодировать всю строку и откуда взялось 37.
.
Если не ошибаюсь, тот тут происходит преобразование null > «null», затем каждый символ проверяется на наличие в системе с основанием 23. Например, символ «n» там есть, равен 23 ((от 1 до 9) + (от «a» до «n»)).
Символ «u» из слова «null», в свою очередь, отсутствует в системе с основанием 24, так как равен 30 ((от 1 до 9) + (от «a» до «u»)), так что прекращаем разбор строки и возвращаем 23
Некоторые критики считают, что по своей гениальной концептуальности песня без звука Мезрахи не уступает чёрному квадрату Малевича.
Серьезно? Критики? Человек выложил пустой трек, чтоб решить конкретную проблему и в этом усмотрели 'гениальную концептуальность'?
Что с этими критиками ребятами не так?
if (d == 1) if (pob.x > Math.round(gP.width / s) * s) pob.x = 0;
Что такое pob, например? И как расшифровывается gP?
Сделать понятные имена и раскидать код по отдельным функциям, как предложено выше — и все комменты из кода можно будет убрать.
Сейчас комменты несут в себе расшифровку кода, а не пояснение действительно сложных алгоритмов/решений/паттернов и т.д.
Не холивара ради, но код без скобок больше подвержен ошибкам при изменении. Надо всегда держать в голове "если там одно действие, то добавить скобки".
В моей практике было несколько случаев, когда при изменении кода, забывали добавить скобки. Отловить ошибку иногда бывает очень сложно.
Главный императив разработки ПО — управление сложностью. Я думаю, что в эту сложность можно вкладывать и сложность поддержки. Чем меньше лишних условий, не относящихся к цели модифицирования кода, требуется учесть, тем лучше. Если я меняю ветку if, я не хочу усложнять себе задачу, проверяя наличие скобок.
Согласен, но как часто процесс разработки проходит по идеальному пути?
Ну разделить представление и логику обычно можно, если заранее на это закладываться. Потому что, как я уже писал ранее, представление зависит только от формата данных, а это уже не архитектурное решение. От дизайна может зависеть более низкоуровневая реализация (к кому обратиться за данными, в каком формате вернуть, сколько записей и т.д.), но никак не архитектура.
В таком случае дизайн это очень и очень широкое понятие
Понятие не то, что бы широкое, скорее нет чёткого однозначного определения, немного путается с архитектурой.
Вот этот переходный этап в некоторых случаях зависит от того как должно выглядеть приложение
По моему, это нормально. Как раз таки когда верхнеуровневая архитектура разработана, можно спускаться ниже и прорабатывать конкретные слои (компоненты, модули). В том числе — механизм взаимодействия с внешним видом.
У меня опыта мобильной разработки мало, так что, возможно, я не совсем в теме, хотя, как мне кажется, общие принципы архитектуры, они едины
При чем тут дизайн? Так ведь эти вещи связаны напрямую. Что будет в основе самого приложения: вкладки внизу или боковая панель с разделами?
По-моему, архитектор не должен брать в расчёт такие детали дизайна, так как они связаны только с отображением, но никак не с архитектурой в целом. Иначе при изменении вкладок на панель, нам нужно будет пересматривать всю архитектуру.
Какие данные нам будет передавать серверная часть? А в каком виде она будет передавать те или иные данные?
Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).
В идеале, дизайн никак не должен зависеть от архитектуры. Есть данные, которые нужно отобразить и которые имеют какой то определённый формат. При изменении внешнего вида, ничего меняться не должно. Это в общем обычный MVC паттерн Вам скажет.
Шутка, конечно, смешная. Но что, если у меня ещё не было дня рождения в этом году?)
Статья фактически о наследовании в jS, а не об ООП. Будет продолжение?
Можно подробнее про «складывается с числом», «после чего можно декодировать всю строку» и «позицию 37»? Не совсем понятно, что с чем складывается, почему после преобразования буквы «u» можно декодировать всю строку и откуда взялось 37.
.
Если не ошибаюсь, тот тут происходит преобразование null > «null», затем каждый символ проверяется на наличие в системе с основанием 23. Например, символ «n» там есть, равен 23 ((от 1 до 9) + (от «a» до «n»)).
Символ «u» из слова «null», в свою очередь, отсутствует в системе с основанием 24, так как равен 30 ((от 1 до 9) + (от «a» до «u»)), так что прекращаем разбор строки и возвращаем 23
Серьезно? Критики? Человек выложил пустой трек, чтоб решить конкретную проблему и в этом усмотрели 'гениальную концептуальность'?
Что с этими
критикамиребятами не так?Пример
или
Что такое pob, например? И как расшифровывается gP?
Сделать понятные имена и раскидать код по отдельным функциям, как предложено выше — и все комменты из кода можно будет убрать.
Сейчас комменты несут в себе расшифровку кода, а не пояснение действительно сложных алгоритмов/решений/паттернов и т.д.
Не холивара ради, но код без скобок больше подвержен ошибкам при изменении. Надо всегда держать в голове "если там одно действие, то добавить скобки".
В моей практике было несколько случаев, когда при изменении кода, забывали добавить скобки. Отловить ошибку иногда бывает очень сложно.
Главный императив разработки ПО — управление сложностью. Я думаю, что в эту сложность можно вкладывать и сложность поддержки. Чем меньше лишних условий, не относящихся к цели модифицирования кода, требуется учесть, тем лучше. Если я меняю ветку if, я не хочу усложнять себе задачу, проверяя наличие скобок.
Скажите, а при чем тут netcat?
-1
В одной строке вариант написания атрибутов с одной кавычкой (value=''), с двумя (name=«password») и вообще без них (type=hidden)
Ну разделить представление и логику обычно можно, если заранее на это закладываться. Потому что, как я уже писал ранее, представление зависит только от формата данных, а это уже не архитектурное решение. От дизайна может зависеть более низкоуровневая реализация (к кому обратиться за данными, в каком формате вернуть, сколько записей и т.д.), но никак не архитектура.
Понятие не то, что бы широкое, скорее нет чёткого однозначного определения, немного путается с архитектурой.
По моему, это нормально. Как раз таки когда верхнеуровневая архитектура разработана, можно спускаться ниже и прорабатывать конкретные слои (компоненты, модули). В том числе — механизм взаимодействия с внешним видом.
У меня опыта мобильной разработки мало, так что, возможно, я не совсем в теме, хотя, как мне кажется, общие принципы архитектуры, они едины
По-моему, архитектор не должен брать в расчёт такие детали дизайна, так как они связаны только с отображением, но никак не с архитектурой в целом. Иначе при изменении вкладок на панель, нам нужно будет пересматривать всю архитектуру.
Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).
В идеале, дизайн никак не должен зависеть от архитектуры. Есть данные, которые нужно отобразить и которые имеют какой то определённый формат. При изменении внешнего вида, ничего меняться не должно. Это в общем обычный MVC паттерн Вам скажет.
Всё это, конечно, сугубо моё мнение.
Что мотивирует Вас использовать такие названия таблиц?