Последние годы Microsoft пытается стать более дружелюбной для разработчиков компанией и активно участвует в жизни open source-сообщества. Сегодня Microsoft имеет один из крупнейших репозиториев на GitHub, из посвященных разработке свободного ПО. Кроме этого некоторые проприетарные продукты компании переводятся в статус открытого программного обеспечения.

Одним из успехов технологического гиганта в этой области можно назвать перевод .NET в статус open source-продукта с публикацией исходного кода на GitHub. Произошло это еще в ноябре 2014 года — более двух лет назад — и сегодня можно с уверенность констатировать, что этот шаг компании принес ей больше пользы, чем вреда.

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

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

• Параллелизм (часть 1, текущая)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3)
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Этот пост является продолжением поста про оптимизацию производительности списка в React приложении.

Внимание. В данном посте примеры подготовлены специально для Redux приложений. Но сам подход возможно применить и с другими библиотеками. Так же нижеприведенный совет работает в react-redux версии 5. Я не смог достичь желаемого результата в версии 4. Глубоко разбираться в причинах я не стал.

И так, стандартный способ хранить некоторое множество элементов в приложении — это хранить их в массиве:

const state = {
  targets: [{id: 'target1', radius: 10}, {id: 'target2', radius: 2}]
};

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).

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

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

От переводчика

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

Хороший перебор — это отсутствие перебора. Рассмотрим пример замены полного перебора запросом.

В свое время, года 3 назад, возникла необходимость оптимизации конфигурации 1С и устранения ее узких мест в одной компании. Одним из таких узких мест оказался, казалось бы, безобидный, механизм распределения товаров в реализации по сериям. Суть в том, что строк распределялось достаточно много и было это очень медленно. Не миллионы за раз, конечно, но на это самое распределение для одного документа могло уходить до минуты.

Запрос специально привожу на T-SQL, т.к. думаю, что Хабравцам это будет ближе.

Предисловие переводчика

Данная статья представляет собой перевод главы 10 из книги Макруса Хиге (Marcus Heege) «Expert C++/CLI: .NET for Visual C++ Programmers». В этой главе разобрано создание классов-обёрток для нативных классов C++, начиная от тривиальных случаев и до поддержки иерархий и вирутальных методов нативных классов.

Идея этого перевода появилась после статьи «Unmanaged C++ library в .NET. Полная интеграция». Перевод занял больше времени, чем ожидалось, но, возможно, подход, показанный здесь, также будет полезен сообществу.

Связка HTML и CSS (CSS в большей степени) всегда казалась мне несколько «туманной», хуже всего поддающейся контролю и тестированию. Я придумывал для себя различные правила и пытался так или иначе стандартизировать свой подход, но не было ощущения, что «вот, это оно». Я несколько раз мельком знакомился с БЭМ (и не только), читал статьи на эту тему, но дальше чтения дело не заходило. Но чем дальше, тем сильнее было ощущение необходимости в наличии определенной строгой методологии. В конце концов, я решил попробовать внедрить БЭМ на одном из своих проектов, где без этого, на мой взгляд, было не обойтись. Речь идет о CMS, упрощенную страничку бекенда которой я приведу в качестве примера верстки:



Сразу хочу заметить, что БЭМ — это далеко не методология на все случаи жизни, и вопрос о необходимости ее применения в том или ином проекте следует рассматривать в частном порядке (в том числе исходя из того, нравится она вам или нет). Также, в силу того, что я не использовал предлагаемую специфическую файловую структуру или генерацию HTML, о них говорить не будем (позднее я все-таки разделил CSS-файл на отдельные части, соответствующие блокам, но этим решил пока ограничиться). Также, уже достаточно много (например, вот и вот) написано о достоинствах и недостатках этого подхода в целом, поэтому говорить об этом тоже не будем, я просто поделюсь своим опытом и размышлениями на эту тему, предполагая, что с сутью вы уже знакомы.

Эту самую картинку наш технический директор подкладывал в каждую презентацию с комментарием: «Я хочу, чтобы вы были как они.»

Приветствую, дорогой читатель.

В атмосфере взаимодействия гибкости и тесного взаимодействия (на буржуйском — Agile и DevOps) присутствует такое понятие, как Continuous Learning. По сути общая идея заключается в том, чтобы признавать простой факт: как бы усердно ты ни работал, каким бы профессионалом бы ты ни был — ты всегда можешь быть и делать лучше.

