Перейми досвід найсильніших NLP команд світу: HuggingFace, Stanford, YouScan, Grammarly
×Закрыть

Гайд по прокачке разработчика

Доброго времени суток обитателям доу.
Сегодня наткнулся на видео: План обучения для программиста
www.youtube.com/watch?v=aCs42vWE8OE

И мне стало интересно посмотреть на альтернативный путь развития(смотреть или нет, решать вам)

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

Поехали:

Разделю все на 3 абстрактных пункта:
— Начальное обучение
— Первая работа
— Профессиональный рост

Начальное обучение:
4-8 мес. — самообразование, курсы — базовый синтаксис, Git, основы SQL, при условии 6-8 часов в день (все зависит от исходных данных знаний, мышления, наличия профильного ВО)
до 6 мес. — пет-проект, в котором вы берете любую среднюю проблему и пытаетесь простенько решить как знаете, с помощью туториалов и тд(используем самые популярные библиотеки для бд и тд)

Первая работа:
до 6 мес. — улучшаем пет проект и ищем работу как конченный(смотря кучу блогов и видосов что спрашивают на собесах): язык, Git, docker, ООП, sql, english, soft skills.

Как только находим первую работу, СРАЗУ забиваем на пет-проект,
Но стараемся никогда не сидеть без дела, ибо все ваше развитие дальше будет непосредственно зависеть от задач на работе,
и самообразовании. Двое людей проработавших год, но в разных компаниях с разными задачами на выходе могут иметь огромный разрыв между друг другом
ТУТ ОЧЕНЬ ВАЖНО: фреймворки которые будете знать, будут зависеть от того используются ли они на работе.

Профессиональный рост(до трех лет):
1. Улучшаем ООП
2. Учим паттерны проектирования(все наизусть знать не нужно, в работе только 3-6 будут всегда использоваться )
3. смотрим что такое DRY, SOLID, микросервисы
4. Улучшаем навыки развертывания проекта (вкратце основы devops)
5. осиливаем документацию по Scrum/Agile + выстраивание правильной коммуникации на проекте и между разработчиками
6. System Design (без него никуда)
7. Антипаттерны
Этот ресурс — ваше спасение: sourcemaking.com

Если вы дошли до этого пункта — поздравляю(вы уже middle) и используете StackOverflow гораздо реже чем в начале. Благодаря постоянной работе у вас появилось более широкие знания смежных технологий в индустрии

8. Algorithms and Data structures(оно не особо применимо в day-to-day работе но очень хорошо структурирует все знания. На ранних этапах — это бессмысленая трата времени)
9. (Optional) 50-100 задач на LeetCode для набивания практики по алгоритмам и закрепления

Если все вышеперечисленные пункты пройдены и есть 4-5 лет опыта на коммерческих проектах
Поздравляю, вы Senior который понимает все аспекты прямой(не рукожопной) разработки
Практически не используете StackOverflow. Только когда кривая документация

ОТСТУПЛЕНИЕ:
1 — Не работайте в компаниях на допотопных проектах, не бойтесь менять компании, это самый важный аспект вашего развития
2 — Яма(в народе «выгорание») может вас подстегать абсолютно на любом этапе, научитесь бороться/предотвращать выгорание(сюда также относится унылый проект, неналаженая коммуникация, технологии динозавров и тд)

P.S.:
10(Optional) — после упорных лет гребли на галерах задумайтесь о смысле существования
Можно описывать развитие дальше, но, пожалуй, для начинающих хватит представления на ближайшие 5 лет

Всем добра :3

LinkedIn

Лучшие комментарии пропустить

Как только находим первую работу, СРАЗУ забиваем на пет-проект

Не используйте слов, значения которых не знаете. Ваш GH несложно найти.

То, что вы хотите видеть, называется дипломной работой. Или мастерской (магистерской) работой. Или учебным проектом. Не сложилось, ПТУ в этой отрасли нет, но суть от этого не меняется: вы хотите видеть небольшой проект, смысл существования которого — показать, что автор осилил учебный материал («берете любую среднюю проблему и пытаетесь простенько решить»). К пет-проектам это не имеет никакого отношения. Если только автор не решит внезапно продолжать пилить этот проект дальше после нахождения работы, тогда возможно.

Аналогия. Вы наверняка не заводили pet dog, чтобы вписать лишнее предложение в резюме (hobbies: jogging w/ a pet dog), и выгнать живоное на улицу сразу как найдёте работу с этим резюме.

Забудьте слова pet projects если вы сами этим не занимаетесь. Это редкое явление в индустрии вообще. У людей, которым ваши советы будут полезны, их не будет. Просто «проект», или «учебный проект», whatever.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как-то всё сложно. Могу описать проще.
1. Учим какую-то технологию.
2. Устраиваемся на работу где её нужно.
3. Работаем.

Если не дурак, дальше всё само пойдёт. Если дурак, то как минимум с работой, что уже неплохо.

как в каментах правильно заметили,

это очень странный, C++/Windows-ориентированный минимум

Начал курс Нг по МЛ, пожелайте мне удачи)

2. Учим паттерны проектирования(все наизусть знать не нужно, в работе только 3-6 будут всегда использоваться )

