Странно что автор не рассмотрел действительно классику — перезагрузку оператора =. Но по вашему замечанию ни чего не мешает и += перегрузить и все остальные составные присваивания. Да приседаний много но оно будет работать всегда и везде
Товарищи, господа, дамы, PM, PO, CIO!
Ну прочтите Мифический человеко-месяц Брукса и особенно 16 главу — Серебряной пули нет.
Поймите что это писалось в 1986, что проблемы и вопросы поставленные тогда ни куда не делались и не решились. Что улучшилось только понимание проблемы, но не способы решения проблем. Начните честно признаваться с первых слов что у Scrum есть куча ограничений честно их и СРАЗУ заявите! Что гибкие методики тоже не применимы в 100%.
P.S. Перестаньте насиловать мозги.
APEX это Good! Хотя довольно часто непонятна логика и компонет и алгоритмов работы. Сравнивая APEX с Delphi, MS Acces и Delphi for PHP понимаешь Oracle-у надо еще много сделать.
Но к подаче материалом автором есть замечание. То что описывает в этой и предыдущей частях лежит на поверхность в документации, если этивещи не получается освоить самостоятельно то лучше не надо изучать данную технологию-она для вас. А в вот описать сложные задачи и рецепты и как их сделать вот то было бы супер.
Разрабатывая переносимый между платформами и БД код на Perl, C++ и Java cтолкнулся в Go с «database/sql» так больно мне не было давно… Начиная от компляции Ораклового драйвера в проект когда без работающей среды gcc не сделаешь ни чего. А мучение и боль при необходимости переключиться с MySQL на Oracle и обратно превращается в какой то ад. притом что в коде на Perl ни чего не меняется, даже в гребной Java практически ни чего (Да буде жить вечно JDBC!) ну ладно в C-x пару десятков строк. А Go… Даже не хочется начинать новые проекты на нем. Go это к сожалению не энтрпрайз и не понятно когда там все наладится. От кода:
tx, err := m.DB.Begin()
if err != nil {
return err
}
Хочется стреляться.
Вещь нужная, но не не питоне. То что автор ее на C написал позволит ее запустить даже на OpenWRT. Но еще лучше ее как модуль/правил в для примера в iptables. Как здесь ruunix.ru/597-tarpit-lovushka-v-iptables.html
Была у Atmel серия микроконтроллеров AT49K так это было FPGA + 8-bit AVR Microcontroller.
Такая была милотоа. Хочешь аппаратный реверсивный счетчик на 42-бита а пожалуйста, хочешь UART на 16-бит тоже пожалуйста (правда чуть сложнее). Хочешь контроллер на циклическую шину и это можно. Я рядышком стоит такой стандартный AVR c обычной периферией. Т.е. такой микро Zynq.Почему убили серию не понятно.
Иногда думаешь есть ли возможность упасть ниже, а потом бац и перепечатка «новости» от риа новости!
Этот опус на наводит разве что на мысли о выполнении плана по статьям. План то она может и поможет выполнить, но вот то что она откроет новое дно как для автора так и для этого сайта это очевидно.
Сколько можно!
Не надо учить программированию детей! Научите их пользоваться компьютерами!
Разработчик ПО это она из десятков тысяч профессий и количественная доля менее 1%. А вот умение пользоваться компьютерами нужно уже 30-50% людей.
Да и как можно научить программировать того кто не знает что можно сделать, а что нельзя сделать с помощью компьютера.
Детский сад какой то!
Уже лет 50 как появилась такая специальность –аналитик. В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
Так же ни кто не запрещает программисту для примера купить книжку «Бухучет» или «Современные методики выращивания гидропонных культур». Так и бухгалтеру не плохо прочитать что то типа «Основа баз данных» или «Администрирование компьютерных сетей». Хотя это все есть «изучения клингонского языка», но первый абзац ни кто не отменял.
P.S. И товарищи программисты, если вы ощущаете себя инженерами, то будьте Инженерами! Настоящий инженер это такой товарищЪ у которого так называемый кругозор или по модному soft skills это как минимум половина инженера!
ANTLR не отдаляет, а заставляет придерживаться формального похода. Реализуя свой язык под ANTLR находишь ошибки в самой постановки техзадания для своего языка. Или находить ошибки в легаси коде.
Но в общем ANTLR позволяет сосредоточиться именн на сути своего языка, а не размениваться на мелочи.
Не проще. 2 компа и шара не решает.
Проблема в том что сейчас весь софт и оконные менеджеры одно фокусные.
В ПП для примера рабочее место должно реализовывать такой поведенческий шаблон:
Разработчик (D) – пишет код в редакторе. И предположим допускает ошибку и допускаем что онлайн проверка ее сразу ловит и подчёркивает. Но D не должен отрываться от разработки на решение данной ошибки, у него мысль в потоке реализации глобального алгоритма.
Ревьюер/вьюер (V) – видя эту ошибку уводит свой указатель на свою часть экрана/второй монитор и предположим изучает сеть или доки на данную тему и находит решение. Видя когда D закончит «алгоритмическую мысль» словесно говорит «есть решении проблемы смотри». Потом ctrl+c/ctrl+v
Это еще как то можно решить настройками системы. В конце концов два указателя мыши и клавы уже есть лет 10 как.
Или более сложный вариант, но требующий уже специализированной IDE где V может сразу править код за D, но тут уже нужен редактор с двумя фокусами ввода.
Ответ про «три головы» это не пойдет по причине что человек может воспринимать с одного входа-органа чувств один поток информации. Можно слушать и видеть, но нельзя слушать одновременно двоих или смотреть одновременно на два монитора. А про две клавиатуры пол левую и правую это будет просто фантастика.
Заголовок правильный. А вот примеры не правильные и музыка даже в 4 руки это не ПП!
Самое главное в режиме ПП многие просто не могут работать. Даже можно сказать что 90% не могут работать.
В отличии от музыки где каждый участник дёргает или нажимает свои струны в ПП роли в каждый момент времени четко разделены. В музыке вы может даже играть две молодили параллельно. А в ПП «фокус ввода один». Один тактик –другой стратег. Один писатель –другой ревьюер. Один писатель – другой аналитик. Вы правильно указали эти роли.
Лет 15 назад когда пытались это сделать выяснилось очень много деталей. Реально нужно как минимум система с двумя независимыми поинтрами на экране (вариант с двумя мышами решает только часть проблем- а надо именно два указателя!). Очень бы наверно помог второй экран со своей клавиатурой, но механизм трансфера кода между экранами надо делать с нуля.
Но вот вопросы что для каждой пары нужно отдельное помещение это сложно. Партнеры все таки говорят в слух.
Потом, психологический подбор партнеров это просто супер задача что кадровика что для управляющего.
Надо признать что ПП выматывает очень сильно 1-2 часа работы, перекур на 30 минут. Но вот производительность при подборе удачной пары реально растет на порядок и что еще не менее важно КАЧЕСТВО кода тоже растет.
Ну прочтите Мифический человеко-месяц Брукса и особенно 16 главу — Серебряной пули нет.
Поймите что это писалось в 1986, что проблемы и вопросы поставленные тогда ни куда не делались и не решились. Что улучшилось только понимание проблемы, но не способы решения проблем. Начните честно признаваться с первых слов что у Scrum есть куча ограничений честно их и СРАЗУ заявите! Что гибкие методики тоже не применимы в 100%.
P.S. Перестаньте насиловать мозги.
Но к подаче материалом автором есть замечание. То что описывает в этой и предыдущей частях лежит на поверхность в документации, если этивещи не получается освоить самостоятельно то лучше не надо изучать данную технологию-она для вас. А в вот описать сложные задачи и рецепты и как их сделать вот то было бы супер.
tx, err := m.DB.Begin()
if err != nil {
return err
}
Хочется стреляться.
Такая была милотоа. Хочешь аппаратный реверсивный счетчик на 42-бита а пожалуйста, хочешь UART на 16-бит тоже пожалуйста (правда чуть сложнее). Хочешь контроллер на циклическую шину и это можно. Я рядышком стоит такой стандартный AVR c обычной периферией. Т.е. такой микро Zynq.Почему убили серию не понятно.
Этот опус на наводит разве что на мысли о выполнении плана по статьям. План то она может и поможет выполнить, но вот то что она откроет новое дно как для автора так и для этого сайта это очевидно.
Не надо учить программированию детей! Научите их пользоваться компьютерами!
Разработчик ПО это она из десятков тысяч профессий и количественная доля менее 1%. А вот умение пользоваться компьютерами нужно уже 30-50% людей.
Да и как можно научить программировать того кто не знает что можно сделать, а что нельзя сделать с помощью компьютера.
Уже лет 50 как появилась такая специальность –аналитик. В сложных и больших проектах системах есть аналитик от IT и аналитик о бизнеса. А для очень сложных систем есть еще системный архитектор. Для длительных проектов вводится менеджер проекта.
Так же ни кто не запрещает программисту для примера купить книжку «Бухучет» или «Современные методики выращивания гидропонных культур». Так и бухгалтеру не плохо прочитать что то типа «Основа баз данных» или «Администрирование компьютерных сетей». Хотя это все есть «изучения клингонского языка», но первый абзац ни кто не отменял.
P.S. И товарищи программисты, если вы ощущаете себя инженерами, то будьте Инженерами! Настоящий инженер это такой товарищЪ у которого так называемый кругозор или по модному soft skills это как минимум половина инженера!
Но в общем ANTLR позволяет сосредоточиться именн на сути своего языка, а не размениваться на мелочи.
Проблема в том что сейчас весь софт и оконные менеджеры одно фокусные.
В ПП для примера рабочее место должно реализовывать такой поведенческий шаблон:
Разработчик (D) – пишет код в редакторе. И предположим допускает ошибку и допускаем что онлайн проверка ее сразу ловит и подчёркивает. Но D не должен отрываться от разработки на решение данной ошибки, у него мысль в потоке реализации глобального алгоритма.
Ревьюер/вьюер (V) – видя эту ошибку уводит свой указатель на свою часть экрана/второй монитор и предположим изучает сеть или доки на данную тему и находит решение. Видя когда D закончит «алгоритмическую мысль» словесно говорит «есть решении проблемы смотри». Потом ctrl+c/ctrl+v
Это еще как то можно решить настройками системы. В конце концов два указателя мыши и клавы уже есть лет 10 как.
Или более сложный вариант, но требующий уже специализированной IDE где V может сразу править код за D, но тут уже нужен редактор с двумя фокусами ввода.
Ответ про «три головы» это не пойдет по причине что человек может воспринимать с одного входа-органа чувств один поток информации. Можно слушать и видеть, но нельзя слушать одновременно двоих или смотреть одновременно на два монитора. А про две клавиатуры пол левую и правую это будет просто фантастика.
Самое главное в режиме ПП многие просто не могут работать. Даже можно сказать что 90% не могут работать.
В отличии от музыки где каждый участник дёргает или нажимает свои струны в ПП роли в каждый момент времени четко разделены. В музыке вы может даже играть две молодили параллельно. А в ПП «фокус ввода один». Один тактик –другой стратег. Один писатель –другой ревьюер. Один писатель – другой аналитик. Вы правильно указали эти роли.
Лет 15 назад когда пытались это сделать выяснилось очень много деталей. Реально нужно как минимум система с двумя независимыми поинтрами на экране (вариант с двумя мышами решает только часть проблем- а надо именно два указателя!). Очень бы наверно помог второй экран со своей клавиатурой, но механизм трансфера кода между экранами надо делать с нуля.
Но вот вопросы что для каждой пары нужно отдельное помещение это сложно. Партнеры все таки говорят в слух.
Потом, психологический подбор партнеров это просто супер задача что кадровика что для управляющего.
Надо признать что ПП выматывает очень сильно 1-2 часа работы, перекур на 30 минут. Но вот производительность при подборе удачной пары реально растет на порядок и что еще не менее важно КАЧЕСТВО кода тоже растет.