• Почему выдается ошибка в массиве?

    Shersh
    @Shersh
    Потому что переменная Index - нигде не определена.
    Ответ написан
    Комментировать
  • Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

    2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

    6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

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

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

    Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
    4 комментария
  • Как повысить уровень программирования?

    tiabc
    @tiabc
    Бизнес-партнер и консультант по технологиям
    Хорошие разработчики постоянно развиваются и никогда не стоят на месте. Любое развитие состоит в делании дел, в решении конкретных задач и в обратной связи, которую ты получаешь от других или в результате рефлексии.

    TL;DR: Читайте книжки, делайте дела, читайте чужой код.

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

    1. Изучайте базу. Алгоритмы, сети, криптографию, архитектуру, ос, устройство браузеров, компиляторы и т.д. Изучение подобных вещей дает понимание какие задачи бывают в реальном мире и как "большие дядьки" решают возникающие проблемы. Это кладезь инсайтов.

    2. Устройтесь на фултайм-работу с сильной командой даже если джуниором. Я считаю, что есть только один способ расти как разработчик: работать фултайм над одним бизнес-продуктом. Такой подход учит решать проблемы масштабируемости, думать заранее, работать над процессом, которому вы следуете в разработке, решать задачи, возникающие с длительной эксплуатацией, решать проблемы с удобными окружениями и вообще учиться планировать свою работу в связи с нуждами бизнеса.

    3. Написание кода - не самая большая часть работы сеньор-девелоперов, я бы сказал. Но когда речь заходит о самом коде, нужно понимать что ты пишешь и зачем. Есть классические книжки, которые можно найти, например, в матрице компетентности программиста, есть современные, но полезные типа The Art of Readable Code, которую я очень рекомендую. Нужно читать книжки. На собеседовании я всегда спрашиваю какие книжки читал или читает соискатель и если ответ отрицательный, то это большой минус.

    4. Участвуйте в опенсорс. Там вам всегда приходится сталкиваться с образом мысли самых разных людей и кодом, который они пишут. Это учит вас читать чужой код, находить в нем ошибки и критически и аргументированно к нему относиться, предлагая свои решения. Опенсорс-разработка, так же как и книжки, дает вам тот чужой опыт, который бы вы никогда сами не получили от людей, которые часто умнее или опытнее вас в чем-то. В опенсорсе, кстати, в отличие от бизнесовой разработки, есть шанс в удовольствие писать очень качественный код, в котором в бизнесе далеко не всегда есть необходимость.

    5. Наберитесь терпения. Это не случится за один день. Думайте над именованием, разделяйте обязанности, изучайте алгоритмы и экосистему, оптимизируйте ваше рабочее место, изучайте новые технологии, читайте статьи и в течение ближайших лет регулярных усилий вы обретете новый способ мышления и будете разрабатывать поддерживаемое и надежное ПО. Легкого пути, к сожалению, нет.
    Ответ написан
    2 комментария
  • Можно ли на знаниях С++ ориентироваться и кодить в Unity пока не изучу С#?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Так-с. Дайте-ка подумать. Гравитация, сильное взаимодействие, слабое взаимодействие, третий закон Ньютона, преобразования Лоренца, квантовая неопределённость, стандартная модель... Эм, не знаю в общем никаких физических законов, которые не позволили бы изучать какую-либо технологию в процессе работы с ней. Даже более того, это единственный эффективный способ начать её изучать.

    Си++, C#, Java, Python, JavaScript... Да как вы надоели с этой хренью, честно. Никто не удивится, если ты понятия не имеешь, что такое рефлексия, зачем нужны лямбда-функции, почему так много споров о сборщике мусора. И тем более такие мелочи, как порядок инициализации или особенности области видимости в VC++98. Вопрос не то, чтобы плохой. Он глупый и неправильный. Unity это про иерархию объектов на сцене, их менеджемент, операции с матрицами, работа с графикой в реальном времени, однако, в основном - это про то, как перетащить объект из ассетов на сцену и поколдовать над его свойствами. Unity это про стейт-машины и формальную логику (например, предикаты), UI/UX и оптимальное программирование, но в большей степени это артисты рисующие модельки, текстуры и спрайты, озвучивающие и анимирующие их. Наконец, надо разбираться в предметной области в сфере, по которой создаётся игра, но для хэлоу ворлдов хватит и восьмого класса.

    Так что хватит загрязнять тостер с этой фигнёй. Тут очень слабое ранжирование хороших вопросов в отличии от stackoverflow, таких вопросов уже тьма задавали. Хватит!
    Ответ написан
    5 комментариев
  • Я не умею готовить репозиторий или он просто не очень?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Коллеги, добрый день!

    Почему никто не упомянул про паттерн UnitOfWork? Паттерн репозиторий становится очень удобным в использовании, если:
    1. это паттерн GenericRepository;
    2. при необходимости можно добавить конкретные репозитории (я их называю ConcreteRepository;
    3. ну и конечно же, если всем этим управляет UnitOfWork;


    При использовании такой связки у Вас:
    • если много сущностей и есть GenericRepository, то вам не нужно плодить репозиторий на каждую сущность - достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>();
    • пункт выше автоматически решает проблему "как выбрать данные из 2-3-4-... таблиц" - с репозиториями вы работаете как с DbSet в EF (кстати, сам DbContext из EF, по сути, реализует паттерн UnitOfWork и GenericRepository);
    • автоматически решается вопрос расширения вашего репозитория методами на каждый чих (т.е. надо получить список логов для конкретного пользователя - добавляем новый метод GetLogsByUserId в репозиторий) - не нужно накручивать репозиторий новыми методами, достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>().GetQuery(e => e.UserId == targetUserId) или var unit = UnitOfWork.Repository<UserLog>().AsQuaryableQuery(e => e.UserId == targetUserId) (методы GetQuery и AsQuaryableQuery - это методы у сущности UnitOfWork, которые возвращают IEnumerable или IQueryable соответственно);
    • если методы SaveChanges/Commit реализованы в UnitOfWork (и UnitOfWork управляет транзакциями БД), то у вас решается проблема консистентности данных - UnitOfWork либо подтверждает все изменения (Commit), либо откатывает в случае ошибок (Rollback);
    Или мне спецальный класс завести в которомом сразу будут все репозитории(как dbContext прям)?

    Правильно мыслите - этот специальный класс и есть UnitOfWork. Он "прям как dbContext", только таким образом вы абстрагируетесь от всяких EF, NHibernate и прочих ORM. В итоге вашей бизнес-логике по барабану, какую ORM вы используете.

    Если мне нужен в 1 контроллере/сервисе не 1 репозиторий? мне по 1 их подключать? может мне 15 надо.

    Достаточно подключить 1 UnitOfWork (и лучше это делать через внедрение зависимостей - DI - DependencyInjection с использованием IoC-контейнера, например, Autofac, Ninject, Unity. Autofac лично мне нравится больше хотя бы потому, что у него самая адекватная и понятная документация, чем у Ninject и уж тем более Unity [нет, это не тема для холивара "кто лучше: Autofac/Ninject/Unity/... - это всё выводы из моего личного опыта]).

    И главный вопрос. Нужно ли вообще применять этот паттерн если ты не используешь юнит тестирование, либо не используешь его для покрытия 100% всего кода а только отдельные хелперы? Ведь для перехода на другую бд достаточно будет сменить провайдер если используешь ef, и если вы используете орм врядли вы полностью от неё откажетесь. Зачем писать кучу кода "наперед" с принципом "а вот вдруг мы поменяем бд/ос", да это скорей всего уменьшит изменения кода по сравнению с полной переписыванием проекта. Но если ты уверен что ос и бд не поменяется?

    В любом enterprise-проекте надо думать наперед, даже если это проект "маленький интернет-магазинчик". Потому что через год этот маленький интернет-магазинчик может превратиться в нормальный такой бизнес с очень высокими оборотами и прибылью, и тогда, если у Вас не будет хорошей абстрагированной архитектуры, если у вас не будет модульности, то любая новая задача будет реализовываться со все большим количеством костылей, и любая новая задача будет приводить к неустойчивости системы и повышению степени регресса (проверено!). А вот если вы как архитектор вложите при разработке в вашу систему модульность и абстрагирование компонентов, то вы тем самым уже упростите себе жизнь в будущем, а это означает, что через какое-то время любая задача по изменению системы будет решаться быстрее, надежнее, а значит, вы сможете брать как разработчик за это больше денег (потому что стоимость новых изменений будет гораздо ниже). А если вы еще и юнит-тестирование будете использовать при разработке, то тем самым вы снижаете риск регресса в поведении вашей системы, что опять же, снижает стоимость разработки лично для вас. Поверьте, когда система имеет хотя бы модульность и абстрагирование компонентов друг от друга (т.е. какой-либо компонент зависит от абстракции - в виде интерфейса или абстрактного класса, а не от реализации - в виде конкретного класса), то работа с такой системой будет доставлять удовольствие.

    СУБД менять - это не такая распространенная практика, а вот от ORM (и от EF в частности) отказываться в пользу производительности - это реальный кейс с ростом нагрузки.

    Толстый Лорри - абсолютно с Вами согласен по этому поводу.

    Михаил очень в тему упомянул принцип единственной ответственности. 1 компонент - 1 ответственность. По себе заметил - если следовать хотя бы этому принципу, то уже автоматически система становится модульной. А раз есть модули, то можно снизить степень связанности компонентов между собой, используя абстракции (интерфейсы и абстрактные классы). А раз есть абстрагирование между компонентами, то юнит-тестирование будет только в радость. Причем компонентом может выступать как класс, так и целый проект. Например, в отдельный проект можно вынести какой-нибудь модуль системы, и затем этот проект можно подключить в другую систему при разработке. Таким образом повышается степень повторного использования кода (зачем 2 раза делать одно и то же?).

    Михаил еще также указал в комментарии, в каких случаях репозиторий можно не использовать. Добавлю: в не-enterprise-решениях. Например, вы делаете какой-нибудь простенький сайт для себя. Или для друга. Или просто для изучения новой технологии.
    Ответ написан
    8 комментариев
  • C# программисты, какие сайты вы читаете каждый день?

    hottabxp
    @hottabxp
    Сначала мы жили бедно, а потом нас обокрали..
    Ответ написан
    Комментировать
  • В чем разница между ASP.Net 5 и MVC6, и vNext?

    ASP.Net это по факту набор фреймворков таких как AspNet.Mvc, AspNet.WebApi, AspNet.WebPages (доступны в виде отдельных NuGet пакетов) и т .д. На данный момент ASP.Net базируется на System.Web.dll которая завязана на IIS и Windows поэтому не кросплатформенна.

    Следующая версия которую называют ASP.NET vNext будет по факту ASP.Net 5 (как в итоге будет называть я не знаю). Она будет базироваться на OWIN и её можно будет запустить везде, где работает Mono ( Mac OS X, Linux, Windows).

    MVC 6 будущий релиз для ASP.NET т.е. будет работать везде, MVC 5 завязан на System.Web со всеми вытекающими.
    Ответ написан
    Комментировать