Блог

Сейчас с семьёй едем в Орландо в Disney World, а пока жена сидит за рулём, я решил сравнить Swift и C#. 

Меня как-то уже спрашивали несколько раз об этом сравнении, последний раз, когда я сравнил Java и .NET. В случае с Java и .NET - это целые платформы с большим количеством возможностей. При сравнении Swift и C# мы сравниваем всего лишь языки и тут можно сравнить только синтаксис. Возможности в основном зависят от того, под какую платформу пишется код. 

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

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

Логично, ведь если программист может скомпилировать в Xamarin приложение для Андроид, то почему бы не выпустить тут же вариант и для Windows Phone? Отсутствие хороших приложений называют как раз самой главной проблемой, почему платформа от последователей Билла Гейтса никак не выстрелит. 

Если к Майкрософт действительно думали так, то мне кажется это опять маркетинговый просчёт. Мне кажется, что большинство программистов все же будет продолжать писать код в своих средах разработки и приложения для iOS продолжат создавать в Xcode. Это лично моё мнение. 

Очередной раз появился слух, что Google может перейти с Java на Swift на своей мобильной платформе Android. Походу Oracle из окончательно заебали судебными издержками и возможным штрафом и проще стало перейти на другой язык.

Если Google действительно выберет Swift, то это будет серьёзный пинок в развитии и в светлом будущем для этого языка. Уверен, что программисты воспримут эту новость положительно, потому что их код из коробки будет компилироваться под две самые популярные платформы. 

Если выбрать какой-то язык типа Go или что-то новое, то понадобиться время, когда пользователи перейдут на новый язык. Даже в случае с Apple до сих пор очень много программ продолжают использовать Objective-C. К тому же, потребуется время, пока программисты выучат язык и неизвестно, понравится ли он им. 

У нас сейчас на работе очень много используют nolock опции при выполнении SELECT запросов. Эту опцию можно использовать только в самых крайних случаях и настоятельно рекомендую избежать её использование. 

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

SELECT * FROM Employee WITH (NOLOCK)

Даже если Employee таблица сейчас заблокирована кем-то, сервер все равно выполнит этот запрос и вернёт данные. 

Интересный вопрос получил по E-mail: 

Хотел бы узнать твое мнение по поводу следующего вопроса: как ты видишь свою профессиональную деятельность спустя 5-10 лет? На сколько мне известно тебе скоро будет 40 лет. Дело в том, что я со своими коллегами иногда в шутку обсуждаем, чем мы (программисты) будем заниматься после 40-ка. Многие утверждают, что к этому возрасту мозг уже не сможет работать так же эффективно, как в 25 лет, поэтому все думают что нужно либо уходить в менеджмент, либо открывать свое дело. 

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

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

Я как-то писал про существование подсказок компилятору в виде loop join, merge join или hash join, которые позволяют заставить SQL Server выбрать определённый план выполнения, об этом здесь - Подсказки оптимизатору MS SQL Serever. Я заметил, что не так уж и много народа знает о существовании этих подсказок, оно и к лучшему. В рабочем приложении нужно доверяться SQL Server ведь план выполнения может зависеть от количества данных, для малого количества лучше выполнить loop, а для большого merge. 

Допустим, что у тебя связывается две таблицы: 

Select *

From Table1 t1

 left join Table2 t2 on t1.key =t2.key

Where …..

Сейчас пытался подключиться к SQL Server Compact Edition из Visual Studio Community Edition и с удивлением узнал, что это невозможно. Сначала я решил, что проблема в отсутствующем драйвере. Я пошёл и скачал последнюю версию SQL Server CE, но программа установщик сообщила, что у меня уже все установлено. 

Я погуглил и гугля сообщил, что можно установить драйвер через NuGet. Я попробовал установить этот пакет, но и после этого в VS не появилось возможности подключаться к CE версии базы данных. 

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

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

В MS SQL Server ты можешь создавать поля типа varchar(max) и с точки зрения производительности это чуть лучше, чем text. Если размер текста в поле меньше 8k, то сервер будет пытаться сохранить его вместе с остальными данным в той же странице. Если больше 8 кило, то данные точно уйдут в отдельное хранилище, что отрицательно скажется на производительности, если массово выбирать данные. 

Обычно для запросов, которые возвращают данные для сеток или списков данных,  не нужно возвращать текстовые поля. Трудно представить себе сетку, где будет большой текст. Разве что блоги. Например, у меня запись блога состоит из двух текстовых полей - первое показывается в списке, а второе, когда вы открываете саму статью. Не знаю как MySQL, но в MS SQL Server эти текстовые поля притормаживали бы запросы. 

За счёт того, что я показываю на блоге записи постранично, максимум 10 записей на странице, то потри не смертельны, но на нагрузке на сервер это все же сказывается. Для сайтов с большим трафиком я бы все же сделал поле Intro, которое у меня отображается в списке не текстовым, а varchar. 1000 символов должно хватить с головой. Главное не выполнять запросов типа SELECT *, но к сожалению этим грешат многие программисты. Да и я сам такой же.

Недавно был на встрече с новым клиентом и обсуждали вопрос строительства сайта. Ребята явно хорошо разбираются в HTML, в фронтенде, но вот на заднем плане у них явные проблемы. Вместо того, чтобы сказать - "мы напишем для вас все, что угодно", их ответ был - "Мы не пишем проекты, мы найдём готовый OpenSource проект и прикрутим его к вашему сайту". Причем за свою работу они просят достаточно большие деньги. 

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

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