JavaScript мой любимый язык программирования :-) Он позволил мне избавиться от ООП шаблонов раз и навсегда в моем собственном коде. Код получается лаконичный, простой, понятный и легкоуправляемый. Дешево и сердито...
А я люблю LeetCode... По работе у меня лютая рутина... парсеры-конвертеры, системы обмена бизнес-данными с внешними системами... одно и тоже много лет, а на LeetCode прикольные кейсы встречаются... иногда там на половину воскресенья залипаю.
Такая практика действительно широко распространена, поэтому я обычно первым делом спрашиваю потенциальных нанимателей что подразумевается под "суммой, до уплаты налогов", потому что результат может быть весьма неоднозначен.
Я сталкивался на практике с тем, что работодатели под "суммой оплаты труда до уплаты налогов" подразумевали что туда входит НДФЛ и отчисления в ПФР, ФСС, ФОМС, а это уже совсем не то же самое, что gross за минусом НДФЛ.
Поэтому мне кажется что когда работодатель указывает в предложении "сумму на руки" ощутимо упрощает понимание ситуации обеими сторонами. Попросту говоря мне кажется что такие работодатели поступают честнее.
Стало еще менее понятно. Что вы подразумевали под фразой "Остальные платежи в силу закона делает работодатель"? Что исчисление и уплата НДФЛ в бюджет возлагается на кандидата?
Сумма размера оклада "до вычета налогов" на скриншоте предполагает что кандидат посчитает проценты отчислений налога на доходы физических лиц, а так же проценты отчислений в страховые, пенсионные и внебюджетные фонды и выведет итоговую ежемесячную сумму "на руки" самостоятельно?
В том, что поведение надо упаковывать в классы? В моем примере все классы же по сути вырожденные. Это просто контейнеры для единственного метода Execute. Ценность самих классов в моем примере равна нулю. В них нет ни приватных методов, ни свойств. У них даже названия не как у нормальных классов HttpClient или DataContext, а как у обычных функций makePaidInvoices, sendReport.
Ну то есть вот есть у нас реальный процесс. Ну скажем вот такая история:
Как система, я хочу выполнить операцию сверки оплаты выставленных счетов
Можете буквально тремя строчками описать его формализацию, так чтобы стало отчетливо видно помощь ООП? Чтобы прямо классы вытаращились отовсюду...
Ну поскольку в вашей публикации речь идет о Java, то в примере кода я естественно использовал доступные возможности Java. Ну а поскольку в Java нельзя просто объявить процедуру ни в глобальной области видимости, ни в области видимости модуля, то я конечно оформил поведение используя ООП, которое к Java приколочено гвоздями. Я мог бы то же самое написать к примеру на Javascript и там бы не было ни классов ни интерфейсов ни ключевых слов new.
Ну да и ладно. Не заметили вы парадигму, ну и бог с ней. Конечно пользуйтесь ООП на здоровье, если вам так проще и удобнее. Я не навязываюсь.
Да простейшую. Контейнеры состояния и массивы-наборы команд-обработчиков. Не очень помню что там в Java, но наверное можно примерно вот так:
public interface Command
{
void Execute(HashMap<String, Object> state);
}
public class MakeOperationId implements Command {
public void Execute(HashMap<String, Object> state) {
if(state.containsKey("error")) return;
int length = (Integer)state.get("operationIdLength");
byte[] bytes = new byte[length];
Random generator = (Random)state.get("randomGenerator");
generator.nextBytes(bytes);
DatatypeConverter converter =
(DatetypeConverter)state.get("DatatypeConverter");
state.put("operationId", converter.printHexBinary(bytes));
}
}
public class ErrorInterceptor {
public static void Execute(Command command, HashMap<String, Object> state) {
try {
command.Execute(state);
}
catch(Exception error) {
state.put("error", error);
}
}
}
Command[] handlers = new Command[] {
new MakeOperationId(),
new ParseRequestBody(),
new ValidateRequestBody(),
new GetUserCredentials(),
new GetUserPermissions(),
new GetInvoicesPendingPayment(),
new GetBankStatement(),
new MakePaidInvoices(),
new SavePaidInvoices(),
new MakeResponseContent(),
new SendReport(),
new ReportError()
};
HashMap<String, Object> operationState =
InvoiceReconciliationOperationState.make(applicationState);
for(Command command : handlers) {
ErrorInterceptor.Execute(command, operationState);
}
Пакет мобильных прокси точно так же легко арендуется, так что это не более чем вопрос личных предпочтений и бюджета. У меня нет никакого желания строить фермы из мобилок, я предпочитаю специализироваться в разработке. Эксплуатация резидентных прокси ферм меня вообще никак не торкает. Это совершенно отдельный бизнес на мой взгляд.
Возможно мне пока просто "не повезло" и я не попадал на такие интеллектуальные контуры систем безопасности сайтов. В общем пока мои заказчики еще ни разу не обнаружили дезинформацию в распарсенных данных.
Именно этот вариант не пробовал. Честно говоря не очень верю в эффективность подобных средств, исходники которых правились в репозитории пять лет назад.
Я пробовал разного рода списки дешевых прокси за $10 в месяц три пачки. Неудачный опыт. Много ошибок обработки запросов, масса мертвых адресов, масса обрывов соединений. Нервотрепка в общем.
Субъективно, из того что я использовал, адекватные прокси услуги обычно стоят от $90-$100 долларов в месяц. Что называется "включил и забыл". Единственное за чем надо следить, это за остатком кредитов на балансе, которые списываются по мере пользования сервисом.
JavaScript мой любимый язык программирования :-) Он позволил мне избавиться от ООП шаблонов раз и навсегда в моем собственном коде. Код получается лаконичный, простой, понятный и легкоуправляемый. Дешево и сердито...
Да я и не пытаюсь создавать языки... тем паче чтобы "на все случаи жизни". Просто JavaScript я люблю больше всего.
На все воскресенье не могу, есть еще гитаризм и Arduino :-)
За 28 лет я в разные годы попрограммировал на C, Java, Dart, PHP, C# и Python и мне кажется что JavaScript самый лучший язык...
А я люблю LeetCode... По работе у меня лютая рутина... парсеры-конвертеры, системы обмена бизнес-данными с внешними системами... одно и тоже много лет, а на LeetCode прикольные кейсы встречаются... иногда там на половину воскресенья залипаю.
Спасибо за ответ
А вот когда деньги, рост и баланс найдены, где искать людей, с которыми было бы интересно что-нибудь нетривиальное замутить?
Так а я же и не называл их налогами. Я использовал термин "отчисления" :-)
Такая практика действительно широко распространена, поэтому я обычно первым делом спрашиваю потенциальных нанимателей что подразумевается под "суммой, до уплаты налогов", потому что результат может быть весьма неоднозначен.
Я сталкивался на практике с тем, что работодатели под "суммой оплаты труда до уплаты налогов" подразумевали что туда входит НДФЛ и отчисления в ПФР, ФСС, ФОМС, а это уже совсем не то же самое, что gross за минусом НДФЛ.
Поэтому мне кажется что когда работодатель указывает в предложении "сумму на руки" ощутимо упрощает понимание ситуации обеими сторонами. Попросту говоря мне кажется что такие работодатели поступают честнее.
Стало еще менее понятно. Что вы подразумевали под фразой "Остальные платежи в силу закона делает работодатель"? Что исчисление и уплата НДФЛ в бюджет возлагается на кандидата?
Сумма размера оклада "до вычета налогов" на скриншоте предполагает что кандидат посчитает проценты отчислений налога на доходы физических лиц, а так же проценты отчислений в страховые, пенсионные и внебюджетные фонды и выведет итоговую ежемесячную сумму "на руки" самостоятельно?
:-) Я так и не понял в чем преимущество ООП :-)
В том, что поведение надо упаковывать в классы? В моем примере все классы же по сути вырожденные. Это просто контейнеры для единственного метода
Execute. Ценность самих классов в моем примере равна нулю. В них нет ни приватных методов, ни свойств. У них даже названия не как у нормальных классовHttpClientилиDataContext, а как у обычных функцийmakePaidInvoices,sendReport.Ну то есть вот есть у нас реальный процесс. Ну скажем вот такая история:
Как система, я хочу выполнить операцию сверки оплаты выставленных счетовМожете буквально тремя строчками описать его формализацию, так чтобы стало отчетливо видно помощь ООП? Чтобы прямо классы вытаращились отовсюду...
ООП конечно не мешает. Мне не пришло бы в голову предложить вам нечто, чем вы не смогли бы воспользоваться.
А чем ООП в данном случае помогает?
Ну поскольку в вашей публикации речь идет о Java, то в примере кода я естественно использовал доступные возможности Java. Ну а поскольку в Java нельзя просто объявить процедуру ни в глобальной области видимости, ни в области видимости модуля, то я конечно оформил поведение используя ООП, которое к Java приколочено гвоздями. Я мог бы то же самое написать к примеру на Javascript и там бы не было ни классов ни интерфейсов ни ключевых слов
new.Ну да и ладно. Не заметили вы парадигму, ну и бог с ней. Конечно пользуйтесь ООП на здоровье, если вам так проще и удобнее. Я не навязываюсь.
Да простейшую. Контейнеры состояния и массивы-наборы команд-обработчиков. Не очень помню что там в Java, но наверное можно примерно вот так:
Избавьтесь от ООП и жизнь станет проще...
Пакет мобильных прокси точно так же легко арендуется, так что это не более чем вопрос личных предпочтений и бюджета. У меня нет никакого желания строить фермы из мобилок, я предпочитаю специализироваться в разработке. Эксплуатация резидентных прокси ферм меня вообще никак не торкает. Это совершенно отдельный бизнес на мой взгляд.
Я пользуюсь вот этими двумя:
https://www.webscrapingapi.com/
https://zenscrape.com/
Возможно мне пока просто "не повезло" и я не попадал на такие интеллектуальные контуры систем безопасности сайтов. В общем пока мои заказчики еще ни разу не обнаружили дезинформацию в распарсенных данных.
Именно этот вариант не пробовал. Честно говоря не очень верю в эффективность подобных средств, исходники которых правились в репозитории пять лет назад.
Я пробовал разного рода списки дешевых прокси за $10 в месяц три пачки. Неудачный опыт. Много ошибок обработки запросов, масса мертвых адресов, масса обрывов соединений. Нервотрепка в общем.
Субъективно, из того что я использовал, адекватные прокси услуги обычно стоят от $90-$100 долларов в месяц. Что называется "включил и забыл". Единственное за чем надо следить, это за остатком кредитов на балансе, которые списываются по мере пользования сервисом.