Блог

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

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

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

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

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

Я как-то писал про существование подсказок компилятору в виде 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 …..

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

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

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

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

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

SELECT * FROM Employee WITH (NOLOCK)

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

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

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

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

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

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

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

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

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

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

Когда-то давным давно мне в журнале Хакер дали задание написать про SOAP. Я начал исследование и меня поразило, как же сложно все описывают эту тему. Большое количество заумных слов, особенно в статьях от IBM. Я попытался максимально упростить тогда свою статью про Web сервисы и SOAP, но сейчас я решил ещё раз вернуться к этой теме и ещё раз попробовать описать Web сервисы, так сказать много лет спустя. 

Что такое SOAP? Это сокращение расшифровывается как Simple Object Access Protocol, что на великий и могучий язык можно повести как Простой Протокол Доступа к Объектам. И он действительно простой. 

Если читать документацию IBM по сервисам, то там обязательно будут заумные вещи типа общей шины, какая-то ещё херня, но все это просто заумные слова, потому что на самом деле Web сервисы очень простые в использовании. 

Запрос к Web сервису в самом простом случае поставляет из себя банальный HTTP запрос, с таким же заголовком и с такими же параметрами, как и у любого другого запроса к любым другим страницам сайта. У Microsoft сервисы могут работать по TCP для увеличения скорости, но это отдельная история, потому что сейчас мы затрагиваем SOAP – классику, с которой кажется и начинались все эти веб сервисы. 

В очередной раз получил вопрос о том, какой язык выбрать. Я из получаю регулярно, но тут автор письма спросил конкретно - C# или Java. 

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

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