Возможные пути: зарегистрировать торговую марку (товарный знак), зарегистрировать патент (на изобретение), зарегистрировать авторское право (свидетельство).
Идеи (в чистом виде) в России не патентуются.
Смотря чего вы опасаетесь, того что конкуренты что-то сделают раньше вас? Так это только простимулирует Вашу активность :)
На Вашем месте я бы регистрировал авторское право, это позволит Вам официально считаться автором данной разработки и требовать за ее использование бабки.
Есть одно но, вам нужно что-то разработать для начала :)
Тут нужно быть осторожным: слой между приложением и базой играет значительную роль в производительности решения, знаю примеры, когда драйверы Java для Oracle съедали до 70% времени на отправку запроса или вызова хранимой процедуры.
если речь только о C++, socket и mysql, то наверно имеет смысл опираться на STL, для mysql используем mysql++, по поводу сокетов сложно что-то предложить, поскольку настолько простой механизм, что вряд ли для него нужны обертки, но можно попробовать boost (я не пробовал)
Большее количество итераций в Agile — это совсем не минус, а то ради чего это все было задумано.
Для сравнения, используя Waterfall на годовом проекте любая ошибка может стоить еще одного года разработки. Изменения, которые накопились в голове у заказчика, будут реализованы только в следующем году, иначе вы сорвете текущий план. Чтобы этого избежать как раз и нужно использовать большое количество итераций с целью повышения прозрачности разработки и получения сходящегося к цели процесса.
Полностью согласен с тем, что всему свое место. Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Что касается MSF, то не вижу тут какого-то открытия. Прежде чем что-то делать, нужно понять что, подготовиться, провести исследования. После того как выполнена основная работа, можно заняться вопросами маркетинга, продажами и т.п.
Тут важно то, что методология подбирается под проект, условия и команду, думаю это ни для кого не открытие.
Не соглашусь по теме Agile. Это семейство методологий не требует тупого написания кода вместо предварительного обдумывания. Суть в том, что команда сама решает когда ей нужно продумать что-то изначально подробно, а потом делать, а когда можно начинать делать, а возможные изменения вносить по ходу.
Вы как раз и работали в Agile, применяя то подход предварительного полного продумывания, то кодирования с учетом непрерывного изменения (аля XP).
Противопоставление Waterfall и Agile уместно на более высоком уровне, то есть на уровне разработки большой части системы, а не конкретной фичи.
1. совершенствоваться в своей области, или изучать другую, технические гуру нужны всегда.
2. заняться менеджментом/бизнесом.
3. заняться консалтингом и продавать свой предыдущий опыт, если он значителен.
ИМХО, среди российской публики нет большого смысла спрашивать о будущем на 5 лет вперед, мы пока всегда в отсающих, поинтересуйтесь об этом у западных коллег.
А если не знаете английского, то самое время его подучить :)
Как я понял предложенная методика никак не ограничивает и не обязывает использование или неиспользование парного программирования (ПП). В случае ПП можно назначать задачи на участников, а можно и не назначать.
Вам хочу посоветовать разобраться в терминах. Я говорил об опытных программистах, а не о профессионалах.
Тем более что виртуальные функции — это основа и не владеть ими не может не то чтобы профессионал, а любой кто хоть раз их пробовал использовать.
Вообще популяризация сложных механизмов всегда чревата :) Позвольте еще один совет:
Популяризуйте язык не путем описания его базовых возможностей, а путем решения обычных или классических задач с привлечением нетривиальных возможностей языка.
охотно верю, однако C++ это не тот инструмент, который можно понять «на пальцах».
с одной стороны: студентам нужно объяснять где найти материал (это классика инженерного образования) и требовать от них желания самостоятельно разобраться в вопросах.
с другой стороны: услышав некоторое поверхностное объяснение большинство на этом и остановится, а через год будет позиционировать себя C++ специалистами, тем самым дескредитировав Вас и Ваше учебное заведение.
Однако, оба мифа мифами не являются, а хорошо известны любому опытному C++ программисту, то есть в статье что-то новое могут открыть для себя программеры «случайно» пишущие на cpp или новички.
Может быть просто дать две ссылки на документацию по cpp и не тратить время на подготовку кода, написание статьи?
Идеи (в чистом виде) в России не патентуются.
Смотря чего вы опасаетесь, того что конкуренты что-то сделают раньше вас? Так это только простимулирует Вашу активность :)
На Вашем месте я бы регистрировал авторское право, это позволит Вам официально считаться автором данной разработки и требовать за ее использование бабки.
Есть одно но, вам нужно что-то разработать для начала :)
Для сравнения, используя Waterfall на годовом проекте любая ошибка может стоить еще одного года разработки. Изменения, которые накопились в голове у заказчика, будут реализованы только в следующем году, иначе вы сорвете текущий план. Чтобы этого избежать как раз и нужно использовать большое количество итераций с целью повышения прозрачности разработки и получения сходящегося к цели процесса.
Полностью согласен с тем, что всему свое место. Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Что касается MSF, то не вижу тут какого-то открытия. Прежде чем что-то делать, нужно понять что, подготовиться, провести исследования. После того как выполнена основная работа, можно заняться вопросами маркетинга, продажами и т.п.
Тут важно то, что методология подбирается под проект, условия и команду, думаю это ни для кого не открытие.
Вы как раз и работали в Agile, применяя то подход предварительного полного продумывания, то кодирования с учетом непрерывного изменения (аля XP).
Противопоставление Waterfall и Agile уместно на более высоком уровне, то есть на уровне разработки большой части системы, а не конкретной фичи.
на мой вариант ушло 5 минут, первый поиск по запросу «mysql rownum» вернул конструкцию как я привел.
для меня было откровением update… order by rating, id :) это необычно.
+--------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+---------+------+-----+---------+-------+
| id | int(11) | YES | | NULL | |
| rating | int(11) | YES | | NULL | |
| place | int(11) | YES | | NULL | |
+--------+---------+------+-----+---------+-------+
3 rows in set (0.01 sec)
mysql> select * from rt;
+------+--------+-------+
| id | rating | place |
+------+--------+-------+
| 1 | 86 | NULL |
| 2 | 5 | NULL |
| 3 | 5 | NULL |
+------+--------+-------+
3 rows in set (0.00 sec)
mysql> update rt set place = (select @rownum:=@rownum+1 from (select @rownum:=0)
t) order by rating, id;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3 Changed: 3 Warnings: 0
mysql> select * from rt;
+------+--------+-------+
| id | rating | place |
+------+--------+-------+
| 1 | 86 | 3 |
| 2 | 5 | 1 |
| 3 | 5 | 2 |
+------+--------+-------+
3 rows in set (0.00 sec)
А можно добавлять свои источники? какой-то формат ленты используется? Я не нашел как.
Ихмо удобнее когда тэги справа, а не с низу и думаю таблица 4x3 самое достаточное, а то глаза разбегаются.
По поводу "+" в боксе с роликом: наверно это голосование, но совсем не очевидно, либо хинт нужно добавить, либо другую иконку выбрать
1. совершенствоваться в своей области, или изучать другую, технические гуру нужны всегда.
2. заняться менеджментом/бизнесом.
3. заняться консалтингом и продавать свой предыдущий опыт, если он значителен.
ИМХО, среди российской публики нет большого смысла спрашивать о будущем на 5 лет вперед, мы пока всегда в отсающих, поинтересуйтесь об этом у западных коллег.
А если не знаете английского, то самое время его подучить :)
вот если бы реальные примеры из жизни, где эти знания пригодятся…
Вам хочу посоветовать разобраться в терминах. Я говорил об опытных программистах, а не о профессионалах.
Тем более что виртуальные функции — это основа и не владеть ими не может не то чтобы профессионал, а любой кто хоть раз их пробовал использовать.
Вообще популяризация сложных механизмов всегда чревата :) Позвольте еще один совет:
Популяризуйте язык не путем описания его базовых возможностей, а путем решения обычных или классических задач с привлечением нетривиальных возможностей языка.
с одной стороны: студентам нужно объяснять где найти материал (это классика инженерного образования) и требовать от них желания самостоятельно разобраться в вопросах.
с другой стороны: услышав некоторое поверхностное объяснение большинство на этом и остановится, а через год будет позиционировать себя C++ специалистами, тем самым дескредитировав Вас и Ваше учебное заведение.
а это зачем?
Однако, оба мифа мифами не являются, а хорошо известны любому опытному C++ программисту, то есть в статье что-то новое могут открыть для себя программеры «случайно» пишущие на cpp или новички.
Может быть просто дать две ссылки на документацию по cpp и не тратить время на подготовку кода, написание статьи?
вопрос о том, что отзыв (положительный или отрицательный) должен быть как-то проверен, подтвержден, что с этим?