Для большинства языков access violation фатален и приводит к немедленному завершению программы. А на delphi — это всего лишь аппаратный exception, который можно обработать.
Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.
К этому добавляются удобные конструкции try..finally и try..except.
Извините, а вы, помимо Object Pascal, с другими языками, например, с Java, C++, Python знакомы? Это типовые инструкции языка, они сейчас есть везде.
Тут дело даже больше в том, что молодым менеджером можно заработать в теории больше, чем начинающим разработчиком. Просто потому что тот же продажник быстрее начинает создавать нужную конторе ценность.
Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.
Просто работодатель не может оценить потенциальную ценность продукта, пока ее продажник не продаст. Поэтому ценит продажника. И продажник тоже себя ценит. А разработчик должен доказывать свою ценность фирме какими-то виртуальными показателями — тысячами SLOC, закрытыми тикетами, черти чем еще.
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
Эти типично красивые слова не выдерживают проверки временем.
Ценность, которую принесет разработчик в большой продукт, может быть монетизирована фирмой через пару лет. К этому времени разработчик уже уволился, потому что фирма его не оценила — ровно потому, что ничего фирме он не принес.
А теперь внимание, вопрос — вы выплатите уже уволившемуся разработчику премию за его вклад двухлетней давности?
И, чтобы два раза не вставать, — офис, НН и Делфи — вы серьезно?
Проблема же заключается в том, что в силу непонимания предметной области лицо, делающее вывод, будет склонно считать всех кандидатов либо обычными, либо способными.
О какой предметной области идет речь? В которой кандидат будет работать?
Если так, то почему лицо, делающее вывод, занимается выводами в той области, где ничего не понимает?
Внимательный читатель заметит, что и в нашей истории проблема Anytime Rational возникает на стыке двух прекрасно работающих систем — продаж и производства.
Мне кажется, что здесь проблема возникла из-за того, что процессы Agile поставили выше взаимодействия людей. Что на корню убило саму идею Agile.
Статья называется "Как руководить интровертами без вреда для здоровья". Типа это актуальная проблема.
Интроверт продуктивен в тиши и одиночестве.
Интроверт работает один и отвечает за всё сам.
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Экстраверт умеет и любит работать в команде. На раз-два налаживает контакты и генерирует идеи на лету.
Экстраверт привык делить и работу, и ответственность.
Я один здесь вижу безответственного чувака, балабола и бездельника?
Может вести крупный проект, где за коммуникацию будут отвечать экстраверты.
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Честно говоря, я не в курсе, как сейчас по законодательству.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
Есть еще третья категория б/у. Бюджетники. Эти звери по моему вообще проводки не разносят никогда.
У меня пока обошлось, не встречался.
Ведь в реальной жизни красным ничего не бывает. Ведь фактически описанный вами овердрафт внутри дня это отдельный счет с кредитом, который работает только в рамках дня.
Я не очень понял про отдельный счет с кредитом. Когда оформляется овердрафт по расчетному счету, то ссудный счет к нему либо открывается сразу, либо при первой выдаче (погашения красного сальдо на расчетном счете). Или вы про что?
Просто мы скрываем часть проводок, для простоты.
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
С овердрафтом они рассчитаются, но на конец дня у них будет опять положительный остаток и выдачи кредита не происходит, новые проводки не появляются. Вот если один не заплатит, то у второго будет красное сальдо, недостача на счете — вот тогда появится проводка по выдаче кредита, которая обнулит остаток.
Извините, если кто-то выше написал то же самое, а я не заметил.
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течение месяца квартала оформлять документы — ордера, авансы, накладные, приходы и расходы и т.д. согласно бюджета, но без отражения по счетам. То есть операции делались, а проводки не фиксировались. Рассчитывалась, к примеру, зарплата, заказывались деньги в банке — зарплата выплачивалась, ведомость по выплате клалась в ящик. И каждый конец квартала был аврал по оформлению квартального отчета. Из всех ящиков вытаскивались все накопившиеся бумажки, считались и записывались в Главную книгу, причем (в зависимости от бухгалтера, конечно) каждый раз главный бухгалтер переживал, сойдется у него баланс или не сойдется. Сколько из-за этого инфарктов было…
У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И о погоде проводках. Изначально — да, проводки содержали два счета и одну сумму. Когда банки стали заниматься инвалютой, то оказалось, что конверсионные проводки плохо укладываются в этот шаблон — суммы в валюте счета по дебету и по кредиту не совпадали. Так как на тот момент нельзя было изменить структуру проводки, то ввели конверсионные счета. Для простой операции вместо одной проводки стало три (с учетом курсовой разницы), иногда четыре. Потом автоматизация улучшилась, и в одну проводку стало можно запихать не одну сумму, а точнее, две и более сумм в разных валютах финансовых инструментах. И не два счета, а 1:M или М:1. Главное, что должно было соблюдаться — равенство сумм в рублях РФ по дебету и кредиту. Ну и соответствие правилам бухучета, конечно, к примеру не стоило запихивать в одну проводку балансовые и внебалансовые счета.
Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Устроился молодой бухгалтер на работу в одну контору. Хороший оказался специалист. Быстро начал в гору идти. Только вот у него странность одна была. Каждое утро он садился на свое рабочее место, отпирал ключиком тумбочку, выдвигал верхний ящик, заглядывал в него, снова запирал и приступал к работе. Шли годы. Он стал главным бухгалтером этого предприятия. Но каждое утро он заглядывал перед работой в тумбочку. Коллеги недоумевали, но в тумбочку заглянуть не решались, да и закрыта она была всегда. И вот, его проводили на пенсию. На следующее утро коллеги ринулись к его рабочему столу, взломали верхний ящик и увидели, что на его дне лежит бумажка, на которой написано крупными буквами:
"ДЕБЕТ — слева, КРЕДИТ — справа".
Мы предложили совсем другую модель, объединиться вокруг продуктов, включив в команду представителей от всех подразделений участвующих в процессах, связанных с данных продуктов(как продажа, так и обслуживание). Второе значимое нововведение – жизненный цикл банковского продукта начинается от лида и заканчивается в момент закрытия или перепродажи сделки.
Команда продолжает существовать, пока продукт продается и обслуживается?
Любой участник команды описывает реализуемое изменение для предварительного анализа, используя для этого формат user-story, которое в итоге попадает в беклог бизнес-аналитика.
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Владелец продукта получает результат каждого спринта на тестирование и может влиять на дальнейший ход
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.
Кажется, нашел — это СИД-1000, на этой фотографии он слева.
Судя по тому, что в справочнике (стр.94) фигурирует «Время начертания одного символа» — он векторный
В этот момент я осознал, что все эти процессы, которые мне казались бюрократией, были придуманы людьми не просто так.
Парадокс, но находятся люди с не меньшим опытом, но так и не осознавшие эту истину.
Вдвойне парадокс, но некоторые из этих людей — менеджеры разработки…
Главное отличие тех мониторов от этого РИН, которое мне запомнилось — ноль не в ту сторону перечеркнут :) Так что они были живой иллюстрацией сказки о байте.
Для этого есть деструкторы, которые, в отличие от Delphi, будут гарантированно вызваны, поэтому в finally необходимость не возникает.
Это достоинство VCL, а не Делфи, что exception ловится на верхнем уровне приложения.
Извините, а вы, помимо Object Pascal, с другими языками, например, с Java, C++, Python знакомы? Это типовые инструкции языка, они сейчас есть везде.
Нет. Нужную конторе ценность создал разработчик (-ки). А продажник ее продал.
Просто работодатель не может оценить потенциальную ценность продукта, пока ее продажник не продаст. Поэтому ценит продажника. И продажник тоже себя ценит. А разработчик должен доказывать свою ценность фирме какими-то виртуальными показателями — тысячами SLOC, закрытыми тикетами, черти чем еще.
Эти типично красивые слова не выдерживают проверки временем.
Ценность, которую принесет разработчик в большой продукт, может быть монетизирована фирмой через пару лет. К этому времени разработчик уже уволился, потому что фирма его не оценила — ровно потому, что ничего фирме он не принес.
А теперь внимание, вопрос — вы выплатите уже уволившемуся разработчику премию за его вклад двухлетней давности?
И, чтобы два раза не вставать, — офис, НН и Делфи — вы серьезно?
О какой предметной области идет речь? В которой кандидат будет работать?
Если так, то почему лицо, делающее вывод, занимается выводами в той области, где ничего не понимает?
Меня больше занимает вопрос, почему во второй фирме Ярослав помог другу Пете из другого отдела, но в первой не может помочь своему подчиненному Ефиму?
Мне кажется, что здесь проблема возникла из-за того, что процессы Agile поставили выше взаимодействия людей. Что на корню убило саму идею Agile.
До кучи:
"Никогда не принимайте контрпредложение"
Эффект второй системы
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Я один здесь вижу безответственного чувака, балабола и бездельника?
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
У меня пока обошлось, не встречался.
Я не очень понял про отдельный счет с кредитом. Когда оформляется овердрафт по расчетному счету, то ссудный счет к нему либо открывается сразу, либо при первой выдаче (погашения красного сальдо на расчетном счете). Или вы про что?
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
С овердрафтом они рассчитаются, но на конец дня у них будет опять положительный остаток и выдачи кредита не происходит, новые проводки не появляются. Вот если один не заплатит, то у второго будет красное сальдо, недостача на счете — вот тогда появится проводка по выдаче кредита, которая обнулит остаток.
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течение
месяцаквартала оформлять документы — ордера, авансы, накладные, приходы и расходы и т.д. согласно бюджета, но без отражения по счетам. То есть операции делались, а проводки не фиксировались. Рассчитывалась, к примеру, зарплата, заказывались деньги в банке — зарплата выплачивалась, ведомость по выплате клалась в ящик. И каждый конец квартала был аврал по оформлению квартального отчета. Из всех ящиков вытаскивались все накопившиеся бумажки, считались и записывались в Главную книгу, причем (в зависимости от бухгалтера, конечно) каждый раз главный бухгалтер переживал, сойдется у него баланс или не сойдется. Сколько из-за этого инфарктов было…У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И о
погодепроводках. Изначально — да, проводки содержали два счета и одну сумму. Когда банки стали заниматься инвалютой, то оказалось, что конверсионные проводки плохо укладываются в этот шаблон — суммы в валюте счета по дебету и по кредиту не совпадали. Так как на тот момент нельзя было изменить структуру проводки, то ввели конверсионные счета. Для простой операции вместо одной проводки стало три (с учетом курсовой разницы), иногда четыре. Потом автоматизация улучшилась, и в одну проводку стало можно запихать не одну сумму, а точнее, две и более сумм в разныхвалютахфинансовых инструментах. И не два счета, а 1:M или М:1. Главное, что должно было соблюдаться — равенство сумм в рублях РФ по дебету и кредиту. Ну и соответствие правилам бухучета, конечно, к примеру не стоило запихивать в одну проводку балансовые и внебалансовые счета.Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Команда продолжает существовать, пока продукт продается и обслуживается?
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.
Судя по тому, что в справочнике (стр.94) фигурирует «Время начертания одного символа» — он векторный
Парадокс, но находятся люди с не меньшим опытом, но так и не осознавшие эту истину.
Вдвойне парадокс, но некоторые из этих людей — менеджеры разработки…