Яка сумна новина для GoF. Щось мені здається що тут переплутані причини та наслідки )))

Очередной тренинг па-самаразвитию

10й пункт самый важный

все (не так), Миша...
(updated)
0. изучаем (m.f-n) English до честного B2. «тяжело/долго/сложно/неочень» === «есть множество других занятий и работ»
(updated)
1. вкатываемся куда_угодно (кроме гос.контор-заводов-параходов) как intern manual QA — гребем — зализываем мозоли — думаем
(критично — нормальное построение процессов, багтрекеры, хоть на что-то похожие методологии/техники тестирования, крайне желательно «чтобы все внутри на английском» (еще раз акцентируют — тестирование/трекинг в джирах, актуальные system development life cycle внутри, т.е. в идеале именно что галера/продукт для западного рынка. НЕ отечественные глиномесы или спаси Б-же, «интеграторы/франчи»)
2. если желание думать не пропало — качяемся дальше как automation QA (чтобы дойти до «условного программирования» на практике), в идеале — на внутренних курсах/с ментором, в см. чтобы вас «вырастили и протащили» внутри
3. если понравилось кодить, тогда уже да, топикстарт (хотя скорее всего к этому времени у чела будет свое понимание че и как делать/учить)

«Именно так» потому, что те кто действительно хотят кодить — УЖЕ кодят (хотя бы задачки/пет-прожекты), и почти всегда способны себе сами прописать career path чисто по вакансиям (а если нет, то — печальные новости).
А вот кто хочет вайти-вайти, должен сначала попробовать собственно, как там внутри — не потеряв сотни времени/жизни.

>

Как только находим первую работу, СРАЗУ забиваем на пет-проект,

Фу такими быть. Таким не место среди разработчиков, ящитаю.

С Вами согласятся большинство западных рекрутеров. Правда, я не могу выбрать, что лучше: я недорабатывал на основной работе и пилил свой гитхаб, или я воровал код, за который заплатил заказчик и выкладывал его на Гитхаб, или у меня нет других интересов, кроме как гитхабить после полноценного рабочего дня.
А!.. Возможно, я сидел год без работы и пилил свой гитхаб. Хотя, не уверен, что это наилучший вариант из четырех.

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

Кому место среди разработчиков, а кому нет — определяет работодатель, т.е. бизнес. Бизнесу надо, чтобы его фичи делались, а деньги — зарабатывались. Следовательно, им нужен тот кто будет зарабатывать им деньги. Каким боком тут пет-проект?

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

ТУТ ОЧЕНЬ ВАЖНО: фреймворки которые будете знать, будут зависеть от того используются ли они на работе.

Лучше конечно найти ментора что бы мог объяснить динамику сообщества, pros/cons каждого решения и долгосрочные перспективы.

Например, можно на проекте Rest API’шки на Django Rest Framework’e штопать, и притвориться что так и нужно... а можно и в FastAPI под uvicorn’ом с asyncpg, без ORM’a, и с хорошей схемой (контролируемая денормализация / сегрегация хранилищ).

Вот в SQL 99% разработчиков действительно не умеют, и такие вещи как CREATE DOMAIN / RULE / VIEW остаются покрыты туманом войны...

Не работайте в компаниях на допотопных проектах

1. Где нет тестов и TDD.
2. Где нет DevOps’a и не налажен Delivery Cycle (3-4 фичи в день с деплоем и откатами).
3. Где нет DBA’шника или вообще человека знающего возможности и ограничения используемой СУБД.

К сожалению, это 99% украинских проектов.

Ну, если взять «свежие местные» то уже не 100.
Были пару раньше контор в Харькове, есть DBBest ... тоже умели и в нормализацию, и в кодогенераторы но как сейчас — не знаю.

А пункты 1 и 2 ты решил скипнуть?

TDD люди мало мальски практикуют, а опсы хотя бы на Terraform’e с каким-то Helm’ом и CI/CD на Jenkins’e или около того довольно распространены.

Хотя если брать конкретно .net территорию — там действительно всё очень печально, и люди слишком оторваны от мира и современных подходов.

CREATE DOMAIN / RULE / VIEW

...в моем CRUD-е?.. 0о

в остальном таки да — два дево-пса этому белому господину!

Дело в том что все современные SQL СУБД умеют в JSON — потому нет даже смысла выполнять сериализацию со стороны бэкенда.

VIEW’шки в базах довольно просто мапяться на REST / GraphQL / GPRC API, с кодогенерацией и матом.

Для примера можно глянуть prisma.io или hasura.

У нас в СRUD’ы не умеют, так как у всех MVC головного мозга — на каждых 2-3 таблички в базе по контроллеру... потом что база что APIшка превращается в помойку с копи-пасты, а таблички и индексы дуються с довольно незаурядной скоростью.

Белые люди умеют в кодогенераторы на рефлексии, особенно если это Golang, Scala, Python 3.7+, Rust ...

Надо научиться писать меньше и надёжно деливерить больше — тогда будет толк.

Дякую за інфу, раніше не чув і не думав навіть, почитаю

У slick’a не особо хорошо работает... тогда уж лучше Quill, там хоть и кривые, но полноценно ассинхронные коннекторы есть, а не этот ваш JDBC...

getquill.io

Под Java испокон веков был Jooq.

ох елки
ну я чуть выпал из модных трендов, думал вы за nosql щас начнете педалить, поле=значение, вот это вот все... и тут увидел рассылку от доу)) респект, вы крутой)
последний раз просто видел результаты джейсонов когда вскрыл недопиленный подрядчиком проект на предмет «добавить полей в форму по образцу», и тут обнаружил поле some_table.jsontxt где в виде хлама, то есть простите джейсон-текста, лежало 2/3 полей сущности данных, которые должны были быть по идее столбцами))
вобщем чуть позже разгуглю все шо вы наговорили, в любом случае спасибо за инфу!

