Highload ++ 2014 глазами докладчика, который очень любит Processing Large-Scale Graph Data разными нехорошими способами

Я имею в виду «Code Name Vivaldi», которое было на keynote. Организаторы его доработали и эффект на порядок вырос :)

Highload ++ 2014 глазами докладчика, который очень любит Processing Large-Scale Graph Data разными нехорошими способами

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

Практическая холакратия. Нарезаем круги и готовим роли

Похожие идеи описаны в книге «Management 3.0», Jurgen Appelo. Там автор тоже утверждает, что жесткие иерархии в мире IT не работают и будущее — за самоорганизующимися командами. Я пробую внедрять подобные вещи у себя на работе и уже имеется положительный эффект.

Умей говорить «нет» и умей говорить «да»

Интересная информация, спасибо за ссылку.

Умей говорить «нет» и умей говорить «да»

К сожалению, такие менеджеры все еще встречаются в нашей индустрии. С этим надо жить. И если работать по принципу «Ты начальник, ты и решай свои вопросы», то можно отхватить больше проблем, нежели в случае, когда каждый пытается подстраховать друг друга.

Умей говорить «нет» и умей говорить «да»

«Как правильно получить ответ Да» — и это тоже. Но в первую очередь это о том, что люди должны понимать, какую ответственность они берут на себя, говоря «да».

Умей говорить «нет» и умей говорить «да»

Ф.А.Ербол. Только сейчас понял шутку :) Кстати, в Казахстане есть такие фамилии. Сейчас многие отказываются от суффиксов -ов, -ев.

Умей говорить «нет» и умей говорить «да»

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

Умей говорить «нет» и умей говорить «да»

У Валеры и его команды бурная жизнь, поэтому продолжение будет :)

Умей говорить «нет» и умей говорить «да»

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

Разработка механизма извлечения DTO из БД с помощью LINQ

По поводу описанного кода — да, мы его используем. И он нас вполне устраивает, проект живет и быстро развивается. Вся логика запросов у нас находится на сервере и фетчеры являются одним из этапов (по факту, декларативно сконфигурированная проекция), которые проходит LINQ-запрос перед тем, как быть выполненным в БД. Перед этим он проходит через различные механизмы, навешивающим на него критерии поиска, безопасности и т.п. Плюс в проекте реализована мультитенантность и она хорошо легла в общую архитектуру. Data Services позволяют писать запросы на клиенте и еще возможно различные плюшки, о которых я пока не знаю, но это не значит, что теперь единственным правильным решением является их использование. Возможно, это действительно панацея (что редко бывает, так везде есть свои плюсы и минусы и разные задачи требуют разного подхода). В моих ближайших планах теперь хорошенько изучить WCF Data Services и составить свое мнение о них.

Разработка механизма извлечения DTO из БД с помощью LINQ

Мы все это делаем на сервере. Как я понял, фишка WCF Data Services в том, что запросы пишутся на стороне клиента. Проверка безопасности должна производиться на сервере. Из предыдущего комментария я понял, что для этого надо использовать Interceptors.

Разработка механизма извлечения DTO из БД с помощью LINQ

Мне не доводилось использовать WCF Data Services в реальных проектах. Хочу воспользоваться моментом и спросить Вас, как человека, имеющего опыт работы с ними. С помощью них можно реализовать мультитенантность? И как проводятся проверки безопасности? К примеру, проверка прав пользователя и/или извлечение только тех сущностей, на которые у пользователя имеются ACL. Сейчас мы на сервере добавляем критерии в LINQ-запрос, который в конце отдаем в фетчер. Причем в зависимости от роли текущего пользователя мы определяем, надо ли проверять ACL или нет. И по разным типам запросов над одним типом данных такая логика может разнится.

Разработка механизма извлечения DTO из БД с помощью LINQ

В последнем решении генерируются наиболее оптимальные SQL-запросы, поэтому производительность БД, наоборот, возрастает. Что касается производительности кода, то она такая же, как и при ручном написании LINQ-запроса, ведь дерево строится один раз в статическом конструкторе. И там, где скорости LINQ хватает, механизм можно смело использовать. По поводу Domain Layer немного не понял, что имеется в виду. Доменная модель присутствует. В статье описывается сценарий, когда надо просто получить данные и отдать их клиенту. Для выполнения бизнес-логики, конечно, из БД загружаются сущности и с ними производятся определённые операции.