Та же история с велосипедом. О чем то думать можно только на низко-среднем пульсе, на среднем или высоком думать уже толком не получается. Ну еще думать не очень выходит после того как проедешь заметное расстояние. Как то через месяц после покупки велосипеда скатался на 70+ км, да еще и без быстро усваиваемой еды, так под конец в голове было только: «лишь бы до темноты успеть вернуться да не сдохнуть»
Ну по факту на работу уходит от 10 часов (обеденный перерыв, дорога), а если добавить еще всякие обязательные дела — свободного времени на обучение или хобби еще меньше остается. Так что по факту 8 — все же много.
Жизненно важно — наверно нечасто, к сожалению я теоретик, за пределы хеллоу ворлдов не выходил, так что примеров как за, так и против не привел бы, но выглядит это комфортнее как то для восприятия. По крайней мере если у нас нет другого явного способа выделить при чтении интерфейсы отдельно.
Черт, серьезно? Когда читал внимания не обратил, пусть даже в используемой мной платформе нет ООП, но странно что я это пропустил. А там нет уточнения что это для случаев когда интерфейс — это элемент языка, или что то в таком духе (к сожалению книга не под рукой сейчас)? Просто этот пункт странным кажется.
Имхо, тут как с паттернами, можно пытаться каждый раз объяснять просто (не факт что конкретный человек это сумеет, и не введет в заблуждение), а можно использовать общепринятую терминологию вроде тех же названий принципов в статье описанных, или ранее упомянутых мной паттернов. Общий словарь все же коммуникацию упрощает (меньше ошибок, неоднозначностей, слов, абстракция содержит больше полезных идей и меньше мусора, ну, в идеале).
Понять что есть лямбды нужно один раз, и дальше этот разработчик вполне будет читать код, так что код будет все еще прост. А вот всякие нагромождения тернарных операторов в тернарных операторах, или десятки параметров метода на километр — когнитивную нагрузку создают очень значительную, и каждый раз когда встречаются, и неважно что концепция разработчику знакома. Я бы уточнил формулировку из комментария выше:
код, который может понять даже человек не знакомый с этим конкретным языком программирования
, в случае знания концепций с использованием которых он был написан.
Брр, скайп полный трэш. По моим ощущениям он разве что на флагманах работать нормально будет, и то не факт. Впрочем скайп для десятки — тоже тот еще трэш.
Сейчас я бы тоже так сделал, или ВК написал бы, а скорее всего изначально бы упорнее пинал тех кто за шину отвечает, что они неправы когда говорят про присылают utf-8. Но когда ты джун который и года не проработал и тебе дают готовое решение генподрядчика которое у них где то уже работает — меньше всего будешь заниматься такими вещами.
К сожалению нет, давно было, к тому же потом выяснилось что необходимость перекодирования — из за настроек шины возникла, соответственно код этот выкинули после изменения настроек.
Был как то случай, из ком объекта массив байтов получали в кривой кодировке, так что в цикле их крутили, немного меняли значения. Бывало цикл со сложением внутри выполнялся несколько часов на 20-30кк операций.
Вот мы и вернулись к тому что все равно где то нужно фиксировать какие данные мы выгрузили и как то получать информацию что загрузка прошла успешно. И тут можно прикрутить что то свое, но лучше для упрощения все же платформенные методы использовать.
Для этого нужно получить подтверждение от мобилки что предыдущая пачка загружена, к тому же это может произойти не скоро, нужно хранить где то (либо ключи с мобилки возвращать) какие данные с регистрации снять. Да еще и убедиться что с прошлой выгрузки эти данные снова не менялись… В общем механизм тех же планов обмена с нумерацией сообщений и т.п. переизобретать. Зачем?
Ну ок, выгрузили в файл (впрочем с мобилкой файлы использовать очень странно, логично когда обмен напрямую через http), а файл кто то повредил или удалил. И что делать с потерянными данными?
Тогда так. Вот было бы здорово, если бы функция «ПланыОбмена.ВыбратьИзменения» принимала максимальный размер выбираемой пачки. Не сразу всё, что там накопилось, а например пачичку в 100 штук. На следующей итерации – ещё 100 штук. И так далее. Она и отрабатывать будет быстрее, если изменений много образовалось. И блокировать будет недолго.
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
, в случае знания концепций с использованием которых он был написан.
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.