Комментарии 65
Есть еще довольно интересный Nikola
Использовал MiddleMan, когда писал на Ruby, очень нравился по куче причин и сделать личный блог с довольно сложными требованиями на нём не составило большого труда.
Хотя в статье не хватает статических блогогенераторов на Go: Hugo и Gostatic, особенно хорош последний. Вот чего не хватает в вашем материале — так это замеров средней скорости генерации. MM генерирует секунд за 15 у меня. Напрягает! © Буйнов
Хотя в статье не хватает статических блогогенераторов на Go: Hugo и Gostatic, особенно хорош последний. Вот чего не хватает в вашем материале — так это замеров средней скорости генерации. MM генерирует секунд за 15 у меня. Напрягает! © Буйнов
Про Gostatic слышал, сегодня почитаю о нем поподробнее.
Насчет средней скорости генерации — если честно, никогда об этом не думал. И как ее подсчитать, чтобы получился объективный и репрезентативный результат?
Насчет средней скорости генерации — если честно, никогда об этом не думал. И как ее подсчитать, чтобы получился объективный и репрезентативный результат?
У gostatic'а дока очень лаконичная, так что поначалу может быть немного тяжело, но он умеет генерировать скелет простенького сайта (gostatic -i name). Можно тут спрашивать, если что. :)
Ну подсчитать — смотря какой точности хочется. Если просто прикинуть — то попробовать сделать сайт страниц на 500 для каждого генератора более-менее одинаковый по сложности (со вложенными темплейтами, етц). Я сконвертировал свой сайт с cyrax'а на gostatic и вышло типа 10-15 секунд против трети секунды: github.com/piranha/gostatic#speed
Ну подсчитать — смотря какой точности хочется. Если просто прикинуть — то попробовать сделать сайт страниц на 500 для каждого генератора более-менее одинаковый по сложности (со вложенными темплейтами, етц). Я сконвертировал свой сайт с cyrax'а на gostatic и вышло типа 10-15 секунд против трети секунды: github.com/piranha/gostatic#speed
Спасибо за отзыв, очень приятно. :)
Салют!
Middleman и Jekyll/Octopress не стоит ставить в один ряд, у них разные цели.
Jekyll/Octopress позволяют с минимальными усилиями запустить сайт проекта или блог, они предоставляют готовые дизайны.
Готовых дизайнов для Middleman вы не найдете. Всё нужно собирать ручками, зато его возможности шире. Оущения от работы с ним близки к таковым от Rails и Padrino. Удел Middleman — сайты с индивидуальным дизайном и статические прототипы фронтенда.
Я плотно работал с Middleman, с удовольствием отвечу на вопросы.
Middleman и Jekyll/Octopress не стоит ставить в один ряд, у них разные цели.
Jekyll/Octopress позволяют с минимальными усилиями запустить сайт проекта или блог, они предоставляют готовые дизайны.
Готовых дизайнов для Middleman вы не найдете. Всё нужно собирать ручками, зато его возможности шире. Оущения от работы с ним близки к таковым от Rails и Padrino. Удел Middleman — сайты с индивидуальным дизайном и статические прототипы фронтенда.
Я плотно работал с Middleman, с удовольствием отвечу на вопросы.
Подскажите, а у Middleman есть возможность работать с изображениями (генерация превью заданного размера), может с помощью плагинов?
Да, конечно: github.com/nhemsley/middleman-thumbnailer
Хм, моя статейка всё-таки пригодилась.
Не вполне понимаю, как заполнялась колонка «Деплой».
Если это всё генераторы статических сайтов, то собранный каждым из них результат можно при помощи чего угодно загрузить на сервер, отдающий файлы по HTTP.
Способ поддержки FTP для Octopress, по сути является написанием задания для системы сборки (
… т. е. деплой поддерживается во всех случаях на что угодно, куда можно загружать файлы при помощи командной строки. Тот же Nanoblogger можно с минимумом усилий деплоить и с помощью Git, что почему-то в его графе отсутствует. А FTP и rsync таким образом должно поддерживаться вообще всеми перечисленными.
Поправьте меня, если я в чём-то неправ.
А также совершенно не раскрыта тема наличия или отсутствия подсветки синтаксиса. Слишком узкая фича?
Не вполне понимаю, как заполнялась колонка «Деплой».
Если это всё генераторы статических сайтов, то собранный каждым из них результат можно при помощи чего угодно загрузить на сервер, отдающий файлы по HTTP.
Способ поддержки FTP для Octopress, по сути является написанием задания для системы сборки (
rake), которая дёргает стороннюю программу (lftp) с целью загрузки указанной директории на сервер. И этот способ, по идее, должен работать с чем угодно, его можно адаптировать и на другие системы, в том числе написать аналог на bash.… т. е. деплой поддерживается во всех случаях на что угодно, куда можно загружать файлы при помощи командной строки. Тот же Nanoblogger можно с минимумом усилий деплоить и с помощью Git, что почему-то в его графе отсутствует. А FTP и rsync таким образом должно поддерживаться вообще всеми перечисленными.
Поправьте меня, если я в чём-то неправ.
А также совершенно не раскрыта тема наличия или отсутствия подсветки синтаксиса. Слишком узкая фича?
Незаслуженно обойдены вниманием генераторы Hexo и Assemble, оба на NodeJS. У обоих очень широкие возможности. Например, встроенной поддержкой интернационализации i18n может похвастать далеко не каждый генератор.
На базе NodeJS есть несколько генераторов попроще, но тоже достаточно популярных: Metalsmith, Harp, Wintersmith.
Мне особо импонирует генератор Techy, реализованный целиком посредством task-runner'а Gulp. Сам его еще не пробовал, но есть подозрение, что, имея минималистичный функционал, он может оказаться самым гибким по настройке и наиболее расширяемым, благодаря огромной базе плагинов Gulp.
На базе NodeJS есть несколько генераторов попроще, но тоже достаточно популярных: Metalsmith, Harp, Wintersmith.
Мне особо импонирует генератор Techy, реализованный целиком посредством task-runner'а Gulp. Сам его еще не пробовал, но есть подозрение, что, имея минималистичный функционал, он может оказаться самым гибким по настройке и наиболее расширяемым, благодаря огромной базе плагинов Gulp.
Ruby, Python… а где же PHP?
А вот он: sculpin.io/ — генератор статических сайтов написанный на PHP поверх фреймворка Symfony 2, расширяется с помощью Symfony бандлов (аля плагины такие). Умеет читать Markdown, Twig и Html. Гибкая конфигурация с помощью YAML.
А вот он: sculpin.io/ — генератор статических сайтов написанный на PHP поверх фреймворка Symfony 2, расширяется с помощью Symfony бандлов (аля плагины такие). Умеет читать Markdown, Twig и Html. Гибкая конфигурация с помощью YAML.
С генераторами на PHP я сталкивался, но в обзор они не вошли лишь потому, что с нашим облачным хранилищем они несовместимы.
За информацию о Sculpin спасибо, обязательно почитаю.
За информацию о Sculpin спасибо, обязательно почитаю.
Есть интересная CMS Kirby, написанная на PHP, которая тоже основана на файловой системе вместо базы, но генерирует сайт на лету.
Кстати да, файловые CMS — хорошая тема!
Я вот не так давно присматривался к picocms.org — a «flat file» CMS.
Я вот не так давно присматривался к picocms.org — a «flat file» CMS.
На middleman отлично реализована работа с assets(так ре как в Rails) + поддержка haml и sass из коробки, ну и конечно coffee
Пользовал Hugo, написанным на Go — штука крутая, с годной документацией и активно дорабатывается комьюнити. Лично мне оттуда оказался удобен auto reload из коробки.
github.com/spf13/hugo
github.com/spf13/hugo
Думал, раз упомянут Jekyll, то будет упомянут и Hakyll.
www.staticgen.com/ неплохая и удобная подборка статических генераторов сайтов, в том числе доступны фильтры поиска.
Пытался пользовать bytexpert.ru/webproject/, но с некоторой версии запутался в усложнившемся интерфейсе.
Кстати, в 10 году так же были перечислены некоторые генераторы
habrahabr.ru/post/93499/
Кстати, в 10 году так же были перечислены некоторые генераторы
habrahabr.ru/post/93499/
Да, WebProject сложноват получился и не очень удобен, непонятно куда элементы добавлять и как их настраивать. Сейчас я на его основе сделал ещё вариант, но уже с другим подходом — добавление и редактирование элементов сайта прямо в окне предварительного просмотра как в онлайновых CMS. Плюсом к тому перевёл программу на использование Хромиум в качестве веб-движка и подключил компилятор less, так что теперь можно собирать сайты с использованием bootstrap. Вообще программа получилась — что-то типа фреймворка для генерации разного типа сайтов, т.е. многое зависит от шаблона. Пока эта программа не выпущена, планирую к концу сентября.
На прежней WebProject версии я сделал весьма внятный прототип для сайта (надо было обозначить компоновку и рубрикацию), вручил людям. Правда, люди переписали его на чём-то другом. Тем не менее, я свою функцию выполнил чётко и с удовольствием.
Пользуясь случаем, приношу свои благодарности! :-) (за прежнюю версию) ;-)
Извините меня за тупость, но мне, как бывшему программисту (да, я туп, пользовался RAD-ами, все ментальные усилия потратил на бизнес-логику вместо вникания в архитектуры), кажется так:
0) Основные блоки все известны — меню (верхнее горизонтальное, левое-правое вертикальные), тэги, новости/блог, галерея, карточка в галерее (фото, цена, ТТХ), заглавие (хэдер), крошки, фильтр по тэгам, окно поиска, подвал (футер), скроллинг (полной страницы или с сохранением хэдера), карта… (конечно не все названные статичны).
1) Если бы возможно было как, например, в Delphi, набросать на окно эти типовые панели, с докованием. Учитывая размер, который задаётся dran-n-drop/ом. А даже учитывая и поля ввода, мёртвые, но, тем не менее полезные для прототипирования.
2) Подложить под эти панели битмапы с артами. Назначить спискам единые буллеты Unicode или битмаповые. Или индивидуальные иконки для индивидуальных пунктов.
3) Определить стили текста для этих панелей.
4) Внести контент этих типовых панелей, особенно статичных, таких как пункты меню.
5) Если возможно, так же вносить (и удалять) аддитивный контент вроде новостей и единиц галерей.
6) Нажать кнопку «Генерировать», затем, опционально, «Послать», для полного счастья. Ну и «Открыть/Сохранить шаблон+контент проекта», естественно.
7) Опционально: открыть доступ для плагинов, типа вставки текстовой информации, подсветки синтаксиса и так далее.
Вот за такой я бы не поскупился и полсотни долларов отдать. Хотя массовый пользователь может считать иначе, вероятно 14.95…
Можно было бы сразу разработчику на глазах клиента прототипы корректировать. А другие клиенты могли бы и сами пользоваться, если им динамичный функционал не нужен.
Или я чего-то не понимаю? В Delphi же работает. Мне не понятно, почему за двадцать лет никто не сделал такого же для html.
Пользуясь случаем, приношу свои благодарности! :-) (за прежнюю версию) ;-)
Извините меня за тупость, но мне, как бывшему программисту (да, я туп, пользовался RAD-ами, все ментальные усилия потратил на бизнес-логику вместо вникания в архитектуры), кажется так:
0) Основные блоки все известны — меню (верхнее горизонтальное, левое-правое вертикальные), тэги, новости/блог, галерея, карточка в галерее (фото, цена, ТТХ), заглавие (хэдер), крошки, фильтр по тэгам, окно поиска, подвал (футер), скроллинг (полной страницы или с сохранением хэдера), карта… (конечно не все названные статичны).
1) Если бы возможно было как, например, в Delphi, набросать на окно эти типовые панели, с докованием. Учитывая размер, который задаётся dran-n-drop/ом. А даже учитывая и поля ввода, мёртвые, но, тем не менее полезные для прототипирования.
2) Подложить под эти панели битмапы с артами. Назначить спискам единые буллеты Unicode или битмаповые. Или индивидуальные иконки для индивидуальных пунктов.
3) Определить стили текста для этих панелей.
4) Внести контент этих типовых панелей, особенно статичных, таких как пункты меню.
5) Если возможно, так же вносить (и удалять) аддитивный контент вроде новостей и единиц галерей.
6) Нажать кнопку «Генерировать», затем, опционально, «Послать», для полного счастья. Ну и «Открыть/Сохранить шаблон+контент проекта», естественно.
7) Опционально: открыть доступ для плагинов, типа вставки текстовой информации, подсветки синтаксиса и так далее.
Вот за такой я бы не поскупился и полсотни долларов отдать. Хотя массовый пользователь может считать иначе, вероятно 14.95…
Можно было бы сразу разработчику на глазах клиента прототипы корректировать. А другие клиенты могли бы и сами пользоваться, если им динамичный функционал не нужен.
Или я чего-то не понимаю? В Delphi же работает. Мне не понятно, почему за двадцать лет никто не сделал такого же для html.
А вот эти less и bootstrap меня путают. Это часа три технически подкованному человеку изучать и настраивать. Фильтр против массового пользователя. Надо на винде портативную копию без конфигурации компа и инсталляции терабайта cygwin-а и erlang-а.
P.S. опечатка. Читать «типа вставки табличной информации» вместо «типа вставки текстовой информации».
P.S. опечатка. Читать «типа вставки табличной информации» вместо «типа вставки текстовой информации».
Не… тут вся фишка в том, что у меня в программе всё доступно из коробки. Т.е. установил программу и всё. При сборке сайта бутстрап пересобирается из less исходников прозрачно для пользователя, ничего настраивать не нужно.
Кроме этого сам less файл собирается во время сборки проекта и поэтому есть возможность в элементы из которых состоит сайт добавлять фрагменты less со стилями которые относятся именно к этому элементу.
Кроме этого сам less файл собирается во время сборки проекта и поэтому есть возможность в элементы из которых состоит сайт добавлять фрагменты less со стилями которые относятся именно к этому элементу.
Мне кажется каждый делает как это видится ему и часто взгляды на то как надо делать идеальный статический HTML генератор просто не совпадают. Вот народ вроде бы MUSE от Adobe пользуется и вполне доволен.
Программы для статических сайтов я бы разделил на 2 категории, основанные на шаблонизаторе и с произвольным html кодом каждой страницы. Плюсы и минусы каждого подхода понятны. Программисту ближе и понятнее шаблонизатор и структура сайта, обычным пользователям визуальный подход как в Word-е.
В новой версии есть шаблонизатор и структура данных, но хочется чего-то визуального. И я сейчас хочу сделать что-то типа конструктора сайта со страницами из html-заготовок. Хочу взять за основу bootstrap и составлять каждую страницу сайта путём добавления заготовок: меню, слайдер, фото, текст, видео и т.п. с возможностью редактирования html и css (less). Т.е. добавил заготовку на страницу и потом подредактировал html. Ну и с возможностью публикации и сохранения. Для небольших сайтов может вполне хватить.
Программы для статических сайтов я бы разделил на 2 категории, основанные на шаблонизаторе и с произвольным html кодом каждой страницы. Плюсы и минусы каждого подхода понятны. Программисту ближе и понятнее шаблонизатор и структура сайта, обычным пользователям визуальный подход как в Word-е.
В новой версии есть шаблонизатор и структура данных, но хочется чего-то визуального. И я сейчас хочу сделать что-то типа конструктора сайта со страницами из html-заготовок. Хочу взять за основу bootstrap и составлять каждую страницу сайта путём добавления заготовок: меню, слайдер, фото, текст, видео и т.п. с возможностью редактирования html и css (less). Т.е. добавил заготовку на страницу и потом подредактировал html. Ну и с возможностью публикации и сохранения. Для небольших сайтов может вполне хватить.
Меня текстовые конфигурации радуют, но только и исключительно в аспекте запихивания их в контроль версий вместо бинарных конфигураций. А вот открывать и править текстовые конфиги руками я избегаю.
Во-1, они часто автоматически генерируются, и сложно угадать не перекроет ли следующий билд мои модификации.
Во-2, действительно ли нужно тратить специальное время на изучение их синтаксиса?
А вы предполагаете, что ваш клиент бросится css врукопашную редактировать?
Сильно ли я ошибаюсь в том, что даже многие IT-шники с радостью бы взяли в оборот визуальный инструмент для непрофильных задач без необходимости его тоже глубоко изучать?
Впрочем, «будем посмотреть». Буду счастлив, если обнаружу визуальный html редактор a-la RAD Borland. Непослушность Komposer/а меня окончательно добила на фронте веба.
Disclaimer: всё мною написанное воспринимать как IMHO.
Во-1, они часто автоматически генерируются, и сложно угадать не перекроет ли следующий билд мои модификации.
Во-2, действительно ли нужно тратить специальное время на изучение их синтаксиса?
А вы предполагаете, что ваш клиент бросится css врукопашную редактировать?
Сильно ли я ошибаюсь в том, что даже многие IT-шники с радостью бы взяли в оборот визуальный инструмент для непрофильных задач без необходимости его тоже глубоко изучать?
Впрочем, «будем посмотреть». Буду счастлив, если обнаружу визуальный html редактор a-la RAD Borland. Непослушность Komposer/а меня окончательно добила на фронте веба.
Disclaimer: всё мною написанное воспринимать как IMHO.
Согласен, HTML и CSS вручную редактировать удовольствие сомнительное. И моя мысль была изначально все сделать через диалоги настроек, где пользователь мог бы выбрать цвет, шрифт, картинку и т.п. Но в последнее время появилось много инструментов позволяющих составлять страницу из заранее созданных блоков и на выходе получить html код, мне они весьма приглянулись. Появилась мысль выпустить программу пока с простым bootstrap шаблоном в который можно было бы добавлять заранее заготовленные блоки типа сниппетов c bootsnipp.com/ После добавления можно было бы редактировать текст добавленного фрагмента, а при необходимости открыть html/css и поправить что нужно вручную.
По поводу боязни, что очередной билд что-то перепишет — да, такая опасность есть. Но как раз в вышеописанном варианте в элементе будет храниться сразу html/css поэтому очередной билд или смена шаблона дизайн поломать не должны, ну если что-то глобальное что-то типа смены версии bootstrap.
По поводу боязни, что очередной билд что-то перепишет — да, такая опасность есть. Но как раз в вышеописанном варианте в элементе будет храниться сразу html/css поэтому очередной билд или смена шаблона дизайн поломать не должны, ну если что-то глобальное что-то типа смены версии bootstrap.
А, ну со сниппетами выглядит перспективно, если они эластичны по размерам — как дизайнер растянет или как разрешение посетителя сплющит.
Особенно если они будут совместимы между конструкторами (иначе кто будет наполнять экосистему?), и совместимы между собой чтобы быть визуально и по данным бесшовными (чтобы не оказалось, что один общается с мускулом, другой с носкулом, третий с xml, а их фоновые картинки не сходятся в единую). Хотя, чую риск этого очень велик.
Особенно если они будут совместимы между конструкторами (иначе кто будет наполнять экосистему?), и совместимы между собой чтобы быть визуально и по данным бесшовными (чтобы не оказалось, что один общается с мускулом, другой с носкулом, третий с xml, а их фоновые картинки не сходятся в единую). Хотя, чую риск этого очень велик.
Вот как раз bootstrap и решает все эти задачи: он адаптивный, т.е. подстраивается под экран и стандартный. А дополнительные стили можно будет добавить к каждому отдельному элементу и они попадут в итоговый css.
Т.е. можно будет добавить на страницу новый нестандартный элемент просто добавив в настройки элемента html и css с сайта. Ну и если фантазировать дальше, то можно сделать что-то типа своей библиотеки из таких своих элементов и добавить возможность скопировать/вставить через буфер обмена.
У меня в программе есть возможность копировать/вставлять элементы сайта через буфер обмена. Формат там простой текстовый xml поэтому даже можно будет c сайта или письма этот xml скопировать в буфер обмена и потом вставить на страницу как элемент.
Т.е. можно будет добавить на страницу новый нестандартный элемент просто добавив в настройки элемента html и css с сайта. Ну и если фантазировать дальше, то можно сделать что-то типа своей библиотеки из таких своих элементов и добавить возможность скопировать/вставить через буфер обмена.
У меня в программе есть возможность копировать/вставлять элементы сайта через буфер обмена. Формат там простой текстовый xml поэтому даже можно будет c сайта или письма этот xml скопировать в буфер обмена и потом вставить на страницу как элемент.
Jekyll очень медленный. Для личного блога или сайт компании — пойдет. Для чего-то большего — нет. Мой личный опыт: Jekyll (на сайте из дополнительных аддонов только простейшая система тегов) генерирует 5000 страниц около часа.
Так что советую всем использовать любой другой генератор, но только не Jekyll.
Так что советую всем использовать любой другой генератор, но только не Jekyll.
Использовал Pelican — впечатления самые позитивные.
К нему еще есть целая куча тем, которые вполне можно корректировать, особенно, если более-менее в теме Jinja и, если не ошибаюсь, Flask.
Быстро работает, без проблем деплоится, очень удобно конфигурится.
Я делал make сначала в тестовый сайт на проде, потом уже — в основной…
Все работает, есть не просит, даже люди используют, совершенно ничего в этом не понимающие. Только распечатку с синтаксисом маркдауна главное не терять 8-)
К нему еще есть целая куча тем, которые вполне можно корректировать, особенно, если более-менее в теме Jinja и, если не ошибаюсь, Flask.
Быстро работает, без проблем деплоится, очень удобно конфигурится.
Я делал make сначала в тестовый сайт на проде, потом уже — в основной…
Все работает, есть не просит, даже люди используют, совершенно ничего в этом не понимающие. Только распечатку с синтаксисом маркдауна главное не терять 8-)
Извиняюсь если немного не в тему. А вот допустим генерация статического HTML сайта из какой-то CMS? Зачем кэшировать php, хранить данные в БД, если можно статикой отдавать. Я не имею в виду динамику типа поиска, авторизацию, итп. Но есть же куча корпоративных сайтов где контент меняется раз в месяц, а сайт жужжит на какой-то CMS, увеличивая нагрузку там, где она не нужна.
Есть ли такие решения — я пользуюсь тем чем привык — а на фронт энд деплою уже результат работы CMS?
Есть ли такие решения — я пользуюсь тем чем привык — а на фронт энд деплою уже результат работы CMS?
Teleport, Offline Explorer ;-)
Надо, наверное, смотреть плагины для конкретных CMS. По идее, тот же кеш — это, по сути, и есть статические страницы, так что всё возможно.
Кэш — это память. SSL+PHP Это проц+пмять. А там где можно было бы обойтись VPS живет VDS итп. Реально, есть ли инструмент для чайников? Вот я, например, сделал кому-то сайт на одной из удобных популярных CMS, клиент чайник, ему только цапы нажимать. Можно начать свой такой проект, но может что-то уже есть?
Ну вот, например, плагин для wordpress. Нагуглил по «wordpress plugin static site generator». Думаю, для других популярных CMS можно также найти аналогичные.
Это еще безопасность выводит на уровень выше… Боевая CMS в оффлайне — на фронт энде только результаты…
Ваше облачное хранилище последние 3 месяца постоянно глючит при аплоаде файлов по FTP.
И поддержка уже месяц не может с этим разобраться, только кормят обещаниями и сожалениями.
И поддержка уже месяц не может с этим разобраться, только кормят обещаниями и сожалениями.
Пока не было, но думаю с вашей вводной я попробую.
Я с полгода назад написал простенький генератор статического сайта на MS PowerShell.
Использовался Twitter Bootstrap + Jquery.
Из нужных мне плюшек — автогенерация бокового/верхнего меню (правда стили еще допиливать), и индексы для каталогов где, допустим лежит очень много .markdown файлов и список этих страниц в index.htm можно забыть обновить (так собирался каталог с рассказами моими, например).
Использовался Twitter Bootstrap + Jquery.
Из нужных мне плюшек — автогенерация бокового/верхнего меню (правда стили еще допиливать), и индексы для каталогов где, допустим лежит очень много .markdown файлов и список этих страниц в index.htm можно забыть обновить (так собирался каталог с рассказами моими, например).
Согласен. Тоже не понял почему они в одной категории. Octopress так вообще просто сборка Jekyll с готовыми темами. Потому, что на руби?
А так же:
Почему такая явно не любовь к руби?
Давайте про питон тоже поговорим:
А так же:
- Rubygems поставляется вместе с ruby уже несколько лет
- Ставить rbenv не надо
- 1.9.3 вполне хватает для запуска свех трех движков
- Напмоню, что 1.9.3 вышла в 2011 году
- Версии до 1.9.3 уже встретили свой EOL
- Ruby который идет вместо с последний OS X вполне хватит для этой задачи
- В FreeBSD и Debian подобных дистрибутивах GNU/Linux можно безболезнено установить всежий руби из PPA. (во freebsd вероятно перестанет работать portupgrade, но он не нужен)
Почему такая явно не любовь к руби?
Давайте про питон тоже поговорим:
- Вам потребуется установить pip
- Так как питон не может нормально в зависимости вам придется ставить virtual env
- Так как делать все руками тупо, вам придется поставить virtualenv-wrapper
Я не автор статьи, но отвечу.
Руби лично для меня — темный лес.
А питон по умолчанию есть почти в любой сборке linux.
И pip, по-моему, тоже. И в любом случае лично я обязательно ставлю и pip, и virtualenv.
И тот же pelican вообще без вопросов заводится и так. Это уже от перфекционизма — в virtualenv его пихать…
Руби лично для меня — темный лес.
А питон по умолчанию есть почти в любой сборке linux.
И pip, по-моему, тоже. И в любом случае лично я обязательно ставлю и pip, и virtualenv.
И тот же pelican вообще без вопросов заводится и так. Это уже от перфекционизма — в virtualenv его пихать…
А питон по умолчанию есть почти в любой сборке linux.
Но мир не ограничивается сборками линукса. И помоему кроме как в одомашеных он нигде не стоит из коробки. Я тому, что проблемы руби в статье высосаны из пальца.
В OS X точно надо было ставить pip руками.
Это уже от перфекционизма — в virtualenv его пихать…
Прочел тему, но так и не понял — в чем смысл генерации статических сайтов?
Чем это лучше какой-либо CMS без базы например?
Чем это лучше какой-либо CMS без базы например?
1. скорость загрузки страниц
2. возможность хоститься на самых дешёвых хостингах
3. безопасность
4. простота бекапа
2. возможность хоститься на самых дешёвых хостингах
3. безопасность
4. простота бекапа
5. Прототипирование.
1. и 2. Скорость и ст-ть хостинга — наверно, хотя мне кажется времена когда для сайта-визитки нехватало мощностей хостога прошли…
3. Этот пункт пожалуй можно окенить как преимущество
4. для flat file cms технически тоже самое.
5. Прототипирование — в чем отличие от прототипирования на flat file cms? на и в целом на любой другой более мнее простой cms…
3. Этот пункт пожалуй можно окенить как преимущество
4. для flat file cms технически тоже самое.
5. Прототипирование — в чем отличие от прототипирования на flat file cms? на и в целом на любой другой более мнее простой cms…
А какие есть CMS без базы?
GetSimple CMS вполне приятная
Я тоже копал эту тему. Поставил следующие требования: Jade + SASS + Coffeescript с перегенерацией на лету. В итоге остановился просто на собственноручно собранном конфиге для Gulp, который ко всему еще и минифицирует картинки, ужимает CSS и JS, конвертирует TTF в EOT/WOFF для иконочных шрифтов.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, на видел этот проект. Я вообще как-то к yeoman прохладно отнесся изначально. Возможно стоит его покопать поглубже.
Но меня реально полностью устраивает мой «велосипед» ко всему прочему. Вчера, например, я прикрутил минуты за 3 парсинг конфигов для шаблонов в формате YAML. Проблема со всеми готовыми решениями в том, что если я хочу добавить, скажем, тот же YAML, мне нужно либо найти готовое решение, либо копать список issues на гитхабе в надежде, что кто-то уже задавал пободный вопрос, либо в конце концов делать свой модуль (разобравшись как это делается).
Но меня реально полностью устраивает мой «велосипед» ко всему прочему. Вчера, например, я прикрутил минуты за 3 парсинг конфигов для шаблонов в формате YAML. Проблема со всеми готовыми решениями в том, что если я хочу добавить, скажем, тот же YAML, мне нужно либо найти готовое решение, либо копать список issues на гитхабе в надежде, что кто-то уже задавал пободный вопрос, либо в конце концов делать свой модуль (разобравшись как это делается).
Не нашел где можно установить Content-Encoding (у Amazon S3 такая возможность есть). Плохо искал?
Как я понял такой возможности нет: developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fstorage.selectel.ru%2F
pycon.ru сделан на базе carcade.readthedocs.org/en/latest/, например.
:)
:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбираем генератор статических сайтов