Обсуждение статьи:
Ребёнок в истерике

страницы: <<   1 2 3   >>

31  nata77 свой человек	22.02.2011 18:57
Ближайший к Норильску сервисный центр в Красноярске :)))
+0

32  schmer друг	22.02.2011 21:04
Не припомню, чтоб железо отказались принимать по гарантии из-за косяков ОСи, а систему переставлять - случай не гарантийный)
+0

33  schmer друг	22.02.2011 21:08
Несколько раз тушки привозили с дефектом *не включается* а там просто Дебиан предустановленный ))
+0

34  schmer друг	22.02.2011 21:16
Бук принесли давеча.. медленно грузицо и там это, не удаляйте, документы архиважные, ребенок учится и в истерике. угу. в автозагрузке все, что можно автозагрузить, включая триальный Нортон, кончившийся 3 года назад, аська и 2 разновидности квипа и т.п. На рабочем столе 60 гиг в папаках, при девственно чистом диске Д: Из архиважных документов - ток фотки, которые хоть щаз в школу уродов - ни единого *txt по учебе. зато ребенок в истерике.
+0

35  SaAnVi tzar	23.02.2011 08:17
> систему переставлять - случай не гарантийный Ну эт понятное дело, коли сам снёс/поломал - сам и кушай. > не удаляйте, документы архиважные До боли знакомая ситуация. :)
+0

36  CTPAHHuK гость	23.02.2011 14:06
>...значительной горизонтальной структурой. >...ничего удобнее на современном рынке ПО, окромя Ёкселя и Аксесса, для быстрого анализа данных и разработки модели обработки НЕ ПРИДУМАНО. Придумано. И давно, еще до Екселя и Аксесса. AWK называется. В ..nix'ах со времен царя гороха. Perl - его продвинутый потомок.
+0

37  m0Ray вырусь-релокант	23.02.2011 17:35
Ну ты чо, это ж для профессионалов, а не мышевозил. ;)
+0

38  ZlydenGL знаток	24.02.2011 11:39
>Придумано. И давно, еще до Екселя и Аксесса. >AWK называется. Ну-ну, хотел бы посмотреть на МНОГОПРОХОДНОЙ анализ десятка таблиц со значительной горизонтальной структурой и значительным числом записей при помощи текстовой команды. Ну совсем уж в ерунду скатываться не надо? Этак можно утверждать, что и MySQL тоже писать не надо было - есть же AWK, зачем огород городить?
+0

39  ZlydenGL знаток	24.02.2011 14:51
Кстати, подобную зашоренность наблюдал на самом деле уже не у одного _поколения_ поклонников Unix / Linux. Да, при помощи CLI можно сделать _очень_ многое. Да, при знании синтаксиса нужных команд, или хотя бы опыте использования man, можно упростить / автоматизировать чертову уйму операций. Вот только не всякую операцию _удобно_ обрабатывать через CLI, и не всякая будет обработана быстро. Возьмем к примеру отвертку. Да, это универсальное устройство, уже давно придумана, еще до всяких там гаечных ключей и пассатиж, но есть куча операций, где отвертка или комбинация отверток будут _менее_ удобны к использованию, чем специализированный инструмент. Обратное тоже верно, ибо даже самым современным лобзиком заворачивать винты / саморезы не более удобно, чем пытаться отверткой выдолбить ту же штробу в бетонной стене.
+0

40  Kromsolog свой человек	24.02.2011 19:17
>А я традиционно заканючу о том, что большинство профессиональных прог для музыки сделано под венду И я. Заканючим хором и запишем результат на виндовую версию Audacity ;)
+0

41  CTPAHHuK гость	25.02.2011 11:19
> МНОГОПРОХОДНОЙ анализ десятка таблиц со значительной горизонтальной структурой и значительным числом записей при помощи текстовой команды. Каждый день скрипты отрабатывают сотни файлов с десятками тысяч записей... Спор бессмысленен, потому как каждый останется при своем мнении. Но, божет быть, Вы не будете в будущем упоминать об исключительности Ёкселя и Аксесса
+0

