Эссе Айзека Азимова о творчестве от 1959 года. Айзек Азимов (1920–1992) – американский писатель и профессор биохимии Бостонского университета, известный как автор научно-фантастических и научно-популярных произведений. Азимов считается одним из «большой тройки» писателей-фантастов своего времени наряду с Робертом Хайнлайном и Артуром Кларком.

---

Заметка Артура Обермайера, друга автора:

В 1959 году я работал ученым в Allied Research Associates в Бостоне. Компания была порождением MIT и изначально изучала воздействие ядерного оружия на конструкции летательных аппаратов. Компания заключила с ARPA контракт с аббревиатурой GLIPAR (Guide Line Identification Program for Antimissile Research) с целью выявления наиболее творческих подходов к созданию противоракетной оборонительной системы. Правительство понимало, что сколько бы ни было потрачено на совершенствование и дополнение существующих технологий, они все равно останутся неудовлетворительными. Они хотели, чтобы мы и несколько других подрядчиков думали нестандартно.

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

За несколько недель до 14 февраля системе Dodo IS немного поплохело под нагрузкой. Одной из причин стало то, что в backend’ах мобильного приложения и сайта не совсем корректно работали политики поверх HttpClient’а (Retry, Circuit Breaker, Timeout). В этой статье я хочу поделиться с вами потенциальными проблемами, которые могут возникнуть при неправильном использовании таких политик.

Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.

Хочу поделиться с вами подходом который я уже много лет использую в разработке приложений, в том числе и веб-приложений. Многим разработчикам настольных, серверных и мобильных приложений этот подход хорошо знаком, т.к. является фундаментальным при построении таких приложений, однако в вебе он представлен очень скудно, хотя желающие использовать такой подход однозначно есть. Кроме того на таком подходе написан редактор VS Code.



В результате применения этого подхода вы отвяжетесь от конкретного фреймворка. Сможете легко переключать библиотеку представления внутри вашего приложения, например React, Preact, Vue, Mithril без переписывания бизнес логики, а в большинстве случаев даже вьюхи. Если у вас есть приложение на Angular 1, вы без проблем сможете перевести его на Angular 2+, React, Svelte, WebComponents или даже свою библиотеку представления. Если у вас есть приложение на Angular 2+, но нету специалистов для него, то вы без проблем сможете перевести приложение на более популярную библиотеку без переписывания бизнес логики. А в итоге вообще забыть про проблему миграции с фремворка на фреймворк. Что же это за магия такая?

Привет Хабр! И так, на четырнадцатый день копья решил я значит начать делать простенький игровой сервер для простой онлайн стрелялки. За одно тему распределенных вычислений затронуть. В этой вводной статье цикла хочу рассказать что такое акторы (в Орлеанс их зернами называют) и принцип их работы. Для этого я пока пример простенького приложения с самодельными акторами без Orleans. Как говориться прежде чем строить корабль посмотрим как плавает и почему плавает обычный бумажный кораблик. За подробностями добро пожаловать под кат.

С тех пор, как в C# 5.0 завезли механизм async/await, нас постоянно во всех статьях и доках учат, что использовать асинхронный код в синхронном очень плохо. И призывают бояться как огня конструкции GetAwaiter().GetResult(). Однако есть один случай, когда сами программисты Microsoft не гнушаются этой конструкцией.

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

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

Именно такие претензии я услышал от наших девелоперов. Самое интересное, что это оказалось правдой, дав начало длительному расследованию. Речь пойдет про SQL servers, которые крутятся у нас на VMware.

В институте учат алгоритмам, структурам данных, ООП. В хорошем случае могут рассказать о паттернах проектирования или многопоточном программировании. А вот про то, чтобы рассказывали как правильно оценивать трудозатраты, я не слышал.

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

Справедливости ради следует заметить, что в разработке гораздо более распространены заниженные оценки. Почему? Кто-то считает, что программисты слишком оптимистичны по своей натуре. Я добавлю к этому еще одну причину: быть хорошим программистом и быть хорошим оценщиком — не одно и тоже. Чтобы стать хорошим программистом одного желания не достаточно. Нужны знания и практика. С чего вдруг с оценкой будет по другому?

В статье я расскажу о том, как менялось мое отношение к оценке задач и как сейчас оцениваются проекты в нашей компании. А начну я с того, как оценивать не надо. Если про то как «не надо» вы уже знаете, переходите сразу ко второй части статьи.

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

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

Текст этой статьи также доступен на английском.

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

Всем привет. 26 февраля в OTUS стартовали занятия в новой группе по курсу «MS SQL Server разработчик». В связи с этим я хочу поделиться с вами своей публикацией про оконные функции. Кстати, в ближайшую неделю еще можно записаться в группу ;-).

---

