КОЛОНКИ · 31 января 2018, 08:40 · Отдел информации dev.by
«Инструкция для смузихлёбов и барбершоперов». Как освоить алгоритмы с нуля

iOS-разработчик Антон Марченко написал для dev.by колонку о том, как приступить к освоению алгоритмов.  

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

Любопытно, что в аутсорсе алгоритмы почти не спрашивают, в то время как во многих «приличных домах» без этих знаний отказывают. Это как с высшим образованием, на мой взгляд. С одной стороны, оно и не нужно, какого-то особого конкурентного преимущества не даёт. А с другой, без него смотрят настороженно, ещё и опасаются, что человек имеет свойство не доводить начатое до конца и может, например, куда-нибудь уплыть с проекта в самый неподходящий момент.

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

Поднять алгоритмы мне удалось только с пятого или шестого захода. Книги Вирта, Кнута, Кормена достаточно долгое время лежали мёртвым грузом, и уже казалось, что алгоритмы — это только для элитных бородатых C++ программистов, сидящих в тёмных подвалах и только иногда выбирающихся на свет божий на своих Ferrai Testarossa.

thesun.co.uk

0. Начало

Начать в первую очередь стоит с поднятия самооценки, посредством прочтения книги «Грокаем Алгоритмы» Адитьи Бхаргавы. Она рассчитана на любопытствующих восьмиклассниц, поэтому читается очень хорошо. Хорошей идеей будет помочь перевести примеры из книги с Python на ваш экзотический выбор. Автор — доброжелательный умница.

Данная книга позволит понять (вспомнить) самые базовые представления о следующих темах:

  • «О-большое» (Big-O notation)
  • Сортировка выбором
  • Рекурсия
  • Быстрая сортировка
  • Перестать бояться хеш-таблиц
  • Поиск в ширину
  • Алгоритм Дейкстры
  • Жадные алгоритмы
  • Динамическое программирование
  • Алгоритм к-ближайших соседей
  • Фильтры Блума
  • Обмен ключами Диффи-Хеллмана

То есть такие вещи, которых не нужно бояться, когда они встречаются в серьёзной литературе.

0.1 Понимать применение

Опционально, для мотивации и расширения кругозора, можно ещё почитать «Алгоритмы, по которым стоит жить» Брайана Кристина и Тома Гриффинса. В книге содержатся очень классные примеры реального использования паттернов на бытовые темы: например, когда стоит жениться, или про то, что использование Merge Sort для сортировки реальной «офлайновой» библиотеки — не лучший выбор.  

Перевод книги Кормена содержит серьёзные отличия от оригинала. Так, например, в главе 24 «Кратчайшие пути из одной вершины» в русском переводе водителю автомобиля нужно найти самый короткий путь из Киева в Запорожье. Хотя в оригинале профессор Патрик едет из Феникса в Индианаполис.

0.5 Подготовка

Итак, для успешного освоения алгоритмов нам понадобится

  • английский язык (если с ним всё плохо, то будет матч мо профитэбел сфокусироваться всё же в первую очередь на нём),
  • бумажная книга Кормена (желательно купленная за свои деньги),
  • качественный блокнот и хорошая ручка (шутки шутками, но для приобретения хороших привычек нужно иметь положительное подкрепление, которое легко достичь приятными тактильными ощущениями от качественных вещей. Поэтому дешёвые ручки и блокноты с надписями «we are hiring» лучше выбросить)
  • и где-то $300 на всё про всё.

I. Собственно обучение

Курс, который я рекомендую, — это Стэнфордская специализация Тим Рафгардена. В отличие от Принстонского Algorithms, Part I, он не завязан на конкретный язык программирования (в моём случае было критично выполнять задание на Swift, который Coursera ещё не поддерживает).

Полученные знания шлифовать открытым курсом MIT на youtube. Эрик Демейн, которого все зовут Эрик, канадский вундеркинд, прекрасно объясняет и очень хорошо острит. Иногда, правда, заставляет чувствовать себя неловко. Например, рассказывая, как самостоятельно написал Depth-first search в возрасте семи лет.

Итак, ещё раз. Вся «вода» сверху и снизу написана ради этих предложений:

  • Проходим курс Стэнфорда.
  • Ведём англоязычный конспект.
  • Читаем необходимые главы из Кормена.
  • Шлифуемся МIT-овским курсом.
  • Дисциплина (на одном энтузиазме красно-чёрное дерево не сбалансируется)

