Объект или предмет исследования

Пишу статью по научной части и снова работаю с понятиями объекта и предмета исследования, которые всегда путал.

Нет, ну реально, "объект" и "предмет" звучат как одно и то же. Я же вижу на столе "объект", но его же могу назвать "предметом".

Позже, изучая статьи по писательству, я выделил ключевую мысль: важно ограничивать тезисы, которые мы хотим донести до читателя. Не стоит распыляться, иначе читатель увязнет в тексте и ничего не поймет.

Как раз на этом моменте и всплыли те самые "объект" и "предмет". Оказывается, они задают рамки. Это, собственно, видно из определений.

Объект исследования - это широкая область, процесс или явление, которое изучается в работе.

Предмет исследования - это его конкретная, узкая часть, аспект, свойства, которые непосредственно рассматриваются и анализируются.

То есть объект шире предмета, а предмет - это часть объекта исследования.

Например:
- Объект исследования: Разработка приложения заказа еды.
- Предмет исследования: Алгоритм рекомендации блюд на основе истории заказов.

Понятно, что в исследованиях нам всегда хочется рассказать обо всем интересном. Но только встав в определенные рамки, получится донести мысль качественно.

Сохраняйте, кому предстоит защита работы в ВУЗе)

—

А вы как, работали уже с этими понятиями?

👍 - Ага
😁 - Неа
🤔 - Видимо, предстоит

#Словарь

#include <iostream>

int main() {
    uint8_t a = 255;
    uint8_t b = 1;
    uint8_t c = a + b;
    std::cout << int(c);
    return 0;
}

Подсказка для незнакомых с C++:
uint8_t - беззнаковый 8-битный целочисленный тип

Принять или толстый

Да-да. Имейте в виду, если используете автоматический перевод страниц 😁

Не понятно, почему он так переводит. По коду HTML там ничего подозрительного. Видимо, он просто обзывается)

—

Кстати, это была 9 часть рубрики "Путаница в интерфейсах".
Читать еще:
- Когда фильтры - так себе фильтры
- Переключатель в Яндекс Книгах

#include <iostream>

int main() {
    int8_t a = 127;
    int8_t b = 1;
    int8_t c = a + b;
    std::cout << int(c);
    return 0;
}

Подсказка: можно сравнить с предыдущим тестом и сделать вывод 👆

Какие файлы нельзя коммитить в Git

В новой статье рассмотрим 3 главных последствия бесконтрольной загрузки проектов на GitHub:

- Неадекватный рост размера репозитория
- Конфликты совместной разработки
- Разглашение секретов

Эта проблема свойственна начинающим разработчикам и проявляется часто. С опытом это проходит, но зачем ждать)

👉 Читать статью

А вы говорите школьная программа не пригодится...

Вот, пожалуйста, на курсе по реверсу следующая домашка - сложение в столбик.

Пригодилась!

Какие ещё нужны доказательства? 😁

Помню, Стив Макконнелл писал, что максимальное комфортное количество аргументов функции равно 7. Ну, плюс-минус 2. Если их будет больше, то работать с функцией станет совсем сложно.

Вообще мнения колеблются от 3 до 7 аргументов. Но мысль одна: много аргументов - плохо.

Тем не менее 👇

2 минуты осталось или 2 минуты прошло?

Рубрика "Путаница в интерфейсах". Часть 10.

На картинке - виджет фокусировки в Windows. Это стандартное приложение, которое отключает все уведомления на заданное время, помогая сфокусироваться на работе.

Сейчас циферблат виджета показывает 2 минуты. Как вы понимаете эти 2 минуты? Как "2 минуты осталось" или как "2 минуты прошло"?

Я был абсолютно уверен, что 2 минуты прошло и еще 8 осталось.

Но не было бы этой рубрики. На самом деле все наоборот)

С какой-то стати обратный отсчет времени на циферблате начинается с положения 3-х часов. Не с 12-ти, как я подумал изначально.

Я понятия не имею, почему так сделано.

Создается ощущение, что внутри это просто обратный отсчет по тригонометрической окружности от 2π до 0. Кто-то поленился сделать сдвиг на π/2 и поднять начало отсчета наверх? Или тут есть неведомый мне смысл?
Если кто-то знает, напишите)