JSON головного мозга теперь часто встречается и у SQL адептов.
JSQuery и JSON(b) стал частью SQL стандарта...

В случае с постгресом чревато так как колонка больше 2Кб уедет в Toast, и нужно развлекаться с Storage Parameters.

и тут увидел рассылку от доу)) респект, вы крутой)

Не мне об этом судить... в чём-то крутой, в другом не оч.

Вообще я сам себе DevOps и DBA ...

Обычно HashiCorp Consul/Nomad/Vault/Packer/Terraform
Мониторинг/Трейсы/логирование — prometheus+influxdb, jaeger, sentry
PostgreSQL11+ под citus pg_pathman pg_repack jsquery zson etc

Rest API’шки на Django Rest Framework’e штопать, и притвориться что так и нужно.

А шо не так?

а можно и в FastAPI под uvicorn’ом с asyncpg, без ORM’a, и с хорошей схемой (контролируемая денормализация / сегрегация хранилищ).

Для чого? На такому стеці зі аплікуху складною бізнес логікою писати дуже важко, а якщо потрібна швидкодія, то краще взяти Go. В пітоні досі немає способу ефективно використовувати всі ядра і ефективно шарити память.

Як в такому стеці менеджити міграції?

Краще б всі ці люди, що пилять тисячний фреймворк поверх aiohttp, витратили зусилля на вдосконалення Django ORM, Python JIT, підтримку Multiple Interpreters та інтеграцію цього всього в Джангу.

А шо не так?

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

Для чого?

Щоб тримати мінімальною кількість коду.

На такому стеці зі аплікуху складною бізнес логікою писати дуже важко

Валідація й ААА — в більшості випадків не є бізнес логікою.
СQRS-ES під MVVM фронтенди — спокійно реалізовується в базі через FDW та вбудовані listen/notify примітиви.

Сomplex != Hard.

а якщо потрібна швидкодія, то краще взяти Go

А в го треба в кодогенерацію до безпосередньо компіляції додатку...
Й там нічього толкового зараз крім fasthttp немає.

В пітоні досі немає способу ефективно використовувати всі ядра і ефективно шарити память.

Юрій Селіванов, розробники пітону, magic stack та uvloop з вами не згодні.

Шарить память частіш за все й не потрібно, в більшості випадків достатньо просто контролювати GC pressure та пули об’єктів (щось схоже на гошний sync.Pool та сортування буферів по кешлайнах).

Як в такому стеці менеджити міграції?

Руцями в Liquibase та голий SQL.

витратили зусилля на вдосконалення Django ORM

Там немає чого вдосконалювати так як ORM сам по собі мертвий як паттерн — використовують маппери SQL’я прямо на Rest OData та GraphQL/GRPC API, валідацію виконують прямо в базі на доменах.

Python JIT

Нічього не заважає взяти GraalVM, якщо дуже хочеться в нормальний AOT.

підтримку Multiple Interpreters

Вже є готове в Graal’і — там купа проблем, пітонівська спільнота таке не потягне та на таке просто ніде взяти грошей.

...та інтеграцію цього всього в Джангу

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

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

Якось занадто загально. Що конкретно не так з Джанго і чим такий хороший FastApi окрім перфомансу. Чому такий підхід не набув поширення з flask?

Через те що в asyncio є ще багато сирих речей або які ще не підтримуються, то скоріше за все це з ним я не зможу щось прогнозувати.

Щоб тримати мінімальною кількість коду.

Ви що рахуєте код фреймворка на якому пишете? Ну тоді так це єдина, але якась сумнівна перевага.

Валідація й ААА — в більшості випадків не є бізнес логікою.

В FastApi є модулі для логіну, реєстрації, скидання паролю чи щось на зразок пермішинів та django-guardian? Я не хочу це писати ручками чи копіпастити в кожен проект.

Для мене бізнес логіка це багато рядків коду на пітоні який має тести (або хоча б протестований користувачами в проді) і який переносити на sql було б не дуже доцільно. Ви ж про це говорите?

В пітоні досі немає способу ефективно використовувати всі ядра і ефективно шарити память.
Юрій Селіванов, розробники пітону, magic stack та uvloop з вами не згодні.

А шо є щось про що я не знаю? Будь ласка, дайте посилання.

Шарить память частіш за все й не потрібно, в більшості випадків достатньо просто контролювати GC pressure та пули об’єктів (щось схоже на гошний sync.Pool та сортування буферів по кешлайнах).

Це точно в пітоні? Я не знаю що значить `сортування буферів по кешлайнах`, але з тим як пітон зберігає обджекти в памяті про оптимізації кешу процесора просто немають сенсу.

