Pull to refresh

Comments 31

Не пробовали не подарками брать, а просто сделать цены нормальные, в смысле низкие? А то подарок — подарком, скидка — скидкой, но это «расходы на маркетинг», если вдуматься, (на вид — так будто бы десятикратно) заложены в какой-то другой из товаров.
пробовали, конечно, но гораздо выгоднее впаривать мусор по тройной цене, чем нормальный товар по нормальной цене. Во втором случае вы очень быстро разоритесь.
А Вы статью-то прочитали? Она совсем не об этом…
Статья интересная, спасибо! Получается, что система фактически была написана одним человеком (90% кода)? В итоге успели ли в срок? Как изменилась архитектура системы после переработки?
В срок успели. Там просто не было других опций :) Архитектура системы после переработки изменилась кардинально. В первой версии системы она фактически отсутствовала (опять же, из-за сроков и отсутствия опции «перенести запуск на более позднюю дату»), а после переработки была выстроена не просто на основании теоретических предположений типа «как там будет система жить с учетом увеличение нагрузки», а на основании практического опыта эксплуатации. Думаю, именно поэтому до сих пор, несмотря на то, что прошло уже немало времени, потребности в очередном архитектурном апгрейде я не вижу. Хотя… кто его знает, что там будет дальше.
Спасибо за статью. А на чем сам веб-сервис писали и какой протокол использовали/используете? SOAP или что-то другое?
Веб-сервис написан на ASP Classic (это который был до ASP.NET). Протокол обмена — кастомный XML/JSON (поддерживаются оба формата). Живет еще даже один legacy REST-интерфейс. SOAP не люблю — очень много лишнего (и, при этом, строго обязательного!) в нем.
Можно спросить про финансовую часть вопроса (точнее, про распределение денег и ответственность)? Ведь проект касался не только запуска, но эксплуатации.
Судя по тому, как вы подошли к проектированию, вы были заинтересованы в создании надежного решения.

Эксплуатация осуществлялась командой из всего двух человек (я и еще один сотрудник), поэтому, Вы абсолютно правы, я был очень заинтересован в создании реально надёжного решения. Финансовая ответственность распределялась очень просто — упомянутая «команда поддержки» отвечала за все косяки своей зарплатой. Причем под «поддержкой» понималось все от доработки программного решения под новые хотелки заказчика до решения проблем с сетевым оборудованием.

Эксплуатация осуществлялась командой из всего двух человек (я и еще один сотрудник)


Из-за этого часто в Мвидео случаются случаи использования купонов на 100% от стоимости?)
Как раз наоборот. Процент скидки рассчитывается в других системах. Если бы они сами и схема их поддержки были бы устроены так, как я описал, проблем, о которых Вы говорите, было бы на порядок меньше.
Интересная статья, отдельное спасибо за информацию про обновление скриптов, не задумывался раньше о таком полезном свойстве, думаю может пригодиться в одном из проектов.
> Можно обновлять веб-приложение без перезапуска веб-сервера и, соответственно, без перерыва в обслуживании.

У вас же 2 сервера, отключение одного приводит к перерывам в обслуживании?

> Вы можете писать .NET-код на мобильном телефоне? А прекомпилировать его на том же телефоне сможете?

А вы можете классический ASP запустить на мобильном телефоне? А зачем тогда? А где вы работоспособность проверяете, на продакшене? А скомпилировать вот там, где вы работоспособность проверяете можно?

И в чем именно преимущество то? Ну то есть, я никогда не ощущал потребности такой, но… На мобильном есть блокнот, и вроде есть клиенты даже под git, и, тем более ftp.
(Но, главное, там есть клиент для RDP)

> Общая «легковесность» приложения. Исходники ничего не весят. Их можно закачать на сервер практически по любому, даже самому медленному каналу связи.

Вот тоже не понял преимущества. Исходники ASP.Net больше весят?
Или бинарники в .net много весят? Ну, хоть больше? На сколько?
1. Вы невнимательно читали. Два сервера как раз для того и были организованы, чтобы отключение одного НЕ приводило к перерыву в обслуживании.

2. Опять невнимательно читали. Зачем запускать ASP-код на мобильном телефоне? Мне нужно было его на мобильном телефоне редактировать и выводить в продуктив. Это гораздо проще делать, если приложение написано на ASP Classic нежели на ASP.NET. Плюс вы не забывайте, что в те времена, когда создавался этот продукт, на мобильных телефонах не было возможности запустить RDP-клиент. С RDP-клиентом каждый сможет делать все что угодно, ясен пень.

3. Вам сколько лет вообще? Вы когда-нибудь пробовали что-нибудь скачивать/закачивать по dial-up модему или 1G/2G мобильному интернету при постоянно пропадающем сигнале? Или кроме выделенки и «вайфая» ничего не пробовали? А вот если бы попробовали, то сразу поняли бы разницу в весе приложений ASP Classic и ASP.NET.

Общее пожелание — смотрите на мир шире :) Как в части технологий, так и в части времени. До нас уже много чего сделано и не все из этого «безнадежно устарело».
> 1. Вы невнимательно читали. Два сервера как раз для того и были организованы, чтобы отключение одного НЕ приводило к перерыву в обслуживании.

Так и в чем преимущество тогда? Обновляете сервера по одному, и нет перерывов.

> Это гораздо проще делать, если приложение написано на ASP Classic нежели на ASP.NET.

Вы эту мантру повторяете, а чем именно проще — не понятно. На мобильном телефоне редактировать вообще не проще.

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

Как минимум, в марте 2007 он уже был (тыц). VNC был ещё раньше.

> А вот если бы попробовали, то сразу поняли бы разницу в весе приложений ASP Classic и ASP.NET.

Я пробовал с 1997 года. Лучше меньше пафоса и больше конкретики — на сколько больше, в процентах, в килобайтах?

> До нас уже много чего сделано и не все из этого «безнадежно устарело».

Да хоть на Cobol. Только преимущества не надо надуманные показывать.
1. Выкатка в прод обновлений для приложения ASP Classic занимает меньше времени по сравнению с ASP.NET и сами изменения весят меньше при одинаковом функциональном наполнении.

2. У меня в 2008-м не было смартфона, на котором можно было бы запускать RDP-клиент. VNC на смартфоне я не видел ни разу. Что толку от того, что в принципе тогда подобные вещи, как вы пишите, уже существовали. В Калифорнии уже сейчас ездят на Tesla. А Вы ездите?

3. А какая разница на сколько конкретно килобайт меньше весит код ASP Classic? Достаточно, чтобы это почувствовать при закачке через 2G. В условиях ограниченных скоростей каналов связи любой выигрыш объеме данных — победа. Или Вы пытаетесь сказать, что код ASP.NET весит меньше чем ASP Classic?
> 1. Выкатка в прод обновлений для приложения ASP Classic занимает меньше времени по сравнению с ASP.NET

А выкатку вы не автоматизировали?

> А Вы ездите?

Ну, подходящий смартфон у меня в 2007 был. Выбирать платформу на следующие 10 лет, на основании того, что телефон пока старенький — это такое себе.

> Или Вы пытаетесь сказать, что код ASP.NET весит меньше чем ASP Classic?

Это вы пытаетесь что-то доказать (голословно, впрочем). Я бы лил diff, или измененные файлы — это несколько килобайт и вообще без разницы через какой канал. Ну, не повод для выбора платформы.

Ну то есть я вообще не понимаю зачем выбирать платформу на 10 лет вперед под редактирование файлов на телефоне (который ещё и не смартфон!) для заливки по 2G (в 2007 году, когда выделенки уже везде, а 3G начали разворачивать).

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

У вас старый телефон и старая платформа просто потому, что… вы решили не брать новый телефон с 3G?

Преимуществ дотнета я в Ваших комментариях тоже не увидел. Пока я вижу только то, что на Ваш вкус дотнет лучше. А о вкусах можно спорить вечно...

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

