Pull to refresh
36
0
Артем Колесников @tyomo4ka

User

Send message

Вот я тоже 5+ лет как живу в Сиднее. Я был по обе стороны процесса. Проходил интервью в три или четыре компании и сам в своей должности провёл более 200 интервью.


Я согласен что и тут, 80% рекрутеров не должны заниматься тем, чем они занимаются. Но 20% вполне толковые ребята. Я встречал несколько человек, которых я могу назвать хорошими специалистами. Таких ребят тут обычно называют TA (Talent Acquisition) и их не нужно путать с Recruiter или HR. Это уже другой уровень, они понимают очень хорошо весь процесс и заботятся не только о том как найти людей но и о том, как из удержать, как построить культуру в компании, как продвигать брэнд компании на рынке труда. TA не допустит, чтобы кандидат остался без обратной связи, но и если кандидат трэшевый, до технического интервью он не дойдёт.


Как мне видится ситуация через пару лет, ТА будет становится больше, а HR и Recruiter меньше. Но координально ситуация не поменяется, это насчёт Австралии. В родных краях ситуация будет налаживаться потихоньку тоже. Такие люди, как автор, которые способны мыслить креативно и оценивать ситуацию объективно, останутся в бизнесе. Те HR которые не способны меняться отсеются за ненужностью. Открыто признавать проблему — это кстати важный шаг. Полностью процесс трансформации займёт многие годы.


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

В идеале — каждый абонент должен быть агентом статистики.


Turbobytes предоставляют мульти CDN. У них есть JS сниппет, который ты можешь вставить в свой контент. Этот сниппет заправшивает асинхронно файл с CDN и отправляет данные о производительнсти назад в Turbobytes. Эта штука у них называется RUM. Работает именно так как вы описали.

ИМХО, все эти сети диагностики CDN — фуфло и маркетинг.


Возможно. Не могу составить экспертного мнения в этой области, так как опыта и реальных знаний у меня маловато. Пульс идеально подходит под одну задачу, которую мне нужно решить. Потому я и перевел статью. Набор агентов только маловат, мне нужно больше, чтобы выборка данных была репрезентативной.
Понял. В пн с их сейлсом созваниваюсь. Узнаю больше информации. Спасибо!
Ага, спасибо. У них только нет HTTP тестов. Буду фоловить их, так как кажется эта фича в разработке.
norlin

Спасибо за наводку. Зарегался, разбираюсь пока, как это работает. Судя по всему они используют hola.org. Интересно!
Вы знаете, этот вопрос достаточно сложный и тут нет однозначных ответов. Все зависит от того каких взглядов на Модель вы придерживаетесь. Если вы сторонник анемичных моделей (в модели только данные, простые хелперы и отношения между сущностями, бизнесс логика в слое сервисов), то не станете мешать в кучу бизнесс логику и сущности, соответственно с вашей точки зрения будет неправильно ложить инициализацию сущностей в контейнер. Если вы сторонник Rich Model, то там будут работать совсем другие принципы и правила.

Я не стану Вам в принципе давать никаких рекомендаций на этот счет. Но если хотите знать мое мнение, то я считаю, что жесткая связь оправдана в сущностях. Я бы даже запретил использовать интерфейсы для сущностей :) Так или иначе вы работатете не с абстракциями а объектами вполне конкретного типа. Если используется наследования, то можно использовать зависимости на базовый класс. С моей! точки зрения это правильно. Я думаю вы поняли, что я сторонник анемичной модели :)
Да, в принципе. Все зависит от того насколько реален пример и почему Вам так надо сделать :) В Вашем случае я вижу 2 решения.

1) Через контейнер заинжектить 1 Book и клонировать его по необходимости.
2) Некоторые контейнеры поддерживают постинициализацию. Вы можете создать метод addBook(Book $book) и попросить контейнер, чтобы он вызвал этот метод после создания объекта.

Вообще, контейнер не предназначен для работы с сущностями. Инжектить что-нибудь в сущности считается плохой практикой, как и инжектить сущности в сервисы. В Вашем случае я бы не рекомендовал использовать контейнер.
Как правило, Вам нужно получать один и тот же экземпляр класса из контейнера. Для этого можно сохранять (кэшировать) готовые объекты в свойство контейнера (ключ сервиса => готовый объект). Потом простая проверка, если объект тут, возвращаем, если не тут, создаем и ложим в кэш.

