Блог

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

Мне кажется, что людей путает выражение "HTML код". Ведь на самом деле это не код, а специальные теги форматирования. HTML в чистом виде не является языком программирования, это стандарт разметки документов. А за логику отвечают совершенно другие языки, например JS, PHP и другие. 

Вот интересно, почему стали говорить HTML код? Хотя как можно скзать по другому, чтобы звучало и отражало реальную суть языка. А можно ли называть HTML языком? Столько вопросов в голове пролетело. Это вопросы так, чисто потрындеть. У меня есть свое мнение, но оно мое. Правильно ли говорить "писать программу на HTML", ведь ее пишут на JS? JS является ли частью HTML? Мне кажется в HTML5 он стал частью.

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

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

Пример такого косяка можно увидеть например на странице Rachel McAdams. Кто знает, может есть какой-то у fb:like параметр, который заставит возвращать одинаковые значения вне зависимости - имееть пользователь активную сессию на сайте или нет. 

На сайте Heapar я выкладываю свои компоненты. Давно не было времени обновить, но вот нашел пару часиков и немного изменил компонент Grid и добавил его исходник к Heapar Essential Library .NET. Качайте, используйте, изменяйте. Полные исходные коды в архиве. Постараюсь найти время и обновить и подправить остальные компоненты. 

Очень часто приходится создавать формы (в классическом программировании) и представления (в web программировании) для редактирования и добавления чего-либо. Очень прошу тех, кто любит создавать отдельные формы/представления для каждой из этих операций - не делайте этого. Я не встречался еще с ситуацией, когда это действительно было полезно. Всегда разделяйте один и тот же код для редактирования и добавления.

Достаточно завести какое-то свойство, которое будет хранить ID текущей записи. если свойство равно нулю или NULL, то это форма добавления и можете спрятать какие-то поля, которые не имеет смысла или нельзя изменять при добавлении. Если поле не нулевое, то это редактирование. При сохранении достаточно проверить это свойство/параметр формы и заменять Insert на Update. 

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

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

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

Но разные действия стоят разных поинтов. Например, если я просто посмотрел товар на сайте, то можно дать 1 поинт, а если я его положил в карзину, то 5, а если еще и купил, то 10.

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

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

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

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

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

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

У меня на работе сервер базы данных занят в нормальные часы не более чем на 20%, а в пики нагрузки не более 50%. Это такие редкие дни и часы, когда процессор напрягается так сильно, что я уже и не помню, когда последний раз это было. 

В пятницу перед уходом с работы проверяю нагрузку сервера, а у меня там от 30% до 50%, причем большую часть времени под 50%. Ну я оставил сервак в покое, не хотел напрягать мозг на выходных. Сегодня пришел на работу, проверил индексы, изменил один индекс, чтобы он включал в себя все необходимое, и нагрузка снова упала до 20%. 

Один запрос с одним неоптимизированным индексом смог поднять нагрузку на процессор в два раза. 

Интересный вопрос поступил в студию:

в методе класса лучше обращаться к полям этого класса или к свойствам(инкапсулирующим эти поля)? Или зависит от ситуации, допустим в свойстве есть какая-то проверка, тогда через свойство. Если нет проверок, то через поле по идее будет работать быстрее.

Был как-то почти такой вопрос - почему, я против прямого доступа к переменным объекта и я отвечал в комментариях. Сегодня решил ответить в отдельной заметке, чтобы потом проще было находить и ссылаться. В вопросе кроется и ответ - доступ к переменным должен осуществляться ТОЛЬКО через свойства. Никогда не должно быть прямого доступа, даже если вы не делаете никаких проверок. Я понимаю, что впадлу писать get/set и для таких случаев в C# есть офигенная конструкция:

Я уже однажды восхищался именованием переменных индусами в заметке ERP система глазами программиста. Сейчас по работе расширяю один Web сервис, который позволяет обмениваться данными со сторонней конторой. Два года назад мы написали им спецификацию и в ней имена переменных были вполне нормальными: AddressLine1, City, Province, PostalCode... Клиенту понадобилось расширить сервис и передавать еще и данные о пользователе. 

Не знаю почему, но на этот раз отдали работу над сервисом индусам. Казалось бы. всего лишь добавить несколько полей не такая проблема. Но эти красавцы умудрились назвать поля LastNm, FrstNm, BrthDt, EMailAdrTxt. Блин, ну неужели так сложно назвать нормально имена полей - LastName, FirstName... Удивило поле EMailAdrTxt своим Txt на конце. У них email адрес может быть не Txt? Нехило обрадовало поле BrthDt, потому что его передают в виде текста. В Индии наверно не знают, что существует такой тип данных как DateTime и он позволяет решить проблемы с ошибками неправильного ввода даты.