Нифига. Последние два класса и 2 года универа занимался тяжёлой атлетикой, жрал очень много, жал штангу своего веса. Жилистый но не массивный был. Просто не набиралось.
А кому то может повезти с чем то там(обмен веществ?) - я при 183 роста смог поправится с катастрофических 50 до 65(в перспективе до 70 в 30 лет) только после аренды квартиры возле метро и макдака, что бы ходить меньше надо было до самого метро(работа была в паре станций). Почти год режим питания - бигмак меню на утро и потом еще одно на обед, вечером заказная пицца под сериальчик. Общая худоба остаётся, но теперь не сдувает зимой в дверях метро. А потом в качалке еще догнал силушки и выносливости чуть чуть. С всякими пищевыми системами, почками, печенью проблем нет. Толстые, завидуйте(сарказм, если что, реально было фигово, девушки в мою сторону не смотрели, и реально могло толкнуть дверьми в метро).
Зачастую такие "задачки" с "продакшена" имеют нулевую повторяемость без контекста. И боюсь представить, какой там контекст, что команда программистов сумела сделать с этого задачку... Я бы с такими не пошел работать :)
Имхо, на проблему с статьи меня бы на 100% удовлетворил ответ "синхронизировать доступ к файлу" и пример возможной синхронизации в разных местах. И абсолютно пофиг сколько раз упал бы наш, абсолютно неизвестный для соискателя, продакшен.
Маленькие таски отлично живут в билд-конфигурации, сложные - в buildSrc. Выносить функцию в три строчки(например с кастомной логикой генерации версии) в отдельный плагин или кодовую базу - вы еще тот извращенец.
Ну почему же немыслимо? На python да, это ужасно, но тот же jsx и на вид ничего себе так, и по функционалу тоже прилично. С небольшой сноровкой даже в больших проектах можно применять. Тот же kotlin с своим dsl и контрактами тоже может дать хороший результат.
Так и не увидел нетривиальную конфигурацию на gradle. Но в любом случай, на gradle это еще +- можно оформить по человечески. Давайте лучше нетривиальную конфигурацию на maven. О Боже, как я люблю программировать на xml...
Вот где ооп напрашивался на каждом шагу - https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition (сарказм, если что). А в DOOM ооп вообще не нужен был. Потому что, внезапно, в DOOM решали задачу по быстродействию, а не красивого, понятного каждой домохозяйке (еще и на тот момент closed-source) кода. DOOM писался в такое время, что любой оверхед на вызов виртуальной функции, или неудачно запакованные данные могли бы стать фатальными недостатками. И наоборот, хитрая и не понятная для свидетелей ООП фигня давала очень хороший и желанный результат.
пс: ломка сознания для ООП - это звучит страшно. Ломать сознание надо для того что бы натянуть ООП везде и всегда? Мне всегда казалось что ООП это инструмент, а не стиль жизни, и для правильного применения ООП нужна не ломка сознания, а: инженерное образование; нормальные, структурированные знания; последовательность. Всегда думал, что обладая таким набором качеств, специалист будет уверенно применять и ООП, и ФП, и спокойно структурировать свой код(при надобности) и на чистом ASM или С, но я могу и ошибаться...
О запретных фразах смешно очень... Обычно мне казалось что такие фразы "запрещены" при рабочем общении на ЛЮБОМ языке, там культура общения, взаимное уважение. А что, своему сокоманднику на русском можно спокойно говорить "это не моя проблема"(а иногда и послать)?
Обожаю ООП, в примерах так радужно, туда сюда интерфейс передал, тут абстракция, там IEmployee... А в реальном мире(и иногда и в реальных приложениях) оказывается коробка передач от карьерного грузовика совсем не подходит в хонду дива.
Если бы меня спросили, как сделать форму логина, я бы ответил: "Какая форма логина?! Только биометрический токен с анализом ДНК и психической активности, что бы случайно не пропустить принужденную аутентификацию третьими лицами".
А без сарказма, аудитория сервиса определяет, что и как показывать. Если моей маме сказать "ваш новый пароль недопустим" без точной причины, она просто отложит facebook на N недель, пока я не приеду в гости и не напишу ей на бумажке новый пароль. А умножить эти N недель на огромное количество таких пользователей, мы получим миллиарды пропущенных кликов на рекламу и потерю прибыли.
Поздравляю, вы технический специалист, а не миллиардер-владелец facebook. И с точки зрения безопасности вы можете быть 100% правым, но прибыль владельца и ЗП junior/middle/senior формошлепщика, который в этом бизнесе работает, зачастую зависит от красоты и удобства в значительно большей мере чем от секьюрности и других маловажных технических факторов.
Есть еще один способ, не волшебный, правда, и не всегда применимый, но мега-крутой - compile-time кодогенерация и post-compile weaving. Последний вообще позволяет получить перфоманс "как будто бы сам написал".
А если заменить алокацию на пул листов или других контейнеров?
пс: у нас сейчас backend java девелоперы(в том числе и я) пишут ui на unity3d. Сделали мы подходящий для себя фреймворк, но в в профайлер еще не заглядывали. Там будет тихий ужас, 100%, потому что на jvm обычно выделяют 100500 мб памяти, тюнят gc и только в самых критичных случаях начинают думать за другие оптимизации. Сейчас потихоньку собираем инфу как и что будем фиксить :)
А, и забыл написать, да, действительно приложения на unity будут выглядеть 100% одинаково, даже если это 32 дюймовый 5к монитор, или китайский планшет на 10 дюймов. А сделать так, что бы и на том и на другом выглядело нормально - еще задача. Мы оставили пользователям несколько ползунков что бы они сами под себя настраивали scale, target dpi, размеры шрифтов, потому что как то это автоматизировать кросплатформенно с полу-пинка так и не осилили .. Все же в unity без особо-крупного багажа решений быстро ничего не сделать кроме 3 в ряд и онлайн казино, и уж точно unity это не о ui. Есть надежда на ui elements, но боюсь что оно так и останется корявым, как и большинство частей unity.
Кек, сейчас в 99% случаев у всех стоит хром или хром-based браузер, и везде что то написанное на каком то react + mui будет выглядеть одинаково. Последние пол года пишем нодный редактор, и господи, на чем угодно было бы легче, быстрее и качественнее его написать чем на unity. Наверное даже на asm + qt было бы проще...
А где можно прочитать об отказе от jit? Я точно читал на форуме что есть в идеях отказ от mono в пользу microsoft'овского рантайма для поддержки последних стандартов, но прям что бы от jit... Я тогда unity вообще уважать перестану. Выкиньте уже тогда c# и отдавайте наружу c++ хидеры, а для писателей онлайн казино и три в ряд наверните сверху свой скриптовый язык. Вот зачем насиловать c# своим il2cpp, burst, кривым рантаймом, фиговым пекедж-менеджером...
Забейте, это начало конца(точнее продолжение конца). Имхо, идет к тому что бы финансовая пирамида доллара(1) планомерно рухнула и начался процесс построения нового мира. И любые инструменты, которые будут как то мешать, те же криптовалюты, будут вне закона абсолютно везде и до конца жизни. У всех будет денег ровно столько, сколько килограмм картохи лежит в подвале :)
Вопрос в том, сколько еще войнушек, пандемий и прочих "исторических" событий посыплется на наши головы, когда вся эта фигня все же бахнет и мир начнут делить заново.
(1) - кроме доллара еще и всех зависимых биржевых рынков, на которых торговцы воздухом типа apple стоят "дороже" компаний которые добывают сотни тысяч тонн ископаемых и имеют тысячи квадратных километров земли и недвижимости
Он заставляет выталкивать любое не io в numpy/свой собственный сишный код :)
Тега "сарказм" не хватает. А если серьезно это воспринять, то бедная сова уже лопнула давно, так тут все натянуто...
Нифига. Последние два класса и 2 года универа занимался тяжёлой атлетикой, жрал очень много, жал штангу своего веса. Жилистый но не массивный был. Просто не набиралось.
А кому то может повезти с чем то там(обмен веществ?) - я при 183 роста смог поправится с катастрофических 50 до 65(в перспективе до 70 в 30 лет) только после аренды квартиры возле метро и макдака, что бы ходить меньше надо было до самого метро(работа была в паре станций). Почти год режим питания - бигмак меню на утро и потом еще одно на обед, вечером заказная пицца под сериальчик. Общая худоба остаётся, но теперь не сдувает зимой в дверях метро. А потом в качалке еще догнал силушки и выносливости чуть чуть. С всякими пищевыми системами, почками, печенью проблем нет. Толстые, завидуйте(сарказм, если что, реально было фигово, девушки в мою сторону не смотрели, и реально могло толкнуть дверьми в метро).
Зачастую такие "задачки" с "продакшена" имеют нулевую повторяемость без контекста. И боюсь представить, какой там контекст, что команда программистов сумела сделать с этого задачку... Я бы с такими не пошел работать :)
Имхо, на проблему с статьи меня бы на 100% удовлетворил ответ "синхронизировать доступ к файлу" и пример возможной синхронизации в разных местах. И абсолютно пофиг сколько раз упал бы наш, абсолютно неизвестный для соискателя, продакшен.
Маленькие таски отлично живут в билд-конфигурации, сложные - в buildSrc. Выносить функцию в три строчки(например с кастомной логикой генерации версии) в отдельный плагин или кодовую базу - вы еще тот извращенец.
Ну почему же немыслимо? На python да, это ужасно, но тот же jsx и на вид ничего себе так, и по функционалу тоже прилично. С небольшой сноровкой даже в больших проектах можно применять. Тот же kotlin с своим dsl и контрактами тоже может дать хороший результат.
пс: дизайнеры, не бейте меня, пожалуйста
Так и не увидел нетривиальную конфигурацию на gradle. Но в любом случай, на gradle это еще +- можно оформить по человечески. Давайте лучше нетривиальную конфигурацию на maven. О Боже, как я люблю программировать на xml...
Не согласен. Код на ломбоке это ситаксически-верный код java. Если бы lombok добавлял бы парочку новых keyword'ов, тогда другое дело.
Вот где ооп напрашивался на каждом шагу - https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition (сарказм, если что). А в DOOM ооп вообще не нужен был. Потому что, внезапно, в DOOM решали задачу по быстродействию, а не красивого, понятного каждой домохозяйке (еще и на тот момент closed-source) кода. DOOM писался в такое время, что любой оверхед на вызов виртуальной функции, или неудачно запакованные данные могли бы стать фатальными недостатками. И наоборот, хитрая и не понятная для свидетелей ООП фигня давала очень хороший и желанный результат.
пс: ломка сознания для ООП - это звучит страшно. Ломать сознание надо для того что бы натянуть ООП везде и всегда? Мне всегда казалось что ООП это инструмент, а не стиль жизни, и для правильного применения ООП нужна не ломка сознания, а: инженерное образование; нормальные, структурированные знания; последовательность. Всегда думал, что обладая таким набором качеств, специалист будет уверенно применять и ООП, и ФП, и спокойно структурировать свой код(при надобности) и на чистом ASM или С, но я могу и ошибаться...
О запретных фразах смешно очень... Обычно мне казалось что такие фразы "запрещены" при рабочем общении на ЛЮБОМ языке, там культура общения, взаимное уважение. А что, своему сокоманднику на русском можно спокойно говорить "это не моя проблема"(а иногда и послать)?
Обожаю ООП, в примерах так радужно, туда сюда интерфейс передал, тут абстракция, там IEmployee... А в реальном мире(и иногда и в реальных приложениях) оказывается коробка передач от карьерного грузовика совсем не подходит в хонду дива.
Если бы меня спросили, как сделать форму логина, я бы ответил: "Какая форма логина?! Только биометрический токен с анализом ДНК и психической активности, что бы случайно не пропустить принужденную аутентификацию третьими лицами".
А без сарказма, аудитория сервиса определяет, что и как показывать. Если моей маме сказать "ваш новый пароль недопустим" без точной причины, она просто отложит facebook на N недель, пока я не приеду в гости и не напишу ей на бумажке новый пароль. А умножить эти N недель на огромное количество таких пользователей, мы получим миллиарды пропущенных кликов на рекламу и потерю прибыли.
Поздравляю, вы технический специалист, а не миллиардер-владелец facebook. И с точки зрения безопасности вы можете быть 100% правым, но прибыль владельца и ЗП junior/middle/senior формошлепщика, который в этом бизнесе работает, зачастую зависит от красоты и удобства в значительно большей мере чем от секьюрности и других маловажных технических факторов.
Есть еще один способ, не волшебный, правда, и не всегда применимый, но мега-крутой - compile-time кодогенерация и post-compile weaving. Последний вообще позволяет получить перфоманс "как будто бы сам написал".
А если заменить алокацию на пул листов или других контейнеров?
пс: у нас сейчас backend java девелоперы(в том числе и я) пишут ui на unity3d. Сделали мы подходящий для себя фреймворк, но в в профайлер еще не заглядывали. Там будет тихий ужас, 100%, потому что на jvm обычно выделяют 100500 мб памяти, тюнят gc и только в самых критичных случаях начинают думать за другие оптимизации. Сейчас потихоньку собираем инфу как и что будем фиксить :)
А, и забыл написать, да, действительно приложения на unity будут выглядеть 100% одинаково, даже если это 32 дюймовый 5к монитор, или китайский планшет на 10 дюймов. А сделать так, что бы и на том и на другом выглядело нормально - еще задача. Мы оставили пользователям несколько ползунков что бы они сами под себя настраивали scale, target dpi, размеры шрифтов, потому что как то это автоматизировать кросплатформенно с полу-пинка так и не осилили .. Все же в unity без особо-крупного багажа решений быстро ничего не сделать кроме 3 в ряд и онлайн казино, и уж точно unity это не о ui. Есть надежда на ui elements, но боюсь что оно так и останется корявым, как и большинство частей unity.
Кек, сейчас в 99% случаев у всех стоит хром или хром-based браузер, и везде что то написанное на каком то react + mui будет выглядеть одинаково. Последние пол года пишем нодный редактор, и господи, на чем угодно было бы легче, быстрее и качественнее его написать чем на unity. Наверное даже на asm + qt было бы проще...
А где можно прочитать об отказе от jit? Я точно читал на форуме что есть в идеях отказ от mono в пользу microsoft'овского рантайма для поддержки последних стандартов, но прям что бы от jit... Я тогда unity вообще уважать перестану. Выкиньте уже тогда c# и отдавайте наружу c++ хидеры, а для писателей онлайн казино и три в ряд наверните сверху свой скриптовый язык. Вот зачем насиловать c# своим il2cpp, burst, кривым рантаймом, фиговым пекедж-менеджером...
Забейте, это начало конца(точнее продолжение конца). Имхо, идет к тому что бы финансовая пирамида доллара(1) планомерно рухнула и начался процесс построения нового мира. И любые инструменты, которые будут как то мешать, те же криптовалюты, будут вне закона абсолютно везде и до конца жизни. У всех будет денег ровно столько, сколько килограмм картохи лежит в подвале :)
Вопрос в том, сколько еще войнушек, пандемий и прочих "исторических" событий посыплется на наши головы, когда вся эта фигня все же бахнет и мир начнут делить заново.
(1) - кроме доллара еще и всех зависимых биржевых рынков, на которых торговцы воздухом типа apple стоят "дороже" компаний которые добывают сотни тысяч тонн ископаемых и имеют тысячи квадратных километров земли и недвижимости
Черепно-мозговой боли.