Мешанина и непонимание вопроса, перед публикацией стоило сперва изучить вопрос. Уже написали, что Free Software не синоним Open Source. С лицензиями тоже полнейшее непонимание. Термин copyleft как раз не просто так введен. Никакие лицензии не запрещают продавать ПО на коммерческой основе, даже если лицензия класса GPL. Публикация исходных текстов также является необязательной, в большинстве случаев, (внезапно, правда?), при этом конечный пользователь вправе потребовать предоставление ему исходных кодов такого продукта по запросу, а продавец обязан их предоставить.
Тема двойного лицензирования вообще не раскрыта никак (да, представьте, можно для студентов прям с исходниками отдавать, а вот с коммерческих предприятий требовать денежку, к примеру), как и смена лицензии на продукт со временем.
Про осторожность при выборе лицензии, уж простите, полный бред. Я как автор могу использовать свой собственный код как хочу и где хочу, даже если опубликовал его ранее под свободной лицензией, потому что (см. предыдущий абзац) могу применить любую лицензию к своему творению, но не могу отозвать лицензию на ранее опубликованный код, его могут использовать все в том виде, в каком он был опубликован (это если мы про GPL какой-нибудь опять же).
А ещё есть статическая или динамическая линковка, и этот момент также крайне важен в юридическом плане.
Ну и упущен ещё один важный момент. Когда мы говорим о лицензии на ПО, то есть условно два разных класса лицензий. То, что рассмотрено в статье - лицензии на исходные тексты, но есть ещё лицензии на экземпляр программного обеспечения, и эти классы ортогональны.
В общем, возвращайтесь после изучения матчасти, а пока статья скорее вредная, чем полезная.
Взглянул на свои правила для eslint и, пожалуй, соглашусь с вами: он у меня использует, собственно, привязки к самому TS и prettier и добавляет то, что не умеет prettier.
По-моему, главная проблема (именно проблема, а не сложность) TS в том, что он не умеет в глубокий вывод типов, причем, сами авторы усердно отказываются подобное внедрять, вроде как из-за проблем в скорости компиляции. Поэтому, например, при строгой проверке типов, вот такой код будет вызывать ошибку:
class MyClass {
public value: number;
constructor() {
this._initialize();
}
private _initialize() {
this.value = 0;
}
}
Дело в том, что TS не смотрит глубже в вызов функций внутри конструктора, поэтому ругнется на то, что поле value должно иметь тип number, но не было инициализировано и, по мнению компилятора, может оставаться undefined. И таких проблем вагон. Именно поэтому приходится вручную для библиотек писать замысловатые выводы типов, что крайне грустно, ведь TS должен по идее облегчать процесс написания кода, а не усложнять, а так выходит, что мы платим временем написания кода за время отладки, а хотелось бы просто экономить время на отладке, как в нормальных языках.
Ну так gentoo умеет в установку и deb и rpm при некотором желании, а calculate, как его производная - тоже должен. Мало того, некоторые пакеты прямо в основном репозитории именно таким образом и ставятся (ebuild-скрипт скачивает и распаковывает deb/rpm). Насколько все легко на сегодня - судить не берусь (с Gentoo связь потеряна последние лет 8), может, какой более удобный инструмент уже придумали. Ну и не забываем про snap/flatpack - вот где экосистема современного проприетарного ПО.
Про best practices имел ввиду ваше замечание про подавление ошибок, а не про защиту от инъекций. По поводу того, что человек спрашивал: так бывает, что назначили на какое-то легаси, а разработчик новичок или всегда пишет только с использованием ORM (что также вызывает вопросы, но, к сожалению, в наше время не редкость).
Про удобство с вами полностью согласен, именно поэтому во время публикации на гитхабе рука дальше нескольких правок под php7 дело и не пошло - не увидел смысла. Но, быть может, автор проекта что-то для себя оттуда почерпнет, или нет.
Ну и для проформы: вы сказали, что методы дырявые, на примере insert можете указать на конкретные места, я так понимаю, вы ознакомились с кодом немного?
О, вы меня неверно поняли, я на php не пишу уже некоторое количество лет, так что ничего подобного писать не соберусь, а если бы т собрался, то делал бы совсем не так. Если что, сам код прямиком из 2009-2010, с PDO тогда было так себе, адаптировано под php7 перед непосредственной публикацией на GitHub (дату коммитов можете посмотреть). Просто мне показалось, что код хорошо подойдёт данному проекту. Насчёт best practices в php вообще ничего сказать не могу.
Возможно, вам будет интересно: ссылка на отечественный query builder собственного велосипедопроизводства. Правда, ему уже миллион лет, и надо адаптировать под современные реалии, но комментарии и структура на месте. Когда-то был частью самописного CMF, но его концепция давно устарела, как мне кажется. Раз уж продвигаете отечественное, может, подхватите знамя.
Ваше замечание было бы обоснованно, если бы люди сперва не привыкли к продуктам MS и Adobe, которые в свое время крайне активно продвигались, а MS ещё и насаждались на государственном уровне. Поэтому для многих до недавнего времени стоял вопрос: зачем менять работающий инструмент, на другой, ещё и с туманными перспективами? Даже замена на открытые офисные пакеты - дорогостоящая операция по перелопачивать всего документооборота организации, а потом выясняется ещё, что контрагенты, включая наше прекрасное государство, "продвигающие" открытые стандарты, само постоянно на официальных сайтах документы выкладывает в формате doc(x)... Ну вы поняли, не всегда переход на бесплатное ПО приводит к экономии средств, особенно на краткой дистанции.
Спасибо за разъяснения, с тормозами при работе с большими документами и сам сталкивался, преимущественно до 7 версии, но с вашими проблемами - нет. Хотелось бы узнать: какие из проблем актуальны до сих пор в версии 7.x?
KDE в помощь. Okular поддкрживает 95% разных документов (не форматов, а документов, просто некоторые pdf иногда не открываются), картинки прекрасно показывает gwenview, да и превью в файловом менеджере dolphin можно зумить, spectacle допилен: скриншот может делать экрана, окна, или выделяемой области, с таймером и без, встроенный миниредактор для аннотаций, выгрузка в облако и просто копирование в буфер со вставкой (в telegram и discord проверял). Только лучше ставить KDE Neon, а не Kubuntu, где очень старая версия кед. Также в комплекте идёт установка софта и обновлений, в том числе из snap и flatpack, через GUI discover. Система поддерживает отложенную установку обновлений (а-ля win 10+).
Подключаем JSX к Vue и все позитивные моменты React сходят на нет (исходя из текста статьи). Не стоит начинать писать статьи с подобного рода текстов, по моему мнению.
Аргументы будут или в тон современным тенденциям голословное утверждение? За время работы с OO и LO не сталкивался ни с чем таким, чего нельзя сделать в этих пакетах. Или вы из тех, кто открывает xls или doc в Calc и Writer соответственно, а потом удивляется, что все поехало, и половина макросов не пашет?
Выводы из статистики вообще странные какие-то. Сперва сравнивают количество открытых за один и за другой период вакансий (зачем, не ясно, ведь то, что они были открыты, не означает, что уже закрыты, это как считать количество населения, суммируя показания всех переписей). Потом говорят от том, что 30+% хотят уехать из РФ, а дальше говорят, что общее количество резюме увеличилось на 15% и делают вывод о росте конкуренции на одну вакансию. Что?! Во-первых, не ясно, каким был показатель доли желающих уехать на начало периода, потому что их, очевидно, нужно отсечь из общей выборки, ведь они ищут работу за рубежом, тогда уже делать выводы о динамике конкуренции на внутреннем рынке труда. Ну и хотелось знать количество и динамику вакансий также внутренних и внешних. В общем, цифры есть, текст есть, теор.вера нет.
Вы, по всей видимости, другого племени практик, такой практик, который сперва ищет и изучает имеющиеся аналоги, вникает в домен, изучает теоретическую базу при необходимости и только потом решает: стоит ли писать свое.
Я вот тоже тот ещё любитель велосипедов, но отвечать, хотя бы самому себе, на вопрос "зачем" определенно стоит.
Можно, проблема в том, как Go интерпретирует ограничения, ограничения - это интерфейсы, а у интерфейсов не может быть полей, только тип и методы. Таким образом, можно ввести ограничение, которое будет задано структурными типами, но нельзя будет обращаться к ним, так как constraint type - это интерфейсный тип, а не структурный. В некотором смысле это даже хорошо, но почему это может быть хорошо нужно писать отдельную статью.
Зависит как раз от лицензии на код.
Мешанина и непонимание вопроса, перед публикацией стоило сперва изучить вопрос. Уже написали, что Free Software не синоним Open Source. С лицензиями тоже полнейшее непонимание. Термин copyleft как раз не просто так введен. Никакие лицензии не запрещают продавать ПО на коммерческой основе, даже если лицензия класса GPL. Публикация исходных текстов также является необязательной, в большинстве случаев, (внезапно, правда?), при этом конечный пользователь вправе потребовать предоставление ему исходных кодов такого продукта по запросу, а продавец обязан их предоставить.
Тема двойного лицензирования вообще не раскрыта никак (да, представьте, можно для студентов прям с исходниками отдавать, а вот с коммерческих предприятий требовать денежку, к примеру), как и смена лицензии на продукт со временем.
Про осторожность при выборе лицензии, уж простите, полный бред. Я как автор могу использовать свой собственный код как хочу и где хочу, даже если опубликовал его ранее под свободной лицензией, потому что (см. предыдущий абзац) могу применить любую лицензию к своему творению, но не могу отозвать лицензию на ранее опубликованный код, его могут использовать все в том виде, в каком он был опубликован (это если мы про GPL какой-нибудь опять же).
А ещё есть статическая или динамическая линковка, и этот момент также крайне важен в юридическом плане.
Ну и упущен ещё один важный момент. Когда мы говорим о лицензии на ПО, то есть условно два разных класса лицензий. То, что рассмотрено в статье - лицензии на исходные тексты, но есть ещё лицензии на экземпляр программного обеспечения, и эти классы ортогональны.
В общем, возвращайтесь после изучения матчасти, а пока статья скорее вредная, чем полезная.
Взглянул на свои правила для eslint и, пожалуй, соглашусь с вами: он у меня использует, собственно, привязки к самому TS и prettier и добавляет то, что не умеет prettier.
По-моему, главная проблема (именно проблема, а не сложность) TS в том, что он не умеет в глубокий вывод типов, причем, сами авторы усердно отказываются подобное внедрять, вроде как из-за проблем в скорости компиляции. Поэтому, например, при строгой проверке типов, вот такой код будет вызывать ошибку:
Дело в том, что TS не смотрит глубже в вызов функций внутри конструктора, поэтому ругнется на то, что поле
valueдолжно иметь типnumber, но не было инициализировано и, по мнению компилятора, может оставатьсяundefined. И таких проблем вагон. Именно поэтому приходится вручную для библиотек писать замысловатые выводы типов, что крайне грустно, ведь TS должен по идее облегчать процесс написания кода, а не усложнять, а так выходит, что мы платим временем написания кода за время отладки, а хотелось бы просто экономить время на отладке, как в нормальных языках.Например, стилизация кода, вроде как, для того и нужен, в первую очередь.
Ну так gentoo умеет в установку и deb и rpm при некотором желании, а calculate, как его производная - тоже должен. Мало того, некоторые пакеты прямо в основном репозитории именно таким образом и ставятся (ebuild-скрипт скачивает и распаковывает deb/rpm). Насколько все легко на сегодня - судить не берусь (с Gentoo связь потеряна последние лет 8), может, какой более удобный инструмент уже придумали. Ну и не забываем про snap/flatpack - вот где экосистема современного проприетарного ПО.
Про best practices имел ввиду ваше замечание про подавление ошибок, а не про защиту от инъекций. По поводу того, что человек спрашивал: так бывает, что назначили на какое-то легаси, а разработчик новичок или всегда пишет только с использованием ORM (что также вызывает вопросы, но, к сожалению, в наше время не редкость).
Про удобство с вами полностью согласен, именно поэтому во время публикации на гитхабе рука дальше нескольких правок под php7 дело и не пошло - не увидел смысла. Но, быть может, автор проекта что-то для себя оттуда почерпнет, или нет.
Ну и для проформы: вы сказали, что методы дырявые, на примере insert можете указать на конкретные места, я так понимаю, вы ознакомились с кодом немного?
О, вы меня неверно поняли, я на php не пишу уже некоторое количество лет, так что ничего подобного писать не соберусь, а если бы т собрался, то делал бы совсем не так. Если что, сам код прямиком из 2009-2010, с PDO тогда было так себе, адаптировано под php7 перед непосредственной публикацией на GitHub (дату коммитов можете посмотреть). Просто мне показалось, что код хорошо подойдёт данному проекту. Насчёт best practices в php вообще ничего сказать не могу.
Возможно, вам будет интересно: ссылка на отечественный query builder собственного велосипедопроизводства. Правда, ему уже миллион лет, и надо адаптировать под современные реалии, но комментарии и структура на месте. Когда-то был частью самописного CMF, но его концепция давно устарела, как мне кажется. Раз уж продвигаете отечественное, может, подхватите знамя.
Ваше замечание было бы обоснованно, если бы люди сперва не привыкли к продуктам MS и Adobe, которые в свое время крайне активно продвигались, а MS ещё и насаждались на государственном уровне. Поэтому для многих до недавнего времени стоял вопрос: зачем менять работающий инструмент, на другой, ещё и с туманными перспективами? Даже замена на открытые офисные пакеты - дорогостоящая операция по перелопачивать всего документооборота организации, а потом выясняется ещё, что контрагенты, включая наше прекрасное государство, "продвигающие" открытые стандарты, само постоянно на официальных сайтах документы выкладывает в формате doc(x)... Ну вы поняли, не всегда переход на бесплатное ПО приводит к экономии средств, особенно на краткой дистанции.
Спасибо за разъяснения, с тормозами при работе с большими документами и сам сталкивался, преимущественно до 7 версии, но с вашими проблемами - нет. Хотелось бы узнать: какие из проблем актуальны до сих пор в версии 7.x?
KDE в помощь. Okular поддкрживает 95% разных документов (не форматов, а документов, просто некоторые pdf иногда не открываются), картинки прекрасно показывает gwenview, да и превью в файловом менеджере dolphin можно зумить, spectacle допилен: скриншот может делать экрана, окна, или выделяемой области, с таймером и без, встроенный миниредактор для аннотаций, выгрузка в облако и просто копирование в буфер со вставкой (в telegram и discord проверял). Только лучше ставить KDE Neon, а не Kubuntu, где очень старая версия кед. Также в комплекте идёт установка софта и обновлений, в том числе из snap и flatpack, через GUI discover. Система поддерживает отложенную установку обновлений (а-ля win 10+).
Подключаем JSX к Vue и все позитивные моменты React сходят на нет (исходя из текста статьи). Не стоит начинать писать статьи с подобного рода текстов, по моему мнению.
Аргументы будут или в тон современным тенденциям голословное утверждение? За время работы с OO и LO не сталкивался ни с чем таким, чего нельзя сделать в этих пакетах. Или вы из тех, кто открывает xls или doc в Calc и Writer соответственно, а потом удивляется, что все поехало, и половина макросов не пашет?
Осталось добавить авторизацию без указания номера телефона, и тогда можно начинать пользоваться.
Выводы из статистики вообще странные какие-то. Сперва сравнивают количество открытых за один и за другой период вакансий (зачем, не ясно, ведь то, что они были открыты, не означает, что уже закрыты, это как считать количество населения, суммируя показания всех переписей). Потом говорят от том, что 30+% хотят уехать из РФ, а дальше говорят, что общее количество резюме увеличилось на 15% и делают вывод о росте конкуренции на одну вакансию. Что?! Во-первых, не ясно, каким был показатель доли желающих уехать на начало периода, потому что их, очевидно, нужно отсечь из общей выборки, ведь они ищут работу за рубежом, тогда уже делать выводы о динамике конкуренции на внутреннем рынке труда. Ну и хотелось знать количество и динамику вакансий также внутренних и внешних. В общем, цифры есть, текст есть, теор.вера нет.
Вы, по всей видимости, другого племени практик, такой практик, который сперва ищет и изучает имеющиеся аналоги, вникает в домен, изучает теоретическую базу при необходимости и только потом решает: стоит ли писать свое.
Я вот тоже тот ещё любитель велосипедов, но отвечать, хотя бы самому себе, на вопрос "зачем" определенно стоит.
Отличный способ решения любых проблем, хотя иногда и единственный.
Инди-хит от российских разработчиков. Своеобразная штука.
Можно, проблема в том, как Go интерпретирует ограничения, ограничения - это интерфейсы, а у интерфейсов не может быть полей, только тип и методы. Таким образом, можно ввести ограничение, которое будет задано структурными типами, но нельзя будет обращаться к ним, так как constraint type - это интерфейсный тип, а не структурный. В некотором смысле это даже хорошо, но почему это может быть хорошо нужно писать отдельную статью.