Проходить просто аудирование будет не достаточно. Весь цимус в самостоятельном решении заданий. Заставить себя ночью реализовывать алгоритмы без проверки решений будет сложновато. Привычка вкладываться в своё обучение (покупкой книг и курсов) — это самая ценная привычка, которая только может быть у современного программиста.

Прежде чем поехать на гироскутере по своим хипстерским делишкам, можно ещё шлифануться вишенкой на торте — курсом Cracking the Code Review на HackerRank (основанным на одноимённой книге Гейл Макдауэлл). И уже точно избавиться от всех этих комплексов.

  • Изучение алгоритмов сделает из меня хорошего программиста?
  • Нет.
  • Может, как человек я стану получше?
  • Ответ опять отрицательный.
Источник: dev.by
Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
Новые комментарии
Европа была позади в IT а сейчас будет отставать ещё сильнее. ИМХО, это не просто мешает развивать бизнес на основе данных но и налагает особые условия на организацию системы, т.к. требует отдельной проработки и затрат. Новые продукты начнут выходить на рынок европы с задержкой, некоторые не будут вообще выходить. Но что они защищают я не пойму, информацию можно использовать как во благо так и во вред. Логично контролировать использование информации а не её наличие. Логично не хочешь передавать данные не используй продукт, альтернатив много. А.. они же не такие удобные, интересно почему? Может просто они не получают достаточно прибыли чтобы кормить армию специалистов которые все сделают идеально, почему? Я лично facebook не использую и живу отлично, не нравится что google о вас собирает данные тогда стоит вернуться в эпоху каталогов, и подумать что лучше иметь отличный бесплатый продукт но поделиться инфой для формирования рекламы или старый добрый каталог? Права на забвение я вообще не понимаю, если информация правдивая то почему она должна исчезать из различных источников, получается интересны отдельного человека ставятся в приоритете интересам общества - т.е. доступу к знаниям о происходящем.
Wistful
27.05.2018 в 23:45
Юридический язык — это не C++. Как белорусские компании подготовились к GDPR

Обсуждение

F66e33f1b11b0312e10c2ed1a9e39188?1522757268
Sergey Bodrov
– инженер-программист в Новатех

-1

Интересно, а инженеров-строителей при собеседовании заставляют лепить кирпичи или синтезировать цемент марки М500 из подручных материалов? Или просто достаточно знать какие есть стройматериалы и в каких случаях их применять?

220b18ebcbc6b461570af69990356f74?1527466819
AnthonyBY
– iOS Developer в Лаборатория А

+7

Автор курса Cracking the Code Interview Гейл Макдауэлл говорит о том что очень распространнёная ошибка относится к техническому интервью как выполнил/не выполнил, нужно показать как ты рассуждаешь и как глубо смотришь.

Поэтому при собеседовании инженера-строителя вполне логично поставить его перед мысленным экспириментом, и уточнять почему именно он решил использовать цемент марки М500 для этого случая

https://www.youtube.com/watch?v=jxAWQN5t6wg

Missing-male
+5

Для них достаточно не забухать и не свалить перед самой сдачей объекта. Как впрочем, и для программиста (у опытных работодателей).

Жаль, ответственность и дисциплинированность ни по каким дипломам не определишь.

Missing

Интересно, почему до 80% писателей "на Qt" не могут ответить на тривиальный вопрос

1) Как реализуются виртуальные методы С++ и какая у этого стоимость?

Missing
-1

Потому что им это не нужно. Если думать о таких вещах — будет получаться плохой код.

Missing
+1

Если не понимать снизу доверху как что устроено, и тем более - не думать об этом, вот тогда плохой как вы говорите shitty code.

Но заказчиков и это устроит, они же сюда просто аутсорят, и знают о рисках, да и им лучше плохой но сейчас, чем хороший но завтра.

Missing
-2

Думать о "стоимости" -> заниматься низкоуровневой оптимизацией на этапе кодирования -> получать плохой код.

Missing

Плохой код, который надо оптимизировать.

Пишите сразу хороший код, это не чуть не затранее по времени, чем упоротый.

Если вы вынесете константные выражения сразу, т.е. подумаете - а зачем их здесь вычислять, плохого кода не получится.

А вот если вы просто не понимаете чего творите - вот это натуральный говнокод, потому что его надо будет менять

4 раза в каждой строчке - другими словами переписывать полностью. Что часто сложнее, чем написать заново,

