Pull to refresh
-4

Программист

1
Subscribers
Send message
В статье достаточно много неточностей.
Например,
«В 1978 году IBM представляет одновременно средний компьютер System/38 и новый диалект языка — RPG III — для него.С этого момента ограничения языка несколько ослабляются и разрешается писать спецификации вычислений в «свободном формате»»
Т.н. «free format», с картинки в статье, появился только в RPG ILE (IV), и не сразу после его выхода в 1994-м, а лишь в версии 5.1 в 2001-м. Мне тогда пришлось преодолеть немало запретов и получить специальное разрешение использовать free в своем коде. Это по-сути был другой диалект языка который рвал на части многие принятые до того стандарты.

Говоря об истории, не стоит забывать об отечественных версиях языка. Например, компилятор с языка был на ЭВМ Минск-32, и я даже когда-то читал книжечку изданную в 70-х про язык РПГ :-).

Eclipse-based клиент, показанный на картинке, назывался «IBM Websphere Development Studio Client», а «IBM Websphere Development Studio» — это прежде всего набор компиляторов на самом мэйнфрейме. В клиенте ничего не компилируется. (вот www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzau1/rzau1ebwds.htm)

RPG для .NET действительно когда-то был, в 2001-м, если не ошибаюсь. Тогда на него возлагали большие надежды, типа убийца AS400 (ведь программа предполагала еще и перенос софта на мощные сервера по управлением OS Windows). Почила в бозе эта инициатива уже давно, насколько мне известно.

Ну и главное, не раскрыто, почему собственно язык пользуется популярностью до сих пор. В чем его мощь? А она вовсе не в синтаксисе. Она в глубокой интеграции с OS, и прежде всего с БД. Если кто-то был знаком c FoxPro — вот это примерно отдаленно то же, только лучше. Нативно, на уровне синтаксиса, поддерживаются операции ввода-вывода в БД.
Ну и надо сказать пару слов о БД. Дело в том, что в IBM параллельно, в одно и то же время, две разные команды разрабатывали концепцию реляционной БД и язык для него. Кодд делал SQL, а команда AS400 (или тогда еще S/38) свой вариант — DDS. Попытка объединить усилия была предпринята, но, как пишет Ф. Солтис (папа архитектуры as400), Кодд воспринял их идеи холодно и больше они не сотрудничали. В результате AS400 получила свой язык описания моделей БД — DDS. А в качестве языка программ-запросов используется RPG.
Конечно, со временем SQL появился и на AS400. Но в существующих программах преобладает использование DDS.

