<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="Naboo" />
<Option pch_mode="2" />
<Option compiler="gcc" />
<Build>
<Target title="Release">
<Option output="Naboo" prefix_auto="1" extension_auto="1" />
<Option object_output="obj\" />
<Option type="1" />
<Option compiler="gcc" />
<Compiler>
<Add option="-O2" />
</Compiler>
<Linker>
<Add option="-s" />
</Linker>
</Target>
</Build>
<Compiler>
<Add option="-Wall" />
<Add option="-fexceptions" />
</Compiler>
<Unit filename="AddressManager\Address.cpp" />
<Unit filename="AddressManager\Address.h" />
<Unit filename="AddressManager\AddressManager.cpp" />
<Unit filename="AddressManager\AddressManager.h" />
<Unit filename="CommandAB.cpp" />
<Unit filename="CommandAB.h" />
<Unit filename="DrawMenu.cpp" />
<Unit filename="DrawMenu.h" />
<Unit filename="FileManager\FileManager.cpp" />
<Unit filename="FileManager\FileManager.h" />
<Unit filename="FileManager\FileManagerMaker.cpp" />
<Unit filename="FileManager\FileManagerMaker.h" />
<Unit filename="NabooBranch.cpp" />
<Extensions>
<code_completion />
<debugger />
</Extensions>
</Project>
</CodeBlocks_project_file>
Форумное образование
Мысли, которые хочу изложить навеяны темой "Поделитесь опытом".
Давно уже меня огорчает одна мысль, что программист-самоучка с помощью форумов может развиться только до определенного уровня, обычно недостаточного для профессиональной работы. То есть, с помощью форумов можно разобраться, как грамотно писать маленькие программы, как использовать какую-то технологию, но знания о грамотной разработке больших программ получить затруднительно.
Ну, возможно, если хорошо разобраться в паттернах, то можно пытаться говорить, о том, какие из них надо применять в той или иной программе. Но так могут быть упущены разные мелочи в коде, которые важны именно в больших проектах.
Кроме того, так не появится опыт работы в команде и т.п.
Примерно то же можно сказать и про обучение по книгам – не всегда поймешь, какую надо читать и для чего. Кроме того, идеи, изложенные в книгах не будут правильно поняты, если нет соответствующей практики.
---
Возможные альтернативы для развития, которые я вижу:
1. Устроиться на работу, где есть команда грамотных программистов, разрабатывающих большие проекты. Это, наверно, наиболее эффективный способ, но не всегда подходящий. Например, если уже есть хорошая работа (по другим параметрам подходящая), или нет подходящей фирмы в родном городе, или там не нужен программист такого уровня.
2. Копаться в исходниках крупных проектов с открытым исходным кодом. Желательно, чтобы эти проекты были бы аналогами того, что создает программист самоучка. Это непредсказуемый путь, так как не отличишь ошибочное решение от правильного, и поспорить об этом не с кем. Да и "переварить" кучу кода бывает тяжело.
3. Участвовать в развитии существующих проектах с открытым кодом. Если есть контакт с другими авторами, то, наверное, это хороший путь для развития. Недостаток тут в том, что проект уже готов, и многие этапы его развития останутся не прочувствованными. Хотя может это и не требуется для большинства программистов.
4. Создать собственный учебный проект с открытым кодом, рассчитанный на команду. Это хороший путь, но наиболее фантастический. Тут и идея интересная нужна, и команда самоучек с похожим опытом, и организатор, и какие-нибудь опытные кураторы... Вроде бы и самоучкам будет опыт, и кураторы будут знать кто на что способен, если надо будет найти программиста для работы. Но вот организовать такое дело обычно невозможно.
---
Вопросы. Заблуждаюсь ли я относительно возможностей форума? Есть ли еще какие-нибудь альтернативы для развития?
Извините, за большой текст.
Давно уже меня огорчает одна мысль, что программист-самоучка с помощью форумов может развиться только до определенного уровня, обычно недостаточного для профессиональной работы. То есть, с помощью форумов можно разобраться, как грамотно писать маленькие программы, как использовать какую-то технологию, но знания о грамотной разработке больших программ получить затруднительно.
Ну, возможно, если хорошо разобраться в паттернах, то можно пытаться говорить, о том, какие из них надо применять в той или иной программе. Но так могут быть упущены разные мелочи в коде, которые важны именно в больших проектах.
Кроме того, так не появится опыт работы в команде и т.п.
Примерно то же можно сказать и про обучение по книгам – не всегда поймешь, какую надо читать и для чего. Кроме того, идеи, изложенные в книгах не будут правильно поняты, если нет соответствующей практики.
---
Возможные альтернативы для развития, которые я вижу:
1. Устроиться на работу, где есть команда грамотных программистов, разрабатывающих большие проекты. Это, наверно, наиболее эффективный способ, но не всегда подходящий. Например, если уже есть хорошая работа (по другим параметрам подходящая), или нет подходящей фирмы в родном городе, или там не нужен программист такого уровня.
2. Копаться в исходниках крупных проектов с открытым исходным кодом. Желательно, чтобы эти проекты были бы аналогами того, что создает программист самоучка. Это непредсказуемый путь, так как не отличишь ошибочное решение от правильного, и поспорить об этом не с кем. Да и "переварить" кучу кода бывает тяжело.
3. Участвовать в развитии существующих проектах с открытым кодом. Если есть контакт с другими авторами, то, наверное, это хороший путь для развития. Недостаток тут в том, что проект уже готов, и многие этапы его развития останутся не прочувствованными. Хотя может это и не требуется для большинства программистов.
4. Создать собственный учебный проект с открытым кодом, рассчитанный на команду. Это хороший путь, но наиболее фантастический. Тут и идея интересная нужна, и команда самоучек с похожим опытом, и организатор, и какие-нибудь опытные кураторы... Вроде бы и самоучкам будет опыт, и кураторы будут знать кто на что способен, если надо будет найти программиста для работы. Но вот организовать такое дело обычно невозможно.
---
Вопросы. Заблуждаюсь ли я относительно возможностей форума? Есть ли еще какие-нибудь альтернативы для развития?
Извините, за большой текст.
замороженный, не замороженный. пишете то че хоть? (и правда лучше бы за свн/файлообменник взялись, социальная польза...)))
А пишем мы, как ни странно, то, с чем каждый из нас по отдельности справился бы куда быстрее :D
Подробности - у Когрома в подписи есть ссылка на социальную группу... Захады, дарагой, гостэм будиш!
Подробности - у Когрома в подписи есть ссылка на социальную группу... Захады, дарагой, гостэм будиш!
Цитата: Washington
замороженный, не замороженный. пишете то че хоть? (и правда лучше бы за свн/файлообменник взялись, социальная польза...)))
Пишем адресную книгу с самодельной базой данных. Задачу такую выбрали потому, что было почти готовое ТЗ + начало проектирования.
Появилась следующая идея: дубликовать в соц. группе выдержки из переговоров по аське. Таким образом, все участники будут видеть, какие идеи есть у других напарников. Чтобы никого не обидеть буду публиковать только свои реплики.
Размещаю это сообщение здесь, потому как подозреваю, что в соц. группу мало кто заглядывает, даже сами участники :)
Размещаю это сообщение здесь, потому как подозреваю, что в соц. группу мало кто заглядывает, даже сами участники :)
Выкладываю свою часть с файлами Нездешнего и Кogroma. Жду комментариев (надеюсь, мне не год придётся ждать:o за мою медлительность в ответ).
Ребята, мой вам хороший совет. Выкладывая что либо - делайте обязательно make-файл. Понимаете - если я чтото например выкладываю из рабочих проектов - я не делаю это иногда просто потому что выполняю одновременно немало проектов банально нет времени - если вы уж позиционируете себя как открытая группа - делайте это. Это не снобизм - для open sours это делается именно так. Иногда бывает возможность потратить время на "догадаться как это работает". Чаще не очень. Учитывайте что не все работают в студии - Исключайте стандартные фишки конкретных сред разработки если это не требуется. Типа StdAfx.h или vcl.h - и возможно вам ответят быстрее.
Вас трое - просто определите кто делает сборку - и пусть он занимается только этим. А остальным пусть занимается по силам. И как вариант этот человек должен отвечать за отслеживание версии.
Цитата: kot_
Ребята, мой вам хороший совет. Выкладывая что либо - делайте обязательно make-файл.
В общем, можно сделать (найти какой-нибудь) парсер из проекта Code::Blocks, то есть той IDE, которой я пользуюсь. У него структура типа:
Код:
Так что сконвертировать наверно можно, если потребуется.
Цитата: kot_
Учитывайте что не все работают в студии - Исключайте стандартные фишки конкретных сред разработки если это не требуется. Типа StdAfx.h или vcl.h - и возможно вам ответят быстрее.
У нас двое пишут не в студии. StdAfx.h - это добавка третьего автора :)
В принципе, если пересадить третьего автора в Code::Blocks (с MinGW), то этот вопрос отпадет сам собой.
Ну так запретите третьему автору добавлять stdafx.h
Цитата: Green
Ну так запретите третьему автору добавлять stdafx.h
Код третьего автора впервые был выложен вчера вечером. До этого голова на тему включения таких файлов не болела.
В принципе, возможно, и лучше, что третий автор работает с другими инструментами - код будет универсальнее.
Оффтоп: однако перенос темы сделал из меня эксперта. Весело :)
Цитата: z0rch
Но я не знаю азов! Поэтому я для себя определился, что хочу получить специальность "Программист". И надеюсь, что в ВУЗе мне расскажут и объяснят многие детали программирования....
Вуз штука полезная в любом случае. Не важно даже в принципе, какая у него специализация. А зацикливаться на том, что "я пойду на программера" не стоит. Люди которые учаться на программистов даже на старших курсах порой такое выдают. Я тоже когда-то серьезно думал о том, а не пойти ли на второе высшее (первое у меня совсем не программерское), но вот посмотрев на такие безобразия и наслущавшийсь понят, что не нужно оно мне. Я и так смогу освоить любую технологию которая мне будет интересна.
И потом не стоит обольщаться. Патерны... красивый код... это понятия о которых не имеют представление многие люди которые занимаются програмингом. Ведь кроме каких то интересных задач существует масса рутины. Я бы даже сказал больше, как и на любом производстве большая часть работы тут именно рутина. К примеру мало каким конторам понадобиться система которая может выдерживать огромные нагрузки, а тем пачем еще меньше тех, кто сможет оплатить разработку такой системы. Но очень много тех, у кого в день на сайте будет не больше десятка посетителей и их вполне устроит любой стандартный движок какой бы он кривой не был.
Образования нет. Есть самообразование. В вуз лишь задает вектор движения, представляет ресурсы в виде тех же книг которым сам бы искал в течении нескольких лет. Сам преподавал и могу точно сказать. Кто хочет учиться, тот учиться.
Цитата: Kogrom
То есть, довольно трудно дать советы по проектированию больших программ, и т.п.
Если программа действительно большая, то ни кто её "не проектирует" хотя бы потому, что удержать в голове все аспекты системы человек физически не способен. Тем более в таких проекта не спещивают кодирование и проектирование. Поэтому, какбэ, я сказал, что проектирование в больших системах может быть от программирования быть на столько же далеко, на сколько программирование далеко от администрирования или сборки компа. И есть даже люди, которые собственно занимаются именно проектированием. Архитектор, который проектирует небоскреб сам лопатой на стройке не машет, более того, он даже в прорабах не ходит ;)
Так зачем запрещать? Я удалила и всё. Почти сразу же отредактировала.
Только мой компонент, доработанный с учетом предложений от Oltzowwa
Я изучаю то, что мы натворили и думаю по поводу тестирования. Пока определенной ясности нет, но чтобы было видно, чем я занят, в социальной группе сделал сообщения с замечаниями по поводу компонента Контроллера и с мыслями по поводу тестирования.
Предложения по развитию Учебного Проекта
1. На данный момент почти уже есть некоторая основа, с которой можно работать. То есть можно уже можно пытаться делать рефакторинг. Чтобы участники не пугались заморского слова, рекомендую прочесть хотя бы первую главу книги Мартина Фаулера про рефакторинг. В хорошем качестве эта глава доступна тут.
В этой главе приведен пример, как из корявого кода сделать что-то приличное с помощью определенных приемов.
2. Есть идея проводить рефакторинги в парах. То есть над изменением кода каждого компонента будут работать 2 автора: новый автор будет менять код, старый автор будет подсказывать, советовать, критиковать. Например, Нездешний может переделывать код Менеджера Файла, Oltzowwa будет править код Менеджера Адреса, а кто-то из новых участников будет менять код Контроллера. При этом надо не переписывать код с нуля, а именно проводить рефакторинг – менять структуру маленькими шажками.
3. Для проведения рефакторинга нужна какая-то система для проведения тестов (о ней я уже писал в соц. группе). Эту систему буду делать я, поглядывая в умные книжки и изучая чужие свободно доступные исходники. При написании этой системы мне, возможно, потребуется помощь некоторых участников. Когда такая система будет готова, рефакторинг можно будет проводить смелее.
4. Участник проекта crot26rus взялся быть инструментальщиком и создал проект на Google Code. Думаю, участникам необходимо ознакомиться с возможностями этого сервиса.
1. На данный момент почти уже есть некоторая основа, с которой можно работать. То есть можно уже можно пытаться делать рефакторинг. Чтобы участники не пугались заморского слова, рекомендую прочесть хотя бы первую главу книги Мартина Фаулера про рефакторинг. В хорошем качестве эта глава доступна тут.
В этой главе приведен пример, как из корявого кода сделать что-то приличное с помощью определенных приемов.
2. Есть идея проводить рефакторинги в парах. То есть над изменением кода каждого компонента будут работать 2 автора: новый автор будет менять код, старый автор будет подсказывать, советовать, критиковать. Например, Нездешний может переделывать код Менеджера Файла, Oltzowwa будет править код Менеджера Адреса, а кто-то из новых участников будет менять код Контроллера. При этом надо не переписывать код с нуля, а именно проводить рефакторинг – менять структуру маленькими шажками.
3. Для проведения рефакторинга нужна какая-то система для проведения тестов (о ней я уже писал в соц. группе). Эту систему буду делать я, поглядывая в умные книжки и изучая чужие свободно доступные исходники. При написании этой системы мне, возможно, потребуется помощь некоторых участников. Когда такая система будет готова, рефакторинг можно будет проводить смелее.
4. Участник проекта crot26rus взялся быть инструментальщиком и создал проект на Google Code. Думаю, участникам необходимо ознакомиться с возможностями этого сервиса.
А ИМХО форумы и книги вполне друг-друга дополняют.
Учиться надо по книгам, а по каким всегда можно узнать на форуме: почти везде есть список проверенных хороших книг по языкам и пр. вот например(). По моему мнению это вполне достаточно чтоб при небольшой доли усердия вполне неплохо уметь печатать. Ну и конечно опыта работы это не заменяет все))) Особо его не заменяеют вариант 2, так как копаться сложней чем делать самому. А вот 4ый вариант вполне может научить что-то делать, если доводить дела до конца конечно.
Учиться надо по книгам, а по каким всегда можно узнать на форуме: почти везде есть список проверенных хороших книг по языкам и пр. вот например(). По моему мнению это вполне достаточно чтоб при небольшой доли усердия вполне неплохо уметь печатать. Ну и конечно опыта работы это не заменяет все))) Особо его не заменяеют вариант 2, так как копаться сложней чем делать самому. А вот 4ый вариант вполне может научить что-то делать, если доводить дела до конца конечно.
В общем, может 4-й путь и хорош, но пока получается что-то типа обучения плаванью путем сброса ученика с моста на глубину. Только в нашем случае сбросили несколько учеников в одну реку. Ну и сочувствующие подсказывают, что есть книги, в которых написано, как правильно грести.
Думаю, более правильная методика, когда ученик все-таки сочетает такой подход с тренировками на берегу, на небольшой глубине. То есть, хорошо бы проводить тренинги, посвященные определенной методике программирования. Но как их организовать я пока не придумал. Какие-то эксперименты я делал тут:
http://forum.codenet.ru/showthread.php?t=54098
но это был разгровор с собой, а значит я опять мог допустить разные ошибки. По науке, такие тренинги надо проводить в парах, или в группах. И под присмотром наставников (но это в идеале).
Думаю, более правильная методика, когда ученик все-таки сочетает такой подход с тренировками на берегу, на небольшой глубине. То есть, хорошо бы проводить тренинги, посвященные определенной методике программирования. Но как их организовать я пока не придумал. Какие-то эксперименты я делал тут:
http://forum.codenet.ru/showthread.php?t=54098
но это был разгровор с собой, а значит я опять мог допустить разные ошибки. По науке, такие тренинги надо проводить в парах, или в группах. И под присмотром наставников (но это в идеале).
Цитата: Kogrom
То есть, хорошо бы проводить тренинги, посвященные определенной методике программирования. Но как их организовать я пока не придумал.
Подобный тренинг организовать можно - но проводить его имеет смысл примерно в таком формате:
1. Даются вводные и сроки выполнения, количество участников ограничено.
2. До срока участники могут посылать друг другу только сообщения.
3. По завершении проводится разбор кода с иллюстрацией ошибок и "правильных" решений.
Но во первых это требует определенного программного решения. Я сейчас над таким работаю например.
Во вторых - ИМХО это должен быть платный сервис, так как объем работы для тех кто будет принимать участие, анализировать и пр. весьма не маленький.
Цитата: kot_
Подобный тренинг организовать можно - но проводить его имеет смысл примерно в таком формате:
1. Даются вводные и сроки выполнения, количество участников ограничено.
2. До срока участники могут посылать друг другу только сообщения.
3. По завершении проводится разбор кода с иллюстрацией ошибок и "правильных" решений.
1. Даются вводные и сроки выполнения, количество участников ограничено.
2. До срока участники могут посылать друг другу только сообщения.
3. По завершении проводится разбор кода с иллюстрацией ошибок и "правильных" решений.
Ну, возможно, и такой подход верен. То есть, это принцип домашней работы в школе, принцип контрольной.
Я думал о другом, более открытом подходе, где проект делается одновременно несколькими участниками по небольшим итерациям. То есть может быть что-то типа турнира. Шажок от одного участника, шажок от другого.
Цитата: kot_
Во вторых - ИМХО это должен быть платный сервис, так как объем работы для тех кто будет принимать участие, анализировать и пр. весьма не маленький.
Я не буду учить вас бизнесу - в этом не силен. Однако, мне кажется, что ваш подход грубоват. Думаю, вначале, нужно привлечь клиента к ресурсу бесплатно, потом можете размещать сторонюю рекламу на сайте, потом привлекать за плату корпоративного клиента.
Однако, повторюсь, что в этом я не силен. Меня больше волнует мое обучение.
Цитата: Kogrom
Я не буду учить вас бизнесу - в этом не силен. Однако, мне кажется, что ваш подход грубоват. Думаю, вначале, нужно привлечь клиента к ресурсу бесплатно, потом можете размещать сторонюю рекламу на сайте, потом привлекать за плату корпоративного клиента.
Я объясню почему говорю о платном. Привлечь бесплатно - по сути вы говорите - "а давайте вы нас бесплатно поучите". Объясните что получат в таком случае те, кто вас обучает? И чего вы сразу съехали на корпоративного клиента? Вам нужны знания? Так почему вы ждете что ктото будет платить за вас? Для того что бы иметь соотвествующий уровень, я например работаю с литературой, которую мне никто не дает бесплатно :), трачу свое время, оплачиваю интернет и пр. И заметьте - вам не нужно никуда ехать каждый день, просыпаться на занятия и т.д. Включил компьютер - зашел в интернет - выполнил задания, получил рекомендации. Или вы может быть регулярно делаете покупки по интернету? Скажите - вот на данном ресурсе рекламы есть немного - вы что то приобрели/купили/потратили? Вот вам ответ. И от того - доход ведь не с показов получают, доход за переходы, а зачастую и за эффективные переходы. Много денег приносит реклама ресурсу?
Корпоративный клиент - вот вы обижаетесь зачастую (я говорю не конкретно о вас, а о посетителях вообще) что я часто матом крою новичков, которые задают один и тот же вопрос, который задавали до них. Как вы думаете - почему? Потому что, если на ресурсе пережевываются темы "А как мне присвоить кнопке название" - этот ресурс нах никому не нужен. Тем более корпоративным клиентам. А уровень коденета пока остается на "как кнопке..." Ок. 20-30 человек активных участников - а когда человеку надоедает отвечать раз за разом на вопрос - "как мне зделать то не знаю что" - он с ресурса уходит. Вот так. И я уже поднимал вопрос о введении "платных" ответов. И я думаю что это едиственный выход.
Цитата: kot_
Я объясню почему говорю о платном. Привлечь бесплатно - по сути вы говорите - "а давайте вы нас бесплатно поучите". Объясните что получат в таком случае те, кто вас обучает? И чего вы сразу съехали на корпоративного клиента? Вам нужны знания? Так почему вы ждете что ктото будет платить за вас? Для того что бы иметь соотвествующий уровень, я например работаю с литературой, которую мне никто не дает бесплатно :), трачу свое время, оплачиваю интернет и пр.
Я не говорю: "а давайте вы нас бесплатно поучите". У меня тоже куча бумажных и электронных книг по программированию, многие из которых я даже прочитал. За Интернет мне приходится переплачивать, но я не отказываюсь от него. Если надо платить, то я буду платить.
Дело в другом. Но пока я не смогу сформулировать лучше, чем сказал это в предыдущем сообщении.
На счет "А как мне присвоить кнопке название": я приложил некоторые усилия и сейчас прикладываю, чтобы это было не так, пытаюсь что-то придумать интересное, полезное.
В общем, что тут спорить - делать надо. Создавайте свой ресурс, а там посмотрим, может на самом деле получется очень полезная вещь, за которую и заплатить не жалко.
И да. Я пользовался рекламой от Яндекса (раньше на этом сайте была такая), которая была созвучна моим поисковым запросам.
Пока добавлю еще одну деталь в головоломку, которую я пытаюсь решить. То есть как сделать, чтобы было и полезно и интересно.
На одном ресурсе я нашел следующую затею: битвы участников. Перед двумя-тремя участниками ставится задача и они ее решают пошагово. При этом есть регламент - время на ход и примерный объем работ на шаг. Через определенное число шагов судьи решают - кто победил. При чем делают это по нескольким категориям. Подробнее тут.
Если кто пойдет по ссылке, возможно, он будет недоумевать, зачем я его отправил на сайт про комиксы. Но, не важно, о чем сайт - важна идея.
Понятно, что в коде по другому. Тут нужны другие подходы для определения трудозатрат на ход и т.д.
В принципе, на сайте уже было что-то такое - решали всякие задачки всем форумом. Но там надо было придумывать каждому свое решение, а тут дополнять или переделывать решение соперника.
На одном ресурсе я нашел следующую затею: битвы участников. Перед двумя-тремя участниками ставится задача и они ее решают пошагово. При этом есть регламент - время на ход и примерный объем работ на шаг. Через определенное число шагов судьи решают - кто победил. При чем делают это по нескольким категориям. Подробнее тут.
Если кто пойдет по ссылке, возможно, он будет недоумевать, зачем я его отправил на сайт про комиксы. Но, не важно, о чем сайт - важна идея.
Понятно, что в коде по другому. Тут нужны другие подходы для определения трудозатрат на ход и т.д.
В принципе, на сайте уже было что-то такое - решали всякие задачки всем форумом. Но там надо было придумывать каждому свое решение, а тут дополнять или переделывать решение соперника.
Поразмыслив, я понял, что формат проекта, неудачно выбранный язык и непродуманная организация не способствовали изучению шаблонов проектирования, рефакторинга, тестирования и т.д.
Минусы формата: каждый закрыто делал свою большую часть, делая большие шаги. Таким образом, сложно было предотвратить ошибки разработчика.
Минусы организации: не было системы стимулов, системы замены разработчика, из-за чего проект тормозился.
Есть задумка вместо одного большого проекта делать несколько маленьких, в виде тренингов. То есть, берется определенный простой проект и делается прямо в теме маленькими шажками. При этом стимулом будет желание разработчика поправить несовершенство предыдущего маленького шажка. Но при этом код должен быть сравнительно компактным, чтобы облегчить чтение другим участникам.
Однако, моей фантазии не хватает, чтобы придумать много маленьких, но сравнительно интересных проектиков для консоли. Лучше использовать проекты с GUI.
Таким образом, предыдущие 2 абзаца показывают, почему C++ не очень подходит для тренингов. Среди инструментов, которые я проанализировал тут лучше всего подходит wxPython. Но это обсуждается.
Итак, тренинги можно проводить в виде мастер-классов, когда весь проект делает один ученик, а другие комментируют, советуют и в виде битв, когда проект делают 2 участника по шагам, а специальное жюри оценивает их работу.
Для проектов можно взять известные приложения: калькулятор, растровый редактор, векторный редактор, электронную таблицу, игры типа сапера и т.п.
Кто что думает по поводу этих предложений?
Минусы формата: каждый закрыто делал свою большую часть, делая большие шаги. Таким образом, сложно было предотвратить ошибки разработчика.
Минусы организации: не было системы стимулов, системы замены разработчика, из-за чего проект тормозился.
Есть задумка вместо одного большого проекта делать несколько маленьких, в виде тренингов. То есть, берется определенный простой проект и делается прямо в теме маленькими шажками. При этом стимулом будет желание разработчика поправить несовершенство предыдущего маленького шажка. Но при этом код должен быть сравнительно компактным, чтобы облегчить чтение другим участникам.
Однако, моей фантазии не хватает, чтобы придумать много маленьких, но сравнительно интересных проектиков для консоли. Лучше использовать проекты с GUI.
Таким образом, предыдущие 2 абзаца показывают, почему C++ не очень подходит для тренингов. Среди инструментов, которые я проанализировал тут лучше всего подходит wxPython. Но это обсуждается.
Итак, тренинги можно проводить в виде мастер-классов, когда весь проект делает один ученик, а другие комментируют, советуют и в виде битв, когда проект делают 2 участника по шагам, а специальное жюри оценивает их работу.
Для проектов можно взять известные приложения: калькулятор, растровый редактор, векторный редактор, электронную таблицу, игры типа сапера и т.п.
Кто что думает по поводу этих предложений?
Мне идея очень нравится, особенно если подходить к проблемам с "неизученных" сторон, например, с точки зрения ФП. Питон в качестве языка мне нравится, также очень привлекательно выглядит в этом плане nemerle (в большей степени из-за продвижения его сами знаете кем и тому что я понял из статей на RSDN).
Сейчас у меня совершеннейшая запарка, и пока не понятно, когда все это кончится :( (надеюсь, что в конце следующей недели) но как только разгружусь буду рад присоединиться! В любом случае даже читать такие темы, мне кажется, будет очень интересно!
Сейчас у меня совершеннейшая запарка, и пока не понятно, когда все это кончится :( (надеюсь, что в конце следующей недели) но как только разгружусь буду рад присоединиться! В любом случае даже читать такие темы, мне кажется, будет очень интересно!
Мне Питон кроме всего прочего нравится некоторой цельностью и простотой получения дистрибутива - зашел на официальный сайт, скачал инстальник, установил и работай.
Правда, IDE по умолчанию не очень удобная и у меня она иногда вылетает при создании приложения с GUI. Поэтому я использую редактор drPython. В принципе, еще удобнее редактор от Netbeans, но он грузится долго и требует файла проекта (хотя может я чего-то недопонял).
Правда, IDE по умолчанию не очень удобная и у меня она иногда вылетает при создании приложения с GUI. Поэтому я использую редактор drPython. В принципе, еще удобнее редактор от Netbeans, но он грузится долго и требует файла проекта (хотя может я чего-то недопонял).
Чего то не понял я, чем тут плох C++.
Как известно плохому танцору мешают... а программисту - плюсы. :)
Просьба не принимать близко к сердцу. :)
Язык в вашей задаче (изучение шаблонов проектирования, рефакторинга, тестирования и т.д.) совсем не при чем. Здесь подойдет любой ООЯП.
А с питоном не обольщайтесь, наплачитесь ещё :)
Как известно плохому танцору мешают... а программисту - плюсы. :)
Просьба не принимать близко к сердцу. :)
Язык в вашей задаче (изучение шаблонов проектирования, рефакторинга, тестирования и т.д.) совсем не при чем. Здесь подойдет любой ООЯП.
А с питоном не обольщайтесь, наплачитесь ещё :)
Цитата: Green
Чего то не понял я, чем тут плох C++. Как известно плохому танцору мешают... а программисту - плюсы. :)
А с питоном не обольщайтесь, наплачитесь ещё :)
А с питоном не обольщайтесь, наплачитесь ещё :)
C++ хорош для "настоящих" приложений. Там, где нужна эффективность, надежность (хотя с этим некоторые будут спорить :) ). Но этот язык не удобен для иллюстрации общих программистских приемов в формате форума. Даже простая конструкция расползается на 150 строчек. Может и Питон тут не поможет, но мои небольшие опыты показали, что текст можно сократить раза в 2.
Далее. Для создания проекта прямо в теме (чтобы он был открыт) требуются небольшие проекты. На консоли много у меня придумать не получается, да и не интересно. То есть, хотелось бы с GUI что-то придумывать. Если использовать C++, то будет разброд - одним VCL подавай, другим WTL, третим QT... В этом смысле проще с Java или C#.
C# мне не нравится своими высокими требованиями: то установи, это установи. С Java лучше. Но Java многословна, на мой взгляд даже многословнее, чем C++.
Для Питона тоже много инструментов для создания GUI напридумывали, но так как тут пока почти никто Питон не использует, то, возможно, будет проще договориться об использовании wxPython.
Добавлено
Кроме того, как показал опыт, при использовании C++ люди увлекаются всякой ерундой и начинают изощряться в хитроумном использовании STL, в использовании всяких самодельных умных указателей, итераторов и т.д. В результате забывается, что же хотели сделать.
Цитата: Kogrom
C# мне не нравится своими высокими требованиями: то установи, это установи. С Java лучше. Но Java многословна, на мой взгляд даже многословнее, чем C++.
.NET3.5 как платформа, если еще не стоит (270Мб) и легковесная IDE SharpDevelop 3.0 (что-то около 10 МБ). SDK и MSDN - по желанию, IDE будет работать и без них. Для Java аналогичный подход.
Цитата: Kogrom
Правда, IDE по умолчанию не очень удобная и у меня она иногда вылетает при создании приложения с GUI. Поэтому я использую редактор drPython. В принципе, еще удобнее редактор от Netbeans, но он грузится долго и требует файла проекта (хотя может я чего-то недопонял).
Что значит - требует файл проекта? А как можно что-то делать без него? Где метаинформацию хранить? :)
Цитата: hardcase
.NET3.5 как платформа, если еще не стоит (270Мб) и легковесная IDE SharpDevelop 3.0 (что-то около 10 МБ). SDK и MSDN - по желанию, IDE будет работать и без них. Для Java аналогичный подход.
Вот у меня на работе трафик безлимитный, а дома интернет только через gprs. А хотелось бы, чтобы среда была и дома и на работе.
Когда я этот IDE SharpDevelop ставил, он долго ругался, что ему не нравится версия .NET моего компа. Скачал дистрибутив версии 3.5 да еще с сервис-паком. При установке он еще что-то докачивал. После установки SharpDevelop опять отказался устанавливаться - пришлось делать автоматическое обновление. Только после этого SharpDevelop соизволил установиться.
Из этого я сделал вывод, что для его установки без крупных докачек из Интернета не обойтись.
С NetBeans все было намного проще.
Хотя, есть еще и Visual C# Express Edition. Может, с ним проще.
Цитата: Zorkus
Где метаинформацию хранить? :)
А по русски? :)
Если проект маленький (например, я хочу провести какой-нибудь экперимент), то хватит одного открытого файла. Если проект большой, то конечно лучше бы где-то хранилась информация о файлах проекта, о том, какие из них были открыты и т.п.
Но NetBeans не предлагает выбора - только с проектом. Отдельный файл не запустится на выполнение. Хотя если проект уже создан, то можно работать и с одним файлом.
Кроме того, мне не нравится, что NetBeans запускается минуту. Для большого проекта это терпимо, для экспериментов - нет.
Цитата: Kogrom
Когда я этот IDE SharpDevelop ставил, он долго ругался, что ему не нравится версия .NET моего компа. Скачал дистрибутив версии 3.5 да еще с сервис-паком.
Оффлайновую версию?
Цитата: Kogrom
При установке он еще что-то докачивал.
Это известный баг - лечится ключом /lang:ENU, он, гад, за языковыми пакетами лезет в инет.
Цитата: Kogrom
После установки SharpDevelop опять отказался устанавливаться - пришлось делать автоматическое обновление.
Дык, окружение у всех разное, трудно сказать, подозреваю что там потребовалась какая-то версия Windows Installer.
Цитата: Kogrom
Хотя, есть еще и Visual C# Express Edition. Может, с ним проще.
С ним проще. Но он больше весит ;) и только C# поддерживает.
Цитата: Kogrom
Если проект маленький (например, я хочу провести какой-нибудь экперимент), то хватит одного открытого файла. Если проект большой, то конечно лучше бы где-то хранилась информация о файлах проекта, о том, какие из них были открыты и т.п.
Маленький эксперимент может перерасти в приличный проект, так что лучше сразу привыкнуть к сопутствующим файлам проекта. Кроме того SDK позволяют в консоли собирать их, в дотнете это так:
Код:
msbuild myapp.sln /t:Build /p:Configuration=Release
Цитата: hardcase
Оффлайновую версию?
Вроде да. Как раз чуть меньше 250 Мб.
Цитата: hardcase
Маленький эксперимент может перерасти в приличный проект, так что лучше сразу привыкнуть к сопутствующим файлам проекта.
Не о том я говорил. Например, я делаю большой проект и хочу внести в него какой-то новый объект или функцию. Для этого я могу создать отдельный маленький проект, в котором создам и испытаю функцию, а затем внесу ее в большой проект.
Для компилируемых языков и тут пригодится проект - можно будет настроить компилятор, библиотеки и т.п. Для Питона это не так актуально.
Но, в общем, это все мелочи.
А вообще Питон я продвигаю, так как у меня есть дополнительные мотивы: создание скриптов для Blender, ускоренное изучение wxWidgets, исследование возможности прототипирования. Ну и изучение основ ФП не повредит, возможно. Так что, стараюсь совместить полезное с полезным. Хотя, возможно, пытаюсь угнаться за несколькими зайцими.
Случайно наткнулся на группу, посмотрел код... В общем ребята - это просто ужос :)
Прежде чем заниматься рефакторингом, вам необходимо всетаки научится оформлять код, иначе его чтение превращается в кошмар не только для сторонних разработчиков, но и даже для членов вашей же группы. В больших командах разработчиков как правило, существует единый стандарт оформления кода. У вас же кто в лес, кто по дрова... Даже у одного человека зачастую меняются правила записи от класса к классу. Да что там классы - методы оформлены по разному :)
Прежде всего определитесь с правилом именования объектов программы (а то в одном месте используется camelNotation, в другом - венгерская, в третьем - воообще какие-то непонятные подчеркивания в конце полей класса). Далее определитесь как нужно оформлять методы - списки параметров, возвращаемых типов и т.д. (это как раз по тот случай, когда нужно определиться, ставить или нет (void) вместо ()) То же самое с классами. Следующий шаг - определитесь как оформлять собственно конструкции кода. Необходимо учесть следующие моменты: размер и количество отступов в коде и как их размещать; расстановка пробелов (пр.: if(!condition), if (!condition), if (! condition), и т.д.); расстановка операторных скобок (классический пример - скобки между if и else)... Думаю идея понятна ;)
Ну и на конец - комментарии. Они тоже должны оформляться в едином стиле. Например, возьмите за основу правила оформления комментариев для работы с Doxygen.
Сам код просмотрел бегло, но что сразу бросилось в глаза:
1. Почему-то все по разному используют неймспейсы - одни объявляют их использование в начале кода, другие - используют явное разрешение имен (хотя это, наверное, больше относиться к стилю).
2. Почему все пренебрегают typedef? Тот же vector<string> встречается в куче мест, почему бы не объявить его как typedef vector<string> StringVector и потом использовать везде?
3. Я понимаю, конечно, что проект учебный, но к хорошему нужно привыкать сразу. Итак, почему все пренебрегают const? Практически нигде не используются объявления const методов и параметров (хотя есть куча геттеров, где const так и проситься :)
4. Для кого придуманы списки инициализации в конструкторах?
Собственно, вот мой небольшой Code Review (который, по идее, должны проводить члены команды разработки для своих коллег).
PS: Если что, я просто мимо проходил...
Прежде чем заниматься рефакторингом, вам необходимо всетаки научится оформлять код, иначе его чтение превращается в кошмар не только для сторонних разработчиков, но и даже для членов вашей же группы. В больших командах разработчиков как правило, существует единый стандарт оформления кода. У вас же кто в лес, кто по дрова... Даже у одного человека зачастую меняются правила записи от класса к классу. Да что там классы - методы оформлены по разному :)
Прежде всего определитесь с правилом именования объектов программы (а то в одном месте используется camelNotation, в другом - венгерская, в третьем - воообще какие-то непонятные подчеркивания в конце полей класса). Далее определитесь как нужно оформлять методы - списки параметров, возвращаемых типов и т.д. (это как раз по тот случай, когда нужно определиться, ставить или нет (void) вместо ()) То же самое с классами. Следующий шаг - определитесь как оформлять собственно конструкции кода. Необходимо учесть следующие моменты: размер и количество отступов в коде и как их размещать; расстановка пробелов (пр.: if(!condition), if (!condition), if (! condition), и т.д.); расстановка операторных скобок (классический пример - скобки между if и else)... Думаю идея понятна ;)
Ну и на конец - комментарии. Они тоже должны оформляться в едином стиле. Например, возьмите за основу правила оформления комментариев для работы с Doxygen.
Сам код просмотрел бегло, но что сразу бросилось в глаза:
1. Почему-то все по разному используют неймспейсы - одни объявляют их использование в начале кода, другие - используют явное разрешение имен (хотя это, наверное, больше относиться к стилю).
2. Почему все пренебрегают typedef? Тот же vector<string> встречается в куче мест, почему бы не объявить его как typedef vector<string> StringVector и потом использовать везде?
3. Я понимаю, конечно, что проект учебный, но к хорошему нужно привыкать сразу. Итак, почему все пренебрегают const? Практически нигде не используются объявления const методов и параметров (хотя есть куча геттеров, где const так и проситься :)
4. Для кого придуманы списки инициализации в конструкторах?
Собственно, вот мой небольшой Code Review (который, по идее, должны проводить члены команды разработки для своих коллег).
PS: Если что, я просто мимо проходил...
Цитата: makbeth
У вас же кто в лес, кто по дрова... Даже у одного человека зачастую меняются правила записи от класса к классу. Да что там классы - методы оформлены по разному :)
Я старался придерживаться стиля, который рекомендован в книге "Стандарты программирования на С++. 101 правило и рекомендации" Александреску и Саттера.
Вроде бы даже я писал, что такой стиль предпочтителен. Однако, особо не настаивал, чтобы не распугать людей.
Цитата: makbeth
Необходимо учесть следующие моменты: размер и количество отступов в коде и как их размещать; расстановка пробелов (пр.: if(!condition), if (!condition), if (! condition), и т.д.); расстановка операторных скобок (классический пример - скобки между if и else)...
Я придерживался стиля Code::Blocks Source formatter plugin AStyle по умолчанию. Так проще.
Вроде бы очевидно. Однако, один участник даже IDE использовал другую, хотя я писал какую будем использовать. Что уж говорить о количестве пробелов.
Хотя, если серьезно, то про пробелы - это явный поклеп :)
Цитата: makbeth
Ну и на конец - комментарии. Они тоже должны оформляться в едином стиле. Например, возьмите за основу правила оформления комментариев для работы с Doxygen.
Это справедливо. Однако, за этими правилами и техническими штучками очень быстро забывается что мы вообще делаем. Кроме того, я стараюсь вообще не использовать комментарии. Могу развести холливар на эту тему :)
Цитата: makbeth
2. Почему все пренебрегают typedef? Тот же vector<string> встречается в куче мест, почему бы не объявить его как typedef vector<string> StringVector и потом использовать везде?
Я использовал typedef реже других. Но тоже использовал когда это давало явный выигрыш в количестве букв.
Приведенный пример ИМХО не очень удачен. Экономия не большая, зато непонятно, что скрывается за этим типом. Можно конечно сказать, что так проще будет поменять тип, но в этом случае придется также и название менять. Выигрыша нет.
Цитата: makbeth
4. Для кого придуманы списки инициализации в конструкторах?
А разве их не использовали? Вроде бы, всегда их использую.
Вообще, критика - это хорошо. Но тут вспоминается, пример, как хотели написать книгу, и ничего не написали ибо застряли на экономических, юридических и т.п. вопросах.
Тут хоть несколько страниц написали... Хотя и со скрипом (камень в сторону одного из участников).
Подпись: организатор проекта и автор модулей FileManager, NabooTest.
Цитата: Kogrom
Я старался придерживаться стиля, который рекомендован в книге "Стандарты программирования на С++. 101 правило и рекомендации" Александреску и Саттера.
Вроде бы даже я писал, что такой стиль предпочтителен. Однако, особо не настаивал, чтобы не распугать людей.
Я придерживался стиля Code::Blocks Source formatter plugin AStyle по умолчанию. Так проще.
Вроде бы очевидно. Однако, один участник даже IDE использовал другую, хотя я писал какую будем использовать. Что уж говорить о количестве пробелов.
Вроде бы даже я писал, что такой стиль предпочтителен. Однако, особо не настаивал, чтобы не распугать людей.
Я придерживался стиля Code::Blocks Source formatter plugin AStyle по умолчанию. Так проще.
Вроде бы очевидно. Однако, один участник даже IDE использовал другую, хотя я писал какую будем использовать. Что уж говорить о количестве пробелов.
Я смотрел код не конкретно твой или другого участника, а рассматривал в общем.
Цитата: Kogrom
Хотя, если серьезно, то про пробелы - это явный поклеп :)
Отнюдь. Опять же, я подходил с точки зрения удобства чтения (хотя у тебя как раз с этим все нормально).
Цитата: Kogrom
Могу развести холливар на эту тему :)
Не стоит, ведь это всего лишь мое мнение ;)
Цитата: Kogrom
Я использовал typedef реже других. Но тоже использовал когда это давало явный выигрыш в количестве букв.
Приведенный пример ИМХО не очень удачен. Экономия не большая, зато непонятно, что скрывается за этим типом. Можно конечно сказать, что так проще будет поменять тип, но в этом случае придется также и название менять. Выигрыша нет.
Приведенный пример ИМХО не очень удачен. Экономия не большая, зато непонятно, что скрывается за этим типом. Можно конечно сказать, что так проще будет поменять тип, но в этом случае придется также и название менять. Выигрыша нет.
А вот и нет. И дело даже не экономии. Ключевой момент здесь в том, что с помощью typedef можно (и ИМХО, нужно) определять тип для того, чтобы всегда можно было определить а, собственно, для чего он предназначен. Я намекаю на то, что название этого нового типа может очень много чего рассказать нам без всяких комментариев и превратить абстракный vector<string> в что-то более осмысленное...
Цитата: Kogrom
А разве их не использовали? Вроде бы, всегда их использую.
В параметрах - да. Но дело ведь не только в параметрах...
Пример:
Код:
void DoSomethingWithFileManager(const FileManager& fm)
{
StringVector address = fm.GetAddress(0); // Упс, а компилятор то ругатся изволит...
}
{
StringVector address = fm.GetAddress(0); // Упс, а компилятор то ругатся изволит...
}
Цитата: Kogrom
Вообще, критика - это хорошо.
Спасибо. Я старался :)
Цитата: makbeth
Я намекаю на то, что название этого нового типа может очень много чего рассказать нам без всяких комментариев и превратить абстракный vector<string> в что-то более осмысленное...
Ну вот - говорил же, что неудачный пример )))
Вместо vector<string> надо ввести имя типа AddressCell (то есть осмысленное), а не StringVector. Так понятнее.
Но вообще, тут главная проблема не в стиле и отступах. Самая большая проблема в организации. Пока занимался проектом приходили в голову разные мысли:
1. О системе "пинков": чтобы как-то будить кодера.
2. О перемене ответственности: чтобы можно было поручить кодеру маленькую задачу, если он не справляется с большой. Или вообще менять его деятельность - например, на аналитика, тестера и т.п.
3. О системе подключения новых участников. А то желающих было человек 6, а кодили только трое.
4. "О поднятии коврика". Была ситуация, когда один из кодеров очень долгое время ничего не мог выложить, оправдываясь тем, что создает мага-крутую структуру. Все мои уговоры делать маленькими шажками ни к чему не привели. И я не мог видеть, то ли участник ничего не делает, то ли творит на самом деле что-то грандиозное.
Но в этих делах у меня совсем нет никакого опыта.
Цитата: Kogrom
Ну вот - говорил же, что неудачный пример )))
Вместо vector<string> надо ввести имя типа AddressCell (то есть осмысленное), а не StringVector. Так понятнее.
Вместо vector<string> надо ввести имя типа AddressCell (то есть осмысленное), а не StringVector. Так понятнее.
Ну необязательно string<vector>... Почему бы не:
Код:
typedef uint32_t AddressID;
bool FileManager::GetAddress(AddressID id, StringVector &vs);
bool FileManager::GetAddress(AddressID id, StringVector &vs);
Цитата: Kogrom
1. О системе "пинков": чтобы как-то будить кодера.
Не взлетит. Кнут здесь не поможет. Нужен пряник (об этом, кстати, уже говорилось).
Цитата: Kogrom
2. О перемене ответственности: чтобы можно было поручить кодеру маленькую задачу, если он не справляется с большой. Или вообще менять его деятельность - например, на аналитика, тестера и т.п.
Устанавливаем приемлимые сроки выполнения. Если к сроку не готово, то простите... + см. ответ по п.1.
Цитата: Kogrom
3. О системе подключения новых участников. А то желающих было человек 6, а кодили только трое.
Опять таки, см. по п.1
Цитата: Kogrom
4. "О поднятии коврика". Была ситуация, когда один из кодеров очень долгое время ничего не мог выложить, оправдываясь тем, что создает мага-крутую структуру. Все мои уговоры делать маленькими шажками ни к чему не привели. И я не мог видеть, то ли участник ничего не делает, то ли творит на самом деле что-то грандиозное.
Здесь, наверное, поможет система контроля версий с ежедневным (ежечасным, еженедельным) обязательным check in'ом.
Цитата: Kogrom
Но в этих делах у меня совсем нет никакого опыта.
Ну с чего-то же надо начинать ;)
Цитата: makbeth
Ну необязательно string<vector>... Почему бы не:
Код:
typedef uint32_t AddressID;
bool FileManager::GetAddress(AddressID id, StringVector &vs);
bool FileManager::GetAddress(AddressID id, StringVector &vs);
Дело вкуса, но я думаю, что это перебор. Тут и в типе и в названии одна и таже информация. При этом теряется основная информация о типе.
Цитата: makbeth
Не взлетит. Кнут здесь не поможет. Нужен пряник (об этом, кстати, уже говорилось).
Хитрый программистский подход: дать ссылку в некуда : ("об этом, кстати, уже говорилось"), а затем ссылаться на эту ссылку :)
Пряник только такой вижу: желание научиться и наличие активного и опытного лидера. Ну, можно было бы нанять именитого лидера или даже нескольких лидеров. Но это тоже непонятно, как организовать, да и не очевидно, что поможет.
Цитата: Kogrom
Хитрый программистский подход: дать ссылку в некуда : ("об этом, кстати, уже говорилось"), а затем ссылаться на эту ссылку :)
Прошу прощения, я мел в виду вот этот пост в этой же теме: http://forum.codenet.ru/showpost.php?p=278581&postcount=70
Lerkin, как всегда, излишне резок, но в данном случае его коммент - в точку :)
Цитата: Kogrom
Пряник только такой вижу: желание научиться и наличие активного и опытного лидера. Ну, можно было бы нанять именитого лидера или даже нескольких лидеров. Но это тоже непонятно, как организовать, да и не очевидно, что поможет.
Ну не знаю... По моему, в первую очередь, нужен проект, который действительно заинтересует. Но заинтересует не результатом (т.е. насколько крутая софтина получится), а именно самим процессом проектирования и собственно разработки.