Пощупал Access

Нужна надбавка за вредность.

если не выёживаться
то Access'а тебе хватит

ты перечитал умных статей на хабре
у тебя «наш-ларёк-должен-иметь-архитектуру-гугла» интоксикация головного мозга

Это не ларек. Это топовый банк Германии.

Смысл темы то заключается в том, что там помимо сейлсфорса, девопса с кубером там есть и MS Access, который тащат аж со второй версии. Cobol не искал.

Турки небось делали

Работа в немецком банке

В туалет по карточкам?

А мне нравится в подобном ковыряться )

То тебе надо интегрировать кучку подразделений, в которых у каждого своё исторически (от FoxPro, через Access до Excel) - такой кайф потом на выходе, когда удается разобраться со всеми форматами и всех их переженить в одной структуре, не потеряв ни одной буквы.

То вот тут сижу, ковыряюсь в 1С77 с самописной конфигурацией (по сути тот же Access, только в профиль, как тут верно подметили). Аж на Си написал свой собственный ковырятель кишок dbf. Там треть этих dbf на уровне структуры поломана, и надо аккуратно их восстановить по байтику.

Весело. Всяко веселее, чем эти новомодные хайлоад-кубер-технологии, черт их дери.

Встречал когда то подбное https://gendalf.ru/store/software/own_development/winDBFview/

Следующая тема будет «Кобол пощупал меня»?

Так это и не программист делал. Какой-нибудь пользователь написал для себя, чтобы что-то автоматизировать. Потом раздал другим, это расползлось, в конце концов от нее стали зависеть критические процессы.

Это ж классика, и плох тот банк, который с этим не борется.

Access - write only, как и Excel.

Cobol не искал

FORTRAN есть? Сколько платят?

Однозначно есть ещё какой нить RPG. Банки занялись этим ваший вайти ещё когда это не было мейнстримом.

Я тоже люблю подобные раскопки. Сейчас вот рефакторю движок одного портала. Весь с нуля был написан на php, разными разработчиками в разное время. Это не какой-нибудь там Друпал.

Но Access, пожалуй, перебор.

Эм... тебе за жопку хвать и кусь не сделают, за то, что ты данные о серваках распространяешь в интернетах?

И в один прекрасный момент, в этом бесконечном однообразном говне надоедает ковыряться, но полученные навыки применять негде.

Спустя время до тебя доходит слух, что ты мудак и нагородил ещё большее говно, роскомнадзор тебя мало.

А ты от имени EnterpriseMobility не выступал раньше?

Это не ларек. Это топовый банк Германии.

А NDA тебе позволяет пиздеть про это?

переводили тут одно американское нефтяное подразделение всем известной британской компании на новую версию программного обеспечения. c# все переменные и методы static, огромный копипаст, сохраняют xml в бд по которому тут же запросы пускают, об индексах в бд даже не догадывались, но в конфиги всё же умели :-), банальная выгрузка/загрузка по локальной сети шла два три часа. т.к. биндинги к c# больше не поддерживались, то переписали все на java (за три недели все переписали) - за 15-10 минут всё выгружается (а можно сделать ещё быстрее). И там практически весь софт такого качества. Пандемия и крызис их к сожалению подкосил, а то так мы были бы обеспечены работой по переписыванию «чудо» кода до скончания времён. :D Причём три недели реальной работы, а обсуждений было на три месяца с кучей людей, из которых чего-то знал и умел один индус. Вот такой он англосаксонский ентерпрайз.

причём денег они нефтяники платят за лицензии и поддержку этого детсадовского поделия просто астрономические.

Турки небось делали

их очень мало в ИТ

Так как немецкие программисты не знают, что такое переменные.

Это не ларек. Это топовый банк Германии.

Ты бы, вместо того, чтобы умничать, подумал о том, что тебе лично от «топовости» твоего рабочего места достаются чьи-то давно протухшие портянки. Но ты, весь из себя такой профи (не то, что эти тупые бюргеры), «зная что такое переменные», согласен копаться именно в таких портянках.

Правильный путь - сначала таблицы в MS SQL, фронт на excel, но ТОЛЬКО С ИСПОЛЬЗОВАНИЕМ PowerQuery

А вообще, access намного лучше внезаптного dBase/clipper.

до скончания времён.

И ведь написал же кто-то!

то переписали все на java

Я, начитавшись хабра, вообразил «переписали всё на javascript» - от был бы адский кейс!

Ну для начала не топовый, а во вторых не Германии, а Украины.

В третьих не банк, а аутсорсинговая контора.

А вообще, access намного лучше внезаптного dBase/clipper.

Спорный вопрос. Чем плох dBase? Кучей .dbf, которые разваливались сами, и разваливались индексы. Как правило, раз в неделю. Access падал реже. Но хуже.

Да. У нас там ввели двухфакторную аутентификацию: если нужно по большому - то нужно еще и сканить QR код.

по результатам месяца самого большого засранца лишают премии?

Да! Кто больше на горшок ходил, тот не является эффективным сотрудником!

Да! Кто больше на горшок ходил, тот не является эффективным сотрудником!