Оконные функции прочно вошли в нашу практику, но мало кто знает как работают фреймы RANGE и ROWS.

Возможно поэтому они несколько реже встречаются. Цель этой статьи привести примеры использования, чтобы у вас точно не осталось вопросов “Кто есть кто?” и “Как это применять?”. Вопрос “Зачем?” в статье останется не освещенным.

Давайте разберемся что такое фрейм, и как схожего эффекта достичь с помощью ORDER By в предложении OVER().

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

Тимлиды часто оценивают проекты, и не все делают это хорошо. Тут многое зависит от личности самого тимлида, а также от его понимания команды. Есть много техник оценки проектов от метода “по аналогии” до PERT. Но сегодня я расскажу о том, как я применяю planning poker и другие приемы, чтобы оценивать точнее и с большей пользой.

Считанные дни остаются до старта нового потока по курсу “MS SQL Server разработчик”. В преддверии старта курса продолжаем делиться с вами полезным материалом.

За годы работы с SQL Server я обнаружила, что есть несколько тем, которые часто игнорируются. Их что боятся, думают, что они сложные или что они не такие важные. Также есть мнение, что эти знания не нужны, так как SQL Server "все делает за меня". Я слышала это об индексах. Я слышала это о статистике.

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

Здравствуй, читатель. Прошло уже достаточно много времени с момента выхода .NET Core 2.1. И такие крутые нововведения, как Span и Memory, уже рассмотрены весьма широко, про них можно достаточно много прочитать, посмотреть и услышать. Однако, к сожалению, библиотека под названием System.IO.Pipelines не удостоилась такого же внимания. Почти все, что есть по этой теме — единственный пост, который многие перевели и разместили у себя. Информации должно быть однозначно больше, чтобы интересующиеся могли взглянуть на технологию с разных углов.

Вот уже более 12 лет я сгораю. Работаю, выгораю и ухожу в запой на неделю. Затем с болью и титаническими усилиями возвращаюсь к жизни, к клиентам, которых не успел потерять за недели небытия и цикл повторяется. Больше 12 лет.

Об этом не принято говорить публично, но у меня нет другого выхода. Я уверен, что у кого-то из вас присутствует те же проблемы, и вы наедине с собой, не знаете что с этим делать. Сгораете, истощаетесь, расслабляется кто как умеет и возвращается в это беличье колесо… опять, и опять, и опять.

Спрыгнуть с него кажется нереальным. Хотя бы потому что счета, семья, ипотека на 2000 лет, и желание соответствовать. Вы — житель мегаполиса хотите быть не хуже, чем сосед, чем родителей других детей, чем друг детства и в конце концов быть на вершине горы, посматривая на всех свысока. Нет? Но вкалываете вы все равно до выпученных глаз, забывая про здоровье, потом про друзей, потом про то что вокруг вообще существует жизнь за пределами вашего монитора. Вы идентифицируете себя с работой, и вся энергия уходит в нее. Вы трудоголик и вероятно вы сгораете на работе, также как и я.

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

12 лет фриланства

В преддверии старта курса «Разработчик C#» подготовили перевод интересного материала.

---

Async/Await — Введение

Языковая конструкция Async/Await существует со времен C# версии 5.0 (2012) и быстро стала одним из столпов современного программирования на .NET — любой уважающий себя C# разработчик, должен использовать ее для повышения производительности приложений, общей отзывчивости и разборчивости кода.

Async/Await делает обманчиво простым внедрение асинхронного кода и избавляет программиста от необходимости разбираться в деталях его обработки, но многие ли из нас действительно знают, как она работает, и каковы преимущества и недостатки этого метода? Существует много полезной информации, но она разобщена, поэтому я решил написать эту статью.

Ну что ж, давайте углубимся в тему.

Киберздоровье через призму Мармока

Марин Мокану, более известный как «Marmok» — один из самых популярных игровых видеоблогеров в СНГ.

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

Не будь жадиной!

При выборке данных выбирать нужно ровно столько сколько нужно за один раз. Никогда не извлекайте все данные из таблицы!

Неправильно:

using var ctx = new EFCoreTestContext(optionsBuilder.Options);                
// Мы возвращаем колонку ID с сервера, но никогда не используем и это неправильно!
ctx.FederalDistricts.Select(x=> new { x.ID, x.Name, x.ShortName }).ToList();

Правильно:

using var ctx = new EFCoreTestContext(optionsBuilder.Options);  
// Мы не возвращаем колонку ID с сервера и это правильно!
ctx.FederalDistricts.Select(x=> new { x.Name, x.ShortName }).ToList();
ctx.FederalDistricts.Select(x => new MyClass { Name = x.Name, ShortName = x.ShortName }).ToList();

Доброго времени суток, друзья!

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

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

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

Итак, поехали.