42  ZlydenGL знаток	25.02.2011 13:29
Хорошо, ОЧЕНЬ простая задачка навскидку, из тех, что на Ёкселе и Аксессе решаются на раз-два - именно из-за их АБСОЛЮТНОЙ в этом классе исключительности. Есть две таблицы - суть бухгалтерские записи из двух систем. Нужно "слить" две таблицы в одну при том, что остатки по конкретному клиенту должны биться (поскольку по сути часть записей из одной таблицы могут "расползаться" на неивестное число записей в другой; в конечной таблице данные должны быть максимально детализированы). Ах, да, пусть число записей будет совсем маленьким - 300 тысяч в одной таблице и 150 тысяч в другой. Для простоты решения предположим, что все хранится в рамках этих таблиц, без внешних связей. Я эту задачу решил за 15 минут написания кода + 5 минут выполнения, правда в конце первой минуты выполнение пришлось прервать для перестройки индекса (секунд 30). Если справитесь ХОТЯ БЫ за вдвое бОльшее время - дам следующую задачу, уже непосредственно связанную с АНАЛИЗОМ этих данных, а также предложу огнестрел на выбор для задачи "застрелиться", ибо решить аналитическую задачу БЕЗ графического представления НЕВОЗМОЖНО в разумный период времени.
+0

43  ZlydenGL знаток	25.02.2011 13:31
На самом деле спор действительно бессмысленен. Как уже писал выше, отверткой действительно можно выдолбить штробу, вот только штроборез выполняет эту задачу проще, быстрее и с меньшим повреждением исходного инструмента. Но "пациент" добавлен в коллекцию "зашоренных" - надеюсь на Вашем, Странник, примере, я еще смогу убедить других заблуждающихся, что под конкретную задачу нужен конкретный инструмент.
+0

44  m0Ray вырусь-релокант	25.02.2011 14:05
Что значит "слить"? array_merge() ? ;) Если чётко представляешь задачу, графический инструмент только мешает и ресурсы лишние жрёт.
+0

45  ZlydenGL знаток	25.02.2011 15:36
Это значит, что в одной таблице может присутствовать 1 запись на контрагенте "ИП Иванов ПП" на сумму 100 рублей, а в другой таблице -несколько записей на контрагенте "Многоуважаемый наш клиент Петр Петрович из славной семьи Ивановых" на суммы от 10 до 50 рублей; на выходе данной ситуации надо выкинуть запись из первой таблицы, оставив вторую. Ну давайте, линухоиды, покажите мне пример решения такой задачи - и если вы думаете, что примеры наименований гиперболизированны, вы ОЧЕНЬ сильно ошибаетесь :) Решите эту задачу - выложу задачу анализа, хотя безусловно знаю, что ее БЕЗ графической аналитики решить невозможно. Кстати, как вариант - то же распределение Бенфорда без графического режима раскидать можно. Но окинув взглядом один двумерный график - это сделать проще, чем анализируя даже сокращенную статистику по записям. Поверьте. Ну или проверьте, если садомазо начало присутствует :)
+0

46  ZlydenGL знаток	25.02.2011 15:39
Хотя нет, это слишком просто. Давайте так: в таблице 1 есть ТРИ записи по контрагенту "ИП Иванов ПП" на суммы 100, 150 и 500 рублей - а в таблице 2 есть россыпь записей по контрагенту "Многоуважаемый...", которые ДЕТАЛИЗИРУЮТ 500 рублевую запись первой таблицы, и одна запись, которая содержит слитые две записи таблицы 1 на сумму 250 рублей соответственно. На выходе надо получить две записи из таблицы 1 (на 100 и 150 рублей) и россыпь из таблицы 2, детализирующие 500 рублей. Можно включать таймер? :)
+0

47  m0Ray вырусь-релокант	25.02.2011 16:09
У контрагента есть идентификатор?
+0

48  ZlydenGL знаток	25.02.2011 16:11
Идентификаторы-то есть! Но - для каждой из таблиц он свой, со второй никак не связан :) Если б был единый - насколько моя работа упростилась бы... Но в подавляющем большинстве таковых нет, приходится бубны плясать.
+0

49  m0Ray вырусь-релокант	25.02.2011 17:50
А как вы тогда их увязываете? Алгоритм есть? Если есть, по фигу на чём его описывать. Дело привычки.
+0

50  schmer друг	26.02.2011 17:26
Уважаемые Гуру *nix'ов, скажите как у этих осей дела обстоят с выводом HD видео, с блюрея, например?
+0

51  ZlydenGL знаток	26.02.2011 17:41
Алгоритм-то есть, но его есть смысл применять только на хорошо индексируемых объектах, иначе время выполнения зашкаливает за все мыслимые пределы. Одна из реализаций: в несколько этапов Этап 1. Увязываем тех контрагентов, которые в разных таблицах называются совершенно одинаково. Этап 2. Разбиваем наименования контрагентов из первой таблицы на значащие элементы (отбрасываем ИП, ООО, ОАО, ТП и т.д.) и ищем повторение этих элементов в наименованиях контрагентов из таблицы 2. При этом если если есть связь 1к1, то связка рабочая. Этап 3. То же самое, только разбиваем несвязанных контрагентов из таблицы 2. Еще раз повторюсь - эта задача выполнима обычными способами, но эффективная работа решения возможно только при использовании ПРАВИЛЬНОГО инструмента. Плюс что-то мне подсказывает, что на VBA заложить практически любую аналитическую логику всегда будет в разы проще, чем через текстовую команду общего назначения.
+0

