Есть Open Source, а есть "Open Source", кажется модель при которой продукт становится open source с целью извлечения большей прибыли из продукта теряет свою популярность.
Есть коммерческая организация
Целью коммерческой организации является извлечение максимальной прибыли
Продукт делается open source
Продукт становится популярным
Другие организации начинают извлекаться прибыль из продукта
Организация видит свою упущенную прибыль
т.к. оригинальная цель была не в open source как таковом, а извлечении максимальной прибыли, лицензия меняется.
Например такие истории логично не случаются с другими продуктам, например PostgreSQL или Linux.
Интересно что такие истории изменения лицензии не происходят с библиотеками и фреймворками (или меня не затрагивали?), т.к. на их основе делаются продукты, но нельзя просто запустить бинарник на сервере и продавать услугу.
Думаю также существует некий предел популярности продукта после которого поздно менять лицензию, например Оракл попробовали ограничить использование их билда jdk 11, но тут же появилось множество альтернатив, в новых версиях они снова изменили лицензию, но уже поздно.
всегда можно задать вопрос еще раз, из последнего:
отлично выдал, функцию для заполнения таблички фейковыми данными.
простой .bat скрипт
совсем не смог выдать скрипт который соберет значения проперти объектов внутри массива, но и на stackoveflow я не осилил найти, чем меньше разбираешься в вопросе, тем сложнее правильный вопрос сформулировать для гугления.
спрашивал по разному, в итоге сдался и пошел читать доки.
так и вижу как владелец компании по разработке и продвижению мобильных игр прочитав статью ОП, решит отказаться от рекламной стратегии которая приносит миллионы.
На lichess можно добавить своего бота, который будет иметь реальный рейтинг, я думаю таким образом можно гораздо лучше оценить рейтинг. lichess.org/player/bots
главный вопрос, зачем вообще что то гуглить в яндексе про программирование. я уверен, что даже в самом яндексе большинство разработчиков тех. вопросы ищут в гугле.
от проекта зависит, где то много простых шаблонных задач для джуна, в других быстрее самому сделать, чем объяснять и потом на ревью 10 раз переделывать.
Кто разработчиков нанимал, кто процессы QA выстраивал?
Если руководство не понимает что оно делает, значит само и виновато.
Можно нанять вчерашних студентов и жаловаться что плохой продукт делают.
Можно создать процессы\атмосферу где никто не будет вылизывать задачи, а потом винить разработчиков в чем-то.
Видите про проблему уже и новость написали, а патч на след. день не вышел, значит руководству все нравится.
У каждого предприятия есть руководство, какие цели руководство ставит такие цели и выполняются разработчиками.
Например разработчики телеграм почему-то осилили написать нативный клиент под каждую платформу — потому что такую цель поставило руководство, а руководство скайп решило что они сэкономят переписав все javascript.
Почему-то когда нужно выжать дополнительную копейку с просмотра рекламы или выжать 1мс скорости обработки трейдингового бота, разработчики справляются, а тут почему-то нет.
Нет, решение гораздо проще, эти данные просто не нужно хранить и все.
— Зачем условному Яндекс Такси имя фамилия? — незачем.
— Должна быть возможность завести временный виртуальный номер без привязки к ФИО
— Персональные данные не должны никого передаваться 3тим лицам, вообще. (как минимум отказ на передачу 3тим лицам, не может быть причиной отказа в обслуживании)
— Всегда должна быть возможность удалить любые свои данные из системы.
— Должна быть возможность при заказе поставить галку — удалить мои данные через N дней, и чтобы компания вообще про вас забыла.
Подозреваю что из it отдела там максимум админ, потому что в компаниях с нормальным it отделом указанные проблемы не только бы легко решили, а выявили бы еще на этапе нагрузочного тестирования.
У Трампа какой-то талант создавать до удивления абсурдные ситуации. Взять хотя бы историю когда пресс конференцию проводили на парковке «Four Seasons Total Landscaping» (рядом с секс-шопом и крематорием), скорее всего спутав с отелем «Four Seasons»
Всегда удивляло как компании с почти безлимитным бюджетом умудряются создавать тормозное глючное ПО, что твиттер, что скайп. При этом центральный функционал этих систем, совсем не рокетсаенс. И ведь что в одной, что в другой есть люди которые получают большие деньги за проектирование UI этих систем.
Выше уже написали много правильных вещей, кажется автор встретился с каким-то оверинжинингом, где интерфейсы использовались не к месту.
Автор почему-то думает что интерфейсы как-то препятствуют изменениям в системе, наоборот это самая замечательная вещь при изменениях, знание того что:
1. При сохранение контракта, мы сколь угодно можем переписывать реализацию и у пользователей моего api (интерфейса) ничего не сломается, значительно упрощает жизнь.
2. Знание того что при изменениях интерфейса, все сломается в нужных местах, пока ты не исправишь реализации оно просто не скомпилиться.
Приведу несколько примеров из жизни за последнее время:
1. Переделывал хранение локализации из properties файлов, в бд -> просто подменил реализации, без необходимости исправлять что-то по всему проекту.
2. Для стороннего api захотели сделать фолбэк, т.к. оно часто падало, просто обернули реализацию в прокси, опять же без необходимости что-то менять.
3. Сторонняя команда, реализовала хранилище нужного нам сервиса на другой бд (ускорив тем самым перфоманс), мы просто поменяли у себя зависимость, и все само заработало.
Идея хороша, можно было бы уволить всех дорогих программистов и заменить их аналитиками, и бизнесу жилось бы прекрасно. Но существующие подходы существуют не просто так, есть ограничения реального мира, жесткие диски, сеть, процессор, память, в условиях бесконечно быстрой и бесконечно большой памяти, бесконечно быстрого процессора можно было придумать любые абстракции их они бы хорошо работали. Даже с существующим железом для систем где данных не очень много, можно было бы подобное реализовать и похожие решения существуют, где можно задавать через ui сущности, делать для них ограничения, разделять доступ т.п. но:
1. Чем больше данных, тем более мы ограничены реальным миром (железом). Как пример,
в результате в реальном мире где-то данные хранят строками, где-то колонками, кому-то хватает json-а для передачи данных, кто-то экономит каждый бит и придумывает свои форматы.
2. Чем более гибкая система тем она сложнее и требует более сложных навыков для работы, и чем более гибкой мы будем делать систему, тем больше она будет напоминать обычную бд с SQL (который придумали как простой язык для непрограммистов), а работа аналитика работу программиста.
Вопрос как всегда в деньгах (времени), просто поиск корневой проблемы может стоить в 10 раз дороже (дольше), чем написание костыля, который проблему более менее решает, в компаниях где ошибка может стоить гораздо больше чем год работы 1 разработчика, корневые проблемы ищут и решают, и нанимают специалистов которые эти проблемы могут решить.
Чем больше (круче) компания (продукт) тем больше вероятность что сторонние продукты (бд и т.п.) собираются из исходников со своими патчами.
Есть Open Source, а есть "Open Source", кажется модель при которой продукт становится open source с целью извлечения большей прибыли из продукта теряет свою популярность.
Есть коммерческая организация
Целью коммерческой организации является извлечение максимальной прибыли
Продукт делается open source
Продукт становится популярным
Другие организации начинают извлекаться прибыль из продукта
Организация видит свою упущенную прибыль
т.к. оригинальная цель была не в open source как таковом, а извлечении максимальной прибыли, лицензия меняется.
Например такие истории логично не случаются с другими продуктам, например PostgreSQL или Linux.
Интересно что такие истории изменения лицензии не происходят с библиотеками и фреймворками (или меня не затрагивали?), т.к. на их основе делаются продукты, но нельзя просто запустить бинарник на сервере и продавать услугу.
Думаю также существует некий предел популярности продукта после которого поздно менять лицензию, например Оракл попробовали ограничить использование их билда jdk 11, но тут же появилось множество альтернатив, в новых версиях они снова изменили лицензию, но уже поздно.
всегда можно задать вопрос еще раз, из последнего:
отлично выдал, функцию для заполнения таблички фейковыми данными.
простой .bat скрипт
совсем не смог выдать скрипт который соберет значения проперти объектов внутри массива, но и на stackoveflow я не осилил найти, чем меньше разбираешься в вопросе, тем сложнее правильный вопрос сформулировать для гугления.
спрашивал по разному, в итоге сдался и пошел читать доки.
select jsonb_path_query_array ('[{
"value": "one"
},
{
"value": "two"
}
]'::jsonb, '$[*].value') as values;
так и вижу как владелец компании по разработке и продвижению мобильных игр прочитав статью ОП, решит отказаться от рекламной стратегии которая приносит миллионы.
lichess.org/player/bots
Если руководство не понимает что оно делает, значит само и виновато.
Можно нанять вчерашних студентов и жаловаться что плохой продукт делают.
Можно создать процессы\атмосферу где никто не будет вылизывать задачи, а потом винить разработчиков в чем-то.
Видите про проблему уже и новость написали, а патч на след. день не вышел, значит руководству все нравится.
Например разработчики телеграм почему-то осилили написать нативный клиент под каждую платформу — потому что такую цель поставило руководство, а руководство скайп решило что они сэкономят переписав все javascript.
Почему-то когда нужно выжать дополнительную копейку с просмотра рекламы или выжать 1мс скорости обработки трейдингового бота, разработчики справляются, а тут почему-то нет.
— Зачем условному Яндекс Такси имя фамилия? — незачем.
— Должна быть возможность завести временный виртуальный номер без привязки к ФИО
— Персональные данные не должны никого передаваться 3тим лицам, вообще. (как минимум отказ на передачу 3тим лицам, не может быть причиной отказа в обслуживании)
— Всегда должна быть возможность удалить любые свои данные из системы.
— Должна быть возможность при заказе поставить галку — удалить мои данные через N дней, и чтобы компания вообще про вас забыла.
en.wikipedia.org/wiki/Four_Seasons_Total_Landscaping_press_conference
Автор почему-то думает что интерфейсы как-то препятствуют изменениям в системе, наоборот это самая замечательная вещь при изменениях, знание того что:
1. При сохранение контракта, мы сколь угодно можем переписывать реализацию и у пользователей моего api (интерфейса) ничего не сломается, значительно упрощает жизнь.
2. Знание того что при изменениях интерфейса, все сломается в нужных местах, пока ты не исправишь реализации оно просто не скомпилиться.
Приведу несколько примеров из жизни за последнее время:
1. Переделывал хранение локализации из properties файлов, в бд -> просто подменил реализации, без необходимости исправлять что-то по всему проекту.
2. Для стороннего api захотели сделать фолбэк, т.к. оно часто падало, просто обернули реализацию в прокси, опять же без необходимости что-то менять.
3. Сторонняя команда, реализовала хранилище нужного нам сервиса на другой бд (ускорив тем самым перфоманс), мы просто поменяли у себя зависимость, и все само заработало.
1. Чем больше данных, тем более мы ограничены реальным миром (железом). Как пример,
в результате в реальном мире где-то данные хранят строками, где-то колонками, кому-то хватает json-а для передачи данных, кто-то экономит каждый бит и придумывает свои форматы.
2. Чем более гибкая система тем она сложнее и требует более сложных навыков для работы, и чем более гибкой мы будем делать систему, тем больше она будет напоминать обычную бд с SQL (который придумали как простой язык для непрограммистов), а работа аналитика работу программиста.
Чем больше (круче) компания (продукт) тем больше вероятность что сторонние продукты (бд и т.п.) собираются из исходников со своими патчами.