Блог

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

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

Было бы удобно выводить в окно Output в конце компиляции время окончания. Я эту проблему для себя решил добавлением в пост билд команду PowerShell для вывода текущего времени.

С помощью компилятора .NET Native можно будет компилировать в машинный код под определенную платформу - x86 или x64 или ARM. И тут возникает вполне резонный вопрос - а где вы были раньше? 

До недавнего времени .NET хоть и был создан с возможностью поддерживать несколько платформ, но всё же официально работал только на x86 или x64 и только под Windows. Остальное поддерживалось только независимыми разработками. При таком раскладе я не понимаю, зачем Microsoft все это время компилировала .NET приложения в IL код, если никогда не планировали запускать его где-то, кроме Windows на Intel совместимых процессорах. Получается, они осознано и бессмысленно тормозили свои же программы на .NET и не получали от этого реальной выгоды.

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

Первая задачка - человек побежал через тунель и на 1/4 пути услышал гудок поезда. Известно, что если он побежит обратно, то встретит поезд на входе, а если побежит вперед, то на выходе. Вопрос, во сколько быстрее едет поезд, если все движутся с постоянной скоростью. 

Неизвестно, на каком расстоянии от входа в тунель находится поезд, да и не нужно. Главное, что человек находится на 1/4 пути. Если побежит обратно, то за эту 1/4 пути поезд как раз дойдет до входа. А если побежит в другую сторону? То через 1/4 пути человек окажется уже посередине туннеля, а поезд на входе. Включаем сложнейшие математические расчеты и смекалку и приходим к выводу, что поезд движется в два раза быстрее, ведь с этого момента за одно и то же время он пройдет весь туннель, а человек только оставшуюся половину, чтобы встретиться на выходе.

Уже шли слухи о том, что Microsoft может добавить возможность запускать приложения iOS на Windows. Пока что слухи не оправдались, но не уверен, что реальность лучше. Теперь приложения на Objective-C можно компилировать под Windows. Как вам эта новость? 

Майкрософт добавила так же возможность максимально использовать Java и C++ код написанный для Андроида. Таким образом, компания просто убивает необходимость писать код на C++ или .NET специально для Windows, на много выгоднее писать для Андроида или iOS, а потом перекомпилировать код под MS. 

В принципе, можно было бы использовать Delphi или что-то подобное, но я сторонник использовать родные инструменты. А из-за того, что у Windows Phone пока популярность слишком никакая, то специально из-за такого низкого рынка писать код особо желания нет.

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

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

Преимущество такого подхода:

Не могу говорить со 100% уверенностью, но мне кажется, что Microsoft реально пыталась создать в лице .NET слишком максимально похожим на С, чтобы его проще было учить. Но при этом они сделали большую ошибку - создавали новый язык на старых шпалах. Попытка максимально взять из C++ привела к тому, что в язык было введено много устаревших конструкций. 

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

Короче, в Swift можно писать имена переменных прямо в строке "Это значение переменной \(param)". Вот в такие круглые скобки, где перед первой скобкой стоит слэш, можно писать переменные. Это удобнее, чем указывать номера в фигурных скобках, как это делается в C или C#. Как я понял, начиная с C# 6 в фигурных скобках можно будет писать имена переменных. Больше не нужно высчитывать номера и расставлять переменные в нужно порядке, просто пишем их прямо в строке.

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

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

Смотрим на следующий пример:

Вышел новый XCode 6.3 и у меня снова не компилируется мой код. Apple внесла изменения в новый язык Swift, которые не совместимы с предыдущими версиями и приходится подправлять везде мелкие изменения. 

С одной стороны, это немного достает, что приходится обновлять исходный код под каждый чих разработчиков Swift, но с другой я понимаю, зачем это делается. Разработчики языка не могли предусмотреть всего. Язык новый и конечно же сейчас выплывают недочеты дизайна. И чтобы не ставить костыли к новому языку, его просто меняют. Да, теряется обратная совместимость, но зато язык остается чистым. 

В последнем XCode в основном поновому приходится приводить as опциональные переменные. Раньше это приходилось делать как param! as something, теперь походу param as! something. Второе выглядит получше и даже смысл немного более правильный. 

Сегодня прочитал, что у приложений на ASP.NET Core (это та версия, которая будет работать на всех ОС и за корой будущее) не будет bin директории и программы н будут компилироваться. Вы всё же сможете создать бинарный файл и публиковать его, но по умолчанию этого не нужно. 

Сейчас у Web Forms исходные файлы за aspx представлениями не обязательно компилировать. Можно вносить изменения и IIS запустит компиляцию налету. В случае с MVC контроллеры лежат в отдельной директории и их всё же приходится компилировать и это серьезная проблема для сайтов с большой нагрузкой.

Если у ASP.NET 5 Core не будет скомпилированного файла, значит исходники вынуждены будут компилироваться налету. 

Хороший ответ сегодня нашел на stakoverflow. Судя по постам это сообщение очень старое, но я на этом сайте просто бываю очень редко. Попробую перевести не дословно, а именно сохраняя смысл:

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