Ну не все корабли способны к самостоятельному плаванию. Иногда им НУЖНО прицепиться к кораблю побольше.
Вполне возможно, что тот же Groupon, если бы Google купил его за 6млрд$, стал бы популярным сервисом Google. Потому что рынок то купонов остался, и нормального решения все равно так и нет. И было бы win-win.
А так компания решила плавать самостоятельно, и в шторм потонула. IPO сам по себе здесь был, возможно, не так важен. Сыграло роль решение жить как независимая компания, а не встроиться в экосистему какого-то гиганта.
PV installations can operate for 100 years or even more[127] with little maintenance or intervention after their initial set-up, so after the initial capital cost of building any solar power plant, operating costs are extremely low compared to existing power technologies.
With current technology, photovoltaics recoups the energy needed to manufacture them in 1.5 to 2.5 years in Southern and Northern Europe, respectively.
Если авторство само по себе ничего не дает, без патента, тогда какой в нем смысл? Писатель не должен патентовать свою книгу, чтобы распоряжаться правами на нее. А профессор, получается, должен?
Поэтому мне и кажется, что понятие авторства в области алгоритмов и кода нигде особенно не применяется. Может быть в России получается делать забавные судебные процессы на этом основании, пользуясь, скажем так, это дыркой в законе. Но больше нигде такого внимания именно к «авторству» кода я не встречал. Скажем так, авторство кода в этом смысле ничем не отличается особенно от авторства повара, работающего на кухне. Формально, конечно, он является, наверное, автором всех своих блюд, которые он готовит. Но в практическом смысле это ни к чему не ведет.
Я имею ввиду здесь именно приготовление обычных блюд, не какой-то очень творческий процесс их придумывания. Впрочем, мне кажется что и творческий процесс тоже здесь подпадет под общее патентное право, и никаких специальных исключений не будет.
Скорее уж авторство музыки, книг и фильмов представляет собой юридически особенный случай. Чем типовой случай, под который мы будем подгонять все другие отрасли.
Иначе можно правда дойти до абсурда. Скажем, хирург будет автором шва на животе, который он сделал, так как это тоже, наверное, в каком-то смысле можно понимать как визуальный элемент. А водитель автобуса будет автором-реализатором специального «танца», в котором он крутит руль.
Обоснуйте, пожалуйста. Соната Бетховена, например, «приносит доход» уже пару сотен лет и продолжает приносить. То же про книги. Почему аппликация должна устареть?
Ну хорошо, игра может выйти из моды. Но аппликация по изучению английского языка?!
Забанили его за воровство картинок. Которые можно элементарно купить, они стоят не дорого. Или взять из бесплатных баз картинок.
Это решаемая проблема.
Я хочу сказать, что автор статьи играет в другой лиге. Чем те, кто просто работает за зарплату. Он может проиграть, а может и выиграть, естественно. Но те skills, которые он нарабатывает, с бОльшим успехом приведут его к большим деньгам.
Представьте себе, что каждый год он пишет по приложению. Какие-то из них погибают, какие-то пользуются успехом. Опыт растет. В какой-то момент человек пишет приложение, которое «выстреливает».
Альтернатива — тот же человек работает за зарплату. Год, другой, третий. Да, его зарплата несколько подрастет за 10 лет. Но вряд ли она изменится в 100 раз, если только он не пойдет открывать свою компанию.
Второе, что я хочу сказать, что пассивный доход и активный доход — это совсем разные вещи. Чтобы получать 300 долларов пассивного дохода, нужно написать апликацию. Скажем, это занимает год. Теперь смотрите — чтобы с помощью работы на ставке добиться пассивного дохода в 300 долларов, нужно:
— откладывать каждый месяц, скажем, по 500 долларов от зарплаты в течении 15(!) лет
— после этого, накопив 100тыс долларов вы сможете их инвестировать в ценные бумаги под 4% и получать те же 300 долларов пассивного дохода
Ну так они как раз алгоритмы располагают в emobiment example section:
Следует принимать во внимание, что настоящее изобретение может быть реализовано многочисленными способами…
В одном из вариантов осуществления описывается способ для автоматического перевода терминов запроса из одного языка и/или набора символов в другой.…
В другом варианте осуществления создается вероятностный словарь, который отображает термины, написанные в первом формате…
В еще одном варианте осуществления описывается способ для создания вероятностного словаря.
и т.д.
То есть сам патент покрывает описание технического устройства, а алгоритм уходит в emodiment example. Понятно, что они все время балансируют. Но в целом, да, алгоритм идет лишь как демонстрация того, как такое устройство может работать.
Если в программе реализован алгоритм, разработанный профессором X и открыто опубликованный им в своей статье? Как передавать авторство такой разработки заказчику?
«Авторство» звучит очень интересно, но что-то меня здесь смущает.
А почему об этом надо спрашивать HR-managers? Это игра что-ли такая?
Какая вообще связь между профессиональным успехом человека и тем, понравилось ли его резюме HR?
Мне казалось, что HR исполняет сервисные функции в tech-компаниях. Ну там ведут ведомости по зарплате, общаются с трудовой инспекцией, находят тренинги. А решение о том, является ли соискатель tech-профессионалом могут принять только другие tech-профессионалы.
Или это как в балетную школу набирать по собеседованию с учителем математики?
Мне, к примеру, половина этих слов очень нравятся. Tech-инженеры, особенно очень хорошие, редко хорошо владеют другой половиной мозга, и навыки социального общения у них могут быть не очень развиты. Они вполне могут писать в резюме прямо, что думают, не обдумывая «понравится ли это HR или нет». И это даже может выглядеть смешно.
С другой стороны профессиональный театральный актер с легкостью напишет резюме, над которым HR будут плакать и повесят его на стенку. Но, как у инженера, результат его работы будет ноль.
Мне не очень понятно, что случится с приложением, которое уже приносит доход, на следующий год? Обычно со временем количество скачиваний только растет, пусть медленно.
Как я понимаю, ветки в SVN изначально совсем для другого — не для параллельной разработки. А скорее, чтобы хранить несколько версий одного продукта для разных пользователей, скажем.
А разработка в SVN хорошо идет, если все всё время работают с одним репозиторием (в одной ветке). Это требует вначале некоторой организации кода, чтобы реально можно было пробовать разные вещи не мешая друг другу, и не мешая основному проекту — на уровне кода, не через SVN. Но зато потом это работает железно, 0 проблем.
Видимо Git пытается взять на себя поддержку параллельной разработки, и от этого на него такая нагрузка. Ведь параллельная разработка — это никогда не бывает слишком просто. В принципе это и не может быть просто, вряд ли здесь есть универсальное решение.
Звучит очень хорошо. ОК, про А мы можем забыть. Делаем ей stash, действительно, и все. Вместо pull сначала fetch, чтобы осмотреться.
По поводу 2: вы не знаете, как в Tortoise выбрать слияние или rebase? И в чем разница?
И другой вопрос — как в Tortoise откатить слияние, если оно слишком запуталось (то есть вернуть чистую версию Б?)
Я как-то уже привык работать через Tortoise, не хочется учить terminal git только для пары вещей.
Лечите, лечите. Может я наконец разберусь. Поверьте, я уже прочитал книжку по Git, и работаю с ним пару лет, и то до сих пор не разобрался в некоторых базовых вопросах. Это уже даже не смешно.
На работе, если у меня что-то не получается, то просто приходит человек и исправляет. Но я все равно не понимаю до конца. Причем, мне кажется, даже он не всегда понимает как именно надо исправить, просто делает несколько разных попыток и в конце все работает.
У нас последняя история — начали работать с submodules, это вообще финиш. Приходится каждый раз ВРУЧНУЮ проверять все ссылки на submodules каждый раз, прежде чем делать pull главной версии. А этих submodules уже больше десятка. Но про это я даже не спрашиваю, мне бы с вещами попроще разобраться.
Я что-то понял, но мне хотелось бы прояснить. Сначала определимся с терминологией.
Версия А — моя локальная версия. НЕКОТОРЫЕ файлы из которой я хочу отправить в репозиторий, а с другими продолжаю работать.
Будем считать, что когда я начал работать с локальной версией, она была синхронизована с репозиторием в день 1.
Я делаю commit этим файлам, и у меня появляется:
Версия Б — это удаленная версия день 1 + мои правки, все это все еще у меня на компьютере.
При этом версия А тоже продолжает оставаться на моем компьютере, так как я сделал commit не всем файлам.
Следующий этап — я делаю push, и понимаю, что удаленная версия изменилась. То есть сразу push не проходит. Назовем удаленная версия день 2, это версия В.
Значит я делаю pull этой версии В, и этот pull портит мне версию А. Но я могу зато сделать merge. При этом версия Б остается неизменной, мой merge на нее не влияет, к сожалению.
Ок, я делаю merge В с А (хотя хотел бы Б с А), потом делаю еще один commit и надеюсь, что теперь Б соединилась с В.
После этого я делаю push и вроде все должно быть нормально.
Однако, поскольку эта процедура портит мне локальную версию А, то и merge A c В может не вполне адекватно отражать то, что я хочу сделать merge Б c В.
Где физически находится версия Б? Могу ли я работать с ней напрямую, после commit но до push? Могу ли я работать с Б так, чтобы моя локальная версия А оставалась нетронутой?
Извините, я неправильно написал. Надо было «сделать push не получается просто так»…
Просто я работаю с несколькими системами одновременно, и все эти понятия слегка смешались у меня в голове.
Но это была моя ошибка, извините.
По сути я описал проблему верно, только ошибся в словах.
Вполне возможно, что тот же Groupon, если бы Google купил его за 6млрд$, стал бы популярным сервисом Google. Потому что рынок то купонов остался, и нормального решения все равно так и нет. И было бы win-win.
А так компания решила плавать самостоятельно, и в шторм потонула. IPO сам по себе здесь был, возможно, не так важен. Сыграло роль решение жить как независимая компания, а не встроиться в экосистему какого-то гиганта.
en.m.wikipedia.org/wiki/Photovoltaics
en.m.wikipedia.org/wiki/Photovoltaics
?
Пишите еще :)
Очень хотелось бы узнать про аналогичные (или другие интересные хай-тек процессы) в США, Израиле и/или Азии.
Поэтому мне и кажется, что понятие авторства в области алгоритмов и кода нигде особенно не применяется. Может быть в России получается делать забавные судебные процессы на этом основании, пользуясь, скажем так, это дыркой в законе. Но больше нигде такого внимания именно к «авторству» кода я не встречал. Скажем так, авторство кода в этом смысле ничем не отличается особенно от авторства повара, работающего на кухне. Формально, конечно, он является, наверное, автором всех своих блюд, которые он готовит. Но в практическом смысле это ни к чему не ведет.
Я имею ввиду здесь именно приготовление обычных блюд, не какой-то очень творческий процесс их придумывания. Впрочем, мне кажется что и творческий процесс тоже здесь подпадет под общее патентное право, и никаких специальных исключений не будет.
Скорее уж авторство музыки, книг и фильмов представляет собой юридически особенный случай. Чем типовой случай, под который мы будем подгонять все другие отрасли.
Иначе можно правда дойти до абсурда. Скажем, хирург будет автором шва на животе, который он сделал, так как это тоже, наверное, в каком-то смысле можно понимать как визуальный элемент. А водитель автобуса будет автором-реализатором специального «танца», в котором он крутит руль.
Ну хорошо, игра может выйти из моды. Но аппликация по изучению английского языка?!
Это решаемая проблема.
Представьте себе, что каждый год он пишет по приложению. Какие-то из них погибают, какие-то пользуются успехом. Опыт растет. В какой-то момент человек пишет приложение, которое «выстреливает».
Альтернатива — тот же человек работает за зарплату. Год, другой, третий. Да, его зарплата несколько подрастет за 10 лет. Но вряд ли она изменится в 100 раз, если только он не пойдет открывать свою компанию.
Второе, что я хочу сказать, что пассивный доход и активный доход — это совсем разные вещи. Чтобы получать 300 долларов пассивного дохода, нужно написать апликацию. Скажем, это занимает год. Теперь смотрите — чтобы с помощью работы на ставке добиться пассивного дохода в 300 долларов, нужно:
— откладывать каждый месяц, скажем, по 500 долларов от зарплаты в течении 15(!) лет
— после этого, накопив 100тыс долларов вы сможете их инвестировать в ценные бумаги под 4% и получать те же 300 долларов пассивного дохода
Вот такое сравнение получается.
Следует принимать во внимание, что настоящее изобретение может быть реализовано многочисленными способами…
В одном из вариантов осуществления описывается способ для автоматического перевода терминов запроса из одного языка и/или набора символов в другой.…
В другом варианте осуществления создается вероятностный словарь, который отображает термины, написанные в первом формате…
В еще одном варианте осуществления описывается способ для создания вероятностного словаря.
и т.д.
То есть сам патент покрывает описание технического устройства, а алгоритм уходит в emodiment example. Понятно, что они все время балансируют. Но в целом, да, алгоритм идет лишь как демонстрация того, как такое устройство может работать.
Ошибаюсь?
«Авторство» звучит очень интересно, но что-то меня здесь смущает.
Какая вообще связь между профессиональным успехом человека и тем, понравилось ли его резюме HR?
Мне казалось, что HR исполняет сервисные функции в tech-компаниях. Ну там ведут ведомости по зарплате, общаются с трудовой инспекцией, находят тренинги. А решение о том, является ли соискатель tech-профессионалом могут принять только другие tech-профессионалы.
Или это как в балетную школу набирать по собеседованию с учителем математики?
Мне, к примеру, половина этих слов очень нравятся. Tech-инженеры, особенно очень хорошие, редко хорошо владеют другой половиной мозга, и навыки социального общения у них могут быть не очень развиты. Они вполне могут писать в резюме прямо, что думают, не обдумывая «понравится ли это HR или нет». И это даже может выглядеть смешно.
С другой стороны профессиональный театральный актер с легкостью напишет резюме, над которым HR будут плакать и повесят его на стенку. Но, как у инженера, результат его работы будет ноль.
А разработка в SVN хорошо идет, если все всё время работают с одним репозиторием (в одной ветке). Это требует вначале некоторой организации кода, чтобы реально можно было пробовать разные вещи не мешая друг другу, и не мешая основному проекту — на уровне кода, не через SVN. Но зато потом это работает железно, 0 проблем.
Видимо Git пытается взять на себя поддержку параллельной разработки, и от этого на него такая нагрузка. Ведь параллельная разработка — это никогда не бывает слишком просто. В принципе это и не может быть просто, вряд ли здесь есть универсальное решение.
По поводу 2: вы не знаете, как в Tortoise выбрать слияние или rebase? И в чем разница?
И другой вопрос — как в Tortoise откатить слияние, если оно слишком запуталось (то есть вернуть чистую версию Б?)
Я как-то уже привык работать через Tortoise, не хочется учить terminal git только для пары вещей.
Спасибо!
На работе, если у меня что-то не получается, то просто приходит человек и исправляет. Но я все равно не понимаю до конца. Причем, мне кажется, даже он не всегда понимает как именно надо исправить, просто делает несколько разных попыток и в конце все работает.
У нас последняя история — начали работать с submodules, это вообще финиш. Приходится каждый раз ВРУЧНУЮ проверять все ссылки на submodules каждый раз, прежде чем делать pull главной версии. А этих submodules уже больше десятка. Но про это я даже не спрашиваю, мне бы с вещами попроще разобраться.
Версия А — моя локальная версия. НЕКОТОРЫЕ файлы из которой я хочу отправить в репозиторий, а с другими продолжаю работать.
Будем считать, что когда я начал работать с локальной версией, она была синхронизована с репозиторием в день 1.
Я делаю commit этим файлам, и у меня появляется:
Версия Б — это удаленная версия день 1 + мои правки, все это все еще у меня на компьютере.
При этом версия А тоже продолжает оставаться на моем компьютере, так как я сделал commit не всем файлам.
Следующий этап — я делаю push, и понимаю, что удаленная версия изменилась. То есть сразу push не проходит. Назовем удаленная версия день 2, это версия В.
Значит я делаю pull этой версии В, и этот pull портит мне версию А. Но я могу зато сделать merge. При этом версия Б остается неизменной, мой merge на нее не влияет, к сожалению.
Ок, я делаю merge В с А (хотя хотел бы Б с А), потом делаю еще один commit и надеюсь, что теперь Б соединилась с В.
После этого я делаю push и вроде все должно быть нормально.
Однако, поскольку эта процедура портит мне локальную версию А, то и merge A c В может не вполне адекватно отражать то, что я хочу сделать merge Б c В.
Где физически находится версия Б? Могу ли я работать с ней напрямую, после commit но до push? Могу ли я работать с Б так, чтобы моя локальная версия А оставалась нетронутой?
Извините, если запутано получилось.
Просто я работаю с несколькими системами одновременно, и все эти понятия слегка смешались у меня в голове.
Но это была моя ошибка, извините.
По сути я описал проблему верно, только ошибся в словах.