52  m0Ray вырусь-релокант	27.02.2011 15:40
Никогда не держал в руках ни блюрейного привода, ни блюрейного диска. Да и машинка у меня слабовата для HD - Sempron 1.6ГГц - получаю слайдшоу на рипах. Однако принципиальных проблем никаких не должно быть на достаточно мощной машине. VBA - это тоже язык программирования, только зачем-то прицепленный к монструозной графической примочке. Если привычка к VBA - понятно, что с ним будет проще. Я ж говорю - дело привычки. Принцип же unix - каждый инструмент должен быть для своеей задачи и эту задачу делать хорошо. Если же опенофис взять - в нём и VBA, и python, и JavaScript есть - на любой вкус. Только это не встроено в него - сами языки реализованы модулями и связаны с соответствующими языковыми пакетами. Точнее, VBA всё же встроили - прогнулись перед подоконниками - но я лично это не одобряю. Хотя позволило поднять популярность. И да, под никсами всё обычно работает быстрее, особенно что писано не строго под винду. Попробовали бы хоть, прежде чем объявлять об исключительной тормознутости опенофиса... Даже заядлые игроки в "контру" говорят, что в WINE она даёт бОльший FPS, нежели под родной виндой. И это не удивительно.
+0

53  SaAnVi tzar	28.02.2011 05:38
А почему когда я говорю, что у меня сайт без использования SQL, меня все чморят? :)
+0

54  CTPAHHuK гость	28.02.2011 10:03
> под конкретную задачу нужен конкретный инструмент. Именно так. И у каждого Мастера свой набор инструментов. Мастер делиться своим опытом, а школота кичится брендом инструмента и мерится пиписками. :)
+0

55  ZlydenGL знаток	28.02.2011 10:06
> Если привычка к VBA - понятно, что с ним будет проще. А если нет никакой привычки? :) Я обычно кодю тем, что эффективней в конкретном случае, мне в целом без разницы, на каком языке писать. > Если же опенофис взять - в нём и VBA, и python, и JavaScript есть - на любой вкус. Тот же самый вопрос - покажите мне продукт-аналог того же монструозного MS Access со всеми его возможностями? Кстати, базовая часть MS Access, конкретно DAO, совсем не монструозная, даже если собирать инсталлер со ВСЕМИ необходимыми библиотеками - очень неплохой по функциональности софт вполне может влезть на 1-2 дискеты. Понятно, что по размеру это все равно не батник под (ba)sh, но и функциональность / юзерфрендлейность обычно просто несопоставима. > И да, под никсами всё обычно работает быстрее Ага, только вот чтобы это "все" обычно работало быстрее - надо долго воскуривать соответствующие форумы, да? Ну так мне просто жаль личного времени, которое можно грохнуть например на приятное времяпрепровождение с женой, а не на вычитывание мана по настройке видеопотока. > Попробовали бы хоть, прежде чем объявлять об исключительной тормознутости опенофиса... Пробовал, поскольку как-то нужно было нписать что-то вроде кроссплатформенного анализатора БД. Поимев тесные отношения с JAVA-based OpenOffice, в какой-то момент плюнул, развернул Kylix и быстренько набросал решение, которое может и не обладало гибкостью MS Excel, но конкретную задачу выполняло на ура - быстрее "коллеги" OpenOffice даже не в разы, а на порядки. > Даже заядлые игроки в "контру" говорят, что в WINE она даёт бОльший FPS, нежели под родной виндой. И это не удивительно. Ну вот пусть заядлые игроки и дро(зачеркнуто) восхваляют линуха дальше - мне для повседневной работы более чем хватает винды, особенно с учетом того, что нужного мне ПО никто писать не собирается. Ну а мне сильно и не надо :) И кстати я что-то до сих пор не вижу решения задачки, предложенной выше. Напоминаю, что на ее решение нужно 15 минут быстрого кодинга, 30 минут - если от души продумать алгоритм, час - если предусмотреть множественные вспомогательные случаи по увязкам на базе нечеткой логики. Причем именно потому, что и MS Access, и MS Excel дают изначальный графический базис, который не надо прописывать, этот процесс достаточно быстр - но на тех же дельфях/сях решение под конкретную задачу я бы вряд ли ваял дольше того же часа. Где же решение на awk, который "украден до нас"?
+0

