northbear

Не могу понять что именно вы хотите автоматизировать (если я правильно понял заголовок)? Написание 100 страниц текста? Или саму прошивку?

Если всё таки прошивку, то это сильно зависит от вашей железки. Для этих нужд вам нужен тестовый стенд на основе вашей железки.

Firefox + Web developer plugin… IMHO, идеальная среда. Даже не знаю что еще к этому можно добавить. Разве что какой-нибудь оффлайновый Reference manual если вы не все теги html и свойства СSS на память помните…

Рекомендую использовать только OpenSource DBMS для курса.

Основой конечно же должна быть Relational Databases. Реляционная алгебра, SQL, деревья и построение индексов, организация хранения данных на дисках.

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

Далее… Технологии организации кластеров: репликация, шардинг и прочая… Хороший инструмент — Apache Cassandrа, это правда NoSQL…
Обязательно надо давать материал по оценки сложности и ресурсоемкости запросов с учётом индексов и без них.
После этого переходить на NoSQL и key-value storages, map/reduce запросы и прочая… По нынешним временам это должно быть обязательно. Это лучше давать в конце. К этому времени вся необходимая теория им будет уже известна…

Так же имеет смысл давать Документоориентированные базы данных и хранилища слабоструктурированных данных и выборки по ним (то, то используют поисковые системы).

Не ведитесь на Oracle. Я так понимаю, что Oracle обещает бесплатные сервера и материалы для обучения. Но:
1) вам придется разориться железо. Системные требования весьма и весьма немаленькие…
2) При поставке Oracle ВУЗу придется подписать весьма кабальное соглашение ограничивающее ваши возможности. Хорошо, если они не заставят вас носить трусы с логотипом Оracle. Футболки и прочая маркетинговая мишура в хорошем хозяйстве найдут применение. Но почти наверняка запретят использовать у учебном процессе базы данных других производителей и open-source СУБД… Бесплатный сыр, как говорится…
3) Вы лишите своих студентов возможности делать практику дома. Express Edition и Personal Edition сильно урезаны. Например кластеры вы на них не соберете… Оpen-Source по многим параметрам предпочтительней.
4) Реальные потребности рынка в Oracle-программистах не высоки. Особенно на периферии. Если у вас не столичный вуз то это бессмысленно…

echo -en обязательно. Без -n в конец строки будет добавлен newline…

Раз вы неплохо разбираетесь в PHP, то начните с Yii. Это позволит вам незаморачиваясь на изучение языка, разобраться со стеком протоколов, техникой и технологией. После этого уже решите, куда вам интересней двинуться дальше на Ruby или Python. Если вообще конечно захотите потом углубляться в сферу…

Если «несколько» — это в пределах десятка и это число не будет увеличиваться, то самое простое, строить на платформе Linux KVM. Если есть перспектива увеличения числа виртуалок свыше десяти и дальше, то правильней будет XEN.

Для KVM'a есть неплохие готовые дистрибутивы типа Proxmox, где всё есть из коробки. Со Xen'ом сложнее, но это плата за мощность… Проприетарные «бесплатные» решения не советую. Там вы очень быстро, не успев тольком начать упрётесь в ограничения и/или неудобства бесплатной версии. А более-менее рабочий набор инструментов VMWare уже стоит денег.

Если бюджет позволяет, то конечно эффективней купить VMWare Server. Там много реально удобных, полезных и вкусных фишек которые весьма и весьма облегчают жизнь…

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

В embedded вообще ничего не гарантируется производителем железа. Максимум гарантий — это температурные режимы конкретного типа кристаллов и вероятностная оценка сбоев в неблагоприятных средах. Слишком многое зависит от кривизны рук разработчиков обвязки (датчики и прочая периферия) и софта. А после них еще от инсталлятора и эксплуатанта… Поэтому всё от вас зависит. При грамотно сделанной обвязке, правильно написанном софте и контроле температурного режима внешней среды будет работать без проблем.

Прочитайте про аппаратный watchdog, например. Если интервалы считывания данных с датчиков достаточно большие, то можно делать hard reset после каждого цикла считывание, обработка, отправка данных uplink'у. Тем самым застрахуетесь от накопления софтовых проблем. Вариант не без недостатков, поэтому смотрите сами…

В общем дерзайте… Никаких принципиальных ограничений там нет.

Зависит от задач… Если для того, чтобы в дороге полазить по сети и проверить почту, то тогда имеет смысл взять таки планшет. Легче, меньше места занимает. Если что-то более серьезное, то лучше смотреть уже на ультрабуки и иже с ними… Для кодинга нетбуки — это грустно…
Если именно нетбук, то тут скорее производителя надо выбирать:
Acer — много моделей с мощной батареей, но жесткость корпуса (особенно верхней крышки, защищающей дисплей) вызывает серьезные сомнения.
Asus — цены выше среднего, дизайн не впечатляет, батареи играют долго, адекватный саппорт.
Dell — модель на модель не приходится, но саппорт отвратительный…
HP — стильные нетбуки, хороший саппорт, батареи держат выше среднего. Но любят лочить железо. Например, если сдох wifi-адаптер, то часто бывает, что заменить его не абы какой нельзя. Замена только на фирменное от hp и только в сервис центре. В дороге это иногда может быть проблемой…
Samsung — стильно, и поэтому дорого. более-менее нормальный саппорт. «Долгоиграющие» батареи…
Lenovo ThinkPad — кондово и дорого. Для тех кому ехать, а не шашечки… Остальные серии надо внимательно пробивать на предмет родовых проблем… Саппорт не фонтан…

Кого еще пропустил?

