Если честно, я кажется ступил, не понял сразу, что вы под иметацией имели ввиду. Вы при помощи него имитировали поступление данных, что бы прогрессБар отображал процесс.
Потому что человек мог работать долго и стабильно в одной компании и из-за определенной узкой направленности задачь из-за специфики направления, он может забывать большую часть хард скилов и на собесе может показаться джуном. Простой пример с людьми получившыми когда-то несколько высших образований, они забывают 90% всего что им преподавали, потому что работают не по специальности.
Если вы хотите чела который имеет более 5-ти лет опыта работы, и помнит все, то вам нужно искать человека который постоянно имеет дела с разными направлениями и соотвественно задачами, а это значит, что такой человек вам тоже не подойдет, потому что это как раз такие люди, которых вы называете вечными джунами, потому что они меняют часто работу.
Одна из причин почему Delphi теряла популярность, это еще по тем временам очень большой размер исполняемых файлов, с этим кто как боролся, но это не помогало.
Но Delphi(хотя как и Visual Studio) уже тогда предлагали в своем арсенале удобные визуальные инструменты отладки, из коробки.
Сейчас если вы хотите дебажить что-то, то руками из терминала и с бубном, по крайней мере в большинстве случаев.
В KMP порог входа существенно выше, чем во Flutter.
В KMP Куча конфигов повторяющихся, хотя сам по себе язык классный, но экосистема там сильно усложнена, наверное наследие от Java. Грубо говоря отличие только тем, что используется gradle вместо xml. Что бы сделать импорт зависимости ее надо прописать в нескольких местах.
Обьясните новичку пожалуйста, зачем там интеграция с Java? Если мы берем в пример Flutter, то он компилит в нативное приложение, то есть разработчики там не имеют дел с Java вообще, в нормальной ситуации. А то не получится ли очередной Котлин?
Название слишком громкое, когда вы используете все плоды ООП, но при этом хотите выделить плюсы функционала перед ООП.
Мне почему-то казалось, что раз статья про функциональное программирование, то я(наверное ошибочно) ожидаю, что тут не будут использоваться классы и их методы. Вместо этого все на классах и методах языка Kotlin.
В котлине что бы завести проект нужно почему-то много настроек сделать в разных gradle файлах и других, кучу импортов везде, и всего такого кода выйдет куда больше чем кода реализации.
Мне иногда кажется, что такие статьи пишут не достаточно «накоденные»(покодили лет 5, умные не отрицаю. Но 5 лет не достаточно) на разных языках. Любой мой код использует ООП, потому что так я добиваюсь переиспользования и как следствие более восприимчивый код за счет лаконичности всей кодовой базы, поэтому совершенно не понимаю такие вот статьи.
Если честно, я кажется ступил, не понял сразу, что вы под иметацией имели ввиду.
Вы при помощи него имитировали поступление данных, что бы прогрессБар отображал процесс.
Любой удет от вас, хоть джун, хоть не джун, если тому пообещают лучшие условия.
Потому что человек мог работать долго и стабильно в одной компании и из-за определенной узкой направленности задачь из-за специфики направления, он может забывать большую часть хард скилов и на собесе может показаться джуном. Простой пример с людьми получившыми когда-то несколько высших образований, они забывают 90% всего что им преподавали, потому что работают не по специальности.
Если вы хотите чела который имеет более 5-ти лет опыта работы, и помнит все, то вам нужно искать человека который постоянно имеет дела с разными направлениями и соотвественно задачами, а это значит, что такой человек вам тоже не подойдет, потому что это как раз такие люди, которых вы называете вечными джунами, потому что они меняют часто работу.
Про сейчас, я хотел сказать про другие современные языки типа Java, Python и т.д.
Там все руками и все через консоль.
Одна из причин почему Delphi теряла популярность, это еще по тем временам очень большой размер исполняемых файлов, с этим кто как боролся, но это не помогало.
Но Delphi(хотя как и Visual Studio) уже тогда предлагали в своем арсенале удобные визуальные инструменты отладки, из коробки.
Сейчас если вы хотите дебажить что-то, то руками из терминала и с бубном, по крайней мере в большинстве случаев.
А еще говорят что не хватает. Вранье и было враньем, только для того, что бы зарплаты сбить.
А нельзя во flutter изображение рендерить в фоне сначала, а потом уже готовым выводить на экране?
В KMP порог входа существенно выше, чем во Flutter.
В KMP Куча конфигов повторяющихся, хотя сам по себе язык классный, но экосистема там сильно усложнена, наверное наследие от Java. Грубо говоря отличие только тем, что используется gradle вместо xml. Что бы сделать импорт зависимости ее надо прописать в нескольких местах.
Обьясните новичку пожалуйста, зачем там интеграция с Java? Если мы берем в пример Flutter, то он компилит в нативное приложение, то есть разработчики там не имеют дел с Java вообще, в нормальной ситуации. А то не получится ли очередной Котлин?
Я полагаю что в данном случае include подгружает записи за один запрос, что бы избежать потом n+1
Я думаю, вы поняли, что я написал, я имел ввиду методы классов, но не отдельные от классов функции.
Название слишком громкое, когда вы используете все плоды ООП, но при этом хотите выделить плюсы функционала перед ООП.
Мне почему-то казалось, что раз статья про функциональное программирование, то я(наверное ошибочно) ожидаю, что тут не будут использоваться классы и их методы.
Вместо этого все на классах и методах языка Kotlin.
Ну да, так даже локаничнее, и более понятно, что это такое вообще.
К сожалению, часто, разработчик приходит к пониманию, что от тестов только плюсы, не сразу и только через собственный опыт.
А вот как код будет выглядеть на ORM в Ruby on Rails:
Смотрю на это все и думаю, как же хорош Ruby on Rails.
Этот бомбила был безобидным таксистом. Но ему придется стать не безобидным бандитом, что бы заработать на жизнь.
В котлине что бы завести проект нужно почему-то много настроек сделать в разных gradle файлах и других, кучу импортов везде, и всего такого кода выйдет куда больше чем кода реализации.
Мне иногда кажется, что такие статьи пишут не достаточно «накоденные»(покодили лет 5, умные не отрицаю. Но 5 лет не достаточно) на разных языках. Любой мой код использует ООП, потому что так я добиваюсь переиспользования и как следствие более восприимчивый код за счет лаконичности всей кодовой базы, поэтому совершенно не понимаю такие вот статьи.
Скальпинг это минимальный риск? Торговля на секундах? Да вы все сразу сольете только на одних комиссиях.