Комментарии

Короче, скрам — это за всё хорошее, против всего плохого, и ничего конкретного.

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

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

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

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

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

ASP.NET состоит из нескольких ключевых компонентов, которые помогают разработчикам создавать мощные и масштабируемые веб-приложения. Рассмотрим основные из них:

MVC — это архитектурный шаблон, который разделяет приложение на три основные части: модель, представление и контроллер. Это помогает упростить разработку и поддержку приложения.

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

Razor Pages используют синтаксис Razor, который позволяет смешивать HTML и C# код в одном файле. Это упрощает разработку и делает код более читабельным. Razor Pages также поддерживают привязку данных и валидацию, что упрощает работу с формами и пользовательскими вводами.

ASP.NET Web API позволяет создавать HTTP-сервисы, которые могут быть использованы различными клиентами, включая браузеры и мобильные приложения. Web API поддерживает стандартные HTTP-методы (GET, POST, PUT, DELETE) и позволяет легко создавать RESTful сервисы.

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

SignalR — это библиотека для ASP.NET, которая упрощает добавление функциональности в реальном времени в ваши приложения. Она позволяет создавать приложения, которые могут мгновенно обновлять данные на клиенте без необходимости обновления страницы. SignalR поддерживает WebSockets и другие транспортные протоколы, что делает его гибким и производительным решением для приложений в реальном времени.

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

А какие основные компоненты ASP.NET?

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

Обычно требуется сервер (через node.js), npm, и что-то типа Webpack-а (Для работы Less или какого-нибудь шаблонизатора/минификатора). Я немного ковырял ASP.NET (Не Core, а обычный) и примерно представляю как быть с серверной частью, но фронтенд для меня темный лес.

Пробема в том, что технологии в вебе обычно не ориентируются на ASP.NET, а больше на node.js, php и прочий мейнстрим. И примеры в документации тоже всегда на этом всем базируются, и для человека непосвященного не так то быстро получается это все с нуля настроить под ASP.NET.

— npm — Нужен для установки различных библиотек в JavaScript, требуется повсеместно.
— Webpack — Нужен если JavaScript и другой контент нужно упаковывать, минифицировать, использовать Less вместо ванильного CSS, шаблонизаторы HTML, использовать транспиляторы JavaScript и тому подобное.
— TypeScript — Его можно использовать как транспайлер из новых версий JavaScript в старые. Также можно использовать сам язык TypeScript. Два в одном получается, плюс грех не использовать так как в Visual Studio сделана неплохая его поддержка.

Умея быстро создать такое приложение дальше уже можно смело изучать любые веб-технологии (включая сам npm, Webpack и TypeScript), при этом сервер будет на родном дотнете.

На данный момент в ASP.NET и так уже встроены механизмы похожие на те, что есть в Webpack, а также студия из коробки (Во всяком случае 2017-ая) работает с TypeScript и компилирует его автоматически, если создать файл конфига для компилятора TypeScript-а.
Но все эти вещи поддерживаются разработчиками ASP.NET, а не веб-сообществом.

Казалось бы, если фреймворк — это всего лишь набор библиотек, а CMS — это уже почти сайт, то к чему вообще этот глупый выбор? Но ведь если бы всё было так просто, то, очевидно, не было бы этой статьи и ты её не читал бы.

CMS значительно ускоряет разработку простого шаблонного сайта. У сайта сразу готова админка и её не надо писать отдельно, в отличии от разработки на фреймворке. Однако это скорость создания сайта достигается за счёт шаблонности, ограниченности или излишней универсальности CMS.

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

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

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

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

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

Буду подводить итоги.

Плюсы CMS:

Скорость. Шаблонное решение можно создать очень быстро.

Готовая админка. На многих популярных CMS достаточно удобная и понятная админка

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

Минусы CMS

Ограниченный функционал. Шаг влево, шаг вправо карается расстрелом. Функционал допилить возможно всегда, но, вероятно, это будет просто межгалактический костыль.

Избыточность. В погоне за универсальностью, разработчики CMS, чтобы угодить всем, закладывают столько функций, что скорее всего для одного проекта всё это не нужно. В итоге получаем много неиспользуемого кода.

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

Сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке.

Плюсы фреймворка

Гибкость.Можно реализовать любую задумку без «войны» с движком

Производительность. Повторю: сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке

Минусы фреймворка

Сложность разработки. Необходимо обладать достаточными знаниями, чтобы не нагородить дырявой какашки

Отсутствие административной части. Раздел редактирования сайта нужно писать самому, а это, считай, ещё целый сайт.

Время. Разработка занимает больше времени, чем разработка с помощью CMS

Минусы решаются переиспользованием ранее написанного кода.

То есть написав одному клиенту админку, скорее всего, для следующего клиента ты возьмёшь её же и, если надо, доработаешь. Но это уже начинает превращаться в CMS!

Когда лучше подойдёт CMS

Шаблонное решение, которое покрывается возможностями CMS

Быстрое, временное или недолгосрочное решение

Для клиентов с небольшими бюджетами

Сайт ради сайта. Клиенту просто нужен сайт и он не знает зачем

Недостаточно опыта у разработчка

Когда лучше использовать фреймворк

Нетиповой нешаблонный проект

Активно изменяющийся или подстраивающийся под тренды проект Достаточно опыта, чтобы написать качественно на фремворке

Как мы видим CMS не проиграла это сравнение в одни ворота.

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

Я намеренно не рассматривал использование чистого языка для разработки, потому что времени на велосипеды будет потрачено ещё больше, чем на разработку на фреймворке, а качество, скорее всего, будет так себе. Каждый программист хочет и, наверное, должен написать свой фреймворк или CMS, но с опытом приходит осознание того, что умные дядьки уже очень много полезного за тебя понаписали и можно этим пользоваться.

Казалось бы, если фреймворк — это всего лишь набор библиотек, а CMS — это уже почти сайт, то к чему вообще этот глупый выбор? Но ведь если бы всё было так просто, то, очевидно, не было бы этой статьи и ты её не читал бы.

CMS значительно ускоряет разработку простого шаблонного сайта. У сайта сразу готова админка и её не надо писать отдельно, в отличии от разработки на фреймворке. Однако это скорость создания сайта достигается за счёт шаблонности, ограниченности или излишней универсальности CMS.

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

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

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

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

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

Буду подводить итоги.

Плюсы CMS:

Скорость. Шаблонное решение можно создать очень быстро.

Готовая админка. На многих популярных CMS достаточно удобная и понятная админка

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

Минусы CMS

Ограниченный функционал. Шаг влево, шаг вправо карается расстрелом. Функционал допилить возможно всегда, но, вероятно, это будет просто межгалактический костыль.

Избыточность. В погоне за универсальностью, разработчики CMS, чтобы угодить всем, закладывают столько функций, что скорее всего для одного проекта всё это не нужно. В итоге получаем много неиспользуемого кода.

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

Сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке.

Плюсы фреймворка

Гибкость.Можно реализовать любую задумку без «войны» с движком

Производительность. Повторю: сайт на CMS всегда уступает в производительности хорошо написанному сайту на фреймворке

Минусы фреймворка

Сложность разработки. Необходимо обладать достаточными знаниями, чтобы не нагородить дырявой какашки

Отсутствие административной части. Раздел редактирования сайта нужно писать самому, а это, считай, ещё целый сайт.

Время. Разработка занимает больше времени, чем разработка с помощью CMS

Минусы решаются переиспользованием ранее написанного кода.

То есть написав одному клиенту админку, скорее всего, для следующего клиента ты возьмёшь её же и, если надо, доработаешь. Но это уже начинает превращаться в CMS!

Когда лучше подойдёт CMS

Шаблонное решение, которое покрывается возможностями CMS

Быстрое, временное или недолгосрочное решение

Для клиентов с небольшими бюджетами

Сайт ради сайта. Клиенту просто нужен сайт и он не знает зачем

Недостаточно опыта у разработчка

Когда лучше использовать фреймворк

Нетиповой нешаблонный проект

Активно изменяющийся или подстраивающийся под тренды проект Достаточно опыта, чтобы написать качественно на фремворке

