Нет, это не рекурсия, а нечто близкое к "порочному кругу". Но логической ошибки тут нет. Она была бы если бы определение звучало как "Квартира - составная часть многоквартирного дома".
помещение - часть объема здания или сооружения, имеющая определенное назначение и ограниченная строительными конструкциями
Таким образом, читая нормы в совокупности, можем сказать, что определение постулирует, что квартирой является помещение именно в многоквартирном доме.
Т.е. пристроенный открытый навес к деревенскому дому "на две семьи" - не квартира (не является помещением, т.к. не ограничен строительными конструкциями); с остекленной верандой ситуация сложнее, ее можно, наверное, отнести к одной из квартир :)
Ну и помещение отдельно стоящего дома "на три окна" - не квартира (дом состоит лишь из 1 помещения, т.е. не многоквартирный).
В 1С приятно то, что язык - русский (хотя можно писать и по-английски, но в российских проектах так делать не надо), и терминология прикладная не требует адаптации. Это огромный плюс, когда речь идет о бухгалтерии или расчете зарплаты. Однако, когда добираемся до технических вещей типа идентификаторов "HTTPЗапрос" или "ОбъектXDTO" напрягает постоянное переключение раскладки.
Раньше это точно было, сейчас не знаю. В 2008-2009 гг. я использовал Access в таком режиме в качестве клиента для генерации отчетов по данным MS SQL базы.
Формы на основе таблиц MS SQL создавать тоже можно было, насколько помню, в т.ч. и "со связями".
Но я в своем приложении в итоге использовал только формы без DataSource и движок отчетов.
А вот SQL-инъекции приходилось писать по-настоящему, а не на JetSQL, который реализован в нативном Access.
Ну да, писать приложения надо быстро, качественно и без ошибок. И тут как раз хорошо, когда инструмент тебе помогает, автоматизируя часть рутины и убирая часть машинальных ошибок.
А вот когда в языке возможны конструкции
b = f(a) //как должно быть f(a,b) //неправильный вызов
Причем во втором случае ни компилятор, ни интерпретатор не сообщают об ошибке, то можно попасть на многочасовую отладку.
Не надо пугать автора, есть же Linux. Торвальдса никто не устранил, жив и здравствует. Хотя, с другой стороны, с Ианом Мёрдоком вышла какая-то очень мутная история.
17 лет назад я хотел написать кросплатформенного убийцу 1С на PyGTK+. Даже название придумал: PyGTK+ Business Forms. Даже начал что-то делать, разобрался в PyGTK+ и Glade, но закрутили дела и ... в общем, сейчас на PyGTK+ уже не хочу :)
В своей практике применяю таблицы решений достаточно часто. Поделюсь в этом комментарии отработанной на многих проектах техникой:
1. Если валидатор проверяет 1, 2 или 3 атомарных бинарных условий - таблица решений не нужна, так как пространство состояний не превосходит 2^3 = 8 и легко перечисляется непосредственно.
2. Если условий 3, 4 и среди них есть небинарные, имеет смысл уже браться за Excel (или иную таблицу) и строить таблицу решений.
3. Если условий 5 и более, то не важно, бинарные они или нет - таблицу решений делать обязательно.
4. В процессе построения таблицы решений всегда следует проводить 2 этапа: а) формальный - просто выписываем все пространство состояний; б) кластеризация и отбрасывание "невозможных" по бизнесу случаев (например, если поле "Серия паспорта" обязательно для заполнения, и передается от подсистемы, дающей гарантию на его заполнение - все кейсы с пустым значением этого поля можно помечать как невалидные).
При этом на шаге б) значения не стоит выкидывать совсем, лучше их помечать каким-либо цветом или зачеркнутым шрифтом. Потом соответствующие колонки (строчки) можно скрыть.
Почему сразу не начать с п. б)? В некоторых случаях так делать можно, но есть риск механических ошибок. Поэтому лучше все же сохранить историю построения таблицы.
Один из самых успешных случаев применения описанной техники - организация тестирования функционала на основании таблицы решений, в которой пространство возможных состояний составляло более 530 кейсов. Это позволило за 2 недели выявить, и оперативно ликвидировать ошибки, которые до того тянулись из релиза в релиз.
Так что подтверждаю, таблицы решений - мощный и нужный инструмент.
На мой взгляд, это никак не измеряется, и в таком плане незачем (ибо невозможно) об этом рассуждать.
В самом деле, что такое "будущее своих детей и внуков"? Почему тогда не пойти дальше, не подумать о правнуках? Какой смысл в этих словах?
Хотя можно говорить об увеличении (или хотя бы сохранении) соотношения доходов к расходам на определенном уровне и законности/приличности способов получения этих доходов. В таком случае, можно рисовать различные сценарии, однако, тут даже со своим будущим сложно разобраться, не говоря уже о гарантиях для детей, внуков, семейного клана :)
Иногда можно увидеть отсутствие перспектив - например, это может сделать фермер, живущий на земле, которая деградирует из-за засаливания почв; или нефтяник, живущий в рабочем поселке при месторождении, срок эксплуатации которого скоро закончится.
Речь вообще-то не о том, чего надо или не надо хотеть мне, и тем более, вам. Я говорил лишь конкретно про себя и Братиславу, и про те города/районы городов Европы, которые застроены таким же spalnik'ом, как Братислава. Жизнь в Братиславе не дала бы мне ничего нового, по сравнению с тем, чего я не видел, и, вероятно, ничего лучшего, чем то, что я пока что имею или имел. Поэтому я туда сейчас и не хочу :)
Прежде чем принимать решение ехать/оставаться (и не важно, на самом деле, откуда и куда - из Урюпинска в Санкт-Петербург, или из Москвы в Прагу) надо ответить самому себе на вопросы:
- Зачем я это делаю? - Что меня тут держит? Важно ли это для меня? - Чего я достигну там и тут? - Что я могу потерять там и тут? - Буду ли я счастливее, если уеду? - Будет ли кто-то несчастен (и кто), если я уеду?
И тут может оказаться, что "Я бы уехал в Австралию, но кто позаботится о престарелых родителях?", например. Или может оказаться, что "а почему же я так долго терял возможности?"
Нет, это не рекурсия, а нечто близкое к "порочному кругу". Но логической ошибки тут нет. Она была бы если бы определение звучало как
"Квартира - составная часть многоквартирного дома".
Смотрим, однако Федеральный закон от 30.12.2009 N 384-ФЗ (ред. от 02.07.2013) "Технический регламент о безопасности зданий и сооружений", п. 14 ч. 2:
помещение - часть объема здания или сооружения, имеющая определенное назначение и ограниченная строительными конструкциями
Таким образом, читая нормы в совокупности, можем сказать, что определение постулирует, что квартирой является помещение именно в многоквартирном доме.
Т.е. пристроенный открытый навес к деревенскому дому "на две семьи" - не квартира (не является помещением, т.к. не ограничен строительными конструкциями); с остекленной верандой ситуация сложнее, ее можно, наверное, отнести к одной из квартир :)
Ну и помещение отдельно стоящего дома "на три окна" - не квартира (дом состоит лишь из 1 помещения, т.е. не многоквартирный).
В 1С приятно то, что язык - русский (хотя можно писать и по-английски, но в российских проектах так делать не надо), и терминология прикладная не требует адаптации. Это огромный плюс, когда речь идет о бухгалтерии или расчете зарплаты. Однако, когда добираемся до технических вещей типа идентификаторов "HTTPЗапрос" или "ОбъектXDTO" напрягает постоянное переключение раскладки.
Или пойти зарабатывать на 1С. По некоторым данным, медианная з.п. 1С разработчика 151 000 р.
Как вы пришли к мнению, что в 1С нет типизации? В 1С есть система типов. https://v8.1c.ru/platforma/sistema-tipov/
В ред хат линуксе лет дцать назад была кривенькая утилита настройки разрешения экрана на Питоне ))) ошибку в ней исправлял.
Сейчас - не знаю. Я бы делал веб-интерфейс, на чем - надо изучать какие есть технологии для фронт-энда, ускоряющие и упрощающие разработку.
Подозреваю, что такого простого и удобного редактора форм, как в 1С, на рынке нет вообще.
Раньше это точно было, сейчас не знаю. В 2008-2009 гг. я использовал Access в таком режиме в качестве клиента для генерации отчетов по данным MS SQL базы.
Формы на основе таблиц MS SQL создавать тоже можно было, насколько помню, в т.ч. и "со связями".
Но я в своем приложении в итоге использовал только формы без DataSource и движок отчетов.
А вот SQL-инъекции приходилось писать по-настоящему, а не на JetSQL, который реализован в нативном Access.
Ну да, писать приложения надо быстро, качественно и без ошибок. И тут как раз хорошо, когда инструмент тебе помогает, автоматизируя часть рутины и убирая часть машинальных ошибок.
А вот когда в языке возможны конструкции
b = f(a) //как должно быть
f(a,b) //неправильный вызов
Причем во втором случае ни компилятор, ни интерпретатор не сообщают об ошибке, то можно попасть на многочасовую отладку.
Что-то не встречал таких вендоров, кто же это? )))
C Access все плохо: а) он дорогой; б) M$ в России самосократился. А так - неплохой вариант для небольших БД.
Ну, например, чтобы помочь бедным странам Африки и латинской Америки.
Не надо пугать автора, есть же Linux. Торвальдса никто не устранил, жив и здравствует. Хотя, с другой стороны, с Ианом Мёрдоком вышла какая-то очень мутная история.
17 лет назад я хотел написать кросплатформенного убийцу 1С на PyGTK+. Даже название придумал: PyGTK+ Business Forms. Даже начал что-то делать, разобрался в PyGTK+ и Glade, но закрутили дела и ... в общем, сейчас на PyGTK+ уже не хочу :)
На средства благотворительного фонда, обычно в таком режиме работают не компании, а проекты типа Debian. Но зачем, когда можно зарабатывать? )))
Да, он сложнее.
Спасибо за эту статью и ссылки на стандарт OMG.
В своей практике применяю таблицы решений достаточно часто. Поделюсь в этом комментарии отработанной на многих проектах техникой:
1. Если валидатор проверяет 1, 2 или 3 атомарных бинарных условий - таблица решений не нужна, так как пространство состояний не превосходит 2^3 = 8 и легко перечисляется непосредственно.
2. Если условий 3, 4 и среди них есть небинарные, имеет смысл уже браться за Excel (или иную таблицу) и строить таблицу решений.
3. Если условий 5 и более, то не важно, бинарные они или нет - таблицу решений делать обязательно.
4. В процессе построения таблицы решений всегда следует проводить 2 этапа:
а) формальный - просто выписываем все пространство состояний;
б) кластеризация и отбрасывание "невозможных" по бизнесу случаев (например, если поле "Серия паспорта" обязательно для заполнения, и передается от подсистемы, дающей гарантию на его заполнение - все кейсы с пустым значением этого поля можно помечать как невалидные).
При этом на шаге б) значения не стоит выкидывать совсем, лучше их помечать каким-либо цветом или зачеркнутым шрифтом. Потом соответствующие колонки (строчки) можно скрыть.
Почему сразу не начать с п. б)? В некоторых случаях так делать можно, но есть риск механических ошибок. Поэтому лучше все же сохранить историю построения таблицы.
Один из самых успешных случаев применения описанной техники - организация тестирования функционала на основании таблицы решений, в которой пространство возможных состояний составляло более 530 кейсов. Это позволило за 2 недели выявить, и оперативно ликвидировать ошибки, которые до того тянулись из релиза в релиз.
Так что подтверждаю, таблицы решений - мощный и нужный инструмент.
Это провал :(
На мой взгляд, это никак не измеряется, и в таком плане незачем (ибо невозможно) об этом рассуждать.
В самом деле, что такое "будущее своих детей и внуков"? Почему тогда не пойти дальше, не подумать о правнуках? Какой смысл в этих словах?
Хотя можно говорить об увеличении (или хотя бы сохранении) соотношения доходов к расходам на определенном уровне и законности/приличности способов получения этих доходов. В таком случае, можно рисовать различные сценарии, однако, тут даже со своим будущим сложно разобраться, не говоря уже о гарантиях для детей, внуков, семейного клана :)
Иногда можно увидеть отсутствие перспектив - например, это может сделать фермер, живущий на земле, которая деградирует из-за засаливания почв; или нефтяник, живущий в рабочем поселке при месторождении, срок эксплуатации которого скоро закончится.
Речь вообще-то не о том, чего надо или не надо хотеть мне, и тем более, вам. Я говорил лишь конкретно про себя и Братиславу, и про те города/районы городов Европы, которые застроены таким же spalnik'ом, как Братислава. Жизнь в Братиславе не дала бы мне ничего нового, по сравнению с тем, чего я не видел, и, вероятно, ничего лучшего, чем то, что я пока что имею или имел. Поэтому я туда сейчас и не хочу :)
Прежде чем принимать решение ехать/оставаться (и не важно, на самом деле, откуда и куда - из Урюпинска в Санкт-Петербург, или из Москвы в Прагу) надо ответить самому себе на вопросы:
- Зачем я это делаю?
- Что меня тут держит? Важно ли это для меня?
- Чего я достигну там и тут?
- Что я могу потерять там и тут?
- Буду ли я счастливее, если уеду?
- Будет ли кто-то несчастен (и кто), если я уеду?
И тут может оказаться, что "Я бы уехал в Австралию, но кто позаботится о престарелых родителях?", например. Или может оказаться, что "а почему же я так долго терял возможности?"
Все индивидуально.
Я посмотрел в Гугле, как выглядит Братислава - и спасибо, в такую Европу точно не хочу :)