rebase переносит МОИ изменения поверх ИХ изменений. Соответсвенно ревьювить то, что недавно прошло ребейз гораздо удобнее, чем просто набор чьих-то изменений. Особенно удобно, когда вы занимаетесь ревью постоянно. Каждый коммит для вас выглядит продолжением предыдущего. И это, намой взгляд, принципиально правильно.
Попробуйте правильно вмержить ветку, которая опирается на коммит недельной давности. Если Вы работаете с большими проектами, то Вы несомненно получите много радости от повторного исправления багов, повторного тестирования фич и много чего еще повторного.
Ну как зачем? Чем ниже уровень инструкций, тем ближе результат к желаемому, независимо от языка.
Что же до «равного» исполнения js — во Файерфоксе, например, нет концепции скрытых классов, которая есть в V8. То есть язык один, код один, а исполняется по-разному (имеется ввиду скорость, не результат выполнения). И для оптимальной работы писать нужно тоже по-разному.
В то же время, если бы у нас была одна VM с одним набором инструкций — то автоматически важным становится только транслятор (с любого исходного языка на общепринятый конечный байт-код), а не браузер, исполняющий код.
Хех, будущее наступит скорее, если поставщики браузеров договорятся и предоставят единую виртуальную машину языка низкого уровня. И вот тогда да — пиши однажны, используй везде. А до этого момента пиши однажды, портируй всегда =)
Я всегда полагал, что диалект это и есть подмножество/ответвление языка.
Предлагаю задуматься над тем, зачем вообще нужен asm.js. На мой взгляд чтобы javascript в браузере быстро работал. И именно javascript, так как у нас есть уже огромное количество кода на нем и нам нужно его оптимизировать. То есть что бы не думали авторы о предназначении asm.js, использоваться он будет именно теми, кто пишет на js, а не теми кому в шутку хочется что-то портировать на js.
Это нисколько не умаляет достоинств asm.js, равно как и не делает написание кода на C/C++ полезным, с учетом того что он будет портирован в js.
Позиционируется:
«как писать на js чтобы было быстро и язык не менялся»
Является:
«как писать на очередном диалекте js, который мы теперь тоже поддерживаем»
Вообще стоит, наверное, учитывать, что масштабировать пласт логики (а это .NET vs PHP в данном примере) не так уж и сложно — ну поставил hadoop в качестве распредилителя нагрузки, ну настроил его один раз. Проблемы нет. Облако (Azure) лишь это и дает в данном случае.
Если и есть проблема перехода с А на Б, то это проблема с масштабированием хранилища и очередей запросов к нему. Но это вряд ли проблема платформы, как правило хранилище — это не часть платформы, а отдельная сущность.
То есть, резюмируя: вопрос масштабирования системы в большей части связан с хранением данных, нежели с платформой для их обработки.
Почему нельзя использовать byte[] в качестве ключа в HashMap?
Очень удивился, прочитав название. Прочитал весь пункт целиком и хочу сказать, что я бы задал этот вопрос, например, так: «почему важно знать как работает equals для массивов?». Потому что в общем и целом разницы с другими типами нет, объекты действительно разные.
Ну, я конечно, не джавист, но все же считаю что такие вещи, как передача поссылке, должны быть очевидны любому специалисту.
Отличная статья, спасибо!
Это просто замечательно, спасибо! =)
Попробуйте правильно вмержить ветку, которая опирается на коммит недельной давности. Если Вы работаете с большими проектами, то Вы несомненно получите много радости от повторного исправления багов, повторного тестирования фич и много чего еще повторного.
Что же до «равного» исполнения js — во Файерфоксе, например, нет концепции скрытых классов, которая есть в V8. То есть язык один, код один, а исполняется по-разному (имеется ввиду скорость, не результат выполнения). И для оптимальной работы писать нужно тоже по-разному.
В то же время, если бы у нас была одна VM с одним набором инструкций — то автоматически важным становится только транслятор (с любого исходного языка на общепринятый конечный байт-код), а не браузер, исполняющий код.
Предлагаю задуматься над тем, зачем вообще нужен asm.js. На мой взгляд чтобы javascript в браузере быстро работал. И именно javascript, так как у нас есть уже огромное количество кода на нем и нам нужно его оптимизировать. То есть что бы не думали авторы о предназначении asm.js, использоваться он будет именно теми, кто пишет на js, а не теми кому в шутку хочется что-то портировать на js.
Это нисколько не умаляет достоинств asm.js, равно как и не делает написание кода на C/C++ полезным, с учетом того что он будет портирован в js.
«как писать на js чтобы было быстро и язык не менялся»
Является:
«как писать на очередном диалекте js, который мы теперь тоже поддерживаем»
Если и есть проблема перехода с А на Б, то это проблема с масштабированием хранилища и очередей запросов к нему. Но это вряд ли проблема платформы, как правило хранилище — это не часть платформы, а отдельная сущность.
То есть, резюмируя: вопрос масштабирования системы в большей части связан с хранением данных, нежели с платформой для их обработки.
Очень удивился, прочитав название. Прочитал весь пункт целиком и хочу сказать, что я бы задал этот вопрос, например, так: «почему важно знать как работает equals для массивов?». Потому что в общем и целом разницы с другими типами нет, объекты действительно разные.
Ну, я конечно, не джавист, но все же считаю что такие вещи, как передача поссылке, должны быть очевидны любому специалисту.