• Куда поступать в IT-магистратуру в Екатеринбурге?

    alexe0110

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

    Насчет: по чему готовится - есть вопросы к вступительному экзамену в магистратуру. На каждом направлении/ВУЗе они свои. Так что эти вопросы лучше там решать. Более того, на кафедре можно получить эти вопросы и в течении года.

    "На Тостере тусуются люди", которые работают в ИТ. В этом большая разница. Большинство из них закончило ВУЗы несколько лет назад. А некоторые - вообще дохрена сколько времени назад. Сейчас образование очень быстро меняется. Здесь можно получить общую информацию: например, "цель - такая то, какая должна быть стратегия". А вот куда поступать - это уже сам поступающий должен решать. Большое количество информации, которая неизвестна и/или недоступна участникам здесь, напрямую получается гораздо быстрее и, самое главное, эффективнее.
  • Куда поступать в IT-магистратуру в Екатеринбурге?

    А, кстати, что-то заслоупочил я немного.

    alexe0110 А почему вы с этим вопросом идете на Тостер, а не в группы Подслушано <ВУЗ>. Там и задавайте вопросы. Нынешние студенты или недавние выпускники вам столько всего расскажут, что будете принимать решение. На Тостере же в основном, теоретические вещи (в т.ч. у меня) - они не показывают реальную картинку в конкретном ВУЗе/направлении
  • Куда поступать в IT-магистратуру в Екатеринбурге?

    DS28 Да, делается. Но это растягивается на 4-6 месяцев и с неизвестным результатом.

    Я НЕ увидел, что магистратура человеку не нужна. М.б. он хочет получить _теоретические_ знания, которых не было на УТС. В отличие, например, от программной инженерии или прикладной математики.

    Тут вопроса два и, действительно, стратегия зависит от цели. Дело в том, что СЕЙЧАС он может поступить на другое направление. Но это не означает, что через 2 года, после работы и когда он созреет (по вашему варианту), Минобр не отменит правило поступления в магистратуру на любое направление. И ему придется довольствоваться магистратурой только по УТС. В магистратуре (нормальной (!)) учат искать решения задач нетривиальным образом. Т.е. не натаскивают, как в проф. деятельности, а именно учат. Т.е. там учат подходу, который использует, например, Senior или Архитектор при выработке решения по выбору стека. С обоснованием этого. А обоснование - важно для бизнеса. И ради этого туда стоит идти. Обычный бакалавр научится этому только посл 4-5 лет в индустрии (а до этого будет тупо кодить). Ради просто корочек, конечно, нет.
  • Куда поступать в IT-магистратуру в Екатеринбурге?

    DS28 Думаю, что вы немного не владеете ситуацией. Правильный ВУЗ и правильное направление в данном контексте - это наличие оных в базе Anabin (Informationssystem zur Anerkennung ausländischer Bildungsabschlüsse). Подобные штуки есть и в других странах, называются по другому.

    P.S. Магистратура не отменяет параллельную работу! Более того, она не только желательна, но и настоятельно рекомендуется.
  • Куда поступать в IT-магистратуру в Екатеринбурге?

    DS28 C магистратурой правильного ВУЗа легче взять трактор. Да, с бакалавриатом тоже можно, но лучше Master of smth
  • СЗОТУ. Как оно в плане обучения?

    Полагаю, что вам лучше рассмотреть классику - СПбПУ, ИТМО и т.п. Дело в том, что практике разработки вы научитесь из практической работы (прошу прощения за некоторую тавтологию). ВУЗ вам нужен (если нужен) только с точки зрения матчасти (т.е. основ: алгоритмов и т.п.). И здесь лучше не жадничать.

    М.б. сначала попробовать устроиться джуниором? И потом уже из практики работы искать ВУЗ - т.е. вы увидете на практике, что такое ИТ, и что такое разработка. И уже потом будете выбирать ВУЗ, исходя из требований - то, чего не хватает в работе.

    Как войти в эту сферу - еще советы поищите здесь на форуме.
  • Можно ли сделать общий словарь - справочник для "офисных" документов?

    other_letter
    Для начала прочитайте вот это:
    Для общего просвещения: singlesourcing.ru/sa/index.html
    Для того, чтобы понять, что и как: singlesourcing.ru/sw/index.html

    Попробуйте сделать за пробный файл за 15 минут с помощью reuse content. Сравните подобное с традиционными решениями. Сколько времени у вас займет все это? Только в этом вопрос (ну, и, как следствие, в деньгах).

    2. Описывать в Word части диаграммы Visio, чтобы данные этой диаграммы и/или изображение менялось "само".

    Кстати, второй пункт мне не совсем понятен.

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

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

    Так что все только пробовать, смотреть и оценивать.
  • Можно ли скормить RTF на вход XSLT-процессору, чтобы получить на выходе PDF?

    Александр Симонов: Я про это и говорил "У вас изначально неправильно поставлена цепочка преобразований" :)
  • Типографика: ГОСТ и импортозамещение - чья взяла?

    Z-r: Вы немного не поняли.

    1. Основная мысль была в посте автора была следующая: "ГОСТ требует одно, а используется другое. Как быть?"

    2. Я привел вам примеры несоответствий не только в шрифтах - все гораздо шире. Т.е. даже те стандарты, которые существуют, совершенно не используются в деятельности госструктур.

    3. И я говорю про _использование_ стандарта в _работе_ любых структур, а не только создание документов _разработчиками_ ПО. Например, нормативные документы на сайте Минсвязи идут в т.ч. в docx, а не как говорит ГОСТ Р ИСО/МЭК 26300-2010 в ODT. Об этом и была подтверждающая статья на хабре.

    4. Государственные - остались. ФГУП НТЦ Атлас, ФГБУ «ЦЭКИ» и т.д.
  • Где лучше всего вести документацию по сервису?

    semenovsanek: Это вы мне ответили на мой коммент? Только не понятно, что именно вы имели в виду :)
  • Как Вы документируете функционал приложения?

    Странно, но под ваш функционал подходит простейший single sourcing (я говорю про DocBook, т.к. на нем специализируюсь).

    Т.е. как мне это видится:
    1. Один article c требованиями ("простыня").
    2. Под каждый section c требованиями поставлены атрибуты (pro, nonpro, common).
    3. Пункты меня оформлены отдельным справочником и с требований идет вставка (xinclude) конкретного пункта меню.

    Можно будет:
    1. Автоматически (через xslt) собирать матрицу функционал - пункты меню.
    2. Хранить версионность.
    3. Если в какой-нибудь ветке исчезнет пункт меню - это сразу же будет видно в функционале (т.к. linked, а не embedded|copy paste).
    4. На выходе вы сможете получить документ, который соответствует конкретной роли (один исходник - несколько выходных документов из него по одной команде).

    А странно, т.к. редко когда сложные решения подходят для простых задач. У вас, судя по всему, именно этот случай.

    Если нужны подробности, то вам с подобными вопросами сюда: forum.singlesourcing.ru
  • Сколько минимум нужно выделить места под разделы для linux, для офисного компа?

    ky0 я не об этом... Я о том, что на рабочих станциях рекомендуется выделять на отдельные разделы var и tmp именно потому, чтобы какое-нибудь приложение пользователя не заполнило весь диск и не положило систему. Да, существуют 5% рута (по умолчанию).

    Квоты на /var и /tmp? Многие приложения запускаются от рута в фоне. Вы будете делать квоту руту?
    Зачем городить огород, когда можно просто вынести в отдельный раздел. Речь же о рабочих станциях.
  • Сколько минимум нужно выделить места под разделы для linux, для офисного компа?

    Вы не правы. А как же размещать /var, /tmp, /home на разных разделах в целях безопасности???
    tldp.org/HOWTO/Partition/requirements.html#AEN493
  • Какие общепринятые принципы формирования электронных документов вам известны?

    @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 (Технология единого источника в технической документации), но у меня достаточно четкое убеждение, что ПОКА вам оно не нужно. Там действительно разработчики делают контент, а оформление идет на стороне автоматических обработчиков/шаблонов (т.е. контент отделен от оформления).
  • Как отсортировать большое количество фотографий?

    И еще... Вы неправильно поставили теги к вопросу. НЕ программирование, а bash или т.п.
  • Как отсортировать большое количество фотографий?

    exifprobe? Ну и остальное под маской exif* Только имейте в виду, что exiv2 и exif* - это разные штуки. Здесь суффикс "...v2" - не ошибка! Насчет JPEG-сигнатур... не могу навскидку ответить. Гугл в помощь.
  • Как узнать IP посетителя сайта?

    1. Если есть доступ к логам веб сервера - через access/error .log
    2. Если нет, то можно попробовать, например, openstat

    Вы определитесь, какие данные вам нужны. Если raw - то п.1, если обработанные - п.2