В тех магистратурах, которые видел я (в одной — даже отучился), это фактически подготовка к аспирантуре — магистранту дается лишние пара лет для того, чтобы углубиться в изучаемыю область и наработать материал для аспирантуры. Кроме того, магистры зачиляются в профильную аспирантуру без экзаменов. Правда, кандидатский минимум всё равно надо сдать, без этого аспиранут никак.
Поправка — бакалавриат в российских вузах — по бОльшей части 4 года. Болонский процесс предполагает переход на 3 или 4 года, но подавляющее большинство вузов взяло верхнюю планку — 4 года, чтобы минимально урезать программу по сравнению со 5-летним специалитетом.
Добротный обзор, жду продолжение о внедрении в конкретной организации «имя котороый для нас не слишком важно».
Кстати — опечаточку поправь — «котороый». И перед предпоследним предложением «image» надо бы заменить на что-нибудь — или картинку, или "" :)
Студенты выбирают себе тему сами — тут главное не сама задача, а то, как её решают… задача ведь обучить, а не получить что-то на продажу :) И работают по одному. Командная работа — штука сложная, чтобы её совмещать с изучением совершенных технологий. Позже есть отдельный курс, где им дают совместные задания, здесь же задача — дать понимание технологий, без отвлечения на что-то ещё.
Задания формулируются в виде документа, который берется в электронном виде в начале семестра. Надо бы и вправду куда-нибудь выложить :) Как раз сейчас готовлю методичку по эту предмету — вот в финальном варианте сложу все задания в приложении, а сам документ выложу в открытый доступ, в Инет. Университетские сервера стараюсь избегать, слишком много бюрократии и случайностей при обслуживании оборудования :))
Преподаю в нашем Политене на одной из профильный специальностей. В частности, Интернет-технологии, 4 семестр (2 курс).
1. Организация Сети, её структура, основные протоколы и их назначение (обзор)
2. Протокол HTTP — что это, основы работы, запрос-ответ, заголовки
3. Протокол CGI — вкраце
4. Обзор/повторение HTML — они уже изучали основы, я рассматриваю его с точки зрения концепции, в привязке в WWW.
5. CSS
6. PHP — семантика, основные бибилиотеки, связка с БД на примере MySQL
7. XML/XSLT/XSD — что такое и зачем надо, подробно рассматривается в другом курсе.
Лабы и итоговая работа строится на пошаговом (по мере изучения технологии) создании веб-сайта с простой логикой и работой с БД.
— постановка задачи на дальнейшую работу, написание требований к своему сайту, разработа структуры
— работа через telnet, чтобы увидеть как работает HTTP
— разработка HTML-макета будущего сайта с использованием CSS
— разработка динамической составляющей, т.е. написание PHP кода для ожидвления сайта. Это может быть лента новостей с админкой и комментариями юзеров или что-то подобное.
В общем, в концу 2 курса народ получает представление о том, как работает Веб и как под него что-то сделать.
А вот что вам давать им на 4 курсе — тут уже вопрос. По идее, надо бы вводный курс чуть пораньше давать — как у меня, например, на 2 курсе. А подробное изучение отдельных технологий, вроде XML/XSLT/XSD/RSS/XML-RPC или же Javascript/AJAX/HTML5 сотоварищи — уже позднее, перед дипломом.
[смахивает слезу рукавом тельняшки]
Тёзка! Я тя практически абажаю! Подписываюсь под каждым словом!
Так уж выходило, что почти на половине проектов приходилось иметь дело с тоннами чужого кода. В одном случае код вообще писался даже на протяжении 4 или 5 лет разными программистами. Просто каша — ни в борщ, ни в Красную Армию. Это было занятие не для слабонервных. Причем, всё работало и очень даже резво. Но при попытке что-то внести — разумеется, тянуло всё за собой. В общем, применяя практики, описанные в статье (за исключением юнит-тестов, увы), постепенно переписал половину системы и сделал возможность расширять её и дальше — без головняка, геморроя и прочей медицины.
От себя добавлю, что рефакторинг небольшого куска функционала, с одновременным добавлением чего-то нового — лучший способ разобраться в наследованном коде.
Приходишь на проект, осматриваешься, понимаешь общий принцип построения архитектуры. А далее, берешь самую небольшую задачу и не торопясь разбираешь систему на винтики, глядя — где же можно чего подкрутить, чтобы задачу решить. Ну и потом собрать на место всё так, чтобы завелось с первого раза :)
Две-три такие задачи — и начинаешь понимать, в каком направлении вести рефакторинг, где самые слабые места, на которые надо обратить внимание в первую очередь, где ещё пока терпимо и можно не трогать до поры до времени… А куда вообще лучше не соваться, понимая, что переписать там что-то невозможно без переделки половины системы. В этих случаях надо просто смириться и тратить силы на более важные направления.
В общем, зачет, пиши ещё.
P.S. к вопросу о source control и бранчах — вот очень неплохая обзорная статья по базовым практикам www.cmcrossroads.com/bradapp/acme/branching/
Практики эти применимы независимо от выбранной системы. Будут вопросы — обращайтесь.
Было дело, 3.5.1 тупил при загрузке. При этом постоянно светил диод обращения к диску. Запустил filemon, выяснилоь, что ФФ зачем-то очень много обращался к temporary internet files (?!) Почистил их — запуск стал вновь нормальным.
Хм… а вот у меня на столе клава, мышка, листок бумаги и карандаш. Плюс кружка и наушники.
Что делаю не так? :)
Творческими кризисами не страдаю, скорее наоборот — код пишется бодро и интенсивно. Кстати, приходится делать много рефакторинга (АКА из хлама — код, работающий быстрее и лучше).
Посему родилась мысль — прежде чем делать рефакторинг кода, надо сделать рефакторинг образа мыслей и окружающего пространства. Вот такой научный материализм :)
P. P. S. Это не призыв к изменению всех и сразу. Это всё сугубо ИМХО. :)
Скажу тебе как преподаватель :) который одно время читал «Теорию БД». К тому же я ещё и практик.
Так вот, тебе просто не везло с преподами :) не смогли объяснить нужность подобных вещей.
Нормализация — это правильная и нужная вещь.
Я встречал пару задач на практике, требовавшие вдумчивой нормализации.Нормальные формы я в них не считал, не задавался целью, но до 4-й дошел стопроцентно.
Так что сферических коней тут нет. Люди, придумавшие НФ, сделали это не из любви к искусству, они ведь тоже решали какие-то задачи таким способом. Тебе не приходило в голову работы Д. Кнута называть подобныи «конями»? Думаю, нет — потому что описанные алгоритмы используются на практике. Так и здесь.
Но нормализация только лишь ради неё самой — это зло. Всё должно быть в меру. Именно об этом и статья — показать вторую сторону медали нормализации.
Мне, кстати, тоже приходилось заниматься описанными в статье вещами — и производителтьность на базах с сотнями тысяч записей вырастала на порядки.
Земляк, подумай о карьере преподавателя, в параллель к основной :) Доступно объяснять сложные вещи — этого сильно не хватает в преподавательской среде :)
1. eTraxis
Очень гибкая и простая в работе система. Open Source. Принимал участие в его разработке. Создателя системы знаю лично :) На предыдущем месте работе стоит как штатная система тикетов внутри компании. Участвовал в его внедрении в одной из больших команд в рамках Motorola Inc (работали мы на них одно время).
2. Redmine
Очень притная система, использовал наодном из проектов. Не такая гибкая, как номер 1, но очень приятная в работе.
В тех магистратурах, которые видел я (в одной — даже отучился), это фактически подготовка к аспирантуре — магистранту дается лишние пара лет для того, чтобы углубиться в изучаемыю область и наработать материал для аспирантуры. Кроме того, магистры зачиляются в профильную аспирантуру без экзаменов. Правда, кандидатский минимум всё равно надо сдать, без этого аспиранут никак.
А вообще, не надо догадок:
ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%81%D1%82%D1%80
Довольно подробно и про магистров и про болонский процесс по сслыкам в статье.
Кстати — опечаточку поправь — «котороый». И перед предпоследним предложением «image» надо бы заменить на что-нибудь — или картинку, или "" :)
Задания формулируются в виде документа, который берется в электронном виде в начале семестра. Надо бы и вправду куда-нибудь выложить :) Как раз сейчас готовлю методичку по эту предмету — вот в финальном варианте сложу все задания в приложении, а сам документ выложу в открытый доступ, в Инет. Университетские сервера стараюсь избегать, слишком много бюрократии и случайностей при обслуживании оборудования :))
Преподаю в нашем Политене на одной из профильный специальностей. В частности, Интернет-технологии, 4 семестр (2 курс).
1. Организация Сети, её структура, основные протоколы и их назначение (обзор)
2. Протокол HTTP — что это, основы работы, запрос-ответ, заголовки
3. Протокол CGI — вкраце
4. Обзор/повторение HTML — они уже изучали основы, я рассматриваю его с точки зрения концепции, в привязке в WWW.
5. CSS
6. PHP — семантика, основные бибилиотеки, связка с БД на примере MySQL
7. XML/XSLT/XSD — что такое и зачем надо, подробно рассматривается в другом курсе.
Лабы и итоговая работа строится на пошаговом (по мере изучения технологии) создании веб-сайта с простой логикой и работой с БД.
— постановка задачи на дальнейшую работу, написание требований к своему сайту, разработа структуры
— работа через telnet, чтобы увидеть как работает HTTP
— разработка HTML-макета будущего сайта с использованием CSS
— разработка динамической составляющей, т.е. написание PHP кода для ожидвления сайта. Это может быть лента новостей с админкой и комментариями юзеров или что-то подобное.
В общем, в концу 2 курса народ получает представление о том, как работает Веб и как под него что-то сделать.
А вот что вам давать им на 4 курсе — тут уже вопрос. По идее, надо бы вводный курс чуть пораньше давать — как у меня, например, на 2 курсе. А подробное изучение отдельных технологий, вроде XML/XSLT/XSD/RSS/XML-RPC или же Javascript/AJAX/HTML5 сотоварищи — уже позднее, перед дипломом.
Тёзка! Я тя практически абажаю! Подписываюсь под каждым словом!
Так уж выходило, что почти на половине проектов приходилось иметь дело с тоннами чужого кода. В одном случае код вообще писался даже на протяжении 4 или 5 лет разными программистами. Просто каша — ни в борщ, ни в Красную Армию. Это было занятие не для слабонервных. Причем, всё работало и очень даже резво. Но при попытке что-то внести — разумеется, тянуло всё за собой. В общем, применяя практики, описанные в статье (за исключением юнит-тестов, увы), постепенно переписал половину системы и сделал возможность расширять её и дальше — без головняка, геморроя и прочей медицины.
От себя добавлю, что рефакторинг небольшого куска функционала, с одновременным добавлением чего-то нового — лучший способ разобраться в наследованном коде.
Приходишь на проект, осматриваешься, понимаешь общий принцип построения архитектуры. А далее, берешь самую небольшую задачу и не торопясь разбираешь систему на винтики, глядя — где же можно чего подкрутить, чтобы задачу решить. Ну и потом собрать на место всё так, чтобы завелось с первого раза :)
Две-три такие задачи — и начинаешь понимать, в каком направлении вести рефакторинг, где самые слабые места, на которые надо обратить внимание в первую очередь, где ещё пока терпимо и можно не трогать до поры до времени… А куда вообще лучше не соваться, понимая, что переписать там что-то невозможно без переделки половины системы. В этих случаях надо просто смириться и тратить силы на более важные направления.
В общем, зачет, пиши ещё.
P.S. к вопросу о source control и бранчах — вот очень неплохая обзорная статья по базовым практикам
www.cmcrossroads.com/bradapp/acme/branching/
Практики эти применимы независимо от выбранной системы. Будут вопросы — обращайтесь.
Уж не знаю, как это связано — но мне это помогло.
Что делаю не так? :)
Творческими кризисами не страдаю, скорее наоборот — код пишется бодро и интенсивно. Кстати, приходится делать много рефакторинга (АКА из хлама — код, работающий быстрее и лучше).
Посему родилась мысль — прежде чем делать рефакторинг кода, надо сделать рефакторинг образа мыслей и окружающего пространства. Вот такой научный материализм :)
P. P. S. Это не призыв к изменению всех и сразу. Это всё сугубо ИМХО. :)
Так вот, тебе просто не везло с преподами :) не смогли объяснить нужность подобных вещей.
Нормализация — это правильная и нужная вещь.
Я встречал пару задач на практике, требовавшие вдумчивой нормализации.Нормальные формы я в них не считал, не задавался целью, но до 4-й дошел стопроцентно.
Так что сферических коней тут нет. Люди, придумавшие НФ, сделали это не из любви к искусству, они ведь тоже решали какие-то задачи таким способом. Тебе не приходило в голову работы Д. Кнута называть подобныи «конями»? Думаю, нет — потому что описанные алгоритмы используются на практике. Так и здесь.
Но нормализация только лишь ради неё самой — это зло. Всё должно быть в меру. Именно об этом и статья — показать вторую сторону медали нормализации.
Мне, кстати, тоже приходилось заниматься описанными в статье вещами — и производителтьность на базах с сотнями тысяч записей вырастала на порядки.
Так что автору — респект и +1 интерес.
1. eTraxis — Очень гибкая настройка жизненного цикла записи.
2. Redmine — Простота работы. Не так гибок, но очень хорош.
3. Простота работы. Там всё действительно до нельзя просто. Иногда слишком. Но читатели Getting Real поймут о чем я ;)
1. eTraxis
Очень гибкая и простая в работе система. Open Source. Принимал участие в его разработке. Создателя системы знаю лично :) На предыдущем месте работе стоит как штатная система тикетов внутри компании. Участвовал в его внедрении в одной из больших команд в рамках Motorola Inc (работали мы на них одно время).
2. Redmine
Очень притная система, использовал наодном из проектов. Не такая гибкая, как номер 1, но очень приятная в работе.
3. Сейчас использую Basecamp :)