LINUX.ORG.RU

книга об опыте разбираться в новых технологиях в целом - есть такая?


0

2

Всем привет. Задам странный вопрос.

Было бы очень прикольно, если бы была книга, в которой систематизируются подходы мышления при разбирательстве в новых технологиях и решении linux-проблем. Я заметил, что, когда разбираешься в разных фреймворках, программах и пр., и когда решаешь linux-проблемы - есть что-то общее в мышлении, какое-то... «мышление линуксоида», что ли. Независимо от того, какая конкретно это технология/язык/ОС и пр.

В общем книга вроде «как мы мыслим и какие решения принимаем, когда патчим KDE2 под FreeBSD». Т.е. не о том, как пропатчить KDE2 под FreeBSD, а именно систематизация опыта разбирательства в технологиях в целом, ну естественно, с примерами.

Есть ли такая книга? Если нет, может быть написать её усилиями сообщества? Думаю, сегодня такая книга была бы очень актуальна.

А ещё неплохо было бы таблетку, чтобы съел и всё понял..

alpha ★★★★★
()

Этому учат в техническом ВУЗе 5 лет. Именно логическому мышлению и принятию наиболее оптимального решения.

Allakka ★★★★
()

Да, это правда, есть определенные подходы. Пока что они разрознены. Из того, что помню:
1. Сначала заставь работать, а потом оптимизируй. Контр-пример: попытка сделать 100500 настроек, а потом муки с выявлением что же пошло не так.
1.1. Сначала сделай главное, а потом второстепенное. Контр-пример: типичная проблема начинающих программеров, который пишут help к программе до того, как как программа еще что-либо еще делает.
1.2. Всегда выполняй минимум действий для достижения результата. В тайм-менеджменте - «не кипяти океан». Контр-пример: попытка понять все опции ядра, когда нужно просто заставить работать звуковую плату.
1.3. При выявлении бага, суживай возможные факторы до минимума. Поменял что-то одно - проверил, второе - проверил и т. п. пока не выявишь критический фактор.
2. Всегда пытайся понять что пытается тебе сказать система; это включает сообщения и логи. Контр-пример: «Выскочило какое-то окошко, я нажал ок.».
3. Выполняй только то действие, для которого ты примерно понимаешь ожидаемый результат, и алгоритм которого ты понимаешь или о котором догадываешься. Это же предполагает что ты изучаешь как работает компьютер. Контр-пример: знаменитый однострочник.
4. Не выполняй необратимых действий; если нету undo - делай бекапы и удаляй их только после того как убедился что все работает. Это же предполагает что ты знаешь как откатить изменения.

Плюс: структурное мышление, навык создания алгоритмов, желание учиться и развиваться, желание создавать, способность точно описать ситуацию и сформировать результат. здравый кусок лени (мотивация к тому, чтобы идти по кратчайшему пути) и стремление к комфорту (желание автоматизировать).

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 2)

Да, а если про то как учиться - книга «Accelerated Learning Techniques» Брайана Трейси (извини, не знаю как по-русски, читал в оригинале). Только учиться - это как плавать: читать можешь сколько угодно, но пока не зайдешь в бассейн...

Kroz ★★★★★
()

Да, это правда, есть определенные подходы. Пока что они разрознены. Из того, что помню:

Да, хорошо написано.

1.2. Всегда выполняй минимум действий для достижения результата. В тайм-менеджменте - «не кипяти океан». Контр-пример: попытка понять все опции ядра, когда нужно просто заставить работать звуковую плату.

Согласен, иногда бывает так, что когда разбираешься в чём-то, начинаешь по инерции лезть всё глубже и глубже, а потом оказывается, что сам не заметил, как потратил силы и время не туда куда нужно. Конечно, опыт полезный - понял, как оно в глубине устроено, но целевую задачу за отведённое время не решил. Т.е. важно держать в голове какую-то границу, в чём стоит разбираться сразу, а чем - только после отдельно принятого решения.

Интернет полон статьями о том, как решить конкретную задачу - как настроить grub, как собрать вот ту библиотеку под другую платформу и т.д.

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

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

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

И вот как раз было бы хорошо, если бы был такой сборник решений проблем «изнутри», основанный на коллективном опыте.

Rammfag
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.