Руцями в Liquibase та голий SQL.

А якщо мені потрібно для кожного рядка примінити якусь функцію, яка вже є на пітоні? Чи Ви пропонуєте по максимуму все переносити в базу данних?

Там немає чого вдосконалювати так як ORM сам по собі мертвий як паттерн — використовують маппери SQL’я прямо на Rest OData та GraphQL/GRPC API, валідацію виконують прямо в базі на доменах.

> Rest OData
Ось про це не знав. Дякую.
> валідацію виконують прямо в базі на доменах
Для виконання перевірки потрібно витягнути всі ці рядки і що є не дуже ефективним. Правильно?

Наприклад в нас є мільйон записів в табличці і ми даємо доступ лише людям які належать до певних груп користувачів, але деяким користувачам як виняток можна дати доступ на пару додаткових записів. Ну тобто приблизно такий запит буде повільним? `join item on user.group_id == item.group_id or item.id in unnest(user.additional_items)`

Нічього не заважає взяти GraalVM, якщо дуже хочеться в нормальний AOT

GraalVM для Python дуже сирий.

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

Що ви розумієте під велосипедами? І нащо їм давали гроші? Просвітіть, будь ласка.

Що конкретно не так з Джанго

Морально застарів.

Чому такий підхід не набув поширення з flask?

Бо нікому було те реалізувати — ніхто не хотів писати рефлексію схеми БД на SQL.

Ви що рахуєте код фреймворка на якому пишете?

Я рахую кількість копі-пасти CRUD’у й наслідки кривого DDL’я.

є модулі для логіну, реєстрації, скидання паролю чи щось на зразок пермішинів та django-guardian?

Воно морально застаріле.

Я не хочу це писати ручками чи копіпастити в кожен проект.

Так треба з цього починати...

А шо є щось про що я не знаю?

... візьміть з полки пряник.

це багато рядків коду на пітоні який має тести (або хоча б протестований користувачами в проді) і який переносити на sql було б не дуже доцільно

Cправа в тому що код який переноситься в SQL — тестувати не потрібно, а код який мапить безпосередньо реляційні проекції в API доволі простий.

Це точно в пітоні?

Ага.

про оптимізації кешу процесора просто немають сенсу.

Ну... загалом для CPython мають.

А якщо мені потрібно для кожного рядка примінити якусь функцію, яка вже є на пітоні?

Її можна на пітоні як є перенести в базу, й за необхідності переписати на С.

Чи Ви пропонуєте по максимуму все переносити в базу данних?

Валідацію, ААА, повнотекстовий пошук можна спокійно повністю переносити в базу.

Для виконання перевірки потрібно витягнути всі ці рядки і що є не дуже ефективним

Ні, не потрібно.

Ну тобто приблизно такий запит буде повільним?

Взагалі за подібні запити треба по руках бити... якщо покрити нормально індексами — не буде.

GraalVM для Python дуже сирий.

Джанга ж працює...

Що ви розумієте під велосипедами?

aiohttp uvloop фреймворки.

І нащо їм давали гроші?

Мені про таке тут краще не писати.

Зараз пишу на Rust’і багато чого під DPDK, ось думав портувати uvicorn ... тому питання «швидкодії» пітона можна вирішити трохи з іншого боку.

Загалом fasthttp додатки тримають десь 120-300K RPS.
Uvicorn FastAPI AsyncPG з оптимізаціями та профілюванням через pyflame — 150-300K RPS.

Goшників найти й навчити — тяжко, довчити пітоніста — набагато легше.

тому питання «швидкодії» пітона можна вирішити трохи з іншого боку.

Як?

Я думаю допомогло б в усі ліби з запропоноваго Вами стеку та код з аплікації «add static typing using C declarations to Python code in order to boost performance».

www.nexedi.com/...​ticore.Python.HTTP.Server

Як?

От так

Пане, якщо ви взагалі не знаєте про що йде мова — не треба кидатись unwarranted aspersions, то зі сторони не дуже професійно виглядає.

add static typing using C declarations to Python code in order to boost performance

Вже є, й давно...

Как только находим первую работу, СРАЗУ забиваем на пет-проект

Не используйте слов, значения которых не знаете. Ваш GH несложно найти.

То, что вы хотите видеть, называется дипломной работой. Или мастерской (магистерской) работой. Или учебным проектом. Не сложилось, ПТУ в этой отрасли нет, но суть от этого не меняется: вы хотите видеть небольшой проект, смысл существования которого — показать, что автор осилил учебный материал («берете любую среднюю проблему и пытаетесь простенько решить»). К пет-проектам это не имеет никакого отношения. Если только автор не решит внезапно продолжать пилить этот проект дальше после нахождения работы, тогда возможно.

Аналогия. Вы наверняка не заводили pet dog, чтобы вписать лишнее предложение в резюме (hobbies: jogging w/ a pet dog), и выгнать живоное на улицу сразу как найдёте работу с этим резюме.

Забудьте слова pet projects если вы сами этим не занимаетесь. Это редкое явление в индустрии вообще. У людей, которым ваши советы будут полезны, их не будет. Просто «проект», или «учебный проект», whatever.