сначала в мешанине придётся понять, что вообще тут творится разумного, а потом собрать обратно.

Missing

"Пишите сразу хороший код, это не чуть не затранее по времени, чем упоротый."

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

Порядок оптимизации должен быть таковым:

"Хорошая" структура -> профилирование -> алгоритмическая оптимизация -> профилирование -> низкоуровневая оптимизация.

Missing

4 последних нужны в 1% случаев.

развитие программирования идёт по концепции "нужно ещё вчера любого качества на остальное наплевать".

поэтому у программиста есть только один шанс написать хороший код.

конечно, при необходимости придётся что-то редизайнить и обобщать, и это нормально.

B381d45a71fcbf72474e2eff13fb5cb1?1517387642
+2

Статья полезная, спасибо, Антон. Но мне так не нравится слово смузихлёб! Вкусный и полезный напиток, вообще непонятно почему попавший в немилость.

Missing
+3

Все нормально. Просто подвид, типа "малиновый пиджак", "волосатая лапа" и тп :)

Missing
+1

Вам на заметку—пиджаки сейчас синие:)

3d6bcab26f0209d5303750cb023f2c96?1526297108
andrew.nester
– Software Engineer в Amazon Web Services

+4

По поводу интервью - на youtube можно найти интересные видео о том, как проходит собеседование у них.

Вот несколько примеров

https://www.youtube.com/watch?v=XKu_SEDAykw

https://www.youtube.com/watch?v=oWbUtlUhwa8

Ну а вообще лично мне при прочтении Кормена не хватало очень одной важной вещи - уверенного знания математики (я имею ввиду статистики, линейной алгебры). Там привоится большое количество доказательств всех алгоритмов и для их понимания это must-have

У MIT для этого есть отличный курс для старта

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-042j-mathematics-for-computer-science-fall-2010/

220b18ebcbc6b461570af69990356f74?1527466819
AnthonyBY
– iOS Developer в Лаборатория А

+1

да, спасибо за комментарий, мне тоже не хватало математики, и уже думал что может было лучше сперва курс по ней пройти:

Introduction to Discrete Mathematics for Computer Science Specialization

https://www.coursera.org/specializations/discrete-mathematics

(у меня в TODO листе)

в стэнфордском курсе рекомендуют следующий книги:

Mathematics for Computer Science Eric Lehman and Tom Leighton

Probability wikibook (очень понравилась)

пробовал ещё проходить стэпик (прошёл 2/3)

Ликбез по дискретной математике (СПбАУ РАН)

https://stepik.org/course/91/syllabus

многое вспоминаешь, но такое издевательство в задачах (когда без Wolfram Mathematica не обойдёшься), то только с готовыми ответами можно его советовать

Missing
+1

Приятный слог - читается с удовольствием. Спасибо.

"Сишник на Феррари" - милая ирония :) (Поправьте только описку в названии марки.)

Missing-male
+10

Да что тут рассуждать - все легко. Идёте в 9 класс на факультатив, где школьники готовятся к олимпиадам (Марченко - в 7-ой), садитесь тихонько в уголочке на последнюю парту и просвещаетесь.

Ибо изучение алгоритмов нужно исключительно, что б научиться думать логически. Остальное - шелуха. Поэтому учите их хоть на английском, хоть на иврите, хоть на санскрите, хоть по курсам MIT и Стенфорда, хоть по БГУИРовским методичкам. Главное, что б в голове соображалка заработала.

А бумага для блокнотов и диплома об изучении пузырьковой сортировки действительно должна быть самого высокого качества (здесь с Антоном нельзя не согласиться), шелковистой, что б пятой точке было комфортно. Так как это единственное им потом полезное применение.

Missing-male
+5

а можно примеров - что из этих талмудов пригодилось за всё время работы?

я только из-за своих хоби разработок полез в графы, сплайны, назначения и ещё по мелочам

даже ML и NN проекты по работе - это использование готовых либ и там не алгоритмические знания нужны

по мне так минским формошлёпам куда полезнее освоить нюансы полного цикла развития проекта - почитать книги по 500 страниц про CI/CD, чтоб знать как упростить жизнь с эволюцией апи и хранилища ибо большинство факапов и болота в проектах из-за этого а не медленных функций.

3d6bcab26f0209d5303750cb023f2c96?1526297108
andrew.nester
– Software Engineer в Amazon Web Services

ну мне кажется понимание алгоритмов и сложности выполнения помогает вместо