По работе со git'ом на старте рекомендую использовать методологию git-flow. Поищите тут на хабре был перевод статьи «A successful Git branching model».
По всему остальному мой совет: не увлекайтесь формализацией/регулированием. Дайте команде возможность самоорганизоваться. Вы им должны задать только основые точки фокуса на которых они должны сконцентрироваться. Используйте японский принцип. Они строят дорожки там, где люди больше всего натоптали тропы. Так и вы, документируйте только те правила, которые уже стали стандартом де факто. И помните главную цель этой формализации: Она нужна для максимально быстрого ввода нового человека в команду. Чтобы лишний раз не приходилось разжевывать новичку вещи, которые для команды уже давно исторически установившиеся правила.
Для эффективной команды формализация не нужна, либо тупо, мешает…

Ставьте хорошую классику. Во-первых — это вызывает ощущение солидности и серьезности заведения. Люди часто заслушиваются. Проще произвести правильно впечатление на клиента…
Во-вторых, избавите себя от необходимости платить авторские, если какие-нибудь «наномихалковы» случайно забредут к вам…

Подбор произведений имеет значение…

GTalk и закрытые googlegroups под ваши условия вполне подходят. У GTalk'а даже с голосом и видео можно пообщаться… Более того. имеются неплохие клиенты на смартфонах на базе Android. Можно участвовать в совещаниях прямо на ходу… Иногда, в условиях распределенной команды, весьма полезная вещь…

Но с Google одна проблема: Рассчитывать на конфиденциальность я бы там не стал. В skype тоже, кстати говоря… mail.ru как российский сервис особенно сомнителен в этом плане…

Для начала придется выучить китайский… Это как раз весьма полезно делать в Китае. Погружение, и всё такое…
Английский там большая редкость, если конечно вы не выберите для обучения Гонконг и Шанхай. В Гонконге с английским вообще без проблем, в Шанхае посложнее…

Пекин не рекомендую. Китай коммунистическая страна. Строит коммунизм, так сказать. И Пекин как столица находится на острие этого «строительства», со всеми приколами и гримасами…

Ехать туда учиться имеет смысл только с прицелом на какой-то бизнес в дальнейшем. С образованием в плане Software Engeneering там круто в том смысле, что они не гнушаются приглашать именитых спецов в этой области для чтения лекций. Но это можно найти и в менее экзотических местах…

На серьезные курсы и темы вас учиться не возьмут. КГБ там тоже есть…

Да, согласен с первым комментарием. На младшие atmel'ы с pic-ов разве что для общей эрудиции… Если с паяльником дружите, то проще самому собрать дев-борд под свои задачи, с программатором и прочими прелестями…

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

Помимо этого, обязательное документирование коммитов git-репозитарий.

Ну и собственно комментарии в коде никто не отменял. В Ruby/RoR есть довольно мощные утилиты, которые позволяют из комментариев в коде собирать довольно приличную документацию… Естественно для этого надо, чтобы комментарии писались по определенному шаблону-стандарту, иначе фигня получается…

www.w3schools.com/ и практика… И ковыряние кода хороших проектов хороших проектов.

Web-программирование достаточно широкое понятие и часто выходит далеко за пределы чистого web-программинга.

Основное деление это:
1) front-end (программирование того. что клиент видит на экране и взаимодействия);
2) back-end — программирование серверной части.

Эти два направления требуют принципиально разных компетенций и редко кому удается удачно (успешно) совмещать… Тут вам хотя бы на первом этапе изучения надо определиться. После этого выбора будет более-менее понятно в какую степь идти и какие инструменты изучать…

Позволю себе добавить для правильного понимания вопроса. В международной практике право требования исполнения лицензии (в данном случае GPL) принадлежит авторам. Никто другой предъявить обвинение в сокрытии кода в рамках GPL не может. Это, правда, впрочем не мешает третьим лицам организовывать публичные компании порицания нарушителей. Эффект от этого не хуже. Авторы это право могут делегировать другим лицам или организациям типа FSF.

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

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

Лучше всего, на мой взгляд, создать новый проект куда авторы пушат свою часть кода под соответствующей лицензией. Недостающий код (если кто-то отказался отдать свой код под другой лицензией) дописывают самостоятельно…

В случае публичных проектов, число авторов кода может быть весьма велико, перелицензирование может быть весьма проблематичным. Этим кстати, объясняется нежелание некоторых коммерческих компаний принимать в свои «открытые» проекты код от сторонних разработчиков. Видимо они еще надеются на коммерческие перспективы этих проектов.

Не совсем понятны задачи сервера… Сколько участников в проекте. Доступ к репе по локалке или с публичных сетей тоже? И таки да, почему http? Чем не подходит стандартный ssh-транспорт?
Сами пользуем Gitolite и вам настоятельно советуем…

Универсального решения независящего от количества текста в колонках нет.
Если количество текста в сайдбаре всегда меньше, чем в контентной колонке. То можно вложить контентный div во внутрь div'а сайдбара, зафиксировав ширину контентного дива и установив float: right;.

Или тривиальный вариант: Сделать двухцветный фон страницы (с background-repeat: repeat-y;), div колонок с прозрачным фоном и соответственное позиционирование каждой колонки на поле своего цвета… ) Колонки по факту будут не 100% процентов высотой, но визуально будет выглядеть так…

TL-MR3020 у меня отлично работает в таком режиме. Там есть соответствующий переключатель режимов: 3G+AP+Router. Очень удобно. Единственно надо помнить, что в режиме AP шлюз не умеет выдавать ip-адрес по DHCP. Нужен внешний dhcp-сервер…

Не вижу причин, почему бы модели 3220 не работать. TP-Link у меня оставил куда лучшее впечатление, чем D-Link.