Одно дело когда почти весь текст "купи! по ссылке" — это будет реклама. Другое дело, когда у вас однократно встретится "код реального проекта на гитхабе смотреть здесь, посмотреть вживую тут". Такое даже в основной текст внести можно.
Не совсем понял, оно каждого пользователя просит залогиниться в его собственный Google Drive? Или работает просто как бэкэнд и абсолютно невидимо для пользователя? Если второе, то используется аккуант разработчика? Как тогда разграничивать где чьи данные? Был бы очень рад увидеть пример реального использования.
Именно прослойка (Nuklear+) бесплатна — она только упрощает код: создаёт окно и контекст, конфигурирует всё. Дальше работает Nuklear. Nuklear сколько потребляет я не знаю, для моих задач было не критично. Библиотека разрабатывалась для использования в 3d играх, не должна жрать много. Если найдете более точную информацию не забудьте скинуть сюда!
1 или 100 кб — не важно. Только фрейморки обычно добавляют как минимум десятки мегабайт… И сравнение получается уже 1 или 100 мегабайт. А здесь уже разница чувствуется. Хотя по сравнению с современным софтом в десятки гигабайт и это мелочи :-)
Хех. Периодически встречаю такие статьи в сети, в стиле "делаем супер-бурбулятор всего за 5 кб". И возникал вопрос, что раз результат такой супер, то почему он не используется в реальных приложениях? Нужно обязательно попробовать, это будет круто! libc? Не, не слышали. Только хардкор.
Проект номер раз: dxPmdxConverter. Пока было без наворотов, влазило в 16кб. Здесь было: манифест (368 байт), загрузка форм из ресурсов (и соответственно возможность визуального их редактирования!), интерфейс на двух языках, быстрое чтение файлов через MemoryMappedFile. Потом захотелось кроссплатформенного PNG — это уже 32кб, т.к. библиотеку пришлось тащить с собой… Почти успех.
Проект номер два: Winter Novel — коммерческая игрушка, продающаяся в стиме (исходники не доступны). Все использованные данные конвертированы в Си-массивы и линкуются компилятором. Версия под Windows может собираться на чистом WinAPI. Максимально ужатая полная версия игры занимает порядка 350 кб. Туда вошли: TTF, libDUMB (воспроизведение трекерных IT-файлов). И это был полный провал. Пришлось реализовать большое количество функций из стандартной библиотеки. ЕХЕ с использованием стандартной библиотеки в итоге получается даже меньше. Кроме того, чистую WinAPI-версию люто ненавидят антивирусы. От сжатия пришлось отказаться вообще — кто-то из антивирусов неадекватно реагирует даже на UPX...
Nuklear — прикольная штука. Как я понял, автор изначально сделал эту библиотеку для упрощения создания пользовательского интерфейса внутри игры. Так сказать, для главного меню и экрана опций. А в итоге вон что из библиотеки получается. Спасибо за интересное применение!
Да, в мобильных браузерах в веб-версии почему-то происходит Select, а не Click. С удовольствием приму Pull Request, исправляющий это поведение. :-)
Нативную Andorid-версию я собирать пока не пробовал. Но скорее всего скомпилируется без проблем (т.к. Open GL ES 2.0 уже есть), и работать тоже скорее всего будет нормально (т.к. люди вроде бы уже пробовали, всё у них нормально).
Я с такой задачей не сталкивался. Nuklear — это порядка 18к строк кода. Не думаю, что там внутри есть что-то подобное. Да и набор контроллов ограничен. Т.е. если планируется сложный навороченный интерфейс, то лучше взять что-нибудь другое.
Nuklear уже готов даже для коммерческих приложений
Здесь я имел ввиду, что библиотека стабильна и свой функционал предоставляет хорошо. Т.е. если нужно сделать какую-нибудь микро-утилиту с 2 кнопками, то не обязательно для этого с собой тащить Qt. Но если делать сложный UI на Nuklear — это уже скорее ближе к извращению. Для каждой задачи свой инструмент.
Ну как минимум, это зависимость от внешних сервисов. Если на сайте есть реклама, то Disqus будет или платным, или показывать свою рекламу. И чисто психологический аспект: я не контролирую свои данные (комментарии), неизвестно что с ними может там стать.
Ну и лично у меня ещё стояла задача переноса старых комментариев. Как это сделать в Disqus мне не очень понятно. Зато со Staticman нужно было просто создать соответствующие файлы, и комментарии 2007 года снова на сайте.
Прошу прощения, насчёт Netlify был не прав. По поводу отсутствия ограничений на плагины — это классно! Иногда вместо извращений с кодом можно сразу взять готовый плагин и просто его включить…
По поводу вместо двух инструментов один — не согласен. Если домен свой, то им всё-равно нужно как-то управлять. Например, где создать поддомен? Можно воспользоваться чем-то типа FreeDNS, а можно сразу напрямую использовать CloudFlare.
Ну плюшек и здесь хватает. Jekyll делался как движок для программистов — его приятно использовать. Кроме того, open source. Как следствие получаем независимость от серверов GitHub, т.к. при желании можно перенести куда угодно. Https CloudFlare даёт по умолчанию. Для доменов *.github.io GitHub даже форсит https.
Мне не совсем понятно, зачем для статических сайтов нужен URLRewrite, но в Jekyll он есть: permalink в заголовке страницы (пример).
Ограничения, конечно, есть везде. Но если использовать Jekyll по предназначению, то в них редко упираешься. А если и упёрся — то один раз делается решение, выносится в отдельный файл и просто подключается.
Да, Jekyll может далеко не всё. Мне так и не удалось узнать в Jekyll размер файла. Т.е. не получилось автоматом сделать ссылки в стиле "скачать (3 Мб)". Лично мне этот функционал в итоге так и не понадобился. Если же нужен часто, то по-моему лучше использовать более специализированные решения вроде netlify.
Аналогично, если нужно очень гибкое облако тэгов. В предложенном решении нужно всегда помнить, какие тэги вообще есть в наличии. Если создаётся новый тэг, то его нужно прописать сразу в несколько мест, что не всегда удобно. Если тэгов с (пару-тройку) десятков и создать их заранее, то решение вполне удобное и имеет право жить. Если для каждой публикации куча тэгов, часто новые, и публикуетесь часто — то опять же лучше использовать что-то другое.
Нет, не требует. Данные POST'ом отправляются роботу, который соавтор в репозитории. Он и делает коммит. Для пользователей всё абсолютно прозрачно, формочку можно на том же Ajax сделать.
Всё жду недождусь когда WinForms приложения можно будет в Linux на .Net Core перенести.
Чем чистите? После тех же обновлений Windows имеет привычку жиреть.
Ну в комментариях ссылку уж точно можно :-)
Одно дело когда почти весь текст "купи! по ссылке" — это будет реклама. Другое дело, когда у вас однократно встретится "код реального проекта на гитхабе смотреть здесь, посмотреть вживую тут". Такое даже в основной текст внести можно.
Не совсем понял, оно каждого пользователя просит залогиниться в его собственный Google Drive? Или работает просто как бэкэнд и абсолютно невидимо для пользователя? Если второе, то используется аккуант разработчика? Как тогда разграничивать где чьи данные? Был бы очень рад увидеть пример реального использования.
Или хотя бы модель: "Окулус чпокулус"
У Pocketbook 740 тоже 1 ГБ ОЗУ: https://habr.com/ru/company/pocketbook/blog/410359/
Поддерживаю мнение про большую диагональ для крупноформатных PDF.
Именно прослойка (Nuklear+) бесплатна — она только упрощает код: создаёт окно и контекст, конфигурирует всё. Дальше работает Nuklear. Nuklear сколько потребляет я не знаю, для моих задач было не критично. Библиотека разрабатывалась для использования в 3d играх, не должна жрать много. Если найдете более точную информацию не забудьте скинуть сюда!
1 или 100 кб — не важно. Только фрейморки обычно добавляют как минимум десятки мегабайт… И сравнение получается уже 1 или 100 мегабайт. А здесь уже разница чувствуется. Хотя по сравнению с современным софтом в десятки гигабайт и это мелочи :-)
Хех. Периодически встречаю такие статьи в сети, в стиле "делаем супер-бурбулятор всего за 5 кб". И возникал вопрос, что раз результат такой супер, то почему он не используется в реальных приложениях? Нужно обязательно попробовать, это будет круто! libc? Не, не слышали. Только хардкор.
Проект номер раз: dxPmdxConverter. Пока было без наворотов, влазило в 16кб. Здесь было: манифест (368 байт), загрузка форм из ресурсов (и соответственно возможность визуального их редактирования!), интерфейс на двух языках, быстрое чтение файлов через MemoryMappedFile. Потом захотелось кроссплатформенного PNG — это уже 32кб, т.к. библиотеку пришлось тащить с собой… Почти успех.
Проект номер два: Winter Novel — коммерческая игрушка, продающаяся в стиме (исходники не доступны). Все использованные данные конвертированы в Си-массивы и линкуются компилятором. Версия под Windows может собираться на чистом WinAPI. Максимально ужатая полная версия игры занимает порядка 350 кб. Туда вошли: TTF, libDUMB (воспроизведение трекерных IT-файлов). И это был полный провал. Пришлось реализовать большое количество функций из стандартной библиотеки. ЕХЕ с использованием стандартной библиотеки в итоге получается даже меньше. Кроме того, чистую WinAPI-версию люто ненавидят антивирусы. От сжатия пришлось отказаться вообще — кто-то из антивирусов неадекватно реагирует даже на UPX...
Это умеет делать Staticman
Nuklear — прикольная штука. Как я понял, автор изначально сделал эту библиотеку для упрощения создания пользовательского интерфейса внутри игры. Так сказать, для главного меню и экрана опций. А в итоге вон что из библиотеки получается. Спасибо за интересное применение!
Да, в мобильных браузерах в веб-версии почему-то происходит Select, а не Click. С удовольствием приму Pull Request, исправляющий это поведение. :-)
Нативную Andorid-версию я собирать пока не пробовал. Но скорее всего скомпилируется без проблем (т.к. Open GL ES 2.0 уже есть), и работать тоже скорее всего будет нормально (т.к. люди вроде бы уже пробовали, всё у них нормально).
Я с такой задачей не сталкивался. Nuklear — это порядка 18к строк кода. Не думаю, что там внутри есть что-то подобное. Да и набор контроллов ограничен. Т.е. если планируется сложный навороченный интерфейс, то лучше взять что-нибудь другое.
Здесь я имел ввиду, что библиотека стабильна и свой функционал предоставляет хорошо. Т.е. если нужно сделать какую-нибудь микро-утилиту с 2 кнопками, то не обязательно для этого с собой тащить Qt. Но если делать сложный UI на Nuklear — это уже скорее ближе к извращению. Для каждой задачи свой инструмент.
Я тоже хочу в GOG! Только мои игры туда почему-то не берут! x-D
Вроде бы нормально. Staticman внутри себя использует Akismet для проверки комментариев на спам.
Ну как минимум, это зависимость от внешних сервисов. Если на сайте есть реклама, то Disqus будет или платным, или показывать свою рекламу. И чисто психологический аспект: я не контролирую свои данные (комментарии), неизвестно что с ними может там стать.
Ну и лично у меня ещё стояла задача переноса старых комментариев. Как это сделать в Disqus мне не очень понятно. Зато со Staticman нужно было просто создать соответствующие файлы, и комментарии 2007 года снова на сайте.
Прошу прощения, насчёт Netlify был не прав. По поводу отсутствия ограничений на плагины — это классно! Иногда вместо извращений с кодом можно сразу взять готовый плагин и просто его включить…
По поводу вместо двух инструментов один — не согласен. Если домен свой, то им всё-равно нужно как-то управлять. Например, где создать поддомен? Можно воспользоваться чем-то типа FreeDNS, а можно сразу напрямую использовать CloudFlare.
Ну плюшек и здесь хватает. Jekyll делался как движок для программистов — его приятно использовать. Кроме того, open source. Как следствие получаем независимость от серверов GitHub, т.к. при желании можно перенести куда угодно. Https CloudFlare даёт по умолчанию. Для доменов *.github.io GitHub даже форсит https.
Мне не совсем понятно, зачем для статических сайтов нужен URLRewrite, но в Jekyll он есть: permalink в заголовке страницы (пример).
Ограничения, конечно, есть везде. Но если использовать Jekyll по предназначению, то в них редко упираешься. А если и упёрся — то один раз делается решение, выносится в отдельный файл и просто подключается.
Да, Jekyll может далеко не всё. Мне так и не удалось узнать в Jekyll размер файла. Т.е. не получилось автоматом сделать ссылки в стиле "скачать (3 Мб)". Лично мне этот функционал в итоге так и не понадобился. Если же нужен часто, то по-моему лучше использовать более специализированные решения вроде netlify.
Аналогично, если нужно очень гибкое облако тэгов. В предложенном решении нужно всегда помнить, какие тэги вообще есть в наличии. Если создаётся новый тэг, то его нужно прописать сразу в несколько мест, что не всегда удобно. Если тэгов с (пару-тройку) десятков и создать их заранее, то решение вполне удобное и имеет право жить. Если для каждой публикации куча тэгов, часто новые, и публикуетесь часто — то опять же лучше использовать что-то другое.
Нет, не требует. Данные POST'ом отправляются роботу, который соавтор в репозитории. Он и делает коммит. Для пользователей всё абсолютно прозрачно, формочку можно на том же Ajax сделать.
Библиотека виртуального терминала какая-то из уже готовых, или самописанная?