Всё заучишь и вот оно, выгорание.

И сразу мысли как самовыпилиться😂

И сразу столько вариантов...

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

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

1 — Не работайте в компаниях на допотопных проектах, не бойтесь менять компании, это самый важный аспект вашего развития

Это главнейший аспект роста зарплаты, но никак не развития.

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

в разных конторах разные люди — что ведет к разным подходам, а без этого невозможно понять ни один из подходов

Если вы дошли до этого пункта — поздравляю(вы уже middle) и используете StackOverflow гораздо реже чем в начале.

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

Все основано на основе моих личных мыслей, но я что-то не припомню чтобы мне хоть раз такое приходилось делать, и думаю что 95% людей в наших реалиях(!) не приходилось такое делать

я тут недавно попросил в js middle программиста развернуть nested (конечные значения всегда стринг) структуру во flat через конкатенацию ключей — чувак потратил день и не смог... (кстати вариант загуглить библиотеку или СО не исключался, что привело меня в еще большее уныние)

Ну это печаль, да. Голову бы просто включил бы и все

печаль была потом еще большая когда я пошел к другому программисту и спросил во сколько оценит эту задачу то сказал что на 2 дня....

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

1) А с каких пор скорость стала метрикой скила?
2) Вполне возможно что делать он ее пару часов будет, а остальное время котиков лайкать
3) средний программер в Украине не умеет программировать, а просто числится программистом и старается не вылететь за профнепригодность

Скорость вообще-то всегда была показателем скила причём не только в программировании

Если закладывать 80% времени на котиков то это не программист, а раздолбай какой-то

Скорость вообще-то всегда была показателем скила причём не только в программировании

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

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

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

то есть по вашему джун того же качества сделает за такое же время?

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

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

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

экспертиза в предметной области — вообще не имеет ничего общего с сеньорностью программиста — за исключением если мы не говорим о синьор екомерс программисте

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

я это называю — shitty code tolerance level — понятное дело что он везде свой, но даже в стартапе можно делать правильно, и кстати говоря нужно, другой вопрос что я под делать правильно имею немного другое чем ты — так что ты меня скорее всего не поймешь (а может и поймешь, всякое бывает).

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

Знание предметной области — важное качество хорошего программиста, иначе зачем его нанимать?

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

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

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

Скорость чего? Набивания кода? Так это машинистка. Программист основное кол-во времени должен проектированию и детализации задачи. И меньшее время — написанию собственно кода.

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

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

А ведь все что я описал в точности является одной из лабораторных работ по программированию в совковом вузе уже на самом первом семестре. То есть эту задачу на ура делают 17-летние студенты CS/CE направлений.

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

nested (конечные значения всегда стринг) структуру во flat

flatMap уже отменили?

Ну как бы один флатмап не решает, надо же в цикл это дело оформить