Стратегически, IBM сейчас нацеливает разработчиков на переход с DDS на SQL. Это, на мой взгляд, сильно нивелирует достоинства языка и становится не понятно, почему например не писать тогда на Java или c++ например?
Если нужна помощь с RPG — обращайтесь. 15 лет опыта c AS400 (RPG, CL и все вокруг).
Начинал на RPG || :-).
Только не простое это будет дело, я так думаю.
Фактически, RPG сегодня — это 3 (или даже 4, как считать) разных диалекта.
Я как-то пытался написать синтаксис для VIM и быстро заскучал :-).
ISO 8601 — это еще тот стандарт для любителей веселухи.
Из практики, почти всегда можно найти вариант, который будет полностью соответствовать стандарту, но не поддерживаться или неправильно интерпретироваться конкретной библиотекой.
Так что, да, указывайте просто ISO 8601, вместо например RFC 3339. Тестерам это реально доставит :-).
Я не понял насчет лексуса 2002-го года. Это некий показатель чего-то? Проясните, пожалуйста.
А то я программист, а не механник. Мне главное чтобы ехала и не ломалась. Ну и чтобы бензина не слишком много кушала. Но вообще, как появилась возможность, я отдал машину жене и езжу на общественном транспорте. Пока едешь — можно подумать спокойно, всякие мысли полезные по работе приходят. Когда сам за рулем как-то нет возможности отвлечься.
Дык в том то и проблема, что как только тебя определят как «разработчика», с заказчиком напрямую общение утрачивается. Для этого ведь есть бизнес аналисты, прожект менеджеры…
Конечно, замечательно, когда в вашей компани по-другому. Но я сталкивался и с тем, о чем пишет автор.
Не только слышал — но и видел. Вбили миллионы во внедрение OBIEE, после чего ключевые пользователи решили, что скачать все в Excel и уж там… им гораздо удобнее.
Все менеджеры получили свои бонусы, архитектор прославился успехом и уехал в крутой американский банк внедрять подобное. MS успешно продолжает продавать свои лицензии корпоративного офиса. Оракл тоже не в накладе — серверы с OBIEE надежно греют окружающую среду, работая утилитой по конвертации таблиц БД в Excel. Я так понимаю, проигравших вообще нет. Так что да, очевидно, это перспективный патерн на будущее.
Отличная статья! Надо улучшать свой стиль общения с командой. А то все ф-ворд да ф-ворд… :-).
Вы видимо не поняли текст автора. Воспользуйтесь переводчиком. Он отрицает первостепенную значимость индивидуальных талантов. Вот с чем я не согласен.
Ну, вам платят за время, а мне — за решение проблем. У всех контракты разные. В моем например обучение обычно не присутствует.
Так время на ревью отличается принципиально, когда его делает подготовленный человек и недостаточно квалифицированный, которому надо разжевывать, объяснять и доказывать.
Это уже не ревью. Это — обучение. А его пытаются втиснуть в ревью и таким образом не доплачивать. Одна из многих уловок хитрого менеджмента по высасыванию соков из людей. Нафик-нафик. Забивайте отдельно время на обучение и отдельно на ревью. Это будет честно.
«Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.»
Далеко не универсальное правило. Команда из крепкий середнячков не выдаст революционный продукт на гора и не сделает чего-то «сверх». Когда вы делаете новый продукт на конкурентном поле, нужен человек-звезда, лидер. Со своим взглядом и стратегическим видением. Он сформирует образ будущего продукта. А серая сплоченная масса хороша для поддержки опердня в банке.
Теоретически все замечательно. А практически выглядит так, что тебя начинают нещадно эксплуатировать. Ты не только разработчик но еще и параллельно должен обучать. К чему это приводит на практике? А к тому, что я может потратил пол часа на таск плюс еще столько же на бодания и объяснение недалекому ревьюверу. В результате он все в конце концов понял и радостный пошел домой, а я должен оставаться овертайм чтобы доделать то, что должен был бы делать в то время, которое потрачено на выяснения — объяснения — обучение. Начальство хочет началось обучать джуниора — пожалуйста. Давайте учитывать как-то по-другому это дополнительное время, а не пытаться схитрить типа и типа сэкономить. Вот потому я Рика очень понимаю. Откуда у него взялась эта доска и откуда дикие переработки.
У владельцев компании задача вырастить из джуниоров специалистов — так за это надо дополнительно платить. У меня задача сделать в срок и качественно свои таски (за что мне платят деньги) и пойти домой вовремя.
А мы давно на ТЫ с вами?
Дружище, с таким подходом, мол я начальник — ты дурак, команда не работает.
И если я пишу код, то задача босса как раз создать мне комфортные условия. А если мне не комфортно — конечно, надо расставаться. «Сейчас везде нужны хорошие счетоводы». А вот боссы из серии «я начальник — ты дурак» востребованы разве в гос структурах и то там все занятно плотно.
Да какие проблемы — код во всеобщем доступе, история коммитов и комментарии тоже. Мердж происходит только после ревью. Вы так говорите, будто кто-то не хочет вам показывать свой код… Вопрос на самом деле, как происходит мердж. И зависит ли он от подтверждения от ревьювера — джуниора. Вот это напрягает — необходимость разжевать и объяснять банальности, иногда и просто тратить время на спор с дебилом, просто чтобы твой код ушел в девелоп. Никакой отдачи мне лично такой процесс не дает. Начальство время и нервы потраченные на такие объяснения не оценит — наоборот, задержка твоего коммита на ревью идет тебе в минус. Вообщем, одна головная боль.
Я поддерживаю вариант, когда ревьювит человек с опытом и в теме. И он же подтверждает мердж. Тогда все уходит в 90% без сучка без задоринки, а если возникают вопросы — то по делу и действительно можно чему-то научиться самому.
Ну, если каждый коммит ревьювит вся комманда (почему один джуниор, пусть уж все джуниоры учатся) — это замечательно. Но как-то малореалистично. Хотя, в банке может быть и не такое. А когда времени в обрез и все заняты своим, то реально ревьювить может один. Остальные максимум тихо учиться ну и как тут сказали указывать на синтаксические ошибки.
Так в том то и дело, что это не ревью. В том то и дело, что опечатку то может такое процесс и найдет, а вот реальную проблему пропустит. Просто по незнанию.
Получается, ни ревью полноценного, ни обучения, на которое требуется время.
Или вы путаете ревью с изучением кода?
Потому что я вижу для себя в этом только головную боль и трату времени безо всякой благодарности.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
Мой опыт говорит о другом. Когда есть деньги — можно собрать команду звезд по всему миру и выдать на гора за пол года, что до этого не могли запустить за 5 лет потратив астрономические суммы.
То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
Я бы пожалуй уволил весь менеджмент и побеседовал бы с Риком на тему, кого оставить в команде, а с кем попрощаться. Далее, я бы попросил Рика провести интервью и набрать команду из людей, которые были бы его уровня «Энштейн» и с которыми ему комфортно и удобно было бы работать и код которых он мог бы спокойно положиться.
Ну так мне слабо верится, чтобы человек ни с того ни сего вдруг такое начал говорить.
Очевидно, уже был на взводе и готов послать все нафик.

Information

Rating
Does not participate
Registered
Activity