И так ужасно ли то, что ты не знаешь в тонкостях работу красно-черных деревьев или путаешь линейный дискриминантный анализ с вторым законом Ньютона?
О этом много говорят: на конференциях, на бигдатовских тусовках, на собеседованиях… Но на практике, при решении конкретных бизнес-задач в жесткие сроки, может оказаться — что твои академические знания как-то странным образом «не особо требуются» и горячий кэш мозга для эффективной работы содержит лишь названия библиотек в boost, java или консольных команд unix, пути к файлам логов и незарастаемую тропинку к бите в подсобке.
Да, я помню вычислительную машину Тьюринга, теорию регулярных выражений на основе конечных автоматов и не только, ragel — а на практике нужно знать, что есть grep, egrep, awk, немного perl и синтаксис регулярок на уровне популярных кейсов.
Да, очень прикольно удаляются узлы в RB-дереве, а очередь с приоритетами иногда даже может быть полезна… но я пишу старый добрый кулинарный SQL-запрос и использую индексы.
Конечно, понятно «в целом» для чего нужна операционная система — но в данный момент меня интересует ключ, выводящий подробности о принадлежности потоков в команде ps.
Полезно знать о поиске в глубину из теории графов и многочисленные NP-hard задачки и подвохи для неопытных, которыми можно пугать внуков — но гораздо чаще требуется понимать на пальцах рук и ног, как работает IP, из чего состоит пакет и почему тормозит этот скрипт, который написал коварно улыбающийся разработчик, попивающий горячий кофе.
Да, конечно, процессор выполняет жестко (не совсем, но нередко в CISC и RISC) запаянные в него команды и понимает небольшой, ограниченный, примитивный набор команд — но, коллеги, без strace часто не понятно, что дает дыхание жизни этому потребляющему 10ГБ ОЗУ крокодилу.
Оказывается, что практически все немногочисленные научные достижения в области вычислений за последние полвека, которые можно собрать в небольшую пригоршню — собраны, обсосаны и реализованы сотни раз и в базах данных, и в распределенных файловых системах и особенно модных сейчас NoSQL-решениях. И нередко возникает другая проблема — знать, что это уже давно сделано и готово и лежит там-то, а не изобретать велосипед и придумывать в рабочее время давно выстраданных кем-то в диссере алгоритм.
Складывается устойчивое впечатление, что на практике гораздо ценнее иметь не очень сложные, но требующие глубокого погружения обширные прикладные знания — тонкости C++, системные вызовы unix, структура пакета TCP, ключики команды ps, типы сборщиков мусора jvm — чем набивать голову обсосанной десятилетиями в научных кругах теорией алгоритмов и вычислений. Хотя конечно, расширение кругозора в свободное время — дело безусловно полезное.
Машинное обучение
С очередной, в который раз за последние десятилетия, модой на нейронки — deep learning и поиском «золота» в больших массивах данных, ну да, стало чуть повеселее. Начали вспоминать «подзабытую» банальную математическую статистику с логистическими регрессиями, бородатый столетний байесовский классификатор. Появились как грибы после дождя утилиты «анализа больших данных», которые ничего алгоритмически сложного внутри себя не представляют и пишутся средним разработчиков на пару отпусков: Spark, Hadoop/MR и т.п.
Анализ языков
В этой области на голом обратном индексе с примочками без машинного обучения, конечно, очень трудно. Но опять таки — это область достаточно узкая, и если ты не лингвист и знаешь русский язык на уровне школы — придется сильно попотеть годик-другой, пока не станешь разбираться в базовой терминологии.
Выводы
Фанатизм в приобретении теоретических знаний может отобрать много времени и сил, а на практике знания могут не пригодиться и выветриться — т.к. почти все нужное человечеству уже написано/переписано по 100 раз в стандартных библиотеках, БД, файловых системах и прочей классике.
Приобретение практических навыков: детали языков программирования, особенности unix, настройки софта, среды разработки, SQL, модные NoSQL возможности (а это опять таки подзабытые старые добрые алгоритмы) и немодные, но не менее мощные SQL инструменты — гораздо более полезно.
Не нужно париться по поводу неглубоких знаний теории графов — возьмете готовое решение, если повезет столкнуться с этой задачкой.
Учимся коммуницироваться и работать в команде. Хорошее настроение — залог успеха проекта.
Не нужно страдать по поводу некомпетентности в области машинного обучения и больших данных. Это для ученых, математиков, аналитиков и научных работников — все равно ничего особо не поймете, если не решали задачи повышенной сложности со школы. Тут важнее понять бизнес-применение. И если окажется, что навороченая нейронка тянет на решение задачи распознавания образов и звуков и вашей онлайн-игре или веб-проекту ну никак не поможет — нечего тратить нервные клетки.
Читайте мануалы по unix и до конца. Их много, это надолго и серьезно. Когда программа будет стабильно и предсказуемо работать — нальете чаю, закажете книжку типа этой и насладитесь наукой.
Всем удачи, побольше практических кейсов и хорошего настроения!
Комментарии (346)
lair
12.03.2016 11:54+8А нужно ли знать программисту алгоритмы?
Нужно знать теорию анализа и проектирования алгоритмов — чтобы хотя бы понимать, как оценивается сложность вычисления.
AlexSerbul
12.03.2016 12:03-5там вся теория — две строки по сути
lair
12.03.2016 12:07+9Даже нотацию большого O сложно запихнуть в две строки.
AlexSerbul
12.03.2016 12:20Ад, квадрат (тоже ад, но иногда нельзя), линейно-логарифмическая зависимость, линейная. Понимать что значит, что задача просто не решается и требуется перебор (NP, криптография с открытым ключом, разложение на множители и т.п.).
lair
12.03.2016 12:30+9Недостаточно перечислить, надо знать, как это определяется.
Понимать что значит, что задача просто не решается и требуется перебор
И откуда это понимание возьмется?
требуется перебор (NP,
… эээ, а почему перебор — это обязательно NP? Есть задачи, которые можно решить перебором за линейное время.AlexSerbul
12.03.2016 12:33Как научиться понимать — посмотреть в таблицу известных алгоритмов с указанной стоимостью. Возьмем задачку дискретного логарифмирования и попробуем ускорить процесс :-)
lair
12.03.2016 12:35+8Как научиться понимать — посмотреть в таблицу известных алгоритмов с указанной стоимостью
Вот и закончились (давно уже) ваши две строчки. Собственно, получается, что знать-то — надо.AlexSerbul
12.03.2016 12:37Да вот поэтому и написал пост. С одной стороны быть компетентным — правильно. Учиться и постигать науку — нужно. Но из практики получается, что требуются знания другого рода, как не парадоксально.
lair
12.03.2016 12:39+11Требуются знания обоих родов. И ничего парадоксального в этом нет.
AlexSerbul
12.03.2016 12:41Чтобы unix знать, нужны годы практики. Либо это будут поверхностные понятия. Я об этом.
lair
12.03.2016 12:57+3И вы по каким-то причинам считаете, что для программиста (любого, без уточнений) поверхностные знания в юниксе — это хуже, чем поверхностные знания в алгоритмах?
AlexSerbul
12.03.2016 13:06Если пишешь код — пойми где и как он выполняется и каким софтом другим. И так по цепочке. Остается мало времени на теорию, к сожалению.
lair
12.03.2016 13:16+5И так по цепочке.
Вплоть до электронов, я надеюсь?
(нет, вы серьезно считаете, что абстракция — ненужная вещь?)
AlexSerbul
12.03.2016 12:34По сути, да, нужно просто выучить список того, что уже открыто — 3 страницы. Чтобы пузырьком не сортировать :-)
lair
12.03.2016 12:35+4По сути, да, нужно просто выучить список того, что уже открыто
Мало выучить список, неплохо бы еще понимать, что там зачем.
psylosss
12.03.2016 21:36+3Мало выучить список, неплохо бы еще понимать, что там зачем.
Понимать — до уровня электронов?lair
12.03.2016 22:07+1Нет, зачем, там есть формальное описание.
psylosss
12.03.2016 22:12+4Разве формальное описание не обязательно понимать? На эту тему есть замечательный отрывок из интервью с Фейнманом — Почему так сложны вопросы "почему"?. Кому-то достаточно знать "формального описания" и принимать его за основу, кому-то недостаточно. Кому-то даже формального описания знать не нужно, достаточно знать что
O(1) < O(log(N)) < O(N) < O(N*log(N)) < O(N^2) < O(N^3)… < O(a^N) < O(N!)
и уметь угадать сложность с точностью примерно плюс-минус пару-тройку звеньев. А кому-то покласть на эту сложность, потому что у него по жизни N=3.lair
12.03.2016 22:16Разве формальное описание не обязательно понимать?
Обязательно. Но на этом уровне абстракции (псевдоязык и матаппарат) можно остановиться.
gandjustas
12.03.2016 22:17Если по жизни N=3, то алгоритмы не нужны, все задачи решаются перебором.
Вот только у любой базы данных N не имеет верхней границы, и O-нотация внезапно становится важна.
deniskreshikhin
12.03.2016 12:41+11Если программист — программист, то достаточно увидеть это:
O(1) < O(log(N)) < O(N) < O(N*log(N)) < O(N^2) < O(N^3)… < O(a^N) < O(N!)
90% алгоритмов это перекрывает.lair
12.03.2016 12:56+19Осталось понять, в какую категорию относится конкретный только что написанный код.
deniskreshikhin
12.03.2016 14:34+1Да это тоже просто, каждый цикл обычно дает множитель N. Поиск по упородоченным структурам (дереву, куче, отсортированному массиву) дает множитель log(N). Все остальное можно узнать в описании либ (если используются).
lair
12.03.2016 14:40+10Да это тоже просто, каждый цикл обычно дает множитель N.
Каждый вложенный цикл. Но представьте себе, что у вас классический рекурсивный алгоритм "разделяй и властвуй" — в нем, конечно, вложенные циклы, но какой множитель они дают?
Поиск по упородоченным структурам (дереву, куче, отсортированному массиву) дает множитель log(N).
Ох. Поиск по упорядоченному дереву дает O(h), а не O(log n). Я не знаю, что такое "поиск в куче", но получение верхушки в куче (а это та операция, под которую куча "заточена") — O(1) (удаление верхушки — действительно O(log n)).
Все остальное можно узнать в описании либы.
Ах если бы.deniskreshikhin
12.03.2016 14:59-8Ох. Поиск по упорядоченному дереву дает O(h), а не O(log n)
Ахаха, лол, может тогда и вспомните какая функция связывает h и n?
Но, вообще речь не об этом. Любая дисциплина на 80% состоит из чистых знаний, и 20% смежных. O-нотация это смежные знания, они не делают программиста лучше или хуже. Да, порой это полезно. Но это не ключевой навык. Самого беглого знакомства достаточно.lair
12.03.2016 15:04+6Ахаха, лол, может тогда и вспомните какая функция связывает h и n?
В общем случае, h <= n. И все.
O-нотация это смежные знания, они не делают программиста лучше или хуже.
А какие же знания для программиста в общем случае "чистые"?
Самого беглого знакомства достаточно.
Достаточно для чего?AlexSerbul
12.03.2016 15:41-6Поиск по дереву — O(log n)
lair
12.03.2016 15:53+11Поиск по дереву — O(log n)
По любому, серьезно?AlexSerbul
12.03.2016 16:00-2Да нет, первый раз услышал про сбалансированные деревья :-)
Вы откровенно умничаете, неконструктивно жирно троллите и цепляетесь к несущественным мелочам, которые очевидны.lair
12.03.2016 16:02+8цепляетесь к несущественным мелочам, которые очевидны.
Кому очевидны? Человеку, который первый раз услышал про деревья? Или человеку, который некоторое время потратил на то, чтобы с ними разобраться?AlexSerbul
12.03.2016 16:05+3Но Ваши опасения разделяю. Страшно давать nodejs-разработчику с отрицательными знаниями алгоритммов давать проектировать. Так что лайкнул.
deniskreshikhin
12.03.2016 15:43-2В общем случае, h <= n. И все.
O(h) = O(log n) для почти всех упорядоченных деревьев.
А какие же знания для программиста в общем случае «чистые»?
Все что касается умения анализировать и формализировать задачи из реального мира и писать программы которые будут эти задачи решать. Если речь про ООП, то это умение построить иерархию классов, а затем описать методы и поля по той информации, которую представляет заказчик/начальник.
Т.е. если мыслить дисциплинарно, то программирование в основном строится на общении (психология, риторика), умении составлять тексты, описания, формализировать информацию (логика, диалектика, литературные навыки), умение работать с компьютером (браузер, текстовый редактор, командная строка), освоить что такое переменная, функция, число, строка, массив, таблица, что такое if/for/switch и немного ООП. И все, человек уже может работать программистом.
Достаточно для чего?
Получить работу программистом, работать программистом, получать за это деньги, двигаться по карьерной лестнице.
cypok
12.03.2016 15:53+5O(h) = O(log n) для почти всех упорядоченных деревьев.
Только для сбалансированных. Для обычных упорядоченных ничего больше O(h) = O(n) гарантировать нельзя.deniskreshikhin
12.03.2016 16:17-2Смотря что подразумевать под O, худший случай да. В среднем же O(log n).
wataru
13.03.2016 21:35+3Извините, что вклиниваюсь, но сама фараза "смотря что подразумевать под O" просто требует комментария из-за ее абсурдности и противоречивости. Есть конкретное определение O() и не с потолка оно взято. Конкретные свойства делают это определение полезным на практике. И подразумевать под O() что-то другое никак нельзя.
deniskreshikhin
13.03.2016 22:31Имелось ввиду, что подразумевается под выражением в целом, а не что такое O. Худшая оценка высоты дерева, да O(n). Средняя O(log n). Я думал это понятно итак, без оговорок.
mayorovp
13.03.2016 22:37Оговорки все равно нужны. В данном случае — про способ и порядок построения дерева. Есть задачи, в который построение дерева без балансировок будет стабильно выдавать длинные "сосиски" со средней высотой O(n).
Кстати, одна из таких задач очень распространена. Я говорю про индекс в базах данных, построенный по автоинкрементному полю.
wataru
13.03.2016 23:18+1Опять же, не придираясь к фразе, средняя оценка — это если входные данные случайны. А как вам уже ответили — это далеко не всегда так. Кроме того, если сервер можно подвесить каким-то запросом, который является худшим случаем, то это совсем не хорошо.
deniskreshikhin
13.03.2016 23:47-4Это так, однако qsort до сих пор используется тут и там, причем порой в самом неудачном варианте.
Понятное дело, что все кто используют деревья обычно заботятся о балансировке.
Но речь то про другое, что все эти знания сомнительной ценности для разработчика. Например на stackoverflow с тегом [alogrithm] около 62.200 вопросов, а с тегом [javascript] 1,073,199 вопросов.
Да и в вакансиях я не встречал, что бы указывали желательное знание O-нотации или там умение балансировать деревья. Можно сказать конечно, что эти знания подразумеваются. Но почему тогда тут и там указывают какой-неть git, или "ответственное отношение к работе"? Уж эти требования тогда тем более можно не указывать.
Так что вывод неутешительный. Можно конечно бесконечно говорить и спорить, о том как важно знать алгоритмы, мучать Кнутом студентов и джуниоров. Но это все очень неправильно, если судить по-человечески. То что правильный путь, культивируемый сообществом и образованием приводит основную массу программистов не к успехам, а к дичайшим фейлам.
Другими словами, "прогнило что-то в Датском Королевстве".
mayorovp
13.03.2016 22:33+3Извините что вклиниваюсь во вклинивание, но программисты-практики часто под O подразумевают ? или даже ?
lair
12.03.2016 15:56+1O(h) = O(log n) для почти всех упорядоченных деревьев.
Только для сбалансированных. Впрочем, вам это уже написали.
Все что касается умения анализировать и формализировать задачи из реального мира
Ха, а ничего, что вы только что влезли в область работы аналитика?
И все, человек уже может работать программистом.
Есть некоторая разница между "может работать" и "хороший специалист".
Получить работу программистом, работать программистом, получать за это деньги, двигаться по карьерной лестнице
А, ну если в таких терминах, то да, сколько угодно.DrPass
13.03.2016 23:54-1> Ха, а ничего, что вы только что влезли в область работы аналитика?
Область работы аналитика является подмножеством области работы программиста. Это просто следующий уровень специализации в крупной команде.lair
14.03.2016 01:14+1Область работы аналитика является подмножеством области работы программиста.
Серьезно? Собирать со стейкхолдеров и писать хорошие, полные, непротиворечивые требования — это подмножество области работы программиста? Ну-ну, удачи этому программисту в том, чтобы найти время на программирование.DrPass
14.03.2016 01:38Серьезно. Фразу «следующий уровень специализации» вы недочитали, или намеренно проигнорировали?
Если вы делаете проект (хорошо, назовем его «проектик», а то некоторые начинают воротить нос, если слышат слово «проект» в отношении работы, которая делается командой меньше десяти человек и стоит меньше пары миллионов денег) в одиночку, вы будете собирать полные и непротиворечивые требования, и никуда от этого не денетесь, потом будете разрабатывать архитектуру, потом будете непосредственно программировать, потом тестировать, потом деплоить на продакшен. И всё это будет вашей работой программиста, и у вас будет время и на первое, и на второе, и на десятое. Когда-то в былые времена только так мы и работали, и ничего, выжили, не помер никто.
Если ваш проектик будет расти, ваша команда тоже, то у вас сначала появится другой программист, который всё это будет делать вместе с вами. Потом вы еще одного наймете, сами при этом сконцентрируетесь на архитектуре, управлении командой и всё еще на сборе требований, и всё еще будете программистом. А через какое-то время уже и девочку в очках с блокнотиком наймете. Как раз на сбор требований.
Специализация, она вот такая. Девочка эта не будет вам писать код, но она будет собирать требования, писать техзадания и формализовать алгоритмы. Вы её будете называть аналитиком, но по сути, она просто будет выполнять коммуникационную/бюрократическую часть работы программиста. Потому что забрать её у разработчиков и сфокусировать их только на написании кода — это таки да, здорово повышает их производительность.lair
14.03.2016 01:48+2Если вы делаете проект (хорошо, назовем его «проектик», а то некоторые начинают воротить нос, если слышат слово «проект» в отношении работы, которая делается командой меньше десяти человек и стоит меньше пары миллионов денег) в одиночку
… то то, что я делаю, не называется работой аналитика. А называется "сделаю проектик в одиночку".
вы будете собирать полные и непротиворечивые требования
Нет, не буду. Зачем?
(btw, нельзя собрать полные и непротиворечивые требования, можно только создать документ с такими требованиями)
Когда-то в былые времена только так мы и работали
Я не знаю, какие "вы" только так и работали, а я вот никогда так не работал. И судя по тому, что литература по работе с требованиями как отдельной дисциплине существует дольше, чем я работаю в отрасли, это не вчера началось.
Ну и да, если в каких-то командах роли совмещаются, это не значит, что все эти роли являются подмножеством одной области работы. Если я на том же проектике завел себе ИП, беру с людей деньги и веду финансовую отчетность — это никак не значит, что работа бухгалтера тоже является частью области работы программиста.DrPass
14.03.2016 02:46+1> … то то, что я делаю, не называется работой аналитика.
Почему это не называется? Именно так и называется. Проводя анализ, вы делаете работу аналитика. Если вы вздумаете пойти и подоить корову на ферме в качестве полезной подработки, вы будете делать работу доярки. А если поведете школьный автобус, то будете делать работу водителя школьного автобуса.
> Нет, не буду. Зачем?
Будете. Потому что без этого вы проект не выполните. Я сейчас не про качество вашей работы (удастся вам собрать всё непротиворечивое или не удастся — дело тридесятое), и не про объем (будет там документ на полгода работы или бумажка с тезисами по итогам одного совещания), а про сам факт выполнения такой работы.
> Я не знаю, какие «вы» только так и работали, а я вот никогда так не работал.
Значит, конкретно «вы» или пришли в эту профессию уже в 21 веке, или изначально попали в какой-то центр космических технологий. Поздравляю. А у нас в _этой стране_ в 1990-е годы такое только-только зарождалось, и было редким исключением, а не правилом профессиональной разработки.
> это никак не значит, что работа бухгалтера тоже является частью области работы программиста.
Это несравнимые вещи. Работа бухгалтера, как и доярки, для написания программы не требуется. А вот системный анализ требуется. И человек на должности системного аналитика по своей профессии, в отличии от бухгалтера, тоже программист.lair
14.03.2016 10:26+3Почему это не называется?
Потому что далеко не факт, что я не скипну этот этап полностью, как и любой из остальных.
Проводя анализ, вы делаете работу аналитика.
… но вообще, конечно, эта фраза очень показательна. "Делаете работу аналитика". Не работу программиста, а работу аналитика.
Потому что без этого вы проект не выполните.
Почему?
Значит, конкретно «вы» или пришли в эту профессию уже в 21 веке, или изначально попали в какой-то центр космических технологий.
Нет и нет.
А у нас в _этой стране_ в 1990-е годы такое только-только зарождалось, и было редким исключением, а не правилом профессиональной разработки.
"Этой страной" жизнь не ограничивается, если что. И выработанными здесь правилами (впрочем, уже устаревшими) — тоже.
Работа бухгалтера, как и доярки, для написания программы не требуется. А вот системный анализ требуется.
Нет, системный анализ для написания программы не требуется. Для написания программы нужны требования на входе.
Но представьте себе на минуту, что вы делаете игру. Для нее — иногда — нужен сценарий. Является ли работа сценариста частью работы программиста?
И человек на должности системного аналитика по своей профессии, в отличии от бухгалтера, тоже программист.
А человек на должности художника, рисующего картинки для игры?
Я повторюсь, то, что люди иногда совмещают разные роли, никак не означает, что все эти роли, на самом деле — часть работы программиста.DrPass
14.03.2016 11:31+1>> Потому что без этого вы проект не выполните.
> Почему?
Потому что нельзя писать для заказчика программы, не собрав его требований и не вникнув в них. Если вы это не сделаете, заказчик её у вас не купит.
> Нет и нет.
А у вас в профиле написан 1981-й год рождения. Вам было 19 лет, когда начался 21 век. Так что где-то вы врёте. Подозреваю, врёте сейчас, ибо вы-то ввязались в спор, ну а как же человек с тегом «Архитектор» в профиле может согласиться с чужим мнением, будь оно хоть трижды аргументированным? ;)
> «Этой страной» жизнь не ограничивается, если что
Полагаю, ни мне, ни кому-либо из других читателей форума факт вашей эмиграции не интересен. Тем более раз если вас отсюда увезли папа с мамой в юности, и вы не в курсе, как тут велась разработка ПО, то хотя бы на слово поверьте, а не спорьте.
> Нет, системный анализ для написания программы не требуется. Для написания программы нужны требования на входе.
Требуется. Как только вы садитесь, и думаете, как написать программу, чтобы она соответствовала требованиям на входе, вы уже проводите системный анализ.
> Я повторюсь, то, что люди иногда совмещают разные роли, никак не означает, что
> все эти роли, на самом деле — часть работы программиста.
Конечно же, не означает. Часть работы программиста — анализ, разработка архитектуры, написание кода, тестирование, т.е. все те работы, которые выполняют сотрудники с квалификацией программиста. Рисование картинок и продажа софта, это не часть работы программиста.lair
14.03.2016 11:34-1Потому что нельзя писать для заказчика программы, не собрав его требований и не вникнув в них. Если вы это не сделаете, заказчик её у вас не купит.
Вы не поверите, но можно. Вопрос агрессивности продажи. А еще можно писать не для заказчика, а свой собственный проект.
А у вас в профиле написан 1981-й год рождения. Вам было 19 лет, когда начался 21 век. Так что где-то вы врёте.
Вы считаете, что люди до 19 лет не работают?
Полагаю, ни мне, ни кому-либо из других читателей форума факт вашей эмиграции не интересен.
А при чем тут эмиграция? Я говорю о том, что практики индустрии формируются не в одной стране.
Как только вы садитесь, и думаете, как написать программу, чтобы она соответствовала требованиям на входе, вы уже проводите системный анализ.
Почему вы считаете, что это системный анализ, а не проектирование?
Часть работы программиста — анализ, разработка архитектуры, написание кода, тестирование, т.е. все те работы, которые выполняют сотрудники с квалификацией программиста.
Если сотрудник с квалификацией программиста рисует картинки, является ли рисование картинок частью работы программиста?DrPass
14.03.2016 23:19> Вы не поверите, но можно. Вопрос агрессивности продажи
Скорее вопрос чистоты «на руку» как контрагента. Если вы не планируете решить задачу заказчика, а просто убедить его, получить предоплату, а дальше — хоть трава не расти, то да, можно. И свой собственный проект можно. Только свой собственный — это не для заказчика. Только какое отношение это имеет к вопросу? Конечно же, из сотни задач вы можете найти одну, которую вы напишете сразу, без анализа. Например, потому что вы это решали.
> Вы считаете, что люди до 19 лет не работают?
Не, я читал в детстве книжку «Сын полка». Бывают исключения. Вас сразу после школы куда взяли сыном полка, в Oracle или Microsoft?
> Я говорю о том, что практики индустрии формируются не в одной стране.
Ну так вы не в эмиграции были, а где-то в СНГ? И в 90-е годы? И в 19 лет? И у вас на предприятии использовалась полноценная современная методика разработки? Ну пусть не совсем современная, пусть не эджайл, но хотя бы водопадец?
Я же говорю, врёте. :)
>Почему вы считаете, что это системный анализ, а не проектирование?
О, коллега, вы сейчас вообще удивитесь, наверное. Конечно, если этот разговор завели ради какого-то смысла, а не чтобы переспорить оппонента ради самого «переспорить», что, судя по вашей манере отвечать, вполне вероятно. Так вот, системный анализ это еще и часть процесса проектирования ;)
> Если сотрудник с квалификацией программиста рисует картинки,
> является ли рисование картинок частью работы программиста?
Ему нужна квалификация программиста для рисования картинок?lair
15.03.2016 00:44+1Только какое отношение это имеет к вопросу?
Да прямое, в общем-то. Речь же шла о том, без чего нельзя выполнить проект.
Вас сразу после школы куда взяли сыном полка, в Oracle или Microsoft?
Ни то, ни другое (заодно и ни третье, ни четвертое, потому что не сразу после школы и не сыном полка). Но вообще, в резюме все написано.
Ну так вы не в эмиграции были, а где-то в СНГ? И в 90-е годы? И в 19 лет? И у вас на предприятии использовалась полноценная современная методика разработки? Ну пусть не совсем современная, пусть не эджайл, но хотя бы водопадец?
Москва, 90-ые годы, 17-18 и далее лет, "водопадец", ага. Учитывая, что водопаду к этому моменту никак не меньше 30 лет (окей, термину — не меньше 20) — ничего удивительного, правда же?
Я же говорю, врёте
Если вы чего-то не видели, это еще не значит, что описывающий врет.
Так вот, системный анализ это еще и часть процесса проектирования
Ага, выстраивается иерархия. Проектирование — часть разработки, анализ — часть проектирования. И все это — обязанности программиста.
Ему нужна квалификация программиста для рисования картинок?
А для сбора и формализации требований с заказчика нужна квалификация программиста?DrPass
15.03.2016 01:41-1> Да прямое, в общем-то. Речь же шла о том, без чего нельзя выполнить проект.
Я прошу прощения, но мы же с вами не юридические условия договора обсуждаем. Мне грешным делом подумалось, что вы в состоянии без лишних уточнений с моей стороны понять, что если говорится «нельзя выполнить проект», то речь идет об общем правиле, а не об абсолютном законе. И что, естественно, найти какие-то единичные исключения из любого правила при желании можно. По крайней мере, этот момент очевиден.
> ничего удивительного, правда же?
Ну кроме того вопроса, кому и зачем мог в профессиональной разработке софта понадобиться 17-летний подросток.
> Если вы чего-то не видели, это еще не значит, что описывающий врет.
Если я не видел, не значит. Если оно противоречит общему тренду, то значит, пока не получены подтверждения обратного.
> А для сбора и формализации требований с заказчика нужна квалификация программиста?
Нужна, естественно, хотя бы на базовом уровне. Иначе формализация будет такой, что программист там мозг взорвет.lair
15.03.2016 01:50+1Нужна, естественно, хотя бы на базовом уровне.
Странно, почему в Вигерсовских Software Requirements (я смотрю на второе издание, 2003 год) в списке скилов Requirement Analyst (с. 68-70) есть listening, interviewing/questioning, analytical, facilitation, observational, writing, organizational, modeling, interpersonal и creativity, но нет ничего, связанного с программированием?
Ну и оттуда же хорошая цитата: "Project managers who lack a dedicated requirements analyst often expect a developer to do the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development." (с. 72)DrPass
15.03.2016 02:52Здесь нет противоречий тому, что я говорю. Абсолютно верно, для сбора требований нужны скиллы коммуникаций, и не нужны скиллы знания Java. Моделирование, аналитика — это та самая смежная часть, где требования превращаются в спецификацию, понятную ИТ-разработчку.
> Unfortunately, the skills and personality needed for requirements development
> aren’t the same as those needed for software development
Здесь речь идет о том, что не стоит пересаживать на сбор требований человека из разработки. Это тоже верно и не противоречит вышесказанному.
А теперь вы лучше скажите, если вам в команду понадобится молодой аналитик с целью «выучить и получить отдачу», где вы его будете брать? Какого он будет профессионального профиля, из какого учебного заведения?lair
15.03.2016 11:35+1Абсолютно верно, для сбора требований нужны скиллы коммуникаций, и не нужны скиллы знания Java
Так где же квалификация программиста-то в этих скиллах?
Моделирование, аналитика — это та самая смежная часть
Аналитические навыки, в терминах Вигерса, совсем не об этом:
An effective analyst can think at multiple levels of abstraction. Sometimes you must drill down from high-level information into details. In other situations, you’ll need to generalize from a specific need that one user described to a set of requirements that will satisfy many members of a user class. Critically evaluate the information gathered from multiple sources to reconcile conflicts, separate user “wants” from the underlying true needs, and distinguish solution ideas from requirements.
Это обобщенный навык, не специфически программный. С моделированием, в принципе, аналогично:
Tools ranging from the venerable flowchart through structured analysis models (data flow diagram, entity-relationship diagram, and the like) to contemporary Unified Modeling Language (UML) notations should be
part of every analyst’s repertoire. Some will be useful when communicating with users, others when communicating with developers. The analyst will need to educate other stakeholders on the value of using these techniques and how to read them.
Здесь речь идет о том, что не стоит пересаживать на сбор требований человека из разработки.
Вам это не кажется нелогичным? "Область работы аналитика является подмножеством области работы программиста", но при этом человека из разработки — программиста — не надо пересаживать на сбор требований, потому что, если верить Вигерсу, у нео другой скилсет. Как же одно может быть подмножеством другого, если скилсет разный?
А теперь вы лучше скажите, если вам в команду понадобится молодой аналитик с целью «выучить и получить отдачу», где вы его будете брать? Какого он будет профессионального профиля, из какого учебного заведения?
В идеале, его образование и/или профессиональный опыт должны коррелировать с предметной областью. Если это сложно — а это чаще всего сложно — то любое высшее (я в этой области, к сожалению, сноб) или высшее-в-процессе. CS100 в анамнезе помогает, но не обязателен.DrPass
15.03.2016 12:07> Вам это не кажется нелогичным? «Область работы аналитика является
> подмножеством области работы программиста»
Нет. Вы каждый раз в упор игнорируете слово «специализация». Вернитесь в начало разговора, и еще раз прочтите тезисы. Разработчик-кодер — это также дальнейшая специализация программиста. После специализации, абсолютно верно, взаимозаменяемость пропадает.lair
15.03.2016 12:17Разработчик-кодер — это также дальнейшая специализация программиста.
А почему вы считаете, что Вигерс в приведенной выше цитате под developer понимаете "разработчика-кодера", а не "программиста"?
И почему, тогда уж, вы считаете, что в треде, в котором вы участвуете (или в заголовке статьи, for that reason) слово "программист" употребляется в том смысле, который вы в него вкладываете, а не в каком-то другом?
И где и кем определен тот всемогущий программист, способный выполнить любую фазу водопада, на которого вы ссылаетесь?
KvanTTT
13.03.2016 13:22+4Не всегда так. Есть такое понятие "Амортизационный анализ".
mayorovp
13.03.2016 14:24+1Добавлю: и еще есть убывающие геометрические прогрессии, которые запросто могут множитель в оценке времени "скушать".
deniskreshikhin
13.03.2016 15:50-5Ну что значит не всегда так -)
Речь ведь шла именно об O-нотации. Это намек на то, что для программиста там нет ничего особо сложного, да и полезного тоже мало.
Изначально О-нотация вообще придумывалась как хороший инструмент классификации функции, т.к. для математиков это жесткая необходимость, ведь от качественной характеристики роста функции зависит многие фундаментальные вещи, например полнота пространства.
В программировании O-нотация используется лишь для того что бы скрыть постоянный множитель и упростить выражение. Смех в том, что именно он порой и важен.
А пришло в программирование это все от того, что большинство computer science-ученых довольно посредственные математики, адекватного инструмента придумано не было, взяли то что учили в университете на первом курсе без особого понимания.
В итоге, O-нотация преподносится "алгоритмистами" как какое-то фундаментальное понятие, но в действительности это одна из самых позорных страниц computer science как науки.
Да, сейчас многие хотят эту дыру заткнуть какими-то комбинаторными понятиями, амортизационный анализ из той же оперы, но там где начинается комбинаторика, там заканчивается наука.lair
13.03.2016 17:48+7А пришло в программирование это все от того, что большинство computer science-ученых довольно посредственные математики, адекватного инструмента придумано не было, взяли то что учили в университете на первом курсе без особого понимания.
Это вы сейчас Кнута записали в посредственные математики?deniskreshikhin
13.03.2016 18:40-6А вы знаете какие-то известные теоремы доказанные Кнутом?
Как ученый Кнут чрезвычайно выдающийся, это бесспорно, но как математик, так се. По сути он даже и не математик.
И это не голословные утверждения, из математиков, которые имели отношение к алгоритмам, даже если брать русских Колмогорова и Маркова-младшего. У них чуть ли не каждая теорема — это новая ветвь математики и новая область в computer science.
У Кнута ничего подобного мы не наблюдаем, хотя он хорошо классифицировал алгоритмы, и хорошо их придумывал. Но успешность в решении какой-то конкретной задаче, даже очень важной, это не математика.lair
13.03.2016 18:50+4А вы знаете какие-то известные теоремы доказанные Кнутом?
А это обязательное требование для того, чтобы быть не-посредственным математиком? Вы же говорите о понимании, а не об изобретении нового.
Но вообще, так, на минуточку: "a Fellow (first class of Fellows) of the Society for Industrial and Applied Mathematics in 2009 for his outstanding contributions to mathematics [...] a fellow of the American Mathematical Society."
gandjustas
13.03.2016 20:34+8А ты думаешь, что придумывание алгоритмов и их анализ и доказательство теорем чем-то отличаются?
Попробуй формально докажи, что хеш-таблица имеет время поиска амортизированное O(1). Доказательство не проще центральной предельной теоремы. Кнут доказал теорему о хеш-таблицах.
Ты пользуешься знаниями о вычислительной сложности алгоритмов как будто это само собой разумеющееся. Ты забыл что математики вроде кнута долго доказывали свойства алгоритмов, чтобы ты мог гордо а собеседовании сказать, что сложность быстрой сортировки — NlogN.deniskreshikhin
13.03.2016 23:13-4Это все доказывается элементарно, сортировка там вообще не сложнее задачи про взвешивание монеток.
У Кнута есть работы по математике, но это комбинаторные работы по числу Лаваса для графов. Но там мутная история, т.к. потом Лавас же получил премию Кнута. (Т.е. рука руку моет.)
Опять же не стоит мешать всех алгоритмистов в кучу, тот же Тьюринг и фон Нейман были первоклассными математиками. А потом уже алгоритмистами.
Тьюринг кстати и начал путь в науку с центральной предельной теоремы.gandjustas
13.03.2016 23:37+3Не совсем формальное доказательство асимптотики быстрой сортировки по твоему не сложнее взвешивания монет? Тогда наверное и теорема ферма для тебя — элементарщина.
KvanTTT
13.03.2016 23:59+4Да, сейчас многие хотят эту дыру заткнуть какими-то комбинаторными понятиями, амортизационный анализ из той же оперы, но там где начинается комбинаторика, там заканчивается наука.
Т.е. по вашему комбинаторика не является разделом математики? Боюсь что википедия с вами не согласна. Или что вы хотели сказать этой фразой?
fogone
12.03.2016 12:57-2Кажется, я нашел закономерность в этой формуле: если убрать O(..) она по прежнему верная.
deniskreshikhin
12.03.2016 13:27+1Про то и речь, что знаний там никаких нет)
Я давно заметил что "старечки" любят напустить тумана этой о-нотацией, но сами даже не понимают что это не вычислительная сложность, а асимптотическое поведение функции описывающей вычислительную сложность. И это все нужно в основном тем кто создает новые алгоритмы, пишет статьи на ACM и т.д.
Для практики же полезен бенчмарк, где учитываются статистика данных, реальное количество данных и т.д. Асимптотика вообще может не отражать реальное положение дел.
tyomitch
13.03.2016 21:17+5Для практики же полезен бенчмарк, где учитываются статистика данных, реальное количество данных и т.д. Асимптотика вообще может не отражать реальное положение дел.
Может не отражать. А может и отражать.
Рядом со мной сидят веб-программеры, которые одну функцию в одном внутрифирменном сервисе реализовали с квадратичной сложностью, когда данных в базе было мало и всё летало и так. Через год, когда база выросла вдесятеро, а время обработки данных, соответственно, в сто раз, — на этот их сервис чертыхался весь отдел. А уже поздно: на ту структуру данных, которую они выбрали, всё в сервисе завязано, переписывать можно только всё целиком.
Естественно, что "реальное количество данных и их статистику" на этапе разработки сервиса предсказать было невозможно: мы и сами тогда не знали, сколько и чего мы в их базу будем пихать.
BelBES
12.03.2016 18:23+6Так-то если там убрать O(...), то придется все домножать на константу, которая может быть сколь угодно большой…
Простой пример: можно отсортировать массив из 3-х элементов за честных 1 n^2 операций (т.е. за 9 операций сравнения), а можно линейно за 100 n операций (т.е. за 300 операций сравнения)...fogone
13.03.2016 20:19-1Вы это мне отвечаете? Вы это лучше напишите человеку, который предложил формулу сравнения O(..) выше. Потому что константа играет в любом случае, есть O() или нет.
alexkolzov
13.03.2016 00:11+2А ничего, что это асимптотические оценки и алгоритм со сложностью O(N) может быть хуже, чем O(N*logN) на характерной для задачи размерности данных? А если у двух алгоритмов одинаковая O-сложность, то какой из них предпочтительней? Если программист — программист, то он знает, как алгоритмы грамотно сравнивать. Если программист — дилетант от программирования, то он берет решение наугад, как привык или как посоветовали.
fogone
12.03.2016 12:55+5Думаю, разработчику очень полезно хорошо представлять как пишутся алгоритмы, какие бывают структуры, как они работают, наверное даже без нюансов реализации, т.е. ему не нужно уметь написать реализацию на листочке, но иметь представление важно для абстрактного представления как работает то, чем он пользуется. Для 80% (цифра взята из закона Парето) случаев вообще нечего такого не понадобится (по ощущению же это цифра еще больше, может быть 95% для рядовой разработки), но зато оставшиеся случаи потребуют от разработчика хорошего понимания как работают его инструменты, чтобы сделать правильно/быстро/разобраться с проблемой. Вот здесь-то непонимающий разработчик и потратит 80% своего времени (опять смотрим на Парето) — на что будет потрачено это время? 1) Разработчик всё-таки разберется как что устроено 2) будет пытаться обойти проблему в поисках на стековерфлоу рабочего решения. Как можно догадаться, первый вариант быстро перейдет из непонимающего в понимающего, второй же скорее всего всегда будет пользоваться вторым способом. Отсюда можно сделать вывод, что важно не столько понимать все инструменты, которыми ты пользуешься (а все знать невозможно), но быть мотивированным на их исследование.
HotFire
12.03.2016 13:00+2Вы (автор статьи), возможно, имеете ввиду то, что в большинстве отраслей и для большинства задач они не нужны.
Однако, они нужны в отраслях бизнеса, связанных с математикой и вычислениями. Например, разработка микропроцессоров или google cars (кейс моего приятеля JAVA-программиста). В случае, когда необходимо разрабатывать именно новые математические алгоритмы на основе существующих.
А так, согласен с Вами. С точки зрения практики — зачем досконально знать алгоритмы в прикладных задачах? Это вдоль и поперек изученная теория, прекрасно (хотелось бы верить) реализованная в готовых библиотеках. Например, у JAVA таких библиотек огромное количество.AlexSerbul
12.03.2016 13:06+2Вот да. Теорию и я люблю и трачу на это все свободное время. Но практика и рынок диктую другие правила.
YuriPanchul
12.03.2016 20:29+11Вы просто находитесь в части рынка, в которой умение писать алгоритмы, которые лазят по графам и деревьям — это неважно.
Я более 20 лет находился в части рынка, где без этого невозможно работать (сначала компиляторы, потом средства проектирования электроники). Вы не можете разрабатывать программы типа Synopsys VCS (я работал в этой группе) без таких навыков. Заработные платы в таких местах существенно выше, чем в среднем по индустрии.
Так что "практика и рынок", если вам нравятся работы такого типа, диктует противоположное.AlexSerbul
12.03.2016 20:51+1Согласен. Я поделился видением со своей колокольни, надеюсь оно будет полезно коллегам.
Alexufo
12.03.2016 13:01Нужно ли кому-то что-то знать больше в его профессии?
1) Если подумать, почему бы и нет, любые знания всегда хорошо, особенно близкие — буду расти как специалист.
2) Но с другой стороны, если я 1С ник, нафига мне машины Больцамана… учиться ловить драконов можно всю жизнь но нафига.
3) Получается, нужно плясать от смысла, какую задачу я хочу решить, что я планирую?
4) А откуда я знаю что я буду делать завтра? Метеорит упадет и все. Кому нужен этот 1С. Но так как это маловероятно, я буду предполагать что вероятно.
5) А вероятно, может быть много чего, жизней не хватит. Все равно цель то не познание вероятности, а максимальный результат от моей деятельности рассчитанный вероятностно. Я же не рассчитываю всю жизнь за учебниками просидеть.
6) Похоже цель — деньги, семья, самореализация, отдых и т.п ну да да вот оно и чтобы стабильно и уверенность в завтрашнем дне.
7) Так, получается меня толкает на все это экзистенциальный страх неизвестного.
8) Если это так то мне просто нужно убрать страх и мне будет хорошо. Можно попробовать химически с помощью там всяких веществ.
9) Не ну, вещества это все равно не то, это просто бегство. Вот хочу как у Васи. Я считаю Васю успешным — личностью.
Чем отличается личность от индивидуальности? Тем что первая нашла свои машины больцмана или свои рецепты для борьбы со страхом, который никогда не пропадает заставляя нас копаться глубже, так как будущее все равно неизвестно, но благодаря которым, мы не цепенеем как пенсионеры перед смарфономAlexSerbul
12.03.2016 13:08-1Согласен. Себя нужно научиться уважать и понять, что важное в жизни — устроено просто :-)
Alexufo
12.03.2016 13:23+3От невозможности определить реальность математически абстракциями и вероятностями (только потому что они не знают че так тоже можно :-) ), многие прибегают к гадалкам и шоу эксрасенсов. Тоже борются с экзистенциальным страхом. Однако, если мы задумаемся, то все важные вещи в нашей жизни были совершенны иррационально.
Случайные встречи, случайные связи. Математика это не устраивает — потому что рандом ненадежно, он он все равно вынужденно руководствуется внутренним чутьем. Это в нас как то заложено — магия эта.
Касаемо этого, для меня неожиданно, в другом ключе открылся смысл магического мышления,, — определенного дедушкой Фрейдом в "татеме и табу".
Монтировал вчера эту лекцию, и мне понравились несогласия с дедушкой Ф.)
HotFire
12.03.2016 13:06+13Уважаемые читатели!
Было бы обалденно, если бы кто-нибудь рассказал о своих кейсах из рабочей практики. Речь не о том, что они "развивают мышление". Это бесспорно. Расскажите случаи, когда вам действительно очень помогло знание алгоритмов — насколько удалось поднять производительность/сэкономить ресурсов и т.п.
У меня таких кейсов, к сожалению нет. Зато есть кейсы успешного применения прикладных знаний, наподобие оптимизации баз данных. И до сих пор есть задачи, требующие углубления именно практических знаний, а вовсе не теорий алгоритмов.
В условиях хронического недостатка времени приходится делать выбор в пользу развития прикладных знаний.AlexSerbul
12.03.2016 13:08у меня был кейс, один за 15 лет :-)
HotFire
12.03.2016 13:13А в какой области Вы работаете и какие задачи обычно решаете/решали?
AlexSerbul
12.03.2016 15:45+1Мы делали рекомендательную систему и кластеризовали каталог товаров. Много математики, чуть меньше алгоритмов — но классические не работали на больших данных, пришлось копать глубже и переделывать на MapReduce :-) Вот ссылочка.
kahi4
12.03.2016 13:21+6Кейс — замаскировать url. Впрочем, я фронт-эндер, задача была не моя, но я помогал решать. Пока бэк-энд пытались придумать супер-убер архитектуру хранения с очисткой старых данных из бд и id, я просто предложил воспользоваться обратимыми алгоритмами хеширования.
Еще один кейс был — хранить большое количество чисел (посещал-не посещал). Покуда это нужно было хранить для каждого пользователя по-отдельности, хранить влоб отвратительная идея (мало того, что только и успевай жесткие диски подсовывать, так еще это нужно как-то искать).
Вообще часто замечаю, что последнее время простенькие задачи пытаются решить сотней-другой гемов (gem), парой БД и диким оверхедом, вместо того, чтобы немного подумать и сделать простое, быстрое и изящное решение. Не то, чтобы не знали алгоритмов, просто забыли и отвыкли их использовать. Слишком уж редко нужно применять в реальности, что невольно первыми в голову лезут идеи найти библиотеку.
MrLibra
20.03.2016 13:54Еще один кейс был — хранить большое количество чисел (посещал-не посещал). Покуда это нужно было хранить для каждого пользователя по-отдельности, хранить влоб отвратительная идея
Не подскажите ваш вариант реализации этого кейса, хотя бы в общих чертах?
fogone
12.03.2016 13:25+1Думаю, здесь нельзя разделить на такой/нетакой кейс. Конечно, если говорить о кандово-математическом процессе создания алгоритмов, то думаю разработчик который не занимается этим непосредственно может и обойтись без таких знаний и умений. Однако, если говорить о представлении того как работают те алгоритмы и структуры, которыми ты пользуешься, то тут совсем другая ситуация. Потому что каждый раз используя что-то из стандартной библиотеки ты можешь сделать это осознанно, выбирая этот способ и понимая, что за собой это может повлечь, или просто потому что обычно делают так.
Myshov
12.03.2016 14:00+12Года три назад, делал систему автоматического определения оптимального передвижения техники по корпусу во время технического обслуживания электролизеров на алюминиевом заводе. По большому счету это NP задача, но она была сведена к достаточно приемлемому алгоритму на базе алгоритма Дейкстры — поиска кратчайшего пути в графе. Работает очень быстро. Так получилось, что из всей команды опыт в алгоритмах был только у меня и делал эту задачу соответсвенно один.
Там же занимался базами данных и понимание сложности очень помогало при профилировании запросов к базе / переписывании меделенных sql-запросов.
Сейчас на текущей работе участвую в разработке WebGL-приложения. Не сказать, что каждый день используются какие-то хитрые алгоритмы, в основном математика, но буквально вчера коллега реализовал дельта-кодирование вершин, что позволило сэкономить объем передаваемых данных на 30%. Алгоритм простой, но не зная его не получилось бы экономии трафика.
Еще друг показывал тестовое задание, которое он решал — по сути это быстрый саггестер для заданного набора строк. Прямолинейное решение O(n) с использованием сбалансированного дерева O(log n).
В общем, мое капитанское мнение такое. Не зная алгоритмы можно кодить и кодить довольно хорошо. Но зная алгоритмическую базу, математику, открывается абсолютно новый класс задач, которые программист без профильных знаний решить, увы, не сможет.HotFire
12.03.2016 14:30+1Спасибо за кейс!
По поводу нового класса задач идея такая. Время у всех катастрофически ограничено. И ежедневно (а то и чаще) возникает вопрос "что учить, куда развиваться?" И выбор — либо углубиться наконец-то в алгоритмы, либо изучить что-то новое в прикладном плане.
Новый класс задач открывается и при изучении алгоритмов, и при изучении новых прикладных методов (например, новых языков программирования или баз данных).
То есть незнание алгоритмов могут сильно тормозить программиста в областях, которые Вы описали.
Но другого программиста в другой области может тормозить незнание прикладных решений. Которые он не знает, потому что потратил время на изучение алгоритмов.
Наверное, так.
RouR
12.03.2016 16:24+1Похоже что знание алгоритмов вероятнее всего пригодится при написании специализированного софта. И мало вероятно в задачах "запилите мне сайтик/магазин" (если конечно не грезить хайлоадом)
Moxa
12.03.2016 14:38+4я сейчас переписываю систему, которая ищет объекты в базе в заданном радиусе от пользователя.
Старая версия: сходить в базу, ограничить зону поиска квадратом, отсортировать по радиусу, и затем полученные данные фильтруются в приложении по еще нескольким критериям. Вся эта подготовка занимает примерно 250мс
Новая версия: выгрузить все гео-объекты в память, положить в RTree, искать в нем. Время сократилось до 0.5мс
не всегда нужно знать, как все работает внутри, но было бы неплохо знать о существовании альтернативных алгоритмовgandjustas
12.03.2016 22:071) В базе использовались индексы?
2) Количество объектов какое?
3) Как часто меняются объекты?Moxa
12.03.2016 22:34конечно, индексы использовались, но все в индекс не запихнешь
~250к
почти не меняются, иногда добавляются новые, сразу после добавления вероятность изменения большеgandjustas
12.03.2016 22:53+1А что за база?
С таким временем ответа не уверен, что индексы были задействованы ил были эффективны.
В SQL Server есть geospatial indexes, те же самые RTree.
Если встроенных в базу нет, то имеет смысл свой аналог сделать, дописав в каждой вершине индекс "области" и сделать обычный индекс по областям.Moxa
12.03.2016 23:01postgres, скорее индексы были не эффективны
gandjustas
12.03.2016 23:05+1http://postgis.net/ не использовали?
Moxa
13.03.2016 00:10+1создал постгисовский идекс на тестовой базе, простой запрос типа
select count(*) from geo_table where ST_DWithin(geo_point, ST_Point(user_lng, user_lat)::GEOGRAPHY, 25000)
выполняется 12мс, с десятком джойнов будет значительно медленнееgandjustas
13.03.2016 00:15+2"Значительно" это сколько? Еще 10мс? Все равно лучше, чем 250.
И зачем вам десяток джоинов?Moxa
13.03.2016 00:24лучше, конечно, чем 250, но все равно в памяти быстрее, да и rtree-либой пользоваться намного проще
зачем — потому что база большая, нужно кучу инфы собратьgandjustas
13.03.2016 00:45+4А это уже неважно. Все что меньше 100мс для пользователя моментально. При этом база масштабируется получше.
База может и большая, но для вывода списка ближайших объектов нет необходимости делать 10 джоинов, даже два джоина для такой задачи — перебор.
rtree-либой пользоваться намного проще
Проще, чем дописать запрос к базе? Простите, но не верю.
CaptainTrunky
12.03.2016 17:25+2Как-то раз возникла задача попарного сравнения некоторых объектов и поиска определенных пар, сложности, соответственно, О(n^2). Т.к. количество объектов было неприлично большим, то решение в лоб работало слишком медленно. Пораскинув мозгами, сделали вывод, что объекты можно не сравнивать после их получения, а построить нужные пары сразу. Казалось бы, задача свелась аж к NP-полной, но на многих кейсах ускорение было с десятков минут до нескольких секунд. Само решение опирается на Boolean SAT. Где б мы были без теоретической подготовки...
AlexSerbul
12.03.2016 20:53-1Классный кейс. А мы прикрутили в этом случае LSH.
CaptainTrunky
12.03.2016 21:06+1У нас пары могут состоять из разных объектов. К примеру, как элементы паззла — чтобы проверить, подходят ли друг другу кусочки, нужно вот прям взять их и попробовать соединить. Если все сошлось — сохраняем, если нет — идем дальше. Вот только в нашем контексте в итоге оказалось, что можно сгенерировать не отдельные элементы, а сразу все пары, без дальнейших проверок.
AlexSerbul
12.03.2016 21:10Из может смежной области мне очень нравится подзабытый алгоритм Блюм-фильтрации.
YuriPanchul
12.03.2016 21:11+9У меня был прикольный случай. Я в 1996-2001 сделал стартап по написанию транслятора из C в Verilog ( https://en.wikipedia.org/wiki/C_Level_Design ), в нем бОльшая часть кода — это всякие алгоритмические преобразования деревьев и графов, все на С++. В некоторый момент я нанял одного товарища, начинающего Java-программиста, писать GUI. К коду транслятора как такового товарищ не прикасался, и когда я через пару лет как-то стал говорить с ним на абстрактные темы, я столкнулся с тем, что он был свято уверен, что я просто использую какой-то "компиляторный API" написанный другими. Конечно, есть всякие вспомогательные тулы от других вендоров (Yacc, Lex, лицензируемые фронт-энды), но они в таких проектах — это типа 5% кода, а самые интересные алгоритмы по работе с структурами данных нужно самому придумывать.
Или например — в 1991-1993 работал в компании в области Optical Character Recognition (распознавание текстов). Там тоже куча алгоритмов самого разного типа — анализ топологии (topological feature extraction) например.
[Сейчас из софтверного инженера стал хардверным инженером по верификации микропроцессора — тут другие проблемы]
LightSUN
12.03.2016 22:09+2Был довольно простой кейс (C#, WinForms). Дерево с фильтром. Если пользователь что-то вводит в фильтре, то остаются только элементы, в названии которых есть такой текст. Остальные скрываются (кроме родительских групп — чтобы было видно структуру дерева). Элементы хранятся в виде обычного списка, у элемента есть его ID и ID его родителя (если не корневой).
Потребовалось вручную просчитывать состояния чекбоксов (3 состояния), т.к. нужно было, чтобы когда пользователь отмечал чекбокс, то отмечались только видимые элементы, а когда пользователь снимал чекбокс, то снимать со всех элементов в том числе со скрытых фильтром.
Делалось это очень просто — в цикле/рекурсии, бегая по списку в поисках родителей/детей для вычисления состояния чекбокса.
Всё работало замечательно пока в дереве были тестовые данные (100-200 элементов). Но когда стали отображаться реальные данные (6000-7000 элементов), то пересчёт чекбоксов стал занимать 300-400 мс, что непростительно долго для простого нажатия на чекбокс.
Переделал пересчёт с использованием хэш-таблицы (HashSet в .NET) — перед рассчётом состояний чекбоксов сначала делался один проход по списку элементов и составлялись хэш-таблицы кто чей родитель и дочерний элемент, кто показывается а кто скрыт фильтром и т.д.
В результате без изменения остального алгоритма время сократилось с 300-400 мс до 1-3 мс.
Кейс не совсем конечно на знание алгоритмов, и даже наверное не на структуру данных, а скорее просто на понимание как это устроено. Но тем не менее.
dimview
12.03.2016 23:25+7Расскажите случаи, когда вам действительно очень помогло знание алгоритмов
Определение квантилей по потоку данных (например, 95-й персентиль). Нельзя просто хранить все данные, потом сортировать — слишком много данных по сравнению с памятью. Недостаточно хранить среднее и стандартное отклонение — данные не следуют нормальному распределению. Персентили не обязаны быть идеально точными.
Определение стартового сигнала (писк примерно известной частоты и длительности) в оцифрованном звуке с микрофона.
Система рекомендаций. Есть длинный список товаров с разными признаками, длинный список пользователей с историей (кто какие товары покупал) и функция похожести одного товара на другой (по признакам товара). Реализация в лоб (сравнивать всех со всеми) дохнет при росте размера списков, потому что O(N^2).
Автодополнение текста поискового запроса. Есть словарь возможных слов и словосочетаний с весами и некоторыми правилами, разбитый по категориям, искать по которому надо быстро и даже при наличии опечаток в запросе.
Кажется, что это стандартные задачи и для них есть готовые решения, но на практике получалось что ни одно из них не подходит (не тот язык, слишком тяжёлое — много зависимостей, не хватает гибкости, слишком сложное — долго разбираться, лицензионная чистота и так далее).
billyevans
14.03.2016 03:02+6Например, буквально в пятницу писал мутную структуру данных, что-то вроде бинарной кучи, но и еще с протуханием верхнего элемента. То есть один поток пихает постоянно данные в эту кучу, а другой ожидает готового элемента из этой кучи, то есть по ключу меньшего и еще и протухшего. В стандартой библиотеке Java такого не нашел, была только DelayQueue, но это сильно проще, чем мне нужно было.
Еще на прошлой работе писал прикольный планировщик некоторых долгих задач для потоков. Есть набор задач их нужно раздавать потокам, после какогото времени потоки эти задачи возвращают с некоторым прогрессом и задачи опять кладуться в очередь. Первая реализация планировщика это была очередь. Но она плохо работала с задачами для которых еще пока нет данных по каким то причинам и было много пустых итераций на таких задачах, вместо того чтобы выполнять другие задачи для которых данные уже были. Потом я почитал код CFS в ядре линукса(это такой планировщик процессов) и запилил похожую планировку основанную на времени потраченном процессором на каждую задачу. А сами задачи, упорядоченные по этому времени хранились в бинарной куче. Соответственно планировщик вынимает задачу которая потратила меньше всего ресурсов отдает потоку на выполнение, после выполнения время обновляется и задача кладется назад в кучу.
Например, в том году понимание, что определенные regex-ы в перле не работают за полиноминальное время помогало быстро понимать, где могут быть проблемы в производительности.
Так же я абсолютно всегда смотрю в код реализации сктруктур/алгоритмов перед их использованием. И знание и понимание каких то базовых вещей мне крайне помогает.
Это то, что я сейчас так быстро припомнил, но алгоритмы вообще абсолютно везде. От чем ConcurrentHashMap отличается от HashMap внетри в Java до того как работает Paxos.
tronix286
12.03.2016 13:23+3Знать — конечно нужно. Но дальше все зависит от языка. На бейсике (это я так называю похапе и прочие скрипты) — глупо не использовать стандартные функции, выполняющие стандартные алгоритмические действия, типа сортировки или работы со строками и тд, так как если выбран бейсик изначально и осознанно — то выбран скорее всего не из-за скорости выполнения программы, а из-за быстроты разработки и широким кругом вхождения (меньше ЗП на программистов). А если скажем речь идет про написание прошивки для микроконтроллера — то тут уже стоит тысячу раз подумать — юзать готовые функции или же написать свой велосипед, который учтет некоторые программно-аппаратные особенности реализации девайса в целом.
bobermaniac
12.03.2016 13:36+22А потом получается, что простейшая задача решается с помощью трех десятков слабо совместимых между собой библиотек в соответствии с принципом чайника, из-за чего умудряются тормозить даже на ферме из 20 блейдов не самых чахлых конфигураций. Зато с реактом, редисом и монетизацией через микротранзакции, все как у больших мальчиков.
До сих пор ситуация в мире разработки напоминала мне *вырезано ибо политика* — любую мало-мальски сложную проблему пытались залить процессорными мощностями, памятью и каналами данных. Они росли и было круто. Теперь они расти перестали и снова пора начинать думать, отсюда все больше требований к математике среди девелоперов.
Да, конечно, можно и за отпуск собрать мапредьюс в облаке из грязи и веток, однако как же удивляется разработчик, когда понимает, что накладываемый такими решениями оверхед настолько велик, что очищенная от него задача спокойно выполняется на втором пентиуме.AlexSerbul
12.03.2016 20:54-3Не, я как раз писал акцентируя на поиск простых решений!
bobermaniac
12.03.2016 21:31+6Простое решение — собрать мапредьюс из грязи и веток и залить процессорами. Развернуть все абстракции, вытащив наружу только то, что реально нужно — решение сложное.
AlexSerbul
12.03.2016 21:51-4За такие "простые" решения — у нас принято брать биту в начале поста и лечить :-)
bobermaniac
14.03.2016 11:00Апологеты MVP с вами радикально несогласны. Впрочем, я тоже, так как вначале должен быть proof of concept, а для него допустимо использовать любые средства, вплоть до вероятностных алгоритмов.
mird
15.03.2016 17:33То есть не для пруф оф концепт вы не будете использовать быструю сортировку (типичный случайный(вероятностный) алгоритм)?
excoder
12.03.2016 15:04+8Положительнейший эффект российского образования — это получение навыка думать. Казалось бы, зачем кодерам все эти матаны, поверхностные интегралы и критерий Рауса-Гурвица. Очевидно, эти знания будут не нужны в 99% случаев. Дело не в знаниях, а в получении навыка поиска, понимания, отождествления связанных вещей и системного анализа. Знания оставлены в университете, навык сохранён и уже дальше развивается в ваших других областях. Люди, которые развивались в университетские годы по какой-то причине узко — будут такими же узко(лобыми) и на работе. На первой же нестандартной ситуации — пык-мык, не знаю, пойду домой. Или, например, нежелание понимать область коллеги по работе — "не, я узкий специалист". Университет (ну или то что вы причисляете к науке) от этого отучивает. Нисколько не ученых готовят университеты, а закаляют к дальнейшей эффективной жизни.
gandjustas
12.03.2016 22:10+4Изучение матана и "навык думать" в общем случае не связаны.
Или, например, нежелание понимать область коллеги по работе — «не, я узкий специалист». Университет (ну или то что вы причисляете к науке) от этого отучивает.
Проводил собеседование десятков вчерашних студентов ведущих вузов. К сожалению универ не отучивает от такой модели. Непонятно за счет чего он должен отучивать.excoder
13.03.2016 01:26А они как вообще, выпустились, с какими результатами, легко ли? Как экзамены сдавали, быстро или медленно готовились? Надо оценить, как человек проходил этот квест. Если это для него не квест, а каторга — ну что ж. Универ — отличный фильтр. Те, кто застревает в такой вот узкой модели — это (на моей памяти, сам собеседовал десятки) обычно такие ребята, которые ходят на все лекции и повторяют за профессором, а потом ещё и сдают на 4. Смышленые, скоростные — они иногда и профессора-то не видели до экзамена, но сдают с блеском, т.к. к вопросу подошли не зубрежкой и повторением, а собственным пониманием.
AlexSerbul
13.03.2016 23:37-2А вот вопрос. Возьмем врачей. Одни изучают ухо, вторые — анус. На западе это разделение четкое и тебе просто не дадут лезть в ухо, если ты посвятил себя проктологии. И это правильно. А у нас как-то наоборот. Тебя учат всему, а потом сидит человек и тупит неделю в консоли юникс.
rg_software
14.03.2016 17:17Вообще это одна из самых популярных баек. "На Западе" по некоторым параметрам ширина охвата покруче, чем у нас. Конкретно в сфере IT можно почитать рекомендации ACM/IEEE по содержанию вузовского образования. И надо иметь в виду, что ни в одном приличном вузе нельзя получить диплом, набирая курсы только в рамках major subject, всегда будут предметы общего характера или по дополнительной (minor subject) специализации.
tyomitch
14.03.2016 18:52+3"На Западе" вузы, абитуриенты и работодатели уже начинают различать специальности "Computer Science" (т.е. наука) и "Software Engineering" (т.е. софтописательство), а "на Востоке" всё ещё мешают в одну кучу всё, где есть слово "computer" в названии.
rg_software
17.03.2016 08:45А вы посмотрите на том же сайте рекомендации по изучению Software Engineering.
spmbt
12.03.2016 16:33+1Троллинг зачётный, но, судя по оценкам, не менее половины принимают вбросы (тезисы автора) всерьёз (которые поставили минусы). Нужна ещё шкала оценок качества троллинга, и тут — однозначный плюс.
terrier
12.03.2016 19:46+5Непонятно, в чем суть такого троллинга. Автор понаписал глупостей, замусорил пространство хабра, на котором и так качественного контента не хватает, подтвердил стереотипы о программистах 1С и битрикса, которые и так интеллектуалами не слывут.
Ну, может, немножко повеселился, да. А может, все-таки веселиться лучше идти на пикабу?AlexSerbul
12.03.2016 20:59Ну зря так. Да, мы больше практики, много программируем, делаем 4 релиза в год. Но алгоритмы — учим, математику — любим, unix знаем на отлично на уровне C. Бигдата у нас тоже есть со сложной математикой, хайлоадом, java и Spark. Но пост о другом — о простоте и ограниченности времени.
AlexSerbul
12.03.2016 20:57+1Спасибо! Если честно, задумка была просто поделиться опытом, плохим-хорошим, какой есть. Знание алгоритмов, истоков, отцов основателей, C, математики — безусловно, БЕЗУСЛОВНО нужно!!! Но не всем. Либо знай это хорошо, либо просто не лезь и не страдай комплексом неполноценности, пей пиво и используй готовое — и будешь полезен человечеству.
samo-delkin
12.03.2016 17:04+7Когда не пишешь нифига, знания не нужны. У меня друг (не программист вообще и не математик) сказал "зачем программировать, если все программы можно в интернете скачать?". Он просто не понимает, что такое программа, которой нет в мире и в которой всё есть.
Я видел, как люди, знающие только регулярки, не могли исправить баги в своих собственных веб-приложениях, потому что там надо было знать грамматики и конечные автоматы, а у них мозгов хватило только на регулярки (уровень средней школы), которыми ничего не сделаешь.AlexSerbul
12.03.2016 21:00Да, нужно постоянно писать код, согласен. Иначе наступает интеллектуальная импотенция и начинаешь бредить.
michael_vostrikov
12.03.2016 18:21+4Думаю, очевидно, что есть задачи в области программирования, связанные со знанием алгоритмов и оценкой их сложности и не связанные.
Также очевидно, что есть задачи, для которых информацию о возможных алгоритмах можно узнать в процессе решения.
Если задачи не связаны с алгоритмами, алгоритмы знать не надо. Тем не менее, это тоже программирование.
Если задачи, связанные с алгоритмами, появляются в работе редко, и есть возможность разобраться с алгоритмом в процессе решения, то общее понимание — нужно, знание вот этого конкретного алгоритма — нет. Использование готового алгоритма из библиотеки относится сюда же.
Если задачи, связанные с алгоритмами, появляются в работе постоянно, алгоритмы знать надо.
Также бывают задачи на нестандартные алгоритмы либо на нестандартное применение стандартных алгоритмов. Для таких задач алгоритмы знать надо, причем очень хорошо.AlexSerbul
12.03.2016 21:01Вот. Имея базовые знания, тратишь недельку другую на деревья и потом аккуратно реализуешь. Вряд ли придется придумывать алгоритм — на них у ученых жизни уходили и дисеры. А вот найти готовый и знать где — разумно.
pak-nikolai
12.03.2016 18:55+5ниже пример = 7000 долларов в месяц, переезд в штаты, возможно пересмотр зарплаты по результатам собеседования
http://hh.ru/vacancy/15925548?query=%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B8%D1%81%D1%82
значит спец в своей области востребован даже если это алгоритмы, и такая позиция не одна, математик вполне может получать больше среднего кодера. При ситуации в которой идет все большая специализация часть программистов медлено превращаются в роботов по набиванию кода.AlexSerbul
12.03.2016 21:02В чем-то согласен… есть такое. Я хотел в посте лишь поднять важность прикладных знаний, дающих нередко 95% отдачи.
psylosss
12.03.2016 22:02+3На период работы, предшествующий переезду (время оформления документов для переезда в США) зарплата — 80,000-120,000 рублей в месяц. Начальная зарплата после переезда в США — $85,000 в год
Это оттуда же. Что-то мне подсказывает, что средненький фулстэк, который путает бинарное дерево с большим О в нотации второго закона Ньютона, может рассчитывать на большее. И в Москве, и в штатах. Это если речь о деньгах.deniskreshikhin
12.03.2016 22:16-1Да, если порыться по американским вакансиям, то обычно там требования в стиле "experienced, independent, self-motivated developer with good сommunication skills?" плюс пару топовых технологий типа node.js, какой-неть nosql, которые учатся за пару вечеров.
lair
12.03.2016 22:16+6пару топовых технологий типа node.js, какой-неть nosql, которые учатся за пару вечеров.
Восторг.
napa3um
12.03.2016 20:27+1Иногда полезнее быть узкоспециализированным, но глубоким в своей специфике специалистом, иногда полезнее быть специалистом широкого профиля без особых требований к глубине познаний. И на всё это нужно время. И ответственность за выбор своей судьбы (ну, или какого-то отрезка карьеры) лежит на каждом человеке, не получится написать статью, которая позволит программистам сделать себе лоботомию и жить не напрягаясь по инструкции. Полезная статья в этой теме — это статья, предлагавшая бы критерии оценки «широты» и «глубины» специализации и ориентирования на текущем рынке по этим параметрам. А сферически в вакууме рассуждать о том, кем лучше быть — пекарем или трактористом, — бессмысленно.
AlexSerbul
12.03.2016 21:07Ну мы не в сферическом вакууме рассуждаем же. Каждый где-то работает, что-то кодит, что-то изучает, что-то зарабатывает. В посте хотелось поднять важность с одной стороны прикладных знаний, а с другой — подчеркнуть ограниченность времени и сил. Когда-то я для себя решил так: разберись с основами, с принципами — дальше будет проще:
- Таненбаум: железо, ОС
- Стивенс, Вахалия: юникс изнутри
- Стивенс, сетевые протоколы
- С
- java, с++ чтобы быстро что-то поднять из готового
- php,python — чтобы в вебе развернуться
- математика, базовое машиное обучение, матстат, тервер — ну чтобы было лучше понятно что происходит
- горстка придуманных человечеством алгоритмов, ну чтобы не придумывать заново
А дальше — практика, практика...
psylosss
12.03.2016 21:42+1Саш, недавно была статья в тему — Чем плохо быть fullstack-ом. Я думаю, что ты примерно про то же самое пишешь. Хорошо или плохо — очень зависит от контекста, условий, окружения, требований.
Alexufo
13.03.2016 04:08+2По мне там самый лучший коммент от MTonly https://habrahabr.ru/post/278467/#comment_8793335
Про Full StackOverflow developer. Хохотали час, не уточняйте детали, пожалуйста :-))
GORKOFF
12.03.2016 22:03+5Сама постановка вопроса, какая-то странная. Конечно надо алгоритмы знать.
У нас в чисто финансовой(!) компании используются следующие алгоритмы:
- Имитация отжига;
- Монте-Карло;
- Стеганография в частотной и пространственной области;
- SIFT-дескрипторы;
- Перцептивные хеши;
- Триангуляция Делоне;
- Поиск остовных деревьев;
- Баесовские классификаторы;
- Метод k-средних
И это только то, к чему я имел непосредственное отношение. Короче надо программисту алгоритмы знать.
psylosss
12.03.2016 22:04-3Я программист. И не знаю. Что значит "надо"? Не надо. Или не программист?
GORKOFF
12.03.2016 22:09+3Если тебя интересует конкретное моё личное мнение, то ты не программист.
Если же подходить к вопросу более формально и смотреть профессиональные стандарты, то в России программист тоже должен знать алгоритмы.psylosss
12.03.2016 22:16-5К сожалению, или к счастью, меня больше интересует мнение работодателей и их бизнеса, а также полезности, которую люди моей профессии (которую для простоты называют "программист") этому бизнесу приносят. Интересно знать, кому (или для чего) должен знать алгоритмы человек, который называет себя программистом? Моё мнение несколько иное. Программист не должен знать алгоритмы.
GORKOFF
12.03.2016 22:28+12Попробую ответить на твой комментарий по частям.
К сожалению, или к счастью, меня больше интересует мнение работодателей и их бизнеса
Никогда не понимал зачем задавать вопрос, если ответ тебя всё равно не интересует.
которую для простоты называют «программист»
Здесь наверное и скрыта вся проблема. Программист и тот, кого для простоты называют "программистом" это зачастую очень разные люди. Не знаю, что у вас там за профессия такая, но немного утрируя, могу рассмотреть гипотетическую ситуацию, где некий эникейщик Вася, которого для простоты называют программистом, занимается тем, что меняет картриджи в принтерах. Такому "программисту" алгоритмы действительно не нужны.
кому (или для чего) должен знать алгоритмы человек, который называет себя программистом
Человек, который сам себя называет программистом никому и ничего не должен. Но проблема в том, что назвать себя программистом недостаточно. Если ты и правда считаешь себя программистом, то должен любить строгость и формализмы (надеюсь на это). Повторюсь, в России для того, чтобы быть программистом, надо удовлетворять требованиям профессионального стандарта. А там как раз перечислены требования.
psylosss
12.03.2016 22:43+2Вот это конструктивно. Но есть несколько нюансов. Если я правильно понял, вы решили свести обсуждение в русло "может или не может считаться программистом в определении неких стандартов России человек, который не знает неких алгоритмов". Что ж, здесь спорить сложно, если действительно есть какой-то стандарт, в котором прописано, что человек только тогда может называться программистом, если знает следующие алгоритмы: Имитация отжига; Монте-Карло; Стеганография в частотной и пространственной области; SIFT-дескрипторы; Перцептивные хеши; Триангуляция Делоне; Поиск остовных деревьев; Баесовские классификаторы; Метод k-средних. Если человек не знает каждый из этих алгоритмов, то, согласно этому стандарту, программистом он считаться не может. Так вот нюанс заключается в том, что потребители этого стандарта не 100% населения России и некоторые люди (особенно те, которые связаны с реальным бизнесом), руководствуются своими соображениями (намеренно не употребляю слова "стандарт") относительно того, что должен и чего не должен знать программист. К примеру, область, в которой я работаю (крупные веб-проекты, особенно в начальной стадии их развития), программистами принято называть людей, которые могут программировать (набирать код) на языке программирования (обычно скриптовом). Вся дальнейшая классификация содержит слово "программист" в сочетании с каким-то другим. Например, "хороший программист", "говно-программист", "программист-архитектор", "бэкенд-программист", "фронтенд-программист" и т.д. Как правило, слово "программист" в моей области является синонимом слова "разработчик".
При этом я убеждён, что есть области, в которых программистами не могут считаться люди, которые не смогут написать некий алгоритм, который ежедневно используется в их работе.
Итог (я уже говорил его, повторюсь): всё сильно зависит от окружения, области, требований. И заявлять о том, что программист должен или не должен — значит забить на контекст и обсуждать сферическую хрень в вакууме. Что, на мой взгляд, лишено всякого смысла, кроме эмоционального.
Mrrl
12.03.2016 23:00+1Интересно знать, кому (или для чего) должен знать алгоритмы человек, который называет себя программистом?
И как же должен называться специалист, от которого требуется имитация отжига; Монте-Карло… далее по списку? Вы уже установили, что это не программист. Тогда кто же?psylosss
12.03.2016 23:03Ок, подсказываю: если я утверждаю, что программист не должен знать алгоритмов, то это не означает, что если он знает алгоритмы, то он не программист.
psylosss
12.03.2016 23:17+1Я понял что вас сбило с толку. Фразу "не должен знать" я употреблял в смысле "не обязан знать", а не в смысле "должен не знать". Мой косяк, допустил двусмысленность.
gandjustas
12.03.2016 22:43-2Никогда не понимал зачем задавать вопрос, если ответ тебя всё равно не интересует.
А он не спрашивал твое мнение. Ты же безапелляционно заявлял что надо алгоритмы знать.
Повторюсь, в России для того, чтобы быть программистом, надо удовлетворять требованиям профессионального стандарта. А там как раз перечислены требования.
Я не поленился и скачал стандарт. Там есть две строки про алгоритмы:
Умения: Применять стандартные алгоритмы в соответствующих областях
Знания: Алгоритмы решения типовых задач, области и способы их применения
Вряд ли "Триангуляция Делоне" может быть отнесена к алгоритмам для решения типовых задач.
Если внимательно почитать стандарт, то становится понятно, что используется широкое понятие алгоритма, как набора инструкций для достижения результата, а не зубодробительных вещей вроде криптографии.
Поэтому под определение алгоритма равно подходят использование готовых библиотек и рукопашная реализация симплекс-метода.
billyevans
14.03.2016 19:53+1Вроде знание и умение оценивать алгоритмы и является базовым требованием для прохождения собеседования на программиста. Я был на куче собеседований в совершенно разные фирмы и абсолютно всегда была половина или больше собеседования посвещена решению различных задач и оценке сложности алгоритма. Возможно, часть из этих задач высоана из пальца, но если работодатель требует это при приеме на работу, соответственно это и есть его требования для квалификации программистов. Собеседований за последние лет пять было с десятка полтора, наверное. Скажу даже больше, всего лишь в одном или двух местах были требования про знание конкретного языка, но на собеседовании такого никто не спрашивал, тем более про какие то библиотеки и фреймворки тоже никто не спрашивал. Может это, конечно, требования к средним программистам, а не к senior, но тем не менее у меня такой опыт.
AlexSerbul
13.03.2016 23:35-1Чтобы понять эти алгоритмы, лично мне потребовалось полтора года свободного времени по дороге на работы и домой. Вы желаете этот ад повторить нормальным инженерам, умеющим писать хороший код:?
mbait
12.03.2016 22:25+11Опять 25. Кто-то просто должен взять и сделать статистический анализ появления статей "Нужны ли программисту алгоритмы?". Было бы очень интересно узнать, как это связано с временем года, возрастом автора, весенним обострением и т.д. ...
По существу. Заметил, что в обсуждении этой, какзалось бы, чисто технической темы очень-очень редко приводят формальные доказательства. Пусть в этот раз будет мой черёд. Кто дочитает до конца узнает лёгкий способ прогнать попоболь и прочую хворь и начать жить счастливо.
Итак, когда мы спрашиваем у сферического воина клавиатуры, нужны ли ему теоретические знания, то возможны следующие варианты ответа:
- «Да, на основе них я разрабатываю новые теории»
- «Да. С помощью них я могу объяснить, как работает программа»
- «Вообщем-то нет, но я учу, чтобы понтануться или загнобить собеседуемого»
- «Нет, я просто пишу код, как знаю, а если не знаю, то лезу в интернет»
- «Что такое алгоритмы?»
И тут, вероятно, вы повчувствуете легкий запах горелого и со сверхсветовой скоростью начнёте писать о том, что не попадаете ни в одну из категорий, попутно раздавая минусы налево и направо. Хочу вас немного притормозить. Дело в том, что чёткая логика работает только в теории. На практике как бы вы ни пытались классифицировать то или иное явление или объект, рано или позжно вы столкнётесь с тем, что два разных объекта по одному из измерений будут принадлежать одному и тому же классу. Простой пример — удерживающие сиденье для ребёнка. Куда бы вы отнесли: к автомобильным товарам или товарам для детей? Ах, да — "удерживающие устройства"… для ребёнка или автомобильные? "Очевидно — автомобильные для ребёнка", скажете вы. Вот тут мы и подошли к сути — наш опыт это линейная комбинация каких-то факторов. Сначало человек говнокодит напропалую и знать не знает о каких-то алгоритмах. Но в душе он понимает, что с кодом, который он пишет, что-то не так — он попахивает. Он начинает читать теорию, углубляться, понимать суть, и код его преображается на глазах. На его в глазах, а в глазах Фабриса Беларда это всё ещё… врочем, Фабрис скорее всего слишком занят, чтобы участвовать в холиворах подобно этому или тратить время на рассуждения о качестве кода. Таким образом получается, что выше приведённые варианты являются базисом, т.е. попарно независимы и образуют целое пространство, элементы которого участники подставляют в свою функцию оценки — нужно или ненужно знать алгоритмы. И как-то так выходит, что мы спорим о разных вещах.
Вывод. Можно тешить ЧСВ сколько угодно долго, и ситуация, когда сначала "молодец среди овец", а потом "а среди молодцов сам овца" абсолютно нормальная. Это называется рост. Просто не стоит задерживать надолго в каждой из фаз, и не стоит забывать, что остальные тоже находятся, каждый в своей фазе, только уровни у всех разные. Если вы не знаете алгоритмы — живите счастливо дальше или идите учить их, а если знаете — вы большой молодец. Только получается, что Геннадий и Петр большие молодцы, чем вы? Ой, нет — то программироваие не имеет ничего общего с реальным. oh, shi...
Секретный методПредставьте, что всё, что вы хотите сказать про программирование будет сказано про… акробатику. Верите или нет, но сходства тут очень много. В акробатике есть такой элемент — заднее сальто. По сути — это куворк назад в вертикальной плоскости. Это самый естесвенный по природе элемент — дикие обезьяны выполняют его без труда. Вы ведь умнее дикой обезьяны? Тогда отложите клавиатуру, встаньте и сделайте заднее сальто. Если не получислось, то попробуйте научиться. Вы узнаете много нового о том, сколько труда может потребовать простое на первый взгляд действие. Если у вас получилось поздравляю — вы или уникальный, или до этого занимались. А теперь выучите пару-тройку других элементов и попробуте: заработать на этом, выиграть олимпиаду по гимнастике, восхитить своих друзей, восхитить друзей-гимнастов, получить грант, устроиться на работу в Cirque Du Soleil или House of Dancing Waters (аналоги гугло-амазано-микрософта). Когда вы закончите, поймёте бессмысленность всего, что говорили про программирование, и обретёте просветление.
AlexSerbul
13.03.2016 23:34Ну я связал пост с проблемой, когда хороший программист лезет в математику и рождает чудо-бред, и наоборот, когда математик, желая заработать, начинает кодить и рождает бредо-код. Это актуально в контексте активизации машинного обучения, бигдаты, дипленинга. Кратко — видится четкое разделение и специализация.
dzhidzhoev
12.03.2016 22:57+16Нужно ли знать программисту математику?
Нужно ли знать программисту алгоритмы?
Боюсь, что скоро возникнет вопрос:
Нужно ли знать программисту языки программирования?gandjustas
12.03.2016 23:19+11Нужно ли программисту уметь программировать?
Ведь все уже написано, надо только уметь запускать IDE и копипастить код со StackOverflow.
psylosss
12.03.2016 23:22Шутки шутками, но критика разработчиков на symfony 1 часто содержала аргумент типа "Программисты на симфони — это не программисты, это писатели конфигов".
Ckpyt
13.03.2016 01:38У нас препод по теории компиляторов, рассказывая классификацию языков программирования, говорил, что идеальный язык программирования — это когда программист, закинув ноги на стол, объясняет компу что ему надо, и тот сам все пишет :-)
Alexufo
13.03.2016 04:12Это детские советские мечты на фоне появления микроволновок стиралок и т.п ))
arielf
13.03.2016 16:40+1Этого я и боюсь. Сам хотел задать подобный вопрос, но вы опередили. Ну а что — запустил редактор, нажал котогенератор, и всё написано.
dimview
12.03.2016 23:36+2Слово пропущено. Должно было быть "А нужно ли знать CRUD программисту алгоритмы". Тогда ответ действительно "нет, не нужно". Но не все делают CRUD.
michael_vostrikov
13.03.2016 07:23+4Реализовать систему для учета печати и продажи билетов в отдельно взятом кинотеатре. Правильная декомпозиция модели данных, CRUD, UI, работа с принтером, использование джойнов для построения отчетов, двойная бухгалтерская запись, исправление ошибок при сбоях печати, обработка различных ситуаций при продаже билетов — возврат, повреждение или брак бланка. Связано с программированием? Да. Делает ее программист? Да. Нужно знание алгоритмов? Нет.
Написать драйвер для конкретных грузовых весов на заводе. Весы передают данные по малопонятому протоколу, надо сделать драйвер, который будет передавать данные в программу, в которой работает оператор, в том формате, который эта программа понимает. Никакого CRUD-а нет, нужно знание ассемблера и умение разбираться в непонятных протоколах. Связано с программированием? Да. Делает ее программист? Да. Нужно знание алгоритмов? Нет.
dezconnect
13.03.2016 12:56+5Вот не буду показывать пальцем относительно той же системы учета печати и продажи билетов, один товарищ как-то спросил "а как посчитать растояние между точками". Даааа какие нафиг алгоритмы в самом деле. Математику бы знать на уровне школьного курса.
dimview
13.03.2016 15:48Приведённый контрпример таковым не является. Понятно, что не в любом не-CRUD проекте нужно знание алгоритомов. Тем не менее такие проекты существуют, я выше в этой ветке даже примеры приводил.
alexkolzov
12.03.2016 23:37+1Товарищи, ну что вы скопом накинулись на автора!? Ведь высказанная мысль отнюдь не нова, а с основным посылом конструктивно спорить сложно: никто же не будет отрицать, что большая масса "рыночных" задач даже мартышка сведет к нескольким типовым и соберет из имеющегося конструктора что-то похожее на правду? А часть рынка, в которой требует использования передовых достижений CS и математики, охватывает относительно небольшое количество имеющего отношение к программированию населения. Эта "вершина" у всех на слуху, они зарабатывают миллиарды, попасть к ним — мечта миллионов, они являются локомотивом индустрии. Туда и нужны образованные специалисты, способные решать нетиповые задачи оригинальными способами. А остальным куда податься? А различные "калькуляторы" кто будет писать?
Автор всего лишь сказал, что ему хорошо в его нише, он доволен своей карьерой и профессиональными успехами — чего и другим желает. Можно только пожелать удачи.
Мне только одно непонятно: откуда (и на кой черт) такое количество дипломированных программистов, если алгоритмы — то есть то, чему и учат на программистских факультетах — не приносят практической пользы, а пресловутые "практические навыки" — которым там по большому счету не учат — приводят к профессиональной успешности? Уверен, что автор что-то да заканчивал. Судя по посту, потерял время впустую.gandjustas
12.03.2016 23:41-3Я вас разочарую.
Миллиарды зарабатывают не алгоритмами.alexkolzov
12.03.2016 23:43+3Вы правы. Миллиарды зарабатывают технологиями. Те компании, которые достаточно умны для того, чтобы вкладывать миллионы в тех, кто способен разрабатывать алгоритмы, на которых эти технологии строятся
gandjustas
12.03.2016 23:49-3И снова разочарую. Миллиарды зарабатывают маркетингом (в смысле впариванием ненужного), продажей рекламы, продажей задорого китайских поделок и откатами.
alexkolzov
12.03.2016 23:53+5Маску это скажите. Еще можете попробовать ребятам из гугла рассказать. IBM и Intel не забудьте порадовать своей мудростью. Вот дяденьки удивятся, они то были уверены, что их основной капитал — технологии.
gandjustas
13.03.2016 00:07-4Капитал и зарабатывание денег — разные вещи.
Вот представь что у тебя появился капитал в виде всех технологий Intel. Но у тебя нет бренда, маркетинга, сбыта и денег.
Как будешь зарабатывать миллиарды?alexkolzov
13.03.2016 00:21+5Давайте представим обратное. Ну так, в форме бреда. У Вас есть бренд, маркетинг и даже каналы сбыта. А за ними — ни шиша. Что случится с Вашими миллиардами? Наверное, по Вашим представлениям Яндекс, SpaceX, Adobe и прочие были всегда, вот так раз — и у них есть и бренд, и маркетинг, и всё-всё-всё. Но давайте я по наивности своей предположу, что они начинали с наработки интеллектуального капитала, в том числе — алгоритмов, на основании чего и стали успешными.
gandjustas
13.03.2016 00:41-2Если у меня есть бренд, маркетинг, каналы сбыта, то я легко стану реселлером продуктов. А с прибыли буду инвестировать разработку своих продуктов. А ты что будешь делать со всеми технологиями intel?
Про яндекс достаточно почитать исторю:
https://yandex.ru/company/history/1990 люди делали поиск и ПРОДАВАЛИ его
https://yandex.ru/company/history/1993 на вырученные с поиска деньги основали интернет-компанию
https://yandex.ru/company/history/1998 яндекс начал сам зарабатывать деньги
То есть 5 лет кто-то кормил разработку.
Были там новые алгоритмы? Вряд ли, TF-IDF известен много лет.
Мог бы яндекс взлететь без денег инвесторов? Однозначно нет. Мог бы яндекс взлететь без опыта продаж — тоже нет.
Технологии важны, но на одних технологиях не уедешь. Нужны деньги, продажи, маркетинг.alexkolzov
13.03.2016 01:04+3Ну стали Вы реселлером. Молодец, заработали на чужих достижениях, стали частью рынка. Нет претензий. Здесь, вообще-то, говорится о секторах, в которых производятся программные продукты, а не перепродается или адаптируется готовое.
https://yandex.ru/company/history/1990 люди ДЕЛАЛИ ПОИСК и продавали его.
Поисковики существовали до гугла и яндекса. Почему выстрелили именно эти, тоже маркетинг? Или денег у них было больше? Наверное, лучше сработали маркетологи… А может их решения были стандартными, но другие почему-то не додумались их использовать? Или всё-таки используемые технологии качественно отличались от технологий конкурентов?
Если у меня будут технологии Intel — инвесторы в очередь выстроятся, чтобы хоть немного приобщиться к подобной бизнес-бомбе. Деньги идут туда, где есть возможность прибыли, а она есть там, где новые технологии открывают новые рынки.gandjustas
13.03.2016 01:27-4В любой гонке кто-то приходит первым. И не обязательно тот, у кого технологии лучше.
Если у меня будут технологии Intel — инвесторы в очередь выстроятся, чтобы хоть немного приобщиться к подобной бизнес-бомбе.
бугага. Прости, реально смешно. Нахапать деньги инвестора и зарабатывать — разные вещи. От слова вообще.
sankadubinin
12.03.2016 23:37-3Компьютер — машина. Программист управляет работой машины, то есть просто водила. От квалификации, степени владения и уровня знаний зависит качество управления. Всё.
fogone
13.03.2016 00:26+4Вопрос: нужен ли водителю навык торможения ручником? Ответ рядового автомобилиста: наверное можно без него и обойтись, но было бы здорово это уметь. Но обязательно придет человек, который скажет, что если водитель не умеет в торможение с разворотом, то допускать до баранки его нельзя — имея ввиду дрифт, а другой человек, который всю жизнь на трамвае ездит пассажиром, вообще не поймет, зачем такое может понадобиться. К чему весь этот разговор, если в коментах каждый говорит о чем-то своем, а сам пост ни о чем и не дает никакой конкретики? Просто посраться на вечнохоливарную тему?
vsb
13.03.2016 00:37Есть умные программисты и есть тупые программисты. Умные программисты пишут любые программы лучше, чем тупые программисты, вне зависимости от того, используются ли там алгоритмы или нет. Задача — отобрать умных программистов (помимо других качеств). Также умные программисты, как правило, немного знают алгоритмы (участвовали в олимпиадах, изучали в университете, на досуге игрались в хакерранке, просто имеют кругозор), поэтому простые алгоритмические задачи — отличный способ отделить зёрна от плевел.
botnet
13.03.2016 00:37-4Помню препод в универе, когда погружался в глубины науки, говорил нам "А если вы окажетесь на необитаемом острове? Вы должны это уметь"
из говна и палок собрать ракету. Убеждён, что если и окажусь на необитаемом острове, то главной для меня задачей будет побыстрее с него свалить в цивилизацию. Так что да, голосую, что пусть алгоритмами занимаются учёные и математики. Знаний и информации стало слишком много, надо уметь настраивать персональный фильтр, как бы всё "нужным" и "полезным" не казалось.
Ckpyt
13.03.2016 01:36+2Знаете, буквально вчера я задавал вопрос насчет самой крутой и самой распиаренной библиотеки .NET: как расшифровать RSA, не имя открытого ключа. Из трех комментаторов никто не понял вопроса. (https://toster.ru/q/300377)
А потом я покурил мануалы, разобрался что куда и зачем, попутно поймал еще и баг с разным направлением байт в экспорте/импорте двух разных классов(RSAParam и BigInteger), и решил задачу за пять часов. Да, признаю, это долго, но, во-первых, я новичок в C#, во-вторых, двое программеров до меня не смогли ее решить. Один просто не собирался лезть в дебри, второй, так же как и комментаторы к моему вопросу, советовал сменить подход.
Так что, пока вы находитесь в зоне комфорта и вас все устраивает — все хорошо. Как только у вас возникнет задача держать вместо 150 клиентов 10 000(посмотрите, была такая оптимизация на хабре), уже станет сложнее. Ну а когда внезапно окажется, что для вашей задачи есть две библиотеки, которые внезапно валятся с ошибками стоит сделать шаг влево, шаг вправо от написанных тестовых примеров — дело будет просто ахтунг.mayorovp
13.03.2016 09:41+8Знаете, но подход вам все равно надо сменить, не смотря на то что задача решена. Точнее, именно потому что задача решена. Фактически, вы получили открытый ключ из закрытого. А значит, кто угодно сможет сделать то же самое, воспользовавшись вашим же кодом.
Насколько я понимаю, вам надо чтобы никто кроме сервера не мог отправить вашей программе данные. Это — обычная задача на цифровую подпись, делается при помощи пары методов SignData / VerifyData (ну или SignHash / VerifyHash). Первый требует обоих ключей, второй — только открытого.
Если требуется еще и чтобы данные никто не обладающий вашей программой не смог прочитать — тут можно использовать любое другое шифрование. Да хоть то же самое, что делали вы — но теперь с него задача верификации снята, а значит можно спокойно оба ключа прописать в программе. Но я бы советовал тут использовать AES или другой симметричный алгоритм — быстрее работать будет.Ckpyt
14.03.2016 20:49Хм… общая ситуация такова:
Во-первых, заказчик не желает ничего слышать о том, чтобы хоть какие-нибудь данные лежали в открытом виде. В смысле, в файле лицензии. Попытки его убедить в том, что расшифровать данные в любом случае труда не составит, наткнулись на его: "это сложнее, чем просто открыть текстовый файл". И не могу с ним не согласиться.
Во-вторых, RSA .net для расшифровки требует наличия открытого и закрытого ключа.
Ну а дальше — пять часов геммороя и BigInteger меня спас :-)
В-третьих, у меня нет доступа к серверу лицензии и заказчик не хочет его давать. Значит, изменения возможны только внутри программы.
Ну а так, да, я совершаю типичную операцию цифровой подписи. Абсолютно типичную, о чем и шла речь в посте. Просто, криво реализованную Майкрософтом.
П.с. до меня там было два ключа — для расшифровки все тем же .Net RSACryptoProvidermayorovp
14.03.2016 20:51+1Но вы лучше не сделали. Вы оставили все так же.
Просто прибавили 3 часа геммороя потенциальному злоумышленнику.
И да — это никакая не операция цифровой подписи. Подписывают закрытым ключом, а не открытым.Ckpyt
14.03.2016 21:11Эээээ… Не подскажите, как злоумышленник может ЗАШИФРОВАТЬ данные моим ключом? Если его у него нет.
Вставить свой ключ в код программы — не вариант, сама программа так же подписывается и проверяет свои подписи при старте.mayorovp
14.03.2016 22:46Он берет ваш алгоритм, и получает открытый ключ из закрытого. Теперь у него есть ОБА ключа, и он может делать что угодно.
Ckpyt
14.03.2016 22:56Вот у вас на руках есть секретная экспонента(d) и модуль(n). Как получить из этого открытую экспоненту?
mayorovp
14.03.2016 23:03Вот так: https://toster.ru/q/300377
Ckpyt
14.03.2016 23:11Там эта задача не решается.
Я вообще выдернул с сайта MSDN кусок кода и изгалялся над ним как только мог.
Повторяю вопрос:
В rsa есть два стартовых больших натуральных числа: p и q, от них вычисляются три других числа: e, d и модуль — n
Как, имея на руках только d и n, вычислить е?mayorovp
15.03.2016 08:43+1У вас в вопросе написан формат закрытого ключа:
Modulus, Exponent, P, Q, DP, DQ, InverseQ, D
Из них элементы Modulus и D образуют открытый ключ. То есть открытый ключ содержится в закрытом.Ckpyt
15.03.2016 09:25Хм… в экспорте RSA в открытом ключе содержатся только Modulus и Exponent.
При этом, значение Exponent нельзя поменять на D — при импорте RSA пишет, что плохое значение.
По итоговому результату, я полностью избавился от расшифрования с помощью RSA, передаю Modulus and D, превращаю их в числа BigInteger, а дальше идет расшифрование с помощью BigInteger.ModPow
При этом, изначально я напутал с терминологией, считая открытый ключ шифрующим. этой ночью с ней разобрался.
Полностью, итоговый метод таков:
private static License Decrypt(byte[] array)
{
License lic;
if (sExponent == 0)
{
GetKeys();
}
try
{
//расшифровка
BigInteger encrLic = new BigInteger(array);
BigInteger decrLic = BigInteger.ModPow(encrLic, sExponent, sModulus);
byte[] decr = decrLic.ToByteArray();
//десериализация
MemoryStream config = new MemoryStream(decr);
BinaryFormatter serial = new BinaryFormatter();
lic = (License)serial.Deserialize(config);
} catch(Exception e)
{
Log.AddLog(e.ToString());
return null;
}
return lic;
}
mayorovp
15.03.2016 09:41Я проверил на ваших строках из вопроса — там Exponent в открытом ключе равна D в закрытом.
Ну, если вы отказались от библиотеки вообще — да, такое будет работать. Из вашего исходного ответа было не понятно что именно вы сделали.Ckpyt
15.03.2016 09:54>Я проверил на ваших строках из вопроса — там Exponent в открытом ключе равна D в закрытом.
Ой, чего я только не делал с ключами в тестовом проекте… В частности, в задании есть и такая строка: «Почитал про RSA, попробовал вместо экспоненты подсунуть секретную экспоненту, пишет плохие данные...»
>Ну, если вы отказались от библиотеки вообще — да, такое будет работать. Из вашего исходного ответа было не понятно что именно вы сделали.
Ок. спасибо за общение и анализ.
grossws
15.03.2016 09:50В принципе, PKCS #1 (RFC 3447) вполне допускает редуцированный вариант закрытого ключа (d, n), но реально его мало кто использует.
В данном случае, всё выглядит как самодельный алгоритм на базе RSA, т. к. вRSAEncrKeyв качестве открытой экспоненты лежит то, что в закрытом ключе лежит в полеD(закрытой экспоненты), а экспонента используется стандартная (0x010001, в base64 —AQAB). Т. е. всё вывернуто.
Disclaimer: я не специалист в криптографии и реальное использование описанного ниже кроме как для экспериментов крайне не рекомендуется.
Использоватьeвместоdи наоборот в теории можно, ноeне должно быть легкоугадываемым (или тем более известным, как в данном случае). Ну иdP,dQ,invQдолжны строится против новогоd, а не оставаться построенными на основе старогоd.
Ckpyt
14.03.2016 21:18Вы не правы, это все-таки операция цифровой подписи, просто без хэша.
http://life-prog.ru/view_teorinfo.php?id=10
почему обычно шифруют хэш? потому что он короче ключа. Но у меня сами данные короче ключа, и потому их можно использовать в качестве хэша.
П.с. и да, вы-таки заставили меня усомниться в том материале, что я слушал четыре года назад.
lair
14.03.2016 21:45В-третьих, у меня нет доступа к серверу лицензии и заказчик не хочет его давать. [...] Ну а так, да, я совершаю типичную операцию цифровой подписи
Эти два тезиса противоречат друг другу. Вы не можете совершать операцию цифровой подписи, ее — или не ее — совершает сервер.
Просто, криво реализованную Майкрософтом.
У MS есть прекрасный класс CmsSigner, который не менее прекрасно реализует цифровую подпись.Ckpyt
14.03.2016 21:59Эти два тезиса противоречат друг другу. Вы не можете совершать операцию цифровой подписи, ее — или не ее — совершает сервер.
Сервер умеет шифровать данные. Если в запросе есть ключ, то к этой шифровке прикрепляются открытые данные.
Так как я научил клиент расшифровывать данные без открытого ключа(на самом деле, я изначально напутал с терминологией, назвав открытым ключом шифрующий, а открытый — это не шифрующий, это тот, который можно передать открыто), то я гордо сказал, что совершаю операцию цифровой подписи… Извините, если ввел в заблуждение.lair
14.03.2016 22:01Так как я научил клиент расшифровывать данные без открытого ключа(на самом деле, я изначально напутал с терминологией, назвав открытым ключом шифрующий, а открытый — это не шифрующий, это тот, который можно передать открыто), то я гордо сказал, что совершаю операцию цифровой подписи…
Извините, а какая — в вашем случае — связь между расшифровкой данных и цифровой подписью?Ckpyt
14.03.2016 22:10-1Операция цифровой подписи — это операция, когда для расшифровки данных нужен открытый(доступный для всех) ключ.
Так как обычно данные превышают размер ключа, то, для увеличения быстродействия алгоритма проверки цифровой подписи, сами данные передаются открыто, а шифруется только хэш этих данных. Соответственно, операция шифрования называется подписыванием, а дешифрования( и если есть хэш, то сверка хэшей) — проверкой подписи.lair
14.03.2016 22:14Так как обычно данные превышают размер ключа, то, для увеличения быстродействия алгоритма проверки цифровой подписи, сами данные передаются открыто, а шифруется только хэш этих данных.
В цифровой подписи всегда есть два экземпляра данных — те, которые подписаны, и сама подпись (подпись считается от хэша, а не от данных, потому что так эффективнее с точки зрения вычислений). У вас так же?Ckpyt
14.03.2016 22:20подпись считается от хэша, а не от данных, потому что так эффективнее с точки зрения вычислений
С точки зрения каких вычислений? ЗАЧЕМ мне считать ЕЩЕ и хэш, если у меня сами данные меньше ключа?
В цифровой подписи всегда есть два экземпляра данных — те, которые подписаны, и сама подпись. У вас так же?
Нет, у меня только данные. Данных там, на самом деле, очень мало — 32 байта, а ключ почему-то используется на 4096бит.lair
14.03.2016 22:22Нет, у меня только данные.
Тогда у вас нет цифровой подписи. Вы получили криптотекст, вы расшифровали его с помощью открытого ключа, вы получили нечто. Откуда вы знаете, что криптотекст не был сгенерен без использования закрытого ключа?Ckpyt
14.03.2016 22:28Потому что, если он не был сгенерен без использования закрытого ключа, я не смогу его расшифровать в 32 байта, один из которых — контрольный.
Ключ зашит в программу, злоумышленник не может его подменить.lair
14.03.2016 22:29Потому что, если он не был сгенерен без использования закрытого ключа, я не смогу его расшифровать в 32 байта, один из которых — контрольный.
Как минимум, replay attack в полный рост.Ckpyt
14.03.2016 22:36Эээ… вы можете рассказать как проводить эту атаку, имея на руках ключ на 4096 и 32 байта конечного результата?
lair
14.03.2016 22:37Replay attack проводится на канал обмена данными. Перехватили сообщение, потом подсунули его вашей программе.
Ckpyt
14.03.2016 22:46Это отдельная задача И я не знаю как ее решить, учитывая что данные сохраняются в файл и лежат на жестком диске. Т.е. любой их может взять себе и спокойно размножить.
Если подскажите куда копать — буду сильно благодарен.lair
14.03.2016 22:50Копать в сторону подписей от изменяющихся данных, очевидно. Детальнее подсказать, не зная условий, я не могу.
Ckpyt
14.03.2016 23:01Условия… Есть сервер лицензий, у каждого получателя своя пара ключей открытый-закрытый.
При этом, открытый жестко вшивается в сам экзешник.
Соответственно, в зависимости от клиента, ему выдается файл лицензии.
Надо гарантировать, что клиент не будет и размножать и передавать в третьи руки, при условии, что программа может работать в отрыве от интернета.
У меня есть только одна идея — привязывать программу к железу… или софту в процессе получения лицензии.
Тогда клиент всегда сможет получить еще один ключ(в разумных пределах), но не сможет передать никому другому.
Вопрос в том как это сделать...
lair
14.03.2016 22:47Но вообще, все, что надо сделать — это решить уравнение вида xd ? m modulo n, где d и n известны, а m задается атакующим. При этом x — мал (вы что-то говорили о 32 байтах, да?), и поэтому мы можем просто решить ее перебором.
Ckpyt
14.03.2016 22:26Блин. Только зашифрованные данные(ака подпись). Извините, уже почти сплю. Но интересно.
ingumsky
13.03.2016 02:11+2Я думаю, правильного ответа на вопрос, поставленный в заголовке, не существует. Есть аргументы в пользу обеих точек зрения, потому скажу, как вижу я. Я не являюсь программистом и разработчиком в полном смысле этого слова — я регулярно пишу небольшие приложения (в основном, server-side JS) и даже получаю за это деньги, но для меня это скорее хобби — поэтому, вероятно, моё мнение не совсем релевантно. Тем не менее…
Я считаю, что алгоритмы и вообще глобальные основы знать надо. Это не только может серьёзно помочь в работе, но и даёт возможность развиваться дальше. Лично мне базовых знаний часто не хватает, потому что фундаментального образования в области точных наук и программирования я не имею. В итоге переход от «говнокодить» и писать лапшу из решений, вычитанных на SO или в чужом коде, который мне достался в наследство, к нормальной разработке мне давался (и даётся) тяжело. Я иногда открываю для себя элементарные вещи, которые, по-хорошему, люди узнают, когда начинают учиться. Я не всегда вижу очевидные решения, потому что не знаю инструментов или идеи, которые помогли бы мне на них выйти.
В целом проблема касается не только программирования, но и других областей знания — чтобы делать что-то стабильно хорошо, надо понимать, что именно ты делаешь и почему. Можно, конечно, раз за разом ходить проторенной ранее кем-то тропкой и быть довольным уже тем, что идёшь, но настоящим специалистом так не станешь.AlexSerbul
13.03.2016 23:31Это кстати частый кейс. Я сам — электромеханик и всю жизнь наверстываю академические знания из "смежной" области, перечитав десятки толстых книжек. Зато со временем фильтруешь теоретическую воду и выбираешь зерна.
ingumsky
13.03.2016 23:36+1Хорошо, когда область смежная, а я по образованию историк (ха-ха), а по основной профессии редактор и переводчик. Несмотря на то, что я с программированием в той или иной степени имею дело уже почти двадцать лет, до сих пор иногда оказывается, что какие-то «азы» мне оказываются неизвестны. Бывает очень обломно.
AlexSerbul
13.03.2016 23:41Зато вы практик и скорее всего знаете столько тонкостей и граблей, что сможете вывести проект к цели не затопив :-) Если мы программируем, значит это видимо наше хобби, страсть. А страсть развивает в человеке все что нужно и даже больше — чем образование из под палки родителей.
ingumsky
13.03.2016 23:54Вы обо мне думаете лучше, чем есть на самом деле :) Но спасибо всё равно.
Соглашусь с вами в том, что интерес и даже страсть к любимому делу помогает двигаться вперёд, но иногда этого недостаточно. Да и вообще в любимом деле хочется понимать и знать всё :)
AlexSerbul
13.03.2016 23:42+1У меня есть хороший знакомый — техдир. По образованию — египтолог. Но умнейший человек, как архитектор — принимает оптимальные решения, проекты идут, успешен :-)
serf
13.03.2016 02:11-1Для работы знать не нужно. Достаточно просто иметь минимальное предствавление о алгоритмах. Нормальный инженер при необходимости (что в обычной прикладной разработке бывает не часто) поднимет нужные материалы, выберет оптимальные алгоритмы и реализует задачу. В прикладной разработке чем проще код тем лучше, лучше использовать библиотечные реализации.
Знать нужно только для собеседований в большие компании. Так как там берут с расчетом что без проблем смогут тебея кидать на любые проекты так как "академическая база" хорошая.
arielf
13.03.2016 02:43+7
О Господи, опять началось! Я ещё понимаю вопрос, 'а нужно ли программисту знать математику?', но вопрос 'нужно программисту знать алгоритмы?' уже за гранью добра и зла. Что же с нами стало?AlexSerbul
13.03.2016 23:30-1Проблема в том, что программисты лезут в область хардкорной математики и чудят. И наоборот, сильно умные ребята лезут кодить и рождают говнокод.
arielf
17.03.2016 01:43+1Я даже не буду комментировать Вашу фразу, ибо у Вас какое-то очень необычное представление о промышленном программировании. Впрочем, всего несколько слов. Я не знаю, где Вы нашли программистов, любящих лезть в математику, насколько я знаю, обычно они боятся её, как черти ладана. То, к чему Вы призвали, называется разделением труда и существует уже очень много лет (как минимум несколько тысяч), но в последнее время фирмы по причине кажущейся экономии или из злого умысла — я не знаю, нанимают, скажем, трёх программистов средней или низкой квалификации, которые как кодеры ещё ничего, но инженеры из них никакие. Вместо того, чтобы нанять одного архитектора, одного программиста и одного тестировщика, ну и нескольких временных консультантов из предметной обасти — видимо, наивно полагая, что три девушки сироты выносят и родят ребёнка быстрее, чем одна из хорошей обеспеченной семьи с папой, мамой и бабушкой в Израиле. В общем, такие дела.
rg_software
13.03.2016 05:27+10Не, это действительно годный троллинг-наброс.
Мне кажется, что подойти можно с другой стороны. Нужно ли программисту знать, как решается квадратное уравнение? Может, и не нужно, но как же вы можете этого не знать, если тему проходят в средней школе?
Курс алгоритмов — неизбежный этап в обучении программированию от Австралии до Норвегии. Предположим, я только начинаю учиться программировать. ОК, написали сначала "Hello, world", потом "Hello, %username%", а дальше-то что? Что можно делать с этими буковками? Выучили понятие массива — отлично, а давайте мы теперь найдём в нём требующееся значение. Нашли? А давайте теперь отсортируем по возрастанию, чтобы данные были как в телефонном справочнике. Замечательно. А давайте теперь поищем значение в отсортированном массиве. Ага! Совсем иначе всё выглядит, да?..
Выше вон писали: зачем программировать, если любую программу можно скачать в интернете? Штука в том, что начинающий программист за первый год (если не больше) обучения в принципе не напишет ничего такого, чего нельзя скачать в интернете. Но учиться же на чём-то надо. Аналогично: студент-химик переливает реактивы в пробирках, хотя на производстве никто ничего переливать не будет; студент-токарь вытачивает детали на станке, которые никогда в жизни больше вытачивать не будет; пианист играет гаммы и этюды, которые никогда больше не сыграет, и так везде.
Если человек ухитрился пройти мимо вот этого этапа обучения, я бы в принципе поостерёгся иметь с ним дело. Пёс его знает, что у него в голове. Это по моим понятиям что-то вроде чатбота: да, наверно, он может умело отвечать на разные вопросы в течение десяти минут, но рано или поздно где-то обнаружится фантастическая дыра, которая сделает дальнейшую работу решительно невозможной.
Другой вопрос состоит в том, насколько важно иметь библиотеку алогоритмов в голове. Ведь ясно, что в университете даже за годовалый курс можно едва-едва освоить книгу Кормена (и то, вероятно, не целиком), а уж всякие специализированные вещи явно остаются за бортом. Не знаю. Наверно, не очень важно. Для меня скорее важно на книге Кормена и аналогичных вырастить в голове некую "чуйку", которая поможет найти в литературе готовый алгоритм по описанию задачи.
Ну то есть возникает на практике какая-то задача, и надо сразу понять: это что-то совсем узкое, и надо думать самому, или достаточно широкое, чтобы готовый алгоритм можно было найти? Если можно найти, то как переформулировать задачу, чтобы найти? А как и где искать?.. Ну и так далее.
А какие-то совсем базовые вещи вроде списков, деревьев, хэш-таблиц, алгоритмов сортировки и поиска, обхода графов и т.п., конечно, надо знать. Но это довольно скромный объём знаний, и опять-таки, пройти мимо них в реальной жизни довольно трудно.
merlin-vrn
13.03.2016 08:34+2Аналогично: студент-химик переливает реактивы в пробирках, хотя на производстве никто ничего переливать не будет; студент-токарь вытачивает детали на станке, которые никогда в жизни больше вытачивать не будет; пианист играет гаммы и этюды, которые никогда больше не сыграет, и так везде.
Химики _напроизводстве, которые занимаются разработкой новых техпроцессов — будут, переливают. Постоянно. Если на производстве такого подходящего химика и лаборатории нет или ресурсов недостаточно, производство идёт в университет и заказывает разработку или анализ им. То есть, я это постоянно наблюдаю на примере, например, ЭФКО и химфака ВГУ. Правда, сейчас пробирками и при обучении-то не особо пользуются. Пользуются колбами, часто с отводами (Клайзена, Арбузова — т. е. для перегонки); нагревателями, холодильниками, дефлегматорами, вакуум-насосами и манометрами, и всё это в лаборатории, как при обучении, студентами, так и при работе, инженерами.
И про пианистов неправда ваша Как-то был на мастер-классе Жаки Терассона, это такой джазовый пианист, довольно известный и очень хороший музыкант. Там у него прямо спросили — вы гаммы часто играете? Он ответил: каждый день так разминаюсь.
И вполне понятно, это действительно разминка мышц, которые двигают пальцами. Если программисту в общем-то пофигу как быстро он будет нажимать на клавиши и сможет ли надёжно регулировать усилие, то для пианиста это вопрос первостпенной важности, поэтому и он разминается каждый раз.
Мне кажется, подобная ситуация присутствует во всём. Нужно постоянно тренировать все органы, в том числе — мозг, для чего обязательно необходимо нагружать его сложными задачами, которые раньше не попадались и для которых решения он не знает (ну или забыл). Другими словами, научился дёргать струны на гитаре — пойди, поучись рисовать.rg_software
14.03.2016 16:18+1Хорошо, пианист разминается гаммами, но не играет их на концертах. Чем разминается программист (или музыкант) — его личное дело. Можно разминаться как раз реализацией алгоритмов. Мы же сейчас говорим о том, что люди делают не ради разминки, а конкретно на работе. Про химиков рассуждать не берусь, но подозреваю, что те, кто занимается разработкой новых техпроцессов — это аналог тех программистов, которые на работе разрабатывают алгоритмы :) То есть явно не средне-стандартный уровень.
merlin-vrn
15.03.2016 08:29Да ну? Не играет? Вы наверное на концертах не бываете.
Возьмите любую популярную мелодию. Давайте, Yesterday. Соль-фа-фа, ля-си-до-диез-ре-ми-фа-ми-ре-ре, ре-ре-до-си-бемоль-ля-соль-си-до-до… Всё ещё не видите гаммы? Хорошо, почитайте ноты Баха, хотя бы знаменитую токкату и фугу ре-минор.
А у джазовых гамм и того больше, там поди половина импровизаций — гамма на соответствующем текущей гармонии звукоряде. Там просто гаммы сложнее, не простые диатонические, как в примере выше.
Гаммы — это основа мелодий, а не разминка для рук.
А любому кодеру время от времени нужно реализовывать алгоритмы уже хотя бы затем, чтобы не появлялись перлы вида if len(str(bool))==4. Я не говорю про проекты, но разминаться нужно обязательно.
lair
13.03.2016 17:52+2пианист играет гаммы и этюды, которые никогда больше не сыграет,
Это не так. Гаммы (и арпеджио) состоят из технических элементов (в первую очередь — аппликатурных решений), которые есть во всем, что играет пианист. Поэтому игра гамм напрямую влияет на то, как человек играет произведения. Более того, гаммы прекрасны тем, что их, как и любое упражнение, можно просто повторять каждый день, не имея необходимости что-то изобретать.
Что характерно, то же самое относится и к программистам. С одной стороны, в повседневных задачах регулярно встречается что-то, что унаследовано из классических алгоритмов (в первую очередь, конечно, разные варианты рекурсивных решений, либо D&C, либо динамические). А с другой стороны, тот же Мартин пишет, что программисту полезна ежедневная отвлеченная практика (те же гаммы и этюды, просто программные).rg_software
14.03.2016 16:20Когда я говорил про "не сыграет", то, разумеется, имел в виду "не сыграет на концерте". В остальном согласен. Собственно, я же скорее на стороне "алгоритмистов" в текущей дискуссии :)
lair
14.03.2016 16:23Когда я говорил про «не сыграет», то, разумеется, имел в виду «не сыграет на концерте».
Еще раз: гаммы, арпеджио и этюды содержат куски, которые входят в "нормальные" произведения. Поэтому, обучая руки играть гаммы, ты обучаешь их чему-то, что однажды надо будет играть на концерте.
amaksr
13.03.2016 08:43+3А я иногда сортирую методом пузырька...
tronix286
13.03.2016 15:38Это ужасно. Самая, имхо, медленная из сортировок. Но я не лучше — я везде и всегда юзаю QSort -)
AlexSerbul
13.03.2016 23:28А он не везде лучше! :-) Иногда элементарная сортировка пузырьком нужна, кстати.
merlin-vrn
14.03.2016 08:44ну, зато стабильная (в смысле, порядок уже отсортированных элементов не портит)
grevus
13.03.2016 10:29+16Уиии! Побольше бы таких статей. Побольше бы! Почему?
Ну, люди ж соглашаются с этими постулатами. Что не надо знать алгоритмы, как работает база, как устроен компилятор ЯП, на котором работаете. Это ж проще, действительно! Зачем напрягаться?
Таких кодеров (вы уж извините), становится всё больше. И я этому очень рад. Почему?
Потому что чем больше кодеров, тем выше моя востребованность на рынке труда.dezconnect
13.03.2016 13:04Правильно, больше обезьянок тупых и уверенных в своей непогрешимости =) И никогда мы без работы не останемся.
AlexSerbul
13.03.2016 23:27-1Разделение труда. Одни в R создают матмодели и доводят их до кондиции. Другие — превращают в хороший код. Не смешивая.
burjui
14.03.2016 14:44+1Однако тем выше вероятность, что на новом месте работы вам придётся разгребать авгиевы или чьи-то ещё конюшни кода.
grevus
14.03.2016 15:02+2Согласен. Только вот разгребать их всегда. Даже за собой. Знаете какой я ужасный код писал 4-5 лет назад? Бррр.
Но это надо принять. Это неотъемлемая часть прикладного программиста.
Я разбирался в коде на ерланге, c, c++ и php.
Да, это больно. Иногда противно. Иногда ты поворачиваешься к окну и закуриваешь сигарету (это потом ты вспоминаешь, что много лет уже не куришь) и смотришь вдаль.
Но, в том числе, в этом состоит моя работа.
sdev
13.03.2016 11:15-3Приглашаю автора на любое соревнование на kaggle.com
Пусть докажет нам, что зная только названия функций, он займет, ну не первое место, ну хотя бы в топ-10% попадет (да, да, там процент конце).AlexSerbul
13.03.2016 14:33+2Я вам другую задачку поставлю, не абстрактную. Есть клиент с требованиями. Выбираете язык и реализуете, можно не быстро. Затем клиент меняет требования. Задача — внести минимум изменений в код. Вперед! 99% олимпиадников — сдохнут, выживут самые опытные и разумные.
istui
13.03.2016 15:04-3"прикладное" программирование и "системное" — две разные вещи.
от прикладника нужно умение грамотно и качественно, в срок делать стабильный и поддерживаемый код, без особых сложностей.
сложные моменты как раз реализует условно "системный" программист — с более глубоким знанием алгоритмов, возможно, изобретая что-то новое (новый проект/либу как минимум).
Где сидят эти личности — в одном человеке, в одной фирме или на разных полушариях — не существенно. Главное, чтобы между ними был контакт.
sdev
13.03.2016 17:28-1на kaggle вполне реальные задачи. По крайней мере, строя модели классификации в своей работе, я именно с такими же сталкивался. Так что велком.
MrEsp
13.03.2016 22:39+1Выживут те, кто имеет опыт работы с переделыванием кода, и особенно — чужого.
AlexSerbul
13.03.2016 23:27-1Согласен. Умение разбираться в логике чужого потока сознания похлеще матана.
sdev
14.03.2016 19:42Подождите, но матан тоже ведь не сам появился, это же тоже чей-то поток сознания
MrEsp
13.03.2016 22:45+2Интересно, как автор себе представляет отбор программистов, которые будут разрабатывать не светофор на ассемблере, где нет ни одного алгоритма, а технологии типа поиска и распознавания голоса. У меня есть несколько предположений, но позволю сначала высказаться.
AlexSerbul
13.03.2016 23:22-1Технологии классического поиска (IR), на мой взгляд, относительно просты и примитивны, иногда с небольшой порцией математики (чуток кластеризации, чуток машинного обучения). К ним бы я допустил программистов на java или другом языке со сборкой мусора () под чутким контролем аналитика.
Технологии посложнее, типа NLP и распознавания речи — неизмеримо сложнее, там много математики и машинного обучения. Поэтому к ним бы программистов напрямую не подпустил. Поручил бы математикам разобрать последние паперы, сделать прототип модельки, в которой нужно соединить правильно алгоритмы, поиграться с ней в R и только когда она покажет хороший Recal/Precision и/или другие подходящие к проблематике метрики — спустить задачку инженерам. Давать инженерам возможность выбирать алогоритм обучения нейронки, моделей маркова, дип-ленинга — я бы не в коем случае не рекомендовал! Пусть программисты отвечают за код расширяемый без багов и копипаста, и не лезут в научные области без подготовки :-)MrEsp
14.03.2016 08:56+1Это, конечно, не более чем идеологические детали, но интересно вы как-то упорядочили по сложности: IR < NLP. Вообще, IR область более широкая, а NLP — более узкая. Как раз на примере поисковых систем. в NLP, к тому же кроме математики есть еще и лингвистика, которая подтягивает свой набор специфических сложностей, поэтому, одной математики маловато даже будет, на самом деле. Короче, вашу идею понял. Однако, вот в чем вопрос: вот возьмем Deep learning к примеру. Кто должен разрабатывать и поддерживать библиотеки для deep learning'а — первые или вторые? Если чистые девелоперы — то им нужно четкое ТЗ с точностью до формулы. Ну окей разработали, а потом фиксы и улучшения — через оформление документа "Change request specification" аля аутсорс разработка на каждый чих? Если условные "математики" — то высокопроизводительную либу они не сделают, без знания низкоуравневой специфик и работы С++, GPU, итд. В общем, я к тому, что спрос на людей, которые знают, алгоритмы и технологии программирования все еще есть и будет.
tyomitch
13.03.2016 12:37+13Хех, я как раз на днях запостил патч для Python, заменяющий 2400 строк кода (валидация синтаксического дерева, написанная кем-то вручную — по отдельной функции для каждого типа узлов) тридцатью (ДКА).
Подозреваю, что автор исходного кода думал так же, как автор этого поста: "а зачем тут алгоритмы? и так же всё работает!"AlexSerbul
13.03.2016 14:34Крутой кейс. Но если человек в проекте с дедлайном через неделю и вместо регулярки начинает умничать и писать модуль на С c конечным автоматом, не успевает и потом этот модуль глючит еще год, засыпая сервер корками — согласитесь, что-то тут не то :-)
tyomitch
13.03.2016 14:58+9Вот именно для этого и нужно знать алгоритмы — чтобы понимать, когда лучше не умничать и влепить лобовое решение, а когда лучше убрать руки с клавиатуры и пару часов порисовать диаграммы на бумажке.
istui
13.03.2016 15:06+2это пример "интеллектуального", но "глупого" разработчика. Умный не будет пихать свой интеллект и знания всюду, только потому, что они у него есть.
Nikobraz
13.03.2016 22:33Хотел бы увидеть статью на эту тему. Это действительно очень круто.
tyomitch
13.03.2016 22:38+2Я б охотно, но пусть мой патч сначала отревьюят.
Кто-нибудь из хабраобитателей может ненавязчиво пнуть мейнтейнеров, чтобы они уделили моему патчу внимание?
http://bugs.python.org/issue26526
guyfawkes
13.03.2016 23:58+2а сколько в скорости выиграли, если не секрет (понятно, на ваших вычислительных ресурсах)?
guai
13.03.2016 16:26+3тут скорее не про алгоритмы, а про not invented here. часто вижу, как люди ошибочно планируют, что они сейчас по-быстрому чего-то налабают в совершенно незнакомой области, и конечно же они сталкиваются с траблами, о которых даже не подозревали. готовая тулза же сначала казалась монструозной, но потом приходит понимание, что всё это, оказывается, неизбежно. но тут уже психологически сложно выкинуть свою писанину, она ж своя родная, в нее труд вложен.
поэтому у меня правило большого пальца такое: сначала изучить имеющиеся решения, только потом начинать своё, если еще думаешь, что надо. чаще всего следование ему даёт положительные результаты. еще можно потом кого-то чрезмерно оптимистичного потыкать носом в проваленные прогнозы.AlexSerbul
13.03.2016 23:25Вот да. Я бы еще ввел разделение труда: аналитики и инженеры. С первых драть матмодели в R, анализ их эффективности и точности, а со вторых — человеческий код.
E_STRICT
13.03.2016 21:37Вопрос поставлен не корректно. Конечно все бы хотели хорошо разбираться в алгоритмах. Только вот не каждый готов тратить время на это. Особенно когда нужно срочно изучить очередной модный фреймворк, чтобы быть в тренде и зарабатывать себе на жизнь.
AlexSerbul
13.03.2016 23:24Вы серьезно хотели бы разобраться в деталях обучения нейронной сети или обучении моделей Маркова? Не думаю, что всем
это интересно и пригодиться, тем более что без хорошей матподготовки ничего не поймешь, как не старайся.
merlin-vrn
14.03.2016 08:48Вчера буквально друг-преподаватель рассказал про одного своего студента. Этот студент, скажем так, плохо учил математику и взялся отсортировать массив обезьянней сортировкой.
Ну преподаватель его пожалел, дал ему массив всего из восьми элементов, поэтому сортировка заняла всего лишь час.
Это я к тому, что понимать O-нотацию программисту обязательно необходимо. Любому. А это, видите ли, из оперы анализа алгоритмов, которая предполагает знание их устройства.DrPass
14.03.2016 10:29+2> поэтому сортировка заняла всего лишь час
А на чем же он её сортировал? Средняя сложность обезьяньей сортировки — n! * n, т.е. в среднем на 8 элементов порядка 300 тыс перестановок. Генераторы псевдослучайных чисел нынче неплохие, так что вероятность большого отклонения от медианы невелика. И в любом случае на захудалой персоналке 8 элементов абыззяна отсортирует за доли секунды.
amaksr
14.03.2016 18:53Для 90% рутинного каждодневного кодинга в тривиальных области типа биллинга и учета, знание алгоритмов не требуется, имхо. Для оставшихся 10% нетривиальных задач знание алгоритмов возможно потребуется, но не факт, что этого будет достаточно — гораздо важнее может оказаться знать, к примеру, на скольких миллионах записей начнет затыкаться Oracle, с тем чтобы решить, нужен ли он вообще, или может можно файлами обойтись, и исходя из этого оптимально спроэктировать жизненный цикл данных.
Можно успешно кодить в группе 90% большинства, при этом набираться опыта, и постепенно переходить к 10% гуру.
istui
Это справедливо для кодера (он же — "прикладной программист"), но не для разработчика (который с большой буквы).
Рано или поздно возникают задачи, которые не может адекватно решить не то что ни одна из boost'овских библиотек — в принципе ни одна из существующих. И тогда приходится делать свой алгоритм, свою библиотеку, еще лучше других. Так и происходит прогресс :)
Другое дело, что задач, не требующих computer science, гораздо больше — как в принципе и всего в реальном мире. Продавцов и менеджеров значительно больше, чем ученых. Тем не менее, в школах дают базовых курс физики и химии, поэтому понимание алгоритмов на базовом уровне (хотя бы для перспективы роста) — скорее необходимо.
AlexSerbul
я и не спорю. просто странно, почему так востребованы и действительно полезны прикладные знания
DrPass
Потому что специалист, который знает библиотеки, но не понимает, как работает хеширование, сортировка, бинарный поиск, прохождение графов и т.д., может решать задачи, но до первой серьезной проблемы. Если где-то возникнет «бутылочное горлышко», понимающий алгоритмы разработчик его сможет разрешить, а кодер — не сможет.
AlexSerbul
Такие случаи в моей практике — крайне редки. Сортировки и поиски по деревьям давно написаны и в либах и в БД. Хэширование… ну там просто все, на пальцах, за полчаса можно дойти по linear-probing hashing с бубнами. А глубоко понять… изменение системы счислений, метод Горна… нужно ли для решения задачи?
DrPass
Ну как редки? Практически в любом крупном проекте когда-никогда случаются. И в команде нужно иметь хотя бы одного специалиста, который способен их разрешать. Вы же поймите, что без этих знаний вы, конечно же, работу себе найдете и сможете вполне успешно заниматься разработкой. Но вы просто себе выставляете определённый потолок профессионального мастерства, за который (почему-то, непонятно почему) решили не заходить.
Ununtrium
Не все проекты являются высоконагруженными. Вам может нравится писать собственную реализацию какой-нибудь операции с модным алгоритмом дающим 1% прироста скорости, но вот юзеров будут бесить баги, которые возникают из-за того что вы пишите свой велосипед, а не используете проверенное решение, где баги уже выловили.
DrPass
Мы о разных вещах говорим. Я говорю, что знание и понимание алгоритмов — это полезное качество для профессионального разработчика. И может ему пригодиться в ряде случаев. Вы говорите, что плохо писать велосипеды и делать программы с багами. Конечно же, это плохо. Но к умению писать алгоритмы оно никакого отношения не имеет. Если человек вместо использования подходящего по критериям проекта готового решения пишет велосипед, это как раз непрофессионально.
С другой стороны, обратите внимание на «подходящего по критериям проекта». Наличие готового решения само по себе — это тоже далеко не всегда признак того, что не надо писать велосипед. Во-первых, его кастомизация может быть сложнее и «дырявее», чем создание некоторого нужного проекту подмножества функций. Во-вторых, оно может быть… плохо проверенным. Готовые библиотеки далеко не всегда хорошие. И так далее. В общем, не ищите себеряную пулю в стратегиях разработки, нет её. Но никакие профессиональные знания/умения лишними не бывают.
Ununtrium
Я скорее имел ввиду, что знание алгоритмов полезно но не является решающим навыком в квалификации программиста (за исключением особых случаев, типа поддержка критичного компонента в хай-лоад системе). Для сферического веб-программиста в вакууме будет полезнее знать SQL и особенности используемой БД, чем помнить как работает merge sort. И поэтому когда вы спрашиваете на интервью как инвертировать бинарное дерево, то потом не жалуйтесь что нету нормальных кандидатов.
bobermaniac
А особенности используемой БД разве не выражаются в тех алгоритмах, которые там используются?
AlexSerbul
А кто нам даст время писать свою БД? :-)
bobermaniac
В той БД, которую вы используете каждый день — какие-то другие вещи, а не алгоритмы?
Думаю, пора выпускать дистрибутивы БД с надписью «без алгоритмов».
michael_vostrikov
В той ОС, которую вы используете каждый день, есть алгоритмы? Вы считаете, что каждый программист должен в подробностях знать, как перейти из реального режима в защищенный, какая структура у дескрипторов, какой в ней алгоритм планирования задач и вытеснения страниц?
bobermaniac
Вообще говоря, было бы очень неплохо. Не в подробностях, но хотя бы в общих чертах.
Ununtrium
А ассемблер знать не надо чтобы веб приложения делать? А то вдруг придется драйвер мыши вручную патчить.
Mexanik
На мой взгляд это полезные качествА, то есть это разные вещи. Я закончил универ не так давно и уже ужасаюсь тому, что все забыл. Поэтому я для себя решил, что универ учит скорее учиться и понимать алгоритмы, чем их знать и успокоился.Вполне естественно, что серое вещество забивается теми вещами, которые часто используешь. Ничто же не мешает найти в гугле нужный алгоритм и реализовать его так, как мне надо.
А еще по опыту работы, реализовать какой либо алгоритм эффективнее существующих решений сложно, но возможно это или нет — зависит скорее от IQ человека, чем от того знает он алгоритм наизусть или нет. Разница между тем, хранится знание в сером веществе или в электронном виде где нибудь на сервере — только в скорости доступа)
SLashRU
Соглашусь. Однако, скорость доступа порой имеет очень важное значение. Например, когда для решения сложной задачи надо комбинировать набор алгоритмов. Если алгоритмы в "быстром доступе" в мозге, то решение будет найдено, если алгоритмы на сервере, то решение может быть попросту не найдено, так как мозг не будет способен найти "хитрую" но полезную связь между двумя описаниями алгоритма на сервере, в то же время, он сможет найти и использовать эту связь, если алгоритмы есть в мозгу. Подобным свойством мышления оперируют, в частности, MindMap'ы для достижения "Аха!"-эффекта при решении сложных задач..
Другой пример: решая сложную задачу, можно внезапно обнаружить, что ты изобретаешь велосипед, исходя из прототипа/набросков нового алгоритма — осознав, что предложенное новое "наивное" решение задачи есть не что иное, как реализация алгоритма X, который уже давно изучен, и можно сразу найти все его преимущества и недостатки… Я таких велосипедов наизобретал в аспирантуре, когда волею судеб был брошен в новую (ок, хорошо забытую со 2-го курса) для меня область.
degs
Вы уже сами ответили на свой вопрос:
— я верю что вы дойдете, а вот кодер — нет. Неужели не встречали таких? С другой стороны, обратный случай тоже нередок — перекачанный в теории индивид начинает через губу всех учить, хотя его код очевидно никуда не годится.Я лично считаю что программирование конечно ремесло, ремесло в той же степени как и например живопись. А чего там такого сложного? Здесь красным намазать, здесь зеленым, и погуще, двухнедельных курсов должно хватить на обучение.
arielf
Ну да, но без знания анатомии вы портрет хороший не нарисуете.
degs
я маринист )
merlin-vrn
Как там с цветоведением?
degs
М-м-м, не очень понял, у меня ирония была, а у вас?
А с цветоведением у нас, маринистов, на двухнедельных курсах было просто, я же писал уже: зеленым — главное погуще.
DrPass
> Я лично считаю что программирование конечно ремесло, ремесло в той же степени как и например живопись
Ну не совсем так. Для программирования все-таки только знания нужны, а для любой живописи нужны как знания, так еще и «физические» навыки.
vics001
Ведь проблема не в том, что надо написать сортировки, хеширование и другое. Проблема в том, что человек, который не писал, не может отличить одно от другого! И потом если ошибка в библиотеки он в полном ступоре. В общем проблема не в том, чтобы взять готовое решение, проблема в том, чтобы понять, что это решение.
Человек, который не знает, что такое поиск в ширину и в интернете найдет полную фигню.
man4j
Кодер пойдет на stackoverflow и тоже сможет )
gBear
Один из моих преподавателей на эту тему высказывался примерно так.
AlexSerbul
Это сложное ремесло. Огромное количество проектов — проваливается по причине "заговнокожения" чистых идей. Взлетают реально единицы.
gBear
Сложное оно или нет — не важно же на самом деле :-) Писать код — это ремесло, ровно в том же смысле, в котором ремеслом является написание любого текста. Например, чтобы написать свой комментарий, вам сильно вряд ли понадобились знания о "как", "зачем" и — главное — "почему" в плане, например, падежей русского языка :-) Т.е. это, грубо говоря, дело привычки… навык, если хотите. А это и есть ремесло. У кого-то этот "навык" развит лучше, у кого-то есть "чувство стиля", кто-то вообще "поэт-прозаик" — суть от этого не меняется :-)
mgremlin
Ни разу не видел проекта, который бы провалился по причине говнокода.
Зато знаю массу невероятно популярных проектов, представляющих из себя нечто невообразимое, но крайне востребованное десятилетиями.
простейший пример — WordPress. Или любой бесплатный движок интернет-магазина.
Талантливый алгоритмист — враг стартапа, пока он не называется Google. Всем остальным хватит говнокода, вопрос совсем не в этом.
первое, что определяет успех проекта — нужен ли он людям, или это фантазии авторов. Второе — сумеют ли авторы о себе рассказать. А как там оно написано — да плевать с пизанской башни, лишь бы работало. Будет затык — поправят. Наймут кого-то на месяц, и поправят. Или перепишут. Или свой компилятор нарисуют. Все это фигня, главное, чтоб был интерес...
KvanTTT
Я работал в стартапе, в котором было много говнокода. Конечно, нельзя сказать с уверенностью сказать, что он не взлетел из-за говнокода (были проблемы с монетизацией), но и из-за него было много проблем: на определенном этапе стало тяжело вносить изменения, начались тормоза, баги, хранение информации в облаках (фотографии) стало выливаться в большие шестизначные суммы в месяц (думаю, что это можно было бы оптимизировать и достаточно сильно сократить расходы). Толковый программист не пойдет работать в стартап с говнокодом (ну я бы сейчас точно не пошел ни за какие деньги). На мой взгляд и по моему опыту можно почти сразу писать хороший код (в начале допустим прототип с говнокодом, который потом без сожалений нужно выкинуть).
lexore
А какие бы вы назвали проекты, которые провалились по причине "заговнокожения" чистых идей? Я без сарказма.
mirrr
В отличии от проектов, которые не провалились, такие мало известны. Я, например, видел, как написанный за приличные деньги в течении двух месяцев проект, начал валиться при 6(!) посетителях в минуту. Автор просто отказался что-то менять — "у меня не было задачи делать хайлоад". Все. Проект свернули, так-как переписывать его было уже не было времени и заказчик не хотел терять еще деньги.
lexore
А, ну такого навалом, да :) Но может там и нет "чистых идей", которые указал автор. Я, честно говоря, не понял, что это за "чистые идеи", поэтому решил уточнить.
AlexSerbul
Чистая идея… идея, которая должна быть 100% без рисков попадания метериотом по голове — завершиться.
Возьмем веб-сервер. Что там сложного и где там алгоритмы новые. Тупой кондовый текстовый протокол. Да, хайлоад может быть.
И что мы видим в мире? Треш!
На первом месте написанный на чистом C — nginx, который делает всех вчистую и по скорости, и по масштабируемости.
Дальше видим написанный умными с потоками apache, который конечно тормознутый монстр.
Я не говорю уже про Tomcat на java — перед которым нужно ставить nginx ;-)
Т.е. простая идея, реализуемая на бумаге, превращается в лужу крови с мозгами в реальности… и рынок выбирает лучшее — nginx ;-)
mayorovp
Ну, тут вы причины со следствиями вывернули. Именно apache и был написан "втупую". Создать по потоку на соединение — это вообще самое простое решение, которому учат в любом учебнике.
А вот автору nginx пришлось постараться — асинхронные конечные автоматы, хитрое управление памятью, свои структуры данных...
AlexSerbul
Сорри. Но я к тому, что человек просто знал хорошо FreeBSD, добавил немного структур данных (видели исходники наверно подробно), написал аккуратно и со вкусом и без выпендрежа. И на этом живет хайлоад всего мира. Победила проста и здравый смысл.
AlexSerbul
Ну еще из интересного там — обработка сокетов через select/pool. Это старая техника, но эффективная и сложная в реализации. Никаких алгоритмов новых.
lexore
Мне кажется, вы делите алгоритмы на "это я знаю, это не ново (для меня)" и "этого я не знаю, это что-то новое неизвестное, да и зачем это учить".
Это вы знаете про select/poll. А для кого-то неблокируемые сокеты — это "вау, ничего себе!". Почему? Потому что он последовал вашему совету и не изучал алгоритмы :)
Кстати, у nginx ещё и sendfile, async io, хеш таблицы с использованием строки кэша процессора и много других алгоритимческих вкусностей.
nginx — это вообще отличный пример, когда просто хорошее знание и применение алгоритмов дало пользу всему человечеству.
mayorovp
Нет, это новая техника. Многопоточный вариант появился раньше.
AlexSerbul
Еще пример чисто идеи — микроядро ОС, о котором спорят Торвальдс с Таненбаумом. :-) И что использую люди — тупо, кондово, монотитно написанный linux. FreeBSD, OpeenBSD,… — писались более умно, правильно, секьюрно — и где они?
antoo
На более-менее защищаемых системах встречаются *BSD довольно часто, по моим наблюдениям. Ну, на платежных гейтах и банковской среде, например. И на банкоматах до сих пор встречается NetBSD, если мне память не изменяет.
AlexSerbul
Названия я не могу сказать, но много лет назад еще до Битрикс часто наблюдал такие кейсы:
1) Ставится очевидно достижимая задача, без новых алгоритмов
2) Ее делает один человек и видно четко, что скоро все закончится
3) Набираются люди
4) Появляются "умники", втыкающие неадекватно сложные-дорогие-ненужные вещи. Ну например вместо записи байтов в сокет ставим либу, которая делает тоже самое через задницу и ООП.
5) Проект никак не может завершится. Сроки сорваны. Люди увольняются. Умники делают черточку в резюме :-)
lexore
Понятно. Вы знаете, так получилось, что вы только что сами ответили на вопрос, зачем программисту знать алгоритмы. Просто для того, чтобы понимать, какой алгоритм лучше применить в каждом случае и не тащить вместо этого гору библиотек.
В вашей логике есть один момент, который вы упустили — вы уже знаете алгоритмы и применяете эти знания, не задумываясь об этом. И, пописывая код с этими знаниями, думаете "а надо ли мне было учить вот это все?". У вас есть понимание, когда что можно воткнуть. Это вам помогает больше, чем вы думаете.
А кто-то просто не знает и втыкает либу, где это уже реализовано. Минус тут только в том, что человек не понимает что происходит внутри.
Если ему дать две либы сортировки, как ему понять, какую применять, если он не понимает, что там происходит?
Или есть два алгоритма хеширования, и у одного проблемы с коллизиями, если его применять к длинным строкам (например, там берутся первые 32 символа). Если вы про это знаете, вы выберете правильный алгоритм. А кто-то столкнется с "неожиданными" проблемами на продакшене через пару месяцев. Вы этому человеку скажете "да ты че, это ж известная фигня", а он только разведет руками "ну, откуда ж я знал...".
Поэтому, отвечая на ваш вопрос, "нужно ли знать", ответ "ДА". Необязательно, чтобы их применять, или разрабатывать новые. Но хотя бы для того, чтобы понимать, что происходит.
AlexSerbul
А когда ты в проектах, они запускаются, приходят клиенты довольные — вот и появляется время почитать "а как оно работает"? :-)
ronkajitsu
Просто есть разница между прогрессом, развитием области, инструментами и прикладным программированием при разработке конечных продуктов для конкретных заказчиков и асбтрактных домохозяек. «Кодеры» в основном решают последние задачи. А вот когда появляются вопросы про реализацю чего-то кардинально нового, то тут другое дело. Приимерами могут служить различные графические движки, игровые платформы. Да даже масштабирование какой-то интернет-платформы. Качественный продукт может потребовать различных знаний.
А вот вопрос развития области требует, определённо, не простого знания библиотек. откуда появились эти удобные и производительные инструменты? Их кто-то создал.
А изучение базовых дисциплин и принципов, особенно в вузе, позволяет понять область, определить свою степень вовлечённости и интереса, а также отделяет те 0,001%, которые потом создадут что-то кардинально новое. Понятное дело, что немало кто пробился сам, но накапливать знания и узучать суть лучше с теми кто в теме. К.О.
AlexSerbul
Ты не успеешь скорее всего придумать свой алгоритм, если не занимаешься целенаправленно научной работой. Будешь искать в паперах, в материалах конференций…
istui
зависит от места и темпа работы, дедлайна и общей склонности к научной деятельности.
проще, конечно, брать уже готовые (и я чаще так делаю), но рано или поздно приходит момент, когда ни один из готовых не обладает нужной производительностью, в таком случае приходится придумывать что-то кардинально новое или как минимум дополнять/оптимизировать существующие решения.