Comments / Profile of tenbits / Habr

Александр Десятьбитов @tenbits

User

Общение скриптов из разных вкладок браузера

tenbits Feb 18 2015 at 09:38

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

Пишем с нуля квест на ASP.NET 5 (vNext) и Angular.js

tenbits Feb 13 2015 at 16:01

> Буду ли миграции работать с nuget manager console, а не с обычной консоли как сейчас?
Так оно и сейчас работает через nuget консоль. Начиная с EF 6.0 так точно. Пишем «Add-Migration», «Update-database»: всё создает, всё обновляет.

Раскол nodejs

tenbits Dec 4 2014 at 21:27

Всё будет в порядке, ребята вот во всю новую страницу пилят: preview.npmjs.com/.

Технологии IBM помогли усовершенствовать производство лыж и сами лыжи

tenbits Dec 3 2014 at 21:39

Короткое видео по сабжу

Youtube

Cобрать лучшее из двух миров — фреймворков и CMS (часть 1)

tenbits Nov 28 2014 at 12:01

Размер табов на github вполне можно настраивать через ?ts=2 query; ребятам нужно лишь это начать поддерживать например в .gitattributes.

О прикладных аспектах управления людьми в организации или причем тут дети?

tenbits Nov 9 2014 at 16:37

Человек всегда делает только то что хочет. Не стыковка желаний и поведения — это глубокое заблуждение. И относится это не только к работе, а ко всей жизнедеятельности человека. Здесь уместно говорить о не стыковке желаний, поэтому очень важно научится управлять своими желаниями, которые в свою очередь формируются из знаний → убеждений → опыта → мировозрения/моральных ценностей. Но в любом случае, **всегда** более сильные желания побеждают.

А если работа кормит семью, то очень глупо не любить её! И каждодневное состояние «не люблю — но хожу» просто сжигает человека.

-1

Что такое холакратия и почему она вам не нужна

tenbits Oct 24 2014 at 00:31

Спасибо, было интересно почитать, продолжил поиск и наткнулся на ещё одно интересное объяснение как-работает-холократия с примером «конституции».

[Перевод] Проблема конструкторов JavaScript и три способа её решения

tenbits Sep 25 2014 at 19:31

Это они там только предлагают это как «шорткат», но это ни в коем случае, также как и с jQuery, не отменяет того что у фабрик должны быть фабричные методы :) Просто jQuery, стандартный API могут вводить некоторые послабления в угоду краткости, так как всем в принципе известно их поведение, а вот если я пишу код для себя и коллег, то тут следует быть более конкретным. А штуки как «самовызывающий конструктор» скрывает от «читателя» свое поведение, поэтому данный трюк считаю даже немного вредным.

[Перевод] Проблема конструкторов JavaScript и три способа её решения

tenbits Sep 25 2014 at 17:20

В этом-то и заключается выразительность кода. Каждое название метода, что-то да обозначает, `resolve`, например, больше значит, что создание объекта зависит от внешних факторов, тогда как `create` действует внутри по строгому алгоритму без внешних параметров.
Далее; у вас `Dict` изначально был функциональным/фабричным методом, а назван существительным. И тут совсем уж не понятно, что он делает — создаёт объект Dict, так почему без new, а если не создает Dict, тогда что же создает; а может вообще ничего не создает, а мутирует аргумент. Вообщем, со стороны возникает много вопросов.

Более того, система была бы более гибкой, сами же видите, что у вас бы возникли проблемы с созданием через конструктор (если бы не хак). Поэтому используя `Dict.create`, например, можно было бы смело сделать создание через конструктор, не боясь поломать обратную совместимость.

В любом случае, это лишь мое мнение, и я вовсе не хочу вам его навязывать; лишь поделился размышлениями.

[Перевод] Проблема конструкторов JavaScript и три способа её решения

tenbits Sep 25 2014 at 13:14

Странные проблемы:
— Фабрика должна создавать и проводить другие операции над обьектами через статические методы: `Dict.create` `Dict.resolve` и так далее. Это более гибкое и явное поведение. А если уж там что то себе передумали в архитектуре и захотели убрать фабрику, то да, нужно перелопачивать код. Даже с простым рефакторингом нужно перелопачивать код, а уж с архитектурой тем более нужно.

— `array.map(x => new MyConstructor(x))` всё же лучше — кода не больше, поведение явное, нет зависимостей от стороннего АПИ в прототипах.

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 24 2014 at 17:04

Также можно, правда `append` нужно сделать мутатором, что кстати и используется в «transducers.js», а иначе, если на каждом шагу создавать новый массив через `concat`, то о никакой производительности на коллекциях даже в тысячу элементов говорить никак нельзя.

function take(n) {
    return function(step) {
        var count = 0;
        return function(result, item) {
            if (++count < n)
                return step(result, item);
            else if (count === n)
                step(result, item);
        }
    }
}
function append(ctx, x) {
    ctx.push(x);
    return ctx;
}

Конечно же с `Reduced` у нас больше возможностей. Для подхода с дополнительными классами такое поведения — это самая нижняя планка, а вот для `void 0` — это максимум, что мы можем выжать. Но нужно ли вводить дополнительные классы/обьекты, если вполне пригодно можно обойтись без них? Хотя этот вопрос спекулятивный, так же как и ваше предложение мне изучить, что такое state.

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 24 2014 at 14:02

Постойте, сам хоть кто-то попробовал подставить `void 0`? Дружно открываем devtools и копируем:

Код

