а есть эта книга в pdf ?

есть

и стоит копейки

combot.org/c/-1001071233926

Сегодня был на собеседовании на позицию программиста php. Дали задание и 2 часа времени. Не справился, потому что 2 часа не хватало. Хочу Скинуть сюда задание

На мой вопрос, а кто-то успел ха два часа. Ответ ожидаемый, нет ;)

Здесь понадобятся графы

Но учитывая что у них 5 версия пыхи указана потеря не велика)))

Здесь понадобится решение в лоб со сложностью О(дохуя) после которого надо сказать "ну а теперь будем оптимизировать"

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

А графы хуяфы это для хипстеров.

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

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

+

Требования к кандидату: знание теории графов, php5

Решение в лоб с тестами в сто раз лучше неработающего "умного" без тестов

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

А нахрена её писать?) Пирамидальная куда проще.

Или быстрая.

Решение в лоб с тестами в сто раз лучше неработающего "умного" без тестов

Хз, иногда смотрят на ход мыслей, а не на двухчасовой результат

Или быстрая.

Или слиянием

Или слиянием

++

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

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

Второй шаг - множество размера один и тест на то, что выдаётся отает

Ответ

Сортируем по дате и дальше за куб(или квадрат?) перебираем ?

Сортируем по дате и дальше за куб(или квадрат?) перебираем ?

нет

Сортируем по дате и дальше за куб(или квадрат?) перебираем ?

О чем я и говорю

нет

А дальше tdd ftw

Тока там не куб, а факториал

Но это похер, потому что на маленьких размерах все работает

А дальше tdd ftw

Именно

сейчас вакансию найду

Тока там не куб, а факториал

Не факториал, если отсортированы по дате, то решение будет первый элемент + самый длинный в остатке если начало совпадает с концом первого элемента, иначе самый длинный в остатке

И так рекурсивно, вроде даже квадрат выйдет

Но это не точно

Это ты уже оптимизируешь

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

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

Так мое решение получается если идти индуктивно. Тест на пустое множество очевиден

На массиве из одного тоже

Я понимаю

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

Не было ни одного технического вопроса

Не было ни одного технического вопроса

Вакансия говно, забей :)

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

Ну тут кому что проще уже, за что мысль зацепится так сказать)

Вакансия говно, забей :)

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

построить граф, вершины которого - маршруты из условия, а ребром соединяем такие маршруты А и Б, если после маршрута А можно сесть на маршрут Б и потом пускаем bfs из узлов, в которые нельзя попасть

построить граф, вершины которого - маршруты из условия, а ребром соединяем такие маршруты А и Б, если после маршрута А можно сесть на маршрут Б и потом пускаем bfs из узлов, в которые нельзя попасть

Машрута нет, он может постоянно меняться. Представь что ты летишь допустим с Москвы в Минск потом в Литву, потом в Лондон. А можно сразу из Москвы в Литву, потом через день в Лондон. Таких маршрутов много, они динамические. Вот тот путь который я описал первый, он верный, так как длинный и согласно условиям соотвествует. Задача напоминает как поиск пути от одного юнита к НПС, но при этом ты ищёшь самый долгий путь.

я неправильно сформулировал, не маршруты, а сегменты

я неправильно сформулировал, не маршруты, а сегменты

Я ассоциацию привёл, без разницы

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

Не было ни одного технического вопроса

Вы меня конечно простите, но само описание вакансии говорит о том, что это полная хуита, а именно: - описание в дос формате(могу ошибаться) - отсутствие дресс кода(можно пиджак не носить) - будет плюсом опыт с Битрикс == Будешь по любому его юзать - шаговая доступность от м. Динамо - я не москвич, но знаю, что Динамо это днище еще то - тестовое задание, от которого ты, видимо, не в восторге - опыт от 5 лет- зп от 140р(верхняя планка, уверен, недалеко)

Вакансия говно, забей :)

+

Вы меня конечно простите, но само описание вакансии говорит о том, что это полная хуита, а именно: - описание в дос формате(могу ошибаться) - отсутствие дресс кода(можно пиджак не носить) - будет плюсом опыт с Битрикс == Будешь по любому его юзать - шаговая доступность от м. Динамо - я не москвич, но знаю, что Динамо это днище еще то - тестовое задание, от которого ты, видимо, не в восторге - опыт от 5 лет- зп от 140р(верхняя планка, уверен, недалеко)

Кстати, Битрикс при чтении я как-то пропустил. Обычно я такие конторы обхожу стороной. Причём за километр.

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

Некрасиво Битрикс поддерживать

Это больше деловая переписка

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

нормально

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

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

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

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

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

у нетфликса один высоконагруженный API сервис который как раз дергает авторизацию и пускает или не пускает

Получается уже связь должна быть жёствая

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

Получается связь на уровне бизнес логики

Запашёк монолита пошел

можешь в сторону CQRS решений посмотреть, есть статьи по тому как готовить kafka + flink

можешь в сторону CQRS решений посмотреть, есть статьи по тому как готовить kafka + flink

первый раз слышу

надо собрать статистику? новую query модель делаешь из того же эвентсурса

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

первый раз слышу

ну вот посмотри это направление :)

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

при правильной микросервисной архитектуре можно дробить хоть на микросервисы которые x с y складывают и отправляют результат дальше :)

при правильной микросервисной архитектуре можно дробить хоть на микросервисы которые x с y складывают и отправляют результат дальше :)

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

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

Микросервисы это же про горизонтальную масштабируемость и fault-tolerance. Если в обозримом будущем этого не предвидится, то зачем преждевременно оптимизировать :)