План учебника

[vitus_wagner]

Совместными усилиями с snowman_sailor и ramendik написали план учебника по введению в программную инженерию. Вместо двух частей получилось три.

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

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

Comments

[schegloff.livejournal.com]

Это не введение, а пятилетний курс для будущих генеральных конструкторов мега-приложений :)

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

[vitus_wagner]

У нас в свое время учебник для курса введение в специальность "Общее землеведение" был вполне нормальной толщины томиком. Страниц на 400, по-моему даже формата А4.

И в первом семестре было 10 теоретичеких курсов с учебниками сравнимой тошщины. Ну ладно, 8 если выкинуть высшую математику и историю КПСС.

[snowman-sailor.livejournal.com]

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

[darkmoor.livejournal.com]

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

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

Честно говоря, мне хотелось об этом сказать сразу, как только увидел оный план. Но вот как раз потому, что учебник называется "Введение...", а не "Конструирование больших программных систем", заставил себя заткнуться.

[wizzard]

Что пришло в голову и чего я часто видел что люди не знают:

1) введение про время, причинность и теорию относительности (что бывают события, про которые нельзя сказать, кто был первым, что сообщения распространяются не мгновенно, и т.д.); - кстати, обьяснять VCS и БД будет проще

2) введение в моделирование данных и онтологию (почему нельзя всему присвоить id, почему вредно считать что чего-то бывает только 1 штука, что такое вообще identity - сравнение по ссылке, по значению, почему нельзя составить Исчерпывающий Список Всего, что делать если мы Машину-5 разобрали на Запчасть-7 и Запчасть-8, а потом собрали из них Машину-10 и Машину-11 и т.д.)
Особенно это в форматах данных важно (версионирование, то-се. СУБД часть вопросов худо-бедно закрывают)

UPD: отличие между неизвестными, ошибочными, неполными и неточными данными еще

3) про оценку производительности (как мерять, как интерпретировать результаты, как искать бутылочные горлышки)

4) как собирать с юзеров фидбек, как отличать фантазии юзеров от наблюдений юзеров (известный анекдот "голова болеть начала? а вот когда мы эту сотовую вышку еще и включим..."), и вообще инженерия требований, хоть она и достойна отдельной книги...

5) как правильно обрабатывать ошибки, хмммм, тут нет серебряной пули но я где-то видел хороший сравнительный обзор, только ссылку потерял

Список ни в коем случае не полон, просто не включая мозг написал

[vitus_wagner]

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

Это что-то вроде онтологической базы системной инженерии. Чему пытается учить ailev. С онтологиями и моделированием оно естетсвенно связанао. А у нас тут приземленная практика.

Ну то есть если вы сумеете впихнуть это в 3-5 страниц. это можно включить во введение. Но боюсь, что тут понадобится более объемное изложение.

Про оценку производительности спряталось под заголовками "нагрузочное тестирование и профайлинг".

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

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

[eldhenn]

> введение про время, причинность и теорию относительности

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

[filonov.livejournal.com]

Как-то не вырисовывается концептуальной целостности. Скорее пока какая-то каша, собранная по принципу "а еще я вот про это знаю".
В первой части - каши больше. в третьей - меньше.

Дабы не быть голословным:
- разделы "межпрограмное взаимодействи", "Расширяемые программы", "использование внешних программ", IMHO нуждаются в сведении в
два раздела

[wizzard]

Мне кажется, тут не может быть концептуальной целостности, но можно сделать постепенное углубление.

[ynot.livejournal.com]

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

к процессу подготовки первокурсников в рамках массового очного первого образования 17-леток отношения не имеет. (простите ради аллаха, вы давно первокурсников "среднего хорошего вуза" вживую видели?)

P.S. (читать "введение в специальность" в течение ДВУХ СЕМЕСТРОВ раз в неделю, как здесь предлагалось - это безумие. Введение должно быть достаточно интенсивным, а не подпороговым, чтобы скорость запоминания хоть немного превышала скорость выветривания)

P.P.S - основной вопрос - пожалуйста, сообщите предпололжительное кол-во учебных часов для этого курса?

[wizzard]

Да, мне тоже кажется, что это интенсивка.

[alll]

Имхо не хватает раздела про деньги. :) Ну то-есть что-то типа "зачем мы пишем код с точки зрения работодателя и как это влияет на принимаемые решения вплоть до закрытия проекта".

[vitus_wagner]

Деньги - сильно частный случай ответа на вопрос "зачем".

[enternet.livejournal.com]

Я пробовал написать книгу про разработку GUI. Написал одну главу и закончил этим заниматься ввиду бессмысленности. Трудозатраты с современной точки зрения я бы оценил месяцев в пять-шесть. Как главу для книги - думаю, нереально. Потому что краткий объем можно свести к фразе "думай, смотри по сторонам и сам пользуйся своим интерфейсом". А при увеличении объема начинается совершенно сумасшедший поток мелочей, сбивающий начинающего с общей картины.

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

Раскина я бы не рекомендовал. Точнее - воздержался бы от любых рекомендаций кроме штатных руководств от разработчиков ОС.

В общем, задумка благородная, но с реализацией ясности нет никакой.

[vitus_wagner]

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

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

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

[lyuden.livejournal.com]

Ну я могу присоединится.

Python, AWS, Django, scrapping, REST API, Jenkins, Gerrit, Ubunty, d3.js, numpy немного работа с кластерами и анализ данных

Ну и опыт преподавания какой-никакой но есть.

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

[vitus_wagner]

Ну я в общем, тоже подумываю, что пора уже с гугль-дока слезать.

[nponeccop.livejournal.com]

Вынесу из комментов. Ха-ха, про вим и софт для внутреннего пользования я таки угадал.

http://wizzard0.livejournal.com/493257.html?thread=5316809

Я имею ввиду, в том числе, условно, что 90% софта - для внутреннего пользования, 9% развлечения, и 1% критического софта, на котором зиждется цивилизация :)

[snowman-sailor.livejournal.com]

Не ясно зачем нужно описывать структуру отрасли и как это описание помешает превращению в УГ?

[zaharchenko]

>Особые случаи GUI - игры, мобильные приложения

В современно мире возможно не совсем корректно называть мобильные приложения особым случаем, он уже несколько лет такой же равноправный как и CUA

[vitus_wagner]

Это интересный вопрос. Есть аргументы за, и есть аргументы против. Подумаем.

[d1f.livejournal.com]

Не нашёл в плане кросс-компиляции.
embedded - это о другом.

[vitus_wagner]

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

По моему,и идея что можно генерировать код не для текущего процессора настолько очевидна, что большого внимания не заслуживает

Вот в главе про деплоймент и дистрибуцию, есть пара мест где можно остановиться на особенностях крос-сборки. Это там, где автоматические системы конфигурмрования, и там где сборка в пакеты. Потому что часто встречаается такая система сборки, которая требует исполнения чего-то свежесобранного. Причем для target-архитектуры, причем по делу.

[jora0.livejournal.com]

Возможно, такое предложение уже было --- но не хотите попробовать денег на это дело на краудфандинге собрать?

[vitus_wagner]

Лично я категорически против. Взятки берем только борзыми щенками. В смысле идеями, кусками текста, рецензиями.

Конкурентное программирование

[8df887a0-b2d1-4ca4-8758-9799a5a7bad1 [openid.stackexchange.com] (from livejournal.com)]

Думаю, в разделе про параллельное программирование незаслуженно забыто конкурентное программирование, основанное на CSP (http://en.wikipedia.org/wiki/Communicating_sequential_processes), которое значительно удобнее спагетти-кода, который получается при подходе, основанном на событиях.

Современные ЯП, реализующие эту парадигму, это Erlang и Go (а также фреймворк Akka для Scala).

Для понимания отличий параллельного программирования от конкурентного, можно посмотреть вот это: http://blog.golang.org/concurrency-is-not-parallelism

Ну и http://state-threads.sourceforge.net/docs/st.html также хорошо объясняет подход.

Re: Конкурентное программирование

[snowman-sailor.livejournal.com]

Действительно забыли.

Не знаю как Erlang и Go, а в Scala + Akka спагетти получается не намного меньше чем в классической модели на коллбеках, при этом код с использованием Akka получается довольно паскудным из-за того что нигде не фиксируется контракт взаимодействия между акторами. Вдобавок обработка ошибок возможна только бинарная: либо все ОК, либо не ОК и тогда все умирают. Все что выходит за рамки ОК/фейл приходится делать ручками усложняя и без того сложную систему сообщений.

[gineer.livejournal.com]

Два предложения:

привелечь пользователя ailev на тему структуризации указаного многообразия

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

Бумажный (даже электронный) талмуд,
все равно никто читать не будет,
даже если он будет сделан (что весьма сомнительно)

You need a main logical thread

[sceptic-008.livejournal.com]

This is a huge mess, a mosaic, a heap of things the authors could remember.

A good plan for a book of this kind should include - and it's the requirement number ONE - some INTERNAL LOGICAL THREAD, which is easy to follow, which makes sense, and so makes it possible to teach varied material as something coherent.

FOR EXAMPLE, a possible main logical thread might be created like this.

Programs live on a computer like animals in a forest, and the "forest" is the environment the computer forms for them. The computer itself is a dead hardware box, and it is something called OS that connects hard drives, memory, periphery into a meaningful whole.

But how can a human user interact with it? - the earlier generations of computer engineers
and OS designers standardized on something called "a shell".

Then you continue with the UNIX PHILOSOPHY, i.e. the principle that programs (runnable from command line or shell scripts) are written in such a way that

(a) they do one thing well rather than many things (all things one can think of ) in one fat executable. Examples: compression programs must know how to compress, but not archive, for that we have "archive programs", etc.

(b) but many specialized programs can be connected into processing CHAINS to combine them and achieve complex tasks
This is done thanks to special features of SHELL (piping, STDIN/STDOUT, ....)

THIS APPROACH was found to be very powerful, and it survives to this very day in PROFESSIONAL applications of computers: shells/REPL/... are built into many programs which at a later stage acquired GUIs

One of the major disadvantages of the Command Line interface to computers is that one has to KNOW before one can use the "commands"

Later people devised the GUI approach. It substitutes this need to know up front with an ability to explore menus -- but is infinitely more restrictive. Therefore to this very day GUI-based attempts at professional application (e.g. GUI-based plotting or math crunching (MathCAD)) are weaker tools than those based on CL (Mathlab).

Most of development follows the CL paradigm and this is the first environment a software engineer needs to learn

But because in today's world we use GUI/window-based environments in which many inidvidual windows (running CL or GUI apps) are living, we will use GUI tools as well.
As a rule, knowing a CL version of development tools makes one immediately understand the (simplified) GUI front-ends to them, but the reverse does not work, a GUI-literate developer will feel helpless when having to switch to CL environment

(2)
NEXT you follow a logical sequence for introducing
-- scripting
-- compilation
-- languages with REPL
-- debugging
-- version control
-- testing

The windowing environments and GUI progs are introduced as TARGETS for the students' future development efforts.

You may show the GUI world mostly as a convenience for the less computer literate and almost totally computer illiterate (from the engineering point of view) end users, who only know how to work in end user programs, and are almost disfunctional as far as the computer itself, as a system is concerned (the "forest" in which animals-progs live).

So this is a natural progression following the needs of the developer rather than an attempt to list all unrelated bits one's memory retained, without rhyme or reason.

You need a certain NARRATIVE to tell, not a mosaic of brightly coloured pieces of various shapes and sizes to dazzle - and leave helpless.

Re: You need a main logical thread

[snowman-sailor.livejournal.com]

Вообще-то такая идея у там есть:

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

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

Также я категорически против исторического подхода к изложению. Это вносит в голову студента путаницу и невозможность ответить на вопрос: а что из этого актуально прямо сейчас. Примерно как если начинать курс "Компьютерные сети" с рассказа о модели OSI. В результате студент искренне уверен что OSI это физически существующая величина, или, в лучшем случае стандарт, а вовсе не искусственная абстракция.

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

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

or, more succintly

[sceptic-008.livejournal.com]

Or - if I could put it more succintly:

the course should follow the HISTORIC outline of computing as it developed,
and at the same time look at this historical progression through the eyes of a developer.

Then:
OS, CL, languages (compiled, LISP-like, scripting),
programming paradigms (a series of instructions; objects living in an object universe; complex "matroyshkaed" sentenses, calculating the ultimate program as a sort of function, etc.)
development tools, development procedures (version control, editors, testing, etc.)

networking, distributed computing paradigms (e.g. client-server; parallel, erlang as an expression of one successful paradigm etc.)

Internet and Web-based computing and tools

AND LATER - specific areas to make students aware of the ideas of security, of commercial distortions of the purely engineering approach to computing etc.

---------
I.e. being historic, putting Unix (=professional and industrial rather than aimed at an uneducated user) development in front of the Windows and MacOS platforms, and progressing along the real history of computing, but looking at it from a developer's perspective.

Then not only a strong narrative emerges, but the course will double as a short history of computers, as it needs to be told to young professionals.

Should be much more interesting than the proposed "bag of (poorly related) things"

[shaplov.livejournal.com]

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

[yurikhan]

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

Компьютерная гигиена. Не запускать какие попало программы. Не работать под админским аккаунтом. Не вставлять в свой компьютер незнакомые USB-устройства и не допускать своим бездействием, чтоб в ваш компьютер было вставлено незнакомое USB-устройство. Если незнакомый сайт говорит вам «АХТУНГ! У вас тут вирусы, немедленно скачайте и запустите вот это» — вы знаете, что делать.

Как распространяется malware. Почему открытие документа в ассоциированном с ним приложении или открытие сайта по ссылке в самой свежей версии браузера даёт сильно меньшую, но ненулевую, вероятность заразиться по сравнению с прямым запуском недоверенного исполняемого файла. Песочницы, Noscript, Flashblock, фаерволы.

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

Отдельным пунктом: котики и пляшущие кролики не являются достаточной причиной для игнорирования правил гигиены.

Но вообще это глава не из этого курса. Это должны знать все пользователи, а не только те, кто собирается избрать IT своей специальностью.

[morfizm.livejournal.com]

Рекомендую: ни в коем случае не называйте это учебником. Назовите это "беседы про программирование" и оформляйте главы в виде самостоятельных статей. Это заодно позволит вам тупо выкинуть те главы, где вы считаете, что у вас троих не хватает квалификации.

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

[snowman-sailor.livejournal.com]

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

ТОП: 11:00 (московское)

[magict30p.livejournal.com]

Вы попали в Т30P (http://www.t30p.ru) самых обсуждаемых тем в блогосфере.
Это Ваш 1-й ТОПовый пост в этом году.
Посмотреть статистику автора можно в карточке топблогера (http://rating.t30p.ru/?vitus_wagner.livejournal.com&p=tops).

[Шура Люберецкий (from livejournal.com)]

Где-то между "Управлением задачами" и "Документированием" можно было бы вставить упоминание ГОСТов 19 и 34 - а то иногда встечаются такие дикие представления о них, что хоть стой, хоть падай.

Не нашел эти темы в плане

[1a1.livejournal.com]

Замечательный план, уже хочу такой учебник)

Вопрос, точнее два:
1. Не вижу UML - почему? что читатель уже знает основы и этого достаточно или UML-диаграммам не место в этом курсе?
2. Что с шаблонами/паттернами проектирования - слишком сложны для введения в специальность?

Re: Не нашел эти темы в плане

[vitus_wagner]

1. Потому что нахрен никому не нужный баззворд.
2. Пол Грэм считает, что шаблоны/паттерны имеют смысл только для слишком низкоуровневых языков вроде Java. На нормальных языках любой паттерн должен быть оформлен как макрос или библиотечная функция.