Я конечо извиняюсь, но 4 курс должен уметь уже работать более-менее самостоятельно. Находить нужные данные и доки в сети и думать об архитектуре а не о реализации.
Веб это не PHP или JSP на сервере или JS на клиенте, а взаимодействие клиент-сервер, с пониманием ограничений и множественного доступа и представлении информации + UI. Конкретный язык или тонкости технологии стунденты должны уже сами находить. В принципе согласен с Monyag по структуре, но упор должен делаться на наращивании понимания того что твориться с реальным приложением, а не освоением языка или фреймворка. Для начала полезно сделать простой пример что бы убедиться что все умеют базовые вещи, чтобы потом этот пример усложнять.
Лабы должны строиться по этому же принципу — как пример: сделали калькулятор, потом пытаемся считать что-то долгое, но итеративное, потом считаем на общих данных с возможными конфликтами или блокировками.
Или возьмем паттерны. Сначала пишем простой элементик, пусть простой tip, потом делаем их несколько разных, потом усложняем/меняем вид/поведение/взаимодействие для половины из них, что бы было понятно зачем нужно разделение на уровни.
По задачам — биржы фрилансеров имхо вредны, большая часть там тупые и стандартные задачи. Примеры надо придумывать вдумчиво и с переспективой на дальнейшее развитие, это не дело 5 минут. Главное для задачи — показать нужное и убрать лишнее. Это как Пушкин — должно быть просто и гениально одновременно.
Я бы посоветовал посмотреть на гайды — там встерчаются простые но интересные примеры.
И на последок о UI. Возможно это отдельная тема, но для веба важно иметь понимание об асинхронности, событиях и взаимодействии с пользователем. Думается что лаба с часиками + запрос на сервер + какой-то движняк на действия мышкой будет полезен.
Вед-два-ноль-ный хомяк и будет страничкой на очередном публичном сервисе. Социальному грызуну не нужен хостинг, ему нужен удобный сервис.
Зачем нужен свой хостинг?
личное казино с блек-джеком ...свой маганзичник плагинов
показывать готовые сайты/скрипты заказчикам
эксперементировать с различными сервисами которые любят привязываться к домену/IP
закостамайзить блог/портфолио для себя любимого
иметь возможность повесить скрипт на сутки-другие
завести жене магазинчик/фото хост/фич сервер
Это краткий перечень зачем мне мой хомяк понадобился в последние 2 месяца и чего я на нем творю в настоящее время.
Да, публичные сервисы могут покрыть стандартные потребности, но мне вечно недостает мелкой фичи, от банального SEO плагина для МЕТА, до запретов на е-комерцию по EULA ( хостинги правда тоже не все подходят по этой причине ) или трудностями по интеграции с системами платежей.
интересно, если покопаться ( то есть открыть исходник и сделать поиск ) то видно что
функция html(code) эквивалентна empty().append(code);
Но там же нашлась функция replaceWith(code) которая собственно по DOMу сама шариться и вставляет. По счастливому стечению обостоятельств именной ей я и вставляю готовые куски в таблицу.
Все правильно в методике работы. Именно так я и получаю «правильных» заказчиков.
Но вот оплата по часам…
Стандартная для меня ситуация когда работа сделана немного раньше срока или вообще вне плана — сильно заранее. Я вроде как получаю свободное время на отдых, самообраование, другие проекты. Но в реальности, если поставить работу в половину срока, то через 2-3 проекта возникает вопрос с оценкой работ.
Менее часто встречающая ситуация, когда работы затянулись. Как правило причины две — либо другой проект повлиял на общий план, либо ожидания были нарушены внешним фактором — обнаружен баг в библиотеке или глюк в ПО. Первое оплачивать заказчику вроде как не с руки, а второе некий форс-мажор, и вменяемые заказчики адекватно оценивают доп работы отдельно.
В общем, перейдя на фиксированные суммы, я получаю до 30% бонусов сверху за скорость и никакого напряга с обоих сторон. Сильная мотивация для меня сделать все как можно быстрее безо всякого контроля и понятные отношения для заказчика. И возможность гибко регулировать свой график и детальный план работы.
Веб это не PHP или JSP на сервере или JS на клиенте, а взаимодействие клиент-сервер, с пониманием ограничений и множественного доступа и представлении информации + UI. Конкретный язык или тонкости технологии стунденты должны уже сами находить. В принципе согласен с Monyag по структуре, но упор должен делаться на наращивании понимания того что твориться с реальным приложением, а не освоением языка или фреймворка. Для начала полезно сделать простой пример что бы убедиться что все умеют базовые вещи, чтобы потом этот пример усложнять.
Лабы должны строиться по этому же принципу — как пример: сделали калькулятор, потом пытаемся считать что-то долгое, но итеративное, потом считаем на общих данных с возможными конфликтами или блокировками.
Или возьмем паттерны. Сначала пишем простой элементик, пусть простой tip, потом делаем их несколько разных, потом усложняем/меняем вид/поведение/взаимодействие для половины из них, что бы было понятно зачем нужно разделение на уровни.
По задачам — биржы фрилансеров имхо вредны, большая часть там тупые и стандартные задачи. Примеры надо придумывать вдумчиво и с переспективой на дальнейшее развитие, это не дело 5 минут. Главное для задачи — показать нужное и убрать лишнее. Это как Пушкин — должно быть просто и гениально одновременно.
Я бы посоветовал посмотреть на гайды — там встерчаются простые но интересные примеры.
И на последок о UI. Возможно это отдельная тема, но для веба важно иметь понимание об асинхронности, событиях и взаимодействии с пользователем. Думается что лаба с часиками + запрос на сервер + какой-то движняк на действия мышкой будет полезен.
Зачем нужен свой хостинг?
личное казино с блек-джеком ...свой маганзичник плагиновЭто краткий перечень зачем мне мой хомяк понадобился в последние 2 месяца и чего я на нем творю в настоящее время.
Да, публичные сервисы могут покрыть стандартные потребности, но мне вечно недостает мелкой фичи, от банального SEO плагина для МЕТА, до запретов на е-комерцию по EULA ( хостинги правда тоже не все подходят по этой причине ) или трудностями по интеграции с системами платежей.
я бы для линков повесил атрибут name в котором бы указал класс или ID связанного div-а. И bind выглядел бы попроще и универсальнее:
функция html(code) эквивалентна empty().append(code);
Но там же нашлась функция replaceWith(code) которая собственно по DOMу сама шариться и вставляет. По счастливому стечению обостоятельств именной ей я и вставляю готовые куски в таблицу.
Но вот оплата по часам…
Стандартная для меня ситуация когда работа сделана немного раньше срока или вообще вне плана — сильно заранее. Я вроде как получаю свободное время на отдых, самообраование, другие проекты. Но в реальности, если поставить работу в половину срока, то через 2-3 проекта возникает вопрос с оценкой работ.
Менее часто встречающая ситуация, когда работы затянулись. Как правило причины две — либо другой проект повлиял на общий план, либо ожидания были нарушены внешним фактором — обнаружен баг в библиотеке или глюк в ПО. Первое оплачивать заказчику вроде как не с руки, а второе некий форс-мажор, и вменяемые заказчики адекватно оценивают доп работы отдельно.
В общем, перейдя на фиксированные суммы, я получаю до 30% бонусов сверху за скорость и никакого напряга с обоих сторон. Сильная мотивация для меня сделать все как можно быстрее безо всякого контроля и понятные отношения для заказчика. И возможность гибко регулировать свой график и детальный план работы.