Давайте я за 5-10 минут чтения и понимания коротенькой статьи добавлю вам в резюме строчки «машинное обучение» и «нейронные сети»? Тем, кто далек от программирования, я развею все мифы о сложности ИИ и покажу, что большая часть всех проектов на машинном обучении строится на предельно простых принципах. Поехали — у нас всего пять минут.

Рассмотрим самый базовый пример нейронных сетей — перцептроны; я сам только после этого примера полностью осознал, как работают нейронные сети, так что, если я не накосячу, и вы сможете понять. Помните: никакой магии здесь нет, простая математика уровня пятого класса средней школы.

Взгляните на эту картинку. Персонаж справа — медведь. Так случилось, что он курит марихуану (не спрашивайте, где он её взял. Знать не хочу). Женщину слева я назвал Салли. За исключением того, что у неё пять рук, Салли совершенно обыкновенная, непримечательная деловая женщина. Салли, как и многие другие обыкновенные деловые женщины, ещё и завзятая многозадачница. На картинке она держит свой ноутбук, готовит какой-то десерт, да ещё и балансирует миской с какой-то обжигающе горячей похлёбкой, наверное, из морепродуктов. А теперь главный вопрос. Допустим, у Салли и медведя одинаковый уровень интеллекта (это очень умный медведь), тогда кто из них покажет лучший результат при тестировании когнитивной деятельности? Иными словами, если бы меня интересовала умственная деятельность, что для меня хуже: быть многозадачным или забивать косяк?

Описать понятие прокрастинации можно этим максимально простым изображением. У вас есть ряд определенных задач и есть выделенное время на их выполнение. Прокрастинаторы решают свалить все задачи в кучу и оставить на самый последний момент.

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



Есть даже исследование, которое доказывает, что жизнь прокрастинатора короче, чем жизнь человека, который делает все вовремя, потому что он прокрастинирует даже визиты к врачам.

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

Под катом рассказ Петра Людвига на конференции Aletheia Business 2017 о том, как положить конец прокрастинации используя три простых инструмента. Как только вы внедрите их в свою жизнь, вы сразу заметите разницу. Вы будете более продуктивны, почувствуете себя счастливее и у вас появится больше энергии.

Привет, Хабр! Версия ASP.NET Core основана на проектной модели .NET Core, которая поддерживает создание кросс-платформенных приложений в ОС Windows, Mac и Linux. При реализации проекта .NET Core вы также можете выбрать вариант .NET для своего приложения: .NET Framework (CLR), .NET Core (CoreCLR) или Mono. Какой вариант .NET подойдет вам? Кратко рассмотрим плюсы и минусы каждого и поделимся классными курсами по платформам.

Работа над программами управления контентом CMS (content management system) полна чудес. Под катом поучительная история Petr Palas. Если у вас все хорошо с английским, то в оригинале текст можно почитать здесь. Enjoy!

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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

JSON сейчас один из самых используемых форматов данных в разработке. Большинство современных сервисов возвращают информацию в виде JSON. JSON также предпочитаемый формат для хранения структурированный информации в файлах, например. Так как очень много данных используется в JSON-формате, то поддержка JSON в SQL Server особенно становится актуальной, чтобы иметь возможность обмениваться данными с другими сервисами.

JSON стал одной из самых востребованных фич, добавленных в SQL Server 2016. Далее в статье мы рассмотрим основные механизмы работы с JSON.

Всем привет! Это вторая часть урока для новичков о том, как создать маленькую игру жанра Tower Defence на движке Unity. Мы остановились на создании скрипта для спауна крипов. Если интересно, прошу под кат.

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).

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

В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!

Речь идет не только про подключение штук, которые ломают интерфейс. То, как вы пишете свой собственный код, тоже играет большую роль в стремлении к уменьшению кода. Вот несколько советов и идей. Я писал о них ранее, но в контексте удобства и отзывчивого дизайна. Просто так получается, что гибкий, удобный веб требует меньше контроля с нашей стороны и его сложнее сломать.

/ фото Rachel Johnson CC