for a in array_1:

for b in array_2:

if a == b:

# do something

писать

for a in array_1:

if hash_map_for_array_2[a] != null:

# do something

(пример очень утрированный)

Многое из такого приходится с опытом, но без четкого понимания почему, а мне нравится понимать почему то или другое лучше/быстрее/оптимальнее работает. А вот тут знание алгоритмов и структур понадобиться

Missing-male
+5

ну чтоб такое понимать вроде достаточно лекций в универе не пропускать - про сложность это ж вообще азы какие-то

это как дойти до того что надо зубы чистить по утрам через обучение на факультете стоматологии

3d6bcab26f0209d5303750cb023f2c96?1526297108
andrew.nester
– Software Engineer в Amazon Web Services

+4

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

и как показывает практика, немногие эти азы знают

Missing-male
+2

>> пример очень утрированный

это да, т.к. без контекста за такое по рукам надо бить....

Missing-male
+1

Я подобное часто вижу на ревью, и если длина обоих массивов ограничена, допустим, 10, то оставляю как есть, так как код с двумя циклами читается проще. Эту оптимизацию никто не заметит. В случае, если массивы могут быть побольше, то тут одной хэш-таблицей на практике не обойдёшься - нужно реализовывать progress tracking и cancellation.

63637f4ec5ea136f9d17ce151501368e?1401052531

мне процентов 90 пригодилось, то там то тут.

первый раз примерно в 2008 - 2009 году на первом месте работы в почти аутсурсе когда попросили "ускорьте время работы такого-то запроса работает медленно очень" и пришлось неделю ковыряться в чужом коде - найти место где использовался vector, а можно было использовать map со нужным ключом.

хотя конечно все закончилось multi index container но это уже когда количество различных запросов возросло кардинально.

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

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

я даже один раз предвидел, только подумал, что уже давно его не было и пора бы ему появиться. и вот.

Missing

> когда-то пришлось ковыряться с пересекающимися наборами операций и неожиданно пришел в голову КМП, который просто случайно решил ту же самую задачу

можно подробнее в этом месте?

63637f4ec5ea136f9d17ce151501368e?1401052531
-1

Подробнее про алгоритм Кнута Морриса Пратта?

Про бизнес логику того решения вспомнить будет не так просто.

Missing
-3

Увы, это не алгоритмы.

Это стандартные контейнеры.

И больше ничего.

Классические алгоритмы более универсальны, читайте того же Кнута.

Missing-male
+13

>> по мне так минским формошлёпам куда полезнее освоить нюансы полного цикла развития проекта - почитать книги по 500 страниц про CI/CD, чтоб знать как упростить жизнь с эволюцией апи и хранилища ибо большинство факапов и болота в проектах из-за этого а не медленных функций.

Причём тут наезд на минских "формошлёпов" я не понял, но большинство проектов загибается в первую очередь по причине избыточной сложности, а не слабой производительности или неоптимального алгоритма, применённого в каком-то локальном участке кода.

Макконел в книге "Совершенный код" обозначает основной проблемой ПО борьбу со сложностью. Не использование лучших алгоритмов, не отсутствие супер-гибких архитектур, а именно борьбу со сложностью. И я с ним согласен. Проблема в том, что, в отличие от алгоритмов, не существует простых книжных рецептов поддержания низкого уровня сложности проекта. И поэтому многие считают мерилом уровня программиста его алгоритмическую базу, хотя на большинстве проектов реальная полезность этой базы невысока.

В случае низкой сложности кода, то есть грамотной компонентизации, предсказуемости и понятности архитектуры, я могу доверить оптимизацию каких-то частей кода жуниору с достаточной базой. При наличии достаточного количество алгоритмических задач, можно нанять алгоритмиста. Но когда проект скатился в Big ball of mud, все оценки становятся нерелеватными, знание алгоритмов не помогает по причине невозможности (в предсказуемое время) локализации конечного числа проблемных точек, и вернуть проект в контролируемое русло крайне тяжело.

Причём проекты легко набирают избыточную сложность как по причине отсутствия архитектуры, так и по причине over-engineering, когда архитектура представляет собой весь набор амбиций архитектора по самовыражению в коде вместо решения реальных проблем.

F66e33f1b11b0312e10c2ed1a9e39188?1522757268
Sergey Bodrov
– инженер-программист в Новатех

+1

