В прошлом году мы в АРПЭ проводили исследование рынка контрактной разработки в России. Вот как выглядела оценка рынка на тот момент: рынок маленький, 1,3 млрд ₽, но растёт. Через три года такими темпами объём рынка должен удвоиться. Ситуация резко изменилась, как это повлияет на рынок контрактной разработки?

Удивительно, но новость из заголовка сообщество почему-то обошло стороной, либо вокруг неё не было особого обсуждения, что достаточно странно, учитывая традиционную заинтересованность аудитории микроэлектроникой. Что ж, давайте восполним этот пробел. Если вам просто интересен вопрос, или же вы специалист и вам есть что сказать - так или иначе добро пожаловать под кат.

Ведь где иначе искать истины в этом вопросе, как не на Хабре...

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

Я верю в "частичные идеи". Бывает, человек крутит в голове половину чего-то важного. А у кого-то есть вторая половина. Чтобы мысли встретились и "клацнули", кто-то должен свою половину опубликовать. Сегодня это делаю я. Считайте это скорее приглашением к обсуждению, нежели готовым рецептом.

С чего все начиналось

Работаю с в строительной компании в проектном отделе. Занимаемся проектированием металлических конструкций. Заказчик передает документацию, которую проектировщики должны превратить в BIM модель. Зачастую в документации Заказчика встречаются несостыковки между отдельными разделами, внутренними стандартами проекта или ГОСТами. В таких случаях пишется технический запрос (technical query) с каким-либо предложением, чтобы конструкция была в соответствии с другими разделами или удовлетворяла стандартам. Написание таких запросов является одной из моих обязанностей. Процесс этот несложный, но жутко рутинный. Ниже схема пайплана этого процесса.

Доброго времени суток, друзья!

Представляю вашему вниманию руководство по Sequelize.

Sequelize — это ORM (Object-Relational Mapping — объектно-реляционное отображение или преобразование) для работы с такими СУБД (системами управления (реляционными) базами данных, Relational Database Management System, RDBMS), как Postgres, MySQL, MariaDB, SQLite и MSSQL. Это далеко не единственная ORM для работы с названными базами данных (далее — БД), но, на мой взгляд, одна из самых продвинутых и, что называется, "battle tested" (проверенных временем).

ORM хороши тем, что позволяют взаимодействовать с БД на языке приложения (JavaScript), т.е. без использования специально предназначенных для этого языков (SQL). Тем не менее, существуют ситуации, когда запрос к БД легче выполнить с помощью SQL (или можно выполнить только c помощью него). Поэтому перед изучением настоящего руководства рекомендую бросить хотя бы беглый взгляд на SQL. Вот соответствующая шпаргалка.

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

Первая часть.
Вторая часть.

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

Представляю вашему вниманию руководство по Sequelize.

Sequelize — это ORM (Object-Relational Mapping — объектно-реляционное отображение или преобразование) для работы с такими СУБД (системами управления (реляционными) базами данных, Relational Database Management System, RDBMS), как Postgres, MySQL, MariaDB, SQLite и MSSQL. Это далеко не единственная ORM для работы с названными базами данных (далее — БД), но, на мой взгляд, одна из самых продвинутых и, что называется, "battle tested" (проверенных временем).

ORM хороши тем, что позволяют взаимодействовать с БД на языке приложения (JavaScript), т.е. без использования специально предназначенных для этого языков (SQL). Тем не менее, существуют ситуации, когда запрос к БД легче выполнить с помощью SQL (или можно выполнить только c помощью него). Поэтому перед изучением настоящего руководства рекомендую бросить хотя бы беглый взгляд на SQL. Вот соответствующая шпаргалка.

Это вторая из 3 частей руководства, в которой мы поговорим о простых и продвинутых ассоциациях (отношениях между моделями), "параноике", нетерпеливой и ленивой загрузке, а также о многом другом.

Первая часть.
Третья часть.

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

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

При реализации потоковых алгоритмов часто возникает задача подсчёта каких-то событий: приход пакета, установка соединения; при этом доступная память может стать узким местом: обычный -битный счётчик позволяет учесть не более событий.
Одним из способов обработки большего диапазона значений, используя то же количество памяти, является вероятностный подсчёт. В этой статье будет предложен обзор известного алгоритма Морриса, а также некоторых его обобщений.

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

Мы начнём с разбора простейшего алгоритма вероятностного подсчёта, выделим его недостатки (раздел 2). Затем (раздел 3) опишем алгоритм, впервые преложенный Робертом Моррисом в 1978 году, укажем его важнейшие свойства и приемущества. Для большинства нетривиальных формул и утверждений в тексте присутствуют наши доказательства — интересующийся читатель сможет найти их во вкладышах. В трёх последующих разделах мы изложим полезные расширения классического алгоритма: вы узнаете, что общего у счётчиков Морриса и экспоненциального распада, как можно уменьшить ошибку, пожертвовав максимальным значением, и как эффективно обрабатывать взвешенные события.

Основные источники

• DOM Living Standart
• HTML Living Standart
• Document Object Model (DOM) Level 3 Core Specification
• DOM Parsing and Serialization

Введение

JavaScript предоставляет множество методов для работы с Document Object Model или сокращенно DOM (объектной моделью документа): одни из них являются более полезными, чем другие; одни используются часто, другие почти никогда; одни являются относительно новыми, другие признаны устаревшими.

Я постараюсь дать вам исчерпывающее представление об этих методах, а также покажу парочку полезных приемов, которые сделают вашу жизнь веб-разработчика немного легче.

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

Сильно погружаться в теорию мы не будем. Вместо этого, мы сосредоточимся на практической составляющей.

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

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