Я, может быть, чего-то и не совсем верно понимаю в теоретической стройности, но я часто сталкиваюсь с проектами, выбравшими Монгу когда-то на старте и теперь страдающими от необходимости костылить обработку взаимосвязей (они то, сюрприз-сюрприз, из предметной области никуда не делись) вне сервера, героически переизобретая алгоритмы, используемые в серверах РСУБД.
Монга прекрасна для проектов, живущих в условиях сильной неопределенности, условных «стартапов», у которых есть идея, наброски реализации, которые сами не знают, чего они (и их пользователи!) захотят послезавтра и к чему они придут в плане данных. Нет достаточно квалифицированных специалистов, чтобы в техническом и экономическом плане проработать продукт на бумаге до начала реализации. Набираем экспертов по объявлениям и в скрамно-аджайловом темпе поскакали навстречу неизвестности!
К этому всему должны прилагаться наполеоновские планы по количеству хранимых данных. (так как на небольших базах двинуть схему — и проблема, соответственно, не большая).
Такой подход очень часто оправдан с точки зрения бизнеса, как по затратам, так и по времени до первого выхода на рынок.
Со временем такие проекты начинают сталкиваться с хорошо известными проблемами, приведшими человечество к реляционным базам данных: обеспечивать консистентность данных на стороне клиента — медленно и глупо, на стороне сервера приложения — трудоёмко и совсем не так весело, как запиливать фичушички и свистелки на ранних стадиях развития.
Таким образом, Монга хороша и полезна там, где она действительно хорошая и полезна, исходя из требований проекта, а вовсе не везде, куда её бездумно и безудержно суют (кстати, по личным ощущениям — уже гораздо меньше, хайп NoSQL, к счатью, поутих).
Совещания помимо удовлетворения простых человеческих потребностей «пообщаться» на более-менее профессиональные темы с себе подобными, а не втыкать всё время в тикеты с реквестами, нужны также и для неформального обмена мнениями.
В поэтапном плане не напишешь вещей типа: «этот костыль перепишем позже», «ту мудацкую хотелку начнем делать после актирования основного функционала, за доп. плату» — и прочие мнения, указания, договоренности, необходимые команде, но плохо формализуемые в документах.
Конечно же, совещаниями, как и всем остальным можно команду зае… ть. На то архитектору (или все-таки тим лиду?) голова и выделена, чтобы искать системный баланс, как в проекте, так и в используемых инструментах управления исполнителями.
Осталось преимущество FF в виде отключаемой (со всё большим трудом) телеметрии и затыкаемых (но неуёмно плодящихся) дырах в приватности, в отличии от неотключаемой и незатыкаемых в Хроме.
В дурной притче же прекрасно всё, от реально нездорового головой короля, верящего в идиотские советы времен первобытной передачи «силы» убитого тигра через ношение его шкуры, до передергиваний понятия счастья и сравнения счастья познавшего разнообразие жизни короля и узколобого бомжа у дороги, которому в объективных обстоятельствах ничего не остается, кроме как весело петь и верить в то, что он и так счастлив (ну или выпилиться, что, может быть, и было в недалеких планах). Еще б к собаке обратились, да жаль она рубах не носит.
Не совсем понимаю, с чем именно вы не согласитесь.
Лично я вел лекции в обычном порядке, без проекторов и слайдов, с объяснением на доске. Просто давал возможность не записывать весь текст, один раз уже записанный мною, а скачать его в виде pdf файла.
Не требовал, не собирал и не проверял конспекты, так как не имел желания тратить на это своё время и время студента. Объяснял, что отсутствие требования не означает, что нужно расслабиться и ничего не писать вовсе, а наоборот, студент, как взрослый человек, должен понять, помогает ли записывание укреплению его понимания предмета или нет, и выбрать сам, нужно ему это или нет.
Рекомендовал писать (рукописные) шпоры к экзамену, так как материал, проходящий через мозг во время сжатия конспекта до шпоры может оставить там весьма качественный след понимания структуры и логики материала. Настолько качественный, что при хорошей памяти, шпора в идеале на экзамене вообще не понадобится.
Поэтому с моей точки зрения способ конспектирования, рекламируемый в данной статье (тратить лекционное время на расстановку машиночитаемого форматирования только для того, чтобы на выходе получить красивый макет конспекта), кажется, как минимум, мало полезным, а с учетом необходимости концентрации внимания для понимания некоторых сложных абстракций и методов — и вредным.
Это вдвойне удобно еще и потому, что проглядев материал грядущей лекции онлайн и поняв, что конкретно этот кусок каких-то особенных разъяснений не требует, можно её с чистой совестью променять на что-то более полезное: библиотеку, работу, общение с друзьями, драгоценный сон.
Лично меня всегда убивала лекция в формате диктанта. Удивляло, почему бы не дать студентам скопировать(скачать) нормальный полный и подробный текст лекции, записанный лектором (то, что он иногда ленится вообще что-либо писать и диктует из остатков памяти с дикого бодуна — другая проблема).
Конспект же лекции, записанный именно студентом, может быть полезен для фиксирования каких-то примеров, пояснений, ценных мыслей, аналогий, связок, которые появляются при прослушивании лекции.
В (недолгую) бытность свою преподавателем старался избегать лекций-диктантов в пользу лекций-объяснений (рассказов), пытаясь донести историческую и логическую связанность темы с предыдущими, показать как и почему люди вообще до этого додумались, какой класс задач решали, что им помогало, что мешало, ход рассуждений и основания выводов. Результат был весьма неплохой, удавалось помочь желающим и, как минимум, разбудить и заинтересовать халявщиков (которые потом с горящими глазами на экзамене признавались, что это редкий случай, когда им не страшно тащить билет).
Это не ноу-хау и не открытая Америка, просто странно, что до сих пор много кто так не делает, предпочитая формально оттарабанить лекцию под запись (что, кстати, снижает скорость подачи материала примерно раза в 3).
Просто ret. Он вытаскивает со стека заботливо положенные туда нули и программа переходит на cs:0000, где находится также заранее заготовленный (та-да-дам) CD 20 (int 20h).
C iret'ом улетите далеко и надолго. Кроме смещения он вытаскивает со стека и восстанавливает сегментный регистр и сохраненные флаги, что, скорее всего, закончится фатально для DOS (или её эмулятора).
Сначала даём возможность фронту (и всем-всем-всем) нагружать бэк слабо контролируемыми запросами, потом мужественно пытаемся решить эту проблему.
Экономия на написании нормальных API эндпоинтов с предсказуемой логикой выливается в издержки по дальнейшему окостыливанию наколеночного GraphQL поделия.
P.S. требования 'гибкости' продукта обычно произрастают из хренового планирования, как бизнес- так и технологической части. Конечно, зачем тратиться на аналитиков и прорабатывать модели и архитектуру, когда можно захреначить в продакшен вот уже завтра (конкуренты же так и ходят стаями!), «а там посмотрим».
Вы правы по поводу причин распространения и развития JS.
Но от стадии 'legacy-говнища' шагнул он знатно и теперь шикарно смотрится на фоне отстающих собратьев, не говоря уже о шизофреническом питоне.
Особенно если сапописанный бэкенд это мерзкий питон
При живом Go, Nodejs, и даже, прости господи, PHP делать web на питоне, по крайней мере, странно.
Эти отступы, двойные подчеркивания, явный self и document[«id»] вместо document.id сделаны как-будто специально, чтобы вывести из равновесия даже самого флегматичного кодера.
Сам по себе язык не хуже других, но эстетические чувства раз от разу страдают.
К этому всему должны прилагаться наполеоновские планы по количеству хранимых данных. (так как на небольших базах двинуть схему — и проблема, соответственно, не большая).
Такой подход очень часто оправдан с точки зрения бизнеса, как по затратам, так и по времени до первого выхода на рынок.
Со временем такие проекты начинают сталкиваться с хорошо известными проблемами, приведшими человечество к реляционным базам данных: обеспечивать консистентность данных на стороне клиента — медленно и глупо, на стороне сервера приложения — трудоёмко и совсем не так весело, как запиливать фичушички и свистелки на ранних стадиях развития.
Таким образом, Монга хороша и полезна там, где она действительно хорошая и полезна, исходя из требований проекта, а вовсе не везде, куда её бездумно и безудержно суют (кстати, по личным ощущениям — уже гораздо меньше, хайп NoSQL, к счатью, поутих).
Короткий ответ — «нет», длинный — тоже «нет».
В поэтапном плане не напишешь вещей типа: «этот костыль перепишем позже», «ту мудацкую хотелку начнем делать после актирования основного функционала, за доп. плату» — и прочие мнения, указания, договоренности, необходимые команде, но плохо формализуемые в документах.
Конечно же, совещаниями, как и всем остальным можно команду зае… ть. На то архитектору (или все-таки тим лиду?) голова и выделена, чтобы искать системный баланс, как в проекте, так и в используемых инструментах управления исполнителями.
Ну какие же суки!
А пользователя спросить при первой необходимости после обновления?!
трудно не согласиться
В дурной притче же прекрасно всё, от реально нездорового головой короля, верящего в идиотские советы времен первобытной передачи «силы» убитого тигра через ношение его шкуры, до передергиваний понятия счастья и сравнения счастья познавшего разнообразие жизни короля и узколобого бомжа у дороги, которому в объективных обстоятельствах ничего не остается, кроме как весело петь и верить в то, что он и так счастлив (ну или выпилиться, что, может быть, и было в недалеких планах). Еще б к собаке обратились, да жаль она рубах не носит.
Лично я вел лекции в обычном порядке, без проекторов и слайдов, с объяснением на доске. Просто давал возможность не записывать весь текст, один раз уже записанный мною, а скачать его в виде pdf файла.
Не требовал, не собирал и не проверял конспекты, так как не имел желания тратить на это своё время и время студента. Объяснял, что отсутствие требования не означает, что нужно расслабиться и ничего не писать вовсе, а наоборот, студент, как взрослый человек, должен понять, помогает ли записывание укреплению его понимания предмета или нет, и выбрать сам, нужно ему это или нет.
Рекомендовал писать (рукописные) шпоры к экзамену, так как материал, проходящий через мозг во время сжатия конспекта до шпоры может оставить там весьма качественный след понимания структуры и логики материала. Настолько качественный, что при хорошей памяти, шпора в идеале на экзамене вообще не понадобится.
Поэтому с моей точки зрения способ конспектирования, рекламируемый в данной статье (тратить лекционное время на расстановку машиночитаемого форматирования только для того, чтобы на выходе получить красивый макет конспекта), кажется, как минимум, мало полезным, а с учетом необходимости концентрации внимания для понимания некоторых сложных абстракций и методов — и вредным.
Конспект же лекции, записанный именно студентом, может быть полезен для фиксирования каких-то примеров, пояснений, ценных мыслей, аналогий, связок, которые появляются при прослушивании лекции.
В (недолгую) бытность свою преподавателем старался избегать лекций-диктантов в пользу лекций-объяснений (рассказов), пытаясь донести историческую и логическую связанность темы с предыдущими, показать как и почему люди вообще до этого додумались, какой класс задач решали, что им помогало, что мешало, ход рассуждений и основания выводов. Результат был весьма неплохой, удавалось помочь желающим и, как минимум, разбудить и заинтересовать халявщиков (которые потом с горящими глазами на экзамене признавались, что это редкий случай, когда им не страшно тащить билет).
Это не ноу-хау и не открытая Америка, просто странно, что до сих пор много кто так не делает, предпочитая формально оттарабанить лекцию под запись (что, кстати, снижает скорость подачи материала примерно раза в 3).
Ведь при прыжке есть ненулевая вероятность «случайно» сломать ногу, и тогда этот ад как-нибудь закончится. С точки зрения психоанализа.
C iret'ом улетите далеко и надолго. Кроме смещения он вытаскивает со стека и восстанавливает сегментный регистр и сохраненные флаги, что, скорее всего, закончится фатально для DOS (или её эмулятора).
Экономия на написании нормальных API эндпоинтов с предсказуемой логикой выливается в издержки по дальнейшему окостыливанию наколеночного GraphQL поделия.
P.S. требования 'гибкости' продукта обычно произрастают из хренового планирования, как бизнес- так и технологической части. Конечно, зачем тратиться на аналитиков и прорабатывать модели и архитектуру, когда можно захреначить в продакшен вот уже завтра (конкуренты же так и ходят стаями!), «а там посмотрим».
Но от стадии 'legacy-говнища' шагнул он знатно и теперь шикарно смотрится на фоне отстающих собратьев, не говоря уже о шизофреническом питоне.
При живом Go, Nodejs, и даже, прости господи, PHP делать web на питоне, по крайней мере, странно.
Эти отступы, двойные подчеркивания, явный self и document[«id»] вместо document.id сделаны как-будто специально, чтобы вывести из равновесия даже самого флегматичного кодера.
Сам по себе язык не хуже других, но эстетические чувства раз от разу страдают.