Иногда бывает нужно каждый раз получать новый экземпляр класса. Для этого Вам всего лишь нужно перестать кэшировать объект (либо просто клонировать первый созданный). В моем коде вы будете получать каждый раз новый объект.
Да, верно. DI контейнер предполагает ни один клиентский класс, ничего не знает о том, что какой-то контейнер вообще существует. В одном месте фреймворк получает один! необходимый сервис и передает управление ему.
Я планировал еще статью конкретно по Symfony Dependency Injecton Component. Хочется поделиться некоторыми идеями и получить на них фидбек. Но я достаточно кропотливо отношусь к написанию статей, поэтому не обещаю, что это будет скоро :)
1) Тут слой сервисов немного не причем :) Идея Service Locator в том чтобы отвязать логику инициализации объекта от логики его использования. Ты просто как бы говоришь контейнеру, дай мне этот объект. И он создает его со всеми зависимостями, которые тебе нужны или берет уже существующий объект, если он был инициализирован раньше. Не знаю, почему назвали именно Service Locator, как-то видимо так исторически сложилось :)

2) Не совсем так. Вы можете использовать и там и там одну реализацию контейнера. Когда вы создаете классы, которые будут сами обращаться к контейнеру и получать у него нужные сервисы – это Service Locator. Когда фреймворк берет на себя все обязанности по созданию объектов и у Вас нет клиентских классв, которые имеют зависимость на контейнер – это Dependency Injection. Т.е. в случае с Web приложением. Фреймворк принимает запрос, сопоставляет его сервису (вы должны будете в конфигруации роутов указать ключ по которому сервис доступен а контейнере), получает сервис из контейнера и передает в него запрос. Как-то так.
Спасибо, за отзывы. В статье я попытался объяснить больше «практическую проблему», т.е. почему не стоит дубилровать код создания объектов, почему стоит выносить инциализацию объектов за пределы класса, и каким образом можно организовать работу по созданию объектов внутри приложения. Насколько я понимаю, BoneFletcher прав, слово Container обычно опускают, когда говорят о DI. И, если не ошибаюсь, тот же Фаулер об этом писал. Вообще, в терминологии тяжело запутаться :) Так что я не стану спорить…
Хороший перевод, спасибо! На статью сам недавно ссылался. Сейчас добавлю ссылку еще и на Ваш перевод :)
Меня зовут Андрей и я 4 месяца разрабатываю на Symfony2


Прям клуб анонимных Симфонистов какой-то :)

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


Если Вы имеете ввиду коллекции, symfony.com/doc/master/reference/forms/types/collection.html то вся магия вот в этом классе github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php.

Если есть какие-то конкретные вопросы. Спрашивайте, я помогу.
Да, Doctrine уже лучше. Еще лучше, если только EntityManager (doctrine.orm.default_entity_manager). Т.е. только то, что Вам реально необходимо.

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

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

1. Используйте yaml для конфигурации, он гораздо легче читается.
2. Не нужно делать праметров для класса сервиса, как в документации. Эти параметры нужны, чтобы можно было подменить класс в 3dparty бандле, если нужно его заоверрайдить. В своем проекте вы всегда можете это сделать ручками, но читабельность конфига повысится.
3. Используйте команду php app/console container:debug (можно сокращать до cont:de) + grep, чтобы найти нужный сервис.
4. Делайте класс, пишите не него тесты. И только потом, конфигурируйте его как сервис в контейнере.
5. Делайте приватными те сервисы, которые нужны только как засисмости для других сервисов. Т.е. если вы не дергаете нигде сервис из контроллера, но используете только как засимость для другого сервиса.
Вы забыли упомянуть, что проект не только хостится на Github, но и сам Github использует Ace :)
Не все, картинки, а те, которые сильно сжаты… появляется эффект «квадратиков». Это вообще не очень заметно. И таки в Сафари картинки выглядят получше, чем в Хроме :)

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity