Про школу – это больше к тому, что стаж виден по одному ключевому слову)
А про var в консоли – почему-то не задумывался о таком применении, просто писал window.b = ... (эффект тот же). Забавна, кстати, разница в поведении браузеров. В консоли хрома и сафари
И не надо. Достаточно вместо передачи bind(...) передавать стрелочную (ну или обычную, но не использующую this) функцию-обёртку, вызывающую метод класса с нужным this.
Если нужно частичное каррирование, можно например Sugar.js .fill использовать, там можно так:
Ну да, но проще
let b = (name, end) => a(name, 'Doe', end);
ЗЫ: Вижу джаваскриптера стпрой школы, ещё с привычкой к var :-)
Выкачать почти наверняка можно, и это, скорей всего, не механика. Чинить – я бы ему после такого уже не доверял. Единственный вопрос – обратиться к спецам (у них, если что, есть доноры для пересадки и т.п., чтобы стянуть инфу в тех условиях, где у вас не получится) или сэкономить и делать самому (тоже выглядит реальным, возможные подходы вам подсказали, но больше риск добить диск).
Ну да, чтобы пустые страницы реюзать и таким образом равномерно распределять износ. Я к тому, что для TRIM нужна информация от операционной системы, какие страницы пустые, а для рефреша можно даже без этого обойтись: знай себе иди последовательно и не спеша по всем страницам и читай-пиши их. Ну или раз уж у тебя есть информация от TRIM – перемещай на новое место :-)
Ну и через bind можно привязать не только this, но и любой аргумент. Но новичков я бы учил для начала привязывать через замыкания, bind/call/apply – в продвинутый курс.
Раз в полгода – это с запасом взято. Я погуглил – у современных SSD рефреш куда сложнее устроен, с учётом ошибок, износа и т.п. Но в это даже вникать не требуется, достаточно знать, что SSD нужно питание, а за рефреш (как и за размазывание износа по всем ячейкам) отвечает он сам.
Зачем таблицы? Зачем время записи для ячейки? Идём по циклу по всем ячейкам – так, чтобы за полгода все обойти. Хранить достаточно номер последней обновлённой ячейки (ну, это для случая, когда контроллер всегда включён).
Но это самая тупая реализация, можно и получше придумать. Например, команда TRIM позволит не заниматься регенерацией свободного места.
ЗЫ: Погуглил – в современных контроллерах используется более продвинутая реализация, реально отслеживающая, какие страницы долго не трогали: "Data refresh ❑ Refresh pages with long retention ages".
Раньше программа писалась одним человеком для одного компьютера с одним пользователем, и она работала с десятком-другим килобайт памяти.
Скучаю по таким задачкам :-). Сейчас такое – совсем редкость, не бывает достаточно мелких прог, которые можно было бы оптимизировать до упора... Пишешь что-то большое, думая в основном о том, как его потом поддерживать.
Так лишние уровни абстракции не от хорошей жизни появляются. И простой код в ваших примерах – потому что вы решаете простую задачу. Но в целом да, принцип KISS (keep it simple, stupid) никто не отменял. И, в принципе, современные языки помогают придерживаться этого принципа. Сравните Swift с Objective C и C++ или Kotlin с Java.
Ну, претензий дофига, но перейдя на него с Visual Studio (ну, так случилось, что перешёл с винды на мак) – ощутил, что стало удобнее. Лучше отладчик, лучше системное API (ну, это не заслуга XCode, но та же инфраструктура) и т.п.
Ну и, конечно, глупо говорить "избегайте XCode". Надо называть альтернативы и говорить, чем они лучше. Потому как XCode – стандарт для программирования приложений под MacOS и iOS, и альтернативным IDE нужно иметь очень веские преимущества.
Мне кажется, при изучении JavaScript следует как можно дольше избегать использования this, ибо сделано это слово крайне странно.
Собственно, примерно всегда можно обойтись замыканиями – может, чуть менее эффективно, но шансов выстрелить себе в ногу, передав куда-то метод без объекта (так что он вызовется неизвестно с каким this внутри) – куда меньше.
И начинать его использование, уже умея обходиться без него и понимая, что это такое в js (вообще не то же самое, что в других языках).
Я бы не стал дожидаться. 6 месяцев хранения – достаточный критерий, чтобы обновить страницу, не дожидаясь её порчи. Это проще, чем раз в неделю проверять – не пора ли обновлять?
Но, в принципе, это даёт некоторый простор для оптимизации энергопотребления.
30 лет назад нормой было "стажировку" проходить, пока ещё учишься. Если хочешь нормальную работу после вуза – ты должен работать (пусть и не зарабатывая толком) с третьего курса.
Оверхед минимальный: переписать терабайт (или какой там объём диска) в течение полугода. Потерей ресурса можно пренебречь: за 10 лет каждая ячейка перезапишется аж 20 раз.
Да сколько того ресурса надо для "поддержания штанов"? Раз в полгода ячейку перезаписать – это, получается, за 10 лет она будет переписана 20 раз, беда, беда, огорчение.
Ну как-то не очень светлая идея – доводить до несовпадения ECC. Как и требовать чтения для обновления блока. SSD должен просто работать, без танцев с бубном, и редко используемые файлы не должны портиться. Благо, сделать это не очень трудно.
Именно что периодически проходить по всем ячейкам. Это необходимость (иначе файлы, которые долго не использовались, однажды не прочтутся). И довольно-таки уверен, что в большинстве SSD это сделано (а вот во флешках и SD-картах – не факт). Так что в комменте выше, как и предполагает его автор, это баг в прошивке. По сравнению с SSD TRIM – очень простая операция, нужен один счётчик и просто идти, обновляя блок за блоком в определённом темпе.
Что касается ресурса – перезапись ячейки, допустим, раз в месяц его точно не исчерпает :-)
Про школу – это больше к тому, что стаж виден по одному ключевому слову)
А про var в консоли – почему-то не задумывался о таком применении, просто писал window.b = ... (эффект тот же).
Забавна, кстати, разница в поведении браузеров. В консоли хрома и сафари
ведт себя совсем по-разному. var одинаково.
И не надо. Достаточно вместо передачи bind(...) передавать стрелочную (ну или обычную, но не использующую this) функцию-обёртку, вызывающую метод класса с нужным this.
Ну да, но проще
ЗЫ: Вижу джаваскриптера стпрой школы, ещё с привычкой к var :-)
Выкачать почти наверняка можно, и это, скорей всего, не механика. Чинить – я бы ему после такого уже не доверял.
Единственный вопрос – обратиться к спецам (у них, если что, есть доноры для пересадки и т.п., чтобы стянуть инфу в тех условиях, где у вас не получится) или сэкономить и делать самому (тоже выглядит реальным, возможные подходы вам подсказали, но больше риск добить диск).
Ну да, чтобы пустые страницы реюзать и таким образом равномерно распределять износ.
Я к тому, что для TRIM нужна информация от операционной системы, какие страницы пустые, а для рефреша можно даже без этого обойтись: знай себе иди последовательно и не спеша по всем страницам и читай-пиши их. Ну или раз уж у тебя есть информация от TRIM – перемещай на новое место :-)
Или через стрелочные функции.
Ну и через bind можно привязать не только this, но и любой аргумент. Но новичков я бы учил для начала привязывать через замыкания, bind/call/apply – в продвинутый курс.
Да даже если писать инструменты: "всё должно делаться через одно место", если хэш считается git – и надо вызывать для этого git.
Раз в полгода – это с запасом взято. Я погуглил – у современных SSD рефреш куда сложнее устроен, с учётом ошибок, износа и т.п. Но в это даже вникать не требуется, достаточно знать, что SSD нужно питание, а за рефреш (как и за размазывание износа по всем ячейкам) отвечает он сам.
Зачем таблицы? Зачем время записи для ячейки? Идём по циклу по всем ячейкам – так, чтобы за полгода все обойти. Хранить достаточно номер последней обновлённой ячейки (ну, это для случая, когда контроллер всегда включён).
Но это самая тупая реализация, можно и получше придумать. Например, команда TRIM позволит не заниматься регенерацией свободного места.
ЗЫ: Погуглил – в современных контроллерах используется более продвинутая реализация, реально отслеживающая, какие страницы долго не трогали: "Data refresh
❑ Refresh pages with long retention ages".
Скучаю по таким задачкам :-). Сейчас такое – совсем редкость, не бывает достаточно мелких прог, которые можно было бы оптимизировать до упора... Пишешь что-то большое, думая в основном о том, как его потом поддерживать.
Так лишние уровни абстракции не от хорошей жизни появляются. И простой код в ваших примерах – потому что вы решаете простую задачу. Но в целом да, принцип KISS (keep it simple, stupid) никто не отменял. И, в принципе, современные языки помогают придерживаться этого принципа. Сравните Swift с Objective C и C++ или Kotlin с Java.
Ну, претензий дофига, но перейдя на него с Visual Studio (ну, так случилось, что перешёл с винды на мак) – ощутил, что стало удобнее. Лучше отладчик, лучше системное API (ну, это не заслуга XCode, но та же инфраструктура) и т.п.
Ну и, конечно, глупо говорить "избегайте XCode". Надо называть альтернативы и говорить, чем они лучше. Потому как XCode – стандарт для программирования приложений под MacOS и iOS, и альтернативным IDE нужно иметь очень веские преимущества.
Мне кажется, при изучении JavaScript следует как можно дольше избегать использования this, ибо сделано это слово крайне странно.
Собственно, примерно всегда можно обойтись замыканиями – может, чуть менее эффективно, но шансов выстрелить себе в ногу, передав куда-то метод без объекта (так что он вызовется неизвестно с каким this внутри) – куда меньше.
И начинать его использование, уже умея обходиться без него и понимая, что это такое в js (вообще не то же самое, что в других языках).
Я бы не стал дожидаться. 6 месяцев хранения – достаточный критерий, чтобы обновить страницу, не дожидаясь её порчи. Это проще, чем раз в неделю проверять – не пора ли обновлять?
Но, в принципе, это даёт некоторый простор для оптимизации энергопотребления.
30 лет назад нормой было "стажировку" проходить, пока ещё учишься. Если хочешь нормальную работу после вуза – ты должен работать (пусть и не зарабатывая толком) с третьего курса.
Это куда лучше, чем их потерять.
Оверхед минимальный: переписать терабайт (или какой там объём диска) в течение полугода. Потерей ресурса можно пренебречь: за 10 лет каждая ячейка перезапишется аж 20 раз.
На картинке вижу для TLC 8 уровней.
Интересно, почему она трёхуровневая (Triple-Level Cell), если для трёх битов нужно 8 уровней?
Да сколько того ресурса надо для "поддержания штанов"? Раз в полгода ячейку перезаписать – это, получается, за 10 лет она будет переписана 20 раз, беда, беда, огорчение.
Ну как-то не очень светлая идея – доводить до несовпадения ECC. Как и требовать чтения для обновления блока. SSD должен просто работать, без танцев с бубном, и редко используемые файлы не должны портиться. Благо, сделать это не очень трудно.
Именно что периодически проходить по всем ячейкам. Это необходимость (иначе файлы, которые долго не использовались, однажды не прочтутся). И довольно-таки уверен, что в большинстве SSD это сделано (а вот во флешках и SD-картах – не факт). Так что в комменте выше, как и предполагает его автор, это баг в прошивке.
По сравнению с SSD TRIM – очень простая операция, нужен один счётчик и просто идти, обновляя блок за блоком в определённом темпе.
Что касается ресурса – перезапись ячейки, допустим, раз в месяц его точно не исчерпает :-)