| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
---|Ветка была без названия|---
Dmitry1 © (2002-10-16 13:58:00)Кто нибудь может посоветовать где можно посмотреть реализацию метода списания товара по FIFO.
MsGuns (2002-10-18 12:47:00) [21]>Johnmen © (18.10.02 12:15)
Итак, выясняется, что учет фактический в любой момент времени ОТЛИЧАЕТСЯ от учета "На бумаге" (или в компе, что в данном случае одно и то же)
Довод 1.
При занесении данных в учет (компьютер или бумага) тот, кто это делает, НЕ ВИДИТ товара и заносит его по накладной. Выясняется это не сразу, а чуть погодя, и приводит к КОРРЕКЦИИ учетного (компьютерного) документа уже с поправкой информации кладовщика.
(Например, по накладной покупателю отпустили шоколад "Аленка", а он ЧАСТЬ взял "Славутич" по той же цене).
Т.е. фактически товар перевыдается (по компьютеру) Но у нас есть только:
1. Остаток на карточке (условный, как я показал ранее)
2. Количество расхода по накладной НОВОЕ, написанное на бумажке кладовщиком (или тем, кто товар отгружал со склада). Пусть даже есть старое количество, все равно возникает конкретная путаница, ПОТОМУ ЧТО ОСТАТОК на карточке определяется не пересуммировкой всех записей по позиции, а простым сложением-вычитанием абстрактного числа с новым/старым кол-вом по накладной.
И хорошо, если это делается по одной позиции и только один раз.
Вживую месится все это очень даже густо, да еще и сразу по нескольким накладным, в суете и спешке (покупатель долго ждать не будет). Т.е. кто-то что-то забыл, и "история" остатка "умерла", а сам остаток "врет"
Довод 2.
Возврат товара. Покупатель, недовольный качеством части приобретенного НЕДЕЛЮ назад товара, возвращает его с требованием замены. На складе, допустим, уже нет этого товара (на остатке 0),
находим в компе его накладную недельной давности (при условии, что он ее прихватил с собою,- для мелкого опта и тем более розницы это маловероятно). Теперь в найденной накладной надо исправить кол-во выдать с, допустим 10, на 5, а вместо него выписать другой в количестве 5. Т.е. надо "откатить всю старую накладную, поправить ее, а потом закоммитить с подсчетом нового остатка. При одновременно выполняемых хотя бы на двую компах подобных операциях Вы неизбежно получите НЕВЕРНЫЙ остаток. На одном компе будет то же самое, например, при вырубании э/сети.
Если МОИ доводы показались интересными или тем более убедительными, продолжу.
Alexandr (2002-10-18 12:42:00) [22]ну шо вы спорите?
Подход Digitman ориентирован на клиент-серверные базы данных. И там при таком подходе тормозов при получении оперативного остатка на текущий момент не будет, и быстродействие выборки остатка будет максимальным практически независимо от количества пользователей.
Подход MSGuns ориентирован на FoxPro и другие файл-серверные базы данных, где действительно очень тяжело получать оперативный остаток в отдельной таблице (и при сетевой версии с большим количеством пользователей уходит в тупик, как он и говорит).
Так что оба правы, т.к. все зависит от специфики применения подхода и средств для осуществления.
passm (2002-10-18 12:42:00) [23]Jeer © (18.10.02 12:12)> Таким образом приходим к процедуре закрытия отчетного периода.
MsGuns © (18.10.02 11:46)> Насколько я понял предлагается выдергивать информацию о товарном остатке из журналов прихода/расхода. Если так, то это, ИМХО, не долговечно - понятно почему не приветствуешь большие таблицы.
Просьба не забывать о работе в оффлайн, где, в общем случае, из точек документы могут приходить не по хронологии.
Поддерживаю четырьмя <Digitman © (17.10.02 11:01)> и <Jeer © (18.10.02 12:12)>
Johnmen (2002-10-18 12:15:00) [24]>MsGuns ©
>Доводов могу привести с десяток...
Мне интересны именно доводы!
И именно твои !
(А теория и концепции известны ...) :))
Jeer (2002-10-18 12:12:00) [25]> Дата поступления
> Номер накладной
..
Еще ссылка на товар из справочника товара, разумеется.
1.Если это приложение торгово-учетное, то при партионном учете очень полезной бывает средне-приходная цена как
N1*P1+N2*P2+..+N2*P2
--------------------
sum(N1..Ni)
2. Разумеется, если режим работы не онлайн, товар в отчетности расходиться с наличием. Здесь надо правильно организовывать работу.
Товар сначала появляется на складе, потом в отчетности.
Товар сначала уходит из отчетности, затем со склада.
Иначе "дрова ломаются".
MsGuns (2002-10-18 11:46:00) [26]>Johnmen © (18.10.02 09:37)
>Вот уж против чего я возражаю КАТЕГОРИЧЕСКИ, так это вычисление
>остатка как разности(суммы) движимого по док-ту кол-ва и
>старого остатка. Доводов могу привести с десяток, но похоже,
>это мало кому интересно.
> А я бы послушал (в смысле, почитал :-))...
Да с удовольствием.
Термин "Остатки" отражает количество определенного наименования товара (в данном случае - ведь речь идет о складе ТОВАРОВ) в складе на некий момент времени. Если речь идет о начале месяца, недели, суток (раб.дня), то "остатки" называются сальдовыми или начальными.
Когда происходит убыль или прибыль товара в следствие расхода (продажи, перемещения, списания) или прихода (возврата, перемещения), это самое количество изменяется ФАКТИЧЕСКИ, о чем ДОЛЖНЫ БЫТЬ СДЕЛАНА ЗАПИСЬ в соответствующей книги учета (КНИГА учета товаров, товарно-кассовая книга, складская или бухгалтерская картотека учета товаров на складе или др.) В эти книги заносится не просто, что "поступило столько-то на сумму такую-то", а
Дата поступления
Номер накладной
Дата накладной (может отличаться от даты поступления)
Поставщик или покупатель
Цена учетная (по себестоимости без НДС)
Цена отпускная (при реализации)
Количество мест (ящиков, блоков и т.д.)
Количество в ед.измерения (кг,т,шт,л,..)
Сумма себестоимость
Сумма отпуска (не обязательно)
Сумма НДС (не обязательно)
Корр.счета (не обязательно)
Т.е. для КАЖДОЙ ПОЗИЦИИ ТОВАРА (кода товара) должно быть столько подобных записей, сколько было документов, по которым он (товар) приходил-уходил.
Т.о. НА КАЖДЫЙ момент времени существующий остаток есть не что иное, как сумма по колонке "Количество" (при условии,что расход вводлися по-красному, т.е. с минусом), который в течение дня может меняться многократно. Здесь речь идет об УЧЕТНОМ кол-ве (сумме), т.е. кол-ве, ЗАФИКСИРОВАННОМ в отчетности. Которое, если быть точным НИКОГДА НЕ СОВПАДАЕТ С ФАКТИЧЕСКИМ НА СКЛАДЕ.
(Товар уже выгружен на склад и принят кладовщиком/товароведом/менеджером, подписан путевой и машина уехала, а запись будет сделана только ВЕЧЕРОМ или НА СЛЕДУЮЩИЙ ДЕНЬ.
Если интересно, буду продолжать
Johnmen (2002-10-18 11:36:00) [27]>Johnmen © (18.10.02 09:37)
>>MsGuns ©
>>А я бы послушал (в смысле, почитал :-))...
MsGuns (2002-10-18 11:27:00) [28]>German Ivanov (18.10.02 03:36)
>Гду Вы видели, чтобы в живой фирме правили движение 3-4-х месячной давности
>Если ничего не путаю отчетность сдается раз в пол-года, раз в год.
Отчетность и подделка накладных не суть одно и то же.
>Поэтому вполне возможна ситуация с продолжительным хранением и модификацией остатков(в свете нагрянувшей отчетности).
Именно о таких фирмах я и упоминал, употребив слово "гнилые".
В таких лавках отчет обычно иделается "для ГНИ", как заметил Digitman. Типа "Деньги и товар-одно, отчетность-другое".
В НОРМАЛЬНЫХ фирмах учет нужен прежде всего для администрации, причем учет НОРМАЛЬНЫЙ, а не "для галочки". Скажу больше. Сегодня ЕКВОЗМОЖНО работать на мелкооптовом и оптовом рынке (не имею в видц газ, связ, коммуналку, жд и проч.монополистов) без НОРМАЛЬНО ПОСТАВЛЕННОГО УЧЕТА. В том числе БУХГАЛТЕРСКОГО.
Складской учет сам по себе не может дать такие жизненно важные характеристики, как эффективность продаж, прогнозируемость продвижения товара и пр. Я уже не говорю о том, что "со склада" не определишь, с выгодой торгуешь или себе в убыток.
>German Ivanov (18.10.02 03:42)
>Кстати по моему IMHO таблицы с огромным количеством записей это признак плохо спроектированной базы данных.
В точку. Можно цитировать другим
>Воспользовавшись этим мудрым постулатом, не могли бы вы таки высказать хоть одно предложение по теме вопроса? Не обругать чужие , кстати здравые идеи, а высказать свои собственные?
А я, собственно говоря, с этого и начал (первый мой пост), выступив катерогически против использования его при списании в ТОРГОВЛЕ. Могу, конечно, пояснить, и даже привести примеры "неудобоваримости" этого метода в чисто алгоритмическом плане и "брехливости" в эксплуатации. Но автор вопроса, похоже, исчез вместе с вопросом. Может быть, испугавшись возникшей здесь свары.
Jeer (2002-10-18 10:49:00) [29]Мужики ! Не деритесь !
Наше российская действительность очень многообразна и задач, сильно отличающихся по постановке и решению, выплескивает массу.
Если принципиально - то есть приложения, ориентированные на ввод, а есть на представление.
И это может быть одна и та же складская задача.
В некоторых случаях кладовщик, он же розничный продавец, он же логистик, он же бракер. В других случаях операторы и аналитики явно разделены. В одних случаях приход и отгрузка явно разделены по времени, в других - идет интенсивный переток.
У меня тоже немалый опыт написания учетных задач, еще начиная с DBASE II, а также CS.
Дополню постинги следующим: не всегда применение Оракла оправдано технической необходимостью - чаще это способ выйти на другие цены. И совсем не обязательно, что при таких ресурсах будут еще и оптимизацией заниматься.
Тот же, кто прошел "огонь и воды" ранних СУБД, тот и сейчас может с незначительными ресурсами создавать приемлимые по отклику приложения.
Johnmen (2002-10-18 09:37:00) [30]>German Ivanov
Да-а-а-а... Нагнал пурги ! И по поводу БД и по поводу своих наблюдений !
Не потрудившись даже зарегиться...
>MsGuns ©
Согласен с твоими представлениями о прогр-ии и окружающих нас здесь людях...
>Вот уж против чего я возражаю КАТЕГОРИЧЕСКИ, так это вычисление
>остатка как разности(суммы) движимого по док-ту кол-ва и
>старого остатка. Доводов могу привести с десяток, но похоже,
>это мало кому интересно.
А я бы послушал (в смысле, почитал :-))...
German Ivanov (2002-10-18 03:42:00) [31]Кстати по моему IMHO таблицы с огромным количеством записей это признак плохо спроектированной базы данных.
Когда мне показывают нечто вроде каталога библиотеки с 10000 записей-наименований , я обычно говорю - "А почему бы Вам было не создать таблицы с именами А,Б...Я и не разложить в них книги по наименованию?" Разумеется пример утрирован, но общая идея на мой взгляд просматривается.
German Ivanov (2002-10-18 03:36:00) [32]Гду Вы видели, чтобы в живой фирме правили движение 3-4-х месячной давности
Если ничего не путаю отчетность сдается раз в пол-года, раз в год.
Поэтому вполне возможна ситуация с продолжительным хранением и модификацией остатков(в свете нагрянувшей отчетности).
Меня поразило еще СОВЕРШЕННО СЕРЬЕЗНОЕ заявление весьма уважающего себя человека о том, что СКЛАД и БУХГАЛТЕРИЯ - это абсолютно разные вещи.
Термин АРМ расшифровывается как автоматизированное рабочее место.
Кладовщик и бухгалтер являются одним и тем-же лицом как правило в небольших конторах. Бизнес логика приложений склада и бухгалтерии совершенно различна. Это база данных у них одна. Протестуя против таблицы с "горячими остатками" вы совершенно упустили из вида что это может быть банальный вид или связанная таблица с вычисляемым полем.
то если НЕ ЗНАЕШЬ КАК КОНКРЕТНО ПОМОЧЬ товарищу, нечего соваться с умным видом
Воспользовавшись этим мудрым постулатом, не могли бы вы таки высказать хоть одно предложение по теме вопроса? Не обругать чужие , кстати здравые идеи, а высказать свои собственные?
начиная с "тыкания" заведомо более старшему человеку
По моими наблюдениям, начиная примерно с 25 лет , люди начинают пользоваться в публичных местах своим (или чужим) именем и фамилией.Кличка в качестве своего идентификатора признак подростка. Дополнительным признаком является комплекс неполноценности приводящий к непрерывному выпясиванию своего пениса с целью померятся его размерами.
MsGuns (2002-10-17 19:00:00) [33]>petr_v_a © (17.10.02 17:06)
Не имеет смысла держать в рабочей БД движение более чем за 2-3 месяца ! Все остальное - в архив, который ТОЛЬКО ПРОСМАТРИВАЕТСЯ ! Гду Вы видели, чтобы в живой фирме правили движение 3-4-х месячной давности ? Я лично видел такое раза 2, но там были такие гнилые торгаши (в смысле химичили напропалую, что в итоге и закончилось для них плачевно..)
И вообще данные о номенклатуре товара, его динамике, эффективности продаж, доходности и пр. более чем 2-х месячной давности могут интересовать разве что директора или Гл.менеджера в качестве ОБОБЩЕННЫХ СРАВНИТЕЛЬНЫХ ДАННЫХ, да и то по ГРУППАМ товаров, а не по конкретной позиции.
Что же касается физической фиксации "горячих" остатков в одной (или более) таблицах БД, то я не был КАТЕГОРИЧЕСКИ против, я просто доказывал, что это будет работать ДОЛЬШЕ ! Вот и все.
У меня, кстати, есть и такие, и такие проекты.
Вот уж против чего я возражаю КАТЕГОРИЧЕСКИ, так это вычисление остатка как разности(суммы) движимого по док-ту кол-ва и старого остатка. Доводов могу привести с десяток, но похоже, это мало кому интересно.
Также КАТЕГОРИЧЕСКИ против LIFO/FIFO, т.к. это путь в гроб. Говорю не потому, что я им не пользуюсь (У меня, кстати есть проги, где он используется, например в программе "Маслоцех", где именно таким образом списывается семечка), а потому что это ТЯЖЕЛО РЕАЛИЗУЕМЫЙ АЛГОРИТМ, КОТОРЫЙ ОЧЕНЬ ЧАСТО БУДЕТ ДЕЛАТЬ НЕ ТО, ЧТО НАДО ! Доводов могу привести достаточно, но не буду по той же причине.
Меня поразило еще СОВЕРШЕННО СЕРЬЕЗНОЕ заявление весьма уважающего себя человека о том, что СКЛАД и БУХГАЛТЕРИЯ - это абсолютно разные вещи. Тут даже возразить нечего,- язык отнимается. Но спасибо, товарный знак уже знаем.
А вообще-то сколько программистов, столько и методов решения любой проблемы, в т.ч. и этой.
Суть моего "наезда" на Digitman © в том, что я не понял его высоконаучного тона, за которым, ИМХО, часто скрывается некомпетентность. Чего от начал на меня катить бочку я так и не понял, кроме одного: товарищ возмутился какой-то там... . И вообще, я считаю, что если НЕ ЗНАЕШЬ КАК КОНКРЕТНО ПОМОЧЬ товарищу, нечего соваться с умным видом. Если я не шурупю как следует в ООПе, я вообще не высказываюсь в ветках типа API или Система. Наезжать надо по делу, сначала разобравшись в сути критикующего.
А вообще-то я заметил, что хорошим тоном на форуме с некоторых пор стало унижение собеседника, начиная с "тыкания" заведомо более старшему человеку, который к тому же обращается вежливо и на "Вы".
petr_v_a (2002-10-17 17:06:00) [34]> MsGuns вынужден поддержать в чем-то поддержать Digitman © :))
Предлагаемая Вами схема хорошо рабаотает, пока по складам идет 100, ну 300 операций в день и система работает год ну полтора ((: Еще как при ней бороться с таким явлением, как несогласованное чтение?
MsGuns (2002-10-17 13:36:00) [35]>Digitman © (17.10.02 13:10)
>Предлагаю закруглиться с публичными упражнениями в демонстрации "крутости"
Ну и ладненько q;ь
Digitman (2002-10-17 13:10:00) [36]>MsGuns
Вот к чему ты все это ?) Я не понял. Единственный пост, адресованный тебе - это насчет "неважно", да и то сведенный до шутки) ... Все остальное (хочешь читай или не читай) адресовано автору вопроса в кач-ве пояснений ... Ему и выбирать, сойдет ли подобная примерная организация и механизм для его целей.
Ты же, imho, вместо рекомендаций автору, основанных на своем видении решения, просто начал uppercase-шуметь не по адресу... Демонстративно и, imho, безапелляционно навязывая собственную, субъективную (но почему-то представляемую как единственно верную) практику решения подобных частных задач
>>ты не очень разбираешься в предмете ТОРГОВЛИ
мне это и не требуется) ... ни профессионально ни иначе)
>>программисту наплевать, что хочет пользователь
..или он не программист
>>мое скромное замечание в твой адрес
Ну уж извини, скромным я бы его никак не назвал
>>Сочувствую тем непрограммистам, которые имеют несчастье общаться с тобой в качестве лохов-бухгалтеров
А при чем здесь бухгалтеры ? И тем блоее - лохи ? Разве о бухучете вообще идет речь ? То, как складские операции отражаются (в результате проведения) в чисто бухг.отчетности - совершенно из другой оперы. Будь уж так любезен - не меси в общую кучу подсистемы склада и бухучета)...
Скажи на милость - с каких пор ГНИ (ради чего бухгалтерия и существует в первую очередь) стала интересоваться - FIFO или LIFO уходит изделие/товар ? Произвел/Получил/Продал/Списал/Украл/Заныкал товар - будь любезен, товарищ бухгалтер, заплати/получи бабки и отчитайся как положено, когда, что, сколько, на какую сумму и на каком основании... И привяжи все это, тов.бухгалтер, к установленному плану счетов .. А как это там у тебя (или в твоей конторе), товарищ бухгалтер, организовано физически или как тебе удобней вести внутренний учет товара - по-барабану, это твои проблемы...
>>"голубые"
Это ты о чем, сударь ?
>>могут быть так самолюбивы и не терпят малейшей критики.
Ну отчего же) ... К критике я отношусь вполне адекватно ... Если это критика, аргументированная и без распальцовки
>>Бери пример с того же Зотова
Да всенепременно !) Как только <Юрий Зотов> сочтет нужным поучаствовать в дискуссиях и поделиться опытом в разделе "Базы данных", обязательно возьму - не сомневайся даже)
>>человек не боится сказать, что он ОЧЕНЬ МНОГО НЕ ЗНАЕТ !
И оч.правильно делает. Полностью с ним согласен, потому как сам такой)
>>После этого его авторитет нисколько не пострадал, наоборот вырос (например, для меня)
Во благо бы ! Только вот прочие в большинстве люди все же создают и заходят в ветки дискуссий не на предмет авторитета или отрицания оного, а чтобы спросить, определиться, поделиться опытом и идеей, поймать идею (в отсутствии ее), сориентироваться в направлении поиска и т.п.
P.S.
Думаю, дальнейший треп на эту тему будет неуместен, ибо риск угодить в "Потрепаться" растет в геом.прогрессии)...
Предлагаю закруглиться с публичными упражнениями в демонстрации "крутости"
P.P.S.
Еще раз повторюсь - я всего лишь поделился общеконцептуальными соображениями с автором. Бредовые они или нет, понадобятся ли они ему, заинтересуют ли детали - ему выбирать.
Polevi (2002-10-17 12:57:00) [37]2MsGuns © (17.10.02 11:16)
у меня в базе 50 тыс счетов и таблица содержимого их содержит милион записей - вы предлагаете каждый раз динамически вычислять остаток по позиции создавая курсор на
SELECT * FROM Contents WHERE GoodID=12345 ???
Одновременно 10-15 операторов добавляют записи
Или я чегото не понял, или будет жуткая тормозня, если все делать по вашему
MsGuns (2002-10-17 12:24:00) [38]>Наталия © (17.10.02 12:03)
>2. Чтобы получить остаток из таблицы ДВИЖЕНИЕ (например 1 млн.записей) надо сделать select sum(кол-во) для конкретной позиции. Сервер конечно,посчитает, но всё-таки это будет медленнее.
Вы недостаточно внимательно прочитали мой пост о технологии подкачки движения, где я отметил цифру 100 как макс ПО ОДНОЙ ПОЗИЦИИ. Простой пробег по строкам или агрегатное поле (еще быстрее, т.к.формируется про основном запросе) займет времени меньше, чем тот же пересчет, но с записью в "Таблицу Остатков".
Если же Вы предлагаете остаток считать по простой схеме
[Остаток] = [Остаток] -(+) [Кол-во по строке док-та]
то флаг Вам в руки. Тем более, что так делается в БОЛЬШИНСТВЕ складских программ. Сочувствовал и до сих пор сочувствую тем людям, которые до сих пор работают с подобными технологиями. Вот уж где, действительно, без откатов (о которых так вдохновенно вещал Digitman) не обойтись !
Для локалки или для 2-3 станций это работает, но не более !
Наталия (2002-10-17 12:03:00) [39]MsGuns © (17.10.02 11:16)
1. Да хоть пять операций в одну секунду - на клиенте сделать DataSet.Refresh для одной позиции - c сервера вытягивается одна строка. (например в таблице ОСТАТКИ 5тыс.позиций) Чтобы лишнее не списали - механизм исключений.
2. Чтобы получить остаток из таблицы ДВИЖЕНИЕ (например 1 млн.записей) надо сделать select sum(кол-во) для конкретной позиции. Сервер конечно,посчитает, но всё-таки это будет медленнее.
MsGuns (2002-10-17 11:48:00) [40]>Digitman © (17.10.02 10:54) и все последующие..
На "ты", так на "ты".
Во-первых, я хотел сказать, что ты не очень разбираешься в предмете ТОРГОВЛИ(там просто лишняя частица "не"), и все твои последующие посты лишь подтверждение этому.
Да, в умении заумно и наукообразно выражать простые мысли тебе отказать трудно. Видно, что книжек начитался да и опыт работы в Клиент-Сервере немалый (чего не могу сказать о себе). Сочувствую тем непрограммистам, которые имеют несчастье общаться с тобой в качестве лохов-бухгалтеров. Однако умение закладывать крутые виражи не очень-то нужно при первозках крупнотоннажных грузов. Та схема, что ты так настойчиво отстаиваешь, является надежной только при малых нагрузках на БД.
Когда одновременно :
-5 операторов выписывают счета или накладные
-2 товароведа заводят приходы
-6-7 менеджеров просматривают остатки на предмет составления заявок на допоставку товара
-2-3 бухгалтера "правят" документы прошлого месяца
-кладовщики делают пересортицу
эта схема с транзакциями лопнет по швам или на ее поддержку надо будет ставить что-то типа Оракла на счетверенном пне-IV, класть оптоволокно и т.д. Иначе или все будут безбожно тормозить или остатки будут так же безбожно врать.
Не буду тебе доказывать свою правоту по причине полной безнадеги. Для того, чтобы это понять, надо не работать 5 лет с готовой программой, а самому написать хотя бы с пяток подобных проектов, а потом их посопровождать лет эдак по 5, да в РАЗНЫХ по специфике и объемах фирмах.
Твое мнение по поводу организации складских остатков ТИПИЧНО для подавляющего большинства НЕ ОЧЕНЬ ХОРОШИХ программистов (ИМХО). Для того, чтобы писать классные программы, к сожалению совершенно недостаточно даже ВЕЛИКОЛЕПНОГО понимания ООП и знания в совершенстве десятка серверов БД и такого же кол-ва программных сред. Типичное заблуждение (к сожалению, и на этом форуме, особенно среди новичков) - ПРОГРАММИСТУ НАПЛЕВАТЬ, ЧТО ХОЧЕТ ПОЛЬЗОВАТЕЛЬ. Главное,- это красивый интерфейс и крутые штучки типа хуков и выкрутасов с железом. Ну и чтоб "классно катили транзы" (выражение одного моего знакомого-свистуна)
Мне очень жаль, что мое скромное замечание в твой адрес вызвало такую бурную реакцию, не думал, что "голубые" могут быть так самолюбивы и не терпят малейшей критики. Бери пример с того же Зотова - человек не боится сказать, что он ОЧЕНЬ МНОГО НЕ ЗНАЕТ !
И ничего ! После этого его авторитет нисколько не пострадал, наоборот вырос (например, для меня)
| |
Страницы: 