—

А вы запутались или я один такой?

👍 - Запутался
😁 - Один такой

Doc As Code: диаграммы PlantUML в Doxygen

ИИ заставляет по-другому смотреть на разработку. Привычные подходы оказываются так себе.

В этом плане ведение документации зацепило знатно. Документация оказалась нужна как никогда) Причем не детальная, а, наоборот, - высокоуровневая. Детали ИИ и сам неплохо соображает по коду. Но вот концепт, архитектуру, идею ему выделить сложно.

И все бы хорошо, документации у нас есть немножко) Но вот схемы и диаграммы... Они в картинках. В целом ИИ умеет в картинки, но делает это плохо и не точно.

Как раз в этот момент я вспомнил про текстовые нотации диаграмм, про PlantUML в частности. Точнее я их и не забывал, но пользовался редко. А тут оказалось, что ИИ отлично понимает, генерирует и редактирует такие диаграммы.

Получив какой-то опыт на нескольких задачах, я доработал свои соображения по принципу Doc As Code для C++ проектов. Если раньше там использовался только Doxygen и Markdown, то теперь добавляется PlantUML. Код, документация и диаграммы полностью состоят из текста и в полном объеме обрабатываются ИИ.

👉 Смотрите в новой статье, что получилось, и пишите, что думаете по этому поводу. Ощущаете необходимость в хорошей документации или с ИИ можно работать и без нее?

—

Читать еще:
- Прошлая статья по Doc As Code для C++
- Зачем нужны UML диаграммы?

Снова и снова сводит олдскулы на курсе по обратной разработке)

ASM, DOS, BIOS, MBR...

Когда-то давно все это было на слуху. Примерно тогда, когда "переустановить винду" было чем-то само собой разумеющимся. Постоянно что-то слетало, что-то не работало... Приходилось ковыряться.

А сейчас все как-то надежнее что ли стало. Пару лет назад я менял ноутбук просто потому, что он устарел) Но за все время его использования я ни разу не менял ОС. Может, просто повезло. Может, лень возиться. Не знаю...

Но к чему это я. А вы помните, что такое MBR? 😁👇

Мементо

Недавно посмотрел "Мементо" Нолана.

Честное слово, главный герой - ходячая нейросеть. Он помнит все, что было до болезни, но не может вспомнить события нескольких минут назад. Как у нейросети: предобученная база и ограниченный оперативный контекст)

Чтобы хоть как-то удержать ниточку событий, герой носится со своими фотокарточками и заметками, как Клод с Claude.md. Получается у него или нет - судить зрителю. Я свое мнение придержу.

Фильм смотрится сложно. Мне проще переваривать что-то линейное типа "Колобка": сбежал из дома, пообщался с местными, пал жертвой афериста. Все просто.

А тут... Не просто.
Но вывод есть: хорошо, что нейросеть - это машина без ручек и ножек 😅

—

В следующем материале поговорим как раз про ведение заметок и почему ИИ здесь выступает триггером.

Кто там голосовал, что не сохраняет ссылки и не ведет базу знаний, а?

Вот, пожалуйста:

Использование инструментов ИИ неизбежно... особенно если вы молодой человек, стремящийся получить преимущество на все более сложном рынке труда. Но когнитивная разгрузка опасна в любом возрасте. Накопление базы знаний может спасти ваш мозг и навыки от атрофии.

Поясню.

Когнитивная разгрузка возникает, когда мы полностью полагаемся на ИИ. Знание, которое ИИ использовал для решения задачи, для нас теряется. Долгосрочно тут ничего хорошего. Если, конечно, мы не выделим это знание и не зафиксируем его.

Так рождается база знаний. Это могут быть не только личные заметки, но и любые другие виды документации, вроде корпоративных вики. База знаний - это то место, где мы делимся знанием как с самим собой в будущем, так и со всеми остальными, кто имеет к ней доступ.

Ведение базы знаний помогает частично решить проблемы с:

- Запоминанием. Изложение материала своими словами способствует усвоению. Да-да, простое "копировать-вставить" не сработает. Хотя это лучше, чем ничего.

