Ну, естественно. Это мейджор релиз. Он предполагает что обратная совместимость не гарантируется. Такие миграции сначала делают на резервном сервере. Уверен, что в Release Notes/Changelog'ах всё подобные грабли описаны, на все грабли не по разу "наступлено", и рекомендации как на них не наступать выработаны. А так, да... Опыт - сын ошибок трудных.
Еще косвенная-косвенная и инкремент/декремент для косвенной косвенной… Это получается семь, а поскольку это задаётся для обоих операндов, то можно считать комбинации режимов. Тогда вообще сложность зашкаливает…
Для меня простота, когда ты можешь понять что делает программа просто читая восмеричный код. Для вас в количестве режимов адресации? Ну, окей, пусть так.
Хм… Мой пардон… Тогда снимаю свой, можно сказать, «наезд» на счет Паскаля. В вашем случае это вполне нормально, вы еще не профессиональный разработчик.
Пишите статьи от себя. Не надо пытаться выглядеть «крутым» разработчиком. Вы и так достаточно круты для своего уровня. Я, по крайней мере, в ваши годы не умел так хорошо излагать свои мысли…
В общем я с вами согласен. Go — хороший язык для изучения в качестве первого языка. Пока не дойдет до конкурентных вычислений. Там уже требуется иметь теоретический бэкграунд. Параллельные/многопоточные вычисления это отдельная дисциплина…
Главный же плюс Go, в отличие от того же Паскаля — это актуальность…
Это все прекрасно, но частотный диапазон WiFi в обычном многоквартирном доме засран, дальше некуда… Обеспечить надежную работу системы в таких условиях будет реальной проблемой…
Как вы можете утверждать много/немного, если сами говорите, что плохо знаете Паскаль?.. ))
Единственное, что есть принципиального у Go, чего нет в Паскале — это интерфейсы, замыкания и, в большинстве реализаций Паскаля, функций как базового типа. Всё остальное то же самое, кроме того, что в Паскале:
— Присваивание :=
— Точка с запятой в конце инструкции ставится всегда
— Переменные объявляются всегда
— Есть цикл while
Чтобы было что обобщать, надо для начала научиться делать частности. Генерики формируют дополнительный слой абстракции, который на начальном этапе не нужен…
"… Реализация требовалась на паскале, а я паскаль знаю очень плохо..."
Уж лучше бы вы не позорили гоферов. После такой заявки как-то рассуждать о Go, как языке обучения, мягко говоря, не комильфо…
Паскаль самое что ни на есть прямое подмножество языка Go, только нет интерфейсов и фигурные скобки заменяются на begin/end. Ну еще пара несущественных нюансов…
Исходная информация будет в биллинге… Делаем возможность тегировать абонентов в биллинге и далее агреггируем данные абонентов по тегам… Это довольно дежурный функционал…
>> А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Для нужд управленческого учета информация по каждому клиенту попросту не нужна. Минимальная разбивка агреггированные данные по категориям клиентов, например: Физлица/Юрлица, Частный сектор/Микрорайоны/сельская местность и так далее… Причем это разбивка может меняться в зависимости от принятой учётной политики, маркетинговых целей и кучи всего остального чуть ли не каждый год, а то и чаще…
Биллинг — это прежде всего система обслуживания клиента. Он относится к УУ и БУ как один из инструментов, источников информации…
Попытка сделать её непосредственной частью системы управленческого учета (или бухгалтерского) приводит к нездоровому усложнению системы. Применение бухгалтерских терминов лишь усугубляет неправильное восприятие, тут вы правы.
Тролли? А что вас так заусило?
Оптимизация за счет использования более специфических, не библиотечных алгоритмов, оптимизированнных под конкретную реализацию языка, это новость разве что для новичков…
Опять же не вижу в этом ничего плохого. Кто-то новичкам должен рассказать про разницу между использованием библиотечных функций и самописных, оптимизированных под конкретную задачу и конкретный транслятор…
Но опять же, чтобы новичкам например знать о «туповатой реализации bool в pypy» надо наверное написать свою реализацию python'a.
И? Какова мораль? Для новичков мораль конкретная: учите asm (дабы понимать разницу между туповатой реализацией и «нетуповатой») и учите классические алгоритмы.
А для не новичков?
Похоже это просто пиар своей платформы. Впрочем не вижу в этом ничего плохого. ))
Странный способ убеждать продажника. Обычно им достаточно на бумажке подсчитать сколько времени займёт набор новой команды и переписывание. И пояснить, что развитие проекта на это время придётся полностью остановить…
Ну, естественно. Это мейджор релиз. Он предполагает что обратная совместимость не гарантируется. Такие миграции сначала делают на резервном сервере.
Уверен, что в Release Notes/Changelog'ах всё подобные грабли описаны, на все грабли не по разу "наступлено", и рекомендации как на них не наступать выработаны.
А так, да... Опыт - сын ошибок трудных.
Нормальный бриф адекватного курса DBA. Всё по теме.
Пишите статьи от себя. Не надо пытаться выглядеть «крутым» разработчиком. Вы и так достаточно круты для своего уровня. Я, по крайней мере, в ваши годы не умел так хорошо излагать свои мысли…
В общем я с вами согласен. Go — хороший язык для изучения в качестве первого языка. Пока не дойдет до конкурентных вычислений. Там уже требуется иметь теоретический бэкграунд. Параллельные/многопоточные вычисления это отдельная дисциплина…
Главный же плюс Go, в отличие от того же Паскаля — это актуальность…
>>— Присваивание :=
Единственное, что есть принципиального у Go, чего нет в Паскале — это интерфейсы, замыкания и, в большинстве реализаций Паскаля, функций как базового типа. Всё остальное то же самое, кроме того, что в Паскале:
— Присваивание :=
— Точка с запятой в конце инструкции ставится всегда
— Переменные объявляются всегда
— Есть цикл while
Остальные различия чисто косметические…
Уж лучше бы вы не позорили гоферов. После такой заявки как-то рассуждать о Go, как языке обучения, мягко говоря, не комильфо…
Паскаль самое что ни на есть прямое подмножество языка Go, только нет интерфейсов и фигурные скобки заменяются на begin/end. Ну еще пара несущественных нюансов…
Для нужд управленческого учета информация по каждому клиенту попросту не нужна. Минимальная разбивка агреггированные данные по категориям клиентов, например: Физлица/Юрлица, Частный сектор/Микрорайоны/сельская местность и так далее… Причем это разбивка может меняться в зависимости от принятой учётной политики, маркетинговых целей и кучи всего остального чуть ли не каждый год, а то и чаще…
Попытка сделать её непосредственной частью системы управленческого учета (или бухгалтерского) приводит к нездоровому усложнению системы. Применение бухгалтерских терминов лишь усугубляет неправильное восприятие, тут вы правы.
Оптимизация за счет использования более специфических, не библиотечных алгоритмов, оптимизированнных под конкретную реализацию языка, это новость разве что для новичков…
Опять же не вижу в этом ничего плохого. Кто-то новичкам должен рассказать про разницу между использованием библиотечных функций и самописных, оптимизированных под конкретную задачу и конкретный транслятор…
Но опять же, чтобы новичкам например знать о «туповатой реализации bool в pypy» надо наверное написать свою реализацию python'a.
И? Какова мораль? Для новичков мораль конкретная: учите asm (дабы понимать разницу между туповатой реализацией и «нетуповатой») и учите классические алгоритмы.
А для не новичков?
Странный способ убеждать продажника. Обычно им достаточно на бумажке подсчитать сколько времени займёт набор новой команды и переписывание. И пояснить, что развитие проекта на это время придётся полностью остановить…