Время разработчика – это бесценный ресурс, которого постоянно не хватает. Мы в компании «ИТ-ГРАД» относимся к этому вопросу очень внимательно.

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

В связи с этим мы хотели бы дать несколько советов для руководителей компаний и менеджеров проектов, которые позволят максимально эффективно работать и взаимодействовать с командой разработки.

Будучи исторически погруженным в вопросы разработки модульных приложения на ASP.NET, первое что я сделал, когда вышел ASP.NET Core RC2 – постарался перевести на него свой модульный фреймворк ExtCore. И вот тут оказалось, что в новой версии все изменилось и старые подходы из RC1 больше не работают, зато появились новые интересные возможности, о которых я и хочу рассказать.

Если коротко, то разработка модульных приложений в RC2 очень упрощена. Благодаря новой возможности «части приложения» (application parts), вы легко можете разделить свой большой проект на несколько более мелких и затем свободно компоновать их. Особенно это удобно при работе с областями (areas), которые и так изолируют набор контроллеров, представлений и прочих ресурсов — каждую область теперь можно выделить в отдельный проект. Насколько я понял (в частности, из aspnet/Mvc#4089), реализация ориентирована именно на разделение большого проекта на маленькие и только в части MVC. Остальное все-таки придется писать самому.

К сожалению, не у всех есть браузер/устройство, поддерживающие flexbox. Это руководство в виде шпаргалки, в котором предлагаются альтернативы обратной совместимости для свойств flexbox.

Хотя некоторый CSS-код в этом руководстве, возможно, покажется очевидным, я собираюсь бросить вызов flexbox, а также предложить простые решения проблем, которые возникали, пока он не обрёл популярность.

Делимся с вами саммари (кратким изложением идей) на книгу Майка Микаловица «Метод тыквы. Как стать лидером в своей нише без бюджета». В оригинале книга называется «The Pumpkin Plan. A Simple Strategy to Grow a Remarkable Business in Any Field». Переводчик решил вставить в название фразу «без бюджета», напомнив про предыдущую книгу автора («Стартап без бюджета»). Но всё-таки переводное название вводит в заблуждение. Книга о другом.
Рекомендуем к прочтению тем, кто увяз в работе над собственным делом, кто гоняется за каждым новым заказом, кто устал от плохих клиентов, и всем, кто хочет сделать свой бизнес выдающимся. Возможно, нам есть чему поучиться у фермеров, выращивающих гигантские тыквы.

Итак…

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

В разработке корпоративных приложений очень часто приходится решать задачу выгрузки данных в документы — от небольших справок до больших отчетов.

Хочу поделиться нашим opensource-решением для генерации docx документов, которое позволяет заполнять документы по шаблону, оформление которого можно менять в Word без переписывания кода.

Для начала — немного вводных.

Что нам было нужно от шаблонизатора

• Шаблон создается в Word и сразу видно, на что будет похож результирующий документ, шаблон без лишнего мусора.
• Результирующий документ после скачивания содержит все необходимые данные, не подтягивая их с внешних источников.
• Возможность заполнять списки, таблицы, и иногда еще и таблицы с вложенными в них списками.
• Шаблон можно доверить секретарю клиента, чтобы он мог сменить логотип, реквизиты компании, или как-либо еще подкорректировать оформление. И все это уже после сдачи проекта, не модифицируя наш код.

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).

В этой статье Джеймс Клир (James Clear), расскажет, как использовать законы Ньютона для повышения продуктивности в повседневной жизни.

В свое время у меня накопилось достаточное количество прикольных, но тем не менее бесполезных в быту вещей, одной из которых была трубка для рентгеноструктурного анализа «БСВ-25».

Вам когда-нибудь хотелось прямо в CSS коде посчитать, в меню 4 элемента или 10? Для четырех задать им ширину по 25%, а если набралось десять — прижать их друг к другу и уменьшить отступы?
Как выяснилось, CSS умеет работать с разным количеством элементов, позволяя избавиться от головных болей и лишнего кода на js.