Хорошая статья, и докер — это действительно революция в деплойменте, но пару пессимистичных ноток я добавлю:
Докер не отменяет ansible. Как-то нужно ставить сам докер, обновлять хост, конфигурировать данные для контейнера (ту же базу создать или правильный конфиг подложить при деплойменте). Докер также не отменяет кучу телодвижений при разворачивании кластера, той же монги например.
логи. логгировать в sysout/syserr — ужасная идея, т.к. а) часто у приложений куда больше типов логов, а если их сливать в sysout, то потом не отпарсишь и б) сетевое логгирование не предлагать, т.к. если отправлять логи по сети синхронно, это поднимает вопрос "что делать, если получатель логов недоступен или отвечает очень медленно".
Как уже писали выше, стандартное решение для микросервисной архитектуры — OAuth2. Преимущества — изолированный сервис аутентификации, стандарт, наличие всяких интересных плюшек помимо обычной аутентификации по токену.
Что касается авторизации — я не уверен, что пихать её в nginx — хорошая идея. Логика авторизации часто зависит от конкретного приложения. Как вариант, можно настроить nginx, чтобы он сам валидировал токен и добавлял в заголовки юзернейм, а логику авторизации все-таки оставить приложению.
Всё так, на современном яваскрипте уже можно писать большие проекты. Но про стандартную библиотеку не согласен — она очень-очень-очень нужна. Почему? Потому, что она работает. Представляете? Не глючит, не имеет альтернативно одаренной имплементации, проблем с обратной совместимостью и списка поддерживаемых браузеров. А работает. ES6 делает шаги в правильном направлении, но до приличных языков его библиотеке еще расти и расти.
class A {
final static Object b = new B();
final static int S1 = 1;
final static Integer S2 = 2;
static void f() {
System.out.println(S1);
System.out.println(S2);
}
}
class B {
static {
A.f();
}
}
public class App
{
public static void main( String[] args )
{
A.f();
}
}
Помимо очевидных плюсов — минимальные первоначальные капиталовложения, экономия на поддержке, безопасность (с виртуального рабочего места крайне сложно украсть жесткий диск или переписать данные на флешку), есть и очевидные минусы:
тотальнейшая зависимость от интернета.
лаги из-за ненулевых пингов. Офисные девочки будут страдать, а программистов в такие условия вы не заманите.
Совсем неприличная зависимость бизнеса клиента от хостера таких услуг. У клиента должно быть четкое понимание, что он будет делать, если хостер удвоит цены или скажет "я устал, я ухожу".
Да-да-да, теория управления, теория цифровой обработки сигналов, дискретное преобразование Фурье, цифровые фильтры… Это совсем другой мир, и конкретно автомобили тут ни при чем — похожие проблемы возникают при компьютерном управлении любой системой из реального мира — что механической, что химической, что тепловой.
Да, умение написать на бумажке работающий рекурсивный алгоритм — очень важное качество для программиста. Это самый простой способ определить, может ли программист в принципе писать алгоритмы или его будут вгонять в ступор вещи типа «написать toString для нашего рекурсивного доменного объекта».
А что про IDE? IDE — это качественный автокомплит, линтер, навигация по исходникам и документации. Если вы хорошо знаете все нужные вам API и используете скриптовый язык (или автоматическую рекомпиляцию), то IDE не так уж и нужно. Но лично я слишком быстро меняю библиотеки и технологии, чтобы заучивать их наизусть.
Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
Подмена понятий. Можно написать аналогичный текст на тему «зачем мне IDE, гит, скрам, багтрекер, юнит-тесты, приемочные тесты, дженкинс, автоматический деплоймент, если я хочу написать hello world для лабораторки в универе».
Надеюсь, все понимают жизненную необходимость всего вышеперечисленного для больших проектов. А теперь попытайтесь это объяснить человеку, который писал лабораторки на паскале.
С распределенными отказоустойчивыми системами всё то же самое.
В статье небольшая неточность — большинство бизнесов продаются за десятикратную годовую прибыль. Почему так? Покупатель получает бизнес, который приносит 10% годовых от вложенных средств (т.е. от стоимости покупки). В случае с приложениями всё сложнее из-за деградации стоимости актива, но принцип остается тот же — при продаже через несколько лет покупатель должен остаться с 10% годовых прибыли.
У перевода сильно страдает литературный стиль — не говорят так по-русски. В дальнейшем имеет смысл после такого перевода «начерно» бить его на абзацы и излагать своими словами, сохраняя смысл. Почему в школе никогда не рассказывают о том, как важно уметь писать сочинения?
По теме — в тексте есть одна умная мысль — с точки зрения бизнеса функционал и время, потраченное непосредственно на кодинг функционала важнее, чем архитектура, красота и повторное использование.
Перфекционизм хорош в больших командах, когда твой код видит много людей и знания о проекте передаются по наследству. В бизнесе прежде всего — время. Раньше покажешь людям, раньше соберешь отзывы, раньше получишь клиентскую базу, раньше пойдут первые деньги.
Моё мнение — что для своего кода главное, чтобы ты смог через полгода вспомнить, что это вообще такое и как его запускать. Поэтому — модульность, документирование модулей, автоматизация сборки и деплоймента, самодокументируемость (все запускаемые приложения при старте должны выдавать вменяемый хелп о назначении и возможных параметрах конфигурации). А внутри может быть что угодно, лишь бы работало хорошо.
В программировании UI есть один тонкий момент — нужно уметь различать одинаковые части интерфейса и похожие части интерфейса.
Повторное использование первых — хорошо. Повторное использование вторых приведет к россыпям костылей для каждого конкретного случая и очень хрупкому коду.
Проблема же в том, чтобы понимать, когда надо обобщать, а когда надо плюнуть на DRY и скопипастить.
Вот про песочницу — не верю. Без разницы, как это называть — «песочница» или «мы еще не собрали о сайте все данные», но факт — сайт набирает свой вес в поисковой выдаче минимум несколько месяцев.
Как не переходить на темную сторону? Там же печеньки!
А если серьезно, сложная защита от копирования может негативно сказаться на репутации. Сломают её все равно, но Интернет будет набит отзывами «Программа XYZ тупит/падает/глючит и т.п.». Разумеется, без указания, что это ломаная версия.
в большинстве случаев достаточно обновить хосты и то небольшое число контейнеров, которые затронуты этой уязвимостью.
Что касается авторизации — я не уверен, что пихать её в nginx — хорошая идея. Логика авторизации часто зависит от конкретного приложения. Как вариант, можно настроить nginx, чтобы он сам валидировал токен и добавлял в заголовки юзернейм, а логику авторизации все-таки оставить приложению.
null
1
2
Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
Надеюсь, все понимают жизненную необходимость всего вышеперечисленного для больших проектов. А теперь попытайтесь это объяснить человеку, который писал лабораторки на паскале.
С распределенными отказоустойчивыми системами всё то же самое.
Вышенаписанное про цены в валюте естественно.
По теме — в тексте есть одна умная мысль — с точки зрения бизнеса функционал и время, потраченное непосредственно на кодинг функционала важнее, чем архитектура, красота и повторное использование.
Перфекционизм хорош в больших командах, когда твой код видит много людей и знания о проекте передаются по наследству. В бизнесе прежде всего — время. Раньше покажешь людям, раньше соберешь отзывы, раньше получишь клиентскую базу, раньше пойдут первые деньги.
Моё мнение — что для своего кода главное, чтобы ты смог через полгода вспомнить, что это вообще такое и как его запускать. Поэтому — модульность, документирование модулей, автоматизация сборки и деплоймента, самодокументируемость (все запускаемые приложения при старте должны выдавать вменяемый хелп о назначении и возможных параметрах конфигурации). А внутри может быть что угодно, лишь бы работало хорошо.
Но все равно мешает проклятый перфекционизм :-)
Повторное использование первых — хорошо. Повторное использование вторых приведет к россыпям костылей для каждого конкретного случая и очень хрупкому коду.
Проблема же в том, чтобы понимать, когда надо обобщать, а когда надо плюнуть на DRY и скопипастить.
А если серьезно, сложная защита от копирования может негативно сказаться на репутации. Сломают её все равно, но Интернет будет набит отзывами «Программа XYZ тупит/падает/глючит и т.п.». Разумеется, без указания, что это ломаная версия.
ps. мне одному кажется, что лису поймали в очень неудачный для нее момент?