• Нужна ли холакратия в it-компании: плюсы и минусы
    +1
    До ожидаемого коллапса осталось вырасти до 100-150 человек. Где-то с этого размера коллектива издержки на p2p коммуникации в команде начинают съедать всю пользу. Люди просто не будут знать соседей по имени, а то и в лицо.

    Проблема построения таких организаций именно в масштабируемости. До 10 человек все тривиально, т.к. даже у самого деспотичного руководителя физически хватит времени следить за всеми или у команды будет хватать времени общаться внутри себя. При росте ещё на порядок наступает предел естественного языка и скорости коммуникаций, а также восьмичасового рабочего дня.

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

    Сам прохожу подобный переход как руководитель. Подобные статьи отдают некоторой наивностью и замалчиванием.
  • Alma Mater технического прогресса
    +1
    Не правильно расшифровываете МВТУ. Старожилы знают, что Мы Вас Тут Угробим) Или Могила Вырытая Трудами Ученых.

    Есть еще вариант:
    Мало Выпьешь, Трудно Учиться
    Много Выпьешь, Тут же Уволят

    МГТУ, к сожалению, веселых народных расшифровок известных мне не имеет((

    Фото классные. В мой выпуск 2009 большей части всего еще не было.
  • Что нового в Visual Studio 2015 для JS-разработчиков
    +3
    Возможно, что с точки зрения фич особо преимущества и нет, но то, что есть в VS работает раз в 10 приятнее. Активно пользуюсь студией с 2005-й версии. Продуктами JB последние полтора года. Так вот, писать код в студии нереально комфортней. Ничего не тормозит, шрифты масштабируются под 4к без проблем, интеллисенс субъективно умнее. Для меня ощущение от студии, как от пользования хорошим профессиональным инструментом, пусть и с разумным минимумом функций. От JB инструментов, как от пылесоса с влажной уборкой и парогенератором. Сухую уборку делать можно, но неудобно таскать из-за габаритов и кучи ненужных функций, которые вообще не будешь использовать.

    Это все про js. Не знаю, как с поддержкой Java в IDEA, но после работы с C# в студии, на остальные IDE смотреть вообще не хочется. Просто разница лет в 10.

    Естественно все это имхо и не претендует на объективность.
  • Новогоднее видео RBDoom3-BFG на процессоре Эльбрус-4С
    0
    Возможно. С портом дела не имел. Сам bfg был, емнип, ограничен. В видео выше 30 частота кадров не поднималась или я этого просто не увидел.
  • МЦСТ будет выпускать материнскую плату и операционную систему для процессора «Эльбрус-2СМ»
    0
    Естественно. Но это не поменяет принципиально картину.
  • МЦСТ будет выпускать материнскую плату и операционную систему для процессора «Эльбрус-2СМ»
    –2
    Если мне не изменяет память, шифрование по ГОСТ никаким боком не относится к openssl. Могу ошибаться, т.к. работал с ним давно. В любом случае, именно шифрование по ГОСТ актуальная задача для отечественного CPU, а не любой другой алгоритм, поэтому в данной части ваши замечания не совсем корректны.

    На счет тестирования в целом, полностью согласен, что оно не особо репрезентативно. Многоядерность толком и не тестировали. С другой стороны, а как корректно тестировать 2 абсолютно разные архитектуры кроме как в синтетике? В любом случае, других тестов Эльбруса я вообще не видел.
  • МЦСТ будет выпускать материнскую плату и операционную систему для процессора «Эльбрус-2СМ»
    0
    Мимо этих статей проходят везде и всюду. Тестирование Эльбрус-2С+ там тоже есть, кстати.
  • МЦСТ будет выпускать материнскую плату и операционную систему для процессора «Эльбрус-2СМ»
    +2
    Не знаю почему, но все прошли мимо статьи с детальным описанием и тестов: часть 1, часть 2 и часть 3
  • Первый смартфон Microsoft Lumia
    0
    Полностью поддерживаю. Ждал 830. Думал, что будет флагман, но с 4.5+- дюймами. Вышло непонятно что.
  • Атом — реализация на TypeScript
    0
    Тут важно иметь ввиду ограничения обещаний:
    1. обработчик вызывается отложенно


    Вопрос, что в этом плохого? Как работает ваша реализация атомов? Изменения распространяются синхронно без отложенных вызовов?
  • Корпорация Microsoft представила Microsoft Band: фитнес-трекер + умные часы
    +2
    Вы просто никогда не бегали по утрам с шестидюймовым телефоном в руках, похоже. Это киллерфича для многих, включая меня.
  • Новинки Берлина: аксессуары для Lumia
    0
    Люто плюсую. Проверяю уже каждый день. Когда?
  • По поводу появления 8 и 10Тб жёстких дисков
    0
    Эмм. А не пробовали памяти больше 2ГБ под Win7/8 ставить? Разница между HDD/SSD даже для работы не всегда очевидна, если системе хватает памяти для активного кэшировнаия. Единственное, что отличается кардинально — время загрузки системы. Поэтому бы я не был так категорически настроен, что невозможно перейти. Дома SSD, на работе HDD. Принципиальной разницы в скорости работы не ощущается.
  • Атом — минимальный кирпичик реактивного приложения
    0
    Мы с вами немного про разные вещи говорим.

    Вы про UI, я про обертку над API. По сути, с вами согласен, если говорить именно про UI слой.
  • Атом — минимальный кирпичик реактивного приложения
    0
    Это очень сильно зависит от задачи, на самом деле. Грубо говоря, данные можно поделить на 2 категории: доменные, которые живут постоянно и описываются атомами, и контекстно-зависимые. Соотношение очень сильно зависит от типа системы. В корпоративном приложении или b2c системах, типа яндекс денег, практически не будет контекстных данных. В соц. сетях, наоборот, 90% времени это просмотр чужих страниц, котиков и т.п., которые существуют только в рамках текущего запроса пользователя. Их просто бессмысленно кэшировать и, более того, это прямой путь к неработоспособности на слабых клиентах. В любом случае, тут разумно использовать совершенно другие механизмы кэширования с меньшими издержками по памяти и производительности.
  • Атом — минимальный кирпичик реактивного приложения
    0
    Теперь я знаю, как называется тот подход, который я применяю уже пару лет)

    На самом деле, это совершенно замечательный паттерн для работы с данными в сложносвязных системах. В своей практике использую его для построения слоя доступа к данным, т.е. как обертку для серверными API. Например, если в spa у нас есть возможность работать как незалогиненным, так и в рамках конкретного пользователя, то атомы это идеальный способ описать состояние логина системы. Аналогично, это очень хорошо работает для всех долгоживущих данных.

    Но атомы не отменяют события и промисы. Если есть необходимость просто получить данные, то атомы избыточны и даже вредны.
  • Интервью с разработчиками на TypeScript
    +6
    На моей практике (2-й проект на 100к+ строк кода, начиная с версии 0.8) оказалось удобнее вообще с map файлами не заморачиваться и отлаживать сразу js, т.к. код очень близок.
  • Dependency Injection. JavaScript
    0
    Как раз в методе инициализации require.js можно создать и реализовать что угодно, если это необходимо. В частности управлять версиями загруженных модулей и т.п. Это не DI, но все еще IoC. Далее работают сами синтаксические конструкции языка, где необходимо.

    Что касается необходимости, то IoC с DI это еще тот антипаттерн в плане поддержки кода. JS и так ужасно поддерживается IDE по сравнению с .Net/Java. Молчу про то, что нет никаких способов нормально осуществлять Go to declaration нет, так еще и вводим паттерн, который намеренно усложняет эти связи. Представьте, что у вас пара сотен тысяч строк кода в проекте и как вы это будете поддерживать.
  • iOS vs WPF — сложное против мелкомягкого
    0
    Не успел отредактировать предыдущий пост. По этой статистике у ASP.NET 28.2%, PHP 70.7, а остальные делят жалкие 1.1%
  • iOS vs WPF — сложное против мелкомягкого
    +1
    Да. Именно так. Ссылки есть в комментарии ниже.
  • iOS vs WPF — сложное против мелкомягкого
    +2
    Пришлось напрячься, чтобы вспомнить, где видел: линк. В общем, мопед не мой, вопросы следует задавать автору топика по ссылке.

    Но если погуглить по «ASP.NET Share», то по первой же ссылке получаем 17.2%.
  • iOS vs WPF — сложное против мелкомягкого
    +5
    Как бы Unity 3D. Один из самых популярных движков для разработки игр. Построен на базе mono. Основной язык — C#. Разработка для всех больших платформ и мобильников. Проходил слух про нативный шарп на PS4. Все консоли MS поддерживают разработку на шарпе. В мире игр C# играет очень заметную роль.

    Недавно была статистика, что 17% рунета это ASP.NET. Да, это не 80% PHP, но это дикий перевес над любыми другими платформами.

    В общем, C# используется очень много где. Просто об этом не все задумываются.
  • SpaceX вывел на орбиту 6 спутников
    0
    Строго говоря, у нас тоже не сидят ровно: ссылка
  • История спецэффектов в кинематографе
    +28
    Думаю, что списку недостает одного важнейшего фильма — Парка юрского периода. Он поражал своей достоверностью. Не знаю, как про него можно было забыть и вставить железного человека (который, кстати, мне очень нравится).

    Также я бы добавил День независимости. Разрушение городов… Это было нечто.
  • Маркетинг для финансовых институтов. Часть первая: кампании
    +3
    Идиотский вопрос, а что этот менеджер знает и как его использовать? Получилось так, что есть карта с подобным пакетом, но я вообще не могу понять, зачем мне это нужно. Карту оформлял по причинам, совершенно не связанным с премиум пакетом, но получилось, что он шел довеском.
  • История игрового рынка, часть 2
    0
    При всем уважении, но рынок далеко не занят только PS3. X360 присутствует в более чем сопоставимых объемах. Среди моих знакомых X360 раза в два больше чем PS3, если уж на то пошло. Причем у 2/3 владельцев ящика есть и кинект.

    Возможно, по стране ситуация отличается от Москвы, но заявление автора о безоговорочном лидерстве PS3 явно не отражает реальность.
  • Swift — нововведения
    –1
    На TypeScript же, который похож C#.
  • Swift — нововведения
    +1
    TypeScript. Почти полное совпадение.
  • Сколько налогов вы платите с зарплаты?
    +1
    Я не бухгалтер, не могу сказать точно. Расчет выше это просто первый попавшийся пример из сети в моей легкой интерпретации.

    Суть не в конкретных цифрах, а в том, что все намного сложнее. И Нельзя налоги, уплачиваемые предприятием «в лоб» приплюсовывать к з/п. Особенно, если вспомнить про льгот для ИТ, 10%, вычеты за детей и т.д.

    Мое мнение — важны не 100 рублей, а те 87, которые получает работник и то, что он может на них купить. Налоги компаний это совсем иная песня.
  • Сколько налогов вы платите с зарплаты?
    +3
    Не могу с вами согласиться. Это огромная разница.

    Во-первых, налог считается совсем иначе, о чем упоминали выше. Грубо говоря, максимальная сумма, с которой платится ЕСН в годовом эквиваленте — +-600 тысяч рублей (округляю для простоты). Т.е. для белой з/п в 100000 рублей в год, ЕСН составит не 1200000*0,26=312000, а 600000*0,26 = 156000. Не находите, что полторы зарплаты это уже серьезная разница? И она начинает действовать от 60000 в месяц. Т.е. предприятию безразлично, если сотрудник получает больше 60000 рублей в месяц.

    Во-вторых, ЕСН платит предприятие, а не работник. Это выбор предприятия повысить налог для себя, а не работника. Работнику абсолютно это безразлично. Вкупе с постоянным НДФЛ в 13% налоги вообще не волнуют работника, т.к. важна только чистая з/п.
  • Сколько налогов вы платите с зарплаты?
    0
    И еще раз про 26%. Гугление показывает, что выплаты на соц. страхование в 2013-году равны 30%.
  • Сколько налогов вы платите с зарплаты?
    +1
    Первая попавшаяся цитата из сети:

    Налоговая база

    Для налогоплательщиков первой группы объектом налогообложения признаются выплаты и иные вознаграждения, начисляемые (выплачиваемые) в пользу физических лиц по трудовым и гражданско-правовым договорам…


    Т.е. база это ФОТ. Налог не входит в ФОТ. Т.е. 26% мы должны считать от 100 рублей. Но никак не высчитывать 100 рублей от X — 26%.
  • Сколько налогов вы платите с зарплаты?
    +2
    Нескромный вопрос. А почему 26% = 135 135,13? Насколько я помню с институтских времен, автор полностью перепутал суть налогов уплачиваемых работником и работодателем.

    Есть з/п в 100 рублей. Из них 13 платит работник. 26% от ФОТ = 26 рублей, платит работодатель и они не входят в ФОТ. Т.е. в сумме получаем 126 рублей.

    И второй вопрос в том, что 26% уже давно стали 34%, если мне не изменяет память.

    Заранее прошу извинить за ошибку в расчетах. Просто схема расчета совершенно не ясна.
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    Не сказал бы, что совсем уж вкуса. При переносе каких-то решений из мира .Net в веб есть один очень серьезный подводный камень — в JS нет типов и, как следствие, рефлексии.

    Поэтому если LINQ долежен переноситься вполне адекватно, т.к. это чисто compile time, то многие другие, опирающиеся на рефлексию подсистемы нет. Например, при все схожести шаблонизации ASP.Net MVC c underscore.template по своему подходу, перенести те же практики «в лоб» проблематично из-за невозможности использовать рефлексию для определения типов полей модели, и, как следствие, перехода к куда более тяжелому синтаксису, вместо Html.EditorFor. Хотя о моих размышлениях на эту тему скорее всего как раз следующая статья и будет.
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    Честно говоря, тут уже рождается вопрос про велосипеды и их изобретение. А зачем в TS/JS LINQ? Сто лет есть underscore.js, который все тоже самое делает, типизирован в TS 0.9 и понятен любому фронтэнд разработчику.
  • Построение масштабируемых приложений на TypeScript. Часть 2.5 — Работа над ошибками и делегаты
    0
    Спасибо. Продолжение обязательно будет. Но пока мне надо завершить внутренний холивар на тему очередных велосипедов и их необходимости в реальной жизни :) Ну, и еще выспаться после рабочей недели)
  • Построение масштабируемых приложений на TypeScript. Часть 2 — События или зачем стоит изобретать собственный велосипед
    0
    В итоге тоже к этому пришел. TS без проблем по правой части выражения вычисляет. В любом случае, спасибо за замечание.
  • Построение масштабируемых приложений на TypeScript. Часть 1 — Асинхронная загрузка модулей
    0
    Вы никоим образом не опровергаете того, что JS не был спроектирован для написания больших приложений и ошибки его проектирования мы сейчас вынуждены решать, подставляя различные костыли :)
  • Построение масштабируемых приложений на TypeScript. Часть 1 — Асинхронная загрузка модулей
    0
    Инструмент зависит от задачи. В конкретно моей, из которой выросла статья, типизация реально помогает. М/б вам просто везет, что у вас нет рефакторинга из-за регулярных изменений требований.

    По сути, так и есть, но существуют особенности языка, которые можно использовать себе во благо. Или которые не получится использовать, если смотреть на язык, как на «классическое ООП».


    Безусловно, нюансы есть. Более того, я искренне люблю JS и не имею никаких предпочтений между ним и C#. Для каждой задачи свой инструмент. Поэтому вдвойне люблю TS, т.к. он их прекрасно сочетает.

    И как это связано? JSHint/JSLint/Closure compiler, не?


    Не холивора ради, но как любое из этих средств проверит соответствие типов? Если трезво подойти к проблеме статического анализа, то ни одна утилита не может проверить то, что не знает. Например, типы или обязательность параметров в функциях. Ну, или никогда не сможет проверить на 100%. Безусловно, все перечисленное вами ПО работает, но это только половина дела. вторую делает TS, вводя типы и т.д.

    Это прям реально, реально проблема архитектуры, но никак не динамических языков, и JS в частности.


    Проблема конкретно JS в том, что конкретно на нем большие листинги нечитаемы. Молчу про сплошные костыли с модульностью и т.п. Многое можно нивелировать архитектурой, стандартами кодирования и т.п., но в любом случае мы получим либо слабочитаемый листинг, либо тучу комментариев. Естественно, тут я немного преувеличиваю, но в реальном мире действительно хороший код на JS попадается исчезающе редко. Иначе — написать неудобочитаемый код на JS в разы легче чем на любом статически типизированном языке.
  • Построение масштабируемых приложений на TypeScript. Часть 2.5 — Работа над ошибками и делегаты
    0
    В общем, если все совместить, то получим:

    export interface ICallback<ArgType>
    {
        (arg: ArgType, context?: any);
    }
    
    export interface ICallbackDesc<ArgType>
    {
        Callback: ICallback<ArgType>;
        Subscriber: any;
    }
    
    export class Event<ArgType>
    {
        private Callbacks: ICallbackDesc<ArgType>[] = [];
    
        public Subscribe(callback: ICallback<ArgType>, subscriber: any): ITypedSubscription<ArgType>
        { 
            //Выполняем работу
        }
    
        public Unsubscribe(callback: ICallback<ArgType>): void 
        { 
            //Выполняем работу
        }
    
        public Trigger: ICallback<ArgType> = function (arg: ArgType, context?: any)
        {
            //Выполняем работу
        }
    }
    
    /** Базовый интерфейс подписки на событие. Минимальная функциональность. Можем просто отписаться и все. */
    export interface ISubscription
    {
        Unsubscribe: { (): void };
    }
    
    /** Типизированная версия. Включает ссылки на событие и callback */
    export interface ITypedSubscription<ArgType> extends ISubscription
    {
        Callback: ICallback<ArgType>;
        Event: Event<ArgType>;
    }
    


    т.е., ровно то, что вы предлагали, но с вынесенным во вне делегатом.

    Я немного перестарался, как и писал в прошлом комментарии. Спасибо за подсказку.