cruse

6
Рейтинг

cruse



  •   Регистрация: 04.08.2009 (14 лет назад)

  •   Был(а) на сайте: 22.10.2021

Подписчики 1

Рейтинг 6


Комментарии

О жизниБорис Нуралиев ответил на вопросы сообщества “Инфостарт”#85 12.07.13 14:51
(71) Asmody, все начинается с мелочей. Чтоб очистить журнал регистрации надо протыкать мышью 5 кнопок, делать это по 40-50 раз на дню при разработке импорта доставляет. Или, например, пробовали ли Вы выстроить функциональные роли доступа в большой конфе, где до этого все работали под полными правами? Сделать это из формы в конфигураторе используя встроенную форму, тыкая галочки - задача на "тихо помереть". Лично я использовал сторонние средства, языки программирования и тот же git.
О жизниБорис Нуралиев ответил на вопросы сообщества “Инфостарт”#70 12.07.13 13:32
А помоему все предельно просто. При всем уважении, не нужна разработка от orefkov для официального открытия того api, которое уже есть (в недрах). Просто имеет место конфликт интересов, примерно тот же самый как и опенсорс 7.7. Если разработчику дать вместо палки-копалки нормальную лопату, то он таких конфигураций налопатит, что потом замучаешься продавать типовые, ИТСы.

Просто вслух об этом никто не скажет.
О жизниБорис Нуралиев ответил на вопросы сообщества “Инфостарт”#32 12.07.13 0:58
Прозвучал таки ответ на "самый главный вопрос о жизни, вселенной, api к конфигуратору и вообще..." и конечно же это 42.

У меня руки отваливаются от елозания мышью, отсутствия хоткеев, а тут достижение - фолдинг, что при имеющихся проблемах с инкапсуляцией, добавит к процедурам и функциям еще 1.5-3 тыс. строк кода.
О жизниТОП 10 самых раздражающих факторов для программиста#26 07.02.11 19:34
Для того что бы не раздражала проблема 1 (собственный код) я задействую принципы коллективной разработки даже когда один. В комментариях писать чего хотел, использовать хранилище как историю изменений, задумываться над архитектурой (проявляется связность отдельных включений).

Кстати, часто приходит такая мысль, что не просто написал алгоритм для зачета, а придумал микроязык, с помощью которого будут выражаться мысли в данном модуле, классе задач. И такой язык совершенствуется от задачи к задаче.

Было у меня лет 15 когда я не то что бы не мог вспомнить кто написал код (хоть это был я сам), но я даже не мог понять что вообще автор хотел этим кодом сказать, какую мысль выразить. Все конструкции написаны на языке программирования, который я знаю и от которого есть документация, а что этот код хочет сделать не понятно. Слава богу больше такого не повторялось, на самом деле даже приятно открывать старые разработки.
DevКомпонент для чтения CF-формата. Описание CF-формата.#41 07.02.11 18:53
В свое время реверсил формат .1cd

Приятно что есть люди, которым близка тематика. То что конфигуратор не имеет своего API удручает, на больших проектах обеспечивать качество врукопашную, когда код постоянно модифицируется, любого выматает.
Управление проектамиЭссе о внедрении#28 16.08.10 14:22
(27) Сложно сказать без общей картины, по крайней мере пункт начинается с 4.20, т.е. вверху вероятно есть более общее описание, из которого этот пункт вытекает. А представьте ТЗ, которое буквально начинается так: 1.1 справочник Х, рекивизит 1 (число), реквизит 2 (строка),... И нигде не сказано откуда это, какова цель проекта, чего реально хочет заказчик. В результате, боевое подразделение разработчиков идет туда, не знаю куда, за тем, не знаю чем. Из разговора я понял как это происходит, человек пишет, что-то в тз, потом смотрит, что объем маленький, накидывает туда надерганных из разных конф реквизитов для солидности. Чистой воды подстава. Или вот интересный вопрос. Как до начала разработки можно понять количество документов в системе? (я больше работаю по конфам с нуля). Человек говорит, ну это же очевидно! Вот к пользователю приносят одну бумажку - это документ, вот он печатает пару других - это тоже документы. Результатом становиться то, что бюрократия бумажная превращается в бюрократию электронную. Недавно только клиент искал другую систему, жаловался, что на одно простое в общем-то действие ему надо заполнить кучу инфы в 5-6 документах. ИМХО правильнее было бы изучить процесс, выделить его временные этапы, участников, потом составить матрицу, на пересечении этапа и участвующего пользователя определить структуру информации (реквизиты, сведения...), определить название документа по его сути. Тогда может оказаться, что пользователь оформляет один документ, а остальные - просто подключенные печатные формы. Или например, позволит избежать ситуации, когда один документ заполняется несколькими участниками. Встречалось ли Вам такое, когда бригадир, делая отчет за смену, сидит и тупо не понимает, что за поле "себестоимость" или там "счет учета"?
Управление проектамиЭссе о внедрении#24 16.08.10 11:33
(4) Платиновые ваши слова. Ладно там заказчик, он может опыта не имеет, если вовремя, то можно направить в нужное русло, а вот когда свои... так и хочется каленым железом ... и каленом еще, каленом... Вот читаю ТЗ, а там написано, нужен справочник Договоры, а почему собсно справочник??? Кто это решил? Что термины "справочник", "документ", "регистр сведений" или реквизиты вообще делают в ТЗ? А потом получается, что ошибки и НЕУДАЧА проекта заложены уже в самом начале пути. Реализует их программист и спросят это с программиста. А кому еще задавать вопросы по реализации? Менеджеру по продажам, руководителю? Ей богу, как вижу в ТЗ состав реквизитов, так и хочется с ноги заехать.
Общие вопросы управленияДжоэл Спольски о программном обеспечении#12 21.07.10 11:57
Дельно написано. Я скажу так, если в вашей компании работают программисты, у которых есть устремление писать качественные продукты, то все, о чем пишет Джоел становиться очевидным. Например, о тех 15 минутах на вход в поток, о расстоянии между людьми, когда для того, чтобы отвлечь человека надо выйти в другую комнату или хотя бы снять трубку телефона. Я понял все эти вещи еще в 90 годах работая в средней оптовой фирме. Не важно по каким причинам в программисте живет этот стержень "писать хорошо, прокачивать требования и прорабатывать модели", потому что это круто или денег больше, пока его не сломали люди сами могут найти правильные решения и методы и найти свои "ноу хау", которые станут конкурентным преимуществом компании.

Как ломают? Начиная от менеджеров по продажам, которые еще до обследования обещают золотые горы клиенту в сжатые сроки и говорят "я все понял, тут все просто". И заканчивая корпоративными делами, когда 2 монитор тебе нельзя не потому, что денег нет, а потому, что другие тоже захотят. Правда не понятно, что в этом плохого, если это в разы экономит время при производстве изделия и делает, например, составление договоров, ТЗ, справок не таким муторным.
О жизниИстория программирования: Шура-Бура.#21 13.07.10 14:33
(17) нет, как говаривал Ошо, ни универсального добра, ни универсального зла. Взять хоть фантастику, она вдохновила многих людей заниматься наукой, да даже просто техникой. Как говорил Иешуа "А истина прокуратор в том, что у тебя болит голова.." от жары кажеться :))) Если честно, мне кажется, дядька, который это писал, либо либо слишком серьезно ко всему относиться или банально хочет привлечь к себе внимание, вот и весь хрен до копейки.
О жизниИстория программирования: Шура-Бура.#15 13.07.10 11:22
Скорее бы эта нефть уже кончилась, сколько разговоров про нее