Не нужны циклы, есть мап и флатмап. Если у тебя есть foo: Map[T,Map[U,V]] то ты делаешь foo flatMap {case (kt,inner) => inner map { case (ku,vv) => (concat(kt, ku), vv)}. Если у нас мапа произвольной вложенности можно сделать тайплевел-рекурсию. И никаких циклов, заметь.

scala js, туда прекрасно компилится большинство всех библиотек. И там есть *барабанная дробь* оптимизация хвостовых вызовов, благодаря которой все циклы из кода можно безболезненно выпилить.

scala js

Почитал, не слышал раньше.

Правда когда есть уже куча кода на es5/6/typescript мало кто будет переходить на какие-то альтернативы.

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

Я и так знаю что js не самый хороший язык

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

странный подход к определению хороший или плохой язык...

странный подход к определению хороший или плохой язык...

там гораздо больше огрехов, чем только этот.

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

И все это конечно с помощью графических примитивов без библиотек

Так или иначе для вывода на экран какой угодно картинки вам нужно будет юзать API доступа к графическому контексту, или ещё что там. Что само по себе уже библиотека. Задача в 2д случае сама по себе довольно проста, а в 3д — сложна. Все рендереры, графические движки и прочее занимаются выводом графика кусочно-линейной функции проекции квадрата в трёхмерное пространство. Я думаю что обсирашка с 3д графиками ждёт вообще всех кто не занимается 3д граф движками.

График функции из 2д области параметров в 3д пространство это поверхность. Рендерить поверхность это не так просто как 2д график. Ибо это нужно лезть в МПВ и численно решать уравнение рендеринга.

lolwut? Елементарна триангуляція регулярної сітки. Звичайно те, що виводить 3д графіки так і робить. Там є деякі тонкощі, але там краще тупо сітку щільніше зробити, ніж хитро триангуляцію робити.

Елементарна триангуляція регулярної сітки

если я тебе функцию такую подсуну где ваша интерполяция ломается(sin(1/(x^2 + y^2))), ты тоже будешь сетку плотнее делать? там не всё так просто как ты пишешь.

если я тебе функцию такую подсуну

То на такому і у 2д проблем вигребеш. І це вже пипець проблема, яку звичайно вирішувати сенсу нема. Регулярна сітка, прямими з’єднав, що вийшло то вийшло. Ну можна якісь сплайни, але вгадайте як сплайни растерізують. То ви не пхали веселуху на кшалт cos(1/x) у матпакети — то знали б, що навіть там не дуже паряться з аналізом функції.
UPD: ну от ви написали функцію — запхайте її у проф. мат. пакет, шо буде?

Регулярна сітка, прямими з’єднав, що вийшло то вийшло.
из 2д области параметров в 3д пространство это поверхность.

Это вайрфрейм получается, а не поверхность. Если бы всё так хорошо и гладко было, то почему в 3д моделировании даже в прошаренных пакетах, выбор топологии для формы так, чтобы не было артифактов ни при сабдивижне, ни при рендеринге, ни при запекании это очень тонкое искусство? В почти любом пакете реультат получается хороший только если правильная топология + регулярная сетка. если что-то вдруг не так, то пиши пропало. По этому повторюсь:

Я думаю что обсирашка с 3д графиками ждёт вообще всех кто не занимается 3д граф движками.
Это вайрфрейм получается, а не поверхность

В про 3д рендері практично усе — вайрфрейм.

Если бы всё так хорошо и гладко было

Ніфіга не гарно і не гладко ніде. Специфічно у побудові графіків функцій, що 3д, що 2д все просто саме тому, що зробити толком ніфіга не можна (і сенсу мало) і це не намагаються робити навіть професійні математичні програми. Ви про 2д зауваження прочитали, зрозуміли, що там рівно ті самі проблеми у графіків?

рівно ті самі проблеми у графіків?

на самом деле их там меньше, ибо костылей, которых туда напихано меньше.

Натяки та загадки — це все, що у вас лишилось?

Я же прямо написал — график функции одной переменной одномерен, и чтобы его нарисовать нужно насовать точек. График функции двух переменных — двумерен, и чтобы его нарисовать — нужно рисовать поверхность. Чтобы рисовать поверхность нужно юзать много численных методов. Численные методы в своей природе, это костыли, которые работают только если данные соотвествуют нужным критериям которые иногда непросто проверить, да и не просто удовлетворить. Вот тебе такая простая логика — больше численных методов, больше оговорок «это будет работать, если».

Я же прямо написал — график функции одной переменной одномерен, и чтобы его нарисовать нужно насовать точек

А, то ви навіть в 2д не уявляєте, як графіки малюють. Бо як ви кажете по одній точці на значення — можуть бути дірки навіть у лінійних функціях. Бо оті точки — з’єднувати таки треба. І отут — прєвєд ті самі проблеми і те саме просте рішення, взагалі без чисельних методів. Яке цілком природнім чином розповсюджується на 3д і дуже широко використовується.

о оті точки — з’єднувати таки треба.

И 2д, и 3д что сейчас существует это насовать точек изощрённым образом. Других средств отображения на экран не существует. Соединение точек = линейная (полиномиальная, сплайновая) интреполяция = потеря точности, и делается только для ускорения процесса. Рисовать можно без линейной интерполяции, и дефакто это есть насовывание(насчитывание значений функции в дискретном множестве входных данных) дискретных точек на дискретное изображение таким образом чтобы соединять там было нечего и точки создавали иллюзию непрерывного изображения.

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

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

интерполяции

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

если выходные данные будут нецелочисленные при использовании целочисленных координат экрана

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

интреполяция = потеря точности

Ну точніше за піксел — так не буде, а просто додаванням купи точок антіаліасінг нормальний не зробити, а от графічні ліби для прямих можуть його дати, так що може й точніше інтерполяцією буде.

І при відсутньості подібної інтерполяції у 3д — там теж повністю аналогічні проблеми вилізуть, ще й гірше — навіщо?

графічні ліби для прямих

по условию задачи, о всех существующих либах необходимо забыть.

без библиотек
Если бы всё так хорошо и гладко было, то почему в 3д моделировании даже в прошаренных пакетах, выбор топологии для формы так, чтобы не было артифактов ни при сабдивижне, ни при рендеринге, ни при запекании это очень тонкое искусство?

Это нужно в основном только для освещения, подходов существуют два — тесселяция объектов и расчёт нормалей не перпендикулярными поверхности, а таким образом, чтобы они сглаживали переходы между полигонами. Искусства там нет. Обычный OpenGL evaluators для цели тесселяции существует уже лет 30 (IrisGL (-> CosmoGL) -> OpenGL), после того, как он отсох с fixed pipeline, можно использовать GLU библиотеку для тесселяции по сетке — там те же алгоритмы. Те же алгоритмы представлены и для одномерных «сеток».

Искусства там нет.

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

и всё потому что сетка плохо подходит под форму.

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

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

Подключить graphics.h и по справочнику в книге посмотреть функции.

а в 3д — сложна

Это задача со звездочкой. Не всем такой вариант лабораторной попадается. Но ничо — все равно справляются же студенты как-то.

Но ничо — все равно справляются же студенты как-то.

Ни разу не видел, чтобы в лабораторной работе (не курсовая и не диплом, а лаба на которую отведено 8 часов), и именно с такой формулировкой(без либ), без заготовок и пошаговой инструкции и вообще каких либо материалов было запрашиваемое сделано. Под определением слова сделано понимается наличие отображения результатов вычисления функции (u,v) => (x(u,v); y(u,v); z(u,v); c(u,v)) где с(u,v) — цвет, а на изображении присутствует тру-затененение без формул фонга и интерполяции, вайрфрейма, равномерной сетки и т.д. Рисование вайрфеймов — не тру. Заливка всякой триангуляции — тоже не тру.

Это задача со звездочкой.

Это не задача со звёздочкой, а задача для пакетов компьютерной графики.

как-то

ключевое слово. Справляются — «как-то», потому что студент один, времени мало, и человеко часов на «как положено» заведомо не хватает.

На этом этапе прикинул, а что если пациенту закинуть задачу

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

50-100 задач на LeetCode

сколько там того литкода, все задачи надо решить

ну за останні кілька років він суттєво розрісся. Зараз там 500-600 задач здається, і Hard задачі не середньо-статистичний програміст (не олімпіадник) буде доооовго вирішувати ( якшо вирішить). Та і чи треба воно? Спокійно вирішувати Middle задачі цілком вистачить

В общем, прошло фильтр. Некоторые замечания с моей колокольни:

1. Улучшаем ООП
2. Учим паттерны проектирования(все наизусть знать не нужно, в работе только 3-6 будут всегда использоваться )
6. System Design (без него никуда)
7. Антипаттерны

Вот как бы это все — одно и то же, и чем дизайн отличается от паттернов?

8. Algorithms and Data structures(оно не особо применимо в day-to-day работе но очень хорошо структурирует все знания. На раних этапах — это бессмысленая трата времени)

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

Поздравляю, вы Senior который понимает все аспекты прямой(не рукожопной) разработки
Практически не используете StackOverflow. Только когда кривая документация

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

Не работайте в компаниях на допотопных проектах, не бойтесь менять компании, это самый важный аспект вашего развития

Первую работу не выбирают, но через пол-года нужно начинать отслеживать сколько стоишь на рынке.

Яма(в народе «выгорание») может вас подстегать абсолютно на любом этапе, научитесь бороться/предотвращать выгорание(сюда также относится унылый проект, неналаженая коммуникация, технологии динозавров и тд)

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

чем дизайн отличается от паттернов?

System design — имелось ввиду Архитектура систем(можно добавить «распределенных»)

8. Algorithms and Data structures(оно не особо применимо в day-to-day работе но очень хорошо структурирует все знания. На раних этапах — это бессмысленая трата времени)

Думаю вопросы на собесе на начальную позицию будут скорее по подобным темам (array vs linked list, etc.), чем про докеры-кубернетесы, git flow, merge/rebase и абстрактные фабрики декораторов адаптеров мостов.

6. System Design (без него никуда)

Многое завязано на разных идеях и математике из п. 8, например bloom filter.

8. Algorithms and Data structures(оно не особо применимо в day-to-day работе но очень хорошо структурирует все знания. На раних этапах — это бессмысленая трата времени)

Советская школа информатики как раз уделяла этому львиную долю времени на ранних этапах обучения. Именно в подобных задачах: es145informatika.jimdo.com/...​мерных-числовых-массивов

на любом языке программирования.

9. (Optional) 50-100 задач на LeetCode для набивания практики по алгоритмам и закрепления

leetcode.com/...​ontainer-with-most-water

Реально — это @баный стыд. Задача первого года обучения информатике в школе для работы с одномерными массивами, классифицирована как Medium с failure rate 55%. Писец. Полный писец.

Основная причина, что все считают, что 8. — это бессмысленная трата времени.

ну это медиум задача. Ее конечно можно решить в лоб, за O(n2), но неплохо бы догадаться до решения за O(n), которое довольно неочевидно.
Failure rate на leetcode как раз не особо значимо, там очень гуманные сообщения об ошибках, по этому многие локально не тестируют, а сабмитят сразу.

да, решение в лоб за O(n^2) не пролазит в timelimit литкода, видать отсюда и такой failure rate

но неплохо бы догадаться до решения за O(n), которое довольно неочевидно.

Если честно, то я даже не представляю как можно решить его по-другому способу %) Я серьёзно. Видать, это именно та тренировка годами над дебильными задачами с процессингом массивов.

