• Первый — возможность получить обратную связь есть только тогда, когда код готов и пользователь может проверить решение, кликая разные кнопочки в GUI. Это часто приводит к тому, что реализованную часть системы приходится писать заново.
• Второй, что хуже — CODE FIRST предполагает каскадную модель разработки: нет возможности настроить параллельно несколько потоков работ.
• Третий недостаток — отсутствие документации и часто слишком детализированное API. Такое API невозможно переиспользовать. 
• И ещё один, четвёртый, минус — отсутствие адаптации к изменениям. А изменения обычно происходят уже во время разработки.

• Дефицит бизнес-навыков и аналитического мышления у дизайнеров.
• Маршруты, положенные в основу архитектуры системы и UI, часто не совпадают с картой бизнес-процессов пользователя. Проще говоря, дизайнер может изобразить любой вариант UI, но возникает вопрос: а можно ли реализовать ту или эту фичу как функционал?
• Ну и та же проблема, как и с CODE FIRST: нет возможностей для быстрой и эффективной адаптации к изменениям. 

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

В 2022 / 2023 году, возник массовый, довольно новый для налоговиков РФ и налоговиков стран ЕАЭС тренд, при котором физическое лицо в статусе индивидуального предпринимателя осуществляет аналогичную деятельность в РФ и еще где-то, то есть как ИП в РФ (на УСН, ПСН, НПД) и как ИП образованное по законам зарубежного государства, при этом такое физическое лицо, может не иметь статус налогового резидента ни в одном из этих государств, административная и судебная практика по таким кейсам только формируется.

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

Почему, например, даже образованные разумные люди нередко поддаются на классические схемы очередных мошенников, верят заманчивым рекламным обещаниям, участвуют в сомнительных конкурсах или, скажем, выкатывают непротестированную сборку прямо в прод?

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

Несколько недель назад в блоге «.NET Blog» появилась статья «Что такое .NET, и почему вы должны выбрать его?». В нем был представлен высокоуровневый обзор платформы, кратко описаны различные компоненты и архитектурные решения, а также обещаны более подробные посты по затронутым темам. Этот пост является первым таким продолжением, в котором подробно рассматривается история создания, архитектурные решения и детали реализации async/await в C# и .NET.

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

Эта статья приоткроет завесу магии, скрывающуюся за кулисами веб-браузеров.

Давайте начнем!

Если вам о чём-то говорят фамилии Зив, Хомченко и Рымкевич, иди сюда, дай обниму, бедолага-олимпиадник, то вы наверняка знаете, как важно прорешивать задачи для полноценного, осознанного и глубокого понимания изученного материала. Когда нет или совсем мало реальной практики, задачи дают возможность покрыть практикой все теоретические знания, погрузиться в неожиданные выводы, сложности, баги, препятствия. Более того, даже если практики достаточно, задачи помогают относительно быстро, комплексно и глубоко проработать типичные и нетипичные ситуации, возникающие в разработке (любой другой науке). Это всегда безопасный (никто не взрывает лабораторию и не роняет прод), доступный и удобный способ подробно разобраться в предмете. Определённо, программирования это касается в первую очередь.

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»

В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.

Сегодня нет никаких технических, технологических, финансовых, нейро-эстетических обоснований для использования в цифровых продуктах такой конструкции как «шрифтовая пара». Это искусственное ограничение дизайнерской мысли носит исключительно исторических характер и не способствует здоровому развитию специалистов не заставших «типографскую печать».

Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech. 

Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.

Порой приходится слышать: «Отладчики бесполезны, гораздо целесообразнее иметь дело с логированием и модульными тестами». Подозреваю, что многие из разделяющих такое мнение думают, будто отладчик только и может, что расставлять точки останова на определённых строках, пошагово просматривать код и проверять значения переменных. Притом, что любой годный отладчик действительно всё это может, на самом деле это только верхушка айсберга. Задумайтесь: мы уже вполне можем наткнуться на код, которому около 40 лет; наверняка же с тех пор что-то изменилось?  

Tl;dr — в этом эпизоде дедовского нытья вы узнаете, что хороший отладчик поддерживает различные виды точек останова, предлагает широкие возможности визуализации данных, имеет среду REPL для выполнения выражений, может показывать зависимости между потоками и контролировать их выполнение, может подхватывать изменения в исходном коде и применять их без перезапуска программы. Также он может проходить код от конца к началу и перематывать состояние программы до любого момента в истории её выполнения. Можно даже записать весь ход управления программы и визуализировать поток управления и историю потока данных.