var array = [1, 2, 3, 4, 5, 6, 7];
(function() {
    var i = 0;
    function reduce(coll, fn, seed) {
        var result = seed;
        for (; i < coll.length; i++) {
            result = fn(result, coll[i]);
            if (Reduced.isReduced(result)) {
                return result.unwrap();
            }
        }
        return result;
    }
    function Reduced(wrapped) {
        this._wrapped = wrapped;
    }
    Reduced.prototype.unwrap = function() {
        return this._wrapped;
    }
    Reduced.isReduced = function(obj) {
        return (obj instanceof Reduced);
    }
    function take(n) {
        return function(step) {
            var count = 0;
            return function(result, item) {
                if (count++ < n) {
                    return step(result, item);
                } else {
                    return new Reduced(result);
                }
            }
        }
    }
    var first5T = take(5);
    var result = reduce(array, first5T(append), []);
    console.log('> Reduced. Loops: %d Result: ', ++i, result);
}());

(function() {
    var i = 0;
    function reduce(coll, fn, ctx) {
        var prev = ctx;
        for (; i < coll.length; i++) {
            ctx = fn(ctx, coll[i]);
            if (ctx === void 0) 
                return prev;
            prev = ctx;
        }
        return ctx;
    }
    function take(n) {
        return function(step) {
            var count = 0;
            return function(result, item) {
                if (count++ < n) 
                    return step(result, item);
            }
        }
    }
    var first5T = take(5);
    var result = reduce(array, first5T(append), []);
    console.log('> Void 0. Loops: %d Result: ', ++i, result);
}());

function append(ctx, x) {
    return ctx.concat([x]);
}

[Перевод] Проблема конструкторов JavaScript и три способа её решения

tenbits Sep 24 2014 at 11:57

4ый способ: jshint(newcap), unit-tests и, как сказали, «use strict» — при таком наборе пропустить `new` просто невозможно, при этом нет хаков в конструкторах. Ну а использование `new` по назначению повышает выразительность кода.

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 20:32

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

> А вот хранение результата где-то в вызывающей функции

Результат хранится в рамках одной функции, и лишь хранит ссылку на `current`/`next` значения, поэтому это состоянием назвать нельзя, так как обычно подразумевается, что состояние находится в системе (между некоторыми функциями/библиотеками/запросами). И вот когда мы создаем какой-то объект который содержит значение системы (в данном случае `reduced/notReduced`) и передает другим элементам системы — вот это и есть State. А то, что наш `runner` заканчивает работу при `void 0` — так это лишь поведение. `void 0` не содержит в себе никакого значения, поэтому и состоянием быть не может. Хотя тут можно философствовать, что «отсутствие состояния — является состоянием» )

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 18:13

Больше чем с `Reduced` мы не обработаем, в случае с прерыванием `Reduced` и `void 0` — эквивалентны. Там где мы возвращаем `new Reduced` мы можем вообще ничего не возвращать, поэтому там тот `else` просто удаляется, а там где у нас `isReduced` появится `=== void 0`. как то так

-2

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 18:06

Ещё раз, `void 0 / undefined` — это отсутствие какого либо значение, а `null / false / Symbol / Reduced ` — это какое-то значение. В javascript это существенная разница. И учитывая, что нашa runner-функция ожидает `nextValue`, то вполне логично если она ничего не получила, тут же прервёт итерацию и вернёт `currentValue`.
Ещё одним недостатком `Reduced/Symbol` является то, что мы в систему добавляем новый апи, это значит, что наша `take` функция становится зависимой от `Reduced/Symbol`. Сами понимаете чем это чревато, а вот в случае с `void 0` — это лишь вопрос поведения.

В дополнение, `Reduced` вносит State в систему, поэтому я бы не назвал это чистым подходом. Чем меньше состояний тем лучше.

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 15:57

Фишка `void 0` в том что это даже не значение. Функция может абсолютно ничего не возвращать и это уже будет `result === void 0`. Таким образом не нужно вводить дополнительную «обёртку» `Reduce`, и не нужно каждый раз вызывать instanceof. На коллекциях в миллион элементов это будет существенным улучшением.

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 15:23

Но мы же можем на нужном шаге вернуть `void 0`, тем самым сообщив нашему итератору, что нужно завершить работу и вернуть коллекцию из предыдущего шага.
/cc mayorovp

Трансдьюсеры в JavaScript. Часть вторая

tenbits Sep 23 2014 at 15:09

Странно, вместо конструкции `Reduced` можно же реализовать `take/limit` на подобии `filter`. Или я что-то упустил?
Ну a интерфейс функций для преобразователей нужно взять аналогичный стандартному `reduce`: `([[CurrentCtx]],[[Item]], [[Accessor]],[[RootCtx]], )`, где `Accessor` это индекс (в случае итерации по массиву).

Трансдьюсеры в JavaScript. Часть первая

tenbits Sep 22 2014 at 18:16

Через Pipelines можно достичь того же результата, плюс меньше кода и менее запутанно:

Код

var addOne    = (ctx, x, next) => next(x + 1),
    lessThan4 = (ctx, x, next) => x < 4 && next(x),
    append    = (ctx, x)  => ctx.push(x);

console.log(test(addOne, lessThan4, append));
console.log(test(lessThan4, addOne, append));

// test
function test(...fns) {
    return [1, 2, 3, 4].reduce(runner(fns), [])
}
// implementation
function runner(fns){
    return function(ctx, x){
        var i = -1;
        function next(x){
            if (++i < fns.length)
                fns[i](ctx, x, next);
        }
        next(x);
        return ctx;
    };
}

1 2 3 4 5

7 8 ...

15 16