задача из разряда max subarray, которая решается за O(n) через two pointers + критерий, кстати в solutions там есть решение

Что как раз подтверждает мои слова о:

Основная причина, что все считают, что 8. — это бессмысленная трата времени.
Что как раз подтверждает мои слова о:

Не играл в олимпидные задачи по информатике.
Не задротил алгоритмов от слова совсем.
5 минут подумал, нашёл решение в 1 проход.
Заглянул в решения — оно там же.
Это далеко не надрочка.

Надумал и решил — две разные вещи.

Надумал и решил

Любая «задача», которая находится на литкоде не является задачей как таковой. Она является загадкой, где авторы загадали какую-либо конкретную вещь. Если навык разгадывания этих загадок есть, то делать там больше нечего, остальное чисто технический навык правильного вбивания кода который появляется после пары десятков задач. Навык разгадывания загадок, тоже на самом деле алгоритмичен — брать все известные методы решения задач по этой теме и пробовать собирать решение как конструктор лего. Имея под рукой(или в голове) хорошую базу данных этих алгоритмов, задачу этой методологией можно решить. Надрачивание — перенос базы данных решений в голову.

— максимальный элемент количества воды от линии до левой минимальной планки (той же высоты)
— максимальный элемент количества воды до правой минимальной планки (той же высоты)

