Pull to refresh
10
0
Оникийчук Антон @onikiychuka

User

Send message
Обычно по уровню ответственности. Junior — решает очень локальную тактическую задачу. Middle — уровень конкретных задач. Senior — решает проблемы (уже может поговорить на тему предметной области с PM, дать свои рекомендации и главное — отвечать за решение проблемы). Team Lead -отвечает за всю систему целиком.
Например — мы пишем игру
Нарисовать красный пункт меню с текстом «Поехали!» — задача джуниора
Сделать полоски здоровья и маны — задача мидла
Написать систему поиска пути для юнитов — задача сеньера
Написать игру — задача тим лида
Есть несколько замечаний:
1. Ну идея определять время жизни объекта в том месте где ты его инжектишь — как минимум странная. Клас по идее вообще не должно волновать — какое время жизни у объекта — главное он есть и доступен.
2.
Объект времени исполнения (Runtime). Все клиенты используют один и тот же объект, который может изменяться во время работы программы.

Очень странное поведение. Я не могу придумать ни одной идеи где подобный подход был-бы оправдан. Плюс он создает кучу проблем (на вскидку — синхронизация переменных внутри класса, обновление значений во всех созданных объектах, что делать с тем от чего зависит этот объект).
3. Инжектить в поля — это моветон. Мешает использовать ваш объект без DI фреймворка, и делает зависимости класса менне явными (плюс много черной магии)
4. Макросы — больше черной магии в коде, которую фиг поймешь, фиг отладишь и даже затрейсишь.

Вообще статическая типизация и DI дружат очень хорошо (как раз с динамической намного больше проблем). Просто в С++ не достает средств интроспекции чтобы сделать все красиво. Посмотрите например на Dagger для Java (http://square.github.io/dagger/) он мало того что работает поверх языка со статической типизацией, как еще и проверят весь граф объектов на момент компиляции.
Имхо в C# есть 3 вещи которые к сожалению C++ пока не снились и которые очень сильно ускоряют разработку:
1) Нормальный туллинг (Отличный отладчик в VS и ReSharper + NuGet). Ничего подобного уровня в C++ просто не существует. Блин я 2014 году экосистема у которой нет управления зависимостями — это полный… (и не надо мне говорить про CMAKE например — тот еще ужос)
2) Языковые возможности которые дают писать, предсказуемый и читабельный код (Async-Await, Generics, LINQ). Этого крайне не хватает.
3) Библиотеки. Я промолчу про стандартную библиотеку. Но без Autofac, WCF, WPF, MEF и еще череды отлично задизайненых и сделанных библиотек разработка оказывается очень тяжелой. Да у C++ есть boost — но лучше бы его не было. В этой мешанине классов, подходов и темплейтов очень сложно разобраться. Имхо единственная логичная библиотека на C++ это stl. Но в ней очень маленький набор примитивов.

В это месте вы можете вернутся по тексту назад и поменять C# на Java. Результат будет практически тот-же (поменяются названия библиотек и языковые возможности).

В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.

Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Это далеко не так. (Я при это не сравниваю С++ с 9кой а C# с BMW, просто хочу показать на некорректность вашей фразы)
нам пришлось бы реализовать 6 полей вместо одного, принимая решение о том, что показывать, а что нет за уровень представления.

И я абсолютно за такой подход. ViewModel это модель View. Они неразрывно связанны. Единственная разница заключается в том что уровень ViewModel очень просто тестировать, а вот View слой тестировать достаточно сложно. Ну и separation of concern -> логика View уходит во ViewModel, а вот стиль отображения остается во View. В моей практике — так получалось проще.
public class BoolToVisibilityConverter
        : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            return (value as bool?) == true
                ? Visibility.Visible
                : Visibility.Collapsed;
        }

        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            throw new NotImplementedException();
        }
    }