56  ZlydenGL знаток	28.02.2011 10:10
> А почему когда я говорю, что у меня сайт без использования SQL, меня все чморят? :) Предлагаю вместе дюзнють в зюзю тому, кто смеет задирать лапку на боевое решение, не имея под рукой опыта разворота аналогичных проектов :) > Мастер делиться своим опытом Золотые слова! Только к чему тогда была изначальная фраза "Придумано. И давно, еще до Екселя и Аксесса. AWK называется. В ..nix'ах со времен царя гороха."? По мне так это ни что иное как кичение брендом опенсорса.
+0

57  CTPAHHuK гость	28.02.2011 10:19
> с выводом HD видео, с блюрея, например? Файлы MKV идут без проблем. Блюрэй не пробовал, ибо считаю что он нафиг не нужен. Но по отзывам в инете, вроде как в никсах не поддерживаются только диски с защитой. Ну и не зря же существует целый пучок проектов домашнего кинотеатра на базе линукса.
+0

58  m0Ray вырусь-релокант	28.02.2011 12:43
Воскуривать ничего не надо, всё работает "из коробки". Решать я в общем-то и не собирался ничего. По первому описанию ваша задача в общем виде не решалась, по второму - решалась тривиально практически любым инструментом. В случае с Kylix вы сами же себе доказали, что годится любой инструмент, даже основанный на учебном ЯП.
+0

59  m0Ray вырусь-релокант	28.02.2011 13:05
Что касается SQL... У меня за плечами, пожалуй, уже сотни проектов. Из них без SQL - единицы. Это там, где в принципе нет динамического контента. Конечно, решение данного сайта тоже неплохо, "чморить" тут не за что, но я бы сделал по-другому. БД - она как-то свободы больше даёт, имхо... Про кинотеатр на линухе - да, один MythTV чего стОит...
+0

60  ZlydenGL знаток	28.02.2011 15:37
> По первому описанию ваша задача в общем виде не решалась, по второму - решалась тривиально практически любым инструментом. Жесть, потому что как раз первую задачу приходится решать довольно регулярно (сообщение №42, если что), а вот вторая задача - что называется аггрегация различных примеров в один среднего уровня сложности (сообщение № 46). Где логика? > В случае с Kylix вы сами же себе доказали, что годится любой инструмент Любой ПРИСПОСОБЛЕННЫЙ инструмент. Если бы в Kylix'е не было компонент работы с БД/ЭТ, то и реализовывать я б естественно на нем нифига не стал бы. Ну не люблю я отвертками штробить бетонные стены, поверьте :) > Что касается SQL... У меня за плечами, пожалуй, уже сотни проектов. Из них без SQL - единицы. Это там, где в принципе нет динамического контента. Алилуя!!! Т.е. ты прямо признаешь, что есть какминимум сотни твоих проектов, где "давно придуманной" командой AWK делать нечего? "Повторите это пожалуйста для первых рядов" :D > Воскуривать ничего не надо, всё работает "из коробки". Не буду утверждадь, бо в игры на линухе не бегаю и фильмы не смотрю, но ИМХО где-то в 2005х годах форумы были просто усланы вопросами, как ускорить работу игр до приемлимого. А в 2007 году ради интереса слил тогдашнюю реализацию Кноппикса, заинсталлил его на винт, обновил базу кодеков и попытался воспроизвести 700 метровый рип. ТАКОГО слайд-шоу на ноуте топовой конфигурации (2.3ГГц проц, 4 Гб оперативы) я не видел даже на своем K6-3 в процессе игры с виртуальной машинкой VirtualPC на втором монике. Не спорю, что сейчас ситуация вполне может выглядеть намного лицеприятнее - но остаюсь при своем изначальном мнении: слишком много на свете специализированного софта под винды, которое или не планируется к портированию на Unix/Linux, либо никогда не будет портировано. В случае типографов это Photoshop/Indesign, в случае музыкантов - софт Толи, в моем случае - инструменты быстрой разработки а-ля MS Excel/Access. И аналогов этим продуктам в Unix/Linux средах НЕТ.
+0

страницы: <<   1 2 3   >>

↑ к началу комментариев    ↑↑ к началу страницы

Вы не зарегистрированы. Зарегистрируйтесь или войдите в систему, чтобы не набирать каждый раз проверочный код (и иметь другие приятные функции на сайте). Действует суточный лимит анонимных комментариев для защиты от троллей, школоло-хакеров и спам-ботов. На текущий момент осталось комментариев: 10.

Добавить комментарий

Фулюганствовать не надо: соблюдайте правила приличия. Я не люблю комментариев не по делу типа "Оццтой!" и им подобных. Если хотите что-то покритиковать или поучить кого-то жизни - делайте это с чувством, с толком и с расстановкой.