если я правильно понял ваше решение, то оно не верно. Что косвенно подтверждает и право задачи на medium, и 55% failure rate.

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

1. Первый проход. Ищем максимальный и минимальный элемент массива(число) (для двух координатного массива).
2. Второй проход. Ищем для каждого элемента(справа и слева) количество воды, которое могло бы быть если бы максимальный и минимальный элемент(границы бассейна) был бы той же высоты, что и текущий (выполняется условие невозможен наклон бассейна).
3. Третий проход ищем максимальные элементы из двух массивов — максимум воды справа и слева.
4. Вычисляем реальный объем бассейна из двух найденных элементов.

2 и 3 можно совместить, но если нужна наглядность, то лучше оставить два массива и поиск.

Tuple[int, int, int] SolveThePool(int[] aEdges)
{
if (aEdges.Length <= 0)
throw new ArgumentException("aEdges must be at least 1″);

int lMin = 0;
int lMax = aEdges.Length — 1;
int[] lLeft = new int[aEdges.Length];
int[] lRight = new int[aEdges.Length];

for (int i = 0; i < aEdges.Length; ++i)
{
lRight[i] = (i — lMin) * aEdges[i];
lLeft[i] = (lMax — i) * aEdges[i];
}

int lMaxLeftBorder = lLeft[0];
int lMaxLeftInd = 0;
int lMaxRightBorder = lRight[0];
int lMaxRightInd = 0;
for (int i = 0; i < aEdges.Length; ++i)
{
if (lMaxLeftBorder < lLeft[i])
{
lMaxLeftBorder = lLeft[i];
lMaxLeftInd = i;
}
if(lMaxRightBorder< lRight[i])
{
lMaxRightBorder = lRight[i];
lMaxRightInd = i;
}
}

int lPoolValue = (lMaxRightInd — lMaxLeftInd) * Math.Min(aEdges[lMaxRightInd], aEdges[lMaxLeftInd]);
return new Tuple[int, int, int](lPoolValue, lMaxLeftBorder, lMaxRightBorder);
}

private void Button1_Click(object sender, EventArgs e)
{
int[] lEdges = new int[] { 1, 8, 6, 2, 5, 4, 8, 3, 7 };
Tuple[int, int, int] lRes = SolveThePool(lEdges);

MessageBox.Show(lRes.Item1.ToString());
}

Небольшое изменение можно сделать для двух-координатного массива, где есть координата бортика и высота (тогда lMin и lMax нужно будет вычислить). Два прохода можно совместить в продакшене, но в качестве наглядного пособия — лучше оставить.

Да, я так и думал.
а если int[] lEdges = new int[] {1,2,2,1},
ваш код выдаст 2, а правильно — 3.

Решение все равно оптимальное, как по скорости так и по качеству. Для методов AI сойдет, так как иногда быстро нужно найти оптимальную формулу, а не искать неделями оптимальное решение или прикручивать нейросетку. Ну а поправить алгоритм можно и потом.

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

Если учесть еще сферичность задачи в вакууме, что не будет в реальных задачах (отсортированный массив без пропусков в координатах) то да за 10 минут, а вот на реальном проекте будет доказывать невозможность реализации этого проекта, когда такие как я сделают на уровне удовлетворяющем заказчика.

А почему вы думаете что заказчика удовлетворит и неправильное решение? Может ему лучше за NlogN но правильное?

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

Задача первого года обучения информатике ... failure rate 55%. Писец. Полный писец

так школота и тренируется

Задача первого года обучения информатике в школе для работы с одномерными массивами, классифицирована как Medium с failure rate 55%

А який алгоритм розв’язку Ви пропонуєте?

Главным является другой вопрос, ведь сейчас в СА сильно выделяются задроты, нарешавшихся литкода и прочих. Будешь ли ты в продакшене городить тяжелый для понимания, но быстрый код, если ты 100% знаешь, что размерность массива никогда не превысит 10 элементов. Если тебе надо найти максимальный элемент once in a while в фиксированном массиве, размерность которого ограничена числом до 100, будешь ли ты вместо массивов с линейным поиском использовать деревья или другие структуры? Вот он самый главный вопрос. Это же и ответ, почему второй не полетели на луну — горе от ума %)

Мені просто стало цікаво: виходячи з треду вище, Ви стверджуєте, що задача доступна абсолютному початківцю і він знайде рішення складності O(n). Я подивився задачу і в мене виникло питання: що це за рішення таке, до якого можна додуматись не маючи жодного попереднього досвіду розв’язку подібних задач?

Я писал про решение, а не про O(n). Но и O(n) тоже после некоторого времени тренировок обработки одномерных и двумерных массивов. Например, задача поиска длинного подмассива в массиве ещё в совковых учебниках информатики подавалась под соусом «чем длинее искомый массив, тем быстрее найдёт или не найдёт», где сравнение проводилось с обоих концов строки.

www.geeksforgeeks.org/...​ubarray-of-another-array

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

failure rate

Це «не приймемо, бо не компілиться, бо ти лінива скотина» у тому числі.

Подписаться на комментарии