Литература для задающихся таким вопросом публикуется буквально в каждом таком вопросе.
Макконнелл. Совершенный код.
Фаулер. Рефакторинг.
и т.д.
В терминологию типа "декомпозиции" упираться не надо, надо понять, чего ты хочешь от кода. А хочешь ты - чтобы можно было вывести код на один экран и о том коде, который остался за экраном, в это время вообще не вспоминать. Этого можно добиться, если нормально применять ООП, заворачивать в классы то, что нужно им и не нужно больше никому, минимизировать связи между ними, вовсе уничтожить знание одного кода о том, как работает другой (только - что он делает и как его об этом попросить) и тому подобные приемы со сложными терминологическими названиями, но довольно простой логикой, если в нее врубиться, освоить и не давать себе сделать "как проще и понятней", разводя говнокод.
P.S. и если хочешь врубиться, а не имитировать - забудь про лапшерезки ЧатГопоты и им подобные. Учебник и практика. Своей головой, а не псевдомозгом.
lazix, если бы я интересовался вашим вопросом, я бы для начала перевел оба файла в нейтральный формат типа BMP и проверил, совпадет ли результат. Чтобы говорить о том, что выкинуто было именно служебное и ненужное.
Размер форматов с потерями сильно зависит от того, насколько глубокий анализ исходного изображения был проведен (для поиска информации, от которой можно избавиться без особенной визуальной разницы). Даже при тех же характеристиках компьютерная программа может использовать больше ресурсов именно на этом этапе. А мобильное приложение - экономит время в ущерб результату.
Установка не преследуется вовсе. Преследуется - использование, и виновным оказывается - установивший.
Устаревших версий не бывает. У M$ есть политика даунгрейда, решающая эту проблему.
Где-то на полочке до сих пор валяется нераспечатанный MS Server 2008 Enterprise, потому что эти жадные ублюдки только его готовы были даунгрейдить до MS Server 2000 Advanced, на который безрукие дебилы залочили проданный с оборудованием софт.
Например, NextCloud на файловом сервере позволит давать ссылки на все файлы, которые на него накидали, и вообще будет удобен для просмотра и скачивания, если народ привыкнет.
Сергей Сахаров, и где вы увидели противоречие? Они же научились, полагаю? Значит, не дауны.
Или вы не смогли научить пользователей даже пользоваться архиватором?
В телефоне вполне может использоваться алгоритм сжатия, не самый оптимальный по размеру результата.
Зато, может, он вдвое быстрее, и покупатель сразу видит, какой у него крутой и шустрый телефон.
А сожранное место - это уже его проблемы.
я их не считаю за даунов, я знаю что они в 90% такие... спроси у любого сисАдмина)
Уточнение: они такие у любого сисадмина, который считает из за даунов и не снисходит до объяснений.
Если же админ без короны, то и пользователи нет-нет, да подтягиваются, разбираются и, что характерно, меньше дергают того же админа.
Drno, ТС уточнил диапазон своего "недорого" в комментах до того, как вы отправили ответ.
Адекватность - это, по-русски говоря, соответствие. Ваш ответ его запросам - не соответствует.
А логика, подразумевающая какую-то "абсолютную адекватность", сферическую в вакууме - заведомо порочна.
Drno, цена - это та реальность, от которой стоит отталкиваться. Соизмеряя шаги с длиной ноги, а не "как овощь" гоняясь за хайпом.
И уж цену надо смотреть, естественно, у нормального продавца, а не на Озоне.
Для работы с графикой и архитектурой нужен нормальный экран, а не ноут, и нормальная периферия, а не ноут.
Для видео-проектов нужны достаточно сильный процессор и хороший винт, а не ноут.
Для того и другого сейчас весьма желательна вменяемая видеокарта, а не ноут.
Лет через пять этот ноут придется положить на полку и покупать новый, а вот не-ноут достаточно будет проапгрейдить.
А главное - не сильно дорогих и при этом производительных ноутов - не бывает. Потому что ноут - это компромисс между тем, что можно уместить в узкую коробку, и необходимостью это охлаждать в той же тесноте. Недорогой вариант заведомо будет с перекосом в сторону энергосбережения, а не производительности.
На самом деле, совершенно неважно, что создает Лара. Вы же будете работать с данными, а не с Ларой. То есть будете читать-писать таблицы, которые сами же и пропишете в БД.
Засада может быть в кэшировании: Лара может считать, что таблица не изменялась и выдавать закешированные данные, а вы там уже все пересобачили Питоном... можно, конечно, каждый раз запускать очистку кэша artisan-ом...
Может быть, имеет смысл завести отдельную таблицу под то, что приходит от микросервиса, а в Ларе прописать ежеминутный обработчик, разгребающий это в свои данные. А то ведь анализировать содержимое таблицы, в которую суются с двух сторон, при необходимости отладки будет невесело...
lyonyamanyonya, вам стоит смотреть не языки, а движки. С нуля у вас все равно вряд ли что-то путное получится, движок задаст структуру и логику. А язык - дело наживное, освоить синтаксис того же Питона поле Пыха можно за неделю. Было бы желание.
pfemidi, под "pure C" вы имеете в виду С99, С11 или С17? :)
Я, собственно, и сказал, что разница между "простым С" и "сложным С++" в том, что в "сложном" вы продолжаете изучать сам язык, применяя это знание где угодно, а в "простом" - язык заканчивается, начинаются нюансы его применения на разных платформах. Что совой об пенек, что пеньком об сову...
"Вышка" в техническом вузе вообще - обязательный предмет. А на айтишных специальностях вокруг будут люди, которые чувствуют математику печенкой. Будет туго. Но если есть уверенность, что осилишь получить высшее образование с вот таким заваленным средним... все равно имеет смысл идти на специальность, которая интересует.
pfemidi, да полноте. Просто не надо хвататься за свежие стандарты сразу, без опыта и понимания, зачем были сделаны эти добавления. В Ассемблере и Сях куда больше нюансов - они ближе к платформе, и на практике имеешь дело уже не с единым (хотя и сложным) стандартом, а с кучей частностей и подпорок под костыли...
