Зачем понимать что такое int и string? Достаточно понимать что в переменной x записано число, а в переменной y — строка.
Не забывайте что это первоначальное обучение, там надо минимизировать количество сущностей, которые надо держать в голове.
Типы вообще отдельная и сложная тема, которая при начальном обучении мешает. Любая попытка использовать статически типизированный язык натыкается на генерики\шаблоны при переходе к контейнерам. Я помню как у нас на первом курсе из 100 человек осилили array of record человек 10 всего. и это еще мягкий вариант обобщений.
1) Есть jsfiddle — его более чем достаточно.
2) В jsfiddle есть JSLint, он быстро покажет где неправ.
3) Никакого менеджмента вообще. На начальном этапе важно понять как делать функции и комбинировать их в другие функции. Любое управление ресурсами — головная боль, мешающая достижению цели.
4) Haskell, F#,Scala, Lisp — за всю жизнь может ни разу не пригодиться. Старый паскаль — очень далек от современного delphi. Голый C — может пригодиться только в курсе системного программирования, в качестве языка для начала обучения не подойдет. Про эзотерику вроде brainfuck даже не говорю.
Язык для первоначального обучения программированию (то есть когда студенты еще ни на чем никогда не программировали) должен иметь следующие свойства:
1) Не требовать установки софта вообще
2) Иметь минимум «базовых» сущностей и никакого public-static-void-main-overhead
3) Иметь динамическую типизацию и\или мощный авто вывод типов
4) Никакого менеджмента ресурсов
5) Быть практическим (то есть на нем можно писать реальные программы)
Идеально подходит JavaScript. C++ категорически не подходит по всем параметрам, C# и java тоже. Python — нормальный вариант.
Далее чему учить: никакого ООП в первые полгода-год, объекты — наборы «ключ»-«значение» и все. Нельзя давать ни классы, ни прототипы.
Обязательно функции, рекурсию, лямбды и замыкания. Алгоритмы на массивах, матрицах, деревьях, графах.
Уже потом можно грузить компиляцией, модульностью, ООП, управлением ресурсами. Лучше всего на C#.
А вот на третий год уже выносить мозг C++ с шаблонами. А также можно параллельным\асинхронными программированием.
То есть у вас уже была вполне конкретная схема данных и не было проблем уложить её в NoSQL.
А если вы начинаете проект с NoSQL, особенно Document DB, то как вы заранее узнаете какую схему создавать
Вообще созданием правильной схемы для Document DB, как Mongo — крайне нетривиальная задача. Даже отсутствие однозначного ответа в случае простого интернет-магазина это очень хорошо показывает.
А в статье рекомендуется начинать в том числе с NoSQL, со всеми вытекающими.
Я этот вопрос задавал многим, кто пропагандирует использование NoSQL, никто ответа не дал. Все начинали про scale рассказывать, но он-то как раз не нужен. Если инет-магазин насчитывает не более 300 позиций и до 1000 заказов в месяц (а таких подавляющее большинство), то это все отлично реализуется на РСУБД с меньшими затратами, чем NoSQL. Все запросы типа «похожие» и «популярные» отлично делаются SQL, пока у вас не миллионы записей.
Ох как я задолбался повторять этот пример, но покажите как ваш подход работает на обычном интернет-магазине.
Структура простая:
1) Товары и категории
2) Заказы и позиции заказов
3) Покупатели
Задачи:
1) показывать каталог товаров по категориям
2) показывать историю заказов по пользователю
3) показывать «популярные» (с наибольшей суммой продаж за месяц) товары на сайте
4) показывать похожие товары — товары и той же категории, которые чаще всего встречаются в заказах вместе с указанным товаром
Нагрузка предполагается небольшая, нужно максимизировать скорость разработки и корректность данных.
Я читал этот отчет, он меня расстроил. Ниже 5-го места совершенно дохлые порталы. До 1000 пользователей, написанные двумя с половиной программистами, минимум полезного функционала. У российских Телекомов интранеты покруче.
Для end-to-end тестов инфраструктура чуть ли не важнее самих тестов. Это для Unit-тестов соотношение Code LOC/Test Loc может быть меньше 1, а для end-to-end этот показатель обычно больше 100. Но вот написать его в виде автоматически выполняемого сценария очень сложно, ибо много инфраструктурных вещей надо сделать: базы поднять, настройки развернуть, запросы нужные сделать, данные базы посмотреть. Готового Фреймворка для этого нет.
Статья хорошо описывает ситуацию для небольшой компании, которой сейлы MS не пропарили моск на тему SharePoint. 100% EPG заказчиков идут по другому сценарию.
А этим самым небольшим компаниями я бы рекомендовал сразу на Office 365 смотреть. Там и телефонный справочник сделать можно, и почта с конференц-связью есть.
DeskWorks хорош тем, что пытается закрыть в бесплатном Foundation фичи, которые есть в платных версиях. В остальном, как сказал автор статьи, готовых решений не бывает и все равно надо пилить, чтобы была польза. А пилить всегда проблема если кодом не владеешь, к в случае любой коробки.
Так всетаки, пихать риски в Гант или нет? Как учитывать вероятность риска? Какой финальный срок\стоимость называть с учетом риска? Какие действия предпринимать чтобы риски не оказывали влияния на проект?
Нет, чувак. Тебе платят за то, чтобы не приходилось договариваться больше одного раза. Ну перенесешь ты сроки раз, второй, третий. Потом окажется что проект убыточен и тебя уволят нафиг.
Суть в том, чтобы составить такой план, который за заранее определенно время позволит достингуть успеха с высокой долей вероятности.
В статье об этом написано, но, увы, на очень примитивном примере.
Скрытые работы на то и скрытые, что о них заранее неизвестно. А когда узнаешь — удлинять задачи уже поздно ибо по срокам пролетишь.
Тоже самое касается продуктивности сотрудников.
Если везде закладывать риски, то окажется что проект у вас более чем на 50% это риски.
Когда станет больше одного ресурса на задачу красивые картинки перестанут быть красивыми и очевидное не успевание станет неочевидным.
Диаграмма ганта молчит о других вещах:
1) Продуктивность сотрудников. Если задача А занимает 3 дня, а задача Б (того же типа) 5 дней, обе задачи делал Вася П. Это означает что задача Б больше задачи А или просто Вася занимался своими делами?
2) Скрытые работы. Чтобы построить диаграмму ганнта надо иметь полную структуру работ. Такая структура появляется в конце проекта. На этапе планирования и в ходе проекта часто появляются новые задачи.
Поэтому Гантт с задачами категорически не подходит для точного планирования и отслеживания проектов. Особенно сложных проектов.
Не забывайте что это первоначальное обучение, там надо минимизировать количество сущностей, которые надо держать в голове.
Типы вообще отдельная и сложная тема, которая при начальном обучении мешает. Любая попытка использовать статически типизированный язык натыкается на генерики\шаблоны при переходе к контейнерам. Я помню как у нас на первом курсе из 100 человек осилили array of record человек 10 всего. и это еще мягкий вариант обобщений.
Так что не нужно парить мозг сущностями, которые не нужны для достижения цели.
2) В jsfiddle есть JSLint, он быстро покажет где неправ.
3) Никакого менеджмента вообще. На начальном этапе важно понять как делать функции и комбинировать их в другие функции. Любое управление ресурсами — головная боль, мешающая достижению цели.
4) Haskell, F#,Scala, Lisp — за всю жизнь может ни разу не пригодиться. Старый паскаль — очень далек от современного delphi. Голый C — может пригодиться только в курсе системного программирования, в качестве языка для начала обучения не подойдет. Про эзотерику вроде brainfuck даже не говорю.
Излишняя сложность в начале убивает желание учиться. Типизация — дополнительная сложность и надо её избегать на начальном этапе.
1) Не требовать установки софта вообще
2) Иметь минимум «базовых» сущностей и никакого public-static-void-main-overhead
3) Иметь динамическую типизацию и\или мощный авто вывод типов
4) Никакого менеджмента ресурсов
5) Быть практическим (то есть на нем можно писать реальные программы)
Идеально подходит JavaScript. C++ категорически не подходит по всем параметрам, C# и java тоже. Python — нормальный вариант.
Далее чему учить: никакого ООП в первые полгода-год, объекты — наборы «ключ»-«значение» и все. Нельзя давать ни классы, ни прототипы.
Обязательно функции, рекурсию, лямбды и замыкания. Алгоритмы на массивах, матрицах, деревьях, графах.
Уже потом можно грузить компиляцией, модульностью, ООП, управлением ресурсами. Лучше всего на C#.
А вот на третий год уже выносить мозг C++ с шаблонами. А также можно параллельным\асинхронными программированием.
А если вы начинаете проект с NoSQL, особенно Document DB, то как вы заранее узнаете какую схему создавать
Вообще созданием правильной схемы для Document DB, как Mongo — крайне нетривиальная задача. Даже отсутствие однозначного ответа в случае простого интернет-магазина это очень хорошо показывает.
А в статье рекомендуется начинать в том числе с NoSQL, со всеми вытекающими.
И зачем в миллиардных хранилищах NoSQL?
например маленький интернет-магазин можно масштабировать в сотни и даже тысячи раз если прикрутить кеш и полнотекстовый индекс на Lucene.
Я этот вопрос задавал многим, кто пропагандирует использование NoSQL, никто ответа не дал. Все начинали про scale рассказывать, но он-то как раз не нужен. Если инет-магазин насчитывает не более 300 позиций и до 1000 заказов в месяц (а таких подавляющее большинство), то это все отлично реализуется на РСУБД с меньшими затратами, чем NoSQL. Все запросы типа «похожие» и «популярные» отлично делаются SQL, пока у вас не миллионы записей.
А ели же вам нужно сильно масштабировать, то просто используйте кеш. Полнотекстовый индекс кстати тоже является кешом в некотором роде и довольно легко прикручивается к РСУБД.
Подробно тут: www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Структура простая:
1) Товары и категории
2) Заказы и позиции заказов
3) Покупатели
Задачи:
1) показывать каталог товаров по категориям
2) показывать историю заказов по пользователю
3) показывать «популярные» (с наибольшей суммой продаж за месяц) товары на сайте
4) показывать похожие товары — товары и той же категории, которые чаще всего встречаются в заказах вместе с указанным товаром
Нагрузка предполагается небольшая, нужно максимизировать скорость разработки и корректность данных.
А статья предполагает что будет через год-два, учитывая темпы создания интранет-порталов.
Магии нет.
А этим самым небольшим компаниями я бы рекомендовал сразу на Office 365 смотреть. Там и телефонный справочник сделать можно, и почта с конференц-связью есть.
Суть в том, чтобы составить такой план, который за заранее определенно время позволит достингуть успеха с высокой долей вероятности.
В статье об этом написано, но, увы, на очень примитивном примере.
Тоже самое касается продуктивности сотрудников.
Если везде закладывать риски, то окажется что проект у вас более чем на 50% это риски.
Диаграмма ганта молчит о других вещах:
1) Продуктивность сотрудников. Если задача А занимает 3 дня, а задача Б (того же типа) 5 дней, обе задачи делал Вася П. Это означает что задача Б больше задачи А или просто Вася занимался своими делами?
2) Скрытые работы. Чтобы построить диаграмму ганнта надо иметь полную структуру работ. Такая структура появляется в конце проекта. На этапе планирования и в ходе проекта часто появляются новые задачи.
Поэтому Гантт с задачами категорически не подходит для точного планирования и отслеживания проектов. Особенно сложных проектов.