Это не вопрос вкусов. И это претензия к тексту, а не к классическому ASP.
А можно было и на Java написать систему, и на C++, и еще на чем-нибудь. Если нормально написать, всяко будет работать хорошо. Я в статье описал успешный кейс от принятия решений до реализации и последующей эксплуатации. А Вы мне пытаетесь доказать, что принятые решения не обоснованы, и можно было написать на ASP.NET. А почему именно ASP.NET? Почему не Python? Месседж Ваш какой? Мой месседж — хорошую систему можно написать на чем угодно, главное голову включать. О технологиях спорят либо те, кто их продает, либо те, кто не знает ничего, кроме технологий :)
Серьёзно, Вы спрашиваете у меня почему у Вас в тексте ASP.NET?

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

Вы предлагаете сейчас брать ASP? Нет? Тогда нужна методология, позволяющая выбрать путь сейчас, в других условиях. Придумывание, в оправдание выбора, недостатков у других технологий тут не поможет.

А вот при отсутствии архитектуры (включая, как выясняется, и выбор платформы) — голову никто особо не включал. Можно написать работоспособную систему методом «фигак-фигак и в продакшен»? Можно.

Но необходимость что-то править с мобильника на выходных не говорит об успешности кейса, и тем более не говорит о «нормально написано».
Так в том-то и дело, что единой методологии не существует эффективной. Каждый кейс уникален и только с такой точки зрения и должен рассматриваться для выбора эффективного решения. В статье об этом тоже написано (вынужден уже в 3-й раз акцентировать Ваше внимание на том, что, как бы, уже должно быть прочитано). «Дайте методологию» — подход менеджеров. Да и то не всех, а тех, кто не хочет углубляться в то, что он менеджерит.
> Так в том-то и дело, что единой методологии не существует эффективной.

1) Зачем и о чем вы тогда пишите?
2) Вы отрицаете существование эффективных методологий? Зачем вы передергиваете?

> Каждый кейс уникален и только с такой точки зрения и должен рассматриваться для выбора эффективного решения.

Каждое дерево уникально, это не мешает из них эффективно зубочистки нарезать. Простите, но сервис по гашению подарочных карточек — это давно не rocket science.

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

лолшто?

Ладно, давайте заменим слово «методология» на «алгоритм». Или «паттерн».

Повторю, на всякий случай, вопрос: Зачем и о чем вы тогда пишите? Что общественности делать с вашим кейсом, если «каждый кейс уникален»? Взять себя в руки и пойти изобретать велосипеды? Восхититься, что вы смогли сервис накодить?
Восхититься — это, извините, похоже, Ваш мотиватор. Мне не нужно чье-то восхищение. Вы так основательно пытаетесь мне что-то доказать, что я даже завидую Вашему упорству. Мне бы надоело уже, честное слово :) Я пишу статью для того, чтобы поделиться опытом. Если Вам такой опыт неинтересен или вы не согласны со мной, проходите мимо. Вы пишите комментарии потому, что хотите выпендриться. Вам хочется, чтобы кто-то, кто прочитает наш «диалог» здесь, сказал бы: «Да, вот это классный парень! Он-то знает, как разрабатывать правильные приложения!» Я почитал Ваши комментарии к другим статьям. Они все точно в такой же стилистике. Я уже начинаю подозревать, что Вы что-то продаете и пиаритесь таким образом :) Только я пока не понял, что…
Т.е. вы решили не отвечать «зачем вы это пишите» («поделиться опытом» — это не «зачем»), а перейти на личности? Ну ок, дискуссию о разработке правильных приложений можно дальше не продолжать.
Вы на Хабре написали 1,7 тыс. комментариев и ни одной (!) статьи. У Вас комментомания или Вы только так можете выражать свои мысли?
Вы не ответили по делу ни на один мой вопрос. Вам по сути статьи ответить нечего, но поговорить хочется, в вы решили кащенита включить? Вам не кажется такой приём устаревшим лет на 15? Ах, да, кого я спрашиваю…
Нашу беседу завершаем. Она абсолютно не конструктивна. Идите еще что-нибудь прокомментируйте. Статей на Хабре много.
Спасибо за статью.
Подскажите, присутствовали особенности поведения покупателей помимо «пик держался с 12 до 14 часов 8 марта».
Присутствовали. Например, покупали товары из определенной группы, на которую действовала акция. Но влияния на техническую сторону вопроса это не оказало.
Sign up to leave a comment.