я Андрей Поснов, переехал из Москвы в Барселону с женой и собакой: въехал по туристической визе, получил студенческую, а как только появилась digital nomad visa, подался на нее. Я работаю инжиниринг-менеджером в американском стартапе удаленно и веду свой ютуб и телеграм каналы

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

PostgreSQL и MySQL — это надежные, безопасные и масштабируемые базы данных, которые существуют уже много лет. Каждая из них имеет уникальные сильные и слабые стороны, что делает какую‑либо из них более подходящей для конкретных нужд. В этой статье мы проведем их сравнение, чтобы помочь с принятием обоснованного решения в 2023 году.

Привет! Меня зовут Наташа Калачева. Я Frontend-разработчик в компании AGIMA. Vue — один из самых популярных фреймворков JS, его используют для разработки SPA и PWA. А его главные плюсы — это понятная, четкая документация, готовая структура и низкий порог входа.

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

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

Следуя этим рекомендациям, вы сможете создавать более эффективные проекты.

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

Одна из многословных конструкций .NET связана с деталями реализации асинхронности и обросла кучей мифов. Про неё спрашивают на собеседованиях, код-ревью, делают обязательной, добавляя в правила линтера. Это .ConfigureAwait(false), сопровождающий каждый await в коде.

В этой статье я расскажу, зачем нужен ConfigureAwait(false) и как обойтись без него.

2014-й стал переломным годом для моей карьеры в Интел. В начале 2013-го меня назначили генеральным директором по R&D в России – и мне казалось, что теперь все дороги будут открыты. От перспектив сделать что-то хорошее и для Интела и для России за спиной прямо-таки росли крылья. Но не тут-то было.

Год сразу начался по-дурацки — я полетел в Новосиб в легкой курточке и простудился на тамошнем морозе. В Сибири погода вообще коварная. У нас — минус 30 это адский ад из‑за высокой влажности. А там сухо, солнечно, тихо и ощущается как минус 10, в худшем случае минус 15. А на самом деле те же самые минус 30. И в результате вместо поездки на Олимпиаду в Сочи я сидел дома и болел две недели. Ну а потом началось — в конце февраля — начале марта Россия присоединила Крым, а в апреле начались бои на Донбассе. Нас обложили санкциями. Ну и на корпоративном фронте ситуация также резко накалилась. В том году я летал в Штаты 6 раз и провел там в общей сложности четыре месяца, уговаривая интеловый истеблишмент не закрывать бизнес в России. Дамоклов меч повис уже тогда, однако судьбе было угодно дать нам еще 8 лет...

Шок и трепет

Поначалу, как всегда, была паника и неразбериха. Никто не понимал, куда бежать и чего бояться. Вспоминается апрельский диалог с Биллом Сэвиджем – директором Developer Product Division, основным стейкхолдером Интел в России. На него тогда работало у нас человек, наверно, 700. Как сейчас помню, разговор этот состоялся в пятницу, часов в 6 вечера в санта‑кларовском офисе SC12. Обычно амеров в пятницу из офиса «сдувает» в половине 4го. Ну самый край в 4. Но Билл не уходит — переживает отчасти за Россию, но больше за свою карьеру. И мы уже несколько часов гоняем по кругу его страхи — фантомные и реальные.

Представьте, что вы работаете в команде над крупным проектом какое-то время. Проект прошел начальный этап и уже работает в продакшн среде. Им пользуются люди, даже можно сказать, что им пользуются много людей и они рассчитывают на ваш продукт, он для них важен. С какого-то момента вдруг вами овладевает беспокойство, что что-то не так. Каждый спринт дается тяжело. Новые задачи вызывают проблемы с внедрением, а после релиза вы ловите один инцидент за другим. Каждый день вы со страхом смотрите в свой месенджер, боясь увидеть очередное сообщение с очередной проблемой, которую нужно срочно решать. Запросы к базе начинают тормозить, важная информация теряться, все валится из рук, контроль над ситуацией утекает как песок сквозь пальцы. Вы начинаете плохо спать, начинают снится кошмары о бесконечных сообщениях в очередях вашего брокера, которые воркеры не способны переварить. Вам снятся сервера, на которых заканчивается CPU и память, потому что сервисы безмерно потребляют ресурсы. Утилизация дисков на серверах с СУБД уже давно под 100%, ведь сервисы что-то постоянно с них читают или пишут. Ошибки, задержки, падения. Вы просыпаетесь.

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