Как мы видим CMS не проиграла это сравнение в одни ворота.

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

Я намеренно не рассматривал использование чистого языка для разработки, потому что времени на велосипеды будет потрачено ещё больше, чем на разработку на фреймворке, а качество, скорее всего, будет так себе. Каждый программист хочет и, наверное, должен написать свой фреймворк или CMS, но с опытом приходит осознание того, что умные дядьки уже очень много полезного за тебя понаписали и можно этим пользоваться.

Выбор между фреймворком и CMS зависит от конкретных потребностей проекта.

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

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

При выборе также стоит учитывать опыт команды разработчиков и бюджет проекта.

Выбор между фреймворком и CMS зависит от конкретных потребностей проекта.

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

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

При выборе также стоит учитывать опыт команды разработчиков и бюджет проекта.

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

Не касаясь существа предложения, ну почему «экосистема»? Везде, во всех энциклопедиях, этот термин обозначает совершенно другое, это из совершенно другой области. Как же это слово пролезло в IT-шную речь, уже без раздумья, автоматически используется.

В порядке здоровой критики.

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

Не касаясь существа предложения, ну почему «экосистема»? Везде, во всех энциклопедиях, этот термин обозначает совершенно другое, это из совершенно другой области. Как же это слово пролезло в IT-шную речь, уже без раздумья, автоматически используется.

В порядке здоровой критики.

Если оцифровать активы нашей компании, тогда можно решить вопрос монетизации и развития экосистемы, но до этого нам все таки еще далеко, а жаль, двигаться нужно именно в этом направлении

Если оцифровать активы нашей компании, тогда можно решить вопрос монетизации и развития экосистемы, но до этого нам все таки еще далеко, а жаль, двигаться нужно именно в этом направлении

За последние 4 года я поучаствовал в разработке и проектировании около 50 платформ, стартапов, SaaS решений и приложений. Наша команда разрабатывала “Uber” для юристов, платформу оценки соответствия продукции Технических Регламентов ЕАЭС, консалтинговую платформу и так далее. Как правило — это многопользовательские платформы, на которых участники должны взаимодействовать между собой через модерацию или напрямую друг с другом.

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

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

Именно это меня и вдохновляет в работе — создавать платформы, которые стремятся к экосистеме.

Экосистема в моем понимании — это не про наличие веб-версии, приложения и расширения для браузера. Это про решения всех вопросов данной ниши в одном сервисе.

К примеру.

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

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

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

За последние 4 года я поучаствовал в разработке и проектировании около 50 платформ, стартапов, SaaS решений и приложений. Наша команда разрабатывала “Uber” для юристов, платформу оценки соответствия продукции Технических Регламентов ЕАЭС, консалтинговую платформу и так далее. Как правило — это многопользовательские платформы, на которых участники должны взаимодействовать между собой через модерацию или напрямую друг с другом.

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

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

Именно это меня и вдохновляет в работе — создавать платформы, которые стремятся к экосистеме.

Экосистема в моем понимании — это не про наличие веб-версии, приложения и расширения для браузера. Это про решения всех вопросов данной ниши в одном сервисе.

К примеру.

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

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

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

Да, Sphinx отлично себя зарекомендовал. На данный момент я пока не сталкивался с задачами по поиску, которые он бы с блеском не решал. Но в AWS есть managed elasticsearch и нет managed sphinx, и вообще product awareness у Sphinxsearch не очень. Даже на постсоветском пространстве далеко не каждый вспомнит про него, что уж говорить о Европе / США. А зря — это реально классная, полнофункциональная, производительная альтернатива ES.

Кстати SphinxSearch прекрасен, если научиться его готовить.

Всё верно. Я это и имел в виду:
Для Graylog создаётся Elastic (вернее Graylog его создаёт и активно им управляет).
Плюс у Graylog своя обвязка вместо Kibana, Logstash и *beats.

Логи грейлог сам не доставляет, скорее грейлог это замена логстэшу и эластик кластер для грейлога создается отдельно (правда только версия эластика не выше шестерки). А так там тотже lucene query syntax для поиска.