Редактировать hosts удобно, когда есть только один клиентский компьютер.
У меня же помимо ноутбука еще телефон и планшет. DNS нужен в любом случае.
по поводу IP — не вижу, каким образом это могло помочь в моей ситуации. Вместо запоминания портов мне бы пришлось запоминать IP-адреса. --network=host просто работает. Никакие вопросы безопасности меня не интересуют, это моя личная сеть.
Ну, учитывая, что я ничего не понимаю в сабже, я не вижу никакой проблемы в bind9. Установил и настроил за 10 минут, даже не вдаваясь в тех. детали (если не считать проблемы с bonjour). В конечном итоге все сводится к "работает — не трогай"
с таким же успехом можно деплоить и с локальной машины, с помощью скриптов. В чем смысл вашего подхода? В том, что тревис неожиданно упасть может? Это смех
Смысл поста в том, чтобы продемонстрировать, что веб-приложения с гитхаба могут "изкаробки" деплоиться на pages с помощью бесплатного и известного travis ci
Для меня документация к утилите, генерирующей проект (не фреймворк), не является авторитетом.
Директория public используется многими фреймворками и должна использоваться для хранения статических файлов, которые должны быть доступны "as is" для отдачи сервером. В пример можно привести рельсы и express (хотя там название все же опционально). Вы же предлагаете там хранить файлы конфигурации хостинга. Подход с добавлением файла в public проще, но все так же является костылем. И то, что об этом написано в документации (причем документации к утилите), этого не отменяет
Да, все верно. При билде даже выводится сообщение, говорящее об этом.
Но лично меня это не спасло в некоторых случаях (однако вина была полностью на мне, следует полагать).
В любом случае, с этой проблемой можно столкнуться и следует держать это в уме.
Я ответил Вам, почему считаю такой подход неразумным.
Мой код не должен знать что-то о тонкостях хостинга и зависеть от него. CNAME — это черта исключительно github.io, соответственно, она должна находиться только в коде, осуществляющим деплой.
Anyway, я считаю оба варианта костыльными, так что кому что
Думал об этом. Но тогда будет костыль с лежащим в public/ (я думал, что лучше в build/ и под гит занести) файлом CNAME, а так все, что относится к деплою хотя бы хранится в одном конфиге, я считаю это меньшим из зол. Остальному коду должно быть плевать на деплой
С пунктом про серый цвет на цветном фоне, как потенциальный "зритель", не согласен.
Я ничего не понимаю в дизайне, и у меня не какой-то навороченный монитор. Я сравниваю два изображения, и светлый оттенок цвета фона в глаза бросается гораздо сильнее. Да еще и режет глаз немного своей светлостью.
Прекрасное дополнение! Совсем вылетело это из головы.
Однако, это не совсем то, о чем я говорил (хотя стоило это добавить).
Фича, которую выпилили, подменяла константу в случае, если был указан неправильный путь к ней. Причем, там все достаточно хитро. Например:
# 1.rb
class A; end
class B; end
A::B # вернет A, но выдаст предупреждение
# 2.rb
class A; end
module M; end
M::A # ==> NameError
Эта фича срабатывает только при явных ошибках в коде (явное указание неправильного пути к константе) и действительно является поводом ненависти:) Хотя лично я проблемы с ней встречал всего пару раз в каком-то легаси коде.
Истинно так.
Главное соблюдать уровни абстракции. А конкретную низкоуровневую реализацию всегда можно понять, немного углубившись.
я бы еще слово "взломал" заменил англицизмом "хакнул", т.к. "взломал" не особо подходит по смыслу.
Терминология, конечно, вещь не самая приятная:(
Привет:)
Да, проброс сокета нужен для билда образов. Это не единственный способ, но он мне показался самым понятным и простым.
Документация
Редактировать hosts удобно, когда есть только один клиентский компьютер.
У меня же помимо ноутбука еще телефон и планшет. DNS нужен в любом случае.
по поводу IP — не вижу, каким образом это могло помочь в моей ситуации. Вместо запоминания портов мне бы пришлось запоминать IP-адреса. --network=host просто работает. Никакие вопросы безопасности меня не интересуют, это моя личная сеть.
Ну, учитывая, что я ничего не понимаю в сабже, я не вижу никакой проблемы в bind9. Установил и настроил за 10 минут, даже не вдаваясь в тех. детали (если не считать проблемы с bonjour). В конечном итоге все сводится к "работает — не трогай"
Да, хорошая идея. Но я не в той ситуации, когда это может мне облегчить жизнь (слишком мало всего)
Интересное замечание. Спасибо.
Но я дилетант и речь идет о домашней системе, так что...=)
с таким же успехом можно деплоить и с локальной машины, с помощью скриптов. В чем смысл вашего подхода? В том, что тревис неожиданно упасть может? Это смех
Смысл поста в том, чтобы продемонстрировать, что веб-приложения с гитхаба могут "изкаробки" деплоиться на pages с помощью бесплатного и известного travis ci
Для меня документация к утилите, генерирующей проект (не фреймворк), не является авторитетом.
Директория public используется многими фреймворками и должна использоваться для хранения статических файлов, которые должны быть доступны "as is" для отдачи сервером. В пример можно привести рельсы и express (хотя там название все же опционально). Вы же предлагаете там хранить файлы конфигурации хостинга. Подход с добавлением файла в public проще, но все так же является костылем. И то, что об этом написано в документации (причем документации к утилите), этого не отменяет
Не понимаю, зачем Вы продолжаете этот тред.
как видите, в тревисе этот функционал есть из коробки=)
Да, все верно. При билде даже выводится сообщение, говорящее об этом.
Но лично меня это не спасло в некоторых случаях (однако вина была полностью на мне, следует полагать).
В любом случае, с этой проблемой можно столкнуться и следует держать это в уме.
Спасибо!
Я ответил Вам, почему считаю такой подход неразумным.
Мой код не должен знать что-то о тонкостях хостинга и зависеть от него. CNAME — это черта исключительно github.io, соответственно, она должна находиться только в коде, осуществляющим деплой.
Anyway, я считаю оба варианта костыльными, так что кому что
Спасибо за наводку!
Быстро сейчас глянул. Как я понял, он нужен для деплоя с локальной машины. У меня же деплой происходит через CI.
Т.е. от меня требуется просто запушить изменения в мастер, CI запустит тесты, билд и если все ок, то задеплоит уже на github.io
не соглашусь.
Мне не нужен файл CNAME на моем сайте. Мне он нужен в репозитории github, чтобы github pages адекватно работал с доменом.
Приложение может быть задеплоено и в другом месте. Так что в
public/на мой взгляд этому файлу точно делать нечегоДумал об этом. Но тогда будет костыль с лежащим в
public/(я думал, что лучше вbuild/и под гит занести) файлом CNAME, а так все, что относится к деплою хотя бы хранится в одном конфиге, я считаю это меньшим из зол. Остальному коду должно быть плевать на деплойС пунктом про серый цвет на цветном фоне, как потенциальный "зритель", не согласен.
Я ничего не понимаю в дизайне, и у меня не какой-то навороченный монитор. Я сравниваю два изображения, и светлый оттенок цвета фона в глаза бросается гораздо сильнее. Да еще и режет глаз немного своей светлостью.
ЗЫ Пост добавил в закладки. Спасибо
нет, это абсолютно та же самая ситуация. Вы предлагаете отказаться от динамики в пользу строгости.
Иногда это имеет смысл. Но не постоянно.
Поэтому и нужно знать язык, на котором пишешь, чтобы понимать, когда нужно написать строже, а когда нет.
Почему бы тогда не проверять типы в каждом методе?
А лучше — сменить язык на джаву.
Это просто неудобно:) В быту знание таких "тонкостей" не так уж часто пригождается, однако кто предупреждает, тот вооружен.
опечатался.
A::BвернетBПрекрасное дополнение! Совсем вылетело это из головы.
Однако, это не совсем то, о чем я говорил (хотя стоило это добавить).
Фича, которую выпилили, подменяла константу в случае, если был указан неправильный путь к ней. Причем, там все достаточно хитро. Например:
Эта фича срабатывает только при явных ошибках в коде (явное указание неправильного пути к константе) и действительно является поводом ненависти:) Хотя лично я проблемы с ней встречал всего пару раз в каком-то легаси коде.
Anyway, спасибо огромное за ценный комментарий