Вот я и спрашиваю, зачем? В большинстве случаев, можно обойтись без картинок. Лично мне, они больше мешают, чем помогают. Возможно, это так делается, чтобы чисто мнемонически привязать конкретную статью к картинке. Использовать картинку как удобный якорь для памяти. Лично меня такие картинки иногда даже раздражают. Зато там где надо, картинок нет. В этом смысле, более полезным был бы сервис, которому можно было "скармливать" куски читаемого текста и визуализировать то, о чём там говорится. В этом случае. автор текста мог бы выставлять в тексте невидимые подсказки для LLM, которые вместе с указаниями пользователя превращаются в точный промпт.
А зачем, вообще, кому-то нужно что-то создавать? Да, отдельные эксперименты могут быть интересны. Как инструмент, реализующий некоторые особые идеи художников, да. Но зачем нужна эта генерация в промышленным масштабах? И не окажется ли потом, что все эти картинки, "нарисованные" ИИ, обладают неким дефектом (пока ещё не вполне осознаваемым), который плохо влияет на мозги. Рискну предположить и такое. Уж, извините.
Фильм с какой-то своей атмосферой. Несмотря на некоторую стереотипность образов и совершенную вычурность насквозь фантастического/сказочного сюжета. Но! Всегда приятно, когда зло наказывают. Даже если ради этого надо накрутить всякого сюжетного трэша. Главное, показать побольше всяких загадочных картинок. Особенно "убило" эдакое картинное "хождение по системе". Но фильм забавный. И... все ещё такие молодые!
У нас зачем-то назвали фильм про Кевина Митника "Хакеры 2", хотя он никакого отношения к оригинальным "Хакерам" не имел. Это там где главного героя играл Скит Ульрих. (Разве что, Скит Ульрих играл вместе с Мэтью Лиллардом (вот он сидит на картинке с зубной щёткой) в фильме "Крик". Но это только очень косвенная связь.) Зато фильм оказался удивительно достоверен (не смотря на всю свою художественность) в плане противостояния Митника с Симоммурой.
Если мы реализуем вычисление на несколько страниц формул или какую-нибудь сборку пакета стандартного формата из нескольких тысяч полей, то как ещё это нужно писать, кроме простыни последовательных операторов присваивания?
Подождите! А почему мы не хотим всё это хозяйство как-то автоматизировать? Почему мы не можем несколько тысяч полей пройти в цикле? Откуда, кстати, взялись тысячи полей?
В рамках патча Оверстрита добавленная опция journal_rewind откатывала изменения в журнале для сброса ФС в более раннее состояние.
хм... Может быть, лучше было бы написать "в предыдущее" или "в одно из предыдущих"?
А. вообще, было интересно узнать про достижения в области построения файловых систем. Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
Если бы Вас интересовало бы существо дела, то тут было бы оно из двух: либо автор книги (Роберт Мартин?) где-то здорово промахнулся, и чей-то опыт об этом ярко свидетельствует, либо где-то искажена мысль самого автора (при изложении). Наша задача в чём заключается? В том, чтобы лучше программировать.
Принцип единственной ответственности (Single Responsibility Principle - SRP): У класса должна быть только одна причина для изменения. Если класс делает слишком много, его нужно разбить. Признаки нарушения SRP: Много несвязанных методов/полей, частые изменения в разных местах класса по разным причинам, большой размер.
В этом смысле, поражают визуальные компоненты. В них собрана куча разнородных функций! Следовало бы разделить. Почему никто так и не разделил?
А ещё есть такой вопрос: а нужен ли здесь обязательно какой-нибудь класс?
Инкапсуляция: Скрывайте данные и детали реализации! Делайте поля приватными. Предоставляйте доступ через методы / свойства. Ослабляйте уровень доступа только при явной необходимости.
Все так советуют делать. Вроде бы, азы ООП. Напоминает одну детскую книжку:
– Я умею кое-что получше.
– Все говорят «я умею кое-что получше», – засмеялись ребята.
– Правду говорю!
– Все говорят «правду говорю!»
– Да ну вас!
– Все говорят «да ну вас!»
Композиция прежде наследования (Composition over Inheritance): Наследование создаёт сильную связь между классами. Часто композиция (включение одного класса в другой как поле) + интерфейсы дают больше гибкости.
Наверное, в таком стиле (как в приводимом примере) можно многое переписать...
А ещё больше гибкости даёт таблица попарных отношений между классами, когда каждой упорядоченной паре классов соответствует свой способ взаимосвязи.
Вообще говоря, очень хотелось бы всегда из функции возвращать целый объект, а не какой-то отдельный код. Такой объект фиксировал бы состояние вызываемой функции на момент возврата (удачного или неудачного) и содержал бы как само возвращаемое значение (если оно есть), так и описание ошибки (если она случилась).
Наверное, существуют две школы: школа любителей исключений и школа любителей кодов ошибок.
Сначала пишите Try-Catch-Finally: Обрабатывайте код, который может выбросить исключение, блоком try. Обрабатывайте конкретные исключения в catch. Освобождайте ресурсы в finally.
Верно ли я понимаю, что мне нужно оформить в виде исключения ситуацию, когда, например, у квадратного уравнения не оказывается вещественных корней, а нужны именно вещественные? И какая будет разница между исключениями и кодами ошибок?
А, ведь, можно пойти ещё дальше и, вообще, весь код построить на исключениях! А что? Удобно! Дошёл до конца списка — выкинул исключение. Можно было бы даже из вложенных циклов выходить вместо break и с подробным описанием уровня, с которого выскочили.
Не возвращайте null! Это источник NullReferenceException (для C#, аналогично в других языках). Возвращайте пустые коллекции (Enumerable.Empty(), new List()), используйте Nullable<T> для значимых типов, применяйте паттерн Null Object.
Эххх... Вот, во времена засилья C/C++ очень любили всё сравнивать с NULL. Автор книги, наверное, перебрал с C/C++. Впрочем, вопрос интересный. Мне кажется, что "пустой объект" отдельного ото всех типа (как в Python) — это хорошая идея. Думаю, здесь есть, что обсудить.
Не передавайте null! Это смещает ответственность за проверку на вызывающего. Бросайте ArgumentNullException в начале метода, если null недопустим.
И что мы должны сделать, если такое исключение выкинется?
Нужен не просто сертификат а реальное подтверждение квалификации. А для этого надо, чтобы квалификация была. Чтобы любая, даже, самая простая работа, хорошо выполнялась .
Во всех подобных разговорах никак не учитывается, что образование (как и всё в этом мире) держится на людях. Пока были дореволюционные преподаватели и их ученики, а потом послевоенные преподаватели и их ученики, уровень и держался. Советская система образования (как система вообще, и как советская система) так и не смогла ничего воспроизвести. Воспроизводимость требует вложений. И денежных то же. Советская система, действительно, оказалась, во многом бесплатной. Учителя уходили, а на их место было некому приходить. Экспериментальные школы оказались на совершенной периферии. Да, надо было поддерживать приток специалистов в нужные отрасли. С этим система справлялась. Но всеобщего массового образования получится никак не могло. А с другой стороны, реальная потребность в специалистах стала падать после создания атомного оружия и т.п. успехов. Вот чем занималась наука и производство в 70-тых и в 80-тых? Выполняло план? Стагнировало? Какие-там вызовы времени?
Да. К этому надо быть готовым всем участникам процесса. Чтобы как-то сократить неприятности от этого, надо, всего лишь, чтобы все компании обучали собственных сотрудников (а не искали их на стороне) и чтобы компании привлекали бы себе сотрудников интересными задачами. При этом, такое обучение должно идти в довесок к курсам, и, возможно, даже и оплачиваться самим работодателем. Потому как курсы могут дать (и должны давать) только некоторые общие представления о предмете, но никак не гарантию трудоустройства. Хотя, может быть, особо ретивых выпускников специализированных курсов (где целенаправленно учат конкретным технологическим инструментам или долго чему-то учат) и присматривают уже в компании.
Я тоже сейчас прохожу один такой простой курс по Питону. Но это мне нужно именно для фундамента, чтобы уверенно использовать этот язык. Чтобы реальные приложения писать. Не более.
Хотя, да, было бы здорово найти контору, где тебе могли позволить какое-то время поучиться в реальных условиях с наставником, что-называется, за небольшие деньги, но зато, с приобретением какого-то реального опыта, хорошо себя зарекомендовать и, затем, войти уже в нормальный штат. Понимаю, что такая идеальная ситуация практически неосуществима. Особенно, для человека в возрасте. Особенно, в наше время, когда всё в каком-то кризисе, когда все выживают, а не развиваются.
Следующий логичный шаг в развитии e-mail — более полная интеграция с искусственным интеллектом, который сможет не просто сортировать почту, расставлять приоритеты, прибивать спам и маркировать фишинговые сообщения, но и самостоятельно планировать встречи, звонки, мероприятия, опираясь на полученные сообщения.
А что может быть для сортировки почты ИИ? То, что касается спама. Здесь должна быть возможность установления связи с отправителем: во-первых, Вы должны точно знать, от кого Вы получаете почту, и, если Вы не хотите получать почту от определённого отправителя, то Вы просто отписываетесь. Во-вторых, если бы почта оставалась текстовой (в plain text), то всё было бы гораздо проще и безопаснее. Не было бы ссылок, по которым можно было бы получить вирус или сходить на фишинговый сайт. Нужны новые возможности — разрабатывайте новый протокол поверх старого. Далее, если я работаю с каким-то сайтом, то, в идеале, я должен его "установить" себе в системе, и тогда я буду получать письма только от этого сайта. Почему, вместо того, чтобы предложить людям более развитую инфраструктуру, мы модернизируем почту и допускаем опасное использование?
Возможно даже, однажды он догадается поздравить отдельным письмом моего редактора с днем рождения, потому что сам я опять забуду это сделать.
Какой в этом смысл? Получать поздравление от работа? Нужное реальное человеческое участие.
Почта окончательно станет инфраструктурой, которая научится понимать контекст и помогать в принятии решений.
Не станет. Никогда не станет. Можно было бы организовать дело так, что общение с любым интернет магазином будет осуществляться через почту. В каком смысле? Вот я зашёл и просматриваю товары: в почте появляется "снимок" ситуации, фиксирующий положение дел на момент моего прихода в магазин. Затем, я что-то покупаю, и всё оформление корзины также проводится через почту. А в конце ещё и чек высылается. Причём, всё это делается не так, как делается сейчас, кто как хочет, тот так и присылает информацию о заказе, там, статус заказа, а на регулярной основе, и на основе жёсткого протокола, фиксирующего каждый этап/элемент процесса. Потом можно будет документально подтвердить, что дело было так и так. Но! Так, ведь, не сделано. И никто ни когда не сделает.
Не надо нам Уорхолла.
Вот я и спрашиваю, зачем? В большинстве случаев, можно обойтись без картинок. Лично мне, они больше мешают, чем помогают. Возможно, это так делается, чтобы чисто мнемонически привязать конкретную статью к картинке. Использовать картинку как удобный якорь для памяти. Лично меня такие картинки иногда даже раздражают. Зато там где надо, картинок нет. В этом смысле, более полезным был бы сервис, которому можно было "скармливать" куски читаемого текста и визуализировать то, о чём там говорится. В этом случае. автор текста мог бы выставлять в тексте невидимые подсказки для LLM, которые вместе с указаниями пользователя превращаются в точный промпт.
И что будет теперь, когда есть ИИ?
Да. А то не понятно, к чему контрпример. Значит, что? Нельзя "линии" получить? А что за "линии"? Кусочно-линейные функции или что?
А зачем, вообще, кому-то нужно что-то создавать? Да, отдельные эксперименты могут быть интересны. Как инструмент, реализующий некоторые особые идеи художников, да. Но зачем нужна эта генерация в промышленным масштабах? И не окажется ли потом, что все эти картинки, "нарисованные" ИИ, обладают неким дефектом (пока ещё не вполне осознаваемым), который плохо влияет на мозги. Рискну предположить и такое. Уж, извините.
А Вы можете быть уверены, что не разговариваете сейчас с LLM? :-)
Фильм с какой-то своей атмосферой. Несмотря на некоторую стереотипность образов и совершенную вычурность насквозь фантастического/сказочного сюжета. Но! Всегда приятно, когда зло наказывают. Даже если ради этого надо накрутить всякого сюжетного трэша. Главное, показать побольше всяких загадочных картинок. Особенно "убило" эдакое картинное "хождение по системе". Но фильм забавный. И... все ещё такие молодые!
У нас зачем-то назвали фильм про Кевина Митника "Хакеры 2", хотя он никакого отношения к оригинальным "Хакерам" не имел. Это там где главного героя играл Скит Ульрих. (Разве что, Скит Ульрих играл вместе с Мэтью Лиллардом (вот он сидит на картинке с зубной щёткой) в фильме "Крик". Но это только очень косвенная связь.) Зато фильм оказался удивительно достоверен (не смотря на всю свою художественность) в плане противостояния Митника с Симоммурой.
Подождите! А почему мы не хотим всё это хозяйство как-то автоматизировать? Почему мы не можем несколько тысяч полей пройти в цикле? Откуда, кстати, взялись тысячи полей?
хм... Может быть, лучше было бы написать "в предыдущее" или "в одно из предыдущих"?
А. вообще, было интересно узнать про достижения в области построения файловых систем. Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
Не все пересказы одинаково бесполезны. ;-)
А что именно Вас беспокоит?
Если бы Вас интересовало бы существо дела, то тут было бы оно из двух: либо автор книги (Роберт Мартин?) где-то здорово промахнулся, и чей-то опыт об этом ярко свидетельствует, либо где-то искажена мысль самого автора (при изложении). Наша задача в чём заключается? В том, чтобы лучше программировать.
Я не иронизирую, а говорю совершенно серьёзно. Пытаюсь представить.
Ох, уж, @cupraer разошёлся бы...
В этом смысле, поражают визуальные компоненты. В них собрана куча разнородных функций! Следовало бы разделить. Почему никто так и не разделил?
А ещё есть такой вопрос: а нужен ли здесь обязательно какой-нибудь класс?
Все так советуют делать. Вроде бы, азы ООП. Напоминает одну детскую книжку:
Наверное, в таком стиле (как в приводимом примере) можно многое переписать...
А ещё больше гибкости даёт таблица попарных отношений между классами, когда каждой упорядоченной паре классов соответствует свой способ взаимосвязи.
Чисто или часто? ;-)
Вообще говоря, очень хотелось бы всегда из функции возвращать целый объект, а не какой-то отдельный код. Такой объект фиксировал бы состояние вызываемой функции на момент возврата (удачного или неудачного) и содержал бы как само возвращаемое значение (если оно есть), так и описание ошибки (если она случилась).
Наверное, существуют две школы: школа любителей исключений и школа любителей кодов ошибок.
Верно ли я понимаю, что мне нужно оформить в виде исключения ситуацию, когда, например, у квадратного уравнения не оказывается вещественных корней, а нужны именно вещественные? И какая будет разница между исключениями и кодами ошибок?
А, ведь, можно пойти ещё дальше и, вообще, весь код построить на исключениях! А что? Удобно! Дошёл до конца списка — выкинул исключение. Можно было бы даже из вложенных циклов выходить вместо break и с подробным описанием уровня, с которого выскочили.
Эххх... Вот, во времена засилья C/C++ очень любили всё сравнивать с NULL. Автор книги, наверное, перебрал с C/C++. Впрочем, вопрос интересный. Мне кажется, что "пустой объект" отдельного ото всех типа (как в Python) — это хорошая идея. Думаю, здесь есть, что обсудить.
И что мы должны сделать, если такое исключение выкинется?
Мне кажется, что функция может быть вполне длинной (занимать несколько экранов), но хорошо читаться. Так что, думаю, что это — выстрел "в молоко".
Нужен не просто сертификат а реальное подтверждение квалификации. А для этого надо, чтобы квалификация была. Чтобы любая, даже, самая простая работа, хорошо выполнялась .
Во всех подобных разговорах никак не учитывается, что образование (как и всё в этом мире) держится на людях. Пока были дореволюционные преподаватели и их ученики, а потом послевоенные преподаватели и их ученики, уровень и держался. Советская система образования (как система вообще, и как советская система) так и не смогла ничего воспроизвести. Воспроизводимость требует вложений. И денежных то же. Советская система, действительно, оказалась, во многом бесплатной. Учителя уходили, а на их место было некому приходить. Экспериментальные школы оказались на совершенной периферии. Да, надо было поддерживать приток специалистов в нужные отрасли. С этим система справлялась. Но всеобщего массового образования получится никак не могло. А с другой стороны, реальная потребность в специалистах стала падать после создания атомного оружия и т.п. успехов. Вот чем занималась наука и производство в 70-тых и в 80-тых? Выполняло план? Стагнировало? Какие-там вызовы времени?
Да. К этому надо быть готовым всем участникам процесса. Чтобы как-то сократить неприятности от этого, надо, всего лишь, чтобы все компании обучали собственных сотрудников (а не искали их на стороне) и чтобы компании привлекали бы себе сотрудников интересными задачами. При этом, такое обучение должно идти в довесок к курсам, и, возможно, даже и оплачиваться самим работодателем. Потому как курсы могут дать (и должны давать) только некоторые общие представления о предмете, но никак не гарантию трудоустройства. Хотя, может быть, особо ретивых выпускников специализированных курсов (где целенаправленно учат конкретным технологическим инструментам или долго чему-то учат) и присматривают уже в компании.
Я тоже сейчас прохожу один такой простой курс по Питону. Но это мне нужно именно для фундамента, чтобы уверенно использовать этот язык. Чтобы реальные приложения писать. Не более.
Хотя, да, было бы здорово найти контору, где тебе могли позволить какое-то время поучиться в реальных условиях с наставником, что-называется, за небольшие деньги, но зато, с приобретением какого-то реального опыта, хорошо себя зарекомендовать и, затем, войти уже в нормальный штат. Понимаю, что такая идеальная ситуация практически неосуществима. Особенно, для человека в возрасте. Особенно, в наше время, когда всё в каком-то кризисе, когда все выживают, а не развиваются.
??
А что может быть для сортировки почты ИИ? То, что касается спама. Здесь должна быть возможность установления связи с отправителем: во-первых, Вы должны точно знать, от кого Вы получаете почту, и, если Вы не хотите получать почту от определённого отправителя, то Вы просто отписываетесь. Во-вторых, если бы почта оставалась текстовой (в plain text), то всё было бы гораздо проще и безопаснее. Не было бы ссылок, по которым можно было бы получить вирус или сходить на фишинговый сайт. Нужны новые возможности — разрабатывайте новый протокол поверх старого. Далее, если я работаю с каким-то сайтом, то, в идеале, я должен его "установить" себе в системе, и тогда я буду получать письма только от этого сайта. Почему, вместо того, чтобы предложить людям более развитую инфраструктуру, мы модернизируем почту и допускаем опасное использование?
Какой в этом смысл? Получать поздравление от работа? Нужное реальное человеческое участие.
Не станет. Никогда не станет. Можно было бы организовать дело так, что общение с любым интернет магазином будет осуществляться через почту. В каком смысле? Вот я зашёл и просматриваю товары: в почте появляется "снимок" ситуации, фиксирующий положение дел на момент моего прихода в магазин. Затем, я что-то покупаю, и всё оформление корзины также проводится через почту. А в конце ещё и чек высылается. Причём, всё это делается не так, как делается сейчас, кто как хочет, тот так и присылает информацию о заказе, там, статус заказа, а на регулярной основе, и на основе жёсткого протокола, фиксирующего каждый этап/элемент процесса. Потом можно будет документально подтвердить, что дело было так и так. Но! Так, ведь, не сделано. И никто ни когда не сделает.