Пару дней назад я наткнулся на первую статью из этой серии уроков. К сожалению, переведены только начальные уроки, а все самое интересное (SSAO, PBR, тени) только впереди. Этот курс переводили три человека (теперь четыре), и я надеюсь, что кто-то из читателей поможет с переводом остальных частей. К сожалению, я не являюсь профессиональным переводчиком, по этом в тексте могут быть ошибки разного характера. Буду рад, если вы сообщите о них. Приятного чтения!
float FastInvSqrt(float x) {
float xhalf = 0.5f * x;
int i = *(int*)&x; // представим биты float в виде целого числа
i = 0x5f3759df - (i >> 1); // какого черта здесь происходит ?
x = *(float*)&i;
x = x*(1.5f-(xhalf*x*x));
return x;
}
UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.
Простой код на Java: generic интерфейс, класс который его реализует, и метод, принимающий его экземпляр:
//Gen.java:
public interface Gen<A> {
A value();
}
//GenInt.java:
public class GenInt implements Gen<Integer> {
private final int i;
public GenInt(int i) {
this.i = i;
}
@Override
public Integer value() {
return i;
}
}
//GenTest.java:
public class GenTest {
public static <A extends Gen<T>, T> T test(A a) {
return a.value();
}
public static void main(String[] argv) {
GenInt g = new GenInt(42);
Integer i = test(g);
}
}Он компилируется и даже запускается. Как вы думаете, что будет, если вам захочется вызывать метод test из Scala?
object TestFail extends App {
val genInt = new GenInt(42)
val i = GenTest.test(genInt)
}
Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).
Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.
Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?
Ответ на этот вопрос даёт мутационное тестирование.
Недавно на ресурсе Medium были опубликованы две статьи от одного и того же автора, затрагивающие функциональность C# async/await.
Основными выводами были:
Но главная проблема вышеприведенных публикаций — абсолютное непонимание модели кооперативной многозадачности в C# с вводом читателей в заблуждение. Сами же бенчмарки — бессмысленные, как мы увидим позже.
Далее в статье я попытаюсь раскрыть суть проблемы более подробно с примерами решения.
После небольшой правки кода исходных примеров, реализация бенчмарка на .NET оказывается быстрее варианта Go. Попутно решаем проблему переполнения стека у рекурсивных асинхронных методов.
NB: использоваться будут свежевыпущенный .NET Core 2.0 и Go 1.8.3.