Дабы не вызывать комплекс неполноценности, я взял за правило, что мой КПД — 95%.
Эта цифры взята из потолка, но она дает мне право осознавать, что я достаточно вовлечен в процесс, я пытаюсь выжать максимум из своих возможностей, но всегда есть 5% которых мне не хватает до идеала. Набравшись новых знаний, я пробую снова — но цифры всегда остаются прежними — 95% и ни процента больше.

Однако, каждый раз я задаюсь одним и тем же вопросом — становлюсь ли я лучше?

В публикации «Сказка о потерянном времени» пользователь crea7or рассказал, как он опровергал Гипотезу Эйлера на современном CPU.

Мне же было интересно узнать как покажет себя GPU, и я сравнил однопоточный код с многопоточным для CPU и совсем многопоточным для GPU, с помощью архитектуры параллельных вычислений CUDA.

Всем привет из 2018! Оригинальный react-redux-universal-hot-example прекратил развитие в 2017 году, но его можно собрать на версии 6.14.2, на 8 и выше версии будут ошибки. Но есть его форк
https://github.com/bertho-zero/react-redux-universal-hot-example, где продолжается разработка и поддерживаются более свежие версии Nodejs.

Это краткое руководство и обучение по фронтэнеду для бэкендера. В данном руководстве я решаю проблему быстрого построения пользовательского интерфейса к серверному приложению в виде одностраничного веб-приложения (single page app).

Основной целью моего исследования является возможность за разумное время (для одного нормального человека) получить удобный и простой в использовании интерфейс-черновик к серверному приложению. Мы (как разработчики серверной части) понимаем, что наш приоритет — серверная часть. Когда (в гипотетическом проекте) появятся во фронте профи своего дела, они все сделают красиво и "правильно".

В роли учебной задачи представлена страничка чата с каким-то умозрительным "ботом", который работает на стороне сервера и принимает сообщение только через WebSocket. Бот при этом выполняет эхо ваших сообщений (мы тут не рассматриваем серверную часть вообще).

В Интернете есть много разных материалов о том, как правильно делать новые интернет-проекты, как их потом продвигать, как улучшать уже существующий интерфейс и т.д. Но вот чего нет, так это системного взгляда на проблему поддержки и развития существующих проектов. Многие думают, что это как покупка хорошего нового автомобиля: купил и иногда масло меняешь, может новый коврик купишь за пару лет. На самом деле, это неправильный подход: недостаточно раз в год оплачивать хостинг и домен. Даже иногда вносить доработки недостаточно. Сайт — это инструмент, и он должен работать максимально эффективно. Над всеми успешными сайтами работа идет постоянно и непрерывно.

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

Всем привет! Эта статья о том как связать клиентское приложение Angular2 с Rails 5 сервером используя Websocket.

Введение

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

Аарон Густафсон недавно отправил твит Indiegogo, в котором было сказано, что при распечатке их страниц с информацией о заказе получается нечто совершенно неприличное. И понеслооось.

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

Небольшая ремарка: комментарии вКонтакте достаточно… противоречивы. Чтобы не нагружать тебя бесполезной информацией, я хочу тебя предупредить, что это всего лишь мой опыт, и твой будет разниться.

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

И снова здравствуйте! Почти пять лет уже не писал здесь новых статей, хотя, если честно, всегда знал, что рано или поздно начну это делать снова. Не знаю как вам, а мне все таки это дело всегда казалось довольно увлекательным.

Начинать написание нового материала после столь продолжительного отдыха от этого дела — труднее всего. Но раз цель поставлена — надо идти до конца. Начну немного издалека.

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

Под хабракатом вы найдете Quick Start по использованию Docker на уровне, необходимом для решения конкретных задач, обозначенных ниже, без углубления в "дебри" виртуализации и прочих сопутствующих тем. Если вы до сих пор хотите начать успешно использовать эту современную технологию, тем самым значительно упростив целый ряд процессов: от разработки веб-продуктов и до разворачивания и переноса оных под какое-либо современное оборудование — прошу под кат!

Вступление

Всем привет! Данная серия статей — это текстовый вариант моего доклада на WSD в Киеве 26 ноября. Решил написать, чтобы дать более развернутое описание темам, которые были затронуты, а некоторые моменты уточнить. Кроме того, есть возможность рассмотреть больше примеров, услышать мнение от тебя, уважаемый читатель. И, конечно же, поделиться информацией с более широкой аудиторией.

Ключевой особенностью онлайн-сервисов является то, что к ним имеют доступ пользователи практически со всего мира, говорящие на разных языках. Если вы разрабатываете такой сервис и хотите, чтобы им могли пользоваться люди из разных стран, то вам нужно его перевести и адаптировать, иными словами — локализовать.

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