Предлагаю лайфхак: назначить дежурного, срать всем в ведро, и чтоб дежурный один раз это ведро выносил. Менеджер сможет отчитаться о повышении эффективности сотрудников.

Я про переделку legacy. В dBase все эти ограничения на название полей, масса уже не зарактерных для современных СУБД ограничений, восьмибитные кодировки... Ну нафик. Из access всё забрать и перенести гораздо проще.

Я про переделку legacy. В dBase все эти ограничения на название полей, масса уже не зарактерных для современных СУБД ограничений, восьмибитные кодировки…

А, ну, да! Есть такая задница. В этом плане Access и правда лучше.

человек, который это делал 15 лет назад понятия не имел о программировании.

немецкие программисты не знают, что такое переменные.

Вы путаетесь в показаниях :)

Какой-нибудь пользователь написал для себя, чтобы что-то автоматизировать. Потом раздал другим, это расползлось, в конце концов от нее стали зависеть критические процессы.

Вот два чая, проблема не в том, что такое было, а в том, что это не отрефакторили.

PERL!

Встречал когда то подбное https://gendalf.ru/store/software/own_development/winDBFview/

Кстати, спасибо. Интересный вариант. Не встречал. Может пригодится.

Все поделки, кроме этой (какие находил) - считают длину поля в байт. Да и по документации к dBase III там должен быть байт. А в этих реальных dbf - два байта. Реальное поле в 400 символов - большинство этих dbf-читальщиков считают полем в 144 символа.

Это одна из причин, зачем свой велосипед городил.

Вчера на github нашел какой-то читальщик dbf на Golang. Так мало того, что там тоже байт в формате поля. Самое страшное - смотреть, как оно читает двоичные данные из файла - с двойным перекладыванием: сначала в массив байтов, а потом из массива в структуру.

И, насколько я понял, это принципиальная позиция новомодности - на уровне языка отсутствует возможность трактовать память так, как захочется программисту. Нет никакой возможности считать данные сразу по адресу структуры. Прям сильное впечатление.

Да вы батенька, реставратор.

Нет никакой возможности считать данные сразу по адресу структуры.

Уже достаточно наобсирались с указателями, поэтому так и не делают.

Уже достаточно наобсирались с указателями, поэтому так и не делают.

И получают вот такую красоту неимоверную:

dt.numberOfRecords = uint32(s[4]) | (uint32(s[5]) << 8) | (uint32(s[6]) << 16) | (uint32(s[7]) << 24)

Да. Криво, стрёмно, зато сложнее обосраться.

Всё наоборот.

Чем запутаннее код, тем легче в нём обосраться.

dt.numberOfRecords = uint32(s[4]) | (uint32(s[5]) << 8) | (uint32(s[6]) << 16) | (uint32(s[7]) << 24)

От лишних копирований тут не избавиться. Но почему автор не в состоянии добавить немного семантики и написать что-то типа:

dt.numberOfRecords = unpack_uint32(s, numberOfRecordsOffset)

?

Чем запутаннее код, тем легче в нём обосраться.

Так он не запутанный, тут всё ясно. Речь вообще про пляски с указателями, там можно полные штаны наделать в самом элементарном коде.

Так он не запутанный, тут всё ясно.

А теперь представь, что таких строк штук 200 для парсинга сложных структур.

Речь вообще про пляски с указателями, там можно полные штаны наделать в самом элементарном коде.

На крестах всё можно красиво и безопасно инкапсулировать, не надо ля-ля.

На крестах всё можно красиво и безопасно инкапсулировать, не надо ля-ля.

И также красиво, можно отстрелить себе все конечности. Исходи из того, что средник кодерок - криворукий самоуверенный балбес.

А теперь представь, что таких строк штук 200 для парсинга сложных структур.

Программирование копипастой - не проблема языка.

Программирование копипастой - не проблема языка.

А что, в Go есть средства метапрограммирования, чтобы не писать 200 раз:

target.field1 = unpack(buffer, field1_offset);
target.field2 = unpack(buffer, field2_offset);

, ни разу не ошибившись в правильном offset?

И также красиво, можно отстрелить себе все конечности.

Ну да, перепутанный оффсет отстрелит конечность менее красиво. Зато кровь по стенам будет не хуже.

почему автор не в состоянии добавить немного семантики и написать что-то типа:

Не скажу за автора.

«Что-то типа» unpack_uint32 в Golang, наверное, выглядело бы как-то так:

p := bytes.NewBuffer(s[4:])
binary.Read(p, binary.LittleEndian, &dt.numberOfRecords)

Могу пофантазировать, что автор точно знает, что его авторский вариант компилятор Go сможет преобразовать в простые инструкции в итоге, а вот огород с созданием объекта - так и останется огородом с объектом. Мне так кажется.

Да. Да, пощупал ту самую первую строчку кода на коболе, которая написала Хоппер.

Это смотря как писать. Если руки из зада то да, всё будет разваливаться.

Я про переделку legacy. В dBase все эти ограничения на название полей, масса уже не зарактерных для современных СУБД ограничений, восьмибитные кодировки… Ну нафик. Из access всё забрать и перенести гораздо проще.

Ой да ладно. Сконвертил в csv и загрузил штатным bulk loader-ом