Это не самый лучший подход. Тесты получаются не так выразительны как могли-бы быть. Гораздо лучше делать свойство типа Visibility во View Model
Резюме + референсы у меня прошли.
Вообще там есть опции типа «зарплата больше 67.5к в год или 5 лет опыта» == «диплом» но они вроде как не приняты. Работодатели на счет диплома не особо беспокоятся и переживать из-за этого не стоит.


Общался с дамой из Blue Card программы, это 5 лет подтвержденного опыта заменяют диплом.
Камрады! Сколько можно писать хрень что сделано у нас, если у нас только собрано?!

Действительно. А ну немедленно прекратите!
Вас как-то не задевает что компоненты серверов HP произведенны далеко не только HP. Тоже самое с миллионом других продуктов. Важно кто сделал ПРОДУКТ, а не его составляющие.
Тем что очень тяжело автоматически хеджироватся с него, есть несколько бриджей для ECN (упомянутый Currenex например), но все равно все криво и косо.
Интересно, что мешает использовать ее не-кухонным брокерам, на рынке фьючерсов/акций напр?? Ну кроме отсутствия 'стакана' — который вобщем-то не очень и нужен, если вы — не скальпер…

Тем что это MT. Он вообще не знает нифига о площадке торгов например. Акции на разных площадках могут иметь разную цену.

Ну и это — известная фича МТ, за которую его обожают кухни — возможность руками добавлять квоты. Очередной раз когда у вас лимит слетят на спайке — задумайтесь о том — насколько это крутой софт :)
Не совсем бухгалтерия, но все же о деньгах.

Слышал звон — не знаю где он
Системы прайсинга и HFT настолько далеки от бухгалтерского ПО, насколько ваша игра от программирования реальной ракеты для полета на Марс. И там и там космос, но на столько разный…
Любой где количество таких объектов очень большое. Например — процессинг квот в биржевом софте.
Да и структуру и класс (это одно и тоже вообщем) можно создать как в куче так и на стеке. Эта приятная особенность С++ мне известна. Я намекал SVLad о том что пользователи намного чаще хотят C#-style структур в Java. Особенно те кто пытается снизить нагрузку на GC.
То что она создестя на куче а не в стеке не важно? Если нет то все ок. Но автору коментария (и многим кому приходится оптимизировать работу с памятью) важно.
Баротравма легких вообще не связанна с кесонной болезнью (растворение азота в тканях а потом его обратное превращение в газ при уменьшении давления), хотя кесонка тоже возможна при резкой разгеметизации (растворенный азот все равно есть в такнях, просто его концентрация ниже). И тут смысл не в абсолютных величинах давления, а в его перепаде. На баротравму можно нарватся при перепаде давления в 2-3 раза (от 3 атм на 20 метрах до 1 амт на поверхности). А вы говорите о перепаде давления практически в бесконечность раз. Мелкие баротравмы — ушей и пазух при такой разгерметизации будут 100% — для них очень маленький перепад нужен.
Да вы впринципе все правильно говорите. Господам неверующим — погуглите что такое баротравма легких. Есть такой эффект при знаятии дайвингом. Здесь будет тоже самое.
С async/await
void async AnimateSome()
{
    await UIView.AnimateAsync(0.25, ()=>someView.Alpha = 1)
    await UIView.AnimateAsync(0.25, 3, (UIViewAnimationOptions)0, () => someView.Alpha = 0)
    someView.RemoveFromSuperview()
}


Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
У вас часто бывало, что вы пришли на интервью и интервьюера нет? Я в своей практике с таким не сталкивался

Достаточно часто. Плюс задержки на 15-20 минут это вообще норма.
Так вы и на 100% не можете быть увереным что финализатор вообще вызовется. Платформа вам этого не гарантирует.
Может лучше было потратить усилия на то чтобы тестировать вызов Dispose во всех местах где он должен вызываться?

Information

Rating
Does not participate
Location
Россия
Works in
Date of birth
Registered
Activity