Нюансы развития и поддержания проектов (то, что раньше называли "инженерной школой") актуальны при наличии осязаемой ответственности за последствия. Большинству айтишников это совершенно незнакомо и непонятно, как дикарям непонятна необходимость мыть руки перед едой.

Missing-male
+24

смотрите как в жизни бывает - откуда берётся камплексити

Приходит заказчик и ставит требования, все по ним работают пол года. Естественно никто ничего лишнего сложного обычно не придумывает ибо на это не дают времени и денег, да и заказчик просит тока сингпэйдж апп. За пол года получается какой-то результат и возможно даже пользователи. Результат оценивают и докидывают требований. Что делают программисты когда получают новые требования - они пытаются вщемить их в существующую архитектуру с минимальными изменениями, ибо на большие изменения никто не даст времени/денег.

Таких итераций происходит несколько.

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

Имеем унылых программистов которые вынуждены рвать свой контекст каждый день на поддержку веток + развитие продукта. Имеем проблемы с развитием проекта.

Всё стаёт фаллическим символом вертикально вверх.

И тут заказчик нанимает консалта на проект. Приезжает дядька за 200 в час, смотрит на финальные требования, смотрит на финальную архитектуру и говорит $ука с умным видом - у вас тут камплексити - мол зачем вы так криво шли если можно было по-прямой. Заказчик ессно не верит в оправдания программистов за 40 в час - ибо дядька за 200 полюбому умнее этих формошлёпов, он кстати и книги пишет про камплексити.

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

к чему эта байка - грамотная организация эволюции проекта это не менее сложный домен знаний чем оптимизации скорострельности функций.

F66e33f1b11b0312e10c2ed1a9e39188?1522757268
Sergey Bodrov
– инженер-программист в Новатех

-2

> Что делают программисты когда получают новые требования - они пытаются вщемить их в существующую архитектуру с минимальными изменениями, ибо на большие изменения никто не даст времени/денег.

Это и есть "не моют руки перед едой". Чтобы хватало времени и воды, нужно ожидаемые сроки и затраты умножать на число Пи. А иначе технический долг придется отдавать с процентами.

Missing
-2

Костыли подпирают костыли.

В процессе работы мудрый программист обязан убедить заказчика потратить деньги и время

на редизайн.

Иначе надо бежать с проекта, иначе придётся говнокодить, со всеми вытекающими.

А вытекает только то, что человек перестаёт уметь нормально, качественно работать.

Говнокод становится перманентным результата данного программиста, под девизом "и так сойдёт".

Missing

Со всем согласен, но Макконел скорее всего подсмотрел-подслушал у Брукса и Буча, так что это не его оригинальные идеи.

Первый code complete вышел в 1993ем https://en.wikipedia.org/wiki/Code_Complete

https://en.wikipedia.org/wiki/The_Mythical_Man-Month (1975) http://worrydream.com/refs/Brooks-NoSilverBullet.pdf -(1986) - многие для себя откроют с удивлением что всю их современную боль и страдания прочувствовали и обсудили уже 30-40 лет назад

Missing

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

Missing-male
vvolkau
– тестер в EPAM

+3

Про феррари смешно. Пригодились полученные знания по алгоритмам в работе?

Missing
+1

Очень полезно понимать как работают индексы в базе, B+ деревья. Да и понимать как работают хеш-таблицы или словари в вашем языке очень полезно. Да и GetHashCode необходимо много где переопределять если вы пишите на c# или java. Также очень помогает знание master theorem когда вы пишите рекуррентные алгоритмы. Обход рекурсивных структур мне очень часто встречается на практике. Или если у вас в домене есть ирерахия классов и визиторы - это уже фактически обход дерева. А если у вас в проекте есть кастомный DSL и нужно разбирать AST - тут же опять появляются рекуррентные алгоритмы. Да для понимания работы современных Nosql баз также нелпохо бы понимать как работают LSM-trees и SSTables (ну возможно вам когда-нибудь нужно будет реализовать append-only структуру на диске с индексами).

Missing-male

>> Обход рекурсивных структур мне очень часто встречается на практике. Или если у вас в домене есть ирерахия классов и визиторы - это уже фактически обход дерева. А если у вас в проекте есть кастомный DSL и нужно разбирать AST - тут же опять появляются рекуррентные алгоритмы.

И каким образом вам master theorem помогла обойти иерархию классов, реализовать визитор или построить/обойти AST?

Missing
+1

