А на мощных одноплатниках и так, я думаю, обычный Ruby можно запустить. Получается очень нишевая вещь какая-то.
И да и нет. Мощные одноплатники имеют тенденцию перегреваться, что (помимо цены) несколько ограничивает их применение.
Хотя честно говоря тут сложно судить — реалии постоянно меняются, у меня на столе например стоит очень компактный NAS, внутри которого работает полноценный Linux а веб‑интерфейс крутится на полноценном Python.
Generally Ethernet is not built into microcontrollers. First you need a jack which can convert Ethernet signals into signals read by a microcontroller (this is generally called 'magnetics'). Then you need a TCP/IP stack, and then on top of that you need DHCP, DNS and whatever other protocols you want to use. So the actual microcontroller you use doesn't matter a whole lot. If you get something very powerful like an ARM with Linux running on it, then developing for it would be very simple, almost the same as writing a network application running on a desktop PC running Linux. Or you could go with something less powerful & cheaper like an AVR or PIC.
Но там же чуть ниже:
Lots of the TI Luminary microcontrollers (ARM Cortex-M3) have an onboard ethernet MAC. It needs an external crystal and ethernet PHY (connector + magnetics).
Стартовая модель включает 8 ГБ оперативной памяти и 64 ГБ внутренней памяти.
Так что думаю все несколько проще стало.
на бинарник веб-сервера
Дело в том что это не просто веб-сервер, а целый фреймворк: REST, JSON, авторизация и так далее и тому подобное.
Но главное тут в другом: встраиваемый MRuby дает отделение прикладной логики от системной части, т.е. можно реализовать отдачу html и обработку параметров на скриптах, которые при ошибке не уронят все приложение целиком, а системную часть оставить на Си.
Shortly after Borland ended the development of OWL, maintenance was taken over by a group of users led by Yura Bidus. This effort evolved into the OWLNext[1]open-source project currently hosted at the SourceForge site. OWLNext is a modern update and extension of OWL with support for the latest Windows versions and modern C++ compilers from Microsoft and Embarcadero.
Удивительные вещи творятся:
32-bit and 64-bit targets for Windows XP/Vista/7/8/10/11.
В который раз убеждаюсь что софт это в первую очередь идея, а идею хрен убьешь.
Поскольку так получилось, что в TCL/TK я тоже немногопонимаю, добавлю что:
1) Tk и Perl связаны очень долгой историей, поскольку Perl второй после Tcl язык где Tk всегда активно использовался. Для примера отрывок из статьи 2001го года:
An important advantage of using the pTk (Perl/Tk) combination is that you can write truly portable cross-platform GUI applications– applications that will work similarly across Win32, Macintosh, Linux, and even the AS/400!
2) Ставить из СPAN этот поддерживающий пакет — идея не очень если нужна портабельность. Надо ставить все же системный пакет (p5-Tk для FreeBSD), чтобы не было конфликта версий с Tk. Вся связка Perl + Tk + p5-Tk ввиду историчности и популярности присутствует в виде готовых пакетов наверное в любой ОС и дистрибутиве.
Поскольку я немного понимаю в старых системах, замечу что история с NexT и GNUstep — отличается. Отличается в первую очередь тем, что существенная часть кодовой базы и оригинальных концептов пробралась в настоящее без существенных изменений.
Xerox все же была исследовательской системой, купить и использовать которую дома или на работе обычному человеку было мало реально. А рабочие станции NeXT с самого начала были коммерческим продуктом, они продавались и использовались.
Самым известным фактом использования NeXT для разработки является создание Doom:
At the time of Doom's production, id Software was using a NeXTcube for its graphic engine development, so the NeXTSTEP version of Doom actually existed before the MS-DOS version and carries the name NeXTDoom. The application is sluggish on anything other than an Motorola 68040-based NeXTstation or NeXTcube (the more memory, the better), and has no sound support (DMX was not supported on NeXTSTEP). With OPENSTEP on the most recent i386 hardware, it runs smoothly under all conditions up to screen sizes of 400%. The released version is labeled v1.2, with programming credited to John Carmack, John Romero, and Dave Taylor.
Замечательный вопрос для человека с таким-то ником )
Постараюсь ответить максимально четко: чем меньше файлов с исходным кодом в проекте — тем меньше проблем. Для всех и вне зависимости от языка разработки.
Меньше рисков что-то потерять при коммите, меньше нерешаемых конфликтов при сведении изменений от нескольких разработчиков.
Сильно проще провести ревью коммита с парой файлов но сотней правок, нежели с сотней файлов но по паре правок в каждом.
Чем меньше исходных файлов — тем проще и быстрее идет сборка, поскольку на каждый исходный файл генерируется минимум один.class файл (для Java).
Проще даже среде разработки и поисковому индексатору, поскольку каждый отдельный файл с исходником необходимо мониторить на внешние изменения, что нагружает и диск и ОС.
Потому что до такого уровня безумия я еще не дошел, в современных браузерах есть встроенный парсер JSON, так что как минимум половина работы с форматом (клиентская часть) исчезает.
Вообще-то помимо инсталлятора создается еще и сам запускаемый рантайм (сюрприз) путем нарезания JRE, вот пример под мак (обратите внимание на каталог runtime).
~3мб достигается если выкинуть практически все модули, особенно модуль java.desktop (он самый большой).
Но скажу сразу, что для более-менее крупных приложений такое урезание невозможно, поскольку в модуль java.desktop запихана часть javax.el (Expression Language) и потому никакие Tomcat/Jetty на таком обрезанном рантайме не заработают.
Поэтому если вам действительно надо генерировать бинарник из настоящего Java-приложения, то стоит использовать GraalVM, который действительно его создает и честно падает с "page fault" при ошибках.
Но ведь дата-маппер придуман, чтобы требований к ентити не было, "пишите свою сущность", а маппер заммапит. Никто не просил обвязывать их ломбуком.
А как насчет требований оформления к самому дата мапперу? А ничего, что этим вы вводите в проект целый отдельный слой для перекладывания данных? Причем аж на уровне сборки (если вы про MapStruct), не смущает?
А что если "надо такой же но с перламутровыми пуговицами": в Entity например старый java.util.Date а в DTO уже LocalDateTime (что сплошь и рядом)? Конвертер будете писать? Для маппера?
Требования к Plain Object .
Я вас удивлю, сказав что существуют требования оформления к POJO?
(например как в го пишут и не испытывают проблем с этим
Разработка на Go сильно отличается ввиду другой культуры разработки и куда меньших проектов - не забывайте что для Java проект в 100 млн строк кода это обыденность, это даже не большой проект. В Go с учетом особенностей сборки думаю будет ад и погибель уже на одном миллионе.
Тоже пришёл к тому, что тащить современные фреймворки в небольшой новый проект, или легаси с самописом, с которого надо слезть, избыточно.
Прежде чем приходить к такому интересному выводу, рекомендую ознакомиться с проектом OWASP и посмотреть сколько новых уязвимостей сейчас выкладывают в паблик за один день.
Дальше думаю стоит оценить риски, собственные таланты и объем свободного времени — действительно ли вы готовы вкладываться в поиск уязвимостей и защиту.
И не стоит думать, что раз ваш сайт или проект не особо известны и популярны то никому не нужны — нужны в первую очередь доступные ресурсы на сервере (например для майнинга), а взлом ныне автоматический, с помощью роботов.
Проект в статье если что тестовый, в тексте специально написано несколько раз:
«не стоит так делать в реальном проекте».
Написано как раз потому что простота обманчива — существенный объем кода уходит на решения проблем с безопасностью и разумеется в 700 строк я бы просто не уложился.
Все становится гораздо прозрачнее, если строить взаимодействие между пакетами только через интерфейсы и забыть про публичные классы
К сожалению это редко когда возможно в современной разработке.
Дело в том что в большинстве случаев «ваши классы вам не принадлежат» — разработчики вынуждены соблюдать бесконечное количество правил оформления классов, вводимых тем или иным фреймворком: сеттеры/геттеры, обязательное наличие публичного конструктора, требования к модификаторам полей и самих классов.
Есть требования к JPA Entity классам, требования к POJO сериализуемым в JSON через какой-нибудь Jackson, требования к CDI бинам, требования к Repository в Spring и так далее и тому подобное.
В результате вся прикладная разработка так или иначе выстраивается вокруг запросов используемых фреймворков а не ваших архитектурных идей.
Спринг вообще в 80% случаев оверкилл, который берут чисто по привычке.
Понимаю что речь про современные вебсервисы, отдающие JSON из пары десятков однотипных методов, но если смотреть шире — Spring Framework еще очень небольшой, по сравнению с тем что живет в Java-мире.
А живет там например OSGi, который сложнее Spring наверное раза в два или RCP вроде Eclipse, первая же разработка под который будет незабываемой .
Не стоит забывать про Jakarta EE, в девичестве JEE, где каждый сервер приложений фактически является огромным фреймворком, доходящим до своего апофеоза в виде Websphere или Weblogic.
И это я еще не трогал более глобальные вещи вроде ESB или BPM, которые вообщем‑то тоже — фреймворки.
А есть еще Portlet API и Java Portals с монстрами вроде Liferay (не к ночи будет помянут), который тоже является огромным и сложным фреймворком, под который ведется разработка конечного приложения.
Вообщем переусложнение на ровном месте и бесконечное количество архитектурных слоев — конек Java.
Ну нет, сеньоры с 5-7 лет опыта как были "рабочими проектными лошадками" 10 лет назад так и остались. И врядли это изменится в будущем.
Не все разумеется, но именно из таких формируются команды разработки.
Вот там где 10+ стажа уже начинаются сложности: необучаемость, бесконечные закидоны, требования и придирки.
Ни разу не видел успешных команд (кроме своей) собранных только из ветеранов, чтобы там все не передрались и пересрались до взаимной ненависти за первые полгода работы, вот честно.
И именно поэтому я не пользуюсь всякими "генераторми проектов", где какие-то случайные люди решили, что они лучше меня знают, что именно нужно для моего проекта.
Для вашего проекта — безусловно никаких ограничений нет, но есть еще такие проекты за которые платят деньги и в большинстве случаев они вам (как разработчику) не пренадлежат.
Называется это «коммерческая разработка», которой на сегодняшний день большинство.
В тех редких случаях, когда проект создается с нуля, главную роль играет скорость создания функционала а не идейные соображения, поэтому и используют готовые шаблоны проектов.
Но это повторюсь — большая редкость и чаще всего дело приходится иметь с уже существущей и работающей системой, которую надо «просто доработать» или что‑то в ней исправить.
В этом случае думаю вполне очевидно — ничего глобального менять вам просто не дадут.
я еще меньше стал понимать смысл данной статьи
Скажем так: статья написана для моих коллег по заказной разработке, годами не вылезающих из всевозможных «кривоколенных проектов», спроектированных пьяными матросами и далеко не в самый их лучший день.
Отдых для уставшей души — временами надо увидеть, что хоть где‑то может быть по другому.
И да и нет. Мощные одноплатники имеют тенденцию перегреваться, что (помимо цены) несколько ограничивает их применение.
Хотя честно говоря тут сложно судить — реалии постоянно меняются, у меня на столе например стоит очень компактный NAS, внутри которого работает полноценный Linux а веб‑интерфейс крутится на полноценном Python.
По идее да:
Но там же чуть ниже:
И как быть?
Вообще речь про embedded разработку, что на сегодняшний день либо arduno/pi либо промавтоматика со своими законами и АСУ.
По крайней мере так обстоят дела в тех проектах к которым я имел или имею отношение - если даже в самокаты сейчас arduno ставят, чтож теперь сделаешь.
Ну даже не знаю, из соседней статьи:
Так что думаю все несколько проще стало.
Дело в том что это не просто веб-сервер, а целый фреймворк: REST, JSON, авторизация и так далее и тому подобное.
Но главное тут в другом: встраиваемый MRuby дает отделение прикладной логики от системной части, т.е. можно реализовать отдачу html и обработку параметров на скриптах, которые при ошибке не уронят все приложение целиком, а системную часть оставить на Си.
Самое крутое что я смог реализовать на перле это вот, врядли получится выше прыгнуть - все же очень старая технология.
Терзают смутные сомнения, что поддержки Wayland все же ожидать не стоит )
Когда там релиз 10й версии? Чего-то затягивать начали с новыми выпусками, из года в год все длиннее релизный цикл.
Что характерно не похоронили до сих пор:
Удивительные вещи творятся:
В который раз убеждаюсь что софт это в первую очередь идея, а идею хрен убьешь.
Поскольку так получилось, что в TCL/TK я тоже немного понимаю, добавлю что:
1) Tk и Perl связаны очень долгой историей, поскольку Perl второй после Tcl язык где Tk всегда активно использовался. Для примера отрывок из статьи 2001го года:
2) Ставить из СPAN этот поддерживающий пакет — идея не очень если нужна портабельность. Надо ставить все же системный пакет (p5-Tk для FreeBSD), чтобы не было конфликта версий с Tk. Вся связка Perl + Tk + p5-Tk ввиду историчности и популярности присутствует в виде готовых пакетов наверное в любой ОС и дистрибутиве.
Да, .Xresources до сих пор используется в современном Xorg а xsetroot все также позволяет установить обои.
Поскольку я немного понимаю в старых системах, замечу что история с NexT и GNUstep — отличается. Отличается в первую очередь тем, что существенная часть кодовой базы и оригинальных концептов пробралась в настоящее без существенных изменений.
Xerox все же была исследовательской системой, купить и использовать которую дома или на работе обычному человеку было мало реально. А рабочие станции NeXT с самого начала были коммерческим продуктом, они продавались и использовались.
Самым известным фактом использования NeXT для разработки является создание Doom:
Замечательный вопрос для человека с таким-то ником )
Постараюсь ответить максимально четко: чем меньше файлов с исходным кодом в проекте — тем меньше проблем. Для всех и вне зависимости от языка разработки.
Меньше рисков что-то потерять при коммите, меньше нерешаемых конфликтов при сведении изменений от нескольких разработчиков.
Сильно проще провести ревью коммита с парой файлов но сотней правок, нежели с сотней файлов но по паре правок в каждом.
Чем меньше исходных файлов — тем проще и быстрее идет сборка, поскольку на каждый исходный файл генерируется минимум один.class файл (для Java).
Проще даже среде разработки и поисковому индексатору, поскольку каждый отдельный файл с исходником необходимо мониторить на внешние изменения, что нагружает и диск и ОС.
Потому что
до такого уровня безумия я еще не дошел, в современных браузерах есть встроенный парсер JSON, так что как минимум половина работы с форматом (клиентская часть) исчезает.Да понятно давно что я ничего не знаю и понимаю, не утруждайте себя моей повторной оценкой, а то еще надорветесь.
Но думаю вам ваших лет опыта все же хватит, чтобы посмотреть на вещи чуть дальше терминов.
Вообще-то помимо инсталлятора создается еще и сам запускаемый рантайм (сюрприз) путем нарезания JRE, вот пример под мак (обратите внимание на каталог runtime).
За создание этого рантайма отвечает другая утилита jlink, которую jpackage вызывает при работе.
~3мб достигается если выкинуть практически все модули, особенно модуль
java.desktop (он самый большой).Но скажу сразу, что для более-менее крупных приложений такое урезание невозможно, поскольку в модуль java.desktop запихана часть javax.el (Expression Language) и потому никакие Tomcat/Jetty на таком обрезанном рантайме не заработают.
Поэтому если вам действительно надо генерировать бинарник из настоящего Java-приложения, то стоит использовать GraalVM, который действительно его создает и честно падает с "page fault" при ошибках.
А как насчет требований оформления к самому дата мапперу? А ничего, что этим вы вводите в проект целый отдельный слой для перекладывания данных? Причем аж на уровне сборки (если вы про MapStruct), не смущает?
А что если "надо такой же но с перламутровыми пуговицами": в Entity например старый java.util.Date а в DTO уже LocalDateTime (что сплошь и рядом)? Конвертер будете писать? Для маппера?
Я вас удивлю, сказав что существуют требования оформления к POJO?
Разработка на Go сильно отличается ввиду другой культуры разработки и куда меньших проектов - не забывайте что для Java проект в 100 млн строк кода это обыденность, это даже не большой проект. В Go с учетом особенностей сборки думаю будет ад и погибель уже на одном миллионе.
Прежде чем приходить к такому интересному выводу, рекомендую ознакомиться с проектом OWASP и посмотреть сколько новых уязвимостей сейчас выкладывают в паблик за один день.
Дальше думаю стоит оценить риски, собственные таланты и объем свободного времени — действительно ли вы готовы вкладываться в поиск уязвимостей и защиту.
И не стоит думать, что раз ваш сайт или проект не особо известны и популярны то никому не нужны — нужны в первую очередь доступные ресурсы на сервере (например для майнинга), а взлом ныне автоматический, с помощью роботов.
Проект в статье если что тестовый, в тексте специально написано несколько раз:
«не стоит так делать в реальном проекте».
Написано как раз потому что простота обманчива — существенный объем кода уходит на решения проблем с безопасностью и разумеется в 700 строк я бы просто не уложился.
К сожалению это редко когда возможно в современной разработке.
Дело в том что в большинстве случаев «ваши классы вам не принадлежат» — разработчики вынуждены соблюдать бесконечное количество правил оформления классов, вводимых тем или иным фреймворком: сеттеры/геттеры, обязательное наличие публичного конструктора, требования к модификаторам полей и самих классов.
Есть требования к JPA Entity классам, требования к POJO сериализуемым в JSON через какой-нибудь Jackson, требования к CDI бинам, требования к Repository в Spring и так далее и тому подобное.
В результате вся прикладная разработка так или иначе выстраивается вокруг запросов используемых фреймворков а не ваших архитектурных идей.
Понимаю что речь про современные вебсервисы, отдающие JSON из пары десятков однотипных методов, но если смотреть шире — Spring Framework еще очень небольшой, по сравнению с тем что живет в Java-мире.
А живет там например OSGi, который сложнее Spring наверное раза в два или RCP вроде Eclipse, первая же разработка под который будет незабываемой .
Не стоит забывать про Jakarta EE, в девичестве JEE, где каждый сервер приложений фактически является огромным фреймворком, доходящим до своего апофеоза в виде Websphere или Weblogic.
И это я еще не трогал более глобальные вещи вроде ESB или BPM, которые вообщем‑то тоже — фреймворки.
А есть еще Portlet API и Java Portals с монстрами вроде Liferay (не к ночи будет помянут), который тоже является огромным и сложным фреймворком, под который ведется разработка конечного приложения.
Вообщем переусложнение на ровном месте и бесконечное количество архитектурных слоев — конек Java.
Ну нет, сеньоры с 5-7 лет опыта как были "рабочими проектными лошадками" 10 лет назад так и остались. И врядли это изменится в будущем.
Не все разумеется, но именно из таких формируются команды разработки.
Вот там где 10+ стажа уже начинаются сложности: необучаемость, бесконечные закидоны, требования и придирки.
Ни разу не видел успешных команд (кроме своей) собранных только из ветеранов, чтобы там все не передрались и пересрались до взаимной ненависти за первые полгода работы, вот честно.
Для вашего проекта — безусловно никаких ограничений нет, но есть еще такие проекты за которые платят деньги и в большинстве случаев они вам (как разработчику) не пренадлежат.
Называется это «коммерческая разработка», которой на сегодняшний день большинство.
В тех редких случаях, когда проект создается с нуля, главную роль играет скорость создания функционала а не идейные соображения, поэтому и используют готовые шаблоны проектов.
Но это повторюсь — большая редкость и чаще всего дело приходится иметь с уже существущей и работающей системой, которую надо «просто доработать» или что‑то в ней исправить.
В этом случае думаю вполне очевидно — ничего глобального менять вам просто не дадут.
Скажем так: статья написана для моих коллег по заказной разработке, годами не вылезающих из всевозможных «кривоколенных проектов», спроектированных пьяными матросами и далеко не в самый их лучший день.
Отдых для уставшей души — временами надо увидеть, что хоть где‑то может быть по другому.