Многие программисты делают записи, описывают трудности, красивые и не очень решения, с которыми приходится сталкиваться по долгу службы. Это может быть собственный технический блог, рабочая вики, или даже обычный блокнот — суть одна. Постепенно, из маленьких Evernote-заметок может вырасти целая статья на Хабр. Но время идет, перемена места работы сулит изменения в стеке разработки, да и технологии не стоят на месте (кстати, EF Core уже пару месяцев как в версии 1.1). С другой стороны, Entity Framework 6 был и остается "рабочей лошадкой" для доступа к данным в корпоративных приложениях на стеке .net, не в последнюю очередь благодаря своей стабильности, низкому порогу входа и широкой известности. Поэтому, я надеюсь, статья всё еще окажется кому-то полезной.

Содержание:

1. Database First без EDMX
2. Работа с отсоединенными графами
3. Модификация SQL. Добавление табличных указаний
4. Кэширование данных за пределами времени жизни DbContext
5. Retry при ошибках от SQL Server
6. Подменяем DbContext, изолируемся от реальной БД
7. Быстрая вставка

Похоже, все в мире стартапов согласны с тем, что первые версии приложений должны представлять собой минимально жизнеспособный продукт (MVP, Minimal Viable Product), создавая который можно не особо заботиться о его масштабировании с технической точки зрения. Мне много раз доводилось слышать о том, что самое главное в подобных делах – поскорее выпустить нечто работающее. И, до тех пор, пока бизнес-модель нормально функционирует в условиях роста клиентской базы – всё нормально. А тратить время и деньги на то, чтобы сделать систему, которая сможет выдержать внезапный наплыв пользователей, не стоит. Беспокоиться нужно лишь о проверке предположений, об оценке рынка и о раскрутке бизнеса. Масштабируемость – это то, что можно отложить на потом. К несчастью, такая вот слепая вера в шаблонные идеи уже не раз приводила к оглушительным провалам. Pokémon GO, и, в частности, связанные с этим проектом приложения, служат напоминанием об этом.

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


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

UPD: в этом посте отражено субъективное мнение автора в 2016-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ...». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост. Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы, 10+ лет проведенных в этой системе, с короткими перерывами.

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

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

Мне нравится записывать полезные вещи об интерфейсах, свойствах, методах, функциях, типах данных, и обо всём прочем, что относится к веб-разработке. Так я заполняю пробелы в знаниях. Сейчас я занят документацией к Node.js, а до этого проработал материалы по HTML, DOM, по Web API, CSS, SVG и EcmaScript.

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

Здравствуйте. Мы в команде [censored] (да, так и называемся) уже некоторое время творим стек для построения беспроводных mesh-сетей с адаптивной маршрутизацией. И, представьте себе, получается!

Два месяца труда одним URL: ru.vuejs.org
Кроме того, переведена документация Vuex: vuex.vuejs.org/ru
И vue-router: router.vuejs.org/ru

Огромное спасибо Konojoto и всем остальным, кто помогал переводить и вычитывать документацию (полный список контрибьюторов см. в репозиториях на github.com/translation-gang)

Документация выполнена небольшим (хотелось бы верить, что это не надолго) сообществом энтузиастов open-source перевода Translation Gang. Если вы хотели бы помочь с переводами документации какого-либо проекта с открытыми исходными кодами на русской язык, милости просим в наши ряды.

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

***

Я расскажу историю одного тестового задания. Немного длинную, но, надеюсь, интересную.

У нас в Ecwid все тестовые задания для инженеров выложены открыто на GitHub вот тут — github.com/Ecwid/new-job. Можно просто начать делать любую понравившуюся задачу, никого не предупреждая, а потом, когда сами будете довольны результатом, поделиться им со мной.

Одно из первых заданий, что я придумал, был консольный качальщик файлов по HTTP. Оно очень простое и придумывал я его именно с такой мыслью. Пусть, рассуждал я, пока такое простое повисит, а потом-то я, конечно, добавлю крутые задания. Потом-то я ого-го что выдумаю! Такие крутые тестовые выложу, что все ахнут и немедленно побегут их делать, а этот примитивный качальщик я куда-нибудь запрячу и никому больше не буду показывать. Как-то так я тогда думал.

Качальщик нужно сделать действительно очень примитивный. Судите сами — ты ему список ссылок в текстовом файле, а он скачивает эти файлы и кладет в указанную папку на локальном диске. Должен уметь качать несколько файлов одновременно (в несколько потоков, например, 3 потока) и выдерживать указанное ограничение на скорость загрузки, например, 500 килобайт в секунду. Всё.

«К сожалению, мы не выбираем себе смерть, но мы можем встретить её достойно, чтобы нас запомнили как мужчин.»
— к/ф «Гладиатор»



Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer для iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот по буферизации данных, обслуживанию очередей, установлению и восстановлению соединений, и прочие вещи), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

• Автор более 30 протоколов и распределённых систем.
• Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
• Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
• CEO сервиса по созданию собственных вики-проектов Wikidot.
• Он был активистом open standards, и основателем Digital Standards Organization.
• Питер в 2007 был назван одним из «50 самых влиятельных людей в области Интеллектуальная собственность».

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

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

Моим детям 12, 9 и 5 лет. Они вырастут с моим ДНК, с моими бесконечными выступлениями на Youtube и книгами.

Под катом немного наследия, которое оставил Питер.