Конкретно с визиторами или с AST никак не помогло. Но один раз по результатам парсинга развесистого xml я сформировал дерево, с определенным количеством узлов и потом с ним работал. Иногда мне надо было перепарсить подузлы в процессе работы и посчитать по мелочи в процессе. Ну я посчитал сложность этого мероприятния и порадовался что мне что-то пригодилось из универа.

Missing
-3

Понимать надо, но это, увы, вовсе не знания алгоритмов.

Это знание конкретной реализации контейнера/коллекции.

И всё.

В другой либе аналогичное понятие может быть реализовано по-другому.

Missing
+1

Мне пригодилось, что я знал, что такая структура существует и я могу найти и использовать готовую реализацию.

Ну и общее понимание индексов и пр.

Picture?type=square
-1

спасибо, Антон, за заметки. обязательно воспользуюсь твоим советом.

Missing
+5

>> как приступить к освоению алгоритмов

поступить в универ, не не пробовал? ))

Бородатый хипстер пытается изобрести самую обычную вузовскую программу, но со смузи и дорогими блокнотиками :)

63637f4ec5ea136f9d17ce151501368e?1401052531

далеко не все специальности содержат курс алгоритмов и структур данных

если бы можно было давать советы в прошлое - то в школе в 7 классе можно начать читать книжку информатики с углубленным уровнем для мат-инфо классов под авторством Котова.

F66e33f1b11b0312e10c2ed1a9e39188?1522757268
Sergey Bodrov
– инженер-программист в Новатех

+8

Это поможет, если в ВУЗ поступать после техникума или курсов и пары лет практики. Когда уже есть понимание предметной области, руки уже немного выпрямились, но в голове не хватает специальных знаний.

А сразу после школы универ ничего не даст - будет голова забита умными вещами, но к моменту, когда они, наконец, пригодятся на практике, уже все забудется и забьется тупой рутиной. Редко кто начинает серьезно практиковаться или подрабатывать по специальности еще со школы, чтобы универ помогал совершенствовать навыки.

Missing
+1

Конечно же это шутка, сам штудирую курс по ML которого не было во времена универа :)  

Missing
+2

Ещё можно набирать код в блокноте чтоб он компилировался и работал - это для телефонных интервью.

И решать у доски - это для обычных.

Picture?type=square
-1

Антон, спасибо! Очень толковая статья, захотелось все почитать

778b228104958de91071dece0933f380?1420143855
+1

Вместо блокнота и ручки пользовалась маркерами и доской формата A4 - тоже приятно:)

Missing-male
+1

Скравчу себе худи "Смузихлеб" и буду ходить модный.

Missing

Если есть пошаговая инструкция о том, как делать хорошие алгоритмы, то у меня для программистов плохие новости. Кое что сможет делать это быстрее и лучше. :)

А вообще, то что могут делать люди и пока еще не так хорошо делают машины - это узнавание паттернов и синтез абстрактных концепций.

То есть, например, человек может представить Черчилля, представить бульдога, найти "что-то общее" между ними и объединить эти два образа в своей голове, представив бульдога в костюме, цилиндре, с сигарой и стаканом коньяка. Собственно поэтому в изучении алгоритмов (для нематематика) важно, думаю, скорее понимание класса проблем, общих черт проблем, решаемых с помощью какого-то алгоритма, чтобы в будущем мозг мог в прикладной проблеме узнать черты схожие с абстрактной задачей решаемой алгоритмом и синтезировать решение. И конкретно для такого рода "изучения алгоритмов" есть другая "более лучшая" книга с меньшим количеством математики.

Missing
+1

(2014) Data Structures and Algorithms in Java, 6th Ed (ISBN 1118771338) - хорошая книга. легко читается

Missing
-2

Не статья а помойка из отходов продуктов неокрепшего сознания.

В реальных проектах программисту нужно просто понимание тех же контейнеров и опыт их использования,

алгоритмы пишут в математических же институтах.

Что-то реальное новые в Беларуссии программисты не разрабатывают.

Да и архитектуру должны строить ребята по-умнее, их называют архитекторы.

Их как раз задача - анализ узких мест и с ребятами из мат. институтов решение

новых (для мира) проблем.

Всё остальное просто базируется на существующем в мире промышленном уровне.

Никто не будет писать свои векторы, мапы и прочее если уже есть библиотека,

и она устраивает заказчика по функциональным и нефункциональным (например скорости работы)

требованиям.

63637f4ec5ea136f9d17ce151501368e?1401052531
-1

