• Где конкретно прочитать про правильную реализацию ООП на javascript?

    Rema1ns
    @Rema1ns
    и так сойдет
    Есть хорошая книга Javascript Шаблоны Стоян Стефанов. Редакция О'рейли.
    Ответ написан
    1 комментарий
  • Ремонтная мастерская дома. Что для этого требуется знать и иметь?

    @polar_winter
    Немного офтоп: оставьте эту затею - вам это нафиг не надо. IMHO всегда задачи определяют инструменты, а не наоборот. Если вы не знаете что вам надо (инструмент) - значит вы не готовы. Всё эти люди которые легко ремонтируют - как правило имеет профильное(похожее) образование и значительный опыт работы по профилю. А то что они говорят что это просто - так они выпендриваются.
    Ещё раз интерес -> знания -> инструменты.
    Ответ написан
    Комментировать
  • Чем опасны кастомные прошивки и рут права?

    Smithson
    @Smithson
    20+ лет админю
    Права рута позволяют вам (именно вам и прежде всего вам) иметь полный контроль над устройством.
    Опасны они прежде всего для производителей андроида и телефона, потому что имея рут, вы можете удалить их рекламные сранки с вашего телефона и даже запретить всемогущему гуглу следить за вами. А это уже покушение на основы.
    По поводу ПО - каждое ПО, которому нужен рут, будет его у вас запрашивать. И ваше личное дело - разрешить или нет конкретной программе иметь рут-доступ к телефону. И разрешить его навсегда или на 10-15 минут (на один запуск), а потом пусть снова просит.
    По большому счету, рут на андроиде нужен для Titanium Backup (установка-удаление, бакап-восстановление приложений), AdAway (блокировщик рекламы) и firewall (разделение доступа к сети, вам же не надо, чтобы за ваш счет по медленному и дорогому 3g какая-нибудь гадость качала вам рекламу? Или сливала ваши фотки в АНБ?). Еще иногда рут нужен программам по исправлению косяков (для вашего удобства!) в андроиде, например, которые открывают запись на SD-карту. Но им он обычно нужен разово. Все остальные перетопчутся.
    Насчет доступа к вашим данным. На андроиде есть такое понятие, как разрешения. Вот в них (вы их видите, когда устанавливаете программу) и прописано, что приложение может делать, а что нет. И наличие у этого приложения рут-доступа ничего тут не поменяет. Есть у него в разрешениях отправка смс или звонки - может звонить и отправлять, не взирая, есть у него рут-доступ или нет. Нету такого разрешения - не может звонить и отправлять.

    И про менеджер паролей - конечно ставьте! Не важно, рутован ваш телефон или нет, это на перехват паролей мало влияет. Зато сторонние клавиатуры (да и родная) могут и видят всё, что вы набираете и могут сливать это в инет. Опять же вне зависимости от того, есть рут или нет. Зато если есть firewall (а ему нужен рут) и клавиатуре доступ в инет закрыт - вот тут можно спать чуть спокойнее.
    Ответ написан
    1 комментарий
  • Почему увеличивается сила тока при параллельном соединении батареек?

    Jump
    @Jump
    Системный администратор со стажем.
    Выясняется, что если соединить батарейки последовательно, то напряжение у них суммируется, а сила тока остается прежней, а если подключить параллельно, то напряжение прежнее, а сила тока суммируется.
    Не правильно.
    Исправная батарейка всегда создает разницу электрических потенциалов между выводами, эта разница называется напряжение.
    Соединяем последовательно - увеличивается напряжение.
    Соединяем параллельно - напряжение не меняется.

    Никакого тока в батарейке нет. поэтому ток не может увеличиваться или уменьшаться!
    Ток это течение!
    Пока батареи не подключили к нагрузке, никакого тока нет! А когда подключили к нагрузке - ток будет зависеть от нагрузки.

    И посоветуйте хорошую книгу
    Сворень Р.А. Электроника шаг за шагом: Практическая энциклопедия юного радиолюбителя.
    Там популярно разжевана вся теория.
    Ответ написан
    Комментировать
  • Как рассчитать схему?

    fox_12
    @fox_12
    Расставляю биты, управляю заряженными частицами
    По цепочке R1 - R2, представляющей собой делитель напряжения, при замкнутом ключе S1 будет протекать ток 12/(2000+1000)=0.004 А. Током в затвор можно пренебречь. Соответственно между землей и точкой G будет 1000*0.004 = 4 В. При разомкнутом ключе потенциал т.G будет стремиться к нулю.
    Аналогично при открытом транзисторе потенциал т. D будет стремиться к нулю, и весь ток будет течь через сопротивление R2 и светодиод HL1. А при закрытом - в т, D. ,будет стремиться к 12 В за вычетом падения напряжения на светодиоде примерно в 0.6-2 В. Потенциал т.S во всех случаях будет равен нулю.
    Ответ написан
    Комментировать
  • Как легче освоить внедрение зависимостей, code-first, TDD и паттерны?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый вечер! Спасибо за приглашение.
    На мой взгляд, Вам следует придерживаться следующих приоритетов по изучению:
    1. внедрение зависимостей более важно из Вашего списка, т.к. относится к SOLID принципам;
    2. TDD - на мой взгляд, вещь более нужная для изучения, чем code-first или patterns. Сам не так давно начал разрабатывать по TDD. Это очень здорово, что изобрели такой подход. Экономит тонну времени на ручное тестирование, а также дает быстрое понимание, что и где случайно (или неслучайно) сломалось. Главное - понимать, что покрывать тестами;
    3. третьим в список я бы добавил AngularJS или KnockoutJS или BackboneJS - сам пока что не изучил их и не начал применять, но судя по их популярности и преимуществам - думаю, Вам стоит с ними ознакомиться;
    4. code-first или database-first - не так уж и важно на Вашем этапе понимания. Главное отличие подхода Code-first: 1) модель пишется вручную, в связи с чем не нужно постоянно отслеживать edmx-диаграмму (т.е. можно считать, что Ваша code-first модель всегда находится в актуальном состоянии); 2) поддерживает миграции БД. В Database-first Вам нужно самому отслеживать актуальность состояния Вашей edmx-модели - с этим тоже могут быть проблемы. Опять же - только с опытом. С другой стороны, Database-first позволяет наглядно видеть Вашу модель, а вот Code-first - нет;
    5. паттернами тоже можете пока что голову не забивать. Безусловно, это нужно, но понимание их придет только с опытом (признаюсь честно: я сам не до конца все паттерны знаю и понимаю). На мой взгляд, важно соблюдать 1 основной паттерн - 3-уровневая архитектура (клиентский слой, слой бизнес-логики, слой работы с данными).

    Теперь по MVC.
    1. Model - тут, в принципе, всё просто: модель данных. Здесь можно поспорить, что иметь в виду под Моделью: модель самих данных или модель представления. Лично я после опыта работы с шаблоном MVVM в WPF под моделью данных в терминах ASP.NET MVC понимаю модель представления, а под термином "модель данных" - саму доменную модель (EF code-first, например). Кто-то может сказать, что это "лишняя работа" - по упаковыванию модели данных из EF-объектов в объекты модели представления. Да, частично соглашусь. Но зато это дает некую гарантию безопасности, что случайно пользователь не поменяет важную часть модели данных (например, ID).
    2. Контроллер. Основная задача контроллера - сформировать данные для отображения и передать эти данные в представление. Т.е. нужно стремиться к тому, чтобы код метода действия в контроллере содержал минимум кода. В идеале - вызов метода из слоя бизнес-логики и передача полученных данных в представление. Если Вы видите, что метод действия в контроллере содержит какую-то бизнес-логику, то это сигнал к рефакторингу: Ваш метод действия слишком много знает. По опыту могу добавить, что в среднем код метода действия содержит от 2 до 20-30 строк кода (с учетом того, что скобки { и } расположены на отдельных строках).
    3. Представление. Тут тоже всё просто: отобразить данные (из модели представления). Ни в коем случае нельзя в представлении писать логику по работе с самими данными, например, так делать нельзя:
    <div id="account">
        @{
            using(var db = new MyEfDbContext()
            {
                var userAccount = db.Accounts.FirstOrDefault(e => e.Username == User.Identity.Username);
                if(userAccount != null)
                {
                    @:Имя: @userAccount.Name
                    @:Фамилия: @userAccount.LastName
                }
            }
        }
    </div>


    Если у Вас 3-уровневая архитектура, например, есть слои:
    1. MyApp.MVC - MVC-application
    2. MyApp.BL - слой бизнес-логики
    3. MyApp.DAL - слой работы с данными
    то в представлении (View) вызывать напрямую сервисы бизнес-логики тоже нельзя, особенно, если Вы используете DI-принцип (внедрение зависимостей) и IoC контейнер. Т.е. такой пример недопустим:
    <div id="account">
        @{
            var accountService = new MyApp.BL.AccountService();
            var userAccount = accountService.GetUserAccountByUsername(User.Identity.Name);
            if(userAccount != null)
            {
                @:Имя: @userAccount.Name
                @:Фамилия: @userAccount.LastName
            }
        }
    </div>

    Попробую донести мысль архитектора и разработчика Александра Шевчука (преподавателя с http://itvdn.com): "Одна из главных целей при разработке - стремиться к упрощению системы". Ослабление зависимостей позволяет нам упрощать систему благодаря тому, что изменение осуществляется только на 1 каком-то слое/уровне. Если Вы во View вынесете логику по работе с данными, а уж тем более, как в примерах выше, работу с EF-контекстом, то Вы усилите зависимость одного компонента системы (MVC-слоя) от другого (слоя работы с данными или слоя бизнес-логики). Усиление зависимостей приводит к бОльшему числу изменений, что в свою очередь сказывается на повышении расходов на эту систему. Ослабление зависимостей приводит к меньшему числу изменений (например, при переходе от EF к native SQL или NHibernate затрагивается только слой работы с данными, а слой MVC и бизнес-логики не меняются), а значит, к более раннему выпуску системы или очередного релиза, и как следствие, снижение расходов (не только денежных, но и других ресурсов) на разработку. TDD тоже можно отнести к практикам, которые снижают затраты ресурсов на содержание системы. Но это я ушел в глобальное...

    Правильным будет подход, при котором у Вас снижается зависимость компонентов системы друг от друга, в случае с ASP.NET MVC приложением, на мой взгляд, это когда:
    - View знает о модели (я по прежнему буду иметь в виду модель представления - ViewModel, которые объявлены либо в MVC-слое, либо в слое бизнес-логики);
    - контроллер знает о слое бизнес-логики, обращается к нему за выполнением операций и получением ViewModel'ей, после чего передает во View полученную ViewModel (ну или JSON-данные);
    - Model формируется по принципу, грубо говоря, почти на каждую View своя модель.

    Фразу "правильным будет подход" я обосновываю тем, что у такого подхода есть масса плюсов (которые очевидны опытным разработчикам, но могут быть не до конца или неправильно поняты менее опытными коллегами, а именно):
    + View ничего не знает о доменной модели (только о ViewModel), благодаря чему Вы можете спокойно менять свою доменную модель, не внося изменений во View (см. выше про ослабление зависимостей и снижение количества связей). Также Вы спокойно можете перейти от EF к NHibernate или к native SQL, или использовать и то, и другое - View об этом никогда не узнает;
    + контроллер (да и весь MVC-слой) знает только о существовании слоя бизнес-логики, но ничего не знает о слое работы с данными.
    + если на View делать отдельную ViewModel, то это позволяет более полноценно управлять тем, что нужно показать пользователю. Т.е. дает возможность большего контроля отображаемых данных, повышает безопасность Вашего приложения (пользователь, например, не сможет изменить ID просматриваемой записи, если этого ID нет вообще в модели представления).

    Ну а вообще все зависит от задачи/проекта: нужно ли применять разбивку на слои или использовать ViewModel'и вместо обычных доменных моделей - надо думать над каждой ситуацией отдельно.

    P.S. На мой взгляд, литературу выбрали правильно - я тоже начинал изучение MVC с нее. Понравилась тем, что дается сначала общее описание и работа с ASP.NET MVC на сквозном примере. А потом идет более глубокое погружение в ASP.NET MVC. По разработке могу посоветовать блог Александра Бындю: blog.byndyu.ru Как мне кажется, там очень хорошо некоторые моменты разжевываются, в том числе SOLID, TDD, шаблон Repository, UnitOfWork и др.
    Ответ написан
    2 комментария
  • Какую фантастику порекомендуете, где главный герой программист/инженер?

    @whiteBlackness
    Мне очень понравился фанфик "Гарри Поттер и рациональное мышление"
    hpmor.ru
    От спеца по ИИ (Элие́зер Шло́мо Юдко́вский )
    Ответ написан
    2 комментария
  • Как влияют указатели на быстроту работу метода считывания цвета с битмапки?

    Nipheris
    @Nipheris Куратор тега C#
    Так влияют, что вы пишете/читаете напрямую в ту память, которая будет потом использовать Bitmap-ом для отрисовки/сохранения и всего прочего. В частности, у вас нет вызовов GetPixel/SetPixel, которые ОЧЕНЬ МЕДЛЕННЫЕ для данной задачи. У вас цикл по двум измерениям картинки, т.е. вызовов GetPixel будет width * height штук. Поверьте, это много и тяжело. Адресная арифметика, а именно
    curpos = ((byte*)bd.Scan0) + h * bd.Stride;
    намного легче. Собственно, возможность ее применения обеспечивается блокировкой реальных данных битмапа методом LockBits. Под блокировкой здесь понимается пометка для кода CLR, в частности для GC, что этот участок памяти трогать нельзя (перемещать, например), пока вы эту пометку не снимете.
    Собственно говоря, более-менее быстрая работа с Bitmap возможна только через BitmapData, так как используя Get/SetPixel вы не дождетесь конца работы вашего алгоритма.
    Ответ написан
    Комментировать
  • Какие изменения можно внести в лучшую сторону, и почему?

    @dmitryKovalskiy
    программист средней руки
    Код читал поверхностно и советов по оптимизации не дам, но скажу что от вашего кода сильно пахнет процедурным программированием. Я тут немножко про другое. Вы калькулятором пользовались когда-нибудь? настоящим или виндовым или еще каким-то. Никто не просит ввести число, никто не просит ввести действия. Человек нажимает последовательность кнопок исходя из которых решается действие. Читайте не строку, а каждую нажатую кнопку. Если цифра - обновить цифру , если знак - проставить действие, если enter - вывести результат. Подумайте не о том как проще написать вычисления вам, а о том как работает реальный калькулятор.
    Ответ написан
    Комментировать
  • Есть ли научно-фантастические книги с обоснованием событий на уровне "Марсианина"?

    skobkin
    @skobkin
    Гентушник, разработчик на PHP и Symfony.
    Вообще, немного не в кассу, но не так давно товарищ Юдковский закончил писать "свою версию" Гарри Поттера - Гарри Поттер и Методы Рационального Мышления (Harry Potter and Methods of Rationality). Начиналось это как безобидный фанфик, но в итоге вылилось в огромную книгу. Науки там не зашкаливающее количество, но она там есть. Есть логика, рациональность и отсутствие роялей в кустах.
    Так что могу порекомендовать и её. Читать интересно, а местами - даже смешно, так как есть масса отсылок к оригиналу с намёком на некоторые глупости.
    Ответ написан
    6 комментариев
  • Как организовать streaming музыки?

    @m0hn
    VLC
    Ответ написан
    Комментировать
  • Как организовать streaming музыки?

    Ответ написан
    Комментировать
  • Какую редакцию Visual Studio скачать?

    @dmitryKovalskiy
    программист средней руки
    Скачайте Visual Studio Express For Desktop. Для изучения WebForms хватит.
    Ответ написан
    Комментировать
  • Как наладить взаимодействие между двумя простыми консольными приложениями?

    profesor08
    @profesor08
    Из приложения "Меню" отправляешь данные на определенный порт, который слушается в приложении "Поле". В приложении "Поле" обрабатывай полученные данные. Все.
    Ответ написан
    Комментировать
  • Можно ли такое реализовать?

    gbg
    @gbg Куратор тега Программирование
    Любые ответы на любые вопросы
    Ответ написан
    Комментировать
  • Как научиться грамотно писать код?

    Visual Studio -> Анализ кода
    d48fb82a6ccf4c39be08cc9a969411e1.pngПрактическое руководство Настройка анализа кода для проекта управляемого кода. Только не включайте все правила сразу, предупреждений будут сотни, включайте по одному, как исправите недочеты (внимательно читая предупреждения на сайте Microsoft), применяйте другие, и так до включения "All".
    Мне эти правила понравились (в каждой компании свои требования к коду), теперь использую везде где пишу сам с нуля.
    Можно использовать StyleCop, но он вроде заброшен, форк есть для Roslyn, но этих хватит что бы научить команду соблюдать практику Microsoft.

    Шаблоны проектирования бесплатная книга, GOF для .NET от сертифицированных специалистов.

    Я понял что этот путь бесконечный, в книгах пишут что люди смотря на свой код написанный год назад "плачут/смеются, говорят - кто это написал." :)
    Испытываю тоже самое.
    Ответ написан
    Комментировать
  • Какие технологии используются сейчас для работы с БД?

    Nipheris
    @Nipheris Куратор тега C#
    ORM-ку сверху накиньте, вместо прямого ADO.Net, и будет вам современные технологии. В тренде, очевидно, Entity Framework, хотя NHibernate - нестареющая классика.
    Можете заморочиться над архитектурой, вплоть до разделения на клиент и сервер - тогда будет место и для Web API.
    Или другой вариант - подтащить документую БД, хотя для бухгалтерии не факт что это хорошее решение (разве что в пару к реляционной, для хранения характеристик ваших товаров).
    Ответ написан
    Комментировать