• Новый REST API Яндекс.Диска и Полигон. А также зачем Диску ещё один API и как мы его делали
    0
    Добрый день! Изучаю API Диска на предмет показа внутри своей веб-системы потокового видео с диска. Вижу, что ваш веб-клиент использует некое, судя по адресам, публичное API, например, yadi.sk/public-api-desktop/get-video-streams. Но не могу найти документацию на него. Есть ли она?

    Или может быть все-таки есть некий способ сделать встраиваемый виджет для видео с Я.Диска?
  • Управление релизами в Visual Studio 2013
    0
    эту проблему решил, добавив пользователя с именем SRV-1-1\Administrator в список пользователя в настройках Release Management.

    теперь другая проблема: Deploy Agent не хочет подключаться к Server. причем установка Агента прошла успешно, видимо он сумел обратиться к Серверу в процессе этого.
    Но на Клиенте функция Scan не работает, и добавление вручную Агента по IP тоже не приводит к его обнаружению (= статус Offline).

    может потому, что я добавляю не доменным именем, а по IP? агент стоит на сервере, который не в домене. это вообще поддерживается?
  • Управление релизами в Visual Studio 2013
    0
    Коллеги, а с кем можно пообщаться по поводу решения проблем при установке?

    У меня Microsoft Deployment Agent не может подключиться к Release Management Server. Первый на сервере из живой площадки, не в домене, а второй в офисе, в домене.

    Вся диагностическая информация от агента:

    V, 2014/01/23, 01:22:49.324, Created Nt account for user Administrator
    V, 2014/01/23, 01:22:49.324, Found Sid S-1-5-21-3719844311-4177430663-3684011079-500 for user Administrator
    V, 2014/01/23, 01:22:49.324, Is Administrator network service account? False 
    V, 2014/01/23, 01:22:49.324, Created Nt account for user Administrator
    V, 2014/01/23, 01:22:49.324, Found Sid S-1-5-21-3719844311-4177430663-3684011079-500 for user Administrator
    V, 2014/01/23, 01:22:49.324, Is Administrator local system account? False 
    V, 2014/01/23, 01:22:49.324, Domain: 
    V, 2014/01/23, 01:22:49.324, Final UserName: SRV-1-1\Administrator.
    V, 2014/01/23, 01:22:49.324, Loading account details for SRV-1-1\Administrator
    V, 2014/01/23, 01:22:49.324, Is SRV-1-1\Administrator local machine account? True 
    I, 2014/01/23, 01:22:49.324, Normalized account is SRV-1-1\Administrator and Sid is S-1-5-21-3719844311-4177430663-3684011079-500
    I, 2014/01/23, 01:22:49.340, Validating account to use as identity for Release Management Services...
    I, 2014/01/23, 01:22:49.340, IsAdminAccount : Trying to determine if the account : SRV-1-1\Administrator is an admin on the local machine
    I, 2014/01/23, 01:22:49.355, IsAdminAccount : Trying to determine if the account : SRV-1-1\Administrator is an admin on the local machine
    I, 2014/01/23, 01:22:49.355, User SRV-1-1\Administrator is system, Admin 
    I, 2014/01/23, 01:22:49.355, Validated account to use as identity for Release Management Services.
    I, 2014/01/23, 01:22:49.355, Validating Release Management Server for Team Foundation Server 2013...
    E, 2014/01/23, 01:22:49.527, Received Exception : Microsoft.TeamFoundation.Release.CommonConfiguration.ConfigurationException: Failed to validate Release Management Server for Team Foundation Server 2013.
       at Microsoft.TeamFoundation.Release.CommonConfiguration.DeployerConfigurationManager.ValidateServerUrl()
       at Microsoft.TeamFoundation.Release.CommonConfiguration.DeployerConfigurationManager.ValidateAndConfigure(DeployerConfigUpdatePack updatePack, DelegateStatusUpdate statusListener)
       at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
    I, 2014/01/23, 01:22:49.527, Work completed for GetConfiguration() call : got out of turn error
    E, 2014/01/23, 01:22:49.527, Failed to validate Release Management Server for Team Foundation Server 2013.
    
  • Будущее C#
    +5
    объектно-ориентированность и функциональщина — не альтернативы друг другу, а ортогональные понятия. так что «ухода» от одного к другому быть не может
  • Прелюдия или как полюбить Haskell
    0
    можете объяснить, почему не оптимизируется, или почему ему и не надо?
  • Java навсегда! 12 причин длительного доминирования Java
    0
    Конечно, я и не говорил, что это правильное определение. Я написал то, что должно было заинтересовать человека из мира Явы, не знакомого с такой концепцией вовсе. А уж с деталями он разберется, если откроет первую же статью по теме.
  • Java навсегда! 12 причин длительного доминирования Java
    0
    В данном контексте под структурой понимается тип, хранящийся в стеке. Т.е. «такой же» как int, только пользовательский.

  • В C# с типами все в порядке
    0
    Так или иначе, но в одной из библиотек из той таблицы именно так и сделано. Есть метод Match, который обязывает обработать оба варианта, и только через него можно получить внутреннее значение. Честно, по-пацански по-монадически.
  • В C# с типами все в порядке
    –1
    1. Как новичок, увидев вместо User MaybeUser я бы либо спросил у старшего, что это и как пользоваться, либо недюжинным мозговым усилием перевел слово Maybe на русский и догадался, что стоит сперва проверить на наличие значения.

    2. А вот на кодревью скажут написать не так, как автор предложил, а что-то вроде такого:

    FindUser(1)
        .Where(u => u.LastName == "Иванов")
        .Match(GreetUser, orElse: LaunchMissiles)
    
  • В C# с типами все в порядке
    +1
    если вам это так не нравится, то следует выбрать другой язык.

    Абсолютно не следует, на то C# и мультипарадигменный язык.

    Я бы хотел больше ФП-шности в нем, но не перехожу на F# или Haskell почему-то. Вам, возможно, арифметики указателей не хватает, и все же вы тоже не ушли в C.

    Допустимы разные стили в рамках одного языка, только и всего. Вполне может быть, что для кого-то ваши «много классных штук» будут находиться в нерекомендуемом подмножестве языка. Как те же ref и out.
  • В C# с типами все в порядке
    0
    Переводить же все баги в разряд скрытых и трудноотлавливаемых — это как лгать самому себе.

    Чистая правда, и ведь это именно NullReference таким и является, ведь он возникает отложенно (т.е. не там, где истинная причина, а много позже, когда столкнулись с последствиями), и как раз такие нехорошие ошибки мы заменили на явные и незамедлительно возникающие.

    чем жестче будет падать система — тем лучше, быстрее починят

    Это именно то, что у нас и происходило. Сразу ошибка «Объект не найден», сгенерированная кодом вида

    return items.FirstMaybe(cond).OrElse(()  => new ItemNotFoundException());
    

    вместо NullReference где-то еще позже.

    Так что ваш вывод о скрытых ошибках неверен, все наоборот — мы не прячем что-либо, а делаем еще одну неявную вещь — явной. Так что куча ошибок была, и была быстро исправлена, т.к. это были форсированные исключения, бросаемые очень близко к самой точке возникновения проблемы.
  • В C# с типами все в порядке
    +3
    Как автор изначальной статьи, чувствую себя должным ответить, хотя по частям все эти мысли уже изложены выше другими участниками.

    1. Автор приводит несколько, назовем их так, странные реализации GetItem, неявно постулируя, что они вытекают из первичной статьи. Однако же, они из нее ничуть не следуют.

    Из нее может следовать, например, вот такая реализация, гарантирующая либо объект, либо исключение:

    public Item GetItem(int itemId)
    {
        return dataAccessor
    		.getItemById(itemId)
    		.ToMaybe()
    		.OrElse(() => new ItemNotFound(itemId));
    }
    


    Либо такая, явно декларирующая возможность неудачного поиска, и трактующая его как нормальное, штатное поведение:

    public Maybe<Item> FindItem(int itemId) // а Get выше тогда должен реализовываться через этот Find для устранения дублирования
    {
        return dataAccessor.getItemById(itemId).ToMaybe(); 
    }
    


    2.
    При этом в одном из примеров он использует контракты, что противоречит их принципам.
    При этом «противоречие принципам» автор иллюстрирует якобы необходимостью вставить в сторожевое условие сам код метода:
    Что бы достать объект из репозитория, нужно сначала вытащить объект из репозитория.


    Но если мы посмотрим на GetItem из п.1 моего комментария, то видим, что туда нужно только вставить Contract.Ensures(Contract.Result() != null); и более ничего; никакого коллапса вселенной бесконечной рекурсии это не вызывает.

    3.
    Правда в том, что никто не может гарантировать существование объекта в репозитории.

    Я уже писал, что именно репозитории тут не специфичны. Но если в каком-то конкретном случае правда именно в этом (что объекта где-то может быть), я вовсе не предлагаю пытаться гарантировать наличие объекта, а предлагаю явно выразить эту правду, вернув Maybe.

    4.
    Я перефразирую: nullable reference. Масло масляное

    Только потому кажется «масляным», что в виду ошибки проектирования языка классы в Algol C# по умолчанию снабжены значением null.

    Anthony Hoare
    I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W)…

    посмотреть на человека-легенду

    Если старичок Хоар покажется слишком далеким от нашего времени, вот цитата из Барта Де Смета, для .NET человека «изнутри», книга C# Unleashed, одна из Must-Read по классификации замечательного SergeyT:

    Цитирую врезку из этой книги под характерным названием «Жизнь без null»

    Давайте явно уясним одну вещь: (a) возможность/невозможность принимать значение null и (b) различие между значимыми и ссылочными типами — это ((a) vs (b)) ортогональные (независимые) свойства и это правильно. Было бы хорошо, если бы любой тип мог явно задекларировать, поддерживает ли он значение null, или нет.


    И далее по тексту Барт говорит, что проектировщики C# не могли сделать эту ортогональность полной, т.е. в классах нет возможности «отключить null», и это вызвано лишь причинами совместимости. Например, в экспериментальном Spec# (где можно не думать так сильно о совместимости) такая возможность есть.

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

    5.
    Что мешает обратится к содержимому объекту без этой проверки? Можно точно так-же безалаберно не проверить на null через неравенство.


    Я считаю, что вероятность первого много ниже, чем вероятность второго. Чтобы обратиться к содержимому Maybe без проверки, нужно совершить явное действие — добавить «.Value». Чтобы не проверить на null делать не нужно ничего, это уже сделано :).

    Спотыкание об это «.Value» — это вроде как если бы у программиста был ангел-хранитель, который при каждом случае, когда тот написал GetSome().DoStuff(), волшебным образом смотрел бы в исходник GetSome(), и при необходимости стучал бы его по плечу и говорил: «А кстати, там может быть null».

    Замечу, что как раз невозможность случайно игнорировать Maybe здорово стимулирует к тому, чтобы проектировать систему с минимальным количеством необязательных возвращаемых значений. И оказывается, что далеко не так часто нужны nullable-классы, как это кажется на первый взгляд. Они нужны приблизительно так же часто, как nullable-структуры. Иногда.

    6. Для аргументирования вредности подхода автор приводит код:

    public Maybe<Item> SomeMethod()
    {
        var mbItem = GetMbItem();
    
        if(mbItem.HasValue)
        {
            var item = mbItem.Value;
    
            ModifyItem(ref item); 
        }
    
        return mbItem;
    }
    


    Во-первых, вполне явная ошибка: изменяем одну переменную, возвращаем другую, чего хорошего тут ждать, непонятно.

    Однако, в духе Maybe, этот код пишется совсем иначе (учитывая, что ref и out использовать без крайней необходимости не следует, т.к. это ломает возможности функционального программирования):

    public Maybe<Item> SomeMethod()
    {
        return GetMbItem().Select(ModifyItem);
    }
    


    где ModifyItem имеет вид Item ModifyItem(Item item){...}

    Или, если очень приспичило, даже с ref:

    public Maybe<Item> SomeMethod()
    {
        return GetMbItem().Select(i => { ModifyItem(ref i); return i; });
    }
    


    7. Что же касается тезиса
    для того, чтобы не допускать NullReferenceException, нужно быть внимательным,
    готов принять даже более широкий тезис, например, такой: «нужно быть внимательным».

    И да удастся это нам всем :)
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    0
    Вполне могу согласиться с таким подходом, лишь бы команда его принимала и использовала единоообразно.

    Хотя, при желании, вызовы библиотек прекрасно оборачиваются ToMaybe, об использовании неинициализированных переменных и полей предупреждает компилятор или решарпер, а в алгоритмах вполне можно как обходиться без null, так и «разрешить» его локальное использование особым способом (зависящим от того, каким методом null был запрещен; например, специальным комментарием).
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    +1
    При условии, что:
    • null запрещен (одним из вышеперечисленных способов) и
    • выбранная реализация Maybe не разрешает Maybe(null) (или приравнивает его Nothing),

    ваш первый тезис становится неверным.
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    +1
    Я так понял, что вы имеете в виду шаблон Null Object. Это вполне хорошее решение, когда оно на своем месте. Однако, на мой взгляд, на роль универсального избавителя от null оно не подходит. Этот шаблон относится к моделированию предметной области: если у нас есть семейство объектов (например, разные типы Начислений в финансовом приложении), и для них можно (для унификации обработки) говорить также об Отсутствующем Начислении (если это имеет смысл с точки зрения той модели, в которой мыслят пользователи и проектировщики приложения), то это хорошее место для применения Null Object.

    Однако, если у меня есть коллекция users и мне нужно сделать следующее:

    var defaultAdmin = ...;
    var admin = users.FirstMaybe(u => u.IsAdmin).OrElse(defaultAdmin); 
    


    То тут вводить NullUser, на мой взгляд, неуместно, так как он не будет представлять никакую существенную концепцию в модели предметной области.

    Что же касается возможности вызвать maybe.Value при отсутствии значения, она, хоть и приведет к исключению, все же является явной операцией. Вы прицеливаетесь и четко стреляете себе в ногу, сие есть ваше неотъемлемое право. Мы лишь гарантируем, чтобы пистолет не выстрелил без нажатия на курок :)
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    +1
    Только и разницы, что вместо одной строчки две. Никто не умрет, но суть немного затуманивается. Чем такого меньше, тем лучше.
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    0
    Почему же, если на уровне проекта мы заявляем: «методы никогда не возвращают null», то, соответственно, нужно внедрить в код каждого метода, возвращающего ссылочный тип, вышеуказанный контракт. Это работа для AOP.

    При этом подразумевается, что повсеместно (где необходимо) передается/возвращается Maybe. Точки сочленения с внешним миром оборачиваются, если необходимо, тоже в Maybe. И — вуаля, «ошибка на миллион долларов» исправлена :)
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    0
    Пожалуйста :) Исходные коды его на githube, если в процессе использования родятся какие-то еще общеполезные расширения — пушьте, включим в новые версии пакета.
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    0
    Конечно, это оно, да и Func<T, ...> тоже есть, как функциональный тип.

    Но и то, и другое можно поудобнее сделать.

    Например, поддержать анонимный функциональный тип вида (int -> string), автоматически приводимый к любому подходящему делегату, как Func<int, string> так и какому-нибудь sting MyCustomDelegate(int a).

    То же и с кортежами:
    Сейчас так:

    var tuple = IntegerDivide(5, 3);
    var div = tuple.Item1;
    var mod = tuple.Item2; 
    

    А можно было бы так:
    var (div, mod) = IntegerDivide(5, 3); 
    
  • Усиливаем контроль типов: где в типичном C#-проекте присутствует непрошеный элемент слабой типизации?
    0
    Ну, я имею в виду так, чтобы глобально, например, для целого проекта запретить. На уровне метода — да, контракты. Ну а на уровне проекта — тоже контракты, но с AOP, я об этом написал ниже :)
  • Нам не нужен ваш кофе
    –1
    Согласен, в команде конечно же нужно следовать общим политикам, тут и говорить нечего.
  • Нам не нужен ваш кофе
    –9
    Ну может этот наш гипотетический популяризатор готов пожертвовать своим рейтингом (который ему не поставят нелюбители coffee) на эту фразу. А может, ему любители кофе еще и добавят, кто знает. Слава Богу, это решает сообщество, плюсуя, а не авторитарные личности с призывами «запретить». Спасибо, слон уже есть :)

    А как можно спрашивать о JS, приводя пример на CS? Ведь такой вопрос можно автоматом считать про CS, да и все.
  • Нам не нужен ваш кофе
    –14
    Ну может этот гипотетический популяризатор готов обменять свой рейтинг (который ему не поставят coffee-
  • Нам не нужен ваш кофе
    –18
    Но автор-то даже и спрашивать на эсперанто запрещает. Это вообще, по-моему, за гранью.

    Насчет ответов — с одной стороны, соглашусь, на js общепонятнее будет.

    С другой стороны — ответ на SO дело добровольное, как и чтение такого ответа. И если человек хочет потратить свое время на ответ, и в качестве «платы» желает популяризовать что-то, например, любимый диалект, почему он не вправе? Не понимаете coffee/typescript/… — пропускайте этот, читайте другие ответы. Давший ответ ничем не обязан вам, чтобы вы ему условия ставили, правда ведь?
  • Нам не нужен ваш кофе
    +26
    А отличная идея — в более широком смысле — вообще запретить окружающим: говорить непонятные мне слова, т.к. «я их не понимаю», оперировать непонятными мне концепциями, т.к. «они мне не знакомы» и т.д. Далеко пойдет автор :)
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    Да, наверное :) Я не фронтенд-разработчик, ну и тут дело вкуса, есть и других портов Linq куча.
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    И не только по правой части. Я себе реализовал аналог Linq и при этом получается вот такой типизированный код на TS:

    data.document.p.where(paragraphCondition)
        .selectMany(p => p.s.where(sentenceCondition))
        .selectMany(s => s.l)
        .select(l => data.vocabularyItems.firstOrDefault(vi => matchesLexem(vi, l)))
        .where(vocabularyLexem => vocabularyLexem && vocabularyLexem.level < 10 && !alreadyPresent(vocabularyLexem))
        .distinct(vocabularyLexem => vocabularyLexem.descriptor.presentation)
        .foreach(vocabularyLexem => this.vocabularyItems.push(vocabularyLexem));
    


    Где и в последней строчке TS знает правильный тип vocabularyLexem.
  • Построение масштабируемых приложений на TypeScript. Часть 2.5 — Работа над ошибками и делегаты
    0
    Автор увлекается аннотированием, на мой взгляд, излишне. В статье почти все (!) аннотации типов можно выкинуть, *ничего* не потеряв в типизиции. TS отлично умеет выводить типы, как по инициализаторам, так и по использованию.

    У в моей аналогичной библиотеке такой код выглядел бы так:
    public messagesLoaded = new Event<string[]>();

    При этом messagesLoaded имеет четкий тип Event<string[]> — аннотация тут просто не нужна.
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    Круто! Сам параллельно прохожу аналогичный процесс разработки.

    По коду: лучше бы не писать аннотацию типа там, где она очевидна, например: «public MessagesLoaded: Events.Event = new Events.Event(); », и уж тем паче с обобщенными типами.
  • Поддержка С++ в ReSharper
    0
    О, это крайне приятно слышать! :)
  • Насколько сложно изменить бизнес модель спустя 2 года? История перезапуска стартапа
    +1
    Все были расстроены. Морального права *проклинать* Гугл за это, говорить, что они теперь *корпорация зла* — никто, я считаю, *на основании этого факта* не имел. Быть расстроенным, выражать сожаление и выносить суждения об ошибочности такого решения гугла — это сколько угодно.

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

    Если человек пользуется каким-то сервисом бесплатно, то он должен быть в любой момент быть готовым перейти на платную основу или остаться без сервиса. Иначе — это халява, а халява развращает. Что-то есть очень потребительское в отношении «однажды предложили бесплатно — должны всегда».
  • Насколько сложно изменить бизнес модель спустя 2 года? История перезапуска стартапа
    +1
    Если сервис не давал гарантии вам, что он будет вечно сущ, он может завтра же закрыться, и вы не только не имеете морального права быть недовольным, но и должны сказать спасибо, что он предоставлял вам услугу какое-то время.
  • Specification By Example – BDD для прагматиков
    0
    Этот сорт по-русски называется «корнишон», ну уж никак не геркин :)
  • Обзор Windows Workflow Foundation на примере построения системы электронного документооборота [Часть 1]
    0
    Да, очень было бы интересно посмотреть на детали реализации реального сценария.
  • Внутри Cycleplex: странный, дикий мир велосипедов Google
    +1
    Те, что коснулись меня: вся территория вокруг Борисовских прудов, в т.ч. вдоль всей улицы Борисовские пруды.
    Ее «продолжение» вокруг течения Городни в Братеево.

    Марьинский парк (там и раньше было, а добавилась длинная велодорога в Капотню).

    Еще где-то в окрестных районах встречал небольшие локальные «кольцевые» дорожки в микропарках и скверах, которые можно «включить» в маршрут, если ставить целью максимально ехать по в/д.

    Вдоль Каширки пока нету, про планы не знаю, но по общей логике происходящего и вдоль Каширки тоже должна появиться (это не знание, просто надежда :) )

    Еще видел пару раз за прошлую неделю Газели, везущие куда-то крытые (с крышей) велопарковки. Установленных пока не видел :)
  • Внутри Cycleplex: странный, дикий мир велосипедов Google
    0
    Не знаю где как, а Москве этот круг, похоже, разрывается. И дай-то Бог чтобы хорошо разорвался :)
  • Внутри Cycleplex: странный, дикий мир велосипедов Google
    0
    О, да, в самый буран мне довелось поколесить по городу — и по снегу, и по льду, и по вот этой каше невообразимой. Зато теперь летний песок или грязь — просто семечки, едешь и не замечаешь :)
  • Внутри Cycleplex: странный, дикий мир велосипедов Google
    0
    Абсолютно солидарен с rusevgen. Добавлю, велодорожки в этом году активно и повсеместно появляются (речь про Москву сейчас). Уже на нескольких моих маршрутах, где я всегда ездил по дороге или тротуару, я неожиданно обнаружил на большой части пути велодорожку.

    Так что — пробуйте :) Я ездил на велосипеде на работу пару раз в неделю (20 км в одну сторону). Сейчас работаю дома, езжу в магазины, к друзьям, к родителям, просто покататься. И это все вполне удобоваримо было и 2 года назад, а сейчас, повторюсь, еще получше стало.
  • Элегантные строки
    0
    А, в этом смысле да. Хотя, если посмотреть на мок- и модульно-тестовые библиотеки, там это вполне основной подход. Да и внутренние DSL на C# тоже вполне неплохо пишутся, например, когда предметная область из каких-нибудь тарифов по-разному собираемых — очень читаемо и красиво получается :)
  • Элегантные строки
    0
    С каких пор текучие вызовы нетипичны для C#?) Очень даже в духе тенденций, так скажем.