Все же, надо отметить, что языковая нагрузка, т.е. количество задач, связанных с разными языками всё-таки неравномерна.
Да, сравнение со строительной бригадой от части уместно, но при условии, что наша бригада большую часть времени занимается плиточными работами и изредка нужно сделать что-то по электрике.
Так и тут: большая часть задач — это php разработка, но при этом команда иногда делает задачи, требующих знания других технологий и языков.
Вероятно, при этом код на другом языке будет не совсем идиоматичным, но это не делает его плохим.
Зато появляется возможность применить подходящую технологию там, где ей место, не ограничиваясь одним языком, а для ребят появляются точки роста и развития.
Эх, это же ведь все просто исторический очерк и в следующей статье будет рассказано, как все это было заменено на один из популярных инструментов, ведь правда?
Правила оформления кода — это самый безобидный, простой и к тому же автоматизируемый способ поддерживать читабельность и чистоту. От нарушения каждого отдельного правила в каждом отдельном месте мозг не взорвется, но вот если каждый в проекте будет писать так, как ему вздумается, то взрыв как раз таки наступит очень скоро. И чтобы не тратить дни на бессмысленные споры типа табы или пробелы и придуман кодстайл.
У кого-то наступает выгорание от того, что линтер просит поменять порядок импортов? Толи ещё будет, когда к такому человеку придет бизнес с хард дедлайном!
Ваш пример не проще. Вы реализуете специальную конструкцию, где у основного метода run нужно ещё не забывать вызывать task.Tick(), тем самым вы фактически переизобретаете корутины, только корявого вида.
Ещё раз хочу обратить Ваше внимание, что контекст не имеет отношения к многозадачности, это лишь способ переноса информации.
Возвращаясь опять к вашему примеру, нет, вам не удастся со своей библиотекой сосредоточиться на бизнес-логике. Во, первых вам надо будет помнить про упомянутый выше Tick, что уже завязывает вашу логику на библиотеку. Во вторых, вы не сможете ничего заканселить, если внутри метода у вас будет например http вызов: вам придется городить внутри сложный механизм и все равно в итоге вы начнёте работать с context.Context.
В стандартном гошном подходе вы бы просто написали несколько функций с контекстом в качестве первого параметра и в основном методе запустили бы их в корутинах, в вашем же случае — попытка сделать что-то похожее не генераторы в php.
Для статьи стоило бы показать пример решения вашей задачи на стандартных механизмах голанга и потом с помощью вашей библиотеки. Пока выглядит как переусложнение там, где не нужно. Паттерны разумеется в го применимы, и command, и job, и любые другие, но как и всегда, если это обосновано чем-то
Интерфейсы в го в большинстве случаев стоит делать только на стороне потребителя.
Т.е. вполне можно иметь просто тип Task, так как у вас нет разных типов задач, требующих обобщения. Если же в будущем они появятся — можно будет ввести интерфейс.
А пользователь вашей библиотеки вполне может у себя завести интерфейс с нужными ему методами и использовать его в меру необходимости, так как в отличии от php в го применим duck-typing
Вы все время упоминаете context.Context, что он нужен для асинхронности или корутин. Но ведь это не так: контекст, как сообщает нам официальная документация — это переносчик состояния процесса или, что более специфично, текущего api вызова.
Чаще всего контекст используется для хранения в нем специфичной для запроса информации (например, проброса такой информации, как трейсинг), а также прокидывания сигналов отмены.
Т.е., с его помощью можно контролировать выполнение нижележащих вызовов, например задавать таймауты запросов.
Самое главное, что контекст понимают все встроенные в язык пакеты, связанные с какими-либо вызовами, а также все другие библиотеки.
Почему вы его противопоставляете своему подходу с джобами?
Пытаться искать общие точки и на их фоне попробовать стать не джуном, а выше. Ведь позиция складывается из нескольких вещей:
степень самостоятельности
знание языка и его экосистемы
Причем первое скорее имеет приоритет над вторым.
Если вы синьор в мобильной разработке, то скорее всего по первому пункту уже явно должны проходить не на джуна и в любой другой области.
С точки зрения языка и экосистемы надо смотреть на варианты либо с переходом на тот же язык, что у вас уже есть (например, андроид разработчик на Java-бекенд), либо активно учить язык в свободное время (это не так сложно обычно).
Ещё вариант перейти внутри своей компании, если есть такая возможность. Это самый простой путь, так как вас уже знают.
Судя по всему, php постепенно и придет к тому, что типы будут везде. Уже сейчас в большинстве проектов считается обязательным как минимум для нового кода использовать типизацию. Пока ещё невозможно это делать для переменных, но думаю, что и там тоже типы добавятся со временем.
Не думаю, что язык когда-либо станет строго типизированные, поскольку это сломает обратную совместимость в куче проектов, но то, что через некоторое время типы будут применяться повсеместно, это точно. И скорее всего такой код будет работать быстрее, чем код без типов.
Во-первых, с появлением возможности указывать типы язык не перестал быть языком с динамической типизацией.
Во-вторых, есть немало проектов, которые переписывать никто не будет, а вот внедрить в них потихоньку типизацию с целью увеличения качества кода вполне можно.
В-третьих, типизация не делает язык лучше всех остальных, она лишь привносит ещё одно улучшение, которое можно применять с целью сделать свой код качественнее.
А почему нет? Например, в тех же тестах часто есть конструкции вида MyClass|TestObject и теперь это можно законно использовать на уровне языка, а не аннотаций.
Смотря что понимать под фичами. Первые задачи могут быть готовы и на второй день (в теории), но часто сложность общего функционала все-таки выше, чтобы человек, который второй день работает с проектом, мог сразу выкатить что-то существенное в прод
Наш подход позволяет при необходимости публиковать одно и тоже событие из любого сервиса, на любом из поддерживаемых языков, так как кодогенератор способен создать dto события и клиент автоматически.
Тем не менее, мы стараемся не делать так, чтобы одно событие публиковалось из разных источников, так как воспринимаем сообщения, публикуемые в шину доменными событиями систем, а не командами. Появление двух разных сервисов, публикующих одно и тоже событие означало бы, что у нас появляется несколько источников правды.
С другой стороны: у многих продукт это именно веб-приложение.
Действительно, PHP подходит для реализации систем со сложной бизнес логикой, где поддерживаемость кода в будущем имеет приоритет на скоростью работы приложения. Но в то же время не могу не отметить, что в большинстве таких случаев, сегодня использование PHP имеет скорее исторические корни: уже много написали, дорого переписывать и плюсы переписывания не очевидны.
Мы держим АТОЛ в облаке для фискализации всех операций, которые происходят без физического участия сотрудников: онлайн платежи на сайте, возвраты и т.п. Это очень удобно именно для онлайн платежей и интернет магазинов, которые не осуществляют физические рассчеты на месте. Надеемся, что скоро станет законодательно возможно и оффлайн рассчеты тоже фискализировать через онлайн кассы.
При этом работать с физической кассой также можно из PHP — в нем есть необходимые средства для реализации как бинарных протоколов, а АТОЛ вообще имеет встроенный в кассу веб-сервер.
Однако, в нашем случае физические кассы — это кассы на пунктах выдачи товаров и у наших торговых представителей, распределенные по всем регионам России, которые не возможно просто так подключить к какому-то одному серверу. Поэтому для работы с ними мы не используем PHP напрямую, а используем наше же ПО для торговых представителей, которое представляет собой нативное Android приложение.
К сожалению, в тот момент мы не смогли добиться того, чтобы номад не убивал прежний контейнер, не дождавшись работоспособного нового. Возможно, в более новых его версиях это возможно, но в имевшейся у нас в то время на продакшене — так не работало
Все же, надо отметить, что языковая нагрузка, т.е. количество задач, связанных с разными языками всё-таки неравномерна.
Да, сравнение со строительной бригадой от части уместно, но при условии, что наша бригада большую часть времени занимается плиточными работами и изредка нужно сделать что-то по электрике.
Так и тут: большая часть задач — это php разработка, но при этом команда иногда делает задачи, требующих знания других технологий и языков.
Вероятно, при этом код на другом языке будет не совсем идиоматичным, но это не делает его плохим.
Зато появляется возможность применить подходящую технологию там, где ей место, не ограничиваясь одним языком, а для ребят появляются точки роста и развития.
Эх, это же ведь все просто исторический очерк и в следующей статье будет рассказано, как все это было заменено на один из популярных инструментов, ведь правда?
Линтер не поменяет, потому что поменяет форматер. Он для того и придуман, чтобы вообще о таких мелочах не думать и вручную не править
Правила оформления кода — это самый безобидный, простой и к тому же автоматизируемый способ поддерживать читабельность и чистоту. От нарушения каждого отдельного правила в каждом отдельном месте мозг не взорвется, но вот если каждый в проекте будет писать так, как ему вздумается, то взрыв как раз таки наступит очень скоро. И чтобы не тратить дни на бессмысленные споры типа табы или пробелы и придуман кодстайл.
У кого-то наступает выгорание от того, что линтер просит поменять порядок импортов? Толи ещё будет, когда к такому человеку придет бизнес с хард дедлайном!
Ваш пример не проще. Вы реализуете специальную конструкцию, где у основного метода run нужно ещё не забывать вызывать task.Tick(), тем самым вы фактически переизобретаете корутины, только корявого вида.
Ещё раз хочу обратить Ваше внимание, что контекст не имеет отношения к многозадачности, это лишь способ переноса информации.
Возвращаясь опять к вашему примеру, нет, вам не удастся со своей библиотекой сосредоточиться на бизнес-логике. Во, первых вам надо будет помнить про упомянутый выше Tick, что уже завязывает вашу логику на библиотеку. Во вторых, вы не сможете ничего заканселить, если внутри метода у вас будет например http вызов: вам придется городить внутри сложный механизм и все равно в итоге вы начнёте работать с context.Context.
В стандартном гошном подходе вы бы просто написали несколько функций с контекстом в качестве первого параметра и в основном методе запустили бы их в корутинах, в вашем же случае — попытка сделать что-то похожее не генераторы в php.
Да, и паниковать при ошибках плохая практика.
Для статьи стоило бы показать пример решения вашей задачи на стандартных механизмах голанга и потом с помощью вашей библиотеки. Пока выглядит как переусложнение там, где не нужно. Паттерны разумеется в го применимы, и command, и job, и любые другие, но как и всегда, если это обосновано чем-то
Интерфейсы в го в большинстве случаев стоит делать только на стороне потребителя.
Т.е. вполне можно иметь просто тип Task, так как у вас нет разных типов задач, требующих обобщения. Если же в будущем они появятся — можно будет ввести интерфейс.
А пользователь вашей библиотеки вполне может у себя завести интерфейс с нужными ему методами и использовать его в меру необходимости, так как в отличии от php в го применим duck-typing
Вы все время упоминаете context.Context, что он нужен для асинхронности или корутин. Но ведь это не так: контекст, как сообщает нам официальная документация — это переносчик состояния процесса или, что более специфично, текущего api вызова.
Чаще всего контекст используется для хранения в нем специфичной для запроса информации (например, проброса такой информации, как трейсинг), а также прокидывания сигналов отмены.
Т.е., с его помощью можно контролировать выполнение нижележащих вызовов, например задавать таймауты запросов.
Самое главное, что контекст понимают все встроенные в язык пакеты, связанные с какими-либо вызовами, а также все другие библиотеки.
Почему вы его противопоставляете своему подходу с джобами?
Добавьте тогда в список ещё Windows и Office.
А если серьезно, какое отношение большая часть программ имеет к тайм-менеджементу?
Какой-то случайный набор программ.
Пытаться искать общие точки и на их фоне попробовать стать не джуном, а выше. Ведь позиция складывается из нескольких вещей:
Причем первое скорее имеет приоритет над вторым.
Если вы синьор в мобильной разработке, то скорее всего по первому пункту уже явно должны проходить не на джуна и в любой другой области.
С точки зрения языка и экосистемы надо смотреть на варианты либо с переходом на тот же язык, что у вас уже есть (например, андроид разработчик на Java-бекенд), либо активно учить язык в свободное время (это не так сложно обычно).
Ещё вариант перейти внутри своей компании, если есть такая возможность. Это самый простой путь, так как вас уже знают.
Судя по всему, php постепенно и придет к тому, что типы будут везде. Уже сейчас в большинстве проектов считается обязательным как минимум для нового кода использовать типизацию. Пока ещё невозможно это делать для переменных, но думаю, что и там тоже типы добавятся со временем.
Не думаю, что язык когда-либо станет строго типизированные, поскольку это сломает обратную совместимость в куче проектов, но то, что через некоторое время типы будут применяться повсеместно, это точно. И скорее всего такой код будет работать быстрее, чем код без типов.
Во-первых, с появлением возможности указывать типы язык не перестал быть языком с динамической типизацией.
Во-вторых, есть немало проектов, которые переписывать никто не будет, а вот внедрить в них потихоньку типизацию с целью увеличения качества кода вполне можно.
В-третьих, типизация не делает язык лучше всех остальных, она лишь привносит ещё одно улучшение, которое можно применять с целью сделать свой код качественнее.
А почему нет? Например, в тех же тестах часто есть конструкции вида MyClass|TestObject и теперь это можно законно использовать на уровне языка, а не аннотаций.
Наш подход позволяет при необходимости публиковать одно и тоже событие из любого сервиса, на любом из поддерживаемых языков, так как кодогенератор способен создать dto события и клиент автоматически.
Тем не менее, мы стараемся не делать так, чтобы одно событие публиковалось из разных источников, так как воспринимаем сообщения, публикуемые в шину доменными событиями систем, а не командами. Появление двух разных сервисов, публикующих одно и тоже событие означало бы, что у нас появляется несколько источников правды.
Важный момент с ConfigMap состоит в том, что в них нельзя положить файлы неограниченного размера.
Так как ConfigMap хранятся в базе etcd, то лимит на их размер равен 1 мегабайту.
С другой стороны: у многих продукт это именно веб-приложение.
Действительно, PHP подходит для реализации систем со сложной бизнес логикой, где поддерживаемость кода в будущем имеет приоритет на скоростью работы приложения. Но в то же время не могу не отметить, что в большинстве таких случаев, сегодня использование PHP имеет скорее исторические корни: уже много написали, дорого переписывать и плюсы переписывания не очевидны.
При этом работать с физической кассой также можно из PHP — в нем есть необходимые средства для реализации как бинарных протоколов, а АТОЛ вообще имеет встроенный в кассу веб-сервер.
Однако, в нашем случае физические кассы — это кассы на пунктах выдачи товаров и у наших торговых представителей, распределенные по всем регионам России, которые не возможно просто так подключить к какому-то одному серверу. Поэтому для работы с ними мы не используем PHP напрямую, а используем наше же ПО для торговых представителей, которое представляет собой нативное Android приложение.