- Удержанием знаний. Хорошо, когда есть, куда заглянуть. Поиск по ключевым словам лучше работает с заметками, чем с головой. Особенно если в голове ничего и не было.

- Подготовкой новых специалистов. Хоть это и не очевидно, но... Если у всех будут проблемы с удержанием знаний, то кто будет обучать следующее поколение инженеров? Чат-боты? Похоже, что да. Но на что это будет похоже, я не знаю.

На самом деле, все это работало и до распространения ИИ. Просто было не так актуально. Тот же поисковик далеко не всегда давал ответ на вопрос - надо было покопаться, почитать, разобраться. Хочешь - не хочешь, а запомнишь.

Теперь все по-другому. Знание не просто доступно, знание - не нужно. На любой вопрос есть ответ. Остается его просто принять. Поэтому 👇

Делайте заметки, конспектируйте, систематизируйте. Со временем это войдёт в привычку. Со временем база знаний начнёт работать на вас. А когнитивная разгрузка из-за использования ИИ потеряет свое разрушающее действие.

—

Выше я упомянул, что эффект от когнитивной разгрузки будет заметен в долгосрочной перспективе. В следующий раз поговорим о том, почему важно и нужно смотреть в долгосрок.

Последнее время я набрал столько обязательств, что физически не успеваю выгребать. Часть проектов поставил на паузу, от части вообще отказался.

Понимаете ли, мне давно не 23, и просто сказать "выгорел" я не могу. Выгорает тот, кто не знает, что делать. А я знаю: выкидываем все необязательное и давим на обязательное, чтобы поскорее вернуть обратно необязательное 😁

Блог - уже тоже обязательство и на паузу не встанет. Да, пока "хардовых" материалов и викторин будет поменьше (их сложно писать), а "софтовых" и общенаправленных - побольше. Здесь есть, что сказать, и когда, если не сейчас.

Работать долго

Чтобы повысить свои шансы добиться хоть чего-нибудь, надо работать долго.

Что это значит?

Ну, например, готовы ли вы держать пари на $1 000 000, поставив на решку в подбрасывании монеты? Нет? А если я скажу, что у вас есть не одна, а 100 попыток ее подбросить? Заманчиво? Мы понимаем, что с таким количеством попыток резко возрастает вероятность выигрыша.

В любом другом деле все то же самое. Чем больше мы пробуем, тем выше наши шансы на успех. Только мы не можем их измерить.

В книге "Одураченные случайностью" Талеб пишет:

Конечно, в игре с ясно и недвусмысленно определенными правилами шансы можно вычислить, а риски измерить. Но не в реальном мире. Ведь мать-природа не подарила нам четкие правила. Эта игра не колода карт (мы даже не знаем, сколько в ней мастей).

Там же приводится пример с ученым, день за днем разделывающим мышей в своей лаборатории. Ничего стоящего и прорывного у него не выходит. Некоторые, в том числе и собственная жена, считают ученого неудачником. НО: с каждым днем вероятностно он оказывается все ближе и ближе к конечному результату.

При этом мало просто долго работать. Наша работа должна быть долгосрочно устойчивой и качественной.
Талеб пишет:

То же касается издателей: они могут выпускать одну книгу за другой, и к их бизнес-модели не будет никаких вопросов, если однажды раз в десять лет они не взорвутся серией супербестселлеров масштаба Гарри Поттера - конечно, при условии, что они делают работу качественно, а у их книг есть вероятность стать бестселлерами.

Так и в нашей работе. Неплохо бы быть готовым воспользоваться "вкусными" возможностями в любой момент.

Q: Как быть готовым?
A: Работать долго, устойчиво и качественно.

Q: Как работать качественно?
A: Постоянно учиться.

Q: Как постоянно учиться?
A: Сомневаться в собственной исключительности, искать и признавать свои некомпетенции.

Вот такой просто рецепт.

Инвестируйте в себя и работайте долго.

#КнижнаяПолка
📍 Нассим Николас Талеб - "Одураченные случайностью" (2001)

—

Позже расскажу об одном из неочевидных моментов в профессии программиста - предсказуемости.