Яндекс хотя-бы идет на такой шаг осознанно и может себе такое позволить.
и в более мелких конторах иногда приходится велосипедить с такими вещами
Видите ли путь библиотеки (например парсера JSON) на реализации только начинается. Самое важное — что будет потом: огромное количество тестов, кейсы использования, примеры реализации, замеры производительности и выпуск релизов.
Как только библиотекой начинают пользоваться — 90% работы уходит на тесты и сопровождение. Как бы вы не старались, такой огромный масштаб работы спрятать не получится, поэтому ситуация когда:
Не все кто «сверху» к этому бывают морально готовы...
имеет все шансы закончиться для вас крайне печальным образом.
Разумеется я не ставлю под сомнение, что в некоторых случаях даже «самостийная и краснознаменная реализация» JSON — оправдана (если ваша компания называется «Яндекс» например).
Но это должна быть полноценная и согласованная сверху разработка — с тестами и релизами, не подпольная партизанщина в корпоративном проекте ради строчки в резюме.
Если вам принципиально, то достаточно давно существует утилита jpackage, поставляемая в составе JDK, с помощью которой можно генерировать готовые запускабельные бинарники с упакованным внутрь Java-приложением.
Проект из статьи запросто превращается в запускаемый бинарник размером ~ 3Мб без зависимости от JDK/JRE в системе.
К сожалению эта интересная технология немного опоздала и в нынешних реалиях не особо кому нужна, поэтому акцентировать на такой возможности в статье не стал.
Реляционная СУБД уж слишком большая и сложная в плане реализации, не влезет в ~ 1000 строк никак. Вот пример такого проекта, написанный лектором для курса по устройству реляционных баз данных.
Писать собственный шаблонизатор — чуть более спорная затея.
Ага а собственная реализация недопарсера JSON — прям божья благодать ) Весь этот проект целиком — не более чем упражение, применять такие подходы в реальном проекте стоит только если вы очень хорошо разбираетесь в теме.
До формата книги я пока не дорос, несмотря на глобальность опыта все же считаю что нужно нечто большее чем просто компетенции для такого.
Но вообще у меня достаточно специфическое отношение к технической литературе - большинство таких книг считаю унылым говном слишком уж скучными и пафосными для излагаемой темы.
«фреймворк» — от фразы «frame of work», что в дословном переводе означает «направление работы».
Смысл существования любого фреймворка — дать возможность реализации конечного функционала со своей помощью в строго заданном направлении.
Поэтому выход за рамки направления работ у используемых фреймворков является самым проблемным местом в современной разработке — просто потому что Баба Яга сам фреймворк против таких действий.
То что я реализовал в рамках статьи является не фреймворком а конечным приложением, без каких либо внешних фреймворков и библиотек вообще — в этом и был смысл: показать чего стоит реализация бизнес‑логики «голыми руками».
Слушайте, это все конечно круто и замечательно, но вы разбираете код, основной задачей которого является минимально возможная реализация и отсутствие внешних зависимостей, поэтому идеи из серии:
не нужно привязываться к реализации коллекций
или:
то можно было бы написать адаптер для удобного использования.
мягко говоря - неактуальны.
Вы бы еще исходники какого-нибудь демо под Амигу взяли и начали описывать как можно код улучшить с точки зрения обычной корпоративной разработки, ей-богу.
но за почти 30 лет использования FreeBSD я единственный раз столкнулся (по причине power outage в процессе обновления) с фатальным несоответствием userland и kernel
как-то подозрительно редко для столь солидного стажа, поскольку еще лет 15-20 назад "make world" было делать просто модно среди BSD-шников, даже на продуктовых серверах и этим типа гордились.
А указанное несоответствие словить очень просто до сих пор - достаточно собрать ядро из CURRENT ветки и все - userland сразу отъедет. Сложно правда сказать насколько фатально, благо он легко чинится загрузкой с флешки и копированием архива с базовой ОС.
По-моему, с годами их наоборот становится всё больше и больше, если говорить в контексте “Linux-based OS versus any other Unix-like OS
Вам стоит посмотреть вживую один из старых юниксов вроде Solaris, HP-UX или AIX, одного дня проведенного в любой из этих систем хватит чтобы полюбить и iproute2 и systemd всей душой.
Если вам сложно оценить тенденцию к унификации, то опять же разница между AIX и например Solaris это то как было раньше везде, часто отличия вводились искусственно в качестве своеобразного "vendor lock".
Дело не только в господдержке и деньгах. AutoCAD развивался десятилетиями
Да это так, было замечательное время роста и развития, когда пользователи мирились с багами и недоработками, могли довольствоваться даже простым функционалом и еще и охотно за это платили.
Сейчас же порог входа в любую продуктовую разработку невероятно высок, создать что-то с нуля мало, нужно еще как-то умудриться переманить часть пользователей существующего продукта и затем заставить их платить.
Думаю даже по комментариям к этой статье становится очевидно насколько высока инертность современных пользователей при одновременной нереальности ожиданий.
В таких условиях никаких других вариантов кроме гос.проекта просто нет.
А вы не очень умный: это надо было умудриться процитировать текст со ссылкой на JHipster и не попробовать ее даже открыть )
Если «кажется» — креститься надо, говорят помогает.
Яндекс хотя-бы идет на такой шаг осознанно и может себе такое позволить.
Видите ли путь библиотеки (например парсера JSON) на реализации только начинается. Самое важное — что будет потом: огромное количество тестов, кейсы использования, примеры реализации, замеры производительности и выпуск релизов.
Как только библиотекой начинают пользоваться — 90% работы уходит на тесты и сопровождение. Как бы вы не старались, такой огромный масштаб работы спрятать не получится, поэтому ситуация когда:
имеет все шансы закончиться для вас крайне печальным образом.
Разумеется я не ставлю под сомнение, что в некоторых случаях даже «самостийная и краснознаменная реализация» JSON — оправдана (если ваша компания называется «Яндекс» например).
Но это должна быть полноценная и согласованная сверху разработка — с тестами и релизами, не подпольная партизанщина в корпоративном проекте ради строчки в резюме.
Если вам принципиально, то достаточно давно существует утилита jpackage, поставляемая в составе JDK, с помощью которой можно генерировать готовые запускабельные бинарники с упакованным внутрь Java-приложением.
Проект из статьи запросто превращается в запускаемый бинарник размером ~ 3Мб без зависимости от JDK/JRE в системе.
К сожалению эта интересная технология немного опоздала и в нынешних реалиях не особо кому нужна, поэтому акцентировать на такой возможности в статье не стал.
Реляционная СУБД уж слишком большая и сложная в плане реализации, не влезет в ~ 1000 строк никак. Вот пример такого проекта, написанный лектором для курса по устройству реляционных баз данных.
Спасибо за теплые слова, к сожалению владелец «другого ресурса» оказался на другой стороне, поэтому посчитал невозможным дальнейшую поддержку проекта.
Ага а собственная реализация недопарсера JSON — прям божья благодать ) Весь этот проект целиком — не более чем упражение, применять такие подходы в реальном проекте стоит только если вы очень хорошо разбираетесь в теме.
Безумно плюсую, поскольку устал от
малолетнихспециалистов, в ультимативной форме требующих от меня ссылку на обои под каждой технической статьей.Вы серьезно считаете что у автора есть проблемы с опытом?
До формата книги я пока не дорос, несмотря на глобальность опыта все же считаю что нужно нечто большее чем просто компетенции для такого.
Но вообще у меня достаточно специфическое отношение к технической литературе - большинство таких книг считаю
унылым говномслишком уж скучными и пафосными для излагаемой темы.Тогда специально для вас одна из прошлых статей.
Получается все было зря? О боже мой.
Ладно, в следующей раз будет статья про реализацию HTTP-сервера на чистом ассемблере.
Да ктстати про:
«фреймворк» — от фразы «frame of work», что в дословном переводе означает «направление работы».
Смысл существования любого фреймворка — дать возможность реализации конечного функционала со своей помощью в строго заданном направлении.
Поэтому выход за рамки направления работ у используемых фреймворков является самым проблемным местом в современной разработке — просто потому что
Баба Ягасам фреймворк против таких действий.То что я реализовал в рамках статьи является не фреймворком а конечным приложением, без каких либо внешних фреймворков и библиотек вообще — в этом и был смысл: показать чего стоит реализация бизнес‑логики «голыми руками».
Слушайте, это все конечно круто и замечательно, но вы разбираете код, основной задачей которого является минимально возможная реализация и отсутствие внешних зависимостей, поэтому идеи из серии:
или:
мягко говоря - неактуальны.
Вы бы еще исходники какого-нибудь демо под Амигу взяли и начали описывать как можно код улучшить с точки зрения обычной корпоративной разработки, ей-богу.
вы невнимательно читали - в 700 строк уместился конечный проект гостевой, где авторизация лишь одна из фич.
Никаких вообще.
как-то подозрительно редко для столь солидного стажа, поскольку еще лет 15-20 назад "make world" было делать просто модно среди BSD-шников, даже на продуктовых серверах и этим типа гордились.
А указанное несоответствие словить очень просто до сих пор - достаточно собрать ядро из CURRENT ветки и все - userland сразу отъедет. Сложно правда сказать насколько фатально, благо он легко чинится загрузкой с флешки и копированием архива с базовой ОС.
Вам стоит посмотреть вживую один из старых юниксов вроде Solaris, HP-UX или AIX, одного дня проведенного в любой из этих систем хватит чтобы полюбить и iproute2 и systemd всей душой.
Если вам сложно оценить тенденцию к унификации, то опять же разница между AIX и например Solaris это то как было раньше везде, часто отличия вводились искусственно в качестве своеобразного "vendor lock".
Проблема в том что любая программная изоляция является лишь иллюзией и маркетингом — ресурсы‑то общие.
Пока у вас общий процессор работает с общей памятью — всегда будет риск утечки, есть прецеденты выхода даже из границ виртуальной машины.
Госпроекта по созданию аналога AutoCAD.
Вы про что именно?
Да это так, было замечательное время роста и развития, когда пользователи мирились с багами и недоработками, могли довольствоваться даже простым функционалом и еще и охотно за это платили.
Сейчас же порог входа в любую продуктовую разработку невероятно высок, создать что-то с нуля мало, нужно еще как-то умудриться переманить часть пользователей существующего продукта и затем заставить их платить.
Думаю даже по комментариям к этой статье становится очевидно насколько высока инертность современных пользователей при одновременной нереальности ожиданий.
В таких условиях никаких других вариантов кроме гос.проекта просто нет.