Человек на полном серьезе написал, что механизм аппроксимации (нейросеть) позволяет аппроксимировать (приблизительно вычислить) аппроксимируемую функцию?
Гениально…
С нетерпением жду статьи про ряды
Стесняюсь спросить, но а о какой схеме начисления процентов идет речь?
Ануитет? Вначале основной долг а потом проценты или наоборот?
Есть ли льготная схема погашения кредита? Или по ипотеке все-все-все стандартизировано?
По поводу переплаты — "переплата" — это проценты + комиссии? Если банку не выкручивают руки, то свои проценты и комиссии он всегда возьмет, и вариантов со снижением переплаты не будет. Если же это льготный кредит, да еще и с ануитетом с погашением основного долга вначале, то тут да, можно много сэкономить, если вовремя кредит вернуть. Во всех остальных случаях "банк своего не упустит".
Цель проекта (определяемая как углубленное исследование темы, достойной изучения) заключается в том, чтобы узнать как можно больше о данной теме, а не искать правильные ответы на вопросы, заданные учителем.
Т.е., как я это понимаю (и как вижу со своей стороны, как это работает) нашли хайповую тему — изучили тему — ищем новый хайп. Узко, конкретно, но максимально быстро/практично здесь и сейчас. Если есть база — работает шикарно (быстрый результат). Нет базы — все грустно и печально.
А чтобы искать правильные ответы на вопросы — надо уметь учиться (ну или уметь анализировать вопросы + находить ответы). Что подразумевает некую широту базовых знаний (базу).
Статья о том, что универсальное образование с ключевым обучением умению обучатьсяважнее чем изучение трендовых дисциплин/фреймворков/технологий/языков???
Стесняюсь спросить, что что это за бред?
Заголовок
Мы сейчас стоим на пороге новой эры облачных вычислений
И в тексте за исключением легкого упоминания
Быстрые мобильные сети с минимальной скоростью минимум 10 Гб/с
(тонкий намек на сети 5G и на последнюю презентацию гугла с его игровым стримингом)
ничего нового нет! Эти облака уже лет 10 как (или больше) активно живут и развиваются.
И как-бы люди этим уже давно и активно пользуются. За исключением игрового стриминга, который вроде как первой NVidia пыталась стартануть, и теперь вот Гугл разродился.
Все.
Может и надо было о стриминге писать?
А так — пустая статья.
Опять статья про нетехнического проектного менеджера (PM) чьи недостатки компенсируются прокачанным лидром команды (Team Lead), по факту выполняющим функции технического менеджера проекта?
Я думаю, в основном потому, что авторы хотят показать, откуда эта абстракция исторически возникла. С другой стороны, это не вредно: категории и функторы сами по себе являются полезными абстракциями, имеющими множество имплементаций.
У меня ни разу не возникло возражений при подобном описании монад в учебниках по Хаскелю, написаных скорее математиками для математиков, чем инженерами для инженеров (разве что только один раз видел исключение у Шевченко (https://www.ohaskell.guide)). Но когда в заголовке вижу "Монады с точки зрения программистов" ожидаю все-таки инженерный подход. Sorry.
Представьте, что вы рассказываете про паттерн «абстрактная фабрика» студенту, который ещё ни разу не сталкивался с проблемами, которые этот паттерн решает: студент будет удивляться, зачем такая сложная штука нужна.
Скажу больше — неоднократно это делал причем не только для студентов-программистов, но и для гуманитариев, решивших стать программистами. Там гораздо сложнее было объяснить, что такое переменная и зачем нужна функция, чем на паре практических примеров показать, сколько кода надо писать с фабрикой и без.
Мне всегда интересно было, почему, например, Монаду нельзя описать как некую хрень с сайдэффектом (нечто, что, например, пишет инфу в базу, в поток) или как некую защитную обертку над другими типами (Maybe вообще шикарно соотвествует Nullable из какого-нибудь C#). Почему обязательно пытаться притягивать категории, функторы? Я понимаю, что высокая наука требует применения спецтерминов, чтобы доказать свою научность. Но инженерная практика работает то с чем-то более осязаемым...
И кстати, я случаем не пропустил в статье сказочное утверждение, что в хаскеле попав в монаду, из нее нельзя выйти?
Я наверное туплюю сегодня, но зачем это делать? Вроде ж как подобные полеты в реальности были, американцы на апполонах все уже проверили. Зачем опять то? Что-то поменялось?
Опять топливные элементы. Лет 10 назад вроде как все только о них говорили. Обещали, что вот-вот… А случился Маск, Тесла и литиевые батарейки…
Где мой обещанный электромобиль на топливных элементах?!!!!!!
Боже ты мой. Когда-то давным давно все старались делать на STL. При этом апологеты Boosta вопили, какие все тупые идиоты, что с STL не слазят. Апологеты победили. Все стали юзать буст… А теперь "внезапно" пошел откат? Здравый смысл одержал победу на дизайном? Не верю :)
Часто и внезапно на невинных запросах выскакивает Request Rate is Large. Обычное решение — попытаться несколько раз повторить запрос через задержку от 1 до 10 MS или, что рекомендует MS, увеличить выделяемые на коллекцию RU. Для непартиционных коллекций особой беды нет (разве что денег больше возьмут), для unlimited при интенсивных вставках легко нарваться в размножение партиций с последующей нехваткой RU и, соответсвенно, сообщениями Request Rate is Large.
Я с этим помнится уж наигрался, так наигрался. Даже статейку задумывал написать про то, как "правильно готовить космос"… Но что-то не срослось.
Судя по описанию, AWS DocumentDB будет куда как лояльнее к пользователями чем Mongo Endpoint от Cosmos DB. И я ОЧЕНЬ надеюсь, что RU-проклятья пользователям AWS удастся избежать. Иначе нафиг все это надо.
Мне чисто интересно, куда MS смотрел, у которого Cosmos DB был сделан как дальнейшее развитие ихнего же DocumentDB. И более того, ссылки по DocumentDB будут вести не на AWS, а на Azure! Ждем суда?
Человек на полном серьезе написал, что механизм аппроксимации (нейросеть) позволяет аппроксимировать (приблизительно вычислить) аппроксимируемую функцию?
Гениально…
С нетерпением жду статьи про ряды
Мне иногда кажется, что те, кто пишут про оптимизацию на python тупо издеваются...
Статья была бы шикарная, если бы не слегка странноватый стиль изложения. А по сути сложно не согласиться
Круто! Один вопрос — почему 3 AAA батарейки вместо каких-нибудь мелких CRок?
Очень рекомендую глянуть https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%BD%D1%83%D0%B8%D1%82%D0%B5%D1%82
Особенно пробежаться по разным табличкам.
Аннуитет решает задачу равных регулярных выплат ну очень разнымы способами, и в зависимости от настроек банковского продукта могут весьма неожиданные вещи вылазить.
Ой ли...
Стесняюсь спросить, но а о какой схеме начисления процентов идет речь?
Ануитет? Вначале основной долг а потом проценты или наоборот?
Есть ли льготная схема погашения кредита? Или по ипотеке все-все-все стандартизировано?
По поводу переплаты — "переплата" — это проценты + комиссии? Если банку не выкручивают руки, то свои проценты и комиссии он всегда возьмет, и вариантов со снижением переплаты не будет. Если же это льготный кредит, да еще и с ануитетом с погашением основного долга вначале, то тут да, можно много сэкономить, если вовремя кредит вернуть. Во всех остальных случаях "банк своего не упустит".
Терзают смутные сомнения, что не совсем.
Согласно https://sites.google.com/site/projektitegevus/proektnoe-obucenie:
Т.е., как я это понимаю (и как вижу со своей стороны, как это работает) нашли хайповую тему — изучили тему — ищем новый хайп. Узко, конкретно, но максимально быстро/практично здесь и сейчас. Если есть база — работает шикарно (быстрый результат). Нет базы — все грустно и печально.
А чтобы искать правильные ответы на вопросы — надо уметь учиться (ну или уметь анализировать вопросы + находить ответы). Что подразумевает некую широту базовых знаний (базу).
Статья о том, что универсальное образование с ключевым обучением умению обучаться важнее чем изучение трендовых дисциплин/фреймворков/технологий/языков???
Да кто бы мог подумать то....
Стесняюсь спросить, что что это за бред?
Заголовок
И в тексте за исключением легкого упоминания
(тонкий намек на сети 5G и на последнюю презентацию гугла с его игровым стримингом)
ничего нового нет! Эти облака уже лет 10 как (или больше) активно живут и развиваются.
И как-бы люди этим уже давно и активно пользуются. За исключением игрового стриминга, который вроде как первой NVidia пыталась стартануть, и теперь вот Гугл разродился.
Все.
Может и надо было о стриминге писать?
А так — пустая статья.
Опять статья про нетехнического проектного менеджера (PM) чьи недостатки компенсируются прокачанным лидром команды (Team Lead), по факту выполняющим функции технического менеджера проекта?
У меня ни разу не возникло возражений при подобном описании монад в учебниках по Хаскелю, написаных скорее математиками для математиков, чем инженерами для инженеров (разве что только один раз видел исключение у Шевченко (https://www.ohaskell.guide)). Но когда в заголовке вижу "Монады с точки зрения программистов" ожидаю все-таки инженерный подход. Sorry.
Скажу больше — неоднократно это делал причем не только для студентов-программистов, но и для гуманитариев, решивших стать программистами. Там гораздо сложнее было объяснить, что такое переменная и зачем нужна функция, чем на паре практических примеров показать, сколько кода надо писать с фабрикой и без.
Мне всегда интересно было, почему, например, Монаду нельзя описать как некую хрень с сайдэффектом (нечто, что, например, пишет инфу в базу, в поток) или как некую защитную обертку над другими типами (Maybe вообще шикарно соотвествует Nullable из какого-нибудь C#). Почему обязательно пытаться притягивать категории, функторы? Я понимаю, что высокая наука требует применения спецтерминов, чтобы доказать свою научность. Но инженерная практика работает то с чем-то более осязаемым...
И кстати, я случаем не пропустил в статье сказочное утверждение, что в хаскеле попав в монаду, из нее нельзя выйти?
Я наверное туплюю сегодня, но зачем это делать? Вроде ж как подобные полеты в реальности были, американцы на апполонах все уже проверили. Зачем опять то? Что-то поменялось?
Да… Мелковато… До "русских физиков, выбирающих Slack" на LoRе не дотягивает…
Да и тема стеклянного потолка не раскрыта.
Опять топливные элементы. Лет 10 назад вроде как все только о них говорили. Обещали, что вот-вот… А случился Маск, Тесла и литиевые батарейки…
Где мой обещанный электромобиль на топливных элементах?!!!!!!
Что-то мне это напомнило старый добрый TheBat и чат функцию, реализованную там…
Эх. Явно история сделала очередную спирать.
Боже ты мой. Когда-то давным давно все старались делать на STL. При этом апологеты Boosta вопили, какие все тупые идиоты, что с STL не слазят. Апологеты победили. Все стали юзать буст… А теперь "внезапно" пошел откат? Здравый смысл одержал победу на дизайном? Не верю :)
Часто и внезапно на невинных запросах выскакивает Request Rate is Large. Обычное решение — попытаться несколько раз повторить запрос через задержку от 1 до 10 MS или, что рекомендует MS, увеличить выделяемые на коллекцию RU. Для непартиционных коллекций особой беды нет (разве что денег больше возьмут), для unlimited при интенсивных вставках легко нарваться в размножение партиций с последующей нехваткой RU и, соответсвенно, сообщениями Request Rate is Large.
Я с этим помнится уж наигрался, так наигрался. Даже статейку задумывал написать про то, как "правильно готовить космос"… Но что-то не срослось.
Судя по описанию, AWS DocumentDB будет куда как лояльнее к пользователями чем Mongo Endpoint от Cosmos DB. И я ОЧЕНЬ надеюсь, что RU-проклятья пользователям AWS удастся избежать. Иначе нафиг все это надо.
Мне чисто интересно, куда MS смотрел, у которого Cosmos DB был сделан как дальнейшее развитие ихнего же DocumentDB. И более того, ссылки по DocumentDB будут вести не на AWS, а на Azure! Ждем суда?