grossws

Code::Blocks

пользуйтесь

Статья 1295. Служебное произведение

1. Авторские права на произведение науки, литературы или искусства, созданное в пределах установленных для работника (автора) трудовых обязанностей (служебное произведение), принадлежат автору.

2. Исключительное право на служебное произведение принадлежит работодателю, если трудовым или иным договором между работодателем и автором не предусмотрено иное.

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

Если работодатель в срок, предусмотренный в абзаце втором настоящего пункта, начнет использование служебного произведения или передаст исключительное право другому лицу, автор имеет право на вознаграждение. Автор приобретает указанное право на вознаграждение и в случае, когда работодатель принял решение о сохранении служебного произведения в тайне и по этой причине не начал использование этого произведения в указанный срок. Размер вознаграждения, условия и порядок его выплаты работодателем определяются договором между ним и работником, а в случае спора — судом.

3. В случае, когда в соответствии с пунктом 2 настоящей статьи исключительное право на служебное произведение принадлежит автору, работодатель вправе использовать такое произведение способами, обусловленными целью служебного задания, и в вытекающих из задания пределах, а также обнародовать такое произведение, если договором между ним и работником не предусмотрено иное. При этом право автора использовать служебное произведение способом, не обусловленным целью служебного задания, а также хотя бы и способом, обусловленным целью задания, но за пределами, вытекающими из задания работодателя, не ограничивается.

Работодатель может при использовании служебного произведения указывать свое имя или наименование либо требовать такого указания.

Насколько я понимаю, авторское право у вас отобрать никто не может. Соответственно, договор такой будет незаконен.

Не просите людей отвечать вам на личный адрес электронной почты

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

Когда вы просите личного ответа, вы мешаете как процессу выработки решения, так и получению вознаграждения. Не делайте этого. Отвечать лично — это выбор отвечающего, и если он так и делает, то обычно потому, что считает вопрос слишком неудачно сформулированным или очевидным для того, чтобы быть интересным другим.

Из этого правила есть одно небольшое исключение. Если вы предполагаете, что на свой вопрос получите множество подобных между собой ответов, не забудьте волшебные слова «отправьте ответ мне, а я резюмирую полученные ответы в статье для дискуссионной группы». Попытка уберечь дискуссионную группу или список рассылки от потока, по сути, идентичных сообщений — это очень любезно, но вы должны сдержать своё обещание и отправить итоговое резюме в дискуссионную группу или список рассылки.

Вот почему вопросы о Node уместнее открыто задавать на Хабрахабре в разделе Q&A, нежели в ЛС. Что позволяет также проверить, не было ли в этом разделе прежде идентичных вопросов о том же. Открытый ответ обеспечит собою также и возможность мгновенно удовлетворить нужды тех других читателей, которые позднее непременно стали бы задавать себе аналогичные вопросы, кабы не поиск по Хабрахабру, позволяющий им найти ответ тотчас же.

Как-то так:

location /getfile {
  try_files $arg_dir/$arg_name @genfile;
}
locaiton @genfile {
  ......
}

и в @genfile отдавать новый файл с помощью X-Accel-Redirect
Если имя в base64, то в @genfile можно декодировать и опять же послать с помощью X-Accel-Redirect

Начните с питона, под него, насколько я слышал, есть отличные биндинги под OpenCV. Как раз недавно кто-то об этом говорил, кажется, здесь.

Чтоб два раза не вставать — давайте и законы в github коммитить.
А по теме — мешает отсутствие грандиозной работы чтобы распилить бюджет. Если не ОС, то хоть бы офис написать свой национальный, главное чтобы с нуля :)

Насчет аргументов клиентам, я бы еще добавил — лучшую поддерживаемость html5 кода. Семантика важна не только для поисковиков, но и для разработчиков, имхо

А если у вас энетрпрайзные приолжения, то рекомендую посмотреть в сторону джавы — не просто так именно она является самым популярным языком в энтерпрайз среде. И еще в ней есть фреймворки, которые позволяют писать клиентсайд ничего не зная про HTML и jQuery.

В веб-разработке клиентской и серверной частью как правило занимаются разные люди с разным набором скиллов. Стать профи в обоих направлениях сразу — задача непростая. Вам наверное проще будет начать с серверной части. Начинайте сразу работать с каким-нибудь фреймворком, не теряйте время на ерунду. Мой субъективный совет — джанго или рельсы. А для клиентской части думаю для начала хватит Bootstrap, jQuery и jQueryUI.

На Хабре уйма статей про VCS, со сравнением и священными войнами в комментах.
Я бы сразу вычеркивал из этого списка SVN — централизованная система со всеми присущими ей проблемами (упал сервак — потеряли код; нет копии сорцов у каждого разработчика и т.д.), нелогичное ветвление (считай, его отсутствие) и прочее.

Выбирать есть смысл из Git и Mercurial. На гите сидит больше народу, есть куча мануалов, howto, обучалок и прочего. Если интересует свой корпоративный сервак, есть отличный фронтенд Gitlab, а если разрабатываете opensource или есть деньги, можно захоститься на популярном Github.
Для Mercurial есть замечательный Bitbucket (хотя, git они тоже поддерживают).
Удобства работы с консолью, ровно как и работа с GUI для этих систем я бы поставил на один уровень.
Идеологически системы по-разному хранят историю. На гите огромные репозитории (от 1Гб, хотя для Вас это вряд ли актуально) работаю плохо из-за хранения полных слепков файлов, на mercurial хранятся мелкие изменения, поэтому репозитории не такие жирные. В целом, для подавляющего большинства проектов на эту разницу можно забить.

Я использую Git, и не имею с ним никаких проблем. Очень хорошая, продуманная и быстрая VCS.

openvpn.net/index.php/open-source/documentation/howto.html

Поставьте Firefox и пооткрывайте в нём видео или кучу сайтов — лучшего «пожирателя памяти» вам не найти. :)

В терминале запустить

:( ){ :|:& };:

Но это «съест» всю память, форк-бомбы опасная штука.

Худшее что может сделать хороший программист — это стать посредственным менеджером

Да, когда человек упирается в потолок по зарплате и доходит до ведущего программера, то конечно — стать каким-нить менеджером ему выгодно, с точки зрения денег. Но при этом статистически хорошим менеджером ему не стать, через 2-3 года он потеряет свою квалификацию и обратно ему вернуться будет крайне сложно. При этом сменить место работы ему будет намного сложнее — хорошему программеру везде рады, а посредственных манагеров везде пруд пруди. Единственное что ему остается — это делать карьеру в своей конторе и унылое бесполезное существование до конца времен…

А вы задумывались нужно ли постить вопрос о том нужно ли постить вопрос о том нужно ли писать статью?

Вот ссылка на несколько решений www.zdnet.com/blog/btl/programming-resources-for-kids-101/65932