За всю Беларусь не говорите. У нас сделали много чего нового и реального.

Никто не будет писать свои векторы и мапы (на самом деле будет - потому, что например оптимизаций под многопроцесоорные системы в стандартных контейнерах (допустим для языка С++) вроде как пока нет).

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

Можно конечно использовать буст, но он тоже имеет свои ограничения по мобильным платформам.

Missing
-1

От 95% всего белорусского АйТи - аусорс голимый, новое и реальное не требуется по определению.

Даже продуктовые конторы - и те по факту оказывается просто на аутсорсе у западных на целых продуктах.

Изредка есть что-то своё. И это исключение, но и там никакой новизны нет.

Ибо у с вайбера нет никаких отличий и преимуществ перед тем же матстодонтом скайпом, а ныне и перед вотсапом и/или телеграмом.

63637f4ec5ea136f9d17ce151501368e?1401052531
-1

сочувствую вашему опыту и радуюсь, что у меня совершенно другой

Missing

Тогда поделитесь своим опытом.

Что вы создали нового, чем вы гордитесь.

И мы порадуемся за вас, и будет гордится вместе с вами.

Только чур - чтобы это было лучше мировых аналогов.

Missing
+2

Насчет "помойки" не согласен — статья интересная. И вообще, изучение алгоритмов может быть интересным занятием. Главное, чтобы потом не возникло желание самому контейнеры реализовывать.

Missing
-1

Немного не в тему.

Характерный пример уровня IT (точнее - уровня разгильдяйства) в республики Беларусь:

Сейчас уже 3 сутки заканчиваются, как сайт нацбанка стоит с устаревшим SSL сертификатом.

Думаю не надо объяснять, зачем он вообще нужен, и к чему может привести его невалидность.

Телефон НБ РБ отвечает, что у них выходной и звонить нужно в рабочие часы.

Доставка e-mail, отправленного на указанные на сайте адреса была отложена,

из-за невозможности в течении 30 минут достучаться до почтовых серверов национального банка.

Притом господа администраторы однозначно получают от субъекта, подписавшего

сертификат, уведомления о его скором устаревании и необходимости его перевыпуска,

просто потому что это их хлеб.

Кроме того, вменяемый админ всегда будет иметь средство типа нагиоса, для контроля

доступности его сервисов и сбора статистики.

И такой бардак на сайте/портале который является официальным и единственным источником

весьма чувствительной финансовой информации.

220b18ebcbc6b461570af69990356f74?1527466819
AnthonyBY
– iOS Developer в Лаборатория А

Тут, видимо есть misunderstanding по поводу определения, что такое белорусского айти. Мне импонирует определение которое дал Дмитрий Насковец, три года назад: американцы могут позволить себе нанять белорусов, а вот белорусы белорусов уже нет.

Поэтому мне кажется что большинство аудитории дев.бай достаточно далеки от Нац. Банка, и прочих местечковых поделок.

Missing

Чаще всего цепочка такая.

Иностранцы нанимают белоруса, а тот нанимает других белорусов, которые от этого не перестают быть беларусами :)

Missing

Алгоритмы необходимы. Это очень эффективный лифт в профессионалы. Не устаревающие фундаментальные знания (в отличие от фреймворков однодневок). Собеседования в крупные компании. Наука 21 века (как писал проф Седжвик). Интересное участие в олимпиадах. Но лучше изучать совсем не так как в статье. Лично я видео не люблю и считаю неэффективной тратой времени. Ищем список алгоритмов, к примеру ~82 алгоритма на codechef. Берем какой-либо неизученный. Одного места где описано толково все, будь то Скиена, Седжвик или Кормен, просто нету. Поэтому сами начинаем искать годные материалы под конкретный алгоритм. Гугл, как ни странно, неплохо сортирует материалы по качеству. Просто скачем по выдаче из блога в блог, пока не наступит просветление. Радостные от понимания новой концепции, заходим на какой-нибудь online judge и решаем задачу с использованием этого алгоритма. Лучше зарегистрироваться сразу на нескольких сайтах с задачами. Ну и цель - красный цвет на codeforces. Товарищам собравшимся применять готовые "контейнеры", могу только посочувствовать :) Странно такое читать на родине Гены tourista

Missing
+1

"Товарищам собравшимся применять готовые "контейнеры", могу только посочувствовать"

Пожалуйста, не вводите в заблуждение неокрепшие умы.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси