Ну, например, в Политеховской группе (СПб) адекватные вопросы и ответы. Можно кинуть вопрос и спросить, как учатся. И все ответы в личку. Понятно, что никто не будет светится прямо. А в личку скажут без стеснения кто, что и почему.
Насчет: по чему готовится - есть вопросы к вступительному экзамену в магистратуру. На каждом направлении/ВУЗе они свои. Так что эти вопросы лучше там решать. Более того, на кафедре можно получить эти вопросы и в течении года.
"На Тостере тусуются люди", которые работают в ИТ. В этом большая разница. Большинство из них закончило ВУЗы несколько лет назад. А некоторые - вообще дохрена сколько времени назад. Сейчас образование очень быстро меняется. Здесь можно получить общую информацию: например, "цель - такая то, какая должна быть стратегия". А вот куда поступать - это уже сам поступающий должен решать. Большое количество информации, которая неизвестна и/или недоступна участникам здесь, напрямую получается гораздо быстрее и, самое главное, эффективнее.
alexe0110 А почему вы с этим вопросом идете на Тостер, а не в группы Подслушано <ВУЗ>. Там и задавайте вопросы. Нынешние студенты или недавние выпускники вам столько всего расскажут, что будете принимать решение. На Тостере же в основном, теоретические вещи (в т.ч. у меня) - они не показывают реальную картинку в конкретном ВУЗе/направлении
DS28 Да, делается. Но это растягивается на 4-6 месяцев и с неизвестным результатом.
Я НЕ увидел, что магистратура человеку не нужна. М.б. он хочет получить _теоретические_ знания, которых не было на УТС. В отличие, например, от программной инженерии или прикладной математики.
Тут вопроса два и, действительно, стратегия зависит от цели. Дело в том, что СЕЙЧАС он может поступить на другое направление. Но это не означает, что через 2 года, после работы и когда он созреет (по вашему варианту), Минобр не отменит правило поступления в магистратуру на любое направление. И ему придется довольствоваться магистратурой только по УТС. В магистратуре (нормальной (!)) учат искать решения задач нетривиальным образом. Т.е. не натаскивают, как в проф. деятельности, а именно учат. Т.е. там учат подходу, который использует, например, Senior или Архитектор при выработке решения по выбору стека. С обоснованием этого. А обоснование - важно для бизнеса. И ради этого туда стоит идти. Обычный бакалавр научится этому только посл 4-5 лет в индустрии (а до этого будет тупо кодить). Ради просто корочек, конечно, нет.
DS28 Думаю, что вы немного не владеете ситуацией. Правильный ВУЗ и правильное направление в данном контексте - это наличие оных в базе Anabin (Informationssystem zur Anerkennung ausländischer Bildungsabschlüsse). Подобные штуки есть и в других странах, называются по другому.
P.S. Магистратура не отменяет параллельную работу! Более того, она не только желательна, но и настоятельно рекомендуется.
Полагаю, что вам лучше рассмотреть классику - СПбПУ, ИТМО и т.п. Дело в том, что практике разработки вы научитесь из практической работы (прошу прощения за некоторую тавтологию). ВУЗ вам нужен (если нужен) только с точки зрения матчасти (т.е. основ: алгоритмов и т.п.). И здесь лучше не жадничать.
М.б. сначала попробовать устроиться джуниором? И потом уже из практики работы искать ВУЗ - т.е. вы увидете на практике, что такое ИТ, и что такое разработка. И уже потом будете выбирать ВУЗ, исходя из требований - то, чего не хватает в работе.
Как войти в эту сферу - еще советы поищите здесь на форуме.
Попробуйте сделать за пробный файл за 15 минут с помощью reuse content. Сравните подобное с традиционными решениями. Сколько времени у вас займет все это? Только в этом вопрос (ну, и, как следствие, в деньгах).
2. Описывать в Word части диаграммы Visio, чтобы данные этой диаграммы и/или изображение менялось "само".
Кстати, второй пункт мне не совсем понятен.
Не все так сложно, как кажется. Я часто наблюдаю ситуацию, немного подобно вашей. При использовании традиционных технологий деньги на поддержку документации улетают в трубу (по чуть-чуть, поэтому незаметно). Но в итоге получается много.
Здесь вопрос не в том, насколько сложны эти технологии в общем, а насколько они применимы к вашим требованиям (в смысле трудозатраты - отдача). Я не исключаю, что трудозатраты на применение технологий под ваши требования окажется меньше, нежели текущий затраты на поддержание.
Так что все только пробовать, смотреть и оценивать.
1. Основная мысль была в посте автора была следующая: "ГОСТ требует одно, а используется другое. Как быть?"
2. Я привел вам примеры несоответствий не только в шрифтах - все гораздо шире. Т.е. даже те стандарты, которые существуют, совершенно не используются в деятельности госструктур.
3. И я говорю про _использование_ стандарта в _работе_ любых структур, а не только создание документов _разработчиками_ ПО. Например, нормативные документы на сайте Минсвязи идут в т.ч. в docx, а не как говорит ГОСТ Р ИСО/МЭК 26300-2010 в ODT. Об этом и была подтверждающая статья на хабре.
4. Государственные - остались. ФГУП НТЦ Атлас, ФГБУ «ЦЭКИ» и т.д.
Странно, но под ваш функционал подходит простейший single sourcing (я говорю про DocBook, т.к. на нем специализируюсь).
Т.е. как мне это видится:
1. Один article c требованиями ("простыня").
2. Под каждый section c требованиями поставлены атрибуты (pro, nonpro, common).
3. Пункты меня оформлены отдельным справочником и с требований идет вставка (xinclude) конкретного пункта меню.
Можно будет:
1. Автоматически (через xslt) собирать матрицу функционал - пункты меню.
2. Хранить версионность.
3. Если в какой-нибудь ветке исчезнет пункт меню - это сразу же будет видно в функционале (т.к. linked, а не embedded|copy paste).
4. На выходе вы сможете получить документ, который соответствует конкретной роли (один исходник - несколько выходных документов из него по одной команде).
А странно, т.к. редко когда сложные решения подходят для простых задач. У вас, судя по всему, именно этот случай.
ky0 я не об этом... Я о том, что на рабочих станциях рекомендуется выделять на отдельные разделы var и tmp именно потому, чтобы какое-нибудь приложение пользователя не заполнило весь диск и не положило систему. Да, существуют 5% рута (по умолчанию).
Квоты на /var и /tmp? Многие приложения запускаются от рута в фоне. Вы будете делать квоту руту?
Зачем городить огород, когда можно просто вынести в отдельный раздел. Речь же о рабочих станциях.
@vadi7
По поводу SSTD следует уточнить несколько моментов. Реализация оного бывает в двух видах: стандартах, основанных на xml (организация oasis) и самописные проприетарные решения (типа Help&Manual, MadCap Flare и т.п.).
1. XML стандарты (DocBook, DITA) - большие, изучать достаточно много, НО при этом гибкие, открытые и именно _стандарты_. Ориентированы на Enterprise-class documentation. Возможностей там очень много. По этим вопросам вам сюда: forum.singlesourcing.ru
2. Самописные решения, как правило, win GUI (Help&Manual, MadCap Flare), которые реализовывают _похожие_ функции, но с упором на GUI. Кроме того, там часто отсутствуют спецификации. Сложно все запихать в систему контроля версий и т.п. (хотя, многие и используют xml в качестве источника данных). Но их плюс - что научится любой, кто хоть как-то работает с Виндой.
Полагаю, что вам на _текущем_ этапе вашей деятельности вполне подойдет именно п.2 при условиях:
- Вы не будете расширять линейку продуктов.
- Вам не нужен автоматический транслейт и т.п.
Т.е. если вы не будете развиваться вширь и вглубь.
P.S. И никогда не пренебрегайте ролью Readme.txt :)
1. Т.е. это производственники. Есть вероятность, что им нужна "бумажка" - т.е. будет "чтение с листа" в распечатанном виде. Я не просто так спросил - разное ПО требует документацию разного вида (структуры и представления, кстати, это разные вещи).
2. Немного не о том спрашивал. Имеется в виду - виндовое приложение, или кросс-платформенное , например, на GTK, или веб-приложение, или серверное. По ответу на п.1 становится понятно, что это GUI, правда непонятно, какого вида.
3. Я немного не о том говорил. Имеется в виду, хочет ли организация получит документы определенных типов и видов или ей пофигу и "главное чтоб понятно было"?
Можно еще много задавать вопросов, но я обозначу то, что вижу сейчас.
У вас несколько вариантов:
1. Взять ГОСТ 34 и выдернуть из него структуру руководства. Не пугайтесь словом ГОСТ - структура там очень хорошая. Можно не лепить рамочки, а просто адаптировать структуру под себя.
2. Нанять технического писателя на аутсорс, который все сделает за вас.
Вам надо понять, что ваша задача делится на две части:
1. Сделать документ с нормальной структурой (по части контента).
2. Сделать документ, который имеет единообразное оформление (т.е. отступы и т.п.).
По п.1 - я уже сказал выше по поводу структуры. По п.2 - делайте дизайн (шаблон) и пусть вам туда выливают информацию.
По вашей теме есть специализированные решения - Single Sourcing Technical Documentation (Технология единого источника в технической документации), но у меня достаточно четкое убеждение, что ПОКА вам оно не нужно. Там действительно разработчики делают контент, а оформление идет на стороне автоматических обработчиков/шаблонов (т.е. контент отделен от оформления).
exifprobe? Ну и остальное под маской exif* Только имейте в виду, что exiv2 и exif* - это разные штуки. Здесь суффикс "...v2" - не ошибка! Насчет JPEG-сигнатур... не могу навскидку ответить. Гугл в помощь.
Ну, например, в Политеховской группе (СПб) адекватные вопросы и ответы. Можно кинуть вопрос и спросить, как учатся. И все ответы в личку. Понятно, что никто не будет светится прямо. А в личку скажут без стеснения кто, что и почему.
Насчет: по чему готовится - есть вопросы к вступительному экзамену в магистратуру. На каждом направлении/ВУЗе они свои. Так что эти вопросы лучше там решать. Более того, на кафедре можно получить эти вопросы и в течении года.
"На Тостере тусуются люди", которые работают в ИТ. В этом большая разница. Большинство из них закончило ВУЗы несколько лет назад. А некоторые - вообще дохрена сколько времени назад. Сейчас образование очень быстро меняется. Здесь можно получить общую информацию: например, "цель - такая то, какая должна быть стратегия". А вот куда поступать - это уже сам поступающий должен решать. Большое количество информации, которая неизвестна и/или недоступна участникам здесь, напрямую получается гораздо быстрее и, самое главное, эффективнее.