Все книги с картинки относятся к IT (программирование, devops), а ссылку на IT не проставили. Только отдельные издательства. А ссылки на подборку с книгами с картинки - нету. Хотя заманивают то в основном книги с картинки.
Не совсем. Дело в том, что в тестах techempower, который показывает самый производительный Web фреймворк используется не коробочное решение, а максимально затюненое решение. Затюненое до такой степени, что читать код невозможно.
Present Simple - описательное время, можете погуглить в русском - описательные высказывания. Например "солнце светит", "Земля кружится вокруг солнца", "Часы круглые", "Шкаф стоит".
Present Continuous - повествовательное время - "я читаю книгу", "я бегаю", "слон идет". Т.е. какой-то процесс происходит и мы о нем говорим.
Кстати тут вопрос "Часы идут" - это описание или повествование. Можно сказать и так и так. Наверное "Часы ходят" - это описание, а "Часы тикают" - это уже повествование, процесс идет.
Persent Perfect - например тебе дали работу, и ты пункт 1 работы уже сделал, но при этом еще делаешь остальную часть работы.
Т.е. в настоящее время работа делится на ту часть, которую ты уже сделал, и ту часть которую ты еще не сделал.
И чтобы подчеркнуть, что это настоящее время, но часть работы ты уже сделал - говорят не в "прошлом", а "в настоящем, но уже сделанном".
Т.е. "я попил чай", говорит что сегодня (день еще не завершен), в настоящем, я чай УЖЕ попил. Т.е. это настоящее завершенное время. Не вчера, не в прошлом, попил чай, а именно сегодня, действие уже завершилось, в сегодняшнем (что значит сегодняшний - решаешь сам, например рабочий день, или день в школе - это сегодняшнее время, в ней работа есть завершенная уже (о ней говорят в Present Perfect), и еще не завершенная) интервале времени.
Т.е. тебя спросят - ты работу уже выполнил? Я скажу - выполнил пункт 1. Я скажу это в Present Perfect, т.к. рабочий день еще идет, но часть работы уже завершена. И об этой части работы, которая уже завершена - говорят в Present Perfect. А если спросят завтра - то это будет уже прошедшее время - Past какой-то там.
Конкретно говорится что React Elements - это то что можно "потрогать" из реализации Virtual DOM в React. И еще Fibers говорится, но это вроде Internal, как их потрогать я не знаю, постоянно вижу упоминания в исходниках, но наружу вроде они не торчат.
В статье сказано - минимальный. Обычно под минимальной оценкой я понимаю 1 или 2 балла в нашей системе школьных оценок. Слово минимально - обычно ассоциируется с абсолютным значением. "им рекомендовано присвоить минимальный рейтинг 10% сотрудников" - этож каким нелюдем надо быть, чтобы рекоммендовать присваивать минимальный рейтинг даже вполне нормальному человеку. Хотя в оригинале фраза звучит, как найти 10% самых отстающих. Что уже не вызывает такой ненависти. Специально искажают слова? Зачем?
Salesforce asked some managers to rank their lowest 10% of employees.
Т.е. надо выявить 10%-тов самых lowest (не знаю, не продуктивных или самых плохих) сотрудников.
А не присвоить 10%-там сотрудников самый низкий рейтинг. Можно фразу с оригинала, где сказано именно так?
Если данная ошибка перевода сделана специально, то решение - просто перестать верить в кликбейтные заголовки: "Завтра 3-я мировая война". Отличный тест на проверку!
Я не знаю что у вас за нагрузка, но обычно проблема фреймворков - не в том, что они не выдерживают нагрузку. Может для проекта мирового масштаба - это да - проблема. Но в России таких проектов очень мало, я думаю, что даже Wildberries и Ozon с их 100 миллионами посетителей в месяц могут позволить себе писать на фреймворке, а не на нативном go. Может не hot point точку куда делаются прямо все запросы, но очень много своих сервисов - могут (сервис оплаты, сервис личного кабинета, сервис доставки и т.д.).
Основная проблема фреймворков, что либо он забрасывается (или уходит из мейнстрима и все начинают писать на другом фреймворке) или выходит v2, v3, которые "ну надо переписать весь проект, потому что v2 это совсем другой фреймворк, полностью не совместимый с первой версией".
Пример фреймворка из Go: Gorilla Mux, раньше, когда я изучал Go мы прям изучали конкретно этот - популярный на тот момент фреймворк. Он прям был популярен, нам прям говорили - вот будете знать что нужно на рынке труда. А теперь - The Gorilla project has been archived, and is no longer under active maintainenance.
Я тут подумал, скорее всего эффективный батчинг - это реально то место, где можно что-то доработать, и действительно является недоработанным местом текущих ORM, и там можно что-то сделать. Но скорее всего там будет другой метод сохранения сущностей, т.к. нельзя при дефолтном вызове save открывать транзакции, рассчитывать что надо как-то доработать клиентский код под откат батчинга и т.д. Пока катимся на голом SQL.
Допустим вы загрузили из базы 10 товаров и у них поменяли prop1 = value1. А у четных товаров еще поменяли prop2 = value2, просто для сферического примера.
Когда вы сохраняете товары по-одному, у вас товар сохраняются единой сущностью, т.е. либо весь товар сохранен, либо весь не сохранен. Т.е. генерируется запрос update product set prop1 = value1, prop2 = value2 where id = 1. И так для 10 товаров по очереди.
А если оптимизировать скорость и разбивать данное обновление с помощью крутой ORM автоматически на 2 SQL запроса: update product set prop1 = value1 where id in (1, 2, 3, ..., 10), а потом update product set prop2 = value2 where id in (2, 4, 6, ..., 10), то в случае невыполнения 2-го запроса, т.е. если он завершился с ошибкой у вас в базе и в вашем аппликейшене будет полностью мешанина из обновленных данных и не обновленных - часть полей обновилась, часть не обновилась, непонятно что обновилось а что не обновилось, и у каких товаров. Откатить выполнившиеся update'ы в базе не всегда возможно, по-этому придется проверять и разруливать ситуацию в ручную всегда, писать кастомный код, а разрулить данную ситуацию в плане объектов ORM будет в ну очень сложно.
По-этому для таких ситуаций пишут голый SQL, которые сделает необходимые обновления. И это гораздо проще, чем потом разрулить ситуацию с частично обновленными 10 товарами. Т.е. прям в коде пишешь функцию: update product set prop1 = :prop1_value where id in (:prop1_update_ids). И потом еще один SQL: update product set prop2 = :value2 where id in (:prop2_update_ids), и всё, код очень простой. По сравнению с тем, что надо писать метод прохода по 10 товарам и проверки, что в них обновилось а что - нет и отката всего до какого-то нормального состояния когда автоматический откат невозможен (а непонятно что ORM смогло откатить назад автоматически, а что не смогло, по-этому проверять надо всё).
Как видим, в этом случае получается 50 записей (их можно сократить до 20, предлагаю подумать и написать в комментариях как это сделать).
Думаю для возраста 16-21 и стажа 0,1,2 коэффициент одинаковый, и их можно объединить в 1 запись. И тогда получится 20 записей.
При варианте с 3 таблицами, похоже никто не мешает вставить повторяющиеся диапазоны и в таблицу возраста и в опыта. Контроля уникальности нет. Тогда этот вариант можно заменить 1 таблицей: id, age_from, age_to, experience_from, experience_to, coefficient.
Давайте озвучим это: каждый хочет жить подольше. Мы ходим на работу чтобы когда-нибудь заработать столько денег, чтобы можно было не умирать вообще. Это если "типа" математически строго создавать теорему жизни и подходить к этому вопросу через строгие типа математические доказательства (не совсем математика, но какая-то формальная строгость и формальная правильность бытия). Другие конечно кажут - зачем нужна формальная "теория всего" и т.д., хочу просто веселиться, хорошо кушать. гулять, хорошо проводить время с другими и всё, т.е. без всяких великих теорий.
Я тоже дам определение на интересный вопрос. Ну например я вижу камень лежит на земле. Между камнем и землей происходит какое-то взаимодействие. Вот если взять весь спектр таких взаимодействий, все их (гравитация там, электромагнитные взаимодействия и т.д.), то это реальность.
Раньше были интересные курсы от Академия 1С-Битрикс, я смотрел №1 - Интеграция дизайна и настройка платформы №2 - Основные технологии и расширение типовых возможностей системы №3 - Расширенные технологии и производительность D7. Разработка собственного модуля
Ну то есть ясно, как в ней копаться: идёшь в файл пролог, дальше во все, кого он там подключает, ну и так далее.
В кодовой базе - вам не разобраться. Я бы советовал именно "трясти дерево" как вы говорите. Т.е. вызывать функции с типовыми параметрами, и не рекоммендовал лезть сильно глубоко внутрь. Там очень сложный и непонятный код. Эффективно работать с 1С-Битрикс == хорошо знать как работать с функциями в основном инфоблоков (CIBlockElement::GetList и т.д.), catalog, sale, но != залезть в них внутрь и заковыряться там.
Я веб бекендер разработчик с большим опытом. Могу сказать что Битрикс - самая трудная система. Он сложнее: Laravel, Symfony, Python Django, C# .NET, и даже Java Spring. Огромная кодовая база. Под разобраться - я имею ввиду реально знать как работает CIBlockElement::GetList, прям залезть внутрь и разобраться, а не уметь вызывать его с типовыми параметрами.
UPD: а, да, сейчас там же делается через D7, что-то вроде \Bitrix\Iblock\Iblock::wakeUp. Но все равно, сути это не меняет.
Все книги с картинки относятся к IT (программирование, devops), а ссылку на IT не проставили. Только отдельные издательства. А ссылки на подборку с книгами с картинки - нету. Хотя заманивают то в основном книги с картинки.
del
Pyypl не принимает российский паспорт.
Не совсем. Дело в том, что в тестах techempower, который показывает самый производительный Web фреймворк используется не коробочное решение, а максимально затюненое решение. Затюненое до такой степени, что читать код невозможно.
Был статья на хабре об этом.
https://habr.com/ru/post/701352/
Т.е. в реальной жизни все так - именно в классической парадигме.
https://www.techempower.com/benchmarks/
Present Simple - описательное время, можете погуглить в русском - описательные высказывания. Например "солнце светит", "Земля кружится вокруг солнца", "Часы круглые", "Шкаф стоит".
Present Continuous - повествовательное время - "я читаю книгу", "я бегаю", "слон идет". Т.е. какой-то процесс происходит и мы о нем говорим.
Кстати тут вопрос "Часы идут" - это описание или повествование. Можно сказать и так и так. Наверное "Часы ходят" - это описание, а "Часы тикают" - это уже повествование, процесс идет.
Persent Perfect - например тебе дали работу, и ты пункт 1 работы уже сделал, но при этом еще делаешь остальную часть работы.
Т.е. в настоящее время работа делится на ту часть, которую ты уже сделал, и ту часть которую ты еще не сделал.
И чтобы подчеркнуть, что это настоящее время, но часть работы ты уже сделал - говорят не в "прошлом", а "в настоящем, но уже сделанном".
Т.е. "я попил чай", говорит что сегодня (день еще не завершен), в настоящем, я чай УЖЕ попил. Т.е. это настоящее завершенное время. Не вчера, не в прошлом, попил чай, а именно сегодня, действие уже завершилось, в сегодняшнем (что значит сегодняшний - решаешь сам, например рабочий день, или день в школе - это сегодняшнее время, в ней работа есть завершенная уже (о ней говорят в Present Perfect), и еще не завершенная) интервале времени.
Т.е. тебя спросят - ты работу уже выполнил? Я скажу - выполнил пункт 1. Я скажу это в Present Perfect, т.к. рабочий день еще идет, но часть работы уже завершена. И об этой части работы, которая уже завершена - говорят в Present Perfect. А если спросят завтра - то это будет уже прошедшее время - Past какой-то там.
Кто знает что там с Present Perfect Continuous?
Документация с вами не согласна: https://reactjs.org/docs/faq-internals.html
Конкретно говорится что React Elements - это то что можно "потрогать" из реализации Virtual DOM в React. И еще Fibers говорится, но это вроде Internal, как их потрогать я не знаю, постоянно вижу упоминания в исходниках, но наружу вроде они не торчат.
В статье сказано - минимальный. Обычно под минимальной оценкой я понимаю 1 или 2 балла в нашей системе школьных оценок. Слово минимально - обычно ассоциируется с абсолютным значением. "им рекомендовано присвоить минимальный рейтинг 10% сотрудников" - этож каким нелюдем надо быть, чтобы рекоммендовать присваивать минимальный рейтинг даже вполне нормальному человеку. Хотя в оригинале фраза звучит, как найти 10% самых отстающих. Что уже не вызывает такой ненависти. Специально искажают слова? Зачем?
Salesforce asked some managers to rank their lowest 10% of employees.
Т.е. надо выявить 10%-тов самых lowest (не знаю, не продуктивных или самых плохих) сотрудников.
А не присвоить 10%-там сотрудников самый низкий рейтинг. Можно фразу с оригинала, где сказано именно так?
Если данная ошибка перевода сделана специально, то решение - просто перестать верить в кликбейтные заголовки: "Завтра 3-я мировая война". Отличный тест на проверку!
Я не знаю что у вас за нагрузка, но обычно проблема фреймворков - не в том, что они не выдерживают нагрузку. Может для проекта мирового масштаба - это да - проблема. Но в России таких проектов очень мало, я думаю, что даже Wildberries и Ozon с их 100 миллионами посетителей в месяц могут позволить себе писать на фреймворке, а не на нативном go. Может не hot point точку куда делаются прямо все запросы, но очень много своих сервисов - могут (сервис оплаты, сервис личного кабинета, сервис доставки и т.д.).
Основная проблема фреймворков, что либо он забрасывается (или уходит из мейнстрима и все начинают писать на другом фреймворке) или выходит v2, v3, которые "ну надо переписать весь проект, потому что v2 это совсем другой фреймворк, полностью не совместимый с первой версией".
Пример фреймворка из Go: Gorilla Mux, раньше, когда я изучал Go мы прям изучали конкретно этот - популярный на тот момент фреймворк. Он прям был популярен, нам прям говорили - вот будете знать что нужно на рынке труда. А теперь - The Gorilla project has been archived, and is no longer under active maintainenance.
По поводу когда у вас просили скидку, и вы сделали еще скидку в 2%.
Вы говорили ЛПРу что уже дали скидку 30%? Это общий посыл.
Я бы ответил как-то так (все зависит от интонации и т.д., у вас диалог может быть другой):
Иван Сергеевич, я уже поговорил с Владимиром Петровичем и конечно же предоставил Вашей фирме скидку в 30%.
Я тут подумал, скорее всего эффективный батчинг - это реально то место, где можно что-то доработать, и действительно является недоработанным местом текущих ORM, и там можно что-то сделать. Но скорее всего там будет другой метод сохранения сущностей, т.к. нельзя при дефолтном вызове save открывать транзакции, рассчитывать что надо как-то доработать клиентский код под откат батчинга и т.д. Пока катимся на голом SQL.
Допустим вы загрузили из базы 10 товаров и у них поменяли prop1 = value1. А у четных товаров еще поменяли prop2 = value2, просто для сферического примера.
Когда вы сохраняете товары по-одному, у вас товар сохраняются единой сущностью, т.е. либо весь товар сохранен, либо весь не сохранен. Т.е. генерируется запрос update product set prop1 = value1, prop2 = value2 where id = 1. И так для 10 товаров по очереди.
А если оптимизировать скорость и разбивать данное обновление с помощью крутой ORM автоматически на 2 SQL запроса: update product set prop1 = value1 where id in (1, 2, 3, ..., 10), а потом update product set prop2 = value2 where id in (2, 4, 6, ..., 10), то в случае невыполнения 2-го запроса, т.е. если он завершился с ошибкой у вас в базе и в вашем аппликейшене будет полностью мешанина из обновленных данных и не обновленных - часть полей обновилась, часть не обновилась, непонятно что обновилось а что не обновилось, и у каких товаров. Откатить выполнившиеся update'ы в базе не всегда возможно, по-этому придется проверять и разруливать ситуацию в ручную всегда, писать кастомный код, а разрулить данную ситуацию в плане объектов ORM будет в ну очень сложно.
По-этому для таких ситуаций пишут голый SQL, которые сделает необходимые обновления. И это гораздо проще, чем потом разрулить ситуацию с частично обновленными 10 товарами. Т.е. прям в коде пишешь функцию: update product set prop1 = :prop1_value where id in (:prop1_update_ids). И потом еще один SQL: update product set prop2 = :value2 where id in (:prop2_update_ids), и всё, код очень простой. По сравнению с тем, что надо писать метод прохода по 10 товарам и проверки, что в них обновилось а что - нет и отката всего до какого-то нормального состояния когда автоматический откат невозможен (а непонятно что ORM смогло откатить назад автоматически, а что не смогло, по-этому проверять надо всё).
Думаю для возраста 16-21 и стажа 0,1,2 коэффициент одинаковый, и их можно объединить в 1 запись. И тогда получится 20 записей.
При варианте с 3 таблицами, похоже никто не мешает вставить повторяющиеся диапазоны и в таблицу возраста и в опыта. Контроля уникальности нет. Тогда этот вариант можно заменить 1 таблицей: id, age_from, age_to, experience_from, experience_to, coefficient.
Давайте озвучим это: каждый хочет жить подольше. Мы ходим на работу чтобы когда-нибудь заработать столько денег, чтобы можно было не умирать вообще. Это если "типа" математически строго создавать теорему жизни и подходить к этому вопросу через строгие типа математические доказательства (не совсем математика, но какая-то формальная строгость и формальная правильность бытия). Другие конечно кажут - зачем нужна формальная "теория всего" и т.д., хочу просто веселиться, хорошо кушать. гулять, хорошо проводить время с другими и всё, т.е. без всяких великих теорий.
добро пожаловать в будущее
Я тоже дам определение на интересный вопрос. Ну например я вижу камень лежит на земле. Между камнем и землей происходит какое-то взаимодействие. Вот если взять весь спектр таких взаимодействий, все их (гравитация там, электромагнитные взаимодействия и т.д.), то это реальность.
Раньше были интересные курсы от Академия 1С-Битрикс, я смотрел
№1 - Интеграция дизайна и настройка платформы
№2 - Основные технологии и расширение типовых возможностей системы
№3 - Расширенные технологии и производительность
D7. Разработка собственного модуля
В кодовой базе - вам не разобраться. Я бы советовал именно "трясти дерево" как вы говорите. Т.е. вызывать функции с типовыми параметрами, и не рекоммендовал лезть сильно глубоко внутрь. Там очень сложный и непонятный код. Эффективно работать с 1С-Битрикс == хорошо знать как работать с функциями в основном инфоблоков (CIBlockElement::GetList и т.д.), catalog, sale, но != залезть в них внутрь и заковыряться там.
Я веб бекендер разработчик с большим опытом. Могу сказать что Битрикс - самая трудная система. Он сложнее: Laravel, Symfony, Python Django, C# .NET, и даже Java Spring. Огромная кодовая база. Под разобраться - я имею ввиду реально знать как работает CIBlockElement::GetList, прям залезть внутрь и разобраться, а не уметь вызывать его с типовыми параметрами.
UPD: а, да, сейчас там же делается через D7, что-то вроде \Bitrix\Iblock\Iblock::wakeUp. Но все равно, сути это не меняет.
Не, вот сейчас второй раз запустил - нормальная музыка пошла.
У меня в "Бодрость" какая-то циркулярная пила разных тонов.